Кто не делится найденным, подобен свету в дупле секвойи (древняя индейская пословица)

Версия для печати

Библиографическая запись: Логические модели данных. — Текст : электронный // Myfilology.ru – информационный филологический ресурс : [сайт]. – URL: https://myfilology.ru//165/bazy-dannyx/logicheskie-modeli-dannyx/ (дата обращения: 27.04.2024)

Логические модели данных

Содержание

Реляционная модель данных

Термин «реляционный» означает, что теория основана на математическом понятии "отношение". Например, бинарное отношение ∝ на χ есть подмножество ∝ ⊆ χ х χ, а тернарное - ∝ ⊆ χ ³.

Реляционная база данных — это такая база данных, которая воспринимается ее пользователями как множество переменных (т.е. переменных отношения — relvar), значениями которых являются отношения или, менее формально, таблицы. Реляционная система — это система, которая поддерживает реляционные базы данных и операции над ними, включая, в частности, операцию сокращения RESTRICT (иначе называемую выборкой, SELECT), операцию проекции PROJECT И операцию соединения JOIN. ЭТИ И подобные им операции, известные под названием операций реляционной алгебры, выполняются на уровне множеств. Свойство замкнутости реляционных систем означает, что результат выполнения операции имеет тот же тип, что и объекты, над которыми проводилась операция (все они являются отношениями). А это, в свою очередь, позволяет использовать вложенные реляционные выражения. Значения переменных отношения изменяются с помощью операций реляционного присваивания, причем привычные нам операции обновления INSERT, UPDATE и DELETE можно считать сокращенной формой записи операций реляционного присваивания определенных типов.

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

Структурный аспект. Данные в базе воспринимаются пользователем, как таблицы (и никак иначе).
Аспект целостности. Эти таблицы отвечают определенным условиям целостности.
Аспект обработки. В распоряжении пользователя имеются операторы манипулирования таблицами (например, предназначенные для поиска данных), которые генерируют новые таблицы на основании уже имеющихся и среди которых есть, по крайней мере, операторы сокращения (restrict), проекции (project) и объединения (join).

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

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

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

Для того, чтобы можно было однозначно различать записи, каждый тип записи должен иметь ключ. Ключ - это набор полей, однозначно идентифицирующий экземпляр записи. Например, в записи, описывающей человека, таким ключом может быть номер паспорта.

Групповое отношение - иерархическое отношение между записями двух типов. Как и сетевая, иерархическая модель данных базируется на графовой форме построения данных, и на концептуальном уровне она является просто частным случаем сетевой модели данных. Групповые отношения при графическом изображении обозначаются дугами ориентированного графа (типы связей предок — потомок), типы записей - вершинами. Такое изображение структуры БД называется диаграммой Бахмана (автор - американский исследователь Charles Bachman).

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

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

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

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

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

Сетевая модель данных

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

В сетевой модели используются несколько различных типовых структур данных, главными из которых являются типы записей и наборы. Для построения этих структур применяются такие конструктивные элементы, как элемент данных и агрегат. Элемент данных (или просто «элемент») - минимальная именованная единица данных, доступная пользователю с помощью СУБД. Агрегат данных - именованная совокупность элементов или других агрегатов данных.

Запись - это агрегат, который не входит в состав никакого другого агрегата, обычно описывает некоторый объект реального мира и составляет основную единицу обработки БД (записи запоминаются, извлекаются, удаляются).

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

Модель «сущность — связь» (ER)

Модель «сущность — связь» (ER, Entity-Relationship model) — модель данных, позволяющая описывать концептуальные схемы предметной области.

Модель сущность-связь называют также методом «ER-диаграмм», она основана на использовании диаграмм, называемых соответственно диаграммами ER-экземпляров и диаграммами ER-типа.

Основными понятиями метода сущность-связь являются следующие:

сущность,
атрибут сущности,
ключ сущности,
связь между сущностями,
степень связи,
класс принадлежности экземпляров сущности,
диаграммы ER-экземпляров,
диаграммы ER-типа.

Сущность представляет собой объект, информация о котором хранится в БД. Экземпляры сущности отличаются друг от друга и однозначно идентифицируются. Названиями сущностей являются, как правило, существительные, например. ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА, КАФЕДРА, ГРУППА.

Атрибут представляет собой свойство сущности. Это понятие аналогично понятию атрибута в отношении. Так, атрибутами сущности ПРЕПОДАВАТЕЛЬ может быть его Фамилия, Должность, Стаж (преподавательский) и т. д.

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

Связь двух или более сущностей - предполагает зависимость между атрибутами этих сущностей. Название связи обычно представляется глаголом. Примерами связей между сущностями являются следующие: ПРЕПОДАВАТЕЛЬ ВЕДЕТ ДИСЦИПЛИНУ (Иванов ВЕДЕТ «Базы данных»), ПРЕПОДАВАТЕЛЬ ПРЕПОДАЕТ В ГРУППЕ (Иванов ПРЕПОДАЕТ В 256 группе), ПРЕПОДАВАТЕЛЬ РАБОТАЕТ НА КАФЕДРЕ (Иванов РАБОТАЕТ-НА 25 кафедре).

На начальном этапе проектирования БД выделяются атрибуты, составляющие ключи сущностей. На основе анализа диаграмм ER-типа формируются отношения проектируемой БД. При этом учитывается степень связи сущностей и класс их принадлежности, которые, в свою очередь, определяются на основе анализа диаграмм ER-экземпляров соответствующих сущностей.

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

Модель «сущность — атрибут — значение» (EAV)

Модель «сущность-атрибут-значение» (EAV, Entity–attribute–value model) — это модель данных для кодирования с эффективным использованием места сущностей, где количество атрибутов (свойств, параметров), которые можно использовать для их описания, потенциально огромно, но количество на самом деле применяются к данному объекту является относительно скромным. Такие сущности соответствуют математическому понятию разреженной матрицы .

EAV также известен как модель объект-атрибут-значение, модель вертикальной базы данных и открытая схема.

Это представление данных аналогично экономичным методам хранения разреженной матрицы , где хранятся только непустые значения. В модели данных EAV каждая пара атрибут-значение представляет собой факт, описывающий объект, а строка в таблице EAV хранит один факт. Таблицы EAV часто описывают как «длинные и узкие»: «длинные» относятся к количеству строк, а «узкие» — к нескольким столбцам.

Данные записываются в виде трех столбцов:

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

Объектно-ориентированная модель

В объектно-ориентированной модели используются понятия класса, объекта, метода.

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

1. Инкапсуляция — объекты наделяются некоторой структурой и обладают определенным набором операций (методов). Внутренняя структура объекта скрыта от пользователя; манипуляция объектом, изменение его состояния возможны лишь посредством его методов. Таким образом, объекты можно рассматривать как самостоятельные сущности.

2. Наследование — возможность создавать из объектов новые объекты, которые унаследуют структуру и поведение своих предшественников, добавляя к ним черты, отражающие их собственную индивидуальность.

3. Полиморфизм — различные объекты могут получать одинаковые сообщения, но реагировать на них по-разному, в соответствии с тем, как реализованы у них методы, реагирующие на сообщения.

Моделирование данных в ООМД базируется на понятии объекта. ООМД обычно применяется в сложных предметных областях, для моделирования которых не хватает функциональности реляционной модели (например, для систем автоматизации проектирования (САПР), издательских систем и т.п.).

В объектно-ориентированной модели при представлении данных имеется возможность идентифицировать отдельные записи базы. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования.

Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым — string) или типом, конструируемым пользователем (определяется как class).

Значением свойства типа string является строка символов. Значение свойства типа class есть объект, являющийся экземпляром соответствующего класса. Каждый объект-экземпляр класса считается потомком объекта, в котором он определен как свойство. Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную
иерархию объектов.

При создании объектно-ориентированных СУБД (ООСУБД) используются разные методы, а именно:

встраивание в объектно-ориентированный язык средств, предназначенных для работы с БД;
расширение существующего языка работы с базами данных объектно-ориентированными функциями;
создание объектно-ориентированных библиотек функций для работы с БД;
создание нового языка и новой объектно-ориентированной модели данных.

К достоинствам ООМД можно отнести широкие возможности моделирования предметной области, выразительный язык запросов и высокую производительность. Каждый объект в ООМД имеет уникальный идентификатор (OID – object identifier). Обращение по OID происходит существенно быстрее, чем поиск в реляционной таблице.

Среди недостатков ООМД следует отметить отсутствие общепринятой модели, недостаток опыта создания и эксплуатации ООБД, сложность использования и недостаточность средств защиты данных.

Документная модель

Документная модель представляет наиболее распространенный способ отражения слабоструктурированной информации.

Документ — агрегат данных в документальных системах (АИПС), имеющий иерархическую структуру и, кроме форматных полей (элементы или агрегаты данных фиксированной длины), обычно содержащий текстовые поля или символьные последовательности неопределенной длины, логически подразделяющиеся на параграфы (PAR, SEGM), предложения (SENT), слова (WORD).

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

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

Запись базы данных — документ, который задается как набор в общем случае необязательных полей, для каждого из которых определены имя и тип. Допустимы большинство стандартных типов (так называемые «форматные» поля, задающие числовые, символьные и другие величины), а также текстовые. Текстовые поля имеют переменную длину и композиционную структуру, не имеющую прямых аналогов среди стандартных типов языков программирования: текстовое поле состоит из параграфов; параграф — из предложений; предложение — из слов. При этом идентифицируемым (адресуемым атомарным) элементом данных с точки зрения хранения будет поле, а с точки зрения поиска (атомарным семантически значимым) — слово. Вследствие этого поисковые структуры строятся в виде инвертированных файлов.

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

Звёздная модель

Схема «звезды» (схема звёздного соединения, звездоподобная схема, звёздная схема) — специальная организация реляционных таблиц, удобная для хранения многомерных показателей. Лежит в основе реляционного OLAP (online analytical processing, технология обработки данных, заключающаяся в подготовке суммарной информации на основе больших массивов данных, структурированных по многомерному принципу).

Модель данных состоит из двух типов таблиц: одной таблицы фактов (fact table) — центр «звезды» — и нескольких таблиц измерений (dimension table) по числу измерений в модели данных — лучи «звезды».

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

Таблицы измерений расшифровывают ключи, на которые ссылается таблица фактов; например, таблица «products» измерения «товары» базы данных торговой компании может содержать сведения о названии товара, его производителе, типе товара. За счёт использования специальной структуры таблицы измерений реализуется иерархия измерений, в том числе ветвящаяся.

Обычно данные в таблицах-измерениях денормализованы: ценой несколько неэффективного использования дискового пространства удается уменьшить число участвующих в операции соединения таблиц, что обычно приводит к сильному уменьшению времени выполнения запроса. Иногда, тем не менее, требуется произвести нормализацию таблиц-измерений; такая схема носит название «снежинка».

Модель снежинки

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

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

И звездочки, и снежинки - реляционные разновидности многомерной модели данных (ROLAP). ROLAP не имеет ограничений на объем данных, но обладает низким быстродействием.

Дейт К. Дж. Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом "Вильяме", 2005. — 1328 с.
Нестеров С. А. Базы данных: учеб. пособие / С. А. Нестеров. - СПб.: Изд-во Политехи, ун-та, 2013. - 150 с.
Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений / Под ред. npоф. А. Д. Хомоненко. — 6-е изд., доп. - СПб.: КОРОНА-Век, 2009. - 736 с.
Карпова И.П. Базы данных. Курс лекций и материалы для практических заданий. – Учебное пособие. – М.: Питер, 2013. – 240 с.
Советов Б. Я. Базы данных: теория и практика : учебник для бакалавров / Б. Я. Советов, В. В. Цехановский, В. Д. Чертовской. — 2-е изд. — М. : Издательство Юрайт, 2014. — 463 с.
Голицына О. Л., Максимов Н. В., Попов И. И. Базы данных: Учебное пособие. — М.: ФОРУМ: ИНФРА-М, 2006. — 352 с:

23.01.2022, 1441 просмотр.