Понятие системы управления базами данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В технической литературе в качестве примеров сетевых БД часто называют системы 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.5) содержит столбцы (атрибуты) с именами А,, А2,..., Ап.

Рис. 2.5. Структура реляционной таблицы-отношения R

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

Значение атрибута Aj в клетке на пересечении i-й строки и j-го столбца  обозначим через аij. Тогда отношение R образуется множеством упорядоченных  кортежей: R={Ki}, где К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. «Таможенный брокер» является примером отношения, для которого первичный ключ состоит из двух атрибутов, т.е. является составным. При этом возможны два варианта первичного ключа: атрибуты «Наименование организации» и «Регион деятельности» либо «Номер лицензии» и «Регион деятельности». Если задать какой-нибудь из возможных номеров лицензии и название организации, то в таблице найдется не более одной строки с заданными значениями.

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

Он используется для того, чтобы  выбирать из таблицы несколько строк, удовлетворяющих заданному значению вторичного ключа. Например, чтобы из  таблицы 2.3 выбрать фамилии сотрудников, занимающих определенную должность, в качестве вторичного ключа следует взять атрибут «Должность».

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

Так, для табл. 2.3 любой отдельный  атрибут будет вторичным ключом. Например, если задать значение атрибута «Номер лицензии» равным 107000/0003, в таблице будут найдены две строки с этим значением.

Нормализация таблиц-отношений.

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

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

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

Рис. 2.6. Применение внешних ключей для связи отношений

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

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

Выделяют следующие формы нормализованных  таблиц:

- первая нормальная форма (1НФ);

- вторая нормальная форма (2НФ);

- третья нормальная форма (ЗНФ);

- усиленная третья нормальная  форма или нормальная форма  Бойса-Кодда (БКНФ);

- четвертая нормальная форма (4НФ);

- пятая нормальная форма (5НФ).