Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

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

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


Визначення зв'язків атрибутів по суті "Категорія товарів"

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

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

1: 1

Будь

Ш

1: ЛГ

-

ІДФ

категорії

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

категорії

Будь

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

Таблиця 4.12

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

image238

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

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

Q Категорія товарів

Q Будь товарів

$ £ ІДФ категорії: SERIAL

Н-о <

ІДФ підкатегорії: SERIAL

fV Найменування категорії: VARCHAR (150) [АК]

Найменування підкатегорії: VARCHAR (150) [АК]

о- ІДФ категорії: INTEGER [FK]

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

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

Таблиця 4.13

Опис атрибутів сутності "Будь товарів"

п / п

сутність

Атрибут

Тип

даних

алгоритм

замовчування

обмеження

NULL

1

І Іодка-

тегории

товарів

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

С (150)

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

Таблиця 4.14

Опис ключів сутності "Будь товарів"

п / п

Атрибут

Тип ключа

Тип

даних

унікальна

ність

Додаткові

кові

1

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

Первинний

Ц (+1)

-

сурогатний

2

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

альтернативний

С (150)

індекс

-

3

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

зовнішній

Ц

-

-

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

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

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

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

image239

Мал. 4.28. Результат моделювання ключовий суті "Товари"


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

Таблиця 4.15

Визначення зв'язків для сутності "Товари"

ІДФ

товару

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

товару

1: 1

І Ієна товару

1: АГ

1: ЛГ

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

1: ЛГ

1: ЛГ

-

ІДФ товару

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

товару

Ціна товару

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



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


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

атрибути

обгрунтування

ІДФ

товару

Ціна

товару

  • ( ІДФ Л гттл Л, Л
  • 1) 1: ЛЧ I Ціна товару) V категорії У 1 1 У

Одна одиниця товару може оцінюватися тільки однієї ціною. Але конкретна ціна може характеризувати різні товари

ІДФ

товару

Будь

(ІДФ | 1: Л Г 1 (категорія)

V категорії У 1 ------------ 1 V 1 У

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



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

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

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

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


image240

Мал. 4.29. Результат нормалізації суті "Товари"


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

image241

Мал. 4.30. Атрибутивний складу ключової сутності "Замовлення"


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

image242

Мал. 4.31. Виділення суті "Клієнт"


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

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

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

Таблиця 4.17

Визначення зв'язків між атрибутами сутності "Замовлення"

ІДФ замовлення

Номер замовлення

1: 1

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

1: Л Г

1: ЛГ

клієнт

: До

1: Л Г

КМ

Товари

КМ

КМ

КМ

КМ

кількість

КМ

КМ

КМ

КМ

КМ

вартість

КМ

КМ

КМ

КМ

км

КМ

ІДФ

замовлення

номер

замовлення

Дата

замовлення

клієнт

Товари

кількість

вартість



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

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

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

image243

Мал. 4.32. Результат нормалізації суті "Замовлення"


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

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

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

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

 
<<   ЗМІСТ   >>