SlideShare a Scribd company logo
1 of 56
The Relational Data Model
What is Relational Model?
 Relational model is most widely used data model for
commercial data-processing. The reason it’s used so
much is, because it’s simple and easy to maintain.
 The model is based on a collection of tables. Users of the
database can create tables, insert new tables or modify
existing tables. There are several languages for database
programming.
 SQL, Oracle, etc.
3
 The relational model invented by Edgar
F. Codd, of IBM's San Jose Research
Laboratory.
 He suggested that the rigid
principles of mathematics could be
used to design, create and manage
a database system.
 Codd's ideas were first published in
1970 in a seminal paper 'A
Relational Model of Data for Large
Shared Data Banks’.
 This research gave birth to
the relational model on
which relational databases are
Brief History
3
Edgar F. Codd
4
 One of the rules proposed by Codd was that a
relational database should include a common
language that is used to:
 create the database
 store and manipulate the data within it
 manage security.
 The language that was widely adopted
was Structured Query Language (SQL)
Brief History
4
5
Database Structure (Relational Model)
 This model organizes data into one or
more tables (or "relations") of columns and
rows, with a unique key identifying each
row.
 Generally, each table/relation represents
one "entity type"
(such as customer or product).
 The rows represent instances of
that type of entity (such as "Lee“
or "chair") and the columns
representing values attributed to that
Database Structure
5
Relational Database
6
Database Structure (Relational)
 Data is organized into rows, columns and tables,
and it is indexed to make it easier to find relevant
information.
Database Structure
6
Relational Model Basic
The relational model gives us a single way to represent
data: as a two-dimensional table called a relation.
 Attributes
 Schemas
 Tuples
 Domains
 Equivalent Representations of a Relation
Relational Model
 Sets
 collections of items of the same type
 no order
 no duplicates
 Mappings
domain range
1:many
many:1
1:1
many:many
Attributes
Attribute
Title Year Length
Star Wars 1977 124
Might Ducks 1991 104
Wayne’s World 1992 95
Attributes of a relation serve as names for the columns of the
relation. Usually, an attribute describes the meaning of entries in
the column below.
Table = relation.
Column headers = attributes.
Schemas
 The name of a relation and the set of attributes for a relation is
called a schema.
 We show the schema for the relation with the relation name
followed by a parenthesized list of its attributes.
 Relation schema = name(attributes) + other structure info.,
e.g., keys, other constraints.
 Order of attributes is arbitrary, but in practice we need to
assume the (standard) order given in the relation schema.
 Relational database schema = collection of relation schemas.
 So the schema for previous slide is
Movies (title, year, length)
Tuples
Tuple
Title Year Length
Star Wars 1977 124
Might
Ducks
1991 104
Wayne’s
World
1992 95
 The rows of a relation, other than the header row containin
The attribute names are called tuples.
 A tuple has one component for each attribute of the relatio
Domains
 Each attribute of a relation is associated with a
particular element type called domain.
 The components of any tuple of the relation must have,
in each component, a value that belongs to the domain
of the corresponding column.
 Example:
with title string is associated
with year integer is associated
The Entity Relationship Data Model
The Entity Relationship Data Model
Relations
Overview of Entity/Relationship
(E/R) Model
 Entities
 Relationships
 Roles of entities in a
relationship
 Constraints on entities:
 domain constraints
 key constraints
 Constraints on relationships
 Cardinality Constraints
(mapping constraints in SKS)
 Participation Constraints
(existence dependencies in
SKS)
 Weak Entity Sets
 Multiway relationships
 Subclass/superclass
Relationships
15
The Entity Relationship Data Model
 Entities represent classes of real-world objects.
Person, Students, Projects, Courses are entities
of a University database
 Relationships represent interactions between two
or more entities
Person
Is_Born_In
City
Lives_In
N 1
N 1
Entities & Relationship
16
The Entity Relationship Data Model
Entities
The Entity Relationship Data Model
 Entities are represented by means of rectangles.
Rectangles are named with the entity set they
represent.
Entities
ER Diagram Representation
18
The Entity Relationship Data Model
For Example:
 Every employee works in at least one project
 Every project has employees working on it.
EMPLOYEE
SSN
Name
Salary
PROJECT
Name
Code
WORKS_ON
N
N
Entities & Relationship
19
The Entity Relationship Data Model
Attributes
The Entity Relationship Data Model
Attributes represent elementary properties of the
entities or relationships. The stored data will be
kept as values of the attributes
PERSON
Ssn
Name
Profession
Is_Born_In
CITY
Name
Country
Elevation
Population
Lives_In
N 1
N 1
Birth_Date
Moving_Date
Attributes
21
The Entity Relationship Data Model
Attributes
 single-valued vs multi-valued:
 color of car could be multi-valued
 salary of employee is single-
valued
 atomic vs composite:
 age of a person is atomic
 address of a person could be
composite
 stored vs derived:
 derived attributes are those that
can be derived from other
attributes or entities, e.g., age
can be derived from date of birth.
The Entity Relationship Data Model
Attributes are properties of entities. Attributes are
represented by means of eclipses. Every eclipse represents
one attribute and is directly connected to its entity
(rectangle).
Attributes
ER Diagram Representation
23
The Entity Relationship Data Model
If the attributes are composite, they are further divided in a tree
like structure. Every node is then connected to its attribute. That
is composite attributes are represented by eclipses that are
connected with an eclipse.
Composite Attributes
ER Diagram Representation
24
The Entity Relationship Data Model
MAN
Draft_Status
FEMALE
Maiden_Name
PERSON
Ssn
Name
Address
• An entity could be seen from many different
viewpoints
• Each viewpoint defines a set of roles in a
generalization
• Example below uses SEX to classify the object
“Person”
25
The Entity Relationship Data Model
 A classification could be disjoint or
overlapping
 An entity could have more than one
classification
MAN
Draft_Status
FEMALE
Maiden_Name
PERSON
Ssn
Name
Address
SEX
Full_Time
Annual_Salary
Department
Part_Time
Hour_Rate
Weekly_Hours
JOB
Generalizations
Attributes
Attributes
26
The Entity Relationship Data Model
Phases of Database
Design
Class Discussion
27
Conceptual
Design
Product Person
Country
Attributes
Relationship
The Entity Relationship Data Model
 How entities act upon each other or are associated with each
other.
 Think of relationships as verbs.
Relationship
For example, the named student
might register for a course.
The two entities would be the student
and the course, and the relationship
depicted is the act of enrolling,
connecting the two entities in that
way. Relationships are typically
shown as diamonds or labels directly
Entities
Attributes
Relationships between entities
Entities
Student
Name
Enroll
Course
The Entity Relationship Data Model
A relationship may involve more than two
entities
Course Meets Classroom
Day
Relationship
30
The Entity Relationship Data Model
Recursive
relationships
Relationships could be mapped from one
entity to itself
Manager_Of
Employee Manages
Subordinate_To
1
N
31
The Entity Relationship Data Model
Roles in a Relationship
 The function that an entity plays in a relationship
is called its role
 Roles are normally not explicitly specified unless
the meaning of the relationship needs
clarification
 Roles needed when entity set is related to itself
via a relationship.
employee works for
manager
worker
32
The Entity Relationship Data Model
Example: Department Store 1/2
 A department store operates in several cities
 In a city there is one headquarter coordinating the local
operations
 A city may have several stores
 Stores hold any amount of items
 Customers place their orders for any number of items to
a given store
GOAL: Optimize shopping in each city
33
The Entity Relationship Data Model
Example: Department Store 2/2
 A department store
operates in several
cities
 In a city there is one
headquarter
coordinating the local
operations
 A city may have several
stores
 Stores hold any amount
of items
 Customers place their
orders for any number
of items to a given store
CITIES
City Name
State
HeadQtr Address
STORES
Store ID
Address
Manager ID
LOCATED
IN
ITEMS
Item ID
Description
Size
Color
ORDERS
Order Number
Order Date
ITEMS ORDERED
Qty Ordered
HOLD
Qty Held
IN-CITIES
Qty_in_cities
CUSTOMER
Customer Name
Address
Phone Number
PLACE
N
N
1
N
N N
N N N
1
34
The Entity Relationship Data Model
Phases of Database
Design Example
35
Conceptual
Design
Purchase
Product Person
Person
Country President
Constraints in E/R Diagrams
The Entity Relationship Data Model
Constraints in E/R Diagrams
Finding constraints is part of the modeling process.
Commonly used constraints:
• Keys: social security number uniquely identifies a person.
• Single-value constraints: a person can have only one father.
• Referential integrity constraints: if you work for a company, it
must exist in the database.
• Other constraints: peoples’ ages are between 0 and 150. 37
The Entity Relationship Data Model
Keys in E/R Diagrams
address name ssn
Person
Product
name category
price
Underline to specify
keys in E/R diagrams
38
The Entity Relationship Data Model
Single Value Constraints
makes
makes
v. s.
39
The Entity Relationship Data Model
Referential Integrity Constraints
Company
Product makes
Company
Product makes
40
The Entity Relationship Data Model
Other Constraints
Company
Product makes
<100
What does this mean ?
41
The Entity Relationship Data Model
Other Constraints
42
The Entity Relationship Data Model
Enterprise Constraints
Enterprise constraints – sometimes referred to as semantic
constraints – are additional rules specified by users or database
administrators and can be based on multiple tables.
Here are some examples.
•A class can have a maximum of 30 students.
•A teacher can teach a maximum of four classes per semester.
•An employee cannot take part in more than five projects.
•The salary of an employee cannot exceed the salary of the employee’s
manager.
Other Constraints
43
The Entity Relationship Data Model
Business Rules
Business rules are obtained from users when gathering requirements.
The requirements-gathering process is very important, and its results
should be verified by the user before the database design is built. If the
business rules are incorrect, the design will be incorrect, and ultimately
the application built will not function as expected by the users.
Some examples of business rules are:
•A teacher can teach many students.
•A class can have a maximum of 35 students.
•A course can be taught many times, but by only one instructor.
•Not all teachers teach classes.
Other Constraints
44
The Entity Relationship Data Model
Cardinality
The Entity Relationship Data Model
Cardinality
• Defines the numerical attributes of the relationship between two
entities or entity sets.
The three main cardinal relationships are one-to-one, one-to-many,
and many-many.
• A one-to-one example: would be one student associated with one
mailing address.
• A one-to-many example (or many-to-one, depending on the
relationship direction): One student registers for multiple courses,
but all those courses have a single line back to that one student.
• Many-to-many example: Students as a group are associated with
multiple faculty members, and faculty members in turn are associated
The Entity Relationship Data Model
Cardinality
Cardinality views: Cardinality can be shown as look-across
or same-side, depending on where the symbols are shown.
Cardinality constraints: The minimum or maximum
numbers that apply to a relationship.
Phases of Database Design
Conceptual Design
47
Cardinality
Phases of Database Design
Conceptual Design
48
Cardinality
Phases of Database Design
Conceptual Design
49
Cardinality
Phases of Database Design
Conceptual Design
50
Cardinality System Examples
Phases of Database Design
Conceptual Design
Phases of Database
Design
52
Conceptual
Design
Purchase
Product Person
Person
Country President
Cardinality
 Superclass and Subclass relationships arise during schema
design due to the process of specialization and generalization
 Specialization: process of classifying a class of objects into
more specialized subclasses
 E.g., during design, we begin with an employee entity set. We
then specialize the employee set into different types of
employees.
 Generalization: Reverse of specialization -- it is a process of
synthesis of two or more (lower level) entity sets to produce a
higher-level entity set.
 E.g., during design, we have identified a car, a sports utility
Super/Subclasses
Phases of Database Design
Conceptual Design
53
Super/Subclasses
 Generalisation is the Superclass concept
An entity with one or more distinct subgroupings
 Specialisation is the Subclass concept
An entity of a distinct subgrouping
Staff
Full-Time Part-Time
Superclass
Subclasses

Phases of Database Design
Conceptual Design
54
Super/Subclasses
 Staff has a superclass/subclass relationship
 With 2 subclasses
 The relationship is ONE-TO-ONE
 The super/subclass structure
 Avoids modelling different attributes in the
same entity
 Avoids therefore nulls
 Models common attributes in the superclass
 Models unshared attributes in the
subclasses
Phases of Database Design
Conceptual Design
Full-
Time
Staff
Part-
Time

55
Copyright

More Related Content

What's hot

All data models in dbms
All data models in dbmsAll data models in dbms
All data models in dbms
Naresh Kumar
 
12. Indexing and Hashing in DBMS
12. Indexing and Hashing in DBMS12. Indexing and Hashing in DBMS
12. Indexing and Hashing in DBMS
koolkampus
 
19. Distributed Databases in DBMS
19. Distributed Databases in DBMS19. Distributed Databases in DBMS
19. Distributed Databases in DBMS
koolkampus
 

What's hot (20)

All data models in dbms
All data models in dbmsAll data models in dbms
All data models in dbms
 
OODM-object oriented data model
OODM-object oriented data modelOODM-object oriented data model
OODM-object oriented data model
 
Relational Data Model Introduction
Relational Data Model IntroductionRelational Data Model Introduction
Relational Data Model Introduction
 
Lec 1 indexing and hashing
Lec 1 indexing and hashing Lec 1 indexing and hashing
Lec 1 indexing and hashing
 
12. Indexing and Hashing in DBMS
12. Indexing and Hashing in DBMS12. Indexing and Hashing in DBMS
12. Indexing and Hashing in DBMS
 
Spatial Database
Spatial DatabaseSpatial Database
Spatial Database
 
Database Systems - Relational Data Model (Chapter 2)
Database Systems - Relational Data Model (Chapter 2)Database Systems - Relational Data Model (Chapter 2)
Database Systems - Relational Data Model (Chapter 2)
 
Chapter-2 Database System Concepts and Architecture
Chapter-2 Database System Concepts and ArchitectureChapter-2 Database System Concepts and Architecture
Chapter-2 Database System Concepts and Architecture
 
Ordbms
OrdbmsOrdbms
Ordbms
 
19. Distributed Databases in DBMS
19. Distributed Databases in DBMS19. Distributed Databases in DBMS
19. Distributed Databases in DBMS
 
Database language
Database languageDatabase language
Database language
 
ER Model in DBMS
ER Model in DBMSER Model in DBMS
ER Model in DBMS
 
Data Models
Data ModelsData Models
Data Models
 
Chapter 4 terminolgy of keyvalue databses from nosql for mere mortals
Chapter 4 terminolgy of keyvalue databses from nosql for mere mortalsChapter 4 terminolgy of keyvalue databses from nosql for mere mortals
Chapter 4 terminolgy of keyvalue databses from nosql for mere mortals
 
Int306 02
Int306 02Int306 02
Int306 02
 
한국어와 NLTK, Gensim의 만남
한국어와 NLTK, Gensim의 만남한국어와 NLTK, Gensim의 만남
한국어와 NLTK, Gensim의 만남
 
Database : Relational Data Model
Database : Relational Data ModelDatabase : Relational Data Model
Database : Relational Data Model
 
SQL Views
SQL ViewsSQL Views
SQL Views
 
Types of Database Models
Types of Database ModelsTypes of Database Models
Types of Database Models
 
Segments in Graphics
Segments in GraphicsSegments in Graphics
Segments in Graphics
 

Similar to Week 4 The Relational Data Model & The Entity Relationship Data Model

Dbms Lec Uog 02
Dbms Lec Uog 02Dbms Lec Uog 02
Dbms Lec Uog 02
smelltulip
 
From relational data to object spaces
From relational data to object spacesFrom relational data to object spaces
From relational data to object spaces
Andrea Saltarello
 

Similar to Week 4 The Relational Data Model & The Entity Relationship Data Model (20)

Schema Integration, View Integration and Database Integration, ER Model & Dia...
Schema Integration, View Integration and Database Integration, ER Model & Dia...Schema Integration, View Integration and Database Integration, ER Model & Dia...
Schema Integration, View Integration and Database Integration, ER Model & Dia...
 
Data models
Data modelsData models
Data models
 
Data models
Data modelsData models
Data models
 
Download different material from slide share
Download different material from slide shareDownload different material from slide share
Download different material from slide share
 
Database Management System
Database Management System Database Management System
Database Management System
 
Sq lite module3
Sq lite module3Sq lite module3
Sq lite module3
 
DBMS Part-2.pptx
DBMS Part-2.pptxDBMS Part-2.pptx
DBMS Part-2.pptx
 
Lecture 16 requirements modeling - scenario, information and analysis classes
Lecture 16   requirements modeling - scenario, information and analysis classesLecture 16   requirements modeling - scenario, information and analysis classes
Lecture 16 requirements modeling - scenario, information and analysis classes
 
Dbms Lec Uog 02
Dbms Lec Uog 02Dbms Lec Uog 02
Dbms Lec Uog 02
 
Bca examination 2017 dbms
Bca examination 2017 dbmsBca examination 2017 dbms
Bca examination 2017 dbms
 
Data resource management
Data resource managementData resource management
Data resource management
 
Unit-1-DBMS-SUN-4 everything you need to know.pptx
Unit-1-DBMS-SUN-4 everything you need to know.pptxUnit-1-DBMS-SUN-4 everything you need to know.pptx
Unit-1-DBMS-SUN-4 everything you need to know.pptx
 
Db lec 02_new
Db lec 02_newDb lec 02_new
Db lec 02_new
 
From relational data to object spaces
From relational data to object spacesFrom relational data to object spaces
From relational data to object spaces
 
Dbms
DbmsDbms
Dbms
 
COMPUTERS Database
COMPUTERS Database COMPUTERS Database
COMPUTERS Database
 
Chapter – 2 Data Models.pdf
Chapter – 2 Data Models.pdfChapter – 2 Data Models.pdf
Chapter – 2 Data Models.pdf
 
Use analyzed requirements in the design of database.pptx
Use analyzed requirements in the design of database.pptxUse analyzed requirements in the design of database.pptx
Use analyzed requirements in the design of database.pptx
 
Database
DatabaseDatabase
Database
 
Islamic University Previous Year Question Solution 2019 (ADBMS)
Islamic University Previous Year Question Solution 2019 (ADBMS)Islamic University Previous Year Question Solution 2019 (ADBMS)
Islamic University Previous Year Question Solution 2019 (ADBMS)
 

More from oudesign

More from oudesign (20)

Week 8 multicultural images OUacademicTech
Week 8 multicultural images OUacademicTechWeek 8 multicultural images OUacademicTech
Week 8 multicultural images OUacademicTech
 
ITS-35505-Amazing_photoshop_slideshow
ITS-35505-Amazing_photoshop_slideshowITS-35505-Amazing_photoshop_slideshow
ITS-35505-Amazing_photoshop_slideshow
 
CST 20363 Session 7 - Blockchain
CST 20363 Session 7 - BlockchainCST 20363 Session 7 - Blockchain
CST 20363 Session 7 - Blockchain
 
CST 20363 Session 6 Cybersecurity Policy
CST 20363 Session 6 Cybersecurity PolicyCST 20363 Session 6 Cybersecurity Policy
CST 20363 Session 6 Cybersecurity Policy
 
CST 20363 Session 6 Cyberspace
CST 20363 Session 6 CyberspaceCST 20363 Session 6 Cyberspace
CST 20363 Session 6 Cyberspace
 
CST 20363 Session 5 Robotics
CST 20363 Session 5 RoboticsCST 20363 Session 5 Robotics
CST 20363 Session 5 Robotics
 
CST 20363 Session 3
CST 20363 Session 3CST 20363 Session 3
CST 20363 Session 3
 
CST 20363 Session 4 Computer Logic Design
CST 20363 Session 4 Computer Logic DesignCST 20363 Session 4 Computer Logic Design
CST 20363 Session 4 Computer Logic Design
 
CST 20363 Session 2
CST 20363 Session 2CST 20363 Session 2
CST 20363 Session 2
 
CST 20363-Session 1.2-A Brief History of Computing
CST 20363-Session 1.2-A Brief History of ComputingCST 20363-Session 1.2-A Brief History of Computing
CST 20363-Session 1.2-A Brief History of Computing
 
CST-20363-Session 1.1-Something Called CS
CST-20363-Session 1.1-Something Called CSCST-20363-Session 1.1-Something Called CS
CST-20363-Session 1.1-Something Called CS
 
CST-20363-Session 1-In the Bitginning
CST-20363-Session 1-In the BitginningCST-20363-Session 1-In the Bitginning
CST-20363-Session 1-In the Bitginning
 
Synthetic Division
Synthetic DivisionSynthetic Division
Synthetic Division
 
Week 7 Database Development Process
Week 7 Database Development ProcessWeek 7 Database Development Process
Week 7 Database Development Process
 
Week 6 Normalization
Week 6 NormalizationWeek 6 Normalization
Week 6 Normalization
 
Week 3 Classification of Database Management Systems & Data Modeling
Week 3 Classification of Database Management Systems & Data ModelingWeek 3 Classification of Database Management Systems & Data Modeling
Week 3 Classification of Database Management Systems & Data Modeling
 
Week 2 Characteristics & Benefits of a Database & Types of Data Models
Week 2 Characteristics & Benefits of a Database & Types of Data ModelsWeek 2 Characteristics & Benefits of a Database & Types of Data Models
Week 2 Characteristics & Benefits of a Database & Types of Data Models
 
Week 1 Lab Directions
Week 1 Lab DirectionsWeek 1 Lab Directions
Week 1 Lab Directions
 
Week 1 Before the Advent of Database Systems & Fundamental Concepts
Week 1 Before the Advent of Database Systems & Fundamental ConceptsWeek 1 Before the Advent of Database Systems & Fundamental Concepts
Week 1 Before the Advent of Database Systems & Fundamental Concepts
 
ACG 7000 Week 5 Developmental Psychology
ACG 7000 Week 5 Developmental PsychologyACG 7000 Week 5 Developmental Psychology
ACG 7000 Week 5 Developmental Psychology
 

Recently uploaded

Histor y of HAM Radio presentation slide
Histor y of HAM Radio presentation slideHistor y of HAM Radio presentation slide
Histor y of HAM Radio presentation slide
vu2urc
 

Recently uploaded (20)

2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...
 
Finology Group – Insurtech Innovation Award 2024
Finology Group – Insurtech Innovation Award 2024Finology Group – Insurtech Innovation Award 2024
Finology Group – Insurtech Innovation Award 2024
 
Histor y of HAM Radio presentation slide
Histor y of HAM Radio presentation slideHistor y of HAM Radio presentation slide
Histor y of HAM Radio presentation slide
 
Axa Assurance Maroc - Insurer Innovation Award 2024
Axa Assurance Maroc - Insurer Innovation Award 2024Axa Assurance Maroc - Insurer Innovation Award 2024
Axa Assurance Maroc - Insurer Innovation Award 2024
 
A Domino Admins Adventures (Engage 2024)
A Domino Admins Adventures (Engage 2024)A Domino Admins Adventures (Engage 2024)
A Domino Admins Adventures (Engage 2024)
 
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
 
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerHow to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected Worker
 
Exploring the Future Potential of AI-Enabled Smartphone Processors
Exploring the Future Potential of AI-Enabled Smartphone ProcessorsExploring the Future Potential of AI-Enabled Smartphone Processors
Exploring the Future Potential of AI-Enabled Smartphone Processors
 
Workshop - Best of Both Worlds_ Combine KG and Vector search for enhanced R...
Workshop - Best of Both Worlds_ Combine  KG and Vector search for  enhanced R...Workshop - Best of Both Worlds_ Combine  KG and Vector search for  enhanced R...
Workshop - Best of Both Worlds_ Combine KG and Vector search for enhanced R...
 
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, AdobeApidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
 
Developing An App To Navigate The Roads of Brazil
Developing An App To Navigate The Roads of BrazilDeveloping An App To Navigate The Roads of Brazil
Developing An App To Navigate The Roads of Brazil
 
Driving Behavioral Change for Information Management through Data-Driven Gree...
Driving Behavioral Change for Information Management through Data-Driven Gree...Driving Behavioral Change for Information Management through Data-Driven Gree...
Driving Behavioral Change for Information Management through Data-Driven Gree...
 
From Event to Action: Accelerate Your Decision Making with Real-Time Automation
From Event to Action: Accelerate Your Decision Making with Real-Time AutomationFrom Event to Action: Accelerate Your Decision Making with Real-Time Automation
From Event to Action: Accelerate Your Decision Making with Real-Time Automation
 
[2024]Digital Global Overview Report 2024 Meltwater.pdf
[2024]Digital Global Overview Report 2024 Meltwater.pdf[2024]Digital Global Overview Report 2024 Meltwater.pdf
[2024]Digital Global Overview Report 2024 Meltwater.pdf
 
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
Connector Corner: Accelerate revenue generation using UiPath API-centric busi...
 
Data Cloud, More than a CDP by Matt Robison
Data Cloud, More than a CDP by Matt RobisonData Cloud, More than a CDP by Matt Robison
Data Cloud, More than a CDP by Matt Robison
 
Boost Fertility New Invention Ups Success Rates.pdf
Boost Fertility New Invention Ups Success Rates.pdfBoost Fertility New Invention Ups Success Rates.pdf
Boost Fertility New Invention Ups Success Rates.pdf
 
GenAI Risks & Security Meetup 01052024.pdf
GenAI Risks & Security Meetup 01052024.pdfGenAI Risks & Security Meetup 01052024.pdf
GenAI Risks & Security Meetup 01052024.pdf
 
Automating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps ScriptAutomating Google Workspace (GWS) & more with Apps Script
Automating Google Workspace (GWS) & more with Apps Script
 
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemkeProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
 

Week 4 The Relational Data Model & The Entity Relationship Data Model

  • 2. What is Relational Model?  Relational model is most widely used data model for commercial data-processing. The reason it’s used so much is, because it’s simple and easy to maintain.  The model is based on a collection of tables. Users of the database can create tables, insert new tables or modify existing tables. There are several languages for database programming.  SQL, Oracle, etc.
  • 3. 3  The relational model invented by Edgar F. Codd, of IBM's San Jose Research Laboratory.  He suggested that the rigid principles of mathematics could be used to design, create and manage a database system.  Codd's ideas were first published in 1970 in a seminal paper 'A Relational Model of Data for Large Shared Data Banks’.  This research gave birth to the relational model on which relational databases are Brief History 3 Edgar F. Codd
  • 4. 4  One of the rules proposed by Codd was that a relational database should include a common language that is used to:  create the database  store and manipulate the data within it  manage security.  The language that was widely adopted was Structured Query Language (SQL) Brief History 4
  • 5. 5 Database Structure (Relational Model)  This model organizes data into one or more tables (or "relations") of columns and rows, with a unique key identifying each row.  Generally, each table/relation represents one "entity type" (such as customer or product).  The rows represent instances of that type of entity (such as "Lee“ or "chair") and the columns representing values attributed to that Database Structure 5 Relational Database
  • 6. 6 Database Structure (Relational)  Data is organized into rows, columns and tables, and it is indexed to make it easier to find relevant information. Database Structure 6
  • 7. Relational Model Basic The relational model gives us a single way to represent data: as a two-dimensional table called a relation.  Attributes  Schemas  Tuples  Domains  Equivalent Representations of a Relation
  • 8. Relational Model  Sets  collections of items of the same type  no order  no duplicates  Mappings domain range 1:many many:1 1:1 many:many
  • 9. Attributes Attribute Title Year Length Star Wars 1977 124 Might Ducks 1991 104 Wayne’s World 1992 95 Attributes of a relation serve as names for the columns of the relation. Usually, an attribute describes the meaning of entries in the column below. Table = relation. Column headers = attributes.
  • 10. Schemas  The name of a relation and the set of attributes for a relation is called a schema.  We show the schema for the relation with the relation name followed by a parenthesized list of its attributes.  Relation schema = name(attributes) + other structure info., e.g., keys, other constraints.  Order of attributes is arbitrary, but in practice we need to assume the (standard) order given in the relation schema.  Relational database schema = collection of relation schemas.  So the schema for previous slide is Movies (title, year, length)
  • 11. Tuples Tuple Title Year Length Star Wars 1977 124 Might Ducks 1991 104 Wayne’s World 1992 95  The rows of a relation, other than the header row containin The attribute names are called tuples.  A tuple has one component for each attribute of the relatio
  • 12. Domains  Each attribute of a relation is associated with a particular element type called domain.  The components of any tuple of the relation must have, in each component, a value that belongs to the domain of the corresponding column.  Example: with title string is associated with year integer is associated
  • 14. The Entity Relationship Data Model Relations
  • 15. Overview of Entity/Relationship (E/R) Model  Entities  Relationships  Roles of entities in a relationship  Constraints on entities:  domain constraints  key constraints  Constraints on relationships  Cardinality Constraints (mapping constraints in SKS)  Participation Constraints (existence dependencies in SKS)  Weak Entity Sets  Multiway relationships  Subclass/superclass Relationships 15 The Entity Relationship Data Model
  • 16.  Entities represent classes of real-world objects. Person, Students, Projects, Courses are entities of a University database  Relationships represent interactions between two or more entities Person Is_Born_In City Lives_In N 1 N 1 Entities & Relationship 16 The Entity Relationship Data Model
  • 18.  Entities are represented by means of rectangles. Rectangles are named with the entity set they represent. Entities ER Diagram Representation 18 The Entity Relationship Data Model
  • 19. For Example:  Every employee works in at least one project  Every project has employees working on it. EMPLOYEE SSN Name Salary PROJECT Name Code WORKS_ON N N Entities & Relationship 19 The Entity Relationship Data Model
  • 21. Attributes represent elementary properties of the entities or relationships. The stored data will be kept as values of the attributes PERSON Ssn Name Profession Is_Born_In CITY Name Country Elevation Population Lives_In N 1 N 1 Birth_Date Moving_Date Attributes 21 The Entity Relationship Data Model
  • 22. Attributes  single-valued vs multi-valued:  color of car could be multi-valued  salary of employee is single- valued  atomic vs composite:  age of a person is atomic  address of a person could be composite  stored vs derived:  derived attributes are those that can be derived from other attributes or entities, e.g., age can be derived from date of birth. The Entity Relationship Data Model
  • 23. Attributes are properties of entities. Attributes are represented by means of eclipses. Every eclipse represents one attribute and is directly connected to its entity (rectangle). Attributes ER Diagram Representation 23 The Entity Relationship Data Model
  • 24. If the attributes are composite, they are further divided in a tree like structure. Every node is then connected to its attribute. That is composite attributes are represented by eclipses that are connected with an eclipse. Composite Attributes ER Diagram Representation 24 The Entity Relationship Data Model
  • 25. MAN Draft_Status FEMALE Maiden_Name PERSON Ssn Name Address • An entity could be seen from many different viewpoints • Each viewpoint defines a set of roles in a generalization • Example below uses SEX to classify the object “Person” 25 The Entity Relationship Data Model
  • 26.  A classification could be disjoint or overlapping  An entity could have more than one classification MAN Draft_Status FEMALE Maiden_Name PERSON Ssn Name Address SEX Full_Time Annual_Salary Department Part_Time Hour_Rate Weekly_Hours JOB Generalizations Attributes Attributes 26 The Entity Relationship Data Model
  • 27. Phases of Database Design Class Discussion 27 Conceptual Design Product Person Country Attributes
  • 29.  How entities act upon each other or are associated with each other.  Think of relationships as verbs. Relationship For example, the named student might register for a course. The two entities would be the student and the course, and the relationship depicted is the act of enrolling, connecting the two entities in that way. Relationships are typically shown as diamonds or labels directly Entities Attributes Relationships between entities Entities Student Name Enroll Course The Entity Relationship Data Model
  • 30. A relationship may involve more than two entities Course Meets Classroom Day Relationship 30 The Entity Relationship Data Model
  • 31. Recursive relationships Relationships could be mapped from one entity to itself Manager_Of Employee Manages Subordinate_To 1 N 31 The Entity Relationship Data Model
  • 32. Roles in a Relationship  The function that an entity plays in a relationship is called its role  Roles are normally not explicitly specified unless the meaning of the relationship needs clarification  Roles needed when entity set is related to itself via a relationship. employee works for manager worker 32 The Entity Relationship Data Model
  • 33. Example: Department Store 1/2  A department store operates in several cities  In a city there is one headquarter coordinating the local operations  A city may have several stores  Stores hold any amount of items  Customers place their orders for any number of items to a given store GOAL: Optimize shopping in each city 33 The Entity Relationship Data Model
  • 34. Example: Department Store 2/2  A department store operates in several cities  In a city there is one headquarter coordinating the local operations  A city may have several stores  Stores hold any amount of items  Customers place their orders for any number of items to a given store CITIES City Name State HeadQtr Address STORES Store ID Address Manager ID LOCATED IN ITEMS Item ID Description Size Color ORDERS Order Number Order Date ITEMS ORDERED Qty Ordered HOLD Qty Held IN-CITIES Qty_in_cities CUSTOMER Customer Name Address Phone Number PLACE N N 1 N N N N N N 1 34 The Entity Relationship Data Model
  • 35. Phases of Database Design Example 35 Conceptual Design Purchase Product Person Person Country President
  • 36. Constraints in E/R Diagrams The Entity Relationship Data Model
  • 37. Constraints in E/R Diagrams Finding constraints is part of the modeling process. Commonly used constraints: • Keys: social security number uniquely identifies a person. • Single-value constraints: a person can have only one father. • Referential integrity constraints: if you work for a company, it must exist in the database. • Other constraints: peoples’ ages are between 0 and 150. 37 The Entity Relationship Data Model
  • 38. Keys in E/R Diagrams address name ssn Person Product name category price Underline to specify keys in E/R diagrams 38 The Entity Relationship Data Model
  • 39. Single Value Constraints makes makes v. s. 39 The Entity Relationship Data Model
  • 40. Referential Integrity Constraints Company Product makes Company Product makes 40 The Entity Relationship Data Model
  • 41. Other Constraints Company Product makes <100 What does this mean ? 41 The Entity Relationship Data Model
  • 42. Other Constraints 42 The Entity Relationship Data Model Enterprise Constraints Enterprise constraints – sometimes referred to as semantic constraints – are additional rules specified by users or database administrators and can be based on multiple tables. Here are some examples. •A class can have a maximum of 30 students. •A teacher can teach a maximum of four classes per semester. •An employee cannot take part in more than five projects. •The salary of an employee cannot exceed the salary of the employee’s manager.
  • 43. Other Constraints 43 The Entity Relationship Data Model Business Rules Business rules are obtained from users when gathering requirements. The requirements-gathering process is very important, and its results should be verified by the user before the database design is built. If the business rules are incorrect, the design will be incorrect, and ultimately the application built will not function as expected by the users. Some examples of business rules are: •A teacher can teach many students. •A class can have a maximum of 35 students. •A course can be taught many times, but by only one instructor. •Not all teachers teach classes.
  • 44. Other Constraints 44 The Entity Relationship Data Model
  • 46. Cardinality • Defines the numerical attributes of the relationship between two entities or entity sets. The three main cardinal relationships are one-to-one, one-to-many, and many-many. • A one-to-one example: would be one student associated with one mailing address. • A one-to-many example (or many-to-one, depending on the relationship direction): One student registers for multiple courses, but all those courses have a single line back to that one student. • Many-to-many example: Students as a group are associated with multiple faculty members, and faculty members in turn are associated The Entity Relationship Data Model
  • 47. Cardinality Cardinality views: Cardinality can be shown as look-across or same-side, depending on where the symbols are shown. Cardinality constraints: The minimum or maximum numbers that apply to a relationship. Phases of Database Design Conceptual Design 47
  • 48. Cardinality Phases of Database Design Conceptual Design 48
  • 49. Cardinality Phases of Database Design Conceptual Design 49
  • 50. Cardinality Phases of Database Design Conceptual Design 50
  • 51. Cardinality System Examples Phases of Database Design Conceptual Design
  • 52. Phases of Database Design 52 Conceptual Design Purchase Product Person Person Country President Cardinality
  • 53.  Superclass and Subclass relationships arise during schema design due to the process of specialization and generalization  Specialization: process of classifying a class of objects into more specialized subclasses  E.g., during design, we begin with an employee entity set. We then specialize the employee set into different types of employees.  Generalization: Reverse of specialization -- it is a process of synthesis of two or more (lower level) entity sets to produce a higher-level entity set.  E.g., during design, we have identified a car, a sports utility Super/Subclasses Phases of Database Design Conceptual Design 53
  • 54. Super/Subclasses  Generalisation is the Superclass concept An entity with one or more distinct subgroupings  Specialisation is the Subclass concept An entity of a distinct subgrouping Staff Full-Time Part-Time Superclass Subclasses  Phases of Database Design Conceptual Design 54
  • 55. Super/Subclasses  Staff has a superclass/subclass relationship  With 2 subclasses  The relationship is ONE-TO-ONE  The super/subclass structure  Avoids modelling different attributes in the same entity  Avoids therefore nulls  Models common attributes in the superclass  Models unshared attributes in the subclasses Phases of Database Design Conceptual Design Full- Time Staff Part- Time  55