Элементы ER-моделирования

Модель предметной области - это наши знания о предметной области. Знания могут быть как в виде неформальных знаний в сознании эксперта, так и выражены формально при помощи каких-либо средств.

В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в университете и т.п. Опыт показывает, что текстовый способ представления модели предметной области крайне неэффективен. Гораздо более информативными и полезными при разработке баз данных являются описания предметной области, выполненные при помощи специализированных графических нотаций. Имеется большое количество методик описания предметной области. Из наиболее известных можно назвать методику структурного анализа SADT и основанную на нем IDEF0, методику объектно-ориентированного анализа и проектирования UML, и другие. Модель предметной области описывает скорее процессы, происходящие в предметной области и данные, используемые этими процессами. От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки приложений.

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

Примеры понятий - "сотрудник", "факультет", "дисциплина", "группа". Примеры взаимосвязей между понятиями - "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений - "возраст сотрудника не менее 16 и не более 60 лет".

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

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

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

При разработке физической модели данных возникают вопросы: хорошо ли спроектированы таблицы? Правильно ли выбраны индексы? Насколько много программного кода в виде триггеров и хранимых процедур необходимо разработать для поддержания целостности данных?

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

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

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

Основная цель проектирования БД – это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте.

Критерии оценки качества логической модели данных. Цель введения критериев – дать некоторые величины, характеризующие принципы построения хороших логических моделей данных. Хороших в том смысле, что решения, принятые в процессе логического проектирования приводили бы к хорошим физическим моделям и в конечном итоге к хорошей работе БД.

Критерии качественной базы данных:

· Адекватность базы данных предметной области;

· Легкость разработки и сопровождения базы данных;

· Скорость выполнения операций обновления данных (вставка, обновление, удаление кортежей);

· Скорость выполнения операций по работе с данными данных.

Адекватность базы данных предметной области. База данных должна адекватно отражать предметную область. Это означает, что должны выполняться следующие условия:

• Состояние базы данных в каждый момент времени должно соответствовать состоянию предметной области.

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

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

Одно из назначений базы данных - предоставление информации пользователям. Информация извлекается из реляционной базы данных при помощи оператора SQL - SELECT. Одной из наиболее дорогостоящих операций при выполнении оператора SELECT является операция соединение таблиц. Таким образом, чем больше взаимосвязанных отношений было создано в ходе логического моделирования, тем больше вероятность того, что при выполнении запросов эти отношения будут соединяться, и, следовательно, тем медленнее будут выполняться запросы. Таким образом, увеличение количества отношений приводит к замедлению выполнения операций выборки данных, особенно, если запросы заранее неизвестны.

2.5.1 Основные понятия модели «сущность-связь»

Моделирование структуры базы с использованием строгих правил и алгоритмов нормализации имеет свои недостатки. Поэтому в реальном проектировании архитектуры БД чаще применяется семантическое моделирование. Такое моделирование представляет собой моделирование структуры данных исходя из смысловой нагрузки на эти данные. При таком моделировании в качестве инструмента используются различные варианты ER моделирования – моделирования сущность-связь. Разработка базы данных основывается на методе проектирования с помощью диаграмм «сущность-связь» (E/R - диаграмм).

ER-диаграмма – это графическое представление предметов и отношений между ними. Ее цель – точно представить на логическом уровне данные, которые необходимо хранить и обрабатывать.

Атрибуты. Атрибуты представляют данные об объектах, которые необходимо хранить. Атрибуты представляются именами существительными, которые описывают характеристики сущностей.

Сущност ь – это множество экземпляров реальных или абстрактных объектов, обладающих атрибутами или характеристиками. Имя сущности отображает тип объекта (обычно имя существительное).

Связь – это некоторая ассоциация между двумя и более сущностями, которая показывает взаимосвязь между ними. Характеризуется типами связей (1:1, 1:n, n:m). Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем, то связь называется идентифицирующей, в противном случае - неидентифицирующей. Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может существовать для каждого экземпляра сущности-родителя). Могут быть выражены следующие мощности связей:

· каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;

· каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

· каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;

· каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

Дата добавления: 2014-11-20