Сутність (Entity) - реальний чи абстрактний об'єкт, має істотне значення для предметної області. Сутність повинна мати найменування, виражене іменником в однині

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

Примірник сутності – це конкретний представник цієї сутності. Наприклад, екземпляром сутності Співробітника може бути співробітник Іванов.

Кожна сутність повинна мати такі властивості:

мати унікальне ім'я;

мати один або кілька атрибутів, які або належать сутності, або успадковуються через зв'язок;

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

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

Існують такі види атрибутів:

простий – складається з одного елемента даних;

складовий - складається з кількох елементів даних;

однозначний - містить одне значення однієї сутності;

багатозначний містить кілька значень для однієї сутності;

необов'язковий – може мати порожнє (невизначене) значення;

похідний - значення, похідне значення іншого атрибута.

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

Кожна сутність може мати будь-яку кількість зв'язків з іншими сутностями.

Зв'язки між сутностями

Зв'язок (Relationship) - названа асоціація між сутностями, значуща для аналізованої предметної області.

Ступенем зв'язку називається кількість сутностей, що у зв'язку.

Потужність зв'язку - кількість екземплярів сутності, що у зв'язку.

Залежно від значення потужності зв'язок може мати один із трьох типів:

один до одного (позначається 1:1).

одним-багатьом (позначається 1: N).

багато-багатьом (позначається M: N).

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

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

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

3 . Компоненти моделі даних

Сутність (entity), визначення сутності, джерела інформації про сутності

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

3.1 Сутності

Сутність це щось таке, про що потрібно зберігати інформацію в базі даних.

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

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

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

Атрибут.

Предметна область.

Банк даних. Визначення.

СУБД. Визначення.

База даних. Визначення.

Третя нормальна форма. Визначення. приклад.

Змінна відношення R знаходиться в третій нормальній формі тоді і тільки тоді, коли виконуються такі умови:

· R знаходиться у другій нормальній формі.

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

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

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

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

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

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

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

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

Перерахуйте функції СУБД

Основні функції СУБД:

1) Визначення структури створюваної бази даних, її ініціалізація та проведення початкового завантаження.

2) Надання користувачам можливості маніпулювання даними (вибірка необхідних даних, виконання обчислень, розробка інтерфейсу введення/виводу, візуалізація).

3) Забезпечення логічної та фізичної незалежності даних.

4) Захист логічної цілісності бази даних - достовірність даних може бути порушена при їх введенні в БД або при неправомірних діях процедур обробки даних, які отримують та заносять у БД неправильні дані. На підвищення достовірності даних у системі оголошуються звані обмеження цілісності.

5) Захист фізичної цілісності – засоби відновлення бази даних (транзакції).

6) Управління повноваженнями користувачів доступу до бази даних.

7) Синхронізація роботи кількох користувачів.

8) Управління ресурсами середовища зберігання - СУБД виділяє ресурси пам'яті для нових даних, перерозподіляє пам'ять, що звільнилася, організує ведення черги запитів до зовнішньої пам'яті тощо.

9) Підтримка діяльності системного персоналу

Термін "реляційний" означає "заснований на відносинах". Реляційна база даних складається з сутностей (таблиць), що у певному відношенні друг з одним. Назва походить від англійського слова relation-відношення.
Проектування бази даних і двох основних фаз: логічного і фізичного моделювання.
Під час логічного моделювання ви збираєте вимоги і розробляєте модель бази даних, яка залежить від конкретної СУБД (системи управління реляційними базами даних). Це схоже на те, якби ви створювали креслення вашого будинку. Ви могли б продумати та накреслити все: де буде кухня, спальні, вітальня. Але це все на папері та в макетах.
Під час фізичного моделювання ви створюєте модель, оптимізовану для конкретної програми та СУБД. Саме ця модель реалізується практично. Якщо повернутися до будинку з попереднього абзацу, на цьому етапі вам доведеться будувати десь будинок - тягати колоди, цеглини.

Процес проектування бази даних складається з наступних етапів:

• збір інформації;
• визначення сутностей;
• визначення атрибутів кожної сутності;
• визначення зв'язків між сутностями;
• нормалізація;
• перетворення до фізичної моделі;
• створення бази даних.

Перші 5 етапів утворюють фазу логічного проектування, інші два - фазу фізичного моделювання.

Логічна фаза

Логічна фаза складається з кількох етапів. Далі всі вони розглянуті.

Збір вимог

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

Визначення сутностей

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

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

Сутності складаються з атрибутів (стовпців таблиці) та записів (рядків у таблиці).

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

Будь-яка таблиця має такі характеристики:

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

На цьому етапі вам необхідно виявити всі категорії інформації (сутності), які зберігатимуться у базі даних.

Визначення атрибутів

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


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

Ключі

Ключем (key) називається набір атрибутів, що однозначно визначає запис. Ключі діляться на два класи: прості та складові.
Простий ключ складається лише з одного атрибуту. Наприклад, у базі «Паспорта громадян країни» номер паспорта буде простим ключем: адже немає двох паспортів з однаковим номером.
Складовий ключ складається з кількох атрибутів. У тій самій базі «Паспорта громадян країни» може бути складовий ключ із наступними атрибутами:
прізвище, ім'я, по батькові, дата народження. Це - як приклад, тому що цей складовий ключ теоретично не забезпечує гарантованої унікальності запису.
Також існує кілька типів ключів, про які розповідається далі.

Можливий ключ

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

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

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

Альтернативні ключі

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

Зовнішні ключі

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

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

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

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

Один до одного

Кожному запису першої сутності відповідає лише один запис з другої сутності. А кожному запису другої сутності відповідає лише один запис із першої сутності. Наприклад, є дві сутності: Люди та Свідоцтва про народження. І в однієї людини може бути лише одне свідчення про народження.

Один-до-багатьом

Кожен запис першої сутності може відповідати кілька записів з другої сутності. Однак кожному запису другої сутності відповідає лише один запис із першої сутності. Наприклад, є дві сутності: Замовлення та Позиція замовлення. І в одному замовленні може бути багато товарів.

Багато хто багатьом

Кожен запис першої сутності може відповідати кілька записів з другої сутності. Однак і кожний запис другої сутності може відповідати кілька записів з першої сутності. Наприклад, є дві сутності: Автор та Книга. Один автор може написати багато книжок. Але книга може мати кілька авторів.
За критерієм обов'язковості відносини поділяються на обов'язкові та необов'язкові.

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

Нормалізація

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

Перша нормальна форма

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

Для приведення сутності Будинок в першу нормальну форму необхідно видалити групи значень, що повторюються, тобто видалити атрибути Власник 1-3, помістивши їх в окрему сутність. Результат (Сутність Будинок, наведена до першої нормальної форми):

Друга нормальна форма

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

Третя нормальна форма

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

Обмеження

Обмеження (Constrains)- це правила, дотримання яких стежить система управління бази даних. Обмеження визначають безліч значень, які можна вводити в стовпець чи стовпці.
Наприклад, ви не хочете, щоб сума замовлення у вашому дуже крутому магазині була б меншою за 500 рублів. Ви просто встановлюєте обмеження на стовпчик Сума замовлення.

Збережені процедури

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

ПРИМІТКА
Процедури, що зберігаються, знаходяться в базі даних і виконуються на сервері бази даних. Зазвичай, вони швидше операторів SQL, оскільки зберігаються у компильованому вигляді.

Цілісність даних

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

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

Тригери

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

Ділові правила

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

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

Всі ці можливості можна застосовувати для реалізації ділових правил у базі даних.

Фізична модель

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

Денормалізація

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

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

Сьогодні мова піде про модель «сутність-зв'язок», або entity-relationship model.

Теорія

Модель “сутність-зв'язок” (Entity-Relationship model або ER – модель) є високорівневою концептуальною моделлю даних, яка була розроблена з метою спрощення завдання проектування структур баз даних.

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

Мета діаграм "сутність-зв'язок" - це створити точне і повне відображення реальної предметної області (ПрО), що використовується надалі як джерело інформації для побудови бази даних автоматизованих систем обробки інформації (БД АСОІ).

Ця діаграма чи концептуальна модель ПрО має відповідати таким вимогам:

• Забезпечувати адекватне відображення ПРО;
• Представляти мовою, зрозумілою як майбутнім користувачам АСОІ, так і розробникам БД;
• утримувати інформацію про ПрО, достатню для подальшого проектування БД (розробка логічної та фізичної моделей);
• Гарантувати однозначну інтерпретацію чи тлумачення моделі ПрВ.

Основні концепції цієї моделі - поняття сутність, атрибут та зв'язок.

СУТНІСТЬ- Це безліч об'єктів реального світу з однаковими властивостями. Сутність характеризується незалежним існуванням і може бути об'єктом із фізичним (або реальним) існуванням або об'єктом із концептуальним (або абстрактним) існуванням.

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

Практика

ПРИКЛАД. Предметна область " Замовлення квитків у кінотеатрі”. У кінотеатрі показують фільми, квитки на які можна купити в день показу або забронювати заздалегідь. У базі даних знаходиться інформація про всі кінопокази в даному кінотеатрі, у тому числі про старі. У кожного кінопоказу свою вартість, тобто. квитки на той самий фільм, але в різний час, можуть відрізнятися за ціною. Кінопоказ складається з Фільму, інформація про який так само зберігається у БД.

Для ПрО “ Замовлення квитків у кінотеатрі” По суті виступатимуть такі поняття:

Кінопоказ

Фільми

Глядач

Квиток

Бронь

Вартість

Графічно сутності на діаграмах "сутність-зв'язок" представляються у вигляді прямокутників:

АТРІБУТ— це засіб, з допомогою якого визначаються властивості сутності чи зв'язку. Атрибут - це названа характеристика сутності. Найменування атрибута має бути унікальним для конкретної сутності, але може бути однаковим для різних сутностей.

Конкретний набір атрибутів для сутності визначається завданнями, у яких використовуються. Наприклад, сутність ПрО “Замовлення квитків у кінотеатрі” можна описати за допомогою наступної сукупності атрибутів:

Кінопоказ(Номер кінопоказу, Номер Фільму, Дата показу, Номер Вартість);

Фільм(Номер фільму, Назва, Тривалість, Короткий опис);

Глядач(Номер глядача, ПІБ, дата народження);

Квиток(Номер глядача, Номер кінопоказу, Вартість квитка);

Бронь(Номер глядача, номер кінопоказу, дата броні);

Вартість(Номер вартості, номер кінопоказу, вартість).

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

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

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

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

Найменування зв'язку має нести у собі певний сенс, щоб було легше дати раду тому, як співвідносяться сутності. Наприклад, взаємовідносини між сутностями Глядач і Білет можна визначити як "Купує".

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

Показник кардинальності зв'язку (характеристика однозначності) позначає ступінь взаємозв'язку сутностей та описує кількість можливих зв'язків кожної з сутностей-учасниць:

• один до одного (1:1);
• одним-багатьом (1: N);
• багато-багатьом (N: M).