Summary of the Notations Used in ER Diagram , Naming Conventions and Design Issues

 

ER Diagrams, Naming Conventions, and Design Issues 

 ER Diagram Notation (Overview)

ER diagrams focus on schemas (structure) rather than instances (data) because schemas are stable and easier to represent.

Core ER Notation- Refer Fig 3.14

ConceptRepresentation
Strong entity    Rectangle
Weak entity    Double rectangle
Relationship    Diamond
Identifying relationship    Double diamond
Attribute    Oval
Composite attribute    Oval with component ovals
Multivalued attribute    Double oval
Derived attribute    Dotted oval
Key attribute    Underlined
Partial key (weak entity)    Dashed underline

Structural Constraints

  • Cardinality ratio: 1:1, 1:N, M:N (shown as 1, M, N on edges)

  • Participation:

    • Total participation → Double line

    • Partial participation → Single line

Roles

  • Role names are shown when the same entity type participates more than once in a relationship (e.g., SUPERVISION).

📌 ER notation is not unique—many alternative notations exist.

Proper Naming of Schema Constructs

Good naming improves clarity and correctness.

Naming Conventions

  • Entity types & relationship types → UPPERCASE

  • Attributes → Capitalized

  • Role names → lowercase

  • Entity names → Singular (e.g., EMPLOYEE, not EMPLOYEES)

Guidelines from Requirements Narrative

  • Nouns → Entity types

  • Verbs → Relationship types

  • Descriptive nouns → Attributes

Relationship Naming

  • Binary relationships should read naturally top-to-bottom or left-to-right

  • Example:

    • DEPENDENTS_OF (bottom-to-top)

    • Can be renamed as HAS_DEPENDENTS for readability

📌 Any binary relationship can be described from either direction, so names must be chosen carefully.

Design Choices in ER Conceptual Design

Deciding whether a concept is an entity, attribute, or relationship is often non-trivial.

General Principle

ER design is an iterative refinement process.

Common Refinements

1. Attribute → Relationship

  • When an attribute refers to another entity type

  • Example: Department attribute → WORKS_FOR relationship

  • Remove the attribute after refinement to avoid redundancy

2. Attribute → Entity Type

  • When the same attribute appears in multiple entity types

  • Example: Department in STUDENT, INSTRUCTOR, COURSE

  • Create a separate DEPARTMENT entity

3. Entity Type → Attribute

  • If an entity:

    • Has only one attribute

    • Participates in only one relationship

  • Example: DEPARTMENT → attribute of STUDENT

4. Relationship Degree Refinements

  • Decisions on binary vs ternary relationships (discussed later)

  • Further refinements include specialization/generalization (discussed later)

Key Takeaways

✔ ER diagrams represent schemas, not data instances
✔ Clear notation captures structure and constraints
✔ Proper naming improves readability and semantics
✔ ER design is iterative and flexible
✔ Attributes, entities, and relationships can be refined as understanding improves

A frequent conceptual question:

When should an attribute be modeled as an entity type?

Answer:

When it has its own properties, participates in multiple relationships, or is shared across several entity types.


Comments

Post a Comment

Popular posts from this blog

Database Management Systems DBMS PCCST402 Semester 4 KTU CS 2024 Scheme

 About Me Database Management Systems DBMS PCCST402 Scheme and Syllabus Module-1 Introduction to DBMS Introduction to DBMS Example  Database Database System Vs Traditional File Processing Database System Concepts and Architecture Data Models, Schemas and Instances   Three schema architecture and Data Independence Database Languages and Interfaces Centralized and Client Server Architectures in DBMS Classification of Database Management Systems Conceptual Data Modeling and Database Design Conceptual Modeling and the Role of the ER Model in Database Design Entities and Attributes  Company Database Application - Example Entity Types, Entity Sets, Keys, and Value Sets in the ER Model Initial Conceptual Design of the COMPANY Database Relationship Types in the ER Model Relationship Degree, Role Names, and Recursive Relationships Constraints on Binary Relationship Types Attributes of Relationship Types Weak Entity Types Summary of the Notations Used in ER Diagram , Naming Co...
Read more

Database Management Systems DBMS PCCST402 Scheme and Syllabus

  DATABASE MANAGEMENT  SYSTEMS (Common to  CS/CD/CA/CR/AD/AI/CB/CN/CC/CU/CI/CG)   Course  Code PCCST402 CIE Marks 40 Teaching  Hours/Week (L:T:P: R) 3:1:0:0 ESE Marks 60 Credits 4 Exam Hours 2Hrs.30 Min. Prerequisites(if  any) PCCST303 Course Type Theory Course Objectives:   1.        Equip the students with a comprehensive understanding of fundamental DBMS concepts as well as the principles and applications of NoSQL databases 2.        Enable students to design,implement,and manage both relational and NoSQL databases SYLLABUS   Module No. Syllabus  Description Contact Hours         1 Introduction to Databases...
Read more

Introduction to Database Management System -DBMS

Image
In today’s digital world, almost every application—from mobile banking and e-commerce to university portals and hospital systems—depends on the efficient storage, organization, and retrieval of data. As the amount of information generated by individuals and organizations continues to grow, managing this data in a structured and meaningful way becomes essential. This is where database systems play a central role. A database can be thought of as a well-organized collection of related data, designed so that it can be easily accessed, managed, and updated. But the database itself is only one component. To manage it effectively, we rely on a specialized software package known as a Database Management System (DBMS) . A DBMS provides a systematic and automated way to store large volumes of data, enforce rules for consistency and correctness, protect data from unauthorized access, and allow multiple users to work with the data simultaneously without conflicts. A database typically has three...
Read more