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

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

Таблица Основные действия на каждом этапе жизненного цикла приложения 2

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

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

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

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

Инфологическая модель представления «Отделение» учебного проекта DreamHome (пример) 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-модель) ER-модель (Entity-Relationship model) представляет собой высокоуровневую концептуальную модель данных, не зависящую от конкретной СУБД или аппаратной платформы ER-модель представляет собой набор концепций, которые описывают структуру информационной модели предприятия и его потребностей Назначение ER-модели: Формализация пользовательского восприятия данных Проработка технических аспектов, связанных с проектированием БД и переходом к логической модели 9

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

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

Схематическое изображение атрибутов находится в родственных отношениях Список атрибутов 12

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

Схематическое изображение кратности связи (продолжение) Альтернативные способы представления ограничений кратности 14

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

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

Локальная концептуальная модель данных для представления «Сотрудник» (пример) 17

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

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

Удаление двухсторонних связей "многие ко многим" (*:*) б) декомпозиция этой связи на две связи типа 1:* «запрашивает» и «подвергается» с созданием новой слабой сущности Осмотр 20

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

Удаление сложных связей 22

Удаление многозначных атрибутов а) сущность «Отделение» с многозначным атрибутом «тел№» 23

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

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

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

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

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

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

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

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

32

3) Необязательное участие обеих сторон в связи типа 1:1 Замечание. Если сотрудников больше, чем автомобилей, то вариант а) требует меньше памяти для размещения отношений 33

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

Связи типа суперкласс/подкласс Общее правило: Сущность, соответствующая суперклассу, определяется как родительская, а сущность, соответствующая подклассу, - как дочерняя Рекомендации по выбору способа преобразования связи суперкласс/подкласс с учетом только ограничений степени участи и непересечения 35

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

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

38

АЛЬТЕРНАТИВНЫЕ СИСТЕМЫ ОБОЗНАЧЕНИЙ ER-МОДЕЛИРОВАНИЯ (обозначения Чена) 39

1 1 M 1 1 M 1 0..100 M M M 1 1 M ER-модель (рис.11), переоформленная в системе обозначений Чена 40

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

ER-модель (рис.11), переоформленная в системе обозначений «воронья лапка» 42