Теория и практика построения баз данных (1088289), страница 59
Текст из файла (страница 59)
Например, один столбец может содержать имена покупателей, а другой — их даты рожде- ния. Каждый столбец имеет уникальное имя, н порядок следования столбцов несуществен. Столбцы отношения носят название атрибутов. Калсдьш атрибут имеет свой домегн который представляет собой физическое и логическое описание множества допустимых значений. 3. В отношении не может быть двух одинаковых строк,и порядок следования строк несуществен (рис. 8.1).
Строки отношения называются также кортежами. Столбец 1 Столбец 2 Столбец 3 Столбец 4 Столбец б (или атрибут 1) Строка 1 (или колтон 1 ) Строка 2 Строка 3 Строка 4 Строка б Строка 6 Рис. 6.1. Отдельный экземпляр реляционной структуры РАТ1ЕМТ Рисунок 8.1 являет собой пример, или отдельный экземпляр, реляционной структуры, содержащей сведения о пациенте клиники. Обобщенный формат, РАТ1Е)тТ ()4згпе, В!г(ЬВа(е, бепбег, Ассоцп()тцглйег, Рйуяс1ап) — это структура отношения; именно ее болыппнство людей имеют в виду под термином отношение. (Вспомните из главы 5, что подчеркиванием выделяется атрибут, являюгцийся ключом отношения.) Если мы добавим в структуру отношения ограничение на возможные значения данных, мы получим реляцио>глую схему (ге!айопа! зсйегпа).
Все эти термины приведены в табл. 8.1. Недоразумения относительно термина «ключ» Термин кточ зачастую является источником недоразумений, так как он имеет различные значения па стадиях проектирования и реализации, В процессе проектирования под ключом понямаетгя один или несколько столбцов, однозначно определягощих строку отношения. Как мы знаем из главы 5, каждое опюпгение имеет хотя бы один ключ, поскольку каждая строка является уникальнои; в предельном случае ключ представляет собой комбинацию всех столбцов отношения.
Обычно ключ состоит из одного-двух столбцов. На стадии реалпзапии термин ключ используется в другом значении. В большинстве реляционных СУБД ключом называется столбец, на базе которого СУБД формирует индекс и другие структуры данных. Это делается для того, чтобы обеспечить быстрый доступ к значениям из данного столбца. Эти ключи це обязаны быть уникальными, и зачастукг они действительно таковыми не являкттся. Они создаются только для повышения быстродействия. (Информацггю о таких структурах данных вы найдете в приложении А,) 276 Глава В. Основы построения реляционных баз данных Описание реляционных данных 277 Рассмотрим, например, отношение ЗАКАЗ (НомерЗаказа, ДатаЗаназа, НомерКлиента, Количества). С точки зрения проекпгироваггия, ключом этого отношения является НоиерЗаказа, так как выделение жирным шрифтом означает, что данный атрибут однозначно определяет строку отношения. С точки зрения реализации, ключом может быть любой из четырех столбцов данного отношения.
Это может быть, например, атрибут ДатаЗаказа. В таком случае СУБД создаст структуру данных, обеспечивающук> быстрый доступ к данным из отношения ЗАКАЗ по значени>о даты заказа. Скорее всего, конкретному значению атрибута ДатаЗаназа будет соответствовать много строк. В дапнолг смысле определение атрибута в качестве ключа не п>ворит ничего о его уникальности. Иногда, чтобы различать два значения слова ключ, употребляются термины логический ключ (!ой!са! 1сеу) и физический ключ (рйу>йса1 1«еу). Логический ключ— это уникальный идентификатор, а физический ключ — это столбец, для которого с целью увеличения быстродействия создан индекс или другая структура данных.
Таблица 8.1. Обзор реляционной терминологии Значение Термин Двумерная таблица Столбец отношения Отношение (таблица, файл) Атрибут(столбец, поле, элемент данных) Кортеж (строка, запись) Домен Строка отношения Физическое и логическое описание множества допустимых значений Реляционная структура Вхождение Формат отношения Реляционная структура с данными Реляционная структура плюс ограничения Группа из одного или нескольких атрибутов, которая однозначно идентифицирует кортеж в отношении То же, что и ключ Реляционная схема Ключ Логический ключ Физический ключ (индекс) Группа из одного или нескольких атрибутов, для которой существует специальная структура данных, ускоряющая считывание данных по значениям этих атрибутов и обеспечивающая быстрый последовательный доступ Индексы Поскольку физический ключ обычно является индексом, некоторые оставляют за термином ключ значение логического ключа, а за термином и>>деке — значение физического ключа.
В данной книге мы именно так н будем поступатвк термин ключ мы будем использовать в значении «логический клточь, а термин и>>деков в значении «физический ключи. В пользу создания индексов есть трн соображения. Одно из них состоит в том, чтобы обеспечить ускоренный доступ к строкам по значению индексируемого атрибута. Другое заключается в упрощении сортировки строк по этому атрибуту. Например, в отношении ЗАКАЗ в качестве ключа кюжет быть определен атрибут ДатаЗаказа, в результате чего отчеты, в которых заказы отсортированы по дате, будут генерироваться быстрее.
Третья цель построения индексов — обеспечение уникальности. Индексы не обязаны быть уникальными, но когда разработчик хочет, чтобы какой-то столбеп был уникальным, СУБД создает для атого столбца индекс. В большинстве реляционных СУБД столбец или группу столбцов можно сделать уникальнымп, если нри определении столбца в таблице указать ключевое слово ОМ10ОЕ Реализация реляционной базы данных Н этой книге для описания структуры базы данных мы используем реляционную модель.
Поэтому от проектирования базы данных мы люжем непосредственно переходить к ее реализации. Нам нет нужды как-либо преобразовывать структуру ца стадии реализации: все, что требуется сделать, — это описать существующую реляционную структуру для СУБД. При реализации баз данных с использованием СУБД, основанных не на реля>(ионной модели, дело обстоит иначе. Например, реализуя базу дапцых на основе модели Р[.,г[, мы должны преобразовать реляционную структуру в иерархическую, а затем описать для СУБД преобразованную структуру. Описание структуры базы данных для СУБД Есть несколько способов, с помощью которых структура базы данных описываетг я для СУБД.
Эти способы зависят от того, какая конкретно СУБД используется, В некоторых продуктах создается текстовый файл, который описывает структуру базы данных. Язык, используемый для определения такой структуры, иногда нанявается языком определения данных (дага де[[в[с!оп!апйпайе, РР1.). В текстовом РРЕ-файле перечислены названия таблиц базы данных, указаны названия столбцов этих таблиц и описано их содержимое, определены индексы, а также описаны другие структуры (ограничения, меры безопасности). В листинге 8.! с помощьк> типичного языка определения данных описана простая реляционная база данных для гипотетической СУБД.
Более реалистичные примеры с использованием стандарта под названием БЯ[ приведены в главах 12 и 13. Листинг 8.1. Пример текстового 00С-файла определения данных ГИЕАТЕ 5СНЕНА РНУ5[С[АИ СИЕАТЕ 5СНЕНА РНУ5[С1АИ СИЕАТЕ ТАВЕЕ РАТ[ЕИТ (Изя>е СНАИАСТЕй УАКУ!ИО (35) ИОТ ИОП.. Вате ОТ В)г[Ь ВАТЕ/Т!НЕ, Оепбег СНАИАСТЕй УАИУ[ИО ([0), Ассоцп[йсгябег [ИТЕОЕй ИОТ ИОП, Рпуэт'стапйаае ГК1 СНАИАСТЕй ЧАИУ[МО (35) МОТ МОП.. Рй[НАИУ КЕУ (Ассосп[йцк>Ьег ), продолжение«> 278 Глава 8.
Основы построения реляционных баз данных Описание реляционных данных 279 Листинг 8.1 (продолжение) ЕОКЕ18И КЕУ (РЬУ51с1апкаве ГК!) КЕЕЕКЕИСЕ5 РНУ5!С!АИ СКЕАТЕ ТАВСЕ РН)5!С!АИ (Рвут сзапИаве СНЯКАСТЕК УАКУ!ИВ (35) ИОТ ИВСЕ, АгеаСобе СНАКЯСТЕК УАКУ!ИВ (3), Соса)Ииабег СНАКАСТЕК УАКУ!ИВ (В) ИОТ ИЦСС, РК!МАКУ КЕУ (РИУ51с)апка(зе) Некоторые СУБД не требуют, чтобы структура базы данных была определена с помощью Е)!З!.
в текстовом формате. Наиболее распространенная альтернатива — это графический способ задания структуры базы данных. Например, в Ассезз 2002 разработчику дается графическая структура в виде списка, в соответствующих местах которой нужно ввести имена таблиц и столбцов. Пример этого мы видели в главе 2 (см.
рис. 2.2). Вообще говоря, графические средства описания данных распространены в СУБД, предназначенных для работы на персональных компьютерах. На серверах и больших ЭВМ применяются как графические, так и текстовые средства. Например, в Огас!е и 5Я! 5егуег для определения данных могут применяться оба способа. На рнс. 8.2 представлена общая схема процесса описания данных для СУБД. Пользователь Данные о структуре базы денных Графическое средство проектирования Рис.
В.В. Процесс описания данных дле СУБД При любом способе определения структуры данных разработчик должен дать название каждой таблице, определить столбцы для этой таблицы и описать физический формат дштных в каждом столбце (скажем, ТЕХТ 10). Кроме того, в зависимости от возможностей используемой СУБД, разработчик может указать ограничения, которые должны реализовываться СУБД.
Значения столбцов могут определяться, например, как ИОТ НОСЕ (не пустой) или ОИ100Е (уникальный). Некоторые продукты позволяют также устанавливать ограничения на возможные .иачения (атрибут Часть может принимать значения, меньшие 10 000, а атрибут Цвет может принимать одно из значений 1'Красный",Зеленый",Синий'1). Наконец, могут быть введены ограничения целостности по внешнему ключу. Приведем пример такого ограничения: «Значение атрибута НомерОтдела в таблице СОТРУДНИК должно быть равно значению атрибута НомерОтдела в таблице ОТДЕЛ .
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
