Лекція

«Архітектура систем баз даних,

моделі даних»

1. Трирівнева архітектура ANSI/SPARC.

2. Моделі даних.

Кафедра безпеки інформаційних систем і технологій

 Трирівнева архітектура ANSI/SPARC
Система баз даних

Дані Апаратне Програмне Користувачі

(БД) забезпечення забезпечення
(в тому числі СУБД)

СУБД
База данных является общим ресурсом. Адміністратор
Каждому пользователю может потребоваться свое, бази даних
отличное от других представление о (АБД)
характеристиках информации, сохраняемой в БД.
С другой стороны, при формировании БД необходимо Прикладные
Прикладные
Прикладні
учесть информационные потребности всей программисты
программисты
програмісти
организации, поэтому описание данных должно быть
абстрактным и общим.
Как это совместить?
Эта задача может быть решена с помощью СУБД. Основная Конечные
Конечные
Конечные
Кінцеві
пользователи
цель СУБД заключается в том, чтобы предложить пользователи
пользователи
користувачі
пользователю абстрактное представление данных, скрыв
конкретные особенности хранения и управления ими.
Чтобы понять этот механизм обратимся к архитектуре модели ANSI/SPARC.
 Трехуровневая архитектура ANSI/SPARC
ANSI – American National Standard Institute – Национальный институт стандартизации США;
SPARC – Standards Planning and Requirements Committee – Комитет планирования стандартов
и норм.
 Трехуровневая архитектура ANSI/SPARC
Цель трехуровневой архитектуры – отделить пользовательское
представление базы данных от ее физического представления.
Причины, по которым желательно выполнить такое разделение:
 каждый пользователь должен иметь возможность обращаться к одним и
тем же данным, реализуя свое собственное представление о них, и если
пользователь изменил свое представление о данных, то это изменение не
должно оказывать влияния на других пользователей;
 пользователи не должны непосредственно иметь дело с подробностями
физического хранения данных в базе;
 администратор базы данных должен иметь возможность изменять
структуру хранения данных в базе, не оказывая влияния на
пользовательские представления;
 внутренняя структура базы данных не должна зависеть от таких
изменений физических аспектов хранения информации, как
переключение на новое устройство хранения;
 АБД должен иметь возможность изменять концептуальную структуру базы
данных без какого-либо влияния на всех пользователей.
 Трехуровневая архитектура ANSI/SPARC
Внешний (или пользовательский логический) уровень архитектуры – это
представление базы данных с точки зрения пользователей.
Этот уровень описывает ту часть базы данных, которая относится к каждому
пользователю.
Внешнее представление содержит только те сущности, атрибуты и связи "реального
мира", которые интересны пользователю. Другие сущности, атрибуты или связи,
которые ему неинтересны, также могут быть представлены в базе данных, но
пользователь может даже не подозревать об их существовании.

Сущность (entity) – это нечто существующее (в том числе реальный или

представляемый объект), информация о котором должна сохраняться и быть
доступной.
Атрибут (attribute) – это свойство (признак), которое описывает некоторый аспект
(характеристику) рассматриваемой сущности.
Связь (relationship) является ассоциативным отношением между сущностями. Это то,
что объединяет несколько сущностей.

Различные представления могут по-разному отображать одни и те же данные.

Например, один пользователь может просматривать даты в формате (день, месяц,
год), а другой – в формате (год, месяц, день).
Некоторые представления могут включать производные или вычисляемые данные,
которые не хранятся в базе данных, а создаются по мере надобности.
 Трехуровневая архитектура ANSI/SPARC
Концептуальный (общий логический или просто логический) уровень
архитектуры – это обобщающее представление базы данных.
Этот уровень описывает то, какие данные хранятся в базе данных, а также связи,
существующие между ними.
Этот уровень содержит логическую структуру всей базы данных (с точки зрения АБД).
Фактически это полное представление требований к данным со стороны организации,
которое не зависит от любых соображений относительно способа их хранения.
На концептуальном уровне представлены следующие компоненты:
 все сущности, их атрибуты и связи;
 информация о типах данных и их характеристиках;
 информация о мерах обеспечения безопасности и поддержки
целостности данных.

Концептуальный уровень поддерживает каждое внешнее представление, в том

смысле, что любые доступные пользователю данные должны содержаться (или могут
быть вычислены) на этом уровне.
Однако этот уровень не содержит никаких сведений о методах хранения данных.
Например, описание сущности должно содержать сведения о типах данных атрибутов
(целочисленный, действительный или символьный) и их длине (количестве значащих
цифр или максимальном количестве символов), но не должно включать сведений об
организации хранения данных, например об объеме занятого пространства в байтах.
 Трехуровневая архитектура ANSI/SPARC
Внутренний (или физический) уровень архитектуры – это
физическое представление базы данных в компьютере.
Этот уровень описывает, как информация хранится в базе данных (физическую
реализацию БД). Он предназначен для достижения оптимальной
производительности и обеспечения экономного использования дискового
пространства.

На внутреннем уровне хранится следующая информация:

 распределение дискового пространства для хранения данных и
индексов;
 описание подробностей сохранения записей (с указанием реальных
размеров сохраняемых элементов данных);
 сведения о размещении записей;
 сведения о сжатии данных и выбранных методах их шифрования.
 Трехуровневая архитектура ANSI/SPARC
Каждому уровнями абстракции трехуровневой архитектуры ANSI/SPARC
соответствует своя схема представления БД.
Общее описание базы данных называется схемой базы данных.
На самом высоком уровне имеется несколько внешних схем или подсхем,
которые соответствуют разным представлениям данных.
На концептуальном уровне описание базы данных называют
концептуальной схемой, а на самом низком уровне абстракции 
внутренней схемой.
Концептуальная схема описывает все сущности, атрибуты и связи между
ними, с указанием необходимых ограничений поддержки целостности
данных.
На нижнем уровне находится внутренняя схема, которая является полным
описанием внутренней модели данных. Она содержит определения
хранимых записей и методов представления, описания полей данных,
сведения об индексах и выбранных схемах хеширования.
Для каждой базы данных существует только одна концептуальная и одна
внутренняя схема.
СУБД отвечает за установление соответствия между тремя типами схем, а
также за проверку их непротиворечивости.
Трехуровневая архитектура ANSI/SPARC
Различия между тремя уровнями представления данных
Трехуровневая архитектура ANSI/SPARC
Различия между тремя уровнями представления данных
Схема архитектуры системы баз данных
 Трехуровневая архитектура ANSI/SPARC
Основным назначением трехуровневой архитектуры является обеспечение
независимости от данных, которая означает, что изменения на нижних уровнях не влияют
на верхние уровни. Различают два типа независимости от данных: логическую и
физическую.
Логическая независимость от данных означает полную защищенность внешних схем
от изменений, вносимых в концептуальную схему.
Физическая независимость от данных означает защищенность концептуальной
схемы от изменений, вносимых во внутреннюю схему.
Реализация независимости от данных в трехуровневой архитектуре
ANSI/SPARC
 Взаимодействие пользователя, СУБД и операционной системы при
обработке запроса на получение данных
Последовательность взаимодействий:
1. Пользователь посылает СУБД запрос на
получение данных из БД (стрелка 1).
2. Анализ прав пользователя и внешней
схемы данных, соответствующей данному
пользователю (стрелка 2), подтверждает
или запрещает доступ данного
пользователя к запрошенным данным
(стрелка 3).
3. В случае запрета на доступ к данным
СУБД сообщает пользователю об этом
(стрелка 12) и прекращает дальнейший
процесс обработки данных, в противном
случае СУБД определяет часть
концептуальной схемы, которая
затрагивается запросом пользователя
(стрелка 4).
4. СУБД получает информацию о запрошенной части концептуальной схемы (стрелка 5).
5. СУБД запрашивает информацию о местоположении данных на физическом уровне (на уровне
внутренней схемы) - файлы или физические адреса (стрелка 6).
6. В СУБД возвращается информация о местоположении данных в терминах операционной системы
(стрелка 7).
7. СУБД просит операционную систему предоставить необходимые данные, используя средства
операционной системы (стрелка 8).
8. Операционная система осуществляет перекачку информации из устройств хранения и пересылает ее в
системный буфер (стрелка 9).
9. Операционная система оповещает СУБД об окончании пересылки (стрелка 10).
10. СУБД выбирает из доставленной информации, находящейся в системном буфере, только то, что нужно
пользователю (стрелка 11), и пересылает эти данные в рабочую область пользователя.
 Модели данных
Модель данных  это совокупность правил описания и
структурирования данных, допустимых операций над ними и видов
ограничений целостности, которым они должны удовлетворять.
В соответствии с архитектурой ANSI/SPARC можно определить такие модели
данных:
 внешняя модель данных, отображающая представления каждого
существующего в организации типа пользователей;
 концептуальная модель данных, отображающая обобщенное
представление о данных, независимое от типа выбранной СУБД (эти
модели с точки зрения инфологического подхода называют
даталогическими);
 внутренняя модель данных, отображающая концептуальную схему
определенным образом, подходящим для выбранной целевой СУБД.
В литературе можно встретить деление моделей данных на три категории:
 семантические модели данных,
 модели данных на основе записей (или логические модели данных),
 физические модели данных.
Первые две могут использоваться для описания данных на концептуальном и внешнем
уровнях, а последняя  на внутреннем уровне.
 Модели данных
Общий подход к проблеме семантического моделирования можно охарактеризовать
четырьмя основными этапами:
1. Выявление некоторого множества семантических концептов/понятий (concepts),
которые используются для описания "реального мира". Например, таких как "сущность",
"тип сущности", "свойство", "связь" и т.д. Следует заметить, что эти термины определены не
совсем точно или формально, поскольку они являются всего лишь понятиями/концептами
(concepts) "реального мира", а не формальными терминами. Таким образом, данный этап
является неформальным, тогда как приведенные ниже этапы, напротив, достаточно формальны.
2. Определение набора соответствующих символических (формальных) объектов,
которые могут использоваться для представления описанных выше
семантических понятий. Например, в расширенной реляционной модели (RM/T) вводится
несколько особых видов отношений, которые называются Е- и Р-отношениями. Е-отношения
(entity-relations) представляют сущности (точнее список суррогатов для всех заданных типов
сущностей), а Р-отношения (property-relations)  свойства типа сущности. Е- и Р-отношения имеют
конкретные формальные определения, тогда как сами понятия "сущности" и "свойства" их не
имеют.
3. Определение набора формальных общих правил целостности, предназначенных
для работы с такими формальными объектами.
4. Определение набора формальных операторов, предназначенных для
манипулирования этими формальными объектами.
 Модели данных

К известным представителям направления семантического

моделирования можно отнести следующие модели:
 модель сущность-связь (entity-relationship model, или ER-
модель) и ее расширенные модели:
 EERM – Enhanced Entity-Relationship Model,
 HERM – Higher-Order Entity Relationship Model – модель
«сущность-связь» более высокого порядка;
 модель "объект-роль" (ORM, с диалектом NIAМ);
 объектную модель;
 семантическую бинарная модель Абриаля;
 семантические сетевые модели;
 инфологические модели;
 онтологические модели;
 модель «объект-событие» и т. д.
 Модели данных
Модели данных на основе записей
В модели данных на основе записей база данных представляется в виде
нескольких записей фиксированного формата, которые могут иметь
разные типы.
Каждый тип записи определяет фиксированное количество полей, каждое
из которых имеет фиксированную длину.

До недавнего времени существовало три основных типа моделей данных

на основе записей (три основные модели организации данных):
 реляционная модель данных (relational data model);
 сетевая модель данных (network data model);
 иерархическая модель данных (hierarchical data model).
 Модели данных

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

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

На верхнем уровне дерева в этой модели имеется

один узел — корень, на следующем уровне
располагаются узлы, связанные с этим корнем,
затем узлы, связанные с узлами предыдущего
уровня и т.д.
При этом каждый узел может иметь только одного
предка (родителя).

Основные достоинства иерархической модели  простота описания иерархических

структур реального мира и быстрое выполнение запросов.
Однако не всегда удобно каждый раз начинать поиск нужных данных с корня, а
другого способа перемещения по базе в иерархических структурах нет.
 Модели данных
Примеры деревьев (схемы иерархической модели данных) различного уровня детализации.
Пример 1.

Пример 2.

Пример 3.
 Модели данных
Сетевая модель данных
Сетевой подход к организации данных является расширением иерархического подхода.
Сетевая модель данных позволяет отображать разнообразные взаимосвязи элементов
данных в виде произвольного графа, обобщая тем самым иерархическую модель данных.
Сетевую модель можно представить как граф с записями в виде узлов графа и наборами в
виде его ребер.

Если в иерархических структурах запись-потомок могла

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

Например, каждый преподаватель

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

Достоинством сетевой модели данных является возможность

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

Недостатком сетевой модели данных является высокая

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

В реляционной модели данных

единственное требование состоит в
том, чтобы база данных с точки
зрения пользователя выглядела как
набор таблиц.
Такое восприятие относится только к
логической структуре базы данных,
то есть к внешнему и к
концептуальному уровням
архитектуры ANSI/SPARC.
Оно не относится к физической
структуре базы данных, которая
может быть реализована с помощью
разнообразных структур хранения.
 Сравнительная характеристика моделей данных
Вид модели Достоинства Недостатки
Иерархическая - простота понимания; - отношения М:М могут быть реализованы
- простота оценки операционных только искусственно;
характеристик. - могут быть избыточные данные;
- усложняются операции включения и удаления;
- удаление исходных объектов ведет к удалению
порожденных объектов;
- процедурный характер манипулирования
данными;
- доступ к любому порожденному узлу возможен
только через корневой узел;
- сильная зависимость логической и физической
БД;
- сильно ограниченный набор структур запроса.
Сетевая - сохранение информации при - сложность структуры: прикладной программист
уничтожении владельца; должен детально знать логическую структуру
- более богатая, чем в БД (для навигации в наборах и записях);
иерархической модели, структура - возможна потеря независимости данных при
запросов; реорганизации БД;
- меньшая, чем у иерархических - представление в прикладной программе
модели, зависимость логической и сложнее, чем в иерархической модели.
физической БД.
Реляционная - простота работы; - необходимость глубокого рассмотрения
- наличие представлений отношений (нормализация), в том числе
пользователя; отношений М:М;
- гибкость (соединение, разделение - возможность логических ошибок и
файлов); необходимость осторожной работы с моделью;
- произвольная структура запросов; - линейность структуры таблиц.
- хорошее теоретическое
обоснование.
 Модели данных
Модели данных баз данных NoSQL

Модель данных Пример базы данных

Ключ-значение (Key-Value) Redis, Berkeley DB, LevelDB, Memcached, Projecr
Voldemorr, Riak
Документная (документно- MongoDB, CouchDB, OrientDB, RavenDB, Terrastore
ориентированная) (Document)
Семейство столбцов Cassandra, HBase, Hypertable, Amazon SimpleDB
(Column-Family)
Графовая (Graph) HyperGraphDB, Infinire Graph, Neo4j, OrientDB,
FlockDB
 Модели данных
Модели данных баз данных NoSQL
JSON-модель, которую сегодня задействуют документо-ориентированные БД
(MongoDB, RethinkDB, CouchDB, Espresso) весьма схожа на иерархическую
модель данных.

Связи «один-ко-многим» формируют древовидную структуру в JSON-представлении

 Модели данных
NewSQL базы данных
Многие сторонники NoSQL делают необоснованные утверждения, например:
 «Реляционная модель не может масштабироваться»,
 «SQL не может масштабироваться».
Заявляя при этом о прогрессивности новых концепций, связанных с BASE (Basic
Availability – базовая доступность; Soft state – гибкое состояние; Eventual consistency –
согласованность в конечном счёте), теоремой САР.
Однако опыт показывает, что многие базы данных класса NoSQL сегодня не в полной
мере могут решать множество задач.
Возникшие на рубеже 2000-х и 2010-х годов множество технологий на базе SQL
породили так называемый класс СУБД NewSQL, стремящихся совместить в себе
преимущества NoSQL и транзакционные требования классических систем управления
базами данных.

Основная категория NewSQL-систем – это реляционные СУБД, изначально

построенные под требования горизонтальной масштабируемости:

 Clustrix,  HyPer,  SAP Hana,

 CockroachDB,  MemSQL,  Spanner,
 H-Store,  NuoDB,  VoltDB и др.
 Модели данных
Физические модели данных
Физические модели данных описывают то, как данные хранятся в
компьютере, представляя информацию о структуре записей, их
упорядоченности и существующих путях доступа.
То есть физическая модель данных оперирует категориями, касающимися
организации внешней памяти и структур хранения, используемых в данной
операционной среде.
В настоящий момент в качестве физических моделей используются
различные методы размещения данных, основанные на файловых
структурах – это организация:
 файлов прямого и последовательного доступа,
 индексных файлов,
 инвертированных файлов,
 файлов, использующих различные методы хеширования,
 взаимосвязанных файлов.
Кроме того, современные СУБД широко используют страничную
организацию данных.