Типы моделей БД: сетевые, иерархические, реляционные БД.

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

Иерархическая модель. В иерархической модели элементы организованы в структуры, связанные между собой иерархическими или древовидными связями. Родительский элемент может иметь несколько дочерних элементов. Но у дочернего элемента может быть только один предок. «Система управления информацией» (Information Management System) компании IMB – пример иерархической СУБД.

Иерархическая модель организует данные в форме дерева с иерархией родительских и дочерних сегментов. Такая модель подразумевает возможность существования одинаковых (преимущественно дочерних) элементов. Данные здесь хранятся в серии записей с прикреплёнными к ним полями значений. Модель собирает вместе все экземпляры определённой записи в виде «типов записей» – они эквивалентны таблицам в реляционной модели, а отдельные записи – столбцам таблицы. Для создания связей между типами записей иерархическая модель использует отношения типа «родитель-потомок» вида 1:N. Это достигается путём использования древовидной структуры – она «позаимствована» из математики, как и теория множеств, используемая в реляционной модели. Схема иерархической базы данных состоит из нескольких иерархических схем.

Сетевая модель. Записи в такой модели связаны списками с указателями. IDMS («Интегрированная система управления данными») от компании Computer Associates international Inc. – пример сетевой СУБД.

Иерархическая модель структурирует данные в виде древа записей, где есть один родительский элемент и несколько дочерних. Сетевая модель позволяет иметь несколько предков и потомков, формирующих решётчатую структуру.

Сетевая модель позволяет более естественно моделировать отношения между элементами. И хотя эта модель широко применялась на практике, она так и не стала доминантной по двум основным причинам. Во-первых, компания IBM решила не отказываться от иерархической модели в расширениях для своих продуктов, таких как IMS и DL/I. Во-вторых, через некоторое время её сменила реляционная модель, предлагавшая более высокоуровневый, декларативный интерфейс.

Популярность сетевой модели совпала с популярностью иерархической модели. Некоторые данные намного естественнее моделировать с несколькими предками для одного дочернего элемента. Сетевая модель как раз и позволяла моделировать отношения «многие ко многим». Её стандарты были формально определены в 1971 году на конференции по языкам систем обработки данных (CODASYL).

Основной элемент сетевой модели данных – набор, который состоит из типа «запись-владелец». Запись подчинённого уровня может выполнять свою роль в нескольких наборах. Соответственно, поддерживается концепция нескольких родительских элементов.

Запись старшего уровня («запись-владелец») также может быть «членом» или «владельцем» в других наборах. Модель данных – это простая сеть, связи, типы пересечения записей (в IDMS они называются junction records, то есть «перекрёстные записи). А также наборы, которые могут их объединять. Таким образом, полная сеть представлена несколькими парными наборами.

В каждом из них один тип записи является «владельцем» (от него отходит «стрелка» связи), и один или более типов записи являются «членами» (на них указывает «стрелка»). Обычно в наборе существует отношение 1:М, но разрешено и отношение 1:1. Сетевая модель данных CODASYL основана на математической теории множеств.

Известные сетевые базы данных: TurboIMAGE; IDMS; Встроенная RDM; Серверная RDM.

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

В отличие от двух других типов СУБД, в реляционных моделях данных нет необходимости просматривать все указатели, что облегчает выполнение запросов на выборку информации по сравнению с сетевыми и иерархическими СУБД. Это одна из основных причин, почему реляционная модель оказалась более удобна. Распространённые реляционные СУБД: Oracle, Sybase, DB2, Ingres, Informix и MS-SQL Server.

РСУБД – реляционная система управления базами данных, основанная на реляционной модели Э. Ф. Кодда. Она позволяет определять структурные аспекты данных, обработки отношений и их целостности. В такой базе информационное наполнение и отношения внутри него представлены в виде таблиц – наборов записей с общими полями.

Реляционные таблицы обладают следующими свойствами:

- Все значения атомарны.

- Каждый ряд уникален.

- Порядок столбцов не важен.

- Порядок рядов не важен.

- У каждого столбца есть своё уникальное имя.

Некоторые поля могут быть определены как ключевые. Это значит, что для ускорения поиска конкретных значений будет использоваться индексация. Когда поля двух различных таблиц получают данные из одного набора, можно использовать оператор JOIN для выбора связанных записей двух таблиц, сопоставив значения полей.

Поскольку отношения здесь определяются только временем поиска, реляционные базы данных классифицируются как динамические системы.

Сравнение трёх моделей.

Первая модель данных, иерархическая, имеет древовидную структуру («родитель-потомок»), и поддерживает только отношения типа «один к одному» или «один ко многим». Эта модель позволяет быстро получать данные, но не отличается гибкостью. Иногда роль элемента (родителя или потомка) неясна и не подходит для иерархической модели.

Вторая, сетевая модель данных, имеет более гибкую структуру, чем иерархическая, и поддерживает отношения «многие ко многим». Но быстро становится слишком сложной и неудобной для управления.

Третья модель – реляционная – более гибкая, чем иерархическая и проще для управления, чем сетевая. Реляционная модель сегодня используется чаще всего.

Объект в реляционной модели определяется как позиция информации, хранимой в базе данных. Объект может быть осязаемым или неосязаемым. Примером осязаемого объекта может быть сотрудник организации, а примером неосязаемой сущности – учётная запись покупателя. Объекты определяются атрибутами – информационным отображением свойств объекта. Эти атрибуты также известны как столбцы, а группа столбцов – как ряд. Ряд также можно определить как экземпляр объекта.

 

Компоненты СУБД.

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

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

Контроллер базы данных. Этот компонент взаимодействует с запущенными пользователями прикладными программами и запросами. Контроллер базы данных принимает запросы и проверяет внешние и концептуальные схемы для определения тех концептуальных записей, которые необходимы для удовлетворения требований запроса. Затем контроллер базы данных вызывает контроллер файлов для выполнения поступившего запроса.

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

Препроцессор языка DML. Этот модуль преобразует внедренные в прикладные программы DML-операторы в вызовы стандартных функций базового языка. Для генерации соответствующего кода препроцессор языка DML должен взаимодействовать с процессором запросов.

Компилятор языка DDL. Компилятор языка DDL преобразует DDL-команды в набор таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге, а управляющая информация – в заголовках файлов с данными.

Контроллер словаря. Контроллер словаря управляет доступом к системному каталогу и обеспечивает работу с ним. Системный каталог доступен большинству компонентов СУБД.

Ниже перечислены основные программные компоненты, входящие в состав контроллера базы данных.

Контроль прав доступа. Этот модуль проверяет наличие у данного пользователя полномочий для выполнения затребованной операции.

Процессор команд. После проверки полномочий пользователя для выполнения затребованной операции управление передается процессору команд.

Рисунок 1. Основные компоненты типичной системы управления базами данных.

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

Оптимизатор запросов. Этот модуль определяет оптимальную стратегию выполнения запроса.

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

Планировщик. Этот модуль отвечает за бесконфликтное выполнение параллельных операций с базой данных. Он управляет относительным порядком выполнения операций, затребованных в отдельных транзакциях.

Контроллер восстановления. Этот модуль гарантирует восстановление базы данных до непротиворечивого состояния при возникновении сбоев. В частности, он отвечает за фиксацию и отмену результатов выполнения транзакций.

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

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

 

Вопросы для самоконтроля

1. Система управления базами данных

2. Многопользовательские СУБД

3. Иерархическая модель

4. Сетевая модель

5. Реляционная модель

6. Компоненты СУБД

Список литературы

Основная литература:

Коломейченко, А. С. Информационные технологии: учебное пособие / А. С. Коломейченко, Н. В. Польшакова, О. В. Чеха. — Санкт-Петербург: Лань, 2018. — 228 с. — ISBN 978-5-8114-2730-7. — Текст: электронный // Лань: электронно-библиотечная система. — URL: https://e.lanbook.com/book/101862. — Режим доступа: для авториз. пользователей.

Геоинформационные системы: учебное пособие / составители О. Л. Гиниятуллина, Т. А. Хорошева. — Кемерово: КемГУ, 2018. — 122 с. — ISBN 978-5-8353-2232-9. — Текст: электронный // Лань: электронно-библиотечная система. — URL: https://e.lanbook.com/book/120040. — Режим доступа: для авториз. пользователей.

Подрядчикова, Е. Д. Инструментальные средства ГИС: учебное пособие / Е. Д. Подрядчикова. — Тюмень: ТюмГНГУ, 2018. — 86 с. — ISBN 978-5-9961-1887-8. — Текст: электронный // Лань: электронно-библиотечная система. — URL: https://e.lanbook.com/book/138256. — Режим доступа: для авториз. пользователей.

Дополнительная литература:

Информационные технологии. Базовый курс: учебник / А. В. Костюк, С. А. Бобонец, А. В. Флегонтов, А. К. Черных. — 2-е изд., стер. — Санкт-Петербург: Лань, 2019. — 604 с. — ISBN 978-5-8114-4065-8. — Текст: электронный // Лань: электронно-библиотечная система. — URL: https://e.lanbook.com/book/114686. — Режим доступа: для авториз. пользователей.

Любчик Г.П. Правовое обеспечение землеустройства и кадастров [Электронный ресурс]: учебное пособие/ Любчик Г.П.— Электрон. текстовые данные.— Тюмень: Тюменский индустриальный университет, 2017.— 218 c.— Режим доступа: http://www.iprbookshop.ru/83716.html.— ЭБС «IPRbooks».

Щербаков В.М. Экспертно-оценочное ГИС-картографирование [Электронный ресурс]/ Щербаков В.М.— Электрон. текстовые данные.— Санкт-Петербург: Проспект Науки, 2017.— 192 c.— Режим доступа: http://www.iprbookshop.ru/35807.html.— ЭБС «IPRbooks».

 

ЛЕКЦИЯ 14