Типы связей в реляционных базах данных

Для чего все это нужно?

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

Правильно настроив связи, можно быть уверенным, что ничего не потеряется.

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

  • < Назад
  • Вперёд >

Новые статьи:

  • Объединение таблиц – UNION

  • Соединение таблиц – операция JOIN и ее виды

  • Тест на знание основ SQL

Если материалы office-menu.ru Вам помогли, то поддержите, пожалуйста, проект, чтобы я мог развивать его дальше.

Sql- язык структурированных запросов

Язык структурированных запросов SQL является наиболее распространенным языком управления базами данных клиент/сервер. содержит операторы:

  • описания данных (DDL — Data Definition Language). Основные операторы DDL — Create Domain (Создание домена), Alter Domain (Изменение домена), Drop Domain (Уничтожение домена), Create Table, Alter Table, Table Drop;

  • управления данными (DML — Data Manipulation Language). Основные операторы DML — Select (Выбор), Insert (Вставка), Update (Обновление), Delete (Удаление);

  • формирования запросов.

        Операторы DDL (Data Definition Language) — операторы определения объектов базы данных

    • CREATE SCHEMA — создать схему базы данных

    • DROP SHEMA — удалить схему базы данных

    • CREATE TABLE — создать таблицу

    • ALTER TABLE — изменить таблицу

    • DROP TABLE — удалить таблицу

    • CREATE DOMAIN — создать домен

    • ALTER DOMAIN — изменить домен

    • DROP DOMAIN — удалить домен

    • CREATE COLLATION — создать последовательность

    • DROP COLLATION — удалить последовательность

    • CREATE VIEW — создать представление

    • DROP VIEW — удалить представление

          Операторы DML (Data Manipulation Language) — операторы манипулирования данными

      • SELECT — отобрать строки из таблиц

      • INSERT — добавить строки в таблицу

      • UPDATE — изменить строки в таблице

      • DELETE — удалить строки в таблице

      • COMMIT — зафиксировать внесенные изменения

      • ROLLBACK — откатить внесенные изменения

Запросы к отношениям

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

Например, у нас есть блог, в котором модель связана с моделью :

Вы можете получить все опубликованные записи пользователя следующим образом:

Методы отношений и Динамические свойства

Если Вам не нужны дополнительные ограничения на запрос, то лучше всего использовать динамические свойства. Например, продолжая рассматривать модели и , Вы можете получить доступ ко всем сообщениям пользователя следующим образом:

Динамические свойства являются «lazy loading«, то есть они будут загружать данные только тогда, когда Вы хотите их получить. Также разработчики часто используют , для получения предварительно загруженных отношений, которые, как они знают, будут доступны после загрузки модели.

Запрос на существование отношений

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

Вы также можете использовать операторы сравнения:

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

Вы также можете использовать методы и :

Жадная загрузка (eager loading)

Данные об отношениях подгружаются только в момент обращения к динамическому свойству. Жадная загрузка (eager loading) призвана устранить проблему N+1. Например, представьте, что у нас есть модель , которая связана с моделью . Отношение определено как:

Теперь загрузим все книги и их авторов:

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

Теперь давайте заранее получим всех авторов при помощи методов :

Тогда будут выполнены всего два запроса:

Жадная загрузка нескольких отношений

Иногда Вам может потребоваться жадная загрузка нескольких разных отношений за одну операцию. Для этого просто передайте дополнительные аргументы методу :

Вложенная жадная загрузка

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

Ограничения жадной загрузки

Иногда вам может быть нужно не только загрузить отношение, но также указать условие для его загрузки:

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

Ленивая жадная загрузка

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

Вы также можете дополнить запрос при помощи функции-замыкания:

Типы соединения

Существует три основных типа соединения: Вы можете увидеть их на следующем снимке экрана:

Вариант 1 определяет внутреннее соединение. Внутреннее соединение — это соединение, в котором записи из двух таблиц объединяются в результатах запроса только в том случае, если значения в объединенных полях соответствуют определенному состоянию. В запросе соединение по умолчанию — это внутреннее соединение, которое выбирает записи только в том случае, если значения в объединенных полях совпадают.

Вариант 2 определяет левое внешнее соединение. Левое внешнее соединение — это соединение, в котором все записи с левой стороны операции LEFT JOIN в оператора запроса SQL добавляются к результатам запроса, даже если нет соответствующих значений в объединенном поле из таблицы на правой стороне.

Вариант 3 определяет правое внешнее соединение. Правое внешнее соединение — это соединение, в котором все записи с правой стороны операции RIGHT JOIN в операторе запроса SQL добавляются к результатам запроса, даже если нет соответствующих значений в объединенном поле из таблицы на левой стороне.

Создание и изменение отношений 1:N между сущностями

Откройте обозреватель решений.

В разделе Компоненты раскройте узел Сущности, затем раскройте сущность, с которой требуется работать.

Выберите Отношения 1:N.

Чтобы изменить отношение или просмотреть сведения для отношения, выберите отношение и нажмите на панели инструментов «Действия» кнопку Другие действия, затем выберите Изменить.
— ИЛИ —
Чтобы добавить новое отношение, выберите Создать отношение «один ко многим».

Важно!
Если кнопка Создать отношение «один ко многим» не отображается на панели инструментов «Действия», то создать отношение 1:N для этой сущности невозможно.

Для нового отношения в разделе Определение отношения выберите в списке Связанная сущность сущность для связывания.

Примечание
При указании связанной сущности задается значение по умолчанию в поле Имя. Если изменить связанную сущность перед ее сохранением, соответственно изменится и значение поля Имя.

Выберите, будет ли это поле доступно для поиска или нет.

В разделе Поле поиска укажите значение для поля в поле Отображаемое имя.

Важно!
При указании значения Отображаемое имя задается значение по умолчанию в поле Имя

Если изменить Отображаемое имя поля поиска перед сохранением данных, значение в поле Имя не изменится. Поэтому необходимо ввести в поле Имя информативное значение перед сохранением данных.

В списке Требование поля выберите вариант, чтобы указать требования к данным для поля перед сохранением записи.

В разделе Элемент области переходов для основной сущности в списке Параметры отображения выберите вариант отображения связанных представлений для пользовательской метки.

В разделе Поведение отношений выберите в списке Тип отношений один из следующих вариантов.

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

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

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

Настраиваемое каскадное. В настраиваемом каскадном отношении между двумя сущностями выбирается поведение, связанное с каждым из наборов возможных действий.

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

Дополнительные сведения:

  1. Выберите Сохранить и закрыть, чтобы закрыть форму Отношение.

  2. Выполнив настройки, опубликуйте их:

    • Чтобы опубликовать настройки только для компонента, изменяемого в данный момент, на панели инструментов «Действия» выберите Опубликовать.

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

Примечание

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

Термины кортеж, атрибут и отношение в реляционных базах данных

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

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

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

Таблица с данными из базы данных World

У нас есть простая таблица City из базы данных World, в которой есть строки и столбцы. Но термины: таблица, строка, столбец – это термины стандарта SQL.

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

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

Если рассматривать таблицу, как объект (например книга), то столбец – это характеристики объекта, а строки содержат информацию об объекте.

Виды и типы связей между таблицами в реляционных базах данных

Давайте теперь рассмотрим то, как могут быть связаны таблицы в реляционных базах данных. Сразу скажу, что всего существует три вида связей между таблицами баз данных:
• связь один к одному;
• связь один ко многим;
• связь многие ко многим.

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

Реализация связи один ко многим в теории баз данных

Связь один ко многим в реляционных базах данных реализуется тогда, когда объекту А может принадлежать или же соответствовать несколько объектов Б, но объекту Б может соответствовать только один объект А. Не совсем понятно, поэтому смотрим пример ниже.

Реализация связи один ко многим в реляционных базах данных

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

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

Связь многие ко многим реализуется в том случае, когда нескольким объектам из таблицы А может соответствовать несколько объектов из таблицы Б, и в тоже время нескольким объектам из таблицы Б соответствует несколько объектов из таблицы А. Рассмотрим простой пример.

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

У нас есть таблица с книгами и есть таблица с авторами. Приведу два верных утверждения. Первое: одну книгу может написать несколько авторов. Второе: автор может написать несколько книг. Здесь мы наблюдаем типичную ситуацию, когда связь между таблицами многие ко многим. Такая связь (связь многие ко многим) реализуется путем добавления третьей таблицы.

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

Связь один к одному – самая редко встречаемая связь между таблицами. В 97 случаях из 100, если вы видите такую связь, вам необходимо объединить две таблицы в одну.

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

Таблицы будут связаны один к одному тогда, когда одному объекту таблицы А соответствует один объект таблицы Б, и одному объекту таблицы Б соответствует один объект таблицы А. Как я уже говорил: если вы видите, что связь один к одному – смело объединяйте таблицы в одну, за исключением тех случаев, когда происходит модернизация базы данных.

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

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

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

2.4.3.3. Заполнение таблиц

Заполнение таблиц можно начать и с заполнения таблицы Студенты. В окне Базы данных выделяем нужную таблицу, затем выполняем щелчок на кнопке Открыть.

На экране появится структура таблицы БД в режиме таблицы. Новая таблица состоит из одной пустой строки.

Рис. 5.

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

Для заполнения поля MEMO в таблице (колонка Место рождения) нажимаем комбинацию клавиш , предварительно установив курсор в поле MEMO. Открывается диалоговое окно Область ввода, после ввода или редактирования данных в этом окне щелкаем на кнопке ОК.

После заполнения таблица Студенты имеет следующий вид.

Рис. 6.

Аналогичным образом заполняются остальные таблицы: Группы Студентов, Успеваемость, Дисциплины.

Рис. 7. Рис. 8. Рис. 9.

В приложении Access применяются различные методы перемещения по таблице. Переходить от записи к записи можно с помощью: клавиш управления курсором; кнопки из области Запись, расположенной внизу таблицы в режиме таблицы; команды Правка — Перейти.. Для перемещения от поля к полю (слева направо) применяются клавиши Tab и Enter, а в обратном направлении Shift+Tab.

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

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

Далее …>>>Тема: 2.4.4. Формирование запросов

Ключевые слова sql

  1. Команды – представляют собой глаголы определяющего действия, которые необходимо выполнить (SELECT, ALTER, CREATE, DROP)

  2. Условия (квалификатор)-ограничивают диапазон значений элементов, входящих в запрос (WHERE)

  3. Модификаторы (предложения)-модифицируют выполнение инструкций (ORDER BY)

  4. Предикаты – представляют собой выражения, такие как IN. Могут возвращать в качестве результата значения True, False, в некоторых случаях Null (неизвестный результат)

  5. Операторы (=, <,>)- сравнивают значения или применяются для создания объединений в синтаксисе предложений WHERE. Эти операторы наз предикатами сравнения.

  6. Статистические функции (агрегаты)- возвращают одно результирующее значение на основе набора данных (SUM (сумма), COUNT (количество), MIN (минимальное значение), MAX (максимальное значение) или AVG (среднее значение)

  7. Функции преобразования типа данных – изменяют тип данных с одного на др.(CAST, CONVERT)

  8. Другие ключевые слова (зарезервированные)-изменяющие действие команд или управляющие курсором (указателем текущей записи в наборе)

В синтаксических конструкциях используются следующие обозначения:

звездочка (*) для обозначения «все» — употребляется в обычном для программирования смысле, т.е. «все случаи, удовлетворяющие определению»;

квадратные скобки ([]) – означают, что конструкции, заключенные в эти скобки, являются необязательными (т.е. могут быть опущены);

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

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

прямая черта (|) – означает наличие выбора из двух или более возможностей. Например обозначение ASC|DESC указывает, можно выбрать один из терминов ASC или DESC; когда же один из элементов выбора заключен в квадратные скобки, то это означает, что он выбирается по умолчанию (так, |DESC означает, что отсутствие всей этой конструкции будет восприниматься как выбор ASC);

точка с запятой (;) – завершающий элемент предложений SQL;

запятая (,) – используется для разделения элементов списков;

пробелы ( ) – могут вводиться для повышения наглядности между любыми синтаксическими конструкциями предложений SQL;

прописные жирные латинские буквы и символы – используются для написания конструкций языка SQL и должны (если это специально не оговорено) записываться в точности так, как показано;

строчные буквы – используются для написания конструкций, которые должны заменяться конкретными значениями, выбранными пользователем, причем для определенности отдельные слова этих конструкций связываются между собой символом подчеркивания (_);

Основой SQL является инструкция SELECT, используемая для создания запросов на выборку.

Синтаксис инструкции:

SELECT список_выбора

]]

FROM имена таблиц

];

SELECT — выбрать (директива) данные из указанных столбцов и (если необходимо) выполнить перед выводом их преобразование в соответствии с указанными выражениями и (или) функциями

FROM — из (условие) перечисленных таблиц, в которых расположены эти столбцы

WHERE — где (условие) строки из указанных таблиц должны удовлетворять указанному перечню условий отбора строк

GROUP BY — группируя по (условие) указанному перечню столбцов с тем, чтобы получить для каждой группы единственное агрегированное значение, используя во фразе SELECT SQL – функции: SUM (сумма), COUNT (количество), MIN (минимум), MAX (максимум), AVG (среднее значение)

HAVING — имея в результате лишь те группы, которые удовлетворяют указанному перечню условий отбора групп (условие)

ORDER BY — спецификация сортировки (условие) определяет порядок сортировки: ASC – сортировка по возрастанию, DESC — сортировка по убыванию.

ПРЕДИКАТЫ :

1. Сравнения =, <>, >=, <, <=

2. В интервале — “между” BETWEEN a1 and a2

3. Входит в множество IN (= IN (“Мука”,“Крупа”…..)

4. Подобие < имя > Like < образец > ( что ) ( с чем сравнивать)

Элемент области навигации для основной сущности

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

Поле Описание
Параметры отображения — Не отображать. Выберите этот параметр, требуется запретить пользователям переходить к списку записей связанных сущностей.- Использовать специальные метки. Выберите этот параметр, если требуется указать специальную метку для использования.- Использовать имя во множественном числе. Выберите этот параметр, если имя связанной сущности во множественном числе требуется использовать в качестве метки.
Пользовательская метка При выборе параметра Использовать специальные метки в качестве параметра отображения введите специальную метку, которую требуется использовать вместо имени связанной сущности во множественном числе.
Область отображения — Сведения. Выберите этот параметр для включения элемента навигации в группу Общие.- Маркетинг. Выберите этот параметр для включения элемента навигации в группу Маркетинг.- Продажи. Выберите этот параметр для включения элемента навигации в группу Продажи.- Служба. Выберите этот параметр для включения элемента навигации в группу Служба.
Порядок отображения Это значение управляет тем, будет ли элемент навигации включен в выбранную область отображения. Диапазон доступных номеров начинается с 10 000. Элементы области навигации с меньшим значением будут стоять в списке выше других отношений.

Использование связей с кратностью «многие ко многим» вместо временного решенияUse a relationship with a many-many cardinality instead of the workaround

Начиная июльской версии 2018 г., в Power BI Desktop можно напрямую связывать таблицы, например те, которые мы упоминали выше, не прибегая к использованию аналогичных временных решений.With the July 2018 version of Power BI Desktop, you can directly relate tables, such as the ones we described earlier, without having to resort to similar workarounds. Теперь можно задать кратность связи многие ко многим.It’s now possible to set the relationship cardinality to many-to-many. Этот параметр указывает, что ни одна из таблиц не содержит уникальные значения.This setting indicates that neither table contains unique values. Такие связи позволяют контролировать, какая таблица фильтрует другую таблицу.For such relationships, you may still control which table filters the other table. Либо можно применить двунаправленную фильтрацию, где каждая таблица фильтрует другую.Or you can apply bidirectional filtering, where each table filters the other.

В Power BI Desktop по умолчанию задается кратность многие ко многим, когда программа определяет, что ни одна из таблиц не содержит уникальные значения столбцов связи.In Power BI Desktop, the cardinality defaults to many-to-many when it determines neither table contains unique values for the relationship columns. В таких случаях отображается предупреждение с сообщением о том, что вы хотите установить связь, и изменение не является случайным результатом проблемы с данными.In such cases, a warning message confirms you want to set a relationship, and the change isn’t the unintended effect of a data issue.

Например, при создании связи непосредственно между CityData и Sales—, где фильтры должны применяться от CityData к Sales, в —Power BI Desktop отображается диалоговое окно Изменение связи.For example, when you create a relationship directly between CityData and Sales—where filters should flow from CityData to Sales—Power BI Desktop displays the Edit relationship dialog box:

Итоговое представление связей будет содержать прямую связь «многие ко многим» между двумя таблицами.The resulting Relationship view would then display the direct, many-to-many relationship between the two tables. Внешний вид таблиц в списке Поля и их последующее поведение при создании визуальных элементов аналогично ситуации, в которой мы применили обходной путь.The tables’ appearance in the Fields list, and their later behavior when the visuals are created, are similar to when we applied the workaround. Там мы создали дополнительную скрытую таблицу уникальных штатов.In the workaround, the extra table that displays the distinct State data isn’t made visible. Как было сказано выше, отображается визуальный элемент со сведениями о штате, населении и продажах.As described earlier, a visual that shows State, Population, and Sales data would be displayed:

Основные различия между связями с кратностью «многие ко многим» и более распространенными связями многие к одному заключается в следующем.The major differences between relationships with a many-many cardinality and the more typical Many-1 relationships are as follows:

  • Значения, показываемые в них, не содержат пустую строку, отвечающую за несовпадающие строки в другой таблице.The values shown don’t include a blank row that accounts for mismatched rows in the other table. Кроме того, значения не отвечают за строки, в которых столбец, используемый для связи в другой таблице, имеет значение NULL.Also, the values don’t account for rows where the column used in the relationship in the other table is null.

  • Использовать функцию (так как связанными могут быть несколько строк) не удастся.You can’t use the function, because more than one row could be related.

  • При использовании функции в таблице не удаляются фильтры, примененные к другим таблицам, у которых с ней установлена связь «многие ко многим».Using the function on a table doesn’t remove filters that are applied to other, related tables by a many-to-many relationship. В предыдущем примере мера, определенная согласно данному скрипту, не удалит фильтры по столбцам связанной таблицы CityData.In the preceding example, a measure that’s defined as shown here wouldn’t remove filters on columns in the related CityData table:

    Визуальный элемент с отображением штата, объема продаж и общего объема продаж будет таким, как на рисунке ниже.A visual showing State, Sales, and Sales total data would result in this graphic:

Учитывая перечисленные различия, убедитесь, что вычисления, использующие , такие как % от общей суммы, возвращают желаемые результаты.With the preceding differences in mind, make sure the calculations that use , such as % of grand total, are returning the intended results.

Поведение отношений

Можно настроить поведение отношения 1:N для поддержки бизнес-правил организации. Почему это может потребоваться? Рассмотрим пример.

Допустим, у вас новый продавец и требуется назначить ему несколько существующих возможных сделок, в данное время назначенных другому продавцу. Каждая запись возможной сделки может иметь несколько действий задач, связанных с ней. Можно легко найти активные возможные сделки, которые требуется переназначить, и назначить их новому продавцу. Но что произойдет с действиями задач, связанными с возможными сделками? Хотелось бы вам открывать каждую задачу и указывать, должна ли она также быть назначена новому продавцу? Скорее всего, нет. Вместо этого можно разрешить отношению применить некоторые стандартные правила автоматически. Эти правила применяются только к записям задач, связанным с возможными сделками, которые вы переназначаете. Это отношение сущностей называется Opportunity_Tasks. Можно выполнить следующие действия:

  • Переназначить все активные задачи.

  • Переназначить все задачи. Это поведение принимается по умолчанию.

  • Не переназначать задачи.

  • Переназначить все задачи, которые в данный момент назначены бывшему владельцу возможной сделки.

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

Действие Описание Возможное поведение
Назначение Что должно произойти, когда меняется владелец записи основной сущности? — Каскад для активных- Каскад для всех- Без каскадных- Передавать владельцу
Общий доступ Что должно произойти при совместном использовании записи основной сущности? — Каскад для активных- Каскад для всех- Без каскадных- Передавать владельцу
Отмена общего доступа Что должно произойти при отмене совместного использования записи основной сущности? — Каскад для активных- Каскад для всех- Без каскадных- Передавать владельцу
Переподчинение Что должно произойти, когда меняется значение поля поиска для отношения родительского типа в записи основной сущности? Отношение родительского типа — это отношение, использующее Каскад для всех для всех действий. — Каскад для активных- Каскад для всех- Без каскадных- Передавать владельцу
Удаление Что должно произойти при удалении записи основной сущности? — Каскад для всех- Удалить связь- Ограничить удаление
Слияние Что должно произойти, когда запись основной сущности объединяется с другой записью? — Каскад для всех- Без каскадных

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

Поведение Описание
Передавать активным Выполнение действия для всех активных записей связанной сущности.
Передавать всем Выполнение действия для всех записей связанной сущности.
Не передавать никому Никакие действия не выполняются.
Удалить ссылку Удаление значения поля поиска для всех записей связанной сущности.
Ограничить удаление Блокировка возможности удаления записи основной сущности, если существуют связанные записи.
Передавать владельцу Выполнение действия для всех записей связанной сущности тем же пользователем, что и пользователь записи основной сущности.

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

Значение поля Описание
Родительский Все действия используют поведение Передавать всем.
Ссылочный Действия Назначить, Предоставить общий доступ, Отменить общий доступ и Переподчинение используют поведение Не передавать никому. Действие Удалить использует поведение Удалить ссылку. Действие Объединить использует поведение Передавать всем.
Ссылочный, ограничить удаление Аналогично значению Ссылочный за исключением того, что действие Удалить использует поведение Ограничить удаление.
Настраиваемое каскадное Отдельное поведение можно назначить для каждого действия. Если выбранные значения соответствуют любым другим категориям Тип поведения, значение изменится на значение Тип поведения.

Есть две таблицы..

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

Если рассмотреть иной пример: допустим, футболисты и команды ( с учетом того, что хотя бы один из футболистов играл за разные сборные, и каждая сборная имеет в своем составе одиннадцать игроков), суть построения связи не поменяется. Также будут нужны три таблицы. Из них «Футболисты» и «Команды» в качестве основных, и одна промежуточная.

Оцените статью
Рейтинг автора
5
Материал подготовил
Илья Коршунов
Наш эксперт
Написано статей
134
Добавить комментарий