Концептуальна модель предметної області

Діаграма «сутності - зв’язки» виступає засобом опису схеми бази даних на концептуальному рівні проектування. Метод був запропонований у 1976 році Пітером Пін Шань Ченом. На діаграмах концептуального рівня сутності зображуються прямокутниками, атрибути – еліпсами, зв’язки – ромбами.

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

 

 

Рис. 2.5 Фрагмент концептуальної моделі ПО на першому етапі

 

Успішність засвоєння матеріалів дисциплін контролюється заліковими заходами, які визначають бал кожного студента з певної дисципліни. Отже необхідно виділити окремо сутність Statement (успішність), яка буде відображати зв'язок між сутностями Subject та Student (рис. 2.6.).

 

Рис. 2.6. Фрагмент концептуальної моделі ПО на другому етапі

 

На діаграмі присутній один зв'язок «множина-до-множини», який є недопустимим в реляційній БД. Давайте проаналізуємо: кожен студент проходить контрольні заходи з декількох предметів і кожен предмет вивчається декількома студентами. Кожен студент навчається в одній групі і в кожній групі навчаються декілька студентів. Відомість на контрольний захід видається на групу студентів. Отже заміна сутності Student у зв’язку «отримують» на сутність Group вирішує конфліктну ситуацію. Кожен об’єкт БД має свої атрибути. Отже приходимо до такого вигляду фрагменту концептуальної діаграми ПО успішність, яка наведена на рис. 2.7.

Рис. 2.7. Фрагмент концептуальної моделі на третьому етапі

 

Взагалі, якщо досліджується достатньо об’ємна ПО, раціональним є розроблення декількох локальних концептуальних моделей при подальшому їх об’єднанні у більш складну загальну концептуальну модель. Локальні моделі формуються таким чином, щоб кількість об’єктів (сутностей) не перевищувала 6-7 штук.

 

Функціональна модель предметної області

Третім ключовим моментом створення ІС з метою автоматизації інформаційних процесів організації є аналіз функціональної взаємодії об'єктів автоматизації. Аналітики наводять результати у вигляді функціональної моделі ПО БД. Склад функціональної моделі істотно залежить від контексту конкретного ІТ-проекту і може бути представлений за допомогою досить широкого спектра документів у вигляді текстової і графічної інформації.

Визначимо функціональну модель ПО БД як сукупність деяких моделей, призначених для опису процесів обробки інформації. Будемо називати ці моделі конструкціями функціональної моделі. Нижче наведений перелік основних конструкцій функціональної моделі, які необхідні для виконання проектування реляційних БД.

Моделі процесів:

· бізнес-модель процесів (ієрархія функцій системи);

· модель потоку даних.

Моделі станів:

· модель життєвого циклу сутності;

· набір специфікацій функцій системи (вимоги);

· опис функцій системи через сутності й атрибути;

· бізнесу-правила, які реалізують функції.

Бізнес-модель процесів

Бізнес-модель процесів призначена для опису процесів і функцій системи в ПО БД. Частіш за все, бізнес-модель документується відповідно нотаціям IDEF0 і подається у вигляді сукупності ієрархічно впорядкованих та взіємопов’язаних діаграм. Діаграми містять такі компоненти:

· контекстна діаграма;

· діаграма декомпозиції;

· діаграма дерева вузлів;

· діаграма «тільки для експозиції».

Контекстна діаграма є вершиною ієрархічної структури діаграм і є узагальненим описом системи та її взаємодії з зовнішнім середовищем.

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

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

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

Основними елементами IDEF0-діаграм є роботи, вхідні ти вихідні параметри, керування, механізми та виклик. Приклади діаграм будуть наведені у наступній темі на прикладі аналізу процесу проектування бази даних.

Модель потоку даних

Модель потоку даних призначена для опису процесів переміщення даних в ПО БД і подається у вигляді діаграми потоку даних (Data Flow Diagram). Основними елементами діаграми є:

· джерела даних (Data Source);

· процеси обробки даних (Data Process);

· сховища даних (Data Store);

· потоки даних (Data Flow).

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

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

Діаграма потоку даних дозволяє:

· подати систему з точки зору джерел та користувачів даних;

· відобразити переміщення даних в процесі обробки;

· відобразити зовнішні механізми передачі даних;

· відобразити метод отримання даних.

Діаграма потоку даних надає проектувальнику інформацію про:

· сховища даних, що дозволить на наступних етапах проектування обґрунтовано визначити кількість БД для ІС;

· прийняті схеми перетворення інформації, що дозволить в подальшому скласти специфікації додатків.

Модель життєвого циклу

Модель життєвого циклу (ЖЦ) сутності призначена для опису зміни станів сутності та переходів між ними. Подається у вигляді діаграм ЖЦ сутності (Entity Lifecycle Diagram), які відображають напрямки переходу сутності з деякого початкового стану до кінцевого стану і події, що ініціюють зміни станів сутності. Модель ЖЦ також може бути подана у текстовому вигляді опису.

2.4.4. Набір специфікацій функцій системи (вимог), опис функцій через сутності і атрибути, бізнес-правила

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

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

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

Бізнес-правила подають конкретні вимоги та умови для функцій, які визначають поведінку даних, і використовуються для підтримки цілісності даних в БД.

 

Поняття структури даних