0% found this document useful (0 votes)
24 views55 pages

Chapter 2 Data Models

Chapter Two discusses data modeling as a crucial step in database design, emphasizing the creation of data models that represent real-world data structures and their relationships. It outlines the components of data models, including entities, attributes, relationships, and constraints, and highlights the importance of business rules in defining and enforcing data integrity. The chapter also covers the evolution of data models and the relational model, which revolutionized database design by organizing data into tables and using keys for data retrieval and integrity.

Uploaded by

floydannold
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
24 views55 pages

Chapter 2 Data Models

Chapter Two discusses data modeling as a crucial step in database design, emphasizing the creation of data models that represent real-world data structures and their relationships. It outlines the components of data models, including entities, attributes, relationships, and constraints, and highlights the importance of business rules in defining and enforcing data integrity. The chapter also covers the evolution of data models and the relational model, which revolutionized database design by organizing data into tables and using keys for data retrieval and integrity.

Uploaded by

floydannold
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 55

CHAPTER TWO

Data Models
DATA MODELLING OVERVIEW
▪ Database Design focuses on how the database structure will be used to store and
manage end-user data.
What is Data Modelling?
▪ On the other hand, Data Modelling is the first step in designing a database and
refers to the process of creating a specific data model for a determined
problem domain.
What is a Data Model?
▪ A data model is a conceptual representation of the data structures that are
required by a database. The data structures include:
▪ data objects
▪ the associations between data objects
▪ the rules which govern operations on the objects.
DATA MODELLING OVERVIEW
▪ A data model is a relatively simple representation, usually graphical, of
more complex real-world data structures.
▪ The data model focuses on:
▪ what data is required
▪ how it should be organized

▪ To use a common analogy, the data model is equivalent to an architect's


building plans.
▪ A data model is independent of hardware or software constraints. It
focuses on representing the data as the user sees it in the “real world”.
DATA MODELLING OVERVIEW
▪ It serves as a bridge between the concepts that make up real-world
events and processes and the physical representation of those concepts
in a database.
▪ The data model has two outputs:
▪ Entity-relationship diagram which represents the data structures in a
pictorial form.
▪ Because the diagram is easily learned, it is valuable tool to communicate the
model to the end-user.
▪ Data document: This document that describes in details the data objects,
relationships, and rules required by the database.
▪ The data document provides the details required by the database developer to
construct the physical database.
DATA MODELLING OVERVIEW
▪ Done properly, the final data model is an effect “blueprint” containing all the
instructions to build a database that will meet all end-user requirements.
▪ An implementation-ready data model should contain at least the following
components:
▪ A description of the data structure that will store the end-user data.
▪ A set of enforceable rules to guarantee the integrity of the data.
▪ A data manipulation methodology to support the real-world data
transformations.
▪ The data model is an abstraction; you cannot draw the required data out of the
data model.
▪ For example, think of a house plan or blueprint, you cannot live in a blueprint and
architects consider blueprints before constructing a building.
THE IMPORTANCE OF DATA MODELS
▪ A data model’s main function is to help you understand the complexities of the real-world environment.
▪ The goal of the data model is to make sure that the all data objects required by the database are
completely and accurately represented. Because the data model uses easily understood notations and
natural language, it can be reviewed and verified as correct by the end-users.
▪ The data model is also detailed enough to be used by the database developers as a “blueprint” for
building the physical database.
▪ The information contained in the data model will be used to define the relational tables, primary and
foreign keys, stored procedures, and triggers.
▪ The data model also acts as a communication tool to facilitate interaction among the designer, the
applications programmer, and the end user. End-users have different views and needs for data from the
designers and programmers. A well-developed data model can even foster improved understanding of
the organization.
COMPONENTS OF DATA MODELS
There are four (4) component of a database model:
▪ Entity: an entity is anything (a person, a place, a thing, or an event) about which data are to
be collected and stored. An entity represents a particular type of object in the real world.
▪ Attribute: an attribute is a characteristic of an entity.
▪ Relationship: a relationship describes an association among entities. Relationships can be
thought of as verbs, linking two or more nouns.
▪ Constraint: a constraint is a restriction placed on the data.
Example: department and a course are some of the important components of any academic
institution. In that case:
▪ the department and course are entities,
▪ the department name, course name, course code, etc. are attributes of these entities,
▪ a department has multiple courses and a course has a department is the relationship between these
entities
RELATIONSHIPS: THE BASIC CHEN ERD

Database Systems 6e / Rob & Coronel 2- 8


RELATIONSHIPS:THE BASIC CROW’S FOOT ERD

Database Systems 6e / Rob & Coronel 2- 9


COMPONENTS OF DATA MODELS
▪ Entities and relationships can both have attributes. E.G. an employee entity
might have an Identity Number (ID Number) attribute; the proved
relationship may have a date attribute.
▪ Every entity (unless it is a weak entity) must have a minimal set of uniquely
identifying attribute(s), which is called the entity's primary key.
▪ Entity-relationship diagrams don't show single entities or single instances of
relations. Rather, they show entity sets and relationship sets.
▪ Entity-relationship diagrams don't show single entities or single instances of
relations. Rather, they show entity sets and relationship sets. For example: a
particular song is an entity. The collection of all songs in a database is an
entity set.
TYPES OF RELATIONSHIPS
▪ One-to-one (1:1): One entity from entity set A can be associated with at
most one entity of entity set B and vice versa.
▪ One-to-many (1:M): One entity from entity set A can be associated with
more than one entities of entity set B however an entity from entity set
B, can be associated with at most one entity of entity set B.
▪ Many-to-one (N:1): More than one entities from entity set A can be
associated with at most one entity of entity set B, however an entity
from entity set B can be associated with more than one entity from
entity set A.
▪ Many-to-many (M:N): One entity from A can be associated with more
than one entity from B and vice versa.
TYPES OF RELATIONSHIPS
▪ As a general rule, to properly identify the relationship type, you should
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 enrol?
▪ How many students can enrol in one class?
TYPES OF RELATIONSHIPS




CONSTRAINTS
▪ A constraint is a restriction or rule placed on the data. Constraints are important
because they help to ensure data integrity. Constraints are normally
expressed in the form of rules.
▪ They can apply to a column, a whole table, more than one table or an entire
schema.
▪ The schema is the conceptual organization of the entire database. There are
there are mainly three types of schemas:
▪ External Schema - database users’ view
▪ Conceptual Schema - database administrators’ view
▪ Internal Schema - database developers’ view
▪ The internal schema is composed of the physical schema and the logical
schema.
CONSTRAINTS
▪ Five Types of Constraints:
▪ NOT NULL: value in a column must not be NULL.
▪ UNIQUE: value(s) in specified column(s) must be unique for each row in a table.
This constraint ensures that each rows for a column must have different value.
▪ PRIMARY KEY: combination of a NOT NULL and a UNIQUE constraint. value(s)
in specified column(s) must be unique for each row in a table and not be NULL;
normally each table in a database should have a primary key - it is used to
identify individual records.
▪ FOREIGN KEY: ensure the referential integrity of the data and value(s) in
specified column(s) must reference an existing record in another table (via
primary key or unique constraint). Referential integrity means that if the
foreign key contains a value, that value refers to an existing valid tuple (row) in
another relation
▪ CHECK: ensures that the value stored in a column meets a specific condition.
BUSINESS RULES
▪ From a database point of view, the collection of data becomes
meaningful only when it reflects properly defined business rules.
▪ A business rule is a brief, precise, and unambiguous description of a
policy, procedure, or principle within a specific organization.
▪ Business rules apply to any organization that stores and uses data to
generate information.
▪ Business rules help to create and enforce actions within any
organization’s environment.
▪ Properly written business rules are used to define entities, attributes,
relationships, and constraints.
BUSINESS RULES
▪ Business rules can apply to people, processes, corporate behavior and computing
systems in an organization, and are put in place to help the organization achieve its
goals.
▪ Data can be considered significant only after business rules are defined, without them
the data is just records. However, to a business they are the characteristics that are
defined and seen by the company.
▪ To be considered true, business rules must be in writing and kept up to date.
▪ Sources of business rules are: managers, policy makers, department managers,
written documentation, procedures, standards, operation manuals, and interviews
with end-users.
▪ Business Rules give the proper classification of entities, attributes, relationships, and
constraints.
BUSINESS RULES
▪ As a general rule in database design, the noun in a business rule will translate into an entity in
the model and a verb (active or passive) associating nouns will translate into a relationship
among the entities.
▪ Business rules should be considered as bidirectional. There are two questions to ask to properly
identify a relationship in a business rules:
▪ How many instances of B are related to one instance of A?
▪ How many instances of A are related to one instance of B?

▪ Examples of business rules:


▪ Departments ------offers---------Course
▪ Course----------generates---------Class
▪ Professor --------teaches----------Class

▪ There are several protocols to the way business rules are written. Not every protocol has to be
followed.
CHARACTERISTICS OF BUSINESS RULES
▪ Business rules are brief, precise, and unambiguous descriptions of a policies,
procedures, or principles within a specific organization
▪ They apply to any organization that stores and uses data to generate
information
▪ They are description of operations that help to create and enforce actions within that
organization’s environment
▪ They must be rendered in writing
▪ They must be kept up to date
▪ Sometimes they are external to the organization
▪ They must be easy to understand and widely disseminated
▪ They describe characteristics of the data as viewed by the company
IMPORTANCE OF BUSINESS RULES
▪ Business rules promote the creation of an accurate data model.
▪ They help standardize the company’s view of data.
▪ They can be a communication tool between users and designers.
▪ They allow the designer to:
▪ understand the nature, role, and scope of the data
▪ understand business processes
▪ develop appropriate relationship participation rules
▪ identify all constraints
▪ create an accurate data model.
EXAMPLES OF BUSINESS RULES
▪ Suppose there was a single company responsible for handling student
applications to different universities and it had the following
business rules:
▪ Each student can submit one application per university.
▪ Each application is submitted by only one student.
▪ Each university can be associated with one or more applications and each
application is associated with only one university
▪ Each application must include two or more recommendations and each
recommendation is included with only one application.

▪ From the above business rules identify all the entities and relationships
among the entities and draw a relational data model that include:
▪ All the entities
▪ At least three (3) attributes for each entity
▪ All the relationships among the entities
EVOLUTION OF DATA MODELS
▪ Hierarchical
▪ Network
▪ Relational
▪ Entity relationship
▪ Object oriented
EVOLUTION OF DATA MODELS
EVOLUTION OF DATA MODELS
RELATIONAL MODEL
▪ The Relational Model represented a major breakthrough for both users and
designers.
▪ Its conceptual simplicity set the stage for a genuine database revolution.
▪ The Relational Model stores data in a matrix composed of intersecting rows
and columns referred to as a relation (tables). Each row in a relation is called
a tuple.
▪ The relational database is a collection of tables in which data are stored.
▪ Tables are related to each other through the sharing of a common attribute.
▪ A relational diagram is used to represent the relational database’s entities,
the attributes within those entities, and the relationships between those
entities.
RELATIONAL DIAGRAM
RELATIONAL DATABASE KEYS
Key Type Definition
Composite Two or more attributes that uniquely identify a row in a database table
key
Super key A set of attributes within a table that uniquely identifies each row
within a table.
Candidate A super key with no redundant attributes. Candidate keys are defined
key as the set of fields from which primary key can be selected.
Primary key A candidate key that is selected to uniquely identify each record (row)
in a relation (table). It is the main key of the table.
Secondary A candidate key which is not selected for primary key. Secondary keys
Key are used strictly for data retrieval purposes
Foreign Key An attribute or set of attributes within one relation (table) that
matches the candidate key of another relation (table)
RELATIONAL DATABASE KEYS
RELATIONAL DATABASE KEYS
▪ Composite Key: EMPLOYEE_ID, EMPLOYEE_NAME or SSN, EMPLOYEE_NAME
▪ Super key: EMPLOYEE_ID or EMP_PASSPORT_NUM or LICENCE_NUMBER or
SSNN or a combination of these fields with other fields e.g. SSN,
EMPLOYEE_NAME
▪ Candidate key: EMPLOYEE_ID or EMP_PASSPORT_NUM or
LICENCE_NUMBER or SSN
▪ Primary key: EMPLOYEE_ID
▪ Secondary key: EMP_PASSPORT_NUM or
LICENCE_NUMBER or SSNN
▪ Foreign Key: DEPARTMRNT_NUMBER
ENTITY RELATIONAL MODEL
▪ The Relational Model (ER) was a vast improvement over the hierarchical
and network models, it still lacked the features that would make it an effective
database design tool.

▪ Because it is easier to examine structures graphically than to describe them in


text, database designers prefer to use a graphical tool in which entities and
their relationships are pictured.

▪ The ER model is a form of graphical representation of entities and


their relationships in a database structure that quickly became popular
because it complemented the relational data model concepts.

▪ The relational data model and ERM combined to provide the foundation for
tightly structured database design.

▪ ER models are normally represented in an entity relationship diagram (ERD),


ENTITY RELATIONAL MODEL (2)
▪ An entity is represented in the ERD by a rectangle, also known as an entity box.
▪ The ER model uses the term connectivity to label the relationship types. The
name of the relationship usually is an active or passive verb. For example:
▪ a PAINTER paints many PAINTINGs
▪ an EMPLOYEE learns many SKILLs
▪ a STUDENT
attends/enrol/registers/takes/has
▪ There are two different types of representing relationships using two
many CLASSES
ER notations:
▪ Chen Notation - relationships are represented by a diamond connected to the related
entities through a relationship line. The relationship name is written inside the diamond.
▪ Crow’s Foot - connectivity are represented by symbols. For example:
▪ 1 is represented by a short line segment
▪ M is represented by the three-pronged crow’s foot
CHEN VS CROW’S FOOT NOTATION
RELATIONAL DATABASE MODEL
 Relational database is a collection of tables
 Heading: table name and column names

 Body: rows, occurrences of data

Heading

Student (table name)


StdSSN StdLastName StdMajor StdClass StdGPA
123-45-6789 WELLS IS FR 3.00
124-56-7890 NORBERT FIN JR 2.70
234-56-7890 KENDALL ACCT JR 3.50
Body 3
RDBMS
 A relational database management system (RDBMS) is a
program that lets you create, update, and administer a relational
database.
 Most commercial RDBMS's use the Structured Query Language

(SQL) to access the database, although SQL was invented after


the development of the relational model and is not necessary for
its use.

4
COMPONENTS OF RELATIONAL
DATABASE STRUCTURAL TERMINOLOGY
Relation
• a table with columns and rows

Tuple (row of record)


• a row of a relation

Cardinality of a relation (number of rows)


• the number of tuples it contains

Attribute (column or field)


• a named column of a relation

Degree of a relation (number of columns)


• number of attributes it contains

Primary key (unique identifier)


• the candidate key that is selected to identify tuples uniquely within the relation

Domain (pool of values of specific attributes of 6


relation)
• the set of allowable values for one or more attributes
COMPONENTS OF RELATIONAL
DATABASE STRUCTURAL TERMINOLOGY

Primary key: sid

Degree: 5 Domain of age: Integer


Cardinality : 6

7
COMPONENTS OF RELATIONAL
DATABASE STRUCTURAL TERMINOLOGY
Exercise:

Table name: Animal_Vaccination

Identify:
a. Name of the relation.
b. Cardinality of the relation.
c. Degree of the relation.
d. Suitable domain for column Type.
e. Suitable domain for column Date of Birth.
8
PROPERTIES OF TABLES IN A
RELATIONAL DATABASE

Value Column
s are values are of
the same kind
atomi
c
The The
sequence of sequence of
rows is columns is
insignificant insignificant

Each Each
column
row is must
have a
uniqu unique 10
name
e
CHARACTERISTICS OF RELATION SCHEME

Relation scheme
Named relation defined by a set of attribute
and domain name pairs.

Characteristics:
a. Relation name
b. Attribute name
c. Domains

Syntax:
11
RelationName (attribute-1, attribute-2…
attribute-n)
CHARACTERISTICS OF RELATION SCHEME

Example:
Table name: Animal_Vaccination

Animal_Vaccination (ID, Name of Animal, Type, Date of Birth,


Vaccinated?, Keeper)

12
RELATION INSTANCE
 A tuple at a specifc moment of time
 Eg: Student (StudentId, firstName, lastName, courseId)
 The relation instance for Student:
 (L0002345, Jim, Black, C002)
 (L0001254, James, Harradine, A004)
 The relation instance changed when the tuple is updated,
deleted or inserted

13
RELATION KEYS
1) Candidate key
- Any set of one or more columns whose combined values are
unique among all occurrences (i.e., tuples or rows).
No
- component of a candidate key is allowed to be null.
There
- can be any number of candidate keys in a table.

14
RELATION KEYS
2) Primary key (identifier)
- Any candidate key of that table which the database
designer arbitrarily designates as "primary".
- The primary key may be selected for convenience,
comprehension, performance, or any other reasons.

3) Foreign key (referential)


- A set of one or more columns in any table which may

hold the value(s) found in the primary key column(s) of


some other table.

15
RELATION KEYS

16
RELATION KEYS

17
RELATION KEYS
Exercise:

Identify:
i. candidate key
ii. primary key

18
INTEGRITY RULES
 Data integrity means that the data values in the
database are correct and consistent.
 Integrity constraints provide a way of ensuring that changes
made to the database by authorized users do not result
in a loss of data consistency

 Data integrity is enforced in the relational model by:


1)Entity integrity
2)Referential integrity

19
INTEGRITY RULES
1) Entity Integrity
- states that “for every instance of an entity, the value of the

primary key must exist, be unique, and cannot be null”


- Without entity integrity, the primary key could not fulfill
its role of uniquely identifying each instance of an entity

2) Referential Integrity
- states that “every foreign key value must match a primary

key value in an associated table”


- ensures that we can correctly navigate between related

entities
20
INTEGRITY RULES
Exercise
:

1)What is the primary key for each of the


table?
2)What is the foreign key? 21

3)Write relation scheme for both tables.


EXERCISE

Identify:
a. Suggest suitable name for the relation. Senior_Citizen, Member, Neighbour
b. Cardinality of the relation.
c. Degree of the relation.
d. Suitable domain for column Last Name.
e. Suitable domain for column City.
22
f. Suitable domain for column Age.
EXERCISE

Identify:
a. Suggest suitable name for the relation.
b. Cardinality of the relation.
c. Degree of the relation.
d. Suitable domain for column ID.
e. Suitable domain for column Class.
23
f. Suitable domain for column Mark.
Exercise
• Consider the business rule below:
• A company has several departments.
• Each department has a supervisor and at least one employee.
• Employees must be assigned to at least one department.
• Project will be given to the employee and it will be done in a group.
• At least one employee is assigned to one project or more.
• The important data fields are the names of the departments, projects,
supervisors and employees, as well as the supervisor and employee
number, department code and a unique project number
• Required:
• Identify all the entities
• List atleast 3 attributes for each entity
• List the relationships btween the entities identified
• Draw an ERD

You might also like