Документирование делового регламента

Слабые сущности

Слабая сущность (weak entity) - это особый тип сущности, которая может существовать только если существует сущность какого-то другого типа. Сущность не являющаяся слабой называется сильной сущностью (strong entity). Если имеется две сущности и связь, то сущность способная существовать без связи с другой сущностью будет сильной. Та, что обязательно должна быть связана - слабой. На диаграммах слабые сущности могут быть изображены как прямоугольники со скругленными углами.

К особому типу слабых сущностей относятся идентификационно-зависимые сущности (ID-dependent entities). Это такие сущности, идентификатор которых содержит идентификатор другой сущности. Например, имеется две сущности: ДОМ и КВАРТИРА. У сущности ДОМ идентификатором является атрибут НазваниеДома, а у сущности КВАРТИРА композитным идентификатором являются атрибуты НазваниеДома сущности ДОМ и НомерКвартиры сущности КВАРТИРА. В данном примере, сущность КВАРТИРА будет идентификационно-зависимой.

В больших базах данных, где имеется множество сущностей, связанных друг с другом, может возникнуть неоднозначное толкование понятия слабой сущности. Некоторые разработчики ошибочно считают, что если какая-то сущность должна быть обязательно связана с другой отличного типа - то эта сущность слабая. Для того чтобы исключить путаницу, слабыми сущностями будут считаться те, которые логически зависят от сильных. Например - ТЕЛЕФОН при ведении списка телефонов для какого-либо человека. Нелогично предположить наличие телефона без наличия человека, которому этот телефон принадлежит. Слабые сущности идеально подходят для представления многозначных атрибутов о которых говорилось в разделе «Атрибуты».

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

Проектирование баз данных. Реляционная модель данных

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

Для того чтобы лучше понять что такое нормализация, начнем с того, что не все отношения одинаковы: некоторые являются более предпочтительными. Нормализация (normalization) - это процесс преобразования отношения имеющего недостатки в отношение, которое этих недостатков не имеет. Термин нормализация появился благодаря Э. Ф. Кодду, который определил различные нормальные формы (normal forms) отношений.

Реляционная модель

Двумерная таблица в реляционной модели именуется отношением (relation). Каждая строка таблицы содержит данные о некоторой вещи или конкретной её части. Каждый столбец таблицы описывает конкретный атрибут этой вещи. Строки иногда называют кортежами (tuples), а столбцы - атрибутами (attributes). Термины отношение, кортеж и атрибут пришли из реляционной математики, но для профессиональных программистов удобнее отношения называть файлами (file), кортежи - записями (record), а атрибуты - полями (field). Пользователи, в свою очередь, называют отношение - таблица (table), кортеж - строка (row), а атрибут - столбец (column).

Для того чтобы таблица стала отношением, она должна удовлетворять определенным критериям:

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

Все записи в одном столбце должны быть одного типа.

Каждый столбец должен иметь уникальное имя. Порядок столбцов в таблице неважен.

В таблице не должно быть двух одинаковых строк. Порядок следования строк в таблице не важен.

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

Функциональные зависимости

Функциональная зависимость (functional dependency) - это связь между атрибутами. Таким образом, атрибут Y функционально зависит от атрибута X если зная X мы можем определить Y. Функциональная зависимость может быть выражена уравнениями, например, Стоимость = Цена * Количество, но функциональные зависимости между атрибутами в отношении обычно не выражаются уравнениями. Допустим, имеются студенты, у каждого из которых есть уникальный идентификационный номер и каждый студент обучается по одной и только одной специальности. Таким образом, имея уникальный идентификационный номер студента, можно узнать его специальность. Поэтому, атрибут «Специальность» функционально зависит от атрибута «ИдентификационныйНомер» и эта зависимость обозначается как:

ИдентификационныйНомер > Специальность

Фактически, можно говорить, что база данных нужна только для хранения и выдачи функциональных зависимостей. Как уже говорилось, если идентификационный номер студента определяет специальность, то каждому номеру студента соответствует только одна специальность. С другой стороны, одной и той же специальности будет соответствовать несколько студентов, ибо все студенты обучающиеся на одной и той же специальности будут с ней связаны. В данном случае можно сказать, что связь атрибутов «ИдентификационныйНомер» и «Специальность» имеет вид N:1. В общем случае, справедливо утверждение, что если A определяет B, то отношение между значениями A и B имеет вид N:1.

Между тем, в функциональные зависимости могут быть вовлечены группы атрибутов. Например, группа атрибутов студента «ИдентификационныйНомер» и «Дисциплина» определяет оценку. В этом случае, зависимость обозначается как:

(ИдентификационныйНомер, Дисциплина) > Оценка

Стоит заметить, что ни ИдентификационныйНомер ни Дисциплина не могут самостоятельно определить оценку, следовательно, эта группа не может быть разделена. Так же стоит обратить внимание на следующее различие. Если X > (Y, Z), то X > Y и X > Z. Но если (X, Y) > Z, то в общем случае неверно что X > Z или Y > Z.

Ключи

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

Функциональные зависимости, ключи и уникальность

У многих возникает путаница с понятиями функциональной зависимости, ключа и уникальности. Для того чтобы избежать путаницы, уясните себе следующее: Если известно, что A определяет B и что A и B находятся в одном отношении, то однозначно утверждать можно только о функциональной зависимости между A и B. Уникальность А не гарантируется. Ключи же всегда должны быть уникальными, потому что дублирование ключа означает дублирование всего кортежа, что противоречит определению отношения.

Нормализация

Таблица, отвечающая минимальному определению отношения, может иметь неэффективную или неподходящую структуру. Изменение данных для некоторых отношений может привести к нежелательным последствиям, называемым аномалиями модификации (modification anomalies).

Аномалии модификации

Допустим, имеется отношение, в котором хранится информация о студентах, курсах которые они посещают и стоимости этих курсов. Из этого отношения производится удаление кортежа, который содержит (помимо информации о студенте) информацию о названии и стоимости курса, посещаемого этим студентом. Если информация о названии и стоимости курса хранилась в единственном экземпляре только в этом кортеже, она безвозвратно исчезнет из отношения. Такая ситуация называется аномалия удаления (deletion anomaly). Выполнение операции удаления приводит к потере информации о двух сущностях.

На примере этого же отношения можно проиллюстрировать аномалию вставки (insertion anomaly). Допустим, надо добавить информацию о названии и стоимости определенного курса, но мы не сможем добавить эту информацию до тех пор, пока на курс не записан ни один студент. Избавиться от обоих аномалий можно путем разбиения имеющегося отношения на два, каждое из которых будет содержать данные только одной сущности. Таким образом, удаление информации о студенте не затронет данные о курсах.

При разбиении отношения на два так же возникают проблемы. Например, можно ли записать студента на несуществующий пока курс? Эти проблемы должны решаться путем обсуждения бизнес-правил. Если бизнес-правилами будет предусмотрено требование наличия информации о курсе и стоимости при записи на этот курс студента, то при записи студента на курс будет производиться проверка на существование требуемого курса. Подобного рода проверки называются ограничениями ссылочной целостности (referential integrity constraints) или ограничениями целостности по внешнему ключу (interrelation constraints).

Суть нормализации

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

Классы отношений

Отношения можно классифицировать по типам аномалий модификации которым они подвержены. С 1970-х годов теоретики реляционных баз данных постепенно сокращали количество этих типов. Как только кто-то находил аномалию он классифицировал её, думал как предотвратить её возникновение и критерии построения отношений совершенствовались. Классы отношений и способы предотвращения аномалий называются нормальными формами (normal forms).

В своей работе 1970 года, Кодд и другие определили первую, вторую и третью нормальные формы (1НФ, 2НФ, 3НФ). Позднее, появилась нормальная форма Бойса-Кодда (НФБК), а еще позднее - четвертая и пятая нормальные формы. Все нормальные формы являются вложенными, а это означает, что отношение в третьей нормальной форме так же является отношением во второй и первой нормальной форме.

Нормальные формы помогали разработчикам, но у них было серьезное ограничение - не было теории, доказывающей что какая-либо из форм устранит все аномалии. Ситуация улучшилась в 1981 году, когда Р. Фагин (R. Fagin) ввел новую нормальную форму, которую он назвал доменно-ключевой нормальной формой или ДКНФ (domain/key normal form, DK/NF). В своей статье Фагин показал, что отношение в ДКНФ свободно от всех аномалий модификации, независимо от их типа. Так же он показал, что любое отношение, свободное от аномалий всех типов должно находиться в ДКНФ. Таким образом, если возможно привести отношение к ДКНФ, то можно быть уверенным, что оно будет свободно от всех аномалий. Вопрос только в том как привести отношение в ДКНФ.

Нормальные формы от первой до пятой

Первая нормальная форма (1НФ)

О любой таблице, которая соответствует определению отношения, говорят, что она находится в первой нормальной форме (first normal form, 1NF). Вспомним, что это за условия:

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

Все записи в одном столбце должны быть одного типа.

Каждый столбец должен иметь уникальное имя. Порядок столбцов в таблице неважен.

В таблице не должно быть двух одинаковых строк. Порядок следования строк в таблице так же не важен.

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

Вторая нормальная форма (2НФ)

Отношение находится во второй нормальной форме (second normal form, 2NF) если все его неключевые атрибуты зависят от всего ключа. Из этого определения можно сделать один важный вывод. Если в отношении использовать в качестве ключа одиночный атрибут, то оно автоматически находится во второй нормальной форме. Поскольку ключ является одиночным атрибутом, то по умолчанию каждый неключевой атрибут зависит от всего ключа, и частичных зависимостей быть не может. Следовательно, вторая нормальная форма представляет интерес только для тех отношений, которые имеют композитные ключи.

Третья нормальная форма (3НФ)

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

Нормальная форма Бойса-Кодда (НФБК)

Представим, что вместо стоимости курса в нашем примере будет фигурировать преподаватель. Существуют так же бизнес-правила, в соответствии с которыми один преподаватель может преподавать только в пределах одного курса. На одном курсе может быть несколько преподавателей. Таким образом преподаватель для одного курса будет не одним и тем же, а меняться для разных студентов. Таким образом, преподаватель курса будет зависеть от пары атрибутов - (ИдентификационныйНомер, Курс), а курс - от пары атрибутов (ИдентификационныйНомер, Преподаватель). Две указаные пары атрибутов будут называться ключами-кандидатами (candidate keys). Та пара атрибутов, которая в итоге будет выбрана - будет называться первичным ключем (primary key).

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

Четвертая нормальная форма (4НФ)

Отношение находится в четвертой нормальной форме (fourth normal form, 4NF) если оно находится в НФБК и не имеет многозначных зависимостей. Иными словами, детерминант должен определять одно значение атрибута, функционально зависящего от него. Если ИдентификационныйНомер студента определяет не один, а несколько курсов, то это противоречит условию четвертой нормальной формы.

Пятая нормальная форма (5НФ)

пятая нормальная форма связана с зависимостями, которые имеют неопределенный характер. Речь идет об отношениях, которые можно разделить на несколько более мелких, но затем невозможно восстановить. Например, имеется две таблицы - «Экзамены» или «Зачеты». И в одной и в другой содержатся записи предметов и дата экзамена или зачета. Если сделать таблицу «Оценки», в которой будет храниться код предмета и оценка, но не будет храниться никакой информации относительно того из какой таблицы эта оценка - восстановить информацию при выборке будет невозможно, хотя записать информацию в такую схему данных вполне реально.

Синтез отношений

Атрибутивная связь "один к одному"

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

Атрибутивная связь "один ко многим"

Если в создаваемом отношении A определяет B, то добавлять в это отношение можно только те атрибуты, которые определяются атрибутом A.

Атрибутивная связь "многие ко многим"

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

Оптимизация

Иногда результат нормализации не стоит затраченных на него усилий. В таких случаях можно объединить часть атрибутов в одном отношении вопреки требованиям нормализации.

Денормализация

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

Преднамеренная избыточность

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

ER-модели широко используются в практике создания БД. Они применяются при ручном и автоматизированном проектировании с использованием CASE-средств, поддерживающих весь цикл разработки СБД или отдельные его стадии. Ктаким средствам относятся: ProKit*WORKBENCH, Design / IDEF, CASE Oracle (Designer / 2000), Power Designer (S-Designor), ERWin, SILVERRUN, ERStudio и другие. CASE-средства являются сравнительно новым направлением в информационных технологиях. Первая версия инструментария Oracle появилась в 1989 г.

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

При сравнении CASE-систем кроме используемой методологии ER-моделирования, необходимо учитывать специфические критерии, связанные с реализацией функций автоматизированного проектирования:

· число и перечень поддерживаемых целевых СУБД;

· поддержку распределенных БД;

· поддержку коллективной работы при проектировании (управление правами пользователей, ведение репозитория и т. д.);

· построение концептуальной ER-модели по описанию структуры существующей БД – реверс-инжиниринг;

· автоматизируемые функции проектирования и степень их автоматизации;

· качество и жесткость проектных решений (возможность выбора из нескольких альтернативных решений, возможность ручного вмешательства в процесс);

· надежность работы;

· документирование проекта;

· открытость системы (возможность стыковки с другими средствами);

· удобство графического редактора;

· количественные ограничения (общее число сущностей, число уровней вложенности для обобщенной сущности и др.);

· возможность автоматической оценки объема памяти для проектируемой БД;

· возможность автоматической генерации процедур;

· наличие средств моделирования хранилищ данных;

· требования к ресурсам компьютера;

· операционную среду;

· стоимость системы.

CASE-средства показывают модель с разной степенью детализации:

· только обозначения сущностей и связей между ними;

· сущности + ключи;

· сущности + ключи + внешние ключи;

· сущности + все атрибуты.

Наличие таких возможностей создает существенные удобства, особенно при создании больших и сложных моделей.

Важной характеристикой CASE-средств является возможность получать подмодели из общей модели и обеспечивать интеграцию фрагментов в единую модель. Эти возможности могут быть полезны не только при коллективной разработке проекта – при обсуждении модели с конечными пользователями очень удобно каждому из них предоставлять только ту часть модели, которая имеет для него интерес. Декомпозиция модели облегчает процесс проектирования.

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

Наличие средств проверки моделей может помочь устранить ошибки, связанные с невнимательностью – отсутствие идентификатора у сущности, отсутствие связи объекта с другими объектами, неправильное задание имен, отсутствие информации, необходимой при дальнейшем проектировании (объемные характеристики для классов объектов и связей между ними и т. п.), противоречия в модели (что особенно важно при коллективной разработке) и др.

Многие CASE-средства этим позволяют задавать в модели ограничения целостности и генерируют программы (триггеры, хранимые процедуры), проверяющие эти ограничения при эксплуатации БД. Кроме того, CASE-средства могут генерировать программы ведения БД.

Многие CASE-средства позволяют экспортировать модели в другие системы и, наоборот, импортировать их из других систем.

Дата добавления: 2015-05-10