Управление данными Часть 1 Базы данных Тема 2

Управление данными Часть 1. Базы данных Тема 2. Инфологическое проектирование баз данных д. т. н. , профессор НИУ ВШЭ Акопов А. С.

Нормализация баз данных Первая нормальная форма (1 NF) — базовая нормальная форма отношения в реляционной модели данных. Переменная отношения находится в первой нормальной форме тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов. В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение. Что же касается различных таблиц, то они могут не быть правильными представлениями отношений и, соответственно, могут не находиться в 1 NF. В соответствии с определением К. Дж. Дейта для такого случая, таблица нормализована (эквивалентно — находится в первой нормальной форме) тогда и только тогда, когда она является прямым и верным представлением некоторого отношения. Конкретнее, рассматриваемая таблица должна удовлетворять следующим пяти условиям: 1. 2. 3. 4. 5. Нет упорядочивания строк сверху вниз (другими словами, порядок строк не несет в себе никакой информации). Нет упорядочивания столбцов слева направо (другими словами, порядок столбцов не несет в себе никакой информации). Нет повторяющихся строк. Каждое пересечение строки и столбца содержит ровно одно значение из соответствующего домена (и больше ничего). Все столбцы являются обычными[1]. «Обычность» всех столбцов таблицы означает, что в таблице нет «скрытых» компонентов, которые могут быть доступны только в вызове некоторого специального оператора взамен ссылок на имена регулярных столбцов, или которые приводят к побочным эффектам для строк или таблиц при вызове стандартных операторов. Таким образом, например, строки не имеют идентификаторов кроме обычных значений потенциальных ключей (без скрытых «идентификаторов строк» или «идентификаторов объектов» ). Они также не имеют скрытых временных меток[1].

Нормализация баз данных Пример приведения к 1 NF Исходная ненормализованная (то есть не являющаяся правильным представлением некоторого отношения) таблица: Сотрудник Номер телефона Иванов И. И. 283 56 82 390 57 34 Петров П. П. 708 62 34 Таблица, приведённая к 1 NF (являющаяся правильным представлением некоторого отношения): Сотрудник Номер телефона Иванов И. И. 283 56 82 Иванов И. И. 390 57 34 Петров П. П. 708 62 34

Нормализация баз данных Вторая нормальная форма (2 NF) Переменная отношения находится во второй нормальной форме тогда и только тогда, когда она находится в первой нормальной форме и каждый неключевой атрибут неприводимо (функционально полно) зависит от ее потенциального (первичного) ключа. Третья нормальная форма (3 NF) Переменная отношения находится в третьей нормальной форме тогда и только тогда, когда она находится во второй нормальной форме и отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключевых.

Нормализация баз данных Нормальная форма Бойса — Кодда Нормальная форма Бойса-Кодда (англ. Boyce-Codd normal form; сокращённо BCNF) — одна из возможных нормальных форм отношения в реляционной модели данных. Иногда нормальную форму Бойса Кодда называют усиленной третьей нормальной формой, поскольку она во всех отношениях сильнее (строже) по сравнению с ранее определённой ЗНФ[1]. Названа в честь Рэя Бойса и Эдгара Кодда, хотя Кристофер Дейт указывает, что на самом деле строгое определение «третьей» нормальной формы, эквивалентное определению нормальной формы Бойса Кодда, впервые было дано Иэном Хитом (англ. Ian Heath) в 1971 году, поэтому данную форму следовало бы называть «нормальной формой Хита» [1].

Нормализация баз данных Нормальная форма Бойса — Кодда Определение Переменная отношения находится в BCNF тогда и только тогда, когда каждая её нетривиальная и неприводимая слева функциональная зависимость имеет в качестве своего детерминанта некоторый потенциальный ключ[1]. Менее формально, переменная отношения находится в нормальной форме Бойса Кодда тогда и только тогда, когда детерминанты всех ее функциональных зависимостей являются потенциальными ключами. Для определения BCNF следует понимать понятие функциональной зависимости атрибутов отношения. Пусть R является переменной отношения, а X и Y — произвольными подмножествами множества атрибутов переменной отношения R. Y функционально зависимо от X тогда и только тогда, когда для любого допустимого значения переменной отношения R, если два кортежа переменной отношения R совпадают по значению X, они также совпадают и по значению Y. Подмножество X называют детерминантом, а Y — зависимой частью. Функциональная зависимость тривиальна тогда и только тогда, когда ее правая (зависимая) часть является подмножеством ее левой части (детерминанта). Ситуация, когда отношение будет находиться в 3 NF, но не в BCNF, возникает, например, при условии, что отношение имеет два (или более) потенциальных ключа, которые являются составными и имеют общий атрибут. На практике такая ситуация встречается достаточно редко, для всех прочих отношений 3 NF и BCNF эквивалентны.

Нормализация баз данных Нормальная форма Бойса — Кодда Пример Предположим, создаётся таблица бронирования для теннисных кортов на день: {Номер корта, Время начала, Время окончания, Тариф, Член клуба}. Тариф зависит от выбранного корта и членства в клубе. Таким образом, возможны следующие составные первичные ключи: {Номер корта, Время начала}, {Номер корта, Время окончания}, {Тариф, Время начала}, {Тариф, Время окончания}. Таблица соответствует второй и третьей нормальной форме, так как атрибуты, не входящие в состав первичного ключа, зависят от составного первичного ключа целиком (2 NF) и нет транзитивных зависимостей (3 NF). Тем не менее, существует функциональная зависимость тарифа от номера корта. То есть, по ошибке можно нарушить логическую целостность и, например, приписать тариф Premium для первого корта, хотя тариф Premium может относиться только ко второму корту. Можно улучшить структуру, разбив таблицу на две: {Номер корта, Время начала, Время окончания, Член клуба} и {Тариф, Номер корта, Член клуба}. Данное отношение будет соответствовать BCNF.

Нормализация баз данных Нормальная форма Бойса — Кодда Четвёртая нормальная форма (4 NF) Переменная отношения находится в четвёртой нормальной форме, если она находится в нормальной форме Бойса — Кодда и не содержит нетривиальных многозначных зависимостей. Пятая нормальная форма (5 NF) Переменная отношения находится в пятой нормальной форме (иначе — в проекционно соединительной нормальной форме) тогда и только тогда, когда каждая нетривиальная зависимость соединения в ней определяется потенциальным ключом (ключами) этого отношения. Доменно-ключевая нормальная форма (DKNF). Переменная отношения находится в ДКНФ тогда и только тогда, когда каждое наложенное на неё ограничение является логическим следствием ограничений доменов и ограничений ключей, наложенных на данную переменную отношения. Шестая нормальная форма (6 NF) Введена К. Дейтом в его книге, как обобщение пятой нормальной формы для темпоральной базы данных.

Инфологическое проектирование СУБД • Инфологическое проектирование прежде всего связано с попыткой представле ния семантики предметной области в модели БД. Реляционная модель данных в силу своей простоты и лаконичности не позволяет отобразить семантику, то есть смысл предметной области. • Общепринятым стало сокращенное название ER модель, большинство современ ных. CASE средств содержат инструментальные средства для описания данных в формализме этой модели. Кроме того, разработаны методы автоматического преобразования проекта БД из ER модели в реляционную.

Модель «сущность—связь» • Основные понятия: • Сущность, с помощью которой моделируется класс однотипных объектов. • Объект, которому соответствует понятие сущности, имеет свой набор атрибутов — характеристик, определяющих свойства данного представителя класса. • Набор атрибутов, однозначно идентифицирующий конкретный экземпляр сущности, называют ключевым. • сущностями могут быть установлены связи бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой.

Пример

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

Обозначения

Типы связей • Связи делятся на три типа по множественности: • один-к-одному (1: 1), • один-ко-многим (1: М), • многие-ко-многим (М: М). • Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками.

принцип категоризации сущностей • Подтип сущности, каждая из которых может иметь общие атрибуты и отношения и/или атрибуты и отношения, которые определяются однажды на верхнем уровне и наследуются на нижнем уровне. • Все подтипы одной сущности рассматриваются как взаимоисключающие, и при разделении сущности на подтипы она должна быть представлена в виде полного набора взаимоисключающих подтипов.

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

Пример супертипа и подтипов

Результат проектирования • В результате построения модели предметной области в виде набора сущностей и связей получаем связный граф. В полученном графе необходимо избегать цик лических связей — они выявляют некорректность модели.

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

Пример ER модели

Использование ERWin для построения модели данных

ERWin • Чтобы запустить программу нужно выбрать следующий путь: – Program files > CA Associates > All. Fusion > ERWin Data Modeler > ERWin

Начало работы с ERWin

Выбор логической/физической модели

Пустая логическая модель

Изменение свойств модели Здесь можно задать тип модели, например, IDEF 1 X а также тип физической нотации.

Методология SADT как основа IDEF SADT (акроним от англ. Structured Analysis and Design Technique) — методология структурного анализа и проектирования, интегрирующая процесс моделирования, управление конфигурацией проекта, использование дополнительных языковых средств и руководство проектом со своим графическим языком. Процесс моделирования может быть разделен на несколько этапов: опрос экспертов, создание диаграмм и моделей, распространение документации, оценка адекватности моделей и принятие их для дальнейшего использования. Этот процесс хорошо отлажен, потому что при разработке проекта специалисты выполняют конкретные обязанности, а библиотекарь обеспечивает своевременный обмен информацией. SADT возникла в конце 60 х годов в ходе революции, вызванной структурным программированием. Когда большинство специалистов билось над созданием программного обеспечения, немногие старались разрешить более сложную задачу создания крупномасштабных систем, включающих как людей и машины, так и программное обеспечение, аналогичных системам, применяемым в телефонной связи, промышленности, управлении и контроле за вооружением. В то время специалисты, традиционно занимавшиеся созданием крупномасштабных систем, стали осознавать необходимость большей упорядоченности. Таким образом, разработчики решили формализовать процесс создания системы, разбив его на следующие фазы: 1. 2. 3. 4. 5. 6. Анализ — определение того, что система будет делать, Проектирование — определение подсистем и их взаимодействие, Реализация — разработка подсистем по отдельности, объединение — соединение подсистем в единое целое, Тестирование — проверка работы системы, Установка — введение системы в действие, Эксплуатация — использование системы.

Методологии IDEF — методологии семейства ICAM (Integrated Computer Aided Manufacturing) для решения задач моделирования сложных систем, позволяет отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. При этом широта и глубина обследования процессов в системе определяется самим разработчиком, что позволяет не перегружать создаваемую модель излишними данными. IDEF — методологии создавались в рамках предложенной ВВС США программы компьютеризации промышленности — ICAM, в ходе реализации которой выявилась потребность в разработке методов анализа процессов взаимодействия в производственных (промышленных) системах. Принципиальным требованием при разработке рассматриваемого семейства методологий была возможность эффективного обмена информацией между всеми специалистами — участниками программы ICAM (отсюда название: Icam DEFinition — IDEF другой вариант — Integrated DEFinition). После опубликования стандарта он был успешно применен в самых различных областях бизнеса, показав себя эффективным средством анализа, конструирования и отображения бизнес процессов. Более того, собственно с широким применением IDEF (и предшествующей методолoгии — SADT) и связано возникновение основных идей популярного ныне понятия — BPR (бизнес процесс реинжиниринг).

Методология IDEF 0 – Функциональное моделирование Function Modeling — методология функционального моделирования. С помощью наглядного графического языка IDEF 0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функций (функциональных блоков — в терминах IDEF 0). Как правило, моделирование средствами IDEF 0 является первым этапом изучения любой системы. Методологию IDEF 0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique).

Методология IDEF 0 – Функциональное моделирование

Методология IDEF 1 – Информационное моделирование Information Modeling — методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи. IDEF 1 X (IDEF 1 Extended) — Data Modeling — методология моделирования баз данных на основе модели «сущность связь» . Применяется для построения информационной модели, которая представляет структуру информации, необходимой для поддержки функций производственной системы или среды. Метод IDEF 1, разработанный Т. Рэмей (T. Ramey), также основан на подходе П. Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF 1 создана ее новая версия — методология IDEF 1 X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF 1 X–диаграммы используются рядом распространённых CASE– средств (в частности, ERwin, Design/IDEF).

Методология IDEF 1 X

Методология IDEF 2 Simulation Model Design — методология динамического моделирования развития систем. В связи с весьма серьёзными сложностями анализа динамических систем от этого стандарта практически отказались, и его развитие приостановилось на самом начальном этапе. В настоящее время присутствуют алгоритмы и их компьютерные реализации, позволяющие превращать набор статических диаграмм IDEF 0 в динамические модели, построенные на базе «раскрашенных сетей Петри» (CPN — Color Petri Nets);

Другие методологии IDEF 4 - Object-Oriented Design — методология построения объектно ориентированных систем, позволяют отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно ориентированные системы. IDEF 5. Ontology Description Capture — Стандарт онтологического исследования сложных систем. С помощью методологии IDEF 5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация. IDEF 6 – IDEF 14

Настройка панели управления • Выберете view, toolbars and toolbox. • Это обеспечит Вам возможность добавления сущностей и связей посредством соответствующих иконок панели управления.

Альтернативный способ добавления сущностей • Сущности – Щелкните правой кнопкой мыши по иконке сущности в окне • Иконка сущности находится в левом окне

Чтобы добавить атрибуты нужно… • Раскрыть иконку сущности • Правой кнопкой мыши кликнуть по иконке атрибутов и добавить атрибут • Правой кнопкой мыши кликнуть по атрибуту и открыть его свойства • Здесь можно задать первичный ключ и типы данных для атрибутов, которые могут быть в дальнейшем им присвоены

Добавление внешних ключей

Результаты “идентификации”

Связь без идентификации

Идентифицирующей связью называется связь, которая добавляет признаки идентичности в дочернюю сущность путем миграции ключей родительской сущности в область ключевых атрибутов дочерней и таким образом делая дочернюю сущность зависимой от родительской в смысле своей идентичности. Например, когда атрибут movie numb. ER мигрирует из сущности MOVIE в MOVIE COPY на диаграмме MOVIES. ER 1, то каждый экземпляр MOVIE COPY зависит и от movie numb. ER, и от movie copy numb. ER, которые уникальным образом его определяют (ни один из этих двух атрибутов не может сам по себе уникальным образом определить конкретную копию фильма). Можно задать также и такую связь, которая не ставит дочернюю сущность в зависимость от родительской. Этот тип связи называется неидентифицирующей связью. В ERwin такая связь обозначается пунктирной линией с жирной точкой на конце, соответствующем дочерней связи. При неидентифицирующей связи атрибуты первичного ключа родительской сущности мигрируют в область данных (неключевая область) , которая расположена под чертой в дочерней сущности. Если атрибуты, которые мигрировали в неключевую область дочерней сущности, не нужны в этой сущности, то связь называется необязательной неидентифицирующей связью, что подразумевает, что мигрировавшие атрибуты не нужны дочерней сущности для ее идентификации и что она может существовать и без этих атрибутов. В ERwin необязательная неидентифицирующая связь обозначается пунктирной линией с жирной точкой на одном конце (дочернем) и ромбиком на другом (родительском).

Разрешить или не разрешить нулевые значения? Когда Вы рисуете неидентифицирующую связь, Вам нужно решить, могут ли атрибуты внешнего ключа, наследуемые от родителя, принимать значение NULL или нет. По умолчанию для неидентифицирующей связи задается режим 'Nulls Allowed', что означает, что дочерняя сущность может существовать без родительской, и связь называется необязательной. 'No Nulls' означает, что существование дочерней сущности зависит от родительской, и связь называется обязательной. В случае необязательной связи (Nulls Allowed) на родительском конце неидентифицирующей связи ERwin ставит знак ромбик. Одно из основных различий между идентифицирующей и неидентифицирующей связью в том, что только те внешние ключи, которые мигрируют через неидентифицирующую связь, могут принимать значения NULL. По умолчанию для неидентифицирующей связи установлен режим 'Nulls Allowed', т. е. значения NULL для внешних ключе

Чтобы перейти к физической модели… Выберите физическую модель (‘physical’) в выпадающем списке • .

Чтобы сформировать схему БД… • Используйте физическую модель • Выбирайте БД Oracle 9. x или выше • Выберите Forward Engineer / Schema generation • Определите (выберите) элементы схемы, которые нужно сгенирить

Опции схемы БД

Опции представления

Опции таблицы

Опции столбцов

Опции индексов

Ссылочная целостность

Триггеры

Другие опции

Когда все параметры установлены • Выберите (кликните) “Generate”, если есть коннект к Вашей схеме БД иначе: • Выберите (кликните) Preview – Это даст Вам SQL скрипт, который нужно запустить чтобы создать свою схему БД – Можно сохранить SQL –скрипт и запустить его позднее.

Просмотр SQL скрипта

Спасибо за внимание

Реализация различных уровней проектирования СУБД с использованием Er. Win для предметно ориентированной ( «домашней» ) базы данных Домашнее задание: Построить в ER диаграмму к домашней базе данных (не менее 6 реляционных таблиц) с использованием ER Win.

Практическое упражнение по БД