• 2.1. Поняття предметної області
• 2.2 Інформаційна модель предметної області бази даних
• 2.3 Концептуальна модель предметної області
• 2.4 Функціональна модель предметної області
  • 2.4.1. Бізнес-модель процесів.
  • 2.4.2. Модель потоку даних.
  • 2.4.3. Модель життєвого циклу.
  • 2.4.4. Набір специфікацій функцій системи (вимог), опис функцій через сутності і атрибути, бізнес-правила.

2.1. Поняття предметної області

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

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

Прикладами сутностей (з погляду ІС) або об'єктів (з погляду зовнішнього світу) є окремий студент, група студентів, аудиторія, час занять, слова, числа, символи. Звичайно вважається, що бути об'єктом - означає бути дискретним і помітним.

З об'єктами пов'язано дві проблеми: ідентифікація й адекватний опис. Для ідентифікації використовують ім'я. Використовується тільки вказівна функція імені. Ім'я - це прямий спосіб ідентифікації об'єкта. До непрямих способів ідентифікації об'єкта відносять визначення об'єкта через його властивості (характеристики або ознаки).

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

Методи математичної логіки дозволяють формалізувати ці твердження і подати їх у вигляді, придатному для аналізу.

На рис. 2.1 наведений один із підходів до класифікації ситуацій у рамках ПО.

Рисунок 2.1 Класифікація ситуацій ПО

 

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

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

2.2 Інформаційна модель предметної області бази даних

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

Інформаційна модель ПО БД містить такі основні конструкції:

• діаграми "сутність-зв'язок" (Entity - Relationship Diagrams);
• визначення сутностей;
• унікальні ідентифікатори сутностей;
• визначення атрибутів сутностей;
• відношення між сутностями;
• супертипи й підтипи.

Елементи інформаційної моделі даних ПО є вхідними даними для вирішення завдання проектування БД - створення логічної моделі даних.

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

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

Одним з основних комп'ютерних засобів розпізнавання сутностей у базі даних є присвоєння сутностям ідентифікаторів. Часто ідентифікатор сутності називають ключем. Завдання вибору ідентифікатора сутності є суб'єктивним завданням. Оскільки сутність визначається набором своїх атрибутів, то для кожної сутності доцільно виділити таку підмножину атрибутів, що однозначно ідентифікує дану сутність.

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

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

Кожен атрибут сутності має домен. Домен - це вираз, який визначає значення, дозволені для даного атрибута. Іншими словами, домен - це область значень атрибута. Розробник БД повинен проконтролювати, щоб в інформаційній моделі ПО для кожного атрибута сутностей був визначений домен.

Сутності не існують окремо одна від одної. Між ними є реальні відношення, і вони повинні бути відбиті в інформаційній моделі ПО. При виділенні відношень акцент робиться на фіксацію зв'язків і їх характеристик. Відношення (зв'язок) являє собою з'єднання (взаємовідношення) між двома або більше сутностями. Кожен зв'язок реалізується через значення атрибутів сутностей. Звичайно зв'язок позначається дієсловом. Кожен зв'язок також повинен мати свій унікальний ідентифікатор зв'язку.

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

Зв'язки характеризуються ступенем зв'язку і класом належності сутності до зв'язку. Ступінь (потужність) зв'язку - це відношення числа сутностей, що беруть участь в утворенні зв'язку. Існують такі типи: "один-до-одного", "один-до-множини", "множина-до-множини".

Типовою формою документування інформаційної моделі ПО є діаграми "сутність-зв'язок" (ER-діаграми), яка дозволяє графічно представити всі елементи інформаційної моделі згідно із простим, інтуїтивно зрозумілим, але чітко визначеним правилом - нотацією. Далі ми будемо користуватися умовними позначеннями, прийнятими в методології інформаційного проектування.

Сутність на ER-діаграмі наводиться прямокутником з ім'ям у верхній частині. Будемо використовувати англійські слова для іменування елементів моделі.

Рисунок 2.2 Подання сутності Student (студент) на ER-діаграмі з атрибутами й унікальним ідентифікатором сутності

У прямокутнику перераховуються атрибути сутності, при цьому атрибути, що становлять унікальний ідентифікатор сутності, підкреслюються.

Домени призначаються аналітиками й фіксуються в спеціальному документі - словнику даних (Data Dictionary). На стадіях розроблення логічної й фізичної моделей реляційної БД домени уточнюються у сутностях на ER-діаграмі.

Розробник БД повинен ретельно вивчити домени кожного атрибута з погляду на можливість їх реалізації у СКБД.

Рисунок 2.3 Візуалізація визначення доменів атрибутів на ER-діаграмі при створенні фізичної моделі реляційної БД

Відношення (зв'язок) сутностей на ER-діаграмі зображується лінією, що з'єднує ці сутності. Ступінь зв'язку зображується за допомогою символа "пташина лапка", що вказує на те, що у зв'язку бере участь багато (N) екземплярів сутності, і одинарною горизонтальною рискою, що вказує на те, що у зв'язку бере участь один екземпляр сутності.

Відношення читається вздовж лінії або ліворуч праворуч, або праворуч–ліворуч. На рис. 2.4 наведене таке відношення: кожен студент повинен бути зареєстрований за певною групою, в кожній групі може бути зареєстровано один або більше студентів.

Рисунок 2.4 Подання відношення між двома сутностями на ER-діаграмі

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

• модель життєвого циклу сутності;
• набір специфікацій функцій системи (вимоги);
• опис функцій системи через сутності й атрибути;
• бізнесу-правила, які реалізують функції.

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

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

• контекстна діаграма;
• діаграма декомпозиції;
• діаграма дерева вузлів;
• діаграма «тільки для експозиції».

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

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

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

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

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

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

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

• джерела даних (Data Source);
• процеси обробки даних (Data Process);
• сховища даних (Data Store);
• потоки даних (Data Flow).

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

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

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

• подати систему з точки зору джерел та користувачів даних;
• відобразити переміщення даних в процесі обробки;
• відобразити зовнішні механізми передачі даних;
• відобразити метод отримання даних.

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

• сховища даних, що дозволить на наступних етапах проектування обґрунтовано визначити кількість БД для ІС;
• прийняті схеми перетворення інформації, що дозволить в подальшому скласти специфікації додатків.

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

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

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

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

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

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

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