discount_id int NO NULL, stor_id
( discount_id int NO NULL, stor_id char(4) NO NULL,
lowqty smallint NO NULL, highqty smallint NO NULL,
PRIMARY KEY (discount_id, stor_id),
FOREIGN KEY (discount_id) REFERENCES discounts,
FOREIGN KEY (stor_id) REFERENCES stores)
В обеих новых таблицах с первичным ключом полный порядок. Но ведь
SQL никаким образом не стимулирует такое более правильное
проектирование баз данных. И именно потому, что в таблицах могут
содержаться дубликаты. Раз все равно могут существовать таблицы
без первичного ключа, то зачем навязывать первичные ключи при
определении таблицы. Компромиссы...
Первичные, возможные, внешние ключи, функциональные зависимости и
операция группирования
Я снова воспользуюсь примером из базы данных pubs. В базе данных
имеются таблицы sales и stores, определяемые следующим образом:
CREATE TABLE sales (stor_id char(4) NO NULL,
ord_num varchar(20) NO NULL, ord_date datetime NO NULL,
qty smallint NO NULL, payments varchar(12) NO NULL,
title_id tid NO NULL,
PRIMARY KEY (stor_id, ord_num, title_id),
FOREIGN KEY (stor_id) REFERENCES stores,
FOREIGN KEY (title_id) REFERENCES titles)
CREATE TABLE stores (stor_id char(4) NO NULL,
stor_name varchar(40), stor_address varchar(40),
city varchar(20), state char(2), zip char(5),
PRIMARY KEY (stor_id))
Возникает естественное желание выполнять запросы с
эквисоединением этих двух таблиц, получая некоторую агрегатную
информацию о заказах, выполняемых некоторыми магазинами. Примером
такого запроса может быть следующий: "Выдать названия, адреса и
общий объем заказов для магазинов, расположенных в штате
Калифорния". На языке SQL хочется написать такой запрос:
SELECT stor_name, stor_address, sum(qty)
FROM stores A, sales B
WHERE state = 'CA' AND A.stor_id = B.stor_id
GROUP BY A.stor_id
Мы-то понимаем, что хотим сказать: результат соединения
группируется по значениям столбца stor_id, но мы знаем, что
идентификатору магазина в таблице stores однозначно соответствует
его название и адрес (более точно, существуют функциональные
Содержание Назад Вперед