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

Question

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.

Answer 1

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 :-)

Answer 2

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.

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, that then is an entity.

Marc

Answer 3

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.

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

Relational tables represent relations between 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.

For table persons,

id   name  surname
1    John  Smith

id, name and surname are entities in the real world and may or may not represent entities in the underlying ER model.

The fact of a record exists in the table means that these entities are in the following relation: "person 1 has name John and has surname Smith".

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

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

In example above name and surname can 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.

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

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 attribute is an entity which can participate in a relationship but cannot be contained in a domain-defining table.

For instance, the table 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).

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

Answer 4

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 article would get you started?

Answer 5

In the entity relationship world an entity is something that may exist independently and 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.

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

Answer 6

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).

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.

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.

Answer 7

This seems helpful: http://en.wikipedia.org/wiki/Entity-relationship%5Fmodel

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.

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

Answer 8

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