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

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

Допустим, вы намерены создать БД, способную управлять продажами в вашем магазине изделий из бисера, сделанных на заказ. Первая составляющая достаточно проста — таблица 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

342

Yoda

MagicPlastic

China

2003

No

$8.99

 

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

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

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

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

ID

Character

Manufacturer

Manu-facturer-Location

Manufacturer-OpeningYear

Manufacturer-Lawsuits

Purchase-Price

342

Yoda

MagicPlastic

China

2003

No

S8.99

343

Dick Cheney

Rebobbiicans

Taiwan

2005

No

S28.75

344

Tiger

Woods

MagicPlastic

China

2003

No

$2.99

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

 

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

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

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

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

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

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

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

ID

Character

Manufacturer

PurchasePrice

342

Yoda

MagicPlastic

$8.99

343

Dick Cheney

Rebobblicans

$28.75

344

Tiger Woods

MagicPlastic

$2.99

 

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

ID

Manufacturer

Location

OpeningYear

Lawsuits

1

MagicPlastic

China

2003

No

2

Rebobbitcans

Taiwan

2005

No

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

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

 

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

 

 

Примечание

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

 

 

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100