Что показывают связи между таблицами
Руководство по проектированию реляционных баз данных (7-9 часть из 15) [перевод]
Продолжение.
Предыдущие части: 1-3, 4-6
7. Связь один-ко-многим.
Я уже показал вам как данные из разных таблиц могут быть связаны при помощи связи по внешнему ключу. Вы видели как заказы связываются с клиентами путем помещения customer_id в качестве внешнего ключа в таблице заказов.
Другой пример связи один-ко-многим – это связь, которая существует между матерью и ее детьми. Мать может иметь множество детей, но каждый ребенок может иметь только одну мать.
(Технически лучше говорить о женщине и ее детях вместо матери и ее детях потому, что, в контексте связи один-ко-многим, мать может иметь 0, 1 или множество потомков, но мать с 0 детей не может считаться матерью. Но давайте закроем на это глаза, хорошо?)
Когда одна запись в таблице А может быть связана с 0, 1 или множеством записей в таблице B, вы имеете дело со связью один-ко-многим. В реляционной модели данных связь один-ко-многим использует две таблицы.
Схематическое представление связи один-ко-многим. Запись в таблице А имеет 0, 1 или множество ассоциированных ей записей в таблице B.
Как опознать связь один-ко-многим?
Если у вас есть две сущности спросите себя:
1) Сколько объектов и B могут относится к объекту A?
2) Сколько объектов из A могут относиться к объекту из B?
Если на первый вопрос ответ – множество, а на второй – один (или возможно, что ни одного), то вы имеете дело со связью один-ко-многим.
Примеры.
Некоторые примеры связи один-ко-многим:
В данном случае все настолько просто, что только поэтому может оказаться трудным понимание. Возьмем последний пример с домами. На улице ведь действительно может быть любое количество домов, но у каждого дома именно на этой улице может быть только одна улица (не берем дома, которые на практике принадлежат разным улицам, возьмем, к примеру, дом в центре улицы). Ведь не может конкретно этот дом быть одновременно в двух местах, на двух разных улицах, а мы говорим не про какой-то абстрактный дом вообще, а про конкретный.
8. Связь многие-ко-многим.
Связь многие-ко-многим – это связь, при которой множественным записям из одной таблицы (A) могут соответствовать множественные записи из другой (B). Примером такой связи может служить школа, где учителя обучают учащихся. В большинстве школ каждый учитель обучает многих учащихся, а каждый учащийся может обучаться несколькими учителями.
Связь между поставщиком пива и пивом, которое они поставляют – это тоже связь многие-ко-многим. Поставщик, во многих случаях, предоставляет более одного вида пива, а каждый вид пива может быть предоставлен множеством поставщиков.
Обратите внимание, что при проектировании базы данных вы должны спросить себя не о том, существуют ли определенные связи в данный момент, а о том, возможно ли существование связей вообще, в перспективе. Если в настоящий момент все поставщики предоставляют множество видов пива, но каждый вид пива предоставляется только одним поставщиком, то вы можете подумать, что это связь один-ко-многим, но… Не торопитесь реализовывать связь один-ко-многим в этой ситуации. Существует высокая вероятность того, что в будущем два или более поставщиков будут поставлять один и тот же вид пива и когда это случится ваша база данных — со связью один-ко-многим между поставщиками и видами пива – не будет подготовлена к этому.
Создание связи многие-ко-многим.
Связь многие-ко-многим создается с помощью трех таблиц. Две таблицы – “источника” и одна соединительная таблица. Первичный ключ соединительной таблицы A_B – составной. Она состоит из двух полей, двух внешних ключей, которые ссылаются на первичные ключи таблиц A и B.
Все первичные ключи должны быть уникальными. Это подразумевает и то, что комбинация полей A и B должна быть уникальной в таблице A_B.
Пример проект базы данных ниже демонстрирует вам таблицы, которые могли бы существовать в связи многие-ко-многим между бельгийскими брендами пива и их поставщиками в Нидерландах. Обратите внимание, что все комбинации beer_id и distributor_id уникальны в соединительной таблице.
Таблицы “о пиве”.
Таблицы выше связывают поставщиков и пиво связью многие-ко-многим, используя соединительную таблицу. Обратите внимание, что пиво ‘Gentse Tripel’ (157) поставляют Horeca Import NL (157, AC001) Jansen Horeca (157, AB899) и Petersen Drankenhandel (157, AC009). И vice versa, Petersen Drankenhandel является поставщиком 3 видов пива из таблицы, а именно: Gentse Tripel (157, AC009), Uilenspiegel (158, AC009) и Jupiler (163, AC009).
Еще обратите внимание, что в таблицах выше поля первичных ключей окрашены в синий цвет и имеют подчеркивание. В модели проекта базы данных первичные ключи обычно подчеркнуты. И снова обратите внимание, что соединительная таблица beer_distributor имеет первичный ключ, составленный из двух внешних ключей. Соединительная таблица всегда имеет составной первичный ключ.
Есть еще одна важная вещь на которую нужно знать. Связь многие-ко-многим состоит из двух связей один-ко-многим. Обе таблицы: поставщики пива и пиво – имеют связь один-ко-многим с соединительной таблицей.
Другой пример связи многие-ко-многим: заказ билетов в отеле.
В качестве последнего примера позвольте мне показать как бы могла быть смоделирована таблица заказов номеров гостиницы посетителями.
Соединительная таблица связи многие-ко-многим имеет дополнительные поля.
В этом примере вы видите, что между таблицами гостей и комнат существует связь многие-ко-многим. Одна комната может быть заказана многими гостями с течением времени и с течением времени гость может заказывать многие комнаты в отеле. Соединительная таблица в данном случае является не классической соединительной таблицей, которая состоит только из двух внешних ключей. Она является отдельной сущностью, которая имеет связи с двумя другими сущностями.
Вы часто будете сталкиваться с такими ситуациями, когда совокупность двух сущностей будет являться новой сущностью.
9. Связь один-к-одному.
В связи один-к-одному каждый блок сущности A может быть ассоциирован с 0, 1 блоком сущности B. Наемный работник, например, обычно связан с одним офисом. Или пивной бренд может иметь только одну страну происхождения.
В одной таблице.
Связь один-к-одному легко моделируется в одной таблице. Записи таблицы содержат данные, которые находятся в связи один-к-одному с первичным ключом или записью.
В отдельных таблицах.
В редких случаях связь один-к-одному моделируется используя две таблицы. Такой вариант иногда необходим, чтобы преодолеть ограничения РСУБД или с целью увеличения производительности (например, иногда — это вынесение поля с типом данных blob в отдельную таблицу для ускорения поиска по родительской таблице). Или порой вы можете решить, что вы хотите разделить две сущности в разные таблицы в то время, как они все еще имеют связь один-к-одному. Но обычно наличие двух таблиц в связи один-к-одному считается дурной практикой.
Примеры связи один-к-одному.
Проект реляционной базы данных – это коллекция таблиц, которые перелинковываются (связываются) первичными и внешними ключами. Реляционная модель данных включает в себя ряд правил, которые помогают вам создать верные связи между таблицами. Эти правила называются “нормальными формами”. В следующих частях я покажу как нормализовать вашу базу данных.
Какой же вид связи вам нужен?
А если есть некие данные, которые могу быть присвоены любому человеку, то имеем дело со связью многие-ко-многим. Например, есть таблица со списком людей и мы хотим хранить информацию о том, какие страны посетил каждый человек. В данном случае имеется две сущности: люди и страны. Любой человек может посетить любое количество стран равно, как и любая страна может быть посещена любым человеком. Т.е., в данном случае, страна не является уникальными данными для конкретного человека и может использоваться повторно.
В таких случаях использование связи многие-ко-многим с использованием трех таблиц и с хранением общей информации централизованно очень удобно. Ведь если общие данные меняются, то для того, чтобы информация в базе данных соответствовала действительности достаточно подправить ее только в одном месте, т.к. хранится она только в одном месте (таблице), в остальных таблицах имеются лишь ссылки на нее.
А когда у вас есть набор уникальных данных, которые имеют отношение только друг к другу, то храните все в одной таблице. Ваш выбор – связь один-к-одному. Например, у вас есть небольшая коллекция автомобилей и вы хотите хранить информацию о них (цвет, марка, год выпуска и пр.).
Руководство по межтабличным связям
Одной из целей создания хорошей структуры базы данных является устранение избыточности (повторения) данных. Для этого нужно распределить данные по нескольким отдельным тематически организованным таблицам, чтобы каждый факт был представлен один раз. В приложении Access будет предоставлен способ сбора разбросанных данных — это делается путем помещения общих полей в связанные таблицы. Чтобы корректно выполнить это действие, нужно понять взаимосвязи между таблицами и описать эти взаимосвязи в базе данных.
В этой статье
Введение
После создания таблицы для каждой темы в базе данных нужно предоставить приложению Accessсредства, с помощью которых можно будет при необходимости объединять сведения. Это делается путем создания общих полей в связанных таблицах и настройки связей между таблицами. После этого можно создавать запросы, формы и отчеты, одновременно отображающие сведения из нескольких таблиц. Например, приведенная ниже форма содержит сведения из нескольких таблиц:
1. Эта форма содержит данные из таблицы клиентов,
4. и сведений о заказах.
Имя клиента в поле Плательщик получено из таблицы «Клиенты», значения кода заказа и даты заказа — из таблицы «Заказы», наименование товара — из таблицы «Товары», а цена и количество — из таблицы «Заказано». Чтобы можно было передать данные в форму, эти таблицы связаны друг с другом несколькими способами.
В приведенном примере поля в таблицах должны быть согласованы таким образом, чтобы отображать сведения об одном и том же заказе. Это согласование осуществляется путем установления связей между таблицами. Связь между таблицами устанавливает отношения между значениями в ключевых полях — часто между полями, имеющими одинаковые имена в обеих таблицах. В большинстве случаев с первичным ключом одной таблицы, являющимся уникальным идентификатором каждой записи, связывается внешний ключ другой таблицы. Например, для связывания сотрудников с заказами, за которые они отвечают, можно создать связь между полями «Код сотрудника» в таблицах «Сотрудники» и «Заказы».
1. Поле «Код сотрудника» отображается в двух таблицах: как первичный ключ.
2. и как внешний ключ.
Типы связей между таблицами
В Access есть три типа связей между таблицами.
Рассмотрим базу данных, в которой учитываются заказы, включающую таблицы «Клиенты» и «Заказы» в качестве примера. Клиент может разместить любое количество заказов. Следовательно, у любого клиента, представленного в таблице «Клиенты», может быть много заказов, представленных в таблице «Заказы». Поэтому связь между таблицами «Клиенты» и «Заказы» — это отношение «один-ко-многим».
Чтобы создать отношение «один-ко-многим» в структуре базы данных, добавьте первичный ключ на стороне «один» в таблицу на стороне «многие» в виде дополнительного поля или полей. В данном примере необходимо добавить новое поле — поле «Код» из таблицы «Клиенты» — в таблицу «Заказы» и назвать его «Код клиента». После этого Access сможет использовать номер «Код клиента» из таблицы «Заказы» для поиска клиента каждого заказа.
Рассмотрим связь между таблицами «Товары» и «Заказы». Отдельный заказ может включать несколько товаров. С другой стороны, один товар может входить в несколько заказов. Таким образом, для каждой записи в таблице «Заказы» может существовать несколько записей в таблицы «Товары». Таким образом, для каждой записи в таблице «Заказы» может существовать несколько записей в таблице «Заказы». Эта связь называется отношением «многие-ко-многим». Обратите внимание, что для определения существующей схемы отношений «многие ко многим» между вашими таблицами, очень важно рассматривать обе стороны отношений.
Чтобы представить связь «многие-ко-многим», нужно создать третью (связующую) таблицу, в которой она разбивается на две связи «один-ко-многим». Первичные ключи двух таблиц вставляются в третью таблицу. В результате в третьей таблице сохраняются все экземпляры связи. Например, таблицы «Заказы» и «Продукты» имеют связь «многие-ко-многим», определяемую путем создания двух связей «один-ко-многим» в таблице «Заказано». В одном заказе может быть много продуктов, и каждый продукт может быть указан во многих заказах.
При отношении «один-к-одному» каждая запись в первой таблице может иметь не более одной связанной записи во второй таблице, и наоборот. Отношения этого типа используются нечасто, поскольку обычно сведения, связанные таким образом, хранятся в одной таблице. Отношение «один-к-одному» используется для разделения таблицы, содержащей много полей, с целью отделения части таблицы по соображениям безопасности, а также с целью сохранения сведений, относящихся к подмножеству записей в главной таблице. После определения такого отношения у обеих таблиц должно быть общее поле.
Зачем создавать связи между таблицами?
Связи между таблицами можно создать непосредственно с помощью окна «Схема данных» или путем перетаскивания поля из области Список полей. Access использует связи между таблицами для того, чтобы решить, как связать таблицы для использования их в объекте базы данных. Существует несколько причин для создания связей между таблицами перед созданием других объектов базы данных (форм, запросов, отчетов).
Связи между таблицами предоставляют сведения для структурирования запросов
Для работы с записями из нескольких таблиц часто приходится создавать запросы, соединяющие таблицы. Запрос сопоставляет значения в поле первичного ключа первой таблицы с полем внешнего ключа второй таблицы. Например, чтобы получить строки, в которых перечисляются все заказы для каждого из клиентов, можно создать запрос, соединяющий таблицу «Клиенты» с таблицей «Заказы» на основе поля «Код клиента». В окне «Схема данных» можно вручную указать поля для соединения. Но если связь между таблицами уже существует, Access использует соединение по умолчанию на основе существующей связи между таблицами. Кроме того, при использовании одного из мастеров запросов Access использует сведения об уже определенных связях между таблицами, чтобы предоставить пользователю выбор и подставить в параметры свойств соответствующие значения по умолчанию.
Связи между таблицами предоставляют сведения для структурирования форм и отчетов
При создании формы или отчета в Access используются сведения об уже определенных межтабличных связях, чтобы предоставить пользователю выбор и предварительно заполнить параметры свойств соответствующими значениями по умолчанию.
Связи между таблицами — это та основа, с помощью которой можно обеспечить целостность данных, чтобы в базе данных не было потерянных записей. Потерянная запись — это запись со ссылкой на несуществующую запись (например, запись заказа со ссылкой на отсутствующую запись клиента).
При создании базы данных сведения распределяются по таблицам, в каждой из которых есть первичный ключ. После этого к связанным таблицам добавляются внешние ключи, имеющие ссылки на первичные ключи. Эти пары из внешнего и первичного ключей формируют основу для связей между таблицами и многотабличных запросов. Поэтому важно, чтобы ссылки «внешний ключ — первичный ключ» оставались синхронизированными. Целостность данных, которая зависит от связей в таблице, гарантирует, что ссылки остаются синхронизированными.
Понятие о целостности данных
При создании базы данных сведения распределяются по множеству тематически организованных таблиц, чтобы свести к минимуму избыточность данных. После этого в Access предоставляются средства сбора разбросанных данных путем создания в связанных таблицах общих полей. Например, чтобы создать связь «один-ко-многим», добавьте первичный ключ из таблицы на стороне «один» как дополнительное поле в таблицу на стороне «многие». Чтобы соединить данные, Access подставляет значение из таблицы на стороне «многие» в соответствующее поле таблицы на стороне «один». Таким образом, значения таблицы на стороне «многие» связаны с соответствующими значениями на стороне «один».
Предположим, между таблицами «Грузоотправители» и «Заказы» существует связь «один-ко-многим», и нужно удалить грузоотправителя. Если у грузоотправителя, которого нужно удалить, есть заказы в таблице «Заказы, они станут потерянными записями после удаления записи грузоотправителя. В таблице «Заказы» останется код грузоотправителя, но он будет недействителен, поскольку запись, на которую он ссылается, уже не существует.
Задача сохранения целостности данных состоит в предотвращении появления потерянных записей и поддержании ссылок в синхронизированном состоянии, чтобы описанная выше гипотетическая ситуация никогда не возникла.
Обеспечение целостности данных включается для конкретного отношения между таблицами. После активации, Access будет отклонять любые операции, нарушающие целостность данных для этой межтабличной связи. Это означает, что Access будет отклонять как любые обновления, изменяющие целевой объект ссылки, так и удаление такого целевого объекта. Возможно, у вас может быть полностью допустимая потребность в изменении первичного ключа для поставщика, у которого есть заказы в таблице «Заказы». В этом случае необходимо, чтобы Access выполнил автоматическое обновление всех задействованных строк в рамках одной операции. Таким образом, Access гарантирует, что обновление будет полностью завершено, а база данных не будет находиться в несогласованном состоянии, когда некоторые строки обновлены, а другие — нет. Для этого в Access имеется параметр Каскадное удаление связанных записей. Если при включении обеспечения целостности данных был включен параметр Каскадное удаление связанных полей, то при последующем обновлении первичного ключа Access автоматически обновляет все связанные с ним поля.
Может понадобиться удалить строку и все связанные записи — например, запись грузоотправителя и все связанные с ним заказы. Для этого в Access имеется параметр Каскадное удаление связанных записей. Если при обеспечении целостности данных выбрать параметр Каскадное удаление связанных записей, а затем удалить запись на стороне первичного ключа в отношении, Access автоматически удалит все записи со ссылкой на первичный ключ.
Просмотр связей между таблицами
Чтобы просмотреть межтабличные связи, щелкните Схема данных на вкладке Работа с базами данных. Откроется окно «Схема данных», в котором будут отображены все существующие связи. Если связи еще не были определены или это окно открывается впервые, приложение Access предложит добавить в окно таблицу или запрос.
Вызов окна «Схема данных»
Щелкните «Файл», выберите«Открыть», а затем выберите и откройте базу данных.
На вкладке Работа с базами данных в группе Отношения нажмите кнопку Схема данных.
На вкладке Конструктор в группе Связи нажмите кнопку Все связи.
Будут отображены все связи, определенные в базе данных. Обратите внимание на то, что скрытые таблицы (таблицы, для которых установлен флажок скрытый в диалоговом окне Свойства) и их отношения не отображаются, если в диалоговом окне Параметры переходов не выбран параметр Показывать скрытые объекты.
Связь между таблицами представляется как линия между таблицами в окне «Схема данных». Связь, не обеспечивающая целостность данных, отображается как тонкая линия между общими полями, поддерживающими связь. Если выбрать связь, щелкнув линию, то линия станет жирной. Если обеспечить целостность данных для этой связи, линия станет толще на концах. Кроме того, над жирной частью линии с одной стороны связи будет отображаться цифра 1, а с другой стороны — символ бесконечности ( ∞).
Когда открыто окно «Схема данных», на ленте доступны указанные ниже команды.
На вкладке Конструктор в группе Сервис
На вкладке Конструктор в группе Отношения
Добавление таблиц (добавление таблицы в Access 2013 Позволяет показывать в окне «Отношения» выбор таблиц.
Связи между таблицами в модели данных
Чтобы сделать анализ данных более емким, создайте связи в разных таблицах. Связь — это соединение между двумя таблицами, которые содержат данные: один столбец в каждой таблице является основой для связи. Чтобы понять, чем полезны связи, представим, что отслеживаются данные для заказов клиентов в бизнесе. Вы можете отслеживать все данные в одной таблице с такой структурой:
Однообъективный зеркальный фотоаппарат
Этот подход может быть эффективным, но он подразумевает хранение множества избыточных данных, таких, как адрес электронной почты клиента для каждого заказа. Хранение данных обходится дешево, но если адрес электронной почты изменился, необходимо убедиться, чтоб была обновлена каждая строка для этого клиента. Одним из решений этой проблемы является разбиение данных на несколько таблиц и задание связей между этими таблицами. Этот подход используется в реляционных базах данных таких, как SQL Server. Например, импортированная база данных может представлять данные заказа, используя три связанные таблицы.
Однообъективный зеркальный фотоаппарат
Связи существуют в модели данных ( та, которую вы создали явным образом или которая Excel автоматически создается от вашего имени при одновременном импорте нескольких таблиц. Кроме того, вы можете воспользоваться надстройкой Power Pivot для создания модели и управления ею. Дополнительные сведения см. в статье Создание модели данных в Excel.
Во время импорта таблицы из одной базы данных с помощью надстройки Power PivotPower Pivot может обнаруживать связи между таблицами, основанными на столбцах, заключенных в [квадратные скобки], и воспроизводить эти связи в модели данных, создаваемой в фоновом режиме. Дополнительные сведения см. в разделе Автоматическое обнаружение и вывод связей этой статьи. Если таблицы импортируются из нескольких источников, можно вручную создать связи, как это описано в статье Создание связей между двумя таблицами.
Связи основываются на столбцах в каждой таблице, содержащих одинаковые данные. Например, можно связать таблицу «Клиенты» с таблицей «Заказы», если каждая из них содержит столбец с ИД клиента. В данном примере имена столбцов одинаковы, но это не является обязательным условием. Один столбец может называться CustomerID, а другой — CustomerNumber, при условии, что все строки в таблице Orders содержат идентификатор, который также хранится в таблице Customers.
В реляционной базе данных существует несколько типов ключей. Ключ обычно является столбцом со специальными свойствами. Знание назначения каждого ключа помогает в управлении моделью данных с несколькими таблицами, предоставляющей данные для сводной таблицы, сводной диаграммы или отчета Power View.
Хотя существует множество типов ключей, они являются самыми важными в нашем предназначении:
Первичный ключ: однозначно определяет строку в таблице, например CustomerID в таблице Customers.
Альтернативный ключ (или первичный ключ): уникальный столбец, который не является первичным ключом. Например, таблица Employees может хранить идентификатор работника и номер карточки социального страхования, при том что оба они являются уникальными.
Внешнее ключ: столбец, который ссылается на уникальный столбец другой таблицы, например CustomerID в таблице Orders, который ссылается на CustomerID в таблице Customers.
В модели данных первичный или резервный ключ называется связанным столбцом. Если таблица содержит первичный и резервный ключ, любой из них можно использовать как основу для связи между таблицами. Внешний ключ называется исходным столбцом или просто столбцом. В нашем примере связь между customerID в таблице Orders (столбцом) и CustomerID в таблице Customers (столбцом подытов) будет определена. Если данные импортируются из реляционной базы данных, по умолчанию Excel выбирает внешний ключ из одной таблицы и соответствующий первичный ключ из другой таблицы. Тем не менее для столбца подстановки можно использовать любой столбец, содержащий уникальные значения.
Связь между клиентом и заказом является связью «один-к-многим». Каждый клиент может иметь несколько заказов, однако ни один из заказов не может иметь несколько клиентов. Еще одна важная связь между таблицами — «один к одному». В нашем примере таблица CustomerDiscounts, которая определяет единую ставку дисконтирования для каждого клиента, имеет отношение «один-к-одному» с таблицей Customers.
В этой таблице показаны связи между тремя таблицами (Customers, CustomerDiscountsи Orders):
Примечание: Связи «многие ко многим» не поддерживаются в модели данных. Примером связи «многие ко многим» является прямая связь между таблицами Products и Customers, в которой заказчик может купить много продуктов и одинаковый продукт может быть одновременно куплен несколькими заказчиками.
После создания связи необходимо Excel пересчет всех формул, которые используют столбцы из таблиц в созданной связи. Обработка может занять некоторое время в зависимости от объема данных и сложности связей. Дополнительные сведения см. в теме Пересчет формул.
Модель данных может содержать несколько связей между двумя таблицами. Для точного вычисления Excel требуется один путь от одной таблицы к другой. Поэтому одновременно активной может быть только одна связь между каждой парой таблиц. Хотя другие неактивны, вы можете указать неактивное отношение в формулах и запросах.
В представлении диаграммы активная связь является сплошной линией, а неактивные — пунктирными линиями. Например, в таблице AdventureWorksDW2012 таблица DimDate содержит столбец DateKey, связанный с тремя разными столбцами в таблице FactInternetSales: OrderDate, DueDateи ShipDate. Если есть активная связь между столбцами DateKey и OrderDate, эта связь и будет использоваться по умолчанию в формулах, если не указано иное.
Связь можно создать, если выполняются следующие требования.
Уникальный идентификатор для каждой таблицы
Каждая таблица должна иметь один столбец, однозначно определяющий каждую строку в этой таблице. Такой столбец часто именуется первичным ключом.
Уникальные столбцы подстановки
Значения данных в столбце подстановки должны быть уникальными. Другими словами, столбец не может содержать дубликаты. В модели данных нули и пустые строки эквивалентны пустому полю, которое является самостоятельным значением данных. Это значит, что столбец подстановки не может содержать несколько значений NULL.
Совместимые типы данных
Типы данных в исходном столбце и в столбце подстановки должны быть совместимыми. Дополнительные сведения о типах данных см. в теме Типы данных, поддерживаемые в моделях данных.
В модели данных нельзя создать связь между таблицами, если ключ является составным. Также существует ограничение на создание связей «один к одному» и «один ко многим». Другие типы связей не поддерживаются.
Составные ключи и столбцы подстановки
Составной ключ состоит из нескольких столбцов. Модели данных не могут использовать составные ключи: таблица должна всегда иметь ровно один столбец, однозначно определяя каждую строку в таблице. При импорте таблиц, имеющих существующую связь на основе составного ключа, мастер импорта таблиц в Power Pivot не будет учитывать эту связь, так как ее нельзя создать в модели.
Для создания связи между двумя таблицами, имеющими несколько столбцов, в которых определены первичный и внешние ключи, сначала объедините значения для создания единого ключевого столбца. Это можно сделать перед импортом данных или путем создания вычисляемого столбца в модели данных с помощью надстройки Power Pivot.
Связи «многие ко многим»
Самосоединения и циклы
В модели данных не разрешается использование самосоединений. Самосоединение — это рекурсивная связь таблицы с самой собой. Самосоединения часто используются для определения иерархий типа «родители-потомки». Например, можно настроить самосоединение для таблицы Employees, чтобы создать иерархию, показывающую цепочку управления на предприятии.
Excel не позволяет создавать циклы среди связей в книге. Иными словами, следующий набор связей запрещается.
Таблица 1, столбец «а» к Таблице 2, столбец «f»
Tаблица 2, столбец «f» к Таблице 3, столбец «n».
Таблица 3, столбец «n» к Таблице 1, столбец «a».
При попытке создания связи, которая приведет к образованию цикла, выдается ошибка.
Одно из преимуществ импорта данных с помощью надстройки Power Pivot заключается в том, что Power Pivot иногда может обнаруживать связи и создавать новые связи в модели данных, создаваемой в Excel.
При импорте нескольких таблиц Power Pivot автоматически определяет все существующие связи между ними. Кроме того, при создании сводной таблицы Power Pivot анализирует данные в таблицах. Он обнаруживает возможные связи, которые не были определены, и предлагает столбцы, которые можно включить в них.
Алгоритм обнаружения на основании статистических данных о значениях и метаданных столбцов формирует выводы о вероятности связей.
Типы данных во всех связанных столбцах должны быть совместимыми. Для автоматического обнаружения поддерживаются только целочисленные и текстовые типы данных. Дополнительные сведения о типах данных см. в разделе Типы данных, поддерживаемые вмоделях данных.
Для успешного обнаружения связи количество уникальных ключей в столбце подстановки должно превышать количество значений в таблице на стороне «многие». Другими словами, ключевой столбец на стороне «многие» связи не должен содержать значений, не содержащихся в ключевом столбце таблицы подстановки. Например, предположим, что имеется таблица, в которой перечислены продукты и их идентификаторы (таблица подстановки), а также таблица продаж, содержащая данные продаж всех продуктов (сторона «многие» связи). Если записи продаж содержат идентификатор продукта, не имеющего соответствующий идентификатор в таблице Products, связь нельзя создать автоматически, но можно создать вручную. Для обеспечения обнаружения связи с помощью Excel необходимо сначала обновить таблицу подстановки Product с использованием идентификаторов недостающих продуктов.
Убедитесь, что имя ключевого столбца на стороне «многие» совпадает с именем ключевого столбца в таблице подстановки. Имена не должны быть абсолютно идентичны. Например, в бизнес-параметрах часто имеются варианты имен столбцов, которые содержат фактически одинаковые данные: «ИД сотрудника», «ИД сотрудника», «ИД сотрудника», «EMP_ID»и так далее. Алгоритм выявляет похожие имена и задает более высокие значения вероятности столбцам, имена которых похожи или полностью совпадают. Поэтому, чтобы увеличить вероятность создания связи, можно попытаться переименовать столбцы в импортируемых данных, подобрав имена чем-то похожие на имена строк в существующих таблицах. Если Excel находит несколько возможных связей, связь не создается.
Эти сведения помогают понять, почему не удалось выявить все связи и какие изменения в метаданных (именах полей и типах данных) могут повысить эффективность автоматического обнаружения связей. Дополнительные сведения см. в разделе Устранение неполадок в связях.
Автоматическое обнаружение именованных наборов
Связи между именованными наборами и связанными полями в сводной таблице не обнаруживаются автоматически. Такие связи можно создать вручную. При необходимости использования автоматического обнаружения связей удалите каждый именованный набор и добавьте отдельные поля из именованного набора непосредственно в сводную таблицу.
В некоторых случаях связи между таблицами автоматически объединяются в цепочки. Например, если создать связь между первыми двумя наборами таблиц, указанных ниже, то определяется наличие связи между другими двумя таблицами и эта связь устанавливается автоматически.
Products и Category — связь создается вручную
Category и SubCategory — связь создается вручную
Products и SubCategory — связь определяется автоматически
Для автоматического объединения связей в цепочки эти связи должны идти в одном направлении, как показано выше. Если исходные связи были установлены, например между таблицами Sales и Products, а также между Sales и Customers, то связь не выводится. Это вызвано тем, что связь между таблицами Products и Customers является связью «многие ко многим».