логіки першого рівня недостатньо).
Важливим, хоча й недостатньо обгрунтованим припущенням Беєр є те, що двох традиційних рівнів - схеми і даних - для ООБД недостатньо.
Для точного визначення ООБД потрібен рівень мета-схеми, вміст якого має визначати види об'єктів і зв'язків, допустимих на схемном рівні БД. Мета-схема повинна грати для ООБД таку ж роль, яку відіграє структурна частина реляційної моделі даних для схем реляційних баз даних.
Підтримується зумовлений клас Оbject raquo ;, є коренем решітки класів; будь-який інший клас є неявним спадкоємцем класу Object і успадковує зумовлені методи ( is_same raquo ;, is_value_equal і т.д.) [8].
Реляційна модель
У реляційної моделі досягається набагато вищий рівень абстракції даних, ніж в ієрархічній або мережевий. Реляційна модель надає засоби опису даних на основі тільки їх природної структури, тобто без потреби введення будь-якої додаткової структури для цілей машинного представлення. Іншими словами, подання даних не залежить від способу їх фізичної організації. Це забезпечується за рахунок використання математичної теорії відносин (сама назва реляційна походить від англійського relation ставлення ).
Структура інформації дає підставу припускати, що найбільш придатною для датологіческой проектування буде реляційна модель даних, тому вона здатна забезпечить цілісність даних при вставці, видаленні та зміні записів, а так само дає можливість організації всіх видів зв'язків 1: 1, 1: М і М: М (при цьому зв'язку М: М розкриваються) [7].
. 3 Логічне проектування
У реляційних базах даних (РБД) датологіческой проектування призводить до розробки схеми БД, тобто сукупності схем відносин, адекватно моделюючих об'єкти ПО і семантичних зв'язків між ними.
Основою аналізу коректності схеми є функціональні залежності між атрибутами БД. Деякі можуть бути небажаними.
В кінці цього етапу повинно бути отримано опис схеми БД в термінах обраної СУБД. Метою датологіческой проектування є побудова коректної схеми БД, орієнтовану на реляційну модель. Коректної називається схема БД, в якій відсутні небажані залежності між атрибутами відносин.
Процес розробки коректної схеми РБД і є датологіческой проектуванням. Можливі 2-а способу:
· Декомпозиція (розбиття);
· Синтез;
Для переходу від інфологічної моделі до реляційної існує спеціальний алгоритм:
. кожної сутності ставиться у відповідність ставлення;
2. кожному атрибуту сутності ставиться у відповідність відповідний атрибут відповідного ставлення;
. первинний ключ сутності стає PK відповідного ставлення, при цьому атрибути, що входять в PK, обов'язкові для заповнення (NOT NULL);
. в кожне відношення, відповідне підпорядкованої сутності, додається набір атрибутів основний суті, є в ній первинним ключем. Відносно, відповідне підпорядкованої сутності ці атрибути стають FK (зовнішнім ключем);
. за замовчуванням, всі атрибути, що не входять в PK, необов'язкові;
. для відбиття категоризації сутностей можливі кілька варіантів;
. всі зв'язки М: М повинні бути розкриті;
Скористаємося даними алгоритмом і опишемо кожну сутність інфологічної моделі:
· Водій
? номер прав водія; int NOT NULL PK
? ПІБ; varchar (80) NOT NUL
? рік народження; date NOT NULL
? адреса; varchar (100) NOT NULL
? телефон; int NOT NULL
? дані про медогляд; varchar (50) NOT NULL
? оклад; int NOT NULL
· Автобус
? номер автобуса; int NOT NULL PK
? держ. номер; varchar (10) NOT NULL
? марка; varchar (20) NOT NULL
? пробіг; int NOT NULL
? дата техогляду; date NOT NULL
· Маршрут
? номер маршруту; int NOT NULL PK
? кілометраж; int NOT NULL
? число зупинок; int NOT NULL
· Контролер
? таб. номер контролера; int NOT NULL PK
? ПІБ контролера; varchar (80) NOT NUL
? рік народження; date NOT NULL
? адреса; varchar (100) NOT NULL
? телефон; int NOT NUL...
