Доступ до бази даних КОРОТКИЙ ОГЛЯД

Перш ніж перейти до обговорення структур зберігання як таких, необхідно спочатку розглянути, в чому, взагалі кажучи, складається весь процес доступу до даних У рішенні задачі пошуку конкретного фрагмента даних в базі даних і передачі його користувачеві бере участь кілька різних рівнів програмного забезпечення Безумовно, подробиці влаштування цих рівнів у значній мірі залежать від конкретної системи (до того ж у різних системах часто застосовується різна термінологія), але використовувані при цьому принципи є досить стандартними, і ці принципи коротко описані нижче (рис Г1)

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

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

3 Нарешті, диспетчер диска визначає фізичне місцезнаходження бажаної сторінки на дис ке і видає необхідний запит на виконання операції введення-виведення на диску

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

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

Диспетчер диска

Рис ГОЛ Загальна схема взаємодії СУБД, диспетчера файлів і диспетчера диска

Диспетчер диска – це компонент базової операційної системи Він являє собою компонент, що відповідає за всі фізичні операції вводу-виводу (в деяких системах його називають компонентом Основних служб введення-виведення) Як такий, цей компонент, безумовно, повинен володіти інформацією проадресах на фізичному дискуНаприклад, після отримання запиту від диспетчера файлів на вибірку деякої зазначеної сторінки р диспетчер диска повинен точно визначити, де сторінка р знаходиться на диску З іншого боку, компонент, що користується послугами диспетчера диска (а саме диспетчер файлів) не повинен володіти такою інформацією Замість цього в диспетчері файлів диск розглядається просто як логічна колекція наборів сторінок (Page set), де кожен набір сторінок являє собою колекцію сторінок постійного розміру Кожен набір сторінок позначається унікальним ідентифікатором набору сторінок Кожна сторінка, в свою чергу, позначаєтьсяномером сторінки,який є унікальним в межах всього диска різні набори сторінок є непересічними (тобто не мають спільних сторінок) Відображення між номерами сторінок і адресами на фізичному диску підтримується і супроводжується диспетчером диска Основною перевагою такої організації доступу (не єдино можливий) є те, що весь код, що відноситься до конкретного пристрою, можна ізолювати в єдиному компоненті

системи (а саме в диспетчері диска), в результаті чого всі компоненти більш високого рівня

(Зокрема диспетчер файлів) можуть стати незалежними від фізичного пристрою

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

■ Вибірка сторінки р з набору сторінок s

■ Заміна сторінки р в наборі сторінок s

■ Додавання нової сторінки до набору сторінок s (тобто отримання порожньої сторінки з набору вільних сторінок і визначення номера нової сторінки р)

■ Видалення сторінки р з набору сторінок s (тобто повернення сторінки р в набір вільних сторінок)

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

Диспетчер файлів

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

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

Кожен файл позначається імям файлу або ідентифікатором файлу, унікальним, щонайменше, в що містить його наборі сторінок, а кожен запис, в свою чергу, позначається номером запису або ідентифікатором запису (Record ID – RID), унікальним, щонайменше, в що містить його файлі (Зазвичай на практиці ідентифікатор запису є унікальним не тільки в містить його файлі, але фактично і на всьому диску, оскільки він, як правило, складається з комбінації номера сторінки і деякого значення, унікального в межах цієї сторінки Див розділ ГЗ)

Операції з файлами, підтримувані диспетчером файлів (тобто операції, які має можливість зажадати СУБД), включають перераховані нижче

■ Вибірка записи r з файлу f

■ Заміна записи r у файлі f

■ Додавання нового запису у файл f і визначення ідентифікатора нового запису р

■ Видалення запису r з файлу f

■ Створення нового файлу f

■ Знищення файлу f

Застосування цих примітивних операцій управління файлами дозволяє в СУБД формувати і маніпулювати структурами зберігання, які є основною темою даного додатка (див розділи Г4-Г7)

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

операційною системою, не зовсім ідеально відповідає вимогам такого додатка спеціального призначення, яким є СУБД Додаткова інформація на цю тему приведена в [Г44]

Кластеризація

Це оглядове опис не буде повним без короткого згадки такої теми, як кластеризація даних Основна ідея, що лежить в основі кластеризації, полягає в тому, що необхідно забезпечити зберігання логічно повязаних записів (які тому часто використовуються спільно) в безпосередній близькості один від одного на фізичному диску Фізична кластеризація даних відіграє виключно важливу роль з точки зору продуктивності, у чому можна легко переконатися на такому прикладі Припустимо, що останньою за часом записом, до якої був виконаний доступ, є rl, а наступна необхідна запис-це r2 Припустимо також, що rl зберігається на сторінці pi, а r2 – на сторінці р2 У такому випадку справедливі наведені нижче твердження

1 Якщо pi і р2 являють собою одну і ту ж сторінку, то для доступу до r2 взагалі не потребу ється яких фізичних операцій введення-виведення, оскільки необхідна сторінка р2 вже буде знаходитися в буфері оперативної памяті

2 Якщо сторінки p1 і р2 є різними, але розташованими на фізичному пристрої дос таточно близько один до одного (зокрема, якщо вони є фізично суміжними), то для дос тупа до r2 буде потрібно фізична операція вводу-виводу (безумовно, за винятком того випадку, що р2 також знаходитиметься в буфері оперативної памяті), але час пошуку, требуе моє в цій операції введення-виведення, буде гранично скорочено, оскільки головки чтеніязапісі вже повинні знаходитися недалеко від потрібної позиції на диску Зокрема, час пере ходу з доріжки на доріжку дорівнюватиме нулю, якщо сторінки p1 і р2 знаходяться на одному і тому ж циліндрі

Як приклад кластеризації розглянемо зазвичай застосовується в даній книзі базу даних постачальників і деталей1

■ Якщо в додатку часто виникає вимога забезпечити послідовний доступ до інфор мації про всі постачальниках в порядку номерів постачальників, то записи постачальників повинні бути кластерізовани таким чином, щоб запис постачальника S1 була фізично розташована близько до запису постачальника S2, запис постачальника S2 – близько до запису постачальника S3 і тд Це-приклад внутріфайловой кластеризації, тобто кластеризації, застосовуваної в межах одного файлу

■ Якщо ж, з іншого боку, в додатку часто виникає вимога забезпечити доступ до даних деякого конкретного постачальника поряд з даними про всі поставки цього постачальника, то записи постачальників і поставок повинні зберігатися з чергуванням таким чином, щоб записи поставок для постачальника S1 були фізично розташовані близько до запису постачальника S1, записи поставок для постачальника S2 – близько до запису постачальника S2 і тд Це – приклад междуфайловой кластеризації, тобто кластеризації, яка застосовується більше ніж до одного файлу

Безумовно, будь-який конкретний файл або набір файлів в будь-який конкретний момент часу може бути фізично кластеризувати не більш ніж одним способом

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

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

існуючої запису Диспетчер диска в свою чергу повинен зробити все від нього залежне, щоб дві логічно суміжні сторінки були фізично суміжними і на диску (див розділ ГЗ)

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

ГЗ НАБОРИ сторінок і файлів

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

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

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

2 Диспетчер файлів ініціює виконання операції створення набору сторінок для записів по ставщика і вставляє пять записів постачальників, які відносяться до постачальників S1-S5 Диспетчер диска видаляє сторінки 1-5 з набору вільних сторінок і відзначає їх як набір сторінок постачальників.

3 Аналогічні дії виконуються для розміщення інформації про деталі і поставках Тепер існують чотири набори сторінок: набір сторінок постачальників (сторінки 1-5), набір сторінок деталей (сторінки 6-11), набір сторінок поставок (сторінки 12-23) і набір вільних сторінок (сторінки 24, 25, 26 і тд) Ситуація, що склалася до цього часу, показана на рис Г2

Продовжимо опис даного прикладу

4 Потім диспетчер файлів вставляє новий запис постачальника (з інформацією про новий постав щіке з номером S6) Диспетчер диска знаходить першу вільну сторінку в наборі вільних сторінок (а саме сторінку 24) і додає її до набору сторінок постачальників

5 Диспетчер файлів видаляє запис з даними про постачальника S2 Диспетчер диска повертає сторінку постачальника S2 (сторінку 2) в набір вільних сторінок

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

6 Диспетчер файлів вставляє новий запис деталі (з даними про деталі Р7) Диспетчер диска на ходить першу вільну сторінку в наборі вільних сторінок (а саме сторінку 2) і добав ляє її до набору сторінок деталей

7 Диспетчер файлів видаляє запис з даними про постачальника S4 Диспетчер диска повертає сторінку для постачальника S4 (сторінку 4) в набір вільних сторінок

Рис Г2 Компонування диска після створення і первинного завантаження бази даних постачальників і деталей

Надалі тривають аналогічні дії, а ситуація, що склалася до цього моменту, показана на рис ГЗ Основний висновок, який може бути зроблений після аналізу цієї ситуації, полягає в наступному: після того як система експлуатувалася певний час, вона більше не може гарантувати, що логічно суміжні сторінки будуть як і раніше фізично суміжними (навіть якщо на самому початку вони були такими) З цієї причини логічна послідовність сторінок в будь-якому конкретному наборі сторінок повинна бути представлена ​​не за допомогою постійної підтримки фізичної суміжності, а за допомогою покажчиків Кожна сторінка повинна містити заголовок сторінки, іншими словами, набір керуючої інформації, яка (крім усього іншого) включає фізичну адресу на диску тієї сторінки, яка безпосередньо випливає за цією сторінкою в логічній послідовності (рис Г4)

На підставі розглянутого прикладу можна зробити наведені нижче висновки

■ Заголовками сторінок (зокрема, покажчиками наступної сторінки) управляє диспетчер диска вони повинні бути повністю невидимими для диспетчера файлів

■ Як було описано в підрозділі про кластеризації в кінці розділу Г2, бажано зберігати логічно суміжні сторінки в фізично суміжних місцях на диску (наскільки це можливо) З цієї причини диспетчер диска зазвичай включає і виключає сторінки з наборів сторінок не по одній, як було описано в даному прикладі, а скоріше у вигляді фізично суміжних груп (або екстентів), що дозволяє включати в набір одночасно (скажімо) 64 сторінки

■ Виникає резонне питання: Як диспетчер диска визначає, де знаходяться різні набори сторінок” або точніше: Як він визначає для кожного набору сторінок, де знаходиться (логи тично) перша сторінка цього набору сторінок (Безумовно, достатньо знайти першу сторінку, оскільки другий і всі інші сторінки можна після цього виявити, слідуючи за вказівниками в заголовках сторінок) Відповідь на це питання полягає в тому, що для зберігання сторінки, утримуючи щей ​​саме цю інформацію, використовується деяке постійне місце на диску (як правило, нульовий циліндр і нульова доріжка) Тому така сторінка (яка згадується під раз вими назвами, такими як зміст диска, каталог диска, каталог набору сторінок або просто нульова сторінка) зазвичай містить список наборів сторінок, існуючих в нас тоящее час на диску, в якому є покажчики на першу сторінку кожного такого набору сторінок (рис Г5)

Рис ГЗ Компонування диска після вставки запису постачальника S6, видалення запису постачальника S2, вставки запису деталі Р7 і видалення запису постачальника S4

Рис Г4 Переглянутий варіант рис ГЗ, на якому показані покажчики наступної сторінки (У верхньому правому куті кожної сторінки)

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

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

1 Насамперед, виконується вставка пяти записів з даними про постачальників S1-S5, які зберігаються разом на деякій сторінці р, як показано на рис Г6 Зверніть увагу на те, що сторінка р все ще містить значний обсяг вільного простору

2 Тепер припустимо, що СУБД вставляє новий запис постачальника (з інформацією про новий по ставщика, скажімо, з номером S9) Диспетчер файлів вносить цю запис на сторінку р (оскільки на ній ще є вільне місце) безпосередньо слідом за записом з даними про по ставщика S5

3 СУБД видаляє запис постачальника S2 Диспетчер файлів стирає запис S2 зі сторінки р і зрушує записи постачальників S3, S4, S5 і S9 вгору, щоб заповнити звільнився проміжок

4 СУБД вставляє новий запис постачальника з інформацією ще про один новий постачальнику, з але мером S7 Диспетчер файлів знову вносить цю запис на сторінку р (оскільки на ній ще є вільне місце) він поміщає новий запис безпосередньо слідом за записом з даними про по ставщика S5, зрушуючи запис постачальника S9 вниз, щоб звільнити місце Ситуація, склавши шаяся до цього часу, показана на рис Г7

Рис Г5 Каталог диска (нульова сторінка)

Рис Г6 Компонування сторінки р після первинного завантаження пяти записів з

Рис Г7 Компонування сторінки р після вставки запису постачальника S9,

видалення запису постачальника S2 і вставки запису постачальника S7

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

Як було показано в розділі Г2, в якості внутрішнього позначення записів використовуються ідентифікатори записів (Record ID – RID) На рис Г8 показано, як звичайно реалізовані ідентифікатори записів Ідентифікатор записи r складається з двох частин: по-перше, номера сторінки р, містить запис r, і, по-друге, зміщення в байтах від кінця сторінки р, що позначає той слот, який в свою чергу містить зсув в байтах записи r від початку сторінки р Ця схема дозволяє досягти прийнятного поєднання характеристик – швидкодії прямої адресації і гнучкості непрямої адресації, оскільки зсув записів вгору і вниз в межах їх містить сторінки (як показано на рис Г7 і Г8) не повязаний з необхідністю коригувати ідентифікатори записів (при кожному зсуві припадає лише коригувати локальні зміщення в нижній частині тієї сторінки, де повинні бути проведені зміни) проте, доступ до кожної конкретної запису за її ідентифікатором відбувається швидко і вимагає тільки одного звернення до сторінки (До того ж вельми бажано, щоб ідентифікатори записів не змінювалися, оскільки вони, як правило, широко використовуються в базі даних як покажчики на розглянуті записи, наприклад, в індексах Якщо ж дійсно відбувається зміна ідентифікатора деякого запису, то виникає необхідність виконати також коригування всіх таких посилань, оформлених у вигляді покажчиків, у всій базі даних)

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

Рис Г8 Принцип практичної реалізації ідентифікаторів записів

третій, то на первісної сторінці покажчик буде відкоректований таким чином, щоб він вказував на те місце, де знаходиться запис в даний час

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

■ Заслуговує на увагу один наслідок з наведеного вище опису, яке полягає в тому, що при використанні будь-якого конкретного файлу завжди можливо забезпечити доступ до всіх записів цього файлу послідовно Тут під терміном послідовно мається на увазі в послідовності записів, що знаходяться на послідовно упорядкованих сторінках в наборі сторінок (Як правило, у порядку зростання ідентифікаторів сторінок) Таку після довність часто неформально називають фізичної послідовністю, хоча має бути очевидно, що вона не обовязково відповідає будь-якої очевидної фізичної послідовно ності на диску Але для зручності аналогічний термін застосовується і надалі изло жении

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

■ Необхідно підкреслити, що фізична послідовність часто виявляється, щонайменше, цілком прийнятною для використання як шляху доступу до якогось конкретного файлу Іноді такий шлях доступу може навіть виявитися оптимальним (особливо якщо файл невеликий) Але набагато частіше зустрічається ситуація, коли потрібно якийсь кращий спосіб доступу А як було зазначено в розділі Г1, для забезпечення такого кращого способу доступу застосовується надзвичайно різноманітний набір методів

■ З метою спрощення до кінця цього додатка зазвичай передбачається, що (унікальної) фізичної послідовністю для будь-якого конкретного файлу є послідовність первинних ключів (як було визначено в розділі ГЗ), якщо явно не вказано інше Але слід враховувати, що це припущення прийнято виключно з метою спрощення наведеного нижче опису автор визнає, що на практиці можуть виникати серйозні підстави для застосування фізичного упорядкування даного конкретного файлу в деякій іншій формі, наприклад, за значенням (значеннями) деякого іншого поля (полів) або просто за часом надходження даних (у хронологічній послідовності)

■ Цілком імовірно, що з різних причин крім звичайних поля з даними в запис доведеться включити певну керуючу інформацію Така інформація зазвичай сосредотачів ается в передній частині запису у формі префікса запису Як приклади того, якого роду інформація зазвичай знаходиться в таких префіксах, можна вказати ідентифікатор включає цю запис файлу (він є обовязковим, якщо одна сторінка може містити записи з декількох файлів), довжину запису (вона є обовязковою для записів змінної довжини), прапорець видалення (обовязковий, якщо записи фізично не стираються під час виконання логічної операції видалення), покажчики (які потрібні, якщо записи якимось чином зєднуються один з одним у ланцюжки) і тд Але, безумовно, вся подібна інформація, що управляє зазвичай прихована від користувача

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

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

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*