lecture 02 - db development
TRANSCRIPT
-
7/30/2019 Lecture 02 - DB Development
1/45
2
-
7/30/2019 Lecture 02 - DB Development
2/45
()?
...
*!
*
ISO/IEC 12207:1995Information Technology Software Life Cycle Processes ,
. ,, , .
2
http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81http://ru.wikipedia.org/wiki/%D0%94%D0%B5%D1%8F%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8Chttp://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B4%D0%B0%D1%87%D0%B0http://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B4%D0%B0%D1%87%D0%B0http://ru.wikipedia.org/wiki/%D0%94%D0%B5%D1%8F%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8Chttp://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81 -
7/30/2019 Lecture 02 - DB Development
3/45
-
7/30/2019 Lecture 02 - DB Development
4/45
4
-...
-
7/30/2019 Lecture 02 - DB Development
5/45
5
-...
-
7/30/2019 Lecture 02 - DB Development
6/45
6
...
-
7/30/2019 Lecture 02 - DB Development
7/45
7
Puzzle
... ...
-
7/30/2019 Lecture 02 - DB Development
8/45
8
?
:
.
.
.
.
.
-
7/30/2019 Lecture 02 - DB Development
9/45
9
-
:
;
.
-
7/30/2019 Lecture 02 - DB Development
10/45
-
7/30/2019 Lecture 02 - DB Development
11/45
Levels of Abstraction
Views describe howusers see the data.
Conceptual schemadefines logicalstructure
Physical schemadescribes the filesand indexes used.
(sometimes called the
ANSI/SPARC model)
Physical Schema
Conceptual Schema
View 1 View 2 View 3
DB
Users
-
7/30/2019 Lecture 02 - DB Development
12/45
Example: University Database
Conceptual schema:
Students(sid: string, name: string,login: string, age: integer, gpa:real)
Courses(cid: string, cname:string,
credits:integer) Enrolled(sid:string, cid:string,
grade:string)
External Schema (View):
Course_info(cid:string,
enrollment:integer)
Physical schema:
Relations stored as unordered files.
Index on first column of Students.
Physical Schema
Conceptual Schema
View 1 View 2 View 3
DB
-
7/30/2019 Lecture 02 - DB Development
13/45
Data Independence
Applications insulated fromhow data is structured andstored.
Logical data independence:Protection from changes in
logicalstructure of data.
Physical dataindependence: Protectionfrom changes inphysical
structure of data.
Q: Why are theseparticularly important forDBMS?
Physical Schema
Conceptual Schema
View 1 View 2 View 3
DB
-
7/30/2019 Lecture 02 - DB Development
14/45
Entity-Relationship Model
" - " " - ", ER -
.
(entity-relationship diagram), - .
(entity set).
- , -
-
7/30/2019 Lecture 02 - DB Development
15/45
15
-
7/30/2019 Lecture 02 - DB Development
16/45
16
Database design lifecycle
Requirements analysis
User needs; what must database do?
Conceptual design
High-level description; often using E/R model
Logical design
Translate E/R model into (typically) relational schema
Schema refinement
Check schema for redundancies and anomalies
Physical design/tuning
Consider typical workloads, and further optimise
Today
-
7/30/2019 Lecture 02 - DB Development
17/45
17
Todays lecture
E/R modelling
Entities
Attributes
Relationships Constraints on relationships
Extended E/R modelling
Object ideas
-
7/30/2019 Lecture 02 - DB Development
18/45
-
7/30/2019 Lecture 02 - DB Development
19/45
19
E/R basics
An entity is a real-world object that isdistinguishable from other objects
Each entity has attributes (with domains)
A particular entity will have a value for each of itsattributes
An entity type defines a set of entities that havethe same attributes
An entity set is the collection of all entities of aparticular entity type (at a particular point intime)
-
7/30/2019 Lecture 02 - DB Development
20/45
20
Entities and attributes
Entity types are drawn as rectangles, e.g.
Attributes are drawn as ovals, andattached to the entity sets with lines, e.g.
Employees
NI dob
Name
Employees
-
7/30/2019 Lecture 02 - DB Development
21/45
ER Diagrams - Symbols
-
7/30/2019 Lecture 02 - DB Development
22/45
Summary of Symbols
-
7/30/2019 Lecture 02 - DB Development
23/45
23
Key attributes
A key attribute of an entity type is anattribute whose values are distinct foreach entity
Sometimes several attributes (a compositeattribute) together form a key
NB: Such a composite should be minimal
We underline key attributes
NI dobName
Employees
-
7/30/2019 Lecture 02 - DB Development
24/45
24
Relationships
A relationship type among two or moreentity types defines a set of associationsbetween entities from those types
Mathematically, relationship type RR E1 En.
The set of instances of the relationshiptype is called the relationship set
-
7/30/2019 Lecture 02 - DB Development
25/45
25
Relationships in E/R
Relationship types are represented bydiamonds
They connect the participating entity types
with straight lines, e.g.
Works_in
NI dobName
Employees
DID budgetdname
Departments
-
7/30/2019 Lecture 02 - DB Development
26/45
26
Relationship set diagrams
Sometimes its useful to represent therelationship set diagrammatically
e1
e2e3
e4
e5
d1
d2
d3
d4
d5
r1
r2
r3
r4
-
7/30/2019 Lecture 02 - DB Development
27/45
27
Relationship attributes
Relationships can also have attributes
NB: A relationship must be uniquelydetermined by the entities, without referenceto the relationship attributes
Works_in
NI dobName
Employees
DID budgetdname
Departments
since
-
7/30/2019 Lecture 02 - DB Development
28/45
28
N-ary relationships
Although relatively rare, we can have n-ary relationships, e.g.
Works_in2
NI dob
Name
Employees
DID budget
dname
Department
since
Locationsaddress capacity
-
7/30/2019 Lecture 02 - DB Development
29/45
29
Recursive relationships
Each entity type in a relationship plays aparticular role, which is associated with a rolename (this is usually suppressed)
An recursive relationship is when an entity
type plays more than one role in the relationshiptype
In this case the role name is required
-
7/30/2019 Lecture 02 - DB Development
30/45
30
Recursive relationships in E/R
e.g.
Employees
Reports-to
NI
namedob
subordinatesupervisor
-
7/30/2019 Lecture 02 - DB Development
31/45
31
Constraints on relationship types
For example: An employee can work in many departments;
a department can have many employees
In contrast, each department has at most one
manager
Thus we need to be able to specify thenumber of relationship instances that anentity can participate in.
For binary relationships the possible ratiosare: 1:1, 1:N, N:1, M:N
-
7/30/2019 Lecture 02 - DB Development
32/45
32
Cardinality ratios1:1 1:N
M:N
-
7/30/2019 Lecture 02 - DB Development
33/45
33
Cardinality ratios in E/R
M:N
N:1
1:1
M N
N 1
1 1
Note: Sometimes this is written using different arrowheads
-
7/30/2019 Lecture 02 - DB Development
34/45
Types of Binary Relationships
Representation of Many-One
Many-many
Many-one E/R: arrow pointing to one.
One-oneMany-one
-
7/30/2019 Lecture 02 - DB Development
35/45
35
Participation constraints
Every department must have a manager
This is an example of a participation
constraint The participation of an entity set, E, in a
relationship set R is said to be totalif
every entity in E participates in at leastone relationship in R. (If not itsparticipation is said to be partial)
-
7/30/2019 Lecture 02 - DB Development
36/45
36
Participation in E/R diagrams
Total participation is displayed as a boldline between the entity type and therelationship
NB. Sometimes this is written as a double line
Manages
NI dobName
Employees
DID budgetdname
Department
since
1 N
-
7/30/2019 Lecture 02 - DB Development
37/45
37
Weak entity types
An entity type may not have sufficientattributes to form a primary key
Such an entity type is called a weak
entity type A weak entity can only be identified
uniquely by considering the primary key ofanother (owner) entity
-
7/30/2019 Lecture 02 - DB Development
38/45
38
Weak entity types cont.
Thus the owner and weak entity typesmust participate in a 1:N relationship
Weak entity set must have total
participation in this identifyingrelationship set.
Employees
NIName
Policy Dependents
CostpName age
1 N
-
7/30/2019 Lecture 02 - DB Development
39/45
39
Extended E/R modelling
What weve seen so far is classic E/R
Over the years a number of features havebeen added to the model and the
modelling process These features include:
Sub- and super-
classes Specialisation
Generalisation
Categories
Higher/Lower-level
entity sets Attributeinheritance
Aggregation
-
7/30/2019 Lecture 02 - DB Development
40/45
40
ISA hierarchies
We can devise hierarchies for our entitytypes
If we declare
A ISA B, everyA entity isconsidered tobe a B entity
Employees
ISA
Temp_Emp Contract_Emp
hoursrate cid
NI Name dob
-
7/30/2019 Lecture 02 - DB Development
41/45
41
Attribute inheritance
As wed expect, attributes of superclassesare inherited by the subclasses.
Thus: Temp_Emp also has attributes NI,
Name and dob
In fact, subclasses inherit relationships too
-
7/30/2019 Lecture 02 - DB Development
42/45
42
Aggregation
Suppose we have an entity set ofProjectsand that each project is sponsored by oneor more departments; thus
Sponsors DepartmentsProjects
PID
start
budget
since
budgetDID
dname
NM
-
7/30/2019 Lecture 02 - DB Development
43/45
43
Aggregation cont.
Suppose that employees are assigned tomonitor a sponsorship
Monitors should be a relationship between
Employees and the Sponsorsrelationship Aggregation allows us to indicate that a
relationship set participates in anotherrelationship set
Use dashed box
-
7/30/2019 Lecture 02 - DB Development
44/45
44
Aggregation cont.
Sponsors DepartmentsProjects
PID
startbudget
since
budgetDID
dname
Employees
nameNI
Monitors until
N M
A Data Model from the
-
7/30/2019 Lecture 02 - DB Development
45/45
45
A Data Model from theEuropean Bioinformatics Institute (EBI)
See http://intact.sourceforge.net/uml/intactCore.gif