Повна версія

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

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


<<   ЗМІСТ   >>

Нотація Пітера Чена

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

Позначення для моделі в нотації Чена

Таблиця 2.14

№ п / п

позначення

опис

1

сутність

Сутність ( Об'єкт)

Структурний елемент предметної області, що представляється об'єктом і що містить набір атрибутів

2

сутність

Залежна сутність ( Об'єкт )

Структурний елемент предметної області, екземпляри якого залежать від наявності даних але вихідному об'єкту

3

зв'язок

Елемент взаємодії сутностей (об'єктів) моделі із зазначенням смислового навантаження по предметної області

4

идентифицирующая зв'язок

Елемент взаємодії сутностей (об'єктів), де одна (один) з них є залежною (-им)

5

Атрибут

Атрибут

Характеристика сутності (об'єкта), що описує що представляється елемент даних

б

Атрибут

Первинний ключ

Характеристика сутності (об'єкта), своїми значеннями дозволяє однозначно виділити один екземпляр даних

7

Атрибут ^)

зовнішній ключ

Характеристика сутності (об'єкта), по якій здійснюється інформаційне зв'язування



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

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

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

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

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

Наприклад, для об'єкта "Фізична особа" таким атрибутом в предметної області "Електронний магазин" може бути атрибут "Особовий рахунок". Цей атрибут має унікальне значення на рівні всієї сукупності даних, не може повторюватися і однозначно закріплений за кожним конкретним клієнтом-покупцем. Цей же атрибут може бути первинним ключем для об'єкта "Юридична особа". Також для цього об'єкта первинним ключем може виступати атрибут "Ідентифікаційний номер платника податків (ІПН)", який також унікальний для кожної організації (юридичної особи).

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

image85

Мал. 2.45. Приклад зв'язку об'єктів в нотації Чена


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

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

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

Оскільки зв'язок категоризації (рис. 2.46) є окремим випадком зв'язку один - до - одному (1: 1), то цілком природним буде той факт, що між об'єктами встановлюється ідентифікує зв'язок, яка визначає однозначна відповідність між екземплярами пов'язують сутностей.

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

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

image86

Мал. 2.46. Приклад додавання в модель категорізаціонной зв'язку


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

Для об'єкта "Юридична особа" вказані два атрибути, один з яких, "ІПН", є первинним ключем. Його вказівку необхідно, оскільки взаємини фінансового характеру між юридичними особами, за правилами предметної області, повинні здійснюватися через документ "Рахунок", де цей атрибут є ідентифікує для організації (юридичної особи). Вказівка ​​в якості первинного ключа не є, в даному випадку, обов'язковою умовою для моделі, оскільки організацію буде характеризувати атрибут "Особовий рахунок", отриманий з об'єкта "Клієнт" на підставі правил подання ідентифікує зв'язку. Проте, зазначений в якості первинного ключа атрибут "ІПН» не порушує вимог представлення моделі.

У процесі побудови концептуальної моделі додавання об'єкта "Товар" (рис. 2.47) привело до появи зв'язку багато - до - багатьох (Л !: М), що допустимо з точки зору нотації Чена, але створює певну проблему - оскільки в замовленні, за умовами предметної області, для кожного зазначеного товару необхідно не тільки вказати ціну

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

image87

Мал. 2.47. Приклад додавання об'єкта "Товар"


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

image88

Мал. 2.48. Подання в моделі об'єкта "Товар гарту"


{ 1 Під зчепленим ключем розуміється сукупність атрибутів, які подаються в якості однотипного ключа.

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


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

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

 
<<   ЗМІСТ   >>