Лекція Розробка ER-діаграми для аналізованої предметної галузі
Зміст лекції: методи розробки ER-діаграм.
Мета лекції: розробити ER-діаграми для аналізованої предметної області.
Основними завданнями концептуального проектування є визначення предметної області системи та формування погляду програмне забезпечення з позицій майбутніх користувачів бази даних. Як приклад спроектуємо концептуальну модель системи, призначеної для зберігання інформації про книги та сфери знань, представлених у бібліотеці. Опис предметної області наведено раніше (лекція 4).
Виділимо основні об'єктні множини. Насамперед існує об'єктна безліч КНИГИ, кожна книга має унікальний шифр, який є її ключем, і ряд атрибутів, які взяті з опису предметної області. Безліч екземплярів множини визначає безліч книг, які зберігаються в бібліотеці. Кожен екземпляр множини КНИГИ відповідає не конкретної книги, що стоїть на полиці, а опису деякої книги, яке дається зазвичай у предметному каталозі бібліотеці. Кожна книга може бути присутня в кількох примірниках, і це саме ті конкретні книги, які стоять на полицях бібліотеки. Для того щоб відобразити це, ми повинні ввести об'єктну множину ЕКЗЕМПЛЯРИ, яка міститиме описи всіх екземплярів книг, що зберігаються в бібліотеці. Кожен екземпляр сутності ЕКЗЕМПЛЯРИ відповідає конкретній книзі на полиці. Кожен екземпляр має унікальний інвентарний номер, який однозначно визначає конкретну книгу. Крім того, кожен екземпляр книги може бути або в бібліотеці, або на руках у деякого читача, і в останньому випадку для даного екземпляра вказуються додатково дата взяття книги читачем і дата очікуваного повернення книги. Нагадаємо, що зв'язки буваютьобов'язковііфакультативні. Якщо об'єкт одного типу виявляється за потребою пов'язаним з об'єктом іншого типу, між цими типами об'єктів існує обов'язковий зв'язок. Інакше зв'язок є факультативним.
Між сутностями КНИГИ і ЕКЗЕМПЛЯРИ існує зв'язок «один-багатьом» (1:М), обов'язковий з двох сторін. Чим визначається цей тип зв'язку? Ми можемо припустити, що кожна книга може бути присутня в бібліотеці в декількох примірниках, тому зв'язок «один-багатьом». При цьому якщо в бібліотеці немає жодного екземпляра цієї книги, то ми не зберігатимемо її опис, тому якщо книга описана по суті КНИГИ, то принаймні один екземпляр цієї книги присутній у бібліотеці. Це означає, що з боку книги зв'язок є обов'язковим. Що стосується сутності екземпляри, то не може існувати в бібліотеці жодного екземпляра, який би не ставився до конкретної книги, тому і з боку екземпляри зв'язок теж обов'язковий.
З опису предметної області ми знаємо, кожен читач може тримати кілька екземплярів книг. Для відображення цієї ситуації нам треба провести зв'язок між сутностями ЧИТАЧІ та ЕКЗЕМПЛЯРИ. А чому не між сутностями ЧИТАЧІ та КНИГИ? Тому що читач бере з бібліотеки конкретний екземпляр конкретної книги, а не книжку. А як дізнатися, яка книга у даного читача? А це можна буде дізнатися щодо додаткового зв'язку між сутностями ЕКЗЕМПЛЯРИ та КНИГИ, і цей зв'язок кожному примірнику ставить у відповідність одну книгу, тому ми в будь-який момент можемо однозначно визначити, які книги знаходяться на руках у читача, хоча зв'язуємо з читачем лише інвентарні номери взятих книг. Між сутностями ЧИТАЧІ ТА ЕКЗЕМПЛЯРИ встановлено зв'язок «один-багатьом», і при цьому він необов'язкова із двох сторін. Читач на даний момент може не тримати жодної книги на руках, а з іншого боку, даний екземпляр книги може не знаходитися в жодного читача, а просто стояти на полиці в бібліотеці.
З опису предметної області нам відомо, що кожна книга може містити відомості з кількох областей знань, а також у бібліотеці може бути безліч книг, що належать до однієї і тієї ж області знань, тому нам необхідно встановити між СИСТЕМНИЙ_КАТАЛОГ і КНИГИ зв'язок «багато-ко- багатьом», обов'язкову з обох сторін. Дійсно, у системному каталозі не повинно бути такої галузі знань, відомості по якій не представлені в жодній книзі нашої бібліотеки, неприємне було б безглуздо. І навпаки, кожна книга має бути віднесена до однієї чи кількох областей знань для того, щоб читач міг її швидше знайти. Це ставлення формуєскладове об'єктне безліч, для зручності таким відносинам іноді дають об'єктні іменники - іменники (додатково до імені відношення). Назвемо це безліч ВІДОМОСТІ. Графічно складова множина позначається прямокутником, намальованим навколо відношення та об'єктних множин, що беруть у ньому участь (рисунок 7.1).
Спроектуємо концептуальну модель системи, що призначена для зберігання інформації видавничої компанії (предметна область описана в лекції 4). Розробку моделі почнемо із виділення основних сутностей.
Малюнок 7.2 - ER-діаграма моделі видавничої компанії
Отже, діаграми сутність-зв'язок дозволяють використовувати наочні графічні позначення для моделювання сутностей та їх взаємозв'язків. Основна перевага методу полягає в тому, модельбудується шляхом послідовних уточнень початкових діаграм. Концептуальні діаграминевраховують особливості конкретних систем управління базами даних.
Лекція. Приклади концептуального моделювання
Зміст лекції: приклади концептуального проектування баз даних.
Мета лекції: вивчити на прикладах методи розробки концептуальних схем баз даних.
Як зазначалося, відносини можна як об'єкти, у разі вони називаються складовими об'єктними множинами. Більшість проблем бізнесу потребують використання складових об'єктів. Раніше в прикладах у всіх відносинах брали участь дві об'єктні множини (бінарнівідносини). Однак відношення може пов'язувати три і більше об'єктних множин (n-арнівідносини). Проілюструємо це прикладом.
Розглянемо досвід компанії, що займається міжнародною торгівлею товарами. Концепція компанії така: знайти у різних країнах виробників, чиї товари завжди задовольняють високим стандартам якості; знайти фірми, що реалізують товари; встановити ділові зв'язки між виробниками та продавцями, забезпечуючи останні товари, закуплені у вибраних виробників. Компанія має офіси в різних країнах; штат кожного офісу складається з торгових агентів та закупників.
Створимо концептуальну модель даних компанії. Компанія має клієнтів, торгових агентів, товарів, виробників цих товарів. Виділимо такі об'єкти: ТОВАР, КЛІЄНТ, ТОРГОВИЙ_АГЕНТ, ВИРОБНИК. Встановимо відповідні відносини між ними, як показано на малюнку 8.1:
Припустимо, що слід відстежувати кількість кожного товару, проданого кожному клієнту. Ми повинні приписати атрибут КІЛЬКІСТЬ одному з об'єктів. Якщо це буде атрибут об'єкта ТОВАР, то ми незможемо розрізняти кількість товару, проданого різним клієнтам, а якщо атрибут присвоїти об'єкту КЛІЄНТ, то зможемо розрізняти товари, продані клієнту. Тому, КІЛЬКІСТЬ - атрибутвідносиниміж товаром і клієнтом, а не товару або клієнта окремо. Отже, відношення «продан_кому»саме є об'єктним безліччю або складовим об'єктом, якому і приписується атрибут КІЛЬКІСТЬ (рисунок 8.2).
Малюнок 8.2 - Правильна модель відображення кількості продажів
Припустимо, що необхідно записувати кількість продажів кожного товару, проданого кожному клієнту в конкретний день. Тоді пов'язуємо відношення «продан_кому»з об'єктом ДАТА і приписуємо атрибут КІЛЬКІСТЬ цьому новому відношенню. Модель зручніше подати у вигляді одного тристороннього відношення (рисунок 8.3). Необхідно зважити, що серед об'єктів нашої моделі є виробники товарів. Відобразимо цей об'єкт на схемі. На схемі також позначені потужності відносин.
| * |
Малюнок 8.3 - Повна модель відстеження продажів
Для ілюстрації ще одного поняття концептуальному моделюванні, розглянемо наступний приклад. Будівельна компанія будує різні будівлі. Для всіх будівель потрібні різноманітні матеріали у різних кількостях. На різних етапах проекту працюють різні бригади (арматурників, мулярів, штукатурів тощо). При складанні графіка роботи компанія варіює склад бригад. Робітники призначаються до різних бригад відповідно до кваліфікації. Бригади складаються таким чином, як потрібно для конкретної будівлі. Для кожної бригади призначається бригадир. Робітник може очолювати одну бригаду та працювати в іншійпростим робітником. Створимо концептуальну модель даних, яка може забезпечити необхідною інформацією власника компанії. На малюнку 8.4 представлено відношення між будинками та матеріалами.
Потужність відношення між об'єктними множинами БУДІВЛІ і ТИП_МАТЕРІАЛА багатьом. Атрибут АДРЕСА відноситься тільки до безлічі БУДИНОК, може бути використаний як ключ, для ідентифікації конкретної будівлі. Прямокутник навколо відношення «вимагає»показує, що ми використовуємо це відношення як складову об'єктну множину. Цьому об'єктному безлічі надаємо атрибут КІЛЬКІСТЬ, елементами цієї множини будуть пари: будівля та тип матеріалу.
Важливо відзначити, що в цьому прикладі об'єктна множина ТИП_МАТЕРІАЛА єконцептуальний, а нефізичнийоб'єкт.Концептуальнийоб'єкт – об'єкт, що означає тип речей, тобто елементами цієї множини є абстрактні поняття. Тобто кожен елемент цієї множини означаєтипматеріалу, а не фізичний «шматок» матеріалу.Фізичнеоб'єктне безліч – об'єктне безліч, елементами якого є фізичні предмети. Таке поняття концептуального об'єкта, що протиставляється фізичному об'єкту, часто застосовується у концептуальному моделюванні даних. У раніше розглянутому прикладі про бібліотечну проблему в об'єктній множині «Книги» зберігаються відомості проконцептуальнікниги,фізичнікниги ж це копії, томи або, як прийнято в нашій моделі,екземплярикниг. Хоча читач може не розрізняти ці поняття, щоб вирішити, як моделювати дані, необхідно з'ясувати, яка інформація потрібна користувачеві бази даних.
Тепер покажемо формування бригад та призначення робітників та бригадирів. Ще один приклад концептуальногооб'єктної множини - ТИП_БРИГАДИ - це не конкретні бригади, а типи бригад (бригада арматурників, мулярів і т.д.). Відношення між будівлею та типом бригади представляє конкретну бригаду, призначену виконувати на даному будинку цей тип робіт. Це ставлення розглядатимемо як об'єкт, назвемо його БРИГАДА.
Для кожної бригади як елемента об'єктної множини БРИГАДА вибираються дні роботи. Тобто між БРИГАДА і ДАТА є відношення багатьом.
Далі представлено розподіл робітників та бригадирів за бригадами. Ставлення «є_бригадиром»має потужність «один-багатьом» т.к. у бригади один бригадир, але одна людина може очолювати кілька бригад.
Малюнок 8.5 – Модель формування бригад та бригадирів
На малюнку 8.6 представлено об'єднану діаграму, що представляє повну модель даних для будівельної компанії.
Малюнок 8.6 – Модель даних для будівельної компанії
Моделі, розглянуті вище, ґрунтувалися на інформації, закладеній у типах питань, які задають менеджери чи керуючі. Тому ці моделі є основою інформаційно-керуючих систем. Слід зазначити, що концептуальну модель можна вивести із форм звітів, які у ділових операціях.