Виділення допоміжних сутностей

Розглянута раніше сутність "Категорія товарів" містить об'єктний атрибут "Будь", який відповідає аналогічному об'єкту предметної області. Це було виявлено при аналізі предметної області. Однак для застосування правила нормалізації цієї сутності необхідно визначити зв'язки між атрибутами (табл. 4.11).

Зазвичай в рамках ключової сутності атрибути простих типів будуть пов'язані зв'язком один - до - одному (1: 1), підтверджуючи їх коректність відображення в розглянутій сутності. Для інших атрибутів першочергове значення мають зв'язки з первинним ключем, який характеризує кожен конкретний екземпляр об'єкта (сутності) "Категорія товару". Розглядаючи цей атрибут, підспудно розробник говорить про весь об'єкт в цілому, всієї сукупністю його основних атрибутів (табл. 4.12).

Таблиця 4.12

Обгрунтування зв'язків атрибутів сутності

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

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

Мал. 4.27. Результат нормалізації по атрибуту "Будь"

Як і в разі сутності "Категорія товарів", по суті "Будь товарів" є ідентифікує атрибут "Найменування підкатегорії", представлений символьним типом даних, що говорить про недоцільність його використання в якості первинного ключа (табл. 4.13). У світлі цього створюється сурогатний первинний ключ "ІДФ підкатегорії", а атрибут "Найменування підкатегорії" буде вказаний як альтернативного ключа.

Таблиця 4.13

Опис суті "Будь товарів" розглядається тільки по атрибутам, безпосередньо пов'язаним з об'єктом (табл. 4.14). Тому в таблиці описів вказано тільки один атрибут "Найменування підкатегорії".

Таблиця 4.14

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

На особливу увагу заслуговує атрибут зовнішнього ключа "ІДФ категорії". На відміну від аналогічного атрибута по суті "Категорія товарів"

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

Дослідження об'єкта "Товари". Розглядаючи функцію "Облік довідника товарів", розробник визначає сутність "Товари" (рис. 4.28).

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

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

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

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

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

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

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

Розгляд атрибута "Клієнт" (рис. 4.31), використовуючи правило нормалізації, призводить до створення сутності "Клієнт", відповідної ідентичному об'єкту.

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

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

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

Таблиця 4.17

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

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

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

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

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

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

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