Функціоналізація моделі

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

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

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

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

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

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

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

image231

Мал. 4.20. Дерево функцій розглянутого прикладу


Функціоналізація моделі у вигляді дерева функцій дала можливість в інструментальному засобі IBM InfoSphere Data Architect сформувати комплекс діаграм, які необхідні для спрощення уявлення моделі, обмеживши кількість сутностей, які в моделі повинні бути відображені (рис. 4.21). На кожному рівні діаграми моделей бази даних, крім відображення дочірніх діаграм, буде відображатися модель бази даних, що має відношення саме до даної діаграмі.

image232

Мал. 4.21. Приклад взаємозв'язку діаграм моделі бази даних


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

image233

Мал. 4.22. Приклад сформованого безлічі взаємопов'язаних діаграм


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

image234

Мал. 4.23. Зведена модель взаємодії діаграм


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

грам розділяти але видам: діаграми бізнес-процесів, моделі бізнес-функцій, моделі допоміжних функцій. Тоді кількість моделей на діаграмі буде невеликим, що дозволить се легко відобразити на аркуші паперу, і буде дотриманий принцип комплексності побудови моделей функціональних діаграм.

Виділення ключових сутностей

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

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

Розгляд функції "Облік категорій товарів". Вибір даної функції заснований на двох моментах:

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

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

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

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

image235

Мал. 4.24. Сутність, відповідна ключовому інформаційного об'єкту


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

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

Таблиця 4.8

Опис атрибутивного складу суті "Категорія товару"

п / п

сущ

ність

Атрибут

Тип

даних

Ачго-

ритм

промовчу

ня

ограниче

ня

NULL

1

Каті

гории

товарів

Найменування категорії

С (150)

-

-

-

-

2

11одкатсгорія

об'єкт

-

-

-

0



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

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

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

При розгляді атрибутів розробником можуть бути виявлені три основні види атрибутів:

  • • стандартний атрибут - характеризується простими типами даних, що позначають зберігання однозначно розуміється значення;
  • • об'єктний атрибут - характеризується зв'язком з іншим об'єктом предметної області, визначаючи необхідність отримання допоміжних даних, при первинному моделювання будемо позначати типом даних, який максимально ідентичний суті атрибута (наприклад, datalink, binary, table і т.д.);
  • • структурний атрибут - характеризується необхідністю поділу на окремі структурні (атрибутивні) елементи, але не представляється об'єктом предметної області, аналогічно об'єктному атрибуту спочатку в моделі може бути відображений максимально ідентичним типом даних.

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

  • 1) створити сурогатний первинний ключ з автоматичним заповненням, тобто володіє типом "Serial" або аналогічним.
  • 2) визначити альтернативний ключ по атрибуту "Найменування категорії", забезпечивши унікальність значень.

image236

Мал. 4.25. Наповнення суті атрибутами


Таблиця 4.9

Опис ключових атрибутів

п / п

Атрибут

Тип ключа

Тип

даних

унікальна

ність

Додаткові

кові

1

ІДФ категорії

Первинний

Ц (+1)

-

сурогатний

2

Найменування

категорії

альтернатив

ний

С (150)

індекс

-



В результаті моделювання були сформовані необхідні ключі, але, оскільки немає можливості показати все характеристики на самій моделі бази даних, а використання блоків коментарів сильно ускладнить візуалізацію моделі, то формується описова таблиця ключових атрибутів, де відображається:

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

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

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

image237

Мал. 4.20. Підсумкове уявлення ключовий суті


Розгляд функції "Наповнення замовлення товарами". Функція, згідно з формулюванням, забезпечує наповнення замовлення клієнта товарами із зазначенням кількості. Вивчення функції дозволяє сформувати перелік атрибутів, якими характеризується замовлення (табл. 4.10).

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

Таблиця 4.10

Опис атрибутивного складу суті "Замовлення"

п / п

сущ

ність

Атрибут

Тип

даних

алгоритм

промовчу

ня

ограниче

ня

1

замовлення

номер

замовлення

З (7)

-

-

-

про

2

дата замовлення

Д

-

Поточна

дата

-

-

3

клієнт

об'єкт

-

-

-

-

4

Товари

- "-

-

-

-

про

5

кількість

ц

1

> 0

Про

6

вартість

ч

Товари. Ціна 'Кількість

> = 0

Про



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

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

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

 
< Попер   ЗМІСТ   Наст >