Software Engineering

Dr. Saba Bashir

1
 Today’s Lecture
• Data Modeling • ERD Notations
• Data Object • Entity, Entity Attributes,
• Data Attributes Primary Key, Foreign Key,
Cardinality
• Relationships
• ER Models
• Cardinality and Modality
• Conceptual
• Entity Relationship Diagram (ERD)
• Logical
• What is an ERD?
• Physical
• When to draw ERD?
• How to draw an ER diagram
• Entity Relationship Diagram
• ERD Examples
• What is an ERD?
• When to draw ERD? 2
Data Modeling

3
Data Modeling
• Analysis model often begin with data modeling.
• Data model consists of three interrelated pieces of
information:
• The data object,
• The attributes that describe the data object, and
• The relationships that connect data objects to one
another.

4
Data Object
• A data object is a representation of almost any composite information that
must be understood by software.
• composite information - number of different properties or attributes.
• A data object can be:-
• An external entity (e.g., anything that produces or consumes information),
• A thing (e.g., a report or a display),
• An occurrence (e.g., a telephone call)
• Event (e.g., an alarm),
• A role (e.g., salesperson),
• An organizational unit (e.g., accounting department),
• A place (e.g., a warehouse),
• A structure (e.g., a file).

5
For Ex.- Set of attributes can be defined for a
person or a car (i.e. Data Object)

6
Data Attributes
• Define the properties of a data object.
• Attributes name a data object, describe its
characteristics, and in some cases, make
reference to another object.
• In addition, one or more of the attributes must
be defined as an identifier( Key value or
Unique value).
Ex. Data object Car has Id number as identifier.

7
Relationships
• Data objects are connected to one another in different
ways.
• Consider two data objects
• Book
• Bookstore
• A connection is established between book and bookstore
because the two objects are related.

8
Relationship
• To determine relationship between them, must
understand the role of book and bookstore.
• Can define a set of object/relationship pairs that
define the relevant relationships.

For Example:
• A bookstore orders books.
• A bookstore displays books.
• A bookstore stocks books.
• A bookstore sells books. 9
• A bookstore returns books.
Cardinality and Modality
• Additional element of data modeling.
• Object X relates to object Y does not provide
enough information.
• How many occurrences of object X are related to
how many occurrences of object Y called
cardinality.

10
Cardinality
• Representing the number of occurrences objects in a given
relationship.
• Cardinality is the specification of the number of occurrences of
one [object] that can be related to the number of occurrences of
another.
• Cardinality is usually expressed as simply 'one' or 'many’.
• 1:1 – One object can relate to only one other object.
• 1:M – one object can relate to many objects.
• M:N – Some no. of occurrences of an object can relate to some
other no. of occurrences of another object.

11
Example
Example
Example
Example
Modality
• Cardinality does not provide an indication of whether or
not a particular data object must participate in the
relationship.
• Modality of a relationship is 0 if there is no explicit need
for the relationship to occur or the relationship is
optional.
• The modality is 1 if an occurrences of the relationship is
mandatory.

20
Entity Relationship Diagram
ERD

21
What is an ERD?
• Database is absolutely an integral part of software systems.
• To fully utilize ER Diagram in database engineering
guarantees you to produce high-quality database design to use
in database creation, management, and maintenance.
• An ER model also provides a means for communication.
• An ERD contains different symbols and connectors that
visualize two important information:
• The major entities within the system scope, and
• The inter-relationships among these entities.
• That's why it's called "Entity" "Relationship" diagram (ERD)
22
What is an ERD?
• When we talk about entities in ERD, very often we are
referring to
• business objects such as people/roles (e.g. Student),
• tangible business objects (e.g. Product),
• intangible business objects (e.g. Log), etc.
• "Relationship" is about how these entities relate to each other
within the system.

23
When to draw ER Diagram?
• Depending on the scale of change, it can be risky to alter a
database structure directly in a DBMS.
• To avoid ruining the data in a production database, it is
important to plan out the changes carefully.
• ERD is a tool that helps. By drawing ER diagrams to visualize
database design ideas, you have a chance to identify the
mistakes and design flaws, and to make corrections before
executing the changes in the database.

24
ERD Notations
• Entity
• Entity Attributes
• Primary Key
• Foreign Key
• Cardinality

25
ERD Notations – Entity
• An ERD entity is a definable thing or concept within a
system, such as
• a person/role (e.g. Student),
• object (e.g. Invoice),
• concept (e.g. Profile) or
• event (e.g. Transaction)
• When determining entities, think of them as nouns.
• In ER models, an entity is shown as a rounded rectangle,
with its name on top and its attributes listed in the body of
the entity shape.
• The ERD example above shows an example of an ER entity.
26
ERD Notations – Entity Attributes
• An attribute is a property or characteristic of the entity that
holds it.
• An attribute has
• a name that describes the property and
• a type that describes the kind of attribute it is,
such as varchar for a string, and int for integer.

• When an ERD is drawn for physical database development, it is

important to ensure the use of types that are supported by the
target RDBMS.
• The ER diagram above shows an entity with some attributes in it.
27
 ERD Notations – Primary Key
• A primary key is a special kind of entity attribute that uniquely defines a
record in a database table.
• In other words, there must not be two (or more) records that share the same
value for the primary key attribute.
• The ERD example below shows an entity 'Product' with a primary key attribute
'ID', and a preview of table records in the database.
• The third record is invalid because the value of ID 'PDT-0002' is already used
by another record.

28
ERD Notations – Foreign Key
• A foreign key is a reference to a primary key in a table.
• It is used to identify the relationships between entities.
• Note that foreign keys need not be unique.
• Multiple records can share the same values.
• The ER Diagram example below shows an entity with some
columns, among which a foreign key is used in referencing
another entity.

29
ERD Notations – Foreign Key

30
ERD Notations – Relationship
• A relationship between two entities signifies that the two
entities are associated with each other somehow.
• For example, a student might enroll in a course. The entity
Student is therefore related to Course, and a relationship is
presented as a connector connecting between them.

31
ERD Notations – Cardinality
• Cardinality defines the possible number of occurrences in
one entity which is associated with the number of
occurrences in another.
• For example, ONE team has MANY players. When present in
an ERD, the entity Team and Player are inter-connected with a
one-to-many relationship.
• In an ER diagram, cardinality is represented as a crow's foot
at the connector's ends.
• The three common cardinal relationships are one-to-one, one-
to-many, and many-to-many.

32
ERD Notations – One-to-One Cardinality
• A one-to-one relationship is mostly used to split an entity in two
to provide information concisely and make it more
understandable.
• The figure below shows an example of a one-to-one relationship.

33
ERD Notations – One-to-Many Cardinality
• A one-to-many relationship refers to the relationship between
two entities X and Y in which an instance of X may be linked to
many instances of Y, but an instance of Y is linked to only one
instance of X.
• The figure below shows an example of a one-to-many
relationship.

34
 ERD Notations – Many to Many
• A many-to-many relationship refers to the relationship between two
entities X and Y in which X may be linked to many instances of Y and
vice versa.
• The figure below shows an example of a many-to-many relationship.
• Note that a many-to-many relationship is split into a pair of one-to-
many relationships in a physical ERD.

35
 ER Models
• An ER model is typically drawn at up to three levels of
abstraction:
• Conceptual ERD / Conceptual data model
• Logical ERD / Logical data model
• Physical ERD / Physical data model

36
 Conceptual Data Model
• Conceptual ERD models the business objects that should
exist in a system and the relationships between them.
• A conceptual model is developed to present an overall picture
of the system by recognizing the business objects involved.
• It defines what entities exist, NOT which tables.
• For example, 'many to many' tables may exist in a logical or
physical data model but they are just shown as a relationship
with no cardinality under the conceptual data model.

37
 Logical Data Model
• Logical ERD is a detailed version of a Conceptual ERD.
• A logical ER model is developed to enrich a conceptual model
by defining explicitly the columns in each entity and
introducing operational and transactional entities.
• Although a logical data model is still independent of the
actual database system in which the database will be created,
you can still take that into consideration if it affects the
design.

38
Logical Data Model – Example

39
 Physical Data Model
• Physical ERD represents the actual design blueprint of a
relational database.
• A physical data model elaborates on the logical data model by
assigning each column with type, length, nullable, etc.
• Since a physical ERD represents how data should be
structured and related in a specific DBMS it is important to
consider the convention and restriction of the actual database
system in which the database will be created.
• Make sure the column types are supported by the DBMS and
reserved words are not used in naming entities and columns.

40
Physical Data Model – Example

41
Conceptual/Logical/Physical ER Models

42
How to draw an ER diagram?
1. Make sure you are clear about the purpose of drawing the
ERD. Are you trying to present an overall system
architecture that involves the definition of business objects?
Or are you developing an ER model ready for database
creation? You must be clear about the purpose to develop an
ER diagram at the right level of detail
2. Make sure you are clear about the scope to model. Knowing
the modeling scope prevents you from including redundant
entities and relationships in your design.
3. Draw the major entities involved in the scope.
4. Define the properties of entities by adding columns.
43
 How to draw an ER diagram?
5. Review the ERD carefully and check if the entities and columns are
enough to store the data of the system. If not, consider adding
additional entities and columns. Usually, you can identify some
transactional, operational and event entities in this step.
6. Consider the relationships between all entities and relate them with
proper cardinality (e.g A one-to-many between entity Customer and
Order). Don't worry if there are orphan entities. Although it's not
common, it's legit.
7. Apply the technique of database normalization to re-structure the
entities in a way that can reduce data redundancy and improve data
integrity. For example, the details of the manufacturer might be
stored under the Product entity initially. During the process of
normalization, you may find that the detail keeps repeating records
44
over records, then you can split it as a separate entity Manufacturer,
and with a foreign key that links between Product and Manufacturer.
ERD Example – Loan System

45
ERD Example – Online Shop

46
ERD Example – Movie Rental

47
End of Lecture

48