Это что-то вроде таблиц? Или он также будет включать такие вещи, как ограничения, хранимые процедуры, пакеты и т.д.?
Я просмотрел интернет, но найти элементарные ответы на элементарные вопросы иногда немного сложно.
В мире отношений сущности сущность - это нечто, что может существовать независимо, и поэтому часто существует взаимно однозначное отношение между сущностями и таблицами базы данных. Однако это сопоставление является решением реализации: например, диаграмма ER может содержать три объекта: Треугольник, Квадрат и Круг, и они потенциально могут быть смоделированы как одна таблица: Форма.
Также обратите внимание, что некоторые таблицы базы данных могут представлять отношения между объектами.
Это довольно общий вопрос!
В принципе, все типы, предлагаемые системой базы данных, такие как NUMERIC, VARCHAR и т.д., или что предлагаемый язык программирования (int, string и т.д.) будет рассматриваться как "атомные" данные (базовые).
Все, что вы - на основе требований вашей программы или бизнеса - основывается на этом, бизнес-объектах и т.д., - это сущности.
Таблицы, ограничения и т.д. являются внутренними объектами базы данных, необходимыми для хранения и извлечения данных, но они вообще не считаются "сущностями". Данные, хранящиеся в ваших таблицах при извлечении и преобразовании в объект, , который, затем являются сущностью.
Марк
Это кажется полезным: http://en.wikipedia.org/wiki/Entity-relationship_model
В базе данных сущность представляет собой таблицу. Таблица представляет собой концепцию реального мира, которую вы пытаетесь моделировать (человек, транзакция, событие).
Контракты могут представлять отношения между сущностями. Это были бы иностранные ключи. Они также применяют такие правила, как first_name, не могут быть пустыми (null). Транзакция должна содержать 1 или несколько элементов. Событие должно иметь дату.
Хранимые процедуры/пакеты/триггеры могут обрабатывать более сложные отношения и/или могут обрабатывать бизнес-правила, просто зависит от того, что он делает.
Этот поток разрушает одну причину, по которой трудно найти "элементарные ответы на элементарные вопросы". Определенные слова были использованы различными парадигмами программирования для обозначения разных вещей (попробуйте спросить кучу программистов OO, какая разница между классом и объектом когда-нибудь).
Здесь я принимаю это.
Я впервые встретил Entity как модельный термин в SSADM (спросите своего папу). В этом контексте сущность используется для моделирования логического набора данных на этапе сбора/анализа требований. Соотношения между объектами моделировались с использованием диаграмм Entity Relationship, а профиль Enity моделировался с использованием Entity Life Histories. Схемы ELH были очень полезны в системах COBOL, но совершенно ужасны в реляционных базах данных. С другой стороны, ERD продолжают оставаться полезными и по сей день.
На этапах проектирования и реализации Entities получают решения в таблицах, объектах или записях базы данных в входном файле COBOL. В ходе этого процесса логический объект может быть разделен на несколько таблиц, или несколько объектов могут попасть в единую таблицу или может быть взаимно однозначное сопоставление. Иногда объект полностью разрешается или задерживается как представление или хранимая процедура.
Мой ответ, очевидно, немного поздний, но здесь он определен в учебнике по сертификации базы данных:
Entity: уникально идентифицируемый элемент, по которому данные хранятся в базе данных.
и для устранения путаницы сущностей и таблиц,
Сущность не является таблицей. Таблицы можно назвать "таблицами" или "отношениями", слова синонимичны.
Это зависит от того, как вы думаете об этом и как вы моделируете свой проблемный домен. в большинстве случаев, когда вы слышите о сущностях, это таблицы базы данных (один или многие), отображаемые на классы объектов. Таким образом, это не действительно сущность, пока она не была запрошена и не превратилась в экземпляр класса.
но опять же, это зависит от вашей методологии моделирования, и есть несколько: -)
Update:
См. эту статью в своем блоге, в которой я более подробно расскажу о предмете:
Сущность - это термин из entity-relationship model.
A relational model (ваша схема базы данных) является одним из способов реализации модели ER.
Реляционные таблицы представляют собой отношения между простыми типами, такими как целые числа и строки, которые, в свою очередь, могут представлять все: сущности, атрибуты, отношения.
Вы не можете сказать, что это только из реляционной структуры, вам нужно увидеть модель ER.
Для таблицы persons,
id name surname
1 John Smith
id, name и surname являются объектами в реальном мире и могут или не могут представлять объекты в базовой модели ER.
Факт записи в таблице означает, что эти сущности находятся в следующем соотношении: "person 1 имеет имя John и имеет фамилию Smith".
В приведенном выше примере сущность определяется id (с точки зрения модели).
Если человек меняет свое имя от John до Jack, человек остается тем же (опять же, с точки зрения модели), но получает связь с другим name.
В примере выше name и surname можно рассматривать как attribute (в отличие от entity), но опять же, вам нужно увидеть модель ER, которую эта схема реализует, чтобы сообщить, что это такое.
В некоторых сопоставлениях ER-реляционной модели сущность должна быть определена в таблице, ссылающейся на FOREIGN KEY, которая должна считаться entity (которая должна ограничивать его домен).
Однако это ограничение может существовать, но не быть представлено в базе данных (из-за технологических ограничений или чего-то еще).
Например, мы не можем хранить список всех возможных имен, но имя @#$^#, скорее всего, является не-именем, следовательно, оно не относится к домену имен.
Следовательно, attribute является entity, который может участвовать в связи, но не может содержаться в определяющей домене таблице.
Например, таблица prices:
good_id price
определяет отношения между множеством товаров (которые определяются таблицей goods) и множеством действительных чисел (которые не могут содержаться в таблице, поскольку она не является даже счетной).
Тем не менее, каждая цена (например, $2.00) также является реальным объектом.
Нам нужно знать какой-то контекст. Одна вещь, которую иногда делают люди при анализе данных в преддверии для разработки базы данных, - это создать диаграмму реальности Entity, где вы рассматриваете, какие элементы данных вы управляете, и их отношения.
Интересно, понимаете ли вы этот контекст?
Если это возможно, прочитайте эту статью , чтобы вы начали?
Сущности "имеют значение" для пользователей/бизнес/корпоративных/проблемных областей.