Модели данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.3. ПОНЯТИЕ БАЗЫ ДАННЫХ.
ОБЪЕКТЫ БД

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

2. СОЗДАНИЕ МНОГОТАБЛИЧНОЙ
БАЗЫ ДАННЫХ

2.1. ОРГАНИЗАЦИЯ СВЯЗИ МЕЖДУ
ТАБЛИЦАМИ БАЗЫ ДАННЫХ

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

К связываемым таблицам в базе данных предъявляются следующие требования.

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

· Связываемые таблицы должны быть нормализованными.

· Для связанных таблиц должна обеспечиваться целостность данных.