0. 1.3 Завдання на лабораторну роботу

Провести інфологічне і датологічне проектування для предметної області, що вказана у варіантах, або заданої викладачем:

Варіант 1. ДЕТАЛІ, ЗБУТ, БРИГАДИ.

Варіант 2. ВКЛАДНИКИ, РАХУНКИ, ДОВІДНИК.

Варіант 3. МОДЕЛІ, МАТЕРІАЛ, ЗБУТ.

Варіант 4. ЛІТАКИ, ЕКІПАЖИ, ПОГОДА.

Варіант 5. АБОНЕНТИ, ДОВІДНИК, ЗВ’ЯЗКІВЦІ.

Варіант 6. ПЕРЕДПЛАТНИКИ, ВИДАННЯ, ПОШТА.

Варіант 7. СТУДЕНТИ, ЛАБОРАТОРІЇ, РОЗКЛАД.

Варіант 8. ВОДІЇ, ВАНТАЖІ, ЗАМОВЛЕННЯ.

Варіант 9. БУДМАТЕРІАЛИ, ДОСТАВКА, ВИКОРИСТАННЯ МАТЕРІАЛІВ.

Варіант 10. НАДОЇ, ФУРАЖ, РЕЖИМ.

Варіант 11. РОБІТНИКИ, БУХГАЛТЕРІЯ, ТАБЕЛЬНИК.

Варіант 12. ДЕРЖАВИ, ЕКОНОМІЧНИЙ СТАН, РЕСУРСИ.

Варіант 13. АБІТУРІЄНТИ, ФАКУЛЬТЕТИ, ІСПИТИ.

Варіант 14. ШАХИСТИ, ТУРНИРНА ТАБЛИЦЯ, ГОНОРАР.

Варіант 15. ТОВАРИ, ПОКУПЦІ, ПРОДАВЦІ.

Варіант 16. РИБОЛОВНА БРИГАДА, РЕСУРСИ, ЗБУТ.

Варіант 17. СЛУЖБОВЦІ, МОВИ ПРОГРАМУВАННЯ, ВОЛОДІННЯ МОВАМИ ПРОГРАМУВАННЯ.

Варіант 18. КНИГИ, ЧИТАЧІ, ВИДАНІ КНИГИ.

Варіант 19. ГРУПИ, СТУДЕНТИ, ОЦІНКИ.

Варіант 20. КНИГИ, АВТОРИ, АВТОРИ КНИГИ.

Варіант 21. ПРЕДМЕТИ, ВИКЛАДАЧІ, ВИКЛАДАЧІ, ЩО ВЕДУТЬ ПРЕДМЕТИ.

Варіант 22. ПРЕДМЕТИ, ГРУПИ, ГРУПИ, ЩО ВИВЧАЮТЬ ПРЕДМЕТ.

Варіант 23. ПОКУПЦІ, ТОВАРИ, ЗАМОВЛЕННЯ.

Варіант 24. КІМНАТИ, СТУДЕНТИ, СТУДЕНТ, ЩО МЕШКАВ.

Варіант 25. КОМП’ЮТЕРИ, СТУДЕНТИ, СТУДЕНТИ, ЩО ПРАЦЮВАЛИ ЗА КОМП’ЮТЕРОМ.

Варіант 26. ДІАГНОЗ, ХВОРИЙ, ХВОРОМУ НАДАНИЙ ДІАГНОЗ.

Варіант 27. РЕЄСТРАТУРА, ХВОРІ, ЛІКАРІ.

Варіант 28. СПІВРОБІТНИКИ, ВІДДІЛ КАДРІВ, НАВЧАННЯ.

1.4 Методика виконання

Розглянемо по кроках загальний підхід до датологічного проектування на основі інфологічної моделі, представленої ІЛМ.

1. Кожна проста сутність перетворюється в таблицю (відношення). Назва сутності стає ім'ям таблиці. Кожен простий атрибут стає стовпцем таблиці з тим же ім'ям: R1 (І1, А1, А2, А3).

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

• довжина ключа – в якості первинного ключа вибирається, як правило, найкоротший з ймовірних ключів;

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

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

В СУБД MySQL можливо автоматично генерувати значення (AVTO_INCREMENT) поля, що використовується в якості ключа. Цей штучний код можна використовувати для простих об'єктів, якщо в предметній області не передбачається застосування іншої системи кодування (наприклад, ЕДРПОУ – класифікатор підприємств і організацій, ЗКГНГ – класифікатор галузей, ІПН – податковий номер). Якщо до складу унікального входять зв'язки, то до числа полів первинного ключа додається копія унікального ідентифікатора сутності, що знаходиться на далекому кінці зв'язку (процес може тривати рекурсивно).

3. Кожному з багатозначних атрибутів ставиться у відповідність відношення, полями якого будуть ідентифікатор, вибраний в якості первинного ключа, і багатозначний атрибут. Ключ цього відношення буде складовим, що включає обидва ці атрибута. Для багатозначних атрибутів БА4 і БА5 будуть створені відносини: R2 (І1, БА4) і R3 (І1, БА5).

4. Якщо сутність має необов'язковий атрибут, можливі два варіанти:

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

• якщо властивість має мале число екземплярів, то можна виділити відношення, що включає ідентифікатор і відповідний атрибут: R4 (І1, НА6). Відношення буде містити стільки рядків, скільки об'єктів має властивість.

5. Якщо сутність має складовий атрибут, то можливі два варіанти:

• складовій сутності ставиться у відповідність окреме поле;

• кожному з складових елементів складеної сутності ставиться у відповідність окреме поле.

Вибір варіанту залежить від характеру обробки даних. При реалізації запитів простіше об'єднати поля, ніж виділити частину поля. Якщо передбачається використання компонентів атрибуту, краще варіант 2, інакше – варіант 1.

6. Бінарні зв'язки один-до-одного і один-до-багатьох стають зовнішніми ключами. Створюється копія унікального ідентифікатора з кінця зв'язку "один", і відповідні поля складають зовнішній ключ. Зв'язок один-до-одного між сутностями зустрічається рідко. Якщо клас належності обох сутностей є обов'язковим, то для відображення обох пов'язаних сутностей можна використовувати одну таблицю: R3 (І1, І2, А1, А2). Однак таким рішенням зловживати не слід. Якщо для кожного об'єкта будуть потрібні свої зв'язки або в запитах потрібна інформація по кожній сутності, то таке рішення ускладнить або сповільнить роботу з БД.

Якщо для кожної сутності створюються окремі відношення, то інформацію про зв'язки можна відобразити, включивши в одне з відношень ідентифікатор з іншого відношення. Причому це можна зробити в будь-якому з відношень: R1 (І1, А1, И2) R2 (І2, А2) або R1 (І1, А1) R2 (І2, А2, І1). Якщо клас належності однієї з сутностей є необов'язковим, то ідентифікатор сутності з необов'язковим класом додається до відношення відповідної сутності з обов'язковим класом належності. Якщо клас належності обох сутностей є необов'язковим, то, щоб уникнути наявності порожніх полів, слід використовувати три відношення: по одному для кожної сутності і одне – для відображення зв'язку між ними: R1 (І1, А1) R2 (І2, А2 ) R3 (І1, І2 ).

7. Перетворення бінарного зв'язку один-до-багатьох (1: N) залежить тільки від класу належності N-зв'язкової сутності. Якщо він є обов'язковим, то можна використовувати два відношення (по одному для кожної сутності). У відношення для N-зв'язкової сутності додається ідентифікатор 1-зв'язкової сутності: R1 (І1, А1) R2 (І2, А2, І1). Якщо клас належності N-зв'язкової сутності є необов'язковим, то для відображення зв'язку необхідно створити трете відношення, його призначення – містити ключі кожної з пов'язаних сутностей: R1 (І1, А1) R2 (І2, А2) R3 (І1, І2).

8. Для бінарного зв'язку багато-до-багатьох (М: N) потрібні три відношення: по одному для кожної сутності та одне додаткове – для відображення зв'язку між ними. Останнє відношення буде містити ідентифікатори пов'язаних об'єктів. Ключ цього відношення буде складовим: R1 (І1, А1) R2 (І2, А2) R3 (І1, І2).

9. У разі N-арного зв'язку необхідно використовувати (n+1) відношення – по одному для кожної сутності, і одне для зв'язку. Ідентифікатор кожної сутності стане первинним ключем відповідного відношення. Відношення, яке породжене зв'язком, буде мати серед своїх атрибутів ключі кожної сутності. Якщо зв'язок має атрибути, то вони стають атрибутами відношення зв'язку. Наприклад: R1 (І1, А1) R2 (І2, А2) R3 (І3, А3) R4 (І1, І2, І3, АЗ4).

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

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

1.5 ЗМІСТ ЗВІТУ

Звіт містить номер, тему та мету лабораторної роботи, завдання загальне і за варіантом. Розділ “Результати роботи” повинен містити овал-діаграму з коментарями, результати датологічного проектування, висновки.

Далі у вказівках в змісті звіту йдеться про розділ “Результати роботи”.