ПОЯСНЕНИЕ -------------------------------------------------------------------------------------------------------

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

12. Правило соблюдения правил (запрет обхода правил).

Если в реляционной системе имеется язык низкого уровня («одна запись за раз»), его нельзя использовать для нарушения или пропуска правил или ограничений целостности, установленных в реляционном языке более высокого уровня («несколько записей за раз»).

6.3.3. Ключи и связи

Рассмотрим стандартную для современных информационных систем задачу построения базы данных, которая содержит в себе информацию о клиентах и сде­ланных ими заказах (покупках).

Самое первое решение:, каждый раз, когда клиент делает заказ, делать об этом одну запись в базу данных. Схема этой записи могла бы выглядеть так, как показано на рис. 6.13.

1шты и ттт

Huivicjj осичаоа

Имя клиента Адрес заказа Адрес отгрузки Контактный адрес Номер счета Дата заказа Дата отгрузки Дата оплаты Товар 1 Товар 2 Товар 3 Товар 4

Рис. 6.13. Схема таблицы Клиенты и заказы

В этой таблице будет множество записей. Все поля в записях могут принять одинаковые значения (даже номер счета, поскольку один и тот же клиент может сделать два идентичных заказа, и их впишут в один счет). Значит, для того чтобы обеспечить уникальность каждой записи в таблице, необходимо иметь поле, в ко­тором значения никогда не повторяются. Если в данной фирме принята сквозная уникальная нумерация заказов, мы можем в качестве уникального идентификатора выбрать номер заказа. В случае, если это не так, мы можем в качестве уникальной метки для записи добавить еще одно поле, значения в котором будут уникальными.

'^^фшШфШ^^г это mm ,пр^йнЫёййо^Длй щЬИифиЛии Ышт !^т^Шттт^утшшы. г ь* ; „ , '

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

Произведя разделение схемы таблицы на две, одна из которых содержит све­дения о сделанном заказе, а другая — о каждом заказанном товаре, мы свяжем эти таблицы между собой при помощи связи один ко многим (на рис. 6.14 это линия с цифрой 1 около одного конца и значком бесконечности около другого).

шпшшы

Номер позиции

Номер заказа

Адрес заказа

Количество штук

Контактный адрес

Общая стоимость

Дата заказа

Дата отгрузки

Дата оплаты

Рис. 6.14. Связь один ко многим

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

6.3.4. Ссылочная целостность

Как уже отмечалось, первичный ключ любой таблицы должен содержать уни­кальные непустые значения для данной таблицы. Это утверждение является одним из правил ссылочной целостности (referential integrity). Практически все современные СУБД контролируют уникальность первичных ключей. При попытке присвоить первичному ключу значение, уже имеющееся в другой записи, СУБД ге­нерирует диагностическое сообщение, обычно содержащее словосочетание primary key violation (нарушение первичного ключа). Если две таблицы связаны соотноше­нием один ко многим, внешний ключ второй таблицы должен содержать только те значения, которые уже имеются среди значений первичного ключа первой таблицы. Современные СУБД отслеживают попытки удалить запись в первой таблице, если во второй таблице есть связанные с ней записи, препятствуя этому и генерируя диагностические сообщения. Если бы этого не происходило, со временем вторая таблица переполнилась бы записями, не связанными ни с одной записью в первой таблице (а значит, попросту бесполезными).

6.3.5. Нормализация данных

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

Первая нормальная форма

Вернемся к таблице Клиенты и заказы. Структура этой таблицы показана на рис. 6.15.

Номер заказа Имя клиента Адрес заказа Адрес отгрузки Контактный адрес Номер счета Дата заказа Дата отгрузки Дата оплаты

Рис. 6.15. Таблица Клиенты и заказы в первой нормальной форме

Чтобы таблица соответствовала первой нормальной форме, все значения ее полей должны быть атомарными и все записи — уникальными.

Таблица Клиенты и заказы соответствует этим требованиям, как и любая другая реляционная таблица. Однако она, несмотря на выделение из нее таблицы с зака­занными товарами, остается в значительной степени избыточной. На самом деле каждый раз, добавляя в таблицу очередной заказ от одного и того же клиента, мы многократно дублируем множество сведений. Это, в свою очередь, может привести к некоторым негативным последствиям:

□ до тех пор, пока клиент не сделал хотя бы один заказ, сведения о нем не появятся в базе данных;

□ при удалении последней записи о заказанном товаре из базы исчезают все све­дения о клиенте;

□ при изменении клиентом адреса в базе могут оказаться две записи с разными адресами одного и того же клиента.

Некоторые из этих проблем могут быть решены путем приведения таблиц дан­ных ко второй нормальной форме.

Вторая нормальная форма

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

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

Третья нормальная форма

Итак, таблица Клиенты и заказы превратилась у нас в группу связанных таблиц. Благодаря упорядоченности связей в схеме появилась логика: в центре теперь клиент, с которым связаны его заказы и адреса. В свою очередь, с заказами связаны заказанные товары. Но и эта схема все еще не соответствует третьей нормальной форме. Происходит это потому, что в таблице Заказанные товары есть поле Общая сто­имость. Это поле получено в результате произведения значений полей Количество штук и Цена за штуку.

База данных находится в третьей нормальной форме, если она находится во второй нормальной форме и все поля ее сущностей не зависят друг от друга^[1].

Таким образом, чтобы привести полученную группу объектов к третьей нор­мальной форме, нужно удалить из таблицы Заказанные товары поле Общая стоимость.

6.3.6. Язык SQL

Математическая реляционная модель данных предполагает, что для манипу­ляций с данными и сущностями должна использоваться одна из специальных алгебр — реляционная. Для реализации операций реляционной алгебры в СУБД был разработан специальный язык SQL (Structured Query Language — структури­рованный язык запросов). SQL является декларативным языком программиро­вания. В отличие от процедурных языков программирования, SQL определяет не

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

Язык SQL содержит несколько групп операторов.

Операторы манипулирования данными

Операторы манипулирования данными позволяют производить извлечение, добавление, изменение и удаление данных. В группу входят следующие операторы:

□ SELECT — оператор извлечения данных. Пример:

SELECT 'Номер заказа', 'Номер счета', 'Дата заказа' FROM 'Заказы' WHERE 'Номер клиента' - 20

Этот запрос обращается к таблице Заказы,и выбирает из нее все записи, при­надлежащие клиенту с номером 20,организуя эти записи в три столбца: Номер заказа, Номер счета, Дата заказа.

□ INSERT — оператор добавления данных. Пример:

INSERT INTO 'Заказы' VALUES (1420, 20, 'Ускоренная доставка', 1221, 15.03.2010)

Этот запрос обращается к таблице Заказыи добавляет к ней запись со значе­ниями полей, перечисленными в скобках после оператора VALUES.

□ UPDATE — оператор изменения данных. Пример:

UPDATE 'Заказы' SET 'Номер счета' = 1432 WHERE 'Номер заказа' - 1220

Этот запрос обращается к таблице Заказы и в записи с номером заказа 1220 изменяет значение поля Номер счета на 1432.

□ DELETE — оператор удаления данных. Пример:

DELETE FROM 'Заказы' WHERE 'Номер клиента' - 20

Из таблицы Заказыудаляются строки с номером клиента 20(то есть все за­казы данного клиента).

Операторы определения данных

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

□ CREATE (TABLE, VIEW, TRIGGER, INDEX, STORED PROC) - создает указанный объект базы данных.

□ DROP (TABLE, VIEW, TRIGGER, INDEX, STORED PROC) — уничтожает указанный объект базы данных.

□ ALTER (TABLE, VIEW, TRIGGER, INDEX, STORED PROC) — изменяет структуру указанного объекта базы данных.

Операторы управления данными

К операторам управления данными относятся операторы назначения прав до­ступа и управления транзакциями, а также операторы создания баз данных и из­менения структуры данных.

□ GRANT — предоставляет привилегии пользователям. Пример:

GRANT SELECT ON 'Заказы' ТО NEKTO

Разрешает пользователю NEKTO выполнять запросы на выборку данных к та­блице Заказы. При этом пользователь не получает привилегий, позволяющих ему изменять данные в этой таблице или в структуре таблицы.

□ REVOKE — аннулирует привилегии. Пример:

REVOKE ALL ON 'Заказы' FROM NEKTO