24 Концептуальное проектирование базы данных.

Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных.

Чаще всего концептуальная модель базы данных включает в себя:

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

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

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

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

25 Нормальные формы: первая нормальная форма, вторая нормальная форма, третья нормальная форма

ПЕРВАЯ НОРМАЛЬНАЯ ФОРМА. Отношение приведено к первой нормальной форме, если все его атрибуты атомарны. Другими словами, ни один из элементов отношения сам не должен быть отношением. Например, если в процессе описания отношения ПОСТАВКА один из его атрибутов ПОСТАВЩИК является в свою очередь отношением, включающим атрибуты ФИО, ТЕЛЕФОН, то такое отношение не приведено к первой нормальной форме. Для приведения отношения к первой нормальной форме нужно избавиться от сложного атрибута ПОСТАВЩИК и заменить этот атрибут на два простых ФИО ПОСТАВЩИКА и ТЕЛЕФОН ПОСТАВЩИКА.

ВТОРАЯ НОРМАЛЬНАЯ ФОРМА. Отношение приведено ко второй нормальной форме, если каждый неключевой атрибут функционально полно зависит от ключевого атрибута. Под функциональной зависимостью понимают ситуацию, когда значение атрибута в кортеже однозначно определяет значение другого атрибута в кортеже. Например, отношение ВЕДОМОСТЬ=(СТУДЕНТ, ДИСЦИПЛИНА, ПРЕПОДАВАТЕЛЬ, ОЦЕНКА) не находится во второй нормальной форме, т.к. атрибут ПРЕПОДАВАТЕЛЬ не находится в функционально полной зависимости от составного ключа СТУДЕНТ+ ДИСЦИПЛИНА. Атрибут ПРЕПОДАВАТЕЛЬ зависит только от атрибута ДИСЦИПЛИНА и не находится в функционально полной зависимости от составного ключа. Для приведения отношения ВЕДОМОСТЬ ко второй нормальной форме его надо разбить на два отношения УСПЕВАЕМОСТЬ и ПРЕПОДАВАТЕЛЬ.

ТРЕТЬЯ НОРМАЛЬНАЯ ФОРМА. Отношение приведено к третьей нормальной форме, если устранены транзитивные зависимости между атрибутами отношения. Транзитивная зависимость имеет место в том случае, если один неключевой атрибут зависит от другого неключевого атрибута. Например, отношение СПИСОК СОТРУДНИКОВ=(СРТРУДНИК, ДОЛЖНОСТЬ, ПОДРАЗДЕЛЕНИЕ, ТЕЛЕФОН) не приведено к третьей нормальной форме, т.к. атрибут ТЕЛЕФОН зависит от неключевого атрибута ПОДРАЗДЕЛЕНИЕ. Для приведения отношения к третьей нормальной форме отношение СПИСОК СОТРУДНИКОВ нужно разбить на два отношения СОТРУДНИКИ и ПОДРАЗДЕЛЕНИЯ.

26 Отношение; мощность отношения; отношения «один-к-одному», «один-ко- многим», «многие-ко-многим».

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

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

Отношение "один–ко–многим"

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

Отношение "один–к–одному"

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

Отношение "многие–ко–многим"

Отношение "многие–ко–многим" применяется в следующих случаях:

одной записи в родительской таблице соответствует более одной записи в дочерней;

одной записи в дочерней таблице соответствует более одной записи в родительской.

Всякую связь "многие–ко–многим" в реляционной базе данных необходимо заменить на связь "один–ко–многим" (одну или более) с помощью введения дополнительных таблиц.