Повна версія

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

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


<<   ЗМІСТ   >>

Нотація Мартіна (Crow's Foot)

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

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

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


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

Таблиця 2.15

Позначення в моделі бази даних але нотації Мартіна

п / п

позначення

опис

1

сутність

сутність

2

-1 --------------- 1--

Зв'язок 1: 1

3

-1 ---------------- <

Зв'язок 1: ЛГ

4

> -------------------- <

Зв'язок Л Г : Л /

5

-н ​​--------------- © <

Зв'язок з вказаною потужністю (кардинально)



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

image89


Мал. 2.49. Приклад опису суті в нотації Мартіна

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

image90

Мал. 2.50. Приклад встановлення зв'язку в нотації Мартіна


Проте, оскільки не завжди можна однозначно розділити суті на "ліву" і "праву", розробниками вказується змістове наповнення зв'язку двома дієслівними формами, аналогічно тому, як це робилося при розгляді моделі в нотації Чена. Коли визначається смислове наповнення (рис. 2.51) двома дієслівними формами, то вони можуть розміщуватися двома способами:

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

image91

Мал. 2.51. Приклад смислового наповнення зв'язку в нотації Мартіна


Для представленого прикладу, як і в нотації Чена, розробник змушений виділити допоміжну функціональну сутність "Товар замовлення" з метою вказівки атрибута "Кількість", який не може бути віднесений до сутностей "Товар" і "Замовлення". Це в нотації Мартіна буде представлено, як показано на рис. 2.52.

image92

Мал. 2.52. Подання функціональної сутності-зв'язки в нотації Мартіна


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

При описі зв'язків, на відміну від нотації Чена, кардинальність встановлюється не у вигляді текстових позначень, а відповідними графічними уявленнями на зв'язку. Так, коли потрібно вказати, що в зв'язку у відповідній суті можуть бути відсутніми пов'язані екземпляри, то на відповідному кінці буде позначатися гурток, як, наприклад, між сутностями "Клієнт" і "Замовлення", де примірник клієнта може бути представлений в базі даних, що не маючи жодного замовлення. При цьому, коли вказується кардинальність для зв'язку в напрямку сутності "Клієнт", то вказується дві вертикальні риси, що позначають, що екземпляр клієнта, який формує замовлення, обов'язково повинен існувати. Множинність кардинальності в нотації Мартіна позначається "воронячою лапкою" (Crow's Foot) у вигляді кінцевого елемента.

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

image93

Мал. 2.53. Приклад вказівки зв'язку категоризації в нотації Мартіна


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

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

image94

Мал. 2.54. Приклад зв'язку між сутностями "Юридична особа" і "Банк"


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

image95

Мал. 2.55. Приклад моделі бази даних в нотації Мартіна


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

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

 
<<   ЗМІСТ   >>