1 Этапы жизненного цикла приложений баз данных Планирование

Зарегистрируйтесь, чтобы просмотреть полный документ!

1 Этапы жизненного цикла приложений баз данных Планирование базы данных Определение системы Сбор и анализ требований Проектирование базы данных Выбор СУБД (необязат. этап) Концептуальное проектирование Проектирование приложений Логическое проектирование Тестирование Физическое проектирование Разраб. прототи па (необязат. этап) Эксплуатационное сопровождение Реализация Преобразование и загрузка данных

Таблица 2 Этап Основные действия на каждом этапе жизненного цикла приложения Описание Примеры собираемых данных Примеры документации Планирование разработки БД Планирование наиболее эффективного способа реализации этапов жизненного цикла системы Целевые функции и технические требования к проекту БД Техническое задание и технические требования Определение требований к системе Определение диапазона действий и границ приложения БД, состава пользователей и областей применения Описание основных пользовательских представлений (включая должностные роли или область применения в бизнесе) Определение области действия и границ применения БД; определение поддерживаемых пользоват. представл. Сбор и анализ требований пользователей из всех возможных областей применения Требования для пользовательских представлений и системы Спецификации пользовательских и системных требований Проектирование БД Полный цикл разработки включает концептуальное, логическое и физическое проектирование БД Пользовательская реакция на логический проект БД; функциональные возможности рассматриваемой СУБД Концептуальный/логический проект БД (включает ER-модели, словарь данных и реляционную схему); физич. проект БД Выбор целевой СУБД (необяз. этап) Выбор наиболее подходящей СУБД для приложения БД Функциональные возможности рассматриваемой СУБД Оценка СУБД и подготовка рекомендаций Разработка приложений Определение пользовательского интерфейса и прикладных программ, Пользовательская реакция на проект интерфейса Проект приложения (включает описание программ и интерфейса пользователя) Создание прототипов (необязательный этап) Создание рабочей модели приложения БД, которая позволяет представить и оценить окончательный вид и способы функционирования системы Пользовательская реакция на прототип Модифицированные спецификации пользовательских и системных требований Реализация Создание внешнего, концептуального и внутреннего определения БД и прикладных программ Функциональные возможности разработанной СУБД Преобразование и загрузка данных (и прикладных программ) из старой системы в новую Формат существующих данных; возможности импорта данных целевой СУБД Тестирование Приложение базы данных тестируется с целью обнаружения ошибок, а также его проверки на соответствие всем требованиям, выдвинутым пользователями Результаты проверки Применяемые методики тестирования; анализ результатов проверки Эксплуатация и сопровождение В случае необходимости в функционирующее приложение могут вноситься изменения, отвечающие новым требованиям. Результаты проверки производительности; новые или измененные пользовательские и системные требования Руководство пользователя; анализ результатов измерения производительности; модифицированные спецификации пользоват. и системных требований

3 Концептуальное, логическое и физическое проектирование базы данных Концептуальное проектирование базы данных. Создание информационной модели предприятия, не зависящей от любых деталей реализации, например, таких как тип СУБД, язык программирования, аппаратная платформа, производительность, физическая организация БД Логическое проектирование базы данных. Конструирование информационной модели предприятия на основе существующих конкретных моделей данных (типа СУБД), но без учета используемой СУБД и прочих физических условий реализации. Физическое проектирование базы данных. Описание конкретной реализации базы данных, размещаемой во внешней памяти с учетом особенностей используемой СУБД. Физический проект описывает базовые отношения, определяет организацию файлов и состав индексов, применяемых для обеспечения эффективного доступа к данным, а также регламентирует все соответствующие ограничения целостности и меры защиты.

4 Концептуальное проектирование базы данных • Создание локальных концептуальных моделей данных, исходя из представлений о предметной области каждого из типов пользователей • Определение типов сущностей • Определение типов связей • Определение атрибутов и связывание их с типами сущностей и связей • Определение доменов атрибутов • Определение атрибутов, являющихся потенциальными и первичными ключами • Проверка модели на отсутствие избыточности • Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям • Обсуждение локальных концептуальных моделей с пользователями

5 Логическое проектирование БД (реляционного типа) • Создание локальной логической модели данных из концептуальной модели • Устранение особенностей, несовместимых с реляционной моделью • Определение набора отношений • Проверка отношений с помощью правил нормализации • Проверка соответствия отношений требованиям пользовательских транзакций • Определение требований поддержки целостности данных • Обсуждение локальных логических моделей с пользователями • Создание и проверка глобальной логической модели данных путем слияния локальных моделей • Обсуждение глобальной логической модели данных с пользователями

6 Физическое проектирование БД (с использованием реляционной СУБД) • Перенос глобальной логической модели данных в среду целевой СУБД • Проектирование базовых отношений в среде целевой СУБД • Проектирование отношений, содержащих производные данные • Реализация ограничений предметной области • Проектирование физического представления данных • Анализ транзакций • Выбор файловой структуры • Определение индексов • Определение требований к дисковой памяти • Разработка пользовательских представлений • Разработка механизмов защиты • Анализ необходимости введения контролируемой избыточности

7 Инфологическая модель представления «Отделение» учебного проекта Dream. Home (пример) 1. Требования к данным Отделения Компания Dream. Home имеет отделения во всех городах Великобритании. Каждое отделение укомплектовано определенным количеством сотрудников; в их число входят менеджеры, которые управляют работой отделения. С каждым отделением связаны такие данные, как уникальный номер отделения, адрес (улица, город и почтовый индекс), номера телефонов (вплоть до максимального количества, равного трем) и имя сотрудника компании, который в настоящее время управляет работой отделения. О каждом менеджере хранятся дополнительные данные, которые включают дату вступления менеджера в должность руководителя данного отделения и ежемесячную премиальную оплату, основанную на результатах его работы на рынке аренды недвижимости. Объекты недвижимости, предназначенные для сдачи в аренду Каждое отделение предлагает клиентам целый ряд объектов недвижимости, сдаваемых в аренду. О каждом объекте недвижимости хранятся такие данные, как номер объекта недвижимости, адрес (улица, город, почтовый индекс), тип, количество комнат, ежемесячная арендная плата и сведения о владельце объекта недвижимости. Каждый номер объекта недвижимости является уникальным во всех отделениях. Каждым арендованным или предназначенным для сдачи в аренду объектом недвижимости управляет один из сотрудников компании. Ни один из сотрудников не может управлять более чем 100 объектами недвижимости одновременно.

8 2. Требования к транзакциям (пример) Ввод данных 1) Ввести сведения о новом отделении (например, об отделении ВООЗ в Глазго). 2) Ввести сведения о новом сотруднике отделения (например, о сотруднике Ann Beech отделения ВООЗ). 3) Ввести сведения о рекламе объекта недвижимости в газете (например, о том, что об объекте недвижимости с номером PG 4 опубликовано рекламное объявление в газете Glasgow Daily 6 мая 2000 года). Обновление/удаление данных 1) Обновить/удалить сведения об отделении. 2) Обновить/удалить сведения о сотруднике отделения. 3) Обновить/удалить сведения об указанном договоре аренды в некотором отделении. Транзакции А. Составить список с номерами, адресами, обозначениями типа и арендной платы всех объектов недвижимости в Глазго, отсортированный по величине арендной платы. B. Составить список со сведениями о сдаваемых в аренду объектах недвижимости, которыми управляет указанный сотрудник. C. Определить общее количество объектов недвижимости каждого типа во всех отделениях. D. Составить отчет об осмотрах объектов недвижимости E. Сотрудник регистрирует потенциального клиента и его пожелания G. Определить имя и номер телефона владельца указанного объекта недвижимости

9 Модель «сущность-связь» (ER-модель) ER-модель (Entity-Relationship model) представляет собой высокоуровневую концептуальную модель данных, не зависящую от конкретной СУБД или аппаратной платформы ER-модель представляет собой набор концепций, которые описывают структуру информационной модели предприятия и его потребностей Назначение ER-модели: • Формализация пользовательского восприятия данных • Проработка технических аспектов, связанных с проектированием БД и переходом к логической модели

10 Объекты ER-модели • Сущность а) сильная; б) слабая • Связь а) односторонняя; б) двухсторонняя; в) многосторонняя а) «один-к-одному» ; б) «один-ко-многим; в) «многие-ко-многим» а) обязательная; б) не обязательная • Атрибут а) простой; б) составной а) однозначный; б) многозначный; в) производный • Ограничения • Ключ а) первичный; б) потенциальный (альтернативный) • Роль

11 Схематическое изображение сущностей и связей Имя связи Персонал Имеет Отделение Сотрудник компании руководит сотрудником компании Руководит Инспектор Имя сущности Рис. 1. Изображение двухсторонней связи «Отделение имеет персонал» Персонал Регистрирует Отделение Договор аренды Рис. 2. Пример трехсторонней связи «регистрирует» Сотрудник Подчиненный Рис. 3. Пример односторонней связи «руководит» с ролевыми именами «инспектор» и «подчиненный»

12 Схематическое изображение атрибутов Альтернатив ный ключ Первичный ключ Сотрудник Список атрибутов сотрудник№ {PK} имя {AK} должность оклад /заработок Производный атрибут Отделение отделение№ {PK} адрес улица город почтовый. Инд тел№ [1. . 3] Сильная сущность Составной атрибут Многозначный атрибут Рис. 4. Представление атрибутов сущностей Сотрудник и Отделение Газета имя. Газеты{PK} публикует Объявление объект№{PK} дата. Публикации цена Рис. 5. Атрибуты связи «публикует» Клиент клиент№ {PK} фамилия имя тел№ Слабая сущность находится в родственных отношениях Родственник степень. Родства обращение фамилия имя тел№ Рис. 6. Атрибуты сущности сильного и слабого типа

13 Схематическое изображение кратности связи Количество отделений, которыми управляет сотрудник, может быть равно 0 или 1 Каждым отделением управляет один сотрудник Сотрудник сотрудник№ Управляет 1. . 1 0. . 1 Отделение отделение№ Количество газет, в которых публикуется объявление может составлять от 0 и больше Газета название 0. . * Кратность Рис. 7. Кратность взаимооднозначной связи(1: 1) Количество сотрудников, которые управляют объектом, может быть 0 или 1 Сотрудник сотрудник№ Количество объектов, которыми управляет каждый сотрудник, может быть от 0 и больше Управляет 0. . 1 0. . * Объект. Недв объект№ Рис. 8. Кратность связи «один-ко-многим» (1: *) публикует 1. . * Объявление объект№ Количество объектов, которые рекламируются в каждой газете, может быть от 1 и больше Рис. 9. Связь типа “многие-комногим” (*. . *)

14 Схематическое изображение кратности связи (продолжение) Сотрудник 1. . 1 Регистрирует 1. . 1 Отделение 0. . * Арендатор Рис. 10. Кратность трехсторонней связи «регистрирует» Альтернативные способы представления ограничений кратности 0. . 1 1. . 1 (или просто 1) 0. . * (или просто *) 1. . * 5. . 10 0, 3, 6 -8 Нуль или один экземпляр сущности Точно один экземпляр сущности От нуля и больше экземпляров сущности От одного и больше экземпляров сущности От пяти до десяти экземпляров сущности включительно Нуль, три, шесть, семь или восемь экземпляров сущности

15 Ловушки ER-моделирования Дефект типа «разветвление» : состоит из Сотрудник 1. . * 1. . 1 включает Отдел 1. . 1 1. . * Отделение Запрос «в каком отделении работает сотрудник? » не имеет однозначного ответа Сотрудник Отделение Устранение дефекта включает Отдел 1. . 1 состоит из 1. . * Отделение 1. . 1 1. . * Сотрудник

16 Ловушки ER-моделирования Дефект типа «разрыв» : состоит из Отделение 1. . 1 отвечает 1. . * Сотрудник 0. . 1 0. . * Объект. Аренд Ответ на запрос «Какое отделение компании отвечает за работу с объектом? » может не существовать, если ни один из сотрудников на отвечает за этот объект Отделение Сотрудник Объект. Аренды ? Устранение дефекта: состоит из Отделение 1. . 1 отвечает 1. . * Сотрудник работает с 0. . 1 0. . * Объект. Аренд 1. . *

17 Локальная концептуальная модель данных для представления «Сотрудник» (пример) Сотрудник сотрудник№ {PK} имя должность оклад 0. . 1 1. . 1 регистрирует (E) Клиент Объект. Аренды 0. . 100 объект№ {PK} отвечает за адрес (B) улица город почтовый. Инд тип. Объекта 1. . * число. Комнат (G) (B) цена 1. . 1 владеет оплачивается 1. . 1 осматривает 0. . * (A) 0. . * (D) клиент№ {PK} имя тел№ 1. . 1 дата. Осмотра комментарии 1. . 1 (E) высказывает согласен на (C) 0. . * Оплата 0. . * Владелец№ {PK} Адрес тел№ 0. . * оплата№ {PK} способ. Оплаты депозит. Карта начало. Оплаты конец. Оплаты 1. . 1 Пожелания тип. Объекта мах. Цена Рис. 11. Применение путей выполнения транзакций для проверки соответствия модели пользовательским требованиям

18 Переход от концептуальной к логической (реляционной) модели данных 1. Исключение особенностей, не совместимых с реляционной моделью (необязательный этап). 2. Формирование отношений на основе локальной логической модели данных. 3. Проверка отношений с использованием средств нормализации. 4. Проверка применимости отношений для выполнения пользовательских транзакций. 5. Определение ограничений целостности. 6. Согласование локальной логической модели данных с пользователем.

19 Исключение особенностей, не совместимых с реляционной моделью 1. Удаление двухсторонних связей "многие ко многим" (*: *). 2. Удаление рекурсивных связей "многие ко многим" (*: *). 3. Удаление сложных связей. 4. Удаление многозначных атрибутов.

20 Удаление двухсторонних связей "многие ко многим" (*: *) осматривает Клиент№{PK} 0. . * Объект. Аренд 0. . * объект№{PK} дата. Осмотра комментарии а) связь типа *: * «Клиент осматривает Объект. Аренды» запрашивает Клиент№{PK} 1. . 1 подвергается Осмотр 0. . * дата. Осмотра комментарии 0. . * Объект. Аренд 1. . 1 объект№{PK} б) декомпозиция этой связи на две связи типа 1: * «запрашивает» и «подвергается» с созданием новой слабой сущности Осмотр

21 Удаление рекурсивных связей "многие ко многим" (*: *) Сотрудник компании может иметь несколько руководителей-сотрудников компании и/или руководить несколькими сотрудниками руководит 0. . * Подчиненный Инспектор Сотрудник сотрудник№ Сотрудник руководит 1. . * 0. . * сотрудник№ б) преобразование рекурсивной связи в двухстороннюю типа «многие-ко-многим» (*: *) а) рекурсивная связь «руководит» типа «многие-ко-многим» (*: *) Сотрудник сотрудник№ 0. . * 1. . 1 подчиняется Руководство руководит 0. . * 1. . 1 Сотрудник сотрудник№ в) устранение двухсторонней связи типа «многие-ко-многим» Сотрудник руководит 1. . 1 0. . * Руководство подчиняется 1. . 1 0. . * в) объединение двух сущностей Сотрудник сотрудник№

22 Удаление сложных связей Регистрирует Сотрудник сотрудник№{PK} 1. . 1 Отделение 1. . 1 отделение№{PK} 0. . * Клиент клиент№{PK} а) сложная связь «регистрирует» Сотрудник сотрудник№{PK} выполняет 1. . 1 регистрирует Регистрация 0. . * 1. . 1 Отделение отделение№{PK} соглашается 1. . 1 на 1. . 1 Клиент клиент№{PK} б) декомпозиция на три двухсторонние связи и новую слабую сущность

23 Удаление многозначных атрибутов Отделение отделение№ {PK} адрес тел№[1. . 3] а) сущность «Отделение» с многозначным атрибутом «тел№» Отделение отделение№ {PK} адрес Телефон доступны 1. . 1 1. . 3 тел№ {PK} б) декомпозиция многозначного атрибута и получение новой сущности с простыми атрибутами

24 Расширенная модель «сущность-связь» (EER-модель) Дополнительные концепции: • уточнение/обобщение • агрегирование • композиция 1. Уточнение/обобщение Суперкласс. Тип сущности, включающий одну или несколько различимых вспомогательных группировок ее экземпляров, которые должны быть представлены в модели данных. Подкласс. Различимая вспомогательная группировка экземпляров типа сущности, которая должна быть представлена в модели данных. Связь между суперклассом и подклассом является связью "один к одному" (1: 1) и называется связью суперкласс/подкласс Пример. «Сотрудник» можно разбить на группы «Менеджер» , «Инспектор» , «Секретарь» . «Сотрудник» - суперкласс, остальные - подклассы

25 Атрибуты суперкласса наследуются, связанными с ним подклассами, которые могут также иметь свои собственные дополнительные атрибуты. Этот процесс называется множественным наследованием. Уточнение. Процесс подчеркивания различий между элементами сущности путем выявления их отличительных особенностей. Обобщение. Процесс стирания различий между элементами сущности путем выявления их общих особенностей Ограничения процесса уточнения/обобщения 1. Ограничение степени участия ( «Mandatory» -обязательный; «Optional» необязательный) 2. Ограничение непересечения ( «Or» -подклассы не пересекаются; «And» подклассы могут пересекаться) Ограничение степени участия. Определяет, должен ли быть отнесен к какомуто подклассу каждый элемент суперкласса. Ограничение непересечения. Описывает связь между элементами подклассов и указывает, может ли элемент суперкласса принадлежать только к одному или нескольким подклассам

26 Отделение отделение№ {PK} 1. . 1 адрес улица город почтовый. Инд 1. . 1 Сотрудник состоит из 1. . * сотрудник№ {PK} имя должность оклад Суперкласс Ограничение степени участия Mandatory или Optional Ограничение непересечения And или Or Указывает на уточнение/обобщение управляет {Optional, And} {Mandatory, Or} 1. . 1 Менеджер нач. Дата бонус Инспектор обслуж. Район польз. Авто Секретарь скор. Печати Подклассы функциональных обязанностей Полная. Занят Оклад число. Дней. Отпуск Неполн. Занят почасов. Ставка Подклассы полной/неполной занятости EER-схема с результатами уточнения/обобщения сущности «Сотрудник» (показаны подклассы функциональных обязанностей и подклассы типов договоров найма)

27 2. Агрегирование. Представляет связь «включает» (или «входит в состав» ) между типами сущностей, один из которых представляет "целое", а другой — "часть". Сущность «целое» представляет собой более крупную сущность, состоящую из меньших сущностей ( «частей» ) «Сотрудник» представляет «часть» в связи «состоит из» «Отделение» представляет «целое» в связях «состоит из» и «управляет» состоит из Сотрудник сотрудник№ {PK} 1. . * 0. . 1 Обозначает агрегирование 1. . 100 Объект. Аренды объект№ {PK} 1. . 1 Отделение отделение№ {PK} 1. . 1 управляет 1. . * «Объект. Аренды» представляет «часть» в связи «управляет» Примеры агрегирования связей «Отделение состоит из сотрудников» и «Отделение управляет объектами. Аренды»

28 2. Композиция. Особая форма агрегирования, представляющая зависимость между сущностями, которая характеризуется полной принадлежностью и совпадением срока существований между "целым" и "частью". В композиции "целое" отвечает за размещение его "частей", их создание и разрушение. Любой объект в любой момент времени может входить в состав только одной композиции. «Газета» представляет «целое» в связи «публикует» «Объявление» представляет «часть» в связи «публикует» Обозначение композиции Газета имя. Газеты{PK} Объявление публикует 1. . 1 1. . * объявлен№{PK} Пример композиции связи «Газета публикует Объявление

29 Определение набора отношений реляционной БД Общее правило. Из двух сущностей, участвующих в связи, определяют, которая является родительской, другая является дочерней (подчиненной). Родительская сущность передает копию своего первичного ключа в отношение, представляющее дочернюю сущность, для использования его в качестве внешнего ключа. Если связь имеет атрибуты, то они помещаются в дочернее отношение. 1. Сильные типы сущностей Отделение отделение№ {PK} адрес улица город почтовый. Инд тел№ В отношение «Отделение» включают все простые атрибуты сущности; из составных атрибутов включаются только составляющие их простые атрибуты Отделение(отделение№, улица, город, почтовый. Инд, тел№) PRIMARY KEY отделение№ 2. Слабые типы сущностей Пожелания тип. Объекта max. Цена В отношение «Пожелания» включают, аналогично сильной сущности, все простые атрибуты. Отличие в том, что невозможно определить первичный ключ, пока не будет преобразована связь между сильной и слабой сущностью, поэтому первичный ключ отсутствует Пожелания(тип. Объекта, max. Цена)

30 Двухсторонние связи типа "один-ко-многим" (1 : *) Сущность на стороне «один» - родительская, на стороне «многие» - дочерняя. Копия первичного ключа родительской сущности передается в отношение, соответствующее дочерней сущности, и используется в качестве внешнего ключа Сотрудник сотрудник№ {PK} имя должность оклад Клиент регистрирует 1. . 1 0. . * клиент№ {PK} имя тел№ Сотрудник(сотрудник№, имя, должность, оклад) PRIMARY KEY сотрудник№ Клиент(клиент№, имя, тел№, сотрудник№) PRIMARY KEY клиент№ FOREIGN KEY сотрудник№ REFERENCES Cотрудник(сотрудник№)

31 Двухсторонние связи типа "один к одному" (1: 1) 1) Обязательное участие обеих сторон в связи типа 1: 1 а) Обе сущности объединяются в одно отношение Первичный ключ одной из сущностей становится первичным ключом отношения, а первичный ключ другой сущности становится альтернативным ключом. Если связь имеет атрибуты, то они включаются в создаваемое отношение б) Одну (любую) из сущностей выбирают в качестве родительской, а другую – дочерней. Копия первичного ключа родительской сущности передается в отношение, соответствующее дочерней сущности, и используется в качестве внешнего ключа. Если связь имеет один или несколько атрибутов, то они перемещаются в дочернее отношение. 2) Обязательное участие одной стороны в связи типа 1: 1 Сущность, которая характеризуется обязательным участием становится родительской, а сущность с необязательным участием – дочерней. Далее см. п. 1 б) 3) Необязательное участие обеих сторон в связи типа 1: 1 Одну (любую) из сущностей выбирают в качестве родительской, а другую – дочерней. Далее см. п. 1 б)

32 Клиент тип. Объекта 1. . 1 мах. Цена 1. . 1 клиент№ {PK} имя тел№ Пожелания высказывает а) Клиент(клиент№, имя, тел№, тип. Объекта, max. Цена) PRIMARY KEY клиент№ б) Клиент(клиент№, имя, тел№) PRIMARY KEY клиент№ Пожелания(тип. Объекта, max. Цена, клиент№) PRIMARY KEY клиент№ FOREIGN KEY клиент№ REFERENCES Клиент(клиент№) 1) Обязательное участие обеих сторон в связи типа 1: 1 Клиент 1. . 1 клиент№ {PK} имя тел№ высказывает Пожелания тип. Объекта 0. . 1 мах. Цена Клиент(клиент№, имя, тел№) PRIMARY KEY клиент№ Пожелания(тип. Объекта, max. Цена, клиент№) PRIMARY KEY клиент№ FOREIGN KEY клиент№ REFERENCES Клиент(клиент№) 2) Обязательное участие одной стороны в связи типа 1: 1

33 Сотрудник сотрудник№ {PK} имя должность оклад Автомобиль использует 0. . 1 гос№ {PK} марка дата. Нач. Исп сумма. Компенс а) Сотрудник(сотрудник№, имя, должность, оклад) PRIMARY KEY сотрудник№ Автомобиль(гос№, марка, дата. Нач. Исп, сумма. Компенс, сотрудник№) PRIMARY KEY гос№ FOREIGN KEY сотрудник№ REFERENCES Сотрудник(сотрудник№) б) Автомобиль(гос№, марка) PRIMARY KEY гос№ Сотрудник(сотрудник№, имя, должность, оклад, гос№, дата. Нач. Исп, сумма. Компенс) PRIMARY KEY сотрудник№ FOREIGN KEY гос№ REFERENCES Автомобиль(Гос№) 3) Необязательное участие обеих сторон в связи типа 1: 1 Замечание. Если сотрудников больше, чем автомобилей, то вариант а) требует меньше памяти для размещения отношений

34 Рекурсивные связи Общее правило. Рекурсивная связь является односторонней. Выбор родительского и дочернего отношений аналогичен выбору для двухсторонних связей. Но так как фактически мы имеем одну сущность, то в дочернее отношение помещаются только ключи: первичный ключ от родительской таблицы и копия первичного ключа (с другим именем), используемая в качестве внешнего ключа. руководит 0. . 1 0. . * Подчиненный Инспектор Руководит 0. . 1 Сотрудник Подчиненный сотрудник№ Сотрудник(сотрудник№, инспектор№) PRIMARY KEY сотрудник№ FOREIGN KEY инспектор№ REFERNCES Сотрудник(сотрудник№) а) рекурсивная связь типа один ко многим (1: *) Инспектор 0. . 1 Сотрудник сотрудник№ Сотрудник(сотрудник№, инспектор№) PRIMARY KEY сотрудник№ FOREIGN KEY инспектор№ REFERNCES Сотрудник(сотрудник№) б) рекурсивная связь типа один к одному (1: 1) Сотрудник(сотрудник№) PRIMARY KEY сотрудник№ Сотрудник руководит 1. . 1 сотрудник№ подчиняется 1. . 1 0. . * Руководство(сотрудник№, инспектор№) PRIMARY KEY сотрудник№, инспектор № FOREIGN KEY сотрудник№ REFERNCES Сотрудник(сотрудник№) KEY инспектор№ REFERNCES Сотрудник(сотрудник№) в) рекурсивная связь типа многие ко многим (*: *) FOREIGN

35 Связи типа суперкласс/подкласс Общее правило: Сущность, соответствующая суперклассу, определяется как родительская, а сущность, соответствующая подклассу, - как дочерняя Рекомендации по выбору способа преобразования связи суперкласс/подкласс с учетом только ограничений степени участи и непересечения Ограничение степени участия Ограничение непересечения Необходимые отношения Обязательное {Mandatory} Пересечение допускается {And} Одно отношение (с одним или несколькими определителями, позволяющими указать тип каждой записи) Необязательное {Optional} Пересечение допускается {And} Два отношения: одно – для суперкласса, а второе для всех подклассов (с одним или несколькими определителями, позволяющими указать тип каждой записи) Обязательное {Mandatory} Пересечение не допускается {Or} Несколько отношений: по одному отношению для каждого сочетания суперкласс/подкласс Необязательное {Optional} Пересечение не допускается {Or} Несколько отношений: одно – для суперкласса, а другие – по одному для каждого подкласса

36 Дальнейшие этапы логического проектирования 1) определение функциональных зависимостей для модели (первичный ключ, внешний ключ, альтернативный ключ) 2) проверка отношений с помощью правил нормализации до НФБК: • 1 НФ – отсутствие в отношении повторяющихся групп атрибутов • 2 НФ – отсутствие частичных зависимостей атрибутов от первичного ключа • 3 НФ – отсутствие транзитивных зависимостей атрибутов от первич. ключа • НФБК – каждая детерминанта является потенциальным ключом 3) проверка соответствия отношений требованиям пользоват. транзакций 4) определение требований поддержки целостности данных • обязательные данные • ограничения для доменов атрибутов • целостность сущностей (первичный ключ не м. б. NULL) • ссылочная целостность (атрибуты внешнего ключа либо д. б. NULL, либо значение первичного ключа д. присутствовать в родительском отношении) • ограничения предметной области

37 Логическая схема базы данных (пример)

39 АЛЬТЕРНАТИВНЫЕ СИСТЕМЫ ОБОЗНАЧЕНИЙ ER-МОДЕЛИРОВАНИЯ (обозначения Чена) Сильная сущность Атрибут Первичный ключ Слабая сущность Производный атрибут Многозначный атрибут A A A 1 1 1 М M N B Связь «один к одному» (1: 1) с обязательным участием сущностей A и B B Связь «один ко многим» (1: M) с необязательным участием сущности A и обязательным - B B Связь «многие ко многим» (M: N) с необязательным участием сущности A и необязательным - B Атрибут Составной атрибут Атрибут Суперкласс Буква в кружке: «d» - связь непересекающаяся, «o» - связь не явл. непересекающейся d Связь со слабой сущностью Подкласс Уточнение/обобщение Подкласс Линия от суперкласса к кружку: двойная линия обозначает обязательное участие, одинарная линия - необязательное

40 имя сотрудник№ должность цена 1 Сотрудник M Регистрирует 1 1 Высказывает Осматривает 0. . 100 M объект№ цена адрес Владелец город адрес Согласен на M Объект. Аренды 1 владелец№ 1 Клиент M Отвечает за адрес объект№ оклад 1 тип. Объекта 1 Пожелания Оплачивается число. Комнат тип. Объекта M M Max. Цена Оплата улица почтовый. Инд оплата№ депозит. Карта Способ. Оплаты начало. Оплаты тед№ ER-модель (рис. 11), переоформленная в системе обозначений Чена

41 АЛЬТЕРНАТИВНЫЕ СИСТЕМЫ ОБОЗНАЧЕНИЙ ER-МОДЕЛИРОВАНИЯ (обозначения «воронья лапка» ) Сущность B Связь «один к одному» (1: 1) с обязательным участием сущностей A и B B Связь «один ко многим» (1: M) с необязательным участием сущности A и обязательным - B B A Связь «многие ко многим» (M: N) с необязательным участием сущности A и необязательным - B Сущность A Первичный ключ Атрибут 1 Атрибут 2 {Многозначный атрибут} A Связь «один к одному» Суперкласс Связь «один ко многим» Подкласс Связь «многие ко многим» Подкласс Для представления иерархии уточнение/обобщение используются вложенные прямоугольники

42 Сотрудник сотрудник№ имя должность оклад регистрирует объект№ отвечает за адрес улица 0. . 100 город почтовый. Инд тип. Объекта число. Комнат цена владеет Владелец№ Адрес тел№ высказывает клиент№ имя тел№ Объект. Аренды Владелец Клиент оплачивается осматривает Пожелания тип. Объекта мах. Цена дата. Осмотра комментарии согласен на Оплата оплата№ способ. Оплаты депозит. Карта начало. Оплаты конец. Оплаты ER-модель (рис. 11), переоформленная в системе обозначений «воронья лапка»

Скачать презентацию 1 Этапы жизненного цикла приложений баз данных Планирование

ER-моделирование.ppt

Количество слайдов: 42