2. Структура базы данных. Иерархическая, сетевая, объектно-реляционная, реляционная, объектно ориентированная , гибридная и многомерная модели данных

Привет, сегодня поговорим про структура базы данных, обещаю рассказать все что знаю. Для того чтобы лучше понимать что такое структура базы данных, иерархическая структура базы данных, сетевая структура базы данных, реляционная структура базы данных, объектно-ориентированная структура базы данных, гибридная структура базы данных, иерархическая базы данных, сетевая базы данных, реляционная базы данных, объектно-ориентированная базы данных, гибридная базы данных, многомерная модель , настоятельно рекомендую прочитать все из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL.

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

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

1) Иерархическая структура базы данных

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

К основным понятиям иерархической модели относятся: уровень, элемент (узел), связь

Это древовидная структура представления информации. Ее особенность в том, что каждый узел на более низком уровне имеет связь только с одним узлом на более высоком уровне. Посмотрим, например, на фрагмент иерархической структуры базы данных "Институт":



Из структуры понятно, что на одной кафедре может работать несколько преподавателей. Такая связь называется "один ко многим" (одна кафедра - много преподавателей). Но если мы попытаемся добавить в эту структуру группы студентов, то нам понадобится связь "многие ко многим":



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

Примеры иерархических бд

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

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

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

Структурная часть иерархической модели

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

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

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

Управляющая часть иерархической модели

В рамках иерархической модели выделяют языковые средства описания данных (ЯОД) и средства манипулирования данными (ЯМД). Каждая физическая база описывается набором операторов, обусловливающих как ее логическую структуру, так и структуру хранения БД. При этом способ доступа устанавливает способ организации взаимосвязи физических записей.

Определены следующие способы доступа:

• иерархически последовательный;
• иерархически индексно-последовательный;
• иерархически прямой;
• иерархически индексно-прямой;
• индексный.

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

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

Примеры типичных операторов поиска данных в иерархических БД

• найти указанное дерево БД;
• перейти от одного дерева к другому;
• найти экземпляр сегмента, удовлетворяющий условию поиска;
• перейти от одного сегмента к другому внутри дерева;
• перейти от одного сегмента к другому в порядке обхода иерархии.

Примеры типичных операторов поиска данных с возможностью модификации:

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

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

• вставить новый экземпляр сегмента в указанную позицию;
• обновить текущий экземпляр сегмента;
• удалить текущий экземпляр сегмента.

В иерархической модели автоматически поддерживается целостность ссылок между предками и потомками. Основное правило: никакой потомок не может существовать без своего родителя.

Известные иерархические СУБД

СУБД, основанные на иерархической модели данных: IMS, PC/Focus, Team-Up, Data Edge, Ока, ИНЭС, МИРИС.

Примерами баз данных с иерархической моделью являются :

• Типичным представителем (наиболее известным и распространенным) является Information Management System (IMS) фирмы IBM (1966-1968 г.).
• Time-Shared Date Management System (TDMS) компании System Development Corporation;
• Mark IV MultiAccess Retrieval System компании Control Data Corporation;
• System 2000 разработки SAS Institute ;
• InterSystems Caché .

Достоинства иерархической модели данных

• Простота понимания
• Простота оценки операционных характеристик
• Хорошие временные показатели выполнения операций над данными

Недостатки иерархической модели данных

• Структура данных задается на этапе проектирования БД и не может быть
• изменена при организации доступа к данным
• Громоздкость модели для обработки информации со сложными
• логическими связями
• Отношения М : М могут быть реализованы только искусственно
• Возможны избыточные данные
• Удаление исходных объектов ведет к удалению порожденных объектов
• Доступ к любому порожденному узлу возможен только через корневой узел
• Ограниченный набор структур запроса

2) сетевая структура базы данных

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

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

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

Сетевая БД состоит из набора экземпляров определенного типа записи и набора экземпляров определенного типа связей между этими записями.

Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия:

• каждый экземпляр типа записи P является предком только в одном экземпляре типа связи L;
• каждый экземпляр типа записи C является потомком не более чем в одном экземпляре типа связи L.

Рис Пример сетевой модели данных

Аспект манипуляции

Примерный набор операций манипулирования данными:

• найти конкретную запись в наборе однотипных записей;
• перейти от предка к первому потомку по некоторой связи;
• перейти к следующему потомку в некоторой связи;
• перейти от потомка к предку по некоторой связи;
• создать новую запись;
• уничтожить запись;
• модифицировать запись;
• включить в связь;
• исключить из связи;
• переставить в другую связь и т. Об этом говорит сайт https://intellect.icu . д.

Аспект целостности

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

Достоинства сетевых бд

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

Недостатки сетевых бд

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

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

История сетевых бд

Сетевая модель была одним из первых подходов, использовавшимся при создании баз данных в конце 50-х — начале 60-х годов. Активным пропагандистом этой модели был Чарльз Бахман. Идеи Бахмана послужили основой для разработки стандартной сетевой модели под эгидой организации CODASYL. После публикации отчетов рабочей группы этой организации в 1969, 1971 и 1973 годах многие компании привели свои сетевые базы данных более-менее в соответствие со стандартами CODASYL. До середины 70-х годов главным конкурентом сетевых баз данных была иерархическая модель данных, представленная ведущим продуктом компании IBM в области баз данных — IBM IMS .

В конце 60-х годов Эдгаром Коддом была предложена реляционная модель данных и после долгих и упорных споров с Бахманом реляционная модель приобрела большую популярность и теперь является доминирующей на рынке СУБД.

Сетевые СУБД

Сетевая СУБД — СУБД, построенная на основе сетевой модели данных.

К основным понятиям сетевой модели базы данных относятся: уровень, элемент (узел), связь.

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

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

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

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

СУБД, основанные на сетевой модели данных: IDMS, db_Vista III, СЕТЬ, СЕТОР, КОМПАС

Список самых значимых сетевых СУБД на 1978 год :

• IDS (Integrated Data Store) компании General Electric — самая первая сетевая СУБД, разработанная Чарльзом Бахманом в 1960 году
• IDS/2 или IDS/II) компании Honeywell, купившей IDS у General Electric, позднее — компании Bull
• Integrated Database Management System (IDMS) компании Cullinet, развитие IDS на основе ее исходных кодов
• DMS-1100 (для мейнфреймов UNIVAC 1100) и DMS-90 (для мини-компьютеров, первый релиз — ноябрь 1974) компании UNIVAC
• DBMS-10 компании DEC для Decsystem-10 и Decsystem-20
• CDC DMS-170
• Burroughs Data Management System (DMS-2 ). Продукт представлен на рынке в октябре 1974 года.

Другие подобные СУБД:

• IMAGE/3000 компании Hewlett-Packard (1974 г.)
• Norsk-Data SYBAS
• NCR IDM-9000
• Cincom TOTAL
• dbVista
• Universal Datenbank System (UDS) от Siemens
• СООБЗ Cerebrum
• ИСУБД «CronosPRO»
• Caché
• GT.M

3) реляционная структура базы данных

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

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

К основным понятиям реляционной модели относятся: тип данных, домен, атрибут, кортеж, отношение, первичный ключ

Рис элементы реляционной модели

Рис пример реляционной модели

Достоинства реляционной модели данных

• Простота работы и отражение представлений пользователя
• Гибкость (соединение, разделение файлов)
• Простота внедрения плоских файлов
• Отделение от физической реализации (независимость)
• Произвольная структура запросов
• Хорошее теоретическое обоснование

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

• Сложность структуры, вызванная процессом нормализации
• Низкая производительность из-за поиска по ключу (что в 3-5 раз увеличивает количество операций доступа)
• Ограниченный набор типов данных (например, отсутствуют форматы мультимедиа, геоинформации и т.д.)
• Недостаточное естественное представление данных (в виде плоских двумерных таблиц, а не таблиц со сложной структурой, как в сетевой модели данных)
• Невозможность рассмотрения данных послойно, на разных уровнях абстракции
• Невозможность определить набор операторов (методов), связанных с определенным типом данных (приходится задавать операции в конкретном
• приложении)

СУБД, основанные на реляционной модели данных:
Clipper, dBase, Paradox, FoxPro, Access, Oracle, Mysql, Postgress

4) Объектно-ориентированные и гибридные базы данных

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

Гибридные БД совмещают в себе возможности реляционных и объектно-ориентированных, поэтому их часто называют объектно-реляционными. Примером такой СУБД является Oracle, начиная с восьмой версии.

Несомненно, такие БД будут развиваться в будущем, но пока первенство остается за реляционными структурами. Поэтому именно их мы и будем изучать в последующих уроках.

ООМ графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом или
типом, конструируемым пользователем (определяется как Сlass).
К основным понятиям объектно-ориентированной модели относятся: объект, линии поведения, сообщения, класс, отношения.
Объекты являются моделями, очень близкими по своим свойствам и характеристикам объектам реального мира.

Объекты характеризуются свойствами, определяющими их состояние, и методами, определяющими их поведение. Объекты взаимодействуют друг с
другом путем передачи сообщений, активизирующих их линии поведения.

Компоненты объектно-ориентированной модели:

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

История ООБД

Первые публикации об объектно-ориентированных базах данных появились в середине 80-х годов.

Характеристики ООБД

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

В манифесте ООБД предлагаются обязательные характеристики, которым должна отвечать любая ООБД. Их выбор основан на 2 критериях: система должна быть объектно-ориентированной и представлять собой базу данных.

Обязательные характеристики

1. Поддержка сложных объектов. В системе должна быть предусмотрена возможность создания составных объектов за счет применения конструкторов составных объектов. Необходимо, чтобы конструкторы объектов были ортогональны, то есть любой конструктор можно было применять к любому объекту.
2. Поддержка индивидуальности объектов. Все объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов.
3. Поддержка инкапсуляции. Корректная инкапсуляция достигается за счет того, что программисты обладают правом доступа только к спецификации интерфейса методов, а данные и реализация методов скрыты внутри объектов.
4. Поддержка типов и классов. Требуется, чтобы в ООБД поддерживалась хотя бы одна концепция различия между типами и классами. (Термин «тип» более соответствует понятию абстрактного типа данных. В языках программирования переменная объявляется с указанием ее типа. Компилятор может использовать эту информацию для проверки выполняемых с переменной операций на совместимость с ее типом, что позволяет гарантировать корректность программного обеспечения. С другой стороны класс является неким шаблоном для создания объектов и предоставляет методы, которые могут применяться к этим объектам. Таким образом, понятие «класс» в большей степени относится ко времени исполнения, чем ко времени компиляции.)
5. Поддержка наследования типов и классов от их предков. Подтип, или подкласс, должен наследовать атрибуты и методы от его супертипа, или суперкласса, соответственно.
6. Перегрузка в сочетании с полным связыванием. Методы должны применяться к объектам разных типов. Реализация метода должна зависеть от типа объектов, к которым данный метод применяется. Для обеспечения этой функциональности связывание имен методов в системе не должно выполняться до времени выполнения программы.
7. Вычислительная полнота. Язык манипулирования данными должен быть языком программирования общего назначения.
8. Набор типов данных должен быть расширяемым. Пользователь должен иметь средства создания новых типов данных на основе набора предопределенных системных типов. Более того, между способами использования системных и пользовательских типов данных не должно быть никаких различий.

Необязательные характеристики:

• Множественное наследование
• Проверка типов
• Распределение
• Проектные транзакции

Открытые характеристики:

• Парадигмы программирования (процедурное, декларативное)
• Система представления
• Система типов
• Однородность. Реализация — язык программирования — интерфейс.

ООБД и ее СУБД

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

Некоторые объектно-ориентированные базы данных разработаны для плотного взаимодействия с такими объектно-ориентированными языками программирования, как Python, Java, C#, Visual Basic .NET, C++, Objective-C и Smalltalk; другие имеют свои собственные языки программирования. ООСУБД используют точно такую же модель, что и объектно-ориентированные языки программирования.

СУБД должна обеспечивать:

• Долговременное хранение
• Использование внешней памяти
• Параллелизм
• Восстановление
• Нерегламентированные запросы

Реализация объектно-ориентированного подхода

Реализация объектно-ориентированного подхода характеризуется следующими ключевыми свойствами объектов:

• Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено.
• Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта.
• Полиморфизм означает способность одного и того же программного кода работать с разнотипными данными. Другими словами, он означает допустимость в объектах разных типов иметь методы (процедуры или функции) с одинаковыми именами. Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента.

Достоинства объектно-ориентированной модели данных:

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

Недостатки объектно-ориентированной модели данных:

• Высокая понятийная сложность
• Неудобство обработки данных
• Низкая скорость выполнения запросов

СУБД, основанные на объектно-ориентированной модели данных:
POET, Jasmine, Versant, Iris, Orion, Postgres.

5) Объектно-реляционная СУБД (ОРСУБД)

Объектно-реляционная СУБД (ОРСУБД) — реляционная СУБД (РСУБД), поддерживающая некоторые технологии, присущие объектно-ориентированным СУБД и реализующие объектно-ориентированный подход: объекты, классы и наследование реализованы в структуре баз данных и языке запросов.

Объектно-реляционными СУБД являются, например, широко известные Oracle Database, Informix, DB2, PostgreSQL.

6) Хранилища данных и модели их представления

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

Основные модели представления данных в хранилищах данных:

• 1. Реляционная
• 2. Многомерная
• 3. Гибридная
• 4. Виртуальная

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

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

рис Схема построения реляционного хранилища данных «звезда»

Центральной является таблица фактов (Fact table), с которой связаны таблицы измерений (Dimension tables).

Преимущества схемы «звезда»:

• простота и логическая прозрачность модели
• более простая процедура пополнения измерений, поскольку
• приходится работать только с одной таблицей

Недостатки схемы «звезда»:

• медленная обработка измерений, поскольку одни и те же значения
• измерений могут встречаться несколько раз в одной и той же таблице высокая вероятность возникновения несоответствий в данных (в частности, противоречий), например, из-за ошибок ввода

Рис Схема построения реляционного хранилища данных «снежинка» (модификация схемы «звезда»)

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

Преимущества схемы «снежинка»:

• она ближе к представлению данных в многомерной модели
• процедура загрузки из РХД в многомерные структуры более
• эффективна и проста, поскольку загрузка производится из отдельных таблиц
• намного ниже вероятность появления ошибок, несоответствия данных
• большая, по сравнению со схемой «звезда», компактность
• представления данных, поскольку все значения измерений упоминаются только один раз

Недостатки схемы «снежинка»:

• достаточно сложная для реализации и понимания структура данных
• усложненная процедура добавления значений измерений

Преимущества реляционных хранилищ данных:

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

Главный недостаток реляционных хранилищ данных:

• При использовании высокого уровня обобщения данных и иерархичности измерений в таких хранилищах начинают «размножаться» таблицы агрегатов. В результате скорость выполнения запросов реляционным хранилищем замедляется

7 многомерная модель

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

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

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

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

В ячейке 1 будут располагаться факты, относящиеся к продаже цемента ООО «Спецстрой» 3 ноября, в ячейке 2 – к продаже плит ЗАО «Пирамида» 6
ноября, а в ячейке 3 – к продаже плит ООО «Спецстрой» 4 ноября.

Рис Многомерный взгляд на измерения Дата, Товар и Покупатель

Выделенный сегмент будет содержать информацию о том, сколько плит, на какую сумму и по какой цене приобрела фирма ЗАО «Строитель» 3 ноября.

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

Преимущества многомерного подхода:

• Представление данных в виде многомерных кубов более наглядно, чем совокупность нормализованных таблиц реляционной модели, структуру которой представляет только администратор БД
• Возможности построения аналитических использующей МХД, более широки запросов
• В некоторых случаях использование многомерной значительно уменьшить продолжительность поиска в выполнение аналитических запросов практически в времени к системе, модели позволяет МХД, обеспечивая режиме реального

Недостатки использования многомерной модели:

• Для ее реализации требуется больший объем памяти
• Многомерная структура труднее поддается модификации

Системы, поддерживающие многомерную модель данных:
Essbase, Media Multi-matrix, Oracle Express Server, Cache.
Многие программные продукты позволяют одновременно работать с многомерными и с реляционными БД.

Вау!! 😲 Ты еще не читал? Это зря!

• модели данных , ранние подходы к организации данных ,
• реляционная модель данных ,
• иерархическая модель , сетевая модель ,
• постреляционная модель , многомерная модель ,
• реляционная модель данных ,
• концептуальная модель базы данных , концептуальная модель ,
• преобразование концептуальной модели в реляционную , создание реляционной модели ,
• хранилища данных
• Объектно-реляционное отображение
• Объектно-реляционная база данных
• паттерны обработки объектно-реляционных метаданных , metadata mapping ,
• паттерны , объектно-реляционного структурирования ,
• orm , object-relational mapping ,
• объектно-реляционный разрыв ,

В общем, мой друг ты одолел чтение этой статьи об структура базы данных. Работы впереди у тебя будет много. Смело пиши комментарии, развивайся и счастье окажется в твоих руках. Надеюсь, что теперь ты понял что такое структура базы данных, иерархическая структура базы данных, сетевая структура базы данных, реляционная структура базы данных, объектно-ориентированная структура базы данных, гибридная структура базы данных, иерархическая базы данных, сетевая базы данных, реляционная базы данных, объектно-ориентированная базы данных, гибридная базы данных, многомерная модель и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL