Рівні моделі даних

Реляційна модель даних

За минулі десятиліття реляційна модель розвивалася в двох напрямах. Перший напрям заклав знаменитий експериментальний проект компанії IBM System R. У цьому проекті виникла мова SQL, спочатку заснований на ідеях Кодда, але що порушує деякі принципові розпорядження реляційній моделі.

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

Назва “реляційна” (у перекладі з англійського relation - відношення) пов'язана з тим, що кожен запис в таблиці містить інформацію, що відноситься тільки до одного конкретного об'єкту.

Детальніше реляційну модель даних розглянемо пізніше.

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

Виділяють три рівні моделі даних:

¾ інфологічна;

¾ даталогична;

¾ фізична.

Рис.5.1.5 Рівні моделей даних

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

Такі обмеження називаються обмеженнями цілісності даних.

Інфологичеськая модель об'єднує в єдине узагальнене уявлення вимоги окремих користувачів і служить засобом спілкування між ними, тому розробляється без урахування особливостей представлення даних в пам'яті ЕОМ.

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

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

Таким чином основне завдання проектування полягає в створенні інфологичеськой моделі ПО і концептуальною БД.

Контрольні питання:

1. Що таке БД?

2. Що таке СУБД?

3. Які ви знаєте функції СУБД?

4. Які існують типи СУБД? У чому їх відмінності?

5. Дати визначення інфологичеськой моделі БД.

6. Дати визначення концептуальної моделі БД.

5.2. Інфологичеська модель даних "суть-зв'язок"

Основні поняття інфологичеського моделювання. Суть. Атрибут. Ключ. Зв'язок. Основні класи суті. ER-диаграммы і мова інфологичеського моделювання. Чотири види зв'язків.

Дата добавления: 2013-12-12