ТЕМА № 4
Логічне проектування БД.

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

Мета логічного етапу проектування – організація даних, виділених на етапі інфологічного проектування у форму, прийняту в обраній СУБД¹. Задачею логічного етапу проектування є відображення об'єктів предметної області в об'єкти використовуваної моделі даних, щоб це відображення не суперечило семантиці предметної області і було по можливості найкращим (ефективним, зручним і т.д.). З погляду обраної СУБД задача логічного проектування реляційної бази даних складається в обґрунтованому прийнятті рішень про те:

-    з яких відношень (таблиць) повинна складатися база даних;

-    які атрибути повинні бути в цих відношень;

-    як забезпечити виконання вимог до реляційної БД;

-    як позбутися суперечливості та надлишковості даних;

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

2.2. Рівні логічної моделі реляційної БД

Розрізняють три рівні логічної моделі для БД реляційного типу, що відрізняються по глибині представлення інформації про дані:

-    діаграма сутність-зв'язок (Entity Relationship Diagram, ERD);

-    модель даних, заснований на ключах (Key Based model, KB);

-    повна атрибутивна модель (Fully Attributed model, FA).

Діаграма сутність-зв'язок являє собою модель даних верхнього рівня. Вона містить сутності і взаємозв'язки, що відбивають основні бізнес-правила предметної області. Така діаграма не занадто деталізована, у неї включаються основні сутності і зв'язки між ними, що задовольняють основним вимогам, пропонованим до ІС. Сутності представляються у вигляді таблиць, чи, як їх інакше називають, відношень, що містять назву сутності на логічному рівні та перелік імен доменів (атрибутів), що ідентифікують сутність. Діаграма сутність-зв'язок може включати зв'язки багато до багатьох і не включати опис ключів. Як правило, ERD використовується для презентацій і обговорення структури даних з експертами предметної області.

Модель даних, заснована на ключах, – більш докладне представлення даних. Вона включає опис усіх сутностей і первинних ключів і призначена для представлення структури даних і ключів, що відповідають предметній області. В такій моделі є змога перевірки забезпечення цілісності за сутностями і за посиланнями.

Повна атрибутивна модель – найбільш детальне представлення структури даних. Вона представляє дані в третій або вищих нормальних формах і включає всі сутності, атрибути і зв'язки.

Основні компоненти ER-діаграми - це сутності, атрибути і зв'язки. Кожна сутність є множиною подібних індивідуальних об'єктів, називаних екземплярами. Кожен екземпляр індивідуальний і повинен відрізнятися від всіх інших екземплярів. Атрибут виражає певну властивість об'єкта. З погляду реляційної БД сутності відповідає таблиця, екземпляру сутності - рядок у таблиці, а атрибуту - стовпець таблиці.

Побудова моделі даних передбачає визначення сутностей і атрибутів, тобто необхідно визначити, яка інформація буде зберігатися в конкретній сутності чи атрибуті. Сутність можна визначити як об'єкт, подію чи концепцію, інформація про які повинна зберігатися. Сутності повинні мати найменування з чітким змістовним значенням, іменуватися іменником в однині, не носити "технічних" найменувань і бути досить важливими для того, щоб їх моделювати. Іменування сутності в однині полегшує надалі читання моделі. Фактично ім'я сутності дається по імені її екземпляра. Прикладом може бути сутність Замовник (але не Замовники!) з атрибутами Номер замовника, Прізвище замовника й Адреса замовника. На рівні логічної моделі їй може відповідати таблиця Customer (Замовник) з колонками Customer_number (Замовник_Номер), Customer_name (Замовник_Ім'я) і Customer_address (Замовник_Адреса).

Для внесення сутності в модель при розробці її в Microsoft Visio, як і в багатьох інших CASE-засобах, необхідно "активувати" форму сутності на панелі шаблону Entity Relationship та перетягнути її на ті місце на діаграмі, де необхідно розташувати нову сутність. Клацнувши правою кнопкою миші по сутності і вибравши зі спливаючого меню пункт Set Entity Name, можна викликати діалог Custom Properties, у якому визначаються ім'я, тип і визначення (опис) сутності. Кожна сутність може бути цілком визначена за допомогою текстового опису у вкладці Dеfіnе. Вкладка Dеfіnе використовується для уведення визначення сутності. Ці визначення корисні як на логічному рівні, оскільки дозволяють зрозуміти, що це за об'єкт, так і на фізичному рівні, оскільки їх можна експортувати як частину схеми і використовувати в реальної БД (CREATE COMMENT on entity_name).
Вимоги до обраного набору відношень і складу їхніх атрибутів повинні задовольняти наступним умовам:

-    відношення повинні відрізнятися мінімальною надмірністю атрибутів;

-    обрані для відношення первинні ключі повинні бути мінімальними;

-    між атрибутами не повинне бути небажаних функціональних залежностей;

-    вибір відношень і атрибутів повинен забезпечувати мінімальне дублювання даних;

-    не повинно бути труднощів при виконанні операцій включення, видалення і модифікації даних;

-    час виконання запитів на вибірку даних повинен задовольняти пропонованим вимогам;

-    перебудова набору відношень при введенні нових типів повинна бути мінімальною та по можливості автоматичною.

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

2.3. одержання реляційної схеми бази даних з ER-діаграми

Процес одержання реляційної схеми бази даних з ER-діаграми містить наступні кроки.

1.                 Кожна проста сутність перетворюється у відношення. Проста сутність - сутність, що не є підтипом і не має підтипів. Ім'я сутності стає іменем відношення.

2.                 Кожен багатозначний атрибут породжує або набір багатозначних атрибутів, або нову сутність, складену з компонентів багатозначного атрибуту. При цьому ця сутність може бути асоційованою, зв'язуючи дві нові сутності, одна з яких часто є незалежною, друга – залежною. З вихідною сутністю нова сутність зв'язується зв'язком 1:М.

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

4.                 Компоненти унікального ідентифікатора сутності перетворюються в первинний ключ відношення. Якщо є кілька можливих унікальних ідентифікаторів, вибирається найбільш використовуваний.

5.                 Зв'язки M:1 (і 1:1) стають зовнішніми ключами. Для цього робиться копія унікального ідентифікатора із кінця зв'язку "один" і відповідні стовпці утворюють зовнішній ключ. Необов'язкові зв'язки відповідають стовпцям, що допускають невизначені значення; обов'язкові зв'язки - стовпцям, що не допускають невизначених значень.

6.                 У таблицях, побудованих на основі асоціацій, зовнішні ключі використовуються для ідентифікації учасників асоціації, а в таблицях, побудованих на основі характеристик і позначень, - для ідентифікації сутностей, описуваних цими характеристиками і позначеннями. Обмеження, пов'язані з кожним з цих зовнішніх ключів, підлягають окремій специфікації.

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

а) усі підтипи розташувати в одній таблиці;

б) для кожного підтипу побудувати окрему таблицю.

При застосуванні способу (а) таблиця створюється для найбільш зовнішнього супертипу. У таблицю додається принаймні один стовпець, що містить код ТИПУ, і він стає частиною первинного ключа. Для роботи з підтипами можуть створюватися представлення. При використанні методу (б) супертип відтворюється за допомогою конструкції UNION.