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



Мы поможем в написании ваших работ!


Мы поможем в написании ваших работ!



Мы поможем в написании ваших работ!


ЗНАЕТЕ ЛИ ВЫ?

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



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

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

 

 



Последнее изменение этой страницы: 2016-08-14; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.235.184.215 (0.01 с.)