DBMS - Weak Entity Types

In relational database mapping, we study different types of entity sets. There are two major types of entities: strong entities and weak entities. Understanding weak entity types is essential for grasping how relationships are organized and represented in a database. Unlike strong entities, weak entities cannot exist independently—they rely on other entities for their identification and existence.

In this chapter, we will explore weak entity types, understand why they are important, and illustrate their use with examples for better clarity.

Understanding Weak Entity Types in Relational Database Mapping

A weak entity cannot be uniquely identified by its own attributes alone. In contrast, strong entities have a primary key that uniquely identifies each instance. Weak entities, however, depend on another entity, known as the owner entity, for identification. To uniquely identify a weak entity, we must use a combination of its own attributes and the attributes from its owner entity.

Key Characteristics of Weak Entity Types

Weak entities have special distinguishing features, such as –

• No Primary Key − A weak entity lacks a unique primary key of its own.
• Dependence on Owner Entity − A weak entity exists only through its relationship with a strong (owner) entity.
• Partial Key − A weak entity has a partial key, a set of attributes that, when combined with the primary key of the owner entity, uniquely identifies the instances of the weak entity.

The Role of Identifying Relationships

To function properly within a database, every weak entity must be linked to its owner entity through an identifying relationship. This relationship ensures that the weak entity is connected to the strong entity’s primary key. Identifying relationships are crucial for maintaining the integrity and traceability of weak entities in relational database design. Let's understand it better with the help of an example.

Example − In a system that keeps track of a company's projects, the "Project" is a strong entity type, however the "Project_Department" is a weak entity type.

The "Project" has a primary key known as "Project_ID." However, the "Project_Department" entity cannot be identified just by its own attributes; it needs the "Project_ID" to be unique.

Here, Project (Strong Entity) is the entity type having attributes like "Project_ID," "Project_Name," and "Project_Budget." The "Project_ID" acts as the primary key for this entity.

Project_Department (Weak Entity) has the attributes of this weak entity that include "Dept_Name" and "Dept_Manager." However, these attributes alone are not enough to make each "Project_Department" unique across all projects.

Identifying the Relationship

In our example, let's consider "Project_Department" relies on the "Project" entity through an identifying relationship called "Belongs_To". Now each instance of "Project_Department" must be associated with a specific project, which makes the combination of "Project_ID" and "Dept_Name" the composite key that uniquely identifies the department within that project.

Importance of Weak Entity Types

We understood the basics of weak entity types. Let us now try to figure out why we need weak entities in the first place. Weak entities are important for capturing real-world scenarios where certain data cannot stand alone.

Real-World Constraints

In real-world database designing, sometimes we need to model scenarios where one entity depends another entity. For example, a project department within a company might exist only within the context of a particular project. And we can feel that it cannot be understood or identified without knowing which project it is associated with. Using a weak entity allows databases to accurately represent such cases.

Ensuring Data Integrity

When we work with weak entities, it helps to maintain the integrity of related data. By linking a weak entity to its owner through an identifying relationship, we can make sure that the data is tied to a specific project, person, or event. Every data record has to be correctly associated and maintained. This property is needed for preventing orphan records or data inconsistencies.

The Concept of Partial Keys

The idea of partial key is an interesting and quite useful concept for an attribute or set of attributes that uniquely identify a weak entity within the context of its relationship with the owner entity. It is not enough to identify the weak entity on its own. When combined with the primary key of the owner, it serves this purpose.

A partial key refers to an attribute (or a set of attributes) that can uniquely identify a weak entity, but only within the context of its relationship with an owner (strong) entity. On its own, a partial key is insufficient to identify a weak entity. However, when combined with the primary key of the owner entity, it can uniquely identify a weak entity.

Example − Consider the previously discussed example involving Project_Department. In this case, Dept_Name acts as the partial key. On its own, the Dept_Name does not uniquely identify a department. But when combined with the Project_ID from the associated Project entity, it becomes unique within that context.

How to Identify Weak Entities in ER Models?

Now that we understand the concept of weak entities, it's important to recognize them when designing a database. In Entity-Relationship (ER) diagrams, weak entities can be identified through specific notations:

• Double Rectangles − In ER diagrams, weak entities are represented using double rectangles.
• Double Diamonds − Identifying relationships that connect weak entities to their owner entities are shown using double diamonds.
• Composite Keys − A composite key, which is formed by combining the partial key of the weak entity with the primary key of the owner entity, should be clearly represented in the ER diagram.

Conclusion

In this chapter, we touched upon the basics of what weak entity types are and why they are significant in database models. We also understood how these entities differ from strong entities and the role of identifying relationships in connecting them to their owner entities. With the help of an example, we demonstrated how weak entity types work in practice. We also highlighted the basic concepts of partial keys and how they fit into identifying relationships.