3. Нормализация реляционных отношений. Вторая нормальная форма (2нф)

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

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

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

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

Любая реляционная таблица находится в первой нормальной форме (1НФ)

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

В таблице «Булочная» составным ключом является совокупность полей – хлебозавод+продукт. Если при этом цена на одинаковые продукты разных хлебозаводов назначена одной и той же то поле цена будет зависеть только от части ключа – поля продукт.

Для устранения неполной функциональной зависимости необходимо разделить исходную таблицу на две. В первой будут поля Хлебозавод, Продукт (ключ Хлебозавод+Продукт) и Количество, а во второй Продукт (ключ) и Цена.

4. Индексные файлы, двоичный поиск данных

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

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

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

Если в таблице Nзаписей , то при самом неблагоприятном варианте – искомое значение ключа будет в последней записи , придется проделатьNшагов. Для рассмотренного простейшего алгоритма максимальное число шагов при поиске –log2N

5. Логическая модель данных idef1x. Сущности и атрибуты.

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

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

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

Атрибут – определенное свойство объекта. Имя атрибута – существительное в единственном числе , уникальное рамках модели (а не только сущности), например – КодЗаказ, НаименПрод

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

StringNumberDateTimeBlob

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

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

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

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

Модель IDEF1xпредполагает также текстовое описание сущности.

Оно содержит:

• Определение сущности

• Дополнительные замечания, не отраженные в определении

• Примеры запросов, которые могут быть использованы по отношению к сущности

• Примеры данных для этой сущности

• Свойства , определяемые пользователем

Каждая сущность на логическом уровне должна быть нормализована , т.е. находится в 3НФ.