Почему реляционная модель лучше

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

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

Компоненты реляционной базы данных

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

Родственники и таблицы – что общего?

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

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

Большинство людей знакомы с двумерными массивами строк и столбцов. Это электронные таблицы, с которыми можно работать в таких приложениях, как Microsoft Excel. Другой пример двумерного массива – это статистика на обратной стороне бейсбольной карточки игрока высшей лиги. В такой карточке имеются столбцы, указывающие год, команду, количество игр, ударов битой, попаданий, выигранных очков и т.п. Строки соответствуют годам, на протяжении которых игрок играл в высшей лиге. Эти данные также можно хранить в отношении (таблице), которое имеет ту же простую структуру. На рис. 1.2 показана таблица реляционной базы данных, содержащая статистику по одному из игроков высшей лиги. В действительности такая таблица может хранить статистику для всей команды или даже целой лиги.

Исторические перспективы

Персональные базы данных впервые появились на персональных компьютерах в начале 1980-х годов. Самые первые продукты работали с системами плоских файлов, но чуть позже появились продукты, из которых некоторые пытались следовать реляционной модели. По мере развития некоторые популярные системы СУБД для персональных компьютеров достаточно близко подошли к тому, чтобы стать по-настоящему реляционными, т.е. удовлетворяющими определению доктора Кодца. Начиная с конца 1980-х годов в организациях все больше и больше ПК объединяются в рабочие группы или в сети отделов. Чтобы заполнить эту новую рыночную нишу, те СУБД, которые первоначально работали только на больших ЭВМ (мэйнфреймах), "спустились" на персональные компьютеры, а реляционные СУБД для ПК, наоборот, "поднялись" на большие ЭВМ.

Рис. 1.2. Таблица со статистикой игрока

Столбцы в массиве являются постоянными, т.е. означают в каждой строке одно и то же. Если в одной строке столбец содержит фамилию игрока, то в остальных строках в том же столбце должны быть фамилии. Порядок расположения строк и столбцов в массиве не имеет значения. Что касается СУБД, то для нее не имеет значения, какой столбец будет первым, какой – следующим и какой – последним. Каким бы ни был порядок столбцов, СУБД будет обрабатывать таблицу одинаковым способом. То же верно и для строк. Для СУБД порядок расположения строк не имеет значения.

Каждый столбец в таблице из базы данных представляет один из атрибутов этой таблицы. Это означает, что столбец содержит однородные данные в каждой строке таблицы. Например, в таблице могут находиться имена, адреса и номера телефонов всех клиентов организации. Каждая табличная строка (также называемая записью, или кортежем) содержит данные по одному клиенту. А каждый столбец содержит один атрибут. Это, например, может быть один из следующих атрибутов: номер клиента, его имя, улица, на которой он живет, его город, штат, почтовый код или номер телефона. Столбцы и строки такой таблицы показаны на рис. 1.3.

Рис. 1.3. Каждая строка базы данных содержит запись; каждый столбец этой базы содержит один атрибут

Помни:
Понятие отношения в модели базы данных – это то же самое, что таблица в базе данных, основанной на определенной модели. Попробуйте повторить это определение быстро десять раз.

Оцените представление

В моем представлении часто возникает один из моих любимых пейзажей: вид на Йосе-митскую долину весенним вечером на выезде из туннеля Уовона. Золотой свет заливает отвесную поверхность скалы Эль-Капитан, вдали сияет пик Хаф-Доум, а водопад "Фата невесты" (Бридалвейл) создает серебряный каскад сверкающей воды, в то время как стайка легких облаков слегка закрывает небо. У баз данных также имеются виды, пусть даже не такие живописные. Называются они представлениями. Их красота заключена в реальной пользе, которую они приносят при работе с данными.

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

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

Скажем, вы работаете, например, с базой данных, в которой имеются таблицы CUSTOMER (клиент) и INVOICE (счет-фактура). В первой таблице имеются столбцы CustomerlD (идентификатор клиента), FirstName (имя), LastName (фамилия), Street (улица), City (город), State (штат), Zipcode (почтовый код) и Phone (телефон). А столбцами второй таблицы являются InvoiceNumber (номер счета-фактуры), CustomerlD (идентификатор клиента), Date (дата), TotalSale (всего продано), TotalRemitted (всего переведено денег) и FormOfPayment (форма платежа).

Главный менеджер по продажам хочет видеть на экране только такие реквизиты клиентов, как имя, фамилия и номер телефона. Если из таблицы CUSTOMER создать представление, в котором содержатся лишь три столбца с названной информацией, то менеджер будет просматривать только нужную ему информацию. А данные из тех столбцов, которые его не интересуют, он видеть не будет. На рис. 1.4 показано получение представления для главного менеджера по продажам.

Рис. 1.4. Представление для главного менеджера по продажам, получаемое из таблицы CUSTOMER

Региональный менеджер по продажам, возможно, хочет видеть имена, фамилии и номера телефонов всех клиентов, с почтовым кодом в диапазоне между 90000 и 93999 (Южная и Центральная Калифорния). Эту работу выполняет представление, которое накладывает ограничение на получаемые с его помощью строки, а также на выводимые с его помощью столбцы. На рис. 1.5 показано получение представления для регионального менеджера по продажам.

Рис. 1.5. В представлении для регионального менеджера по продажам имеются только некоторые строки из таблицы CUSTOMER

Менеджеру по оплате счетов, возможно, требуется просматривать имена и фамилии клиентов из таблицы CUSTOMER и значения столбцов Date, TotalSale, TotalRemitted и FormOfPayment из таблицы INVOICE, причем только из таких записей, где значение TotalRemitted меньше значения TotalSale. Это ограничение на записи имеет место тогда, когда оплата еще не проведена полностью. Для такого просмотра требуется создать представление, которое собирает данные из обеих таблиц. На рис. 1.6 показаны потоки данных, идущие из обеих таблиц, CUSTOMER и INVOICE, в представление для менеджера по оплате счетов, которое называется ACCTS_PAY.

Рис. 1.6. Представление для менеджера по оплате счетов собирает данные из двух таблиц

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

Схемы, домены и ограничения

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

Схемы

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

Домены

Атрибут отношения (т.е. столбец таблицы) может допускать некоторое конечное число значений. Множество всех таких значений и является доменом атрибута.

Скажем, например, что вы являетесь дилером по продаже автомобилей и торгуете новинкой – спортивным Curarri GT 4000 с двухместным закрытым кузовом. Данные об автомобилях, находящихся на складе, вы держите в базе данных, а именно в таблице, которую называете INVENTORY (наличные товары). Один из столбцов этой таблицы вы назвали Color (цвет), и в нем находятся данные о наружном цвете каждого автомобиля. GT 4000 поступают только четырех цветов: огненно-малиновый (blazing crimson), насыщенный черный (midnight black), снежно-белый (snowflake white) и металлический серый (metallic grey). Эти четыре цвета и представляют собой домен атрибута Color.

Ограничения

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

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

Что касается примера с автомобилями, то можно применить к таблице ограничение, при котором в столбец Color (цвет) можно будет вводить только одно из перечисленных значений. Если после этого оператор ввода данных попытается ввести в этот столбец такое значение, как, например, темно-зеленый, система это значение не примет. Ввод данных нельзя будет продолжить до тех пор, пока оператор не введет в поле Color правильное значение.