Інформаційна система з обліку нарахування заробітної плати працівникам управління Державного казначейства (стр. 11 из 11)

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

Кожен зв'язок може мати одну з двох модальностей зв'язки:

Мал. 6

Модальність "може" означає, що екземпляр однієї суті може бути пов'язаний з одним або декількома екземплярами іншої суті, а може бути і не пов'язаний ні з одним екземпляром.

Модальність "винен" означає, що екземпляр однієї суті зобов'язаний бути зв'язаний не менше чим з одним екземпляром іншої суті.

Зв'язок може мати різну модальність з різних кінців (як на Мал. 4).

Описаний графічний синтаксис дозволяє однозначно читати діаграми, користуючись наступною схемою

побудови фраз: <Кожен екземпляр СУТІ 1> <МОДАЛЬНІСТЬ ЗВ'ЯЗКУ> <НАЙМЕНУВАННЯ ЗВ'ЯЗКУ> <ТИП ЗВ'ЯЗКУ>

<екземпляр СУТІ 2>.

Кожен зв'язок може бути прочитаний як зліва направо, так і справа наліво. Зв'язок на Мал. 4 читається так:

Зліва направо: "кожен співробітник може мати декілька дітей".

Справа наліво: "Кожна дитина зобов'язана належати рівно одному співробітникові".

Приклад розробки простій ER-моделі

При розробці ER-моделей ми повинні отримати наступну інформацію про наочну область:

1. Список суті наочної області.

2. Список атрибутів суті.

3. Опис взаємозв'язків між суттю.

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

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

Наприклад, в ході бесіди з менеджером з продажу, з'ясувалося, що він (менеджер) вважає, що проектована система повинна виконувати наступні дії:

• Зберігати інформацію про покупців.

• Друкувати накладні на відпущені товари.

• Стежити за наявністю товарів на складі.

Виділимо всі іменники в цих пропозиціях - це будуть потенційні кандидати на суть і атрибути, і проаналізуємо їх (незрозумілі терміни виділятимемо знаком питання):

• Покупець - явний кандидат на суть.

• Накладна - явний кандидат на суть.

• Товар - явний кандидат на суть

• (?)Склад - а взагалі, скільки складів має фірма? Якщо декілька, то це буде кандидатом на нову суть.

• (?)Наявність товару – це, швидше за все, атрибут, але атрибут якої суті?

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

Мал. 7

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

Куди помістити суть "Накладна" і "Склад" і з чим їх зв'язати? Запитаємо себе, яка зв'язана ця суть між собою і з суттю "Покупець" і "Товар"? Покупці купують товари, отримуючи при цьому накладні, до яких внесені дані про кількість і ціну купленого товару. Кожен покупець може отримати декілька накладних. Кожна накладна зобов'язана виписуватися на одного покупця. Кожна накладна зобов'язана містити декілька товарів (не буває порожніх накладних). Кожен товар, у свою чергу, може бути проданий декільком покупцям через декілька накладних. Крім того, кожна накладна повинна бути виписана з певного складу, і з будь-якого складу може бути виписано багато накладних. Таким чином, після уточнення, діаграма виглядатиме таким чином:

Мал. 8

Пора подумати про атрибути суті. Розмовляючи із співробітниками фірми, ми з'ясували наступне:

• Кожен покупець є юридичною особою і має найменування, адресу, банківські реквізити.

• Кожен товар має найменування, ціну, а також характеризується одиницями вимірювання.

• Кожна накладна має унікальний номер, дату виписки, список товарів з кількостями і цінами, а також загальну суму накладної. Накладна виписується з певного складу і на певного покупця.

• Кожен склад має своє найменування.

• Знову випишемо всі іменники, які будуть потенційними атрибутами, і проаналізуємо їх:

• Юридична особа - термін риторичний, ми не працюємо з фізичними особами. Не звертаємо уваги.

• Найменування покупця - явна характеристика покупця.

• Адреса - явна характеристика покупця.

• Банківські реквізити - явна характеристика покупця.

• Найменування товару - явна характеристика товару.

• (?)Ціна товару - схоже, що це характеристика товару. Чи відрізняється ця характеристика від ціни в накладній?

• Одиниця вимірювання - явна характеристика товару.

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

• Дата накладної - явна характеристика накладної.

• (?)Список товарів в накладній - список не може бути атрибутом. Ймовірно, потрібно виділити цей список в окрему суть.

• (?)Кількість товару в накладній - це явна характеристика, але характеристика чого? Це характеристика не просто "товару", а "товару в накладній".

• (?)Ціна товару в накладній - знову ж таки це повинна бути не просто характеристика товару, а характеристика товару в накладній.

• Сума накладної - явна характеристика накладної. Ця характеристика не є незалежною. Сума накладної рівна сумі вартостей всіх товарів, що входять в накладну.

• Найменування складу - явна характеристика складу.

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

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

Точно також поступимо із зв'язком, що сполучає суть "Склад" і "Товар". Введемо додаткову суть "Товар на складі". Атрибутом цієї суті буде "Кількість товару на складі". Таким чином, товар числитиметься на будь-якому складі і кількість його на кожному складі буде своє.

Тепер можна внести все це до діаграми:

Мал. 9

Концептуальні і фізичні ER-моделі

Розроблений вище приклад ER-діаграми є прикладом концептуальної діаграми. Це означає, що діаграма не враховує особливості конкретної СУБД. По даній концептуальній діаграмі можна побудувати фізичну діаграму, яка вже враховуватимуться такі особливості СУБД, як допустимі типи і найменування полий і таблиць, обмеження цілісності і т.п. Фізичний варіант діаграми, приведеної на Мал. 9 може виглядати, наприклад, таким чином:

Мал. 10

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

Легко відмітити, що отримані таблиці відразу знаходяться в 3НФ.

Висновки

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

Як інструмент семантичного моделювання використовуються різні варіанти діаграм суть-зв'язок (ER - Entity-Relationship).

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

Розрізняють концептуальні і фізичні ER-діаграми. Концептуальні діаграми не враховують особливостей конкретних СУБД. Фізичні діаграми будуються по концептуальних і є прообразом конкретної бази даних. Суть, визначена в концептуальній діаграмі стають таблицями, атрибути стають колонками таблиць (при цьому враховуються допустимі для даної СУБД типи даних і найменування стовпців), зв'язки реалізуються шляхом міграції ключових атрибутів батьківської суті і створення зовнішніх ключів.

При правильному визначенні суті, отримані таблиці відразу знаходитимуться в 3НФ.

Основна гідність методу полягає в тому, модель будується методом послідовних уточнень первинних діаграм.

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