Схема работы с разделом 3
Раздел 3. Модели и типы данных в БД
Третий раздел курса включает две темы: “Представление концептуальной модели средствами СУБД”, и “Типовые модели данных СУБД”. После изучения каждой темы Вам следует ответить на вопросы для самопроверки.
Работа с разделом 2 завершается сдачей контрольного теста.
Для того, чтобы Вы смогли успешно ответить на вопросы контрольного теста, Вам предоставляется возможность поработать с репетиционным тестом. Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главе 5 учебника [1] или к учебному пособию [7].
3.1. Представление концептуальной модели средствами СУБД
При изучении данной темы Вы должны рассмотреть концепцию моделей БД и методы, используемые при проектировании моделей баз данных различных уровней поддерживаемых СУБД.
Для проверки изучения материала темы Вам предстоит ответить на вопросы для самопроверки.
При затруднениях в ответе на какой-либо вопрос следует обратиться к главе 14 учебника [1] или к материалам учебного пособия [9].
3.1.1. Общие представления о моделях данных СУБД
В соответствии с рис.2.6 после построения ILM выбирается СУБД, с помощью которой будет организована база данных и работа с ней. Каждая СУБД поддерживает определенные виды и типы данных, а также средства представления связей между данными, составляющими модель данных СУБД.
Вторая стадия – это отображение ILM в концептуальную модель данных целевой СУБД. Этот этап часто называют логическим проектированием базы данных или построением схемы модели. Под схемой базы данных будем понимать ее описание средствами языка определения данных.
Модель данных – это способ структурирования и формализации данных прикладной области для возможности их обработки.
Объекты, которыми оперирует модель, представляют собой сущности ILM. Сущности находятся во взаимосвязи друг к другу. Модель, таким образом, представляет собой совокупность элементов: объектов и связей и атрибутов их раскрывающих. Указанные элементы имеют содержательную (смысловую) интерпретацию только в ILM.
Связи (их иногда называют ассоциациями, отношениями, структурными связями) характеризуются кардинальными числами, и подразделяют на: один к одному (1:1), один ко многим (1:M), многие ко многим (M:N) (рис.3.1).
Рис. 3.1. Пример объектов и атрибутов их составляющих, с ассоциациями между ними
Каждый атрибут описывается как поле с типом (типы данных - numeric, char, date и т.д. Понятие тип данных в модели данных полностью адекватно понятию типа данных в языках программирования.) и характеристиками, возможными в выбранной СУБД.
В дальнейшем нам потребуются следующие термины:
-
Элемент данных (поле) – наименьшая поименованная единица данных. Используется для представления значения атрибута.
-
Запись – поименованная совокупность полей. Используется для представления совокупности атрибутов сущности (записи о сущности).
-
Экземпляр записи – запись с конкретными значениями полей.
-
Первичный ключ – минимальный набор полей записи, однозначно идентифицирующих экземпляр записи файла (таблицы, отношения).
-
Файл – поименованная совокупность экземпляров записей одного типа на внешнем устройстве. Используется для представления однородного набора сущностей.
-
Группа – это поименованная совокупность элементов данных и других групп, обобщающая понятия "файл" и "запись".
-
Групповое отношение – поименованное бинарное отношение, заданное на двух множествах экземпляров рассматриваемых групп. По характеру бинарных связей различают групповые отношения вида 1:1, 1:M, M:1, M:N. В групповом отношении один член группы назначается владельцем отношения, другой – членом. Групповое отношение - иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения) называется исходной записью, а дочерние записи (члены группового отношения) - подчиненными.
-
Ограничения целостности концептуальной модели. Используются для реализации как структурных ограничений концептуальной модели, так и внутренних ограничений модели данных.
-
В качестве основных элементарных операций обычно рассматриваются следующие: поиск записи с заданным значением ключа, чтение нужной записи, добавление записи, корректировка, удаление.
Обычно рассматриваются три основных модели представления данных, которые отличаются ограничениями, накладываемыми на представление данных и виды связей. Это, в порядке хронологии появления, иерархическая, сетевая и реляционная модели. В настоящее время развивается и другие типы моделей.
3.1.2. Классификация моделей данных
Одними из основополагающих в концепции баз данных являются обобщенные категории "данные" и "модель данных".
Понятие "данные" в концепции баз данных — это набор конкретных значений, характеризующих объект, условие, ситуацию или любые другие факты, пригодные для переработки в некотором процессе. Информация – это смысл, который придается данным при их представлении.
Примеры данных: Иванов Иван Иванович, $7 и т. д. Данные не обладают структурой, данные становятся информацией тогда, когда пользователь задает им определенную структуру, то есть осознает их смысловое содержание. Поэтому центральным понятием в области баз данных является понятие модели.
Модель данных - это некоторая абстракция, которая, будучи приложима к конкретным данным, позволяет пользователям и разработчикам трактовать их уже как информацию, то есть сведения, содержащие не только данные, но и взаимосвязь между ними.
На рис.3.2 представлена классификация моделей данных.
В соответствии с рассмотренной ранее трехуровневой архитектурой мы сталкиваемся с понятием модели данных по отношению к каждому уровню. И действительно, физическая модель данных оперирует категориями, касающимися организации внешней памяти и структур хранения, используемых в данной ОС. В качестве физических моделей используются различные методы размещения данных, основанные на файловых структурах: это организация файлов прямого и последовательного доступа, индексных файлов и инвертированных файлов, файлов, использующих различные методы хэширования, взаимосвязанных файлов. Кроме того, современные СУБД широко используют страничную организацию данных.
Кроме трех рассмотренных уровней абстракции при проектировании БД существует еще один уровень, предшествующий им. Модели этого уровня называются инфологическими, или семантическими, и отражают в естественной форме информационно-логический уровень абстрагирования, связанный с фиксацией и описанием объектов предметной области, их свойств и их взаимосвязей.
Рис. 3.2. Классификация моделей данных
Инфологические модели данных используются на ранних стадиях проектирования для описания структур данных в процессе разработки приложения, а даталогические модели уже поддерживаются конкретной СУБД.
Документальные модели данных соответствуют представлению о слабоструктурированной информации, ориентированной в основном на свободные форматы документов, текстов на естественном языке.
Модели, основанные на языках разметки документов, связаны прежде всего со стандартным общим языком разметки — SGML (Standart Generalised Markup Language), который был утвержден ISO в качестве стандарта еще в 80-х годах.
Этот язык предназначен для создания других языков разметки, он определяет допустимый набор тегов (ссылок), их атрибуты и внутреннюю структуру документа. Контроль за правильностью использования тегов осуществляется при помощи специального набора правил, называемых DTD-описаниями, которые используются программой клиента при разборе документа. Для каждого класса документов определяется свой набор правил, описывающих грамматику соответствующего языка разметки в некотором стандартизованном формате. Одним из клонов SGML являются языки HTML и XML (Extensible Markup Language), которые в настоящее время является основным механизмом представления информации в Интернете.
Язык HTML позволяет определять оформление элементов документа и имеет некий ограниченный набор инструкций — тегов, при помощи которых осуществляется процесс разметки. Инструкции HTML в первую очередь предназначены для управления процессом вывода содержимого документа на экране программы-клиента и определяют этим самым способ представления документа, но не его структуру.
В качестве элемента гипертекстовой базы данных, описываемой HTML, используется текстовый файл, который может легко передаваться по сети с использованием протокола HTTP.
Тезаурусные модели основаны на принципе организации словарей, содержат определенные языковые конструкции и принципы их взаимодействия в заданной грамматике.
Дескрипторные модели — сопоставляют каждому документу дескриптор — описатель. Этот дескриптор описывает документ (например, патент) в соответствии с теми характеристиками, которые требуются для работы с документами в разрабатываемой документальной БД.
Как уже упоминалось ранее, эти модели отражают совокупность объектов реального мира в виде графа взаимосвязанных информационных объектов. В зависимости от типа графа выделяют иерархическую или сетевую модели. Исторически эти модели появились раньше, и в настоящий момент они используются реже, чем реляционная модель данных.
Вопросы для самопроверки по теме 3.1
1. Дайте определение модели данных БД
2. Назовите и раскройте суть основных компонентов модели данных.
3. Зачем нужна ILM и чем она отличается от концептуальной модели?
4. Перечислите основные типы моделей данных?
5. Что такое данные и тип данных?
6. Поясните, что Вы понимаете под информацией в БД?
7. Что такое гипертекстоваая БД и в каком формате она представлена?
3.2. Типовые модели данных СУБД
При изучении данной темы Вы должны рассмотреть концепции классических моделей БД их структуру и используемые в них операции.
Для проверки изучения материала темы Вам предстоит ответить на вопросы для самопроверки.
Если Вы испытываете затруднения в ответе на какой-либо вопрос, обратитесь к главе 4 учебника [4].
3.2.1. Иерархическая и сетевая модель данных
Иерархическая модель данных является наиболее простой среди всех моделей. Исторически она появилась первой среди всех моделей: именно эту модель поддерживает первая из зарегистрированных промышленных СУБД IMS фирмы IBM (1969 г).
Появление иерархической модели связано с тем, что в реальном мире очень многие связи соответствуют иерархии, когда один объект выступает как родительский, а с ним может быть связано множество подчиненных объектов. Иерархия проста и естественна в отображении взаимосвязи между классами объектов.
Иерархическая модель имеет дело с древовидными структурами, в которых объекты модели представлены узлами дерева и называются сегментами.
Рис. 3.3. Иерархическая модель данных
В модели 1 возникает избыточность, если хирург оперирует более одного пациента. Кроме того, возникают нежелательные явления, возникающие при работе с базой данных, которые называют аномалией.
Аномалия включения: В БД (модель 1) невозможно включить не оперировавшего хирурга.
Аномалия удаления: так как при удалении узла исключаются и все его подузлы, то при удалении хирурга из БД (модель 2) исчезают все его пациенты.
Иерархическая модель обладает следующими свойствами.
-
Существует корень. В базе столько деревьев, сколько объектов в ILM.
-
Узел содержит атрибуты.
-
Исходный и зависимый узлы находятся в отношении «непосредственный предок и потомок». Узлы добавляются горизонтально и вертикально.
-
Потомок соединен единственной связью с предком.
-
Предок может иметь несколько потомков.
-
Доступ к данным производится через предка.
-
Может существовать множество экземпляров узла.
-
При удалении узла удаляется все его поддерево.
Основной недостаток – невозможность реализации отношения «многие к многим» в рамках одной базы данных.
В сетевой модели отношение записей представляет собой граф, не имеющий циклов. Иерархическая модель может быть представлена как частный случай сетевой.
Сетевая модель основана на рекомендациях рабочей группы по базам данных КОДАСИЛ (CODASYL) (1969-1978 гг.).
Согласно рекомендациям, база данных делится на области, те – на записи, состоящие из полей. С другой стороны, база состоит из наборов, а те – из записей (рис. 3.4).
Связь «пациент-операция» означает «пациент перенес операцию», «хирург-операция» – «хирург выполнил операцию».
Отношение «пациент-хирург» – это отношение M:N, и для его реализации вводится добавочный связующий файл. При этом объекты пациент и хирург объявляются владельцами набора, а операция – членом набора. Наборы-владельцы (ключевые наборы - хэш таблицы), как и наборы-члены (детальные наборы) реализованы в виде отдельных файлов, структура которых различна.
Рис. 3.4. Сетевая модель данных
Достоинства
-
Реализуется отношение "многие к многим".
-
Высокая производительность.
Недостатки
-
Основной недостаток сетевой модели – трудность реорганизации базы данных, то есть изменения ее структуры. Обычно реорганизация требует выгрузки данных с последующей их загрузкой в БД с новой структурой. При этом важно не только не потерять данные, но и корректно определить ссылки, в противном случае часть информации будет недоступной.
Для организации физического размещения сетевых и иерархических данных в памяти ЭВМ могут использоваться следующие группы методов:
-
представление линейным списком с последовательным распределением памяти;
-
представление связными линейными списками (методы, использующие указатели и справочники).
Геометрически сетевая модель изоморфна графу, каждая связанная компонента которого отражает определенный тип набора, а вершинам графа соответствуют типы записей.
Иерархическая модель геометрически изоморфна дереву, и является частным случаем сетевой модели.
3.2.2. Реляционная и постреляционная модель данных
Реляционная модель (как и любая рассмотренная выше и ниже) предназначена для отображения ILM в концептуальную модель СУБД. Если реализация СУБД позволяет четко разграничить логические и физические аспекты доступа и управления БД, использует алгебраическую систему (<�носитель, множество операций>) как основы концептуальной схемы, то ее принято относить к СУБД реляционного типа.
Для сетевой и иерархической модели носителем является набор и сегмент соответственно.
В качестве носителя (структурной единицы) в реляционной модели выбрано отношение (relation) n-го порядка: при соответствующих операторах (реализованных в SQL или QBE) и концептуальном представлении в виде таблиц оно позволяет приблизиться к реализации принципа независимости данных.
Отношение n-го порядка – математическое множество, в котором порядок строк не имеет значения. Заметим, что понятие реляционная БД несколько шире, чем табличная: во втором случае предполагается, что к строке можно добраться по номеру, следовательно, порядок строк имеет значение. Традиционно позиционирование данных определялось адресами в памяти, в реляционной модели адресный способ выбора данных заменен ассоциативным. Каждая единица информации в реляционных БД ассоциируется с уникальной тройкой: именем отношения, значением ключа, именем атрибута (рис.3.5). При таком подходе закладывается непроцедурный путь доступа к данным.
Напомним, что модель данных – это не только структура, это комбинация, по крайней мере, трех составляющих:
-
типов структур данных,
-
операций (правил вывода), применимых к структурным типам данных,
-
правил целостности, которые определяют множество непротиворечивых состояний БД и множество изменений ее состояний.
Структурная часть реляционной модели состоит из следующих компонент:
-
доменов – совокупности однотипных значений данных, которые совместимы в семантическом плане;
-
отношений n-го порядка, концептуально представленных таблицами;
-
атрибутов – атомарных данных, определяющих столбцы таблицы, т.е. среди значений домена не могут содержаться множества (отношения);
-
кортежей – строк таблицы,
-
потенциальных (возможных) ключей – атрибутов, однозначно определяющих кортеж в отношении;
-
первичных ключей – для отношения это один из возможных ключей.
Для каждого отношения, по крайней мере, полный набор его атрибутов является первичным ключом.
Атрибуты, представляющие собой копии ключей других отношений, называются внешними ключами.
Достоинства.
-
простота и доступность для понимания;
-
объекты и связи представляются единым образом в виде отношений (плоских таблиц);
-
встроенная оптимизация реализации алгоритмов поиска данных;
-
наличие формального аппарата конструирования концептуальной модели и способов поиска данных (реляционная алгебра и реляционное исчисление).
Рис. 3.5. Таблица СОТРУДНИК
Отметим, что набор отношений составляющих схему реляционной модели должен быть нормализован (см. следующий раздел).
Реляционная модель с геометрической точки зрения также соответствует графу, вершинами которого являются хранимые отношения, а ребра графа ассоциированы с ключами хранимых отношений.
Постреляционная модель данных представляет собой расширенную реляционную модель, в которой отменено требование атомарности атрибутов.
Достоинством постреляционной модели является возможность представления совокупности связанных реляционных таблиц одной постреляционной таблицей. Это обеспечивает высокую наглядность представления информации и повышение эффективности ее обработки.
Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных.
Существует несколько коммерческих постреляционных СУБД, самыми известными из которых являются системы Adabas, ORD и Universe.
3.2.3. Многомерная модель данных
В развитии концепций ИС можно выделить следующие два направления:
-
системы транзакционной (оперативной) обработки (OLTP - On-Line Transaction Processing. Ежедневные операции: покупки, заказы, производство, регистрация и т.п.);
-
системы аналитической обработки (системы поддержки принятия решений) OLAP - On-Line Analytical Processing.
Реляционные модели, рассмотренные ранее, предназначались для информационных систем оперативной обработки информации.
В основе концепции OLAP - лежит многомерное представление данных. Термин OLAP ввел Кодд (E. F. Codd) в 1993 году. В своей статье он рассмотрел недостатки реляционной модели, в первую очередь невозможность "объединять, просматривать и анализировать данные с точки зрения множественности измерений, то есть самым понятным для корпоративных аналитиков способом", и определил общие требования к системам OLAP, расширяющим функциональность реляционных СУБД и включающим многомерный анализ как одну из своих характеристик.
"Сервер OLAP" — не определяют физического механизма хранения данных.
Хотя часто в публикациях аббревиатурой OLAP обозначается не только многомерный взгляд на данные, но и хранение самих данных в многомерной БД.
Многомерное концептуальное представление является наиболее естественным взглядом управляющего персонала на объект управления. Оно представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям данных определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению.
Многомерные СУБД (МБД) являются узкоспециализированными СУБД, предназначенными для интерактивной аналитической обработки информации.
Раскроем основные понятия, используемые в этих СУБД: агрегируемость, историчность и прогнозируемость данных.
Агрегируемость данных означает рассмотрение информации на различных уровнях ее обобщения. В ИС степень детальности представления информации для пользователя зависит от его уровня: аналитик, руководитель,оператор.
Историчность данных предполагает обеспечение высокого уровня статичности (неизменности) собственно данных и их взаимосвязей, а также обязательность привязки данных ко времени.
Статичность данных позволяет использовать при их обработке специализированные методы загрузки, хранения, индексации и выборки.
Временная привязка данных необходима для частого выполнения запросов, имеющих значения времени и даты в составе выборки. Необходимость упорядочения данных по времени в процессе обработки и представления данных пользователю, накладывает требования на механизмы хранения и доступа к информации. Так, для уменьшения времени обработки запросов желательно, чтобы данные всегда были отсортированы в том порядке, в котором они наиболее часто запрашиваются.
Прогнозируемость данных подразумевает задание функций прогнозирования и применение их к различным временным интервалам.
Многомерность модели данных обеспечивают многомерное логическое представление структуры информации при ее описании и в операциях манипулирования данными.
Рис. 3.6. Многомерная модель. Вариант агрегации данных по Avg (среднее)
По сравнению с реляционной моделью многомерная организация данных обладает более высокой наглядностью и информативностью. Для иллюстрации на рис. 3.7 приведено реляционное представления одних и тех же данных агрегированных в многомерной модели рис. 3.6.
Если речь идет о многомерной модели с размерностью больше двух, то не обязательно визуально информация представляется в виде многомерных объектов (трех-, четырех- и более мерных гиперкубов). Пользователю и в этих случаях более удобно иметь дело с двухмерными таблицами или графиками. Данные при этом представляют собой «вырезки» (точнее, «срезы») из многомерного хранилища данных, выполненные с разной степенью детализации.
Рассмотрим основные понятия многомерных моделей данных, к числу которых относятся измерение и ячейка.
Измерение (Dimension) – это множество однотипных данных, образующих одну из граней гиперкуба. Примерами наиболее часто используемых временных измерений являются Дни, Месяцы, Кварталы и Годы. В качестве географических измерений широко употребляются Города, Районы, регионы и Страны. В многомерной модели данных измерения играют роль индексов, служащих для идентификации конкретных значений в ячейках гиперкуба.
Ячейка (Cell) или показатель – это поле, значение которого однозначно определяется фиксированным набором измерений. Тип поля чаще всего определен как цифровой. В зависимости от того, как формируются значения некоторой ячейки, обычно она может быть переменной (значения изменяются и могут быть загружены из внешнего источника данных или сформированы программно) либо формулой (значения, подобно формульным ячейкам электронных таблиц, вычисляются по заранее заданным формулам).
Рис. 3.7. Реляционная модель и многомерная модель.
В существующих МБД используются два основных варианта (схемы) организации данных: гиперкубическая и поликубическая.
В поликубической схеме предполагается, что в БД может быть определено несколько гиперкубов с различной размерностью и с различными измерениями в качестве граней. Примером системы, поддерживающей поликубический вариант БД, является сервер Oracle Express Server.
В случае гиперкубической схемы предполагается, что все показатели определяются одним и тем же набором измерений. Это означает, что при наличии нескольких гиперкубов БД все они имеют одинаковую размерность и совпадающие измерения. Очевидно, в некоторых случаях информация в БД может быть избыточной (если требовать обязательное заполнение ячеек).
В случае многомерной модели данных применяется ряд специальных операций: формирование «среза», «вращение», агрегация и детализация.
Roll up: агрерация данных: по иерархии(-ям) до полного исключения измерения.
Drill down: детализация: от обощенных данных к более детальным, от верхних уровней измерений – к нижним, детализация данных по дополнительным измерениям.
Slice and dice: проекции и выборки – выборка нужных элементов кубика
Pivot (rotate): вращение куба, визуализация, выборка и ориентация одно-, двух-, трехмерных срезов для визуального анализа.
Другие операции:
drill across: кросс-детализация (условно – смена кубов при drilldown).
drill through: переход с самого нижнего уровня детализации OLAP-куба, к фактам из выбранной ячейки (из исходной реляционной таблицы).
«Срез» (Slice) представляет собой подмножество гиперкуба, полученное в результате фиксации одного или нескольких измерений. Формирование «срезов» выполняется для ограничения используемых пользователем значений, так как все значения гиперкуба практически никогда одновременно не используются.
Операция «вращение» (Rotate) применяется при двухмерном представлении данных. Суть ее заключается в изменении порядка измерений при визуальном представлении данных. Так, «вращение» двухмерной таблицы, показанной на рис. 3.7, приведет к изменению ее вида таким образом, что по оси X будут показаны предметы, а по оси Y – студенты.
Операцию «вращение» можно обобщить и на многомерный случай, если под ней понимать процедуру изменения порядка следования измерений. В простейшем случае, например, это может быть взаимная перестановка двух произвольных измерений.
Операции «агрегация» (Drill Up) и «детализация» (Drill Down) означают соответственно переход к более общему и к более детальному представлению информации пользователю из гиперкуба.
Основным достоинством многомерной модели данных является удобство и эффективность аналитической обработки больших объемов данных, связанных со временем. Недостатком многомерной модели данных является ее громоздкость для простейших задач обычной оперативной обработки информации.
Примерами систем, поддерживающих многомерные модели данных, являются Essbase (Arbor Software), Media Multi-matrix (Speedware), Oracle Express Server (Oracle) и Cache (InterSystems).
Вопросы для самопроверки по теме 3.2
1. Что такое OLTP и OLAP БД?
2. Назовите и раскройте суть основных операций МБД.
3. Что такое измерение в многомерной модели?
4. Назовите критерии использования OLTP и OLAP.
5. Что такое отношение?
6. Поясните, что Вы понимаете под постреляционной БД?
7. Назовите СУБД, ориентированные на реляционную модель данных.
8. Что такое кортеж?
9. Что такое кординальное число и степень отношения?
10. Определите понятие домена и атрибута?
Резюме. Описаны основные категории моделей данных используемые при проектировании концептуальной модели СУБД.
|
