The Entity-Relationship Model (ERM) is a conceptual framework for database design, capturing entities, their attributes, and relationships. Entity-Relationship Diagrams (ERDs) visually represent this model, using symbols like rectangles and diamonds to illustrate entities and connections, facilitating the design and understanding of relational databases.ERDs serve as a valuable tool in visualizing and planning the structure of a database.
Original Title
Entity relationship model and entity-relationship diagrams
The Entity-Relationship Model (ERM) is a conceptual framework for database design, capturing entities, their attributes, and relationships. Entity-Relationship Diagrams (ERDs) visually represent this model, using symbols like rectangles and diamonds to illustrate entities and connections, facilitating the design and understanding of relational databases.ERDs serve as a valuable tool in visualizing and planning the structure of a database.
The Entity-Relationship Model (ERM) is a conceptual framework for database design, capturing entities, their attributes, and relationships. Entity-Relationship Diagrams (ERDs) visually represent this model, using symbols like rectangles and diamonds to illustrate entities and connections, facilitating the design and understanding of relational databases.ERDs serve as a valuable tool in visualizing and planning the structure of a database.
model and entity-relationship diagrams The Entity Relationship (ER) Model • ER model forms the basis of an ER diagram • ERD represents a conceptual database as viewed by the end user • ERDs depict the database’s main components: • Entities: A “thing” or “object” in the real world that is distinguishable from other objects. • Attributes: A property of an entity • Relationships: An association among several entities. The Entity Relationship (ER) Model • Peter Chen introduced the ER data model in 1976; the graphical representation of entities and their relationships in a database structure quickly became popular because it complemented the relational data model concepts. • The relational data model and ERM combined provide the foundation for tightly structured database design. • Crow's foot notation, the beginning of which dates back to an article by Gordon Everest (1976). The Entity Relationship (ER) Model The Entity Relationship (ER) Model The Entity Relationship (ER) Model • Increasingly complex real-world problems demonstrated a need for a data model that more closely represented the real world. • In the object-oriented data model (OODM), both data and its relationships are contained in a single structure known as an object. • In turn, the OODM is the basis for the object-oriented database management system (OODBMS). Evolution of Data Models Evolution of Data Models
Study Table 2.2 for advantages
and disadvantages of these famous data models. Entities • Refers to entity set and not to single entity occurrence • Corresponds to table and not to row in relational environment • In both Chen and Crow’s Foot models, entity is represented by rectangle containing entity’s name • Entity name, a noun, is usually written in capital letters Attributes • Characteristics of entities • Sometimes referred to as properties • In Chen model, attributes are represented by ovals and are connected to entity rectangle with a line • Each oval contains the name of attribute it represents • In Crow’s Foot model, attributes are written in attribute box below entity rectangle Attributes Primary Keys • Underlined in the ERD • Key attributes are also underlined in frequently used table structure shorthand • For example, a CAR entity may be represented by
CAR (CAR_VIN, MOD_CODE, CAR_YEAR, CAR_COLOR)
The Entity Relationship (E-R) Model • Classes of Attributes • A simple attribute cannot be subdivided. • Examples: Age, Gender, and Marital status • A composite attribute can be further subdivided to yield additional attributes. • Examples: • ADDRESS Street, City, State, Zip • PHONE NUMBER Area code, Exchange number • NAME last, first, Middle The Entity Relationship (E-R) Model • Classes of Attributes • A single-valued attribute can have only a single value. • Examples: • A person can have only one CNIC number. • A manufactured part can have only one serial number. • A student can only have one GPA • Multivalued attributes can have many values. • Examples: • A person may have several college degrees. • A household may have several phones with different numbers • Cars can have multiple colors • Multivalued attributes are shown by a double line connecting to the entity. The Entity Relationship (E-R) Model • Multivalued Attribute in Relational DBMS • relational DBMS cannot implement multivalued attributes. • Possible courses of action for the designer • create several new attributes, one for each of the original multivalued attribute’s components (Figure 4.4). • Create a new entity composed of the original multivalued attribute’s components (Figure 4.5). Multivalued Attributes Multivalued Attributes Resolving Multivalued Attribute Problems The Entity Relationship (E-R) Model • A derived attribute is not physically stored within the database; instead, it is derived (calculated) by using an algorithm. • Example: AGE can be derived from the data of birth and the current date. • Could be stored in DB if you understand the trade-off and decide it is worth it Derived Attributes The Entity Relationship (E-R) Model • Cardinality • Cardinality expresses the specific number of entity occurrences associated with one occurrence of the related entity. Crow’s Foot Symbols Existence Dependence • Existence dependence • Exist in database only when it is associated with another related entity occurrence • Means FK cannot be null • Existence independence • Entity can exist apart from one or more related entities • Sometimes refers to such an entity as strong or regular entity Relationship Strength • Weak (non-identifying) relationships • Exists if PK of related entity does not contain PK component of parent entity (related PK is only the FK) • Strong (Identifying) Relationships • Exists when PK of related entity contains PK component of parent entity Weak (Non-Identifying) Relationships Weak (Non-Identifying) Relationships Strong (Identifying) Relationships Weak Entities • Weak Entities • A weak entity is an entity that • Is existence-dependent and • Has a primary key that is partially or totally derived from the parent entity in the relationship. • Hence the weak entity is the dependent entity involved in a strong (identifying) relationship • The existence of a weak entity is indicated by a double rectangle. (in Chen notation) • The weak entity inherits all or part of its primary key from its strong counterpart. Weak Entities Relationship Participation • Optional participation • One entity occurrence does not require corresponding entity occurrence in particular relationship • Mandatory participation • One entity occurrence requires corresponding entity occurrence in particular relationship Relationship Participation Relationship Participation Relationship Participation Relationship Degree • Indicates number of entities or participants associated with a relationship • Unary relationship • Association is maintained within single entity • Binary relationship • Two entities are associated • Ternary relationship • Three entities are associated Three Degrees of Relationships Three Degrees of Relationships Three Degrees of Relationships Three Degrees of Relationships Composite Entities Composite Entities Relationship Degree Recursive Relationships • Relationship can exist between occurrences of the same entity set • Naturally found within unary relationship Recursive Relationships Recursive Relationships Recursive Relationships Recursive Relationships Recursive Relationships Composite Entities • Also known as bridge entities • Composed of primary keys of each of the entities to be connected • May also contain additional attributes that play no role in connective process Developing an ER Diagram • Database design is an iterative rather than a linear or sequential process • begins with a general narrative (problem description) • Iterative process • E-R model is created and presented for review. • process repeated until the end users and designers agree Developing an ER Diagram • Building an ERD usually involves the following activities: • Create detailed narrative of organization’s description of operations • Identify business rules based on description of operations • Identify main entities and relationships from business rules • Develop initial ERD • Identify attributes and primary keys that adequately describe entities • Revise and review ERD Database Design Challenges: Conflicting Goals • Database design must conform to design standards – avoidance of redundancy / protection against inconsistency. • High processing speeds are often a top priority in database design – may lead to fewer tables than would be ideal design. • Quest for timely information might be focus of database design.