Database Systems

Disclaimer
Eduvos and the Flipped Classroom

1 2 3
Pre-Session Assessment
What will be covered in this week’s sessions?

•
•
•
•
•
•
•
 Data Modelling
Data modeling is the first step in the database design journey, serving as a
bridge between real-world objects and the computer database.

Data modeling, the first step in designing a database, refers to the process of
creating a specific data model for a determined problem domain.

A data model is a relatively simple representation, usually graphical, of more

complex real-world data structures.
Note: Within the database environment, a data model represents data
structures and their characteristics, relations, constraints, transformations, and
other constructs with the purpose of supporting a specific problem domain.
 Data Model Basic Building Blocks
The basic building blocks of all data models are entities, attributes,
relationships, and constraints.

1.Entity - A person, place, thing, concept, or event for which data can be stored.
An entity represents a particular type of object in the real world, which means an
entity is “distinguishable” with each entity occurrence being unique and
distinct.
For example, a CUSTOMER entity would have many distinguishable customer
occurrences, such as Kusakana Mashilo or Ngobeni Tshabalala
 Data Model Basic Building Blocks
2. Attribute - A characteristic of an entity or object. An attribute has a name and a data
type.
For example, a CUSTOMER entity would be described by attributes such as customer last name,
customer first name, customer phone number, customer address, and customer credit limit.

3. Relationship - An association between entities.

• one-to-many (1:M or 1..*) relationship

Associations among two or more entities that are used by data models. In a 1:M relationship,
one entity instance is associated with many instances of the related entity.

Example: A painter creates many different paintings, but each is painted by only one painter.
Thus, the painter (the “one”) is related to the paintings (the “many”).
 Data Model Basic Building Blocks
• one-to-many (1:M or 1..*) relationship

Associations among two or more entities that are used by data models. In a 1:M relationship, one
entity instance is associated with many instances of the related entity.

Example: A painter creates many different paintings, but each is painted by only one painter. Thus, the
painter (the “one”) is related to the paintings (the “many”).

• one-to-one (1:1or 1..1) relationship

Associations among two or more entities that are used by data models. In a 1:1 relationship, one
entity instance is associated with only one instance of the related entity.

Example: A retail company’s management structure may require that each of its stores be managed by
a single employee. In turn, each store manager, who is an employee, manages only a single store.
 Data Model Basic Building Blocks
4. Constraint is a restriction placed on the data. Constraints are
important because they help to ensure data integrity. Constraints are
normally expressed in the form of rules:
For example, “A student’s GPA must be between 0.00 and 4.00.”
Data Model Techniques
Evolution of Data Models
 Importance of Data Models
The primary goal of using data model are:

•Ensures that all data objects required by the database are accurately represented. Omission of data will lead
to creation of faulty reports and produce incorrect results.

•A data model helps design the database at the conceptual, physical and logical levels.
•Data Model structure helps to define the relational tables, primary and foreign keys and stored procedures.
•It provides a clear picture of the base data and can be used by database developers to create a physical
database.

•It is also helpful to identify missing and redundant data.

•It makes maintenance operations cheaper and faster.
 Advantages and Disadvantages of
Data Models
The main goal of a designing data model is to make certain To develop Data model, one should know physical data stored
that data objects offered by the functional team are characteristics.
represented accurately.
The data model should be detailed enough to be used for This is a navigational system produces complex application
building the physical database. development, management. Thus, it requires a knowledge of the
biographical truth.
The information in the data model can be used for defining Even smaller change made in structure require modification in the
the relationship between tables, primary and foreign keys, entire application
and stored procedures.
Data Model helps business to communicate the within and There is no set data manipulation language in DBMS
across organizations.
Data model helps to documents data mappings in ETL
process.
Help to recognize correct sources of data to populate the
model.
 Types of Data Models in DBMS

There are mainly three different types of data models: conceptual data models,
logical data models, and physical data models, and each one has a specific
purpose. The data models are used to represent the data and how it is stored in the
database and to set the relationship between data items.
 Types of Data Models in DBMS
There are mainly three different types of
data models: conceptual data models,
logical data models, and physical data
models, and each one has a specific
purpose. The data models are used to
represent the data and how it is stored in
the database and to set the relationship
between data items.
 Types of Data Models in DBMS
1. Conceptual data model

The conceptual model represents a global

view of the entire database by the entire
organization. That is, the conceptual model
integrates all external views (entities,
relationships, constraints, and processes)
into a single global view of the data in the
enterprise. Also known as a conceptual
schema.
 Types of Data Models in DBMS
2. Logical data model Characteristics of a Logical data model

The Logical Data Model is used to define the

•Describes data needs for a single project but
structure of data elements and to set
could integrate with other logical data models
relationships between them. The logical data based on the scope of the project.
model adds further information to the •Designed and developed independently from
conceptual data model elements. The the DBMS.
advantage of using a Logical data model is to •Data attributes will have datatypes with exact
provide a foundation to form the base for the precisions and length.
Physical model. However, the modeling •Normalization processes to the model is
structure remains generic. applied typically till 3NF.
 Types of Data Models in DBMS
3. Physical data model Characteristics of a physical data model

A Physical Data Model represents the actual design

•The physical data model describes data need for a single
blueprint or implementation of a relational database. It
project or application though it maybe integrated with other
offers database abstraction and helps generate the
physical data models based on project scope.
schema. This is because of the richness of meta-data
•Data Model contains relationships between tables that which
offered by a Physical Data Model. The physical data model
addresses cardinality and nullability of the relationships.
also helps in visualizing database structure by replicating
•Developed for a specific version of a DBMS, location, data
database column keys, constraints, indexes, triggers, and
storage or technology to be used in the project.
other RDBMS features.
•Columns should have exact datatypes, lengths assigned and
default values.
•Primary and Foreign keys, views, indexes, access profiles, and
authorizations, etc. are defined.
Comparison Between Conceptual,
Logical and Physical Data Model
 Business Rules In Data Modelling

Business rule
A description of a policy, procedure, or principle within an organization. For
example, a pilot cannot be on duty for more than 10 hours during a 24-hour period,
or a professor may teach up to four classes during a semester.
 Business Rules In Data Modelling
Translating Business Rules into Data Model Components

As a general rule, a noun in a business rule will translate into an entity in the model, and a
verb (active or passive) that associates the nouns will translate into a relationship among
the entities.
For example, the business rule “a customer may generate many invoices” contains
two nouns (customer and invoices) and a verb (generate) that associates the nouns.
From this business rule, you could deduce the following:
• Customer and invoice are objects of interest for the environment and should be
represented by their respective entities.
• There is a generate relationship between customer and invoice.
 Business Rules In Data Modelling
To properly identify the relationship type, you should generally ask two questions:

• How many instances of B are related to one instance of A?

• How many instances of A are related to one instance of B?

For example, you can assess the relationship between student and class by asking two
questions:
• In how many classes can one student enroll? Answer: many classes.
• How many students can enroll in one class? Answer: many students.

Therefore, the relationship between student and class is many-to-many (M:N).

 Naming Conversions
• Entity names should be descriptive of the objects in the business environment and use
terminology that is familiar to the users

• An attribute name should also be descriptive of the data represented by that attribute.
It is also a good practice to prefix the name of an attribute with the name or
abbreviation of the entity in which it occurs. For example, in the CUSTOMER entity, the
customer’s credit limit may be called CUS_CREDIT_LIMIT. The CUS indicates that the
attribute is descriptive of the CUSTOMER entity, while CREDIT_LIMIT makes it easy to
recognize the data that will be contained in the attribute.
 Graph Data Modelling
Data modeling with graphs is a technique
that represents and organizes data using a
graph structure, which consists of nodes,
edges, and properties.

• The nodes represent entities or objects.

• Edges depict relationships between these

entities.
• Properties convey additional information
about both nodes and edges (attributes)
Figure 1: Graph Model
 Graph Data Modelling
A node corresponds to the instance of a
relational entity. The node is a specific instance
of something we want to keep data about. Each
node (circle) in Figure 1 represents a single agent.
Properties are like attributes; they are the data
that we need to store about the node. All agent
nodes might have properties like first name and
last name, but all nodes are not required to have
the same properties.
An edge is a relationship between nodes. Edges
(shown as arrows in Figure 1) can be in one
direction, or they can be bidirectional. Figure 1: Graph Model
 Graph Data Modelling
In Figure 2, we have four entities, Customer, Order,
Product and PriceHistory, which are represented
as nodes.

The links between them are denoted by

relationships. A Customer places an Order while
an Order cannot place a Customer. In this instance,
we represent Places as a directed relationship.
However, a Customer Buys a Product is
represented by a directed relationship as a Product
Buys a Customer cannot be true. Conversely,
a Product may have PriceHistory and PriceHistory
may have Product, hence, this is represented as
undirected relationship.
 Graph Data Modelling
Similarly, a more complex graph data model for
a motor insurance fraud detection model is
presented in Figure 3. In this figure, the nodes
are labeled with their roles and are structured
with named, directed relationships. For
example, a Person Lives_in a City, and a
Person Drives a Car that Possesses an
Figure 3: A graph model for car insurance fraud
Insurance and was Involved in an Accident. investigation.
 Benefits of Graph Database

• Efficient Representation of Relationships: Graph databases excel at modeling and

representing complex relationships between entities.
• Flexible Schema and Schema-less Nature: Graph databases usually support a flexible
schema or are schema-less, allowing for dynamic changes in data structure.
• Highly Performant Traversal Operations: Graph databases are optimized for traversal
operations, making it efficient to navigate and explore relationships between nodes.
• Pattern Recognition and Analysis: Graph databases support advanced pattern-matching
queries and analytical operations.
• Scalability for Growing Relationships: Graph databases are designed to scale
horizontally, accommodating growing datasets and increasing numbers of relationships.
 Relational Database Model
• Relational Model (RM) developed by E.F. Codd of IBM in 1970, is a collection of database’s relations
(a mathematical concept) comprising of entities, attributes within those entities, and relationships.

• The logical view of the relational database is facilitated by the creation of data relationships

based on a logical construct known as a relation. Because a relation is a mathematical construct,

end users find it much easier to think of a relation as a table. A table is perceived as a two-

dimensional structure composed of rows and columns. A table is also called a relation because

the relational model’s creator, E. F. Codd, used the two terms as synonyms.
 Characteristics of a Relational Table

1 table is perceived as a two-dimensional structure composed of rows

and columns.
2 Each table row (tuple) represents a single entity occurrence within the
entity set.
3 Each table column represents an attribute, and each column has a
distinct name.
4 Each intersection of arow and column represents a single data value.

5 All values in a column must conform to the same data format.

6 Each column has a specific range of values known as the attribute

domain.
7 The order of the rows and columns is immaterial to the DBMS.
Relational Database Model

• The database table shown in

Figure 3.1 illustrates the
characteristics listed in Table
 Relational Model Concepts DBMS
• Attribute: Each column in a Table. Attributes are the properties which define a relation. e.g.,
Student_No, name, etc.
• Tables – In the Relational model, the relations are saved in the table format. It is stored along with
its entities. A table has two properties rows and columns. Rows represent records and columns
represent attributes.
• Tuple – It is nothing but a single row of a table, which contains a single record.
• Relation Schema: A relation schema represents the name of the relation with its attributes.
• Degree: The total number of attributes which in the relation is called the degree of the relation.
• Cardinality: Total number of rows present in the Table.
• Column: The column represents the set of values for a specific attribute.
• Relation instance – Relation instance is a finite set of tuples in the RDBMS system. Relation
instances never have duplicate tuples.
• Relation key – Every row has one, two or multiple attributes, which is called relation key.
• Attribute domain – Every attribute has some pre-defined value and scope which is known as
attribute domain.
 Relational Database Keys
Recall that a key is an attribute or Key Type Definition
group of attributes that can
determine the values of other Super key An attribute or combination of attributes that
attributes. Therefore, keys are uniquely identifies each row in a table
determinants in functional Candidate key A minimal (irreducible) super key; a super key
dependencies. Several types of that does not contain a subset of attributes that
keys are used in the relational
is itself a super key
model, and you need to be
familiar with them. Primary key A candidate key selected to uniquely identify all
other attribute values in any given row; Cannot
A composite key is a key that is contain null entries
composed of more than one
attribute. An attribute that
Foreign key An attribute or combination of attributes in one
is a part of a key is called a key table whose values must either match the
attribute. Primary key in another table or be null
Secondary key An attribute or combination of attributes used
strictly for data retrieval purposes
 Example of Relational Database

Note
Technically, a null in a database is not a value and it is not an entry—it is the absence
of a value and the absence of an entry. However, for conversational convenience, even
database professionals and database vendors will often refer to a null in the database as
a“null value”or a“null entry.”
Integrity Rules
An Illustration of Integrity Rules
Entity integrity. The CUSTOMER table’s primary key
is CUS_CODE. The CUSTOMER primary key column
has no null entries, and all entries are unique.
Similarly, the AGENT table’s primary key is
AGENT_CODE, and this primary key column is also
free of null entries.

Referential integrity. The CUSTOMER table contains

a foreign key, AGENT_CODE, that links entries in the
CUSTOMER table to the AGENT table. The
CUS_CODE row identified by the (primary key)
number 10013 contains a null entry in its
AGENT_CODE foreign key because Paul F. Olowski
does not yet have a sales representative assigned to
him. The remaining AGENT_CODE entries in the
CUSTOMER table all match the
AGENT_CODE entries in the AGENT table.
 Operations in Relational Model
Four basic update operations performed on relational database model are:

1. Insert
2. Update
3. Delete
4. Select.

Whenever one of these operations are applied, integrity constraints specified on the
relational database schema must never be violated.
 Operations in Relational Model
1. Insert Operation

Insert is used to insert data into the relation

The insert operation gives values of the attribute for a new tuple which should be inserted into
a relation.
 Operations in Relational Model
2. Update Operation

Allows you to change the values of some attributes in existing tuples

You can see that in the below-given relation table CustomerName= ‘Thapelo’ is
updated from Inactive to Active.
 Operations in Relational Model
3. Delete Operation

Delete is used to delete tuples from the table.

To specify deletion, a condition on the attributes of the relation selects the tuple to be
deleted.
 Operations in Relational Model
4. Select Operation

Select allows you to choose a specific range of data.

In the above scenario, the CustomerName=”Shongwe” is selected

 Relational Model Best Practices
Some best practices that should be followed when creating a relational data model include:

•Data need to be represented as a collection of relations.

•Each relation should be depicted clearly in the table.
•Rows should contain data about instances of an entity.
•Columns must contain data about attributes of the entity.
•Cells of the table should hold a single value.
•Each column should be given a unique name.
•No two rows can be identical.
•The values of an attribute should be from the same domain
 Similarities Between Relational
and Graph Data Models
The similarities between the relational and graph data models lie in their structured representation of
data, incorporation of relationships between data elements, utilization of a query language (such as
SQL for relational databases and graph query languages like Cypher and Neo4j for graph databases),
adherence to the ACID properties to ensure data consistency and integrity, support for data integrity
through constraints, and the use of indexes for performance optimization.

Some of these similarities are expatiated as follows:

1. Structured Data Representation: Both relational and graph data models provide structured
representations for data. In relational databases, data is organized into tables with rows and columns,
while in graph databases, data is structured as nodes and edges.
 Similarities Between Relational
and Graph Data Models
2. Use of Relationships: Both models incorporate the concept of relationships between data
elements. In relational databases, relationships are established through foreign key constraints,
linking records in different tables. In graph databases, relationships are explicitly represented as edges
connecting nodes.

3. Query Language: SQL (Structured Query Language) is commonly used to query relational
databases, enabling users to retrieve, manipulate, and analyze data. Similarly, graph databases often
use query languages tailored to traverse and query graph structures, such as Cypher (used in Neo4j).

4. ACID Properties (Atomicity, Consistency, Isolation, Durability): Relational and graph databases
both adhere to the ACID properties, ensuring data consistency and integrity. Transactions in both
models are designed to be atomic, consistent, isolated, and durable.
 Similarities Between Relational
and Graph Data Models
2. Use of Relationships: Both models incorporate the concept of relationships between data
elements. In relational databases, relationships are established through foreign key constraints,
linking records in different tables. In graph databases, relationships are explicitly represented as edges
connecting nodes.

3. Query Language: SQL (Structured Query Language) is commonly used to query relational
databases, enabling users to retrieve, manipulate, and analyze data. Similarly, graph databases often
use query languages tailored to traverse and query graph structures, such as Cypher (used in Neo4j).

4. ACID Properties (Atomicity, Consistency, Isolation, Durability): Relational and graph databases
both adhere to the ACID properties, ensuring data consistency and integrity. Transactions in both
models are designed to be atomic, consistent, isolated, and durable.
 Similarities Between Relational
and Graph Data Models
5. Data Integrity and Constraints: Both models support the enforcement of data integrity through
constraints. In relational databases, constraints include primary keys, foreign keys, and unique
constraints. In graph databases, constraints may involve specifying the types of relationships between
nodes or defining unique identifiers for nodes.

6. Indexes for Performance Optimization: Relational and graph databases both utilize indexes to
optimize query performance. Indexing is used to accelerate data retrieval operations by providing a
fast lookup mechanism. In relational databases, indexes are applied to columns, while in graph
databases, indexes may be used on node or relationship properties.
Comparison Between Relational
and Graph Data Models
Case Study

Consider the scenario described by the statement “A

customer can make many payments, but each payment
is made by only one customer.” Use this scenario as
the basis for an entity relationship diagram (ERD)
representation.
Group Activity

Create a Graph Data Model for a library system. Entities

include Books, Authors, and Borrowers. Each book is
written by one or more authors, and multiple books can
be borrowed by different users. Propose node attributes
and relationships to represent this library system .
Activity
Discuss the importance of data models.

2. What is a business rule, and what is its purpose in

data
modeling?
3. How do you translate business rules into data model
components?
4. Describe the basic features of the relational data
model
and discuss their importance to the end user and the
designer.
DBMS Examples Demo
 Post-Session Assessment

1.What is a data model?

2. What are building blocks of data models?
3. Role of business rules in data modelling?
4. The difference between Graph and Relational data models?
What will be covered in the next week?
Bibliography
Carlos Coronel and Steven Morris. 2023. Database Systems:
Design, Implementation, & Management – Chapter 1. 14th ed.
Cengage Learning.