Повна версія

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

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


<<   ЗМІСТ   >>

Нормалізація моделі

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

Аналіз зв'язок 1: 1. Найбільш проста нормалізація виконується по зв'язку 1: 1, оскільки зазвичай така зв'язок нормалізується за єдиним правилом - об'єднання в єдину сутність (рис. 4.3).

image214

Мал. 43. Виявлена зв'язок 1: 1


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


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

типи сутностей

Тип зв'язку / Обгрунтування

вартість

замовлення

символьна

вартість

замовлення

/ ^ _______________________ / Сім воль-

  • ( Вартість 4, (
  • 1: 1 1 паю вартість)

замовлення / V /

замовлення

Прямий зв'язок

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

номер

замовлення

клієнт

(^ Ншщр замовлення ^^ | 1: Л ^ | іепт ^^^

Прямий зв'язок

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

При розгляді документа "Замовлення" виявляється, що один конкретне замовлення, описуваний номером, може бути сформований тільки одним клієнтом, але той же клієнт може сформувати багато різних замовлень




типи сутностей

Тип зв'язку / Обгрунтування

номер

замовлення

І Іомер товару

замовлення 4 ^ Л Г : Л / ^^^^ Номер товару ^

непрямий зв'язок

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

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

номер

замовлення

Найменування товару

/ ,, Чг ., ( Найменування

(Номер замовлення) Л.А / 1)

V / -------------------------------------- V товару У

Прямий зв'язок

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



типи сутностей

Тип зв'язку / Обгрунтування

І іаіменова- ня товару

І Ієна товару

  • ( Найменування. ХГ ( тт Л
  • 1: ДГ (І Ієна товару

V товару У --------------------------- Ч 1 /

Прямий зв'язок

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

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

номер

замовлення

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

(^ Номер замовлення ^ 1: ЛҐ (^ Дата замовлення ^^

Прямий зв'язок

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


типи сутностей

Тип зв'язку / Обгрунтування

вартість

товару

кількість

товару

( Вартість Л ( Кількість Л V товару / V товару у

Прямий зв'язок

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

вартість

замовлення

вартість

товару

/ Вартість ( Вартість

V замовлення у --- V товару у

непрямий зв'язок

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



image215

Мал. 4.4. Результат нормалізації зв'язку 1: 1


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

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

Атрибут та відповідний йому тип сутності "Дата замовлення" має з ключовим типом сутності єдиний об'єкт докладання, тому спочатку розглянемо цей зв'язок (рис. 4.5). Між номером замовлення і датою замовлення встановлено зв'язок один - до - багатьох (1: ДО), і, здавалося б, нічого робити не потрібно, але дата є характеристичним атрибутом конкретного замовлення, при цьому множинність зв'язку спрямована на ключовий тип сутності, що говорить про можливої ​​дубльованих саме дати замовлення, а не його номера.

image216

Мал. 4.5. Зв'язок між номером і датою замовлення


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

image217

Мал. 4.6. Результат нормалізації номера і дати замовлення


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

Наступним типом сутності, з яким пов'язана тепер вже сутність "Замовлення", є "Клієнт" (рис. 4.7). Ми розглядаємо сутність "Замовлення", а не тип сутності "Номер замовлення", оскільки такий тип сутності був раніше вилучений, а сутність "Замовлення", з огляду на вказівки в якості первинного ключа атрибута "Номер замовлення" з цього типу сутності, набуває все його властивості , включаючи існуючі зв'язки з іншими типами сутностей.

image218

Мал. 4.7. Зв'язок між замовленням і клієнтом


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

image219

Мал. 4.8. Нормалізована зв'язок між замовленням і клієнтом


Поки сутності-категорії нс створюються, оскільки відповідний розгляд не настав. Це необхідно буде зробити при піду-

щих ітераціях нормалізації або, якщо виникне така ситуація, в процесі розгляду відповідних документів. У розглянутому прикладі дослідження документів "Рахунок", "Рахунок-фактура", "Товарна накладна" і ін. Призведе до необхідності створення сутності-категорії "Організація" і, як наслідок, сутності-категорії "Фізична особа".

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

image220

Мал. 4.9. Додавання категоризації при подальшому розгляді

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

image221

Рис 4.10. Нормалізація зв'язку замовлення з його вартістю

У підсумку всі атрибути сутності "Вартість замовлення" будуть переміщені в сутність "Замовлення", а сама сутність "Вартість замовлення" буде видалена

але через відсутність в ній атрибутів і передачі всіх властивостей в сутність "Замовлення.

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

image222

Мал. 4.11. Зв'язок між замовленням і товаром


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

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

image223

Мал. 4.12. Нормалізація зв'язку замовлення з товаром


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

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

ходима буде зв'язка для інших атрибутів. Проведена нормалізація зв'язку з цим (рис. 4.13) привела до можливості розгляду інших атрибутів в зв'язці з замовленням і товарами, що буде видно при подальшому розгляді.

image224

Мал. 4.13. Нормалізація зв'язку товару з ціною

Аналогічно іншим прикладам ціна товару пов'язана з сутністю "Товар" зв'язком один - до - багатьох і є характеристичним атрибутом товару. Тому, як і в попередніх випадках, атрибут типу сутності "Ціна товару" стає атрибутом сутності "Товар" (рис. 4.14).

image225

Мал. 4.14. Результат нормалізації зв'язку ціни товару з сутністю "Товар"


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

image226

Мал. 4.15. Результат нормалізації номера і кількості товару


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

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

Поєднавши всі виконані дії по нормалізації зв'язків, отримуємо загальну модель бази даних (рис. 4.17).

image227

Мал. 4.16. Встановлення зв'язку між вартістю товару і пов'язаними сутностями


image228

Мал. 4.17. Модель бази даних за підсумками першої ітерації


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

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

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

image229

Мал. 4.18. Нормалізована модель бази даних


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

 
<<   ЗМІСТ   >>