Курс «Организация баз данных» (стр. 6 )

Один до одного (1:1) – кожного запису однієї таблиці відповідає тільки один запис іншої таблиці.

Один до багатьох (1:М) – одного запису головної таблиці можуть відповідати кілька записів підлеглої таблиці.

Багато хто до одного (М:1) – декількох записам головної таблиці може відповідати та сама запис підлеглої таблиці.

Багато хто до багатьох (М:М) – один запис головної таблиці пов'язана з декількома записами підлеглої таблиці, а один запис підлеглої таблиці пов'язана з декількома записами головної таблиці.

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

Та сама таблиця може бути головної стосовно однієї таблиці й підлеглої стосовно іншої. Або в однієї головної таблиці може перебувати в підпорядкуванні не одна, а кілька таблиць.

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

Зв'язок “багато хто до багатьох” (М:М) необхідно розбити на зв'язку “М:1” і “1:М” за допомогою додаткової таблиці.

Клас приналежності визначать обов'язковість входження кожного запису таблиці у зв'язок. Розрізняють обов'язковий і не обов'язковий клас приналежності.

Необов'язковий клас приналежності показує, що допускаються записи таблиці, що не беруть участь у зв'язку.

Обов'язковий клас приналежності показує, що всі записи таблиці беруть участь у зв'язку.

Рис. 1. Схема інфологічної моделі предметної області варіанту 31 ,,Приймальна комісія”, що містить зв'язок М:1

2х1 – розміри прямокутника

1,5х1 – розміри ромба

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

4.  Логічна модель бази даних

Перетворення інфологічної моделі в реляційну модель даних

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

Існує три підходи до вирішення проблеми перетворення інфологічної схеми предметної області в реляційне представлення даних:

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

2.  в другому підході реалізується автоматизована компіляція інфологічної моделі предметної області в схему бази даних, найчастіше реляційну;

3.  третій підхід – це безпосередня робота з базою даних у семантичній моделі, тобто застосування систем управління базами даних, заснованих на семантичних моделях даних.

Згідно першого та другого підходів в результаті створюється реляційна модель бази даних у третій нормальній формі.

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

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

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

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

4.  оскільки між сутностями розробленої інфологічної моделі були визначені тільки зв’язки типу “один-до-багатьох”, то потреби у створенні проміжних таблиць згідно застосованої методики не існує.

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

5.  Фізична модель БД (Даталогічна модель БД)

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

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

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

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

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

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

Обмеження NOT NULL – поле обов'язково заповнюється.

Назва атрибуту	Ідентифікатор	Тип	Розмір	Обмеження
Код абітурієнта	AKodAbiturienta	integer	4	Unique

Зауваження

Первинний ключ і зовнішні ключі внести в перші рядки таблиць, усю решту атрибутів описати послідовно. Об’єднати таблиці за допомогою ліній від первинних ключів батьківських до зовнішніх дочірніх таблиць. Якщо таблиця має первинні і зовнішні ключі, то на схемі винести їх в одну лінію (Рис. 8, Додаток Б).

Рис. 8. Приклад ліній зв’язку між сутностями

На основі правил перетворення ІМПО в ДМБД у таблиці внесені зовнішні ключі. У головні таблиці внесені первинні ключі підлеглий таблиць, які в головній таблиці стали зовнішніми ключами.

На схемі ДМБД первинні й зовнішні ключі винести в одну лінію квадратів з позначеннями ПК і ВК.

На основі схеми ДМБД можна створити скрипт бази даних мовою SQL.

Додаток Б

Приклад схеми даталогічної моделі для В30

Питання для самоконтролю

1.  Що таке нормалізація?

2.  Перелічити властивості 3NF.

3.  Що таке обмеження даних?

4.  Що таке предметна область?

5.  Що таке інфологічна модель?

6.  Дайте характеристику типам зв'язків між таблицями.

7.  Якими геометричними фігурами позначаються сутності й зв'язки на схемі інфологичної моделі предметної області?

8.  Як створити даталогічну модель?

9.  Що означає обмеження Not Null?

10.  Що означає обмеження Unique?

6. Створення проекту в Power Designer

Етапи створення проекту, властивості моделі

З метою автоматизації процесу проектування БД використовується Power Designer. Програма дозволяє уникнути помилок при переході від ІМПО до ДМБД, і спростити створення скрипта БД мовою SQL. ІМПО – концептуальна модель (КМ).

Для КМ визначаються сутності і їхні атрибути, вказуються первинні ключі й обов'язковість для заповнення атрибута; визначаються зв'язки і їхні характеристики.

Створену КМ перетворять у фізичну модель (ФМ) на основі обраної СУБД. На кожному етапі проектування можна виносити доповнення. Так само можна робити зворотні перетворення ФМ у КМ. На основі ФМ автоматично створюється скрипт БД.

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

Power Designer - CASE засіб для створення проектів БД. Запустити Power Designer, вибрати команду File -> New (рис. 3_1) . Відкривається вікно програми з областю відображення моделі, меню, панеллю інструментів і панеллю елементів моделі.

Рис.­3_1 «Створення нового проекту»

Властивості моделі

Dictionary -> Model Properties.

Задати:

-  найменування й ідентифікатор проекту;

-  найменування й ідентифікатор моделі.

Можна вказати: автора моделі, використовуваний мова, версію моделі, увести кратний і докладний опис, анотацію.

Законспектуйте етапи створення інфологічної моделі даних

Створення концептуальної (інфологичної) моделі

Сутність - Entity – прямокутник (рис. 3_2).

Рис. 3_2 «Створення концептуальної моделі»

Установити в області елемент. Двійне клацання на зображенні прямокутника -> відкриється вікно Entity Properties (рис. 3_3) властивості сутності.

Рис. ­3_3 «Діалогове вікно Властивості сутності»

На вкладці General (рис. 3_4) ввести найменування, ідентифікатори й короткий опис сутності. При сумісній розробці моделі на вкладці Notes уводиться докладний опис, а на вкладці General в області Comments уводяться зауваження й коментарі із приводу сутності.

Рис. 3_4 «Вкладка General»

При натисканні на вкладку Atributes (рис. 3_5) показується вікно для уведення атрибутів сутності.

Рис. 3_5 «Вкладка Atributes»

При необхідності можна задати бізнес-правила для сутності, нажавши кнопку Rules. Для атрибута вводимо найменування (Name), ідентифікатор (Code), тип даних (Data Type), обов'язковість заповнення поля (M, mandatory), замітка про первинний ключ (P - Primary key).

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

Для створення доменна виконати команду:

Model -> Domain -> відкриється hist of Domeins

Типи даних

Рис. 3_6 «Вікно типів даних»

Наведемо деякі приклади використання типів даних:

Integer, Short integer, long integer, Bytе – цілі числа

Decimal – для введення грошових даних.

Charcters, Variable characters – текстові дані

Date – дата.

Запишіть тиии з зв'язків між сутностями

Зв'язки між сутностями

Relationship (зв'язок)

Обрати об'єкт і встановити зв'язок між сутностями. Подвійне клацання по зв'язку – відкриється вікно Relationship Properties.

Вкладка General, вказується найменування, ідентифікатор, коментарії.

Вкладка Detail, вказується тип зв'язку і її параметри.

Типи:

one – one – (1:1) один до одному

one – many – (1: M) один до многим

many - one - (M:1) багато хто до одному

many - many (M:M) багато до многим

Параметри:

Mandatory – обов'язковий клас приналежності

mondatory + без mondatory

Рис. 3_7 «Зв'язку між сутностями»

Перевірка моделі

Tools -> Check model (F4) – перевірка моделі на логічні помилки.

Створення фізичної (даталогичної) моделі

Загальні принципи перетворення:

-  сутність перетворюєтся в таблицю; ім'я сутності - ім'я таблиці;

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

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

-  зв'язки стають зовнішніми ключами;

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

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

Tools -> General Physical Data Model...

Вибираємо СУБД, назва моделі й ідентифікатор.

Питання для самоконтролю

1.  Перечислити властивості СУБД?

2.  Power Designer, для чого він використовується?

3.  Як створити новий проект в Power Designer?

4.  Як переглянути властивості проекту. Які данні можливо вказати у властивостях?

5.  Що таке домен?

6.  Назвіть основні типи даних?

7.  Які типи зв’язку існують між сутностями?

8.  Як перевірити модель на логічні помилки?

9.  Які загальні принципи перетворення інфологічної моделі в фізичну?