Что такое сущность в sql

Сущности (службы основных данных)

Сущности — это объекты, содержащиеся в моделях Master Data Services. Каждая сущность содержит элементы, которые являются строками основных данных, которыми можно управлять.

Необходимо число сущностей

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

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

Связь сущностей с другими объектами модели

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

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

Сущности могут использоваться для построения производных иерархий, которые являются многоуровневыми и основанными на нескольких сущностях. Дополнительные сведения см. в разделе «Производные иерархии» (службы Master Data Services).

Сущности также могут содержать явные иерархии (неоднородные структуры на основе одной сущности) и коллекции (одноразовые комбинации подмножеств элементов). Дополнительные сведения см. в разделе «Явные иерархии» (службы Master Data Services) и коллекции (службы Master Data Services).

Использование сущностей в качестве ограниченных списков

Когда пользователи назначают атрибуты элементам в сущности, можно предоставить им выбор из ограниченного списка значений. Для этого используйте сущность для заполнения списка значений атрибута. Такой атрибут называется атрибутом на основе домена. Дополнительные сведения см. в разделе «Атрибуты на основе домена» (службы Master Data Services).

Базовые сущности

Базовая сущность является отправной точкой для пользователей при навигации по объектам в модели. Базовая сущность определяет макет экрана, когда пользователь открывает функциональную область Обозреватель и щелкает пункт Обозреватель на панели меню. Чтобы указать сущность в качестве базовой, необходимо перейти к функциональной области Администрирование системы . На странице Представление модели перетащите сущность из дерева с правой стороны на имя модели в дереве с левой стороны.

Безопасность сущности

Можно дать пользователям разрешения на сущность, которая включает связанные объекты модели. Дополнительные сведения см. в разделе «Разрешения сущностей» (службы Master Data Services).

Примеры сущности

В следующих примерах сущность имеет атрибуты: Name, Code, Subcategory, StandardCost, ListPrice и FilePhoto. Эти атрибуты описывают элементы. Каждый элемент представлен отдельной строкой значений атрибута.

В следующем примере сущность «Продукт» является центральной. Сущность «Подкатегория» является атрибутом на основе домена сущности «Продукт». Сущность «Категория» является атрибутом на основе домена сущности «Подкатегория». StandardCost и ListPrice — это атрибуты в свободной форме сущности Product, а FilePhoto — это файловый атрибут сущности Product.

Это пример на основе пользовательского интерфейса Master Data Manager. Иерархическая древовидная структура показывает отношения между сущностями и атрибутами на основе домена. Она предназначена для отображения отношений, а не для демонстрации уровней важности.

Связанные задачи

Описание задачи	Раздел
Создание новой сущности.	Создание сущности (службы Master Data Services)
Изменение имени существующей сущности.	Изменение сущности (службы Master Data Services)
Удаление существующей сущности.	Удаление сущности (службы Master Data Services)
Назначение разрешения сущностям.	Назначение разрешений объекта модели (службы Master Data Services)

См. также

• Модели (службы Master Data Services)
• Участники (службы Master Data Services)
• Атрибуты (службы Master Data Services)

Основы проектирования баз данных

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

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

1. Выделение сущностей и их атрибутов, которые будут храниться в базе данных, и формирование по ним таблиц. Атомизация сложных атрибутов на более простые.
2. Определение уникальных идентификаторов (первичных ключей) объектов, которые хранятся в строках таблицы
3. Определение отношений между таблицами с помощью внешних ключей
4. Нормализация базы данных

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

У каждой сущности определяют набор атрибутов. Атрибут представляет свойство, которое описывает некоторую характеристику объекта.

Каждый столбец должен хранить один атрибут сущности. А каждая строка представляет отдельный объект или экземпляр сущности.

Восходящий и нисходящий подходы

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

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

Например, нам дана следующая информация:

Том посещает курс по математике, который преподает профессор Смит. Сэм посещает курс по математике, которые преподает профессор Смит. Том посещает курс по языку JavaScript, который преподает ассистент Адамс. Боб посещает курс по алгоритмам, который преподает ассистент Адамс. Сэм имеет следующие электронный адрес sam@gmail.com и телефон +1235768789.

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

Затем мы можем выполнить группировку по сущностям, к которым относятся эти данные:

Дата рождения студента

Электронный адрес студента

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

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

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

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

Иногда подходы комбинируются. Для описания разных частей системы могут использоваться разные подходы. А затем их результаты объединяются.

Атомизация атрибутов

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

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

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

В соответствии с этим аспектом мы можем выделить у сущности «Студент» следующие атрибуты: имя студента, фамилия студента, год рождения, город, улица, дом, телефон.

Домен

Каждый атрибут имеет домен (domain). Домен представляет набор допустимых значений для одного или нескольких атрибутов. По сути домен определяет смысл и источник значений, которые могут иметь атрибуты.

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

Например, выше были определены атрибуты сущности Студент. Определим используемые домены:

• Имя . Домен представляет все возможные имена, которые могут использоваться. Каждое имя представляет строку длиной максимум 20 символов (маловероятно, что нам могут встретиться имена свыше 20 символов).
• Фамилия . Домен представляет все возможные фамилии, которые могут использоваться. Каждая фамилия представляет строку длиной максимум 20 символов.
• Год рождения . Домен представляет все года рождения. Каждый год является числовым значением от 1950 до 2017.
• Город . Домен представляет все города текущей страны. Каждый город представляет строку длиной максимум 50 символов.
• Улица . Домен представляет все улицы текущей страны. Каждая улица представляет строку длиной максимум 50 символов.
• Дом . Домен представляет все возможные номера домов. Каждый номер дома является числом от 1 до, скажем, 10000.
• Телефон . Домен представляет все возможные телефонные номера. Каждый номер является строкой длиной в 11 символов.

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

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

Определитель NULL

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

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

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

Что такое сущность в sql

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

Модель «сущность- отношение» (entity-relationship, ER) используется для проектирования реляционных баз данных с целью удаления всякой избыточности данных. Базовым объектом модели «сущность — отношение» является сущность, т. е. объект реального мира. Каждая сущность имеет несколько атрибутов, которые являются свойствами этой сущности и, следовательно, ее описывают. Основываясь на этом определении, можно сказать, что атрибут может быть:

♦ атомарным (т. е. атрибутом с единственным значением). Атомарный атрибут всегда представлен единственным значением для конкретной сущности. Например, супружеский статус человека (женат/замужем) всегда является атомарным атрибутом. Большинство атрибутов являются атомарными;

♦ многозначным. Многозначный атрибут может иметь одно или несколько значений для конкретной сущности. Например, location (месторасположение) в качестве атрибута для сущности enterprise (предприятие) является многозначным, поскольку каждое предприятие может иметь один или несколько адресов;

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

Сущность person в примере 1.3 имеет несколько атомарных атрибутов, один составной атрибут — Address и многозначный атрибут Collegedegree.

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

Вместе с сущностями и атрибутами отношение — еще одна базовая концепция в модели ER («сущность — отношение»). Отношение существует, если сущность ссылается на одну (или более) других сущностей. Количество присутствующих в отношении сущностей определяет уровень отношения. Например, отношение works_on между сущностями employee и project имеет второй уровень.

Каждое отношение, существующее между двумя сущностями, может иметь один из следующих трех типов: 1:1, или M:N. (Это свойство отношения также называется мощностью отношения.) Например, отношение между сущностями department и employee — это отношение, потому что каждый служащий принадлежит в точности одному отделу, который, в свою очередь, содержит одного или более служащих. А отношение между сущностями project и employee является отношением M:N, потому что каждый проект задействует одного или более служащих, и каждый служащий работает в одно и то же время над одним или более проектами.

Отношение в свою очередь может иметь собственные атрибуты. На рис. 1.1 показан пример диаграммы ER. (Диаграмма ER — это графическое представление, нотация, используемая для описания модели ER.)

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

Можете объяснить простыми словами, в чем разница между сущностью и таблицей?

Я так понимаю, что таблица — это то, что есть в MySQL, например. А сущность — это результат запроса к этой таблице? А то и не только к ней, а даже к нескольким? Правильно?
Приведу пример.

Есть таблица books. Она содержит поля: id, author_id, genre_id. Последние два поля — это внешние ключи для таблиц authors и genres, которые содержат поля: id, title.
А есть сущность Книга. Она содержит поля: id (но обычно его скрывают), Наименование автора (authors.title), Наименование жанра (genres.title).

То есть, сущность — это более удобочитаемые данные для человека, которые являются результатом запроса к таблице(ам)?

В этом и состоит разница. Я правильно понимаю?

• Вопрос задан более трёх лет назад
• 2573 просмотра

1 комментарий

Простой 1 комментарий

sorry_i_noob @sorry_i_noob Автор вопроса
Максим Федоров, то есть, скриншот структуры таблицы и структуры сущности — это одно и то же?
Решения вопроса 2

То есть, сущность — это более удобочитаемые данные для человека, которые являются результатом запроса к таблице(ам)?

В этом и состоит разница. Я правильно понимаю?

Нет, вы наверное путаете с проекцией(указание нужных столбцов для вывода при операции select).

Сущность — это что-то, о чем хранится информация в таблице.
Если таблица Users — в ней хранится информация о сущности Пользователь.
Если таблица Cars — в ней хранится информация о сущности Автомобиль.
И т.д.

Термин сущность пришел отсюда. В реляционных базах данных информация о сущностях хранится в таблицах, но есть другие типы баз данных, где информация о сущностях хранится не в таблицах. То есть сущность — это то о чем храним информацию, а вашем случае в mysql вы храните информацию о сущностях в таблицах.

upd: для вашего случая таблица Books хранит информацию по сущности Книга, таблица Authors — хранит информацию по сущности Автор, таблица Genres — информацию пр сущности Жанр