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

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Файлові системи

Історичним кроком був перехід до використання централізованих систем управління файлами. З точки зору прикладної програми файл - це іменована область зовнішньої пам'яті, в яку можна записувати і з якої можна зчитувати дані. Правила іменування файлів, спосіб доступу до даних, що зберігаються у файлі, і структура цих даних залежать від конкретної системи управління файлами і, можливо, від типу файлу. Система управління файлами бере на себе розподіл зовнішньої пам'яті, відображення імен файлів у відповідні адреси в зовнішній пам'яті та забезпечення доступу до даних.

Перша розвинена файлова система була розроблена фірмою IBM для її серії 360. До теперішнього часу вона дуже застаріла, і ми не будемо розглядати її докладно. Зауважимо лише, що в цій системі підтримувалися як чисто послідовні, так і індексно-послідовні файли, а реалізація багато в чому спиралася на можливості тільки що з'явилися до цього часу контролерів керування дисковими пристроями. Якщо врахувати до того ж, що поняття файлу в OS/360 було вибрано як основний абстрактне поняття, якому відповідав будь-який зовнішній об'єкт, включаючи зовнішні пристрої, то працювати з файлами на рівні користувача було дуже незручно. Був потрібен цілий ряд громіздких і перевантажених деталями конструкцій. Все це добре знайоме програмістам середнього і старшого покоління, які пройшли через використання вітчизняних аналогів комп'ютерів IBM.

1.1.1. Структури файлів

Далі ми будемо говорити про більш сучасних організаціях файлових систем. Почнемо зі структур файлів. Перш за все, практично у всіх сучасних комп'ютерах основними пристроями зовнішньої пам'яті є магнітні диски з рухомими головками, і саме вони служать для зберігання файлів. Такі магнітні диски представляють собою пакети магнітних пластин (поверхонь), між якими на одному важелі рухається пакет магнітних головок. Крок руху пакету головок є дискретним, і кожному положенню пакету головок логічно відповідає циліндр магнітного диска. На кожній поверхні циліндр "висікає" доріжку, так що кожна поверхня містить кількість доріжок, яка дорівнює кількості циліндрів. При розмітці магнітного диска (спеціальному дії, що передує використання диска) кожна доріжка розмічається на одне і те ж кількість блоків таким чином, що в кожен блок можна записати по максимуму одне і те ж число байтів. Таким чином, для твору обміну з магнітним диском на рівні апаратури потрібно вказати номер циліндра, номер поверхні, номер блоку на відповідній доріжці і число байтів, яке потрібно записати або прочитати від початку цього блоку.

Однак ця можливість обмінюватися з магнітними дисками порціями менше обсягу блоку в даний час не використовується у файлових системах. Це пов'язано з двома обставинами. По-перше, при виконанні обміну з диском апаратура виконує три основні дії: підведення головок до потрібного циліндра, пошук на доріжці потрібного блоку і власне обмін з цим блоком. З усіх цих дій в середньому найбільший час займає перше. Тому істотний виграш у сумарному часу обміну за рахунок зчитування або запису тільки частини блоку отримати практично неможливо. По-друге, для того, щоб працювати з частинами блоків, файлова система повинна забезпечити відповідного розміру буфера оперативної пам'яті, що істотно ускладнює розподіл оперативної пам'яті.

Тому у всіх файлових системах явно чи неявно виділяється деякий базовий рівень, що забезпечує роботу з файлами, що представляють набір прямо адресованих в адресному просторі файлу блоків. Розмір цих логічних блоків файлу збігається або кратний розміру фізичного блоку диска і зазвичай вибирається рівним розміром сторінки віртуальної пам'яті, підтримуваної апаратурою комп'ютера спільно з операційною системою.

У деяких файлових системах базовий рівень доступний користувачеві, але більш часто прикривається деяким більш високим рівнем, стандартним для користувачів. Поширені два основних підходи. При першому підході, властивому, наприклад, файлових систем операційних систем фірми DEC RSX і VMS, користувачі представляють файл як послідовність записів. Кожна запис - це послідовність байтів постійного або змінного розміру. Записи можна читати або записувати послідовно або позиціонувати файл на запис з вказаним номером. Деякі файлові системи дозволяють структурувати записи на поля і оголошувати деякі поля ключами запису. У таких файлових системах можна вимагати вибірку запису з файлу за її заданому ключу. Природно, що в цьому випадку файлова система підтримує в тому ж (або іншому, службовому) базовому файлі додаткові, невидимі користувачеві, службові структури даних. Поширені способи організації ключових файлів грунтуються на техніці хешування і B-дерев (ми будемо говорити про ці прийомах більш детально в наступних лекціях). Існують і многоключевие способи організації файлів.

Другий підхід, що став поширеним разом з операційною системою UNIX, полягає в тому, що будь-який файл представляється як послідовність байтів. З файлу можна прочитати вказане число байтів або починаючи з його початку, або попередньо зробивши його позиціонування на байт з вказаним номером. Аналогічно, можна записати вказане число байтів в кінець файлу, або попередньо провівши позиціонування файлу. Зауважимо, що тим не менш прихованим від користувача, але існуючим у всіх різновидах файлових систем ОС UNIX, є базове блочне представлення файлу.

Звичайно, для обох підходів можна забезпечити набір перетворюючих функцій, що призводять подання файлу до деякого іншого виду. Прикладом тому служить підтримання стандартної файлової середовища системи програмування на мові Сі в середовищі операційних систем фірми DEC.

1.1.2. Іменування файлів

Зупинимося коротко на способах іменування файлів. Всі сучасні файлові системи підтримують багаторівневе іменування файлів за рахунок підтримки у зовнішній пам'яті додаткових файлів зі спеціальною структурою - каталогів. Кожен каталог містить імена каталогів та / або файлів, що містяться в даному каталозі. Таким чином, повне ім'я файлу складається зі списку імен каталогів плюс ім'я файлу в каталозі, безпосередньо містить цей файл. Різниця між способами іменування файлів в різних файлових системах полягає в тому, з чого починається цей ланцюжок імен.

У цьому відношенні є два крайні варіанти. У багатьох системах управління файлами потрібно, щоб кожен архів файлів (повне дерево довідників) цілком розташовувався на одному дисковому пакеті (або логічному диску, у розділі фізичного дискового пакета, яка подається за допомогою засобів операційної системи як окремий диск). У цьому випадку повне ім'я файлу починається з імені дискового пристрою, на якому встановлений відповідний диск. Такий спосіб іменування використовується у файлових системах фірми DEC, дуже близько до цього знаходяться і файлові системи персональних комп'ютерів. Можна назвати цю організацію підтриманням ізольованих файлових систем.

Інший крайній варіант був реалізований у файлових системах операційної системи Multics. Ця система заслуговує окремої великої розмови, в ній був реалізований цілий ряд оригінальних ідей, але ми зупинимося тільки на особливостях організації архіву файлів. У файловій системі Miltics користувачі представляли всю сукупність каталогів і файлів, як єдине дерево. Повне ім'я файлу починалося з імені кореневого каталогу, і користувач не зобов'язаний був піклуватися про встановлення на дисковий пристрій будь-яких конкретних дисків. Сама система, виконуючи пошук файлу по його імені, запитувала установку необхідних дисків. Таку файлову систему можна назвати повністю централізованою.

Звичайно, багато в чому централізовані файлові системи зручніше ізольованих: система управління файлами приймає на себе більше рутинної роботи. Але в таких системах виникають істотні проблеми, якщо комусь потрібно перенести піддерево файлової системи на іншу обчислювальну установку. Компромісне рішення застосоване в файлових системах ОС UNIX. На базовому рівні в цих файлових системах підтримуються ізольовані архіви файлів. Один з цих архівів оголошується кореневої файлової системою. Після запуску системи можна "змонтувати" кореневу файлову систему і ряд ізольованих файлових систем в одну загальну файлову систему. Технічно це здійснюється за допомогою закладу в кореневій файловій системі спеціальних порожніх каталогів. Спеціальний системний виклик кур'єр ОС UNIX дозволяє підключити до одного з цих порожніх каталогів кореневий каталог зазначеного архіву файлів. Після монтування загальної файлової системи іменування файлів проводиться так само, як якщо б вона з самого початку була централізованою. Якщо врахувати, що зазвичай монтування файлової системи здійснюється при розкручуванні системи, то користувачі ОС UNIX зазвичай і не замислюються про вихідний походження загальної файлової системи.

1.1.3. Захист файлів

Оскільки файлові системи є загальним сховищем файлів, що належать, взагалі кажучи, різним користувачам, системи управління файлами повинні забезпечувати авторизацію доступу до файлів. У загальному вигляді підхід полягає в тому, що по відношенню до кожного зареєстрованому користувачеві даної обчислювальної системи для кожного існуючого файлу вказуються дії, які дозволені або заборонені даному користувачеві. Існували спроби реалізувати цей підхід у повному обсязі. Але це викликало дуже великі накладні витрати як зі зберігання надлишкової інформації, так і з використання цієї інформації для контролю правомочності доступу.

Тому в більшості сучасних систем управління файлами застосовується підхід до захисту файлів, вперше реалізований в ОС UNIX. У цій системі кожному зареєстрованому користувачеві відповідає пара цілочисельних ідентифікаторів: ідентифікатор групи, до якої належить цей користувач, і його власний ідентифікатор у групі. Відповідно, при кожному файлі зберігається повний код користувача, який створив цей файл, і наголошується, які дії з файлом може виробляти він сам, які дії з файлом доступні для інших користувачів тієї ж групи, і що можуть робити з файлом користувачі інших груп. Ця інформація дуже компактна, при перевірці потрібна невелика кількість дій, і цей спосіб контролю доступу задовільний в більшості випадків.

1.1.4. Режим багатокористувацького доступу

Останнє, на чому ми зупинимося у зв'язку з файлами, - це способи їх використання в багатокористувацької середовищі. Якщо операційна система підтримує багатокористувацький режим, цілком реальна ситуація, коли два або більше користувачів одночасно намагаються працювати з одним і тим же файлом. Якщо всі ці користувачі збираються тільки читати файл, нічого страшного не станеться. Але якщо хоча б один з них буде вносити зміни до файлу, для коректної роботи цієї групи потрібна взаємна синхронізація.

Історично в файлових системах застосовувався наступний підхід. В операції відкриття файлу (першої та обов'язкової операції, з якою повинен починатися сеанс роботи з файлом) крім інших параметрів вказувався режим роботи (читання або зміна). Якщо до моменту виконання цієї операції від імені певної програми A файл вже знаходився у відкритому стані від імені деякої іншої програми B (правильніше говорити "процесу", але ми не будемо вдаватися в термінологічні тонкощі), причому існуючий режим відкриття був несумісним з бажаним режимом ( сумісні тільки режими читання), то в залежності від особливостей системи програмою A або повідомлялося про неможливість відкриття файлу в бажаному режимі, або вона блокувалася до тих пір, поки програма B не виконає операцію закриття файлу.

Зауважимо, що в ранніх версіях файлової системи ОС UNIX взагалі не були реалізовані які б то не було кошти синхронізації паралельного доступу до файлів. Операція відкриття файлу виконувалася завжди для будь-якого існуючого файлу, якщо даний користувач мав відповідні права доступу. При спільній роботі синхронізацію слід було проводити поза файлової системи (і особливих засобів для цього ОС UNIX не надавала). У сучасних реалізаціях файлових систем ОС UNIX за бажанням користувача підтримується синхронізація при відкритті файлів. Крім того, існує можливість синхронізації декількох процесів, паралельно модифікуючих один і той же файл. Для цього введено спеціальний механізм синхронізаційних захоплень діапазонів адрес відкритого файлу.

Області застосування файлів

Після цього короткого екскурсу в історію файлових систем розглянемо можливі області їх застосування. Перш за все, звичайно, файли застосовуються для зберігання текстових даних: документів, текстів програм і т.д. Такі файли зазвичай утворюються і модифікуються за допомогою різних текстових редакторів. Структура текстових файлів зазвичай дуже проста: це або послідовність записів, що містять рядки тексту, або послідовність байтів, серед яких зустрічаються спеціальні символи (наприклад, символи кінця рядка).

Файли з текстами програм використовуються як вхідні тексти компіляторів, які в свою чергу формують файли, що містять об'єктні модулі. З погляду файлової системи, об'єктні файли також мають дуже простою структурою - послідовність записів або байтів. Система програмування накладає на цю структуру більш складну і специфічну для цієї системи структуру об'єктного модуля. Підкреслимо, що логічна структура об'єктного модуля невідома файлової системі, ця структура підтримується програмами системи програмування.

Аналогічно іде справа з файлами, які формувались редакторами зв'язків та містять образи виконуваних програм. Логічна структура таких файлів залишається відомою лише редактору зв'язків і завантажувачу - програмі операційної системи. Приблизно така ж ситуація з файлами, що містять графічну і звукову інформацію.

Одним словом, файлові системи зазвичай забезпечують зберігання слабо структурованої інформації, залишаючи подальшу структуризацію прикладним програмам. У перерахованих вище випадках використання файлів це навіть добре, тому що при розробці будь-якої нової прикладної системи спираючись на прості, стандартні і порівняно дешеві кошти файлової системи можна реалізувати ті структури зберігання, які найбільш природно відповідають специфіці даної прикладної області.

Потреби інформаційних систем

Однак ситуація докорінно відрізняється для згадуваних на початку лекції інформаційних систем. Ці системи головним чином орієнтовані на зберігання, вибір і модифікацію постійно існуючої інформації. Структура інформації часто дуже складна, і хоча структури даних різні в різних інформаційних системах, між ними часто буває багато спільного. На початковому етапі використання обчислювальної техніки для управління інформацією проблеми структуризації даних вирішувалися індивідуально в кожній інформаційній системі. Проводилися необхідні надбудови над файловими системами (бібліотеки програм), подібно до того, як це робиться в компіляторах, редакторах і т.д.

Але оскільки інформаційні системи вимагають складних структур даних, ці додаткові індивідуальні засоби керування даними були істотною частиною інформаційних систем і практично повторювалися від однієї системи до іншої. Прагнення виділити і узагальнити загальну частина інформаційних систем, відповідальну за управління складно структурованими даними, стало, на наш погляд, першою причиною спонукальної створення СУБД. Дуже скоро стало зрозуміло, що неможливо обійтися загальної бібліотекою програм, що реалізує над стандартної базової файлової системою більш складні методи зберігання даних.

Покажемо це на прикладі. Припустимо, що ми хочемо реалізувати просту інформаційну систему, що підтримує облік співробітників деякої організації. Система повинна виконувати наступні дії: видавати списки співробітників по відділах, підтримувати можливість переведення працівника з одного відділу в інший, прийому на роботу нових співробітників і звільнення працюючих. Для кожного відділу повинна підтримуватися можливість отримання імені керівника цього відділу, загальної чисельності відділу, загальної суми виплаченої в останній раз зарплати і т.д. Для кожного співробітника має підтримуватися можливість видачі номера посвідчення по повному імені співробітника, видачі повного імені за номером посвідчення, отримання інформації про поточний відповідність займаній посаді співробітника і про розмір його зарплати.

Припустимо, що ми вирішили засновувати цю інформаційну систему на файловій системі і користуватися при цьому одним файлом, розширивши базові можливості файлової системи за рахунок спеціальної бібліотеки функцій. Оскільки мінімальної інформаційної одиницею у нашому випадку є співробітник, природно вимагати, щоб у цьому файлі містилася один запис для кожного співробітника. Які поля повинна містити такий запис? Повне ім'я співробітника (СОТР_ІМЯ), номер його посвідчення (СПІВР_НОМЕР), інформацію про його відповідність займаній посаді (для простоти, "так" або "ні") (СОТР_СТАТ), розмір зарплати (СПІВР_ЗАРП), номер відділу (СОТР_ОТД_НОМЕР). Оскільки ми хочемо обмежитися одним файлом, та ж запис повинен містити ім'я керівника відділу (СОТР_ОТД_РУК).

Функції нашої інформаційної системи вимагають, щоб забезпечувалася можливість многоключевого доступу до цього файлу за унікальними ключами (недубліруемим в різних записах) СОТР_ІМЯ і СПІВР_НОМЕР. Крім того, повинна забезпечуватися можливість вибору всіх записів з загалом значенням СОТР_ОТД_НОМЕР, тобто доступ по неунікальним ключу. Для того, щоб отримати чисельність відділу чи загальний розмір зарплати, кожного разу при виконанні такої функції інформаційна система повинна буде вибрати всі записи про співробітників відділу і порахувати відповідні загальні значення.

Таким чином ми бачимо, що навіть для такої простої системи її реалізація на базі файлової системи, по-перше, потребує досить складної надбудови для многоключевого доступу до файлів, і, по-друге, викликає вимога істотною надмірності зберігання (для кожного співробітника одного відділу повторюється ім'я керівника) і виконання масової вибірки і обчислень для отримання сумарної інформації про відділи. Крім того, якщо в ході експлуатації системи нам захочеться, наприклад, видавати списки співробітників, які отримують задану зарплату, то доведеться або повністю переглянути файл, або реструктурізовивать його, оголошуючи ключовим полі СПІВР_ЗАРП.

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

Перш за все, система повинна тепер знати, що вона працює з двома інформаційно пов'язаними файлами (це крок у бік схеми бази даних), повинна знати структуру і зміст кожного поля (наприклад, що СОТР_ОТД_НОМЕР у файлі СПІВРОБІТНИКИ і ВІД_НОМЕР у файлі ВІДДІЛИ означають одне і те ж), а також розуміти, що в ряді випадків зміна інформації в одному файлі має автоматично викликати модифікацію у другому файлі, щоб їх загальний вміст було узгодженим. Наприклад, якщо на роботу приймається новий співробітник, то необхідно додати запис в файл СПІВРОБІТНИКИ, а також відповідним чином змінити поля ОТД_ЗАРП і ОТД_РАЗМЕР в записі файлу ВІДДІЛИ, яка описує відділ цього співробітника.

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

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

SELECT ОТД_РАЗМЕР

FROM СПІВРОБІТНИКИ, ВІДДІЛИ

WHERE СОТР_ІМЯ = "ПЕТРО ІВАНОВИЧ СИДОРОВ"

AND СОТР_ОТД_НОМЕР = ВІД_НОМЕР

Таким чином, при формулюванні запиту СУБД дозволить не замислюватися про те, як буде виконуватися цей запит. Серед її метаданих буде міститися інформація про те, що поле СОТР_ІМЯ є ключовим для файлу СПІВРОБІТНИКИ, а ВІД_НОМЕР - для файлу ВІДДІЛИ, і система сама скористається цим. Якщо ж виникне потреба в отриманні списку співробітників, які не відповідають займаній посаді, то достатньо пред'явити системі запит

SELECT СОТР_ІМЯ, СПІВР_НОМЕР

FROM СПІВРОБІТНИКИ

WHERE СОТР_СТАТ = "НІ",

і система сама виконає необхідний повний перегляд файлу СПІВРОБІТНИКИ, оскільки поле СОТР_СТАТ не є ключовим.

Далі, уявіть собі, що в нашої початкової реалізації інформаційної системи, заснованої на використанні бібліотек розширених методів доступу до файлів, обробляється операція реєстрації нового співробітника. Слідуючи вимогам узгодженого зміни файлів, інформаційна система вставила новий запис у файл СПІВРОБІТНИКИ і збиралася модифіковані запис файлу ВІДДІЛИ, але саме в цей момент відбулося аварійне вимкнення живлення. Очевидно, що після перезапуску системи її база даних буде знаходитися в рассогласованного стані. Буде потрібно з'ясувати це (а для цього потрібно явно перевірити відповідність інформації з файлах СПІВРОБІТНИКИ і ВІДДІЛИ) і привести інформацію в узгоджене стан. Справжні СУБД беруть таку роботу на себе. Прикладна система не зобов'язана піклуватися про коректність стану бази даних.

Нарешті, уявімо собі, що ми хочемо забезпечити паралельну (наприклад, багатотермінальних) роботу з базою даних співробітників. Якщо спиратися тільки на використання файлів, то для забезпечення коректності на весь час модифікації будь-якого з двох файлів доступ інших користувачів до цього файлу буде блокований (згадайте можливості файлових систем для синхронізації паралельного доступу). Таким чином, зарахування на роботу Петра Івановича Сидорова істотно загальмує отримання інформації про співробітника Іван Сидорович Петрові, навіть якщо вони будуть працювати в різних відділах. Справжні СУБД забезпечують набагато більш тонку синхронізацію паралельного доступу до даних.

Таким чином, СУБД вирішують безліч проблем, які важко або взагалі неможливо вирішити при використанні файлових систем. При цьому існують додатки, для яких цілком достатньо файлів; програми, для яких необхідно вирішувати, який рівень роботи з даними у зовнішній пам'яті для них вимагається, і додатки, для яких безумовно потрібні бази даних.


Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Доповідь
47.1кб. | скачати


Схожі роботи:
Файлові системи і бази даних Потреби інформаційних систем
Просопографіческіе бази даних Росії на прикладі баз даних Comandarm і Duma1
Створення бази даних критичних властивостей речовин в редакторі баз даних MS Access
Використання електронної таблиці як бази даних Сортування і фільтрація даних в Microsoft Excel
Web-сервери бази даних в Інтернет Пошук інформації в Інтернет Основні системи та засоби
Бази даних банки даних загальне поняття
Захист даних і адміністрування бази даних
Файлові системи
Типові файлові системи та їх особливості
© Усі права захищені
написати до нас