3 Методика логічного моделювання даних

3.1 Головні принципи моделювання даних на логічному рівні подання

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

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

Для стислості викладу матеріалу нижче замість термінів тип об'єкта, зв'язку та атрибута будуть використовуватися терміни об'єкт, зв'язок і атрибут.

3.1.1 Об'єкти

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

Кожному об'єкту привласнюється унікальне ім'я. Прикладами об'єктів у поданій на рис.3.1 ERD для підсистеми “Оперативно-диспетчерське управління” є "Добові дані за АГНКС" (AGNKS DAY), "Довідник АГНКС" (AGNKS), "Оперативні повідомлення" (CEH NEIGHBO). На схемах об'єкти зображуються у вигляді прямокутників із закругленими кутами (далі будемо називати їх комірками), що містять усередині власні імена.

Рисунок 3.1 – Фрагмент ERD для підсистеми “Оперативно-диспетчерське управління”

3.1.2 Зв'язки

Зв'язки є бінарними в тому розумінні, що вони завжди асоціюються тільки з двома об'єктами, або з одним об'єктом, зв'язаним із самим собою. У такий спосіб усі, виникаючі в процесі побудови моделі ситуації, мають бути зведені до цих двох випадків. Зв'язок завжди асоціюється з подіями, що відбуваються в об'єктах, які зв'язуються. Він подається на схемах або у вигляді лінії, що з'єднує два об'єкти, або у вигляді петлі, що з'єднує об'єкт із самим собою (рис. 3.2, 3.6, б).

Рисунок 3.2 – Позначення зв'язку між об'єктами

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

• ступінь, тобто вказівка на те, скільки (один або багато) екземплярів об'єкта на цьому кінці зв'язку може асоціюватися з екземпляром об'єкта на іншому кінці;

• обов’язковість, тобто вказівка на те, чи кожен екземпляр об'єкта на даному кінці зв'язку має завжди асоціюватися з екземпляром об'єкта на іншому кінці;

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

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

3.1.3 Ступінь зв'язку

Є три основні типи ступеня:

- один до одного; коли з одним екземпляром об'єкта асоціюється один екземпляр іншого об'єкта;

- один до багатьох; коли з одним екземпляром об'єкта асоціюється один чи більше екземплярів іншого об'єкта;

- багато до багатьох; коли з одним або більше екземплярів об'єкта асоціюється один або більше екземплярів іншого об'єкта.

Для подання на схемі поняття "багато" на відповідному кінці лінії зв'язку зображується розгалуження у вигляді так званої “воронячої лапки” (crow's foot). Її поява на кінці лінії означає , що один або більше екземплярів об'єкта на цьому кінці можуть асоціюватися з одним екземпляром об'єкта на іншому. Якщо реальна множина екземплярів відома і постійна, то це може бути відображено на схемі довільним позначенням.

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

3.1.4 Обов’язковість

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

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

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

3.1.5 Ідентифікатори зв'язку

Кожен кінець зв'язку має свій єдиний ідентифікатор, який складається з:

• імені предметного об'єкта, з якого він виходить;

• фрази-описувача зв'язку, за якою прямує;

• ім'я цільового об'єкта.

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

3.1.6 Фраза-описувач зв'язку

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

Фрази складаються так, щоб точно і ясно описати значення та зміст появи зв'язків на схемі. Фраза є частиною визначення об'єкта, що примикає до даного кінця зв’язку (рис. 3.3).

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

Кожна лінія зв'язку має бути придатною для читання з обох кінців як ясне, однозначне твердження. Твердження зв'язку включає в свій склад її обов’язковість, значення і ступінь. Його конструкція має такий вигляд:

• слово "кожен", за яким прямує;

• ім'я предметного об'єкта, за яким прямує;

• слова "має бути" чи "може бути", за якими прямує;

• фраза-описувач зв'язку, за якою прямує;

• слова "один і тільки один" або "один чи більш", за якими прямує;

• ім'я цільового об'єкта.

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

Рисунок 3.3 – Приклад зображення поіменованого зв'язку

Фрази, що описують лінії зв'язку, набувають особливої важливості там, де має місце кілька зв'язків між двома об'єктами (рис.3.4).

Рисунок 3.4 – Випадок двох зв’язків між об’єктами

3.1.7 Групи виключних зв'язків

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

Субтипи об’єктів. Зв'язки типу 1:1 можуть використовуватися у виключних групах для того, щоб дати базове уявлення субтипів об’єктів. Наприклад, для рис. 3.5, якщо читати від об'єкта: “Супертип об'єкта має зв'язки та атрибути , які є спільними для його субтипів, і водночас кожен субтип може мати власні зв'язки та атрибути”.

Рисунок 3.5 – Базове уявлення супер- та субтипів

3.1.8 Рекурсивні зв'язки

Існує дві основні ситуації, в яких зручно зображувати об'єкт зв'язаним із самим собою, тобто з рекурсивним зв'язком.

Ієрархія представляє структури, властиві організаційному керуванню на підприємствах.

Така структура зображена на рис. 3.6 та описується такими твердженнями:

“Кожний менеджер може бути відповідальним за одного чи більше менеджерів”.

“Кожний менеджер може бути відповідальним за одного і тільки одного менеджера”.

В цьому спрощеному зображенні обидва кінця лінії зв’язку мають бути необов’язковими. Це дозволяє головному менеджеру не звітувати перед іншими менеджерами, а молодшим – бути підлеглими тільки одному менеджеру (рис. 3.6, а). Ця ситуація може бути зображена у вигляді, що наведений на рис. 3.6, б; де рекурсія – це петля зі ступенем 1:m.

Рисунок 3.6 – Подання ієрархії організаційного керування

рекурсивним зв'язком

На рис. 3.7 наведено більш детальне зображення ієрархії, в якому використаний обов’язковий кінець лінії зв’язку.

Рисунок 3.7 – Більш детальне відображення ієрархії

Ця ситуація описується таким твердженням:

“Кожний менеджер має бути або відповідальним перед одним і тільки одним директором, або відповідальним перед одним і тільки одним менеджером”.

Мережа характеризується наявністю зв'язків типу m:n і найбільш часто виникає при описанні технології виробничих процесів. Будь-яка підмножина складальних одиниць тут може входити до складу інших підмножин як їхня частина і може сама складатися з інших підмножин. Це показано на рис. 3.8, а.

а) б)

Рисунок 3.8 – Рекурсивний зв’язок для мережі та його розкриття

Обидва кінці лінії зв'язку мають бути необов'язковими, тому що є остаточні продукти, які не є складальними одиницями, і є елементарні підмножини, що не мають у своєму складі складальних одиниць. Тут базове позначення для рекурсії - петля, що характеризується ступенем зв'язку m:n. Зв'язки такого типу необхідно розкривати шляхом заміни їх на два зв'язки типу 1:m, як це показано на рис. 3.8, б.

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

3.2 Поняття логічного моделювання даних, які не зображуються на ERD

В даному підрозділі описуються поняття, що використовуються при оформленні документації на ERD, але не зображуються при побудові ERD. Вони не такі важливі та фундаментальні, як поняття введені в пп. 3.1, але без знання цих понять неможливо якісно заповнити форми документації, що наведені в додатку В.

3.2.1 Мобільні та немобільні об'єкти

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

В обов'язкових зв'язках цільові об'єкти завжди мають бути немобільними. У кожному необов'язковому зв'язку цільовий об'єкт потенційно мобільний.

3.2.2 Атрибути

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

Атрибути вимагають ретельного визначення. Вони можуть мати дуже важливе значення при доборі деяких об'єктів чи груп об'єктів.

3.2.3 Обов'язкові та необов'язкові атрибути

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

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

3.2.4 Згруповані домени

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

3.2.5 Унікальні ідентифікатори

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

- один або більше обов'язкових атрибутів, які відносяться до даного об'єкта;

- комбінація одного чи більше атрибутів об'єкта, які беруть участь в одному або більше обов'язкових, немобільних зв'язках;

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

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

3.3 Допоміжні поняття

В даному підрозділі вводяться фундаментальні поняття, що зв'язують логічне моделювання даних з іншими методами.

3.3.1 Головні та допоміжні об'єкти

Більшість зв'язків, які одержані в процесі побудови ERD, у залежності від того, з якого кінця лінії зв'язку вони читаються, мають ступінь 1:m чи m:1. Наприкінці створення ERD усі присутні на ній зв'язки мають бути представлені в такому вигляді. Це забезпечує ясність й ієрархічність структури, а також усі необхідні передумови для застосування подальших методів проектування та реалізації системи.

Усі зв'язки в ERD можуть бути представлені у вигляді зв'язків, які мають ступінь 1:m:

- m:n – зв'язок може бути розкритий, як два зв'язки 1:m з відповідними лініями між двома об'єктами;

- 1:1 – зв'язок може розглядатися як спеціальний випадок зв'язку 1:m, або обидва об'єкти можуть бути об'єднані.

Перетворення зв'язків типу m:n і 1:1 розглядається нижче.

У зв'язках типу 1:m головним вважається об'єкт, який примикає до кінця лінії зі ступенем "один", а об'єкт, який примикає до кінця лінії зв'язку зі ступенем "багато", вважається допоміжним. Терміни "головний" і "допоміжний" указують на роль об'єкта в даному зв'язку точніше, ніж кожна з його характеристик.

Об'єкт може бути головним в одному зв'язку і допоміжним в іншому. Кожен головний об'єкт може мати в підпорядкуванні декілька допоміжних, а кожен допоміжний об'єкт може бути головним для деякої множини допоміжних об'єктів більш низького рівня.

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

Ієрархічна структура наведена на рис. 3.9 цілком відповідає таким допущенням:

- для будь-якого головного об'єкта всі зв'язані з ним допоміжні об'єкти досяжні;

- для будь-якого допоміжного об'єкта досяжний головний.

Рисунок 3.9 – Співвідношення головних та допоміжних об’єктів

3.4 Використання методу в процесі проектування

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

3.4.1 Виділення елементів ERD

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

- аналіз форм документів, використовуваних у документопотоках систе- ми, що аналізується;

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

- обстеження;

- особисті знання і судження;

- структуровані опитування.

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

3.4.2 Ідентифікація об'єктів

У рамках методу об'єкти ідентифікуються за допомогою логічного моделювання даних. Така сама задача вирішується, якщо це необхідно, з використанням методу реляційного аналізу даних. Більшість труднощів виникає при розв`язанні задачі ідентифікації об'єктів шляхом опитувань. Це обумовлено тим, що в процесі спілкування люди розуміються в термінах прикладів й аналогій. Крім того процес ускладнюється використанням у мові синонімів і існуванням у природних мовах омонімів. Тому аналітик зобов'язаний особливу увагу приділити питанням визначення ролей елементів аналізованої системи, (зокрема людей і організацій), вибрати назви об'єктів таким чином, щоб вони коротко і водночас повно відбивали сутність об'єктів, які ідентифікуються, а потім описати їх відповідно до вимог використовуваного методу. Це допомагає настроїтися на мислення в термінах системи позначень для ключів, в оточенні яких необхідно далі працювати з предметною областю аналізованої системи.

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

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

3.4.3 Ідентифікація зв'язків

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

3.4.4 Формування ERD

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

Рівень деталізації ERD має цілком відповідати рівню деталізації DFD і зростати в напрямку від узагальненої ERD до ERD необхідної системи.

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

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

При формуванні ERD аналітик додатково має враховувати такі фактори:

• мета розробки для забезпечення ясності, простоти і змістовності;

• мінімізацію перетинання ліній зв'язку;

• важливість точності розміщення елементів схеми;

• заборону на використання абревіатур;

• повноту опису кінців зв'язків.

3.4.5 Присвоєння імен зв'язкам

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

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

3.4.6 Нормалізація ERD

В нормалізованій ERD об'єкти розглядаються як відношення, що мають бути приведені до вигляду не нижче третьої нормальної форми (3NF). Кваліфікований аналітик одержує модель такого вигляду інстинктивно, шляхом неформального застосування правил реляційного аналізу даних з розвитком моделі. Нижче розглядаються можливості застосування правил реляційного аналізу при логічному моделюванні даних.

Перша нормальна форма.

Атрибут мусить мати тільки одне значення, що відповідає одному екземпляру об'єкта в даний час. Не допускається присутність повторюваних груп. Аналітик має створити новий об'єкт, який має зв'язок ступеня 1:m з вихідним об'єктом для того, щоб вилучити ці групи даних.

Ім'я атрибута має бути сингулярним. Повторюваність імен атрибутів у більшості випадків свідчить про наявність у моделі помилкових об'єктів.

Друга нормальна форма.

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

Третя нормальна форма.

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

3.4.7 Перевірка правильності ERD

Кожна логічна модель даних має бути цілком відповідна до своєї моделі потоків даних.

Перевірка відповідності процесів і об'єктів. Ця задача вирішується для кожного об'єкта з ERD відповідної моделі потоків даних. Має існувати принаймні один процес, який здатний відкликатися на події, що створюють і видаляють об'єкт. За необхідності може бути заповнена "Матриця Процес/Об'єкт", у якій використовуються такі типи доступу до даних як створення, редагування і видалення. Модель потоків даних, якщо це необхідно, має бути змінена.

Порівняння об'єктів і сховищ даних. Ця задача вирішується на всіх етапах створення DFD та ERD. Цілком задача розглянута раніше. Кожен об'єкт має відповідати одному і тільки одному сховищу з усієї множини сховищ даних у DFD, тому що він є неподільним між двома сховищами. Якщо ця умова не дотримується, то обидві моделі і ERD, і DFD необхідно виправити. Зв'язок між сховищами даних і об'єктами відображено в "Таблиці перехресних посилань Логічне сховище даних / Об'єкт". Виключення з цього правила складає випадок декомпозиції сховищ даних, результатом якої є супер- і субтипи, де супертипам відповідає більше одного сховища даних .

Розкриття зв'язків типу m:n. На ранніх стадіях розробки ERD може містити в собі дуже багато зв'язків типу m:n, які відповідають правилам діяльності даної організації.

До того ж зв'язки даного типу часто виявляються корисними під час обговорення моделі з користувачами.

Усі зв'язки типу m:n мають бути розкриті, тому що вони приховують поняття головний/допоміжний об'єкт і роблять неможливим чітке визначення шляхів доступу до даних. Розкриття зв'язку даного типу зазвичай здійснюється шляхом введення в схему зв'язаного об'єкта, що розбиває цей зв'язок на два зв'язки типу 1:m. Незважаючи на зовнішню простоту використовуваного прийому перетворень структури, його застосування не механічний процес, а “могутній” спосіб структурного аналізу. При цьому з вихідного об'єкта, що містить неключові атрибути, виділяється зв'язаний об'єкт, який більш точно описує головні об'єкти і природу зв'язку між ними.

Розкриття зв'язків типу 1:1. Зв'язки цього типу також часто зустрічаються в ERD на ранніх стадіях розробки. Причини цього явища такі самі що й у попередньому випадку.

В остаточному варіанті ERD усі зв'язки повинні мати головні та допоміжні об'єкти, а також кінець, який примикає до допоміжного об'єкта у вигляді "воронячої лапки". Як наслідок, кожен зв'язок цього типу або має зникнути через злиття двох об'єктів, або – бути представленим як зв'язок типу 1:m. Так само як і в попередньому випадку, розкриття зв'язків типу 1:1 – “могутній” спосіб структурного аналізу, що сприяє визначенню нових об'єктів і зв'язків. Він корисний тим, що забезпечує можливість повторного огляду необхідності існування об'єктів, які беруть участь у таких зв'язках.

Це пояснюється тим, що за зв'язками даного типу приховуються об'єкти - аналоги, що з'являються за рахунок вибору різних первинних ключів для того самого об'єкта. Після об'єднання таких об'єктів первинний ключ нового об'єкта має бути одним з первинних ключів вихідних об'єктів. Новий первинний ключ може бути створений тільки в тому випадку, якщо жоден з наявних ключів не підійшов. Якщо два об’єкти, що беруть участь у зв'язку не є єдиним об'єктом, то зв'язок 1:1 необхідно представити на ERD у вигляді зв'язку типу 1:m з виділенням допоміжного об'єкта "воронячою лапкою".

Зв'язок 1:1 з одним необов'язковим кінцем..

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

Зв'язок 1:1 з двома необов'язковими кінцями.

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

Зв'язок 1:1 із двома обов'язковими кінцями.

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

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

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

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

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

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

По закінченні ERD системи, що проектуються, складатимуться з остаточної ERD і заповнених описів об'єктів, атрибутів і згрупованих доменів. Форми описів наведено в додатку В.

Узагальнена ERD не забезпечується підтримуючою документацією.

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

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

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

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

На копії ERD можна відзначити обсяги об'єктів і зв'язків. Значення обсягу об'єкта береться з поля "Середня кількість екземплярів" форми "Опис об'єкта", а обсяг зв'язку підраховується, виходячи з відношення обсягів двох об'єктів, які беруть участь у зв'язку.

Логічний розмір кожного об'єкта підраховується шляхом підсумовування логічних розмірів усіх його атрибутів. Він має містити в собі розміри індикаторів стану.

ПЕРЕЛІК ПОСИЛАНЬ

1. Петров Э.Г., Чайников С.И., Овезгельдыев А.О. Методология структурного системного анализа и проектирования крупномасштабных ИУС. Концепции и методы. Часть 1. – Харьков: Рубикон, 1997. – 140с.

2. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). – М.: Лори,1996. – 242с.

3. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем. – М: Финансы и статистика, 1998. – 176с.

4. Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 1999. – 256с.

Додаток А

ЗРАЗОК ФОРМИ КАТАЛОГУ ВИМОГ

Елементкаталогувимог

Проект/система

Автор

Дата

Версія

Статус

Сторінка

Джерело

Пріоритет

Власник

Ідентифікатор вимоги

Функціональна вимога

Нефункціональна(і) вимога(и)
Опис	Цільове значення	Допустимий діапазон	Коментарі

Ефект

Коментарі / Рішення, що пропонуються

Посилання на інші документи

Посилання на інші вимоги

Висновки

Рисунок А.1 – Зразок форми каталогу вимог