Въведение в базите данни
Алексей Федоров, Наталия Елманова
Преди да се обърнем към конкретни продукти, струва си да разгледаме какво представлява клиент-сървърната архитектура, как СУБД от страна на сървъра се различават от тези за настолни компютри и какви са общите характеристики на съвременните СУБД от страна на сървъра.
Архитектура клиент-сървър
Както беше отбелязано в предишната статия, мейнфрейм и миникомпютърната обработка, популярна през 70-те години, имаше своите предимства, до известна степен загубени по-късно, в ерата на персоналните компютри и настолните СУБД. По-специално, едно от тези предимства беше централизирането на съхранението и обработката на данни. Въпреки това, широко разпространеното очарование от настолните СУБД и техните мрежови версии, причинено от наличността и евтиността както на самия софтуер, така и на неговата работа, накара много потребители да забравят за "мейнфрейм" модела на компютри за много години.
Вече казахме, че недостатъците на настолните СУБД обикновено не се появяват веднага, а само по време на продължителна работа, когато количеството на съхраняваните данни и броят на потребителите станат достатъчно големи - това води до намаляване на производителността на приложенията, използващи такива СУБД.
Известни са много случаи, когато е закупено скъпо мрежово оборудване за решаване на такива проблеми, за да се увеличи честотната лента на мрежата и са използвани други „трикове“, като например съхраняване на метаданни или най-често използвани данни в клиентски приложения или просто на локални твърди дискове. Често се прилага и подход, водещ до децентрализация на съхранението на данни. Типичен пример за този подход е създаването на няколко локални бази данни от един и същи тип, например за различни отдели на компанията или за различни периоди от време (години, тримесечия, месеци), което улеснява работата,свързани с въвеждането на данни, но оскъпяват статистическата им обработка и анализ – в този случай е необходимо да се обработват данни от различни източници. Въпреки това, всички тези мерки позволиха само да отложат решението на проблема с влошаването на производителността за известно време, но не премахнаха основния недостатък на информационните системи, базирани на настолни СУБД - обработката на данни в клиентското приложение.
Радикално решение на проблема с мрежовия трафик и други проблеми, които възникват с увеличаването на обема на данните и броя на потребителите, беше преходът към архитектурата "клиент-сървър", която заимства много от предимствата на стария "мейнфрейм" изчислителен модел, по-специално централизацията на съхранението и обработката на данни.
Принципът на централизация на съхранението и обработката на данни е основният принцип на архитектурата "клиент-сървър". За реализацията му се използва така нареченият сървър на база данни, който се изпълнява като приложение или услуга на операционната система и само той реално може да манипулира файловете, в които се съхраняват данни - за клиентските приложения тези файлове са абсолютно безполезни (и при правилна организация на потребителския достъп до файловете в мрежата не би трябвало изобщо да са достъпни).
Сървърът на базата данни изпълнява цял набор от дейности по управление на данни. Основните му отговорности са:
-
Изпълнение на потребителски заявки за избор и модифициране на данни и метаданни, получени от клиентски приложения, работещи на персонални компютри от локалната мрежа;
поддържане на референтната цялост на данните съгласно правилата, дефинирани в базата данни;
Обикновен персонален компютър може да се използва като работно място на потребителя, което не позволяваизоставете обичайната работна среда. С други думи, в най-простия случай информационната система клиент-сървър се състои от два основни компонента:
-
сървър на база данни, който управлява данни и изпълнява заявки от клиентски приложения;
Има и по-сложни реализации на архитектурата "клиент-сървър", например многослойни информационни системи, използващи сървъри на приложения, които реализират бизнес логика и обработват данни. Обсъждането на архитектурата на такива системи обаче е извън обхвата на този преглед - може да говорим за такива системи в края на този цикъл.
Предимства на архитектурата клиент-сървър
Информационните системи, които използват архитектурата "клиент-сървър", имат значителни предимства пред своите колеги, създадени на базата на мрежови версии на настолни СУБД. Най-важните от тях ще бъдат разгледани по-долу.
Едно от най-големите предимства на архитектурата клиент-сървър е намаляването на мрежовия трафик при отправяне на заявки. Например, ако е необходимо да изберете пет записа от таблица, съдържаща милион записа, клиентското приложение изпраща заявка до сървъра, която се анализира от сървъра за коректност и, ако заявката е правилна, се компилира, оптимизира и изпълнява. След това резултатът от заявката (същите пет записа, а не цялата таблица изобщо) се изпраща обратно на клиента. В същото време, когато формулирате заявка, не можете да мислите дали има индекси в базата данни, които могат да улеснят търсенето на необходимите записи - ако са, тогава те ще бъдат използвани от сървъра, а ако не, заявката пак ще бъде изпълнена, въпреки че може да отнеме повече време, отколкото приизползване на индекси. Но във всеки случай, независимо дали има индекси или не, само резултатът от заявката се предава на клиентското приложение и в този случай мрежовият трафик не зависи от тяхното присъствие или от броя на записите в таблиците, към които е направена заявката.
Второто предимство на архитектурата клиент-сървър е способността да се съхраняват бизнес правила (като правила за референтна цялост или ограничения на стойността на данните) на сървъра, което избягва дублирането на код в различни клиентски приложения, които споделят обща база данни. Освен това в този случай всяко редактиране на данни, включително редактиране със средства, които не са предоставени от разработчиците на информационната система (например различни помощни програми за администриране на сървъри), може да се извърши само като се вземат предвид тези правила. Ако най-новите версии на някои настолни СУБД могат да съхраняват ограничения върху стойности на данни или текстове на SQL заявки, те обикновено нямат тригери и съхранени процедури - просто няма кой да ги изпълни. Единственото изключение тук може би е Microsoft Data Engine, но, както казахме в предишната статия от тази серия, тази СУБД може да бъде класифицирана като настолна СУБД много условно - всъщност MSDE е локален сървър на база данни, който има всички атрибути, характерни за сървърна СУБД, включително отделен сървърен процес.
В първата статия от тази поредица (вижте Computer-Press 3'2000) вече споменахме, че за описание на бизнес правила от страна на сървъра в най-типичните ситуации (например при внедряване на релации главни/подробни), така наречените CASE-инструменти (CASE означава Computer-Aided System Engineering) често се използват за създаване на диаграми на обекти-връзки. Тези инструменти ви позволяват да описвате такива правила на ниво логическо ифизически модели на данни без никакво програмиране и след това генерира кода за съответните сървърни обекти - тригери, съхранени процедури, сървърни ограничения. В този случай на клиентските приложения ще бъде спестена значителна част от кода, свързан с внедряването на бизнес правила директно в приложението. Отбелязваме също, че част от кода, свързан с обработката на данни, може да бъде имплементиран и като сървърни съхранени процедури, което прави възможно още повече „олекотяване“ на клиентското приложение, което означава, че изискванията към работните станции може да не са толкова високи. Това в крайна сметка намалява цената на информационната система дори при използване на скъпи сървърни СУБД и хардуер.
Съвременните сървърни СУБД също имат широки възможности за архивиране и архивиране на данни и често оптимизиране на изпълнението на заявки. Те също така са склонни да осигуряват паралелна обработка на данни, особено когато използват многопроцесорни компютри като сървър на база данни.
И така, ние разгледахме предимствата на клиент-сървърната архитектура и се уверихме, че тази технология решава много от проблемите, които възникват при използване на настолна СУБД. Въпреки това, преди да обсъдим най-популярната сървърна СУБД, нека обърнем внимание на това как се решава проблемът с надграждането на наследени информационни системи, базирани на настолни СУБД, за да се премине към архитектурата клиент-сървър и какви проблеми могат да възникнат в този случай.
Модернизация на остарели информационни системи
Рано или късно почти всеки разработчик или ИТ мениджър се сблъсква с проблема с модернизирането на остарели информационни системи. У нас все още не е трудно да се срещнебанкови системи, използващи dBase, както и сравнително скорошни търговски разработки, създадени с помощта на Clipper, чиято среда за обмен на данни не е интернет или мрежови протоколи, а куриер с флопи дискове и електрически влак (това не винаги се случва поради невежеството на разработчиците - техните клиенти просто нямат и няма да имат пари за прилично оборудване и подходяща инфраструктура в близко бъдеще). Ето защо смятаме, че проблемът за модернизирането на информационните системи в България ще остане актуален още дълго време.
Всяка организация, която преминава през процес на модернизиране на информационната система, има своите проблеми. В един, потребителите изискват да запазят познатия потребителски интерфейс (тези, които са програмирали в Delphi от дълго време, вероятно си спомнят популярната серия „моля на потребителя, свикнал с DOS“ - как да накарате клавиша Enter да прави това, което обикновено прави клавишът Tab във формата за въвеждане на данни); в друг трябва да можете не само да прехвърлите наследени данни в нова база данни, но и да ги промените в съответствие с новопоявилите се нужди (например да коригирате грешки, направени преди много години при проектирането на данни или да комбинирате данни от няколко различни източника); в третата организация са запазени и използвани голям брой отчети, създадени с помощта на старата настолна СУБД, и е необходимо да се осигури възможност за използването им в новата информационна система; в четвъртия процесът на въвеждане на нови данни протича непрекъснато и това налага ограничения върху това как точно да се извърши процесът на подмяна на СУБД и клиентските приложения.
1. Подмяна на СУБД при запазване на структурата на базата данни и потребителските приложения (или сравнително незначителни надстройки).
2. Подмяна както на СУБД, така и на потребителяприложения, като същевременно поддържа структурата на базата данни.
3. Подмяна на СУБД, потребителски приложения и едновременно с това модернизиране на структурата на базата данни.
Ако говорим за първата опция за надграждане, потребителите на Microsoft Access са най-щастливи в това отношение - процесът на замяна на база данни на Microsoft Access с MSDE (или Microsoft SQL Server) е доста безболезнен и потребителските приложения обикновено остават работещи. Тъй като в този случай всички тези СУБД (Access, MSDE и SQL Server) принадлежат на един и същ производител, прехвърлянето на данни между тях се извършва съвсем коректно, като се запазват всички бизнес правила, дефинирани в базата данни. В допълнение, помощните програми за прехвърляне на данни от Access са включени в комплекта за разпространение на други сървърни СУБД (например Oracle). Сравнително безболезнено е да мигрирате данни от Visual FoxPro към Microsoft SQL Server.
Що се отнася до замяната на други версии на настолни СУБД със сървърни, тук могат да възникнат определени проблеми. Например, когато прехвърляте данни от dBase или Paradox към някаква сървърна СУБД, приложението Delphi, което ги обслужва, може да откаже да работи дори след като библиотеките за достъп до данни са правилно преконфигурирани, особено ако съдържа информация за метаданни. Има и различни проблеми, свързани с използването на малки и главни букви в имената на полетата, използването на български имена на полета (и като цяло локализирани версии, които поддържат националните традиции за писане на числа и дати и често превръщат цифровите данни и дати в нещо невъобразимо, когато се прехвърлят в друга СУБД), несъвместимост на някои типове данни (това се случва особено често при прехвърляне на Paradox таблици към друга СУБД). И накрая, ако в сървърната стаяСУБД дефинира всички бизнес правила, няма гаранция, че те са били перфектно спазени в настолната СУБД, от която се прехвърлят данните, и в този случай известно количество „ръчна“ работа при анализиране на данни, което не отговаря на тези правила, е гарантирано за вас или вашите потребители.
Вторият вариант за надграждане на информационната система е по същество създаването на нов проект на базата на готов модел на данни, плюс току-що обмисленото прехвърляне на данни към нова СУБД. Що се отнася до третия вариант за модернизация, той може да се разглежда като два независими проекта. Първият от тях е създаването на информационна система практически от нулата, вторият е попълването на базата данни с наследени данни. В същото време, тъй като структурите на базата данни са различни, стандартните помощни програми за прехвърляне на данни (налични в комплектите за разпространение на много инструменти за разработка и сървърни СУБД) обикновено не могат да бъдат премахнати тук - като правило, в този случай се създават „еднократни“ приложения, които извършват необходимите трансформации на данни по време на тяхното прехвърляне.
След като обсъдихме проблемите, които възникват при прехвърлянето на информационни системи, които използват настолни СУБД, към архитектурата клиент-сървър, можем да преминем към обсъждане на това какви услуги предоставят съвременните сървърни СУБД и как от тази гледна точка трябва да се ръководи от техния избор.