Таблицы

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

Более наглядно структуру таблицы иллюстрирует рис. 4.7, на котором изображена таблица offices. Каждая горизонтальная строка этой таблицы представляет отдельную физическую сущность - один офис. Пять строк таблицы вместе представляют все пять офисов компании. Все данные, содержащиеся в конкретной строке таблицы, относятся к офису, который описывается этой строкой.

Таблица OFFICES

. Данные об офисе

Город, в котором расположен офис

Идентификатор служащего, управляющего офисом

Объем продаж офиса с начала года

Данные об офисе

рс. ki

rpyiaypaipfijvmti

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

На пересечении каждой строки с каждым столбцом таблицы содержится в точности одно значение данных. Например, в строке, представляющей нью-йоркский офис, в столбце city содержится значение New York . В столбце sales этой же строки находится значение $692637,00, которое является объемом продаж нью-йоркского офиса с начала года.

Все значения, содержащиеся в одном и том же столбце, являются данными одного типа. Например, в столбце city содержатся только слова, в столбце sales - денежные суммы, а в столбце mgr - целые числа, представляющие идентификаторы служащих. Множество значений, которые могут содержаться в столбце, называется доменом этого столбца. Доменом столбца city является множество всех названий

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

У каждого столбца в таблице есть свое имя, которое обычно служит заголовком столбца. Все столбцы в одной таблице должны иметь уникальные имена, однако разрешается присваивать одинаковые имена столбцам, расположенным в различных таблицах. На практике такие имена столбцов, как name (имя), address (адрес) и price (цена), часто встречаются в различных таблицах одной базы данных.

Столбцы таблицы упорядочены слева направо, и их порядок определяется при создании таблицы. В любой таблице всегда есть как минимум один столбец. В стандарте ANSI/ISO не указывается максимально допустимое число столбцов в таблице, однако почти во всех коммерческих СУБД этот предел существует и обычно составляет примерно 255 столбцов.

В отличие от столбцов, строки таблицы не имеют определенного порядка. Это значит, что если последовательно выполнить два одинаковых запроса для отображения содержимого таблицы, нет гарантии, что оба раза строки будут перечислены в одном и том же порядке. Конечно, можно ввести в SQL-запрос предложение order by, однако порядок сортировки не имеет совершенно нлчего общего с фактическим расположением строк в таблице.

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

Первичные ключи

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

В правильно построенной реляционной базе данных в каждой таблице есть один или несколько столбцов, значения которых во всех строках разные. Этот столбец (столбцы) называется первичным ключом таблицы. Давайте вновь посмотрим на базу данных, изображенную на рис. 4.7. На первый взгляд, первичным ключом таблицы offices могут служить и столбец office, и столбец city. Однако в случае, если компания будет расширяться и откроет в каком-либо городе второй офис, столбец city больше не сможет исполнять роль первичного ключа. На практике в качестве первичных ключей таблиц обычно следует выбирать идентификаторы, такие как идентификатор офиса (office в таблице offices), служащего (empl num в таблице salesreps) и клиента (cust num в таблице customers). А в случае с таблицей orders выбора нет - единственным столбцом, содержащим уникальные значения, является номер заказа (0rder num).

Таблица products, фрагмент которой изображен на рис. 4.8, является примером таблиць[, в которой первичньгй ключ представляет собой комбинацию столбцов. Такой первичнь[й ключ называется составным. Столбец mfr id содержит идентификаторы производителей всех товаров, перечисленных в таблице, а столбец product id

содержит номера, присвоенные товарам производителями. Может показаться, что столбец product iD мог бы и один исполнять роль первичного ключа, однако ничто не мешает двум различным производителям присвоить своим изделиям одинаковые номера. Таким образом, в качестве первичного ключа таблицы products необходимо использовать комбинацию столбцов mfr id и product id. Для каждого из товаров, содержащихся в таблице, комбинация значений в этих столбцах будет уникальной.

Таблица PRODUCTS

Первичный ключ

flc 4.8. Пример таблицы с составным первичном i

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

Хотя первичные ключи являются важной частью реляционной модели данных, в первых реляционных СУБД (System/R, DB2, Oracle и других) не была обеспечена явным образом их поддержка. Как правило, проектировщики базы данных сами следили за тем, чтобы у всех таблиц были первичные ключи, однако в самих СУБД не было возможности задать для таблицы первичный ключ. И только в СУБД DB2 Version 2, появившейся в апреле 1988 года, компания IBM реализовала поддержку первичных ключей. После этого подобная поддержка была добавлена в стандарт ANSI/ISO.

Отношения предок/потомок

Одним из отличий реляционной модели от первых моделей представления данных было то, что в ней отсутствовали явные указатели, используемые для реализации отношений предок/потомок в иерархической модели данных. Однако вполне очевидно, что такие отношения существуют и в реляционных базах данных. Например, в нашей учебной базе данных каждый из служащих закреплен за конкретным офисом, поэтому ясно, что между строками таблицы offices и таблицы salesreps существует отношение. Не приводит ли отсутствие явных указателей в реляционной модели к потере информации?

Как следует из рис. 4.9, ответ на этот вопрос должен быть отрицательным. На рисунке изображено несколько строк из таблиц offices и salesreps. Обратите

* В английском языке термину отношение соответствует слово relation , а термину реляционная база данных - словосочетание relational database . - Примеч. ред.