Таблица отношений: Соционика. 16 Отношоний между типами. Типы интертипных отношений в соционике. Официальный сайт Гуманитарной соционики Гуленко. Таблица отношений между социотипами. Дуальные отношения, Есенин отношения соционика. Соционика таблица отношений между социотипами

Таблица в класс отношений—Справка | Документация

• Краткая информация
• Использование
• Синтаксис
• Пример кода
• Параметры среды
• Информация о лицензиях

Краткая информация

Создает класс атрибутивных отношений из таблицы-источника, таблицы-адресата и таблицы отношения.

Использование

• Этот инструмент создает таблицу в базе данных, содержащую выбранные поля атрибутов из таблицы отношений. Эти поля используются для хранения атрибутов отношения, которые не относятся ни к исходному классу, ни к классу назначения. Например, в базе данных участков у вас может быть класс отношений между участками и владельцами, где владельцы «владеют» участками, а участки «принадлежат» владельцам. Доля во владении может храниться как атрибут этого отношения.

• Простые или равноправные отношения – это отношения между двумя или более объектами в базе данных, которые существует независимо друг от друга. Например, в железнодорожной сети, могут быть железнодорожные стрелки, имеющие один или более связанный с ними семафор. Однако, железнодорожная стрелка может существовать без семафора, а семафоры могут существовать в железнодорожной сети и там, где нет стрелок. Простые отношения могут иметь кардинальность «один к одному», «один ко многим» или «многие ко многим».

• Сложные отношения – это отношения, в которых существование одного объекта контролирует существования связанных с ним объектов. Например, электрические столбы несут на себе трансформаторы, а трансформаторы установлены на столбах. После удаления столба, сообщение об удалении распространяется и на связанные с ним трансформаторы, которые удаляются из класса трансформаторов. Сложные отношения всегда «один ко многим».

• Описания прямого и обратного отношения поясняют отношение, связывающее один объект с другим. Описание прямого отношения описывает отношение класса-источника к классу-адресату. В примере столб-трансформатор прямой подписью пути может быть: «Столбы поддерживают трансформаторы». Описание обратного отношения поясняет отношение класса-адресата к классу-источнику. В примере со столбом и трансформатором описание обратного отношения могло бы быть таким: «Трансформаторы устанавливаются на столбах».

• Классы отношений также могут быть созданы в ArcCatalog. В контекстном меню базы геоданных выберите элемент Создать (New) > Класс отношений (Relationship Class).

• У параметра Атрибутивные поля (Attribute Fields) кнопка Добавить поле (Add Field) используется только в ModelBuilder. В ModelBuilder, если предыдущий инструмент не был запущен или его производные данные не существуют, параметр Атрибутивные поля (Attribute Fields) не заполняются именами полей. Кнопка Добавить поле (Add Field) позволяет добавлять нужные поля, так что вы можете установить все параметры в диалоговом окне Таблица в класс отношений (Table To Relationship Class) и продолжить построение модели.

Синтаксис

TableToRelationshipClass(origin_table, destination_table, out_relationship_class, relationship_type, forward_label, backward_label, message_direction, cardinality, relationship_table, attribute_fields, origin_primary_key, origin_foreign_key, destination_primary_key, destination_foreign_key)

Параметр	Объяснение	Тип данных
origin_table	Таблица или класс пространственных объектов, который будет связан с таблицей-адресатом.	Table View
destination_table	Таблица или класс пространственных объектов, который будет связан с таблицей-источником.	Table View
out_relationship_class	Создаваемый класс отношений.	Relationship Class
relationship_type	Тип отношения, которое должно быть установлено между источником и адресатом. SIMPLE —Отношение, при котором каждый из объектов не зависит от другого (отношение «равный-с-равным»). Это значение используется по умолчанию. COMPOSITE —Отношение, при котором продолжительность существования одного объекта управляет продолжительностью существования связанного с ним объекта (отношение «родитель-потомок»).	String
forward_label	Подпись, определяющая отношение источника к адресату.	String
backward_label	Подпись, определяющая отношение адресата к источнику.	String
message_direction	Направление сообщений, которые будут пересылаться между объектами, участвующими в отношении. Например, в отношении между столбами и трансформаторами, при удалении столба, он отправляет сообщение связанным с ним объектам трансформатора, информируя их о его удалении. Нет —Сообщения не пересылаются. Это значение используется по умолчанию. FORWARD —Сообщения пересылаются от источника к адресату. BACKWARD —Сообщения пересылаются от адресата к источнику. BOTH —Сообщения пересылаются от источника к адресату и от адресата к источнику.	String
cardinality	Кардинальность отношения между источником и адресатом. ONE_TO_ONE —Каждый объект исходной таблицы или класса объектов может быть связан с одним объектом таблицы-адресата или класса объектов адресата или не связан вовсе. Это значение используется по умолчанию. ONE_TO_MANY —Каждый объект исходной таблицы или класса объектов может быть связан с несколькими объектами в таблице-адресате или адресном классе объектов. MANY_TO_MANY —Несколько объектов исходной таблицы или класса объектов могут быть связаны с несколькими объектами в таблице-адресате или адресном классе объектов.	String
relationship_table	Таблица, содержащая атрибуты, которые будут добавлены к классу отношений.	Table View
attribute_fields [attribute_fields,…]	Поля, содержащие значения, которые будут добавлены к классу отношений.	Field
origin_primary_key	Поле в таблице-источнике, которое будет использоваться для создания отношения. Обычно это поле идентификатора объектов.	String
origin_foreign_key	Имя поля, содержащего внешний ключ в таблице отношения, которое ссылается на поле первичного ключа в классе-источнике.	String
destination_primary_key	Поле в таблице-адресате, которое будет использоваться для создания отношения. Обычно это поле идентификатора объектов.	String
destination_foreign_key	Поле в таблице отношений, которое соответствует полю Первичный ключ (Primary Key) таблицы-адресата.	String

Пример кода

TableToRelationshipClass Пример (окно Python)

На следующем скрипте окна Python демонстрируется, как использовать инструмент Таблица в класс отношений (Table To Relationship Class).

import arcpy
arcpy.env.workspace = "C:/data/Montgomery.gdb"
arcpy.TableToRelationshipClass_management("owners", "Parcels", "ownersParcels_RelClass",
                                          "SIMPLE", "Owns", "Is Owned By", "BACKWARD",
                                          "MANY_TO_MANY", "owners", ["OWNER_PERCENT", "DEED_DATE"],
                                          "OBJECTID", "owner_id", "OBJECTID", "parcel_id")

TableToRelationshipClass Пример (автономный скрипт)

Создание класса отношений с атрибутами между классом объектов участков и таблицей с информацией о владельцах.

# Name: TableToRelationshipClass.py
# Description: Create an attributed relationship class between parcels
#              feature class and table with owner information
# Author: ESRI
# import system modules 
import arcpy
from arcpy import env
# Set environment settings
env.  workspace = "C:/data"
# Copy owners.dat to file gdb table, since both tables to be related
# must be in the same database
ownerDat = "owners.dat"
ownerTbl = "Montgomery.gdb/owners"
arcpy.CopyRows_management(ownerDat, ownerTbl)
# Create attributed relationship class between 'parcel' parcel layer
# and 'owner' table with additional parcel owner information
parcel = "Montgomery.gdb/Parcels"
relClass = "Montgomery.gdb/parcelowners_RelClass"
forLabel = "Owns"
backLabel = "Is Owned By"
attributeFields = ["OWNER_PERCENT", "DEED_DATE"]
originPK = "OBJECTID"
originFK = "owner_ID"
destinationPK = "OBJECTID"
destinationFK = "parcel_ID"
arcpy.TableToRelationshipClass_management(ownerTbl, parcel, relClass, "SIMPLE",
                                          forLabel, backLabel, "BACKWARD", "MANY_TO_MANY",
                                          ownerTbl, attributeFields, originPK, originFK,
                                          destinationPK, destinationFK)

Параметры среды

• Автоподтверждение
• Текущая рабочая область

Информация о лицензиях

• Basic: Нет
• Standard: Да
• Advanced: Да

Связанные разделы

Таблица в класс отношений (Управление данными)—ArcGIS Pro

Подпись	Описание	Тип данных
Таблица-источник	Таблица класса пространственных объектов, которая будет связана с таблицей-адресатом.	Table View
Таблица-адресат	Таблица или класс объектов, который будет связан с исходной таблицей.	Table View
Выходной класс отношений	Создаваемый класс отношений.	Relationship Class
Тип отношений	Определяет тип отношений, который будет создан между таблицей-источником и таблицей-адресатом. Простое—Каждый объект не зависит от другого (отношения равный-с-равным). Это значение по умолчанию Сложное—Существование одного объекта зависит от существования связанного объекта (родительско-дочерние отношения).	String
Надпись прямого отношения	Надпись, описывающая отношение, как оно проходит от класса объектов или таблицы — источника к классу объектов или таблице — адресату.	String
Надпись обратного отношения	Надпись, описывающая отношение, как оно проходит от класса объектов или таблицы — адресата к классу объектов или таблице — источнику.	String
Направление сообщений	Определяет сообщения направлений, которые будут передаваться между объектами в отношении. Например, в отношении между столбами и трансформаторами, при удалении столба, он отправляет сообщение связанным с ним объектам трансформатора, информируя их о его удалении. Отсутствует (сообщения не передаются)—Сообщения не будут передаваться. Это значение по умолчанию Вперед (от объекта-источника к объекту-адресату)—Сообщения будут передаваться от источника к адресату. Назад (от объекта-адресата к объекту-источнику)—Сообщения будут передаваться от адресата к источнику. В обоих направлениях—Сообщения будут передаваться от источника к адресату и от адресата к источнику.	String
Кардинальность	Определяет кардинальность отношений между источником и адресатом. Один-к-одному (1:1)—Каждый объект класса объектов или таблицы — источника может быть связан с нулем, либо одним объектом в классе объектов или таблице — адресате. Это значение по умолчанию Один-ко-многим (1:М)—Каждый объект класса объектов или таблицы — источника может быть связан с несколькими объектами в классе объектов или таблице — адресате. Многие-ко-многим (М:N)—Несколько объектов класса объектов или таблицы — источника может быть связан с несколькими объектами в классе объектов или таблице — адресате.	String
Таблица отношения	Таблица, содержащая атрибуты, которые будут добавлены к классу отношений.	Table View
Атрибутивные поля	Имена полей, содержащих значения атрибутов, которые будут добавлены к классу отношений. Поля должны быть представлены в значении параметра Таблица отношений.	Field
Первичный ключ источника	Поле в таблице-источнике, которое будет использоваться для создания отношений.	String
Внешний ключ источника	Имя поля в таблице отношений, которое ссылается на поле Первичного ключа в классе объектов или таблице — источнике. Для классов отношений на основании таблицы эти значения будут использоваться для заполнения отношений в классе отношений, поэтому они не могут быть пустыми.	String
Первичный ключ адресата	Поле в таблице-адресате, которое будет использоваться для создания отношений.	String
Внешний ключ адресата	Имя поля в таблице отношений, которое ссылается на поле Первичного ключа в классе пространственных объектов или таблице — адресате. Для классов отношений на основании таблицы эти значения будут использоваться для заполнения отношений в классе отношений, поэтому они не могут быть пустыми.	String

arcpy.management.TableToRelationshipClass(origin_table, destination_table, out_relationship_class, relationship_type, forward_label, backward_label, message_direction, cardinality, relationship_table, attribute_fields, origin_primary_key, origin_foreign_key, destination_primary_key, destination_foreign_key)

Имя	Описание	Тип данных
origin_table	Таблица класса пространственных объектов, которая будет связана с таблицей-адресатом.	Table View
destination_table	Таблица или класс объектов, который будет связан с исходной таблицей.	Table View
out_relationship_class	Создаваемый класс отношений.	Relationship Class
relationship_type	Определяет тип отношений, который будет создан между таблицей-источником и таблицей-адресатом. SIMPLE—Каждый объект не зависит от другого (отношения равный-с-равным). Это значение по умолчанию COMPOSITE—Существование одного объекта зависит от существования связанного объекта (родительско-дочерние отношения).	String
forward_label	Надпись, описывающая отношение, как оно проходит от класса объектов или таблицы — источника к классу объектов или таблице — адресату.	String
backward_label	Надпись, описывающая отношение, как оно проходит от класса объектов или таблицы — адресата к классу объектов или таблице — источнику.	String
message_direction	Определяет сообщения направлений, которые будут передаваться между объектами в отношении. Например, в отношении между столбами и трансформаторами, при удалении столба, он отправляет сообщение связанным с ним объектам трансформатора, информируя их о его удалении. NONE—Сообщения не будут передаваться. Это значение по умолчанию FORWARD—Сообщения будут передаваться от источника к адресату. BACKWARD—Сообщения будут передаваться от адресата к источнику. BOTH—Сообщения будут передаваться от источника к адресату и от адресата к источнику.	String
cardinality	Определяет кардинальность отношений между источником и адресатом. ONE_TO_ONE—Каждый объект класса объектов или таблицы — источника может быть связан с нулем, либо одним объектом в классе объектов или таблице — адресате. Это значение по умолчанию ONE_TO_MANY—Каждый объект класса объектов или таблицы — источника может быть связан с несколькими объектами в классе объектов или таблице — адресате. MANY_TO_MANY—Несколько объектов класса объектов или таблицы — источника может быть связан с несколькими объектами в классе объектов или таблице — адресате.	String
relationship_table	Таблица, содержащая атрибуты, которые будут добавлены к классу отношений.	Table View
attribute_fields [attribute_fields,…]	Имена полей, содержащих значения атрибутов, которые будут добавлены к классу отношений. Поля должны быть представлены в значении параметра relationship_table.	Field
origin_primary_key	Поле в таблице-источнике, которое будет использоваться для создания отношений.	String
origin_foreign_key	Имя поля в таблице отношений, которое ссылается на поле Первичного ключа в классе объектов или таблице — источнике. Для классов отношений на основании таблицы эти значения будут использоваться для заполнения отношений в классе отношений, поэтому они не могут быть пустыми.	String
destination_primary_key	Поле в таблице-адресате, которое будет использоваться для создания отношений.	String
destination_foreign_key	Имя поля в таблице отношений, которое ссылается на поле Первичного ключа в классе пространственных объектов или таблице — адресате. Для классов отношений на основании таблицы эти значения будут использоваться для заполнения отношений в классе отношений, поэтому они не могут быть пустыми.	String

Пример кода

TableToRelationshipClass, пример (окно Python)

Пример скрипта в окне Python для использования функции TableToRelationshipClass.

import arcpy
arcpy.env.workspace = "C:/data/Montgomery.gdb"
arcpy.TableToRelationshipClass_management("owners", "Parcels", "ownersParcels_RelClass",
                                          "SIMPLE", "Owns", "Is Owned By", "BACKWARD",
                                          "MANY_TO_MANY", "owners", ["OWNER_PERCENT", "DEED_DATE"],
                                          "OBJECTID", "owner_id", "OBJECTID", "parcel_id")

TableToRelationshipClass, пример (автономный скрипт)

Создает класс отношений с атрибутами между классом объектов участков и таблицей с информацией о владельцах.

# Name: TableToRelationshipClass.  py
# Description: Create an attributed relationship class between parcels
#              feature class and table with owner information
# Author: ESRI
# import system modules 
import arcpy
from arcpy import env
# Set environment settings
env.workspace = "C:/data"
# Copy owners.dat to file gdb table, since both tables to be related
# must be in the same database
ownerDat = "owners.dat"
ownerTbl = "Montgomery.gdb/owners"
arcpy.CopyRows_management(ownerDat, ownerTbl)
# Create attributed relationship class between 'parcel' parcel layer
# and 'owner' table with additional parcel owner information
parcel = "Montgomery.gdb/Parcels"
relClass = "Montgomery.gdb/parcelowners_RelClass"
forLabel = "Owns"
backLabel = "Is Owned By"
attributeFields = ["OWNER_PERCENT", "DEED_DATE"]
originPK = "OBJECTID"
originFK = "owner_ID"
destinationPK = "OBJECTID"
destinationFK = "parcel_ID"
arcpy.TableToRelationshipClass_management(ownerTbl, parcel, relClass, "SIMPLE",
                                          forLabel, backLabel, "BACKWARD", "MANY_TO_MANY",
                                          ownerTbl, attributeFields, originPK, originFK,
                                          destinationPK, destinationFK)

Отношения таблиц базы данных

• Связь один к одному
  • Пример связи один к одному
• Связь «один ко многим»
  • Пример отношения «один ко многим»
• Связь «многие ко многим»
• Дальнейшее чтение

Отношения — это осмысленные ассоциации между таблицами, которые содержат связанную информацию — это то, что делает базы данных полезными. Без какой-либо связи между таблицами в базе данных вы можете работать с разрозненными файлами электронных таблиц, а не с системой базы данных.

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

Определение связей, которые вам понадобятся между таблицами, является частью процесса моделирования данных и разработки схемы, то есть процесса выяснения того, как ваши данные сочетаются друг с другом и как именно вы должны настроить свои таблицы и их поля.

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

• Один на один
• Один ко многим
• Многие ко многим

Если подумать о том, как ваши таблицы должны быть связаны друг с другом, это также поможет обеспечить целостность и точность данных и свести к минимуму избыточные данные.

Связь один к одному

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

Пример отношения один к одному

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

Employee поля, содержащие такую ​​информацию, как марка, год выпуска и операционная система каждого компьютера. Однако это может запутать с семантической точки зрения — неужели компьютерная информация действительно принадлежит в таблице о сотрудниках? Это решать вам, но другой вариант — создать таблицу Computers с отношением один к одному к таблице Employee , как показано на диаграмме ниже:

Рис. 1 . Отношение «один к одному» между таблицей «Сотрудник » и таблицей «Компьютеры «. PK указывает на первичный ключ, а FK указывает на внешний ключ.

В данном случае ключ сущности от нашего Сотрудника 9Таблица 0046 служит внешним ключом для таблицы Computers . У вас могут быть компьютеры, которые еще не назначены сотрудникам, и такое моделирование гарантирует, что вы сможете вести для них записи в таблице Computer . А если сотрудник увольняется из компании, вам нужно будет обновить только одно поле, и вы легко сможете привязать компьютер к новому сотруднику.

Точное форматирование строк, используемых для соединения таблиц в ERD (известное как нотация гусиной лапки), различается; иногда вы увидите простые линии, указывающие на взаимосвязь один к одному, в других случаях эти линии будут заштрихованы, как на рисунке 1.

Отношения «один к одному» также могут быть полезны в целях безопасности, например, если вы хотите хранить конфиденциальную информацию о клиентах в отдельной таблице, которую вы связываете с основной таблицей Customers с помощью внешнего ключа.

Связь "один ко многим"

Отношения "один ко многим" являются наиболее распространенным типом отношений между таблицами в базе данных.

В отношении «один ко многим» (иногда называемому «многие к одному») запись в одной таблице соответствует нулю, одной или многим записям в другой таблице.

Пример связи "один ко многим"

Например, подумайте о таблицах для клиентов и их заказов, как в Sample Database в Metabase, где одна запись из таблицы People может быть связана со многими записями в таблице Orders . В этом случае один клиент может разместить много заказов, и все эти записи заказов будут связаны с одной записью в таблице People . Это соединение кодируется через поле User_ID , которое является первичным ключом в 9Таблица 0045 People и внешний ключ в таблице Orders . На диаграмме ниже показано, как эти две таблицы соотносятся друг с другом:

Рис. 2 . Отношение «один ко многим» между таблицами People и Orders базы данных Sample.

Хотя один человек может быть связан со многими заказами, обратное неверно — заказы связаны только с одной записью в таблице Люди и не имеют большого количества клиентов.

Связь «многие ко многим»

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

На самом деле ваша система баз данных может даже не допускать создания прямого отношения «многие ко многим», но вы можете обойти это, создав третью таблицу, известную как присоединитесь к таблице и создайте отношения «один ко многим» между ней и двумя исходными таблицами.

В этом смысле таблица Orders в базе данных Sample Database действует как таблица соединения, создавая промежуточную связь между People и Products . ERD Sample Database будет выглядеть примерно так, как показано на изображении ниже, где каждое отношение определяется типом линии, используемой для соединения таблиц:

Рис. 3 . ERD, показывающий образец базы данных Metabase.

С технической точки зрения, таблицы Products и Orders имеют отношение «один ко многим», т. е. один продукт может быть связан со многими заказами. Но, судя по базе данных нашей поддельной компании, люди заказывают только один продукт (по какой-то причине они покупают пять легких компьютеров из шерсти). Реальная (и, возможно, более подходящая для бизнеса) реализация этой базы данных, вероятно, будет включать в себя таблицу соединения между ними, благодаря чему заказы могут содержать много разных продуктов.

Дальнейшее чтение

• Страница модели данных: редактирование метаданных
• Присоединяется к метабазе

« Предыдущий Далее »

Вам помогла эта статья?

Спасибо за отзыв!

Руководство по связям между таблицами — служба поддержки Майкрософт

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

В этой статье

• Введение

• Типы отношений между таблицами

• Зачем создавать отношения между таблицами?

• Понимание ссылочной целостности

• Просмотр взаимосвязей между таблицами

Введение

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

1. Информация в этой форме взята из таблицы Customers…

2. …стол заказов…

3. …Таблица товаров…

4. …и таблицу сведений о заказе.

Имя клиента в поле Bill To извлекается из таблицы «Клиенты», значения «Идентификатор заказа» и «Дата заказа» берутся из таблицы «Заказы», ​​название продукта берется из таблицы «Продукты», а значения «Цена за единицу» и «Количество» берутся из таблицу сведений о заказе. Эти таблицы связаны друг с другом различными способами для переноса информации из каждой в форму.

В предыдущем примере поля в таблицах должны быть скоординированы, чтобы в них отображалась информация об одном и том же заказе. Эта координация осуществляется с помощью связей между таблицами. Связь между таблицами работает путем сопоставления данных в ключевых полях — часто это поля с одинаковыми именами в обеих таблицах. В большинстве случаев эти совпадающие поля представляют собой первичный ключ из одной таблицы, который предоставляет уникальный идентификатор для каждой записи, и внешний ключ из другой таблицы. Например, сотрудников можно связать с заказами, за которые они несут ответственность, создав табличную связь между полями EmployeeID в таблицах «Сотрудники» и «Заказы».

1. EmployeeID появляется в обеих таблицах — как первичный ключ…

2. … и как внешний ключ.

Верх страницы

Типы связей между таблицами

В Access существует три типа связей между таблицами.

• org/ListItem»>

  Связь «один ко многим»

  В качестве примера возьмем базу данных отслеживания заказов, включающую таблицы «Клиенты» и «Заказы». Клиент может сделать любое количество заказов. Из этого следует, что для любого клиента, представленного в таблице «Клиенты», может быть много заказов, представленных в таблице «Заказы». Связь между таблицей Customers и таблицей Orders является связью «один ко многим».

  Чтобы представить отношение «один ко многим» в структуре базы данных, возьмите первичный ключ на стороне отношения «один» и добавьте его в качестве дополнительного поля или полей в таблицу на стороне отношения «многие». В этом случае, например, вы добавляете новое поле — поле идентификатора из таблицы «Клиенты» — в таблицу «Заказы» и называете его идентификатором клиента. Затем Access может использовать идентификационный номер клиента в таблице «Заказы», ​​чтобы найти нужного клиента для каждого заказа.

• org/ListItem»>

  Связь «многие ко многим»

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

  Для представления отношения «многие ко многим» необходимо создать третью таблицу, часто называемую соединительной таблицей, которая разбивает отношение «многие ко многим» на два отношения «один ко многим». Вы вставляете первичный ключ из каждой из двух таблиц в третью таблицу. В результате третья таблица записывает каждое вхождение или экземпляр отношения. Например, таблица «Заказы» и таблица «Продукты» имеют отношение «многие ко многим», которое определяется путем создания двух отношений «один ко многим» для таблицы «Сведения о заказе». В одном заказе может быть много продуктов, и каждый продукт может появляться во многих заказах.

• Отношения один на один

  В отношении «один к одному» каждая запись в первой таблице может иметь только одну совпадающую запись во второй таблице, а каждая запись во второй таблице может иметь только одну совпадающую запись в первой таблице. Эта связь не распространена, потому что чаще всего информация, связанная таким образом, хранится в одной и той же таблице. Вы можете использовать отношение «один к одному», чтобы разделить таблицу с множеством полей, изолировать часть таблицы из соображений безопасности или сохранить информацию, которая применяется только к подмножеству основной таблицы. Когда вы определяете такую ​​связь, обе таблицы должны иметь общее поле.

Верх страницы

Зачем создавать отношения между таблицами?

Вы можете явно создать отношения между таблицами, используя окно «Связи» или перетащив поле из панели «Список полей». Access использует отношения между таблицами, чтобы решить, как соединять таблицы, когда вам нужно использовать их в объекте базы данных. Существует несколько причин, по которым вам следует создавать отношения между таблицами перед созданием других объектов базы данных, таких как формы, запросы и отчеты.

• Связи между таблицами информируют о ваших запросах

  Для работы с записями из нескольких таблиц часто необходимо создать запрос, объединяющий таблицы. Запрос работает, сопоставляя значения в поле первичного ключа первой таблицы с полем внешнего ключа во второй таблице. Например, чтобы вернуть строки со списком всех заказов для каждого клиента, вы создаете запрос, который объединяет таблицу «Клиенты» с таблицей «Заказы» на основе поля «Идентификатор клиента». В окне «Связи» вы можете вручную указать поля для объединения. Но если между таблицами уже определена связь, Access предоставляет соединение по умолчанию на основе существующей связи между таблицами. Кроме того, если вы используете один из мастеров запросов, Access использует информацию, которую он собирает из отношений таблиц, которые вы уже определили, чтобы предоставить вам обоснованный выбор и предварительно заполнить параметры свойств соответствующими значениями по умолчанию.

• Отношения между таблицами влияют на дизайн форм и отчетов

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

• Связи между таблицами — это основа, на которой можно обеспечить ссылочную целостность, чтобы предотвратить бесхозные записи в базе данных. Бесхозная запись – это запись со ссылкой на другую несуществующую запись — например, запись заказа, которая ссылается на несуществующую запись клиента.

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

Верх страницы

Понимание ссылочной целостности

При проектировании базы данных вы делите информацию базы данных на множество тематических таблиц, чтобы свести к минимуму избыточность данных. Затем вы даете Access возможность снова собрать данные, поместив общие поля в связанные таблицы. Например, для представления отношения «один ко многим» вы берете первичный ключ из таблицы «один» и добавляете его в качестве дополнительного поля в таблицу «многие». Чтобы собрать данные вместе, Access берет значение из таблицы «многие» и ищет соответствующее значение в таблице «один». Таким образом, значения в таблице «многие» ссылаются на соответствующие значения в таблице «один».

Предположим, у вас есть отношение «один ко многим» между грузоотправителями и заказами, и вы хотите удалить грузоотправителя. Если грузоотправитель, которого вы хотите удалить, имеет заказы в таблице «Заказы», ​​эти заказы станут «сиротами», когда вы удалите запись грузоотправителя. Заказы по-прежнему будут содержать идентификатор грузоотправителя, но этот идентификатор больше не будет действительным, поскольку запись, на которую он ссылается, больше не существует.

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

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

Также возможно, что вам необходимо удалить строку и все связанные записи — например, запись о грузоотправителе и все связанные заказы для этого грузоотправителя. По этой причине Access поддерживает каскадное удаление связанных записей 9.вариант 0200. Когда вы обеспечиваете ссылочную целостность и выбираете параметр Каскадное удаление связанных записей , а затем удаляете запись на стороне первичного ключа отношения, Access автоматически удаляет все записи, которые ссылаются на первичный ключ.

Верх страницы

Просмотр взаимосвязей таблиц

Чтобы просмотреть отношения между таблицами, нажмите Отношения на вкладке Инструменты базы данных . Откроется окно Отношения, в котором будут показаны все существующие отношения. Если отношения между таблицами не определены и вы открываете окно «Связи» в первый раз, Access предлагает добавить в окно таблицу или запрос.

Открыть окно отношений

1. Нажмите Файл , щелкните Открыть , а затем выберите и откройте базу данных.

2. На вкладке Инструменты базы данных в группе Отношения щелкните Отношения .

3. На вкладке Проект в группе Взаимосвязи щелкните Все взаимосвязи .

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

Связь между таблицами представлена ​​линией связи, проведенной между таблицами в окне «Связи». Отношение, которое не обеспечивает ссылочную целостность, выглядит как тонкая линия между общими полями, поддерживающими отношение. Когда вы выбираете взаимосвязь, щелкая ее линию, линия утолщается, указывая на то, что она выбрана. Если вы примените ссылочную целостность для этой связи, линия будет толще на каждом конце. Кроме того, число 1 отображается над толстой частью линии с одной стороны взаимосвязи, а символ бесконечности ( ∞ ) появляется над толстой частью линии с другой стороны.

Когда окно «Взаимосвязи» активно, вы можете выбрать одну из следующих команд на ленте:

На вкладке Design в группе Инструменты :

• Редактировать отношения     Открывает диалоговое окно Редактировать отношения . Когда вы выбираете линию отношения, вы можете нажать Изменить отношения , чтобы изменить отношение таблицы. Вы также можете дважды щелкнуть линию связи.

• Очистить макет     Удаляет все таблицы и отношения из окна «Связи». Обратите внимание, что эта команда только скрывает таблицы и связи, но не удаляет их.

• Отчет о взаимосвязях     Создает отчет, отображающий таблицы и взаимосвязи в базе данных. В отчете отображаются только те таблицы и связи, которые не скрыты в окне «Связи».

На вкладке Проект в группе Взаимосвязи :

• org/ListItem»>

  Добавить таблицы (показать таблицу в Access 2013     Позволяет выбирать таблицы для отображения в окне «Связи».

• Скрыть таблицу     Скрывает выбранную таблицу в окне «Связи».

• Прямые отношения     Отображает все отношения и связанные таблицы для выбранной таблицы в окне «Связи», если они еще не отображены.

• Все отношения     Отображает все отношения и связанные таблицы в вашей базе данных в окне отношений.