Этапы жизненного цикла приложений баз данных Планирование базы данных Определение системы Сбор и анализ требований Концептуальное проектирование Логическое проектирование Физическое проектирование Проектирование базы данных Выбор СУБД (необязат.этап) Проектирование приложений Разраб.прототипа (необязат.этап) Реализация Преобразование и загрузка данных Тестирование Эксплуатационное сопровождение 1
Таблица Основные действия на каждом этапе жизненного цикла приложения Этап Описание Примеры собираемых данных Примеры документации Планирование разработки БД Планирование наиболее эффективного способа реализации этапов жизненного цикла системы Целевые функции и технические требования к проекту БД Техническое задание и технические требования Определение требований к системе Определение диапазона действий и границ приложения БД, состава пользователей и областей применения Описание основных пользовательских представлений (включая должностные роли или область применения в бизнесе) Определение области действия и границ применения БД; определение поддерживаемых пользоват.представл. Сбор и анализ требований пользователей Сбор и анализ требований пользователей из всех возможных областей применения Требования для пользовательских представлений и системы Спецификации пользовательских и системных требований Проектирование БД Полный цикл разработки включает концептуальное, логическое и физическое проектирование БД Пользовательская реакция на логический проект БД; функциональные возможности рассматриваемой СУБД Концептуальный/логический проект БД (включает ER -модели, словарь данных и реляционную схему); физич. проект БД Выбор целевой СУБД (необяз. этап) Выбор наиболее подходящей СУБД для приложения БД Функциональные возможности рассматриваемой СУБД Оценка СУБД и подготовка рекомендаций Разработка приложений Определение пользовательского интерфейса и прикладных программ, Пользовательская реакция на проект интерфейса Проект приложения (включает описание программ и интерфейса пользователя) Создание прототипов (необязательный этап) Создание рабочей модели приложения БД, которая позволяет представить и оценить окончательный вид и способы функционирования системы Пользовательская реакция на прототип Модифицированные спецификации пользовательских и системных требований Реализация Создание внешнего, концептуального и внутреннего определения БД и прикладных программ Функциональные возможности разработанной СУБД Преобразование и загрузка данных Преобразование и загрузка данных (и прикладных программ) из старой системы в новую Формат существующих данных; возмож-ности импорта данных целевой СУБД Тестирование Приложение базы данных тестируется с целью обнаружения ошибок, а также его проверки на соответствие всем требованиям, выдвинутым пользователями Результаты проверки Применяемые методики тестирования; анализ результатов проверки Эксплуатация и сопровождение В случае необходимости в функциони- рующее приложение могут вноситься изменения, отвечающие новым требованиям. Результаты проверки производительности; новые или измененные пользовательские и системные требования Руководство пользователя; анализ ре- зультатов измерения производитель- ности; модифицированные специфика-ции пользоват. и системных требований 2
Концептуальное проектирование базы данных. Создание информационной модели предприятия, не зависящей от любых деталей реализации, например, таких как тип СУБД, язык программирования, аппаратная платформа, производительность, физическая организация БД Логическое проектирование базы данных. Конструирование информационной модели предприятия на основе существующих конкретных моделей данных (типа СУБД), но без учета используемой СУБД и прочих физических условий реализации. Физическое проектирование базы данных. Описание конкретной реализации базы данных, размещаемой во внешней памяти с учетом особенностей используемой СУБД. Физический проект описывает базовые отношения, определяет организацию файлов и состав индексов, применяемых для обеспечения эффективного доступа к данным, а также регламентирует все соответствующие ограничения целостности и меры защиты. 3
Создание локальных концептуальных моделей данных, исходя из представлений о предметной области каждого из типов пользователей Определение типов сущностей Определение типов связей Определение атрибутов и связывание их с типами сущностей и связей Определение доменов атрибутов Определение атрибутов, являющихся потенциальными и первичными ключами Проверка модели на отсутствие избыточности Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям Обсуждение локальных концептуальных моделей с пользователями 4
Создание локальной логической модели данных из концептуальной модели Устранение особенностей, несовместимых с реляционной моделью Определение набора отношений Проверка отношений с помощью правил нормализации Проверка соответствия отношений требованиям пользовательских транзакций Определение требований поддержки целостности данных Обсуждение локальных логических моделей с пользователями Создание и проверка глобальной логической модели данных путем слияния локальных моделей Обсуждение глобальной логической модели данных с пользователями 5
Перенос глобальной логической модели данных в среду целевой СУБД Проектирование базовых отношений в среде целевой СУБД Проектирование отношений, содержащих производные данные Реализация ограничений предметной области Проектирование физического представления данных Анализ транзакций Выбор файловой структуры Определение индексов Определение требований к дисковой памяти Разработка пользовательских представлений Разработка механизмов защиты Анализ необходимости введения контролируемой избыточности 6
1. Требования к данным Отделения Компания DreamHome имеет отделения во всех городах Великобритании. Каждое отделение укомплектовано определенным количеством сотрудников ; в их число входят менеджеры, которые управляют работой отделения. С каждым отделением связаны такие данные, как уникальный номер отделения, адрес (улица, город и почтовый индекс), номера телефонов (вплоть до максимального количества, равного трем) и имя сотрудника компании, который в настоящее время управляет работой отделения. О каждом менеджере хранятся дополнительные данные, которые включают дату вступления менеджера в должность руководителя данного отделения и ежемесячную премиальную оплату, основанную на результатах его работы на рынке аренды недвижимости. Каждое отделение предлагает клиентам целый ряд объектов недвижимости, сдаваемых в аренду. О каждом объекте недвижимости хранятся такие данные, как номер объекта недвижимости, адрес (улица, город, почтовый индекс), тип, количество комнат, ежемесячная арендная плата и сведения о владельце объекта недвижимости. Каждый номер объекта недвижимости является уникальным во всех отделениях. Каждым арендованным или предназначенным для сдачи в аренду объектом недвижимости управляет один из сотрудников компании. Ни один из сотрудников не может управлять более чем 100 объектами недвижимости одновременно. Объекты недвижимости, предназначенные для сдачи в аренду 7
2. Требования к транзакциям (пример) Ввод данных 1 ) Ввести сведения о новом отделении (например, об отделении ВООЗ в Глазго). 2) Ввести сведения о новом сотруднике отделения (например, о сотруднике Ann Beech отделения ВООЗ). 3) Ввести сведения о рекламе объекта недвижимости в газете (например, о том, что об объекте недвижимости с номером PG4 опубликовано рекламное объявление в газете Glasgow Daily 6 мая 2000 года). Обновление/удаление данных 1) Обновить/удалить сведения об отделении. 2) Обновить/удалить сведения о сотруднике отделения. 3) Обновить/удалить сведения об указанном договоре аренды в некотором отделении. Транзакции А. Составить список с номерами, адресами, обозначениями типа и арендной платы всех объектов недвижимости в Глазго, отсортированный по величине арендной платы. B. Составить список со сведениями о сдаваемых в аренду объектах недвижимости, которыми управляет указанный сотрудник. C. Определить общее количество объектов недвижимости каждого типа во всех отделениях. D. Составить отчет об осмотрах объектов недвижимости E. Сотрудник регистрирует потенциального клиента и его пожелания G. Определить имя и номер телефона владельца указанного объекта недвижимости 8
ER- модель ( Entity-Relationship model) представляет собой высокоуровневую концептуальную модель данных, не зависящую от конкретной СУБД или аппаратной платформы ER- модель представляет собой набор концепций, которые описывают структуру информационной модели предприятия и его потребностей Назначение ER- модели: Формализация пользовательского восприятия данных Проработка технических аспектов, связанных с проектированием БД и переходом к логической модели 9
Сущность а) сильная; б) слабая Связь а) односторонняя; б) двухсторонняя; в) многосторонняя а) «один-к-одному»; б) «один-ко-многим; в) «многие-ко-многим» а) обязательная; б) не обязательная Атрибут а) простой; б) составной а) однозначный; б) многозначный; в) производный Ограничения Ключ а) первичный; б) потенциальный (альтернативный) Роль 10
Персонал Отделение Имеет Имя связи Имя сущности Рис. 1. Изображение двухсторонней связи «Отделение имеет персонал» Рис. 2. Пример трехсторонней связи «регистрирует» Регистри- рует Персонал Договор аренды Отделение Рис. 3. Пример односторонней связи «руководит» с ролевыми именами «инспектор» и «подчиненный» Сотрудник Руководит Инспектор Подчиненный Сотрудник компании руководит сотрудником компании Схематическое изображение сущностей и связей 11
Схематическое изображение атрибутов Газета имяГазеты {PK} Объявление объект№ {PK} публикует датаПубликации цена Рис.5. Атрибуты связи «публикует» находится в родственных отношениях Клиент клиент№ { PK } фамилия имя тел№ Родственник степеньРодства обращение фамилия имя тел№ Сильная сущность Слабая сущность Рис.6. Атрибуты сущности сильного и слабого типа Список атрибутов Сотрудник сотрудник№ {PK} имя {AK} должность оклад /заработок Рис.4. Представление атрибутов сущностей Сотрудник и Отделение Отделение отделение№ { PK } адрес улица город почтовыйИнд тел№ [1..3] Производный атрибут Многозначный атрибут Альтернативный ключ Первичный ключ Составной атрибут 12
Сотрудник сотрудник№ Отделение отделение№ Управляет 1..1 0..1 Кратность Каждым отделением управляет один сотрудник Количество отделений, которыми управляет сотрудник, может быть равно 0 или 1 Рис.7. Кратность взаимооднозначной связи(1:1) Количество объектов, которыми управляет каждый сотрудник, может быть от 0 и больше Сотрудник сотрудник№ ОбъектНедв объект№ Управляет 0..1 0..* Количество сотрудников, которые управляют объектом, может быть 0 или 1 Рис.8. Кратность связи «один-ко-многим» (1:*) Газета название Объявление объект№ публикует Количество газет, в которых публикуется объявление может составлять от 0 и больше 0..* 1..* Количество объектов, которые рекламируются в каждой газете, может быть от 1 и больше Рис.9. Связь типа “ многие-ко- многим ” (*..*) Схематическое изображение кратности связи 13
Схематическое изображение кратности связи (продолжение) Регистри- рует Сотрудник Арендатор Отделение 1..1 1..1 0..* Рис.10. Кратность трехсторонней связи «регистрирует» Альтернативные способы представления ограничений кратности 0.. 1 1.. 1 (или просто 1) 0.. * (или просто *) 1.. * 5.. 10 0, 3, 6-8 Нуль или один экземпляр сущности Точно один экземпляр сущности От нуля и больше экземпляров сущности От одного и больше экземпляров сущности От пяти до десяти экземпляров сущности включительно Нуль, три, шесть, семь или восемь экземпляров сущности 14
Отдел Отделение Сотрудник состоит из включает 1..* 1..* 1..1 1..1 Дефект типа «разветвление»: Запрос « в каком отделении работает сотрудник ? » не имеет однозначного ответа Устранение дефекта Отдел Отделение Сотрудник Отдел Отделение Сотрудник состоит из включает 1..* 1..* 1..1 1..1 15
Сотрудник ОбъектАренд Отделение состоит из отвечает 1..* 0..* 1..1 0..1 Дефект типа «разрыв»: Ответ на запрос «Какое отделение компании отвечает за работу с объектом ? » может не существовать, если ни один из сотрудников на отвечает за этот объект Сотрудник ОбъектАренды Отделение ? Сотрудник ОбъектАренд Отделение состоит из отвечает 1..* 0..* 1..1 0..1 Устранение дефекта: работает с 1..1 1..* 16
Локальная концептуальная модель данных для представления «Сотрудник» (пример) ( D) 1..1 датаОсмотра комментарии Сотрудник сотрудник№ {PK} имя должность оклад ОбъектАренды объект№ { PK } адрес улица город почтовыйИнд типОбъекта числоКомнат цена Клиент клиент№ {PK} имя тел№ Оплата оплата№ {PK} способОплаты депозитКарта началоОплаты конецОплаты Владелец Владелец№ {PK} Адрес тел№ Пожелания типОбъекта махЦена регистрирует осматривает отвечает за владеет высказы-вает оплачивается согласен на 1..1 0..* 0..* 0..* 1..1 0..* 1..1 0..* 1..1 1..* 1..1 0..1 0..100 ( G) ( A) ( B) ( B) ( C) ( E) ( E) Рис. 11. Применение путей выполнения транзакций для проверки соответствия модели пользовательским требованиям 17
Переход от концептуальной к логической (реляционной) модели данных Исключение особенностей, не совместимых с реляционной моделью (необязательный этап). 2. Формирование отношений на основе локальной логической модели данных. 3. Проверка отношений с использованием средств нормализации. 4. Проверка применимости отношений для выполнения пользовательских транзакций. 5. Определение ограничений целостности. 6. Согласование локальной логической модели данных с пользователем. 18
Исключение особенностей, не совместимых с реляционной моделью Удаление двухсторонних связей "многие ко многим" (*:*). 2. Удаление рекурсивных связей "многие ко многим" (*:*). 3. Удаление сложных связей. Удаление многозначных атрибутов. 19
Клиент Клиент№ {PK} ОбъектАренд объект№ {PK} осматривает датаОсмотра комментарии 0..* 0..* а) связь типа * : * « Клиент осматривает ОбъектАренды » б) декомпозиция этой связи на две связи типа 1:* « запрашивает » и « подвергается » с созданием новой слабой сущности Осмотр Клиент Клиент№ {PK} ОбъектАренд объект№ {PK} запрашивает Осмотр датаОсмотра комментарии 0..* 0..* подвергается 1..1 1..1 20
Инспектор Сотрудник компании может иметь несколько руководителей-сотрудников компании и/или руководить несколькими сотрудниками Сотрудник руководит Подчиненный сотрудник№ 0..* 0..* а) рекурсивная связь «руководит» типа «многие-ко-многим» (*:*) Сотрудник сотрудник№ Сотрудник сотрудник№ руководит 1..* 0..* б) преобразование рекурсивной связи в двухстороннюю типа «многие-ко-многим» (*:*) Инспектор Подчиненный Сотрудник сотрудник№ Сотрудник сотрудник№ руководит 1..1 0..* Руководство подчиняется 1..1 0..* в) устранение двухсторонней связи типа «многие-ко-многим» в) объединение двух сущностей Сотрудник Сотрудник сотрудник№ руководит 1..1 0..* Руководство подчиняется 1..1 0..* 21
Регистри- рует Сотрудник Клиент Отделение сотрудник№ {PK} отделение№ {PK} клиент№ {PK} 1..1 1..1 0.. * а) сложная связь « регистрирует » регистрирует 1..1 Сотрудник Клиент Отделение сотрудник№ {PK} отделение№ {PK} клиент№ {PK} 1..1 1..1 Регистрация 0..* 1..* 1..1 выполняет соглашается на б) декомпозиция на три двухсторонние связи и новую слабую сущность 22
Удаление многозначных атрибутов Отделение отделение№ {PK} адрес тел№ [1..3] а) сущность «Отделение» с многозначным атрибутом «тел№» Отделение отделение№ {PK} адрес Телефон тел№ {PK} 1..1 1..3 доступны б) декомпозиция многозначного атрибута и получение новой сущности с простыми атрибутами 23
Дополнительные концепции: уточнение/обобщение агрегирование композиция 1. Уточнение/обобщение Суперкласс. Тип сущности, включающий одну или несколько различимых вспомогательных группировок ее экземпляров, которые должны быть представлены в модели данных. Подкласс. Различимая вспомогательная группировка экземпляров типа сущности, которая должна быть представлена в модели данных. Пример. «Сотрудник» можно разбить на группы «Менеджер», «Инспектор», «Секретарь». «Сотрудник» - суперкласс, остальные - подклассы Связь между суперклассом и подклассом является связью "один к одному" (1:1) и называется связью суперкласс/подкласс 24
Атрибуты суперкласса наследуются, связанными с ним подклассами, которые могут также иметь свои собственные дополнительные атрибуты. Этот процесс называется множественным наследованием. Уточнение. Процесс подчеркивания различий между элементами сущности путем выявления их отличительных особенностей. Обобщение. Процесс стирания различий между элементами сущности путем выявления их общих особенностей Ограничения процесса уточнения/обобщения Ограничение степени участия (« Mandatory » - обязательный; « Optional »-необязательный) Ограничение непересечения (« Or »-подклассы не пересекаются; « And »-подклассы могут пересекаться) Ограничение степени участия. Определяет, должен ли быть отнесен к какому- то подклассу каждый элемент суперкласса. Ограничение непересечения. Описывает связь между элементами подклассов и указывает, может ли элемент суперкласса принадлежать только к одному или нескольким подклассам 25
Сотрудник сотрудник№ {PK} имя должность оклад Менеджер начДата бонус Инспектор обслужРайон пользАвто Секретарь скорПечати Суперкласс {Optional, And} Ограничение степени участия Mandatory или Optional Ограничение непересечения And или Or Указывает на уточнение/обобщение Подклассы функциональных обязанностей Отделение отделение№ { PK } адрес улица город почтовыйИнд ПолнаяЗанят Оклад числоДнейОтпуск НеполнЗанят почасовСтавка Подклассы полной/неполной занятости {Mandatory,Or} 1..1 1..1 1..1 1.. * состоит из управляет EER -схема с результатами уточнения/обобщения сущности «Сотрудник» (показаны подклассы функциональных обязанностей и подклассы типов договоров найма) 26
2. Агрегирование Агрегирование. Представляет связь «включает» (или «входит в состав») между типами сущностей, один из которых представляет "целое", а другой — "часть". Сущность «целое» представляет собой более крупную сущность, состоящую из меньших сущностей («частей») Сотрудник сотрудник№ {PK} Отделение отделение№ {PK} ОбъектАренды объект№ { PK } Обозначает агрегирование состоит из управляет 1..1 1..1 1..* 1..100 0..1 1..* «Сотрудник» представляет «часть» в связи «состоит из» «Отделение» представляет «целое» в связях «состоит из» и «управляет» «ОбъектАренды» представляет «часть» в связи «управляет» Примеры агрегирования связей «Отделение состоит из сотрудников» и «Отделение управляет объектамиАренды» 27
2. Композиция Композиция. Особая форма агрегирования, представляющая зависимость между сущностями, которая характеризуется полной принадлежностью и совпадением срока существований между "целым" и "частью". В композиции "целое" отвечает за размещение его "частей", их создание и разрушение. Любой объект в любой момент времени может входить в состав только одной композиции. Газета имяГазеты {PK} Объявление объявлен№ {PK} публикует 1..1 1..* «Газета» представляет «целое» в связи «публикует» «Объявление» представляет «часть» в связи «публикует» Обозначение композиции Пример композиции связи «Газета публикует Объявление 28
Общее правило. Из двух сущностей, участвующих в связи, определяют, которая является родительской, другая является дочерней (подчиненной). Родительская сущность передает копию своего первичного ключа в отношение, представляющее дочернюю сущность, для использования его в качестве внешнего ключа. Если связь имеет атрибуты, то они помещаются в дочернее отношение. 1. Сильные типы сущностей Отделение отделение№ { PK } адрес улица город почтовыйИнд тел№ В отношение «Отделение» включают все простые атрибуты сущности; из составных атрибутов включаются только составляющие их простые атрибуты Отделение( отделение№,улица,город,почтовыйИнд,тел№) PRIMARY KEY отделение№ 2. Слабые типы сущностей Пожелания типОбъекта max Цена В отношение «Пожелания» включают, аналогично сильной сущности, все простые атрибуты. Отличие в том, что невозможно определить первичный ключ, пока не будет преобразована связь между сильной и слабой сущностью, поэтому первичный ключ отсутствует Пожелания(типОбъекта, max Цена) 29
Сущность на стороне «один» - родительская, на стороне «многие» - дочерняя. Копия первичного ключа родительской сущности передается в отношение, соответствующее дочерней сущности, и используется в качестве внешнего ключа Сотрудник сотрудник№ {PK} имя должность оклад Клиент клиент№ {PK} имя тел№ регистрирует 0..* 1..1 Сотрудник( сотрудник№,имя,должность,оклад) PRIMARY KEY сотрудник№ Клиент( клиент№,имя,тел№,сотрудник№) PRIMARY KEY клиент№ FOREIGN KEY сотрудник№ REFERENCES C отрудник(сотрудник№ ) 30
Обязательное участие обеих сторон в связи типа 1:1 а) Обе сущности объединяются в одно отношение Первичный ключ одной из сущностей становится первичным ключом отношения, а первичный ключ другой сущности становится альтернативным ключом. Если связь имеет атрибуты, то они включаются в создаваемое отношение б) Одну (любую) из сущностей выбирают в качестве родительской, а другую – дочерней. Копия первичного ключа родительской сущности передается в отношение, соответствующее дочерней сущности, и используется в качестве внешнего ключа. Если связь имеет один или несколько атрибутов, то они перемещаются в дочернее отношение. Обязательное участие одной стороны в связи типа 1:1 Сущность, которая характеризуется обязательным участием становится родительской, а сущность с необязательным участием – дочерней. Далее см.п.1б) Необязательное участие обеих сторон в связи типа 1:1 Одну (любую) из сущностей выбирают в качестве родительской, а другую – дочерней. Далее см.п.1б) 31
Клиент клиент№ {PK} имя тел№ Пожелания типОбъекта махЦена высказывает 1..1 1..1 а) Клиент( клиент№,имя,тел№,типОбъекта, max Цена) PRIMARY KEY клиент№ б) Клиент( клиент№,имя,тел№) PRIMARY KEY клиент№ Пожелания(типОбъекта, max Цена,клиент№) PRIMARY KEY клиент№ FOREIGN KEY клиент№ REFERENCES Клиент(клиент№) 1) Обязательное участие обеих сторон в связи типа 1:1 Клиент клиент№ {PK} имя тел№ Пожелания типОбъекта махЦена высказывает 1..1 0..1 Клиент( клиент№,имя,тел№) PRIMARY KEY клиент№ Пожелания(типОбъекта, max Цена, клиент№ ) PRIMARY KEY клиент№ FOREIGN KEY клиент№ REFERENCES Клиент(клиент№) 2) Обязательное участие одной стороны в связи типа 1:1 32
Автомобиль гос№ {PK} марка использует 0..1 0..1 а) Сотрудник( сотрудник№,имя,должность,оклад) PRIMARY KEY сотрудник№ Автомобиль( гос№,марка,датаНачИсп,суммаКомпенс, сотрудник№) PRIMARY KEY гос№ FOREIGN KEY сотрудник№ REFERENCES Сотрудник(сотрудник№) б) Автомобиль( гос№,марка ) PRIMARY KEY гос№ Сотрудник( сотрудник№,имя,должность,оклад, гос№, датаНачИсп,суммаКомпенс) PRIMARY KEY сотрудник№ FOREIGN KEY гос№ REFERENCES Автомобиль(Гос№) Сотрудник сотрудник№ {PK} имя должность оклад датаНачИсп суммаКомпенс 3) Необязательное участие обеих сторон в связи типа 1:1 Замечание. Если сотрудников больше, чем автомобилей, то вариант а) требует меньше памяти для размещения отношений 33
Общее правило. Рекурсивная связь является односторонней. Выбор родительского и дочернего отношений аналогичен выбору для двухсторонних связей. Но так как фактически мы имеем одну сущность, то в дочернее отношение помещаются только ключи: первичный ключ от родительской таблицы и копия первичного ключа (с другим именем), используемая в качестве внешнего ключа. в) рекурсивная связь типа многие ко многим (*:*) 0..* 0..* Сотрудник сотрудник№ руководит 1..1 Руководство подчиняется 1..1 Сотрудник руководит Подчиненный сотрудник№ 0..1 0..* Инспектор Сотрудник( сотрудник№,инспектор№) PRIMARY KEY сотрудник№ FOREIGN KEY инспектор№ REFERNCES Сотрудник(сотрудник№) а) рекурсивная связь типа один ко многим (1:*) Сотрудник Руководит Инспектор Подчиненный 0..1 0..1 сотрудник№ Сотрудник( сотрудник№,инспектор№) PRIMARY KEY сотрудник№ FOREIGN KEY инспектор№ REFERNCES Сотрудник(сотрудник№) б) рекурсивная связь типа один к одному (1:1) Сотрудник( сотрудник№ ) PRIMARY KEY сотрудник№ Руководство(сотрудник№, инспектор№) PRIMARY KEY сотрудник№,инспектор № FOREIGN KEY сотрудник№ REFERNCES Сотрудник(сотрудник№) FOREIGN KEY инспектор№ REFERNCES Сотрудник(сотрудник№) 34
Связи типа суперкласс/подкласс Общее правило: Сущность, соответствующая суперклассу, определяется как родительская, а сущность, соответствующая подклассу, - как дочерняя Рекомендации по выбору способа преобразования связи суперкласс/подкласс с учетом только ограничений степени участи и непересечения Ограничение степени участия Ограничение непересечения Необходимые отношения Обязательное {Mandatory} Пересечение допускается {And} Одно отношение (с одним или несколькими определителями, позволяющими указать тип каждой записи) Необязательное {Optional} Пересечение допускается {And} Два отношения: одно – для суперкласса, а второе для всех подклассов (с одним или несколькими определителями, позволяющими указать тип каждой записи) Обязательное {Mandatory} Пересечение не допускается {Or} Несколько отношений: по одному отношению для каждого сочетания суперкласс/подкласс Необязательное {Optional} Пересечение не допускается {Or} Несколько отношений: одно – для суперкласса, а другие – по одному для каждого подкласса 35
определение функциональных зависимостей для модели (первичный ключ, внешний ключ, альтернативный ключ) проверка отношений с помощью правил нормализации до НФБК: 1НФ – отсутствие в отношении повторяющихся групп атрибутов 2НФ – отсутствие частичных зависимостей атрибутов от первичного ключа 3НФ – отсутствие транзитивных зависимостей атрибутов от первич. ключа НФБК – каждая детерминанта является потенциальным ключом 3) проверка соответствия отношений требованиям пользоват. транзакций 4) определение требований поддержки целостности данных обязательные данные ограничения для доменов атрибутов целостность сущностей (первичный ключ не м.б. NULL) ссылочная целостность (атрибуты внешнего ключа либо д.б. NULL, либо значение первичного ключа д. присутствовать в родительском отношении) ограничения предметной области 3 6
3 7
3 8
Атрибут Сильная сущность Слабая сущность Производный атрибут Многозначный атрибут Составной атрибут Атрибут Атрибут Связь Связь со слабой сущностью Первичный ключ 1 1 A B Связь «один к одному» (1:1) с обязательным участием сущностей A и B М 1 A B Связь «один ко многим» (1: M ) с необязательным участием сущности A и обязательным - B N M A B Связь «многие ко многим» ( M : N ) с необязательным участием сущности A и необязательным - B Суперкласс d Подкласс Подкласс Уточнение/обобщение Буква в кружке: « d » - связь непересекающаяся, « o » - связь не явл. непересекающейся Линия от суперкласса к кружку: двойная линия обозначает обязательное участие, одинарная линия - необязательное 3 9
числоКомнат 1 Высказы-вает Сотрудник ОбъектАренды Клиент Владелец Оплата Пожелания Регистри-рует 1 M 1 Согласен на Осматри-вает 1 M Отвечает за Отвечает за 1 0..100 M M M 1 Оплачива-ется 1 M СпособОплаты оплата№ типОбъекта Max Цена депозитКарта началоОплаты объект№ адрес типОбъекта улица почтовыйИнд город владелец№ тед№ адрес цена сотрудник№ имя оклад объект№ цена адрес должность ER- модель (рис.11), переоформленная в системе обозначений Чена 40
АЛЬТЕРНАТИВНЫЕ СИСТЕМЫ ОБОЗНАЧЕНИЙ ER-МОДЕЛИРОВАНИЯ (обозначения «воронья лапка») Сущность Связь «один к одному» Сущность Первичный ключ Атрибут 1 Атрибут 2 { Многозначный атрибут } Связь «один ко многим» Связь «многие ко многим» Связь «один ко многим» (1: M ) с необязательным участием сущности A и обязательным - B A B Связь «один к одному» (1:1) с обязательным участием сущностей A и B A B A B Связь «многие ко многим» ( M : N ) с необязательным участием сущности A и необязательным - B Подкласс Подкласс Суперкласс Для представления иерархии уточнение/обобщение используются вложенные прямоугольники 41
датаОсмотра комментарии Сотрудник сотрудник№ имя должность оклад ОбъектАренды объект№ адрес улица город почтовыйИнд типОбъекта числоКомнат цена Клиент клиент№ имя тел№ Оплата оплата№ способОплаты депозитКарта началоОплаты конецОплаты Владелец Владелец№ Адрес тел№ Пожелания типОбъекта махЦена отвечает за владеет высказывает оплачивается согласен на 0..100 регистрирует осматривает ER- модель (рис.11), переоформленная в системе обозначений «воронья лапка» 42
