7.3. Организация баз данных в информационных технологиях
Модели БД основаны на современном подходе к обработке информации, декларирующем относительную устойчивость структур баз данных, что связано, прежде всего, со стабильностью во времени основных типов объектов на предприятиях, для которых организуется информационная технология. Поэтому в ИТ в менеджменте возможно построение базы данных с постоянной структурой и изменяемыми информационными значениями. Такая БД, отображающая в структурированном виде информационную систему предметной области, позволяет сформировать логические записи, их элементы и взаимосвязи между ними, которые отражают подчиненность элементов БД.
Всем моделям данных присущи определенные типы структур, которые поддерживаются СУБД. Причем, в различных СУБД тип структур данных может быть по-разному определен и назван, например, поле, элемент данных, атрибут и т.д.
Взаимосвязи между элементами БД могут быть типизированы по следующим основным видам:
«один к одному» (1–1), когда одна запись может быть связана только с одной записью;
«один ко многим» (1–М) – одна запись взаимосвязана со многими другими записями или многие записи взаимосвязаны только с одной записью (во втором случае эту связь также называют «многие к одному»);
«многие ко многим» (М–М) – одна и та же запись может входить в отношения со многими другими записями в различных вариантах.
Применение того или иного вида взаимосвязей определило четыре основных модели БД: файловую, иерархическую, сетевую и реляционную.
Файловая модель была первой моделью, используемой при формализации данных во внутримашинном ИО, и является одной из простейших моделей, ориентированных на обработку информации посредством специализированных программ, работающих под управлением какой-либо ОС.
В файловой модели для структурирования информации используется модель «плоский файл», имеющий линейную (одноуровневую) структуру и, представляющую собой двумерную таблицу. Для разработки плоских файлов не используются СУБД. Как правило, их разрабатывают в специализированном ПО.
К основным типам структур файловой модели относятся:
Поле – элементарная единица логической организации данных, которая соответствует минимальной неделимой единице информации – реквизиту. Для каждого из полей назначается позиция и длина. В программе, которая использует файл, определены характеристики, назначенные каждому полю, т.к. этой информации в самой БД нет.
Тип поля определяет множество значений, которые может принимать данное поле в различных записях. В файловых и реляционных моделях используются несколько основных типов полей. Поля, значения которых могут быть только числами, относятся к полям числового типа, которые в свою очередь делятся на поля вещественного типа, поля целого типа, поля денежного типа данных и т.д. Символьный тип поля представляет символьные последовательности (слова, коды и т.п.). Поля типа «дата/время» предназначены для хранения времени, дат и дат совместно с временем в разных форматах представления. Логический тип данных соответствует полю, которое может принимать два значения: «да» – «нет» или «истина» – «ложь» («true» – «false»).
Запись – совокупность полей, соответствующих логически связанным реквизитам. Структура записи определяется составом и последовательностью входящих в нее полей, каждое из которых содержит один реквизит.
Экземпляр записи представляет собой реализацию записи, содержащую конкретные значения полей.
Ключ записи – идентификатор, однозначно определяющий каждый экземпляр записи.
В моделях данных выделят два вида ключей – первичный и вторичный.
Первичный ключ (ПРК) – одно или несколько полей (реквизитов) однозначно идентифицирующих запись. Если первичный ключ состоит из одного поля, то он называет простым, а если из нескольких полей – составным.
Вторичный ключ (ВРК) – поле, значение которого может повторяться в нескольких записях, т.е. реквизит не является уникальным. В отличие от первичного ключа, по которому может быть найден единственный экземпляр записи, по вторичному ключу можно найти несколько записей.
Ключи записей позволяют выполнять индексирование файлов для их последующего поиска и эффективного доступа.
При индексировании создается дополнительный индексный файл, который включает в упорядоченном виде все значения ключа конкретного файла. Для каждого значения ключа в индексном файле содержится указатель на соответствующую запись. При наличии индексного файла, размеры которого меньше основного файла, по заданному параметру оперативно отыскивается запись. С помощью указателя на запись в файле данных осуществляется прямой доступ к этой записи. Индексирование может производиться не только по первичному, но и по вторичному ключу.
При описании логической организации данных каждому файлу присваивается уникальное имя и дается описание структуры его записей, которое включает перечень входящих в нее полей и их порядок внутри записи. Для каждого поля задается сокращенное обозначение – имя поля (идентификатор поля внутри записи), формат поля – тип хранимого данного, длина поля и точность числовых данных (количество десятичных знаков). Для полей, выполняющих роль ключа записи указывается признак ключа.
Структуру файла при описании внутримашинного ИО можно представить в виде таблицы, где отмечаются первичные и вторичные ключи. Например, документ «Ведомость плановой себестоимости изготовления изделий» имеет первичный составной ключ, включающий три реквизита – «код цеха», «код изделия», «наименование изделия». При этом, эти же реквизиты каждый по отдельности являются вторичными ключами, т.к. повторяются в других документах предприятия (см. рис. 7.6).
Рисунок 7.6 – Пример документа и его структуры
Структура плоских файлов позволяет работать с ними очень быстро. Однако недостатком является то, что программная логика, которая предназначена для манипулирования данными из файлов, должна быть очень подробной. В приложении ориентированном на работу с базами плоских файлов указывается, где и как в файле хранятся данные. Небольшие базы данных с плоскими файлами имеют высокую производительность, но при увеличении количества файлов производительность резко падает.
Иерархическая модель данных является наиболее простой и появилась первой среди всех моделей БД, организованных в среде СУБД. Появление иерархической модели связано с тем, что в различных областях человеческой деятельности очень многие связи соответствуют иерархии, когда один объект выступает как родительский, а с ним может быть связано множество подчиненных объектов. Самой известной иерархической системой позволяющей создавать иерархические БД является система IMS (Information Management System) фирмы IBM, используемая в свое время для поддержки лунного проекта «Аполлон» («Apollon»), в процессе реализации которого необходимо было управлять огромным количеством деталей, иерархически связанных между собой.
Иерархическая модель представляется в виде перевернутого дерева, в котором объекты выделяются по уровням соподчиненности (иерархии) объектов (см. рис. 7.7).
Взаимосвязи между элементами БД в иерархической модели организованы по типу «один ко многим». На каждом уровне формируется узел, состоящий из совокупности реквизитов данных, описывающих некоторый объект (запись базы данных). Иерархическая структура всегда удовлетворяет следующим требованиям:
каждый узел на более низком уровне связан только с одним узлом, находящимся на более высоком уровне;
иерархическое дерево имеет только один узел (корневой или корень), не подчиненный никакому другому узлу и находящийся на самом верхнем – первом уровне;
к каждому узлу базы данных существует только один иерархический путь от корневого узла.
Рисунок 7.7 – Иерархическая модель данных
Количество деревьев в БД определяется числом корневых записей. В иерархических моделях непосредственный доступ к данным, как правило, возможен только к объекту самого высокого уровня – корню. К другим объектам доступ осуществляется по связям от корня на вершине модели.
Корневая запись каждого дерева обязательно должна содержать ключ с уникальным значением. Например, в задаче с планом выпуска изделий по цеху, прослеживается четкая иерархия, в которой каждому цеху соответствуют свои виды изделий, на каждый вид изделия запланирован объем выпуска, себестоимость изготовления одного изделия и т.д. (см. рис. 7.8).
Рисунок 7.8 – Пример иерархической базы данных
Основными достоинствами иерархической модели является то, что она позволяет описать структуру данных как на логическом, так и на физическом уровне, эффективно использует память вычислительной машины и имеет достаточно высокие показатели времени выполнения операций над данными.
К недостаткам модели можно отнести жесткую фиксацию взаимосвязей между элементами данных (вследствие чего любые изменения связей требуют изменения структуры), жесткую зависимость физической и логической организации данных. Быстрота доступа в иерархических моделях достигается за счет потери информационной гибкости, что ограничивает их применение.
Сетевая модель данных является развитием иерархической модели. Она появилась в 1971 г., когда группа DTBG (Database Task Group) представила в американский национальный институт стандартов отчет, который послужил в дальнейшем основой для разработки сетевых систем управления базами данных. Стандарт сетевой модели впервые был определен в 1975 году организацией CODASYL (Conference of Data System Languages), которая определила базовые понятия модели и формальный язык описания.
Структура БД в сетевой модели задается типами записей и типами наборов, которые представляют собой поименованную совокупность связанных записей. Сетевая модель данных основана на тех же основных понятиях (уровень, узел, связь), что и иерархическая, но в сетевой модели каждый узел может быть связан с любым другим узлом, т.е. взаимосвязи между элементами БД в сетевой модели организованы по типу «многие к одному» или «много ко многим». Примером сетевой БД можно назвать Internet. Гиперссылки связывают между собой сотни миллионов документов в единую распределенную сетевую базу данных.
В сетевых моделях непосредственный доступ по ключу может обеспечиваться к любому объекту независимо от уровня, на котором он находится в модели. Возможен доступ и по связям от любой точки доступа (см. рис. 7.9).
Рисунок 7.9 – Сетевая модель данных
Структура объекта (записи, файла) в сетевых моделях чаще бывает линейной и реже имеет иерархическую структуру. Структуры данных более низкого уровня также могут иметь свою специфику и названия, например атрибут – аналог поля и т.д. Объект линейной структуры состоит только из простых и ключевых атрибутов.
Например, задача с выпуском изделий по цеху в сетевой модели будет иметь вид, представленный на рис. 7.10.
Рисунок 7.10 – Пример сетевой базы данных
К особенностям организации сетевой модели относятся:
база данных может состоять из произвольного количества записей и наборов различных типов;
связь между двумя записями может выражаться произвольным количеством наборов;
в любом наборе может быть только один владелец;
тип записи может быть владельцем в одних типах наборов и членом в других типах наборов;
тип записи может не входить ни в какой тип наборов.
Основными недостатками сетевого подхода в БД относят как сложность самой модели данных, так и сложность освоения средств манипулирования данными в ней. Однако, сетевые модели данных по сравнению с иерархическими являются более универсальным средством отображения во внутримашинном ИО структуры информации для разных предметных областей, т.к. взаимосвязи данных большинства предметных областей имеют сетевой характер. Это ограничивает использование иерархических моделей.
К достоинствам сетевых моделей можно отнести:
отсутствие дублирования данных в различных элементах модели;
технология работы с сетевыми моделями является удобной для пользователей, т.к. доступ к данным практически не имеет ограничений и возможен непосредственно к объекту любого уровня;
в сетевых моделях допустимы всевозможные запросы и т.д.
Тем не менее, наиболее широкое распространение особенно в экономической деятельности получили реляционные модели, которые положены в основу организации реляционных баз данных.
Реляционная модель данных. Основателем реляционной модели является сотрудник фирмы IBM Э.Ф. Кодд, который в 1970 году в своей статье вывел заключение о том, что любое представление данных может быть сведено к совокупности двумерных таблиц, называемых в математике «отношениями» (relations – отношения). Отсюда и пошел термин, определяющий модель данных, представленную в виде таблиц – «реляционная».
Реляционные модели данных отличаются от иерархической и сетевой простотой структур данных, удобным для пользователя табличным представлением и доступом к данным. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
все столбцы в таблице однородные, т.е. все элементы в одном столбце имеют одинаковый тип (числовой, символьный и т.д.) и максимально допустимый размер;
каждый столбец имеет уникальное имя;
одинаковые строки в таблице отсутствуют;
порядок следования строк и столбцов в таблице может быть произвольным.
Структурными объектами обработки реляционной БД являются следующие информационные единицы (см. рис. 7.11):
Рисунок 7.11 – Основные структурные элементы реляционной базы данных
Атрибут (поле, домен) – элементарная единица логической организации данных, которая соответствует неделимой единице информации (столбец реляционной таблицы). Каждый столбец таблицы (атрибут) должен иметь имя.
Кортеж (запись) – совокупность логически связанных полей, обобщенная строка реляционной таблицы. В каждой строке таблицы содержится по одному значению в соответствующем столбце. В таблице не может быть двух одинаковых строк. Общее количество строк не ограничено.
Экземпляр записи – отдельная реализация записи, содержащая конкретные значения ее полей (конкретная строка реляционной таблицы).
Таблица (отношение) – заданная структура полей, состоящая из конечного набора однотипных записей.
Ключ – один или несколько атрибутов (полей), значения которых однозначно идентифицируют строку таблицы. Как указывалось выше, ключи подразделяются на первичные и вторичные. Первичный ключ в реляционной БД должен обладать следующими свойствами:
однозначная идентификация записи – запись должна однозначно определяться значением ключа;
отсутствие избыточности – никакое поле нельзя удалить из ключа, не нарушая при этом свойства однозначной идентификации записи.
Базы данных могут содержать различные объекты, но к основным относятся, прежде всего, таблицы. Простейшая база данных имеет хотя бы одну таблицу.
Даже если база данных не заполнена (пустая база), то, она все равно представляет из себя полноценную БД, т.к. информация в ней все-таки представлена структурой базы данных, которая определяет методы занесения данных и хранения их в базе. Изменения, вносимые в состав полей базовой таблицы (или их свойства), приводят к изменениям структуры БД и к получению новой базы данных.
Таблицы в реляционной БД создаются таким образом, чтобы каждая содержала информацию об одном информационном объекте. Не рекомендуется сводить в одну таблицу данные, относящиеся к разным информационным объектам. Например, неверно хранить в одной таблице данные о планах изготовления изделий и продукцию склада и т.д.
После создания различных таблиц, содержащих данные, относящиеся к различным информационным объектам БД, между этими таблицами должны быть установлены реляционные связи. Установка таких связей делает возможным выполнение одновременной обработки данных из нескольких таблиц. Для установки связей обычно используют ключевые поля таблиц, например, код цеха в документе по выпуску изделий.
Чтобы связать две реляционные таблицы, необходимо ключ одной связываемой таблицы ввести в состав ключа другой связываемой таблицы (возможно совпадение ключей) или ввести в структуру одной таблицы внешний ключ, т.е. поле, не являющееся ключевым в данной таблице, но являющееся таким в другой. Например, база данных «Поставки изделий по договорам», представленная на рис. 7.12.
Рисунок 7.12 – Реляционная БД поставки товаров по договорам
База данных состоит из шести таблиц – «Заказчики», «Данные о заказчике», «Договоры», «Изделия», «Заказы изделий», «Поставка изделий».
Таблица «Заказчики», приведенная на рис. 7.12 (а), представляет информацию о заказчиках. Каждый заказчик имеет код, уникальный для этого заказчика, фамилию, имя, отчество (неуникальные), местонахождение (город).
Таблица «Изделия» (рис. 7.12 б) содержит код поставляемых изделий и их номер.
Таблица «Данные о заказчике» (рис. 7.13 в) содержит контактные данные о заказчике (название организации и контактный телефон).
Таблица «Договоры» (рис. 7.12 г) описывает заключенные с заказчиками договоры и включает в себя код договора, код заказчика и номер заключенного договора.
В таблице «Заказы изделий» (рис. 7.12 д) отражено количество заказанных изделий по каждому договору.
В таблице «Поставка изделий» (рис. 7.12 е) отражено количество поставленных изделий по каждому заказу и дата отгрузки.
Для наглядности представления связей между таблицами можно изобразить их в виде структур, т.е. только с указанием названия полей (столбцов) таблиц (см. рис. 7.13).
Рисунок 7.13 – Связи в таблицах реляционной базы данных
Каждая из представленных таблиц имеет первичный ключ, который однозначно идентифицирует запись таблицы. В таблицах «Заказчики» и «Данные о заказчиках» – это поле Код заказчика, в таблице «Договоры» – поле Код договора, в таблице «Изделия» – поле Код изделия, в таблице «Заказы изделий» – поле Код заказа, в таблице «Поставка изделий» – поле Код поставки.
Вместе с тем каждая таблица, кроме таблиц «Заказчики» и «Данные о заказчиках», имеет один или несколько внешних ключей, которые обеспечивают ее связь с другими таблицами. Таблица «Договоры» имеет внешний ключ Код заказчика, который связывает ее с таблицей «Заказчики». Таблица «Заказы изделий» имеет два внешних ключа: Код договора, который связывает ее с таблицей «Договоры» и Код изделия, который связывает ее с таблицей «Изделия». Таблица «Поставка изделий» имеет один внешний ключ Код заказа, обеспечивающий связь с таблицей «Заказы изделий»
Таким образом, некоторая запись одной таблицы связана с некоторой записью другой таблицы, если обе эти записи содержат одно и то же значение в поле, по которому установлена связь между таблицами.
Всю информацию, содержащуюся в БД, можно разместить в одной таблице, но такая структура данных является неэффективной, поскольку в этой таблице будет достаточно много повторяющихся данных, что приведет кследующим проблемам:
• наличие повторяющихся данных приведет к неоправданному увеличению размера файла базы данных. Кроме нерационального использования дискового пространства, это также вызовет заметное замедление работы приложения;
• ввод пользователем большого количества повторяющейся информации неизбежно приведет к возникновению ошибок;
• изменение одного из часто используемых параметров потребует значительных усилий по корректировке каждой записи, содержащей эти данные.
Для устранения этих проблем выполняется нормализация данных, под которой понимается процесс уменьшения избыточности информации в базе данных посредством разделения ее на несколько связанных друг с другом таблиц. Выделяют шесть основных уровней нормализации базы данных, которые получили название нормальных форм.
Первая нормальная форма (1NF):
запрещает повторяющиеся столбцы (содержащие одинаковую по смыслу информацию);
запрещает множественные столбцы (содержащие значения типа списка);
требует определить первичный ключ для таблицы, то есть тот столбец или комбинацию столбцов, которые однозначно определяют каждую строку.
Вторая нормальная форма (2NF) требует, чтобы неключевые столбцы таблиц зависели от первичного ключа в целом, но не от его части. Если таблица находится в первой нормальной форме и первичный ключ у нее состоит из одного столбца, то она находится и во второй нормальной форме.
Третья нормальная форма (3NF) требует, чтобы неключевые столбцы в таблице зависели только от первичного ключа. Самая распространённая ситуация – это расчётные столбцы, значения которых можно получить путём каких-либо манипуляций с другими столбцами таблицы. Для приведения таблицы в третью нормальную форму такие столбцы из таблиц необходимо удалять.
Нормальная форма Бойса-Кодда (BCNF) требует, чтобы в таблице был только один потенциальный первичный ключ. Чаще всего у таблиц, находящихся в третьей нормальной форме, так и бывает, но не всегда. Если обнаружился второй столбец (комбинация столбцов), позволяющий однозначно идентифицировать строку, то для приведения к нормальной форме Бойса-Кодда такие данные надо вынести в отдельную таблицу.
Четвёртая нормальная форма (4NF). Для приведения таблицы, находящейся в нормальной форме Бойса-Кодда, к четвёртой нормальной форме, необходимо устранить имеющиеся в ней многозначные зависимости. То есть обеспечить, чтобы вставка или удаление любой строки таблицы не требовала бы модификации других строк этой же таблицы.
Пятая нормальная форма (5NF) представляет собой форму таблицы, в которой устранены зависимости соединения. Данная форма в большей степени является теоретическим исследованием и практически не применяется при реальном проектировании баз данных. Это связано со сложностью определения самого наличия зависимостей «проекции – соединения», поскольку утверждение о наличии такой зависимости должно быть сделано для всех возможных состояний БД.
Шестая доменно-ключевая нормальная форма (DKNF) указывает на то, что если выполнять некоторые правила, то при любых действиях с таблицей ее целостность не пострадает и вся необходимая информация сохранится, т.е. нельзя просто удалить категорию из таблицы категорий, если с этой категорией связаны категории из других таблиц.
Нормализация БД позволяет устранить избыточность, дублирование данных, что ведет к сокращению вероятности появления противоречивых данных, облегчению администрирования и обновления информации в БД , сокращению объёма дискового пространства.
В реляционной модели БД явно выражены три основных вида взаимосвязей между атрибутами (полями) – «один к одному», «один ко многим», «много ко многим».
Таблицы находятся в отношении «один к одному», если каждая запись в первой таблице может иметь не более одной, связанной с ней, записи во второй таблице и наоборот, каждая запись во второй таблице может иметь не более одной связанной с ней записи в первой таблице. В этом случае, для связи используются ключевые поля связываемых таблиц.
Например, рассмотренные ранее таблицы «Заказчики» и «Данные о заказчиках» находятся в отношении «один к одному», т.е. между таблицами
установлена связь типа «один к одному» (см. рис. 7.14).
Рисунок 7.14 – Связь «один к одному» в таблицах реляционной БД
Этот тип связи используется достаточно редко, т.к. в этом случае данные двух таблиц могут быть объединены в одну таблицу. К причинам разбиения одной таблицы на несколько, связанных отношением «один к одному», можно отнести:
разделение очень «широкой» таблицы с целью повышения производительности (чтобы СУБД не обрабатывала большую таблицу там, где по большинству запросов надо вернуть всего несколько полей);
отделение части таблицы по соображениям защиты ее от несанкционированного доступа.
Таблицы находятся в отношении «один ко многим», если каждая запись одной таблицы может быть связана с несколькими записями другой таблицы, но каждая запись во второй таблице не может быть связана более чем с одной записью первой таблицы. В этом случае первая таблица называется главной таблицей, а вторая таблица – подчиненной.
В этом случае для связи используется поле, которое является первичным ключом таблицы, находящейся на стороне отношения «один», и являющееся внешним ключом в таблице, находящейся на стороне отношения «многие».
Например, рассмотренные таблицы «Договоры» и «Заказы изделий» находятся в отношении «один ко многим». При этом на стороне «один» находится таблица «Договоры», а на стороне «многие» – «Заказы изделий». Связь устанавливается по полю Код договора. Каждая запись таблицы «Договоры» может иметь много связанных с ней записей в таблице «Заказы изделий» (т.к. в данном случае по одному договору заказчикам поставляются несколько видов изделий), иначе говоря, в таблице «Заказы изделий» может быть много строк с заданным значением в поле Код договора (например, по различным кодам изделий). В то же время, если взять любую строку в таблице «Заказы изделий», то для нее найдется не более одной строки в таблице «Договоры» с таким же значением в поле Код договора (см. рис. 7.15).
Рисунок 7.15 – Связь «один ко многим» в таблицах реляционной БД
В отношении «один ко многим» находятся также таблицы «Заказчики» и «Договоры» (один заказчик может заключить несколько договоров, но каждый договор имеет только одного заказчика), таблицы «Заказы изделий» и «Изделия» (каждое изделие может содержаться во многих заказах, но каждая строка заказа содержит только одно изделие), таблицы «Заказы изделий» и «Поставки изделий» (заказ изделия может выполняться за несколько поставками, например, в случае, когда на складе на момент отгрузки нет необходимого количества изделий, но каждая поставка выполняется только по одной строке заказа).
Таблицы находятся в отношении «многие ко многим», если каждая запись первой таблицы может быть связана с несколькими записями во второй таблице, и наоборот, каждая запись второй таблицы может быть связана с несколькими записями в первой таблице.
Такая связь всегда реализуется с помощью третьей (связующей) таблицы. Например, в рассмотренной выше задаче для связи таблиц «Договоры» и «Изделия» сформирована таблица «Заказы изделий» (см. рис. 7.16).
Рисунок 7.16 – Связь «многие ко многим» в таблицах реляционной БД
Каждой записи в таблице «Договоры» могут соответствовать несколько записей в таблице «Изделия» (изделий различных кодов), и, наоборот, каждая запись таблицы «Изделия» может иметь более одной соответствующейей записи в таблице «Договоры» (изделие одного кода может поставляться по разным договорам). Соответствие устанавливается с помощью таблицы «Заказы изделий».
При этом если рассмотреть таблицы «Договоры» и «Заказы изделий», то между ними установлено отношение «один ко многим», в котором таблица «Договоры» является главной, а таблица «Заказы изделий» – подчиненной. Аналогично между таблицами «Изделия» и «Заказы изделий» установлена связь «один ко многим», в которой таблица «Изделия» является главной.
В рамках реляционной теории имеется список операций, которые можно осуществлять над таблицами, причем так, что результатом снова будет таблица (и, таким образом, в результате выполнения операции снова образуется реляционная БД). К таким операциям относятся базовые и производные.
Базовые операции:
ограничение – исключение из таблицы некоторых строк;
проекция – исключение из таблицы некоторых столбцов;
декартово произведение – из двух таблиц получается третья по принципу декартова произведения, когда результат содержит все атрибуты из таблиц-сомножителей (количество полей новой таблицы равно сумме количества полей в каждой из таблиц-сомножителей) и все возможные сочетания записей (количество записей в новой таблице равно произведению количества записей в таблицах-сомножителях). Например, умножив таблицу «Заказчики» на таблицу «Договоры» получим 6 полей и 9 записей. Потом оставляем только те записи, где код заказчика совпадает (3) и нужные нам поля. Таким способом получаем сведения о заказчиках для каждого договора;
объединение – объединение множеств строк двух таблиц;
разность – разность множеств строк двух таблиц;
присвоение, когда именованной таблице присваивается значение выражения, полученного за счет манипулирования над другими таблицами.
Производные операции:
операции соединения выполняются для соединения двух логически связанных таблиц, которые отличаются по структурам, но имеют некоторые одинаковые столбцы. В результате получается новая таблица, структура которой является совокупностью всех столбцов исходных таблиц;
пересечение представляет собой пересечение множеств строк двух таблиц;
деление позволяет отвечать на вопросы типа – какой элемент данных соответствует элементам определенного атрибута (столбца)? Например, какие заказчики приобретают изделие кода СТУ1432?
разбиение позволяет отвечать на вопросы типа – какие несколько элемен-
тов соответствуют элементам определенного атрибута (столбца)? Напри-
мер, какие три заказчика приобретают изделие кода СТУ1432?
расширение – добавление новых столбцов в таблицу;
суммирование выполняется в новой таблице с меньшим, чем в исходной, числом строк. Строки получаются как агрегирование (например, суммирование по какому-то столбцу) строк исходной таблицы.
Таким образом, помимо основных таблиц, изначально присутствующих в БД, приведенные операции позволяют получать новые (выводимые) таблицы-«представления», получаемые в результате применения операций.
Основной идеей использования реляционного подхода в организации БД, является предсказуемость результатов работы с данными, которая обеспечивается, использованием математического аппарата. Это объясняется тем, что корректная математическая модель, лежащая в основе модели данных, предполагает что любой запрос к базе данных, составленный на каком-нибудь формальном языке повлечет ответ, однозначно определенный схемой данных и конкретными данными. То же можно сказать не только о запросах, но и о манипулировании моделью с помощью перечисленных операций над таблицами.
Реляционные модели данных имеют значительные преимущества по сравнению с сетевой и иерархической моделями. К этим преимуществам можно отнести:
простота представления данных, благодаря табличной форме;
гибкость системы защиты – для каждой таблицы может быть задана правомерность доступа;
минимальная избыточность данных;
независимость приложений пользователя от данных, допускающая включение и удаление таблиц, изменение единиц информации;
универсальность процедур обработки данных.
Кроме того, в отличие от сетевых и иерархических, базы с реляционной моделью данных не требуют описания схемы данных, что в определенной степени облегчает их проектирование.
Однако, реляционная модель данных, несмотря на ее достоинства, имеет и определенные недостатки. Например, в ряде случаев она не позволяет четко отразить особенности предметной области. Это связано, прежде всего: с тем, что в реляционной модели отсутствуют прямые средства выражения иерархии и т.д. Поэтому постоянно ведутся поиски других моделей, которые также имеют свои сильные и слабые стороны. В соответствии со степенью распространенности других моделей можно коротко упомянуть о двух из них.
Объектно-ориентированная модель данных (ООМД) – это один из вариантов расширенной реляционной модели.
Разработка систем объектно-ориентированных баз данных началась в середине 80-х годов ХХ в., т.к. попытки использования технологий реляционных баз данных в таких сложных приложениях, как автоматизированное проектирование, автоматизированное производство, технология программирования, экспертные и мультимедийные системы показали ограниченность возможностей реляционных моделей баз данных. В этих условиях возникла потребность в объектно-ориентированных моделях БД, в которых при представлении данных имелась бы возможность более адекватно представлять и моделировать объекты предметной области, идентифицировать отдельные записи базы данных, а также устанавливать между записями и функциями их обработки взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования. Были выработаны различные концепции организации объектно-ориентированных моделей БД.
В 1991 г. был образован консорциум ODMG (тогда эта аббревиатура означала Object Database Management Group – группа управления объектными базами данных, но впоследствии приобрела более широкую трактовку – Object Data Management Group – группа управления объектными данными). Консорциум ODMG тесно связан с гораздо более многочисленным консорциумом OMG (Object Management Group – группа управления объектами), который был образован двумя годами раньше. Основной исходной целью ODMG была выработка промышленного стандарта объектно-ориентированных баз данных (общей модели). За основу была принята базовая объектная модель OMG COM (Core Object Model – объектная модель документа). В течение своего существования ODMG опубликовала несколько базовых версий стандарта объектно-ориентированных баз данных.
До сих пор не существует развитого математического аппарата, на который могла бы опираться общая ООМД. Многие специалисты объектно-ориентированного моделирования основным и главным отличием ООМД от реляционной модели считают наличие уникального системного идентификатора, отсутствующего в реляционной модели, где объект целиком описывается его атрибутами. Если, например, заказчик изделий в реляционной таблице представлен ФИО и номером телефона, то после замены номера телефона в существующей строке, реляционная БД не имеет средств представить отчет о том – тот же самый заказчик остался в базе данных или нет. В объектно-ориентированной модели ответ дает неизменившийся системный идентификатор. Кроме того, в объектно-ориентированной БД можно заменить одного заказчика (представителя фирмы) на другого, сохранив все связи и атрибуты прежнего, и при этом системный идентификатор не изменится, хотя подразумеваться будет совсем другой человек.
В целом объектно-ориентированная модель базируется на основных понятиях, схожих с понятиями объектно-ориентированных языков программирования (см. табл. 7.1).
Таблица 7.1 – Основные понятия объектно-ориентированной модели
Упрощенная модель объектно-ориентированной БД представляет собой дерево, узлами которого являются объекты. Каждый объект считается потомком объекта, в котором он определен как свойство. Объект принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов (см. рис. 7.17).
Рисунок 7.17 – Пример логической структуры объектно-ориентированной БД
склада предприятия-поставщика изделий
На рис. 7.17 объект типа Склад является родительским для объектов классов Заказчик, Поставка и Изделие. Различные объекты типа Материал могут иметь одного или разных родителей. Объекты типа Материал, имеющие одного и того же родителя, должны различаться, например, видом материала (уникален для каждого материала), но имеют одинаковые значения свойства – Отделка.
Логическая структура модели объектно-ориентированной БД внешне похожа на структуру модели иерархической БД. Основное различие между ними состоит в методах манипулирования данными.
Для выполнения действий над данными в рассматриваемой модели БД применяются логические операции, усиленные объектно-ориентированными механизмами инкапсуляции, наследования и полиморфизма.
Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Так, если в объект типа Изделие добавить свойство, задающее фурнитуру изделия, то в результате получаются одноименные свойства у объектов Заказчик и Изделие. Смысл такого свойства будет определяться тем объектом, в который оно инкапсулировано.
Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа Материал, являющимся потомками объекта типа Изделие, можно приписать свойства объекта-родителя: код, название, отделка и тип изделия. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств Кода и № поставки в объекте Склад приводит к наследованию этих свойств всеми дочерними объектами Заказчик, Поставка и Материал. Не случайно, поэтому значения свойства Кода заказчика классов Заказчик и Поставка являются одинаковыми – АО126.
Полиморфизм в объектно-ориентированных языках программирования означает способность одного и того же программного кода работать с разнотипными данными. Другими словами, он означает допустимость в объектах разных типов иметь методы (процедуры или функции) с одинаковыми именами. Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента. В примере на рис. 7.17 полиморфизм означает, что объекты класса Материал, имеющие разных родителей из класса Изделие, могут иметь разный набор свойств. Следовательно, программы работы с объектами класса Материал могут содержать полиморфный код.
Поиск в объектно-ориентированной БД состоит в выяснении сходства между объектом, задаваемым пользователем, и объектами, хранящимися в базе данных.
К достоинствам объектно-ориентированной модели обычно относят:
возможность для пользователя определять свои сложные типы данных;
возможность отображения информации о сложных взаимосвязях объектов;
возможность идентифицировать отдельные записи БД и определять функции их обработки;
наличие наследуемости свойств объектов;
повторное использование программного описания типов объектов при обращении к другим типам, на них ссылающимся.
К недостаткам объектно-ориентированной модели можно отнести:
отсутствие строгих определений – разное понимание терминов и различия в терминологии;
недостаточная исследованность и теоретическая проработка модели;
отсутствие общеупотребимых стандартов, позволяющих связывать конкретные объектно-ориентированные системы с другими системами работы с данными;
высокая понятийная сложность;
низкая скорость выполнения запросов.
Объектно-реляционная модель данных совмещает в себе реляционную модель с методами объектно-ориентированного подхода.
Для определения понятия объектно-реляционной модели используются различные термины. Сначала данную модель называли расширенной реляционной моделью данных, однако, в последние годы используется более информативный термин – объектно-реляционная модель, в которой содержится указание на использование понятия объект.
Объектно-реляционные модели данных используются в специализированных СУБД, разработкой которых занимаются три ведущих компании – Oracle, Informix и IBM, продвигая на рынок программных продуктов, несколько отличающиеся по своим функциональным возможностям, СУБД с объектно-реляционной моделью данных.
Основными преимуществами объектно-реляционной модели являются повторное и совместное использование компонентов реляционной и объектно-ориентированной моделей. При правильном проектировании с учетом новых возможностей подобный подход позволяет организациям воспользоваться достоинствами новых расширений эволюционным путем без утраты преимуществ, получаемых от использования компонентов и функций уже существующей базы данных.
К основным недостаткам объектно-реляционной модели являются:
сложность и связанные с ней повышенные расходы (простора и ясность, присущая реляционной модели, утрачивается при использовании подобных типов расширения);
сложность терминологии;
ограниченное количество приложений, на которые ориентирована объектно-реляционная модель данных;
сравнительно низкая производительность и т.д.
В период с 1989 по 1995 гг. авторские группы, включающие известных специалистов в области баз данных, подготовили и опубликовали три документа, которые отражали точки зрения авторов относительно перспектив развития технологии БД. С их легкой руки, начиная с первого, эти документы получили название манифестов, что, в общем то, отражало их суть: в каждом провозглашался набор идей и требований, на которых, по мнению авторов, должны были базироваться системы БД следующего поколения. Интересно отметить различия между коллективами авторов каждого из манифестов. «Манифест систем объектно-ориентированных баз данных» (Первым манифестом) написан академическими исследователями; почти все они являются профессорами различных университетов. Конечно, это нашло свое отражение в стиле первого манифеста – очень мягком и умеренно рекомендательном (хотя по своему духу предложения этого манифеста были весьма радикальными).
Авторы документа «Системы баз данных третьего поколения: Манифест» (Второго манифеста) являлись представителями индустриально-ориентированных исследований. Второй манифест написан в более жестком стиле и во многом направлен на защиту инвестиций крупных компаний-производителей программного обеспечения SQL-ориентированных СУБД. Конечно, Второй манифест во многом представлял собой реакцию индустрии на революционные предложения Первого манифеста. Эти предложения подвергались критике, которая заключалась в том, что, можно добиться аналогичных результатов, не производя революцию в области технологии БД, а эволюционно развивая технологию SQL-ориентированных СУБД. «Третий манифест» являлся одновременно наиболее консервативным и наиболее радикальным. Консервативность Третьего манифеста заключается в том, что его авторы всеми силами утверждают необходимость и достаточность использования в системах БД следующего поколения классической реляционной модели данных. Радикальность состоит в том, что (a) авторы полностью отрицают подходы, предлагаемые в первых двух манифестах, расценивая их как необоснованные, плохо проработанные, избыточные и даже вредные. Фактически, авторы полностью отбрасывают технологию, созданную индустрией баз данных за последние 25 лет, и предлагают вернуться к истокам реляционной модели данных, т.е. к начальным статьям Э. Кодда, который в 1980 году за свою реляционную модель данных получил премию Тьюринга.
Прошло более 15 лет, и, тем не менее, исследования в области объектно-ориентированного подхода продолжаются. На рынке программных продуктов появляются новые разработки, отвечающие современным требованиям организации баз данных.
Модель данных «объектов-ролей» является моделью данных, имеющей конкретную программную реализацию – InfoModeller. Модель «объектов-ролей» была предложена еще в начале 70-х годов и в настоящее время реализуется фирмой Asymetrix. В отличие от реляционной модели в ней нет атрибутов, а основные понятия – это объекты и роли, описывающие их. Роли могут быть как «изолированные», присущие исключительно какому-нибудь объекту, так и существующие как элемент какого-либо отношения между объектами. Модель «объектов-ролей» отличается от реляционной следующими особенностями:
модель служит для понятийного моделирования;
для модели кроме графического языка разработан также естественный язык, не допускающий разночтений. Кроме того, пользователь не только использует естественный язык, но и видит представленный на том же языке результат его работы по формализации задачи.
Модели «объектов-ролей» сейчас уделяется большое внимание специалистов, однако, до промышленных масштабов ее использования еще достаточно далеко.
Многомерная модель данных. В развитии концепций баз данных можно выделить следующие два направления:
системы оперативной (транзакционной) обработки (OLTP-приложения);
системы аналитической обработки (OLAP-приложения).
Реляционные СУБД предназначались для информационных систем оперативной обработки информации и в этой области весьма эффективны. В системах аналитической обработки они показали себя несколько неповоротливыми и недостаточно гибкими. Более эффективными здесь оказываются многомерные модели, которые являются узкоспециализированными моделями, ориентированными на интерактивную аналитическую обработку информации.
Многомерные модели рассматривают данные как кубы, которые являются обобщением таблиц на любое число измерений. Кроме того, кубы поддерживают иерархию измерений и формул без дублирования их определений. Набор соответствующих кубов составляет многомерную базу данных (хранилище данных). Кубами легко управлять, добавляя новые значения измерений. Теоретически куб может иметь любое число измерений. На практике чаще всего кубы данных имеют 4–12 измерений, т.к. при их большем числе современный инструментарий часто сталкивается с нехваткой производительности (особенно свыше 10–15 измерений).
Многомерный подход к представлению данных появился практически одновременно с реляционным, однако, интерес к многомерным СУБД стал приобретать массовый характер с середины 90-х годов ХХ в. Толчком послужила статья Э. Кодда, выпущенная в 1993 г. В ней были сформулированы 12 основных требований к системам класса OLAP, важнейшие из которых связаны с возможностями концептуального представления и обработки многомерных данных (См. «Инструментальные средства построения проблемно-ориентированного прикладного программного обеспечения»):
1. Многомерное представление данных. Средства должны поддерживать многомерный на концептуальном уровне взгляд на данные.
2. Прозрачность. Пользователь не должен знать о том, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда они берутся.
3. Доступность. Средства должны сами выбирать и связываться с наилучшим для формирования ответа на данный запрос источником данных. Средства должны обеспечивать автоматическое отображение их собственной логической схемы в различные гетерогенные источники данных.
4. Согласованная производительность. Производительность практически не должна зависеть от количества Измерений в запросе.
5. Поддержка архитектуры «клиент-сервер». Средства должны работать в архитектуре клиент-сервер.
6. Равноправность всех измерений. Ни одно из измерений не должно быть базовым, все они должны быть равноправными (симметричными).
7. Динамическая обработка разреженных матриц. Неопределенные значения должны храниться и обрабатываться наиболее эффективно.
8. Поддержка многопользовательского режима работы с данными. Средства должны обеспечивать возможность работать более, чем одному пользователю.
9. Поддержка операций на основе различных измерений. Все многомерные операции (например, Агрегация) должны единообразно и согласованно применяться к любому числу любых измерений.
10. Простота манипулирования данными. Средства должны иметь максимально удобный и комфортный пользовательский интерфейс.
11. Развитые средства представления данных. Средства должны поддерживать различные способы визуализации (представления) данных.
12. Неограниченное число измерений и уровней агрегации данных. Не должно быть ограничений на число поддерживаемых Измерений.
Э. Кодд произвел анализ некоторых как субъективных, так и вполне объективных недостатков реляционного подхода, затрудняющих его использование в задачах, требующих сложной аналитической обработки данных.
К основным понятиям, используемым в многомерных моделях относятся – агрегируемость, историчность и прогнозируемость.
Агрегируемость данных означает рассмотрение информации на различных уровнях ее обобщения. В информационных технологиях степень детализации представления информации для пользователя зависит от его уровня: аналитик, пользователь, управляющий, руководитель.
Историчность данных предполагает обеспечение высокого уровня статичности данных и их взаимосвязей, а также обязательность привязки данных ко времени.
Прогнозируемость данных подразумевает задание функций прогнозирования и применение их к различным временным интервалам.
Многомерность модели данных означает не многомерность визуализации цифровых данных, а многомерное логическое представление структуры информации при описании и в операциях манипулирования данными.
К основным элементам структуры данных многомерных моделей относятся:
• Измерение (Dimension) – множество однотипных данных, образующих одну из граней гиперкуба. В многомерной модели измерения играют роль индексов, служащих для идентификации конкретных значений в ячейках гиперкуба. Например, дни, месяцы, годы – это наиболее часто используемые в анализе временные Измерения. К примерам географических измерений можно отнести: города, районы, регионы, страны и т.д.
• Ячейка (Cell) – поле, значение которого однозначно определяется фиксированным набором измерений (Иногда вместо термина «Ячейка» используется термин «Показатель» (Measure)). Тип поля чаще всего определен как цифровой. В зависимости от того, как формируются значения некоторой ячейки, она может быть переменной (значения изменяются и могут быть загружены из внешнего источника данных или сформированы программно) либо формулой (значения, подобно формульным ячейкам электронных таблиц, вычисляются по заранее заданным формулам). Причем, это различие существует только на этапе проектирования и полностью скрыто от конечных пользователей.
• Метки (members) – значения, откладываемые вдоль измерений. Метки используются как для «разрезания» куба, так и для ограничения (фильтрации) выбираемых данных – когда в измерении, остающемся «неразрезанным», выбираются не все значения, а их подмножество, например три заказчика из нескольких десятков. Значения меток отображаются в двумерном представлении куба как заголовки строк и столбцов.
• Иерархии и уровни. Метки могут объединяться в иерархии, состоящие из одного или нескольких уровней (levels). Например, метки измерения Заказчик объединяются в иерархию с уровнями: Код заказчика – ФИО – адрес – телефон.
Комбинации значений измерений определяют ячейки куба. В зависимости от приложения, ячейки в кубе могут располагаться как разрозненно, так и плотно. Кубы, как правило, становятся разрозненными по мере увеличения числа размерностей и степени детализации значений измерений.
По сравнению с реляционной моделью многомерная организация данных обладает более высокой наглядностью и информативностью. Например, на рис. 7.18 приведены реляционное (а) и многомерное (б) представления одних и тех же данных об объемах поставок заказчикам.
Рисунок 7.18 – Примеры реляционной и многомерной БД по объему поставок
В случае, если количество заказчиков и временных периодов гораздо больше, при реляционном представлении данных отчет по объемам поставок изделий будет представлен на нескольких страницах, в то время, как использование многомерной модели позволяет получить компактную таблицу, помещающуюся на одной странице. Такое представление информации имеет четкую визуализацию, что удобно для дальнейшей оценки и анализа.
В соответствии с уровнями иерархии вычисляются агрегатные значения, например, объем поставок для заказчика или в определенный город. В одном измерении можно реализовать более одной иерархии – например, для времени: год, месяц, день и год, неделя, день.
В примере на рис. 7.18 (б) каждое значение ячейки Объем поставок однозначно определяется комбинацией временного измерения Месяц и Заказчик (на практике зачастую требуется большее количество измерений). Пример трехмерной модели данных приведен на рис. 7.19. Следует отметить, что, в отличие от Измерений, не все значения Показателей должны иметь и имеют реальные значения. Например, Заказчики Кузнецов А.М. и Карпов И.В. в апреле и соответственно в марте не делали заказ, и в этом случае все значения Показателя Объем поставок за эти периоды у них будут иметь неопределенные значения.
Рисунок 7.19 – Пример трехмерной модели данных
В общем случае куб позволяет представить только два или три измерения одновременно, но можно показывать и больше за счет вложения одного измерения в другое. Таким образом, путем проецирования куба на двух- или трехмерное пространство можно уменьшить размерность куба, агрегировав некоторые размерности, что ведет к работе с более комплексными значениями параметров. Например, рассматривая проставки по Заказчикам и Месяцам, можно агрегировать информацию для каждого сочетания Заказчик и Месяц. Так, на рис. 7.19, при сложении полей 70 и 30, получится общий объем поставок за март месяц.
В многомерных моделях используются две основных схемы организации данных – гиперкубическая и поликубическая.
Поликубическая схема ориентирована на то, что БД может быть определено несколько гиперкубов с различной размерностью и с различными измерениями в качестве граней.
Гиперкубическая схема предполагается, что все ячейки определяются одним и тем же набором измерений. Это означает, что при наличии нескольких гиперкубов в БД, все они имеют одинаковую размерность и совпадающие измерения.
В многомерных данных широко используются различные процедуры манипулирования Измерениями. К таким операциям относятся – формирование «среза», «вращение», отношения и иерархические отношения, агрегация и детализация.
Формирование «среза». Для визуализации данных, хранящихся в кубе, применяются, как правило, привычные двумерные табличные представления, имеющие иерархические заголовки строк и столбцов. Такое представление куба можно получить, «разрезав» его поперек одной или нескольких осей (измерений). При этом необходимо зафиксировать значения всех измерений, кроме двух, что позволяет получить двумерную таблицу. В горизонтальной оси таблицы (заголовки столбцов) представлено одно измерение, в вертикальной (заголовки строк) – другое, а в ячейках таблицы – значения мер. При этом набор мер фактически рассматривается как одно из измерений – выбирается для показа одной меры (и тогда можно разместить в заголовках строк и столбцов два измерения), или выбирается несколько мер (и тогда одну из осей таблицы займут названия мер, а другую – значения единственного «неразрезанного» измерения) (см. рис. 7.20).
Рисунок 7.20 – Срезы куба для различного количества мер
На рис. 7.20 (а) изображен двумерный срез куба для одной меры – Объема поставок изделий и двух неразрезанных измерений – Заказчики и Месяц поставки.
На рис. 7.20 (б) представлено лишь одно «неразрезанное» измерение – Заказчик, но зато здесь отображаются значения нескольких мер – Объем поставок, Месяц поставки и Объем партии поставляемых изделий.
Двумерное представление куба возможно и тогда, когда «неразрезанными» остаются и более двух измерений. При этом на осях среза (строках и столбцах) будут размещены два или более измерений «разрезаемого» куба – см. рис. 7.20 (в).
Операция «Вращение» (Rotate) представляет собой изменение порядка представления (визуализации) Измерений. «Вращение» обычно применяется при двухмерном представлении данных и обеспечивает возможность визуализации данных в форме, наиболее комфортной для их восприятия. Например, если менеджер первоначально вывел отчет, в котором Заказчики изделий были перечислены по оси X, а Объемы поставок по оси Y, он может решить, что такое представление мало наглядно, и поменять местами координаты (выполнить Вращение на 900).
Отношения и Иерархические отношения. В примере, приведенном на рис. 7.20 значения Показателей определяются только тремя измерениями. На самом деле их может быть гораздо больше и между их значениями обычно существуют множество различных Отношений (взаимосвязей) типа «один ко многим». Например, у каждого предприятия имеется нескольких заказчиков, расположенных в разных городах России, а каждое Изделие может входить в комплект мебельного гарнитура, например, Заказчик → Город; Изделие → Гарнитур.
Следует отметить, что для Измерений, имеющих тип Время (таких как День, Месяц, Квартал, Год), все Отношения устанавливаются автоматически, и их не требуется описывать.
В свою очередь, множество Отношений может иметь иерархическую структуру – Иерархические отношения (Hierarchical Relationships), например, по времени – День → Месяц → Квартал → Год. Заказчики также могут быть представителями различных филиалов предприятия. В этом случае Иерархические отношения будут выстраиваться следующим образом – Заказчик → Филиал → Регион → Предприятие.
Более удобно не объявлять новые Измерения и затем устанавливать между ними множество Отношений, а использовать механизм Иерархических Отношений. В этом случае все потенциально возможные значения из различных Измерений объединяются в одно множество. Например, можно добавить к множеству значений Измерения Заказчик (Кузнецов А.М., Попов Т.Д., Карпов И.В.), значения Измерения Филиал (Филиал 1, Филиал 2, Филиал 3) и Измерения Города (Москва, Архангельск) и затем определить между этими значениями Отношение Иерархии. Например:
Город → Москва
Город → Архангельск
Филиал 1 → Москва
Филиал 2 → Москва
Филиал 3 → Архангельск
Кузнецов А.М. → Филиал 1
Попов Т.Д. → Филиал 2
Карпов И.В. → Филиал 3
Операция Агрегации (Drill Up). С точки зрения пользователя, Филиал, Город являются точно такими же Измерениями, как и Заказчик, но каждое из них соответствует новому, более высокому уровню агрегации значений Показателя Объем поставок. В процессе анализа пользователь не только работает с различными Срезами данных и выполняет их Вращение, но и переходит от детализированных данных к агрегированным, т.е. производит операцию Агрегации. Например, посмотрев, какой объем поставок получил Заказчик Попов Т.Д. в марте текущего года по столам кухонным и ученическим, менеджер по продажам предприятия-поставщика может узнать, как выглядит соотношение заказов этих изделий на уровне филиала, от имени которого Попов Т.Д. оформляет заказы. А затем получить аналогичную справку по предприятию-потребителю или по городу, куда поставляются изделия.
Операция Детализации (Drill Down) представляет собой переход от более агрегированных к более детализированным данным. Например, начав анализ на уровне Города, менеджер по продажам может получить более точную информацию о заказах конкретного предприятия-потребителя или заказчика.
Основным достоинством многомерной модели данных является удобство и эффективность аналитической обработки больших объемов данных.
Недостатком многомерной модели является ее громоздкость для простейших задач обычной оперативной обработки информации.