Проектування РБД

Рисунок 8.1 – Вибір типу МД

Рисунок 8.2 – Вибір нотації МД

75

Рисунок 8.3 – Настройка середовища ERwin

8.2.3.Визначення сутностей

Сутності створюються за допомогою меню та лінійки інструментів (рис.8.4) у режимі відображення сутностей “Entity”.

Рисунок 8.4 – Вид меню і панелі інструментів ERwin

Сутності автоматично позначаються як Еi/I, де Ei – це ім’я сутності, I – її номер у моделі. Позначення розміщується над прямокутником.

Режим “Entity” служить не тільки для розміщення сутностей, а і для зручності огляду великої діаграми.

Незалежні сутності на діаграмі вони зображуються прямокутниками, а залежні – прямокутниками із заокругленими кутами.

Для кожної сутності в редакторі “Entity Definition” можна задати її визначення та докладний опис. Ці нотатки з'являться у звітах і можуть бути відображені на діаграмі. Такий режим представлення сутностей служить для презентації моделі.

76

8.2.4 Визначення атрибутів сутностей

При переході від ПО до ІЛМ потрібно вводити інформацію про те, що становить сутність. Цю інформацію вводять шляхом завдання атрибутів.

Завдання атрибутів проводиться у режимі Attributes, що викликається через пункт основного меню Model або через контекстне меню → Attributes. Цей режим є основним при проектуванні як на логічному, так і на фізичному рівнях.

Відповідне вікно редагування атрибутів “Attributes” дозволяє додавати атрибути до вибраної сутності, проводити їх перейменування та вилучення, визначати тип домену (Datetime, Number, String), назначати ключові атрибути.

На рис. 8.5 наведено вікно завдання властивостей умовним атрибутам Pij, де i – номер сутності, j – номер атрибуту сутності.

Рисунок 8.5 – Вікно визначення властивостей атрибутів

На рис. 8.6 наведено основний планшет МД після створення двух сутностей.

Рисунок 8.6 – Основний планшет діаграми рівня сутностей

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

77

Атрибути, що можуть бути альтернативним ключем, помічають покажчиком AKi у дужках після імені. В ERwin можна також встановлювати групи атрибутів, які не ідентифікують унікально екземпляри сутності, але часто використовуються для доступу до даних.

Порядок завдання первинних ключів та визначення атрибутів не має значення. Ті самі атрибути сутності можуть входити до кількох різних груп ключів.

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

Таким чином, в ERwin сутність візуально представляє три основних види інформації:

–ім’я та тип сутності (незалежна/залежна);

–атрибути, що становлять первинний ключ;

–неключові атрибути.

Залежно від режиму подання діаграми сутність може містити також її опис і інші відомості.

8.2.5 Визначення залежностей між сутностями

Опис зв'язків між сутностями вводиться в редакторі “Relationships”.

В ERwin зв'язки представлені п'ятьма основними елементами інформації:

1)тип зв'язку;

2)батьківська сутність;

3)дочірня (залежна) сутність;

4)потужність зв'язку (cardinality);

5)допустимість порожніх Null-значень.

Зв'язки можуть бути ідентифікуючими, неідентифікуючими, повної або неповної категорії, а також неспецифічними.

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

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

Для визначення зв'язків ERwin обирають тип зв'язку, потім мишею спочатку вказують батьківську сутність, а потім – дочірню сутність. Ідентифікуючий зв'язок зображується суцільною лінією; неідентифікуючий –

78

пунктирною лінією. Лінії закінчуються точкою з боку дочірньої сутності. Зразки зв’язків наведені на рис.8.7.

а) ідентифікуючий зв'язок б) неідентифікуючий зв'язок Рисунок 8.7 – Типи зв’язків між сутностями

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

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

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

Відповідно до методології IDEF1X пакет ERwin надає 4 варіанти для числа N, які зображуються додатковим символом у дочірній сутності:

–нуль, один або більше (за замовчуванням);

–один або більше (зображується буквою "P");

–нуль або один (зображується буквою "Z");

–рівно N, де N – конкретне число (зображується числом N). Властивості звязку встановлюються у вікні Relationship Properties. Приклад опису основних властивостей зв’язку наведено на рис. 8.8а.

При визначенні властивостей звязку бажано встановити правила

підтримки цілісності за посиланнями Referential Integrity. Це дозволить забезпечити вимоги, щоб значення зовнішнього ключа екземпляра дочірньої сутності завжди відповідали значенням первинного ключа екземпляра в батьківській сутності. Правила встановлюються у режимі Referential Integrity (RI) Action (рис. 8.8б) і визначають ті дії (операції), які мають бути виконані для значень атрибутів звязку в екземплярах однієї сутності, якщо в іншій звязаній сутності виконані операції зміни.

79

а) вибір виду зв’язку

б) вибір виду дій Рисунок 8.8 – Вікно визначення властивостей зв’язку

80

Зазвичай такі дії оформлюються як процедури обробки подій при виконанні операції в вибраній сутності. Посилальна цілісність може контролюватися при всіх діях (операціях), які змінюють дані в звязаних сутностях, а саме додавання (Insert), вилучення (Delete) та модифікація (Update). Для кожного зв'язку можуть бути задані вимоги щодо обробки цих операцій як для батьківської, так і для дочірньої сутності. Фактично, для виконання правил цілісності в МД створюються відповідні RIтригери і процедура обробки подій оформлюються як їх реакція.

ERwin надає кілька варіантів обробки подій, які вибираються из списку:

–Restrict (обмеження) перешкоджає дії, якщо в іншій сутності є зв'язані екземпляри (заборона операції);

–Cascade (каскад) виконання аналогічної операції;

–Set null (встановити Null) значення встановлюються як Null (порожнє,

–Set default (встановити значення за умовчанням) встановлюються вказані значення за умовчанням;

–No Action (немає дії) не виконується ніяка дія, яле виконується перевірка допустимості;

–None (нічого) ніяка дія не потрібна (відсутність перевірки). Допустимість порожніх Null-значень у неідентифікуючих зв'язках ERwin

зображує порожнім ромбиком на дузі зв'язку з боку батьківської сутності.

Ім'я зв'язку на логічному рівні являє собою "дієслово", що зв'язує сутності. Фізичне ім'я зв'язку, яке може відрізнятися від логічного, для ERwin означає ім'я обмеження (constraint) або індексу.

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

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

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

Після встановлення властивостей зв’язків можна вважати, що ЛМД побудована.

Кілька прикладів ER-діаграм логічного рівня були наведені на рис. 6.9, 7.6, 7.7.

Після формування ЛМД можна переходити до побудови ФМД і генерації

БД.

Разом з тим, ЛМД і ФМД можуть розроблятися паралельно.

81

9 КОНТРОЛЬНІ ОПИТУВАННЯ

9.1 Представлення моделей баз даних

Опитування №1 проводиться по розділу 4.

В індивідульному завданні (ІЗ) надається структура БД. Під час опитування необхідно:

1.Визначити вид заданої моделі БД

2.Подати БД у відповідності з іншими моделями.

9.2 Концептуальне моделювання

Опитування №2 проводиться по розділу 3, який виноситься на самостійне вивчення.

В ІЗ надається короткий опис предметного середовища (ПО). Під час опитування необхідно:

1.Дати короткий опис процесу обробки інформації короткими реченнями

звикористанням підметів, присудків і додатків (3-4 речення). Кожне речення має починатися з нової строки. Позначити підмети, присудки та додатки.

2.Провести аналіз ПО та визначити ті характеристики, які можуть змінюватися в часі. Навести їх формулювання, наприклад: вважаємо, що працівник у часі може змінювати місце роботи.

3.Розробити ІМД і навести її рисунок у вигляді ER-діаграми типу “Сутності – зв'язки”. В діаграмі рекомендовано визначити різні види сутностей (стрижні, асоціації, характеристики, позначення), їх атрибути та ключі.

4.Надати опис МД за допомогою МІМ.

При виконанні роботи необхідно враховувати наступне:

–реквізит ПІБ (особа, людина, працівник) визначається як 8 атрибутів (прізвище, ім'я, по-батькові, стать, дата народження, резюме, фотографія, телефон);

–реквізит місце роботи – це 3-4 атрибути (підприємство*, підрозділ, посада, оклад);

–реквізит адреса – це 4-6 атрибутів (поштовий індекс, населений пункт*, район*, вулиця, будинок, номер квартири або офісу).

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

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

9.3 Розробка логічних моделей даних

Опитування проводиться по розділам 5-6.

В ІЗ надається короткий опис предметного середовища (ПО).

82

Під час опитування необхідно:

1.Визначити структуру УТ.

2.Розробити ЛМД і навести її рисунок у вигляді ER-діаграми типу “Таблиці – зв'язки”. В діаграмі рекомендовано визначити таблиці, їх поля, первинні та альтернативні ключі.

При виконанні роботи необхідно враховувати додаткові вимоги до полів:

– атрибут ПІБ (особа, людина, працівник) визначається як 8 полів (прізвище, ім'я, по-батькові, стать, дата народження, резюме, фотографія, телефон);

– атрибут місце роботи – це 3-4 поля (підприємство*, підрозділ, посада, оклад);

– атрибут адреса – це 4-6 полів (поштовий індекс, населений пункт*, район*, вулиця, будинок, номер квартири або офісу).

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

ЗАКЛЮЧЕННЯ

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

Логічна МД – це шаг до розробки фізичної МД у середовищі сучасних СУБД. В той же час ЛМД отримує “зворотній” вплив з боку ФМД.

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

Питання фізичної реалізації БД будуть розглянуті окремо.

Конспект призначений для студентів напрямів підготовки “Комп'ютерні науки” та “Комп’ютерна iнженеpiя” при вивчені дисципліни “Організація баз даних і знань”, студентів інших спеціальностей, слухачів курсів підвищення кваліфікації та перепідготовки кадрів, які вивчають комп’ютерні інформаційні технології.

83

84