Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Системи СУБД / Лек7-БД.ppt
Скачиваний:
82
Добавлен:
12.02.2016
Размер:
115.2 Кб
Скачать

Використання CASE-засобів

AllFusion Process Modeler (раніше називався Bpwin)

AllFusion ERwin Data Modeler

редактори Use Case Diagram

Способи збору інформації для інфологічного моделювання. 3:

складні структури даних предметної області

бізнес-правила

каталог даних

Складні структури даних предметної області

це ненормалізовані структури даних, які грають певну роль в ПО.

Такими структурами, наприклад, можуть бути поняття «замовлення», «рахунок», «журнал відвідувань» та ін.

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

Бізнес-правила

описують правила роботи з даними, які зв’язані лише з предметною областю і є незалежними від способу представлення цих даних в базі даних

можуть задаватись при проектуванні бази даних як обмеження на дані,

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

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

Бізнес-правила. Приклади

на посаду бухгалтера можна приймати людину з вищою фінансовою або економічною освітою;

податок з продажу знімається з кожного проданого товару і він рівний 30%;

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

Бізнес-правила. Типи

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

факт, тобто таке бізнес-правило, яке описує зв’язок або відношення між двома типами об’єктів, наприклад, «на Різдво покупець отримує або подарунок (сутність) або скидку (атрибут), але не все разом»

правило виведення, яке визначає, яким чином екземпляри однієї сутності можуть бути отримані з екземплярів іншої сутності

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

Словник або каталог даних

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

складні структури даних,

вже знайдені сутності, атрибути (можливо, без сутностей) і зв’язки.

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

Методологія «сутність-зв’язок»

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

Мета цієї роботи –проектне рішення, яке:

являє собою набір об’єктів системного каталогу цільової СУБД;

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

підготовлене до передачі в цільову СУБД шляхом виконання згенерованого DDL- скрипта (Data Definition Language) в синтаксисі вибраної СУБД.

Нотації в методології «сутність-зв’язок»

При моделюванні на рівні ER- діаграм існують різні нотації – різне графічне представлення ER-діаграм

Чена

Баркера,

IDEF1X

IE-нотація

UML

Поняття ідентифікованого та неідентифікованого зв’язку

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

Такі атрибути в дочірній сутності підлягають під визначення зовнішнього ключа.

Позначається неідентифікований зв’язок штриховою лінією.

Соседние файлы в папке Системи СУБД