Основні компоненти діаграми ERwin – сутності

Частина 1

У статті "Базові концепції моделювання даних" були введені основні поняття, пов'язані з моделюванням даних. У статті , атрибути, зв'язки. Частина 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 К. Фінклештейн визначає кілька типів неключових атрибутів:



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


У третій нормальній формі не ключові атрибути повинні бути простими (основними) або похідними атрибутами.


Прості атрибути


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


Похідні атрибути


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


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


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


Знаходження області визначення атрибута


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


Можна сказати, що область визначення атрибута повинна містити, як мінімум, два значення. Атрибут, для якого завжди дозволено тільки одне значення, ймовірно, некоректно відображений в моделі. На Малюнку 3.5 присутній два таких атрибуту – Банан і Помадка.


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


У Таблиці 3.1 наведені галузі визначення логічних типів даних сутності СПЕЦІАЛЬНА ПРОПОЗИЦІЯ логічної моделі СУМІШ.

ТАБЛИЦЯ 3.1. Приклади логічних типів даних.























Ім'я атрибута

Логічний тип даних
Ідентифікатор спеціальної пропозиції Number (число)
Ідентифікатор морозива Number (число)
Ідентифікатор смаку Number (число)
Початок спеціальної пропозиції Date (дата)
Кінець спеціальної пропозиції Date (дата)

Області визначення простих і розширених типів даних


Область визначення типу даних визначає спосіб представлення значень атрибуту. У завершеною логічної моделі область визначення типу даних потрібна для кожного атрибута. У наступному списку наведено кілька прикладів логічних типів даних ERwin:



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



Області визначення, що вводяться користувачем


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


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


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


У книзі Information Engineering: Strategic Systems Development К. Фінклештейн визначає властивість обов'язковості атрибуту через серію "правил редагування":



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


У Таблиці 3.2 вказано властивість обов'язковості для атрибутів сутності СПЕЦІАЛЬНА ПРОПОЗИЦІЯ. Зверніть увагу на той факт, що при створенні екземпляра сутності СПЕЦІАЛЬНА ПРОПОЗИЦІЯ значення потрібні для всіх атрибутів крім атрибуту Дата закінчення спеціальної пропозиції.

Таблиця 3.2. Приклади обов'язковості атрибутів






















Ім'я атрибута Обов'язковість
Ідентифікатор спеціальної пропозиції Потрібно
Ідентифікатор морозива Потрібно
Ідентифікатор смаку Потрібно
Початок спеціальної пропозиції Потрібно
Кінець спеціальної пропозиції Необов'язково

У таблиці 3.2 представлено бізнес-правило, яке говорить, що для екземпляра сутності СПЕЦІАЛЬНА ПРОПОЗИЦІЯ потрібно наступна інформація:



Дата закінчення для кожного екземпляра сутності СПЕЦІАЛЬНА ПРОПОЗИЦІЯ необов'язкова. Бізнес-правило стверджує, що СПЕЦІАЛЬНА ПРОПОЗИЦІЯ повинно мати початок, але не обов'язково повинне мати кінець.


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


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








ПРИМІТКА


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


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


Іменування атрибутів


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








РАДА


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


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


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


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



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


Імена атрибутів у формі Об'єкт / Модифікатор / Клас


Форма об'єкт / модифікатор / клас – широко поширене в галузі угоду про іменуванні атрибутів. Ця угода спонукає використовувати імена атрибутів, що складаються з трьох частин. Частина об'єкт іноді називають суб'єктом або основним словом. В якості об'єкта зазвичай використовується ім'я суті.


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


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



Приклади імен атрибутів


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

ТАБЛИЦЯ 3.3. Імена атрибутів з поясненнями

































Гарне Ім'я

Невдале ім'я

Пояснення
Person First Name
(Ім'я персони)
 
Name
(Ім'я)
 
Name (Ім'я) – назва класу і потребує позначенні об'єкта Person (персона) і в модифікаторі First (перше).
Ice Cream Sales Quantity
(Обсяг продажів морозива)
 
The Quantity of Sales
(Обсяг продажів)
 
Quantity (Кількість) – назва класу і має бути на останньому місці (в англійському варіанті імені атрибута). "The" і "of" не привносять додаткового сенсу.
Item Cost Amount
(Величина вартості позиції)
 
Cost of Item
(Вартість позиції)
 
"Of" не привносить додаткового сенсу. Назва класу "Amount" (величина) вказує користувачеві, що має бути в атрибуті.
Product Identifier
(Ідентифікатор продукту)
 
Product Identifiers
(Ідентифікатори продуктів)
 
"Identifiers" (Ідентифікатори) – множина. Ім'я атрибута повинно бути іменником у однині.
Point of Sale Location Code
(Код розташування точки продажу)
 
POS Code
(Код POS)
 
"POS" – абревіатура. Використане назва класу "Code" (код) потребує модифікаторі.
Person Birth Date
(Дата народження персони)
 
Birthday
(День народження)
 
Birthday (День народження) не містить назви класу Date (Дата). Включення модифікатора та імені об'єкта прояснює зміст імені атрибута.

Опис атрибутів


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



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

Таблиця 3.4. Імена та опису атрибутів з поясненнями.







































Ім'я атрибута

Хороший опис

Невдале опис

Пояснення


Person First Name


(Імяперсони)


Ім'я персони, яке дозволяє корпорації спілкуватися з персоною, використовуючи дружні звернення.


Поле з довжиною в 40 символів.


Не використовується мова бізнесу. Застосовані технічні терміни.


Ice Cream Sales Quantity


(Обсяг продажів морозива)


Кількість морозива конкретного сорту, проданого в рамках конкретного заходу щодо продажу.


Обсяг продажів.


Не додає нового сенсу, а просто перефразовує ім'я атрибута в розпливчастих термінах.


Item Cost Amount


(Величина вартості позиції)


Величина вартості конкретної позиції в конкретний період часу. Представляє сумарну вартість продажу і доставки.


Шестизначне десяткове число з двома знаками після коми.


Занадто технічний опис. Майже нічого не означає для користувачів елемента даних.


Product Identifier


(Ідентифікатор продукту)


Штучний унікальний числовий ідентифікатор для конкретного продукту.


Ідентифікатори продуктів.


Проста перефразування імені атрибута.


Point of Sale Location Code


(Код розташування точки продажу)


Унікальний код, що ідентифікує географічне положення точки продажу.


Код POS.


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


Person Birth Date


(Дата народження персони)


Дата народження персони.


День народження персони.


В описі опущено назва класу "дата".


Поширені помилки при роботі з атрибутами


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


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


Моделювання в термінах значень


Що розуміється під моделюванням у термінах значень? Під час робочої сесії користувачі можуть сказати вам, що їм потрібний набір атрибутів, що вказують на вікові категорії примірника сутності ПЕРСОНА. У цьому сценарії виникають, щонайменше, три проблеми:



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







РАДА


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


Моделювання багатозначних атрибутів


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


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


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


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


Моделювання надлишкових атрибутів


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


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


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


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


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


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


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


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


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


Висновок


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


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


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


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


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

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


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

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

Ваш отзыв

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

*

*