Создание базы данных

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

Тем не менее, взаимосвязь  может отражать зависимость существования, если бизнес правило для взаимосвязи определяет то, что внешний ключ не может принимать значение NULL. Если внешний ключ должен существовать, то это означает, что запись в дочерней сущности может существовать только при наличии ассоциированной с ним родительской записи.

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

Модель «сущность-связь»  для базы данных ООО «Сиберия» представлена в Приложении 3.

 

 

 

 

 

 

 

 

 

 

 

 

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

 

Часто в базах данных возникает такая ситуация, когда одна  и та же информация повторяется неоправданно большое количество раз, что засоряет базу и делает сложным обновлять и дополнять её.

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

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

Теория нормализации основывается на наличии той или  иной зависимости между столбцами  таблицы.

 

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

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

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

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

 

 

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

1. первая нормальная форма (1NF);
2. вторая нормальная форма (2NF);
3. третья нормальная форма (3NF);
4. нормальная форма Бойса-Кодда (BCNF);
5. четвертая нормальная форма (4NF);
6. пятая нормальная форма, или форма проекции-соединения (5NF или PJNF).

 

Основные свойства нормальных форм:

• каждая следующая нормальная форма в некотором смысле улучшает свойства предыдущей;
• при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

 

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

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

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

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

Четвертая и пятая  нормальные формы учитывают не только функциональные, но и многозначные зависимости между атрибутами.

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

Четвертая нормальная форма является частным случаем пятой нормальной формы, когда полная декомпозиция является соединением ровно двух проекций.

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

Исходя из этих соображений, и структуру базы ООО «Сиберия» следует привести к третьей нормальной форме, или показать, что она уже удовлетворяет ее требованиям: несложно установить, что каждый атрибут любой сущности содержит атомарное значение (выполнены требования первой нормальной формы), составные ключи не используются (схема базы данных находится во второй нормальной форме) и, наконец, анализ отдельных сущностей подтверждает, что структура базы данных удовлетворят требованиям третьей нормальной формы. Следовательно, перед нами задача преобразования структуры не стоит, это тем лучше, что ERwin не содержит полного алгоритма нормализации и не может проводить нормализацию автоматически. Однако его возможности облегчают создание нормализованной модели данных. Запрет на присвоение неуникальных имен атрибутов в рамках модели (при соответствующей установке опции Unique Name) облегчает соблюдение правила "один факт - в одном месте". Имена ролей атрибутов внешних ключей и унификация атрибутов также облегчают построение нормализованной модели.

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

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

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

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

 

6. Разработка физического уровня модели

 

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

Различают два подуровня физического уровня модели данных:

- трансформационная модель (Transformation Model);

- модель СУБД (DBMS Model).

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

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

Физический уровень  модели зависит от выбранного сервера. Для выбора СУБД служит редактор Target Server (меню Database/Choose Database доступно только на физическом уровне). Для выбора СУБД нужно щелкнуть по соответствующей кнопке рядом с именем СУБД.

Диалог Target Server позволяет задать тип данных и опцию NULL для новых колонок, а также правила ссылочной целостности, принимаемые по умолчанию. Тип данных можно выбрать в раскрывающемся списке Default Datatype, который автоматически заполняется типами данных, поддерживаемых выбранным сервером.

Группа кнопок Default Non-Key Null Option позволяет разрешить или запретить значения NULL для неключевых колонок.

При смене СУБД ERwin предлагает автоматически преобразовать тип данных каждой колонки на доступный для новой СУБД. Правила соответствия типов могут быть заданы предварительно. Для автоматического преобразования следует в ответ на запрос нажать Yes.

Процесс генерации физической схемы базы данных из логической модели данных называется прямым проектированием (Forward Engineering). При генерации физической схемы ERwin включает триггеры ссылочной  целостности, хранимые процедуры, индексы, ограничения и другие возможности, доступные при определении таблиц в выбранной СУБД. Процесс генерации логической модели из физической базы данных называется обратным проектированием (Reverse Engineering). ERwin позволяет создать модель данных путем обратного проектирования. Кроме режима прямого и обратного проектирования ERwin поддерживает синхронизацию между логической моделью и системным каталогом СУБД на протяжении всего жизненного цикла создания информационной системы.

Для того, чтобы получить физическую модель базы данных в MS Access 2000 из полученной в ERwin логической модели можно пойти одним из двух путей:

1. Сгенерировать физическую модель используя встроенные процедуры ERwin.
2. Перенести модель «вручную», создавая каждую таблицу и связь самостоятельно.

 

Мне кажется, что для  такой базы данных как эта, целесообразным является настраивать свойства и  параметры полей в режиме конструктора при создании таблицы. Создание связей тоже не будет сложным в этом случае, так как структура базы логически не очень сложна и в принципе понятна, к тому же  MS Access 2000 обладает всеми необходимыми средствами для качественной реализации схемы базы данных. Эта схема находится в Приложении 1.

Разделение модели данных на логические и физические позволяет  решить следующие задачи:

1)        Документирование модели.

Многие СУБД имеют  ограничение на именование объектов (например, ограничение на длину  имени таблицы или запрет использования  специальных символов – пробела  и т. п.). Зачастую разработчики ИС имеют  дело с нелокализованными версиями СУБД. Это означает, что объекты БД могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу предложением - только одним словом). Кроме того, проектировщики БД нередко злоупотребляют "техническими" наименованиями, полученную в результате структуру могут понять только специалисты. Разделение модели на логическую и физическую позволяет решить эту проблему. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы - имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов.