COMP102: Introduction to Databases, 9.1 Dr Muhammad Sulaiman Khan Department of Computer Science University of Liverpool U.K. 21/22 February, 2011
Database Analysis and Design Techniques: Entity-Relationship Modeling, part I
Specific topics for today: How to use Entity-Relationship (ER) modeling in database design. The basic concepts of an ER model called entities, relationships, and attributes. A diagrammatic technique based on UML for displaying an ER model.
Entity-Relationship (ER) modeling Top-down approach to database design. Start by identifying the important data (called entities) and relationships between the data. Then add more details such as the information we want to hold about the entities and relationships (called attributes) and any constraints on the entities, relationships, and attributes.
Entities Entity: A set of objects with the same properties, which are identified by a user or organization as having an independent existence. Entity occurrence: Each uniquely identifiable object within the set, i.e., the entity.
Entities with physical and conceptual existence
ER diagram of entities
Relationships Relationship: A set of meaningful associations among entities. Relationship occurrence: Each uniquely identifiable association within the set, i.e., the relationship. Note: Relationship corresponds to a notion of relation in maths, where it basically means a subset of a given universe set.
ER diagram of relationships
Relationships Degree of a relationship: The number of participating entities in the relationship. Relationship of degree: one is unary. two is binary. three is ternary. four is quaternary. n is n-ary.
Example: ternary relationship
Example: unary relationship Relationship IsManager in entity Staff.
Recursive relationships Recursive relationship: Relationship where same entity participates more than once in different roles. Relationships may be given role names to indicate purpose that each participating entity plays in a relationship. Question: Can an unary relationship be recursive?
Example: Recursive relationship
Attributes Attribute: Property of an entity or a relationship. Hold values that describe each occurrence of an entity or relationship, and represent the main source of data stored in the database. Attribute can be classified as being: simple or composite single-valued or multi-valued or derived
Attributes Simple attribute: Attribute composed of a single component. Composite attribute: Attribute composed of multiple components. Single-valued attribute: Attribute that holds a single value for an entity occurrence. Multi-valued attribute: Attribute that holds multiple values for an entity occurrence. Derived attribute: Attribute that represents a value that is derivable from value of a related attribute, or set of attributes, not necessarily in the same entity.
Example: Kinds of Attributes Simple attribute: E.g., attribute catalogno in entity Video.. Composite attribute: E.g., attribute name in entity Staff, composed of (first name,last name). Single-valued attribute: E.g., attribute catalogno in entity Video. Multi-valued attribute: E.g., attribute category in entity Video; e.g., a video can have category Children and Comedy. Simple multi-valued attribute: E.g., attribute category as above. Derived attribute: E.g., attribute age derivable from attribute DOB date of birth. E.g., attribute nameofmgr (name of manager) in entity Branch, derivable from attributes mgrstaffno, staffno, name in entities Branch and Staff.
Keys Superkey: An attribute, or set of attributes, that uniquely identifies each entity occurrence. Candidate key: A superkey K such that no proper subset of K is a superkey within the entity. Primary key: The candidate key that is selected to identify each entity occurrence. Alternate keys: The candidate keys that are not selected as the primary key of the entity.
Example: ER diagram of entities and their attributes
Strong and weak entities Strong entity: Entity that is not dependent on the existence of another entity for its primary key. Weak entity: Entity that is partially or wholly dependent on the existence of another entity, or entities, for its primary key. Example: Actor and Video are strong entities, because we can distinguish one actor (video) from another actor (video, resp.) without the existence of any other entity; they have their own primary keys. Example: Role is weak entity, because we are not able to distinguish one Role entity occurrence from another without the existence of the Actor and Video entities; this entity has no primary key on its own.
Multiplicity constraints on relationships Multiplicity: Represents the number of occurrences of one entity that may relate to a single occurrence of an associated entity. Represents policies (called business rules) established by user or company.
Multiplicity constraints The most common degree for relationships is binary. Binary relationships are generally referred to as being: one-to-one (1:1) one-to-many (1:*) many-to-many (*:*)
Example: 1:1 relationship: (a) individual examples, (b) multiplicity (UML)
1:1 relationship: More precisely Note: Relationships are usually directed, e.g., from entity Staff to Branch and vice-versa. For each entity occurrence at one end, we set the range of entity occurrences at the other end that it can be associated with. Each staff member manages 0..1 branches. Each branch is managed by 1..1, i.e., precisely 1, staff members.
Example: 1:* relationship: (a) individual examples, (b) multiplicity (UML)
Example: *:* relationship: (a) individual examples, (b) multiplicity (UML)
Complex relationships Multiplicity is the number (or range) of possible occurrences of an entity type in an n-ary relationship when other (n 1) values are fixed.
Example: Complex relationship: (a) individual examples, (b) multiplicity (UML)
Summary of multiplicity constraints
Multiplicity Multiplicity is made up of two types of restrictions on relationships: Cardinality: Describes the maximum number of possible relationships for each participating entity. Participation: Determines whether all or only some entity occurrences participate in a relationship.
Example: Multiplicity as cardinality and participation constraints