Базы данных

 

Дальневосточное таможенное управление состоит из 18 таможен, соответственно в дереве, описывающем это управление, у записи типа РТУ будет 18 записей-потомков. Конкретная таможня, например Владивостокская, будет представлена записью:

Имя	Код
ДВТУ	10702000

 

В СУБД на основе иерархической модели типичными  являются операции типа:

- найти указанное  дерево БД;

- найти указанный  экземпляр записи в ранее выбранном  дереве;

- просмотреть  записи некоторого типа в заданном  порядке;

- добавить запись  в заданную позицию иерархии и др.

Для хранения в памяти ЭВМ иерархической структуры данных используется система указателей. Поэтому, например, при размещении в память ЭВМ записи типа РТУ после нее будет к ячеек-указате-лей с адресами расположения записей типа Т (к - число таможен, подчиненных определенному РТУ). В конце каждой записи типа Т будет столько указателей, сколько таможенных постов у соответствующей таможни.

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

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

В технической  литературе в качестве примеров иерархических  БД часто называют системы IMS (Information Management System), TDMS (Time-Shared Data Management System), Mark IV (Multi-Access Retrieval System), System-2000 и др.

Сетевая модель данных

Иерархическая модель является частным случаем  сетевой. В строго иерархических  моделях любой объект может подчиняться  только одному объекту вышестоящего уровня. В иерархических моделях первоначальный доступ возможен по ключу, как правило, только к объекту самого высокого уровня (сопоставленного корню дерева), который не подчинен другим объектам. Доступ к другим объектам осуществляется по связям от корня дерева с использованием соответствующих дополнительных ключей.

Сетевая организация  БД является дальнейшим развитием иерархической. В иерархических структурах запись-потомок  должна иметь только одного предка, тогда как в сетевой структуре данных потомок может иметь любое число предков. Основными компонентами структуры сетевой БД, как и в иерархической, являются записи и связи, которые характеризуются типом. Конкретная запись или связь называется экземпляром связи или записи.

На рис. 2.4. представлена концептуальная модель сетевой БД, содержащая информацию о предпринимателях, брокерах, офрмляющих грузовые таможенные декларации (с номерами 1,2….,5) на некоторые товары (сахар, окорочка, телевизоры).

Рис.2.4. Пример структуры данных сетевой БД

Достаточно  очевидно, что в этой БД будет  четыре типа записей: <Владелец товара>, <Брокер>, <Грузовая таможенная декларация><Вид товара>.

Логическую  структуру сетевой БД можно представить  в виде графа (рис. 2.5). Нетрудно заметить, что в нем несколько корневых вершин, причем некоторые из них имеют нескольких предков, что является характерным свойством сетевой модели.

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

Таким образом, при использовании сетевой модели пользователю достаточно (в общем случае) задать один ключ, чтобы получить искомую запись. Например, декларацию 2 можно найти в БД через владельцев товара либо брокеров. При иерархической модели может потребоваться последовательное задание нескольких ключей, чтобы получить требуемую запись.

Рис. 2.5. Граф, соответствующий примеру на рис. 2.3.

Таким образом, при использовании сетевой модели пользователю проще получить искомую  запись.

В принципе сетевую  структуру (см. рис 2.3) можно представить в виде нескольких отдельных деревьев ( в виде иерархической модели), но тогда возникнет дублирование части информации, что приведет к росту объема БД.

В СУБД на основе сетевой модели типичными являются операции:

- поиск указанной  записи;

- переход от  предка к потомку;

- переход от  потомка к предку;

- просмотр предков или потомков в заданном порядке;

- добавление  записи в заданную позицию  иерархии и др.

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

Взаимосвязи данных во многих предметных областях имеют  сетевой характер. В то же время  они позволяют отображать и иерархические  взаимосвязи данных. Достоинством сетевых  моделей является также отсутствие дублирования данных.

Внутримашинное представление данных в сетевой БД, как и в иерархической, предполагает снабжение записей указателями.

В технической  литературе в качестве примеров сетевых  БД часто называют системы IDS (Integrated Data Store), IDMS (Integrated Database Management System), db. VISTA и др.

 

2.3 Реляционная модель данных

 

Основные понятия

Длительное  время до появления реляционных  БД на практике преобладали иерархические и сетевые модели.

Считается, что  впервые наиболее полное изложение  реляционной модели сформулировал  Е.Ф. Кодд в начале 70-х гг. К этому  времени стало ясно, что при сложных структурах данных реализация новых запросов или введение новых логических связей в сетевых или иерархических БД требует довольно существенных доработок программного обеспечения. Указанный недостаток обусловлен тем, что в этих БД выбор необходимых записей производится е использованием указателей, через которые связаны записи. Предположим, что исходная иерархическая или сетевая БД содержит сведения о товарах, их ценах в разных поставках и информацию о производителях товаров, причем в графе исходной структуры данных нет пути между вершинами, сопоставленными производителям и их ценам товаров. Тогда при необходимости выбора из БД сведений о ценах товаров указанного производителя придется выполнить несколько запросов и провести специальную обработку выбранных данных (скорей всего для этого потребуется разработать дополнительный программный модуль). Если же было несколько производителей одного товара, то задача может оказаться невыполнимой.

Е.Ф. Кодд предложил представлять логическую модель данных в виде набора таблиц, которые получили название реляций, а сама модель -  реляционной. При использовании этой модели по запросу пользователя из таблиц должна выбираться одна или несколько строк (столбцов), удовлетворяющих заданным требованиям. Кроме того он предложил для обработки таблиц (в целях реализации запросов) применять механизм реляционной алгебры или реляционного исчисления.

В реляционной  модели по запросу пользователя из таблиц должна выбираться одна или несколько строк (столбцов), удовлетворяющих заданным требованиям. Реляционная алгебра позволяет описывать процессы реализации запросов, манипулируя таблицами, а не отдельными данными. С некоторым допущением можно говорить, что пользователь реляционной БД, применяя реляционную алгебру, может при разработке процедур обработки запроса одной командой описать обработку целой таблицы или нескольких таблиц, в то время как в других БД для выполнения этого же запроса ему пришлось бы манипулировать множеством записей и, соответственно, использовать множество команд. Не менее важным свойством реляционных БД является возможность создания достаточно простых стандартных языковых средств формулирования и реализации любых запросов.

Базы данных, объектами которых являются связанные определенным образом таблицы, называют реляционными (от relation - связь, отношение). В реляционной БД таблицы (реляции) должны удовлетворять определенным требованиям.

1. Данные в  ячейках таблицы должны быть структурно неделимыми. Каждая ячейка может содержать только один набор данных. Это свойство часто определяется как принцип информационной неделимости. Недопустимо, чтобы в ячейке таблицы реляционной модели содержалось более одного набора (порции) данных, что иногда называют информационным кодированием.

2. Столбцы должны  размешаться в произвольном порядке, а данные каждого столбца должны быть однотипными.

3. Каждый столбец должен быть уникальным (недопустимо дублирование столбцов) и иметь уникальное наименование.

4. Строки размешаются  в таблице в произвольном порядке.

Связанные отношениями таблицы взаимодействуют по принципу главная (master) - подчиненная (detail). Например, если имеются две таблицы, в одной из которых указаны наименования фирм таможенных брокеров и сведения об оформленных через них ГТД за некоторый период времени, а о другой - сведения о каждом таможенном брокере (адрес, номер и дата выдачи лицензии), то первая будет главной, а вторая - подчиненной. Часто главную таблицу называют родительской, а подчиненную – дочерней. Одна и та же таблица может быть главной по отношению к одной таблице БД и дочерней по отношению к другой.

В теории реляционных БД используется специфическая терминология.   

В таблице 2.2 приведены основные термины, используемые при работе с реляционными БД.

Таблица 2.2

Элемент модели	Определение
Отношение или  реляция	Таблица
Атрибут	Столбец таблицы
Имя атрибута	Заголовок столбца  таблицы
Кортеж	Совокупность  значений строки таблицы
Домен	Совокупность  значений в столбце
Область атрибута	Множество, из которого берутся значения атрибута

Пусть таблица-отношение К (рис. 2.6) содержит столбцы (атрибуты) с именами А,, А₂,..., А_п.

 

 

 

 

 

 

 

 

 

 

Множество значений атрибутов в j-м столбце образуют домен, а множество значений атрибутов в i-й строке образуют кортеж К_i.

Значение атрибута A_j в клетке на пересечении i-й строки и j-го столбца обозначим через а_ij. Тогда отношение R образуется множеством упорядоченных кортежей: R={K_i}, где К_i={а_i1, а_i2..., а_mn}; i=1,..., m - номер кортежа; j =1,2,..., n - номер домена.

В таблице 2.3 приведен пример реляции (таблицы), названной «Таможенный брокер», которая включает три домена и четыре кортежа. Домен 1 содержит наименование организации, домен 2 - номер лицензии, домой 3 - регион деятельности таможенного брокера. Каждый домен имеет по 4 значения, а каждый кортеж состоит из трех элементов.

Таблица 2.3

Отношение «Таможенный  брокер»

Атрибут «Номер лицензии»

Наименование  организации	Номер лицензии	Регион деятельности
РОСТЭК-ДВ	10700/0009	Дальневосточное таможенное упр.
ГРОДЕКОВОВНЕШЬРАНС	107000/0020	Гродековская таможня
ВЛАДВНЕШТРАНС	197000/0003	Владивостокская таможня
ВЛАДВНЕШТРАНС	107000/0003	Гродековская  таможня

Значение атрибута

Ключи

В реляционных  БД. как и в других типах БД, для поиска нужных данных используются ключи.

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

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

Если, например, отношение задано в виде табл. 2.1, то очевидно, что атрибут «Паспорт» будет первичным ключом: если задать любое из возможных значений этого атрибута, в таблице найдется только одна строка с заданным значением.

Как и в БД с рассматривавшимися выше моделями данных, в реляционной БД ключ называется простым, когда он состоит из одного атрибута, или составным, когда он состоит из нескольких атрибутов.

Таблица 2.3 «Таможенный брокер» является примером отношения, для которого первичный ключ состоит из двух атрибутов, т.е. является составным. При этом возможны два варианта первичного ключа: атрибуты «Наименование организации» и «Регион деятельности» либо «Номер лицензии» и «Регион деятельности». Если задать какой-нибудь из возможных номеров лицензии и название организации, то в таблице найдется не более одной строки с заданными значениями.