Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
семантич_моделирование.doc
Скачиваний:
4
Добавлен:
20.09.2019
Размер:
352.77 Кб
Скачать

Правила нормализации логической модели

Для построения оптимальной (нормализованной) модели:

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

  2. Необходимо исключить из таблицы избыточные данные - если атрибут зависит только от части составного ключа, то его следует переместить в отдельную таблицу и присвоить ей уникальный ключ.

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

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

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

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

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

  3. Естественный атрибут может изменяться во времени. Использование в этом случае неизменного кода позволит избежать сложностей при эксплуатации системы.

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

Основы проектирования бд

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

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

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

  • Отношение находится в первой нормальной форме, если его атрибуты являются простыми.

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

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