Databases and Information Systems Code 11548, ECTS: 6 credits

Transcripción

Databases and Information Systems
UNIT 1: Relational Databases
Departament de Sistemes Informàtics i Computació (DSIC)
Escola Tècnica Superior d’Enginyeria Informàtica (ETSINF)
Universitat Politècnica de València (UPV)
Contents
Unit 1. Relational Databases
1.1. Fundamentals
1.2. The Relational Data Model
1.3. Interpretation of a Relational Database
Unit 2. SQL
2.1. DML: Queries and Data Modification
2.2. SQL Exercises (LAB)
2.3. DDL: Data Definition
6 Lectures: 9 hours
7 Lectures: 10.5 hours
7 Lab sessions: 10.5 hours
Unit 3. Relational Database Design
3.1. Design Basics: Stages and Schemas
3.2. Conceptual Design
3.3. Logical Design
3.4. Exercises on Conceptual and Logical Design (LAB)
14 Lectures: 21 hours
Unit 4. Database Management Systems
4.1. ANSI/SPARC Architecture
4.2. Transactions, Integrity and Concurrency
4.3. Recovery and Security
4.4. Evolution of the Relational Model
2
Total: 30 Lectures: 45 hours
10 Lab sessions: 15 hours
Databases and Information Systems - DSIC – ETSINF - UPV
1.1. Fundamentals
Information and processing
Computer science (information processing): a
duality between processing and information.


They do not make sense alone!
Processing perspective:


Programming, algorithmics, etc., deal with
processing.
Information perspective:


3
Data representation, knowledge, data access, data
storage, etc.
1.1. Fundamentals
Representing information
Data, information and knowledge are collected
from and represent a parcel of the world.
Information can be seen as a representation of
reality: facts, events, etc.


Reality
Coding / Design / Modelling
Representation
of Reality
Information
Decoding / Interpretation
Reality can be represented in many ways:


4
With letters, numbers, images, sounds, etc.
1.1. Fundamentals
Representing information
We need to consider both syntax and semantics.


Information/data coding mostly focusses on syntax:


File formats: ASCII, MIME, UTF-8, HTML, MP3, AVI, JPG, etc.
Information/data modelling mostly focusses on semantics:

Modelling, Ontologies, Knowledge, etc. (conceptual models,
logical models, RDF, UML, XML, JSON, SOAP, …)
Representation is different depending on the
purpose:



5
Data access (storage, query and modification):
database perspective (e.g., this subject).
Communication (information exchange): networks,
application communication, protocols (e.g., TSIR, 3A)
1.1. Fundamentals
Reality vs. models of reality
Why do we work with a model of reality if we could
work with the reality itself?



Would you calculate the area of this building by
physically stepping throughout the entire building, or just
using a plan (a model) of the building?
Would you reckon the number of students in this university
by physically gathering all of them at the same time, or
just using any recording system?
Many things cannot be (actually or practically)
done with reality.



6
We try to accurately represent the world through
language, knowledge, science, etc.
We use this representation to serve our purposes.
1.1. Fundamentals
Information system
An information system (IS) is a collection of elements,
which are orderly related to each other following
some rules, that provide the entity they serve with the
necessary information for the completion of its goals.
Basic functionalities of an IS:
 Data Gathering.
 Data Processing.
 Data Storage.
 Data Elaboration and Presentation.

7
1.1. Fundamentals
Database
A database is a collection of structured data
8
1.1. Fundamentals
Database management system
A database management system is a
software tool (collection of programs) that
enables users to create, manipulate and
maintain a database.
9
1.1. Fundamentals
Data model

The way in which reality (entities, relationships, etc.) is
represented in the context of databases (data structures,
constraints, etc.) is known as a data modelling system or simply
a “data model”.

Many different data models have been proposed:
 Hierarchical, network, relational, object-oriented, multidimensional, etc.
 We then talk about hierarchical databases, relational
databases, multi-dimensional databases, etc.

A DBMS assumes one data model and builds everything upon it.
 A Relational DBMS (RDBMS) is a DBMS which is based on the
relational model.
10
1.1. Fundamentals
Database characteristics

Current DBs are characterised by:







11
Integrating all the organisation’s information.
Data Persistence.
Shared accessibility to several users (or applications).
Unified data description, independent of the
applications.
Independence between the applications and
physical data representation.
Description of partial views of the data for different
users.
Mechanisms to ensure data integrity and security.
1.1. Fundamentals
Database characteristics

DBs pursue a general goal:


Global integration of the system’s information in
order to avoid redundancies, with no loss of the
different database perspectives by users.
Additionally, the software tools (DBMSs),
specifically designed to apply these techniques,
must ensure data independence, integrity and
security.
12
1.1. Fundamentals
Example

Information System of a University

The goal is to handle the daily procedures and
administrative tasks in a university.

Originally:


13
We have different perspectives: school administration,
department, students, lecturers.
Keeping these perspectives in a separate way involves
redundancy.
1.1. Fundamentals
Example
Administration’s Perspective
Courses
Computer Science Degree (ITIG)
Term
1A
1B
14
Subject
Code
Dep.
Lect.
Lab
Algoritmos y estructuras de datos I
AD1
DSIC
3
3
Análisis matemático I
AM1
DMA
3
3
Fundamentos de computadores
FCO
DISCA
4.5
4.5
Introducción a la programación
IP
DSIC
1.5
1.5
Matemática discreta
MAD
DMA
3
3
Algoritmos y estructuras de datos II
AD2
DSIC
3
3
----------
----
----
----
----
1.1. Fundamentals
Example
Lecturers
Departament
Code
DSIC
LBP
Bos Pérez, Luis
3545
JCP
Cerdá Pérez, Juan
3222
PMG
Martí García, Pedro
3412
MRC
Ruiz Cantó, María
3675
DISCA
-----
15
Name
Tel.
------
----------
-------
------
----------
------
1.1. Fundamentals
Example
Teaching
Term
1ª
Courses
AD1
IP
1B
16
Lec.
Lab.
Groups
Groups
2
4
2
4
Lecturers
Credits
Cerdá Perez, Juan
9
9
Bos Pérez, Luis
9
Cerdá Perez, Juan
9
AM1
----
----
----
----
AD2
----
---
----
----
1.1. Fundamentals
Example
Department’s Perspective
Lecturers
Code
17
Name
Address
Category
Tel
LBP
Bos Pérez, Luis
Jesús 91
TEU
3545
JCP
Cerdá Pérez, Juan
Olta 23
TEU
3222
PMG
Cuenca 12
TEU
3412
------
----------
------
------
-------
1.1. Fundamentals
Example
Appointed courses
Degree School
ITIG
E.I.
Term
1A
Course
Algoritmos y estructuras de datos I
Introducción a la programación
----
18
-----
Code
Lec
Lab
AD1
3
3
IP
1.5
1.5
1B
Algoritmos y estructuras de datos II
AD2
3
3
----
---------------------
----
----
----
1.1. Fundamentals
Example
Teaching arrangement by subject
Term
A
Degree School
ITIG
E.I.
Course
AD1
IP
---B
19
ITIG
E.I.
LecG LabG
2
2
4
4
Lecturers
Credits
Cerdá Perez, Juan
9
9
Bos Pérez, Luis
9
Cerdá Perez, Juan
9
----
-----
-----
---------
AD2
----
----
---------
----
----
----
---------
1.1. Fundamentals
Example
Teaching arrangement by lecturer
Lecturer
Bos Pérez, Luis
Cerdá Pérez, Juan
Martí García,Pedro
---
20
Term
Subject
Degree
School
Credits
IP
ITIG
E.I.
A
9
AD1
ITIG
E.I.
A
9
IP
ITIG
E.I.
A
9
AD1
ITIG
E.I.
A
9
---
---
---
---
1.1. Fundamentals
Example
Lecturer’s Perspective
Teaching arrangement for José Hernández Orallo
21
Course
School
Year
Term
Credits
ABD
E*I
3rd
B
6
AMD
FI
5th
B
3
BDA
E*I
2nd
B
6
Extr. Con.
M.Sc.
-
B
2
1.1. Fundamentals
Example

We have duplicate information.

Is this a problem?



Storage space is not optimised
Higher update cost.
We can have inconsistencies.


22
For instance, in previous slides, the category of the same
teacher differs depending on the view.
We can integrate everything into the same “logical”
schema.
1.1. Fundamentals
Example
LOGICAL SCHEMA
Lecturer
Course
Teaching
School
Degree
Department
23
Code
Name
Code
Name
lecturer_id
Code
Address
Sem
course_id
Name
Tel
Lec
Category
Lab
LecG
credits
Head
Tel
Code
Name
School
Code
Name
Head
Tel
Dep
LabG
Degree
Dep
1.1. Fundamentals
Example
RELATIONAL DATABASE
Department Relation
Code
DSIC
24
Name
Sistemas Informáticos y Computación
Head
Tel
Juan García
3570
DFA
Física Aplicada
José Ruíz
3540
----
-----
-----
-----
1.1. Fundamentals
Example
RELATIONAL DATABASE
Degree Relation
Name
Code
ITIG
Ingeniero Técnico en Informática de Gestión
E.I.
ITIS
Ingeniero Técnico en Informática de Sistemas
E.I.
Ingeniero Informático
FI
II
----
25
School
-----
-----
1.1. Fundamentals
Example
RELATIONAL DATABASE
School Relation
Code
E.I.
Escuela Universitaria de Informática
FI
Facultad de Informática
----
26
Name
-----
Head
Tel
Pedro Ruiz
3578
José Esteban
3776
-----
-----
1.1. Fundamentals
Example
RELATIONAL DATABASE
Lecturer Relation
Code
Name
Address
Tel
Category
Dep
JCP
Juan Cerdá Pérez
Olta 23
3222
TEU
DSIC
LBP
Luis Bos Pérez
Jesús 91
3545
TU
DSIC
PMG
Pedro Martí García
Cuenca 12
3412
CU
DSIC
----
27
--------
------
-----
-----
------
1.1. Fundamentals
Example
RELATIONAL DATABASE
Course Relation
Code
Name
Sem
Lec
AD1
Algoritmos y estructuras
de datos I
1A
3
3
2
4
ITIG
DSIC
Introducción a la
programación
1A
1.5
1.5
2
4
ITIG
DSIC
AD2
Algoritmos y estructuras
de datos II
1B
3
3
--
--
ITIG
DSIC
-----
--------
---
---
---
--
--
---
---
IP
28
Lab LecG LabG Degree
Dep
1.1. Fundamentals
Example
RELATIONAL DATABASE
Teaching Relation
29
lecturer_id
course_id
credits
JCP
AD1
9
JCP
IP
9
LBP
IP
9
PMG
AD1
9
---
---
---
1.1. Fundamentals
Example

Ok, redundancy has been eliminated.

What about the partial views of the data by the
different users?

Solution in database technology:

30
Use of external schemas (views)
1.1. Fundamentals
Example
Logical Schema
External Schema for DSIC
Lecturer
Lecturers from DSIC
Code
Name
Address
Tel
Category
Dep
…
…
…
…
…
…
SELECT rows WHERE
Dep = ‘DSIC’
Course
Code
…
Code
Name
Address
Tel
Cat
…
…
…
…
…
Courses from DSIC
Name
Sem
…
…
Lec
Lab
…
…
LecG
…
LabG
…
Degree
…
Dep
Code
Name
Sem
Lec
Lab
LecG
LabG
Degree
…
…
…
…
…
…
…
…
…
SELECT rows WHERE
Dep = ‘DSIC’
Teaching
Teaching from DSIC
lecturer_id
course_id
credits
…
…
…
SELECT rows in teaching which
correspond to courses assigned to DSIC
lecturer_id
course_id
credits
…
…
…
Course
Code
Name
Sem
Lec
Lab
LecG
LabG
Degree
Dep
…
…
…
…
…
…
…
…
…
Degree
Degrees from DSIC
Code
Name
School
Code
Name
School
…
…
…
…
…
…
31
The whole relation is included
1.1. Fundamentals
Example

How is everything implemented by the DBMS?

The DBMS usually implements a three-level
architecture:



32
External level (corresponding to the external schemas)
Logical level (corresponding to the logical schema)
Physical (or internal) level (corresponding to the physical
schema)
1.1. Fundamentals
Example
Index for Degree
PHYSICAL SCHEMA
ITIG
<, , >
-----
Index for
Course
AD1

AD2

IP

-----
33
Course File
AD1 Algoritmos y estructuras
de datos I
IP
Introducción a la
programación
1A 3
3
2 4 ITIG DSIC
1A 1.5 1.5 2 4 ITIG DSIC
AD2 Algoritmos y estructuras
de datos II
1B 3
-----
--- --- --- -- --
--------
3 -- -- ITIG DSIC
---
---
1.1. Fundamentals
There-Level DBMS Architecture
The DBMS ensures bottom-up independence for these three levels
users and applications
External
Schema 1
External
Schema 2
…
DBMS
External
Schema n
External-logical
correspondence
Logical Independence
Logical
Schema
Logical-physical
correspondence
Physical Independence
Physical
Schema
operating system, hardware, …
This three-level architecture will be seen in more depth in unit 4.
 In what follows (units 2 and 3), we will focus on the logical level.
34
Contents
1.1. Fundamentals
Unit 2. SQL
6 Lectures: 9 hours
3.3. Logical Design
35
A little bit of history…


Historical milestones about the Relational Data
Model (RDM):

70’s: Proposed by E. Codd in 1970

80’s: Becomes popular in practice (Oracle, ...).
ANSI defines the SQL standard.

90’s: Generalisation and standardisation
(SQL’92) and extensions.
Reasons of success:

36
Simplicity: a database is a “set of tables”.
Informal view of a relational database
Department:
code
name
telephone
head of the department
Lecturer:
code
name
telephone
department which the lecturer belongs to
Subject:
code
name
semester in which is offered
lecture credits
lab credits
department which is responsible for its teaching
37
Department
DSIC
DISCA
MAT
FIS
IDM
EIO
OEM
Sistemas Informáticos y Computación
Ingeniería de Sistemas, Computadores y Automática
Matemática Aplicada
Física Aplicada
Idiomas
Estadística e Investigación Operativa
Org. de Empresas, Economía Financ. y Contabilidad
V. Botti
A. Crespo
P. Pérez
J. Linares
B. Monter
L. Barceló
M. Pérez
3500
5700
6600
5200
5300
4900
6800
Row (Tuple) = department instances
Column (Attribute) = property  with a name and an associated type
DEPARTMENT(dep_code:string(5), dep_name:string(40),
head:string(30), telephone:integer)
38
Subject
BDA
AD1
FCO
MAD
INT
FFI
EC2
Bases de Datos
Algoritmos y Estructuras de Datos 1
Fundamentos de Computadores
Matemática Discreta
Inglés Técnico
Fundamentos Físicos de la Informática
Estructuras de Computadores 2
2B
1A
1A
1A
1B
1A
2A
3
4
4,5
3
3
3
3
3
2
4,5
3
3
3
3
Which department is in charge of teaching each subject?
We have to add an extra attribute to the tuples of the relation
SUBJECT, which represents this information.
Which attribute?
39
Subject
BDA
AD1
FCO
MAD
INT
FFI
EC2
Bases de Datos
Fundamentos de Computadores
Inglés Técnico
2B
1A
1A
1A
1B
1A
2A
3
4
4,5
3
3
3
3
3
2
4,5
3
3
3
3
DSIC
DSIC
DISCA
MAT
IDM
FIS
DISCA
SUBJECT(subj_code : string(3), subj_name : string(40), semester :
string(2), theory : real, lab : real, subj_dep : string(5))
subj_code identifies each subject and subj_dep indicates the
department which it belongs to.
40
SUBJECT
BDA Bases de Datos
AD1 Algoritmos y Estructuras de Datos 1
FCO Fundamentos de computadores
MAD Matemática Discreta
INT Inglés Técnico
FFI Fundamentos Físicos de la
Informática
EC2 Estructuras de Computadores 2
2B
1A
1A
1A
1B
1A
3
4
4,5
3
3
3
2A 3
3
2
4,5
3
3
3
DSIC
DSIC
DISCA
MAT
IDM
FIS
3
DISCA
DEPARTMENT
DSIC Sistemas Informáticos y Computación
DISCA Ingeniería de Sistemas, Computadores
y Automática
MAT Matemática Aplicada
FIS
Física Aplicada
IDM
Idiomas
EIO
Estadística e Investigación Operativa
OEM Org. de empresas, Economía Financ. y
Contabilidad
41
V. Botti
A. Crespo
3500
5700
P. Pérez
J. Linares
B. Montero
L. Barceló
M. Pérez
6600
5200
5300
4900
6800
Lecturer
JCR
RFC
JBD
MAF
CPG
JTM
IGP
DGT
MCG
Juan C. Casamayor Ródenas
Robert Fuster i Capilla
José V. Benlloch Dualde
María Alpuente Frasnedo
Cristina Pérez Guillot
José M. Torralba Martínez
Ignacio Gil Pechuán
Daniel Gil Tomás
Matilde Celma Giménez
7796
6789
5760
7796
7439
4590
3423
5679
7756
DSIC
MAT
DISCA
DSIC
IDM
OEM
OEM
DISCA
DSIC
LECTURER(lect_code : string(3), lect_name : string(40),
extension: integer, lect_dep: string(5) )
42
Resulting relational schema:
1
Department
dep_code
dep_name
1
head
subj_code
telephone
subj_name
lect_code
semester
lect_name
theory
extension
lect_dep
43
N
lab
N
subj_dep

Entities are represented as tables (a.k.a. relations).

Objects (entity instances) correspond to table rows.

Object’s features are represented by attributes.
These attributes correspond to the columns of the
tables, and are also known as fields.

Attributes in the same column must have the same
datatype (domain).
44

There are two kinds of special attributes:

attributes which identify the tuples of a relation:


attributes which associate two relations:

45
dep_code in DEPARTMENT, lect_code in LECTURER and
subj_code in SUBJECT.
subj_dep in SUBJECT which associates it with DEPARTMENT, or
lect_dep in LECTURER which associates it with DEPARTMENT.
Working with relational databases

The ultimate goal of a database is that users and,
especially, applications can:
 Store and modify the information of interest:
Insertion
 Deletion
 Update


Access and retrieve that information:


46
Query
These are the four basic “manipulation” operations
over a database.
Modification operators

INSERT a new lecturer: “CPG, Cristina Pérez, …”
Lecturer
JCR
RFC
JBD
MAF
7796
6789
5760
7796
DSIC
MAT
DISCA
DSIC
Cristina Pérez Guillot
7796
6789
5760
7796
7439
DSIC
MAT
DISCA
DSIC
IDM
Lecturer
JCR
RFC
JBD
MAF
CPG
47

DELETE those lecturers with “extension = 7796”
Lecturer
JCR
RFC
JBD
MAF
7796
6789
5760
7796
DSIC
MAT
DISCA
DSIC
Lecturer
RFC
JBD
48
6789
5760
MAT
DISCA

UPDATE the lecturer with code JBD and set his
extension to “8888”
Lecturer
JCR
RFC
JBD
MAF
7796
6789
5760
7796
DSIC
MAT
DISCA
DSIC
7796
6789
8888
7796
DSIC
MAT
DISCA
DSIC
Lecturer
JCR
RFC
JBD
MAF
49
Queries

What about “querying”?
A relational query is a retrieval operation to a database
which returns part of the information of the database, possibly
combined and/or aggregated, in the form of a single table.

Example of a query:

“Give me the name of all subjects and the head of their
corresponding department”:
Query result:
Bases de Datos
Fundamentos de computadores
Inglés Técnico
50
V. Botti
V. Botti
A. Crespo
P. Pérez
B. Montoro
J. Linares
A. Crespo
Queries

How can we express queries so that the DBMS can
understand and process them automatically?


In natural language?  Still science fiction!
Relational databases can be queried by different
query languages.



51
Relational algebra (operational, based on set and
relational operators)
Relational calculus (declarative, based on logic)
SQL (a standard computer language which integrates
most of the two previous approaches and looks like
natural language).
Set operators
Union: R  S
Difference: R  S
Intersection: R  S
R
R
R
S
S
S
Product: R  S
R
52
a
b
c

x
y
S
=
a
b
c
a
b
c
x
x
x
y
y
y
Relational operators (proper)
Selection
Projection
Join
53
a1
b1
b1
c1
a1
b1
c1
a2
b1
b2
c2
= a2
b1
c1
a3
b2
b3
c3
a3
b2
c2
Logical operators and others

Quantification:


Universal
Existential

Conditions and expressions: AND, OR, NOT

Aggregation: average, maximum, etc.
Grouping: by a condition
Sorting


54
Operators: exercises
EXERCISES!
55
Queries in SQL

SQL combines most of these operators.

E.g., very simple query:

“Give me the name of all subjects and the head of
their corresponding department”:
3. Projection
SELECT subj_name, head
FROM subject, department
1. Cartesian Product
2. Selection
WHERE subj_dep = dep_code;
56
Formal presentation

First of all: terminology, again.
Common Terminology
(computing)
RDM Terminology
(mathematical)
• data types
• domains
• fields / columns
• attributes
• record / row
• tuple
• table
• relation
They are not exactly equivalent
57
Formal presentation: tuple schema
A tuple schema, , is a set of pairs of the form:
 = {(A1, D1), (A2, D2),…, (An, Dn)}
where:
{A1, A2, …, An} (n > 0) is the set of attribute
names in the schema, necessarily different.
D1, D2 …, Dn are the domains associated with
the above-mentioned attributes, which not
necessarily have to be different.
58
Formal presentation: tuple schema
Example of tuple schema:
Person = {(person_id, integer), (name, string), (address, string)}
where:
{ person_id, name, address } is the set of attribute names in the
schema.
integer, string, string are the domains which are associated with
the attributes.
59
Formal presentation: tuple
Tuple:
A tuple, t, of tuple schema  where
 = {(A1, D1), (A2, D2),…, (An, Dn)}
is a set of pairs of the form:
t = {(A1, v1), (A2, v2),…, (An, vn)}
such that i vi  Di.
60
Formal presentation: tuple
Examples of Tuple:
Given the following tuple schema:
Person = {(person_id, integer), (name, string), (address, string)}
We have:

t1 = {(person_id, 2544), (name, “Joan Roig”), (address, “Sueca 15”)}
t2 = {(person_id, “2844F”), (name, “R3PO”), (address, “46022”)}
t3 = { (name, “Pep Blau”), (person_id, 9525), (address, “dunno!”)}
61
Formal presentation: relation
A relation is a set of tuples of the same schema.
Relation schema
A relation schema is the schema of the tuples composing the
relation.
Notation
R(A1: D1, A2: D2,…, An: Dn)
Defines a relation R of schema
{(A1, D1), (A2, D2),…, (An, Dn)}
62

Properties of a relation

Degree of a relation: number of attributes of its
schema

Cardinality of a relation: number of tuples that
compose the relation.

Compatibility: two relations R and S are compatible
if their schemas are identical.
63
Example:
A relation of the PERSON schema might be as follows:
{ { (person_id, 1234), (name, “Pepa Gómez”), (address, “Colón 15”) },
{ (person_id, 2045), (name, “Juan Pérez”), (address, “Cuenca 20”) },
{ (name, “José Abad”), (person_id, 1290), (address, “Blasco Ibáñez 35) },
{ (name, “María Gutiérrez”), (person_id, 35.784.843) (address, “Reina 7”) } }
Degree: 3
Cardinality: 4
Compatible with: any other relation whose schema is:
{(person_id, id_dom), (name, name_dom), (address, add_dom)}
64
Formal presentation: representation of a relation
Representation of a relation  TABLE
• tuples are represented as rows
• attributes give name to the column headers
Example: PERSON relation
Row 
Tuple
65
Column  Attribute
Person_id
Name
Address
2045
Juan Pérez
Cuenca 20
1290
José Abad
Blasco Ibáñez 35
3578
María Gutiérrez
Reina 7
1234
Pepa Gómez
Colón 15
Formal presentation: sets or matrices

The Table is only a Matrix Representation of a
Relation

Traits which distinguish a relation (derived from
the definition of relation as a set of sets):



66
There can’t be repeated tuples in a relation (a
relation is a set).
There isn’t a top-down order in the tuples (a relation
is a set).
There isn’t a left-to-right order in the attributes of a
relation (a tuple is a set). The name of the attribute
must be used to choose.
Formal presentation: extensions and schemas
EXTENSION (data)
SCHEMA
(content)
(definition)
Tuple
Tuple schema = Relation definition
(Extension of a) relation :
set of tuples in a relation
Database:
set of relations
Relational (logical) Schema: set of
relation definitions which
represent an information system
Attention!: DBMSs understand a table as the definition of a relation and
not as its content, which eventually changes by applying operators.
67
Formal presentation: null value
What happens if we don’t know the value
a tuple takes in some of its attributes?

Solution in Programming Languages:
•

use of special or extreme values (-1, “Empty”, “ ”, “We
don’t know”, 0, “No address”, “---”, ...)
Solution in the Relational Model: NULL VALUE (?)

A Domain is something more than a datatype:
A domain is a set of elements which
always includes the NULL value.
68
Given the domains:
id_dom: integer
name_dom, add_dom: string(20)
Tuple schema:
Person = {(person_id, id_dom), (name, name_dom), (address, add_dom)}
Tuples:
t1 = { (person_id, 12345678), (name, “Pepa Gómez”), (address, “Paz 10”) }
t2 = { (name, “Pep Blau”), (person_id, 9525869), (address, ?) }
We say that t2.address is null, not that t2.address = null.

We may use the operator “null” to check:
null(t2.address)
69

How are expressions interpreted when one or
more values are null?

What is the result of:
t2.address = “Main Street”

Is it true or false?

It is neither true nor false!!!


70
IT IS UNDEFINED!
Need for a tri-valued logic: { true, false, undefined }.

This applies to all the comparison operators:
<, >, =, , , , …

Evaluation:
 A □ B (where □ is any comparison operator) is evaluated as
undefined if at least one of A or B is null; otherwise it is
evaluated to the certainty value of the comparison A □ B.
 null(A) is evaluated to true if A is null and to false otherwise.

Examples:




71
3<?
3<5
3<2
?<?
 undefined
 true
 false
 undefined
null(3)  false
null(?)  true
Formal presentation: tri-valued logic
F = G H F = G H
G
H
false
false
false
false
undefined
false
false
undefined
true
false
false
true
false
undefined
false
undefined
G
F=¬G
false
true
undefined undefined
true
false
undefined undefined undefined undefined
true
undefined undefined
true
false
true
false
true
undefined
true
undefined
true
true
true
true
true
72
Formal presentation: tri-valued logic
Example:
Let R be
person_id
name
address
20450120
Juan Pérez
Cuenca 20
12904569
José Abad
Blasco Ibáñez 35
?
María Gutiérrez
Reina 7
12345678
Pepa Gómez
Colón 15
Operations:
R where ¬ (name = “Juan Pérez”)
 (person_id > 12500500) =
R where ¬ (person_id > 12500500) =
person_id
name
address
12904569
José Abad
Blasco Ibáñez 35
person_id
name
address
12345678
Pepa Gómez
Colón 15
R where (person_id <= 12500500)  (person_id > 12500500) = R ? NO
73
Constraints: motivation

The relational data model involves structures and
operators (modifications and queries).

Anything else?
Natural language
Logic
Databases
Orders / commands
“Hire ‘Jane Smith’” as a
new lecturer;
-
INSERT/DELETE/UPDATE
INSERT VALUES(‘Jane
Smith’) INTO lecturer;
Questions
“Who is the head of
department with code
DSIC?”
Open formulae
DX.Head ^
DX:Department ^
DX.dep_code = “DSIC”
Queries
SELECT Head
FROM Department
WHERE
dep_code=“DSIC”;
Statements
“All departaments must
have a code”
Closed formulae
DX:Department
(¬null(DX.dep_code))
Constraints
NNV(dep_code)
74
TABLE “Publication”
book_id
title
kind
author_id
B-000016
Crónica de una muerte anunciada
Novel
GAGA
B-000017
?
Theatre
GAGA
B-000008
Doce cuentos peregrinos
Tale
GAGA
autHor_id
GAGA
name
Gálamo Gante
B-000001
El club de los suicidas
BLUE
ROST
ROST
Robert Stevenson
B-000001
Poemas
Poetry
XXXX
BERU
Bertrand Rusbelt




TABLE “Author”
Can two books have the same value for book_id?
Can a book appear with no value in the attribute title?
Is it possible to have the value “XXXX” in the attribute author_id?
Does it make sense to have the value “BLUE” for the attribute
kind?
75


Solution

Definition of domains

Uniqueness constraint,

Not null constraint.

Definition of primary key

Definition of foreign keys.

General integrity constraints.
They are specified together with the database schema.
The responsible for ensuring them is the DBMS.
76
Constraints over attributes
Definition of a domain

When we associate a domain to each attribute we restrict
the set of possible values that this attribute may take.
Example:
“The kind of a publication can only be Novel, Tale, Theatre or Poetry”.

Domains definition:
Kind_Dom : {Novel, Tale, Theatre, Poetry, ...}

Relation definition:
Publication(pub_id:pub_dom, title:title_dom, kind:kind_dom,
author_id:author_dom);
77
Constraints: not null constraint
NNV: {A1,…, Ap}

The definition of a not null constraint over a set of attributes
K = {A1,…, Ap} of the relation R expresses the following
property: “there cannot be a tuple in R having the null
value in some attribute of K”.
Example:
NNV: { title }

“there cannot be a tuple in Publication which has the null
value in the title attribute”.

Formally, this constraint is defined as:
t:Publication (null(t.title))
78
Constraints: uniqueness
Uni: {A1,…, Ap}

The definition of a uniqueness constraint over a set of attributes K
= {A1,…, Ap} from the relation R expresses the following property:
“there cannot be two tuples in R with the same values in all the
attributes in set K”.
Example:
Uni: {book_id}

“There cannot be two tuples in Publication which have the same
value for the attribute book_id”.

Formally, this constraint is defined as:
(t1:Publication (t2:Publication (t1t2  t1.book_id = t2.book_id

79
null(t1.book_id)  null( t2.book_id))))
Constraints: primary key
PK: {A1,…, Ap}


A primary key in a relation is a set of attributes K = {A1,…, Ap}
which are chosen to serve as unique identifier for its tuples:

Its attributes must always have a value for each tuple (Not null constraint)

The values must be unique for each tuple (Uniqueness constraint).

Must be minimal, (this is a design constraint, will be seen in unit 3)
Example:
PK: {book_id}
“book_id is the primary key for Publication”

Formally, this can be defined as:
(t1:Publication (t2:Publication (t1t2  t1.book_id = t2.book_id

null(t1.book_id)  null( t2.book_id))))

80
t:Publication (null(t.book_id))
Constraints: primary key
FORMALLY, in general:

Given a set of attributes PK which has been defined as a
primary key for R, we say that R satisfies the primary key
integrity constraint if the following properties are met:

R satisfies a non-null constraint over PK, and

R satisfies a uniqueness constraint over PK
otherwise R violates this constraint.

Additionally, PK must be minimal; i.e., there cannot be any
proper subset that could also be primary key for R.
81
Constraints: foreign key
FK: {A1,…, Ap}  S

The use of foreign keys is the mechanism provided by the
relational model to express associations between the
objects in a database schema. This mechanism is defined
such that these associations, if performed, would be
carried out adequately.

With this goal, we can add to the schema of a relation R, a set
of attributes which refer to a set of attributes of a relation S.

This set of attributes K = {A1,…, Ap} is called foreign key in
relation R which refers to relation S.
82
PUBLICATION TABLE
book_id
B-000016
title
kind
Novel
author_id
GAGA
B-000017
Siempre NO
Theatre
GAGA
B-000008
Tale
GAGA
B-000001
Novel
ROST
B-000004
Poemas
Poetry
BERU
AUTHOR
TABLE
83
author_id
GAGA
name
Gálamo Gante
ROST
Robert Stevenson
BERU
Bertrand Rusbelt
83

Is it possible to have the value “XXXX” for the attribute
author_id?

No, the foreign key constraint states:

If there is a tuple in “Publication” such that the value
author_id is not null, then there must be one and only one
tuple in “Author” such that the value of author_id in
“Publication” matches the value author_id in “Author”
Formally:
t:Publication ((null(t.author_id))  (t1:Author (t1.author_id = t.author_id
 t2 :Author  t1t2  t2.author_id = t.author_id)) )
84


FORMALLY:
Given a foreign key FK in R which refers to S, this is
defined as:

A subset K = {A1, …, Ap} in the schema of R

A bijection f: K J such that:





J is a set of attributes in S
J has a uniqueness constraint, and
Ai (Ai  K) Ai and f(Ai) have the same domain.
A type of referential integrity.
This referential integrity (R.I.) can be:

85
weak, partial or complete.

R satisfies the referential integrity constraint over the FK if,
depending on the chosen type, the following property is
met:

Weak R.I.: if in a tuple of R all the values for the attributes of K
have a non null value, then there must exist a tuple in S taking
the same values for the attributes of J that the values in the
attributes of K.

Partial R.I.: if in a tuple of R one or more attributes of K have a
non null value, then there must exist a tuple in S taking the
same values for the attributes of J as the values in the non-null
attributes of K.

Complete (or Full) R.I.: in a tuple of R all the values must have
null value or none of them. In the latter case, there must exist a
tuple in S taking the same values for the attributes in J as the
values in the attributes of K.
86

Foreign key: Simplified Notation


The bijection f: K J can be omitted when J is the primary key of S
and we have one of the following two cases:

The set K has only one attribute, or

the bijection is defined by the syntactic equality between the
attribute names in K and J.
The type of referential integrity (weak, partial, complete) can be
omitted in any of these cases:

The foreign key K has only one attribute, or

When all of them have a not null constraint,

Since in these cases the three types of referential integrity match.
87
Constraints: foreign key and integrity restoration

Violation of the referential integrity

Given two relations R and S such that R has a foreign key K
which refers to J in S, the only operations which may violate
their referential integrity are:



Operations over R:

Insert a tuple in R.

Modify the value of K in a tuple of R.
Operations over S:

Delete a tuple in S.

Modify the value of J in a tuple of S.
If any of these operations attempts to break the
referential integrity, the DBMS aborts the operation.
This is the by-default behaviour.
88

There are other options (apart from aborting the operation)
that can be applied if the foreign key has been previously
defined in that way:


by setting values to null or applying the operation in cascade.
Namely, the referential integrity defined by a foreign key is
always preserved but can be done in different ways
depending on the foreign key definition:

Reject the operation (by default option).

Perform the operation but set some values to null to restore
integrity.

Perform the operation but propagate the action in cascade to
restore integrity
89

This leads to three combinations for each case


90
Deletion

“Restrictive deletion” (not specified in SQL, since it is the
default option)

“On delete cascade”

“On delete set to nulls”
Update

“Restrictive update” (not specified in SQL, since it is the
default option)

“On update cascade”

“On update set to nulls”
Example: Delete cascade propagation(1).
91
book_id
B-000016
title
kind
Novel
author_id
GAGA
B-000017
Siempre NO
Theatre
GAGA
B-000008
Tale
GAGA
B-000001
Novel
ROST
B-000004
Poemas
Poetry
BERU
author_id
GAGA
name
Gálamo Gante
ROST
Robert Stevenson
BERU
Bertrand Rusbelt
92
book_id
B-000016
title
kind
Novel
author_id
GAGA
B-000017
Siempre NO
Theatre
GAGA
B-000008
Tale
GAGA
B-000001
Novel
ROST
B-000004
Poemas
Poetry
BERU
author_id
GAGA
name
Gálamo Gante
ROST
Robert Stevenson
BERU
Bertrand Rusbelt
93
book_id
B-000001
title
kind
Novel
author_id
ROST
B-000004
Poemas
Poetry
BERU
author_id
ROST
name
Robert Stevenson
BERU
Bertrand Rusbelt
Example: Delete setting values to null (1).
94
book_id
B-000016
title
kind
Novel
author_id
GAGA
B-000017
Siempre NO
Theatre
GAGA
B-000008
Tale
GAGA
B-000001
Novel
ROST
B-000004
Poemas
Poetry
BERU
author_id
GAGA
name
Gálamo Gante
ROST
Robert Stevenson
BERU
Bertrand Rusbelt
Example: Delete setting values to null (2).
95
book_id
B-000016
title
kind
Novel
author_id
?
B-000017
Siempre NO
Theatre
?
B-000008
Tale
?
B-000001
Novel
ROST
B-000004
Poemas
Poetry
BERU
author_id
ROST
name
Robert Stevenson
BERU
Bertrand Rusbelt
Constraints: general i.c. and other mechanisms

General integrity constraints: are those which cannot be
expressed with the predefined constraints seen before. This
can be:



Static integrity constraints :

Affecting one table: attribute or table constraints (usually represented
with “CHECK”)

Affecting several tables: can be expressed with “CREATE ASSERTION ...”
or with triggers.
Transition integrity constraints: triggers.
A database is valid (it is in a consistent state), if all the defined
integrity constraints are satisfied.

96
The DBMS ensures that every update in the database generates a
new extension which satisfies all the constraints.
Constraints: schema example
DEPARTMENT(dep_cod:string(5), dep_name:string(90), head:string(30),
telephone:integer)
PK: {dep_code}
NNV: {dep_name}
SUBJECT(subj_code : string(3), subj_name : string(90), semester : string(2),
theory : real, lab : real, subj_dep : string(5))
PK: {subj_code}
FK: {subj_dep}  DEPARTMENT
NNV:{subj_name, semester, theory, lab}
UNI:{subj_name}
CHECK (semester ∈ {‘1A’,‘1B’,‘2A’,‘2B’,‘3A’,‘3B’,‘4A’,‘4B’})
LECTURER(lect_code : string(3), lect_name : string(90), extension: integer,
lect_dep: string(5) )
PK: {lect_code}
FK: {lect_dep}  DEPARTMENT
NNV: {lect_name, lect_dep}
General constraint C1: Every department must have at least one lecturer.
97
Constraints: exercises
EXERCISES!
98
Constraints and transactions

Constraints must always be satisfied.

Previous example:

Can we create a new department?

Option A:


Option B:


Create the department and then insert a lecturer (C1 is violated).
Create the lecturer and then the department (FK is violated).
Some operations must go together, as an atomic block.

99
Leads to the concept of transaction…
A transaction is a sequence of
manipulation or query operations which
constitutes a logical execution unit

We can put a batch of single operations into a transaction (by using
appropriate commands).

Constraints can be disabled during a transaction:


Some constraints are evaluated after every single atomic operation
(immediate evaluation).

Some constraints are evaluated after the transaction is completed
(deferred evaluation).
The database designer or manager are responsible for determining
the mode (immediate or deferred) of each constraint in the system.
100

Previous example. Two possible solutions with transactions.

Solution 1:






Insert the department
Insert a lecturer.
End transaction
Solution 2:






Begin transaction
Disable C1
Begin transaction
Disable FK
Insert a lecturer.
Insert the department
End transaction
We will see the SQL commands in Unit 2.
101
Contents
1.1. Fundamentals
Unit 2. SQL
6 Lectures: 9 hours
3.3. Logical Design
102
1.3. Interpretation of a relational database
Representation of reality
Reality
Design / Modelling
Representation
of Reality
D.B.
Interpretation

For each object in reality about which we want to have information we
define a relation whose attributes denote the most significant properties of
these objects (code, name, …) in such a way that each tuple which is
present in this relation must be interpreted as a particular instance of an
object;

In order to represent associations between objects we use explicit
references through attributes which identify each object.

Associations between objects where the cardinality is many-to-many
require an extra relation
103
Interpreting database schemas


The design/modelling arrow will be the subject of unit 3.
Now we focus on the interpretation arrow.
Reality
D.B.
Interpretation
104
• GEOGRAPHICAL INFORMATION
RIVER (rcod: d_rcod, name: d_nom, length: d_long, mcod: d_mcod)
PK: {rcod}
FK: {mcod} -> SEA
SEA (mcod: d_mcod, name: d_nom, details: d_det)
PK: {mcod}
PROVINCE (pcod: d_pcod, name: d_nom, extension: d_ext)
PK: {pcod}
CROSSES (rcod: d_rcod, pcod: d_pcod, km: d_km)
PK: {pcod,rcod}
FK: {pcod} -> PROVINCE
FK: {rcod} -> RIVER
LIMITS_WITH (pcod1: d_pcod, pcod2: d_pcod)
PK: {pcod1,pcod2}
FK: {pcod1} -> PROVINCE
FK: {pcod2} -> PROVINCE
105
• GEOGRAPHICAL INFORMATION
PROVINCE
pcod
name
extension
CROSSES
rcod
pcod
km
RIVER
rcod
name
length
mcod
SEA
mcod
name
details
LIMITS_WITH
pcod1
pcod2
106

Schema: GEOGRAPHIC INFORMATION





107
1. Can a river flow into two seas?
2. Can a river cross two provinces?
3. Can a river cross the same province twice?
4. Can a province limit with itself?
5. How many seas, as a maximum, can a river flow into?
And the minimum?
• COMPANY
SUPPLIER (vcod: d_vcod, name: d_nom1, city: d_ciu)
PK:{vcod}
PIECE(zcod: d_zcod, name: d_nom2, colour: d_colour, weight: d_weight,
city: d_ciu)
PK:{zcod}
PROJECT(ycod: d_ycod, name: d_nom3, city: d_ciu)
PK: {ycod}
ORDER (vcod: d_vcod, zcod: d_zcod, ycod: d_ycod, quant: d_quant)
PK:{vcod, zcod, ycod}
FK:{vcod} -> SUPPLIER
FK:{zcod} -> PIECE
FK:{ycod} -> PROJECT
108
• COMPANY
PIECE
zcod
name
colour
weight
city
SUPPLIER
vcod
name
city
ORDER
vcod
zcod
ycod
quant
PROJECT
ycod
name
city
109

Schema: COMPANY




110
6. Can two pieces have the same “zcod” code?
7. Can a piece have two colours?
8. Can a supplier provide two orders with the same piece
and project?
9. We could add the attribute “date” to the relation "order",
and it can also be included in the primary key. What would
this modification allow?
• LIBRARY:
USER (scod: d_scod, name: d_nom, address: d_dir)
PK: {scod}
BOOK (lcod: d_lcod, title: d_tit, author: d_author, topic: d_topic)
PK: {lcod}
FK:{topic} -> topic
HAS_READ (scod: d_scod, lcod: d_lcod)
PK: {scod, lcod}
FK: {scod} -> user
FK: {lcod}-> book
TOPIC (topic: d_topic, description: d_desc)
PK: {topic}
FIELD (topic: d_topic, subtopic: d_topic)
PK:{topic, subtopic}
FK:{topic} -> topic
FK:{subtopic} -> topic
111
• LIBRARY:
BOOK
lcod
title
author
topic
HAS_READ
lcod
scod
USER
scod
name
address
TOPIC
topic
description
FIELD
topic
subtopic
112

Schema: LIBRARY 1






113
10. Can a user read more than one book?
11. Can a user read the same book more than once?
12. Can a book have more than one author?
13. Can a book have more than one topic?
14. Can a topic be a subtopic of itself?
15. Can a book be read by two different users?
• RECORD COLLECTION:
COMPOSER (comp_name: d_name, year: d_year, country: d_country)
PK: {comp_name}
CONDUCTOR (cond_name: d_name, year: d_year, biography: d_bio)
PK: {cond_name}
WORK (word_cod: d_work_cod, title: d_title, year: d_year,
comp_name: d_name)
PK: {work_cod}
FK: {comp_name } -> COMPOSER
DISC (ref: d_ref, name: d_name, year: d_year, company: d_comp)
PK: {ref}
IS_IN (workd_cod: d_work_cod, ref: d_ref, cond_name: d_name)
PK: {work_cod, ref}
FK: {work_cod} -> WORK
FK: {ref} -> DISC
FK: {cond_name} -> CONDUCTOR
114
• RECORD COLLECTION:
DISC
ref
name
company
CONDUCTOR
cond_name
year
biography
115
IS_IN
work_cod
ref
cond_name
WORK
work_cod
title
year
comp_name
COMPOSER
comp_name
year
country

Schema: RECORD COLLECTION




116
16. Can a disc contain more than one work?
17. Can a work have more than one composer?
18. Can the same work appear in the same disk twice,
conducted by different conductors?, and by the same
conductor?
19. Can works with the same composer appear in different
discs?
• TRAVEL AGENCY:
TRIP: d_code, date: d_date, price: d_pri, dni_g: d_dni)
PK: {code}
FK: {dni_g} -> GUIDE
NNV: {date}
GUIDE(dni_g: d_dni, name: d_name, language: d_lan, age: d_age)
PK: {dni_g}
DRIVER(dni: d_dni, name: d_name, address: d_ad, age: d_age, gender: d_gen)
PK:{dni}
CITY(city_name: d_name1, history: d_his, inhabitants: d_inh)
PK:{city_name}
VISIT(code: d_code, city_name: d_nom1)
PK:{code, city_name}
FK:{code} -> TRIP
FK: {city_name} -> CITY
DRIVES(dni: d_dni, code: d_code)
PK: {dni, code}
FK: {code} -> TRIP
FK: {dni} -> DRIVER
117
• TRAVEL AGENCY:
CITY
city_name
history
inhabitants
DRIVER
dni
name
address
age
gender
118
VISIT
code
city_name
DRIVES
code
dni
TRIP
code
date
price
dni_g
GUIDE
dni
name
language
age

Schema: TRAVEL AGENCY






119
20. Can the same trip visit the same city twice?
21. Can a guide speak two languages?
22. Can a driver be in two trips at the same time (date)?
23. Can a driver be also a guide?
24. How many drivers are there, as a minimum, in each trip?
25. Can a guide participate in more than one trip?
• “CICLISMO”:
EQUIPO(nomeq: d_eq, director: d_nom)
PK: {nomeq}
CICLISTA(dorsal: d_dor, nombre: d_nom, edad: d_edad, nomeq: d_eq)
PK: {dorsal}
FK: {nomeq} EQUIPO
NNV: {nomeq}
NNV: {nombre}
ETAPA(netapa: d_nº, km: d_km, salida: d_ciu, llegada: d_ciu, dorsal: d_dor)
PK: {netapa}
FK: {dorsal} CICLISTA
PUERTO(nompuerto: d_nom, altura: d_alt, categoria: d_cat, pendiente: d_pen,
netapa: d_nº, dorsal: d_dor)
PK: {nompuerto}
FK: {netapa} ETAPA
NNV: {netapa}
MAILLOT(codigo: d_cod, tipo: d_tipo, premio: d_pre, color: d_col)
PK: {codigo}
LLEVAR(dorsal: d_dor, netapa: d_nº, codigo: d_cod)
PK: {netapa,codigo}
FK: {netapa} ETAPA
FK: {codigo} MAILLOT
NNV: {dorsal}
120

Schema: CICLISMO





121
26. Can a cyclist belong to more than one team?
27. Can a cyclist wear more than one maillot in the same
stage?
28. And more than one maillot during the whole race
("tour")?
29. Can a mountain pass appear in more than one stage?
30. Can a cyclist win more than one stage?
• “MÚSICA”:
CANCION(cod: d_can, título: d_tit, duración: d_dur)
PK: {cod}
NNV: {título}
COMPANYIA(cod: d_comp, nombre: d_nom, dir: d_dir, fax: d_tel, tfno: d_tel)
PK: {cod}
NNV: {nombre}
DISCO(cod: d_dis, nombre: d_nom, fecha: d_fecha, cod_comp: d_comp, cod_gru: d_gru)
PK: {cod}
FK: {cod_comp} COMPANYIA
NNV: {cod_comp}
FK: {cod_gru} GRUPO
NNV: {cod_gru}
ESTA(can: d_can, cod: d_dis)
PK: {can, cod}
FK: {can} CANCIÓN
FK: {cod} DISCO
GRUPO(cod: d_gru, nombre: d_nom, fecha: d_fecha, pais: d_pais)
PK: {cod}
NNV: {nombre}
ARTISTA(dni: d_dni, nombre: d_nom)
PK: {dni}
NNV: {nombre}
CLUB(cod: d_club, nombre: d_nom, sede: d_dir, num: d_num, cod_gru: d_gru)
PK: {cod}
FK: {cod_gru} GRUPO
NNV: {cod_gru}
NNV: {nombre}
PERTENECE(dni: d_dni, cod: d_gru, funcion: f_fun)
PK: {dni, cod}
FK: {dni} ARTISTA
FK: {cod} GRUPO
122

Schema: “MÚSICA”





123
31. Can a disc be published by more than one company?
And by none?
32. Can a club admire more than one group? And can a
group have more than a fans club?
33. Can a song appear in more than one disc?
34. How many groups can an artist belong to as a maximum?
And as a minimum?
35. Can a disc have no songs?
•
“BIBLIOTECA”
AUTOR(autor_id: varchar(4), nombre: varchar(35), nacionalidad: varchar(20))
PK: {autor_id}
NNV: {nombre}
LIBRO(id_lib: varchar(10), titulo: varchar(80), año: integer, num_obras: integer)
PK: {id_lib}
TEMA(tematica: varchar(20), descripcion: varchar(50))
PK: {tematica}
OBRA(cod_ob: integer, titulo: varchar(80), año: d_cat, tematica: varchar(20))
PK: {cod_ob}
FK: {tematica} TEMA
NNV: {titulo}
AMIGO(num: integer, nombre: varchar(60), telefono: varchar(10))
PK: {num}
NNV: {nombre}
PRESTAMO(num: integer, id_lib:varchar(10))
PK: {num,id_lib}
FK: {num}  AMIGO
FK: {id_lib}  LIBRO
ESTA_EN(cod_ob: integer, id_lib:varchar(10))
PK: {cod_ob,id_lib}
FK: {cod_ob}  OBRA
FK: {id_lib}  LIBRO
ESCRIBIR(cod_ob: integer, autor_id:varchar(4))
PK: {cod_ob,autor_id}
FK: {cod_ob} OBRA
FK: {autor_id} AUTOR
124

Schema: “BIBLIOTECA”





125
36. Can a friend have more than one borrowed book at the
same time? And borrow the same book twice?
37. Can a work have more than one topic?
38. Can a book contain a work more than once? And can a
work be included in more than one book?
39. How many works can an author write, as a minimum?
And as a maximum?
40. Can a book be borrowed by different friends?
Interpreting database schemas: general hints

Tables:

Objects are represented by tables for which none of the components
of their PK refer to other tables (they have existence on their own).




This is not true for hierarchical relationships (specialisation), though.
The rest of tables represent relationships (non-entity tables).
Attributes:

Represent properties of objects (if hey are not FK)

Represent relationships between objects (if they are FK). These relationships represent
many to (at most) 1.

If a FK from R to S has a NNV constraint, then every object in R is associated with one
object in S. This means a many-to-(1,1) relationship.

If a FK from R to S does not have a NNV constraint, then every object in R is not necessarily
associated with any object in S. This means a many-to-(0,1) relationship.

If a FK from R to S has a uniqueness constraint, then every object in S can at most be
associated with one object in R. This means a (0,1)-to-(0,1) relationship.
Many-to-many relationships are always represented by an intermediate nonentity table (combining one-to-many and many-to-one relationships).
126

Databases and Information Systems Code 11548, ECTS: 6 credits

Transcripción

Documentos relacionados

Derived relational responding and human language

University of Texas at El Paso Library