Purpose of ER Diagrams in Data Modeling

An Entity-Relationship Diagram (ERD) is a core tool in data modeling. It provides a visual representation of entities, attributes, and relationships, and it plays a central role in designing and understanding relational databases. ERDs are used not only in initial design, but also as documentation, communication aids, and integration tools.

1. Data Structure Visualization: ERDs illustrate how entities connect, along with their attributes and constraints. By presenting the database structure graphically, they make complex systems easier to interpret.
2. Database Design: ERDs serve as blueprints. They capture business rules, constraints, and relationships that are translated into relational schemas and implemented in SQL-based databases.
3. Documentation: As living documents, ERDs provide reference material for DBAs, developers, and business stakeholders throughout the database life cycle. They help new team members quickly grasp the data model.
4. Improving Communication: ERDs bridge the gap between technical and non-technical audiences. By presenting data visually, they allow system analysts, designers, and end-users to share a common understanding of the system.
5. System Analysis and Enhancement: ERDs can reveal redundancies, inefficiencies, or missing relationships in existing databases, making them useful for continuous improvement.
6. Data Integration: When merging data from multiple systems, ERDs offer a holistic view of structures and help define mappings across sources.

An ER diagram is a conceptual model that captures business rules in a concise, structured format. Its objectives include:

1. Providing a unified view of entities, attributes, and relationships within a system.
2. Acting as a communication tool for validating business rules during design.
3. Serving as a blueprint for generating a relational database, typically using SQL^[1].
4. Maintaining documentation throughout the database life cycle, supporting future structural changes.

Most modern CASE tools support ERDs in similar ways. Regardless of the style or notation, the core function remains the same: visualize and enforce consistency in data modeling.

Each simple attribute in an entity type is associated with a value set (or domain), which specifies the permissible values. For example, in Figure 7-2, the Age attribute of EMPLOYEE might be restricted to integers between 16 and 70, while Name values may be alphabetic strings separated by spaces.

Value sets are usually expressed using standard programming language types (integer, string, Boolean, float, enumerated types, subranges) or database-specific types such as date and time. While not shown on ER diagrams, they are vital in defining the validity of data.

Mathematically, an attribute A of entity set E with value set V can be represented as a function from E to the power set ^[2] of V:

A : E → P(V)

For an entity e, the value of A(e) can represent single-valued or multivalued attributes, including NULLs (the empty set). For composite attributes ^[3], the value set is defined as a power set of the Cartesian product of its component attributes:

V = P(P(V1) × P(V2) × ... × P(Vn))

Although these sets describe the full potential range of attribute values, the actual database will only hold values that correspond to the current state of the modeled domain (the "miniworld").

The next lesson introduces three well-known examples of ER diagram applications.

[1]SQL: Structured Query Language, supported by all major relational database vendors.

[2]Power set: The power set P(V) of a set V contains all subsets of V.

[3]Composite attribute: An attribute made up of multiple sub-attributes.