6. Приклад створення логічної моделі даних

Пакет ВР\уіп дозволяє будувати і представляти логічну модель даних на трьох рівнях:

• Модель сутність - зв'язок (БРЕ)).

• Модель даних, засновану на ключах.

• Повну атрибутивну модель.

Модель сутність - зв'язок (БРР) являє собою модель даних у за­гальному вигляді. У ній показані тільки сутності й головні зв'язки між ними. Така модель не деталізована і достатня для аналізу систем у зага­льному вигляді, для презентації системи, обговорення структури даних з експертами.

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

Повна атрибутивна модель - це найбільш повна модель, що дає повну інформацію по структурі даних, включає всі сутності, ключі, ат­рибути сутностей, зв'язки між ними. Вона представляє модель у третій нормальній формі (3НФ).

Пакет ВР\уіп має механізми переходу і може представити повну атрибутивну модель на всіх трьох рівнях, або будувати моделі , напри­клад, на рівні діаграми сутність - зв'язок:

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

Перший крок побудови моделі - виділення сутностей. У нас сут­ності такі: тролейбус, водій, маршрут, випуск, маршрутний листок.

Другий крок - встановлення зв'язків між сутностями.

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

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

Між маршрутом і випуском також встановлюється ідентифіка­ційний зв' язок. Випуск повинен повністю ідентифікувати і маршрут, на якому він здійснюється.

Зв'язок між випуском і маршрутним листком також ідентифіка­ційний, оскільки маршрутний листок повинен ідентифікувати не тільки водія і тролейбус, але й випуск на певному маршруті.

На цьому кроці вже можна розпочинати побудову моделі за до­помогою комп'ютера. Вибір рівня моделі може бути довільним: чи рі­вень сутність - зв'язок, чи модель, побудована на ключах, чи повна ат­рибутивна модель. На кожному рівні програмний пакет дозволяє вводи­ти всі дані в модель, тільки відображає на екрані дисплея дані, що від­носяться до встановленого рівня. Перемикання рівнів моделі здійсню­ється за допомогою панелі інструментів, показаної на рис. 68. У даному випадку рекомендується встановлювати рівень сутність - зв'язок і по­будувати найбільш просту модель, ввівши в неї тільки сутності й вста­новивши зв' язки між ними. Панель інструментів, яка це дозволяє зроби­ти, показано на рис. 69.

Порядок побудови такий. Вибирають інструмент сутностей і вво­дять на модель сутності. Використовуючи контекстне меню, сутностям присвоюють імена. Потім обирають інструмент встановлення потрібно­го типу зв'язку і будують зв'язок за допомогою маніпулятора "мишки" від батьківської до дочірньої сутності. Побудована модель на рівні сут­ність - зв'язок має вигляд, показаний на рис. 70.

Третій крок - виділення атрибутів сутностей та визначення клю­чових атрибутів. Нижче записано атрибути кожної сутності, які автори вважають потрібним ввести. Ключові атрибути підкреслені.

Тролейбус: номер тролейбуса, тип, дата виготовлення, дата ремо­нту, пробіг в кілометрах.

Водій: тарифний номер, прізвище, ім'я, по батькові, дата прийн­яття на роботу, класність, номер бригад.

Маршрут: номер маршруту, довжина, довжина холостого пробі­гу, початкова зупинка, кінцева зупинка, кількість зупинок, обмеження швидкості.

Випуск: номер випуску, перервний чи ні, нічний чи денний, огля­довий ТОЇ чи ні, свято чи будень.

Маршрутний листок: номер листка, дата, час випуску, номер ви­пуску, водій, час випуску, час прибуття, кількість виконаних рейсів.

Для введення атрибутів бажано переключити модель на рівень повної атрибутивної моделі (див. рис. 68, другий зліва інструмент). Пе­ред вводом атрибутів сутностей бажано вилучити зв' язки між сутнос-тями, ввести атрибути і після цього повторно встановити зв' язки між сутностями. Це пов' язане з тим, що коли встановлені зв' язки, то відбу­вається міграція атрибутів і під час вводу атрибутів можна допустити помилки.

Для введення атрибутів у контекстному меню сутності вибира­ється редактор атрибутів (Attribute Editor...) (див. рис. 71).

Після вводу сутностей необхідно вибрати ключову сутність і від­мітити її як первинний ключ, встановивши позначку Primary Key. Сут­ності з введеними атрибутами показані на рис. 73.

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

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

Після вводу атрибутів і зв' язків одержана в нашому прикладі по­вна атрибутивна модель показана на рис. 74.

 

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

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

Сутності у фізичній моделі стають таблицями баз даних. У фізи­чну модель, як видно з рис. 75, ввійшли типи полів і їх розміри, вказані в дужках. Типи полів бажано задати під час вводу атрибутів у вікні вво­ду і редагування атрибутів сутностей (рис. 72). Ці типи в реальних фізи­чних моделях СКБД відповідатимуть типам полів баз даних.

Подальше використання логічної моделі залежить від цілей мо­делювання. Якщо ціллю є аналіз існуючої системи чи системи, що прое­ктується, то достатньо мати модель на одному з рівнів логічної моделі. Якщо ціллю є безпосереднє проектування, то можна виконати подальші кроки і згенерувати коди фізичної моделі в одній з бажаних СКБД (див.. рис. 67), а потім використовувати як реальну фізичну систему баз даних.

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