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

И этой книге для описания структуры базы данных мы используем реляционную модель. Поэтому от проектирования базы данных мы можем непосредственно пе­реходить к ее реализации. Нам нет нужды как-либо преобразовывать структуру па стадии реализации: все, что требуется сделать, — это описать существующую реляционную структуру для СУБД.

При реализации баз данных с использованием СУБД, основанных не на реля­ционной модели, дело обстоит иначе. Например, реализуя базу данных на основе модели DL/I, мы должны преобразовать реляционную структуру в иерархиче­скую, а затем описать для СУБД преобразованную структуру.

Описание структуры базы данных для субд

Есть несколько способов, с помощью которых структура базы данных описывает­ся для СУБД. Эти способы зависят от того, какая конкретно СУБД используется. 13 некоторых продуктах создается текстовый файл, который описывает структуру базы данных. Язык, используемый для определения такой структуры, иногда на­зывается языком определения данных (data definition language, DDL). В текстовом DDL-файле перечислены названия таблиц базы данных, указаны названия столб­цов этих таблиц и описано их содержимое, определены индексы, а также описаны другие структуры (ограничения, меры безопасности). В листинге 8.1 с помощью типичного языка определения данных описана простая реляционная база данных для гипотетической СУБД. Более реалистичные примеры с использованием стандарта под названием SQL приведены в главах 12 и 13.

Некоторые СУБД не требуют, чтобы структура базы данных была определена с помощью DDL в текстовом формате. Наиболее распространенная альтер­натива — это графический способ задания структуры базы данных. Например, в Access 2002 разработчику дается графическая структура в виде списка, в соот­ветствующих местах которой нужно ввести имена таблиц и столбцов. Пример этого мы видели в главе 2 (см. рис. 2.2).

Вообще говоря, графические средства описания данных распространены в СУБД, предназначенных для работы на персональных компьютерах. На серве­рах и больших ЭВМ применяются как графические, так и текстовые средства. Например, в Oracle и SQL Server для определения данных могут применяться оба способа. На рис. 8.2 представлена общая схема процесса описания данных для СУБД.

При любом способе определения структуры данных разработчик должен дать название каждой таблице, определить столбцы для этой таблицы и описать фи­зический формат данных в каждом столбце (скажем, TEXT 10). Кроме того, в зави­симости от возможностей используемой СУБД, разработчик может указать ог­раничения, которые должны реализовываться СУБД. Значения столбцов могут определяться, например, как NOT NULL (не пустой) или UNIQUE (уникальный). Не­которые продукты позволяют также устанавливать ограничения на возможные значения (атрибут Часть может принимать значения, меньшие 10 000, а атрибут Цвет может принимать одно из значений ['Красный'/Зеленый'/Синий']). Наконец, могут быть введены ограничения целостности по внешнему ключу. Приведем при­мер такого ограничения: «Значение атрибута НомерОтдела в таблице СОТРУДНИК должно быть равно значению атрибута НомерОтдела в таблице ОТДЕЛ».

Во многих СУБД разработчик может также устанавливать пароли и исполь­зовать другие средства контроля и безопасности. Как будет показано в главе 11, существует множество различных стратегий обеспечения безопасности. В одних стратегиях объектами контроля являются структуры данных (например, таблица защищается паролем), в других — пользователи (обладатель пароля X может чи­тать и обновлять таблицы Т1 и Т2).