Weak Entity Types

• Strong entity types are those that have a key attribute of their own.

• Weak entity types are entity types that do not have key attributes of their own.

Entities of a weak entity type are identified by being related to specific entities from another (owner) entity type, combined with one or more of their own attribute values.

---

Identifying Relationships

• The owner or identifying entity type provides the context needed to identify a weak entity.

• The relationship that connects a weak entity to its owner is called the identifying relationship.

• A weak entity type always has total participation in its identifying relationship, because it cannot exist without being related to an owner entity.

Not every entity related to another is weak. For example, DRIVER_LICENSE has its own key (License_number), so even though it’s related to PERSON, it is a strong entity, not weak.

---

DEPENDENT

The entity type DEPENDENT is related to EMPLOYEE to track dependents via a 1:N relationship.

• Two dependents (from different employees) may share the same values for attributes like Name, Birth_date, Sex, and Relationship.

• However, they are considered distinct because they are connected to different EMPLOYEE entities.

• The employee owns the dependent entities related to them.

---

Partial Key

• A partial key is an attribute (or set of attributes) that uniquely identifies a weak entity within the context of its identifying relationship.

• It is not sufficient alone to identify the entity, but combined with the owner entity’s key, it becomes unique.

---

ER Diagram Notation

• A weak entity type is represented by a double rectangle.

• Its identifying relationship is shown as a double diamond.

• The partial key attribute is underlined using a dashed or dotted line.

---

• Weak entities can exist at multiple levels, i.e., a weak entity may have its own weak dependents.

• A weak entity can also be identified by more than one owner, meaning the identifying relationship can have degree higher than two.

---

ER Diagrams, Naming Conventions, and Design Issues

Proper Naming of Schema Constructs

Good naming helps improve schema clarity and usability. The following conventions are generally followed:

• Entity type names and relationship type names: written in UPPERCASE and in the singular form (e.g., EMPLOYEE, MANAGES).

• Attribute names: capitalize the first letter of each word (e.g., StartDate, BirthDate).

• Role names: written in lowercase (e.g., manager, worker).

• Nouns in the real-world narrative often become entity types.

• Verbs often indicate relationship types.

• Adjectives or descriptive nouns usually correspond to attributes.

---

Design Choices in ER Conceptual Modeling

Sometimes, it can be unclear whether a miniworld concept should be modeled as:

• An entity type

• An attribute

• A relationship type

Refining Attributes into Relationships

• If an attribute is actually a reference to another entity, it should be modeled as a relationship.

• If two such attributes are inverse references, they are better modeled as a binary relationship.

• Once converted into a relationship, the attribute should be removed from the entity to avoid duplication.

Promoting Attributes to Entity Types

• If the same attribute appears in multiple entity types, it may be promoted to an independent entity type.

In a UNIVERSITY database, if STUDENT, INSTRUCTOR, and COURSE all have a Department attribute, it may be better to create a separate DEPARTMENT entity with an attribute like Dept_name, and then relate it to the other entities with proper relationships.