Реляционные базы данных

Недостатков большого количества указателей можно избежать используя еще одну структуру баз данных — реляционную. В ней данные хранятся как упорядоченные записи или строки значений атрибутов. Атрибуты объектов группируются в отдельных строках в виде так называемыхотношении(relations), поскольку они сохраняют свои положения в каждой строке и определенно связаны друг с другом (Рисунок 4.8) [Healey, 1991]. Каждая

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

Рисунок 4.8. Реляционная структура БД.

 

Реляционные системы основаны на наборе математических принципов, называемых реляционной алгеброй или алгеброй отношений [Ullman, 1982], устанавливающей правила проектирования и функционирования таких систем. Поскольку реляционная алгебра основывается на теории множеств, каждая таблица отношений функционирует как множество, и первое правило гласит, что таблица не может иметь строку, которая полностью совпадает с какой-либо другой строкой. Поскольку каждая из строк уникальна, одна или несколько колонок могут использоваться для определения критерия поиска. Так, примером использования одной колонки для определения критерия поиска может быть выбор уникального личного номера социального страхования, номера телефона, домашнего адреса и других, имеющихся в других колонках той же таблицы при выборе определенного имени из первой колонки. Такой критерий поиска называется первичным ключом (primary key) для поиска значений в других колонках базы данных [Date, 1986]. Всякая строка таблицы должна иметь уникальное значение в колонке первичного ключа, в противном случае мы не сможем однозначно идентифицировать объекты по первичному ключу.

Реляционные системы ценны тем, что позволяют нам собирать данные в достаточно простые таблицы, при этом задачи организации данных также просты. При необходимости мы можем стыковать строки из одной таблицы с соответствующими строками из другой таблицы, используя связующий механизм,называемый реляционным соединением (relational join). Поскольку реляционные системы преобладают в ГИС и поскольку для ГИС созданы довольно большие базы данных, этот процесс широко распространен, и вам нужно повнимательнее его рассмотреть. Любое количество таблиц может быть "связано". Соединение происходит по равенству значений колонки первичного ключа одной таблицы с другой колонкой второй таблицы. Колонка второй таблицы, с которой связан первичный ключ, называется внешним ключом (foreign key). Опять же, значения связанных строк предполагаются находящимися в тех же позициях для гарантии соответствия. Эта связь означает, что все колонки второй таблицы привязаны к колонкам первой таблицы. Благодаря этому каждая таблица может быть наиболее простой, облегчая управление данными. Вы можете привязать сюда третью таблицу, взяв колонку второй таблицы, которая будет использоваться как первичный ключ к соответствующей ключевой колонке (теперь называемой внешним ключом) третьей таблицы. Процесс может продолжаться присоединением все новых простых таблиц для проведения довольно сложного поиска, причем набор таблиц остается очень простым и легко поддерживаемым. Этот подход устраняет путаницу, присущую разработке баз данных с использованием сетевых систем.

Чтобы мы могли устанавливать реляционные соединения, каждая таблица должна иметь хотя бы одну общую колонку с другой таблицей, с которой мы желаем установить такое соединение. Эта избыточность - как раз то, что прежде всего и обеспечивает реляционное соединение. Однако, по возможности, избыточность следует уменьшать. Для определения вида, который ваши таблицы должны иметь, установлен набор правил, называемыхнормальными формами (normal forms) [Codd, 1970]. Мы рассмотрим три основные нормальные формы; существуют некоторые Дополнения, но это уже скорее усовершенствования, чем собственно нормальные формы [Fagin, 1979].

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

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

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

Правила нормальных форм были суммированы Кентом [Kent, 1983]. Эти правила весьма полезны и должны строго выполняться. Сказав это, все же приходится признать, что всегда существуют обстоятельства, когда такое выполнение будет невозможно или существенно снизит производительность системы [Healey, 1991].








Дата добавления: 2016-02-24; просмотров: 838;


Поиск по сайту:

При помощи поиска вы сможете найти нужную вам информацию.

Поделитесь с друзьями:

Если вам перенёс пользу информационный материал, или помог в учебе – поделитесь этим сайтом с друзьями и знакомыми.
helpiks.org - Хелпикс.Орг - 2014-2024 год. Материал сайта представляется для ознакомительного и учебного использования. | Поддержка
Генерация страницы за: 0.004 сек.