Модели данных логического уровня

В СУБД необходимо строить такую модель данных, которая подчиняется правилам структурирования данных в БД, допускает выполнения необходимых операций над данными и предусматривает ограничения для обеспечения их целостности.

Как правило, СУБД поддерживает три уровня организации данных в БД: внешний, концептуальный и физический. Внешний уровень определяет визуальное представление данных, с которым работает конечный пользователь. Концептуальный (логический) уровень – это уровень математической модели, условное представление данных как системы объектов и связей между ними.

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

Проектирование базы данных заключается в реализации определенной цепочки моделей (рис. 1).

Предметная область

Инфологическая модель данных

Логическая модель данных

Физическая модель данных

Рис. 1. Проектирование БД

Инфологическая (семантическая) модель данных Инфологическая модель предшествует разработке внешней и концептуальной моделей. Она сохраняет семантику (смысловое содержание) объектов предметной области. Основным понятием на этом этапе является сущность – некоторый объект предметной области или связанные с ним событие или процесс. Сущность состоит из экземпляров и описывается своими атрибутами – именованными свойствами. Каждый экземпляр характеризуется уникальным набором конкретных значений всех атрибутов сущности. Между сущностями определяются связи, которые описывают их взаимодействие. Связи также могут иметь атрибуты и характеризуются классом принадлежности и степенью связи. Класс принадлежности связи показывает, обязан ли каждый экземпляр участвовать в связи (обязан – 1, не обязан – 0), а степень связи определяет максимальное количество экземпляров одной сущности, связанных с одним экземпляром другой сущности (один – 1, много - *).

В качестве примера рассмотрим семантическую модель
ВУЗа. Она состоит из трех попарно связанных сущностей с обязательным классом принадлежности: Факультет—Студент—Предмет. Например, каждый экземпляр сущности Студент имеет конкретные значения атрибутов: № зач. кн. и ФИО. Связь между сущностями Факультет®Студент характеризуется степенью один-ко-многим (1:*). Это означает, что каждый студент обязан учиться только на одном факультете (1), а на факультете должен обучаться по крайней мере один студент (*). Сущности Студент«Предмет связаны со степенью многие-ко-многим (*:*), что означает: каждый студент должен изучать не менее одного предмета, а каждый предмет должен изучаться по крайней мере одним студентом. Кроме того, для этих сущностей определены атрибуты связи – Семестр и Вид контроля, которые характеризуют не студента или предмет, а их взаимодействие.

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

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

Иерархические модели имеют древовидную структуру данных. Вершинами этой структуры являются записи, состоящие из элементов данных различных типов. При этом родительской записи (предку) соответствует произвольное число подчиненных записей (потомков). Экземпляр записи идентифицируется уникальным ключом, то есть полем, однозначно определяющим этот экземпляр. Иерархическая БД – это совокупность деревьев. Например: дерево 1 - Факультет®Студент®Предмет, дерево 2 – Предмет®Студент.

В сетевой модели поддеревья могут иметь любое число предков. Фактически сетевые БД состоят из набора записей и множества связей между ними, например:
Факультет®Студент«Предмет. Доступ к данным в сетевой модели не имеет ограничений и возможен к любой записи независимо от уровня.

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

Существует постреляционные (многомерные) модели данных (ММД), представляющие собой расширенную РМД, в которой отменено требование атомарности атрибутов, то есть ММД использует трехмерные структуры, позволяя хранить в таблицах другие таблицы.

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

Реляционная модель данных. Рассмотрим основные понятия РМД. К ним относятся: тип данных, домен, атрибут, кортеж, первичный ключ, и отношение.

Атрибут (поле) – это какое-либо свойство объекта предметной области. В РМД атрибут характеризуется именем и значением, которое должно принадлежать некоторому домену. Например, объект Книга одним из своих атрибутов (свойств) имеет атрибут с именем Годы издания книг, а конкретным значением домена этого атрибута может быть число 1564 (год издания первой печатной книги Московской Руси «Апостол»).

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

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

Кортеж для соответствующей схемы отношения – это множество пар {имя атрибута, значение}. Каждому кортежу соответствует одна запись (строка) таблицы. В результате отношение (таблица) – это множество кортежей.

Отметим некоторые важные свойства отношений.

– Отсутствие кортежей-дубликатов. Это означает, что никакие две строки таблицы не могут совпадать. В любой таблице должен быть первичный ключ (ПК) – минимальный набор атрибутов, однозначно определяющий одну строку.

– Отношение не предполагает сортировку по строкам или столбцам, что дает большую гибкость при хранении данных.

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

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

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

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

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

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

Вначале вспомним некоторые понятия:

Простой атрибут — это атрибут, значения которого неделимы. Иными словами, в таблице нет полей типа ФИО или Адрес — они разложены на поля Фамилия, Имя, Отчество в первом случае и на поля Индекс, Город и т. д. во втором.

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

Определение функциональной зависимости: Пусть Xи Y атрибуты некоторого отношения. Если в любой момент времени произвольному значению X соответствует единственное значение Y, то Y функционально зависит от X (X→Y)

Если ключ является составным, то любой атрибут должен зависеть от ключа в целом, но не может находиться в функциональной зависимости от какой-либо части составного ключа, т.е. функциональная зависимость имеет вид (X₁, X₂, ..., X)→Y.

Функциональная зависимость может быть полной или неполной.

Неполной зависимостью называется зависимость неключевого атрибута от части составного ключа.\

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

Определение транзитивной функциональной зависимости: Пусть X, Y, Z— три атрибута некоторого отношения. При эtom X→Y и Y→Z, но обратное соответствие отсутствует, то есть Y не зависит от Z, а Х не зависит от Y. Тогда говорят, что Z транзитивно зависит от Х.

Определение многозначной зависимости: Пусть Х и Y атрибуты некоторого отношения. Атрибут Y многозначно зависит от атрибута X, если. каждому значению X соответствует множество значений Y, не связанных с другими атрибутами из отношения. Многозначные зависимости могут носить характер «один ко многим» (1:М), «многие к одному» (М:1) или «многие ко многим» (М:М), обозначаемые соответственно: X=>Y, Y<=X и X<=>Y. Например, преподаватель ведет несколько предметов, а каждый предмет может вестись несколькими преподавателями, тогда имеет место зависимость ФИО <=> Предмет.

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

ФИО - фамилия и инициалы преподавателя (совпадения фамилий и инициалов исключаются).

Должность - должность, занимаемая преподавателем.

Оклад- оклад преподавателя.

Стаж - преподавательский стаж. Д_Стаж - надбавка за стаж.

Кафедра - номер кафедры, на которой числится преподаватель.

Предмет - название предмета (дисциплины), читаемого преподавателем.

Группа - номер группы, в которой преподаватель проводит занятия.

Вид занятия - вид занятий, проводимых преподавателем в учебной группе.

Исходное отношение ПРЕПОДАВАТЕЛЬ

ФИО	Должность	Оклад	Стаж	Д_Стаж	Кафедра	Предмет	Группа	Вид занятия
Иванов И. М.	Преподаватель					БД	АС-21	Практика
Иванов И. М.	Преподаватель					ОС	АС-22	Практика
Петров М. И.	Ст. преподаватель					БД	АС-21	Лекция
Петров М. И.	Ст. преподаватель					Архитектура	АС-21	Практика
Сидоров Н. Г.	Преподаватель					ОС	АС-22	Лекция
Сидоров Н. Г.	Преподаватель					Архитектура	АС-21	Лекция
Егоров В. В.	Преподаватель					Философия	ПС-22	Лекция

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

Функциональные зависимости: ФИО→Кафедра, ФИО→Должность, Должность→ Оклад, ФИО→Предмет.

Также в нашем отношении ключ является составным и состоит из атрибутов (ФИО, Предмет, Группа).

Неполная функциональная зависимость: (ФИО, Предмет, Группа)→Должность, т.к. атрибут Должность находится в функциональной зависимости от атрибута ФИО, являющегося частью ключа.

Полная функциональная зависимость: (ФИО, Предмет, Группа)→Вид занятия.

Транзитивная зависимость: ФИО→Должность→Оклад, ФИО→Стаж→Д_Стаж.

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

ФИО →Должность ФИО →Оклад ФИО →Стаж ФИО →Д_Стаж ФИО →Кафедра

Стаж →ДСтаж Оклад →Должность Должность →Оклад (ФИО, Предмет, Группа) →Вид занятий

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

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

Каждый преподаватель имеет определенную добавку за стаж, т. е. имеет место функциональная зависимость ФИО→Д_Стаж, но обратная функциональная зависимость отсутствует, так как одну и ту же надбавку могут иметь несколько преподавателей.

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

Каждый преподаватель является сотрудником одной и только одной кафедры. Поэтому имеет место функциональная зависимость ФИО→Кафедра. С другой стороны, на каждой кафедре много преподавателей, поэтому обратной функциональной зависимости нет.

Каждому преподавателю соответствует конкретный оклад, который одинаков для всех педагогов с одинаковыми должностями, что учитывается зависимостями ФИО→Оклад и Должность→Оклад. Нет одинаковых окладов для разных должностей, поэтому имеет место функциональная зависимость Оклад→Должность.

Один и тот же преподаватель в одной группе по разным предметам может проводить разные виды занятий. Определение вида занятий, которые проводит преподаватель, невозможно без указания предмета и группы, поэтому имеет место функциональная зависимость (ФИО, Предмет, Группа) →Вид Занятия.

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

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

Каждая следующая нормальная форма ограничивает определенный тип функциональных зависимостей, устраняет соответствующие аномалии при выполнении операций над отношениями БД и сохраняет свойства предшествующих нормальных форм. Выделяют следующую последовательность нормальных форм: первая нормальная форма (1НФ); вторая нормальная форма (2НФ); третья нормальная форма (ЗНФ).