Логічне проектування баз даних

План

1. Спрощення концептуальної моделі

Вилучення двосторонніх зв 'язків

"багато до багатьох"

Вилучення складних зв'язків

Вилучення багатозначних атрибутів

Вилучення рекурсивних зв'язків

Вилучення зв'язків з атрибутами

2. Методика перетворення ER-діаграм в реляційні структури

Сутності і атрибути

Зв'язки

Зв'язки "один до одного"

Зв'язки "один до багатьох"

Зв'язки "багато до багатьох"

Інші види зв'язків

Зв'язки "суперклас - підклас"

Етапи логічного проектування

Логічне проектування виконується для певної моделі даних. Для реляційної моделі даних логічне проектування полягає у створенні реляційної схеми, визначенні числа і структури таблиць, формуванні запитів до БД, визначенні типів звітних документів, розробці алгоритмів обробки інформації, створенні форм для вводу і редагування даних в БД і рішенні цілого ряду інших задач. Концептуальні моделі за певними правилами перетворюються в логічні моделі даних. Коректність логічних моделей перевіряється за допомогою правил нормалізації, які дозволяють переконатися в структурній узгодженості, логічній цілісності і мінімальній збитковості прийнятої моделі даних. Модель також перевіряється з метою виявлення можливостей виконання транзакцій, які будуть задаватися користувачами. Проектування являє собою циклічний процес. Етапи логічного проектування наведені на рис. 6.1.

Спрощення концептуальної моделі

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

На цьому етапі виконуються такі операції:

- вилучення двосторонніх зв'язків M:N;

- вилучення складних зв'язків;

- вилучення багатозначних атрибутів;

- вилучення рекурсивних зв'язків;

- вилучення зв'язків з атрибутами.

Вилучення двосторонніх зв 'язків "багато до багатьох"

Перетворення зв'язку "багато до багатьох" виконується шляхом введення проміжної сутності із заміною одного зв'язку M:N двома зв'язками 1:N з новою сутністю.

Вилучення складних зв 'язків

Для вилучення складних зв'язків виконуються такі операції:

- у модель вводиться нова сутність;

- складний зв'язок замінюється бінарними зв'язками "один до багатьох" зі знов створеною сутністю;

- кількість бінарних зв'язків дорівнює ступеню складності зв'язку.

Вилучення багатозначних атрибутів

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

Вилучення рекурсивних зв 'язків

На етапі спрощення концептуальної моделі рекурсивні зв'язки 1:1 і 1:M (рис. 6.5) можуть бути перетворені у одне відношення. У випадку, коли є необов'язкова сутність з боку "багато" для зв'язку 1:M для зменшення пустих значень

створюється нове відношення. Зв'язок M:N перетворюється на дві сутності (рис.6.6).

Вилучення зв 'язків з атрибутами

Вилучення зв'язків з атрибутами виконується шляхом додавання у модель нової сутності для відношення M:N з атрибутами зв'язку. Для відношення 1:M атрибути зв'язку передаються у сутність "багато" без створення нової сутності.

Приклад. Розглянемо сутності Студент-Дисципліна (рис.6.7).

У результаті перетворення зв'язку з атрибутами отримано реляційну схему (рис. 6.8).

Спрощення концептуальної моделі передбачає також вилучення збиткових зв'язків. Збиткові зв'язки

характеризуються тим, що одна і та ж інформація може бути отримана не тільки через них, але і через інші зв'язки.

Після спрощення в концептуальній моделі можуть бути присутні тільки такі елементи:

- об'єкти і атрибути;

- зв'язки типу 1:1 і 1:M;

- зв'язки типу суперклас-підклас.

Методика перетворення ER-діаграм в реляційні структури

Для ER-моделі існує алгоритм однозначного перетворення її в реляційну модель даних.

Розглянемо правила перетворення ER-моделі в реляційну модель.

Сутності і атрибути

Для кожної сутності створюється відношення, кожен атрибут сутності стає атрибутом відповідного відношення.

Для сильних сутностей первинний ключ сутності стає PRIMARY KEY (PK) відповідного відношення.

Приклад. Розглянемо сутність Студент (рис.6.9).

Для слабких сутностей первинний ключ частково або повністю залежить від ключа сутності володаря (декількох володарів), тобто PK визначається тільки тоді, коли визначені всі PK сутностей володарів.

Приклад. Розглянемо перетворення сильної сутності Студент і слабкої сутності Нагорода (рис. 6.10).

Зв 'язки

Після перетворення концептуальної моделі залишаються такі типи зв'язків:

- "один до одного";

- "один до багатьох";

- рекурсивні зв'язки;

- суперклас - підклас.

Для кожного типу зв'язку залежно від умов зв'язування* **

* г"\ і * * 'о 'о

існують свої різновиди. Зв'язки між відношеннями в реляційній моделі реалізуються шляхом використання первинних і зовнішніх ключів.

Зв'язки "один до одного"

В концептуальних моделях даних визначають такі обмеження ступеня участі сутностей:

- обов'язкова участь для обох сутностей;

- обов'язкова участь для однієї сутності;

- необов'язкова участь для обох сутностей.

Залежно від обмежень перетворення на реляційну модель будуть різні.

Приклад. Розглянемо можливі варіанти перетворення зв'язку між сутностями Викладач і Дисципліна (рис. 6.11).

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

2. Обов'язкова участь для однієї сутності Припустимо, що кожен викладач обов'язково викладає одну дисципліну, а за кожною дисципліною необов'язково закріплений викладач. В цьому випадку сутність, яка є необов'язковою (Дисципліна) виступає в якості батьківської сутності, а обов'язкова сутність визначається як дочірня (Викладач). Реляційна структура показана на рис. 6.13.

Зовнішній атрибут SU_Cod також може бути ключем для Викладача.

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

Зв'язки "один до багатьох"

У кожне відношення, яке відповідає підлеглій (дочірній) сутності, додається набір атрибутів основної (батьківської)

' W W ** ' Т 7

сутності, який складає первинний ключ основної сутності. У відношенні, що відповідає підлеглій сутності, цей набір атрибутів стає зовнішнім ключем (FOREIGN KEY, FK).

Для моделювання необов'язкового типу зв'язку у атрибутів, що відповідають зовнішньому ключу, встановлюється властивість допустимості невизначених значень (NULL). У разі

обов'язкового типу зв'язку атрибути набувають властивості відсутності невизначених значень (NOT NULL).

Приклад. Розглянемо можливі варіанти перетворення зв'язку між сутностями Викладач і Дисципліна (рис. 6.15).

1. Необов'язкова участь сутності Викладач і обов'язкова участь сутності Дисципліна (рис. 6.16).

2. Необов'язкова участь сутності Викладач і необов'язкова участь сутності Дисципліна (рис. 6.17).

Зв'язки "багато до багатьох"

Для кожного зв'язку M:N необхідно створювати додаткове відношення, яке представляє цей зв'язок і включати в нього всі атрибути, які входять в склад цього зв'язку. Копії атрибутів первинного ключа сутностей, які беруть участь у зв'язку, передаються у нове відношення для використання в якості зовнішніх ключів. Ці зовнішні ключі утворюють також первинний ключ нового відношення.

Приклад. Розглянемо можливі варіанти перетворення зв'язку між сутностями Викладач і Дисципліна (рис. 6.18).

В цьому випадку існує єдина схема перетворення (рис. 6.19).

Інші види зв 'язків

Для рекурсивних зв'язків 1:1 виконуються правила визначені раніше для зв'язку між двома сутностями 1:1. Для

рекурсивного зв'язку 1:1 з обов'язковою участю двох сторін, реляційна схема представляється у вигляді одного відношення з двома копіями первинного ключа (див. рис. 6.12). Одна копія відповідає зовнішньому ключу. Для рекурсивного зв'язку 1:1 з обов'язковою участю тільки однієї сторони створюється або одне відношення, або нове відношення, яке відображає цей зв'язок (див. рис. 6.13). Для рекурсивного зв'язку 1:1 з необов'язковою участю обох сторін створюється нове відношення (див. рис. 6.14).

Для складних типів зв'язків створюється відношення, яке відображає цей зв'язок і включає всі атрибути, які входять в склад цього зв'язку. Копії атрибутів первинного ключа сутностей, які беруть участь у зв'язку, передаються у нове відношення для використання в якості зовнішніх ключів. Ці зовнішні ключі утворюють також первинний ключ нового відношення (див. рис. 6.3).

Для багатозначного атрибуту створюється нове відношення, яке відповідає багатозначному атрибуту, і в це нове відношення передається первинний ключ сутності для використання в якості зовнішнього ключа (див. рис. 6.4).

Зв'язки "суперклас - підклас"

Для виконання перетворення зв'язку типу суперклас - підклас у реляційну модель необхідно враховувати також обмеження ступеня участі у зв'язку (Mandatory або Optional) і обмеження неперетинання (And або Or). Можливі чотири сполучення, перетворення яких дає чотири реляційні схеми. На схему також впливає те, чи беруть участь підкласи в різних зв'язках, кількість сутностей в зв'язку і т.ін. Діапазон можливих варіантів рішення є достатньо великим і конкретна схема вибирається в кожному конкретному випадку з урахуванням багатьох факторів.

Література

1. Гайдамакин Н.А. Автоматизированные информационные системы, базы и банки данных. Вводный курс. - М.: Гелиос АРВ, 2002. - 368 с.

2. Гайна Г.А. Організація баз даних і знань. Мови баз даних: Конспект лекцій.-К .:КНУБА, 2002. - 64 с.

3. Гайна Г.А., Попович Н.Л. Організація баз даних і знань. Організація реляційних баз даних: Конспект лекцій. - К.:КНУБА, 2000. - 76 с.

4. Гарсиа-Молина Г., Ульман Д., Уидом Д. Системы баз данных.-М.: Издательский дом "Вильямс", 2003. - 1088 с.

5. Григорьев Ю.А., Ревунков Г.И. Банки данных.-М.: Изд-во МГТУ им. Н.Э.Баумана, 2002. - 320 с.

6. Грофф Дж., Вайнберг П. Энциклопедия SQL. - СПб.: Питер, 2003. - 896 с.

7. Дейт К.Дж. Введение в системы баз данных. - К.: Диалектика, 1998. - 784 с.

8. Диго С.М. Проектирование и использование баз данных.-М.: Финансы и статистика, 1995. - 208 с.

9. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2001. - 304 с.

10. Когаловский М.Р. Энциклопедия технологий баз данных.- М.: Финансы и статистика, 2002. - 800 с.

11. Конноли Т., Бегг