Основні різновиди моделей даних
Для представлення і подальшого збереження та обробки сукупності взаємопов'язаних даних представляють у вигляді узагальнених структур. Ці структури називають також моделями даних, бо вони відбивають певне представлення користувача про дані реального світу.
Модель даних – це інтегрований набір понять для опису даних, зв'язків між ними й обмежень, що накладаються на дані. Це певна абстракція, інтелектуальний засіб, використання якого дає змогу інтерпретувати дані у відповідності з висунутими вимогами не просто як відомості, а як інформацію, тобто відбити зміст і взаємозв’язки між окремими даними.
Моделі даних (МодД) враховують семантику і синтаксис даних (правила опису даних. ОпД), зміст дій над даними (маніпулювання даними, МД) та обмеження на ці дані, ОД: МодД = áОпД. МД, ОбДñ. Тобто довільна модель даних повинна містити три компоненти:
структурна частина, тобто набір правил, за якими може бути побудована БД так, щоб її зміст відбивав точку зору користувача на представлення даних. Структурна частина описує, які об'єкти існують у моделі даних;
керуюча (маніпуляційна) частина, яка визначає набір допустимих операцій, виконуваних на структурі даних. Модель даних передбачає, як мінімум, наявність мови визначення даних (МВД, DDL – data definition language), що описує структуру їхнього збереження, і мови маніпулювання даними (ММД, DML – data manipulation language), що включає операції добування і модифікації даних.
обмеження цілісності даних - механізм підтримки відповідності даних предметної області на основі формально описаних правил.
Модель даних можна інтерпретувати як сукупність правил породження структур даних у БД, операції над ними, а також обмеження цілісності, що визначає допустимі зв'язки і значення даних, а також послідовність їхньої зміни. Модель даних описує деякий набір родових понять і ознак, які повинні мати всі конкретні СУБД і керовані ними бази даних, якщо вони ґрунтуються на цій моделі. Наявність моделі даних дозволяє порівнювати конкретні реалізації, використовуючи одну спільну мову.
У процесі історичного розвитку в технології БД використовувалися наступні моделі даних: ієрархічна, мережева, реляційна. Останнім часом розроблені та усе частіше застосовуються пост реляційна, об'єктно-орієнтована та багатомірна моделі представлення даних. Пропонуються також інші моделі, які є розширенням чи об’єднанням кількох відомих підходів, наприклад, об’єктно-реляційна, дедуктивна об'єктно-орієнтована, семантична та інші моделі.
Мета побудови моделі даних полягає в представленні даних у зрозумілому вигляді. Якщо таке представлення можливо, модель даних можна буде легко застосувати при проектуванні БД.
У ієрархічній моделі зв’язки між даними можна описати за допомогою впорядкованого графа чи дерева. Ієрархічна БД складається з упорядкованого набору дерев. У ієрархічній моделі всі одиниці даних впорядковуються за принципом ієрархії; при цьому до найвищого рівня ієрархії відносять лише один елемент, який не підпорядковується жодному іншому елементу. Зв’язки між даними можна описати за допомогою впорядкованого графа чи дерева. Зв’язки встановлюються виключно між елементами сусідніх рівнів з підпорядкуванням від вищого рівня до нижчого, при цьому елемент нижчого рівня пов'язаний лише з одним елементом вищого рівня (має одного «предка»), а елемент вищого рівня може бути не пов'язаний з жодним, або пов'язаний з одним чи більше елементів нижчого рівня (мати від 0 до N «нащадків, тип зв’язку 1:1 чи 1:N) (рис. 4.2).
Рис. 4.2. Ієрархічна модель даних
Основними інформаційними одиницями ієрархічної моделі є поле (атрибут), запис (сегмент) і групове відношення. Поле (атрибут, елемент даних) – найменша, переважно іменована одиниця структури даних. Запис - іменована сукупність атрибутів. Групове відношення - ієрархічне відношення між записами двох типів. Батьківський запис (власник групового відношення, «предок») називається вихідним записом, а дочірні записи (члени групового відношення, «нащадки») - підлеглими. Ієрархічна база даних може зберігати тільки такі деревоподібні структури. Групове відношення відбивається орієнтованим деревоподібним графом з записами у вершинах і дугами, що відповідають відношенням.
Таким чином, ієрархічна БД складається з упорядкованого набору дерев, точніше, з упорядкованого набору кількох екземплярів одного типу дерева, які містять екземпляри типу «запис» Тип дерева в цілому являє собою ієрархічно організований набір типів записів, а організація деревоподібної структури підкоряється наступним правилам:
· усі типи зв'язків повинні бути функціональними (1:1, 1:N, N:1);
· дерево являє собою неорієнтований граф, що не містить циклів.
· тип дерева складається з одного "кореневого" типу запису й упорядкованого набору з нуля чи більше типів піддерев (кожне з який є деяким типом дерева).
· у дереві кожен вузол i-рівня зв'язаний тільки з одним батьківським вузлом (i-1)-рівня (будь-який син може мати не більш одного рідного батька, а будь-який батько - безліч синів);
· дуга дерева відповідає типу зв'язку "вихідний-породжений";
· доступ до кожного породженого вузла виконується безпосередньо через вихідний вузол;
· всі екземпляри даного типу нащадка з загальним екземпляром типу предка називаються близнюками.
Приклад типу дерева (схеми ієрархічної БД) та одного екземпляра дерева наведені на рис. 4.3. нижче.
а)
б)
Рис. 4.3. Приклад типу дерева (а) та одного екземпляра дерева (б): тип запису «Відділ» є предком для типів запису «Начальник» і «Співробітники»
Для БД визначений повний порядок обходу - вниз, праворуч; існує єдиний лінійний ієрархічний шлях доступу до будь-якого вузла, починаючи з кореня дерева.
В ієрархічній моделі підтримуються наступні операції над даними:
· пошук зазначеного екземпляру дерева (наприклад, відділу 310);
· перехід від одного дерева до іншого;
· перехід від одного запису до іншого усередині дерева (наприклад, від відділу - до першого співробітника);
· перехід від одного запису до іншого в порядку обходу ієрархії;
· витягання кореневого і наступного записів в порядку лівостороннього обходу дерева з заданням умов вибірки (наприклад, витягти співробітників з окладом більш 1 тисячі грн.;
· вставка (додавання) нового запису у зазначену позицію;
· видалення поточного запису разом з усіма підлеглими йому записами;
· зміна значень попередньо витягнутого запису
Всі операції зміни застосовуються тільки до одного "поточного" запису (який попередньо витягнутий з бази даних). Такий підхід до маніпулювання даних одержав назву "навігаційного".
Мова маніпулювання даними в ієрархічній моделі у явному вигляді підтримує навігаційні операції, пов’язані з пересуванням вказівника, який визначає поточний екземпляр конкретного сегменту. Автоматично підтримується тільки цілісність зв'язків між власниками і членами групового відношення (ніякий нащадок не може існувати без предка). Не забезпечується автоматична підтримка відповідності парних записів, що входять у різні ієрархії.
Ієрархічні моделі даних історично були першими, використаними в технології БД, проте вони не позбавлені ряду недоліків:
1) орієнтація операцій маніпулювання на пошук інформації вниз, тобто за даним екземпляром сегмента-батька можна знайти всі екземпляри сегментів-синів. Зворотний пошук утруднений, а часто і неможливий;
2) дублювання даних на логічному рівні;
3) дублювання дерев для представлення зв'язків M:N (рис. 4.4);
4) специфіка підтримки обмежень цілісності.
У ієрархічних моделях автоматично підтримується цілісність посилань між предками і нащадками за правилом: ніякий нащадок не може існувати без свого батька. Цілісність за посиланнями між записами, що не входять в одну ієрархію, не підтримується. Тому неможливо збереження в БД породженого вузла без відповідного вихідного. Аналогічно, видалення вихідного вузла тягне видалення всіх породжених вузлів (дерев), зв'язаних з ним.
Рис. 4.4. Дублювання дерев для представлення зв'язку M:N у БД «Постачальники» (постачальник постачає різні типи деталей, які своєю чергою постачаються різними постачальниками)
Мережева модель даних була розроблена у розвиток ієрархічної для подолання частини її недоліків.Основні принципи мережевої моделі даних були разработны в середині 60-х років, еталонний варіант мережної моделі даних описаний у звітах робочої групи по мовах баз даних (Cоnference on Dаta System Languages) CODASYL (1971 р.). Мережева модель є розширенням ієрархічної за рахунок зняття обмежень на ієрархічну підпорядкованість даних та встановлення зв’язків між ними: всі елементи даних є рівноправними і допускають встановлення між собою зв’язків довільних типів, у тому числі M:N.
Мережева модель даних базується також на використанні представлення даних у вигляді графа, але цій моделі відповідає довільний граф, вершини якого використовуються для інтерпретації типів об'єктів, а дуги - для інтерпретації типів зв'язків між типами об'єктів. Якщо в ієрархічних структурах запис-нащадок повинен мати виключно одного предка, то у мережевій структурі даних нащадок може мати будь-яку кількість предків.
Мережева модель даних визначається в тих же термінах, що й ієрархічна. Вона складається з множини записів, що можуть бути власниками чи членами групових відношень. Мережева БД складається з набору записів і набору зв'язків між цими записами. Тип зв'язку визначається для двох типів записів: предка і нащадка. Зв'язок між записом-власником і записом-членом також має вид 1:N. Екземпляр типу зв'язку складається з одного екземпляра типу запису предка й упорядкованого набору екземплярів типу запису нащадка.
Основна різниця ієрархічної і мережевої моделей полягає в тому, що в мережевій моделі запис може бути членом більш ніж одного групового відношення. Відповідно до цієї моделі кожне групове відношення іменується і здійснюється розрізнення між його типом і екземпляром. Тип групового відношення задається його ім'ям і визначає властивості спільні для всіх екземплярів даного типу. Екземпляр групового відношення представляється записом-власником і множиною (можливо порожнім) підлеглих записів. При цьому є наступне обмеження: екземпляр запису не може бути членом двох екземплярів групових відношень одного типу.
В мережевій моделі підтримуються наступні основні операції над даними:
· пошук зазначеного запису;
· перехід від предка до першого нащадка;
· перехід від нащадка до предка;
· створення нового запису;
· видалення поточного запису;
· оновлення поточного запису;
· включення запису у зв'язок;
· вилучення запису зі зв'язку;
· включення запису в інший груповий зв’язок.
Як і в ієрархічній моделі забезпечується тільки підтримка цілісності за посиланнями (власник відношення - член відношення). Мережева модель забезпечує сумісне використання даних, вона здатна до адаптації і розширення, проте відзначається надмірністю зв’язків і як, наслідок, складністю керування даними при зростанні їх обсягу. Навігаційний метод доступу, як і у ієрархічних моделях, ускладнює доступ до даних та управління ними.
Наприкінці 60-х років минулого сторіччя з'явилися роботи, у яких обговорювалися можливості застосування різних табличних логічних моделей даних, тобто можливості використання звичних і природних способів представлення даних. Найбільш значною з них була стаття співробітника фірми IBM д-ра Е.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13:6, June 1970), де, імовірно, уперше був застосований термін "реляційна модель даних". Е.Кодд запропонував використовувати для обробки даних апарат теорії множин. Він показав, що будь-яке представлення даних зводиться до сукупності двовимірних таблиць особливого виду, відомого в математиці як відношення, що й дало підставу назвати модель реляційною (від relation (англ.) - відношення).
У реляційній моделі досягається набагато більш високий рівень абстракції даних, ніж в ієрархічній чи мережевій. У згаданій статті Е.Ф.Кодда стверджується, що "реляційна модель надає засоби опису даних на основі тільки їхньої природної структури, тобто без потреби введення якої-небудь додаткової структури для цілей машинного представлення". Іншими словами, представлення даних не залежить від способу їхньої фізичної організації. Це забезпечується за рахунок використання математичної теорії відношень.
Як будь-яка інша модель даних, реляційна складається з трьох частин – структурної, маніпуляційної і цілісної. Структурна частина постулює, що єдиною структурою даних, використовуваною в реляційній моделі, є нормалізовані n-арні відношення. Цілісна частина описує обмеження спеціального виду, що повинні виконуватися для будь-яких відносин у будь-яких реляційних базах даних. Це цілісність сутностей і цілісність зовнішніх ключів (посилань). Маніпуляційна частина описує два еквівалентних способи маніпулювання реляційними даними - реляційну алгебру і реляційне числення. Деколи у склад реляційної моделі даних ще включають теорію нормалізації відношень.
Основними поняттями реляційних баз даних є тип даних, домен, атрибут, кортеж, первинний ключ і відношення.
Поняття тип даних у реляційній моделі даних цілком адекватно поняттю типу даних у мовах програмування. Реляційна модель вимагає, щоб типи використовуваних даних були простими, тобто в реляційних операціях не повинна враховуватися внутрішня структура даних. Звичайно в сучасних реляційних БД допускається збереження символьних, числових даних, бітових рядків, спеціалізованих числових даних (таких як "гроші"), а також спеціальних "темпоральних" даних (дата, час, часовий інтервал). Досить активно розвивається підхід до розширення можливостей реляційних систем абстрактними типами даних (відповідні можливості мають, наприклад, системи сімейства Ingres/Postgres).
Найменша одиниця даних реляційної моделі – це окреме атомарне (нерозкладне) для даної моделі значення даних. Так, в одній предметній області прізвище, ім'я і по батькові можуть розглядатися як єдине значення, а в іншій – як три різних значення.
Домен можна розглядати як підмножину значень деякого типу даних, що мають певний зміст. Загалом домен визначається завданням деякого базового типу даних, до якого відносяться елементи домену, і довільного логічного виразу, який застосовується до елемента типу даних. Якщо обчислення цього логічного виразу дає результат "істина", то елемент даних є елементом домену.
Найбільш правильним інтуїтивним трактуванням поняття домену є розуміння домену як допустимої потенційної множини значень даного типу. Наприклад, домен "Імена" у сутності СПІВРОБІТНИКИ визначений на базовому типі рядків символів, але в число його значень можуть входити тільки ті рядки, що можуть відображати ім'я (зокрема, такі рядки не можуть починатися з м'якого знака).
Відношення- це підмножина декартового добутку множин. Декартовим (прямим) добутком множин A1,A2,…An називається множина упорядкованих наборів елементів (аi1,aj2,…amn) вигляду:
, (4.3)
у якій перший належить множині A1, другий – множині A2, п-ий – множині A2. Для цих упорядкованих сукупностей елементів використовуються назви: кортежі, послідовності, n-ки, набори.
Відношення мають степінь і потужність. Степінь відношення - це кількість елементів у кожнім кортежі відношення (аналог кількості стовпців у таблиці). Підмножина R декартового добутку множин A1*A2*…An називається відношенням степеня n (n-арним відношенням). Потужність відношення - це потужність множини кортежів відношення (аналог кількості рядків у таблиці).
Відношення складаються з однотипних кортежів. За винятком крайнього випадку, коли відношенням є сам декартовий добуток, відношення містить у собі не всі можливі кортежі з декартового добутку. Це означає, що для кожного відношення є критерій, що дозволяє визначити, які кортежі входять у відношення, а які - ні. Цей критерій, власне кажучи, визначає зміст (семантику) відношення.
Атрибути відношення - це пари вигляду <Ім'я_атрибута : Ім'я_домену>. Іменована множина пар «ім'я атрибута - ім'я домена» називається схемою відношення. Кортеж, що відповідає даній схемі відношення, - це множина пар {ім'я атрибута, значення}, що містить одне входження кожного імені атрибута, що належить схемі відношення. Атрибут, значення якого однозначно ідентифікує кортежі, називається ключовим (чи просто ключем). Відношення може містити кілька ключів. Завжди один із ключів є первинним,решта – потенційними. Домен можна розглядати як множину допустимих значень атрибуту.
Відношення має наступні властивості: у відношенні немає однакових кортежів; кортежі не упорядковані (зверху вниз); атрибути не упорядковані (ліворуч праворуч); усі значення атрибутів атомарні.
Відношення зручно представляти у вигляді таблиць (рис. 4.5). На рисунку представлена таблиця (відношення степеня 5), що містить відомості про працівників гіпотетичного підприємства. Рядки таблиці відповідають кортежам. Кожен рядок являє собою опис одного об'єкта реального світу (у даному випадку працівника), характеристики якого містяться в стовпцях.
| Integer | Text | Currency | Тип даних | |||
| Номер | ПІБ | Посада | Заробітна плата | Домени | ||
| Відношення | Табельний номер | ПІБ | Посада | Оклад | Премія | Атрибути |
| Стецюк О.І. | інженер | 1800 грн. | 300 грн. | Кортежі | ||
| Дмитерко І.І. | ст. інженер | 2300 грн. | 500 грн. | |||
| Блага Б.К. | прибиральниця | 1000 грн. | 100 грн. |
Рис. 4.5. Представлення відношення у вигляді таблиці
На відміну від ієрархічної і мережної моделей даних у реляційної відсутнє поняття групового відношення. Складні об'єкти реального світу представляються в реляційній базі даних у вигляді кортежів кількох нормалізованих відношень, зв'язаних між собою. При цьому зв'язки між даними відношеннями описуються в термінах функціональних залежностей. Для відображення функціональних залежностей між кортежами різних відношень використовується дублювання первинного ключа одного відношення (батьківського) в інше (дочірнє). Атрибути, що представляють собою копії ключів батьківських відношень, називаються зовнішніми ключами.
Наприклад, зв'язок між відношеннями ВІДДІЛ і СПІВРОБІТНИК створюється шляхом копіювання первинного ключа "Номер_відділу" з першого відношення в друге (рис. 4.6). Відповідно, для того, щоб одержати список працівників даного підрозділу, необхідно
з таблиці ВІДДІЛ встановити значення атрибута "Номер_відділу", що відповідає даному "Найменуванню_відділу"
вибрати з таблиці СПІВРОБІТНИК усі записи, значення атрибута "Номер_відділу" яких дорівнює отриманому на попередньому кроці.
Рис. 4.6. Фрагмент бази даних підприємства
Набір іменованих схем відношень представляє із себе схему бази даних. Реляційна база даних – це сукупність відношень, що містять всю інформацію, яка повинна зберігатися в БД. Однак користувачі можуть сприймати таку базу даних як сукупність таблиць. Ці таблиці мають певні властивості:
кожна таблиця складається з однотипних рядків і має унікальне ім'я;
рядки мають фіксоване число полів (стовпців) і значень (множинні поля і повторювані групи неприпустимі). Інакше кажучи, у кожній позиції таблиці на перетині рядка і стовпця завжди є одне значення чи немає жодного;
рядки таблиці обов'язково відрізняються один від одного хоча б одним значенням, що дозволяє однозначно ідентифікувати будь-який рядок такої таблиці;
стовпцям таблиці однозначно надаються імена, і в кожному з них розміщаються однорідні значення даних (дати, прізвища, цілі числа чи грошові суми);
повний інформаційний зміст бази даних представляється у вигляді явних значень даних і такий метод представлення є єдиним. Зокрема, не існує яких-небудь спеціальних "зв'язків" чи покажчиків, що з'єднують одну таблицю з іншою;
при виконанні операцій з таблицею її рядки і стовпці можна обробляти в будь-якому порядку безвідносно до їхнього інформаційного змісту. Цьому сприяє наявність імен таблиць і їхніх стовпців, а також можливість виділення будь-якого їхнього рядка чи будь-якого набору рядків із зазначеними ознаками.
Цілісність даних - це механізм підтримки відповідності бази даних предметній області. У реляційній моделі даних визначені дві базові вимоги забезпечення цілісності - цілісність сутностей і цілісність посилань. Вимога цілісності сутностей полягає в унікальності кортежів відношення: у відношенні не може бути двох кортежів з однаковими значеннями всіх атрибутів, що забезпечується наявністю і неповторюваністю значень первинного ключа. Цілком очевидно, що якщо дана вимога не дотримується (тобто кортежі в рамках одного відношення не унікальні), то в базі даних може зберігається суперечлива інформація про один й той самий об'єкт. Підтримка цілісності сутностей забезпечується засобами СУБД за допомогою двох обмежень:
· при додаванні записів у таблицю перевіряється унікальність їхніх первинних ключів;
· не дозволяється зміна значень атрибутів, що входять у первинний ключ.
Вимога цілісності за посиланнями, чи вимога зовнішнього ключа полягає в тому, що зовнішній ключ дочірнього відношення може приймати значення з множини значень первинного ключа у батьківському відношенні або бути невизначеним. Обмеження цілісності по сутностях і по посиланнях повинні підтримуватися СУБД.
Маніпуляційна складова реляційної моделі визначає два рівнозначні базові механізми маніпулювання реляційними даними. Це реляційна алгебра, яка ґрунтується на теорії множин, і реляційне числення, яке базується на математичній логіці (точніше, на численні предикатів першого порядку). Реляційна алгебра і числення є замкнутими відносно поняття відношення, тобто вирази реляційної алгебри і формули реляційного числення визначаються на відношеннях реляційної БД і повертають як результат обчислення також відношення. Обидва механізми мають велику виразну потужність: дуже складні запити до бази даних можуть бути виражені за допомогою одного виразу реляційної алгебри чи однієї формули реляційного числення. Конкретна мова маніпулювання реляційними БД називається реляційно повною, якщо будь-який запит, що виражається за допомогою одного виразу реляційної алгебри чи однієї формули реляційного числення, може бути виражений за допомогою одного оператора цієї мови.
Основна ідея реляційної алгебри полягає в тому, що якщо відношення є множинами, то засоби маніпулювання відношеннями можуть базуватися на традиційних теоретико-множинних операціях, доповнених деякими спеціальними операціями, специфічними для баз даних. До складу теоретико-множинних операцій входять операції: об'єднання, перетинання, узяття різниці та прямого добутку відношень. Спеціальні реляційні операції включають вибірку, проекцію, з'єднання та ділення відношень. Крім того, підтримуються операції перейменування, видалення, додавання та оновлення кортежів відношень.
Механізми реляційної алгебри і реляційного числення еквівалентні за потужністю, тобто для будь-якого припустимого виразу реляційної алгебри можна побудувати еквівалентну (тобто даючу такий же результат) формулу реляційного числення і навпаки. Водночас ці механізми різняться рівнем процедурності. Вирази реляційної алгебри будуються на основі алгебраїчних операцій і мають процедурну інтерпретацію. Іншими словами, запит, представлений мовою реляційної алгебри, може бути обчислений на основі елементарних алгебраїчних операцій з урахуванням їх старшинства і можливої наявності дужок. Для формули реляційного числення однозначна інтерпретація відсутня; формула лише встановлює умови, яким повинні задовольняти кортежі результуючого відношення. Тому мова реляційного числення є більш декларативною. Сучасні мови БД (як, наприклад, у мова SQL) ґрунтуються не суто на реляційній алгебрі чи реляційному численні, а на певній суміші алгебраїчних і логічних конструкцій.
Ієрархічна, мережева та реляційна моделі вважаються класичними моделями даних; більшість БД нині використовує реляційні моделі, тобто є реляційними. Проте, не зважаючи на великі переваги – представлення даних, ненавігаційний підхід до програмування тощо, реляційні бази мають недоліки при роботі зі складно структурованими даними. Реляційна модель не допускає природного представлення даних з ієрархічною структурою, оскільки в її рамках можливе моделювання лише за допомогою плоских відношень (таблиць). Всі відношення знаходяться на одному рівні, і відбити безпосередньо зв’язки між даними різних кортежів одного відношення неможливо. Реляційна модель обмежується виключно простими типами даних, у той час як ряд прикладних застосувань у галузі систем автоматизованого проектування, геоінформаційних систем та систем підтримки прийняття рішень вимагають використання структурованих типів даних. Для усунення цих недоліків запропоновано ряд інших моделей, найвідомішими з яких є постреляційна, об’єктно-орієнтована, об’єктно-реляційна та багатовимірна моделі.
Постреляційна модель даних є розширеною реляційною моделлю, в якій скасована вимога атомарності атрибутів. Вона дозволяє зберігати в полях таблиці інші таблиці (масиви даних), дає змогу враховувати фактор часу, що розширює можливості з опису складних об'єктів реального світу. Як мова запитів використовується дещо розширена SQL, здатна видобувати складні об'єкти з| однієї таблиці без операцій з'єднання.
Багатовимірна модель даних є розвитком постреляційної моделі в напрямку розширення кількості вимірів при представленні даних до трьох та білше, тобто представлення даних не плоскими таблицями, а кубами чи гіперкубами. Основними поняттями багатовимірної моделі даних є гіперкуб даних, вимір, атрибут, комірка, значення. Гіперкуб даних містить один або більше вимірів і є впорядкованим набором комірок. Під виміром розуміють множину атрибутів, що створюють одну з граней гіперкуба. Прикладом часового виміру є список днів, місяців, кварталів; прикладом географічного виміру - перелік територіальних об'єктів: населених пунктів, районів, реґіонів, країн тощо. Кожна комірка визначається одним і лише одним набором значень вимірів – атрибутів. Комірка може містити дані – значення або бути порожньою. Гіперкуб даних можна розглядати як множину відношень реляційної бази даних за значеннями кожного з вимірів. Отже, носієм багатовимірної моделі даних є відношення реляційної бази даних, зображені як зафіксовані виміри. Гіперкуб утворює багатовимірний простір даних, що складається з фіксованої кількості вимірів.
Для отримання доступу до даних користувачу необхідно вказати одну або декілька комірок шляхом вибору значень вимірів, яким відповідають необхідні комірки. Процес вибору значень вимірів називатимемо фіксацією атрибутів, а множину вибраних значень вимірів – множиною фіксованих атрибутів
Багатовимірна модель підтримує додаткові типи даних: дані, залежні від часу; структуровані дані; класифікаційні правила; залежності між агрегатами; залежності між елементами ієрархії. У маніпуляційній частині традиційні реляційні операції доповнені операціями зрізу, згортки, деталізації та обертання. Операція зрізу здійснюється з метою отримання необхідної підмножини комірок і відсікання «непотрібних» значень шляхом послідовної фіксації атрибутів. Зріз, як правило, є двовимірним масивом (таблицею). Обертання це операція зміни порядку подання (візуалізація) вимірів. яка забезпечує можливість візуалізації даних у формі, найбільш комфортній для їх сприйняття. Операції згортки і деталізації здійснюються завдяки наявності ієрархічної структури вимірів. Значення вимірів (атрибутів) можуть об'єднуватися в ієрархії, що складаються з одного або декількох рівнів. Багатовимірні моделі застосовуються для опрацювання даних у системах прийняття рішення, базах знань та сховищах даних, інтелектуальних системах тощо.
Об’єктно-орієнтована модель даних базується на об’єктному підході до логічних конструкцій. Термін «об'єкт» в програмуванні вперше був запроваджений в мові Simula (1967 р.) для позначення деякого аспекту модельованої реальності. Зараз об'єкт тлумачать як «щось, що має чітко визначені межі» (Г.Буч). Об'єкти, що мають однакові властивості, утворюють класи. Зазвичай клас описують як новий тип даних, а об'єкти (екземпляри класу) – як визначені на його основі змінні. Структура об'єктної моделі описуються за допомогою трьох ключових понять:
інкапсуляція – це процес відокремлення один від одного елементів об’єкта, які визначають його устрій та поведінку. Кожен об'єкт має певний внутрішній стан (зберігає усередині себе запис даних), а також набір методів - процедур, за допомогою яких (і лише таким чином) можна дістати доступ до даних, що визначають внутрішній стан об'єкту, або змінити їх. Таким чином, об'єкти можна розглядати як самостійні сутності, відокремлені від зовнішнього світу;
успадковування - можливість створювати на основі існуючих нові класи об'єктів, які успадковують структуру і методи своїх предків, додаючи до них риси, що відображають їх власну індивідуальність;
поліморфізм – можливість одним і тим самим способом взаємодіяти з об’єктами різних типів.
Підтримка цілісності в об'єктно-орієнтованому підході забезпечується: а) автоматичною підтримкою стосунків спадкоємства; б) можливістю оголосити деякі поля даних і методи об'єкту як «приховані», не видимі для інших об'єктів; такі поля і методи використовуються лише методами самого об'єкту; у) створенням процедур контролю цілісності усередині об'єкту
Загальні засоби маніпулювання даними, такі як реляційна алгебра або реляційне числення. у об'єктно-орієнтованій моделі відсутні. Робота з даними ведеться за допомогою однієї з об'єктно-орієнтованих мов програмування загального призначення, наприклад, SmallTalk, C++ або Java.
Об’єктно-реляційна модель даних базується на об’єднанні можливостей реляційного і об'єктно-орієнтованого підходу до представлення і управління даними за рахунок надання елементам реляційної структури можливостей об’єктно-орієнтованих структур - підтримка даних структурованих та абстрактних типів, які є наборами інших об’єктів; визначення операторів, функцій та методів доступу до даних користувачем; динамічне додавання нових типів даних; успадковування даних і функцій.
Системи управління БД
У загальному випадку система управління базою даних (СУБД) являє собою програму чи сукупність програм, які підтримують процеси створення, управління структурою, зміни стану, супроводження і використання бази даних, контроль доступу до даних, що зберігається в ній, та їх захист. СУБД дозволяє кільком додаткам чи користувачам здійснювати спільний доступ до даних. Є кілька вимог до збереження інформації у інформаційних системах, що не задовольняються системами управління файлами: підтримка логічно погодженого набору файлів; забезпечення мови маніпулювання даними; відновлення інформації після різного роду збоїв; паралельна робота кількох користувачів. Можна вважати, що якщо прикладна інформаційна система спирається на деяку систему управління даними, що має ці властивості, то ця система управління даними є системою управління базами даних (СУБД).
При описі функцій СУБД, тобто дій, які вона виконує з даними в інтересах і за замовленням користувача, можна говорити про опис функцій на логічному рівні (тобто як результат дії розуміє користувач і відчуває логічна організація даних) і на фізичному рівні (тобто як результат дій СУБД відчуває комп'ютер і фізична організація даних).
З погляду користувача (на логічному рівні),СУБД виконує наступні функції :
· визначення структури БД і її ініціалізація; керування словником даних (структура описується мовою БД і в результаті створюється порожня БД заданої структури);
· керування збереженням та оновленням даних; виконання операцій над БД; перетворення і представлення даних (ідентифікація даного і перебування його позиції в БД, вибірка даного з БД, введення чи запис даного в БД, видалення даного з БД, модифікація даного в БД);
· забезпечення незалежності даних (зміна логічного представлення даних без зміни фізичного представлення);
· захист логічної цілісності даних та підтримка БД у стані, адекватному стану предметної області (постійна перевіркою даних і зв'язків між ними на виконання обмежень цілісності);
· захист фізичної цілісності даних, управління резервним копіюванням і відновленням даних;
· управління доступом до БД, у тому числі багатокористувацьким,та управління безпекою;
· підтримка мов доступу до даних і інтерфейсів прикладного програмування;
· формуванні і підтримка інтерфейсів взаємодії з БД (користувач може одержить відповідь на запити, заповнюючи екранні форми за допомогою обраного браузера; автоматизувати публікацію форм і звітів в Інтернеті у відповідному форматі; підключитися до електронної пошти і поширити інформацію в мережі тощо)
Ці функції реалізуються через основні функції СУБД на фізичному рівні управління даними:
· управління даними в зовнішній пам'яті (на дисках);
· управління даними в оперативній пам'яті (управління буферами оперативної пам’яті);
· управління транзакціями;
· підтримка мов БД (мови визначення даних і мови маніпулювання даними);
· журналізація змін і відновлення бази даних після збоїв.
Управління даними в зовнішній пам'яті передбачає забезпечення необхідних структур зовнішньої пам'яті як для збереження даних, що безпосередньо входять у БД, так і для службових цілей, наприклад, для прискорення доступу до даних. Управління даними в оперативній пам'яті забезпечує прискорення обробки обсягів даних, більших за розмір оперативної пам’яті, за рахунок підтримання власного набору буферів оперативної пам'яті з власною дисципліною заміни буферів.
Управління транзакціями з боку СУБД забезпечує підтримку цілісності БД за умови багатокористувацького доступу. Транзакція - це послідовність операцій над БД, що розглядаються СУБД як єдине ціле. Або транзакція успішно виконується, і СУБД фіксує у зовнішній пам'яті зміни БД внаслідок всіх операцій транзакції загалом, або жодна зі змін ніяк не відбивається на стані БД. Кожна транзакція починається при цілісному стані БД і залишає цей стан цілісним після свого завершення. При відповідному управлінні СУБД паралельно виконуваними транзакціями має місце їх серіалізація і кожний з користувачів може відчувати себе єдиним користувачем СУБД. Під серіалізацією паралельно виконуваних транзакцій розуміють такий порядок планування їхньої роботи, при якому сумарний ефект суміші транзакцій еквівалентний ефекту їх деякого послідовного виконання. Серіальний план виконання суміші транзакцій - це такий план, що забезпечує серіалізацію транзакцій. Зрозуміло, що якщо вдається домогтися дійсно серіального виконання суміші транзакцій, то для кожного користувача, з ініціативи якого утворена транзакція, присутність інших транзакцій буде непомітною (якщо не вважати деякого уповільнення роботи порівняно з однокористувацьким режимом).
Однією з основних вимог до СУБД є надійність збереження даних у зовнішній пам'яті. Під цим розуміють те, що СУБД повинна забезпечувати відновлення останнього узгодженого стану БД після будь-якого апаратного чи програмного збою. Це вимагає надмірності збереження даних, причому та частина даних, що використовується для відновлення, повинна зберігатися особливо надійно. Найбільш розповсюдженим методом підтримки такої надмірної інформації є ведення журналу змін БД. Журнал - це особлива частина БД, недоступна користувачам СУБД, і підтримувана з особливою старанністю (іноді підтримуються дві копії журналу, розташовані на різних фізичних дисках), у яку надходять записи про всі зміни основної частини БД за методом «випереджаючого запису» (протоколом Write Ahead Log - WAL). За цим протоколом запис про зміну будь-якого об'єкта БД повинен потрапити в зовнішню пам'ять журналу раніш, ніж змінений об'єкт попаде у зовнішню пам'ять основної частини БД. Якщо СУБД коректно підтримує протокол WAL, то за допомогою журналу можна вирішити всі проблеми відновлення БД після будь-якого збою.
У сучасних СУБД звичайно підтримується єдина інтегрована мова, що містить усі необхідні засоби для роботи з БД і об’єднує засоби мови визначення даних та схеми БД (SDL - Schema Definition Language, DDL – Data Definition Language) і мови маніпулювання даними (DML - Data Manipulation Language), тобто дає змогу визначати схему БД і маніпулювати даними. Стандартною мовою найбільш розповсюджених у даний час реляційних СУБД є мова SQL (Structured Query Language). Вона дає змогу визначати дані і маніпулювати ними, задавати обмеження цілісності. При цьому іменування об'єктів БД (для реляційної БД - іменування таблиць і їхніх стовпців) підтримується на мовному рівні в тому сенсі, що компілятор мови SQL робить перетворення імен об'єктів у їхні внутрішні ідентифікатори на підставі спеціально підтримуваних службових таблиць-каталогів. Внутрішня частина СУБД (ядро) узагалі не працює з іменами таблиць і їхніх стовпців. Обмеження цілісності зберігаються в спеціальних таблицях-каталогах, і забезпечення контролю цілісності БД проводиться на мовному рівні, тобто при компіляції операторів модифікації БД компілятор SQL на підставі наявних у БД обмежень цілісності генерує відповідний програмний код.
Мову маніпулювання даними у складі мови СУБД можна розглядати як мову запитів, яка дає змогу оперативно реагувати на нерегламентовані запити[3].Збережені в БД дані загалом можна обробляти вручну, послідовно переглядаючи і редагуючи дані в таблицях за допомогою наявних у СУБД відповідних засобів. Для підвищення ефективності застосовують запити. Запит являє собою спеціальним образом описану вимогу, що визначає склад проведених над БД операцій по вибірці, видаленню чи модифікації збережених даних. Запити дають змогу робити множинну обробку даних, тобто одночасно вводити, редагувати і видаляти множину записів, а також вибирати дані з таблиць. Для підготовки запитів за допомогою різних СУБД найчастіше використовуються 2 основні мови опису запитів: мова QBE (Query by Example) – мова запитів за зразком; мова SQL (Structured Query Language) – стуктурована мова запитів. За можливостями маніпулювання даними при описі запитів ці мови практично еквівалентні. Головна відмінність між ними – у способі формування запитів: мова QBE передбачає ручне чи візуальне формування запиту, у той час як використання SQL означає програмування запиту.
Спеціальні оператори мови SQL дозволяють визначати так називані представлення БД, що фактично є збереженими в БД запитами з іменованими стовпцями. Результатом будь-якого запиту до реляційної БД є таблиця Для користувача представлення є такою ж таблицею, як будь-яка базова таблиця, збережена в БД, але за допомогою представлень можна обмежити чи, навпаки, розширити видимість БД для конкретного користувача. Підтримка представлень здійснюється також на мовному рівні.
За допомогою спеціального набору операторів SQL проводиться також авторизація доступу до об'єктів БД. Для виконання операторів SQL різного виду користувач повинен мати різні повноваження. Користувач, що створив таблицю БД, має повний набір повноважень для роботи з цією таблицею. У число цих повноважень входить повноваження на передачу усіх чи частини повноважень іншим користувачам, включаючи повноваження на передачу повноважень. Повноваження користувачів описуються в спеціальних таблицях-каталогах, контроль повноважень підтримується на мовному рівні.
Організація типової СУБД і склад її компонентів (архітектура СУБД) відповідає розглянутому нами набору функцій [56]. Зазвичай сучасна СУБД містить наступні компоненти (рис. 4.7):
· ядро (Data Base Engine), яке відповідає за управління даними в зовнішній і оперативній пам'яті, управління транзакціями і журналізацію,
· процесор (чи компілятор) мови бази даних, який забезпечує оптимізацію запитів на видобування і зміну даних і створення, як правило, машинно-незалежного внутрішнього коду, що виконується,
· підсистему підтримки часу виконання, що інтерпретує програми маніпуляції даними, які створюють користувацький інтерфейс із СУБД
· сервісні програми (зовнішні утиліти), що забезпечують ряд додаткових можливостей по обслуговуванню інформаційної системи.
Рис. 4.7. Типова архітектура СУБД
Ядро СУБД відповідає за управління даними в зовнішній пам'яті, управління буферами оперативної пам'яті, управління транзакціями і журналізацію. Відповідно, можна виділити такі компоненти ядра:
· менеджер даних,
· менеджер буферів,
· менеджер транзакцій
· менеджер журналу.
Функції цих компонентів взаємозалежні, і для забезпечення коректної роботи СУБД усі ці компоненти повинні взаємодіяти за ретельно продуманими і перевіреними протоколами. Ядро СУБД має власний інтерфейс, не доступний користувачам прямо і використовуваний у програмах, вироблених компілятором SQL (чи в підсистемі підтримки виконання таких програм) і утилітах БД. Ядро СУБД є основною резидентної частиною СУБД. При використанні архітектури "клієнт-сервер" ядро є основною складовий серверної частини системи.
Основною функцією компілятора мови БД є компіляція операторів мови БД у деяку виконувану програму. Основною проблемою реляційних СУБД є те, що мови цих систем (а це, як правило, SQL) є непроцедурними, тобто в операторі такої мови специфікується деяка дія над БД, але ця специфікація не є процедурою, а лише описує в деякій формі умови здійснення бажаної дії. Тому компілятор повинен вирішити, яким чином виконувати оператор мови перш, ніж зробити програму. Результатом компіляції є виконувана програма, що представляється в деяких системах у машинних кодах, але більш часто у виконуваному внутрішньому машинно-незалежному коді. В останньому випадку реальне виконання оператора здійснюється з залученням підсистеми підтримки часу виконання, що представляє собою, по суті справи, інтерпретатор цієї внутрішньої мови.
Взаємодія користувача з СУБД відбувається безпосередньо, через користувацький (термінальний) інтерфейс СУБД, або опосередковано, через прикладну програму (додаток). Такі додатки застосовують для розширення можливостей СУБД з обробки інформації та для автоматизації маніпулювання даними. Вони можуть бути незалежними, тобто виконуватися автономно від середовища СУБД, або виконуватися методом інтерпретації у середовищі СУБД. В останньому випадку СУБД аналізує зміст файлів додатку і автоматично будує машинні команди.
В процесі роботи користувача з БД виконуються наступні основні операції: вибір, додавання, вилучення та модифікування (заміна) даних БД. При проходженні запиту користувача на вибір даних у випадку роботи в діалоговому режимі з СУБД без додатків в першому наближенні має місце наступна послідовність дій (рис. 4.8):
користувач з терміналу надсилає СУБД запит на отримання даних з БД, попередньо сформований на мові запитів QBE чи SQL, чи безпосередньо формуючи цей запит;
СУБД аналізує права користувача і відповідну до нього зовнішню модель даних та за результатами цього аналізу підтверджує чи забороняє доступ даного користувача до даних за запитом;
у разі заборони на доступ до даних, СУБД через термінальний інтерфейс надсилає користувачу відповідне повідомлення і припиняє подальший процес обробки даних; у разі дозволу, СУБД, використовуючи свої системні і керуючі блоки, визначає частину концептуальної моделі, якої стосується запит користувача;
СУБД отримує зі словника (каталогу) даних інформацію стосовно визначеної частини концептуальної моделі;
СУБД формує і надсилає у словник (каталог) даних запит про місцезнаходження даних на фізичному рівні (файли чи фізичні адреси);
у СУБД повертається інформація про місцезнаходження даних у термінах операційної системи (ОС);
СУБД надсилає в ОС запит на представлення необхідних даних засобами ОС;
ОС за допомогою програм доступу файлової системи зчитує шукані дані з зовнішньої пам’яті, перекачує їх з пристроїв збереження і пересилає у системний буфер;
СУБД вибирає з наданої у системний буфер інформації те, що потрібно користувачу, перетворює дані до потрібного формату і надсилає їх у робочу область користувача, доступну для нього через термінальний інтерфейс. Інформація відображається на терміналі користувача.
Рис. 4.8. Схема проходження запиту при роботі х БД
У випадку взаємодії користувача за допомогою додатку, користувач формує запит на деякі дані у процесі діалогу з додатком, а не безпосередньо з СУБД. Додаток формує запит до СУБД на програмному рівні засобами мови маніпулювання даними. Подальше проходження запиту має той самий порядок, що і при безпосередньому зверненні користувача до БД через СУБД до етапу розміщення вибраної з БД інформації у системні буфери та перетворення її до необхідного формату. Далі СУБД пересилає дані у відповідну область програми-додатка і тим чи іншим способом подає сигнал про завершення операції. Результати вибору даних відбиваються на терміналі користувача.
У разі підтримки ОС багатокористувацького режиму у обчислювальній системі може функціонувати багатокористувацька СУБД, яка дає змогу одночасно обслуговувати кількох користувачів таким чином, щоб забезпечити незалежне виконання запитів від різних користувачів.
СУБД відіграє роль посередника між користувачем і БД, транслюючи запити користувача в складний код, необхідний для виконання таких запитів. СУБД приховує від прикладних програм, що використовують БД, її складну внутрішню структуру. Прикладні програми можуть бути написані програмістом на якій-небудь мові програмування чи створені за допомогою сервісних програм СУБД.
СУБД являє собою окремий комерційний програмний продукт, у який розробник БД і тим більше її користувачі не можуть вносити змін. Тому, коли мова йде про проектування БД, мається на увазі проектування структури БД, яка буде використана для збереження й управління даними, а не розробку програмного забезпечення СУБД. Після завершення проектування БД СУБД бере на себе управління всіма складними процедурами, необхідними для переведення представлення структури проектанта у форму, зручну для комп'ютера. Програмне забезпечення сучасних СУБД дозволяє централізовано зберігати не лише структури даних, але і взаємозв'язки таких структур, а також маршрути доступу до них. СУБД також беруть на себе клопоти по визначенню, збереженню й управлінню маршрутами доступу до цих компонентів, а також по підтримці цілісності даних..
СУБД класифікують за різними ознаками. Найчастіше використовують класифікацію СУБД за:
кількістю користувачів - на однокористувацькі (персональні) і багатокористувацькі СУБД. Перші в даний момент часу можуть обслуговувати тільки одного клієнта, другі – кілька. Якщо однокористувацька СУБД реалізована на персональному комп'ютері, її називають настільною.
· ступенем зосередженості розташування БД, яку обслуговує СУБД - на централізовані, або локальні (всі частини БД розташовані в одному місці, наприклад, на одному сайті) та розподілені (БД і відповідні частини СУБД розміщені на кількох різних сайтах чи комп’ютерах);
· заочікуваним відгуком, способом і сферою використання - на транзакційні, чи операційні (керують БД, спроектованими для транзакцій негайного відгуку), та. СУБД для data warehouse, сховищ чи банків даних (керують БД, спроектованими для систем підтримки прийняття рішень) (DSS) – СУБД;
· за підтримуваною моделлю даних – на ієрархічні, мережеві, реляційні, просторові (багатомірні) тощо;
· за способом доступу до БД – на файл-серверні, клієнт-серверні та вбудовувані.
У файл-серверных СУБД файли даних розташовуються централізовано на файл-сервері, СУБД - на кожному клієнтському комп'ютері (робочій станції). Доступ СУБД до даних здійснюється через локальну мережу. Синхронізація читань і оновлень здійснюється за допомогою файлових блокувань. Перевагою такої архітектури є низьке навантаження на центральний процесор сервера, недоліками - потенційно високе завантаження локальної мережі, ускладненість доступу, утрудненість забезпечення надійності і безпеки даних. Прикладами таких СУБД є Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.
Клієнт-серверна СУБД розташовується на сервері разом з БД і здійснює доступ до БД безпосередньо, в монопольному режимі. Всі клієнтські запити на обробку даних обробляються у клієнт-серверній СУБД централізованого. Недолік клієнт-серверних СУБД полягає в підвищених вимогах до сервера, перевага - в потенційно нижчому завантаженні локальної мережі, зручності централізованого управління, високій надійності і безпеці збереження даних. Прикладами таких СУБД є Oracle, Interbase, IBM DB2, MS SQL Server, Sybase, PostgreSQL, MySQL.
Вбудовувана СУБД є бібліотекою, що дозволяє уніфікованим чином зберігати великі обсяги даних на локальній машині. Доступ до даних може здійснюватися за допомогою SQL| або особливих функцій СУБД. Вбудовувані СУБД швидше звичайних клієнт-серверних і не вимагають установки сервера, тому знаходять застосування в програмному забезпеченні локальних інформаційних систем, які працюють з великими обсягами даних (наприклад, геоінформаційних системах). Приклади таких СУБД таких СУБД є OpenEdge, SQLite, BERKELEYDB, MYSQL.
Загалом СУБД допомагає створити робоче середовище, у якій кінцевим користувачам забезпечується більш зручний і швидкий доступ до добре керованих даних, що дозволяє швидше реагувати на зміни та проводити аналіз даних. У коректно спроектованих БД, керованих СУБД, виключається або значно зменшується імовірність суперечливості даних, що підвищує достовірність висновків за результатами їх аналізу.
Проектування баз даних
Висока продуктивність СУБД дозволяє ефективно експлуатувати дані у тому випадку, якщо структури даних коректні з точки зору даної СУБД та вимог користувача. Тому проектування БД є основним етапом створення БД.
Для успішної реалізації проекту бази даних об'єкт проектування повинен бути насамперед адекватно описаний, а також побудовані повні і несуперечливі функціональні та інформаційні моделі бази даних. Модель бази даних – це сукупність логічних конструкцій, що застосовується для представлення структури даних та відношень між ними всередині БД. Проектування БД починається з аналізу і визначення границь предметної області, об'єкти і процеси якої підлягають відображенню в ІС відповідно до вимог замовника. У теорії проектування інформаційних систем предметну область прийнято розглядати у виді трьох представлень, тобто на трьох рівнях абстракції, що одержали назву схем представлень ANSI/SPARC (рис. 4.9):
Рис. 4.9. Трирівнева система представлення баз даних ANSI/SPARC
зовнішній рівень - представлення предметної області в тому вигляді, як вона реально існує і використовується безпосередніми учасниками процесів у ній (користувачами). На цьому рівні створюються зовнішні моделі БД, які містять опис даних предметної області та зв'язків між ними в термінах кожного існуючого в організації типу користувачів;
концептуальний рівень - представлення предметної області в тому вигляді, як її сприймають проектувальник та адміністратор бази даних. На цьому рівні формується концептуальна модель БД, яка відбиває узагальнене представлення про дані, способи утворення одиниць даних, встановлення зв’язків між ними та порядок їх застосування з погляду і в термінах розробника БД. Концептуальна модель створюється у кілька етапів. Спочатку розробляється інфологічна модель, яка відбиває семантику предметної області у моделі БД в термінології об’єктів та зв'язків незалежно від типу обраної моделі даних і СУБД взагалі. Далі формується логічна модель, котра відбиває логічне представлення про дані у вигляді, адекватному моделі організації даних у СУБД визначеного типу, але без урахування специфіки конкретної СУБД. І, нарешті, формується даталогічна модель БД, яка дає опис складу і структури даних у термінах конкретної СУБД;
внутрішній рівень - представлення предметної області в тому вигляді, як вона може бути описана за допомогою символів. На цьому етапі будуються внутрішня модель БД, яка відбиває концептуальну схему у термінах обраної технології реалізації БД, і фізична модель БД, яка містить опис реалізації БД на вторинних запам'ятовуючих пристроях із указівкою структур збереження і методів доступу, які використовуються для організації ефективної обробки даних.
Користувачі сприймають дані на зовнішньому рівні, СУБД і ОС - на внутрішньому. Концептуальний рівень представлення даних призначений для відображення моделей БД зовнішнього рівня на моделі внутрішнього і забезпечення їхньої незалежності одна від одної. Задачі й етапи проектування БД випливають із трирівневої схеми ANSI/SPARC (рис. 4.10).
На етапі інфологічного проектування баз даних вирішують проблему адекватного відображення предметної області та інформаційних потреб користувачів у концептуальній моделі шляхом побудови інфологічних (змістовних концептуальних) моделей; на етапі логічного проектування - проблему знаходження способу адекватного відображення об'єктів предметної області в абстрактні об'єкти моделі даних так, щоб це відображення не суперечило семантиці предметної області, і було найкращим з погляду управління БД. Мета логічного етапу проектування - організація даних, виділених на попередньому етапі, у форму, прийняту в обраній СУБД чи СУБД обраного класу, тобто побудова логічної та/або даталогічної моделі. Проблема забезпечення ефективності виконання запитів до БД, тобто знаходження оптимального розташування даних у зовнішній пам'яті та методів доступу до них розв’язується на етапі фізичного проектування баз даних.
СУБД відповідає за установлення відповідності між моделями БД всіх рівнів, а також за перевірку їхньої несуперечності. Іншими словами, СУБД повинна переконатися в тому, що кожну зовнішню схему можна вивести з концептуальної, а внутрішня схема відбиває концептуальну (а через неї і зовнішні) схему адекватно.
Проектування БД зводиться до послідовного створення набору моделей на різних рівнях абстракції., що адекватно відображають представлення користувачів про предметну область у внутрішню і потім – фізичну (для нереляційних БД) схеми даних.
Інфологічна модель відбиває семантику даних, тобто основні логічні об'єкти (сутності) моделі даних, та зв'язки між ними, необхідні та достатні для ефективного застосування інформації з точки зору користувача, і не залежить від того, яка модель даних буде застосована для їх представлення. На інфологічному рівні застосовують так звані об'єктні(object based) моделі на основі таких понять, як сутність, атрибут та зв'язок. Найпоширенішими типами об'єктних моделей є: модель "сутність-зв'язок" (entity-relationship model, ER - model); семантична модель; функціональна модель (стандарт IDEFO); об'єктно-орієнтована модель.
Рис. 4.10. Основні етапи проектування БД
Як основний інструмент для побудови семантичних моделей даних та уніфікованого представлення даних, незалежного від реалізуючого його програмного забезпечення, на етапі інфологічного проектування найчастіше застосовується неформальна модель "сутність-зв'язок" (entity-relationship model, ER - model). Модель "сутність-зв'язок" ґрунтується на опорній семантичній інформації про реальний світ і призначена для логічного представлення даних у контексті їхнього взаємозв'язку з іншими даними. З моделі "сутність-зв'язок" можуть бути породжені всі існуючі моделі даних (ієрархічна, мережева, реляційна, об'єктна), тому вона є найбільш загальною. Зокрема, об'єктно-орієнтована модель розширює визначення сутності з метою включення у нього не лише атрибутів, що описують стан об'єкту, але й дій, які з ним пов'язані, тобто описують його поведінку. У цьому випадку говорять про те, що об'єкт інкапсулює стан і поведінку.
Логічна модель виводиться з інфологічної з урахуванням обраної моделі організації даних (типу цільової СУБД), але незалежно від особливостей конкретної СУБД і інших фізичних аспектів реалізації. Логічні моделі є моделями реалізації БД на рівні записів. Модель реалізації, на відміну від концептуальної, націлена на відбиття способу представлення (синтаксису) даних у БД, тобто на те, як саме мають бути реалізовані структури даних, щоб адекватно відбити семантику інфологічної моделі з урахуванням особливостей певної моделі даних та специфіки СУБД.
Моделі реалізації поділяють на фізичні і моделі на основі записів, які і формуються на етапі логічного / даталогічного проектування. У моделях на основі записів БД складається з записів фіксованого формату, що можуть мати різні типи. Кожен тип запису визначає фіксовану кількість полів, кожне з який має фіксовану довжину. Відповідно до основних моделей данних існує три основних типи моделей на рівні записів: реляційна (relational); мережева (network);ієрархічна (hierarchical). Розвинутим моделям даних (обєктно-орієнтованій, постреляційній, багатовимірній) відповідають свої моделі на рівні записів.
Реляційна модель заснована на понятті математичних відношень. У ній дані і зв'язки представлені у вигляді таблиць, кожна з який має набір стовпців з унікальними іменами. З погляду користувача БД виглядає як набір таблиць; фізична ж структура БД може бути реалізована за допомогою різноманітних структур збереження. У мережевій моделі дані представлені у вигляді колекції записів, а зв'язки – у вигляді наборів. Зв'язки в явному вигляді моделюються наборами, що реалізуються за допомогою вказівників. Мережеву модель можна представити як граф із записами у вигляді вузлів графа і наборами зв'язків у вигляді його ребер. Ієрархічна модель є обмеженим підтипом мережевої моделі. У ній дані також представлені, як колекція записів, а зв'язки – як набори, однак в ієрархічній моделі вузол може мати тільки одного батька.
Якщо концептуальна модель даних не залежить від будь-яких фізичних аспектів реалізації, то логічна модель даних створюється на основі обраної моделі організації даних у цільовій СУБД. На цьому етапі вже повинне бути відомо, яка СУБД буде використовуватися в якості цільової – реляційна, мережева, ієрархічна чи об'єктно-орієнтована. Для реляційних моделей на цьому етапі фіксується набір і структура таблиць, що представляють сутності, визначаються ключі і проводиться нормалізація таблиць, однак ігноруються всі інші аспекти обраної СУБД, наприклад, будь-які аспекти фізичної організації її структур збереження даних і побудови індексів.
Більшість систем базуються сьогодні на реляційній парадигмі, ранні системи БД будувалися на мережевій чи ієрархічній. При використанні останніх від користувача потрібно знання фізичної організації БД, до якої він повинен здійснити доступ, у той час як у реляційній БД незалежність від даних значно більша. Якщо у реляційних системах для обробки інформації в БД прийнятий декларативний підхід (тобто вони вказують, які дані слід видобути), то в мережевих і ієрархічних системах – навігаційний підхід (тобто вони вказують, як їх слід витягати).
Фізична модель діє на найнижчому рівні абстракції, описуючи способи зберігання інформації на носіях, наприклад, жорстких дисках. Фізична модель вимагає визначення як пристрою фізичного зберігання, так і методу фізичного доступу, необхідного для отримання даних з фізичного носія. Очевидно, що фізична модель є як програмно, так і апаратно залежною. Використовувані структури зберігання залежать від програмного забезпечення (СУБД, операційна система) та від типу носія, що підтримується комп'ютером. Вибір певного методу доступу до даних дає змогу оптимізувати роботу з БД кожного типу, проте реляційна модель в основному орієнтована на логічний рівень представлення і переважно не вимагає такого детального фізичного моделювання, як БД ієрархічного та мережевого типів.
Проблема логічного проектування реляційної бази даних полягає в обґрунтованому прийнятті рішень про те, з яких відношень повинна складатися база даних і які атрибути повинні бути в цих відношень, щоб відбиття об'єктів не суперечило предметній області, відповідало всім вимогам реляційної моделі і критеріям якості БД та забезпечувало можливості ефективної реалізації запитів для БД певного типу при дотриманні обмежень цілісності. Ефективна логічна модель повинна забезпечувати формування такої фізичної моделі БД, яка б відповідала основним критеріям якості БД: адекватність предметній області; легкість розробки і супроводження; швидкість виконання операцій оновлення (вставка, модифікація, видалення кортежів) та вибірки даних. Здатність БД задовольняти цим критеріям залежить від ступеня надмірності інформації у ній, яка проявляється у збереженні тої самої інформації (даних про ті самі властивості тих самих об’єктів) у кількох різних таблицях, що може породжувати аномалії і суперечливості даних. Ймовірність таких аномалій, тобто ймовірність неадекватності предметної області, без розробки спеціальних програмних кодів зростає зі збільшенням ступеня надмірності. Для його зменшення у проектуванні реляційних БД застосовують апарат нормалізації відношень.
Нормалізація відношень - це покроковий оборотний процес композиції чи декомпозиції вихідних відношень у відношення, що мають кращі властивості при включенні, зміні і видаленні даних. У теорії реляційних БД звичайно виділяють 5 нормальних форм (