Построение реляционных баз данных

Построение реляционных баз данных

Основы построения реляционных баз данных

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

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

Обзор терминологии

Как указывалось в главе 5, отношение — это таблица, обладающая определенны­ми свойствами.

1. Записи в отношении могут иметь только одиночные значения; множест­венные значения не допускаются. Следовательно, на пересечении строки и столбца находится только одно значение.

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

3. В отношении не может быть двух одинаковых строк, и порядок следова­ния строк несуществен (рис. 8.1). Строки отношения называются также кортежами.

Рисунок 8.1 являет собой пример, или отдельный экземпляр, реляционной структуры, содержащей сведения о пациенте клиники. Обобщенный формат, PATIENT (Name, Birth Date, Gender, AccountNumber, Physician) — это структура отноше­ния; именно ее большинство людей имеют в виду под термином отношение. (Вспомните из главы 5, что подчеркиванием выделяется атрибут, являющийся ключом отношения.) Если мы добавим в структуру отношения ограничение на возможные значения данных, мы получим реляционную схему (relational schema). Все эти термины приведены в табл. 8.1.

Недоразумения относительно термина «ключ»

Термин ключ зачастую является источником недоразумений, так как он имеет различные значения на стадиях проектирования и реализации. В процессе про­ектирования под ключом понимается один или несколько столбцов, однозначно определяющих строку отношения. Как мы знаем из главы 5, каждое отношение имеет хотя бы один ключ, поскольку каждая строка является уникальной; в пре­дельном случае ключ представляет собой комбинацию всех столбцов отношения. Обычно ключ состоит из одного-двух столбцов.

На стадии реализации термин ключ используется в другом значении. В боль­шинстве реляционных СУБД ключом называется столбец, на базе которого СУБД формирует индекс и другие структуры данных. Это делается для того, чтобы обеспечить быстрый доступ к значениям из данного столбца. Эти ключи не обязаны быть уникальными, и зачастую они действительно таковыми не яв­ляются. Они создаются только для повышения быстродействия. (Информацию о таких структурах данных вы найдете в приложении А.)

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

Иногда, чтобы различать два значения слова ключ, употребляются термины логический ключ (logical key) и физический ключ (physical key). Логический ключ — это уникальный идентификатор, а физический ключ — это столбец, для которого с целью увеличения быстродействия создан индекс или другая структура данных.

Индексы

Поскольку физический ключ обычно является индексом, некоторые оставляют за термином ключ значение логического ключа, а за термином индекс — значение физического ключа. В данной книге мы именно так и будем поступать: термин ключ мы будем использовать в значении «логический ключ», а термин индекс — в значении «физический ключ».

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

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

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

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

При реализации баз данных с использованием СУБД, основанных не на реля­ционной модели, дело обстоит иначе. Например, реализуя базу данных на основе модели 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).

Распределение пространства на физических носителях

Кроме определения структуры базы данных, разработчик должен выделить место для базы данных на физическом носителе. И вновь конкретные действия зависят от того, какая именно СУБД используется. В случае персональной базы данных псе, что требуется сделать, — это присвоить базе данных каталог на диске и дать ей имя. После этого СУБД автоматически выделит пространство для хранения данных.

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

Рассмотрим, например, объект-заказ, скомпонованный из таблиц ЗАКАЗ, СТР0КА_ ЗАКАЗА и ТОВАР. Предположим, что при обработке заказа приложение считывает одну строку из таблицы ЗАКАЗ, несколько строк из таблицы СТР0КА_ЗАКАЗА и по одной строке из таблицы ТОВАР для каждой строки из таблицы СТР0КА_ЗАКАЗА. Далее, строки из таблицы СТР0КА_ЗАКАЗА, относящиеся к одному и тому же за­казу, обычно сгруппированы вместе, а строки в таблице ТОВАР не сгруппированы никак. Эту ситуацию иллюстрирует рис. 8.3.

Теперь представим, что организация параллельно обрабатывает множество за­казов и что у нее есть два диска: один большого объема и быстродействующий, а другой — меньшего объема и более медленный. Разработчик должен опреде­лить наилучшее место для хранения данных. Возможно, производительность улучшится, если таблица ТОВАР будет храниться на большом диске с быстрым доступом, а таблицы СТРОКА_ЗАКАЗА и ЗАКАЗ — на диске меньшего размера и бы­стродействия. А может быть, производительность будет выше, если поместить данные из таблиц ЗАКАЗ и СТРОКА_ЗАКАЗА за предыдущие месяцы на более мед­ленный диск, а за текущий месяц — на более быстрый.

Мы не можем ответить на эти вопросы здесь, поскольку ответ зависит от объема данных, характеристик СУБД и операционной системы, размера и быстродейст­вия дисков и каналов, а также от требований приложений, использующих эту базу данных. Смысл состоит в том, что все эти факторы необходимо принимать во вни­мание при выделении пространства для базы данных на физическом носителе.

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

При создании базы данных разработчику понадобится выделить файловое пространство для журналов базы данных. О ведении журналов вы узнаете в гла­вах 11-13; на данном этапе вам просто следует знать, что СУБД ведет журнал изменений в базе данных, который потом, в случае необходимости, можно ис­пользовать для восстановления базы. Файловое пространство для журналов вы­деляется на этапе создания базы данных.

Составление плана обслуживания базы данных

План обслуживания (maintenance plan) базы данных — это расписание процедур, которые необходимо выполнять на регулярной основе. Эти процедуры включают в себя резервное копирование базы данных, сброс содержимого журнала базы данных в архивные файлы, проверка на наличие нарушений ссылочной целост­ности, оптимизация дискового пространства для данных пользователя и индексов и т. д. К этим вопросам мы также обратимся в главе 11, но имейте в виду, что план обслуживания базы данных должен составляться в процессе ее создания или вскоре после него.

Заполнение базы данных информацией

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

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

Манипулирование реляционными данными

Мы обсудили проектирование реляционных баз данных и способы, при помощи которых структура базы данных описывается для СУБД. До сих пор, говоря об операциях с отношениями, мы рассуждали в обобщенной и интуитивной манере. Такая манера хороша, пока речь идет о проекте, но для реализации приложений нам нужен четкий и непротиворечивый язык, выражающий логику обработки. Такие языки носят название языков манипулирования данпьши (data manipulation languages, DML).