BIG PICTURE C

Week 6-7: Unit Learning Outcomes (ULO): At the end of the unit, you are expected to
a) Understand Concept of Modeling In Data Organization through the used of
basic and enhanced ERD.
b) Understand the Concept Database Normalization

Big Picture in Focus: ULOa Understand Concept of

Modeling In Data Organization through the used of basic
and enhanced ERD

Metalanguage
 Row(s) – List of record(s) or values result from Query
 Schema – Another name of a database.
 Table – An entity in the database where data/records are stored.
 Query – SQL statement that manipulates data in the database.
 ERD - Entity Relationship Diagram.
 ENTITY - It may represent a group of objects, class, person, or place with similar
properties.
 ATTRIBUTES – A property of an Entity or Relationship.
 CONTRAINTS - It is a rules applied on data column/field in a database.
Essential Knowledge
What is an ER Model?

ER model stands for an Entity-Relationship model. It is a high-level data model. This

model is used to define the data elements and relationship of a particular system. It
gives an overview of a conceptual database design for a very simple and easy viewing
of data. In ER modeling, the database structure is portrayed as a diagram called an
entity-relationship diagram.

There are three components of ER diagram which mainly consist of an entity, attribute,
and relation. These will be discussed in detail below.
Figure 1.0 Entity Relationship Model
Entity: An entity may represent a group of objects, class, person, or place with similar
properties. In the ER diagram, an entity can be represented as rectangles. Consider an
organization as an example - teacher, subject, student, department, etc. can be taken
as an entity. See the diagram below.

Figure 1.1 Entities Relationship

Entity types can be classified as strong or weak.

● Strong Entity: An entity type can be considered as strong if its existence does not
depend on another entity type. It is also called a regular entity.

● Weak Entity: On the contrary, there are also weak entities. An entity that is
dependent on another entity is called a weak entity. This entity type does not contain
any key attribute of its own. Below is the diagrammatic representation of a strong
and weak entity.

Figure 1.2 Strong Entity and Weak Entity

Attributes

It is used to represent the property of an entity or a relationship type. For example,

staffNo, name, position, and salary can be attributes of Staff (See the given diagram
below). The attributes contain values that characterize each entity's existence and
represent the main part of the data stored in the database.
Figure 1.3 Entity Attributes

● Key Attribute: The key attribute is used to represent the main characteristics of an
entity. It denotes a primary key. In the diagram above, you will see the key attribute
(staffNo) represented by a circle with the text underlined.
● Composite Attributes: Refers to an attribute that composed of many other
attributes. The composite attribute is drawn by a circle, and those circles are
connected with a circle.

● Multivalued Attribute: A type of attribute that can have more than one value is
associated as a multivalued attribute. For example, a student can have more than
one mobile number from different network subscribers.

● Derived Attribute: This type of attribute can be originated from other attributes. In
the diagram representation, it is represented by a dashed circle. For example, A
person's age changes over time and can be derived from another attribute like Date
of birth.

Figure 1.4 Attributes on Relationship

As mentioned in the definition of an ER model, attributes can also be assigned in entity

relationships. A relationship is used to describe the relation between entities. In the
given examples below, we used a diamond symbol between two entities to represent
the relationship.

TYPES OF ENTITY RELATIONSHIPS:

 One-to-One (1:1) Relationship

 Figure 1.5 One-to-One (1:1) Relationship

When an entity has only one occurrence associated with the relationship, then it is
associated as one to one relationship. Like in the diagram example, A patient
receives a medical prescription, or on the contrary, a medical prescription is given
to a patient.

 One-to-Many (1:*) Relationship

Figure 1.6 One-

to-Many (1:*) Relationship

If there is only one occurrence of an entity on the left, and on the right entity
composed of more than one occurrence associated with the relationship then this
is known as a one-to-many relationship.

For example, A teacher can teach more than one course, or on the contrary, more
than one course can be handled by a single teacher.

 Many-to-Many (*:*) Relationship

Figure 1.7 Many-to-Many (*:*) Relationship

If there is only one occurrence of an entity on the left, and on the right entity
composed of more than one occurrence associated with the relationship then this
is known as a one-to-many relationship.

When there is more than one occurrence of both entities associated with the
relationship, then it is known as a many-to-many relationship.

For example, A scientist can develop more than one COVID vaccine or on the
contrary, a COVID vaccine can be developed by a scientist

CARDINALITY AND PARTICIPATION CONSTRAINTS

Multiplicity consists of two separate constraints known as cardinality and participation.
Cardinality: Describes the maximum number of possible relationship occurrences for
an entity engaging in a given relationship type.

Participation: It identifies whether all or only some entity occurrences participate in a

relationship.

Crow’s Foot Symbols

Figure 1.8 Crow’s Foot Symbols

Since relationship participation is an essential part of database design, it is of great help

when you analyze a particular scenario in which the level of relationship is known.
Indicated below are some diagrammatic examples of entity-relationship participation.

Figure 1.9 Teacher’s and Class Relationship

Looking at the example “Teacher teaches Class” relationship, the reality is, it is also
possible for a Teacher not to teach a Class. Therefore, Class entity type is optional to
Teacher entity. On the other hand, a Class must be taught by a Teacher. Therefore,
Teacher entity type is mandatory to Class entity. Note that the ERD model in the given
diagram shows the cardinality of Student to be (0,5). This indicates that a Teacher may
teach but no Class or the Teacher can teach as many as five Classes. Also, in Teacher
entity type, assuming each class is taught by one and only one Teacher which is
represented by (1,1) cardinality.

Figure 2.0 Teacher’s and Classes Relationship

Suppose that each Course generates one or more Classes.

Self-Help: You can also refer to the sources below to help you further understand
the lesson:
 Big Picture in Focus: ULOb Understand the Concept
Database Normalization

Metalanguage

 Normalization - Normalization is a technique used to assess the quality of a

relational database schema by minimizing data redundancy
 Denormalization - is the process of trying to improve the read performance of a
database, at the expense of losing some write performance, by adding redundant
copies of data or by grouping data

Essential Knowledge

DATABASE Normalization
Normalization is a technique used to assess the quality of a relational database schema
by minimizing data redundancy. It defines specific methods to eliminate these
redundancies. Normalization is based on the analysis of functional dependence and on
a series of normal forms. Let’s discuss these further.

 First Normal Form. A relation is in first normal form it is contains no repeating

fields or group of fields. Repeating columns make your data less flexible, waste
disk space, and make it more difficult to search for data. Consider the example
below.

The CUSTOMER table in Table 1.0 contains the following attributes: Cust_ID,
First_Name, Surname, and Tel_Num.

Table 1.0 Customer table example

Notice that the Tel_Num attribute with Cust_ID 101 and 102 both holds two
values. This means that a customer can have multiple telephone numbers. To
 make this in 1NF, we would add additional records to eliminate repeating
attributes. The resulting table is shown in Table 1.1.

Table 1.1 1NF example

Functional Dependency. This occurs when one attribute in a relation uniquely

determines another attribute. This can be written as A → B which would be the
same as stating "B is functionally dependent upon A." For example, in table
listing employee characteristics including Social Security Number (SSN) and
name, it can be said that name is functionally dependent upon SSN (or SSN →
name) because an employee's name can be uniquely determined from their
SSN.

 Second Normal Form. A relation is in second normal form if it is in first normal

form and if each non-key element is functionally dependent on the entire primary
key. Thus, the next step is to remove all the partially dependent attributes and
place them in another relation. Shown in Table 6.4 and Table 6.5 is an example of
2NF.

Table 1.2 Customer Table

Table 1.3 Customer Telephone Table

2NF is satisfied if any one of the following conditions apply:
 1. The primary key consists of only one attribute (such as the attribute
Cust_ID in relation CUSTOMER).
2. No non-primary key attributes exist in the relation.
3. Every non-primary key attribute is functionally dependent on the full set of
primary key attributes.

 Third Normal Form. A normalized relation is in the third normal form if it is in

second normal form and if no non-key element is functionally dependent on any
other non-key element.

The tables below are not in 3NF.

Table 1.4 Student Table

Table 1.5 Course Table

To convert these tables into 3NF, the resulting table would be:

Table 1.6 Student Table

Table 1.7 Enrollment table

Table 1.8 Course table

Table 1.9 Instructor table