При идентификации для таблиц схемы первичного ключа вам следует также определить альтернативные ключи. Фактически, первичный ключ можно выбрать из двух или более вариантов ключей. Альтернативные ключи содержат уникальные значения, которые приложение обычно использует при поиске строка базе данных. Например, показанная в предыдущих примерах таблица CUSTOMER имеет альтернативный ключ — вместо идентификатора покупателя приложение может обращаться к записям этой таблицы по имени покупателя.
Чтобы найти в схеме альтернативные ключи, нужно просто идентифицировать столбцы, которые приложение будет обычно использовать для запроса строк. Найдя альтернативные ключи, вы можете также определить столбцы, которые приложение обычно опрашивает, но которые не обязательно содержат уникальные значения. Эти столбцы, хотя и не являются основным или альтернативным ключом, имеют важное значение в последующей работе, когда вы будете настраивать производительность приложения с помощью индексов. (В главе 16 поясняется, как можно улучшить производительность приложения, создав в таблице столбцы индексов.)
Идентификация и задание в схеме отношений
При нормализации таблиц в схеме вы можете разбить большие сложные таблицы на маленькие простые, связав их с помощью отношений. При этом нужно четко представлять схему отношений. Это поможет вам с помощью ограничений ссылочной целостности определить для соответствующих данных правила ссылочной целостности. Давайте рассмотрим некоторые вопросы, которые следует учитывать при идентификации отношений в схеме приложения.
Вы можете классифицировать в схеме отношения типа "один к одному", "один ко многим" или "многие ко многим". Понимание типа отношений поможет вам определить различные типы ограничений ссылочной целостности, необходимые для задания требуемых правил ссылочной целостности.
В большинстве схем приложений обычно используются отношения "один ко многим". Рассмотрим, например, диаграмму отношений на рис. 15.3. Отношение таблиц ORDERS и ITEM задано через поле идентификатора каждого заказа (ID). В этом отношении используются уникальные номера заказов, но каждому заказу может соответствовать несколько наименований товаров. Таким образом, заказ и наименования товаров связывает отношение "один ко многим". Чтобы задать правило отношений "один ко многим", сделайте столбец идентификатора ID в таблица ORDERS первичным ключом с ограничением целостности PRIMARY KEY, а столбец ORDERID в таблице ITEM — внешним ключом с ограничением ссылочной целостности.
Аналогично, ограничения ссылочной целостности Oracle7 можно использовать для задания отношений "один к одному". Такое отношение, например, имеет место, когда вы разбиваете таблицу вертикально. Задать между вертикальными разделами таблицы отношение "один к одному" можно просто сделав первичный ключ во втором разделе внешним ключом для первого раздела таблицы. Определение отношения "один к одному" для модифицированной версии таблицы CUSTOMER показано на рис. 15.4.
После идентификации в схеме различных отношений проанализируйте правила ссылочной целостности. Это поможет вам лучше понять задаваемые ссылочные действия. Ссылочные действия говорят Oracle7, как нужно поддерживать ссылочную целостность, когда два пользователя хотят модифицировать или удалить значения родительских ключей, от которых зависят значения внешних ключей. Например, каким образом Oracle7 должен поддерживать ссылочную целостность, когда пользователь пытается удалить в таблице ORDERS заказ, от которого зависят наименования товара в таблице ITEM?
Ограничения ссылочной целостности Oracle7 поддерживают два различных типа ссылочных действий:
· Действие удаления/обновления предотвращает обновление значения родительского ключа или удавление строки родительской таблицы, когда от значения родительского ключа зависит по крайней мере одно значение внешнего ключа.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.