Связывание таблиц с помощью отношений

Таблицы, которые вы видели до сих пор, "жили" уединенно, независимо друг от друга. В реальных БД не найти подобной изоляции. В практических БД таблицы соединены друг с другом паутиной связей.

Допустим, вы намерены создать БД, способную управлять продажами в вашем магазине изделий из бисера, сделанных на заказ. Первая составляющая достаточно проста — таблица Products (изделия), в которой перечислены ваши товары. Но для продолжения вам придет­ся собрать множество дополнительной информации. Проданные изделия из таблицы Products учитываются в таблице Orders (заказы). Товары из таблицы Orders посылаются по почте и фиксируются в таблице Shipments (поставки). Люди из таблицы Customers (клиенты) регистрируются в таблице Invoices (счета). Во всех этих таблицах — Products, Orders, Shipments, Customers и Invoices — содержатся порции связанной информации. В результате, если вы хотите получить ответ на обычный вопрос (например, "Сколько должна Джейн Мэлон (Jane Malone)?" или "Сколько париков из бисера продано на прошлой неде­ле?"), придется заглянуть в несколько таблиц.

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

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

 

 

Основы отношений между таблицами

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

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

Избыточные данные в противоположность связанным

Вернемся к таблице Dolls, созданной в главе 1 для хранения списка кукол-болванчиков. Од­на из порций информации данной таблицы — поле Manufacturer (изготовитель), в котором записано имя компании, изготовившей каждую куклу. Несмотря на то, что это достаточно простая деталь, может оказаться, что для точной оценки стоимости куклы-болванчика вам понадобится немного больше информации о процессе изготовления. Возможно, вы захотите узнать, где находится компания-изготовитель, как долго она существует и вынуждена ли отбиваться от судебных исков разъяренных покупателей.

Если вы ленивы, то можете вставить всю эту информацию в таблицу Dolls так, как пока­зано в табл. 5.1 (затемненные столбцы — новые).

Таблица 5.1. Сведения об изготовителе

ID	Character	Manufacturer	Manufacturer-Location	Manufacturer-OpeningYear	Manu-facturer-Lawsuits	Purchase-Price
	Yoda	MagicPlastic	China		No	$8.99

 

В первый момент вас, возможно, обеспокоит загроможденность таблицы всеми этими полями. Не волнуйтесь — это жизнь, в таблицы должны быть включены все важные детали, поэтому они порой сильно разрастаются. (Это правило проектирования БД, описанное в разд. "Правило 3. Храпите все детали в одном месте" главы 2.) Пусть громоздкость вас не беспокоит. Можно воспользоваться такими средствами, как скрытие столбцов (см. разд. "Скрытие столбцов " главы 3) для устранения полей, которые вас не интересуют.

Несмотря на то что, что обилие столбцов — не повод для беспокойства, в этом примере кроется другая проблема — избыточные данные.

Подобная ситуация кажется невинной, но если добавить несколько новых строк, все окажется не столь безобидно (табл. 5.2).

Таблица 5.2. Сведения о производителе после добавления строк

ID	Character	Manufacturer	Manu-facturer-Location	Manufacturer-OpeningYear	Manufacturer-Lawsuits	Purchase-Price
	Yoda	MagicPlastic	China		No	S8.99
	Dick Cheney	Rebobbiicans	Taiwan		No	S28.75
	Tiger Woods	MagicPlastic	China		No	$2.99

Как только у вас появятся две куклы-болванчика, изготовленные одной компанией (в данном случае MagicPlastic), вы введете дублирующиеся данные — беда всех плохих БД. (Их можно распознать как нарушение правила № 4 хорошего проекта БД, описанного в

разд. "Правило 4. Избегайте дублирования данных" главы 2.) Потенциальные проблемы не­скончаемы.

■ Если компания MagicPlastic переводит свои предприятия из Китая и Южную Корею, вам нужно обновлять целую группу записей о куклах-болванчиках. Если вы использовали две таблицы со связанной информацией (как вы увидите далее), вам придется бороться только с одной записью.

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

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

■ Если же понадобится информация об изготовителях (а не о куклах), вы потерпите неудачу. Например, вам не удастся распечатать список всех изготовителей кукол-болванчиков в Китае (по крайней мере, не так легко, как хотелось бы).

Проблема вполне очевидна. Из-за желания хранить слишком много подробностей в од­ном месте в одной таблице объединяется информация, которую лучше всего хранить в двух отдельных таблицах. Для исправления этого проекта нужно создать две таблицы со связан­ными данными. Например, можно сформировать таблицу Dolls, как показано втабл. 5.3, и отдельную таблицу Manufacturers с подробными данными об изготовителях (табл. 5.4).

Таблица 5.3. Данные в таблице Dolls

ID	Character	Manufacturer	PurchasePrice
	Yoda	MagicPlastic	$8.99
	Dick Cheney	Rebobblicans	$28.75
	Tiger Woods	MagicPlastic	$2.99

Таблица 5.4. Данные в таблице Manufacturers

ID	Manufacturer	Location	OpeningYear	Lawsuits
	MagicPlastic	China		No
	Rebobbitcans	Taiwan		No

Этот проект позволяет легко работать отдельно с двумя типами информации (куклы и изготовители). Он также устраняет риск дублирования. В данном простом примере пре­имущества незначительны, но в таблице с сотнями или тысячами записей о куклах-болванчиках (и намного меньшим числом изготовителей) разница весьма существенна.

Теперь если компания MagicPlastic переезжает в Южную Корею, вам нужно обновить данные поля Location только в одной записи, вместо множества экземпляров в перегруженной

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

 

 

Примечание

В программу Access включено средство, пытающееся отследить дублирующиеся данные в таблице и помочь вам разделить поля на две связанные таблицы. (Для знакомства с ним вы­берите Работа с базами данных → Анализ → Анализ таблицы (Database Tools →Analyze →AnalyzeTable)) Несмотря на то, что теоретически это хорошая идея, данное средство не слиш­ком полезно. Гораздо полезнее, если вам понятна проблема дублирования данных, выявления дублирующихся данных и с самого начала создание хорошо спроектированных БД.