Проектування баз даних з ERwin, CASE-засоби (моделювання), Програмування, статті

Частина 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>

*

*