* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project
Download Logical Data Modelling
Survey
Document related concepts
Transcript
Database Systems
Logical Data Modelling
Tutor:
Tel:
E-mail:
Web:
Ian Perry
01723 35 7287
I.P.Perry@hull.ac.uk
http://itsy.co.uk/units/dbs0204/
Remember the ‘Stack’
Conceptual Overview of things
Logical
Physical
Ian Perry
that are perceived to
be of ‘interest’ in the
‘real’ world.
Data elements & the
relationships between
those elements in a
tabular form.
Actual data held in a
database & the
means to manipulate
that data.
Model of the
Business System.
(ER Model)
Model of Data
Storage Theory
(Db Schema)
Physical
Implementation
(RDBMS)
Slide 2
What is a Logical Data Model?
• A ‘robust’ representation of the initial
decisions made when building our Conceptual
Data Model, which was composed of:
– Entities
– Attributes
– Relationships
• When I say ‘robust’ I mean that this model
MUST ‘perform’ well with respect to a specific
style/type of software.
Ian Perry
Slide 3
Database Theories & Software
• Hardware independent, the match to ‘type’ of
software is our only concern here, e.g.:
– hierarchy
– relations
– objects
Hierarchical DBMS
Relational DBMS
Object-based DBMS
• Each Database Theory addresses:
– Data Structure
– Data Integrity
– Data Manipulation
Ian Perry
Slide 4
Database Theory = Relational Model
• First proposed by Dr. E. F. Codd in June 1970.
– Codd E F, (1970), A Relational Model of Data for Large Shared Data
Banks, Communications of the ACM, Vol. 13, No. 6, Pgs 377 – 387.
• Codd's model is now accepted as the definitive model for
relational database management systems (RDBMS).
• Structured English Query Language ("SEQUEL") was
developed by IBM Corporation, Inc., to use Codd's model.
– SEQUEL later became SQL.
• In 1979, Relational Software, Inc. (now Oracle Corporation)
introduced the first commercial implementation of SQL.
– SQL is the most widely used RDBMS manipulation language.
Ian Perry
Slide 5
Relational Modelling Language
Schema
set of relations
Relation
tablular framework
Tuple
horizontal division of relation (row)
Attribute
vertical division of relation (column)
Data Cell
junction of horizonal & vertical
Cardinality Number of tuples in relation
Degree
Ian Perry
Number of attributes in relation
Slide 6
Relations look very like Entities
• Staff (SCode, Name, Address, DoB, DoE)
SCode Name
9491 Smith
7416 Day
Address
DoB
DoE
6 Shaw St 130265 031098
2 Sale St 140157 031192
• Contract (CCode, Site, Begin, End, Super)
CCode Site
279
Hull
665
York
Ian Perry
Begin
270699
140901
End
030702
020203
Super
9491
7416
Slide 7
Attributes
• Attribute Values are held in Data Cells:
– must be atomic (i.e. simple) values only.
• Set of Attribute Values eligible for entry in a
Data Cell:
– is known as an Attribute’s Domain.
• The Relational Model is weak at explicitly
modelling relationships:
– Relations must share an Attribute Domain if a
relationship is present/possible.
Ian Perry
Slide 8
Data Access
• Data is retrieved by reference to name (of an
Attribute) & value (held in a Data Cell) only.
• Most important Attribute(s) is know as the
‘Key’, of which there are two types.
– Primary Key:
• special Attribute(s) used to control access to Tuples (i.e.
rows) of data.
– Foreign Key:
• used, as logical pointers, instead of lines to represent
associations between Relations.
Ian Perry
Slide 9
Relations are NOT Tables
• Tables are just data items presented in rows &
columns.
– Relations must obey rules (Codd’s 12 Rules).
• For example, we cannot have:
– Duplicates:
• each Tuple (row) must be unique.
– Row or Column dependencies
• there is no hidden meaning from location/sequence of
Tuples (rows) and/or Attributes (columns).
– etc.
Ian Perry
Slide 10
Keys to Data Integrity
• Rule:
– each Tuple (i.e. row) must be unique (for all time).
• Need a way to discriminate between Tuples:
– so, each Relation must have Primary Key:
• There may be many Candidates for the job of
Primary Key, so select on basis of:
– uniqueness AND/OR minimality
• Keys with more than one Attribute:
– are know as composite keys.
Ian Perry
Slide 11
Other things about Attributes
• Attributes that are part of the Primary Key
are known as Prime Attributes.
• Attributes not selected as part of the Primary
Key are known as Secondary Keys.
• Secondary Key Attributes which serve as the
Primary Key in another Relation are known
as Foreign Keys.
Ian Perry
Slide 12
Rules for Integrity
• Entity Integrity:
– No Attribute that is a member of a Primary Key
can assume a ‘null’ value.
• Else, how could we discriminate between Tuples?
• Referential Integrity:
– Foreign Key Attributes must take values that are
either ‘null’, or from same Domain as the Relation
in which Attribute(s) acts as Primary Key.
• Else, we will lose linkages between Relations.
Ian Perry
Slide 13
In Summary
• Logical Data Modelling:
– is all about translating our Conceptual Data Model so that it
might be implemented using software that matches a
specific Database Theory.
• Relational Database Theory, Codd (1970):
– allows us to develop mathematically rigorous abstract data
models, composed of a number of distinct Relations.
• Tables are NOT Relations:
– simply the way we choose to mentally give flesh to our
Logical Data Model,
Ian Perry
Slide 14
And
• Relations?
– defined by a list of Attributes.
– relationships via Primary/Foreign Key mechanism.
• Attributes?
– must be distinctly named.
– ordering is irrelevant.
– data entries:
• should be atomic, of the same type, from the same domain.
• Tuples?
– must be unique (so need a Key).
– ordering is irrelevant.
Ian Perry
Slide 15
So
• Staff (SCode, Name, Address, DoB, DoE)
SCode Name
9491 Smith
7416 Day
Address
DoB
DoE
6 Shaw St 130265 031098
2 Sale St 140157 031192
• Contract (CCode, Site, Begin, End, Super)
CCode Site
279
Hull
665
York
Ian Perry
Begin
270699
140901
End
030702
020203
Super
9491
7416
Slide 16
And Finally!
• I know what you are thinking:
– the Relation Definitions of a Logical Data Model
looks to be exactly the same as the Entity
Definitions of a Conceptual Data Model.
• However:
– it is highly unlikely that your Logical Data Model
will be exactly the same as your Conceptual Data
Model.
• You will have made some logical errors!
Ian Perry
Slide 17