Концептуальне проектування бази даних. Етап 1. Створення локальної концептуальної моделі даних на основі предметної області користувача арМу.
Перший етап проектування бази даних полягає в розробці концептуальної моделі даних для даного користувача. Представлення користувача містить дані, необхідні для прийняття рішень або виконання деякого завдання.
Для деякого представлення локальною концептуальною моделлю даних ми будемо називати концептуальну модель даних, що відображає представлення про предметну область певного користувача. Кожна локальна концептуальна модель даних включає наступне:
типи сутностей;
типи зв’язків;
атрибути;
домени атрибутів;
потенційні ключі;
первинні ключі.
Концептуальна модель доповнюється документацією, яка створюється в процесі розробки цієї моделі. На першому етапі розробки необхідно виконати наступні завдання:
Етап 1.1. Визначення типів сутностей.
Етап 1.2. Визначення типів зв’язків.
Етап 1.3. Визначення атрибутів і зв’язування їх з типами сутностей та зв’язків.
Етап 1.4. Визначення доменів атрибутів.
Етап 1.5. Визначення атрибутів, що є потенційними і первинними ключами.
Етап 1.6. Створення діаграми “сутність-зв’язок”.
Етап 1.7. Обговорення локальної концептуальної моделі даних з користувачем.
Етап 1.1. Визначення типів сутностей.
Перший етап побудови локальної концептуальної моделі даних полягає у визначенні основних об’єктів, які можуть цікавити користувача. Ці об’єкти є типами сутностей, що входять в модель.
На цьому етапі потрібно за допомогою одного з відомих методів ідентифікації сутностей визначити весь набір сутностей, необхідний для задоволення вимог до системи.
Етап 1.2. Визначення типів зв’язків.
Після виділення сутностей наступним етапом розробки буде встановлення всіх існуючих між ними зв’язків. Визначення типів зв’язків здійснюється вибіркою із специфікацій на проект всіх виразів, що складаються з дієслів. Але нас цікавитимуть тільки ті зв’язки між сутностями, що задовільняють вимогам до даного проекту.
Особливу увагу слід приділити перевірці того, чи були виділені всі зв’язки, що явно або неявно присутні у специфікаціях на проект.
Результати аналізу запишіть у таблицю.
Таблиця
2.5. Основні типи зв’язків.
Тип сутності
Тип зв’язку
Тип сутності
Етап
1.3. Визначення атрибутів і зв’язування
їх з типами сутностей та зв’язків.
1-Іа даному етапі необхідно виявити всі дані, які описують сутності і зв’язки в моделі бази даних, що створюється.
Кожний атрибут може бути або простим, або складеним. Складений атрибут — це набір простих атрибутів. Тому важливо ідентифікувати всі прості атрибути для подальшого представлення в концептуальній моделі бази даних, включаючи і ті з них, які надалі потрібно використати для створення складених атрибутів.
Атрибути, значення яких встановлюються за допомогою інших атрибутів, називаються похідними. Як правило, подібні атрибути взагалі не відображаються в концептуальній моделі даних. Але в тих випадках, коли мова йде про можливий ризик видалення або модифікації атрибута або атрибутів, значення яких використовуються для обчислення значення похідного атрибута, останній повинен бути представлений в моделі даних. Це дасть змогу запобігти можливій втраті інформації. Слід також вказати, що даний атрибут є похідним.
Відомості про всі атрибути, що належать відповідним типам сутностей, запишіть у вигляді таблиці.
Таблиця
2.6. Атрибути, що належать сутностям.
Тип сутності
Атрибут
Етап
1.4. Визначення доменів атрибутів.
Кожен атрибут реляційної бази даних визначається на деякому домені. Доменом називають множину допустимих значень для одного або декількох атрибутів. Домени можуть відрізнятись для кожного з атрибутів, але два і більше атрибутів можуть бути визначені на одному і тому ж домені.
Домени повинні містити такі дані:
набір допустимих значень для атрибута;
£
відомості про розмір та формат кожного з полів атрибутів.
В доменах можна вказувати також іншу додаткову інформацію — наприклад, відомості про допустимі операції із значеннями атрибута, а аткож дані про те, які атрибути можна використовувати при побудові комбінацій з декількох атрибутів.
Охарактеризуйте домени всіх атрибутів і результати аналізу запишіть у вигляді таблиці.
Таблиця 2.1. Домени всіх атрибутів.
Атрибут |
Ім’я домену |
Вмістиме домену |
Визначення домену |
|
|
|
|
Етап 1.5. Визначення атрибутів, що є потенційними і первинними ключами.
На цьому етапі для кожної сутності встановлюється потенційний ключ (або ключі), після чого здійснюється вибір первинного ключа. Потенційним ключем називається атрибут або мінімальний набір атрибутів заданої сутності, що дозволяє унікальним чином ідентифікувати кожний її екземпляр. Для деяких еутностей можлива наявність декількох потенційних ключів. В цьому випадку серед них необхідно вибрати один ключ, який називатиметься первинним ключем. Інші потенційні ключі будуть називатись альтернативними ключами
При виборі первинного ключа серед декількох потенційних керуйтеся наведеними нижче рекомендаціями:
Використовуйте потенційний ключ з мінімальним набором атрибутів,
Використовуйте той потенційний ключ, ймовірність зміни значень якого мінімальна.
Вибирайте той потенційний ключ, який має мінімальну ймовірність втрати унікальності значень в майбутньому.
Використовуйте потенційний ключ, значення якого мають мінімальну довжину (у випадку текстових атрибутів).
Зупиніть свій вибір на потенційному ключу, з яким буде легко працювати (з точки зору користувача).
Результати визначення первинних і альтернативних ключів для кожної із еутностей запишіть у вигляді таблиці.
Таблиця 2.8. Сутності та їхні первинні і альтернативні ключі.
Сутність |
Первинний ключ |
Альтернативний ключ |
|
|
! |
Етап 1.6. Створення діаграми “сутніеть-зв ’ток”.
На цьому етапі створюється діаграма “сутність-зв’язок” (ЕК-діаграма), що містить концептуальне відображення представлення користувача про предметну область додатку.
Намалюйте створену ЕЯ-діаграму.
Ця ЕЯ-діаграма і підготовлена на етапі 1 документація (в сукупності) представляють собою локальну концептуальну модель даних для користувача АРМу.
Етап 1.7. Обговорення локальної концептуальної моделі даних з користувачем.
Перш ніж завершити виконання першого етапу розробки бази даних, необхідно обговорити створену локальну концептуальну модель даних з користувачем АРМу, При виявленні помилок слід внести в проект відповідні зміни, для чого необхідно повернутись до
виконання попередніх етапів. Цей цикл повинен повторюватися до тих пір, поки користувач не погодиться з тим, що запропонований йому проект вірно відображає представлення останнього про роботу даного підприємства.