что такое мощность отношения
SPBDEV Blog
В предыдущей статье были изложены основы отношений (связей). Вы узнали, зачем нам нужны отношения, и как они влияют на фильтрацию нескольких таблиц. В этой статье вы узнаете об одном из наиболее важных свойств отношений, которое называется кардинальностью или мощностью связей. Целью данной статьи является понимание смысла отношений “один-к-одному”, “один-ко-многим”, “многие-к-одному” и “многие-ко-многим”.
Необходимое условие
Прочтите первую часть серии о связях Power BI: Назад к основам: раскрытие отношений Power BI.
Отношения в Power BI
Отношения Power BI дают нам возможность получать поля из нескольких таблиц и возможность фильтрации по нескольким таблицам в модели данных. Отношения основаны на поле, которое соединит две таблицы и отфильтрует одну на основе другой (или наоборот, зависит от направления). Например, мы можем отфильтровать данные по количеству таблицы Sales по состоянию в таблице Store, если между таблицами Sales и Store существует связь на основе stor_id:
И отношения между таблицами будут следующими:
Что такое мощность отношений?
Когда вы создаете отношение между двумя таблицами, вы получаете два значения, которые могут быть 1 или * на двух концах отношения между двумя таблицами, называемые кардинальностью или мощностью отношений.
Два значения 1 или * говорят о том, что поле в этой взаимосвязи имеет определенное число значения на строку в этой таблице. Давайте проверим это на примере.
В таблице Stores у нас есть одно уникальное значение для stor_id на строку.
Таким образом, если это поле участвует в одной стороне отношения, то эта сторона примет 1 в качестве показателя кардинальности, который называется ОДНОЙ стороной отношения.
Однако stor_id в таблице Sales не уникален для каждой строки данных в этой таблице. У нас есть несколько строк для каждого stor_id. Или скажем так; в каждом магазине происходит несколько торговых транзакций (что, конечно, нормально):
Таким образом, если stor_id в таблице Sales является частью отношения, эта сторона отношения станет *, или то, что мы называем «МНОЖЕСТВЕННОЙ» стороной отношения.
Итак, основываясь на том, что мы знаем в данный момент, если мы создадим отношение на основе stor_id между двумя таблицами Sales и Stores, то получим вывод:
Эти отношения могут быть прочитаны двумя способами;
Они оба, конечно, одинаковы, и они будут выглядеть точно так же, как каждое из них в представлении схемы. Теперь, когда вы знаете, что такое мощность отношений, давайте изучим все виды мощности.
Типы мощности
Есть четыре типа кардинальности, как показано ниже:
Давайте поочередно рассмотрим каждый из этих типов.
Один-ко-многим или многие-к-одному
Это наиболее распространенный тип мощности, используемый в моделях данных. Этот тип количества элементов означает, что одна из таблиц имеет уникальные значения в каждой строке для поля отношения, а другая имеет несколько значений. Пример, который вы видели ранее между таблицами Stores и Sales на основе stor_id, представляет собой отношение «многие-к-одному» или «один-ко-многим».
Есть два способа назвать эти отношения: один-ко-многим или многие-к-одному. Зависит от того, что является исходной и целевой таблицей.
Например, приведенная ниже конфигурация означает, что от таблицы Sales до таблицы Stores есть отношение «многие-к-одному».
А ниже показано отношение «один-ко-многим» от таблицы Stores к таблице Sales:
Эти две таблицы заканчиваются созданием таких отношений:
Это означает, что нет разницы в отношении «один-ко-многим» или «многие-к-одному», кроме порядка, в котором вы читаете это. Если вы посмотрите от таблицы Stores, у вас будет отношение «один ко многим». Если вы посмотрите на это с точки зрения таблицы Sales, у вас будет отношение «многие к одному». И оба они одинаковы, без какой-либо разницы. Так что теперь, в этой статье, всякий раз, когда вы читаете «многие к одному» или «один ко многим», вы знаете, что вы можете читать их и наоборот.
В остальной части статьи мы будем использовать термины таблиц FACT и DIMENSION, которые мы объясним отдельно в другой статье. А пока вот краткое объяснение терминов:
Отношение «многие к одному» между таблицами фактов и измерений
Этот тип отношений, хотя часто используется во многих моделях, всегда может быть предметом исследования для лучшего моделирования. В идеальной модели данных вы НЕ должны иметь отношения между двумя таблицами измерений напрямую. Давайте проверим это на примере.
Допустим, модель отличается от того, что вы видели в этом примере: таблица Sales, таблица Product и две таблицы для информации о категории и подкатегории продукта:
Отношения “один-к-одному”
Отношение “один-к-одному” происходит только в одном сценарии, когда у вас есть уникальные значения в обеих таблицах на столбец. Примером такого сценария является случай, когда у вас есть таблицы Titles и Titles Details! У них обоих есть один ряд на заголовок. Так что, если мы создадим отношения, это будет выглядеть так:
Если между двумя таблицами существует взаимно-однозначное отношение, они являются хорошим кандидатом для объединения друг с другом с помощью слияния в Power Query. Поскольку обе таблицы в большинстве случаев имеют одинаковое количество строк, или даже если в одной из них меньше строк, все еще учитывающих метод сжатия механизма Power BI xVelocity, потребление памяти будет одинаковым, если вы поместите его в одну таблицу. Так что если у вас отношения “один-к-одному”, подумайте о том, чтобы серьезно объединить эти таблицы.
Было бы лучше, если бы мы объединили обе таблицы выше в одну таблицу, в которой есть все о заголовке.
Отношения “многие ко многим”: слабые отношения
У вас есть несколько записей для каждого значения в поле соединения между таблицами, для обеих таблиц. Если вы подумаете об этом на секунду, вы увидите, что этот сценарий происходит, когда у вас есть таблицы, которые связаны друг с другом без какого-либо общего измерения! Давайте проверим один пример. Допустим, у нас есть таблица инвентаризации фактов и таблица продаж фактов. Они обе имеют несколько записей на один продукт, и мы хотим соединить их вместе, используя идентификатор продукта. Это должно быть отношение «многие-ко-многим», потому что нет поля идентификатора продукта, в котором есть уникальные значения.
Что делать, если у вас есть более одной таблицы с этим сценарием?
Отношения «многие ко многим» вызывают массу проблем, и поэтому они также называются слабыми связями. В большинстве случаев ее можно решить путем создания общего измерения и создания отношений «один ко многим» из общего измерения с таблицами фактов. ИЗБЕГАЙТЕ такого типа отношений в вашей модели.
Лучшая модель для вышеупомянутого образца будет использовать общие размеры, как показано на этой диаграмме:
Резюме
SPBDEV Blog
В предыдущей статье были изложены основы отношений (связей). Вы узнали, зачем нам нужны отношения, и как они влияют на фильтрацию нескольких таблиц. В этой статье вы узнаете об одном из наиболее важных свойств отношений, которое называется кардинальностью или мощностью связей. Целью данной статьи является понимание смысла отношений “один-к-одному”, “один-ко-многим”, “многие-к-одному” и “многие-ко-многим”.
Необходимое условие
Прочтите первую часть серии о связях Power BI: Назад к основам: раскрытие отношений Power BI.
Отношения в Power BI
Отношения Power BI дают нам возможность получать поля из нескольких таблиц и возможность фильтрации по нескольким таблицам в модели данных. Отношения основаны на поле, которое соединит две таблицы и отфильтрует одну на основе другой (или наоборот, зависит от направления). Например, мы можем отфильтровать данные по количеству таблицы Sales по состоянию в таблице Store, если между таблицами Sales и Store существует связь на основе stor_id:
И отношения между таблицами будут следующими:
Что такое мощность отношений?
Когда вы создаете отношение между двумя таблицами, вы получаете два значения, которые могут быть 1 или * на двух концах отношения между двумя таблицами, называемые кардинальностью или мощностью отношений.
Два значения 1 или * говорят о том, что поле в этой взаимосвязи имеет определенное число значения на строку в этой таблице. Давайте проверим это на примере.
В таблице Stores у нас есть одно уникальное значение для stor_id на строку.
Таким образом, если это поле участвует в одной стороне отношения, то эта сторона примет 1 в качестве показателя кардинальности, который называется ОДНОЙ стороной отношения.
Однако stor_id в таблице Sales не уникален для каждой строки данных в этой таблице. У нас есть несколько строк для каждого stor_id. Или скажем так; в каждом магазине происходит несколько торговых транзакций (что, конечно, нормально):
Таким образом, если stor_id в таблице Sales является частью отношения, эта сторона отношения станет *, или то, что мы называем «МНОЖЕСТВЕННОЙ» стороной отношения.
Итак, основываясь на том, что мы знаем в данный момент, если мы создадим отношение на основе stor_id между двумя таблицами Sales и Stores, то получим вывод:
Эти отношения могут быть прочитаны двумя способами;
Они оба, конечно, одинаковы, и они будут выглядеть точно так же, как каждое из них в представлении схемы. Теперь, когда вы знаете, что такое мощность отношений, давайте изучим все виды мощности.
Типы мощности
Есть четыре типа кардинальности, как показано ниже:
Давайте поочередно рассмотрим каждый из этих типов.
Один-ко-многим или многие-к-одному
Это наиболее распространенный тип мощности, используемый в моделях данных. Этот тип количества элементов означает, что одна из таблиц имеет уникальные значения в каждой строке для поля отношения, а другая имеет несколько значений. Пример, который вы видели ранее между таблицами Stores и Sales на основе stor_id, представляет собой отношение «многие-к-одному» или «один-ко-многим».
Есть два способа назвать эти отношения: один-ко-многим или многие-к-одному. Зависит от того, что является исходной и целевой таблицей.
Например, приведенная ниже конфигурация означает, что от таблицы Sales до таблицы Stores есть отношение «многие-к-одному».
А ниже показано отношение «один-ко-многим» от таблицы Stores к таблице Sales:
Эти две таблицы заканчиваются созданием таких отношений:
Это означает, что нет разницы в отношении «один-ко-многим» или «многие-к-одному», кроме порядка, в котором вы читаете это. Если вы посмотрите от таблицы Stores, у вас будет отношение «один ко многим». Если вы посмотрите на это с точки зрения таблицы Sales, у вас будет отношение «многие к одному». И оба они одинаковы, без какой-либо разницы. Так что теперь, в этой статье, всякий раз, когда вы читаете «многие к одному» или «один ко многим», вы знаете, что вы можете читать их и наоборот.
В остальной части статьи мы будем использовать термины таблиц FACT и DIMENSION, которые мы объясним отдельно в другой статье. А пока вот краткое объяснение терминов:
Отношение «многие к одному» между таблицами фактов и измерений
Этот тип отношений, хотя часто используется во многих моделях, всегда может быть предметом исследования для лучшего моделирования. В идеальной модели данных вы НЕ должны иметь отношения между двумя таблицами измерений напрямую. Давайте проверим это на примере.
Допустим, модель отличается от того, что вы видели в этом примере: таблица Sales, таблица Product и две таблицы для информации о категории и подкатегории продукта:
Отношения “один-к-одному”
Отношение “один-к-одному” происходит только в одном сценарии, когда у вас есть уникальные значения в обеих таблицах на столбец. Примером такого сценария является случай, когда у вас есть таблицы Titles и Titles Details! У них обоих есть один ряд на заголовок. Так что, если мы создадим отношения, это будет выглядеть так:
Если между двумя таблицами существует взаимно-однозначное отношение, они являются хорошим кандидатом для объединения друг с другом с помощью слияния в Power Query. Поскольку обе таблицы в большинстве случаев имеют одинаковое количество строк, или даже если в одной из них меньше строк, все еще учитывающих метод сжатия механизма Power BI xVelocity, потребление памяти будет одинаковым, если вы поместите его в одну таблицу. Так что если у вас отношения “один-к-одному”, подумайте о том, чтобы серьезно объединить эти таблицы.
Было бы лучше, если бы мы объединили обе таблицы выше в одну таблицу, в которой есть все о заголовке.
Отношения “многие ко многим”: слабые отношения
У вас есть несколько записей для каждого значения в поле соединения между таблицами, для обеих таблиц. Если вы подумаете об этом на секунду, вы увидите, что этот сценарий происходит, когда у вас есть таблицы, которые связаны друг с другом без какого-либо общего измерения! Давайте проверим один пример. Допустим, у нас есть таблица инвентаризации фактов и таблица продаж фактов. Они обе имеют несколько записей на один продукт, и мы хотим соединить их вместе, используя идентификатор продукта. Это должно быть отношение «многие-ко-многим», потому что нет поля идентификатора продукта, в котором есть уникальные значения.
Что делать, если у вас есть более одной таблицы с этим сценарием?
Отношения «многие ко многим» вызывают массу проблем, и поэтому они также называются слабыми связями. В большинстве случаев ее можно решить путем создания общего измерения и создания отношений «один ко многим» из общего измерения с таблицами фактов. ИЗБЕГАЙТЕ такого типа отношений в вашей модели.
Лучшая модель для вышеупомянутого образца будет использовать общие размеры, как показано на этой диаграмме:
Резюме
BestProg
ER-модель. Понятие связи. Мощность связи. Типы связей. Примеры
Рекомендуется перед изучением данной темы ознакомиться с следующими темами:
Содержание
Поиск на других ресурсах:
1. Что такое связь в ER-модели? Пример
Между двумя сущностями может быть установлена связь. Отношения между сущностями характеризуются глаголом, который можно применить для взаимодействия между ними. Связь – это некое отношение между двумя типами сущностей.
2. Как связи обозначаются в ER-модели?
В ER-модели связи обозначаются в виде ромба. Внутри ромба указывается глагол, который определяет характер взаимодействия между типами сущностей.
3. Какие типы связей различают в ER-модели?
Между типами сущностей различают следующих 3 типа связей:
4. Пример связи типа «один ко многим» – 1:М
На рисунке 1 изображен фрагмент ER-модели, которая демонстрирует связь между типами сущностей Студент и Группа.
Рис. 1. Связь между типами сущностей Студент и Группа
5. Что такое мощность связи? Пример
Мощность связи – это значение максимального количества конкретных экземпляров сущностей, которые могут использоваться для данной связи. Мощность связи 5 говорит о том, что в данной связи может быть использовано не более 5 разных экземпляров сущностей. Или, иными словами, не более 5 отличных между собой значений.
Например. Студент учится в группе. Между типами сущностей Студент и Группа можно установить связь 1:30, как показано на рисунке 2. Число 30 означает, что в группе может учиться не более 30 студентов.
Рисунок 2. Связь между сущностями Студент и Группа
Если количество значений экземпляров сущностей произвольно, то мощность связи наиболее часто представляется символом M или знаком ∝ (бесконечность).
Использование конкретных числовых значений в мощности связи есть удобным при разработке программного обеспечения, поскольку можно более качественно реализовать структуры данных зная их максимальный размер.
6. Пример связи типа «много ко многим»
Рисунок 3. Отображение связи типа «много ко многим»
На рисунке 3 символами M и N обозначен тип связи «много ко многим». Этот тип связи выбран, так как один студент может изучать несколько (много) дисциплин, и, наоборот, одну дисциплину может изучать несколько студентов.
7. Какое характерное отличие типа связи «один к одному» 1:1 в сравнении с другими типами?
Связь «много ко многим» сложно реализовать программно, так как реляционные базы данных поддерживают связь «один ко многим». Чтобы решить эту проблему, разработчик базы данных создает искусственный тип сущности, которая выполняет функции коммутатора между двумя основными сущностями.
Пример. Для двух типов сущностей Студент и Дисциплина можно реализовать искусственный тип сущности, как показано на рисунке 4.
Рис. 4. Реализация связи «много ко многим» или M:N
Для обеспечения лучшей наглядности вышеприведенной схемы, часто реализуется упрощенный вариант, который изображен на рисунке 5. В этом случае, искусственный тип сущности изображают в виде ромба, вписанного в прямоугольник.
Рис. 5. Реализация упрощенного варианта искусственного типа сущности на ER-диаграмме
что такое мощность в базах данных?
Я искал по всему интернету, но, похоже, нет ответа, который я могу понять.
6 ответов
источником путаницы может быть использование слова в двух разных контекстах-моделирование данных и оптимизация запросов к базе данных.
в терминах моделирования данных мощность-это то, как одна таблица соотносится с другой.
есть также необязательные условия участия к вышеизложенному (где строка в одной таблице не есть для связи с другой таблицей вообще).
когда речь идет об оптимизации запросов к базе данных, кардинальность относится к данным в столбце таблицы, в частности, сколько уникальных значений в нем. Эта статистика помогает планировать запросы и оптимизировать выполнение планировавший.
это зависит немного от контекста. Кардинальность означает количество чего-то, но она используется в различных контекстах.
вероятно, есть и другие ситуации, когда люди говорят о мощности, используя другой контекст и означают что-то еще.
кардинальность относится к уникальности данных, содержащихся в столбце. Если столбец имеет много повторяющихся данных (например, столбец, в котором хранится «true» или «false»), он имеет низкую мощность, но если значения очень уникальны (например, номера социального страхования), он имеет высокую мощность.
в базе данных, мощностью понимается набор строк в таблице.
мощность множества-это количество элементов в наборе для у нас есть набор a > a,b,c
Мощность отношений (Кратность)
Мощность отношения (мулитипликатор) означает число связей между каждым экземпляром класса (объектом) в начале линии с экземпляром класса в ее конце. Различают следующие типичные случаи:
| Нотация | Объяснение | Пример |
| 0..1 | Ноль или один экземпляр | кошка имеет или не имеет хозяина |
| Обязательно один экземпляр | у кошки одна мать | |
| 0..* или * | Ноль или более экземпляров | у кошки может быть, а может и не быть котят |
| 1..* | Один или более экземпляров | у кошки есть хотя бы одно место, где она спит |
Работа в StarUML
Создание нового проекта
Запустите программу StarUML на рабочем столе. 
Создание диаграмм
Палитра элементов содержит различные типы элементов, доступных для создания в зависимости от типа диаграммы (рисунок 2). Список доступных элементов изменяется при переходе от диаграммы одного типа к диаграмме другого типа.
1.Выберите тип создаваемого элемента на палитре элементов.
2.Щёлкните желаемое место для нового элемента на диаграмме, чтобы создать там элемент.
Рис.10 Палитра элементов
Что бы редактировать созданный элемент на диаграмме, нажмите в палитре инструментов стрелочку «select» (рисунок 3). После этого вы можете выбирать элементы, изменять их имя (двойным щелчком мыши), размер и местоположение, менять их свойства (правым щелчком мыши).
Рис.11 Режим редактирования элементов
Все остальные манипуляции с элементами можно производить так же как и в любых других программах, копирование, вставка, выбор сразу нескольких элементов (при удерживании нажатой клавиши «shift») и т.д..
Создание подсистемы
1.Выберите в палитре элементов «Subsystem».
2. Затем щелкните место или границу, куда нужно поместить подсистему.
3.Сразу после создания подсистемы на диаграмме классов (справа) будет открыт её горячий диалог. В горячем диалоге, введите имя подсистемы.
Создание интерфейса подсистемы
1.Таким же образом создайте элемент «Interface».
3.Проведите линию от подсистемы к интерфейсу.
4.Между интерфейсом и подсистемой будет создано отношение реализации интерфейса (рисунок 5).
Рис.12 Отношение м/у подситемой и интерфейсом
Добавление операции к подсистеме
Рис.13 Создание операции
Или двойным щелчком левой кнопки мыши на элементе можете создавать новые операции и атрибуты или удалять их, путём нажатия «+» и «-» (рисунок 6).
Рис.14 Создание операций и атрибутов
Создание класса
Таким же образом создайте класс, выбрав элемент «Class» на панели элементов. И добавьте ему атрибут. Таким же образом можно добавлять операции классу.