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

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

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

По указанным причинам СУБД, построенные на основе сетевой модели (IDMS, db_VistaIII и др.), не получили широкого распространения.

Реляционная модель данных (РМД) положена в основу большинства современных СУБД. Достоинствами модели являются простота размещения данных и удобство их интерпретации.

Реляционная модель ориентирована на организацию данных в виде таблиц (отношений).

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

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

Каждая таблица реляционной базы данных имеет имя и строку заголовков.

Рассмотрим таблицу базы данных торгового предприятия, в которой хранятся сведения о поставщиках товаров (табл. 1.1):

Таблица 1.1

Поставщики

Код	Название	Город
	Волна	Хабаровск
	Парус	Владивосток
	Звезда	Хабаровск
	Парус	Иркутск

Таблица имеет имя Поставщики, названия столбцов таблицы Код, Название, Город представляют собой строку заголовков.

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

В терминологии реляционной модели данных каждый столбец таблицы называется полем (атрибутом), каждая строка таблицы – записью (кортежем).

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

К таблицам РМД предъявляются следующие требования:

1. Значения данных, расположенные на пересечении любых строки и столбца, должны быть неделимыми (атомарными, элементарными). Это требование означает, что в каждой ячейке таблицы может находиться только одно значение.

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

3. Порядок следования записей может быть произвольным.

4. В таблице не должно быть одинаковых записей.

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

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

В ситуации, когда в таблице нет поля с уникальными значениями данных, первичный ключ может быть определен по нескольким полям. Например, в таблице Поставки товаров, в которой ведется учет партий товаров, поступивших в магазин, первичным ключом является совокупность полей Артикул и Дата поставки (табл. 1.2):

Таблица 1.2

Поставки товаров

Название товара	Артикул	Количество	Дата поставки	Шифр поставщика
Костюм			10.12.05
Сапоги			10.12.05
Туфли			11.12.05
Костюм			11.12.05
Костюм			12.12.05
Костюм			12.12.05
Туфли			12.12.05

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

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

Предположим, в таблице Дополнительные сведения хранится подробная информация об организациях, поставляющих товары

Дополнительные сведения

Поставщик	Директор	Телефон	Адрес	№ договора
	Иванов П. Л.	64-12-83	Мира, 4
	Сеидов О. А.	22-17-12	Победы, 18
	Цой О. М.	39-18-34	Блюхера, 1
	Лодис С. С.	46-19-23	Пушкина, 1

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

Свяжем таблицы Поставщики и Дополнительные сведения с помощью полей Код и Поставщик. Сравнивая значения данных в этих полях и выбирая сочетания записей, для которых они совпадают, можно получить ответы, например, на такие запросы: «Кто является директором организации «Парус» из Владивостока?» (Сеидов О.А.); «Какой адрес у организации «Волна»?» (Мира, 4). Приведенный пример демонстрирует связь между таблицами «один к одному» – одной записи в таблице Поставщики соответствует одна запись в таблице Дополнительные сведения.

Свяжем теперь таблицы Поставщики и Поставки товаров с помощью полей Код и Шифр поставщика. Возникает вопрос о правомерности выполненных действий. Так как значения данных в поле Шифр поставщика повторяются, это поле не может являться первичным ключом таблицы Поставки товаров.

На самом деле никакого противоречия не существует – поле Шифр поставщика является внешним ключом таблицы Поставки товаров. Внешний ключ – это поле или группа полей таблицы, которые не являются первичным ключом в данной таблице, но являются первичным ключом в другой таблице.

С помощью связывания таблиц Поставщики и Поставки товаров по ключевым полям, можно получить ответы на запросы: «Какая организация поставила костюмы 10 декабря 2005 г.?» (Волна); «Из каких городов были привезены туфли?» (Хабаровск, Иркутск).

Связывая таблицы Поставки товаров и Дополнительные сведения, можно получить ответы на запросы: «Какой номер телефона у организации, поставившей костюмы с артикулом 500?» (64-12-83); «В соответствии с каким договором поставлялись костюмы с артикулом 400?» (№ 35).

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

Для связывания таблиц, данные в связующих полях обязательно должны быть получены из одного домена. Имена связующих полей могут отличаться друг от друга (Код, Шифр поставщика, Поставщик), расположение связующих полей в таблицах может быть произвольным (см. табл. 1.1 – 1.3).

Дата добавления: 2014-01-15