Целью разработки любой базы данных является хранение и использование информации о какой-либо предметной области. Для реализации этой цели имеются следующие инструменты:
1. Реляционная модель данных - удобный способ представления данных предметной области.
2. Язык SQL - универсальный способ манипулирования такими данными.
Можно спроектировать несколько отношений с большим количеством атрибутов, или наоборот, разнести все атрибуты по большому числу мелких отношений. Как определить, по каким признакам нужно помещать атрибуты в те или иные отношения?
Логическая модель данных
Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий - "сотрудник", "отдел", "проект", "зарплата". Примеры взаимосвязей между понятиями - "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений - "возраст сотрудника не менее 16 и не более 60 лет".
Логическая модель данных является начальным прототипом будущей базы данных. Она строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь).
Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных. Однако, т.к. мы рассматриваем именно реляционные СУБД, то можно считать, что логическая модель данных для нас формулируется в терминах реляционной модели данных.
Физическая модель данных
На еще более низком уровне находится физическая модель данных. Физическая модель данных описывает данные средствами конкретной СУБД. Мы будем считать, что физическая модель данных реализована средствами именно реляционной СУБД, хотя, как уже сказано выше, это необязательно. Отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД.
Элементы модели "сущность-связь"
В реальном проектировании структуры базы данных применяются другой метод - так называемое, семантическое моделирование. Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).
Основные понятия ER-диаграмм
Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели.
Каждая сущность должна иметь наименование, выраженное существительным в единственном числе.
Примерами сущностей могут быть такие классы объектов как "Поставщик", "Сотрудник", "Накладная".
Каждая сущность в модели изображается в виде прямоугольника с наименованием:
Атрибут сущности – это именованная характеристика, являющаяся некоторым свойством сущности.
Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными).
Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п.
Атрибуты изображаются в пределах прямоугольника, определяющего сущность:
Ключ сущности – это неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Неизбыточность заключается в том, что удаление любого атрибута из ключа нарушает его уникальность.
Сущность может иметь несколько различных ключей.
Ключевые атрибуты изображаются на диаграмме подчеркиванием:
Связь – это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью (или сама с собою).
Связи позволяют по одной сущности находить другие сущности, связанные с нею. Например, связи между сущностями могут выражаться следующими фразами – "СОТРУДНИК может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ".
Графически связь изображается линией, соединяющей две сущности:
Каждая связь имеет два конца и одно или два наименования. Наименование обычно выражается в неопределенной глагольной форме: "иметь", "принадлежать" и т.п. Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности.
Каждая связь может иметь один из следующих типов связи:
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней.
Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.
ER-диаграммы является примером концептуальной диаграммы. Это означает, что диаграмма не учитывает особенности конкретной СУБД. По данной концептуальной диаграмме можно построить физическую диаграмму, которая уже будут учитываться такие особенности СУБД, как допустимые типы и наименования полей и таблиц, ограничения целостности и т.п.
Создание инфологической и логической моделей базы данных
Разработка информационно-логической модели реляционной БД начинается с рассмотрения необходимых для её создания информационных объектов.
Если, например, представить связь между объектами "Студенты" и "Дисциплины", то вполне очевидно, что студент изучает несколько дисциплин (связь «один» обозначается одинарной стрелкой, а многозначная связь отражается двойной стрелкой). Каждая дисциплина изучается множеством студентов – это тоже многозначная связь. Следовательно, связь между объектами "Студенты" и "Дисциплины" является отношением «Многие-ко-многим» (М : М или M:N).
Множественные связи усложняют управление базой данных, поэтому их нежелательно использовать.
В Access с этой целью создают вспомогательный объект связи, состоящий из ключевых реквизитов связываемых объектов, который может быть дополнен описательными реквизитами. В данном случае таким новым объектом для связи может быть объект «Оценки».
Его реквизиты: код студента, код дисциплины и собственно оценки. Каждый студент имеет оценки по нескольким дисциплинам. При этом связь между объектами «Студенты» и «Оценки» будет «Один-ко-многим» (1 : М). Каждую дисциплину сдаёт множество студентов, поэтому связь между объектами «Дисциплины» и «Оценки» тоже «Один-ко-многим» (1 : М). В результате получается следующая информационно-логическая модель базы данных.
После определения структуры системы (БД): объектов (таблиц), состава их полей (структуры таблиц) и связей между таблицами приступают к непосредственному формированию структуры таблиц и определяют ключевые поля в них.
Ключевое поле – это одно или несколько полей, комбинация значений которых однозначно определяет каждую запись в таблице; это уникальный идентификатор записей, используемый для поиска записей и объединения таблиц.
При ссылке на ключевое поле из другой таблицы оно называется полем внешнего ключа.
В качестве примера приведём характеристики полей таблиц «Студенты» и «Преподаватели».
Выбор типа данных, содержащихся в полях БД Access, осуществляют с помощью следующей таблицы.
Практически любая реляционная БД (в том числе и в Access) создаётся из нескольких таблиц, на основе которых формируются формы и запросы.
Таблицы между собой связываются посредством общих полей, т.е. полей, одинаковых по форматам и, как правило, по названию, имеющихся в обеих таблицах. Такая организация данных позволяет уменьшить избыточность хранимых данных, упрощает их ввод и организацию запросов и отчётов. Каждая таблица включает в свой состав поле кода, используемого обычно как счётчик (идентификатор) главного её параметра и, как правило, являющегося ключевым полем.
Записи таблицы всегда располагаются в файле БД в том порядке, в котором они были включены в таблицу. Для удобства просмотра записей их можно сортировать в таблице в определённой последовательности, например, в порядке убывания или возрастания какого-либо характеризующего поле (столбец) параметра. Сортировку можно произвести по нескольким полям одновременно. Функция сортировки относится к процессу фильтрации данных.