 |
Иерархическая структура и модель данных
|
|
|
|
Первой структурой, используемой в СУБД, была иерархическая структура, появившаяся в начале 60-х годов прошлого века. Иерархическая структура предполагала хранение данных в виде дерева. Это значительно упрощало создание и поддержку таких БД. Однако невозможность представить многие объекты реального мира в виде иерархии привела к использованию таких БД в сильно специализированных областях. Типичным представителем (наиболее известным и распространенным) иерархической СУБД является Information Management System (IMS) фирмы IBM. Первая версия этого продукта появилась в 1968 году.
Иерархические, или древовидные, структуры данных разработаны и используются во многих методах индексирования. Иерархическая модель данных близка по своей идее к иерархической структуре данных. Но модель описывает не конкретные методы работы и манипулирования ссылками, а способ логического представления данных, то, какими терминами оперирует проектировщик структуры базы данных, когда отражает реальные зависимости с помощью имеющихся в СУБД механизмов.
Иерархическая модель позволяет строить иерархию элементов У каждого элемента может быть несколько “наследников” и существует один “родитель”. Для каждого уровня связи вводится интерпретация, зависящая от предметной области и описывающая взаимоотношение между “родителями” и “наследниками”. Каждый элемент представляется с помощью записи. Структура данных, обычно используемая для представления этой записи об элементе, обычно содержит некоторые атрибуты, характеристики каждого элемента.
Сетевая структура БД
Попыткой улучшить иерархическую структуру была сетевая структура БД, которая предполагает представление данных в виде сети. Она основана на предложениях группы Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL). Отчет DBTG был опубликован в 1971 году.
|
|
|
Работа с сетевыми БД представляет гораздо более сложный процесс, чем работа с иерархической БД, поэтому данная структура не нашла широкого применения на практике. Типичным представителем сетевых СУБД является Integrated Database Management System (IDMS) компании Cullinet Software, Inc.
Сетевая модель данных является развитием иерархической модели. Существует также другая точка зрения, что иерархическая модель есть частный случай сетевой. В любом случае, по своим базовым концепциям они очень похожи. В сетевой модели, так же как и в иерархической модели, есть понятие элемента данных и связи, которая может быть именована. Главное отличие сетевой модели от иерархической заключается в том, что к каждому элементу может идти связь не от одного элемента (“родителя”), а от нескольких. Например, генеалогическое дерево, построенное только по мужской линии (или, что не существенно, только по материнской), является древовидной, иерархической структурой - у каждого человека (элемента, по нашей терминологии для баз данных), есть только один родитель. Если же включать в генеалогическое дерево всех родителей, то такое дерево с точки зрения структур данных будет уже не деревом, а сетью:
Реляционные базы данных
Наиболее распространены в настоящее время реляционные БД. Термин "реляционпый" произошел от латинского слова "relatio" — отношение. Такая структура хранения данных построена на взаимоотношении составляющих ее частей. Реляционный подход стал широко известен благодаря работам Е. Кодда (1970 год). Ниже приведем двенадцать правил для реляционной БД Е Кодда:
1. Данные представляются в виде таблиц. БД представляет собой набор таблиц. Таблицы хранят данные, сгруппированные в виде рядов и колонок. Ряд представляет собой набор значений, относящихся только к одному объекту, хранящемуся в таблице, и называется записью. Колонка представляет собой одну характеристику для всех объектов, хранящихся в таблице, и называется полем. Ячейка на пересечении ряда и колонки представляет собой значение характеристики, соответствующей колонке для объекта соответствующего ряда.
|
|
|
2. Данные доступны логически. Реляционная модель не позволяет обращаться к данным физически, адресуя ячейки по номерам колонки и ряда (нет возможности получить значение в ячейке (колонка 2, ряд 3)). Доступ к данным возможен только через идентификаторы таблицы, колонки и ряда. Идентификаторами таблицы и колонки являются их имена. Они должны быть уникальны в пределах, соответственно, БД и таблицы. Идентификатором ряда является первичный ключ — значения одной или нескольких колонок, однозначно идентифицирующих ряды. Каждое значение первичного ключа в пределах таблицы должно быть уникальным. Если идентификация ряда осуществляется на основании значений нескольких колонок, то ключ называется составным.
3. NULL трактуется как неизвестное значение. Если в ячейку таблицы значение не введено, то записывается значение NULL. Его нельзя путать с пустой строкой или со значением 0. 0
4. БД должна включать в себя метаданные. БД хранит два вида таблиц: пользовательские и системные. В пользовательских таблицах хранятся данные, введенные пользователем. В системных таблицах хранятся метаданные: описание таблиц (название, типы и размеры колонок), индексы, хранимые процедуры и др. Системные таблицы тоже доступны, т. е. пользователь может получить информацию о метаданных БД.
5. Должен использоваться единый язык для взаимодействия с СУБД.
Для управления реляционной БД должен использоваться единый язык. В настоящее время таким инструментом стал язык SQL.
6. СУБД должна обеспечивать альтернативный вид отображения дан
ных. СУБД не должна ограничивать пользователя только отображением
таблиц, которые существуют. Пользователь должен иметь возможность
строить виртуальные таблицы— представления (View). Представления
являются динамическим объединением нескольких таблиц. Изменения
данных в представлении должны автоматически переноситься на исход
ные таблицы (за исключением нередактируемых полей в представлении,
например вычисляемых полей).
|
|
|
7. Должны поддерживаться операции реляционной алгебры. Записи реляционной БД трактуются как элементы множества, на котором определены операции реляционной алгебры. СУБД должна обеспечивать выполнение этих операций. В настоящее время выполнение этого правила обеспечивает язык SQL.
8. Должна обеспечиваться независимость от физической организации данных. Приложения, оперирующие с данными реляционных БД, не должны зависеть от физического хранения данных (от способа хранения, формата хранения и др.).
9. Должна обеспечиваться независимость от логической организации данных. Приложения, оперирующие с данными реляционных БД, не должны зависеть от организации связей между таблицами (логической организации). При изменении связей между таблицами не должны меняться ни сами таблицы, ни запросы к ним.
10. За целостность данных отвечает СУБД. Под целостностью данных в общем случае понимается готовность БД к работе. Различают физическую целостность — сохранность информации на носителях и корректность форматов хранения данных и логическую целостность — непротиворечивость и актуальность данных, хранящихся в БД. Потеря целостности базы данных может произойти из-за сбоев аппаратуры ЭВМ, ошибок в программном обеспечении, неверной технологии ввода и корректировки данных, низкой достоверности самих данных и т. д. За сохранение целостности данных должна отвечать СУБД, а не приложение, оперирующее ими. Различают два способа обеспечения целостности: декларативный и процедурный. При декларативном способе целостность достигается наложением ограничений на таблицы, при процедурном — обеспечивается с помощью хранимых в БД процедур.
11. Целостность данных не может быть нарушена. СУБД должна обеспечивать целостность данных при любых манипуляциях, производимых с ними.
12. Должны поддерживаться распределенные операции. Реляционная БД может размещаться как на одном компьютере, так и на нескольких — распределенно. Пользователь должен иметь возможность связывать данные, находящиеся в разных таблицах и на разных узлах компьютерной сети. Целостность БД должна обеспечиваться независимо от мест хранения данных.
|
|
|
2.6. Диаграмма «сущность-связь» Чена
Обобщением иерархической, сетевой и реляционной моделей данных является диаграмма «сущность-связь» Чена.Долгое время она оставалась не реализованной в СУБД, но, за счет своей наглядности, активно применялась на этапе логического проектирования базы данных.. В этой модели между классами сущностей существуют именованные n-арные связи с атрибутами. Объект может принадлежать к нескольким сущностям. Сущности могут входить в связь в нескольких ролях. Сущности обозначаются прямоугольниками, а связи – ромбиками. Связи также как и сущности могут иметь атрибуты. Атрибуты обозначаются овалами. Пример диаграммы «Сущность-связь» приведена на Рис. 212.
Рис. 21. Пример диаграммы «Сущность-связь»
Диаграмма «Сущность-связь» легко преобразуется в реляционную модель. Сущностям соответствуют таблицы, связям с арностью больше двух и связям с атрибутами также соответствуют таблицы. Бинарные связи «многие ко многим» заменяются на вспомогательные таблицы, соединенные со связываемыми таблицами двумя связями «один ко многим».
2.7. Объектно-ориентированные базы даных
Объектно-ориентированные базы данных фактически представляют собой объектно-ориентированные языки программирования, например, С++, Java или Smalltalk, в которые добавлена перманентность объектов – возможность объектов сохранять свои свойства между выполнениями программы. Долгое время в них не было триггеров и транзакций. Некоторые исследователи решили добавить связи наследования и агрегации к диаграмме «Сущность-связь». Таким образом, появились ранние средства проектирования: нотации Коада-Йордана, Шлаера-Меллора, Рамбо, Буча. Затем некоторые из этих исследователей объединились и создали UML – универсальный язык моделирования, который является наиболее распространенным средством объектно-ориентированного проектирования, позволяющего описать структуры как баз данных, так и объектно-ориентированных приложений (изучается в курсе «Проектирование информационных систем»).
В диаграмме «сущность-связь» связи могут иметь атрибуты, что делает их похожими на сущности. Для большего учета семантики создателем реляционной модели – Коддом была предложена расширенная реляционная модель - RM/T. В ней не делается разница между сущностями и связями. Связи могут соединять связи.
|
|
|
В интеллектуальных информационных системах традиционно применяются семантические сети (разновидностью которых можно считать «Сущность-связь» Чена), фрейм-слот, логические и продукционные модели. В последнее время появились гибридные модели, соединяющие эти модели с архитектурами баз данных – интеллектуальные и дедуктивные базы данных и онтологии.
Нормализация БД
На практике в дополнение к перечисленным правилам существует также требование минимизации объемов памяти, занимаемых БД. Это достигается проектированием такой структуры БД, при которой дублирование (избыточность) информации было бы минимальным. Для выполнения этого требования была разработана теория нормализации. Она предполагает несколько уровней нормализации БД, каждый из которых базируется на предыдущем. Каждому уровню нормализации соответствует определенная нормальная форма (НФ). В зависимости от условий, которым удовлетворяет БД, говорят, что она имеет соответствующую нормальную форму. Например:
БД имеет 1-ю НФ, если каждое значение, хранящееся в ней, неразделимо
на более примитивные (неразложимость значений);
БД имеет 2-ю НФ, если она имеет 1-ю НФ, и при этом каждое значение целиком и полностью зависит от ключа (функционально независимые значения);
БД имеет 3-ю НФ, если она имеет 2-ю НФ, и при этом ни одно из значений
не предоставляет никаких сведений о другом значении (взаимно незави
симые значения)и т. д.
Существенным недостатком реляционной модели заключается в том, что не каждый тип информации можно представить в табличной форме, например изображение, музыку и др. Правда, в настоящее время для хранения такой информации в реляционных СУБД сделана попытка использовать специальные типы полей — BLOB (Binary Large OBjects). В них хранятся ссылки на соответствующую информацию, которая не включается в БД. Однако такой подход не позволяет оперировать информацией, не помещенной в базу данных, что ограничивает возможности по ее использованию. Для хранения такого вида информации предлагается использовать постреляционные модели в виде объектно-ориентированных структур хранения данных. Общий подход заключается в хранении любой информации в виде объектов. При этом сами объекты могут быть организованы в рамках иерархической модели. К сожалению, такой подход, в отличие от реляционной структуры, которая опирается на реляционную алгебру, недостаточно формализован, что не позволяет широко использовать его на практике.
В соответствии с правилами Кодда СУБД должна обеспечивать выполнение операций над БД, предоставляя при этом возможность одновременной работы нескольким пользователям (с нескольких компьютеров) и гарантируя целостность данных. Для выполнения этих правил в СУБД используется механизм управления транзакциями.
Транзакция — это последовательность операций над БД, рассматриваемых СУБД как единое целое. Транзакция переводит БД из одного целостного состояния в другое.
Как правило, транзакцию составляют операции, манипулирующие с данными, принадлежащими разным таблицам и логически связанными друг с другом. Если при выполнении транзакции будут выполнены операции, модифицирующие только часть данных, а остальные данные не будут изменены, то будет нарушена целостность. Следовательно, либо все операции, включенные в транзакцию, должны быть выполненными, либо не выполнена ни одна из них. Процесс отмены выполнения транзакции называется откатом транзакции (ROLLBACK). Сохранение изменений, производимых в результате выполнения операций транзакции, называется фиксацией транзакции (COMMIT).
Свойство транзакции переводить БД из одного целостного состояния в другое позволяет использовать понятие транзакции как единицу активности пользователя. В случае одновременного обращения пользователей к БД транзакции, инициируемые разными пользователями, выполняются не параллельно (что невозможно для одной БД), а в соответствии с некоторым планом ставятся в очередь и выполняются последовательно. Таким образом, для пользователя, по инициативе которого образована транзакция, присутствие транзакций других пользователей будет незаметно, если не считать некоторого замедления работы по сравнению с однопользовательским режимом. Существует несколько базовых алгоритмов планирования очередности транзакций. В централизованных СУБД наиболее распространены алгоритмы,
основанные на синхронизированных захватах объектов БД. При использовании любого алгоритма возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания плана необходимо выполнять откат одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально ощутить присутствие в системе транзакций других пользователей.
|
|
|
