Выше уже упоминалось, что схема создается с помощью некоторого языка определения данных. В действительности она создается на основе языка определения данных конкретной целевой СУБД. К сожалению, это язык относительно низкого уровня; с его помощью трудно описать требования к данным в масштабе всей организации так, чтобы созданная схема была доступна пониманию пользователей самых разных категорий. В чем мы действительно нуждаемся, так это в описании схемы на некотором, более высоком уровне. Это описание будем называть моделью Данных.
Модель данных. Интегрированный набор понятий для описания и обработки данных, связей между ними и ограничений, накладываемых на данные в некоторой организации,
Модель является представлением "реального мира" объектов и событий, а также существующих между ними связей. Это некоторая абстракция, в которой акцент делается на самых важных и неотъемлемых аспектах деятельности организации, а все второстепенные свойства игнорируются. Таким образом, можно сказать, что модель данных представляет саму организацию. Модель должна отражать основные концепции, представленные в таком виде, который позволит проектировщикам и пользователям базы данных обмениваться конкретными и недвусмысленными мнениями о роли тех или иных данных в организации. Модель данных можно рассматривать как сочетание трех указанных ниже компонентов.
- Структурная часть, т.е. набор правил, по которым может быть построена база данных.
- Управляющая часть, определяющая типы допустимых операций с данными (сюда относятся операции обновления и извлечения данных, а также операции изменения структуры базы данных).
- Набор (необязательный) ограничений поддержки целостности данных, гарантирующих корректность используемых данных.
Цель построения модели данных заключается в представлении данных в понятном виде. Если такое представление возможно, то модель данных можно легко применить при проектировании базы данных. Для отображения обсуждавшейся в разделе 2.1 архитектуры ANSI
-SPARC
можно определить следующие три связанные модели данных:
- внешняя модель данных, отображающая представления каждого существующего в организации типа пользователей, которую иногда называют предметной областью (Universe of Discourse —
UoD
); - концептуальная модель данных, отображающая логическое (или обобщенное) представление о данных, независимое от типа выбранной СУБД;
- внутренняя модель данных, отображающая концептуальную схему определенным образом, подходящим для выбранной целевой СУБД.
В литературе предложено и опубликовано достаточно много моделей данных. Они подразделяются на три категории: объектные (object
-based
) модели данных, модели данных на основе записей (record
-based
) и физические модели данных. Первые две используются для описания данных на концептуальном и внешнем уровнях, а последняя — на внутреннем уровне.
Объектные модели данных
При создании объектных моделей данных используются такие понятия, как сущности, атрибуты и связи. Сущность — это отдельный элемент деятельности организации (сотрудник или клиент, место или вещь, понятие или событие), который должен быть представлен в базе данных. Атрибут — это свойство, которое описывает некоторый аспект объекта и значение которого следует зафиксировать, а связь является ассоциативным отношением между сущностями. Ниже перечислены некоторые наиболее общие типы объектных моделей данных.
- Модель типа "сущность-связь”, или
ER
-модель (Entity-Relationship model). - Семантическая модель.
- Функциональная модель.
- Объектно-ориентированная модель.
В настоящее время ER
-модель стала одним из основных методов концептуального проектирования баз данных, и именно она лежит в основе предлагаемой в этой книге методологии проектирования баз данных. Объектно-ориентированная модель расширяет определение сущности с целью включения в него не только атрибутов, которые описывают состояние объекта, но и действий, которые с ним связаны, т.е. его поведение. В таком случае говорят, что объект инкапсулирует состояние и поведение.
Модели данных на основе записей
В модели на основе записей база данных состоит из нескольких записей фиксированного формата, которые могут иметь разные типы. Каждый тип записи определяет фиксированное количество полей, каждое из которых имеет фиксированную длину. Существуют три основных типа логических моделей данных на основе записей: реляционная модель данных (relational
data
model
), сетевая модель данных (network
data
model
) и иерархическая модель данных (hierarchical
data
model
). Иерархическая и сетевая модели данных были созданы почти на десять лет раньше реляционной модели данных, потому их связь с концепциями традиционной обработки файлов более очевидна.
Реляционная модель данных
Реляционная модель данных основана на понятии математических отношений. В реляционной модели данные и связи представлены в виде таблиц, каждая из которых имеет несколько столбцов с уникальными именами. В табл. 1 и 2 показан пример реляционной схемы некоторой части проекта DrеатНоте
, содержащей сведения об отделениях компании и персонале организации. Например, из табл. 2 видно, что сотрудник John Whi te работает менеджером с годовой зарплатой 30000 фунтов стерлингов в отделении компании с номером (branchNo
) ВО05, который, согласно данным из табл. 1, расположен по адресу 22 Deer Rd, London. Здесь важно отметить, что между отношениями Staff
и Branch
существует следующая связь: сотрудник работает в отделении компании. Однако между этими двумя отношениями нет явно заданной связи; ее существование можно заметить, только зная, что атрибут branchNo
в отношении Staff
эквивалентен атрибуту branchNo
в отношении Branch
.
Таблица 1. Пример описания сущности Branch
в реляционной схеме
branchNo | street | city | postcode |
8005 | 22 Deer Rd | London | SW14EH |
8007 | 16 Argyll St | Aberdeen | А82 3SU |
8003 | 163 Main St | Glasgow | G119QX |
8004 | 32 Manse Rd | 8ristol | 8S99 1NZ |
8002 | 56 Clover Dr | London | NW10 6EU |
Таблица 2. Пример описания сущности Staff
в реляционной схеме
staffNo | fName | IName | position | sex | DOB | salary | branchNo |
SL21 | John | White | Manager | м | 1-0ct-45 | 30000 | 8005 |
SG37 | Ann | 8eech | Assistant | F | 10-Nov-60 | 12000 | 8003 |
SG14 | David | Ford | Supervisor | м | 24-Mar-58 | 18000 | 8003 |
SA9 | Магу | Howe | Assistant | F | 19-Feb-70 | 9000 | 8007 |
SG5 | Susan | 8rand | Manager | F | 3-Jun-40 | 24000 | 8003 |
SL41 | Julie | Lee | Assistant | F | 13-Jun-65 | 9000 | 8005 |