Что такое “объект базы данных” и какие типы объектов DBMS считают объектами? [закрытый]

Это кажется полезным: http://en.wikipedia.org/wiki/Entity-relationship_model

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

Ограничения могут представлять отношения между сущностями. Это будут внешние ключи. Они также применяют такие правила, как first_name не может быть пустым (нулевым). В транзакции должен быть 1 или несколько элементов. Событие должно иметь дату и время.

Хранимые процедуры / пакеты / триггеры могут обрабатывать более сложные отношения и / или они могут обрабатывать бизнес-правила, в зависимости от того, что они делают.

Это довольно общий вопрос!

По сути, все типы, которые предлагает сама система баз данных, например NUMERIC, VARCHAR и т. Д., Или которые предлагает язык программирования (int, string и т. Д.), Будут считаться "атомарными". «типы данных (базовые).

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

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

Marc

Эта ветка демонстрирует одну причину, по которой трудно найти «элементарные ответы на элементарные вопросы». Определенные слова использовались в разных парадигмах программирования для обозначения разных вещей (попробуйте как-нибудь спросить группу объектно-ориентированных программистов, в чем разница между классом и объектом).

Вот мой взгляд на это.

Я впервые наткнулся на Сущность как модельный термин в SSADM (спросите своего отца). В этом контексте Entity используется для моделирования логической группы данных на этапе сбора / анализа требований. Отношения между объектами были смоделированы с использованием диаграмм Entity Relationship, а профиль Enity был смоделирован с использованием Entity Life History. Диаграммы ELH были очень полезны в системах COBOL, но совершенно ужасны в реляционных базах данных. С другой стороны, ERD продолжают быть полезными и по сей день.

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

это зависит от того, как вы думаете об этом и как вы моделируете свою проблемную область. в большинстве случаев, когда вы слышите об объектах, это таблицы базы данных (одна или несколько), отображенные на классы объектов. Так что это не совсем сущность, пока не ' s был запрошен и преобразован в экземпляр класса.

но опять же, это зависит от вашей методологии моделирования, а их несколько: -)

Сущности являются «важными вещами» для пользователей / бизнеса / предприятия / проблемной области.

Нам нужно знать некоторый контекст. Одна вещь, которую люди иногда делают при анализе данных при подготовке к проектированию базы данных, - это создание диаграммы Entity Realtionship, где вы рассматриваете, какими элементами данных вы управляете, и их отношениями.

Интересно, вы имеете в виду этот контекст?

Если так, возможно, чтение этой статьи поможет вам начать?

Обновление:

См. Эту статью в моем блоге, в которой я пытаюсь осветить эту тему более подробно:

• Что такое модель сущности-отношения?

Сущность - это термин из модели отношения сущность .

Реляционная модель (ваша схема базы данных) является одним из способов реализации модели ER.

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

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

Для таблицы лиц ,

id   name  surname
1    John  Smith

id , name и фамилия являются сущностями в реальном мире и могут или не могут представлять сущности в базовой модели ER.

Факт наличия записи в таблице означает, что эти сущности находятся в следующей связи: « человек 1 имеет имя Джон и имеет ] фамилия Смит ".

В приведенном выше примере сущность определяется id (с точки зрения модели).

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

Например, выше имя и фамилия можно рассматривать как атрибут (в отличие от entity ), но опять же, вам нужно увидеть модель ER который реализует эта схема, чтобы узнать, что это такое.

В некоторых отображениях ER-модели в реляционную модель объект должен быть определен в таблице, на которую можно ссылаться с помощью FOREIGN KEY , чтобы считаться объектом (который должен ограничивать его домен) .

Однако это ограничение может существовать, но не может быть представлено в базе данных (из-за технологических ограничений или чего-то еще).

Например, мы не можем вести список всех возможных имен, но имя @ # $ ^ # , скорее всего, не является именем, следовательно, он не принадлежит домену имен.

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

Например, таблица price :

good_id  price

определяет отношения между набором товаров (который определяется таблицей goods ) и набором действительных чисел (которые не могут содержаться в таблице, так как они даже не подсчитываются).

Тем не менее каждая цена (например, 2,00 доллара ) также является реальной сущностью.