- •Часть I. Теория баз данных
- •Глава I. Системы файлов и базы данных
- •Оценка системы файлов
- •1.2. Понятие базы данных и системы управления базами данных.
- •1.3 Архитектура бд
- •Концептуальная модель
- •Внутренняя модель
- •Физическая модель
- •1.4 Модели баз данных
- •1.4.1 Иерархическая модель данных
- •1.4.2 Сетевая модель данных
- •1.4.3 Реляционная модель данных
- •Нормализация отношений
- •Первая нормальная форма
- •Вторая нормальная форма
- •Третья нормальная форма
- •Нормальная форма Бойса-Кодда
- •Четвертая нормальная форма
- •Пятая нормальная форма
- •Денормализация
- •Методы реализации денормализации
- •1.4.4. Объектно-ориентированная модель данных
- •1.4.4.1. Атрибуты
- •1.4.4.2. Состояние объекта. Сообщения и методы
- •1.4.4.3. Классы
- •1.4.4.4. Протокол
- •1.4.4.5. Суперклассы, подклассы, наследование
- •1.4.4.6. Единичное наследование. Множественное наследование.
- •1.4.4.7. Переопределение методов и полиморфизм
- •1.4.4.8. Абстрактные типы данных
- •1.4.4.9. Классификация объектов
- •1.4.4.10. Свойства объектно-ориентированных моделей данных
- •1.5.1 Сущности
- •1.5.2 Атрибуты
- •1.5.3. Связи
- •1.5.4. Сравнение обозначений в er-моделировании
- •1.5.5. Разработка er-диаграмм
1.5.4. Сравнение обозначений в er-моделировании
Обозначения, которые использовались до настоящего времени типичны для моделей «птичья лапка». Но существуют и другие ER-стили, например модель Чена, Rein85, IDEF1X. Хотя все эти модели основаны на одних и тех же концепциях моделирования, в них разработаны дополнительные стили, которые проще приспосабливаются к компьютерным инструментальным средствам моделирования (computer-assisted systems engineering, CASE).
Модель Гена предложена Питером Ченом (Peter Chen) в основополагающей работе ‘The Entity-Relationship Model. Toward a United View of Data’ (ACM, Transactions of Database System 1(1), March, 1976). Модель Чена переводит концептуальное моделирование в практическую плоскость проектирования БД, предлагая в качестве основных функциональных блоков сущности и связи. Основные структуры в модели Чена, расширенные в работе Теори, Янга и Фрая, доминировали на рынке средств CASE в конце 1980-х годов. Хотя модель Чена в настоящее время и не лидирует на рынке генераторов ER-диаграмм, все современные средства своими корнями уходят в модель Чена.
Модель «птичья лапка», разработанная К.В. Бахманом, стала популярным инструментом моделирования. Вместо использования символьного стиля Чена при обозначении связей (1 и М) и мощности (0,1), (P, N), (1, 1), (1, N) в этой модели используются графические обозначения. Информация о связности и мощности связи совмещается в едином наборе символов. В отличие от модели Гена, эта модель позволяет обозначить лишь три значения мощности 0, 1 или N. Например, в модели «птичья лапка» невозможно отобразить мощность (5, 25).
Модель Rein 85 разработана Д.Рекером в 1985г. Хотя она основана на тех же концепциях, что и модель «птичья лапка», система обозначений другая, она оперирует на более высоком уровне абстракции. В этой модели невозможно явно указать ощность, для ее обозначения используются связи.
Модель IDEF1X стала результатом исследований интегрированных систем автоматизированного производства (ICAM), которые проводились в 1970-х годах. ICAM стала источником графических методов определения функций, структур данных и динамики развития промышленных предприятий. Интеграция этих методов получила название IDEF. Оригинальная версия IDEF получила название IDEF1. Расширенная версия этой модели, которая называется IDEF1X получила признание как основное промышленное инструментальное средство моделирования данных.
На рис. 29 представлено сравнение обозначений в ER-моделях.
Рис. 29. Сравнение обозначений в ER-моделях
Рассмотрим модель выписки счетов с использованием четырех методов.
Установлены следующие бизнес правила:
в моделях учета счетов полагаем, что список CUSTOMER (клиент) содержит и потенциальных и действующих клиентов. Следовательно, клиент в этом списке мог еще и не сделать ни одной покупки, что инициировало бы выписку счета, т.е. сущность INVOICE необязательна для сущности CUSTOMER;
некоторые товары, хранящиеся в инвентарном списке, никогда не продавались и поэтому никогда не присутствовали в счетах, т.е. сущность INVOICE необязательна для сущности PRODUCT (товар). Связь M:N между INVOICE и PRODUCT реализуется через промежуточную сущность LINE для того, чтобы разбить связь M:N на две связи 1:М. Таким образом, сущность LINE (строка) необязательна для сущности PRODUCT, поскольку непродаваемый товар никогда не появлялся в строке счета.
На рис. 30-33 представлены системы учета счетов в различных моделях.
Рис. 30. Представление системы учета счетов с помощью модели Чека
Рис. 31. Представление системы учета счетов с помощью модели “Птичья лапка”
Рис. 32. Представление системы учета счетов с помощью модели Rein85
Рис. 33. Представление системы учета счетов с помощью модели IDEF1X
