Атрибутивные базы данных
Подсистема хранения атрибутивной информации о пространственных объектах в ГИС представлена атрибутивными базами данных. Термин «атрибутивная» в данном случае используется для уточнения характера хранимой информации.
База (пространственных) данных (БД) – совокупность пространственных данных, организованных по определенным правилам, устанавливающим общие принципы описания, хранения и манипулирования данными, предназначенная для удовлетворения информационных потребностей пользователя [7, с.5].
Формирование БД, доступ и работу с ними обеспечивают системы управления базами данных, они позволяют быстро на-ходить требуемую информацию и проводить ее дальнейшую об-работку. Система управления базой данных отделяет пользователя от базы данных: пользователь обращается к системе управления базами, она в свою очередь обращается к базе данных, производит необходимые манипуляции с информацией и предоставляет пользователю запрашиваемый ответ.
Система управления базами данных (СУБД) – комплекс программ и языковых средств, предназначенных для создания, ведения, и использования баз данных [5, с.77]. Средствами СУБД поддерживаются различные операции с данными, включая:
§ ввод;
§ хранение;
§ манипулирование (обработка запросов, поиск, выбор-ка, сортировка, обновление);
§ сохранение целостности;
§ защита от несанкционированного доступа или потери. В связи со спецификой (пространственная форма организации и представления) к данным в геоинформационной системе предъявляются высокие требования. В связи с этими требованиями база данных должна быть [4, с.114, том 1]:
• согласованной по времени – хранящиеся в ней количественные данные должны соответствовать определенному времени, быть актуальными;
• полной, достаточно подробной для предполагаемого создания ГИС или картографического произведения; категории
данных и их подразделения должны включать все необходимые сведения для осуществления анализа и математико-картографического моделирования исследуемого объекта или явления;
• позиционно точной, абсолютно совместимой с другими вновь добавляемыми данными;
• достоверной, правильно отражающей характер явлений, это требует четкого и однозначного определения вводимых в нее атрибутов явлений;
• легко обновляемой.
Проектирование БД. В Процессе проектирования БД выделяют три основных уровня: концептуальный, логический, физический.
Концептуальный уровень не зависит от аппаратно-программного обеспечения, связан с концептуальной моделью географических данных. Включает в себя: определение и описание рассматриваемых объектов, установление способа представ¬ления объектов в БД, и выбор базовых типов пространственных объектов. На этом уровне определяется содержание БД и ее це¬левое использование.
Логический уровень определяется имеющимся программным обеспечением и не зависит от аппаратных средств. Включает разработку логической структуры элементов БД в соответствии с одним из основных типов моделей баз данных.
Наиболее распространенны следующие модели баз данных и соответствующие СУБД:
• системы, основанные на инвертированных списках;
• иерархическая структура;
• сетевая структура;
• реляционная модель БД;
• объектно-ориентированная модель БД.
Физический уровень связан с аппаратными и программными средствами. На этом этапе происходит физическая реализация, решаются вопросы объема хранимой информации, ресурсов компьютеров и серверов, рассматриваются вопросы структурирования файлов на дисках, вопросы распределения правд доступа и т. д.
На сегодняшний день наиболее часто используется реляционная модель баз данных. Файловые, иерархические и сетевые структуры являются историческими предшественниками реляционной модели, и их принято называть «дореляционными» или ранними подходами к созданию БД. Можно выделить наиболее общие характеристики ранних систем [12]:
• Эти системы активно использовались в течение многих лет, на много дольше, чем используется какая-либо из реляционных СУБД. Некоторые из ранних систем используются в настоящее время, в них накоплено большое количество информации, и одной из актуальных проблем информационных систем является использование этих систем совместно с современными системами.
• Все ранние системы не основывались на каких-либо абстрактных моделях. Понятие модели данных появилось только вместе с реляционным подходом. Абстрактные представления ранних систем появились позже на основе анализа и выявления общих признаков у различных конкретных систем.
• В ранних системах доступ к БД производился на уровне записей. Пользователи этих систем осуществляли явную навигацию в БД, используя языки программирования, расширенные функциями СУБД. Интерактивный доступ к БД поддерживался только путем создания соответствующих прикладных программ с собственным интерфейсом.
• Навигационная природа ранних систем и доступ к данным на уровне записей заставляли пользователя самого производить всю оптимизацию доступа к БД, без какой-либо поддержки системы.
• После появления реляционных систем большинство ранних систем было оснащено «реляционными» интерфейсами. Однако в большинстве случаев это не сделало их по-настоящему реляционными системами, поскольку оставалась возможность манипулировать данными в естественном для них режиме.
С появлением реляционных подходов к формированию баз данных стали выделять три составные части, в отношении которых можно проанализировать и описать логическую структуру базы данных: структурная часть, манипуляционная часть, целостная часть. Рассмотрим дореляционные подходы в отношении этих трех частей.
Системы, основанные на инвертированных списках [12]. В отношении структурной части инвертированных списков нужно сказать, что хранимые таблицы и пути доступа к ним видны пользователям, при этом:
§ строки таблиц упорядочены системой в некоторой физической последовательности;
§ физическая упорядоченность строк всех таблиц может
определяться и для всей БД,
§ для каждой таблицы можно определить произвольное число ключей поиска, для которых строятся индексы. Эти индексы автоматически поддерживаются системой, но явно видны пользователям. Для манипулирования данными поддерживаются два класса операторов:
§ Операторы, устанавливающие адрес записи, среди которых:
- прямые поисковые операторы (например, найти первую запись таблицы по некоторому пути досту¬па);
- операторы, находящие запись в терминах относи-тельной позиции от предыдущей записи по некото-рому пути доступа.
§ Операторы над адресуемыми записями Общие правила определения целостности БД отсутствуют. В некоторых системах поддерживаются ограничения уникально¬сти значений некоторых полей.
Иерархические системы [12]. Структурной частью иерар-хических систем является дерево. Иерархическая БД состоит из упорядоченного набора деревьев; более точно, из упорядоченно¬го набора нескольких экземпляров одного типа дерева.
Тип дерева состоит из одного «корневого» типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждое из которых является некоторым типом дерева). Тип де¬рева в целом представляет собой иерархически организованный набор типов записи. Корневая запись называется предком, запи¬си поддеревьев называются потомками. Все экземпляры данного типа потомка с общим экземпляром типа предка называются близнецами. У каждой записи-потомка может быть только один предок, реализуется тип связи один ко многим. Для БД опреде-
лен полный порядок обхода – сверху-вниз, слева-направо. При¬мер схемы иерархической БД показан на рис. 3.
Рис. 3 Пример типа дерева иерархической базы данных: предок – запись Отдела, записи Начальник и Сотрудники являются потомками
Примерами типичных операторов манипулирования иерар-хически организованными данными могут быть следующие: найти указанное дерево БД; перейти от одного дерева к другому; перейти от одной записи к другой внутри дерева (например, от отдела – к первому сотруднику); перейти от одной записи к дру¬гой в порядке обхода иерархии; вставить новую запись в указанную позицию; удалить текущую запись.
Автоматически поддерживается целостность ссылок между предками и потомками. Основное правило: никакой потомок не может существовать без своего родителя.
Сетевые структуры данных [12]. Сетевой подход к организации данных является логическим продолжением и расширением иерархического подхода. В иерархических структурах записи-потомки могут иметь любое количество предков.
Сетевая БД состоит из набора записей и набора связей меж¬ду этими записями, более точно, из набора экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи. Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Простой пример сетевой схемы БД приведен на рис. 4.
Рис. 4 Пример логической структуры сетевой БД
Для манипулирования данными примерный набор операций может быть следующим: найти конкретную запись в наборе однотипных записей; перейти от предка к первому потомку по не-которой связи; перейти к следующему потомку в некоторой свя¬зи; перейти от потомка к предку по некоторой связи; создать новую запись; уничтожить запись; модифицировать запись; включить в связь; исключить из связи; переставить в другую связь и т. д.
Поддержание ограничения целостности не требуется, иногда указывается требование целостности по ссылкам (как в иерархи-ческой модели).
Ранние подходы обладают общими недостатками: сложность использования БД; необходимость знания о физической организации данных для работы с ними; физическое существование связей между записями на диске (уязвимость систем связана с физической потерей связей). Указанные недостатки фактически являются предпосылками разработки и реализации реляционных БД. Тем не менее, в настоящее время дореляционные БД имеют важное значение и используются для хранения информации, которая сама по себе обладает определенной структурой. Например, иерархические БД удобны для моделирования классификационных схем или классификаторов. Это связано с тем, что в основе составления систематизированных перечней наименований объектов (классификаторов), каждому из которых в соответствие присваивается уникальный код, в половине случаев находится иерархический метод классификации.
Общая характеристика реляционной модели данных [13]. Основы реляционной модели данных были впервые изложены в статье Е.Кодда в 1970 г. Эта работа послужила стимулом для большого количества статей и книг, в которых реляционная модель получила дальнейшее развитие. Наиболее распространенная трактовка реляционной модели данных принадлежит К. Дейту. Согласно Дейту, реляционная модель состоит из трех частей:
• структурной части,
• целостной части,
• манипуляционной части.
Структурная часть описывает основные понятия реляционных баз данных: тип данных, домен, атрибут, кортеж, первичный ключ, отношение. Постулируется, что единственной структурой данных, используемой в реляционной модели, являются нормализованные n-арные отношения.
Понятие «типа данных» полностью адекватно понятию типов данных в языках программирования. В классической реляционной модели используются только простые (атомарные) типы данных – логический, строковый и численный типы данных. Простые типы данных не обладают внутренней структурой. Сейчас развивается подход к расширению возможностей реляционных систем абстрактными типами данных (дата, время, де-нежный тип данных и т. д.).
Домены – это типы данных, имеющие некоторый смысл (семантику). Домены определяются заданием некоторого базового типа данных и произвольного логического выражения (условия), ограничивающего значения элементов из базового типа, в результате получаем набор возможных элементов данных – домен. Домены ограничивают сравнения, некорректно, хотя и возможно, сравнивать значения из различных доменов.
Атрибут – это пара вида {имя атрибута, имя домена}.
Отношение – это именованное множество пар {имя атрибута, имя домена}.
Каждое отношение (или набор отношений) представляет собой сущность (явление, объект) моделируемой предметной области. Каждый из атрибутов представляет собой одну их характеристик сущности, описываемой данным отношением, имеет уникальное имя в пределах отношения
Кортеж – это набор именованных значений заданного типа.
Отношение состоит из двух частей – заголовка отношения и тела отношения. Заголовок отношения – это аналог заголовка таблицы. Заголовок отношения состоит из атрибутов. Количество атрибутов называется степенью отношения. Тело отношения – это аналог тела таблицы. Тело отношения состоит из кортежей. Кортеж отношения является аналогом строки таблицы. Количество кортежей отношения называется мощностью отношения.
Свойства отношений непосредственно следуют из приведенного выше определения отношения. Именно в этих свойствах заключается различие между отношениями и таблицами. Отношение обладает следующими свойствами:
1. В отношении нет одинаковых кортежей. Действительно, тело отношения есть множество кортежей и, как всякое множество, не может содержать неразличимые элементы. Таблицы в отличие от отношений могут содержать одинаковые строки.
2. Кортежи не упорядочены (сверху вниз). Причина та же – тело отношения есть множество, а множество не упорядочено. Это вторая причина, по которой нельзя отождествить отношения и таблицы – строки в таблицах упорядочены. Одно и то же отношение может быть изображено разными таблицами, в которых строки идут в различном порядке.
3. Атрибуты не упорядочены (слева направо). Поскольку каждый атрибут имеет уникальное имя в пределах отношения, то порядок атрибутов не имеет значения. Это также третья причина, по которой нельзя отождествить отношения и таблицы – столбцы в таблице упорядочены. Одно и то же отношение может быть изображено разными таблицами, в которых столбцы идут в различном порядке. 4. Все значения атрибутов атомарны. Это следует из того, что лежащие в их основе атрибуты имеют атомарные значения. Это четвертое отличие отношений от таблиц – в ячейки таблиц можно поместить что угодно – массивы, структуры, и даже другие таблицы.
Из свойств отношения следует, что не каждая таблица может задавать отношение. Для того чтобы некоторая таблица за¬давала отношение, необходимо, чтобы таблица имела простую структуру (содержала бы только строки и столбцы, причем, в каждой строке было бы одинаковое количество полей), в таблице не должно быть одинаковых строк, любой столбец таблицы должен содержать данные только одного типа, все используемые типы данных должны быть простыми. Пример отношения реляционной БД приведен на рис. 5.
Рис. 5 Пример отношения реляционной БД, посвященного сущности СОТРУДНИК некоторой организации
Реляционной базой данных называется набор отношений. Схемой реляционной базы данных называется набор заголовков отношений, входящих в базу данных.
Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными – реляционную алгебру и реляционное исчисление. Иными словами математический аппарат опирается на теорию множеств и математическую логику.
Целостная часть описывает ограничения специального вида, которые должны выполняться для любых отношений в любых реляционных базах данных. Это целостность сущностей и целостность внешних ключей.
Целостность сущностей: обязательное наличие первичного ключа, атрибута или совокупности атрибутов, выражающего уникальность каждого картежа отношения.
Целостность внешних ключей: сложные сущности представляются в виде нескольких кортежей нескольких отношений в БД, для связи между ними используется атрибуты, которые называются внешним ключом. Отношение, определяющее внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом. Требование целостности по ссылкам состоит в том, что для каждого значения внешнего ключа должна найтись запись с таким же значением первичного ключа в отношении, на которое вдет ссылка, либо значение внешнего ключа должно быть неопределенным (т. е. ни на что не указывать).
Выше указано, что единственной структурой данных, используемой в реляционной модели, являются нормализованные n-арные отношения. Нормализация связана с наличием тех или иных зависимостей между атрибутами, их поиском и устранением, а так же поиском и устранением различных аномалий БД моделируемого множества данных (предметной области). Нормализация позволяет избежать потери общей информации при
удалении или воде записей. Существует более пяти нормальных форм (форм нормализации), по сути, они являются правилами построения связанного набора отношений. Как правило, ограничиваются приведением отношений к третей нормальной форме. Приведем понятия первых трех типов нормализации:
• Отношение находится в Первой Нормальной Форме (1НФ), если оно содержит только атомарные значения.
• Отношение находится во Второй нормальной форме (2НФ) тогда и только тогда, когда отношение находится в 1НФ и нет неключевых атрибутов, зависящих от части сложного ключа. (Неключевой атрибут – это атрибут, не входящий в состав никакого потенциального ключа). Если потенциальный ключ отношения является простым, то отношение автоматически находится в 2НФ.
• Отношение находится в Третьей нормальной форме (3НФ) тогда и только тогда, когда отношение находится в 2НФ и все неключевые атрибуты взаимно независимы. (Атрибуты называются взаимно независимыми, если ни один из них не является функционально зависимым от другого).
Объектно-ориентированная модель БД [4, с.131-133, том 1]. Направление объектно-ориентированных моделей баз данных (ООБД) возникло сравнительно недавно. Их появление обуслов-лено необходимостью разработки сложных информационных прикладных систем, для которых логические структуры существующих БД не приемлемы.
Общепринятые понятия в отношении структурной, манипуляционной и целостной частей ООБД на сегодняшний день не сформированы, не смотря на большое количество функциональных проектов и коммерческих систем, основанных на объектном подходе. В наиболее общей и классической постановке объект-но-ориентированный подход базируется на следующих концепциях:
• концепция объекта и идентификатора объекта;
• концепция атрибутов и методов;
• концепция классов;
• концепция иерархии и наследования классов.
Сущность реального мира моделируется в виде объекта, который при своем создании получает генерируемый системой уникальный идентификатор, не меняющийся при изменении состояния объекта. Объект имеет состояние и поведение. Со-стояние объекта – набор значений его атрибутов, поведение объекта – набор методов, оперирующих над состоянием объекта. Значение атрибута объекта – это некоторый объект или множество объектов. Состояние и поведение объекта инкапсулированы в объекте; взаимодействие объектов производится на основе передачи сообщений и выполнении соответствующих методов.
Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов. Объект должен принадлежать только одному классу. Класс, объекты которого могут служить значениями атрибутов объектов другого класса, называется доменом этого атрибута.
Допускается порождение класса на основе уже существующего класса – наследование. Новый класс в таком случае называется подклассом существующего класса, наследует все его атрибуты и методы. Различают случаи простого и множественного наследования. В первом случае подкласс может определяться на основе только одного класса, во втором случае классов может быть несколько.
Принято выделять два уровня моделирования объектов: нижний (структурный) и верхний (поведенческий). На структур-ном уровне поддерживаются сложные объекты, их идентификация и разновидности связей. База данных – это набор элементов данных, связанных отношениями «входит в класс» и «является атрибутом».
Наиболее важным качеством ООБД является поведенческий аспект объектов. В прикладных системах с традиционной организацией БД существует принципиальный разрыв между структурной и поведенческой частями. Структурная часть системы поддерживается всем аппаратом БД, ее можно моделировать, верифицировать и т. д., а поведенческая часть создается изолированно. В среде ООБД проектирование, разработка и сопровождение прикладной системы становятся процессом, в котором интегрируется структурный и поведенческий аспекты, что требует создания специальных языков. К сожалению, развитого математического аппарата, на который могла бы опираться общая объектно-ориентированная модель данных, не существует.
Объектно-ориентированным моделям баз данных предстоит дальнейшее интенсивное развитие.
Независимо от структур данных базу данных как компоненту ГИС можно классифицировать по двум взаимосвязанным аспектам: внутренние и внешние БД, однопользовательские и многопользовательские БД.
База данных может быть реализована разработчиками ГИС на основе одной из моделей БД без использования распространенных коммерческих средств СУБД. В таком случае, она является внутренней, наполняется и поддерживается средствами самой ГИС. Как правило, внутренние БД предназначены для работы в однопользовательском (локальном) режиме, имеют функциональные ограничения и ограничения на количество записей. Термин «внешние базы данных» в отношении структуры ГИС означает, что БД создаются на основе коммерческой СУБД: возможности полнофункциональной СУБД интегрируются в ГИС, управление атрибутивными данными и обработка запросов передается непосредственно СУБД, а ГИС управляет графической частью пространственных данных. При этом разработчики ГИС избавлены от необходимости конструировать модуль БД, снимаются ограничения на размеры и скорость работы с БД, появляется возможность реализовать многопользовательский режим работы. Обеспечение коллективного доступа к базе данных реализуется архитектурой «клиент-сервер». База данных создается и хранится на сервере средствами коммерческих СУБД. Доступ к ней от пользователей, объединенных локальной сетью, производится путем обращения к клиентской части системы, интегрированной в ГИС. Клиентская часть при помощи языка управления БД общается с серверной частью.
Использование коммерческих СУБД и архитектуры «клиент-сервер» при работе с пространственно-временной информацией позволяет вести «большие» базы данных и работать с ними в многопользовательском режиме, как в локальной, так и в интернет сети. При этом снимается часть вопросов, связанных с обменом данными между ГИС за счет того, что большинство ГИС используют одни и те же СУБД.