Побудова та опис діаграми «Сутність-зв» язок

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

Базовими компонентами для побудови такої моделі даних є сутність, атрибут і зв’язок. Отже визначимо для нашої предметної області базові компоненти.

Сутність — це збірне поняття, деяка абстракція реально існуючого об'єкта, процесу, явища чи деякого уявлення про об'єкт. Проаналізувавши у попередніх розділах та підрозділах предметну область «підприємство» можна визначити наступні сутності: «Картка абонента», «Послуга», «Тариф», «Пільга», «Лічильник», «Показник лічильника», «Картка розрахунків», «Квитанція». Приклад вигляду сутності «Картка абонента» продемонстровано на рисунку «Рис. 2.1».

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

Розглянемо окремо кожну сутність та визначимо її атрибути.

Сутність «Картка абонента» потрібна для запису персональних даних користувача водопостачальних послуг. Перерахуємо на рисунку «Рис. 2.2» атрибути даної сутності:

Сутність «Тариф» потрібна для запису цін водопостачальних послуг для різних користувачів. Перерахуємо на рисунку «Рис. 2.3» атрибути даної сутності:

Сутність «Послуга» потрібна для запису типів водопостачальних послуг, які може отримувати користувач. Перерахуємо на рисунку «Рис. 2.4» атрибути даної сутності:

Сутність «Пільга» потрібна для запису видів та цін пільг, які може мати користувач водопостачальних послуг. Перерахуємо на рисунку «Рис. 2.5» атрибути даної сутності:

Сутність «Лічильник» потрібна для запису інформації про лічильники кожного споживача водопостачальних послуг. Перерахуємо на рисунку «Рис. 2.6» атрибути даної сутності:

Сутність «Показник лічильника» потрібна для запису показань лічильників, знятих кожного місяця та для розрахунку значення показань для виведення нарахувань за використані послуги. Перерахуємо на рисунку «Рис. 2.7» атрибути даної сутності:

Сутність «Картка розрахунків» потрібна для запису розрахунків суми нарахувань за спожиті користувачем водопостачальні послуги. Перерахуємо на рисунку «Рис. 2.8» атрибути даної сутності:

Сутність «Квитанція» потрібна для запису нарахувань та оплат користувача водопостачальних послуг. Перерахуємо на рисунку «Рис. 2.9» атрибути даної сутності:

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

На рисунку 2.10 зображено зв’язки між усіма сутностями обраної предметної області.

Розглянемо кожен зв’язок окремо.

Зв’язок між сутностями «Картка абонента» та «Пільга»:

Зі зв’язку на рисунку 2.11 визначаємо, що сутність «Пільга» є батьківською, а сутність «Картка абонента» дочірньою. Отже кожен користувач може мати певну пільгу, а кожна пільга може належати декільком користувачам.

Зв’язок між сутностями «Картка абонента» та «Лічильник»:

Зі зв’язку на рисунку 2.12 визначаємо, що сутність «Картка абонента» є батьківською, а сутність «Лічильник» дочірньою. Отже кожен користувач може мати декілька лічильників, а кожен лічильник може належати одному користувачу.

Зв’язок між сутностями «Картка абонента» та «Тариф»:

Зі зв’язку на рисунку 2.13 визначаємо, що сутність «Тариф» є батьківською, а сутність «Картка абонента» дочірньою. Отже кожен тариф може визначати тарифікацію для декількох користувачів, а кожен користувач може обслуговуватися лише по одному тарифу.

Зв’язок між сутностями «Картка абонента» та «Квитанція»:

Зі зв’язку на рисунку 2.14 визначаємо, що сутність «Картка абонента» є батьківською, а сутність «Квитанція» дочірньою. Отже кожен користувач може мати декілька квитанцій, а кожен квитанція може належати лише по одному користувачу.

Зв’язок між сутностями «Картка абонента» та «Картка розрахунків»:

Зі зв’язку на рисунку 2.15 визначаємо, що сутність «Картка абонента» є батьківською, а сутність «Картка розрахунків» дочірньою. Отже кожен користувач може надавати ID для декількох розрахунків, а кожна картка розрахунків може розраховувати лише для одного користувача.

Зв’язок між сутностями «Лічильник» та «Показник лічильника»:

Зі зв’язку на рисунку 2.16 визначаємо, що сутність «Лічильник» є батьківською, а сутність «Показник лічильника» дочірньою. Отже лічильник може мати декілька показань, а кожен показник лічильника може належати лише одному лічильнику.

Зв’язок між сутностями «Показник лічильника» та «Картка розрахунків»:

Зі зв’язку на рисунку 2.17 визначаємо, що сутність «Показник лічильника» є батьківською, а сутність «Картка розрахунків» дочірньою. Отже кожен показник лічильника може надавати декілька значень показань для розрахунку, а кожна картка розрахунку може приймати лише одне значення показань для розрахунку.

Зв’язок між сутностями «Квитанція» та «Картка розрахунків»:

Зі зв’язку на рисунку 2.18 визначаємо, що сутність «Картка розрахунків» є батьківською, а сутність «Квитанція» дочірньою. Отже кожна картка розрахунку може розраховувати для декількох квитанцій, а кожна квитанція може приймати значення лише з одної картки розрахунків.

Зв’язок між сутностями «Послуга» та «Квитанція»:

Зі зв’язку на рисунку 2.19 визначаємо, що сутність «Послуга» є батьківською, а сутність «Квитанція» дочірньою. Отже кожна послуга може надавати своє ID для декількох квитанція, а кожна квитанція може приймати ID лише однієї послуги. Зв’язок між сутностями «Тариф» та «Послуга»:

Зі зв’язку на рисунку 2.20 визначаємо, що сутність «Послуга» є батьківською, а сутність «Тариф» дочірньою. Отже кожна послуга може надавати своє ID для декількох тарифів, а кожен тариф може привласнювати ціну лише одній послузі.

Таким чином визначивши сутності, їх атрибути та зв’язки отримуємо логічну модель для нашої предметної області. Схема логічної моделі приведена у додатку, А (Рис. А.1).

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

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

СУБД MySQL — це система керування реляційними базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування. MySQL надає багатий набір функціональних можливостей, які підтримують безпечне середовище для зберігання, обслуговування і отримання даних. Схема фізичної моделі для СУБД MySQL приведена у додатку, А (Рис. А.3).

СУБД Microsoft SQL Server — одна з найбільш потужних СУБД архітектури клієнт-сервер. Ця СУБД дозволяє задовольняти такі вимоги, що пред’являються до систем розподіленої обробки даних, як тиражування даних, паралельна обробка, підтримка великих баз даних на відносно недорогих апаратних платформах при збереженні простоти управління і використання. Схема фізичної моделі для СУБД MS SQL Server приведена у додатку, А (Рис. А.4).

Виконавши усі необхідні пункти для створення проекту бази даних у підсумку згенеруємо стандартний звіт Table Reports-Table-Physical Properties з переліком таблиць моделі та їх стовпців за допомогою генератора звітів CASE-засобу CA ERwin Data Modeler. Звіт наведено у додатку Б (Таблиця Б.1).