Основы работы в Dreamweaver

         

Связи между таблицами


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

Связи не относятся к какой-то конкретной системе управления базами данных, это обязательный компонент не только для Access и MySQL, но и для любой базы данных и, в частности используются при веб-разработке, например, Microsoft SQL Server, Oracle или PostgreSQL.

Понять принцип работы связей проще всего на примере. Для хранения информации о продажах компании применяется электронная таблица Excel. Каждая операция должна храниться в отдельной строке, поэтому электронная таблица содержит следующие столбцы:

f_name l_name str_add city state/prov country postal cred_card subtotal tax total

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

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

Примечание. В электронных магазинах и компаниях, распространяющих товар по каталогам, используются идентификаторы для товара или покупателей. Эти идентификаторы являются уникальными номерами в базе данных компании, соответствующими конкретному покупателю или товару.


На этот раз таблица клиентов будет выглядеть следующим образом:

cust_ID F_name l_name str_addcitystate/provpostalcredit_card
Таблица операций будет выглядеть так:

transaction_IDcust_IDsubtotal tax total
Обе таблицы содержат поле cust_ID. В таблице клиентов поле cust_ID включает уникальные идентификаторы, называемые также первичными ключами (primary key). У каждой записи в таблице всегда существует свой идентификатор, который не повторяется. В таблице могут оказаться два клиента с одним именем, например, Джон Смит, или два одинаковых почтовых индекса 90210. Но благодаря тому, что каждой строке присваивается первичный ключ cust_ID, в таблице обеспечен порядок, предполагающий корректное обновление, удаление и добавление данных.

В таблице покупок одно и то же значение cust_ID, напротив, может повторяться больше одного раза — в зависимости от того, сколько покупок совершил тот или иной клиент. Когда первичный ключ одной таблицы применяется в качестве поля другой, он называется внешним ключом (foreign key). При использовании внешних ключей между таблицами образуются связи (relationships). Они позволяют избавиться от избыточной (дублирующей) информации и сохранить целостность данных.

Примечание. В приведенном примере таблицы являются достаточно простыми. Например, в порядке вещей будет использование третьей таблицы для хранения информации о товаре (инвентарная таблица) с полем product_ID, добавленным в таблицу покупок в качестве внешнего ключа. Помимо этого, в примере подразумевается, что клиент пользуется только одной кредитной картой. Для подгонки базы данных под все эти требования добавляются новые таблицы, поля и связи.

На приведенном ниже рисунке показана взаимосвязь между двумя таблицами, описанными в этом примере. Линия между таблицами обозначает существование между ними связи. Число 1, расположенное слева, означает, что в таблице tbl_customers параметр cust_ID является уникальным, а знак бесконечности, находящийся справа, указывает, что в таблице tbl_transactions одно и то же значение параметра cust_ID может повторяться сколько угодно. Это взаимосвязь относится к типу связи с отношением "один-ко-многим".



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

Совет. Файл с приведенным примером базы данных можно найти на компакт-диске в папке Lesson08/Start/transaction.mdb. Файл сохранен в формате Microsoft Access.


Содержание  Назад  Вперед