Chapter 4

Database System Architecture &

Database Modeling

1 of 42
 Objectives
• Identify and describe important entities and
relationships to model data
• Develop data models to represent, organize,
and store data
• Design and use relational databases to organize,
store, and manipulate data

2 of 42
 Data Models
 A collection of tools for describing
 data
 data relationships
 data semantics
 data constraints
 Entity-Relationship model
 Relational model
 Other models:
 object-oriented model
 semi-structured data models
 Older models: network model and hierarchical
model
 Entity-Relationship Model
Example of schema in the entity-relationship model
 Entity Relationship Model (Cont.)
 E-R model of real world

 Entities (objects)

• E.g. customers, accounts, bank branch

 Relationships between entities

• E.g. Account A-101 is held by customer Johnson

• Relationship set depositor associates customers with accounts

 Widely used for database design

– Database design in E-R model usually converted to design in the relational

model (coming up next) which is used for storage and processing
 Relational Model
Attributes

• Example of tabular data in the relational model

customer- customer- customer- account-
Customer-
name street city number
id
192-83-7465 Johnson Alma A-101
Palo Alto
019-28-3746 Smith North A-215
Rye
192-83-7465 Johnson Alma A-201
Palo Alto
321-12-3123 Jones Main A-217
Harrison
019-28-3746 Smith North A-201
Rye
A Sample Relational Database
 Instances and Schemas
 Similar to types and variables in programming languages
 Schema – the logical structure of the database
– e.g., the database consists of information about a set of
customers and accounts and the relationship between them
– Analogous to type information of a variable in a program
– Physical schema: database design at the physical level
– Logical schema: database design at the logical level
 …Cont’d
 Instance – the actual content of the database at a particular point
in time
– Analogous to the value of a variable
 Physical Data Independence – the ability to modify the physical
schema without changing the logical schema
– Applications depend on the logical schema

– In general, the interfaces between the various levels and

components should be well defined so that changes in some
parts do not seriously influence others.
 DBMS Architecture
• Many external views
• One conceptual (= logical) schema
• One physical (= internal) schema
– Views describe how users see the data
– Conceptual schema defines logical structure
– Physical schema describes the files and
indexes used
 DBMS Architecture
View 1 View 2 View 3

Mappings

Conceptual Schema

Mapping

Physical Schema

Database
 Database Independence

Linkage to other databases New hardware

New users

New data
Database New storage techniques
user’s view

Change in use Change in technology

New functions
 …Cont’d
• Logical data independence
– change the logical schema without having to change
the
external schemas
• Physical data independence
– change the internal schema without having to
change the
logical schema
Change the mapping, not the schema!
 Database Language and Interface

• Data Definition Language (DDL)

– Commands for setting up the schema of a database
– The process of designing a schema can be complex,
may use a design methodology and/or tool
• Data Manipulation Language (DML)
– Commands to manipulate data in database:
Retrieve, Insert, Delete, Modify
– Also called “query language”
 Classification of Database System

Hierarchical Database Model

• In this model, there is a parent-child relationship. In
this model each entity has only one parent and many
abstract children. There is only one entity in this
model that we call root.
 Hierarchical Database Model

College

Department Infrastructure

Course Teacher Student

 Advantages & Disadvantages
Advantages
• It promotes data sharing.
• There is a parent/child relationship due to which its
concepts are simple
• It provides database security
• It takes one to many relationships
Disadvantages
• It is not flexible
• It does not have data definition and data manipulation
Network Database Model

• In a network model, data is organized into

graphs. And it can have more than one parent
node.
• There is more parent/child relation in it. And in
it some entity can access from multiple path. So
it can be conclude that in this model it is
possible to store and access a data as a network.
 Network Database Model

Store

Customer Manager Salesman

Order Items
 Advantage & Disadvantage
Advantage
• Its concept is as simple as the hierarchical model.
• There is more than one parent/child relationship
• Data can be accessed easily in it
• It provides data integrity
• It contains data definition language (DDL) and data
manipulation language (DML)
Disadvantage
• Its database structure is very complex (difficult) b/c all the
records in it are maintained using pointers
• Changes in its structure require changes in all programs
Relational Database Model

• In this model, data is stored in relations i.e. tables

and each relation has rows and columns. A relational
model is a group of tables in which data and
relationships are specified.
• The data is stored in two dimensional tables, the
tables are also called a relation. And the row of each
table is called a tuple. The tuple represents the entity
and the column of the table represents the attributes.
 Relational database model
Table name Column name

Student
Roll no Name Mobile no

1 Abel +251925251…

2 Robel +25191825…

3 Jemal +25191025…

Attribute/column Table Tuple/row

 Advantage and Disadvantage
Advantage
• It is very flexible, it can easily make any kind of change
• The data is kept in tables, so its concept is very simple
• It provides data integrity. That is, no user can access the database
without the owners permission
Disadvantage
• It requires powerful hardware computers, storage device and
software
• It is very easy to use but when a user stores data in it incorrectly
then it becomes very bad DBMS
• This is a very simple model due to its simplicity some users
create their own database causing the problem of data
inconsistency, data duplication
 E-R MODEL
• The full name of the E-R model is the entity-relationship
model. It is a graphical approach to database design. That
is the database is designed by diagram and visual
representation in it.
• It uses entity/relationship to display real world objects
• In the ER-model, an entity is a real-world object.
• The properties of an entity are called attributes.
• The association between entities is called relationships.
- One to one
- One to many
 Advantage & Disadvantage
• The E-R model is very simple if we know the
relationship between entities and attributes.
• There is no data manipulation
• Its design is of a high level
• This model is presented as a diagram, with which
we can understand easily.
 ER Model

Customer
ID Balance
Customer
Number Balance
Name

Customer
Street City Date

Customer Customer
Account Account
Database Modeling
 Data Modeling Terms
• Entity – a class of real world objects having
common attributes (e.g., sites, variables, methods).
• Attribute – A characteristic or property of an entity
(site name, latitude, longitude)
• Relationship – an association between two or
more entities
• Cardinality – the number of entities on either end
of a relationship (one-to-one, one-to-many, many-
to-many, etc.)

28 of 42
 Data Modeling Exercise
• Consider:
– What is the “entity”?
– What are the “attributes”
of the entity?

29 of 42
 Data Modeling Exercise
• What is the entity?
• What are the attributes?

30 of 42
 Data Modeling Exercise
• What is the entity?
• What are the attributes?

31 of 42
 Data Modeling Exercise
• What are the relationships?

Grows In

Apple Apple Tree Orchard

Grows On

32 of 42
What about the business rules?
 Data Model Requirements
• What is the information/data domain that you
are modeling?
• What are the 20 queries that you want to do?
– e.g., “Give me simultaneous observations of
turbidity and TSS collected during the spring
snowmelt period so I can develop a regression in R.”
• What software do you want (have) to use?
• How do you want to share the data?

33 of 42
 Data Model Design
• Our focus – relational data model
design
• Three stages:
– Conceptual data model
– Logical data model
– Physical data model

34 of 42
 Conceptual Data Model
(The Information Model)
• High-level description of the data domain
• Does not constrain how that description is
mapped to an actual implementation in
software
• There may be many mappings
– Relational database
– Object model
– XML schema, etc.

35 of 42
 Apple/Tree/Orchard Conceptual Model

Grows In

Apple Apple Tree Orchard

Grows On
36 of 42
 Defining Entities and Relationships
• Instead of beginning with this:
Site
1
*
TimeSeries
1
Observations
*

• Sometimes its easier to write statements:

– Many TimeSeries are measured at a Site.
– Each TimeSeries contains one or more DataValues.
• The nouns become entities and the verbs
become relationships.
37 of 42
 Logical Data Model
• Technology independent
• Contains more detail than the Conceptual Data Model
• Considered by many to be just an expanded conceptual
data model
• Defines
– Entities AND their attributes
– Relationships AND cardinality
– Constraints
• Generally completed as a documented Entity
Relationship (ER) Model or diagram

38 of 42
 Example: ODM Logical Data Model ER Diagram

39 of 42
 Entity Relationship Diagram
• Documentation of the structure of the data
• Used to communicate the design
• Serve as the basis for data model
implementation

40 of 42
 Entity Relationship Diagram
(Relation Database Context)

• Entities effectively become tables

• Attributes describe entities and become fields
(columns) in tables
• Relationships link tables on a common attribute
or “key” and become formal constraints (part of
the business rules)

41 of 42
 ER Diagram Entity Notation

Entity Name

Attributes Data Type

42 of 42
Entity
 ER Diagram Relationship Notation
• Multiple notation systems are used
• Each software program is a little different
• Most common is “Crows Foot”
Crows Foot Alternative
0 .. *
1 .. *
1 .. 1
0 .. 1
43 of 42
 Relationship Cardinality and Participation

• Cardinality: maximum number of times an instance in

one entity can be associated with instances in the
related entity
• Participation: minimum number of times an instance
in one entity can be associated with instances in the
related entity

44 of 42
 Cardinality
• Maximum number of times an instance of an entity can
be associated with instances of a related entity
• Can ONLY have values of 1 or many
• Located closest to the entity in Crows Foot notation

45 of 42
 Participation
• Minimum number of times an instance in one entity can be
associated with instances in the related entity
• Indicates whether an instance of an entity MUST participate in
the relationship
• Can ONLY have the values of 0 or 1

46 of 42
 Mapping Cardinality and Participation

Apple Grows_on AppleTree

A1 R1
T1
A2 R2

A3 R3 T2

A4 R4
T3
A5 R5

A6 R6

47 of 42
 Reading Cardinality and Participation

48 of 42
 Relationship Examples

Left to Right: A site has 0 or more time series of data.

Right to Left: A time series is measured at 1 and only 1 site.

Left to Right: A variable has 0 or more time series of data.

Right to Left: A time series can have 1 and only 1 variable.

49 of 42
 Relationship Examples

Left to Right: A TimeSeries has 1 or more Observations.

Right to Left: An Observation belongs to 1 and only 1
TimeSeries.

Left to Right: An Observation has 0 or more Qualifiers.

Right to Left: A Qualifier describes 0 or more Observations.

50 of 42
 Primary and Foreign Keys
• Each row in a table should have an attribute that is a
persistent, unique identifier – the “Primary Key”
• Primary key in “parent” table
• Foreign key in “child” table

51 of 42
 Primary and Foreign Key Example
OrchardID OwnerName Area_acres
1 John Appleseed 5.5 Orchards
2 Daryl Appleseed 15

AppleTreeID Species Size DatePlanted OrchardID

Apple 1 Honeycrisp 5 4/15/2010 1

Trees 2 Honeycrisp 6 4/15/2010 1

3 Honeycrisp 3 4/15/2010 1
AppleID Color Weight AppleTreeID
1 Green 200 2
2 Green 180 2 Apples
3 Green 195 2

52 of 42
 Primary and Foreign Keys
• Usually consist of integer values
• MUST be the same data type in parent and child
tables

53 of 42
 Creating an ER Diagram Using
MySQL Workbench

54 of 42
 Summary
• Data model design is a 3 step process –
conceptual, logical, physical
• Conceptual and logical data models can be
expressed using Entity Relationship (ER)
diagrams
• ER diagrams capture the entities, attributes, and
relationships to model your information domain
• ER diagrams are a powerful way to document the
design of your data model
55 of 42
 Steps in Data Model Design
1. Identify entities
2. Identify relationships among entities
3. Determine the cardinality and participation of
relationships
4. Designate keys / identifiers for entities
5. List attributes of entities
6. Identify constraints and business rules

56 of 42
 Exercise
• Work alone or in groups of 2-3
• Use MySQL Workbench to begin creating an
Entity Relationship diagram
– Identify entities
– Specify attributes
– Create relationships

57 of 42