Это что-то вроде таблиц? Или он также будет включать такие вещи, как ограничения, хранимые процедуры, пакеты и т. Д.?Что такое «объект базы данных» и какие типы элементов СУБД считаются объектами?
Я осмотрел интернет, но найти элементарные ответы на элементарные вопросы иногда немного сложно.
В мире отношений сущности сущность - это то, что может существовать независимо и поэтому существует взаимно однозначное отношение между сущностями и таблицами базы данных. Однако это сопоставление является решением реализации. Например, диаграмма ER может содержать три объекта: треугольник, квадрат и круг, и они потенциально могут быть смоделированы как одна таблица: Shape.
Также обратите внимание, что некоторые таблицы базы данных могут представлять отношения между объектами.
Это зависит от того, как вы думаете об этом и как вы моделируете свой проблемный домен. в большинстве случаев, когда вы слышите о сущностях, это таблицы базы данных (один или многие), отображаемые на классы объектов. Таким образом, это не сущность, пока она не была запрошена и не превратилась в экземпляр класса.
, но опять же, это зависит от вашей методологии моделирования, и Есть несколько :-)
Это довольно общий вопрос!
В принципе, все типы, которые предлагает система базы данных, например, NUMERIC, VARCHAR и т. Д., Или что предлагаемый язык программирования (int, string и т. Д.) Будет рассматриваться как «атомные» данные (базовые).
Все, что вы - на основе требований вашей программы или бизнеса - строите из этого, бизнес-объекты и т. Д., Являются объектами.
Таблицы, ограничения и т. Д. Являются внутренними объектами базы данных, необходимыми для хранения и извлечения данных, но они вообще не считаются «сущностями». Данные, хранящиеся в ваших таблицах при извлечении и преобразовании в объект, , то тогда является сущностью.
Марк
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) является реальным объектом.
не id, имя и фамилия ATTRIBUTES, а не ENTITIES? –
В моем понимании эта строка, представляющая один «Смит, Джон» как ЦЕЛОМ, была бы сущностью –
'@ marc_s': терпение! – Quassnoi
Нам нужно знать какой-то контекст. Одна вещь, которую иногда делают люди при анализе данных в предварительном порядке для разработки базы данных, - это создать диаграмму Reality Ofity, где вы рассматриваете, какие элементы данных вы управляете и их отношения.
Интересно, это контекст, который вы имеете в виду?
Если это возможно, прочитайте об этом article, вы начнете?
В этой теме обсуждается одна причина, по которой трудно найти «элементарные ответы на элементарные вопросы». Определенные слова были использованы различными парадигмами программирования для обозначения разных вещей (попробуйте спросить кучку программистов OO, какая разница между классом и объектом когда-то).
Вот мой пример.
Я впервые встретил Entity как модельный термин в SSADM (спросите своего отца). В этом контексте сущность используется для моделирования логического набора данных на этапе сбора/анализа требований. Соотношения между объектами моделировались с использованием диаграмм Entity Relationship, а профиль Enity моделировался с использованием Entity Life Histories. Схемы ELH были очень полезны в системах COBOL, но совершенно ужасны в реляционных базах данных. С другой стороны, ERD продолжают оставаться полезными и по сей день.
Во время фаз проектирования и реализации Объекты становятся разрешенными в таблицах, объектах или записях базы данных в входном файле COBOL. В ходе этого процесса логический объект может быть разделен на несколько таблиц, или несколько объектов могут попасть в единую таблицу или может быть взаимно однозначное сопоставление. Иногда объект полностью разрешается или задерживается в виде представления или хранимой процедуры.
Это кажется полезным: http://en.wikipedia.org/wiki/Entity-relationship_model
В базе данных предприятие представляет собой таблицу. В таблице представлена любая концепция реального мира, которую вы пытаетесь моделировать (человек, транзакция, событие).
Противопоказания могут представлять собой отношения между сущностями. Это были бы иностранные ключи. Они также применяют такие правила, как first_name, не могут быть пустыми (null). Транзакция должна содержать 1 или несколько элементов. Событие должно иметь дату.
Хранимые процедуры/пакеты/триггеры могут обрабатывать более сложные отношения и/или могут обрабатывать бизнес-правила, просто зависит от того, что они делают.
большое и простое описание! - «В базе данных сущность представляет собой таблицу. Таблица представляет собой концепцию реального мира, которую вы пытаетесь моделировать (человек, транзакция, событие)». –
Объекты «вещи значимости» пользователям/бизнесу/предприятию/проблемному домену.
Мой ответ, очевидно, немного поздно, но здесь, как это определено в сертификации учебнику базы данных:
сущность: однозначно идентифицируемый элемент, о котором данные хранятся в базе данных.
и прояснить сущность и таблицы путаницы,
Entity не является таблицей. Таблицы можно назвать «таблицами» или «отношениями», слова синонимичны.
Сначала уточните свой ответ – user1972007
Я согласен с вами. «Сущность» обычно представляет собой объект реального мира. Таблица PERSON - это сущность, представляющая человека реального мира. Такие вещи, как имя, фамилия и т. Д., Являются атрибутами объекта. –