DATA

MODELLING
 Learning Outcomes

● Apply rules and style guidelines for creating ERDs.

● Construct ERDs for a given system.
● Develop data dictionaries and data stores.
● Define relationships and perform normalization.
● Compile a requirements catalogue.
 Introduction
• A data model is a formal way of representing the data that are used and
created by a business system
• It illustrates people, places, or things about which information is
captured and how they are related to each other.
• During analysis, analysts draw a logical data model, which shows the
logical organization of data without indicating how data are stored,
created, or manipulated.
• In the design phase, analysts draw a physical data model to reflect how
the data will physically be stored in databases and files.
• Although there are several ways to model data, we will present one of
the most commonly used techniques: Entity relationship diagramming
 Entity relationship Diagram
• An Entity Relationship Diagram (ERD) is a graphical representation that
shows how entities (such as people, objects, or concepts) relate to one
another within a system.
• It uses standardized symbols to depict entities, their attributes, and the
relationships between them, and is commonly used in designing and
analyzing relational databases.
• Similar kinds of information are listed together and placed inside boxes
called entities. Lines are drawn between entities to represent relationships
among the data, and special symbols are added to the diagram to
communicate high-level business rules that need to be supported by the
system.
 Elements of an ERD

1. Entity
2. Attribute
3. Relationship
 Entity
• An entity is the fundamental building block of a data model, representing
a person, place, event, or thing about which data is collected.
• It is depicted as a rectangle, named with a singular noun in capital letters,
and described with a short explanation and an identifier.
• An entity represents something that has multiple instances (occurrences),
such as many customers, employees, or products;
• If there is only one instance, it should not be modeled as an entity.
• Example:
• Entity: CUSTOMER
• Instances: John Smith, Susan Jones
 Attribute
• An attribute is a piece of information that describes an entity, such as a
customer’s last name, address, or email.
• Attributes are written as nouns within an entity, often with a prefix of the
entity name to avoid confusion (e.g., CUS_lastname, EMP_lastname)
• One or more attributes can serve as an identifier, uniquely distinguishing
each instance of the entity.
• Identifiers can be a single attribute, a concatenation of multiple
attributes, or a unique system-generated value.
• Example:
• Entity: CUSTOMER
• Attributes: CUS_lastname, CUS_address, CUS_email
 Relationship

• A relationship is an association between two entities in a data model,

represented by a line connecting them.
• Each relationship has a parent entity and a child entity, and it is labeled
with an active verb to show how the entities are related.
• The verb can be read in both directions (e.g., “an LCA makes a chemical
request” and “a chemical request is made by an LCA”).
• Relationships should be uniquely named to clearly describe the
connection between entities.
 Two Types of relationship
1. Cardinality
• Cardinality is the property of a relationship that defines the number of
instances of one entity that can be associated with an instance of another
entity.

Types of Cardinality
1:1 (One-to-One)
• One instance of the parent entity relates to exactly one instance of the
child entity.
• Example: Each Employee of the Month gets exactly one Reserved
Parking Place, and vice versa.
 Two Types of relationship
1:N (One-to-Many)
• One instance of the parent entity can be associated with many child
entity instances, but each child relates to only one parent.
• Example: One Lawn Chemical Applicator (LCA) can make many
Chemical Requests, but each Chemical Request is made by only one
LCA

M:N (Many-to-Many)
• Many parent instances can relate to many child instances.
• Example: One LCA can request many Chemicals, and one Chemical can
be requested by *many LCAs.
• (Usually resolved into two 1:N relationships with a bridging entity like
Chemical Request.)
 Two Types of relationship
2. Modality (Optionality)
Modality specifies whether the participation of an entity in a relationship is
mandatory (not null) or optional (null).

Not Null (Mandatory):

• An instance of the child entity must be related to a parent entity.
• Example: You cannot have a Chemical Request without a Chemical.

Null (Optional)
• An instance of the child entity may exist without being related to a parent
entity.
• Example: A Chemical can exist even if no Chemical Request has been
made for it.
Creating
ERDs
 Iterative Refinement
• Creating an ERD is not a one-time activity; it is refined as more
details are discovered.
• For example, you might initially list Teacher Address as an attribute
of the Teacher entity, but later realize that teachers may have more
than one address (e.g., permanent and current).
• In this case, Address could become a separate entity linked to
Teacher. Likewise, you may later decide to add an entity for Exams to
capture assessments in the system.
• This iterative process ensures that the ERD evolves to reflect the
actual requirements of the school management system.
Step 1: Identify Entities

• The first step in creating an ERD is to identify the main entities,

which represent the key data objects in the system.
• Entities can be people, places, objects, or concepts that the
system needs to keep information about.
• In a school management system, for example, the main entities
might include Student, Teacher, Course, and Classroom.
• These entities are important because the system needs to store
and process data about them to support day-to-day operations
such as enrolling students or assigning teachers to courses.
Step 2: Add Attributes and Assign Identifiers

• After identifying the entities, the next step is to list their attributes, which
describe the properties of each entity.
• For example, the Student entity could have attributes such as Student ID, Name,
Date of Birth, and Address.
• The Course entity might include Course ID, Course Name, and Credits. Among
the attributes, one (or a set of them) must serve as an identifier—a unique way
to distinguish each record.
• For instance, Student ID uniquely identifies each student, and Course ID uniquely
identifies each course. This prevents confusion when two students have the
same name or when two courses have similar titles.
Step 3: Identify Relationships

• The next step is to establish how the entities are related.

• Relationships connect entities and are described using verbs.
• For instance, a Student enrolls in a Course, and a Teacher teaches a
Course.
• These relationships also have cardinality (how many instances can be
linked) and modality (whether the relationship is optional or required).
• For example, a student can enroll in many courses (one-to-many
relationship), and a course can have many students. Similarly, a teacher
may teach multiple courses, but each course must be taught by at least
one teacher.
• These relationships help define the structure of the data and ensure the
system can support real-life school processes.
Data Dictionaries and Metadata
A data dictionary is a centralized repository in a CASE tool that stores detailed
information (definitions, descriptions, and properties) about the elements in a
data model such as entities, attributes, and relationships.

Purpose
• Helps analysts and designers define and look up information about data
model components.
• Ensures consistency across ERDs, process models, and user interfaces.
When something is updated in the dictionary, the change ripples through all
related project parts.
Metadata

• Metadata is data about data, it describes entities, attributes, and relationships

(e.g., entity name, attribute description, relationship cardinality).
• Captured in the data dictionary.
• Helps developers and users better understand the system.
• Becomes more detailed as the project progresses through the SDLC.

Example of Metadata in a Data Dictionary

• Entity Name: CUSTOMER

• Attribute Name: CUS_lastname
• Attribute Type: Text
• Length: 30 characters
• Relationship: CUSTOMER places ORDER (1:N)
 Design Guidelines
1. Use Clear Labels and Naming Conventions

• Names should be specific, clear, and consistent so that anyone reading the ERD
understands what each component represents.
• Avoid generic terms like Name or Number because they can apply to many things.
• Instead, use precise labels such as Customer_Name or Order_Number.

2. Organize Entities Logically on the Diagram

• Although there are no strict rules for ERD layout, placing related entities close together
makes the diagram easier to read.
• For larger systems with hundreds of entities, you can break the ERD into subject areas,
grouping related entities together.
 Design Guidelines
3. Handle Complexity by Iteration

• ERDs can become complex, so it’s best to build them step by step.
• Start with a few key entities and relationships, then gradually add attributes and refine
details.
• Remember that ERDs often change as business requirements evolve.

4. Verify and Test Business Rules

• Every ERD is based on assumptions about business rules.

• If these assumptions are wrong, the data model will be inaccurate.
• That’s why you must validate your assumptions with business users and adjust
the model if rules change.
 Design Guidelines
5. Work Iteratively and Don’t Panic

• Data modeling is a trial-and-error process.

• Don’t expect the first version of your ERD to be perfect.
• Add entities, attributes, and relationships slowly, refine them, and confirm with business
users.
• Over time, the ERD becomes a strong reflection of the real-world system.