database 什么是“数据库实体”，哪些类型的 DBMS 项目被视为实体？

What is a "database entity" and what types of DBMS items are considered entities?

提问by IAmAN00B

Is it things like tables? Or would it also include things like constraints, stored procedures, packages, etc.?

是桌子之类的东西吗？或者它还包括约束、存储过程、包等？

I've looked around the internet, but finding elementary answers to elementary questions is sometimes a little difficult.

我环顾了互联网，但找到基本问题的基本答案有时有点困难。

采纳答案by Adamski

In the entity relationship world an entity is something that may exist independentlyand so there is often a one-to-one relationship between entities and database tables. However, this mapping is an implementation decision: For example, an ER diagram may contain three entities: Triangle, Square and Circle and these could potentially be modelled as a single table: Shape.

在实体关系世界中，实体是可能独立存在的东西，因此实体和数据库表之间通常存在一对一的关系。但是，此映射是一个实现决策：例如，ER 图可能包含三个实体：三角形、正方形和圆形，并且这些实体可能被建模为单个表：形状。

Also note that some database tables may represent relationships between entities.

另请注意，某些数据库表可能表示实体之间的关系。

回答by marc_s

That's quite a general question!

这是一个很普遍的问题！

Basically, all types that the database system itself offers, like NUMERIC, VARCHAR etc., or that the programming language of choice offers (int, string etc.) would be considered "atomic" data(base) types.

基本上，数据库系统本身提供的所有类型，如 NUMERIC、VARCHAR 等，或者选择的编程语言提供的（int、string 等）都将被视为“原子”数据（基础）类型。

Anything that you - based on your program's or business' requirements - build from that, business objects and so forth, are entities.

您基于程序或业务的需求构建的任何东西，业务对象等等，都是实体。

Tables, constraints and so forth are database-internal objects needed to store and retrieve data, but those are general not considered "entities". The data stored in your tables, when retrieved and converted into an object, thatthen is an entity.

表、约束等是存储和检索数据所需的数据库内部对象，但它们通常不被视为“实体”。所存储的数据在表中，检索并转换为对象时，即然后是一个实体。

Marc

马克

回答by David

This seems helpful: http://en.wikipedia.org/wiki/Entity-relationship_model

这似乎有帮助：http: //en.wikipedia.org/wiki/Entity-relationship_model

In a database an entity is a table. The table represents whatever real world concept you are trying to model (person, transaction, event).

在数据库中，实体是一个表。该表代表您尝试建模的任何现实世界概念（人、交易、事件）。

Contraints can represents relationships between entities. These would be foreign keys. They also enforce rules like first_name can not be blank (null). A transaction must have 1 or more items. An event must have a date time.

约束可以表示实体之间的关系。这些将是外键。他们还强制执行诸如 first_name 不能为空 (null) 之类的规则。一个交易必须有 1 个或多个项目。事件必须有日期时间。

Stored Procedures / Packages / Triggers could handle more complex relationships and/or they can handle business rules, just depends on what it's doing.

存储过程/包/触发器可以处理更复杂的关系和/或它们可以处理业务规则，这取决于它在做什么。

回答by APC

This thread is demomnstrating one reason why it is difficult to find "elementary answers to elementary questions". Certain words have been used by different programming paradigms to mean different things (try asking a bunch of OO programmers what is the difference between a Class and an Object sometime).

这个帖子展示了为什么很难找到“基本问题的基本答案”的一个原因。不同的编程范式使用某些词来表示不同的东西（有时尝试询问一群 OO 程序员，类和对象之间有什么区别）。

Here's my take on it.

这是我的看法。

I first came across Entity as a modelling term in SSADM (ask your dad). In that context an Entity is used to model a logical clump of datas during the requirements gathering / analysis phase. The relationships between entities were modelled using the Entity Relationship diagrams, and the profile of an Enity was modelled using Entity Life Histories. ELH diagrams were very useful in COBOL systems but utterly horrible in relational databases. ERDs on the other hand continue to be useful to this day.

我第一次遇到 Entity 作为 SSADM 中的建模术语（问问你爸爸）。在这种情况下，实体用于在需求收集/分析阶段对逻辑数据块进行建模。实体之间的关系使用实体关系图建模，实体的配置文件使用实体生命历史建模。ELH 图在 COBOL 系统中非常有用，但在关系数据库中却非常糟糕。另一方面，ERD 直到今天仍然有用。

During the design and implementation phases the Entities get resolved into database tables, objects or records in a COBOL input file. In the course of that process a logical entity may get split across multiple tables, or several entities may get squidged into a single table, or there may be a one-to-one mapping. Sometimes an entity is resolved away entirely or lingers on as a view or a stored procedure.

在设计和实施阶段，实体被解析为 COBOL 输入文件中的数据库表、对象或记录。在该过程中，一个逻辑实体可能会被拆分到多个表中，或者多个实体可能会被挤入一个表中，或者可能存在一对一的映射。有时，实体会被完全解析或作为视图或存储过程存在。

回答by Billy

My answer is obviously a little late, but here it is as defined in a database certification text book:

我的回答显然有点晚了，但这里是在数据库认证教科书中定义的：

Entity: A uniquely identifiable element about which data is stored in a database.

实体：一个唯一可识别的元素，关于它的数据存储在数据库中。

and to clear up entity and table confusion,

并清除实体和表的混乱，

Entity is not a table. Tables can be called "tables" or "relations" the words are synonymous.

实体不是表。表可以称为“表”或“关系”这两个词是同义词。

回答by ObiWanKenobi

Entities are "things of significance"to the users/business/enterprise/problem domain.

实体对于用户/业务/企业/问题域来说是“重要的事物”。

回答by Quassnoi

Update:

更新：

See this article in my blog in which I try to cover the subject in more detail:

请参阅我博客中的这篇文章，我尝试更详细地介绍该主题：

• What is entity-relationship model?

• 什么是实体关系模型？

---

---

An entity is a term from the entity-relationship model.

实体是来自 的术语entity-relationship model。

A relational model(your database schema) is one of the ways to implement the ER model.

A relational model（您的数据库模式）是实现 ER 模型的方法之一。

Relational tables represent relationsbetween simple types like integers and strings, which, in their turn, can represent everything: entities, attributes, relationships.

关系表代表简单类型（如整数和字符串）之间的关系，而这些类型又可以代表一切：实体、属性、关系。

You cannot tell what is it only from the relational structure, you need to see the ER model.

仅从关系结构无法分辨它是什么，您需要查看ER模型。

For table persons,

对于表persons，

id   name  surname
1    John  Smith

id, nameand surnameare entities in the real world and may or may not represent entities in the underlying ER model.

id，name并且surname是现实世界中的实体，可能代表也可能不代表底层 ER 模型中的实体。

The fact of a record exists in the table means that these entities are in the following relation: "person 1hasname Johnand hassurname Smith".

记录的事实表中存在意味着这些实体是具有以下关系：“person 1有名字John和有姓Smith”。

In the example above, the entity is defined by id(from the model's point of view).

在上面的例子中，实体是由id（从模型的角度）定义的。

If a person changes his name from Johnto Hyman, the person remains the same (again, from the model's point of view), but gets related to another name.

如果一个人将他的名字从 更改John为Hyman，则此人保持不变（同样，从模型的角度来看），但与另一个 相关name。

In example above nameand surnamecan be treated as attribute(as opposed to entity), but again, you need to see the ER model which this schema implements to tell what is it.

在上面的示例中name，surname可以将其视为attribute（与 相对entity），但同样，您需要查看此模式实现的 ER 模型以了解它是什么。

In some ER-to-relational model mappings, an entity should be defined in a table referenceable with a FOREIGN KEYto be considered an entity(which should constrain its domain).

在一些 ER 到关系模型的映射中，一个实体应该定义在一个可引用的表中FOREIGN KEY，被认为是一个entity（应该限制它的域）。

However, this constraint can exist but not be represented in a database (due to technological limitations or something else).

但是，此约束可以存在但不能在数据库中表示（由于技术限制或其他原因）。

Like, we cannot keep a list of all possible names, but the name of @#$^#is most probably a non-name, hence, it does not belong to the domain of names.

就像，我们不能保留所有可能名称的列表，但名称@#$^#很可能是非名称，因此，它不属于名称域。

Therefore, an attributeis an entitywhich can participate in a relationship but cannot be contained in a domain-defining table.

因此，可以参与关系但不能包含在域定义表中的anattribute是 an entity。

For instance, the table prices:

例如，表prices：

good_id  price

defines relationships between the set of goods (which is defined by the table goods) and the set of real numbers (which cannot be contained in a table since it's not even countable).

定义商品集（由 table 定义goods）和实数集（它不能包含在表中，因为它甚至不可数）之间的关系。

Still each price (like $2.00) is a real-world entity just as well.

仍然每个价格（如$2.00）也是一个真实世界的实体。

回答by djna

We'd need to know some context. One thing people sometimes do when analysing data in prepartion for designing a database is to create an Entity Realtionship Diagram, where you are considering what data items you are managing and their relationships.

我们需要了解一些背景信息。人们在为设计数据库做准备时分析数据时有时会做的一件事是创建实体关系图，您可以在其中考虑正在管理的数据项及其关系。

I wonder if that's the context you mean?

我想知道这是否是您的意思？

If so perhaps a read of this articlewould get you started?

如果是这样，也许阅读这篇文章会让你开始？

回答by Joel Martinez

it kind of depends how you think about it and how you model your problem domain. most of the time when you hear about entities, they are database tables (one or many) mapped onto object classes. So it's not really an entity until it's been queried for and turned into a class instance.

这有点取决于您如何看待它以及您如何对问题域进行建模。大多数情况下，当您听说实体时，它们是映射到对象类的数据库表（一个或多个）。所以在它被查询并变成一个类实例之前，它并不是一个真正的实体。

but again, it depends on your modeling methodology, and there are multiple :-)

但同样，这取决于您的建模方法，并且有多种 :-)