Основные концепции баз данных

Мат.методы хранения данных. Лекция 1
Лекция 1
Основные концепции баз данных
Компьютеры все чаще стали использоваться для построения систем обработки документов, систем обработки информации. Такие системы обычно и называют информационными. Информационная система требует создания в памяти ЭВМ модели внешнего
мира, обновляемой в режиме реального времени, с использованием единого хранилища
- базы данных (БД).
Отличительной чертой баз данных следует считать то, что данные хранятся совместно с
их описанием, а в прикладных программах описание данных не содержится. Независимые от программ пользователя данные обычно называются метаданными. В ряде современных систем метаданные, содержащие также информацию о пользователях, форматы отображения, статистику обращения к данным и др. сведения, хранятся в словаре базы данных.
База данных (БД) представляет собой совокупность специальным образом организованных данных, хранимых в памяти вычислительной системы и отображающих состояние объектов и их взаимосвязей в рассматриваемой предметной области.
Предметная область - часть реального мира, подлежащая изучению с целью организации управления и, в конечном счете, автоматизации. Предметная область представляется множеством фрагментов. Каждый фрагмент предметной области характеризуется
множеством объектов и процессов, использующих объекты, а также множеством пользователей, характеризуемых различными взглядами на предметную область. Например,
ВМФ - базы, корабли, заводы … Корабль - тип, порт приписки, траектория движения.
СУБД
Для работы с базой данных необходима СУБД (система управления базами данных), т.е. программа, которая берет на себя все заботы, связанные с доступом к данным. Она содержит команды, позволяющие создавать базы данных и отдельные таблицы в них, вставлять записи в таблицы, искать, изменять и удалять записи.
Система управления базами данных (СУБД) - это комплекс языковых и программных средств, предназначенный для создания, ведения и совместного использования БД
многими пользователями.
Обычно СУБД различают по используемой модели данных. Так, СУБД, основанные на
использовании реляционной модели данных, называют реляционными СУБД
Одними из первых СУБД являются следующие системы: IMS (IBM, 1968 г.), IDMS
(Cullinet, 1971 г.), ADABAS (Software AG, 1969 г.) и ИНЭС (ВНИИСИ АН СССР, 1976 г.).
Количество современных систем управления базами данных исчисляется тысячам
Программист, работающий с БД, не заботится о том, как эти данные хранятся, и приложения, взаимодействующие с СУБД, не знают о способе записи данных на диск. "Снаружи" виден лишь логический образ данных, и это позволяет менять код СУБД, не затрагивая код самих приложений.
Подобная обработка данных осуществляется посредством языка четвертого поколения,
который поддерживает запросы, записываемые и исполняемые немедленно. Язык четвертого поколения позволяет создавать схемы — точные определения данных и отношений между ними. Схема предназначена для контроля целостности данных. Схема
хранится как часть базы данных и может быть изменена без ущерба для данных. Если,
к примеру, объявлено, что поле содержит целочисленные значения, то СУБД откажется
записывать в него числа с плавающей запятой или строки. Отношения между записями
тоже четко контролируются, и несогласованные данные не допускаются. Операции
можно группировать в транзакции, выполняемые по принципу "все или ничего".
СУБД обеспечивает безопасность данных. Пользователям предоставляются определенные права доступа к информации. Некоторым пользователям разрешено лишь просматривать данные, другие пользователи могут менять содержимое таблиц.
СУБД поддерживает параллельный доступ к базе данных. Приложения могут обращаться к базе данных одновременно. Кроме того, отдельные операции могут "распараллеливаться" для улучшения производительности.
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
1
Мат.методы хранения данных. Лекция 1
СУБД помогает восстанавливать информацию в случае непредвиденного сбоя создавая
резервные копии данных. Все изменения, вносимые в базу данных, регистрируются,
поэтому многие операции можно отменять и выполнять повторно.
Для создания и управления персональными БД и приложений, работающих с ними,
используются СУБД, такие как Access и Visual FoxPro фирмы Microsoft, Paradox фирмы
Borland.
Корпоративная БД создается, поддерживается и функционирует под управлением
сервера БД, например, Microsoft SQL Server или Oracle Server, MySQL.
СУБД управляет одной или несколькими базами данных. БД можно представить как
совокупность информации, организованной в виде множеств. Каждое множество содержит записи унифицированного вида. Сами записи состоят из полей. Обычно множества называют таблицами, а записи — строками таблиц. Это логическая модель данных.
В СУБД могут использоваться различные принципы физического хранения данных. На
жестком диске в одном файле может находиться вся база данных, или для каждой базы
данных создается отдельный каталог или иные способы. Например, в MySQL для каждой БД создается отдельный каталог, а каждой таблице соответствуют три файла.
Строки таблиц могут быть связаны друг с другом одним из трех способов.
Простейшее отношение — "один к одному". В этом случае строка первой таблицы соответствует одной единственной строке второй таблицы. На диаграммах такое отношение выражается записью 1:1.
Отношение "один ко многим" означает ситуацию, когда строка одной таблицы соответствует нескольким строкам другой таблицы. Это наиболее распространенный тип
отношений. На диаграммах он выражается записью 1:N.
В отношении "многие ко многим" строки первой таблицы могут быть связаны с произвольным числом строк во второй таблице. Такое отношение записывается как N:M.
Логическую структуру хранимых в базе данных называют моделью представления данных. К основным моделям представления данных (моделям данных) относятся следующие: иерархическая, сетевая, реляционная, постреляционная, многомерная и объектно-ориентированная .
Системы управления файлами
Простейшая база данных организована в виде набора обычных файлов. Эта модель напоминает картотечную организацию документов, при которой папки хранятся в
ящиках, а в каждой папке подшито некоторое число страниц.
Системы управления файлами нельзя классифицировать как СУБД, так как обычно они
являются частью операционной систем и ничего не знают о внутреннем содержимом
файлов. Это знание заложено в прикладных программах, работающих с файлами. Такая
модель базы данных очень неудобна, поскольку она требует использовать язык третьего поколения (3GL, например PASCAL, C++ и т.п.). В результате время программирования запросов увеличивается, а программист должен обладать более высокой квалификацией, так как ему нужно продумать не только логическую, но и физическую структуру хранения данных. Это приводит к тому, что между приложением и файлом образуется тесная связь. Вся информация о полях таблиц закодирована в приложении. Другое
приложение, обращающееся к тому же файлу, вынуждено дублировать существующий
код.
По мере увеличения числа приложений растет сложность управления БД. Изменения
схемы данных приводят к необходимости изменения каждого программного компонента, для которого это актуально. Формирование новых запросов занимает столько времени, что зачастую теряет всякий смысл.
Системы управления файлами не могут помешать дублированию информации, не существует механизмов, предотвращающих несогласованность данных.
Безопасность обычных файлов контролируется операционной системой. Отдельный
файл может быть заблокирован для просмотра или модификации со стороны того или
иного пользователя, но это выполняется только на уровне операционной системы. В
конкретный момент времени лишь одно приложение может осуществлять запись в
файл, что снижает общую производительность.
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
2
Мат.методы хранения данных. Лекция 1
Иерархические базы данных.
Иерархические базы данных поддерживают древовидную организацию информации.
Для описания структуры (схемы) иерархической БД на некотором языке программирования используется тип данных "дерево".
Для справки. Графы есть способ визуализации связей между определенными объектами. Связи эти могут быть направленными, или ненаправленными.
Ориентированный граф G задается двумя множествами G = {V; E}, где
V− конечное множество, элементы которого называют вершинами или
узлами; E − множество упорядоченных пар на V, т.е. подмножество множества V×V, элементы которого называют дугами.
Ориентированным деревом называется бесконтурный ориентированный
граф у которого полустепень захода любой вершины не больше 1 и существует ровно одна вершина, называемая корнем ориентированного дерева, полустепень захода которой равна 0.
При графическом изображении отношения изображают дугами ориентированного графа, а типы записей - вершинами (диаграмма Бахмана).
Тип "дерево" схож с типами данных "структура" языков программирования Си и "запись" языка Паскаль. В них допускается вложенность типов, каждый из которых находится на некотором уровне.
Связи между записями выражаются в виде отношений предок/потомок.
Вершина V ориентированного дерева называется потомком вершины U, если существует путь ненулевой длины из U в V. Вершина U называется предком вершины V.
У каждой записи есть ровно одна родительская запись. Это помогает поддерживать
ссылочную целостность. Когда запись удаляется из дерева, все ее потомки также
должны быть удалены.
Иерархическая модель данных удобна для работы с иерархически упорядоченной информацией.
Иерархические базы данных имеют централизованную структуру, т.е. безопасность
данных легко контролировать. К сожалению, определенные знания о физическом порядке хранения записей все же необходимы, так как отношения предок/потомок реализуются в виде физических указателей из одной записи на другую.
Это означает, что поиск записи осуществляется методом прямого обхода дерева. Записи, расположенные в одной половине дерева, ищутся быстрее, чем в другой. Отсюда
следует необходимость правильно упорядочивать записи, чтобы время их поиска было
минимальным. Это трудно, так как не все отношения, существующие в реальном мире,
можно выразить в иерархической базе данных. Отношения "один ко многим" являются
естественными, но практически невозможно описать отношения "многие ко многим" или
ситуации, когда запись имеет несколько предков. Любые изменения структуры грозят
перекомпиляцией.
Пример:
Рассмотрим следующую модель данных предприятия (см. рис. 1.1): предприятие состоит из отделов, в которых работают сотрудники. В каждом отделе может работать несколько сотрудников, но сотрудник не может работать более чем в одном отделе.
Поэтому, для информационной системы управления персоналом необходимо создать
отношение, состоящее из родительской записи ОТДЕЛ (НАЗВАНИЕ_ОТДЕЛА, КОЛИЧЕСТВО_СОТРУДНИКОВ) и дочерней записи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение показано на рис. (а) (Для простоты полагаем, что
имеются только три дочерние записи).
Для автоматизации учета контрактов с заказчиками необходимо создание еще двух иерархических структур : заказчик - контракты с ним - сотрудники, задействованные в
работе над контрактом и исполнитель-контракт (рис.1.1(b) и (c) ) Эти деревья будут
включать записи ЗАКАЗЧИК (НАЗВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ (НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАЗВАНИЕ_ОТДЕЛА).
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
3
Мат.методы хранения данных. Лекция 1
отдел
a)
Название_отдела
Количество_сотрудников
сотрудник
сотрудник
сотрудник
Фамилия
Должность
Оклад
Фамилия
Должность
Оклад
Фамилия
Должность
Оклад
b)
заказчик
Название_заказчика
Адрес
контракт
контракт
контракт
Номер
Дата
Сумма
Номер
Дата
Сумма
Номер
Дата
Сумма
исполнитель
Фамилия
Должность
Название_отдела
исполнитель
исполнитель
Фамилия
Должность
Название_отдела
c)
Фамилия
Должность
Название_отдела
исполнитель
Фамилия
Должность
Название отдела
контракт
контракт
контракт
Номер
Дата
Сумма
Номер
Дата
Сумма
Номер
Дата
Сумма
Рис. 1.1. Иерархическая база данных.
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
4
Мат.методы хранения данных. Лекция 1
Из этого примера видны недостатки иерархических БД:
1) Частично дублируется информация между записями СОТРУДНИК и ИСПОЛНИТЕЛЬ
(такие записи называют парными), причем в иерархической модели данных не предусмотрена поддержка соответствия между парными записями.
2) Иерархическая модель реализует отношение между исходной и дочерней записью по схеме 1:N, то есть одной родительской записи может соответствовать любое
число дочерних. Допустим теперь, что исполнитель может принимать участие более
чем в одном контракте (т.е. возникает связь типа M:N). В этом случае в базу данных необходимо ввести еще одно групповое отношение, в котором ИСПОЛНИТЕЛЬ
будет являться исходной записью, а КОНТРАКТ - дочерней (рис. (c)). Таким образом, мы опять вынуждены дублировать информацию.
Сетевые базы данных
Ориентированной сетью (или просто сетью) называют бесконтурный ориентированный
граф.
Сеть является бесконтурным графом, поэтому существуют вершины (узлы) сети с нулевой полустепенью захода, которые называют источниками или входами сети, и
вершины (узлы) с нулевой полустепенью исхода, которые называют стоками или выходами сети.
На разработку стандарта сетевой модели данных большое влияние оказал американский ученый Ч. Бахман. Основные принципы сетевой модели данных были разработаны
в середине 60-х годов, эталонный вариант сетевой модели данных описан в отчетах
рабочей группы по языкам баз данных (COnference on DAta SYstem Languages)
CODASYL (1971г.).
Для описания схемы сетевой БД используется две группы типов: "запись" и "связь".
Тип "связь" определяется для двух типов "запись": предка и потомка. Переменные типа
"связь" являются экземплярами связей.
Сетевая БД состоит из набора записей и набора соответствующих связей. Сетевая модель расширяет иерархическую модель, позволяя группировать связи между записями
в множества. С логической точки зрения связь — это не сама запись. Связи лишь выражают отношения между записями. Как и в иерархической модели, связи ведут от родительской записи к дочерней, но здесь поддерживается множественное наследование,
т.е. в сетевой модели данных запись-потомок может иметь произвольное число записей-предков (сводных родителей).
Т.о. в сетевой модели допускаются отношения "многие ко многим". Записи не зависят
друг от друга. При удалении записи удаляются и все ее связи, но не сами связанные
записи.
В сетевой модели требуется, чтобы связи устанавливались между существующими записями во избежание дублирования и искажения целостности. Данные можно изолировать в соответствующих таблицах и связать с записями в других таблицах.
Достоинством сетевой модели данных является возможность эффективной реализации
по показателям затрат памяти и оперативности. В сравнении с иерархической моделью
сетевая модель предоставляет большие возможности в смысле допустимости образования произвольных связей.
Программисту не нужно заботиться о том, как организуется физическое хранение
данных на диске. Это ослабляет зависимость приложений и данных. Но в сетевой модели требуется, чтобы программист помнил структуру данных при формировании запросов.
Недостатком сетевой модели данных является высокая сложность и жесткость схемы
БД, построенной на ее основе, а также сложность для понимания и выполнения обработки информации в БД обычным пользователем. Кроме того, в сетевой модели данных
ослаблен контроль целостности связей вследствие допустимости установления произвольных связей между записями.
Оптимальную структуру базы данных сложно сформировать, а готовую структуру трудно менять. Если вид таблицы претерпевает изменения, все отношения с другими таблицами должны быть установлены заново, чтобы не нарушилась целостность данных.
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
5
Мат.методы хранения данных. Лекция 1
Под целостностью данных обычно понимают следующее: при модификации таблиц
не должны быть потеряны сами данные и логические связи между ними; указанный тип
и диапазон данных должен соблюдаться при любых изменениях.
Сложность подобной задачи приводит к тому, что программисты зачастую отменяют некоторые ограничения целостности ради упрощения приложений.
Иерархическая структура преобразовывается в сетевую следующим образом (см. рис.
1.2):
•
деревья (a) и (b), показанные на рис1.2, заменяются одной сетевой структурой;
•
для отображения типа M:N вводится запись СОТРУДНИК_КОНТРАКТ, которая не
здесь имеет полей и служит только для связи записей КОНТРАКТ и СОТРУДНИК,
см. рис. 1.2.(в этой записи может храниться и полезная информация, например,
доля данного сотрудника в общем вознаграждении по данному контракту).
отдел
заказчик
Название_отдела
Количество_сотрудников
Название_заказчика
Адрес
сотрудник
сотрудник
Фамилия
Должность
Оклад
Фамилия
Должность
Оклад
контракт
контракт
контракт
Номер
Дата
Сумма
Номер
Дата
Сумма
Номер
Дата
Сумма
сотрудник
Фамилия
Должность
Оклад
Сотрудник_ контракт
Сотрудник_ контракт
Сотрудник_ контракт
Рис. 1.2. Сетевая база данных.
Реляционные базы данных
Реляционная модель данных - разработанная Э.Коддом в 1970г. логическая модель
данных основанная на математической теории отношений.
Эдгар Франк Кодд (23 августа 1923 — 18 апреля 2003) — британский учёный, работы
которого заложили основы теории реляционных баз данных. Работая в компании IBM,
он создал реляционную модель данных.
Отношение ( relation ) представляет собой множество элементов, называемых кортежами. Наглядной формой представления отношения является привычная для человеческого восприятия двумерная таблица. Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам - атрибуты отношения.
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
6
Мат.методы хранения данных. Лекция 1
С помощью одной таблицы удобно описывать простейший вид связей между данными, а именно: деление одного объекта (явления, сущности, системы и проч.), информация о котором хранится в таблице, на множество подобъектов, каждому из которых соответствует строка или запись таблицы. При этом каждый из подобъектов имеет одинаковую структуру или свойства, описываемые соответствующими значениями полей записей. Например, таблица может содержать сведения о группе обучаемых, о каждом из
которых известны следующие характеристики: фамилия, имя и отчество, пол, возраст и
образование. Поскольку в рамках одной таблицы не удается описать более сложные
логические структуры данных из предметной области, применяют связывание таблиц.
"Изначально ... реляционная модель ... рассматривалась как средство для освобождения пользователей от неприятностей, связанных с потребностью иметь дело с массой
деталей представления хранимых данных"- пишет Кодд в статье про RM/T . В статье
про Alpha он обозначает следующие "принципиальные мотивы создания реляционной
модели":
1. Независимость данных
2. Простейшая из числа возможных структура, согласованная с семантическими соображениями
3. Обеспечение унифицирующего принципа, упрощающего язык, требуемый для взаимодействия, и анализ операций, требуемый для авторизации доступа и оптимизации
поиска
4. Сравнительно легкий анализ согласованности [данных].
В сравнении с рассмотренными выше моделями реляционная модель требует от СУБД
гораздо более высокого уровня сложности. В ней делается попытка избавить программиста от выполнения рутинных операций по управлению данными, столь характерных
для иерархической и сетевой моделей.
В реляционной модели база данных представляет собой централизованное хранилище
таблиц, обеспечивающее безопасный одновременный доступ к информации со стороны
многих пользователей. В строках таблиц часть полей содержит данные, относящиеся
непосредственно к записи, а часть — ссылки на строки других таблиц. Таким образом,
связи между записями являются неотъемлемым свойством реляционной модели.
Каждая строка таблицы имеет одинаковую структуру. Например, в таблице, содержащей описания автомобилей, у всех строк будет один и тот же набор полей: производитель, модель, год выпуска, пробег и т.д. Такие таблицы легко изображать в графическом виде.
В реляционной модели достигается информационная и структурная независимость. Записи не связаны между собой настолько, чтобы изменение одной из них затронуло остальные, а изменение структуры базы данных не обязательно приводит к перекомпиляции работающих с ней приложений.
Реляционная модель данных описывает:
- структуры данных в виде (изменяющихся во времени) наборов отношений;
- теоретико-множественные операции над данными: объединение, пересечение,
разность и декартово произведение;
- специальные реляционные операции: селекция(выборка), проекция, соединение и
деление;
- специальные правила, обеспечивающие целостность данных.
Появление теории реляционных баз данных положило начало к разработке ряда языков запросов. Языки запросов можно отнести к двум классам:
1) алгебраические языки, позволяющие выражать запросы средствами специализированных операторов, применяемых к отношениям;
2) языки исчисления предикатов, представляющие собой набор правил для записи
выражения, определяющего новое отношение.
В реляционных СУБД применяется язык SQL, позволяющий формулировать произвольные, нерегламентированные запросы. Это язык четвертого поколения непроцедурный
язык, т.е. говорит ,что надо делать, а не как. Программа написанная на непроцедурном (декларативном ) языке задает связи и отношения между объектами, но не определяет последовательности выполнения действий.
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
7
Мат.методы хранения данных. Лекция 1
Существует много приложений, позволяющих строить логические схемы запросов в
графическом виде.
Каждая реляционная СУБД реализует какое-то подмножество стандарта SQL плюс набор уникальных команд, что усложняет задачу программистам, пытающимся перейти от
одной СУБД к другой. Приходится делать выбор между максимальной переносимостью
и максимальной производительностью. В первом случае нужно придерживаться минимального общего набора команд, поддерживаемых в каждой СУБД. Во втором случае
программист просто сосредоточивается на работе в данной конкретной СУБД, используя
преимущества ее уникальных команд и функций.
Достоинство реляционной модели данных заключается в простоте, понятности и
удобстве физической реализации на ЭВМ. Именно простота и понятность для пользователя явились основной причиной их широкого использования. Проблемы же эффективности обработки данных этого типа оказались технически вполне разрешимыми.
Основными недостатками реляционной модели являются следующие: отсутствие
стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей.
Мы будем работать MySQL. MySQL —это быстрая, надежная, открыто распространяемая СУБД. MySQL, как и многие другие СУБД, функционирует по модели "клиент
/сервер".
Сервером определенного ресурса в компьютерной сети называется компьютер (программа), управляющий этим ресурсом, клиентом - компьютер (программа), использующий этот ресурс. В качестве ресурса компьютерной сети могут выступать, к примеру, базы данных, файловые системы, службы печати, почтовые службы. Тип сервера
определяется видом ресурса, которым он управляет. Например, если управляемым ресурсом является база данных, то соответствующий сервер называется сервером базы
данных.
Достоинством организации информационной системы по архитектуре клиент-сервер является удачное сочетание централизованного хранения, обслуживания и коллективного
доступа к общей корпоративной информации с индивидуальной работой пользователей
над персональной информацией. Архитектура клиент-сервер допускает различные варианты реализации.
Компьютеры играют роли клиентов либо серверов. На рис. 1.1 изображена схема передачи информации между компьютером клиента и жестким диском сервера.
Компьютер
пользователя
Клиент
MySQL
Сервер
MySQL
Хранилище
данных
Рис. 1.3 Схема передачи данных в архитектуре "клиент/сервер"
Постреляционная модель
Классическая реляционная модель предполагает неделимость данных, хранящихся в
полях записей таблиц. Это означает, что информация в таблице представляется в первой нормальной форме. Существует ряд случаев, когда это ограничение мешает эффективной реализации приложений.
Постреляционная модель данных представляет собой расширенную реляционную
модель, снимающую ограничение неделимости данных, хранящихся в записях таблиц.
Постреляционная модель данных допускает многозначные поля - поля, значения которых состоят из подзначений. Набор значений многозначных полей считается самостоятельной таблицей, встроенной в основную таблицу.
На рис. 1.3 на примере информации о накладных и товарах для сравнения приведено
представление одних и тех же данных с помощью реляционной (а) и постреляционной
(б) моделей. Таблица INVOICES (накладные) содержит данные о номерах накладных
(INV_N) и номерах покупателей (CUST_N). В таблице INVOICE.ITEMS (накладныетовары) содержатся данные о каждой из накладных: номер накладной (INV_N), название товара (GOODS) и количество товара (QTY). Таблица INVOICES связана с таблицей
INVOICE.ITEMS по полю INV_N.
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
8
Мат.методы хранения данных. Лекция 1
а) INVOICES
INV_N
CUST_N
0373
8723
8374
8232
7364
8723
INVOICE.ITEMS
INV_N
GOODS
QTY
0373
Сыр
3
0373
Рыба
2
8374
Лимонад
1
8374
Сок
6
8374
Печенье
2
7364
Йогурт
1
б) INVOICES
INV_N
CUST_N
GOODS
QTY
0373
8723
Сыр
3
Рыба
2
Лимонад
1
8374
Сок
6
8374
Печенье
2
Йогурт
1
0373
8374
7364
8232
8723
Рис. 1.4 Реляционная (а) и постреляционная (б) модели.
Для обеспечения целостности данных приходится создавать процедуры, автоматически вызываемые до или после обращения к данным.
Достоинством постреляционной модели является возможность представления совокупности связанных реляционных таблиц одной постреляционной таблицей. Это обеспечивает высокую наглядность представления информации и повышение эффективности ее обработки.
Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных.
Рассмотренная нами постреляционная модель данных поддерживается СУБД uniVers.
К числу других СУБД, основанных на постреляционной модели данных, относятся также
системы Bubba и Dasdb
Многомерная модель
Многомерный подход к представлению данных в базе появился практически одновременно с реляционным, но реально работающих многомерных СУБД (МСУБД) до 90-х
годов прошлого века было очень мало. С середины 90-х годов интерес к ним стал приобретать массовый характер.
Интерес к МСУБД после выхода в 1993 году программной статьи одного из основоположников реляционного подхода Э. Кодда.
Эдгаром Коддом, «отцом реляционных БД» был предложен термин OLAP(Online Analytical Processing - оперативная аналитическая обработка). Работа Кодда финансировалась Arbor, компанией, выпустившей свой собственный OLAP-продукт — Essbase (теперь принадлежащий Hyperion) — годом ранее. Как результат, «12 законов аналитической обработки в реальном времени» Кодда появились в их описании Essbase. В ней
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
9
Мат.методы хранения данных. Лекция 1
сформулированы 12 основных требований к системам класса OLAP, важнейшие из которых связаны с возможностями концептуального представления и обработки многомерных данных. Многомерные системы позволяют оперативно обрабатывать информацию для проведения анализа и принятия решения.
В развитии концепций ИС можно выделить следующие два направления:
- системы оперативной (транзакционной) обработки;
- системы аналитической обработки (системы поддержки принятия решений);
Например, поиск и БД документов, в которых имеется вхождение заданной фразы в определенном контексте.
Реляционные СУБД предназначались для информационных систем оперативной обработки информации и в этой области были весьма эффективны. В системах аналитической обработки они показали себя несколько неповоротливыми и недостаточно гибкими. Более эффективными здесь оказываются многомерные СУБД (МСУБД).
Многомерные СУБД являются узкоспециализированными СУБД, предназначенными
для интерактивной аналитической обработки информации.
Основные понятия, используемые в этих СУБД: агрегируемость, историчность и прогнозируемость данных.
Агрегируемостъ данных означает рассмотрение информации на различных уровнях ее
обобщения. В информационных системах степень детальности представления информации для пользователя зависит от его уровня: аналитик, пользователь-оператор, управляющий, руководитель.
Историчность данных предполагает обеспечение высокого уровня статичности (неизменности) собственно данных и их взаимосвязей, а также обязательность привязки
данных ко времени.
Статичность данных позволяет использовать при их обработке специализированные
методы загрузки, хранения, индексации и выборки.
Временная привязка данных необходима для частого выполнения запросов, имеющих
значения времени и даты в составе выборки. Необходимость упорядочения данных по
времени в процессе обработки и представления данных пользователю накладывает
требования на механизмы хранения и доступа к информации. Так, для уменьшения
времени обработки запросов желательно, чтобы данные всегда были отсортированы в
том порядке, в котором они наиболее часто запрашиваются.
Прогнозируемость данных подразумевает задание функций прогнозирования и применение их к различным временным интервалам.
Многомерность модели данных означает не многомерность визуализации цифровых
данных, а многомерное логическое представление структуры информации при описании и в операциях манипулирования данными. С формальной точки зрения мы имеем
дело с n-арным отношением σ, σ ⊆ A1 × A2 × .. × An где Ai-конечное множество, характеризующее признак.
Если речь идет о многомерной модели с мерностью больше двух, то не обязательно визуально информация представляется в виде многомерных объектов (трех-, четырех- и
более мерных гиперкубов). Пользователю и в этих случаях более удобно иметь дело с
двухмерными таблицами или графиками. Данные при этом представляют собой "вырезки" (точнее, "срезы") из многомерного хранилища данных, выполненные с разной степенью детализации.
По сравнению с реляционной моделью многомерная организация данных обладает более высокой наглядностью и информативностью.
Для иллюстрации на рис. 1.5 приведены реляционное (а) и многомерное (б) представления одних и тех же данных об объемах продаж автомобилей.
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
10
Мат.методы хранения данных. Лекция 1
а)
Модель
Месяц
Объем
"Калина"
апрель
10
" Калина "
май
15
" Калина "
июнь
4
"Ford"
апрель
10
"Ford"
июнь
18
"Renault"
июнь
20
б)
Модель
апрель
май
июнь
" Калина "
10
15
4
" Ford "
10
18
N
" Renault"
N
20
N
Рис. 1.5 Реляционная (а) и многомерное представление данных (б).
Рассмотрим основные понятия многомерных моделей данных, к числу которых относятся измерение и ячейка.
Измерение (Dimension) - это множество однотипных данных, образующих одну из
граней гиперкуба. Примерами наиболее часто используемых временных измерений являются Дни, Месяцы, Кварталы и Годы. В качестве географических измерений широко
употребляются Города, Районы, Регионы и Страны. В многомерной модели данных измерения играют роль индексов, служащих для идентификации конкретных значений в
ячейках гиперкуба.
Ячейка (Cell) или показатель - это поле, значение которого однозначно определяется
фиксированным набором измерений. Тип поля чаще всего определен как цифровой. В
зависимости от того, как формируются значения некоторой ячейки, обычно она может
быть переменной (значения изменяются и могут быть загружены из внешнего источника данных или сформированы программно) либо формулой (значения, подобно формульным ячейкам электронных таблиц, вычисляются по заранее заданным формулам).
В примере на рис. 1.5(б) каждое значение ячейки Объем продаж однозначно определяется комбинацией временного измерения (Месяц продаж) и модели автомобиля. На
практике зачастую требуется большее количество измерений.
Пример трехмерной модели данных приведен на рис. 1.6.
Рис. 1.6 Трехмерная модель данных.
В существующих МСУБД используются два основных варианта (схемы) организации
данных: гиперкубическая и поликубическая.
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
11
Мат.методы хранения данных. Лекция 1
В поликубической схеме предполагается, что в БД может быть определено несколько
гиперкубов с различной размерностью и с различными измерениями в качестве граней.
Примером системы, поддерживающей поликубический вариант БД, является сервер
Oracle Express Server.
В случае гиперкубической схемы предполагается, что все показатели определяются
одним и тем же набором измерений. Это означает, что при наличии нескольких гиперкубов БД все они имеют одинаковую размерность и совпадающие измерения. Очевидно, в некоторых случаях информация в БД может быть избыточной (если требовать
обязательное заполнение ячеек).
В случае многомерной модели данных применяется ряд специальных операций, к которым относятся: формирование "среза", "вращение", агрегация и детализация.
"Срез" (Slice) представляет собой подмножество гиперкуба, полученное в результате
фиксации одного или нескольких измерений.
Например, если ограничить значения измерения Модель автомобиля в гиперкубе (рис.
1.6) маркой "Калина", то получится двухмерная таблица продаж этой марки автомобиля
различными дилерами по годам.
Операция "вращение" (Rotate) применяется при двухмерном представлении данных.
Суть ее заключается в изменении порядка измерений при визуальном представлении
данных. Так, "вращение" двумерной таблицы, показанной на рис. 2.8(б), приведет к
изменению ее вида таким образом, что по оси Х будет марка автомобиля, а по оси Y время.
Операцию "вращение" можно обобщить и на многомерный случай, если под ней понимать процедуру изменения порядка следования измерений. В простейшем случае,
например, это может быть взаимная перестановка двух произвольных измерений.
Операции "агрегация" (Drill Up) и "детализация" (Drill Down) означают соответственно переход к более общему и к более детальному представлению информации пользователю из гиперкуба.
Основным достоинством многомерной модели данных является удобство и эффективность аналитической обработки больших объемов данных, связанных со временем. При
организации обработки аналогичных данных на основе реляционной модели происходит нелинейный рост трудоемкости операций в зависимости от размерности БД и существенное увеличение затрат оперативной памяти на индексацию.
Недостатком многомерной модели данных является ее громоздкость для простейших
задач обычной оперативной обработки информации.
Примерами систем, поддерживающими многомерные модели данных, являются
Essbase (Arbor Software), Media Multi-matrix (Speedware), Oracle Express Server (Oracle)
и Cache (InterSystems). Некоторые программные продукты, например Media/ MR
(Speedware), позволяют одновременно работать с многомерными и с реляционными БД.
В СУБД Cache, в которой внутренней моделью данных является многомерная модель,
реализованы три способа доступа к данным: прямой (на уровне узлов многомерных
массивов), объектный и реляционный.
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
12
Мат.методы хранения данных. Лекция 1
Объектно-ориентированная модель
Объектно-ориентированная база данных (ООБД) позволяет программистам, которые
работают с языками третьего поколения, интерпретировать все свои информационные
сущности как объекты, хранящиеся в оперативной памяти. Дополнительный интерфейсный уровень абстракции обеспечивает перехват запросов, обращающихся к тем
частям базы данных, которые находятся в постоянном хранилище на диске. Изменения,
вносимые в объекты, оптимальным образом переносятся из памяти на диск.
Преимуществом ООБД является упрощенный код. Приложения получают возможность
интерпретировать данные в контексте того языка программирования, на котором они
написаны. Реляционная база данных возвращает значения всех полей в текстовом виде, а затем они приводятся к локальным типам данных. В ООБД этот этап ликвидирован. Методы манипулирования данными всегда остаются одинаковыми независимо от
того, находятся данные на диске или в памяти.
Данные в ООБД способны принять вид любой структуры, которую можно выразить на
используемом языке программирования. Отношения между сущностями также могут
быть произвольно сложными. ООБД управляет кэш-буфером объектов, перемещая объекты между буфером и дисковым хранилищем по мере необходимости.
С помощью ООБД решаются две проблемы. Во-первых, сложные информационные
структуры выражаются в них лучше, чем в реляционных базах данных, а во-вторых,
устраняется необходимость транслировать данные из того формата, в котором они хранятся в формат поддерживаемый СУБД. Например, в реляционной СУБД размерность
целых чисел может составлять 11 цифр, а в используемом языке программирования —
16. Программисту придется учитывать эту ситуацию.
В объектно-ориентированной модели при представлении данных имеется возможность идентифицировать отдельные записи базы. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных
соответствующим средствам в объектно-ориентированных языках программирования.
Объектно-ориентированные СУБД выполняют много дополнительных функций. Это окупается сполна, если отношения между данными очень сложны. В таком случае производительность ООБД оказывается выше, чем у реляционных СУБД. Если же данные не
сложные, дополнительные функции оказываются избыточными. В объектной модели
данных поддерживаются нерегламентированные запросы, но языком их составления не
обязательно является SQL. Логическое представление данных может не соответствовать реляционной модели, поэтому применение языка SQL станет бессмысленным. Зачастую удобнее обрабатывать объекты в памяти, выполняя соответствующие виды поиска.
Большим недостатком объектно-ориентированных баз данных является их тесная связь
с применяемым языком программирования. К данным, хранящимся в реляционной
СУБД, могут обращаться любые приложения, тогда как Java-объект, помещенный в
ООБД, будет представлять интерес лишь для приложений, написанных на Java.
Стандартизованная объектно-ориентированной модель описана в рекомендациях
стандарта ODMG-93 (Object Database Management Group - группа управления объектноориентированными базами данных). Реализовать в полном объеме рекомендации
ODMG-93 пока не удается.
Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Свойства объектов описываются некоторым стандартным типом (например, строковым - string) или типом, конструируемым пользователем (определяется как class).
Значением свойства типа string является строка символов. Значение свойства типа
class есть объект, являющийся экземпляром соответствующего класса. Каждый объектэкземпляр класса считается потомком объекта, в котором он определен как свойство.
Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Родовые отношения в БД образуют связную иерархию объектов.
Логическая структура объектно-ориентированной БД внешне похожа на структуру
иерархической БД. Основное отличие между ними состоит в методах манипулирования
данными.
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
13
Мат.методы хранения данных. Лекция 1
Для выполнения действий над данными в О.О. модели БД применяются логические
операции, усиленные объектно-ориентированными механизмами инкапсуляции, наследования и полиморфизма. Ограниченно могут применяться операции, подобные командам SQL (например, для создания БД).
Создание и модификация БД сопровождается автоматическим формированием и последующей корректировкой индексов (индексных таблиц), содержащих информацию
для быстрого поиска данных.
Вспомним понятия инкапсуляции, наследования и полиморфизма
Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Единство трех сущностей –полей, методов (процедуры и функции) и
свойств.
Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Любой класс м.б. порожден от другого класса. Порожденный класс автоматически наследует
поля, методы в и свойства класса-родителя и может добавлять новые.
Полиморфизм в объектно-ориентированных языках программирования означает способность
одного и того же программного кода работать с разнотипными данными. Это свойство класса решать схожие по смыслу проблемы разными способами. В потомке класса можно изменить метод,
сохранив его имя ( перекрытие метода).
Основным достоинством объектно-ориентированной модели данных в сравнении с
реляционной является возможность отображения информации о сложных связях объектов. Объектно-ориентированная модель данных позволяет идентифицировать отдельную запись базы данных и определять функции их обработки.
Недостатками объектно-ориентированной модели являются высокая понятийная
сложность, неудобство обработки данных и низкая скорость выполнения запросов.
В настоящее время получили широкое распространение следующие ООБД:
РОЕТ (РОЕТ Software), Jasmine (Computer Associates), Versant (Versant Technologies),
ODB-Jupiter (научно-производственный центр "Интелтек Плюс"), а также Iris, Orion и
Postgres.
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
14
Мат.методы хранения данных. Лекция 1
Объектно-реляционные базы данных
Объектно-реляционные СУБД объединяют в себе черты реляционной и объектной моделей. Их возникновение объясняется тем, что реляционные базы данных хорошо работают со встроенными типами данных и гораздо хуже — с пользовательскими, нестандартными. Когда появляется новый важный тип данных, приходится либо включать его
поддержку в СУБД, либо заставлять программиста самостоятельно управлять данными в
приложении.
Не всякую информацию имеет смысл интерпретировать в виде цепочек символов или
цифр. Рассмотрим БД предназначенную для хранения траекторий движения кораблей в
океане, параметров кораблей, параметров движения. Траекторию движения можно записать можно в текстовое поле большого размера, но осуществлять осмысленный поиск
по такому текстовому полю будет достаточно трудно. Для хранения траекторий разрабатываются специальные программные средства, с привлечением знаний по геодезии,
картографии.
Перестройка СУБД с целью включения в нее поддержки нового типа данных — не лучший выход из положения. Вместо этого объектно-реляционная СУБД позволяет загружать код, предназначенный для обработки "нетипичных" данных. Таким образом, база
данных сохраняет свою табличную структуру, но способ обработки некоторых полей
таблиц определяется извне, т.е. программистом.
Виноградова М.С. Каф. ФН-12, МГТУ им. Н.Э. Баумана.
15