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

Лекція 1. Бази даних і файлові системи
На першій лекції ми розглянемо загальне значення понять БД і СУБД. Почнемо з того, що з самого початку розвитку обчислювальної техніки утворилися два основних напрями її використання. Перший напрям - застосування обчислювальної техніки для виконання чисельних розрахунків, які дуже довго або взагалі неможливо проводити вручну. Становлення цього напряму сприяло інтенсифікації методів чисельного рішення складних математичних задач, розвитку класу мов програмування, орієнтованих на зручний запис чисельних алгоритмів, становленню зворотного зв'язку з розробниками нової архітектури ЕОМ.
Другий напрям, який безпосередньо торкається теми нашого курсу, це використання засобів обчислювальної техніки в автоматичних або автоматизованих інформаційних системах. У самому широкому значенні інформаційна система являє собою програмний комплекс, функції якого перебувають в підтримці надійного зберігання інформації в пам'яті комп'ютера, виконанні специфічних для даного додатку перетворень інформації і/або обчислень, наданні користувачам зручного і інтерфейсу, що легко освоюється. Звичайно обсяги інформації, з якими доводиться мати справу таким системам, досить великі, а сама інформація має досить складну структуру. Класичними прикладами інформаційних систем є банківські системи, системи резервування авіаційних або залізничних квитків, місць в готелях і т.д.
Насправді, другий напрям виник трохи пізніше першого. Це пов'язано з тим, що на зорі обчислювальної техніки комп'ютери володіли обмеженими можливостями в частині пам'яті. Зрозуміло, що можна говорити про надійне і довготривале зберігання інформації тільки при наявності запам'ятовуючих пристроїв, що зберігають інформацію після вимкнення електричного живлення. Оперативна пам'ять цією властивістю звичайно не володіє. На початку використовувалися два вигляду пристроїв зовнішньої пам'яті: магнітні стрічки і барабани. При цьому місткість магнітних стрічок була досить велика, але за своїй фізичній природою вони забезпечували послідовний доступ до даних. Магнітні ж барабани (вони більше усього схожі на сучасні магнітні диски з фіксованими головками) давали можливість довільного доступу до даними, але були обмеженого розміру.
Легко бачити, що вказані обмеження не дуже істотні для чисто чисельних розрахунків. Навіть якщо програма повинна обробити (або зробити) великий обсяг інформації, при програмуванні можна продумати розташування цієї інформації у зовнішній пам'яті, щоб програма працювала якнайшвидше.
З іншого боку, для інформаційних систем, в яких потреба в поточних даних визначається користувачем, наявність тільки магнітних стрічок і барабанів незадовільна. Уявіть собі покупця квитка, який стоячи біля каси повинен дочекатися повного перемотування магнітної стрічки. Однією з природних вимог до таких систем є середня швидкість виконання операцій.
Як здається, саме вимоги до обчислювальної техніки з боку незлічених додатків спричинили появу знімних магнітних дисків з рухомими головками, що було революцією в історії обчислювальної техніки. Ці пристрої зовнішньої пам'яті володіли істотно більшою місткістю, ніж магнітні барабани, забезпечували задовільну швидкість доступу до даних в режимі довільної вибірки, а можливість зміни дискового пакету на пристрої дозволяла мати практично необмежений архів даних.
З появою магнітних дисків почалася історія систем управління даними у зовнішній пам'яті. До цього кожна прикладна програма, якій був потрібен зберігати дані у зовнішній пам'яті, сама визначала розташування кожної порції даних на магнітній стрічці або барабані і виконувала обміни між оперативною і зовнішньою пам'яттю за допомогою програмно-апаратних засобів низького рівня (машинних команд або викликів відповідних програм операційної системи). Такий режим роботи не дозволяє або дуже утрудняє підтримку на одному зовнішньому носії декількох архівів інформації, що довго зберігається. Крім того, кожній прикладній програмі доводилося вирішувати проблеми іменування частин даних і структуризації даних у зовнішній пам'яті.
1.1. Файлові системи
Історичним кроком з'явився перехід до використання централізованих систем управління файлами. З точки зору прикладної програми файл - це іменована область зовнішньої пам'яті, в яку можна записувати і з якої можна прочитувати дані. Правила іменування файлів, спосіб доступу до даних, що зберігаються в файлі, і структура цих даних залежать від конкретної системи управління файлами і, можливо, від типу файла. Система управління файлами бере на себе розподіл зовнішньої пам'яті, відображення імен файлів у відповідні адреси у зовнішній пам'яті і забезпечення доступу до даних.
Перша розвинена файлова система була розроблена фірмою IBM для її серії 360. До теперішнього часу вона дуже застаріла, і ми не будемо розглядати її детально. Помітимо лише, що в цій системі підтримувалися як чисто послідовні, так і індексно-послідовні файли, а реалізація багато в чому спиралася на можливості контролерів управління, що тільки з'явилися до цього часу дисковими пристроями. Якщо врахувати до того ж, що поняття файла в OS/360 було вибране як основне абстрактне поняття, якому відповідав будь-який зовнішній об'єкт, включаючи зовнішні пристрої, то працювати з файлами на рівні користувача було дуже незручно. Був потрібен цілий ряд громіздких і переобтяжених деталями конструкцій. Все це добре знайоме програмістам середнього і старшого покоління, які пройшли через використання вітчизняних аналогів комп'ютерів IBM.
1.1.1. Структури файлів
Далі ми будемо говорити про більш сучасні організації файлових систем. Почнемо зі структур файлів. Передусім, практично у всіх сучасних комп'ютерах основними пристроями зовнішньої пам'яті є магнітні диски з рухомими головками, і саме вони служать для зберігання файлів. Такі магнітні диски являють собою пакети магнітних пластин (поверхонь), між якими на одному важелі рухається пакет магнітних головок. Крок рушення пакету головок є дискретним, і кожному положенню пакету головок логічно відповідає циліндр магнітного диска. На кожній поверхні циліндр "висікає" доріжку, так що кожна поверхня містить число доріжок, рівне числу циліндрів. При розмітці магнітного диска (спеціальній дії, попередній використанню диска) кожна доріжка розмічається на одну і ту ж кількість блоків таким чином, що в кожний блок можна записати по максимуму одне і те ж число байтів. Таким чином, для створення обміну з магнітним диском на рівні апаратури треба указати номер циліндра, номер поверхні, номер блоку на відповідній доріжці і число байтів, яке треба записати або прочитати від початку цього блоку.
Однак ця можливість обмінюватися з магнітними дисками порціями менше об'єму блоку в цей час не використовується в файлових системах. Це пов'язано з двома обставинами. По-перше, при виконанні обміну з диском апаратура виконує три основних дії: підведення головок до потрібного циліндра, пошук на доріжці потрібного блоку і власне обмін з цим блоком. З всіх цих дій в середньому найбільший час займає перше. Тому істотний виграш в сумарному часі обміну за рахунок прочитання або запис тільки частини блоку отримати практично неможливо. По-друге, для того, щоб працювати з частинами блоків, файлова система повинна забезпечити відповідного розміру буфера оперативної пам'яті, що істотно ускладнює розподіл оперативної пам'яті.
Тому у всіх файлових системах явно або неявно виділяється деякий базовий рівень, що забезпечує роботу з файлами, що представляють набір прямо що адресуються в адресному просторі файла блоків. Розмір цих логічних блоків файла співпадає або кратний розміру фізичного блоку диска і звичайно вибирається рівним розміру сторінки віртуальної пам'яті, що підтримується апаратурою комп'ютера спільно з операційною системою.
У деяких файлових системах базовий рівень доступний користувачеві, але більш часто прикривається деяким більш високим рівнем, стандартним для користувачів. Поширені два основних підходи. При першому підході, властивому, наприклад, файловим системам операційних систем фірми DEC RSX і VMS, користувачі представляють файл як послідовність записів. Кожний запис - це послідовність байтів постійного або змінного розміру. Записи можна читати або записувати послідовно або розташовувати файл на запис з вказаним номером. Деякі файлові системи дозволяють структурувати записи на поля і оголошувати деякі поля ключами запису. У таких файлових системах можна зажадати вибірку запису з файла по її заданому ключу. Природно, що в цьому випадку файлова система підтримує в тому ж (або іншому, службовому) базовому файлі додаткові, невидимі користувачеві, службові структури даних. Поширені способи організації ключових файлів засновуються на техніці хешування і В-дерев (ми будемо говорити про ці прийоми більш детально в наступних лекціях). Існують і багатоключові способи організації файлів.
Другий підхід, що став поширеним разом з операційною системою UNIX, полягає в тому, що будь-який файл представляється як послідовність байтів. З файла можна прочитати вказане число байтів або починаючи з його початку, або заздалегідь зробивши його позиціонування на байт з вказаним номером. Аналогічно, можна записати вказане число байтів в кінець файла, або заздалегідь зробивши позиціонування файла. Помітимо, що проте прихованим від користувача, але існуючим у всіх різновидах файлових систем ОС UNIX, є базове блокове представлення файла.
Звичайно, для обох підходів можна забезпечити набір перетворюючих функцій, що приводять представлення файла до деякого іншого вигляду. Прикладом тому служить підтримка стандартної файлової середи системи програмування на мові Сі в середовищі операційних систем фірми DEC.
1.1.2. Найменування файлів
Зупинимося коротко на способах іменування файлів. Всі сучасні файлові системи підтримують багаторівневе іменування файлів за рахунок підтримки у зовнішній пам'яті додаткових файлів зі спеціальною структурою - каталогів. Кожний каталог містить імена каталогів і/або файлів, що містяться в даному каталозі. Таким чином, повне ім'я файла складається з списку імен каталогів плюс ім'я файла в каталозі, що безпосередньо містить даний файл. Різниця між способами іменування файлів в різних файлових системах полягає в тому, з чого починається цей ланцюжок імен.
У цьому відношенні є два крайніх варіанти. У багатьох системах управління файлами потрібно, щоб кожний архів файлів (повне дерево довідників) цілком розташовувався на одному дисковому пакеті (або логічному диску, розділі фізичного дискового пакету, що представляється за допомогою коштів операційної системи як окремий диск). У цьому випадку повне ім'я файла починається з імені дискового пристрою, на якому встановлений відповідний диск. Такий спосіб іменування використовується в файлових системах фірми DEC, дуже близько до цього знаходяться і файлові системи персональних комп'ютерів. Можна назвати цю організацію підтримкою ізольованих файлових систем.
Інший крайній варіант був реалізований в файлових системах операційної системи Multics. Ця система заслуговує окремої великої розмови, в ній був реалізований цілий ряд оригінальних ідей, але ми зупинимося тільки на особливостях організації архіву файлів. У файловій системі Multics користувачі представляли всю сукупність каталогів і файлів як єдине дерево. Повне ім'я файла починалося з імені кореневого каталогу, і користувач не зобов'язаний був піклуватися про установку на дисковий пристрій яких-небудь конкретних дисків. Сама система, виконуючи пошук файла на його ім'я, запитувала установку необхідних дисків. Таку файлову систему можна назвати повністю централізованою.
Звичайно, багато в чому централізовані файлові системи зручніше ізольованих: система управління файлами приймає на себе більше рутинної роботи. Але в таких системах виникають істотні проблеми, якщо комусь потрібно перенести піддерево файлової системи на іншу обчислювальну установку. Компромісне рішення застосоване в файлових системах ОС UNIX. На базовому рівні в цих файлових системах підтримуються ізольовані архіви файлів. Один з цих архівів оголошується кореневою файловою системою. Після запуску системи можна "змонтувати" кореневу файлову систему і ряд ізольованих файлових систем в одну загальну файлову систему. Технічно це проводиться за допомогою закладу в кореневій файловій системі спеціальних пустих каталогів. Спеціальний системний виклик кур'єр ОС UNIX дозволяє підключити до одного з цих пустих каталогів кореневий каталог вказаного архіву файлів. Після монтування загальної файлової системи іменування файлів проводиться так само, як якби вона з самого початку була централізованою. Якщо врахувати, що звичайно монтування файлової системи проводиться при розкручуванні системи, то користувачі ОС UNIX звичайно і не задумуються про початкове походження загальної файлової системи.
1.1.3. Захист файлів
Оскільки файлові системи є загальним сховищем файлів, що належать, взагалі кажучи, різним користувачам, системи управління файлами повинні забезпечувати авторизацію доступу до файлів. У загальному вигляді підхід полягає в тому, що по відношенню до кожного зареєстрованого користувача даної обчислювальної системи для кожного існуючого файла вказуються дії, які дозволені або заборонені даному користувачеві. Існували спроби реалізувати цей підхід в повному об'ємі. Але це викликало дуже великі накладні витрати як по зберіганню надмірної інформації, так і по використанню цієї інформації для контролю правомочності доступу.
Тому в більшості сучасних систем управління файлами застосовується підхід до захисту файлів, уперше реалізований в ОС UNIX. У цій системі кожному зареєстрованому користувачеві відповідає пара цілочисельних ідентифікаторів: ідентифікатор групи, до якої відноситься цей користувач, і його власний ідентифікатор в групі. Відповідно, при кожному файлі зберігається повний ідентифікатор користувача, який створив цей файл, і відмічається, які дії з файлом може проводити він сам, які дії з файлом доступні для інших користувачів тієї ж групи, і що можуть робити з файлом користувачі інших груп. Ця інформація дуже компактна, при перевірці потрібна невелика кількість дій, і цей спосіб контролю доступу задовільний в більшості випадків.
1.1.4. Режим багатокористувацького доступу
Останнє, на чому ми зупинимося в зв'язку з файлами, - це способи їх використання в багатокористувацькому середовищі. Якщо операційна система підтримує багатокористувацький режим, цілком реальна ситуація, коли два або більше за користувачів одночасно намагаються працювати з одним і тим же файлом. Якщо всі ці користувачі мають намір тільки читати файл, нічого страшного не станеться. Але якщо хоч би один з них буде змінювати файл, для коректної роботи цієї групи потрібна взаємна синхронізація.
Історично в файлових системах застосовувався наступний підхід. У операції відкриття файла (першої і обов'язкової операції, з якою повинен починатися сеанс роботи з файлом) крім інших параметрів вказувався режим роботи (читання або зміна). Якщо до моменту виконання цієї операції від імені деякої програми А файл вже знаходився у відкритому стані від імені деякої іншої програми В (правильніше говорити "процесу", але ми не будемо вдаватися в термінологічні тонкощі), причому існуючий режим відкриття був несумісним з бажаним режимом (сумісні тільки режими читання), то в залежності від особливостей системи програмі А або повідомлялося про неможливість відкриття файла в бажаному режимі, або вона блокувалася доти, поки програма В не виконає операцію закриття файла.
Помітимо, що в ранніх версіях файлової системи ОС UNIX взагалі не були реалізовані які б те не було засобів синхронізації паралельного доступу до файлів. Операція відкриття файла виконувалася завжди для будь-якого існуючого файла, якщо даний користувач мав відповідні права доступу. При спільній роботі синхронізацію потрібно було проводити поза файловою системою (і особливих коштів для цього ОС UNIX не надавала). У сучасних реалізаціях файлових систем ОС UNIX за бажанням користувача підтримується синхронізація при відкритті файлів. Крім того, існує можливість синхронізації декількох процесів, що паралельно модифікують один і той же файл. Для цього введений спеціальний механізм синхронізаційних захоплень діапазонів адрес відкритого файла.
1.2. Сфери застосування файлів
Після цього короткого екскурсу в історію файлових систем розглянемо можливі області їх застосування. Передусім, звичайно, файли застосовуються для зберігання текстових даних: документів, текстів програм і т.д. Такі файли звичайно утворяться і модифікуються за допомогою різних текстових редакторів. Структура текстових файлів звичайно дуже проста: це або послідовність записів, що містять рядки тексту, або послідовність байтів, серед яких зустрічаються спеціальні символи (наприклад, символи кінця рядка).
Файли з текстами програм використовуються як вхідні тексти компіляторів, які в свою чергу формують файли, що містять об'єктні модулі. З точки зору файлової системи, об'єктні файли також володіють дуже простою структурою - послідовність записів або байтів. Система програмування накладає на цю структуру більш складну і специфічну для цієї системи структуру об'єктного модуля. Підкреслимо, що логічна структура об'єктного модуля невідома файловій системі, ця структура підтримується програмами системи програмування.
Аналогічно йде справа з файлами, що формуються редакторами зв'язків і що містять зображення програм, що виконуються. Логічна структура таких файлів залишається відомою тільки редактору зв'язків і завантажувачу - програмі операційної системи. Приблизно така ж ситуація з файлами, що містять графічну і звукову інформацію.
Одним словом, файлові системи звичайно забезпечують зберігання слабо структурованої інформації, залишаючи подальшу структуризацію прикладним програмам. У перерахованих вище прикладах використання файлів це навіть добре, тому що при розробці будь-якої нової прикладної системи спираючись на прості, стандартні і порівняно дешеві кошти файлової системи можна реалізувати ті структури зберігання, які найбільш природно відповідають специфіці даної прикладної області.
1.3. Потреби інформаційних систем
Однак ситуація корінним образом відрізняється для згадуваних на початку лекції інформаційних систем. Ці системи головним чином орієнтовані на зберігання, вибір і модифікацію постійно існуючої інформації. Структура інформації часто дуже складна, і хоч структури даних різні в різних інформаційних системах, між ними часто буває багато загального. На початковому етапі використання обчислювальної техніки для управління інформацією проблеми структуризації даних вирішувалися індивідуально в кожній інформаційній системі. Вироблялися необхідні надбудови над файловими системами (бібліотеки програм), подібно тому, як це робиться в компіляторах, редакторах і т.д.
Але оскільки інформаційні системи вимагають складних структур даних, ці додаткові індивідуальні засоби управління даними були істотною частиною інформаційних систем і практично повторювалися від однієї системи до іншої. Прагнення виділити і узагальнити загальну частину інформаційних систем, відповідальну за управління складно структурованими даними, було, на наш погляд, першою спонукальною причиною створення СУБД. Дуже скоро стало зрозуміло, що неможливо обійтися загальною бібліотекою програм, що реалізовує над стандартною базовою файловою системою більш складні методи зберігання даних.
Покажемо це на прикладі. Передбачимо, що ми хочемо реалізувати просту інформаційну систему, підтримуючу облік співробітників деякої організації. Система повинна виконувати наступні дії: видавати списки співробітників по відділах, підтримувати можливість перекладу співробітника з одного відділу в інший, прийому на роботу нових співробітників і звільнення працюючих. Для кожного відділу повинна підтримуватися можливість отримання імені керівника цього відділу, загальної чисельності відділу, загальної суми виплаченої в останній раз зарплати і т.д. Для кожного співробітника повинна підтримуватися можливість видачі номера посвідчення на повне ім'я співробітника, видачі повного імені по номеру посвідчення, отримання інформації про поточну відповідність посади співробітника і про розмір його зарплати.
Передбачимо, що ми вирішили засновувати цю інформаційну систему на файловій системі і користуватися при цьому одним файлом, розширивши базові можливості файлової системи за рахунок спеціальної бібліотеки функцій. Оскільки мінімальною інформаційною одиницею в нашому випадку є співробітник, природно зажадати, щоб в цьому файлі містився один запис для кожного співробітника. Які поля повинна містити такий запис? Повне ім'я співробітника (СПІВР_ІМ’Я), номер його посвідчення (СПІВР_НОМЕР), інформацію про його відповідність посади (для простоти, "так" чи "ні") (СПІВР_СТАТ), розмір зарплати (СПІВР_ЗАРП), номер відділу (СПІВР_ВІД_НОМЕР). Оскільки ми хочемо обмежитися одним файлом, той же запис повинен містити ім'я керівника відділу (СПІВР_ВІД_КЕР).
Функції нашої інформаційної системи вимагають, щоб забезпечувалася можливість багатоключового доступу до цього файла по унікальних ключах (що не дублюється в різних записах) СПІВР_ІМ’Я і СПІВР_НОМЕР. Крім того, повинна забезпечуватися можливість вибору всіх записів із загальному значенням СПІВР_ВІД_НОМЕР, тобто доступ по не унікальному ключу. Для того, щоб отримати чисельність відділу або загальний розмір зарплати, кожний раз при виконанні такої функції інформаційна система повинна буде вибрати всі записи про співробітників відділу і полічити відповідні загальні значення.
Таким чином ми бачимо, що навіть для такої простої системи її реалізація на базі файлової системи, по-перше, вимагає створення досить складної надбудови для багатоключового доступу до файлів, і, по-друге, спричиняє вимогу істотної надмірності зберігання (для кожного співробітника одного відділу повторюється ім'я керівника) і виконання масової вибірки і обчислень для отримання сумарної інформації про відділи. Крім того, якщо в ході експлуатації системи нам захочеться, наприклад, видавати списки співробітників, що одержують задану зарплату, то доведеться або повністю переглядати файл, або реструктуризовувати його, оголошуючи ключовим поле СПІВР_ЗАРП.
Перше, що приходить на розум, - це підтримувати два багатоключових файли: СПІВРОБІТНИКИ і ВІДДІЛИ. Перший файл повинен містити поля СПІВР_ІМ’Я, СПІВР_НОМЕР, СПІВР_СТАТ, СПІВР_ЗАРП і СПІВР_ВІД_НОМЕР, а другий - ВІД_НОМЕР, ВІД_РУК, ВІД_СПІВР_ЗАРП (загальний розмір зарплати) і ВІД_РОЗМІР (загальне число співробітників у відділі). Більшість незручностей, перерахованих в попередньому абзаці, будуть усунені. Кожний з файлів буде містити інформацію, що тільки не дублюється, необхідність в динамічних обчисленнях сумарної інформації не виникає. Але помітимо, що при такому переході наша інформаційна система повинна володіти деякими новими особливостями, що зближують її з СУБД.
Передусім, система повинна тепер знати, що вона працює з двома інформаційно пов'язаними файлами (це крок у бік схеми бази даних), повинна знати структуру і значення кожного поля (наприклад, що СПІВР_ВІД_НОМЕР в файлі СПІВРОБІТНИКИ і ВІД_НОМЕР в файлі ВІДДІЛИ означають одне і те ж), а також розуміти, що в ряді випадків зміна інформації в одному файлі повинна автоматично викликати модифікацію у другому файлі, щоб їх загальний вміст був узгодженим. Наприклад, якщо на роботу приймається новий співробітник, то необхідно додати запис в файл СПІВРОБІТНИКИ, а також відповідним образом змінити поля ВІД_ЗАРП і ВІД_РАЗМЕР в записі файла ВІДДІЛИ, що описує відділ цього співробітника.
Поняття узгодженості даних є ключовим поняттям баз даних. Фактично, якщо інформаційна система (навіть така простій, як в нашому прикладі) підтримує узгоджене зберігання інформації в декількох файлах, можна говорити про те, що вона підтримує базу даних. Якщо ж деяка допоміжна система управління даними дозволяє працювати з декількома файлами, забезпечуючи їх узгодженість, можна назвати її системою управління базами даних. Вже тільки вимога підтримки узгодженості даних в декількох файлах не дозволяє обійтися бібліотекою функцій: така система повинна мати деякі власні дані (метадані) і навіть знання, що визначають цілісність даних.
Але це ще не все, що звичайно вимагають від СУБД. По-перше, навіть в нашому прикладі незручно реалізовувати такі запити як "видати загальну чисельність відділу, в якому працює Петро Іванович Сидоренко". Було б набагато простіше, якби СУБД дозволяла сформулювати такий запит на близькому користувачам мові. Такі мови називаються мовами запитів до баз даних. Наприклад, на мові SQL наш запит можна було б виразити в формі:
SELECT ВІД_РОЗМІР
FROM СПІВРОБІТНИКИ, ВІДДІЛИ
WHERE СПІВР_ІМ’Я = "ПЕТРО ІВАНОВИЧ СИДОРЕНКО"
AND СПІВР_ВІД_НОМЕР = ВІД_НОМЕР
Таким чином, при формулюванні запиту СУБД дозволить не задумуватися про те, як буде виконуватися цей запит. Серед її метаданих буде міститися інформація про те, що поле СПІВР_ІМ’Я є ключовим для файла СПІВРОБІТНИКИ, а ВІД_НОМЕР - для файла ВІДДІЛИ, і система сама скористається цим. Якщо ж виникне потреба в отриманні списку співробітників, не відповідних посаді, то досить пред'явити системі запит
SELECT СПІВР_ІМ’Я, СПІВР_НОМЕР
FROM СПІВРОБІТНИКИ
WHERE СПІВР_СТАТ = "НІ",
і система сама виконає необхідний повний перегляд файла СПІВРОБІТНИКИ, оскільки поле СПІВР_СТАТ не є ключовим.
Далі, уявіть собі, що в нашій первинній реалізації інформаційної системи, заснованій на використанні бібліотек розширених методів доступу до файлів, обробляється операція реєстрації нового співробітника. Слідуючи вимогам узгодженої зміни файлів, інформаційна система вставила новий запис в файл СПІВРОБІТНИКИ і мала намір модифікувати запис файла ВІДДІЛИ, але саме в цей момент сталося аварійне вимкнення живлення. Очевидно, що після перезапуску системи її база даних буде знаходитися в неузгодженому стані. Зажадається з'ясувати це (а для цього треба явно перевірити відповідність інформації з файлах СПІВРОБІТНИКИ і ВІДДІЛИ) і привести інформацію в узгоджений стан. Справжня СУБД бере таку роботу на себе. Прикладна система не зобов'язана піклуватися про коректність стану бази даних.
Нарешті, уявимо собі, що ми хочемо забезпечити паралельну (наприклад, багатотермінальну) роботу з базою даних співробітників. Якщо спиратися тільки на використання файлів, то для забезпечення коректності на весь час модифікації будь-кого з двох файлів доступ інших користувачів до цього файла буде блокований (пригадайте можливості файлових систем для синхронізації паралельного доступу). Таким чином, зарахування на роботу Петра Івановича Сидорова істотно загальмує отримання інформації про співробітника Іванові Сидоровичі Петрове, навіть якщо вони будуть працювати в різних відділах. Справжня СУБД забезпечує набагато більш тонку синхронізацію паралельного доступу до даних.
Таким чином, СУБД вирішує безліч проблем, які скрутно або взагалі неможливо вирішити при використанні файлових систем. При цьому існують додатки, для яких цілком досить файлів; додатки, для яких необхідно вирішувати, який рівень роботи з даними у зовнішній пам'яті для них потрібно, і додатки, для яких безумовно потрібні бази даних.

Внимание, отключите Adblock

Вы посетили наш сайт со включенным блокировщиком рекламы!
Ссылка для скачивания станет доступной сразу после отключения Adblock!

Скачать