🗊Презентация Инфологическое моделирование предметной области. Лекция 4

Этапы проектирования БД Проектирование реляционной базы данных в терминах отношений на основе механизма нормализации представляет собой очень сложный и неудобный для проектировщика процесс.

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

Семантические модели данных Семантическое моделирование используется на первой стадии проектирования базы данных. При этом в терминах семантической модели строится концептуальная схема базы данных, которая затем автоматически преобразуется к реляционной (или какой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых достаточно четко оговорены все этапы.

Стадии проектирования БД

Стадии проектирования БД Инфологическое проектирование Инфологическая модель (или семантическая или концептуальная модель) – формализованное представление предметной области (без привязки к СУБД, типам данных, программным средствам и т.п.) Даталогическое проектирование Даталогическая модель – привязка к конкретному типу СУБД (например, реляционной СУБД); Конечная цель – описание структуры БД с учетом особенностей модели данных используемой СУБД. Физическое проектирование – проектирование физической структуры БД (выборы носителей, определение размеров физических блоков, буферизация и др.)

Стадии проектирования БД

Этап 1.6. Создание диаграммы «сущность-связь» Большинство современных подходов к проектированию баз данных (главным образом, реляционных) основано на использовании разновидностей ER-модели. Рассмотрим основные понятия ER-модели..

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

Cемантическое моделирование БД В реальном проектировании структуры базы данных применяются метод семантического моделирования. Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).

Модель Entity-Relationship (Сущность-Связи) Модель сущность-связь (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области. ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Питером Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных.1x). На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Питером Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных.1x).

Нотации (графические диаграммы), используемые для визуализации ER-моделей: Нотация Питера Чена Crow's Foot IDEF1X

Диаграмма «Сущность-связь» в нотации Питера Чена Множества сущностей изображаются в виде прямоугольников, множества отношений изображаются в виде ромбов. Если сущность участвует в отношении, они связаны линией. Если отношение не является обязательным, то линия пунктирная. Атрибуты изображаются в виде овалов и связываются линией с одним отношением или с одной сущностью.

Диаграмма «Сущность-связь» в нотации Питера Чена (метамодель)

Пример диаграммы «Сущность-связь» в нотации Чена

Основные понятия модели Entity-Relationship (Сущность-Связи) Основными понятиями ER-модели являются сущность, связь и атрибут. Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности - это имя типа, а не некоторого конкретного экземпляра этого типа. Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности.

Сущность, атрибут Сущность – это объект, который может быть идентифицирован некоторым способом, отличающим его от других объектов. Каждая сущность обладает набором атрибутов. Атрибут - отдельная характеристика сущности. Сущность состоит из экземпляров, каждый из которых должен отличаться от другого экземпляра. Пример: сущность – «Город», экземпляры сущности «Город» – Москва, Пенза, Рязань.

Нотация IDEF1X Сущность обладает одним или несколькими атрибутами, которые являются либо собственными для сущности, либо наследуются через другое отношение (от PK «родителя» передается FK в «сущность-потомок»). Атрибуты однозначно идентифицируют каждый экземпляр сущности. Каждый атрибут идентифицируется уникальным именем. Атрибуты изображаются в виде списка их имен внутри блока ассоциированной сущности, причем каждый атрибут занимают отдельную строку. Определяющие первичный ключ атрибуты размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой.

Ключ Ключ - минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Первичный ключ сущности позволяет идентифицировать ее экземпляры, а внешний – экземпляры сущности, которая находится в связи с данной сущностью.

Типы сущностей Независимая сущность Для определения экземпляра сущности нет необходимости ссылаться на другие сущности. Зависимая сущность Для определения экземпляра такой сущности необходимо сослаться на экземпляр независимой сущности, с которой связана зависимая сущность.

Обозначение сущностей в нотации IDEF1X

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

Примеры: Примеры: Связь один к одному: «Страна» - «Столица» Связь один ко многим: «Группа» - «Студент» Связь многие ко многим: «Сотрудник» - «Проект»

Связь «один-ко-многим»: Отделы – Сотрудники

Связи "many-to-many". Иногда бывает необходимо связывать сущности таким образом, что с обоих концов связи могут присутствовать несколько экземпляров сущности. Например, сотрудники консалтинговой компании участвуют в проектах. При этом один сотрудник может участвовать в нескольких проектах и в одном проекте могут участвовать несколько сотрудников. Для этого вводится разновидность связи "многие-со-многими". Связи "many-to-many". Иногда бывает необходимо связывать сущности таким образом, что с обоих концов связи могут присутствовать несколько экземпляров сущности. Например, сотрудники консалтинговой компании участвуют в проектах. При этом один сотрудник может участвовать в нескольких проектах и в одном проекте могут участвовать несколько сотрудников. Для этого вводится разновидность связи "многие-со-многими". Оформляются через «развязочные таблицы», например: «участие в проектах» (сущность из двух атрибутов: код сотрудника (FK), код проекта (FK)).

Виды связей

Виды связей

Виды связей

Виды связей

Идентифицирующие и неидентифицирующие связи

Пример БД: «Проектная организация»

Пример ER-диаграммы в MySQL WORKBENCH

Пример ER-диаграммы в CA ERwin Data Modeler (ERwin)

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

Нормальные формы ER-схем Во второй нормальной форме устраняются атрибуты, зависящие только от части уникального идентификатора. Эти атрибуты должны определять отдельную сущность. В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности. При правильном проектировании все СУЩНОСТИ должны быть по крайней мере в третьей нормальной форме.

Получение реляционной схемы из ER-схемы Шаг 1. Каждая простая сущность превращается в таблицу. Имя сущности становится именем таблицы. Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут. Шаг 3. Компоненты уникального идентификатора сущности превращаются в первичный ключ таблицы.

Получение реляционной схемы из ER-схемы Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения. Шаг 5. Индексы создаются для первичного ключа (уникальный индекс) и внешних ключей.

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

Пример разработки ER-модели Предположим, что перед нами стоит задача разработать информационную систему управления заказами для оптовой торговой фирмы. В первую очередь мы должны изучить предметную область и процессы, происходящие в ней. Для этого мы опрашиваем сотрудников фирмы, читаем документацию, изучаем формы заказов, накладных и т.п. Менеджер по продажам считает, что проектируемая система должна выполнять следующие действия: Хранить информацию о покупателях. Печатать накладные на отпущенные товары. Следить за наличием товаров на складе.

Пример разработки ER-модели Выделим все существительные в этих предложениях - это будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса): Покупатель - явный кандидат на сущность Накладная - явный кандидат на сущность Товар - явный кандидат на сущность (?)Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность. (?)Наличие товара – это, скорее всего, атрибут, но атрибут какой сущности?

Сразу возникает очевидная связь между сущностями - "покупатели могут покупать много товаров" и "товары могут продаваться многим покупателям". Первый вариант диаграммы выглядит так:

После уточнения информации стало известно, что: После уточнения информации стало известно, что: Фирма имеет несколько складов. Причем, каждый товар может храниться на нескольких складах и быть проданным с любого склада. Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя.

Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных.

Таким образом, после уточнения, диаграмма будет выглядеть следующим образом: Таким образом, после уточнения, диаграмма будет выглядеть следующим образом:

Пример разработки ER-модели Перейдем к атрибутам сущностей. Беседуя с сотрудниками фирмы, мы выяснили следующее: Каждый покупатель является юридическим лицом и имеет наименование, адрес, банковские реквизиты. Каждый товар имеет наименование, цену, а также характеризуется единицами измерения. Каждая накладная имеет уникальный номер, дату выписки, список товаров с количествами и ценами, а также общую сумму накладной. Накладная выписывается с определенного склада и на определенного покупателя. Каждый склад имеет свое наименование.

Пример разработки ER-модели Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их: Юридическое лицо - термин риторический, фирма не работает с физическими лицами. Не обращаем внимания. Наименование покупателя - явная характеристика покупателя. Адрес - явная характеристика покупателя. Банковские реквизиты - явная характеристика покупателя. Наименование товара - явная характеристика товара.

Пример разработки ER-модели (?)Цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной? Единица измерения - явная характеристика товара. Номер накладной - явная уникальная характеристика накладной. Дата накладной - явная характеристика накладной. (?)Список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность.

Пример разработки ER-модели (?)Количество товара в накладной - это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной". (?)Цена товара в накладной - опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же? Сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную. Наименование склада - явная характеристика склада.

Выводы Реальным средством моделирования данных является не формальный метод нормализации отношений, а так называемое семантическое моделирование. В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship). Диаграммы сущность-связь позволяют использовать наглядные графические обозначения для моделирования сущностей и их взаимосвязей.

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