Transcript Detailed Data Modelling

IMS1907
Database Systems
Week 7
Data Modelling
Relational Database Theory
Monash University 2004
1
Detailed Data Modelling
The objective of detailed data modelling is to develop data
structures that
- have stability, minimum redundancy, and are flexible to
allow for future change
- can be used as the basis for physical file and
database design
- reflect the actual data requirements of the system
Monash University 2004
2
Detailed Data Modelling
To expand the conceptual data model we need to identify
and describe
– the details of the entities and relationships
– attributes (data elements) of entities and relationships
An organisation-wide perspective should be adopted to
ensure minimum redundancy and inconsistency and to
facilitate data sharing
Monash University 2004
3
Detailed Data Modelling
Techniques
- attribute collection
- convert ER models to relations
- normalisation
- convert to data structure diagram (DSD)
Monash University 2004
4
Detailed Data Modelling
At this stage our ER models are logical
– independent of implementation technology
We shall consider converting our ER models using the
relational data model because
– it is the most commonly used in DBMS applications
– some principles of logical database design for the
relational model apply to other logical models
– high level of CASE tool support
Monash University 2004
5
Relational Data Model
Introduced by E.F. Codd in 1970
Represents data in the form of tables
Based on mathematical theory
– solid theoretical foundation
Three components are considered
– data structure
– data manipulation
– data integrity
Monash University 2004
6
Relational Data Model
Data structure
– the relational database model represents data in the
form of tables or relations
Important concepts are
- relation
- primary key
- composite key
- foreign key
Monash University 2004
7
Relations
A relation is a named, two-dimensional table of data
Each relation consists of a set of named columns and an
arbitrary number of unnamed rows
Each column corresponds to an attribute of the relation
Each row corresponds to an instance (or record) that
contains values for an instance of that entity
Monash University 2004
8
Relations
A relation generally corresponds to some real world object
or concept of interest to the system -similar to an entity
Employee
Emp#
Name
Salary
Dept
1247
Adams
24000
Finance
1982
Smith
27000
MIS
9314
Jones
33000
Finance
Employee (Emp#, Name, Salary, Dept)
Monash University 2004
9
Properties of Relations
Relational tables are tables in which
- each relation has a unique name
- each attribute or column has a unique name
- data values are atomic and single-valued
- data values in columns are from the same domain
- each row in the relation is unique
- the sequence of columns is insignificant
- the sequence of rows is insignificant
Monash University 2004
10
Primary Key
An attribute or group of attributes which uniquely identifies
a row of a relation
A search criteria that would yield only one record
Entity integrity (relational data base theory) requires that
each relation has a non-null primary key
Represented by underlining the key element
– Employee (Emp#, Name, Salary, Dept)
Can be a composite key
– Order-item (Order#, Item#, Qty-ordered)
Monash University 2004
11
Primary Key
Candidate keys
– where several possible keys are identified, each of
which uniquely identifies the other attributes, they are
known as candidate keys - choose one to be the
primary key
– choose the most stable key or the key over which there
is the most control
– treat the remaining candidates as non-key attributes
• we can deal with them later if they give us trouble!
Monash University 2004
12
Foreign Key
A foreign key is an attribute in one relation that is also a
primary key in another relation in the same database
– it may be a composite key
– allows user to see records in one relation associated
with a record in another elation
The referential integrity constraint (relational database
theory) specifies that if an attribute value exists in one
relation then it must also exist in a linked relation
A foreign key must satisfy referential integrity
Monash University 2004
13
Foreign Key
In the example below, if a given Dept# exists in an
Employee relation then that Dept# must exist in the
Department relation
Employee (Emp#, Name, Salary, Dept#)
foreign key
Department (Dept#, Dname, Budget)
Monash University 2004
14
Integrity Constraints
The relational model has several constraints or rules that
facilitate the maintenance of the accuracy and integrity of
data in the database
– domain constraints
– entity integrity
– referential integrity
Monash University 2004
15
Integrity Constraints
Domain constraints
– all values appearing in a column of a relation must
come from the same domain of values
Domain definitions consist of
– domain name
– meaning
– data type
– size or length
– allowable values or range of values
Monash University 2004
16
Integrity Constraints
Entity integrity
– no primary key attribute or component of primary key
attribute can be null
– ensures every relation has a primary key and all data
values for that key are valid
Null value
– allowable when value is unknown or is not applicable
– not a value or a zero, rather the absence of a value
– inclusion in relational model is controversial – can lead
to anomalies
Monash University 2004
17
Integrity Constraints
Referential integrity
– each foreign key value must match a primary key value
in another relation, or the foreign key value must be null
– associations between tables are defined using foreign
keys
– maintains consistency between rows in two relations
– ensures every foreign key does correspond to an
existing primary key in another relation else the foreign
key is null
Monash University 2004
18
Well-Structured Relations
A well-structured relation
– is robust, stable and flexible
– contains a minimum amount of redundancy
– allows users to insert, modify, and delete rows in a table
without errors or inconsistencies
• known as “anomalies”
Monash University 2004
19
Well-Structured Relations
Three types of anomaly are possible
- insertion
- deletion
- modification
Relations that have been normalised to third normal form
(3NF) are considered to be well structured relations
– although even 3NF relations can have anomalies
Monash University 2004
20
Well-Structured Relations
Insertion anomaly
– cannot create a new record without supplying data
values for for two independent data elements
Deletion anomaly
– cannot delete a record without losing related data in that
record that might need to exist independently
Modification anomaly
– must sometimes update a data value in many records to
ensure consistency
Monash University 2004
21
A Poorly-Structured Relation
Can’t add new employee till completed course
Delete emp no 150 and lose Delphi
Name changes need to be made in more than one record
Emp_ID
Emp_Name
Course
Date_Comp
100
Jim
VB .Net
2/4/03
100
Jim
C++
6/8/03
140
Jane
C++
12/10/02
110
Wendy
Java
30/6/03
110
Wendy
VB .Net
2/4/03
150
Robert
Delphi
1/5/04
Monash University 2004
22
References
Hoffer, J.A., Prescott, M.B. and McFadden, F.R., (2005),
Modern Database Management, (7th edn.), Pearson
Education Inc., Upper Saddle River, NJ, USA.
Ch. 5
Monash University 2004
23