Рівні моделі даних.
Реляційна модель даних
За минулі десятиліття реляційна модель розвивалася в двох напрямах. Перший напрям заклав знаменитий експериментальний проект компанії IBM System R. У цьому проекті виникла мова SQL, спочатку заснований на ідеях Кодда, але що порушує деякі принципові розпорядження реляційній моделі.
Другий напрям, починаючи з 1990-х рр., очолює Крістофер Дейт, до якого пізніше прилучився Хью Дарвен. Проте в 1990-і рр. Дейт і Дарвен прийшли до висновку, що спотворення реляційної моделі даних, властиві мові SQL, досягли настільки високого рівня, що прийшло час запропонувати альтернативу, що спирається на неспотворені ідеї Едгара Кодда і забезпечує всі можливості як SQL, так і об'єктно-орієнтованого підходу до організації баз даних і СУБД.
Назва “реляційна” (у перекладі з англійського relation - відношення) пов'язана з тим, що кожен запис в таблиці містить інформацію, що відноситься тільки до одного конкретного об'єкту.
Детальніше реляційну модель даних розглянемо пізніше.
Проектування бази даних треба починати з аналізу наочної області і виявлення вимог до неї окремих користувачів. Проектування зазвичай доручається людині (групі осіб) - адміністраторові бази даних (АБД). Їм може бути як спеціально виділений співробітник організації, так і майбутній користувач бази даних, досить добре знайомий з машинною обробкою даних.
Виділяють три рівні моделі даних:
¾ інфологічна;
¾ даталогична;
¾ фізична.
Рис.5.1.5 Рівні моделей даних
Інфологічна модельописує предметну область на змістовному рівні. На першому етапі при її розробці здійснюється аналіз предметної області, вирішуваних завдань, запитів користувачів і документів, що відображають події і процеси, що протікають в ПО. Результатом цього аналізу є списки об'єктів предметної області, переліки їх властивостей або атрибутів, визначення зв'язків між об'єктами і опис структури ПО у вигляді діаграми. Для кожного з атрибутів указуються обмеження на їх можливі значення, визначувані властивостями ПО.
Такі обмеження називаються обмеженнями цілісності даних.
Інфологичеськая модель об'єднує в єдине узагальнене уявлення вимоги окремих користувачів і служить засобом спілкування між ними, тому розробляється без урахування особливостей представлення даних в пам'яті ЕОМ.
Концептуальна або даталогичеськая модель описує об'єкти і зв'язки ПО на формальному рівні. Її розробка ведеться на другому етапі і грунтується на інфологичеськой моделі, отриманій на першому етапі. В процесі розробки здійснюється вибір типу моделі даних, і визначаються її елементи. Кожна СУБД підтримує тільки одну з моделей. Вибір моделі даних і вибір СУБД тісно взаємозв'язані.
Внутрішня, або фізична, модель даних визначає спосіб розміщення даних безпосередньо на машинному носієві, враховує розподіл даних, методи доступу і способи індексування. У сучасних прикладних програмних засобах цей рівень організації забезпечується автоматично без втручання користувача. Користувач, як правило, оперує в прикладних програмах і універсальних програмних засобах представленнями СУБД на організацію даних.
Таким чином основне завдання проектування полягає в створенні інфологичеськой моделі ПО і концептуальною БД.
Контрольні питання:
1. Що таке БД?
2. Що таке СУБД?
3. Які ви знаєте функції СУБД?
4. Які існують типи СУБД? У чому їх відмінності?
5. Дати визначення інфологичеськой моделі БД.
6. Дати визначення концептуальної моделі БД.
5.2. Інфологичеська модель даних "суть-зв'язок"
Основні поняття інфологичеського моделювання. Суть. Атрибут. Ключ. Зв'язок. Основні класи суті. ER-диаграммы і мова інфологичеського моделювання. Чотири види зв'язків.