Краткое содержание 29 Об этих стрелках 30 о сочетаниях клавиш 32 о щелчках кнопкой мыши 33 Примеры 33
 Скачать 19.64 Mb.
|
|
Глава 5 Связывание таблиц с помощью отношений Таблицы, которые вы видели до сих пор, "жили" уединенно, независимо друг от друга. В реальных БД не найти подобной изоляции. В практических БД таблицы соединены друг с другом паутиной связей. Допустим, вы намерены создать БД, способную управлять продажами в вашем магазине изделий из бисера, сделанных на заказ. Первая составляющая достаточно проста — таблица Products (изделия), в которой перечислены ваши товары. Но для продолжения вам придется собрать множество дополнительной информации. Проданные изделия из таблицы Products учитываются в таблице Orders (заказы). Товары из таблицы Orders посылаются по почте и фиксируются в таблице Shipments (поставки). Люди из таблицы Customers (клиенты) регистрируются в таблице Invoices (счета). Во всех этих таблицах — Products, Orders, Shipments, Customers и Invoices — содержатся порции связанной информации. В результате, если вы хотите получить ответ на обычный вопрос (например, "Сколько должна Джейн Мэлон (Jane Malone)?" или "Сколько париков из бисера продано на прошлой неделе?"), придется заглянуть в несколько таблиц. На основании полученных вами знаний вы уже можете разработать проект такой БД. Но связи порождают возможность противоречивой информации, А если несоответствие проникнет в БД, вы уже не сможете доверять ей, как прежде. В данной главе вы узнаете о том, как явно устанавливать связи между таблицами. Этот процесс позволит избежать распространенных ошибок, таких как противоречивость данных. Кроме того, он предоставляет мощное средство просмотра связанной информации в нескольких таблицах. Основы отношений между таблицами Одна из основных целей любой БД — разбить информацию на четкие управляемые порции. В хорошо спроектированной БД процесс завершается созданием большого числа таблиц. Несмотря на то, что в каждой из них записано что-то свое, вам часто придется путешествовать из одной таблицы в другую для того, чтобы получить всю нужную информацию. Для того чтобы лучше понять отношения (отнюдь не романтический их вариант), рассмотрим пример. В следующем разделе представлены два способа добавления данных в БД о куклах-болванчиках: в одном есть риск избыточных данных, а другой решает эту проблему за счет надлежащего использования отношения или связи. Избыточные данные в противоположность связанным Вернемся к таблице Dolls, созданной в главе 1 для хранения списка кукол-болванчиков. Одна из порций информации данной таблицы — поле Manufacturer (изготовитель), в котором записано имя компании, изготовившей каждую куклу. Несмотря на то, что это достаточно простая деталь, может оказаться, что для точной оценки стоимости куклы-болванчика вам понадобится немного больше информации о процессе изготовления. Возможно, вы захотите узнать, где находится компания-изготовитель, как долго она существует и вынуждена ли отбиваться от судебных исков разъяренных покупателей. Если вы ленивы, то можете вставить всю эту информацию в таблицу Dolls так, как показано в табл. 5.1 (затемненные столбцы — новые). Таблица 5.1. Сведения об изготовителе
В первый момент вас, возможно, обеспокоит загроможденность таблицы всеми этими полями. Не волнуйтесь — это жизнь, в таблицы должны быть включены все важные детали, поэтому они порой сильно разрастаются. (Это правило проектирования БД, описанное в разд. "Правило 3. Храпите все детали в одном месте" главы 2.) Пусть громоздкость вас не беспокоит. Можно воспользоваться такими средствами, как скрытие столбцов (см. разд. "Скрытие столбцов " главы 3) для устранения полей, которые вас не интересуют. Несмотря на то что, что обилие столбцов — не повод для беспокойства, в этом примере кроется другая проблема — избыточные данные. Подобная ситуация кажется невинной, но если добавить несколько новых строк, все окажется не столь безобидно (табл. 5.2). Таблица 5.2. Сведения о производителе после добавления строк
Как только у вас появятся две куклы-болванчика, изготовленные одной компанией (в данном случае MagicPlastic), вы введете дублирующиеся данные — беда всех плохих БД. (Их можно распознать как нарушение правила № 4 хорошего проекта БД, описанного в разд. "Правило 4. Избегайте дублирования данных" главы 2.) Потенциальные проблемы нескончаемы.
« Если вы хотите хранить в вашей БД еще больше сведений, касающихся изготовителя (например, контактный телефон), вам придется обновлять вашу таблицу Dolls и корректировать каждую отдельную запись. Ваша семья может вас не увидеть в течение нескольких недель. ■ Если же понадобится информация об изготовителях (а не о куклах), вы потерпите неудачу. Например, вам не удастся распечатать список всех изготовителей кукол-болванчиков в Китае (по крайней мере, не так легко, как хотелось бы). Проблема вполне очевидна. Из-за желания хранить слишком много подробностей в одном месте в одной таблице объединяется информация, которую лучше всего хранить в двух отдельных таблицах. Для исправления этого проекта нужно создать две таблицы со связанными данными. Например, можно сформировать таблицу Dolls, как показано втабл. 5.3, и отдельную таблицу Manufacturers с подробными данными об изготовителях (табл. 5.4). Таблица 5.3. Данные в таблице Dolls
Таблица 5.4. Данные в таблице Manufacturers
Этот проект позволяет легко работать отдельно с двумя типами информации (куклы и изготовители). Он также устраняет риск дублирования. В данном простом примере преимущества незначительны, но в таблице с сотнями или тысячами записей о куклах-болванчиках (и намного меньшим числом изготовителей) разница весьма существенна. Теперь если компания MagicPlastic переезжает в Южную Корею, вам нужно обновить данные поля Location только в одной записи, вместо множества экземпляров в перегруженной таблице Dolls. Вы также гораздо легче сможете формировать запросы (см. главу 6), объединяющие данные подходящими и удобными способами. (Например, вы сможете подсчитать, сколько потратили на всех кукол от компании MagicPlastic, и сравнить эту сумму с затратами на кукол, созданных другими компаниями.) Примечание В программу Access включено средство, пытающееся отследить дублирующиеся данные в таблице и помочь вам разделить поля на две связанные таблицы. (Для знакомства с ним выберите Работа с базами данных → Анализ → Анализ таблицы (Database Tools → Analyze → AnalyzeTable)) Несмотря на то, что теоретически это хорошая идея, данное средство не слишком полезно. Гораздо полезнее, если вам понятна проблема дублирования данных, выявления дублирующихся данных и с самого начала создание хорошо спроектированных БД. Совпадающие поля: связующее звено отношения Данная БД о куклах-болванчиках — пример отношения. Верный его признак — две таблицы с одинаковыми полями. В данном случае такой объект — поле Manufacturer, существующее и в таблице Dolls, и в таблице Manufacturers. Примечание В приведенном примере у полей, связывающих две таблицы, одно и то же имя Manufacturer в обеих таблицах. Но это не обязательно. У таких полей могут быть разные имена при условии, что у них один тип данных. С помощью этих связанных полей можно начать с записи в одной таблице и затем найти связанную информацию в другой таблице. Далее объясняется принцип действия.
Другими словами, взаимосвязь таблиц предоставляет больше гибкости, позволяя задавать больше вопросов, касающихся ваших данных, и получать более полные ответы. Связывание с помощью столбца Код (ID) В предыдущем примере таблицы Dolls и Manufacturers связаны друг с другом полем Manufacturer, в котором хранится имя компании-изготовителя. Такой выбор кажется оправданным в данном проекте — до тех пор, пока вы не задумаетесь на пару минут о возможных ошибках. Специалисты по проектированию БД известны тем, что тратят недели на обдумывание неотвратимых бедствий. В данном случае есть две потенциальные проблемы.
Возможно, вы узнали эти проблемы, поскольку они аналогичны тем, с которыми вы сталкивались, когда речь шла о выборе первичного ключа (см. разд. "Первичный ключ "главы 2). Как вы уже знаете, трудно найти данные, гарантированно уникальные и неизменные. Вместо риска возникновения проблем надежнее положиться на поле с типом данных Счетчик, содержащее код (ID number), генерируемый программой Access. Интересно, что тот же подход применяется при связывании таблиц. Для ссылки на запись в другой таблице не следует использовать любую порцию данных — вместо этого нужно применять уникальный код, указывающий на нужную запись. В табл. 5.5 приведена переконструированная таблица Dolls, ставшая более корректной за счет замены поля Manufacturer полем ManufacturerID. Таблица 5.5. Данные в таблице Dolls после ее реконструирования
Если вы вернетесь назад и посмотрите на таблицу Manufacturers (см. табл. 5.4), то быстро обнаружите, что изготовитель с кодом или идентификационным номером 1 — это компания MagicPlastic. Этот проект — универсальный стандарт БД. Но у него есть два явных недостатка: ■ пользователь, вставляющий записи в таблицу Dolls, возможно, не знает кодов всех изготовителей;
Для решения обеих проблем воспользуйтесь подстановкой. Подстановки отображают соответствующие сведения об изготовителе в таблице Dolls, а также позволяют выбрать изготовителя из списка в тот момент, когда добавляется запись или корректируется поле ManufacturerlD. (Вы узнали, как использовать подстановки со списками констант в разд. "Создание простого списка подстановок, состоящего из констант" главы 4. О том, как применять подстановки, сведя вместе связанные таблицы, такие как Dolls и Manufacturers, будет рассказано в разд. "Поиск в связанных таблицах" далее в этой главе.) |