Бази от данни и файлови системи

1.3. Необходимост от информационни системи

Но тъй като информационните системи изискват сложни структури от данни, тези допълнителни индивидуални средства за управление на данните представлявали съществена част от информационните системи и практически се повтаряли от една система към друга. Стремежът да се отдели и обобщи общата част на информационните системи, отговаряща за управлението на сложно структурирани данни, според някои автори, става първата подбудителна причина за създаването на СУБД. Много скоро става ясно, че е невъзможно да се работи без обща библиотека от програми, реализиращи над стандартната базова файлова система по-сложни методи за съхраняване на данни.

Например, да предположим, че искаме да реализираме проста информационна система, поддържаща отчитането на сътрудниците в някаква организация. Системата трябва да изпълнява следните действия: да извежда списъци на сътрудниците по отдели, да поддържа възможността за преместване на сътрудник от един отдел в друг, приемането на работа на нови сътрудници и уволняване на работещи. За всеки отдел трябва да се поддържа възможността за получаване името на ръководителя на този отдел, общата численност на отдела, общата сума на изплатената последна работна заплата и т.н. За всеки сътрудник трябва да се поддържа възможността да се извежда номера на удостоверението по пълното име на сътрудника, извеждане пълното име по номер на удостоверението, получаване на информация за текущото съответствие на заеманата от сътрудника длъжност и за размера на заплатата му.

Да предположим, че сме решили тази информационна система да се основава на файлова система и да се използва освен това един файл, разширявайки базовите възможности на файловата система с помощта на специална библиотека от функции. Тъй като минималната информационна единица в нашия случай е сътрудник, естествено е да се поиска, в този файл да се съдържа един запис за всеки сътрудник. Какви полета трябва да съдържа такъв запис? Пълното име на сътрудника (СЪТР_ИМЕ), номер на удостоверението му (СЪТР_НОМЕР), информация за съответствие на заеманата от него длъжност (за простота, "да" или "не") (СЪТР_СТАТ), размер на работната заплата (СЪТР_ЗАПЛ), номер на отдела (СЪТР_ОТД_НОМЕР). Тъй като искаме да се ограничим с един файл, същият запис трябва да съдържа името на ръководителя на отдела (СЪТР_ОТД_РЪК).

Функциите на нашата информационна система изискват да се осигури възможност за многоключеви достъп към този файл по уникални ключове (недублирани в различните записи) СЪТР_ИМЕ и СЪТР_НОМЕР. Освен това, трябва да осигури възможност за избор на всички записи с общо значение СЪТР_ОТД_НОМЕР, тоест достъп по неуникален ключ. За да се получи числеността на отдела или общият размер на работната заплата, всеки път при изпълнение на такава функция информационната система трябва да избере всички записи за сътрудниците на отдела и да пресметне съответните общи стойности.

Виждa се, че даже за такава проста система нейната реализация на базата на файлова система, първо, изисква създаване на достатъчно сложна надстройка за многоключеви достъп до файловете, и, второ, предизвиква изискване за съществена излишност на съхраняването (за всеки сътрудник на един отдел се повтаря името на ръководителя) и изпълнение на масова извадка и изчисления за получаване на сумарната информация за отделите. Освен това, ако в хода на експлоатация на системата ни се прииска, например, да се издават списъци на сътрудниците, получаващи определена заплата, то ще се наложи или напълно да се преглежда файла, или да се реструктуризира, обявявайки за ключово полето СЪТР_ЗАПЛ.

Първото, което ни идва на ум, това е да се поддържат два многоключеви файла: СЪТРУДНИЦИ и ОТДЕЛИ. Първият файл трябва да съдържат полета СЪТР_ИМЕ, СЪТР_НОМЕР, СЪТР_СТАТ, СЪТР_ЗАПЛ и СЪТР_ОТД_НОМЕР, а вторият - ОТД_НОМЕР, ОТД_РЪК, ОТД_СЪТР_ЗАПЛ (общ размер на заплатата) и ОТД_РАЗМЕР (общ брой сътрудници в отдела). Повечето неудобства, изброени в предишния абзац, ще се преодолеят. Всеки от файловете ще съдържа само недублирана информация, и няма да има необходимост от динамични изчисления на сумарна информация. Ще отбележим, че при такъв преход нашата информационна система трябва да има някои нови особености, сближаващи я със СУБД.

Преди всичко, системата сега трябва да знае, че тя работи с два информационно свързани файла (това е стъпка в посока на схемите на бази от данни), трябва да знае структурата и смисъла на всяко поле (например, че СЪТР_ОТД_НОМЕР във файла СЪТРУДНИЦИ и ОТД_НОМЕР във файла ОТДЕЛИ означават едно и също), а да разбира, че в много случаи изменението на информацията в единия файл трябва автоматично да предизвиква модификация във втория файл, за да може тяхното общо съдържимо да е съгласувано. Например, ако се приема на работа нов сътрудник, то е необходимо да се добави запис във файла СЪТРУДНИЦИ, а също и по съответен начин да промени полетата ОТД_ЗАПЛ и ОТД_РАЗМЕР в записите на файла ОТДЕЛИ, описващи отдела на този сътрудник.

Понятието съгласуваност на данни е ключово понятие за базите от данни. Фактически, ако информационната система (даже и такава проста, както в нашия пример) поддържа съгласуваното съхраняване на информацията в няколко файла, може да се каже, че тя поддържа базата от данни. Ако някоя спомагателна система за управление на данни позволява да се работи с няколко файла, осигурявайки тяхната съгласуваност, може да се нарече система за управление на бази от данни. Вече самото изискване за поддържане на съгласуваност на данните в няколко файла не позволява да се работи без библиотека от функции: такава система трябва да има някои собствени данни (метаданни) и даже знания, определящи целостността на данните.

Но това още не е всичко, което обикновено се изисква от СУБД. Първо, даже в нашия пример е неудобно да се реализират такива заявки като "покажи общата численост на отдела, в който работи Петър Иванов Стефанов". Би било много по-лесно, ако СУБД позволяваше да се формулира такава заявка на близък на потребителите език. Такива езици се наричат езици за заявки към бази от данни. Например, на езика SQL нашата заявка би могла да се изрази във формата:

SELECT ОТД_РАЗМЕР

FROM СЪТРУДНИЦИ, ОТДЕЛИ

WHERE СЪТР_ИМЕ = "ПЕТЪР ИВАНОВ СТЕФАНОВ"

AND СЪТР_ОТД_НОМЕР = ОТД_НОМЕР

По такъв начин, при формулирането на заявка СУБД позволява да не се замисляме за това, как ще се изпълнява тази заявка. Сред нейните метаданни ще се съдържа информация за това, че полето СЪТР_ИМЕ е ключово за файла СЪТРУДНИЦИ, а ОТД_НОМЕР – за файла ОТДЕЛИ, и системата сама ще се възползва от това. Ако възникне потребност от получаване на списъка сътрудници, не съответстващи на заеманата длъжност, то е достатъчно да се предяви към системата заявка

SELECT СЪТР_ИМЕ, СЪТР_НОМЕР

FROM СЪТРУДНИЦИ

WHERE СЪТР_СТАТ = "НЕ",

и системата сама ще изпълни необходимия пълен преглед на файла СЪТРУДНИЦИ, тъй като полето СЪТР_СТАТ не е ключово.

Представете си, че в нашата първоначална реализация на информационната система, основана на използването на библиотеки и разширени методи за достъп до файлове, се обработва операция за регистрация на нов сътрудник. Следвайки изискванията за съгласувано изменение на файловете, информационната система ще вмъкне нов запис във файла СЪТРУДНИЦИ и ще се опита да модифицира записа във файла ОТДЕЛИ, но именно в този момент се случи аварийно изключване на електрозахранването. Очевидно е, че след рестарта на системата нейната база от данни ще бъде в разсъгласувано състояние. Ще трябва да се изясни състоянието (а за това е необходимо явно да се провери съответствието на информацията от файловете СЪТРУДНИЦИ и ОТДЕЛИ) и да се приведе информацията в съгласувано состояние. Истинските СУБД поемат такава работа. Приложната система не е длъжна да се грижи за коректността на състоянието на базата от данни.

Накрая, да си представим, че искаме да осигурим паралелна (например, многотерминална) работа на сътрудниците с базата от от данни. Ако се опрем само на използването на файлове, то за осигуряване на коректността през цялото време на модификацията на някой от двата файла, достъпът на други потребители до този файл ще бъде блокиран (спомнете си възможностите на файловите системи за синхронизация на паралелния достъп). Така, зачисляването на работа на Петър Иванов Стефанов съществено ще затрудни получаването на информация за сътрудника Иван Стефанов Петров, даже и ако те ще работят в различни отдели. Истинските СУБД осигуряват много по-тънка синхронизация на паралелния достъп до данните.

Така, СУБД решават множество проблеми, които трудно или въобще е невъзможно да се решат чрез използването на файлови системи. При това съществуват приложения, за които са напълно достатъчни файловете; приложения, за които трябва да се решава, какво ниво на работа с данните във външната памет е необходимо за тях, и приложения, за които безусловно са нужни бази от данни.