Проектирование логической модели базы данных методом "Сущность-связь" нотация IDEF1X
Давайте вспомним
Методология IDEF1X
Что это такое?
Цели существования
Важно знать и понимать!
Сущности и атрибуты
Рассмотрим пример
Сущности как есть
Сущности как есть
Сущности как есть
Сущности как есть
Рассмотрим пример
Немножко об атрибутах
Немножко об атрибутах
Немножко об атрибутах
Немножко об атрибутах
Немножко об атрибутах
Связи
Типы связей
Типы связей
Рассмотрим пример связей
Рассмотрим пример связей
Идентифицирующая связь
Идентифицирующая связь
Рассмотрим пример связей
Неидентифицирующая связь
Рассмотрим пример связей
Рассмотрим пример связей
Нормализация данных
Нормализация данных
Намана? Намана!
Первая нормальная форма
Вторая нормальная форма
Третья нормальная форма
BCNF — Нормальная форма Бойса-Кодда
Что когда применять?
Что дают нормальные формы?
Запоминайка, чтобы было легче понять
Примеры IDEF1X
Ситуация 2
Ситуация 2
Полная атрибутивная модель
Полная физическая модель
319.02K
Categories: softwaresoftware databasedatabase

Проектирование логической модели базы данных методом "Сущность-связь". Нотация IDEF1X. Лекция 11

1. Проектирование логической модели базы данных методом "Сущность-связь" нотация IDEF1X

ПРОЕКТИРОВАНИЕ ЛОГИЧЕСКОЙ
МОДЕЛИ БАЗЫ ДАННЫХ
МЕТОДОМ "СУЩНОСТЬ-СВЯЗЬ"
НОТАЦИЯ IDEF1X
Раздел 2. Методы проектирования и программирования ПО

2. Давайте вспомним

◦Что такое база данных?
◦Что такое модели данных?
◦Какие модели данных вы
знаете?
◦Что такое распределенная
информационная
система?

3. Методология IDEF1X

МЕТОДОЛОГИЯ
IDEF1X

4. Что это такое?

IDEF1X (Integration Definition for Information
Modeling, версия 1X) — это стандарт,
разработанный для моделирования данных и
проектирования реляционных баз данных.
Она используется для представления информационной
структуры предметной области и помогает проектировщикам
и аналитикам в создании логических моделей данных.

5. Цели существования

IDEF1X предназначен для:
◦формализации требований к данным;
◦построения логической модели данных;
◦упрощения проектирования реляционных баз
данных;
◦улучшения понимания структуры
информации среди участников проекта.

6. Важно знать и понимать!

IDEF1X — это логическая модель, не
физическая.
То есть она описывает что за данные, как они
связаны, какие правила существуют, но не
говорит, как эти данные будут физически
реализованы в СУБД (таблицы, индексы и т.д.).

7. Сущности и атрибуты

СУЩНОСТИ И
АТРИБУТЫ
Проектирование логической модели базы данных методом "Сущность-связь" нотация
IDEF1X

8. Рассмотрим пример

Сущности (Entities) – это классы объектов
реального мира, которые требуется описать в
БД.
Независимая сущность
Зависимая сущность

9. Сущности как есть

Сущности могут являться:
•физическим объектом (например,
Преподаватель, Здание);
• Абстрактным понятием (Курс, Проект, Заказ);
•событием (Платёж, Регистрация).
Но! Всегда описываются СУЩЕСТВИТЕЛЬНЫМ!

10. Сущности как есть

Сущность называется независимой, если каждый
экземпляр данной сущности может быть
уникально идентифицирован независимо от её
связей с другими сущностями. Имеет свой
уникальный идентификатор.
Сущность называется зависимой, если уникальная
идентификация её экземпляров зависит от связи
данной сущности с другими сущностями. Её
первичный ключ включает внешний ключ на родителя

11. Сущности как есть

Связующая сущность – используется для
реализации связи многие-ко-многим (M:N)

12. Сущности как есть

Каждая сущность должна:
•Иметь чётко определённое назначение;
• Иметь однозначный идентификатор (PK);
• Избегать дублирования информации (через
связи и нормализацию);
• Иметь атрибуты, которые логически
принадлежат именно ей.

13. Рассмотрим пример

Атрибуты (Attributes) - это образ характеристики или свойства,
которым обладают все экземпляры сущности.
•Идентифицирующие (Identifying): входят в состав первичного
ключа.
•Неидентифицирующие: обычные данные.
Сотрудник
— ID_Сотрудника (PK)
— Имя
— Фамилия

14. Немножко об атрибутах

Для обеспечения уникальности атрибута в
пределах модели используется составное имя:
<Имя-сущности>.<Имя-атрибута>
Например, для сущности Студент обращение к
его атрибуту Фамилия имеет вид
Студент.Фамилия

15. Немножко об атрибутах

При информационном моделировании атрибуты
принято подразделять на
• указывающие
• описательные
• и вспомогательные.

16. Немножко об атрибутах

Указывающие атрибуты используются для
присвоения имени или обозначения
экземплярам сущности.

17. Немножко об атрибутах

Например,
• Счет.Номер;
• Студент.Фамилия.
Если значение указывающего атрибута изменяется,
то это говорит о том, что изменился экземпляр
сущности.
Указывающие атрибуты часто используются как
идентификатор или часть идентификатора.

18. Немножко об атрибутах

Идентификатор – это атрибут или
совокупность нескольких атрибутов, значения
которых однозначно определяют каждый
экземпляр сущности.
Идентификатор, состоящий из нескольких
атрибутов, называется составным.
Идентификаторы называются также
первичными ключами.

19. Связи

СВЯЗИ
Проектирование логической модели базы данных методом "Сущность-связь" нотация
IDEF1X

20. Типы связей

Для описания каждой связи в IDEF1X используется набор параметров,
перечисленных ниже.
• 1. Имя в виде глагола, который определяет смысловую составляющую
связи (состоит из, входит в, делает,...).
• 2. Кардинальность (мощность): один к одному (1,1), один ко многим
(1,N), многие ко многим (M,N). Кардинальность иллюстрирует, какое
число экземпляров одной сущности определяется экземплярами
другой. К примеру, если Отдел состоит минимум из пяти Сотрудников,
то кардинальность будет выражаться в виде (1,5).
• 3.
Обязательность,
обязательно или нет.
заполнение
атрибутов
внешнего
ключа
• 4. Степень участия (количество сущностей, которые участвуют в
связи). Как правило, в одной связи участвуют две сущности. Связи, не
являющиеся бинарными или унарными, приводят к бинарному виду.

21. Типы связей

Изображение
Тип и обязательность
Кардина
льность
Обязательная, идентифицирующая
1
Обязательная, идентифицирующая
0.. ∞
Z
Обязательная, идентифицирующая
0 или 1
P
Обязательная, идентифицирующая
1.. ∞
Число Обязательная, идентифицирующая
<число>
Обязательная, неидентифицирующая
0.. ∞
Необязательная, неидентифицирующая
0.. ∞

22. Рассмотрим пример связей

Сотрудник
— ID_Сотрудника (PK)
— Имя
— Фамилия
1
Паспорт
1 — ID_Паспорт (PK)
— ID_Сотрудник (FK)
— Серия
— Номер
Один к Одному (1:1)

23. Рассмотрим пример связей

Клиент
— ID_Клиента (PK)
— Имя
— Фамилия
1
Заказ
0..* — ID_Заказа (PK)
—Номер_Позиции (РК)
— ID_Клиента (FK)
—ID_Товара (FK)
Один ко Многим (1:N)
ИДЕНТИФИЦИРУЮЩАЯ

24. Идентифицирующая связь

Идентифицирующая связь означает, что
зависимая сущность (дочерняя) не может
существовать без родительской, и её
первичный ключ (PK) включает в себя внешний
ключ (FK), указывающий на родителя.
То есть PK дочерней сущности "зависит" от PK
родительской.

25. Идентифицирующая связь

Один экземпляр родительской сущности
связан со многими экземплярами дочерней.
Но дочерний экземпляр обязательно связан с
только с одним родительским.

26. Рассмотрим пример связей

Преподаватель
— ID_Преподавателя (PK)
— Имя
— Фамилия
1
Курс
0..* — ID_Курса (PK)
— ID_Преподавателя (FK)
— Название
Один ко Многим (1:N)
Неидентифицирующая связь

27. Неидентифицирующая связь

Неидентифицирующая связь — это связь между двумя
сущностями, при которой:
• дочерняя сущность может существовать независимо от
родительской;
• внешний ключ (FK) на родительскую сущность не входит
в состав первичного ключа (PK) дочерней сущности.
То есть родитель нужен только для связи, но не
определяет уникальность дочерней записи.

28. Рассмотрим пример связей

Студент
— ID_Студента (PK) M
— Имя
— Фамилия
N
Регистрация
— ID_Студента (PK)
— ID_Курса (РК)
— Дата_записи
J
Курс
K — ID_Курса (PK)
Многие ко Многим (M:N)
Через связующую таблицу
— Название

29. Рассмотрим пример связей

Это такая логическая связь между двумя
сущностями, при которой:
• Один объект из первой сущности может быть связан
с несколькими объектами из второй.
• И наоборот: один объект из второй сущности — с
несколькими из первой.
Это не может быть реализовано напрямую в
реляционной базе данных — нужно использовать
промежуточную сущность (таблицу-связку).

30. Нормализация данных

НОРМАЛИЗАЦИЯ
ДАННЫХ
Проектирование логической модели базы данных методом "Сущность-связь" нотация
IDEF1X

31. Нормализация данных

Нормализация –
процесс уточнения и
перегруппировки
атрибутов в
сущностях в
соответствии с
нормальными
формами.

32. Намана? Намана!

Известны шесть нормальных форм. На
практике чаще всего ограничиваются
приведением модели данных к третьей
нормальной форме.

33. Первая нормальная форма

Первая нормальная форма (1NF) – все значения
атрибутов атомарны — то есть в одной ячейке одно
значение (а не список, таблица, массив и т.д.)
СтудентID Имя
Курс
СтудентID
Имя
Курс
1
Иванов
Математика,
Физика
1
Иванов
Математика
2
Петрова
Информатика
1
Иванов
Физика
2
Петрова
Информатика

34. Вторая нормальная форма

•Таблица уже в 1NF
•Каждый неключевой атрибут зависит от всего
первичного ключа, а не от его части (если ключ
составной)
Студент
Студент Курс
ИмяСтудента
ID
ID
НазваниеКурса
1
101
Иванов
Математика
1
102
Иванов
Физика
ID_студента
имя
СтудентКурс
ID_студента
ID_курса

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

•Таблица уже во 2NF
•Нет транзитивной зависимости между неключевыми
атрибутами и первичным ключом.
Курс
КурсID
НазваниеКурса
Преподаватель
Кабинет
101
Математика
Иванова
101-A
102
Физика
Петров
102-B
ID_курса
Название_курса
ID_преподавателя
Преподаватель
ID_преподавателя
ФИО
Кабинет

36. BCNF — Нормальная форма Бойса-Кодда

•Таблица в 3NF
•Для каждой зависимости X → Y, X — суперключ.
То есть: любая зависимость в таблице должна быть
определена суперключом.
BCNF — это усиленная версия 3NF, и чаще всего
нужна, когда в таблице есть альтернативные ключи,
между которыми могут возникать зависимости.

37. Что когда применять?

Форма
1NF
2NF
3NF
BCNF
Цель
Устранение вложенных
структур
Устранение частичных
зависимостей
Устранение транзитивных
зависимостей
Устранение неключевых
определяющих зависимостей
Когда применяется
Всегда
При составном
ключе
Всегда желательно
В продвинутых
случаях

38. Что дают нормальные формы?

✅ Устранение:
• Дублирования
• Аномалий вставки/удаления/обновления
✅ Улучшение:
• Целостности данных
• Читаемости структуры
• Гибкости при изменениях

39. Запоминайка, чтобы было легче понять

Нормальные формы — это как уборка в комнате:
• 1NF: всё разложено по отдельным ячейкам, нет
«пакетов с мусором».
• 2NF: ничего не лежит в неправильных местах — всё
зависит от полной причины.
• 3NF: никаких «вещей в вещах» — всё чётко по
категориям.
• BCNF: даже если есть альтернативные ключи — всё
равно порядок.

40. Примеры IDEF1X

ПРИМЕРЫ IDEF1X
Проектирование логической модели базы данных методом "Сущность-связь" нотация
IDEF1X

41.

1. На основе функциональной модели IDEF0
составим пул – список потенциальных
сущностей.
◦ Пул:
1. Дом
2. Крыша
3. Материалы
4. Проект дома
5. Стены
6. Строители
7. Фундамент
8. Каменщики
9. Плотники
10. Кровельщики
11. Мастера по отделке

42.

2. Определим сущности.
Проект дома
Материал
Дом
Строитель
Фундамент
Стены
Крыша
Каменщ ик
Кровельщ ик
Плотник
Мастер по отделке

43.

Проект дома
Материал
№_проекта
Код_материала
ФИО_архитектора
Дата_создания
Стоимость_проекта
Название
Вид_материала
Характеристики
используется
используется для
P
Строитель
P
Табельный_номер
Дом
ФИО
Профессия
Стаж_работы
Адрес
Адрес
ФИО_хозяина
строит
Фундамент
Стены
Крыша
№_проекта (FK)
Код_материала (FK)
Табельный_номер (FK)
Вид
Дата_сдачи
Z
Профессия
Z
Z
Z
Z
Каменщ ик
Кровельщ ик
Плотник
Мастер по отделке
Табельный_номер (FK)
Табельный_номер (FK)
Табельный_номер (FK)
Табельный_номер (FK)

44. Ситуация 2

45. Ситуация 2

Диаграмма «сущность-связь».
В данной системе присутствует восемь сущностей:
• Клиент – содержит сведения о человеке, заказывающим в прокат
видеофильмы;
• Фильм – содержит описание фильма;
• Копия фильма – описывает копию фильма для проката;
• Данные о прокате – содержит информацию о строках и
условиях проката;
• Оплата – содержит данные об оплате за прокат видеофильма;
• Чек – содержит сведения об оплате банковским чеком;
• Электронный платеж – содержит сведения об электронном
платеже;
• Кредитная карточка – содержит сведения об оплате кредитной
карточкой.

46. Полная атрибутивная модель

47. Полная физическая модель

English     Русский Rules