- •Тема лекції 7:
- •Рівні проектування реляційної бази даних
- •Поняття в проектуванні баз даних
- •Співвідношення понять у проектуванні БД
- •Моделювання даних
- •Процес моделювання даних
- •Моделі методології «сутність-зв’язок»
- •Концептуальна модель
- •При побудові концептуальної моделі виконуються наступні дії
- •Логічна модель даних
- •При переході від концептуальної моделі до логічної виконується
- •Логічна модель
- •Фізична модель даних
- •AllFusion ERwin Data Modeler
- •Компоненти інфологічної моделі
- •Сутності
- •Формальні означення поняття сутності
- •Супутні означення поняття сутності
- •Означення атрибутів сутностей
- •Означення зв’язку між сутностями
- •Бінарний зв’язок
- •Зв’язок типу «один-до-одного»
- •Зв’язок типу «один-до-багатьох»
- •Зв’язок типу «багато-до-багатьох»
- •При переході до реляційної моделі
- •Концептуальне моделювання даних
- •Зображення інфологічних моделей
- •Способи збору інформації для інфологічного моделювання. 1:
- •Способи збору інформації для інфологічного моделювання. 2:
- •Пріоритетність інформаційного проектування
- •Використання CASE-засобів
- •Способи збору інформації для інфологічного моделювання. 3:
- •Складні структури даних предметної області
- •Бізнес-правила
- •Бізнес-правила. Приклади
- •Бізнес-правила. Типи
- •Словник або каталог даних
- •Методологія «сутність-зв’язок»
- •Нотації в методології «сутність-зв’язок»
- •Поняття ідентифікованого та неідентифікованого зв’язку
- •Поняття ідентифікованого та неідентифікованого зв’язку
- •Поняття ідентифікованого та неідентифікованого зв’язку
- •Методології IDEF
- •Дякую за увагу
Бінарний зв’язок
це зв’язок між двома сутностями
це основний тип зв’язку.
Бінарний зв’язок буває
«один-до-одного» (1:1),
«один-до-багатьох» (1: n)
«багато-до-багатьох» (n : m).
Зв’язок типу «один-до-одного»
означає, що один екземпляр першої сутності зв’язаний не більше ніж з одним екземпляром другої сутності і навпаки, один екземпляр другої сутності зв’язаний не більше ніж з одним екземпляром першої сутності
Зв’язок типу «один-до-багатьох»
означає, що один екземпляр першої сутності зв’язаний з декількома екземплярами другої сутності. При цьому один екземпляр другої сутності зв’язаний не більше ніж з одним екземпляром першої сутності. Сутність з боку «один» називається батьківською, а зі сторони «багато» – дочірньою.
Це найпоширеніший тип зв’язку.
Зв’язок типу «багато-до-багатьох»
означає, що кожен екземпляр першої сутності може бути зв’язаний з кількома екземплярами другої сутності, і кожен екземпляр другої сутності може бути зв’язаний з декількома екземплярами першої сутності.
У логічній моделі реляційної бази даних зв’язок «багато-до-багатьох» повинен бути замінений шляхом створення проміжної сутності.
При переході до реляційної моделі
сутності повинні визначатись як таблиці,
ключ сутності є альтернативою реляційному ключу,
атрибути сутностей визначаються як поля таблиць,
екземпляри сутностей визначаються як записи з даними у відповідних таблицях.
Концептуальне моделювання даних
це початковий етап моделювання предметної області
реалізується за допомогою інфологічного (семантичного) моделювання, яке представляє собою моделювання структури даних на основі змісту цих даних.
Зображення інфологічних моделей
основний спосіб – графічний
у якості інструменту використовуються різні види діаграм «сутність-зв’язок»
(ER (Entity-Relationship) або ERD).
За допомогою ER-діаграм визначаються важливі для предметної області об’єкти (сутності), їх властивості (атрибути) і зв’язки між ними.
Способи збору інформації для інфологічного моделювання. 1:
Найпростіший неформальний спосіб – це взяти опис предметної області (можливо, отриманого у процесі проведення інтерв’ю з замовником) і виділити в ньому іменники і дієслова.
іменники – це кандидати на роль сутностей,
дієслова – кандидати на роль зв’язків.
Зауважимо, що такий підхід є дуже приблизним і кожна отримана сутність- кандидат повинна перевірятись колективом аналітиків.
Способи збору інформації для інфологічного моделювання. 2:
отримати список сутностей на основі формального опису бізнес-процесів системи, наприклад, за допомогою
діаграм бізнес-процесів (Business Process Diagram)
діаграм потоків даних (Data Flow Diagram
– DFD)
діаграми варіантів використання (Use Case Diagram) можуть замінити діаграми бізнес-процесів та діаграми потоків даних
Пріоритетність інформаційного проектування
побудова моделі даних повинна передувати функціональній специфікації.
Такий підхід дає наступні переваги.
Багаторазове використання даних для функцій, які не передбачаються на момент побудови моделі.
Встановлення стійких домовленостей щодо імен та ідентифікаторів даних. Наприклад, «отримати відомості про клієнта» та «обслужити замовника». Тут виникає питання, чим замовник відрізняється від клієнта.
Автоматичне отримання значної частини функціональної специфікації з побудованої моделі даних.
Визначення концепції, за допомогою якої можна краще зрозуміти і визначити предметну область: що в ній відбувається, що потрібно реалізувати, а що пропустити, і т.д.