Повна версія

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

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


<<   ЗМІСТ   >>

Моделювання і опис сутностей

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

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

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

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

Для опису сутностей не використовується велика кількість характеристик, оскільки це всього лише группирующий елемент, який

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

  • • Volumetries (вимірювачі) - набір характеристик, що описують кол і вшановують н і показни і:
    • - Initial Row Count (початкова кількість рядків) - параметр, що визначає кількість примірників суті, які повинні бути створені до початку використання бази даних;
    • - Max Rows (максимум рядків) - максимальна кількість примірників суті, яке повинно зберігатися в базі даних;
    • - Growth By Month (зростання на місяць) - кількість примірників суті, яке може додаватися протягом місяця використання бази даних;
  • • Definition (опис) - короткий опис смислового наповнення сутності;
  • • Notes (коментарі) - додаткові змістовні коментарі до суті, відображають особливості її подальшого використання у фізичній моделі і бази даних;
  • • інші характеристики.

image152

Мал. 3.5. / Діалогове вікно опису характеристик сутності в ККУіп


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

Визначивши сутність, розробник за допомогою контекстного меню "Attribute Properties" (властивості атрибута) переходить до опису атрибутів обраної суті. У верхній частині (рис. 3.6) діалогового вікна дає можливість розробнику моделі бази даних перемикатися між наявними в моделі сутностями, автоматично відображаючи певні для неї атрибути. Отримавши список атрибутів, за допомогою відповідних піктограм панелі інструментів діалогового вікна, виконують додавання, видалення і безліч інших дій з розміщення атрибутів по суті. Особливо може виявитися важливим сортування атрибутів, оскільки в базі даних, коли буде формуватися набір метаданих про об'єкти бази даних, порядок створення атрибутів буде грунтуватися на початку певному в логічній, а згодом у фізичній моделі бази даних. Тому, коректне і об'єктивно доцільне розташування атрибутів в послідовності може позначитися на ефективності роботи з атрибутами. При цьому, одне з правил Кодда передбачає незалежність від порядку атрибутів в таблицях, що і реалізується в базах даних, але, оскільки мова обробки даних SQL досить універсальний і дозволяє виконувати деякі операції по обробці полів таблиць без вказівки їх найменувань і послідовності, то в СУБД необхідно мати відомості про порядок створення полів таблиць, що визначається ще на рівні логічної моделі бази даних.

image153

Мал. 3.6. Область вибору атрибутів сутності для редагування


Крім вказівки набору і порядку атрибутів розробник в цій же частині діалогового вікна може визначити деякі базові характеристики:

  • • Name (назва) - повне найменування атрибута, яке буде відображатися в моделі і, при створенні бази даних, буде трансформовано в поле таблиці;
  • • Parent Domain (батьківський домен) - універсальний тип даних, який визначає базові умови обробки даних і дозволяє обмежити список типів даних, якими буде описуватися атрибут:
  • - Blob - бінарний домен, який використовується зазвичай для опису даних, які подаються у вигляді великих бінарних даних, таких як звукові, відео, зображення і т.д .;

DatcTime - домен уявлення тимчасових даних, що включають в себе типи даних "Дата", "Час" або їх комбінацію, а також подання до цифровому вигляді у вигляді кількості секунд від деякої, визначеної СУБД або операційною системою, дати;

  • - Number - числовий домен, що надає можливість визначити атрибути з використанням різних цілочисельних і речових даних;
  • - String - символьний домен, який визначає безліч типів даних, що описують відомості, що подаються з використанням різних символів, включаючи великі текстові відомості;
  • • Logical Data Туре (логічний тип даних) - уявлення типу даних, якому повинні відповідати відомості, що подаються розглядаються атрибутом;
  • • Primary Key (первинний ключ) - вказівка ​​на необхідність подання атрибута в якості первинного ключа, що призводить до необхідності опису правил подання та обробки даних відповідного атрибута;
  • • Foreign Key (зовнішній ключ) - вказівка ​​на використання атрибута як зовнішній ключ, що визначається наявністю відповідного типу зв'язку між сутностями;
  • • Logical Only (тільки логічний) - вказівка ​​на необхідність використання атрибута лише на логічному рівні моделювання бази даних.

Перераховані характеристики є обов'язковими для визначення при описі кожного атрибута сутності і саме тому розташовані в базовій (верхньої) частини опису атрибутивного складу суті. Але, поряд з цим описом, кожен атрибут може бути описаний рядом додаткових параметрів, серед яких виділяються умовчання, обмеження, індекси (групи ключів) і т.д. Додатково до основних характеристик атрибута додається параметр, який визначає можливість зберігання порожніх значень (NULL), для чого використовується закладка "General" допоміжної області діалогового вікна (рис. 3.7).

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

image154

Мал. 3.7. Діалогове вікно редагування властивостей атрибутів


Друга закладка опису властивостей атрибутів сутності використовується для вказівки двох характеристик: замовчування і обмеження значення (правило), рис. 3.8.

image155

Мал. 3.8. Встановлення для атрибута властивостей умовчання і правил в ЕКМЧп


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

Правила обмеження значень використовуються розробниками з метою не дати користувачеві можливість при роботі з базою даних вказати значення для атрибута, що не задовольняє заданому логічному правилом. Це правило автоматично перевіряється в СУБД при спробі внести якесь значення у відповідне поле таблиці. І тільки після успішної перевірки, коли значення буде відповідати всім зазначеним для поля правилами, це значення буде записано в базу даних. Однак для цього властивості атрибута є важливе обмеження - воно використовується тільки для самого атрибута і тільки в межах однієї таблиці. Це обмеження вимагає від розробника формулювання обмежень тільки але кожному конкретному атрибуту і використання тільки значення даного атрибута. Правила для обмежень значень можуть бути трьох видів: призначені для користувача (User-Defined), коли сам розробник визначає умови перевірки, де можуть бути досить складні логічні конструкції; мінімаксні (MinМах), де розробником задаються мінімальне і максимальне значення для атрибута; спискові (Valid Values), де розробник вказує можливі значення, які можуть розміщуватися для розглянутого атрибута.

Оскільки одні й ті ж правила можуть застосовуватися для різних атрибутів, то в ERWin надана можливість вказівки об'єкта "Правило" (Validation Rule), яке згодом накладається на той атрибут, який повинен задовольняти цим правилом. Це дозволяє не дублювати однакові правила, а застосовувати шаблон правила.

Для завдання обмеження в ERWin і по багатьом іншим об'єктам моделі використовується механізм макро-мови, який дозволяє, нс використовуючи явні назви елементів моделі (сутності, атрибути і т.д.), вказати універсальне правило, де замість назви атрибута буде врахована макро-змінна (% AttFieldName), яка вказує на використання імені атрибута, для якого встановлюється правило обмеження (рис. 3.9).

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

  • • Quote Value (значення в лапках) - це властивість дає можливість встановити мінімаксне обмеження на символьні атрибути або атрибути дати і часу, оскільки для них необхідно, щоб значення обрамляють лапками або апострофами, в залежності від правил СУБД;
  • • Invert Expression (зворотне правило) - це властивість створює правило зі зворотним істинністю щодо базового уявлення (наприклад, для правила на рис. 3.9 вираз буде визначати властивість невходження значення в зазначений мінімаксний діапазон).

image156

Мал. 3.9. Встановлення минимаксного обмеження на значення в ERWin


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

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

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

% AttFieldNamc BETWEEN 2010 AND 2014 правило показує, що значення атрибута повинно знаходитися в діапазоні від 2010 до 2014 року, включаючи межі діапазону;

•% AttFieldName IN ( "Чоловічий", "Жіночий") - правило визначає, що можливими значеннями можуть бути "Чоловічий" і "Жіночий", а значення атрибута повинні відповідати тільки цього списку.

Коли ж розробник визначає правило у вільній формі, то важливо використовувати стандартний інструментарій мови SQL, що застосовується в СУБД для логічних виразів, в частині логічних зв'язок і виразів, допустимих для побудови таких правил. Серед них можна виділити наступні:

  • - Between - розміщення значення в діапазоні;
  • - In - збіг значення з одним із зазначених у списку;

like - входження значення в рядок або збіг з рядком.

image157

Мал. 3.10. Встановлення правила на допустимі значення в ERWin


Також в правилах обмежень використовуються логічні порівняння "більше", "менше", "дорівнює" і ін. У разі використання заперечення застосовується директива NOT "НЕ", а для зв'язок декількох логічних правил застосовуються AND "І" та OR "АБО".

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

Для установки значення за замовчуванням в ERWin використовується права частина закладки "Constraint" (обмеження) з назвою "Default" (замовчування, рис. 3.11).

image158

Мал. 3.11. Область встановлення умовчання для атрибута в Е11Ут


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

image159

Мал. 3.12. Завдання значення але замовчуванням в ERWin


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

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

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

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

кілька атрибутів; тип ключа (Туре), що подаються варіантами: РК первинний ключ, FK - зовнішній ключ, АК - альтернативний ключ і т.д .; унікальність значень (Is Unique), що визначає неможливість наявності однакових комбінацій значень але зазначеним в групі атрибутів.

image160

Мал. 3.14. Редагування характеристик ключа в ERWin


ERWin надає розробнику можливість визначити кілька видів ключів:

  • • Primary Key - первинний ключ, сукупність значень атрибутів якого повинна бути унікальною в усій сукупності примірників сутності;
  • • Foreign Key - зовнішній ключ, значення якого не вимагає умови унікальності і вказує на екземпляр пов'язаної сутності;
  • • Alternate Key - альтернативний ключ, який застосовується для встановлення унікальних значень на сукупність значень включених в нього атрибутів;
  • • Inversion Entries - групи атрибутів, за якими необхідно організовувати не унікальні індекси з метою оптимізації виконання запитів до бази даних.

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

Правило єдиності ключа

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

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

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

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

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

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

 
<<   ЗМІСТ   >>