Сущности (службы основных данных)
Сущности — это объекты, содержащиеся в моделях 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)
Понятие ER-модели. Понятие сущности (entity). Атрибуты. Виды атрибутов
При проектировании базы данных и разработке программного продукта наиболее важной проблемой есть проблема взаимодействия разработчика с заказчиком. Задача разработчика – наиболее точно воссоздать пожелания заказчика при разработке программного продукта управления базой данных. Основная проблема, которую нужно решить разработчику – правильное построение базы данных, а точнее схемы (структуры) базы данных.
Кроме того, разработчик дополнительно встречается с другими трудностями, к которым можно отнести:
- поиск эффективных алгоритмов;
- подбор надлежащих структур данных;
- отладка и тестирование сложного кода;
- дизайн и удобство интерфейса приложения.
В процессе разработки программного обеспечения, управляющего базой данных, разработчик должен подробно выучить требования заказчика. База данных должна быть разработана таким образом, чтобы она была понятной, наиболее точно отображала решаемую проблему и не содержала избыточности в данных.
Чтобы облегчить процесс разработки (проектирования) базы данных, используются так называемые семантические модели данных. Для разных видов баз данных наиболее известной есть ER-модель данных (Entity-Relationship model).
2. Что такое ER-модель (Entity-relationship model)? Для чего нужно разрабатывать ER-модель?
ER-модель (Entity-relationship model или Entity-relationship diagram) – это семантическая модель данных, которая предназначена для упрощения процесса проектирования базы данных. Из ER-модели могут быть порождены все виды баз данных: реляционные, иерархические, сетевые, объектные. В основе ER-модели лежат понятия «сущность», «связь» и «атрибут».
Для больших баз данных построение ER-модели позволяет избежать ошибок проектирования, которые чрезвычайно сложно исправлять, в особенности, если база данных уже эксплуатируется или на стадии тестирования. Ошибки в разработке структуры базы данных могут привести к переделке кода программного обеспечения управляющего этой базой данных. В результате время, средства и человеческие ресурсы будут использованы неэффективно.
ER-модель – это представление базы данных в виде наглядных графических диаграмм. ER-модель визуализирует процесс, который определяет некоторую предметную область. Диаграмма «сущность»-«связь» – это диаграмма, которая представляет в графическом виде сущности, атрибуты и связи.
ER-модель – это только концептуальный уровень моделирования. ER-модель не содержит деталей реализации. Для той же самой ER-модели детали ее реализации могут отличаться.
3. Что такое сущность в базе данных? Примеры
Сущность в базе данных – это любой объект в базе данных, который можно выделить исходя из сути предметной области для которой разрабатывается эта база данных. Разработчик базы данных должен уметь правильно определять сущности.
Пример 1. В базе данных книжного магазина можно выделить следующие сущности:
- книга;
- поставщик;
- размещение в магазине.
Пример 2. В базе данных учета учебного процесса некоторого учебного заведения можно выделить следующие сущности:
- студенты (ученики);
- преподаватели;
- группы;
- дисциплины, которые изучаются.
4. Какие существуют разновидности типов сущностей? Обозначение типов сущностей в ER-модели
В модели «сущность»-«связь» различают две разновидности типов сущностей:
- слабый тип. Этот тип сущности есть зависимым от сильной сущности;
- сильный тип. Это самостоятельный тип сущности, который ни от кого не зависит.
На рисунке 1 изображены обозначения слабого и сильного типа сущности в ER-модели.
Рис. 1. Обозначение сильного и слабого типов сущности
5. Для чего предназначены атрибуты? Виды атрибутов. Обозначение атрибутов на ER-модели
Каждый тип сущности имеет определенный набор атрибутов. Атрибуты предназначены для описания конкретной сущности.
Различают следующие виды атрибутов:
- простые атрибуты. Это атрибуты, которые могут быть частью составных атрибутов. Эти атрибуты состоят из одного компонента. Например, к простым атрибутам можно отнести: код книги в библиотеке или курс обучения студента в учебном заведении;
- составные атрибуты. Это атрибуты, которые состоят из нескольких простых атрибутов. Например, адрес проживания может содержать название страны, населенного пункта, улицы, номера дома;
- однозначные атрибуты. Это атрибуты, которые содержат только одно единственное значение для некоторой сущности. Например, атрибут «Номер зачетной книги» для типа сущности «Студент» есть однозначным, так как студент может иметь только один номер зачетной книги (одно значение);
- многозначные атрибуты. Это атрибуты, которые могут содержать несколько значений. Например, многозначный атрибут «Номер телефона» для сущности «Студент», так как студент может иметь несколько номеров телефона (домашний, мобильный и т.д.);
- произвольные атрибуты. Это атрибуты, значение которых формируется на основе значений других атрибутов. Например, текущий курс обучения студента можно вычислить на основе разности текущего года обучения и года поступления студента в учебное заведение (если студент не имел проблем с учебой и хорошо учил дисциплину «Организация баз данных и знаний»).
На ER-диаграмме атрибуты обозначаются так, как изображено на рисунке 2. Как видно из рисунка, любой атрибут обозначается в виде эллипса с названием внутри эллипса. Если атрибут есть первичным ключом, то его название подчеркивают.
Рисунок 2. Представление атрибутов на диаграммах ER-модели
6. Как типы сущностей и атрибуты ER-модели реализуются в реальных базах данных и управляемых ими программах?
При разработке программ управления базами данных, типы сущностей и их атрибуты можно представлять по разному при этом придерживаясь нескольких подходов:
- выбрать в качестве источника данных известную технологию (например Microsoft SQL Server, Oracle Database, Microsoft Access, Microsoft ODBC Data Source и т.п.), которая уже исследована, протестирована, стандартизирована и имеет огромный набор средств управления базой данных;
- разработать собственный формат базы данных и реализовать методы ее обработки, а взаимодействие с известными источниками данных реализовать в виде специальных команд наподобие Импорт/Экспорт. В этом случае придется собственноручно программировать всю рутинную работу по ведению и обеспечению надежной работы базы данных;
- реализовать объединение двух вышеприведенных подходов. Современные средства разработки программного обеспечения имеют мощный набор библиотек для обработки сложных наборов и визуализации данных в них (коллекции, массивы, компоненты визуализации и т.п.).
Если база данных реализуется в известных реляционных СУБД (например Microsoft Access, Microsoft SQL Server и т.п.), то типы сущностей представляются таблицами. Атрибуты из ER-модели соответствуют полям таблицы. Одна запись в таблице базы данных представляет один экземпляр сущности.
Каждый вид атрибута реализуется следующим образом:
- простой атрибут или однозначный атрибут может быть представлен доступным набором базовых типов, которые есть в любом языке программирования. Например, целочисленные атрибуты представляются типом int , integer , uint и т.д.; атрибуты содержащие дробную часть могут быть представлены типом float , double ; строчные атрибуты типом string и т.д.;
- составной атрибут – это объект, который включает в себя несколько вложенных простых атрибутов. Например, в СУБД Microsoft Access составной атрибут некоторой таблицы может формироваться на основе набора простых типов (полей). В языках программирования объединение полей реализуется структурами или классами;
- многозначный атрибут может быть реализован массивом или коллекцией простых или составных атрибутов;
- произвольный атрибут реализуется дополнительным полем, которое вычисляется при обращении к таблице. Такое поле называется вычислительным полем (calculated field) и формируется на основе других полей таблицы;
- атрибут, который есть первичным ключом может быть целочисленным, строчным или иного порядкового типа. В этом случае, значение каждой ячейки таблицы, которая соответствует первичному ключу, есть уникальным. Наиболее часто, в качестве первичного ключа выступает целый тип ( int , integer ).
Если база данных реализована в уникальном формате, то типы сущностей удобнее всего представлять в виде классов или структур. Атрибуты сущности реализуются в виде полей (внутренних данных) класса. Методы класса реализуют необходимую обработку полей класса (атрибутов). Взаимодействие (связь) между классами реализуется с помощью специально разработанных интерфейсов с использованием известных шаблонов проектирования.
7. Пример фрагмента ER-модели для типа сущности «Студент»
Приведенный пример демонстрирует фрагмент ER-модели для типа сущности «Студент».
Рисунок 3. Фрагмент ER-модели для типа сущности «Студент»
На вышеприведенном рисунке объявляются следующие атрибуты, которые в СУБД (программе) могут иметь следующие типы:
- атрибут Первичный ключ – есть уникальным целочисленным значением которое формируется автоматически. В СУБД это есть поле-счетчик;
- атрибут Год вступления – простой атрибут, который можно реализовать целочисленным значением ( int , integer );
- атрибут Номер телефона – многозначный атрибут, который может быть реализован как массив или коллекция и т.п.;
- атрибут Номер зачетной книжки – простой атрибут, который можно реализовать как строку символов, поскольку номер зачетной книжки кроме цифр может содержать и буквы;
- атрибут Страна , Город , Улица , Номер дома – это атрибуты, которые образуют составной атрибут Адрес . Все эти атрибуты могут быть строчного (текстового) типа ( string , Text );
- атрибут Фамилия , Имя , Отчество – это простые атрибуты, которые являются частью составного атрибута Имя студента . Все эти атрибуты могут быть строчного (текстового) типа ( string , Text );
- атрибут День рождения – простой атрибут типа Дата ( DateTime );
- атрибут Возраст студента – вычисляемое поле, которое определяется как разность текущей (системной) даты и значения атрибута День рождения .
Связанные темы
- Подтипы сущностей. Супертип. Пример. Преимущества и недостатки применения подтипов сущностей
- Понятие связи в ER-модели. Мощность связи. Типы связей. Примеры
Можете объяснить простыми словами, в чем разница между сущностью и таблицей?
Я так понимаю, что таблица — это то, что есть в MySQL, например. А сущность — это результат запроса к этой таблице? А то и не только к ней, а даже к нескольким? Правильно?
Приведу пример.
Есть таблица books. Она содержит поля: id, author_id, genre_id. Последние два поля — это внешние ключи для таблиц authors и genres, которые содержат поля: id, title.
А есть сущность Книга. Она содержит поля: id (но обычно его скрывают), Наименование автора (authors.title), Наименование жанра (genres.title).
То есть, сущность — это более удобочитаемые данные для человека, которые являются результатом запроса к таблице(ам)?
В этом и состоит разница. Я правильно понимаю?
- Вопрос задан более трёх лет назад
- 2760 просмотров
1 комментарий
Простой 1 комментарий
sorry_i_noob @sorry_i_noob Автор вопроса
Максим Федоров, то есть, скриншот структуры таблицы и структуры сущности — это одно и то же?
Решения вопроса 2
То есть, сущность — это более удобочитаемые данные для человека, которые являются результатом запроса к таблице(ам)?
В этом и состоит разница. Я правильно понимаю?
Нет, вы наверное путаете с проекцией(указание нужных столбцов для вывода при операции select).
Сущность — это что-то, о чем хранится информация в таблице.
Если таблица Users — в ней хранится информация о сущности Пользователь.
Если таблица Cars — в ней хранится информация о сущности Автомобиль.
И т.д.
Термин сущность пришел отсюда. В реляционных базах данных информация о сущностях хранится в таблицах, но есть другие типы баз данных, где информация о сущностях хранится не в таблицах. То есть сущность — это то о чем храним информацию, а вашем случае в mysql вы храните информацию о сущностях в таблицах.
upd: для вашего случая таблица Books хранит информацию по сущности Книга, таблица Authors — хранит информацию по сущности Автор, таблица Genres — информацию пр сущности Жанр
Модель сущность-связь
Домен не указывает конкретный физический тип, однако позволяет указать, какие атрибуты будут иметь одинаковый тип в физической модели. Так, например, атрибуты $FirstName$ и $LastName$ сущности $Student$ будут обладать одним физическим типом.
Типы доменов:
- Простой — атомарное значение, например, $id$
- Составной — состоящий из нескольких значений, например, passport
Свойства атрибутов:
| Обозначение | Свойство |
|---|---|
| M | Обязательное (англ. mandatory) |
| O | Необязательное (англ. optional) |
| PK | Основной ключ (англ. primary key) |
| Kn | Дополнительный ключ $n$ (англ. key) |
- Так как любой атрибут обладает либо свойством обязательности, либо свойством необязательности, будем считать атрибуты необязательными по умолчанию, не указывая это свойство явно.
- Основной ключ можно выделить, подчеркнув атрибуты, входящие в него, сплошной линией.
Связи
Пример связи
Связь обозначается линией с двумя концами и обладает следующими характеристиками:
- Имя
- Связываемые сущности и их роли
- Тип связи (задается типами концов)
На примере показано, что студен принадлежит одной группе, а в группе может быть несколько студентов (в том числе нуль).
Типы концов:
| Тип | Обозначение |
|---|---|
| Один | |
| Много | |
| Обязательный | |
| Необязательный |
Можно выбрать значение по умолчанию, которое будет обозначаться сплошной линией без символов.
| Связь | Значение | По умолчанию |
|---|---|---|
| Многие ко многим | Единственность, необязательность | |
| Один ко многим | Единственность, обязательность | |
| Один к одному | Единственность, обязательность |
Замечание: В дальнейшем будем считать, что значениями по умолчанию будет «один» и «необязательный».
Ассоциации
| Определение: |
| Ассоциацией (англ. association) называется многосторонняя связь, нагруженная произвольными не ключевыми атрибутами. |
Графическое обозначение ассоциации
- Ассоциация обозначается прямоугольником с закругленными краями
- Может содержать не ключевые атрибуты
- Имеет произвольное количество концов с произвольными ролями и типами
Пример с ассоциацией
Проанализируем пример. Контракт заключается с одним студентом, на одну специальность, которая может быть не указана на момент заключения контракта. У контракта должен быть один или более поручителей. Контракт нагружен информацией о датах, когда контракт был подготовлен (обязательный атрибут) и подписан (опциональный атрибут, поскольку контракт может быть подписан не сразу).
Как понять, что использовать: ассоциацию, связь или сущность?
- Если нужно два конца и нет нагруженности, используем связь
- Если нужно идентифицировать, используем сущность, поскольку связь не идентифицируется из-за отсутствия ключевых элементов
- Иначе используется ассоциация
Многосторонние ассоциации
Пример неоднозначности интерпретации связей
Многостороннюю ассоциацию можно интерпретировать по-разному. Так, например, на рисунке может быть обозначено следующее:
- У каждого контракта есть один поручитель
- Можно быть поручителем у ровно одного контракта
| Ограничение по Чену (англ. Chen-like, Look-across) |
 |
Зафиксировав остальные сущности, получаем ограничение на рассматриваемую. У каждого контракта есть поручитель. |
| Ограничение по Мерис (англ. Merise-like, Look-here) |
 |
Ограничение непосредственно на сущность. Можно быть поручителем у одного контракта. |
Также существуют обобщенные ограничения (англ. generic), позволяющие зафиксировать произвольное подмножество.
Выразительная мощность ограничений
- Для ассоциаций с двумя концами:
- Чен = Мерис = Обобщенные
- Чен + Мерис = Обобщенные
- Чен + Мерис < Обобщенные
Слабые сущности
Определение: Слабой сущностью называется сущность, у которой недостаточно атрибутов для идентификации. Слабая сущность обозначается прямоугольником с двойной границей.
Определение: Идентифицирующей связью называется связь, позволяющая слабой сущности получить атрибуты, необходимые для ее идентификации. 
Пример слабой сущности
Идентифицирующая связь обозначается двойной сплошной линией.
Например, название учебной группы уникально в рамках одного университета. Если же мы будем рассматривать несколько университетов, для идентификации группы будет недостаточно лишь ее названия. В таком случае можно считать группу слабой сущностью, для идентификации которой необходим университет.
Альтернативные нотации
Выше рассматривалась нотация Crow’s foot, предложенная Гордоном Эверестом.
Нотация Питера Чена
Модель Сущность-связь была предложена Питером Ченом в 1976 году, им же была предложена следующая графическая нотация:
UML-нотация
Для каждой таблицы явно подписывается, что она обозначает (ассоциацию, сущность и т.д.). Ограничения прописываются в виде $i..k$ (например, $1..n$), это позволяет наложить ограничение $2..n$, что было невозможно в Crow’s foot.
Object Definition Language
Позволяет задавать схему базы данных кодом.
Рассмотрим пример. У студента есть идентификатор Id , имя Name , а также ссылка на группу group . Явно указываем, что противоположностью этой ссылки является соответствующее поле класса Group : inverse Group::students .
У группы есть Id и смножество студентов students , учащихся в группе. Указываем, что у студентов ссылка хранится в поле group .
В данном примере выражена связь один ко многим: студент зачислен в одну группу, в каждой группе есть несколько студентов.
class Student < int Id; string Name; Group group inverse Group::students; >class Group < int id; Setstudents inverse Student::group; >