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

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

Рис, 1.4. Таблицы е реляционной модели

В примере (рис. 1.4) показано, как могут быть представлены данные и связи между ними в БД некоторой торговой организации. Таблица «Клиент» содер­жит данные о каждом клиенте — фамилию, имя и отчество. В таблице «Товар» хранятся сведения об имеющихся товарах. Когда клиент вступает во взаимоот­ношения с некоторым товаром (делает заказ), этот факт фиксируется в таблице «Заказ». Для того чтобы можно было сослаться на отдельную запись (строку) в некоторой таблице, каждая запись этой таблицы должна содержать уникальный идентификатор. В данном примере роль таких идентификаторов выполняют поля «Id _кл», «Id_TOB» и «Ы_зак». Поле таблицы, значения которого гарантированно уникальны для каждой записи этой таблицы, называют ключевым по­лем или ключом. Ключ не обязательно должен быть числовым. Иногда уни­кальным идентификатором может сложить не одно поле, а комбинация полей. При этом сочетание значений этих полей должно быть уникальным. Такие поля образуют составной ключ таблицы.

Вернемся к примеру. Обратим внимание, что поля «Клиент» и «Товар» со­держат значения, совпадающие со значениями ключей таблиц «Клиент» и «То­вар)» (совпадение имен полей и названий таблиц не является обязательным). Каждая запись таблицы «Заказ» содержит информацию о заказе клиентом не­которого товара — дату заказа и количество единиц товара. В заказе также со­держатся идентификаторы клиента и заказа, что позволяет однозначно опреде­лить — кем и на какой товар сделан заказ. Так, клиент Иванов заказал один шкаф, а позднее — двенадцать стульев. Клиент Николаев заказал только один шкаф, а Петров пока не заказал ничего.

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

Рис. 1.5. Изображение таблиц и связей

Стрелки указывают «направление», в котором используются ключевые по­ля. Значения из поля «Id _кл» помешаются в поле «Клиент», а значения из поля «Id_тов» - в поле «Товар». Очевидно, что одному клиенту может соответство­вать несколько заказов, но каждому заказу соответствует только одни клиент. С товарами — аналогичная ситуация. Один товар может входить в несколько зака­зов, но в каждый заказ входит только один товар.

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

На рис. 1.6 приведена новая структура БД. Таблица «Заказ» содержит для каждого заказа его уникальный идентификатор, идентификатор клиента, сде­лавшего этот заказ и дату. Перечень и количество товаров, входящих в заказ, хранится в таблице «Состав заказа». Одной записи в таблице «Заказ» может со­ответствовать несколько записей в таблице «Состав заказа».

Рис. 1.6. Преобразованная структура БД