Проектування баз даних з ERwin

Частина 1. Поняття сутності


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

Нижче будуть розглянуті наступні питання, що стосуються сутностей:

Так як в ERwin для моделювання даних використовується методологія ER (Entity Relational), давайте почнемо з короткого вступу до концепції ER. Для початку приступимо до вивчення сутностей – "контейнерів" для зберігання інформації логічної моделі.


Введення в реляційну діаграму сутності

У цій та інших публікаціях на цю тему для візуального представлення сутностей і відносин між ними використовуються ERD-діаграма (Entity Relational Diagram – реляційна діаграма сутність), заснована на нотації, що використовується ERwin. Хоча існують і інші методології моделювання даних, такі як розширений реляційний аналіз (Extended Relational Analysis – ERA), об'єктно-орієнтований підхід (Object Oriented – OO) і об'єктно-рольовий моделювання (Object Role Modeling – ORM), фундаментальні концепції ER методології присутні і в них.

Методологія ER-моделювання розроблено П. Ченом в кінці 1970-х років. Для представлення сутностей в методології ER використовуються прямокутники. У вихідній ER-нотації Чена відносини містять атрибути. Рівна можливість використання атрибутів у сутності і відносинах робить відмінність між сутностями і відносинами досить складним.

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

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


Що таке сутність?

Сутність – Це фізичне уявлення логічної угруповання даних. Сутності можуть бути речовими, реальними об'єктами, такими як ПЕРСОНА або МОРОЗИВО, або невідчутними концептуальними абстракціями як ЦЕНТР ЗАТРАТ або РИНОК. Сутності не призначені для представлення одиничного об'єкта, вони представляють набір примірників, що містять інформацію, що представляє інтерес з точки зору їх унікальності. Наприклад, сутність ПЕРСОНА являє собою екземпляр об'єктів типу Персона. Іван Петров, Марія Русанова і Савелій Богданов – конкретні приклади примірників сутності ПЕРСОНА. Конкретний екземпляр сутності представляється рядком таблиці та ідентифікується первинним ключем.

Сутність має наступні ознаки:


Формальні визначення сутності

Нижче наведено список визначень сутності визнаних авторитетів у галузі моделювання даних. Зверніть увагу на їх схожість:


Виділення сутностей

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

Іншим гарним джерелом є корпоративна модель.

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

Існує дві основні групи сутностей: залежні і незалежні . Незалежна сутність не має потребу в інформації з іншої сутності для ідентифікації унікального екземпляра. Вона представляється в ERwin у вигляді прямокутника. Первинний ключ незалежної суті не включає в себе первинних ключів інших сутностей.
Залежна сутність повинна залучати інформацію з іншої сутності для ідентифікації унікального екземпляра. Вона представляється на ER-діаграмі у вигляді прямокутника із закругленими кутами. Первинний ключ залежною суті включає первинні ключі однієї або більше батьківських сутностей.

Рис. 2.1. Приклади стрижневих сутностей для корпорації, яка торгує морозивом.

Зверніть увагу на рис. 2.1., Де зображені прямі кути незалежних сутностей МАГАЗИН та морозиво і закруглені кути залежною сутності МАГАЗИН Морозиво.


Визначення типів сутностей

І залежні, і незалежні суті можна розділити на кілька типів:


Стрижневі сутності

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

Стрижневі сутності можуть бути як незалежними, так і залежними. На малюнку 2.1 представлені приклади стрижневих сутностей для корпорації, яка торгує морозивом. Сутність МОРОЗИВО представляє базовий продукт корпорації. Сутність МАГАЗИН є прикладом каналу збуту або посередника при продажу товару.

Припустимо, що справи у корпорації йдуть добре і приймається рішення про відкриття додаткового МАГАЗИНУ. Щоб додати нових екземплярів сутності МАГАЗИН немає необхідності міняти модель. Те ж саме стосується і сутності МОРОЗИВО.

Зверніть увагу на стрижневі сутності МОРОЗИВО і МАГАЗИН. Хоча приклад може здатися дещо прямолінійним, він ілюструє всю міць концепції, що лежить в основі моделювання стрижневих сутностей.
Розуміння необхідності моделювати стрижневі сутності у вигляді масштабованих і розширюваних контейнерів вимагає від розробника моделі погляду на сутності як на абстрактні концепції та моделювання інформації незалежно від поточного способу її використання. У цьому прикладі модель сутності МОРОЗИВО повністю поза контекстом сутності МАГАЗИН і навпаки. Так що якщо у корпорації вирішать продавати МОРОЗИВО через новий канал збуту, такий як Інтернет або доставка додому, новий канал збуту може бути доданий без змін в інших сутностях.






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


Кодові сутності

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

На малюнку 2.2 ВЕРХІВКА – Незалежна сутність (зверніть увагу на прямі кути). ВЕРХІВКА є до того ж кодової сутністю або класифікатором. Примірники (рядки) сутності ВЕРХІВКА визначають список доступних верхівок.

Кодові сутності зазвичай містять обмежену кількість атрибутів. Існують реалізації, де ці сутності мали тільки один атрибут. Переважно моделювати кодові сутності з використанням штучного ідентифікатора. Штучний ідентифікатор разом з ім'ям і визначенням дозволяють додавати нові види верхівок в якості примірників (рядків) у сутність. Зверніть увагу на три атрибути сутності ВЕРХІВКА.

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

Рис. 2.2. Кодові сутності дозволяють корпорації визначати набір значень для централізованого використання в рамках корпорації. Примірники кодової суті визначають область визначення значень для використання в інших частинах моделі.


Асоціативні сутності

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






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

На малюнку 2.1 асоціативна сутність використовується для дозволу відносини багато-до-багатьох між сутностями МАГАЗИН і МОРОЗИВО. Введення асоціативної суті дає можливість використовувати один і той же МОРОЗИВО для продажу в кількох примірниках МАГАЗИНУ, без необхідності продажу в кожному з МАГАЗИНІВ однакових сортів МОРОЗИВА. Асоціативна сутність МАГАЗИН МОРОЗИВА враховує той факт, що екземпляр МАГАЗИНУ продає безліч екземплярів МОРОЗИВА, і примірник МОРОЗИВА може продаватися багатьма примірниками МАГАЗИНУ.


Характеристичні сутності

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






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

На малюнку 2.3 представлена сутність КОНТЕЙНЕР і характеристичні сутності РОЖОК і стаканчик. Магазин морозива, судячи з усього, торгує не на вагу, а окремими порціями. Зверніть увагу, що екземпляр КОНТЕЙНЕРА повинен бути ріжка або стаканчики. КОНТЕЙНЕР не може бути одночасно і ріжків і стаканчики. Це виключають характеристичні сутності.

Сутність ПЕРСОНА на малюнку 2.3 має дві характеристичні сутності співробітників і клієнтів. Зауважте, що виключають характеристичні суті не дозволять одному примірнику ПЕРСОНИ містити факти, загальні для співробітників і клієнтів. Природно, це суперечить реальній практиці. СПІВРОБІТНИК безумовно може бути КЛІЄНТОМ. ПОСТАЧАЛЬНИК теж може виступати в якості КЛІЄНТА. Це приклад включають характеристичних сутностей.

Рис. 2.3. Два приклади характеристичних сутностей ПЕРСОНА та КОНТЕЙНЕР. Обидва приклади використовують нотацію ERwin IE для подання виключають і включають характеристичних сутностей. Відсутність (X) в символі характеристичної суті вказує на включає ставлення.


Структурна сутність

Іноді екземпляри однієї і тієї ж суті пов'язані. У своїй книзі 1992-го року “Strategic Systems Development” К. Фінклештейн запропонував використовувати структурні сутності для подання відносин між екземплярами однієї й тієї ж сутності. Зв'язки між екземплярами однієї й тієї ж суті називаються рекурсивними відносинами. Рекурсивні відносини будуть розглянуті в статті "Поняття відносини". Рекурсивні відносини – це логічна концепція, а концепції не легко сприймаються користувачами.

На малюнку 2.4 показана додаткова структурна сутність, що описує відношення між екземплярами сутності СПІВРОБІТНИК. Діаграма показує, що характеристична сутність СПІВРОБІТНИК сутності ПЕРСОНА має дві характеристичні сутності ВИКОНАВЕЦЬ і управлінець. Сутність СТРУКТУРА СПІВРОБІТНИКІВ представляє відношення між екземплярами сутності СПІВРОБІТНИК.

Рис. 2.4. Структурна сутність – ілюстрація підходу К. Фінклештейна до вирішення рекурсивних відносин.


Визначення первинного ключа

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

Первинний ключ повинен бути статичним (static) та неруйнівними (non-volatile). Під статичністю і неразрушаемостью мається на увазі, що первинний ключ не повинен зазнавати змін. Зміни первинного ключа важко супроводжувати, що часто призводить до дуже дорогим переробкам, тому найкращим вважається варіант, коли первинний ключ абсолютно не залежить від екземплярів сутності.






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

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

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

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


Іменування сутностей

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

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


Угоди про іменуванні сутностей

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

Нижче наведені деякі положення для формування початкового набору угод про іменування, на випадок, якщо у вашій організації поки такий набір не розроблено:

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


Приклади хороших імен сутностей

Завжди краще використовувати однакові імена в рамках корпорації. У таблиці 2.1 наведено приклади хороших і поганих імен для сутностей.






Рада
Зверніть увагу, що для імен сутностей використовуються великі літери, що відповідає рекомендованому угоди про іменуванні сутностей.

ТАБЛИЦЯ 2.1 Приклади імен сутностей із поясненнями



































Гарне ім'я

Невдале ім'я

Пояснення
МАТЕМАТИЧНА ФОРМУЛА ФОРМУЛА ФОРМУЛА – занадто розпливчасто, додавання прикметника МАТЕМАТИЧНА значно прояснює сенс.
КНИГА КНИГИ КНИГА – іменник в однині.
УСЗС УСЗС
Кушетка
УСЗС і кушетка мають однаковий зміст. Виберіть щось одне.
МОРОЗИВО БУДЬ-ТЕ МОРОЗИВО Займенник БУДЬ-ТО не привносить додаткового значення або сенсу до терміну. Уникайте зайвих доповнень.
Фотознімок ЗОБРАЖЕННЯ Фотознімок – досить виразно. ЗОБРАЖЕННЯ – кілька розпливчасто.
Очікуваний час прибуття ОВП Абревіатура ОВП може виявитися незрозумілою для користувачів.
КОМПАНІЯ КОМПАНІЯ XYZ XYZ – конкретний екземпляр компанії і повинен бути рядком в сутності КОМПАНІЯ.

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

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

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


Правила формування хороших описів

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

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


Приклади хороших описів

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

ТАБЛИЦЯ 2.2. Описи сутностей із поясненнями























Хороший опис

Невдале опис

Пояснення
ПЕРСОНА містить інформацію про фізичних осіб, які вступають
у взаємодію
з корпорацією. Інформація
про персони допомагає корпорації при плануванні, розробці продуктів і рекламної діяльності.
Клієнт або співробітник. Гарне опис включає визначення сутності та її значення для корпорації.
   Включає ім'я, дату народження і т.п. на особу. Просте перерахування атрибутів суті не несе додаткової інформації про те, що собою являє сутність і чому вона важлива для корпорації.
   Інформація про клієнтів
і співробітників.
Клієнт і співробітник є прикладами ролей, в яких може виступати ПЕРСОНА. Використання одних тільки прикладів не пояснює, що сутність собою представляє і чому вона важлива для корпорації.
   Сутність містить символи і числові дані, витягнуті
з POS (Point Of Sale – торговий термінал), що зберігаються з використанням стандартного стиснення і упакованих десяткових чисел.
Даний штучний приклад покликаний проілюструвати, що технічні описи і абревіатури насилу розуміються бізнес-користувачами.

Поширені помилки при моделюванні сутностей і виборі ключів

Цей розділ, присвячений поширених помилок при моделюванні, не претендує на повноту. Його мета – вказати на найбільш поширені помилки, які виникають у розробників моделей.






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


Моделювання ролей

Що мається на увазі під моделюванням ролей? Під час робочих сесій користувачі можуть сказати вам, що їм необхідно зберігати інформацію про співробітників. Виникає спокуса створити сутність СПІВРОБІТНИК. Більш ретельний аналіз інформації, що становить інтерес для корпорації, наприклад, такої як ім'я, адреса і номер соціального страхування показує, що ці значення не залежать від сутності СПІВРОБІТНИК. Для конкретного СПІВРОБІТНИКА значення атрибуту ІМ'Я не залежить від сутності СПІВРОБІТНИК. Це легко зрозуміти, якщо задуматися про те, що ваше ім'я залишається вашим ім'ям незалежно від того, чи є ви ПРАЦІВНИКОМ чи ні.


Перевантаження сутностей

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

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

Наприклад, сутність ОБЛАДНАННЯ може мати зовсім різне значення для підрозділів інформаційних технологій і для відділу засобів масової інформації і комунікацій.


Надлишкові сутності

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

Наприклад, сутності управлінець і СПІВРОБІТНИК можуть містити подібну інформацію, оскільки обидві є ролями, які може грати примірник сутності ПЕРСОНА.


Вибір невірного первинного ключа

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


Використання невдалих імен сутностей

Незрозумілі, неоднозначні чи неточні імена ускладнюють для нових користувачів і команд розробників повторне використання або розширення існуючої моделі.

Не використовуйте абревіатури або акроніми в якості частини імені. Абревіатури та акроніми відкриті для неправильної інтерпретації і навіть можуть мати різне значення в різних предметних областях.







Застереження
Не використовуйте імена власні, що вказують на конкретний екземпляр, такі як, наприклад, Компанія Інтерфейс. Це невдалий вибір імені суті, який в подальшому призведе до серйозних проблем при моделюванні.

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


Використання невдалих описів сутностей

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

Не намагайтеся перефразувати ім'я суті. Не використовуйте ім'я сутності в її описі.

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

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

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


Висновок

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

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

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

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

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


Частина 2. Поняття атрибуту

У статті "Базові концепції моделювання даних" були введені основні поняття, пов'язані з моделюванням даних. У статті Основні компоненти діаграми ERwin – сутності, атрибути, зв'язки. Частина 1. Поняття сутності були дані початкові відомості про сутності і ключах сутностей. У даній статті розглядаються атрибути та більш детально описуються нормалізація і ключі.

У цій статті ви дізнаєтеся як:

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


Що таке атрибут?

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

Атрибут повинен представляти єдину концепцію. Атрибути формують логічні групи, що описують кожен екземпляр сутності. Конкретним примірником атрибута є значення . Наприклад, атрибут з назвою Ім'я визначає область визначення для фактів про сутність з назвою ПЕРСОНА. Габріель, Р.Дж., Уілл і Ванесса – приклади конкретних значень Ім'я для конкретних екземплярів ПЕРСОНИ. Конкретні значення для кожного з атрибутів сутності представляють єдиний екземпляр.

Коректна модель атрибуту володіє наступними ознаками:







ПРИМІТКА
На Малюнку 3.1 представлений приклад не дуже хорошою моделі; це прямолінійний відображення вимог до інформації. У наступних розділах буде зроблена спроба поліпшити цю модель для демонстрації процесу розміщення атрибутів у відповідних сутності.

Корпорація Торгівлі морозивом Бетті Уілсон хоче замовляти більше найбільш популярних смакових добавок і менше – найменш популярних. Корпорація Бетті робить спеціальні пропозиції з продажу морозива, і зацікавлена знати, морозиво з яким смаком покупці вибирають для бананового десерту і вершковою помадки під час спеціальних пропозицій. Для відповідності бізнес-вимогам необхідно збирати дані про смакові добавки до морозива для бананового десерту і вершковою помадки і дату.

На малюнку 3.1 дві сутності бАнАновиЙ ДЕСЕРТ і вершкове помадки. Кожна сутність має атрибути, представляють компоненти кожного з блюд. Зверніть увагу, що для сутності бАнАновиЙ ДЕСЕРТ можна вибрати три смакових добавки, три верхівки: банан, збиті вершки і вишні. Для екземпляра ВЕРШКОВИЙ помадки можна вибрати дві смакових добавки і банан, збиті вершки і вишні.

Рис. 3.1. Сутності та атрибути, представляють (не дуже вдало) дві основні концепції: Вершкове помадкою і бАнАновиЙ ДЕСЕРТ


Виявлення атрибутів

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

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


Упорядкування атрибутів відповідно до вимог до інформації

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






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

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


Аналіз атрибутів

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

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

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

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


Залишитися має тільки один

Атрибут повинен бути присутнім в логічній моделі в єдиному екземплярі. "Один факт в одному місці" (Дейт, 1986). Для гарантії того, що кожен факт представлений єдиним атрибутом, перевірте атрибути з подібними іменами або описами. Крім того, ви повинні визначити, чи є атрибути реальними екземплярами або конкретними значеннями, які помилково представлені в моделі різними атрибутами.

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

Атрибути, які мають у складі свого імені слова "індикатор" або "прапор", швидше за все, представляють конкретне значення з області визначення атрибута. Конкретне значення є екземпляром атрибута. Використання в моделі примірників атрибутів – поширена помилка. Наприклад, "Індикатор чорного волосся" має значення "та" якщо присутні чорне волосся, і значення "ні" якщо чорне волосся відсутні. Більш кращим буде використання в моделі ознаки "Колір волосся", який може мати конкретне значення "Чорний".

Атрибут повинен представляти тільки одну концепцію бізнесу. Він не повинен мати кілька значень для одного примірника сутності. На Малюнку 3.1 показані дві сутності, бананові ДЕСЕРТ і вершкове помадки. Обидві суті містять багатозначний атрибут з ім'ям "Дата початку або закінчення спеціальної пропозиції". Ім'я атрибута показує, що його значення може представляти дату початку спеціальної пропозиції або дату закінчення спеціальної пропозиції, і у нас немає можливості їх розрізнити! Цей атрибут повинен бути розділений на два, кожен з яких представлятиме єдиний факт.






ПРИМІТКА
Хоча розбиття одного атрибута на два для розрізнення фактів дозволяє вирішити проблему з багатозначністю атрибуту, залишається інша проблема: значення атрибутів Дата початку спеціальної пропозиції і Дата закінчення спеціальної пропозиції не залежать від ідентифікаторів сутностей бАнАновиЙ ДЕСЕРТ і вершкове помадки. Ця проблема пов'язана з нормалізацією і буде розглянута в наступному розділі.

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


Нормалізація: приміщення атрибуту у відповідну сутність

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

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

Приведення логічної моделі до третьої нормальної формі часто призводить до появи нових сутностей.






ЗАСТЕРЕЖЕННЯ
Обережно додавайте нові атрибути до сутностей нормалізованої моделі. Новий атрибут повинен залежати від значення ключа, повного ключа, і ні від чого, крім ключа. Розглянемо випадок існування складеного первинного ключа: додавання нового атрибуту, значення якого залежить від значення частини ключа, порушує вимоги частини другої нормальної форми.

Іншими перевагами нормалізації є:

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


Функціональна залежність

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






ПРИМІТКА
У заданому відношенні R атрибут Y функціонально залежить від атрибуту X. У символьному вигляді RX -> RY (читається як "RX функціонально визначає RY") – в тому і тільки в тому випадку, якщо кожне значення X в R асоціюється строго з одним значенням Y в R (в кожен конкретний момент часу). Атрибути X і Y можуть бути складними (Дейт, 1986).

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

Атрибути, що належать до однієї теми, можуть виявитися надмірними. Надлишкові атрибути можуть бути згруповані в єдину сутність або можуть використовувати загальну абстракцію більш високого рівня в якості характеристичних сутностей батьківського сутності. На малюнку 3.1 присутній, щонайменше, дві спільні теми: Смакова добавка до морозива і Верхівка. Ці атрибути є гарними кандидатами на перенесення в інші сутності. Розглянемо їх в аспекті функціональної залежності. Значення атрибута Смакова добавка до морозива не залежить від значення первинного ключа – Інгредієнти бананового десерту. Те ж саме стосується і ключа Вершкова помадка.

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


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

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

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

На малюнку 3.2 перенесені повторювані групи Смакова добавка до морозива і Верхівка в залежні сутності. Зверніть увагу на створення сутності СМАК.

Рис. 3.2. Усунення надмірних атрибутів


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

Приведення до другої нормальної форми означає видалення надлишкових атрибутів. Надлишковими атрибутами можуть бути:







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

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

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

Рисунок 3.2 демонструє рішення для деяких надлишкових атрибутів сутностей бАнАновиЙ ДЕСЕРТ і вершкове помадки. Розглянемо надмірність з точки зору двох стрижневих сутностей. В обох сутності присутні загальні теми: смакова добавка до морозива і верхівка. Це ознака того, що стрижневі сутності можуть бути об'єднані на більш високому рівні абстракції.

Малюнок 3.3 демонструє створення супертіпа з ім'ям СУМІШ, для якого бАнАновиЙ ДЕСЕРТ і вершкове Помадка є його реалізаціями. Я додав класифікаційний атрибут "Тип суміші" в батьківську сутність СУМІШ для ідентифікації чи є СУМІШ примірником сутності бАнАновиЙ ДЕСЕРТ або вершковим помадки. Примірник сутності СУМІШ може бути примірником сутності бАнАновиЙ ДЕСЕРТ або вершковим помадки, але не їх обох одночасно.

Рис. 3.3. Надмірність стрижневих сутностей усунена за рахунок переміщення загальних атрибутів в більш загальну сутність СУМІШ. Зверніть увагу, що первинний ключ "Ідентифікатор суміші" поміщений і по суті бАнАновиЙ ДЕСЕРТ і вершкове помадки.


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

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

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

На Малюнку 3.3 атрибути Збиті вершки і Вишня не залежать від первинних ключів сутностей бАнАновиЙ ДЕСЕРТ і вершкове помадки. Фактично ви повинні вирішити, чи не є атрибути Збиті вершки і Вишня примірниками сутності ВЕРХІВКА.





ПРИМІТКА
Сутність БАнАновиЙ ДЕСЕРТ містить атрибут Збиті вершки і сутність ВЕРШКОВИЙ Помадка теж містить атрибут Збиті вершки. Порівняння описів цих атрибутів показує, що вони описують одну й ту ж концепцію. Збиті вершки були обрані як логічне ім'я для уявлення загальної концепції та переміщені в більш загальну сутність СУМІШ.

На Малюнку 3.4 зверніть увагу на додатковий атрибут Дата суміші, який забезпечує інформацію про те, коли був створений екземпляр сутності СУМІШ. Я видалив атрибути Дата початку та Дата закінчення з сутностей бАнАновиЙ ДЕСЕРТ і вершкове помадки. Нова сутність СПЕЦІАЛЬНА ПРОПОЗИЦІЯ тепер містить ці дві дати й атрибут Смакова добавка до морозива для вказівки того, на який з видів морозива поширюється пропозицію.

Рис. 3.4. Кожен атрибут залежить від первинного ключа, повного первинного ключа і ні від чого, крім ключа.


Визначення характеристик атрибуту

Атрибути діляться на дві групи. Атрибут або є ключем, або ні. Малюнок 3.5 показує ключові атрибути для логічної моделі сутності СУМІШ. Зауважте, що, по суті, атрибути первинного ключа розташовуються над лінією всередині сутності, а інші атрибути – під лінією.

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


Ключові атрибути

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


Атрибути первинного ключа

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

Хороший первинний ключ буде володіти такими ознаками:


Штучні первинні ключі

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

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

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


Кандидати в ключі

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

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


Зовнішні ключі

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


Міграція атрибутів первинного ключа

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


Неключові атрибути

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

У своїй книзі Strategic Systems Development К. Фінклештейн визначає кілька типів неключових атрибутів:

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

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*