Программирование баз данных MS SQL Server (1084479), страница 76
Текст из файла (страница 76)
8.4. Связь между ваблиаами 5ирр1аега и Окс1екв Практически идентичный пример можно найти в базе данных дочепгсгеиогкз в виде связи между таблицами Рпгсназ1пд. РпгспазеОгоегнеаоег и Рсгспаз1щ. Яп1риег)зоб. Единственное реальное различие состоит в том, что в последнем случае рассматривается список компаний, занимающихся поставкой от заказчика, а не заказчику. С помощью'связи такого рода обычно задается так называемая'связь доменов. Доменом., . нвзйвается ограниченный список'значений из которого должен осуществляться выбор при .'вставке данных в зааибимую;таблицу, Йби-этом не допускается'исполъаоеанне, 'каких;либо,, , данных; не находящихся в списке, который рассматривается как домен.', Таблица, в 'которой храня тса строки сданными',.обрааующиМй домен, обйчйо именуетея справочной, 'или пойс«, ' козой таблицей; по крайней мере одна'справочная таблица обычно обнаруживается почти ' -во всех применяемых на практике базах данных, а иногда количество такйх таблиц довольясг ' велико.
В качестве справочной таблиц можно указать таблицу елГРре ге Ксторая йвлоль:.. кообесйвчивзаетхранение информации обидентификаторах иномерах)вглефонрвлоставщиков, 'но и регламентирует то,;юкио'поставщигки могут быть указаны а таблице Огс1егз. СУБД 8ЯЕ Бегтег позволяет обеспечить принудительную поддержку связи такого рода с помощью двух описанных ниже методов ьг Ограничение внешнего ключа, РОЕЕ16И КЕу. Достаточно просто объявить ограничение РОКЕ16И КЕУ, распространяющееся на таблицу, которая используется в качестве стороны связи "многие", и сослаться на таблицу и столбец, который должен стать стороной "один" связи (наличие только одной строки в таблице, указанной в ссылке, гарантируется, поскольку на столбце (столбцах), указанном в объявлении внешнего ключа, должно бьгть задано ограничение РК1ИЫ1 КЕ1 или ОИ1ООЕ).
Триггеры. Фактически во всех ранних версиях ЬОЕ $егтег применение триггеров создавало единственную реальную возможность обеспечить ссылочную целостность. В действительности в базе данных необходимо предусмотреть два триггера, по одному для казкдой стороны связи. Вначале триггер задается на Нормализация и другие важные проблемы проектирования 297 таблице, которая находится на стороне "многие", и с его помощью проверяется.
имеет ли каждая вставляемая или обновляемая в этой таблице строка соответствие в той таблице, от которой она зависит (под этим подразумевается таблица на стороне "один" связи). После этого необходимо задать триггеры удаления и обновления на другой таблице. С помощью этих триггеров осуществляется проверка удаляемых и обновляемых строк в таблице, указанной в ссылке, для обеспечения того, чтобы в ссылающейся таблице не появились так называемые висячие строки (строки, которым не поставлена в соответствие ни одна строка в таблице домена).
В главе, посвященной ограничениям, уже затрагивался вопрос о том, как отличаются по своей производительности два описанных варианта. Как правило, вариант с использованием ограничения РОРЕ1ОП КЕУ позволяет добиться более высокого быстродействия, особенно в тех случаях, когда имеют место попытки нарушения ограничений. Несмотря на это, вариант с применением триггеров может все же оказаться наиболее приемлемым в тех ситуациях, когда требуется выполнить какое.то действие в связи с осуществлением кал~дой операции вставки или обновления данных (или требуется реализовать какие.то другие специальные ограничения).
Связь "многие ко многим" Связь "многие ко многим" характеризуется тем, что на обеих сторонах связи может присутствовать несколько согласующихся строк, а не только одна. В качестве примера такой связи можно указать связь между товарами и заказами. В каждом конкретном заказе может быть указано много разных товаров. С другой стороны, кальхый конкретный товар может стать предметом нескольких разных заказов. Тем не менее все равно может потребоваться поддернсивать связь между таблицами с данными о заказах и товарах, например, для обеспечения того, чтобы в заказах упоминались только имеющиеся в наличии товары (товары, данные о которых имеются в таблице Ргоопссэ).
В СУБД 8ЯЕ 8егтег не предусмотрен способ непосредственного определения связи "многие ко многим", поэтому для организации подобной связи применяется способ, основанный на использовании промежуточной таблицы. (В некоторых таблицах связи "многие ко многим" создаются почти случайно, в ходе обычного процесса нормализации, а в других таблицах создание подобной связи предусматривается с самого начала процесса проектирования базы данных с единственной целью — обеспечить взаимодействие между таблицами по такому принципу.) Промежуточная таблица, выполняющая роль "посредника", часто именуется связуюжвй таблицей, свединитквьквй таблицей, а иногда вбзвдинлюмж таблицей. Вначале рассмотрим связь "многие ко многим", которая создается в ходе обычного процесса нормализации. Пример такой связи можно обнаружить в таблице Огбегпека(1э базы данных ногспн' пб, с помощью которой создается связь "многие ко многим" между таблицами Огбегз и Ргоацсгэ (рис.
8.5). Операции соединения, которые рассматривались в главе 4, позволяют решить задачу определения того, в каких заказах упоминается какой-то конкретный товар, или выполнить обратную задачу — узнать, какие товары указаны в определенном заказе. Перейдем ко второму варианту создания связи "многие ко многим", в котором специально создается с нуля соединительная таблица, позволяющая ввести в действие связь "многие ко многим".
Рассмотрим в качестве примера связь между пользователями и группами прав доступа, которые могут иметь пользователи в системе. 298 Глава 8 Ов!ег йо (РК) огвег оа(е Соо!оеег йо 171/ 1999 100 1717 1999 12000 101 102 1717 1999 1717 1999 103 цое Нее (РК) ноя Рное то)а) Ргие Огеег йо (РК) Раг1 йо 100 144536 15 108 100 Ой 2400 Ой 2403 29 116 415436 750 750 101 ЗХ9567 869200 62.
50 62 50 12 84 102 15 102 8654 37 15 ЗН6250 869200 32 32 102 103 12 480 165 2Р5523 103 42 103 ЗХ9567 42 Начнем с определения таблицы прав доступа Регп1861опв, которая может выглядеть так, как показано в табл. 8.9. Таблица 8.9. Таблица реипавваопв певог1рсяоп Реге1веаопХП йеаг) 1пзегС Орс(аге Ое1еге 1 2 3 4 Риг. В.5. Связь "многие но многим" между тадлийоми Овг(екв и Рвог2иосв Нормализация и другие важные проблемы проектирования 299 Затем определим таблицу Ряегя (табл. 8.10). Таблица 8.10.
Таблица цветя Рп11 Иппа Рааапоеб Ас язеп Пяег1Р Зсг9..ппЗ 21П93~пб Зоппо яапа Зоьп Рае яап Брасе При такой организации данных возникает проблема, связанная с тем, как определить права доступа, предоставленные тем или другим пользователям. В первую очередь напрашивается такое решение, что в таблицу Ряегя необходимо ввести столбец Регпгяягопя с идентификаторами прав доступа.
Таблица 8.11. Таблица пвехв сс столбцом Рехп1вяйопя Рп11 лапе Рааавоеб Реепяав1опа Асевче Пяек1Р ЗоппР 5апя Зсг9..ппЗ 11193 ) пб Зо!зп Рое 5пп ярабе Но ошибочность этого решения сразу же становится очевидной, поскольку вновь созданная таблица не позволяет найти выход из такой ситуации, когда пользователям потребуется предоставить права на выполнение нескольких различных операций. Если бы использовался обычный, плоский файл, то можно было бы просто записывать всю информацию о правах доступа в одно поле (табл. 8.12).
Таблица 8.12. Гипотетическая структура плоского файла с информацией о правах доступа Рахп1аа1спв Асезеа Рс11 лапе Зппп Рое яап ярабе Рааавоеб Зсг9..ппЗ К1К93~пб Паег1Р Зоппэ 1,2,3 1 1,2,3,4 1 Но файл со структурой, показанной в табл. 8.12, представляет собой пример нарушения требований к первой нормальной форме, согласно которым все значения во всех столбцах должны быть неразрывными (однозначными). Кроме того, применение такой структуры приводит к весьма значительному замедлению работы, поскольку после выборки каждого отдельного многозначного значения поля необходимо проводить его синтаксический анализ с помощью процедурных средств. Дело в том, что фактически между этими двумя таблицами, Ряегя и регп1яягопя, существует связь "многие ко многим", поэтому требуется лишь найти способ представления такой связи в базе данных.
Ззу задачу можно ре1пить, введя п действие соединительную таблицу, как показано на рис. 8.6. Еще раз отметим, что соединительная таблица чаще всего не вносит какие-либо новые данные в базу данных, а определяет ассоциацию между строками двух других таблиц. После ввода в действие новой таблицы (назовем ее Ряегрегпаяягопя) появляется возможность назначать пользователям любые наборы прав доступа. Следует отметить, что реализация требований к ссылочной целостности применительно к обеим таблицам является одинаковой, поскольку каждая из базовых таблиц (таблиц, которые содержат основополагающие данные и участвуют в связи "многие ко многим") имеет связь "один ко многим" с ассоциативной таблицей.
Для обеспечения поддержки ограничений ссылочной целостности можно применить триггер или ограничение РРРЕ108 КЕУ. 300 Глава 8 Рис. 8.6. 1грименение таблицы УззкРзхтззззопз для создания связи "многие но мнопси между таблицами 1Уззкз и Рехтззззопз Средства построения диаграмм Разработка качественного проекта базы данных без использования такого вюкного средства, как диаграммы "сущность-связь" (Епг1гу Ке!аг)опз)пр Ебаращз — ЕКВ. или Ей-диаграммы), почти не осуществима. Безусловно, небольшие базы данных обычно удается легко создать с помощью нескольких сценариев и непосредственно их реализовать, вообще не применяя каких-либо схем. Но чем больше становится база данных, тем сложнее удерживать все, что к ней относится, "в своей голове".
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
