1.2 Розробка концептуальної й реляционной моделі

Поетапна допомога з концептуального проектування БД.

1. Визначення типів сутностей.

Можуть виникати наступні складності: 1) використання користувачами при складанні специфікацій синонімів («відділення» й «філія»), омонімів («програма2 може позначати курс навчання або план робіт), прикладів (уживання в специфікації не узагальненого працівника, а одного або декількох імен); 2) рішення про те, чим є оп-ределенный об'єкт - сутністю, атрибутом або зв'язком (приклад - об'єкт Сімейний шлюб).

2. Визначення типів зв'язків.

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

3. Визначення атрибутів і зв'язування їх з типами сутностей і зв'язків. Найпростіший метод виділення атрибутів - після ідентифікації чергової сутності або зв'язку відповістити на запитання «Яку інформацію потрібно зберігати про...».

Можуть виникати наступні складності: 1) визначення, простим або складовим є атрибут («адреса» може зберігатися як єдине ціле або може бути розбита на складові «місто», «вулиця» і т.д.); 2) виявлення атрибутів, значення яких можуть бути обчислені за допомогою інших атрибутів, і перевірка того, чи не можуть бути змінені надалі значення атрибутів, від яких залежить значення, яке обчислюється (приклад - курс валюти).

4. Визначення доменов атрибутів.

Домены повинні містити набір припустимих значень для атрибута й відомості про розмір і формат кожного атрибута.

5. Визначення атрибутів, які є потенційними й первинними ключами. Рекомендації з вибору первинного ключа серед потенційних:

• використати потенційний ключ із мінімальною кількістю атрибутів;

• використати той потенційний ключ, імовірність зміни значень якого мінімальна;

• використати той потенційний ключ, у якого мінімальна ймовірність втрати унікальності в майбутньому;

• використати потенційний ключ із мінімальною довжиною (у випадку текстових атрибутів);

• використати той потенційний ключ, з яким простіше працювати з погляду користувача.

6. Створення діаграми «сутність-зв'язок».

7. Обговорення локальних концептуальних моделей даних з кінцевими користувачами.

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

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

При об'єднанні представлень використаються три основних концепції: ідентичність, агрегація й узагальнення.

Два або більше елементи моделі ідентичні, якщо мають однакове семантичне значення.

Агрегація дозволяє розглядати зв'язок між елементами моделі як новий елемент. При об'єднанні представлень агрегація зустрічається в трьох формах:

1) в одному представленнії агрегатний об'єкт визначений як єдине ціле, а у другому розглядаються його складові частини;

2) агрегатний об'єкт як єдине ціле не визначений в жодному з представлень, але в обох предствленнях розглядаються його складові частини;

3) один агрегатний об'єкт розглядається в різних представленнях, але по складу розрізняється.

Узагальненням називається абстракція даних, що дозволяє трактувати клас різних подібних типів об'єктів як один пойменований узагальнений тип об'єкта.

Процес об'єднання носить ітеративний характер, причина цього в тім, що в процесі об'єднання виявляються протиріччя між окремими локальними представленнями.

Правила перетворення моделі «сутність-зв'язок» у реляційні таблиці:

1) об'єкт із атрибутами перетворюється в таблицю;

2) якщо деякий набір атрибутів може бути використаний як ключ, то він вибирається ключем таблиці, інакше до таблиці додається атрибут, значення якого будуть однозначно визначити екземпляри об'єкта;

3) конкретизація об'єкта представляється таблицею, що містить ключ таблиці для об'єкта, що конкретизується, і додаткові атрибути конкретизації;

4) відношення 1:1 перетворюється шляхом приміщення ключа одного з об'єктів як додаткового атрибуту в таблицю другого об'єкта;

5) у відношенні 1:М у таблицю, що описує об'єкт, потужність із боку якого рівняється «багато», включається стовпець, що відповідає ключу об'єкта, потужність із боку якого рівняється «один», цей стовпець буде зовнішнім ключем;

6) для перетворення відношення М:N створюються три таблиці - по однієї для кожного об'єкта й таблиця-перетинання, що містить ключі двох інших таблиць.

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

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

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

Другий крок нормалізації полягає в тому, щоб виділити ключі й залежні від них атрибути. Кожен рядок таблиці, що перебуває в першій нормальній формі (1НФ), повністю залежить від сукупності ключових атрибутів. Для того щоб привести таблицю до 2НФ, потрібно виділити групи атрибутів, що залежать від частин складеного ключа. Ці групи можуть утворити окремі таблиці. Виділення з таблиці, що перебуває в 1НФ, таких таблиць, у яких неключові атрибути залежать тільки від ключа в цілому, називається приведенням до 2НФ.

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

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

Процес нормалізації базується на аналізі взаємозв'язків між типами атрибутів і ніяк не пов'язаний з можливими значеннями їхніх екземплярів.

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