Day 3 - Entities

📌 Key Takeaways

• An entity is a collective thing for storing and managing information that is needed and useful to the business. It becomes a candidate for a table.
• Six characteristics of an entity: needed by the business, uniquely identified by an identifier, two or more instances, used by business processes, contains attributes, and has at least one relationship.
• By tangibility, entities are divided into tangible, conceptual, and event entities.
• By time of occurrence, entities are divided into basic (key), main, and transaction (action) entities. For an online store, that is Customer/Product, then Order, then Order Item/Order History.
• Entity names should use business terminology, as singular nouns, and be unique within the model.

What Becomes an Entity

The online store's planning meeting notes contain the sentence "When a customer orders the products in their cart, we pay and then ship." Pulling out the nouns gives customer, cart, product, order, payment, and shipment. These nouns are entity candidates. But not every noun becomes an entity. It must meet all of the characteristics below.

Definition

• It is a collective thing (Thing) for storing and managing information that is needed and useful to the business.
• It is a real thing or a concept that is the target of business activity. A visible product and an invisible order can both be entities.
• An entity is a set of instances. The "Customer" entity holds instances such as C001 Gildong Hong and C002 Younghee Kim.

Characteristics of an Entity

• If there is only one instance, it is not a set, so it is not treated as an entity. If the online store company's own information (business name, business registration number) is just one record, you don't make it an entity.
• If there is an entity that no business process uses, that is a sign the business analysis is incomplete or the entity is unnecessary. It serves as a criterion for checking, during modeling, whether a process has been left out.
• An entity whose only attribute is the primary identifier is also not treated as an ordinary business entity. However, exceptions are sometimes allowed, as with code entities.

⚠️ The "at least one relationship" rule has exceptions. Statistical entities, code entities, and internal entities for system processing (such as transaction logs) are sometimes drawn without relationships. This is because a code entity is referenced by many entities, which would make the relationship lines excessive.

Classification by Tangibility

• It is sometimes shortened to two kinds, "tangible/intangible," but the SQLD textbook's classification has three: tangible, conceptual, and event. The intangible ones are conceptual and event.
• Conceptual and event entities both have no form. The difference is whether they occur during business operations. The "Gold tier" is a concept that is set up in advance and used, while an "order" is an event that arises each time a customer acts.
• An insurance product looks tangible, but it is not a physical object, so it is classified as a conceptual entity. Don't assume something is tangible just because its name contains "product."

Classification by Time of Occurrence

Classification by time of occurrence looks at "can it come into being on its own without other entities?"

  Basic entity           Main entity             Transaction entity
  ┌──────────┐
  │ Customer │ ─────────▶ ┌───────┐
  └──────────┘            │ Order │ ──────────▶ ┌────────────┐
                          └───────┘             │ Order Item │
  ┌──────────┐                                  └────────────┘
  │ Product  │ ───────────────────────────────────────▲
  └──────────┘

• An order comes into being only when a customer exists. That is why Customer is a basic entity and Order is a main entity.
• An order item arises from two parents: the order and the product. That is why it is a transaction entity.
• Transaction entities don't show up easily in the early stages of analysis. They are often derived during the detailed design stage or during process-and-data interaction modeling.
• The primary identifier of a basic entity is its own, not inherited from a parent. A customer has its own customer ID.

Looking at the Two Classifications Together

Summarizing where the same entity falls under each of the two criteria reduces confusion.

• The two criteria are separate axes. They do not correspond one-to-one, as in "event entity = main entity."
• Membership Tier has no physical form, so it is a conceptual entity, and since it can be set up without other entities, it is also a basic entity.
• How a particular entity is classified can differ by textbook and example depending on how the business is defined. On the exam, judge by the definition sentences (created independently / arises from basic entities / two or more parents).

Naming Entities

• The reason for using singular nouns is that an entity is already a set. Writing "Customers" reads like a set of sets.
• Names must be unique so there is no misunderstanding in communication. If the same "Shipment" means dispatch on one side and return pickup on the other, each person reading the model will interpret it differently.

Tomorrow we'll cover the types of attributes that fill an entity, and domains.

📖 Glossary

• Entity : A set for storing and managing information needed by the business. It becomes a table candidate.
• Instance : Each individual set of actual values held in an entity. One customer, Gildong Hong, in the Customer entity.
• Identifier : An attribute that tells the instances in an entity apart one by one. Something like a customer ID.
• Event entity : An entity that arises while the business is being carried out. Like orders and payments, it has high volume.
• Basic entity (key entity) : An entity created independently without other entities. It becomes a parent of other entities.
• Main entity : An entity that arises from basic entities and plays the central role in the business.
• Transaction entity : An entity that arises from two or more parent entities. Data keeps accumulating.
• Code entity : An entity that manages a list of values, like tiers or statuses. Relationships are sometimes omitted when drawing it.