Модели данных.
Схема БД создается с помощью языка определения данных некоторой целевой СУБД. Этот язык относительно низкого уровня с его помощью трудно описать требования к данным в масштабе всей организации так, чтобы созданная схема была доступна пониманию пользователей различных категорий, следовательно, необходимо описание схемы на некотором, более высоком уровне, которое будем называть моделью данных.
Модель данных – интегрированный набор понятий для описания данных, связей между ними и ограничений, накладываемых на данные в некоторой организации.
Модель является представлением «реального мира» объектов и событий, а также связей между ними. Это некоторая абстракция, в которой акцент делается на самых важных и неотъемлемых аспектах деятельности организации, а все второстепенные свойства игнорируются. Таким образом, модель данных представляет саму организацию. Она должна отражать основные концепции, представленные, представленные в таком виде, который позволит проектировщикам и пользователям БД обмениваться мнениями об их понимании роли тех или иных данных в этой организации.
Модель данных можно рассматривать как сочетание трех указанных компонентов:
· Структурная часть, т.е. набор правил, по которым была построена БД;
· Управляющая часть, определяющая типы допустимых операций с данными (обновление и извлечение, изменение структуры БД);
· Набор ограничений поддержки целостности данных, гарантирующий корректность используемых данных (необязательно).
Цель построения модели данных в представлении данных в понятном виде. Трехуровневую архитектуру отображают три связанные модели данных:
Внешняя модель – отображает представление каждого типа пользователей. Внешняя модель – это информационное содержание БД в том виде, в каком его представляет конкретный пользователь. Внешняя модель состоит из различных экземпляров различных типов внешних записей. Например, пользователь из отдела кадров может рассматривать БД как совокупность записей об отделах и совокупность записей о служащих и ничего не знать о существовании записей о поставщиках и деталях. Каждая внешняя модель определяется посредством внешней схемы, которая состоит из описания всех типов внешних записей.
Концептуальная модель – отображает логическое или обобщенное представление о данных, не зависимое от выбранной СУБД. Концептуальная модель есть представление полного информационного содержания БД в несколько абстрактной форме по сравнению со способом физического хранения. Концептуальная модель состоит из множества экземпляров концептуальных записей (например совокупностей записей об отделах, об сотрудниках, о поставщиках, о деталях…). Концептуальная запись не обязана быть такой же как внешняя или как хранимая запись. Концептуальная модель определяется посредством концептуальной схемы, которая включает определение каждого типа концептуальных записей. Таким образом, концептуальная модель есть представление общего содержания БД, а концептуальная схема - определение этого представления.
Внутренняя модель – отображает КС определенным образом, понятным выбранной СУБД. Внутренняя модель состоит из различных экземпляров типов внутренних записей (хранимых записей). Внутренняя модель обеспечивается посредством внутренней схемы, которая не только определяет различные типы хранимых записей, но и то как представлены хранимые поля, какова физическая последовательность хранимых записей…
Классификация моделей данных.
1. Объектные:
· Модель типа «сущность связь» (основной метод концептуального проектирования);
· Семантическая модель;
· Функциональная модель;
· Объектно-ориентированная модель;
2. Модели на основе записей – база данных состоит из нескольких записей, фиксированного формата, которые могут иметь разные типы;
· Реляционная;
· Сетевая;
· Иерархическая;
3. Физические модели – описывают то, как данные хранятся в компьютере, представляя информацию о структуре записей, их упорядоченности и существующих путях доступа:
· Обобщающая модель;
· Модель памяти кадров (frame memory).
Модели на основе записей.
Иерархическая модель.
Иерархическая модель исторически появилась первой. Ее появление связано с тем, что в реальном мире очень многие связи соответствуют иерархии, когда один объект выступает как родительский, а с ним может быть связано множество подчиненных объектов. Иерархия проста и естественна в отображении взаимосвязи между классами объектов.
Основными информационными единицами в иерархической модели являются: БД, сегмент, поле.
Поле – минимальная, неделимая единица данных, доступная пользователю с помощью СУБД.
Например, если нам нужно в БД хранить адрес клиента, но нам не нужно проводить анализ этого адреса (анализ городов, из которых поступил заказ…), то адрес может быть записан как элемент данных и пользователь может получить его единой неделимой строкой. Иначе (если нас интересуют города, из которых поступили заказы) необходимо выделить более мелкие элементы данных (город, улица, дом…).
Сегмент синоним записи. При этом различают два понятия: тип сегмента (тип записи) – это поименованная совокупность типов элементов данных, в него входящих.
Экземпляр сегмента (записи) образуется из конкретных значений полей или элементов данных в него входящих.
(аналогично есть тип переменной и есть ее значение)
Например. Тип сегмента Группа(номер, староста) и значения сегментов этого типа (4305, Петров Ф.И.); (383, Кустова Т.С.)
В ИМ сегменты объединяются в древовидный граф. При этом направленные ребра графа отражают иерархические связи между сегментами: каждому экземпляру сегмента, стоящему выше по иерархии (сегменты-предки) соответствует множество экземпляров подчиненного типа сегмента (сегменты-потомки).
Таким образом БД представляет собой совокупность отдельных деревьев. При этом действуют следующие ограничения:
· В каждом дереве есть один корневой сегмент, т.е. сегмент у которого нет логически исходного.
· Каждый исходный сегмент может иметь произвольное число подчиненных сегментов.
· Подчиненный сегмент может иметь только одного родителя.
Иерархическая СУБД – IMS корпорации IBM.
Сетевая модель.
Стандарт сетевой модели впервые был определен в 1975 году организацией CODASYL, которая определила базовые модели и формы языка описания.
Сетевая модель данных – модель, состоящая из записей данных и связей типа «один-ко-многим», установленным между записями.
Сетевую модель можно представить как граф с записями в виде узлов и связями в виде ребер.
В сетевой модели данные представлены в виде коллекции записей, а связи – в виде наборов.
Набор – двухуровневый граф, связывающий отношением один-ко-многим два типа записи. Набор фактически отражает иерархическую связь между двумя типами записей. Родительский тип записи в данном наборе называется владельцем набора, а дочерний – членом того же набора.
Для любых двух типов записей может быть задано любое количество наборов, которые их связивают. Фактически наличие подобных возможностей позволяет промоделировать отношение «многие-ко-многим» между двумя объектами реального мира, что выгодно отличает сетевую модель от иерархической.
Самой популярной сетевой СУБД является IDMS/R фирмы Computer Associates.
При использовании сетевых и иерархических моделей от пользователя требуется знание физической организации БД, к которой он должен осуществлять доступ.
Реляционная модель (РМ).
Основана на понятии математических отношений. Данные и связи представлены в виде таблиц, каждая из которых имеет несколько столбцов с уникальными именами.
Таким образом реляционная БД представляет собой совокупность логически связанных таблиц.
Пример.
Отделы.
| Номер Отдела | улица | Город | Индекс | телефон | Факс |
| В5 | … | Лондон | … | ||
| В7 | … | Глазго | … | ||
| В3 | … | Лондон | … | ||
| В4 | … | … | … | ||
| В2 | … | … | … |
Сотрудники.
| Номер сотр. | Фам. | имя | Адрес | тел | должность | Дата рожд. | Доход | Номер отдела |
| СЛ-21 | Иванов | Н. | В5 | |||||
| СГ-37 | Петров | И. | В3 | |||||
| СГ-14 | … | … | В3 | |||||
| СА-9 | … | … | В7 | |||||
| СГ-5 | … | … | В3 | |||||
| СЛ-41 | … | … | В5 |
Между таблицами «Отделы» и «Сотрудники» существует связь: сотрудник работает в отделении компании. Но существование этой связи можно заметить только зная, что атрибут «номер отдела» в таблице Сотрудники эквивалентен атрибуту «Номер отдела» в таблице «Отделы».
Этот же пример в сетевой модели.
 |
Иерархическая модель.
Реляционная модель.
РМ основана на математическом понятии отношения, физическим представлением которого является таблица. Основные понятия:
Отношение – плоская таблица, состоящая из столбцов и строк.
В реляционной СУБД предполагается, что пользователь воспринимает БД как набор таблиц (но это относится только к внешнему и концептуальному уровню, но не физическому).
Атрибут – поименованный столбец отношения.
Отношения (таблицы) используются для хранения информации об объектах БД. Строки таблицы соответствуют отдельным записям, а столбцы – атрибутам. (Перестановка атрибутов между собой не изменяет отношения).
Домен – набор допустимых значений для одного или нескольких атрибутов.
Домены представляют собой мощный компонент РМ. Каждый атрибут РБД определяется на некотором домене. Домены могут отличаться для каждого из атрибутов, но несколько атрибутов могут определяться на одном домене.
Пример. Домены некоторых атрибутов отношений Отделы и Сотрудники.
| Атрибут | Имя домена | содержимое | Определение |
| Номер отдела | Branch_num | Мн-во допустимых номеров отделов комп. | Символьный: размер 3 |
| Улица | Street | Мн-во всех названий улиц Вел-нии | Симв: размер 25 |
| Город | City | Мн-во всех названий городов Вел-нии | Симв: разм. 13 |
| Индекс | Pcode | Мн-во всех почтовых индексов Вел-ии | Симв: разм 8 |
| Телефон | TelFax | Мн-во всех номеров телефонов и факсов | Симв: разм 13 |
| Факс | TelFax | Мн-во всех номеров телефонов и факсов | Симв: разм 13 |
| Дата рожд. | DoB | Все возможные даты рождения сотрудника | Дата от 1.01.20 формат дд-мм-гг |
| Доход | Salary | Все возможные зн-я годового дохода | Ден.: 5 цифр 6.000-40.000 |
Понятие домена имеет большое значение, т.к. благодаря ему пользователь может централизованно определять смысл и источник значений, которые могут получать атрибуты. Это позволяет избежать семантически некорректных операций (например сравнения города и телефона, хотя оба символьные).
Замечание. В большинстве СУБД понятие домена реализовано в очень узком смысле. Имеется в виду то, что СУБД поддерживает встроенные типы данных (целые, текстовые, логические…). Но если говорить о поддержке доменов в контексте реляционной теории, то тогда система должна обеспечивать возможность пользователю создавать свои типы данных: например определить тип «цвет» или «мужские имена» и предоставлять инструменты для работы с ними.
Кортеж – это строка отношения.
Элементами отношения являются кортежи, или строки, таблицы. В отношении «Отделы» каждая строка содержит 7 значений, по одному для каждого атрибута. Кортежи могут располагаться в любом порядке.
Описание структуры отношения вместе со спецификацией доменов и любыми другими ограничениями возможных значений атрибутов иногда называют заголовком. Кортежи называют расширением, состоянием или телом отношения.
Степень отношения определяется количеством атрибутов, которое оно содержит.
Кардинальность – количество кортежей в отношении (меняется при каждом добавлении или удалении).
Альтернативная терминология.
| Официальный термин | Вариант 1. | Вариант 2. |
| Отношение | Таблица | Файл |
| Кортеж | Строка | Запись |
| Атрибут | столбец | Поле |