Advanced Database Models

Dr.-Ing. Eike Schallehn

OvG Universität Magdeburg

Fakultät für Informatik
Institut für Technische und Betriebliche Informationssysteme

2019
Organization

Weekly lecture
I http://www.dbse.ovgu.de/dbse/en/Lectures/Lehrveranstaltungen/Advanced+Database+Models.html

Weekly exercises (3 alternative slots, currently)

I Starting April 15th
Exams
I Written exams of 120 minutes at the end of lecture period

Schallehn (FIN/ITI) Advanced Database Models 2019 2 / 358

History of this Lecture

Previous titles
I Object-oriented Database Systems
I Object-relational Database Systems
Latest addition: semi-structured data models
Previously held and refined by
I Gunter Saake
I Can Türker
I Ingo Schmitt
I Kai-Uwe Sattler

Schallehn (FIN/ITI) Advanced Database Models 2019 3 / 358

Overview of the Lecture

Data and design models

I Recapitulation: the relational model
I NF 2 and eNF 2
I Object-oriented models
I Object-relational models
I Models for semi-structured data (XML)
For these models we discuss
I Theoretical foundations
I Query Languages
I Application
I Standards and systems

Schallehn (FIN/ITI) Advanced Database Models 2019 4 / 358

English Literature /1

Stonebraker, M.; Moore, D.: Object-Relational DBMSs: The Next

Great Wave, Morgan Kaufmann Publishers, 1999
Date, C. J.; Darwen, H.: Foundation for Object / Relational
Databases: The Third Manifesto, Addison-Wesley, 1998
Melton, J.:Advanced SQL: 1999 - Understanding
Object-Relational and Other Advanced Features,Morgan
Kaufmann, 2002

Schallehn (FIN/ITI) Advanced Database Models 2019 5 / 358

English Literature /2

Russel, C. et al.: The Object Data Standard: ODMG 3.0, Morgan

Kaufmann, 2000
Chaudhri, A. B., Rashid, A.; Zicari, R.: XML Data Management:
Native XML and XML-Enabled Database
Systems,Addison-Wesley, 2003
Elmasri, R.; Navathe, S.: Fundamentals of Database Systems,
Addison Wesley, 2003

Schallehn (FIN/ITI) Advanced Database Models 2019 6 / 358

German Literature

Türker, C.; Saake, G.: Objektrelationale Datenbanken,

dpunkt.verlag, Heidelberg 2006
Türker, C.: SQL:1999 & SQL:2003, dpunkt.verlag, Heidelberg,
2003
Klettke, M.; Meyer, H.: XML und Datenbanken, dpunkt.verlag,
Heidelberg, 2003
Saake, G.; Türker, C.; Schmitt, I.: Objektdatenbanken, Int.
Thomson Publishing, 1997
Elmasri, R.; Navathe, S.: Grundlagen von Datenbanksystemen,
Pearson Studium, 2002

Schallehn (FIN/ITI) Advanced Database Models 2019 7 / 358

 Teil I

Introduction
Overview
Some Basic Terms
History of Database Models
Problems with RDBMS
Aspects of Advanced Data Models

Schallehn (FIN/ITI) Advanced Database Models 2019 9 / 358

Some Basic Terms

Data Model
Database Model
Database
Database System
Database Management System
Conceptual Model
Database Schema(s)

Schallehn (FIN/ITI) Advanced Database Models 2019 10 / 358

Data Model

A data model is a model that describes in an abstract way how data

is represented in an information system or a database management
system.

Generic term includes models of

I Programming languages
I Database systems
I Conceptual design methods
Often (but not here) ambiguously used for schemata

Schallehn (FIN/ITI) Advanced Database Models 2019 11 / 358

Data Model /2

A data model
I is a system of concepts and their interrelations
I is the “‘language” used to describe data
I defines syntax and semantic of data
I is the fundamental to other aspects of systems such as integrity
and operations for access and manipulation

Schallehn (FIN/ITI) Advanced Database Models 2019 12 / 358

Data Models: Examples

The data model of the Java programming language allows structuring

data as objects of classes consisting of attributes of basic
data-types or references to other objects, specifying
methods to access the data, etc.
The relational database model allows structuring data as tables of
tuples with attributes, foreign keys, integrity constraints,
etc.
The ER model for conceptual design describes data as instances of
entity types, relationship types with cardinalities,
attributes, etc.

Schallehn (FIN/ITI) Advanced Database Models 2019 13 / 358

Database Model

A database model is a data model for a database system. It

provides a theory or specification describing how a database is
structured and used.

Tightly coupled with database management system (DBMS), i.e. a

database management system usually implements one (or more)
data models

Schallehn (FIN/ITI) Advanced Database Models 2019 14 / 358

Database Models: Examples

Hierarchical model
Network model
Relational model
NF 2 and eNF 2
Object-Relational model
Object-oriented model (or short, object model)
Multi-dimensional model
Semi-structured model
Multimedia data model
Spatio-temporal data model
...

Schallehn (FIN/ITI) Advanced Database Models 2019 15 / 358

Database Management Systems

A database management system (DBMS) is a suite of computer

programs designed to manage a database and run operations on the
data requested by numerous clients.

A database (DB) is an organized collection of data.

A database system (DBS) is the concrete instance of a database

managed by a database management system.

Schallehn (FIN/ITI) Advanced Database Models 2019 16 / 358

Database Management Systems: Examples

Current database management systems such as

I Oracle DBMS
I IBM DB2
I Microsoft SQL Server
are mainly based on the object-relational model with extensions /
extensibility for
I Multi-dimensional data (Data Warehouse)
I Multimedia data (Image, Video, Audio, ...)
I Semi-structured data (HTML, XML)
I ...
Specific other systems:
I Object-oriented database systems
I XML-database systems
I ...

Schallehn (FIN/ITI) Advanced Database Models 2019 17 / 358

Database Systems: Examples

The EBay Web-database running on several servers managing the

offered items, the users, and their activities.
The Wallmart Data Warehouse managing information about customer
behavior from all their supermarkets and supporting
complex analytical tasks.
The student database of our university running on a server in the
students department managing the identity, credits,
status, etc. of our students.

Schallehn (FIN/ITI) Advanced Database Models 2019 18 / 358

Database Systems: Examples /2

Database systems in almost all larger companies and

organizations as the core components of systems supporting
I Human resource management
I Customer relationship management
I Product development / construction
I Collaborative work
I Sales and marketing
I Decision and management support
I ...

Schallehn (FIN/ITI) Advanced Database Models 2019 19 / 358

Conceptual Models

A conceptual model is a data model or diagram for high-level

descriptions of schemata independently of their implementation. It
often provides a graphical notation and is used in the first stages of
information-system design (conceptual design).

Entity-relationship model for (relational) DB design

Unified Modeling Language (UML) for application design, but
gaining support in database design

Schallehn (FIN/ITI) Advanced Database Models 2019 20 / 358

Database Design Process
Requirements Analysis

Conceptual Design
Conceptual Models
e.g. ER or UML

Database Models
Logical Design
e.g. RM, ORM, OO

Concrete implementation of a database model, e.g.

Data Definition
the object−relational model of the Oracle 10g DBMS

Physical Design

Implementation

Schallehn (FIN/ITI) Advanced Database Models 2019 21 / 358

Database Schema

A database schema is a map of concepts and their relationships for

a specific universe of discourse. It describes the structure of a
database.

A conceptual database schema is a high-level and

implementation-independent database schema expressed using the
constructs of a conceptual data model.

A logical database schema is a detailed database schema

expressed using the constructs of a database model and is ready for
implementation.

Schallehn (FIN/ITI) Advanced Database Models 2019 22 / 358

Database Design Process /2
Requirements Analysis

Conceptual Design

Conceptual Database Schema

Logical Design

Logical Database Schema

Data Definition

Physical Design Implemented database schema

Implementation

Schallehn (FIN/ITI) Advanced Database Models 2019 23 / 358

Conceptual Database Schema: Example
fname minit lname address
works_for name number
name sex (1,*)
(1,1)
ssn
startdate numberofemployees Department locations
Employee (0,*)
bdate
manages (1,1) (0,*)
(0,*) (0,1)
salary supervisor supervisee (1,*)

(0,*)
controls
Supervision hours

works_on
(1,1)
dependents_of (1,*)
Project

(1,1)
name number location
dependent

name sex birthdate relationship

Schallehn (FIN/ITI) Advanced Database Models 2019 24 / 358

Logical Database Schema: Example

Employee(fname, minit, lname, ssn, bdate, address, sex, salary, superssn, dno)

Department(dname, dnumber, mgrssn, mgrstartdate)

Dept_locations(dnumber, dlocation)

Project(pname, pnumber, plocation, dnum)

Works_on(essn, pno, hours)

Dependent(essn, dependent_name, sex, bdate, relationship)

Schallehn (FIN/ITI) Advanced Database Models 2019 25 / 358

Database: Example

EMPLOYEE
FNAME MINIT LNAME SSN BDATE ADDRESS SEX SALARY SUPERSSN DNO
John B Smith 123456789 1965-01-09 731 Fondren, Houston, TX M 30000 333445555 5
Franklin T Wong 333445555 1955-12-08 638 Voss, Houston, TX M 40000 888665555 5
Alicia J Zelaya 999887777 1968-07-19 3321 Castle, Spring, TX F 25000 987654321 4
Jennifer S Wallace 987654321 1941-06-20 291 Berry, Bellaire, TX F 43000 888665555 4
Ramesh K Narayan 666884444 1962-09-15 975 Fire Oak, Humble, TX M 38000 333445555 5
Joyce A English 453453453 1972-07-31 5631 Rice, Houston, TX F 25000 333445555 5
Ahmad V Jabbar 987987987 1969-03-29 980 Dallas, Houston, TX M 25000 987654321 4
James E Borg 888665555 1937-11-10 450 Stone, Houston, TX M 55000 null 1

DEPT_LOCATIONS
DEPARTMENT DNUMBER DLOCATION
DNAME DNUMBER MGRSSN MGRSTARTDATE 1 Houston
Research 5 333445555 1988-05-22 4 Stafford
Administration 4 987654321 1995-01-01 5 Bellaire
Headquarters 1 888665555 1981-06-19 5 Sugarland
5 Houston

Schallehn (FIN/ITI) Advanced Database Models 2019 26 / 358

Database: Example /2
WORKS_ON
ESSN PNO HOURS
123456789 1 32,5
123456789 2 7,5
666884444 3 40,0
453453453 1 20,0 PROJECT
453453453 2 20,0 PNAME PNUMBER PLOCATION DNUM
333445555 2 10,0 ProductX 1 Bellaire 5
333445555 3 10,0 ProductY 2 Sugarland 5
333445555 10 10,0 ProductZ 3 Houston 5
333445555 20 10,0 Computerization 10 Stafford 4
999887777 30 30,0 Reorganization 20 Houston 1
999887777 10 10,0 Newbenefits 30 Stafford 4
987987987 10 35,0
987987987 30 5,0
987654321 30 20,0
987654321 20 15,0
888665555 20 null

Schallehn (FIN/ITI) Advanced Database Models 2019 27 / 358

Database: Example /3
DEPENDENT
ESSN DEPENDENT_NAME SEX BDATE RELATIONSHIP
333445555 Alice F 1986-04-05 DAUGHTER
333445555 Theodore M 1983-10-25 SON
333445555 Joy F 1958-05-03 SPOUSE
987654321 Abner M 1942-02-28 SPOUSE
123456789 Michael M 1988-01-04 SON
123456789 Alice F 1988-12-30 DAUGHTER
123456789 Elizabeth F 1967-05-05 SPOUSE

Schallehn (FIN/ITI) Advanced Database Models 2019 28 / 358

History of Database Models

implementation abstract

1960 HM

NWM
1970 RM
ER
SQL
1980 NF 2 SDM
eNF2
OODM OEM
1990 (C++)

ODMG
2000 ORM / SQL−99

Schallehn (FIN/ITI) Advanced Database Models 2019 29 / 358

Database Models, Conceptual Models, Standards

Database models
I Hierarchical model (HM)
I Network model (NM)
I Relational model (RM)
I (extended) Non-first normal form (NF 2 and eNF 2 )
I Object-relational model (ORM)
I Object-oriented database model (OODM)
Conceptual Models
I Entity-relationship model (ER)
I Semantic data models (SDM)
Standards
I Object Data Management Group (ODMG)
I Structured Query Language (SQL:1999 and SQL:2003)

Schallehn (FIN/ITI) Advanced Database Models 2019 30 / 358

The Hierarchical Model
First important database model
Developed in the late ’50s
Data organized as tree-structured networks of
flat records
IBM Information Management System (IMS) one
of the most successful DBMS
I Developed since 1966
I Used until today
Important concepts of hierarchical model still
relevant for XML and semi-structured data

Schallehn (FIN/ITI) Advanced Database Models 2019 31 / 358

The Network Model
Developed in the late ’60s by Charles Bachman
Database extension to the data model of the
successful COBOL programming language
Also know as CODASYL (COnference on DAta
SYstems Languages) database model
Data organized as arbitrary networks of flat
records
Became an official standard in 1969
Influenced object-oriented data(base) models
developed later on

Schallehn (FIN/ITI) Advanced Database Models 2019 32 / 358

The Relational Model

Developed by Edgar F. Codd (1923-2003) in 1970

Derived from mathematical model of n-ary relations
Colloquial: data is organized as tables (relations) of records
(n-tuples) with columns (attributes)
Currently most commonly used database model
Relational Database Management Systems (RDBMS)
First prototype: IBM System R in 1974
Implemented as core of all major DBMS since late ’70s:
IBM DB2, Oracle, MS SQL Server, Informix, Sybase, MySQL,
PostgreSQL, etc.
Database model of the DBMS language standard SQL

Schallehn (FIN/ITI) Advanced Database Models 2019 33 / 358

New Applications

Concepts of RDBMS developed for classic database applications,

e.g.
I Administration
I Banking
I Sales / Customer Relations
Mass data in new applications
I Engineering / product development
I Telecommunications
I Multimedia systems
I Document management / WWW
introduce new requirements

Schallehn (FIN/ITI) Advanced Database Models 2019 34 / 358

More Complex and Flexible Structures

Real-world objects can not be described by flat records

I Consist of other objects
I Contain sets or lists of other objects
I Complex relationships to other objects
Real-world objects have no fixed structure
I Properties may be optional
I Properties / parts may have varying cardinality
I Properties (or their consideration) can be added or removed

Schallehn (FIN/ITI) Advanced Database Models 2019 35 / 358

More Semantic Concepts

Typical abstraction concepts

I Specialization / Generalization
I Aggregation
I Association
Differing representations of objects
I Temporal: versions
I Conditional alternatives: variants
Object identity: the property of an object to be itself independently
of changing values

Schallehn (FIN/ITI) Advanced Database Models 2019 36 / 358

Description of Behavior

Relational model: focus on structure of data

Integrity constraints only way to restrict dynamics
Operations and transactions are independent of application
In programming combined view of data and behavior common
practice
I Methods for access and modification
I Constructors / destructors
I Encapsulation
I Processes composition

Schallehn (FIN/ITI) Advanced Database Models 2019 37 / 358

Extensions and Extensibility
Support for new (e.g. multimedia) or application-specific data types

AP AP AP

AP AP AP

Object−relational SQL

Extension

Relational SQL DBMS ...

Extension
DBMS

Schallehn (FIN/ITI) Advanced Database Models 2019 38 / 358

Impedance Mismatch

The (object-relational) impedance mismatch is the difference of

data models used in programming and in database technology.

Derived from electrical engineering

Involved data models
I Programming: nowadays mostly object-oriented
I Databases: mostly relational
The same application objects are
I Persistently stored in the database
I Transiently processed by the application
Transformations in both directions required

Schallehn (FIN/ITI) Advanced Database Models 2019 39 / 358

Impedance Mismatch /2

public class Person { SELECT FNAME, LNAME

String firstname; FROM EMPLOYEE
String lastname;
} RESULT:EMPLOYEE
FNAME LNAME
public class Employee John Smith
extends Person { Franklin Wong
Alicia Zelaya
Employee(...) { Jennifer Wallace
...; Ramesh Narayan
} Joyce English
} Ahmad Jabbar
James Borg

Schallehn (FIN/ITI) Advanced Database Models 2019 40 / 358

Aspects of Advanced Data Models

More
I complex,
I flexible, and
I meaningful
data structures
Integration of behavior
Extensions and extensibility
Solving the “impedance mismatch” problem

Schallehn (FIN/ITI) Advanced Database Models 2019 41 / 358

 Teil II

Recapitulation: Relational Database

Systems
Overview
Basic Principles of Database Systems
The Relational Database Model
The Relational Algebra
Relational Database Management Systems
SQL

Schallehn (FIN/ITI) Advanced Database Models 2019 43 / 358

Database Management Systems (DBMS)

Nowadays commonly used

I to store huge amounts of data persistently,
I in collaborative scenarios,
I to fulfill high performance requirements,
I to fulfill high consistency requirements,
I as a basic component of information systems,
I to serve as a common IT infrastructure for departments of an
organization or company.

Schallehn (FIN/ITI) Advanced Database Models 2019 44 / 358

Codd’s 9 Rules for DBMS /1

Differentiate DBMS from other systems managing data

persistently, e.g. file systems

1 Integration: homogeneous, non-redundant management of data

2 Operations: means for accessing, creating, modifying, and
deleting data
3 Catalog: the data description must be accessible as part of the
database itself
4 User views: different users/applications must be able to have a
different perception of the data

Schallehn (FIN/ITI) Advanced Database Models 2019 45 / 358

Codd’s 9 Rules for DBMS /2

5 Integrity control: the systems must provide means to grant the

consistency of data
6 Data security: the system must grant only authorized accesses
7 Transactions: multiple operations on data can be grouped into a
logical unit
8 Synchronization: parallel accesses to the database are
managed by the system
9 Data backups: the system provides functionality to grant
long-term accessibility even in case of failures

Schallehn (FIN/ITI) Advanced Database Models 2019 46 / 358

3 Level Schema Architecture

External Schema 1 ... External Schema N

Query Processing

Data Representation
Conceptual Schema

Internal Schema

Schallehn (FIN/ITI) Advanced Database Models 2019 47 / 358

3 Level Schema Architecture /2

Important concept of DBMS

Provides
I transparency, i.e. non-visibility, of storage implementation details
I ease of use
I decreased application maintenance efforts
I conceptual foundation for standards
I portability
Describes abstraction steps:
I Logical data independence
I Physical data independence

Schallehn (FIN/ITI) Advanced Database Models 2019 48 / 358

Data Independence

Logical data independence: Changes to the logical schema level

must not require a change to an application (external schema) based
on the structure.

Physical data independence: Changes to the physical schema level

(how data is stored) must not require a change to the logical schema.

Schallehn (FIN/ITI) Advanced Database Models 2019 49 / 358

Architecture of a DBS
Schema architecture roughly conforms
to general architecture of a database
systems Application 1 ... Application n
Applications access database
using specific views (external
schema)
DBMS
The DBMS provides access for
all applications using the logical
schema
Database
The database is stored on
secondary storage according to
an internal schema

Schallehn (FIN/ITI) Advanced Database Models 2019 50 / 358

Client Server Architecture
Schema architecture does not direct-
ly relate to client server architecture Client 1 ... Client n
(communication/network architecture)
Clients may run several
applications DB Server

Applications may run on several

clients
DB servers may be distributed Database
...

Schallehn (FIN/ITI) Advanced Database Models 2019 51 / 358

The Relational Model

Developed by Edgar F. Codd (1923-2003) in 1970

Derived from mathematical model of n-ary relations
Colloquial: data is organized as tables (relations) of records
(n-tuples) with columns (attributes)
Currently most commonly used database model
Relational Database Management Systems (RDBMS)
First prototype: IBM System R in 1974
Implemented as core of all major DBMS since late ’70s:
IBM DB2, Oracle, MS SQL Server, Informix, Sybase, MySQL,
PostgreSQL, etc.
Database model of the DBMS language standard SQL

Schallehn (FIN/ITI) Advanced Database Models 2019 52 / 358

Basic Constructs

A relational database is a database that is structured according to

the relational database model. It consists of a set of relations.

Relation name Attributes

R A1 ... An } Relation schema

...

... Relation
Tuple
...

Schallehn (FIN/ITI) Advanced Database Models 2019 53 / 358

Basic Constructs /2

A relation is a set of tuples conforming to one relation schema and is

identified by a relation name (relvar ).

A relation schema is a set of attributes, each identified within the

relation by an attribute name and conforming to a domain/type of
valid values.

A tuple is a set of attribute values, conforming to a relation schema.

Schallehn (FIN/ITI) Advanced Database Models 2019 54 / 358

Integrity Constraints

Static integrity constraints describe valid tuples of a relation

I Primary key constraint
I Foreign key constraint (referential integrity)
I Value range constraints
I ...
In SQL additionally: uniqueness and not-NULL
Transitional integrity constraints describe valid changes to a
database

Schallehn (FIN/ITI) Advanced Database Models 2019 55 / 358

The Relational Algebra

A relational algebra is a set of operations that are closed over

relations.

Each operation has one or more relations as input

The output of each operation is a relation

Schallehn (FIN/ITI) Advanced Database Models 2019 56 / 358

Relational Operations
Primitive operations:
Non-primitive operations
Selection σ
Natural Join ./
Projection π
θ-Join and Equi-Join ./ϕ
Cartesian product (cross
Semi-Join n
product) ×
Outer-Joins = ×
Set union ∪
Set intersection ∩
Set difference −
...
Rename β

Schallehn (FIN/ITI) Advanced Database Models 2019 57 / 358

Notation for Relations and Tuples

If R denotes a relation schema (set of attributes), than the function

r (R) denotes a relation conforming to that schema (set of tuples)
R and r (R) are often erroneously used synonymously to denote a
relation, assuming that for a given relation schema only one
relation exists
t(R) denotes a tuple conforming to a relation schema
t(R.a) denotes an attribute value of a tuple for an attribute a ∈ R

Schallehn (FIN/ITI) Advanced Database Models 2019 58 / 358

The Selection Operation σ
Select tuples based on predicate or complex condition
PROJECT
PNAME PNUMBER PLOCATION DNUM
ProductX 1 Bellaire 5
ProductY 2 Sugarland 5
ProductZ 3 Houston 5
Computerization 10 Stafford 4
Reorganization 20 Houston 1
Newbenefits 30 Stafford 4

σPLOCATION=0 Stafford 0 (r (PROJECT ))

PNAME PNUMBER PLOCATION DNUM

Computerization 10 Stafford 4
Newbenefits 30 Stafford 4

Schallehn (FIN/ITI) Advanced Database Models 2019 59 / 358

The Projection Operation π
Project to set of attributes - remove duplicates if necessary
PROJECT
PNAME PNUMBER PLOCATION DNUM
ProductX 1 Bellaire 5
ProductY 2 Sugarland 5
ProductZ 3 Houston 5
Computerization 10 Stafford 4
Reorganization 20 Houston 1
Newbenefits 30 Stafford 4

πPLOCATION,DNUM (r (PROJECT ))

PLOCATION DNUM
Bellaire 5
Sugarland 5
Houston 5
Stafford 4
Houston 1

Schallehn (FIN/ITI) Advanced Database Models 2019 60 / 358

Cartesian or cross product ×
Create all possible combinations of tuples from the two input relations

R
A B
1 2 A B C D E
3 4 1 2 5 6 7
1 2 8 9 10
r (R) × r (S) 1 2 11 12 13
S 3 4 5 6 7
C D E 3 4 8 9 10
5 6 7 3 4 11 12 13
8 9 10
11 12 13

Schallehn (FIN/ITI) Advanced Database Models 2019 61 / 358

Set: Union, Intersection, Difference

All require compatible schemas: attribute names and domains

Union: duplicate entries are removed
Intersection and Difference: ∅ as possible result

Schallehn (FIN/ITI) Advanced Database Models 2019 62 / 358

The Natural Join Operation ./

Combine tuples from two relations r (R) and r (S) where for
I all attributes a = R ∩ S (defined in both relations)
I is t(R.a) = t(S.a).
Basic operation for following key relationships
If there are no common attributes result is Cartesian product
R ∩ S = ∅ =⇒ r (R) ./ r (S) = r (R) × r (S)
Can be expressed as combination of π, σ and ×
r (R) ./ r (S) = πR∪S (σVa∈R∩S t(R.a)=t(S.a) (r (R) × r (S)))

Schallehn (FIN/ITI) Advanced Database Models 2019 63 / 358

The Natural Join Operation ./ /2

R
A B
1 2
3 4
5 6
A B C D
r (R) ./ r (S) 3 4 5 6
5 6 7 8
S
B C D
4 5 6
6 7 8
8 9 10

Schallehn (FIN/ITI) Advanced Database Models 2019 64 / 358

The Rename Operation β
Can be used to create
compatible schemas for set operations, or
overlapping schemas for join operations.

PERSON
ID NAME
1273 Dylan r (PERSON) ./ (βOWNERID→ID (r (CAR)))
3456 Reed
ID NAME BRAND
1273 Dylan Cadillac
CAR
1273 Dylan VW Beetle
OWNERID BRAND
3456 Reed Stutz Bearcat
1273 Cadillac
1273 VW Beetle
3456 Stutz Bearcat

Schallehn (FIN/ITI) Advanced Database Models 2019 65 / 358

The Semi-Join Operation n

Results all tuples from one relation having a (natural) join partner
in the other relation
r (R) n r (S) = πR (r (R) ./ r (S))

PERSON
PID NAME
1273 Dylan
2244 Cohen r (PERSON) n r (CAR)
3456 Reed
PID NAME
1273 Dylan
CAR
3456 Reed
PID BRAND
1273 Cadillac
1273 VW Beetle
3456 Stutz Bearcat

Schallehn (FIN/ITI) Advanced Database Models 2019 66 / 358

Other Join Operations

Conditional join: join condition ϕ is explicitly specified

r (R) ./ϕ r (S) = σϕ (r (R) × r (S))
θ-Join: special conditional join, where ϕ is a single predicate of
the form aθb with a ∈ R, b ∈ S, and θ ∈ {=, 6=, >, <, ≤, ≥, . . . }
Equi-Join: special θ-Join where θ is =.
(Left or Right) Outer Join: union of natural join result and tuples
from the left or right input relation which could not be joined
(requires NULL-values to grant compatible schemas).

Schallehn (FIN/ITI) Advanced Database Models 2019 67 / 358

Relational Completeness

Important question: Is it possible to compute all derivable

relations using these operations? → No!
Computational completeness, such as provided by e.g. imperative
programming languages (C++, Java, . . . ) not given
Problems
Negation: return all tuples that are not in a relation.
Recursion: return the transitive closure of a tuple following foreign
key relationships.

An algebra or query language providing the same computational

power as a relational algebra based on the primitive operations is
relationally complete.

Schallehn (FIN/ITI) Advanced Database Models 2019 68 / 358

Further concepts

Data manipulations (insert, delete, update) are described as

status changes of a database relation
Functional dependencies are used to define quality criteria →
normal forms avoid redundancy

Schallehn (FIN/ITI) Advanced Database Models 2019 69 / 358

Relational Database Management Systems

A Relational Database Management System (RDBMS) is a

database management system implementing the relational database
model.

Today, most relational DBMS implement the SQL database model

There are some significant differences between the relational
model and SQL discussed later on

Schallehn (FIN/ITI) Advanced Database Models 2019 70 / 358

Codd’s 12 Rules for RDBMS

Similar intention as 9 rules for DBMS

12 rules list requirements on DBMS implementing the relational
database model
Intended to differentiate RDBMS from other DBMS
Very rigid rules, that even some well established commercial
RDBMS fail to fully comply with
Already include aspects of SQL (e.g. NULL-values)
To add some more confusion: the 12 rules are actually 13

Schallehn (FIN/ITI) Advanced Database Models 2019 71 / 358

Codd’s 12 Rules for RDBMS /1

Rule 0 - System is relational, a database, and a management system: i.e. to

qualify as an RDBMS, it must use its relational facilities
(exclusively) to manage the database.
Rule 1 - The information rule: All information in the database to be
represented only by values in column positions within rows of
tables.
Rule 2 - The guaranteed access rule: All data must be accessible with no
ambiguity, i.e. every individual scalar value in the database
must be logically addressable the name of the containing table,
the name of the column and the primary key value of the
containing row.

Schallehn (FIN/ITI) Advanced Database Models 2019 72 / 358

Codd’s 12 Rules for RDBMS /2

Rule 3 - Systematic treatment of null values: The DBMS must support a

representation of “missing information and inapplicable
information” that is systematic, distinct from all regular values,
and independent of data type.
Rule 4 - Active online catalog based on the relational model: The system
supports a relational catalog that is accessible by means of the
query language.
Rule 5 - The comprehensive data sub-language rule: The system must
support a relational language that has a linear syntax, can be
used interactively and within application programs, supports
data definition and manipulation, security, integrity, and
transactions.

Schallehn (FIN/ITI) Advanced Database Models 2019 73 / 358

Codd’s 12 Rules for RDBMS /3

Rule 6 - The view updating rule: All views that are theoretically updatable
must be updatable by the system.
Rule 7 - High-level insert, update, and delete: Insert, update, and delete
operators can be applied to sets of tuples.
Rule 8 - Physical data independence: Changes to the physical schema level
(how data is stored) must not require a change to the logical
schema.
Rule 9 - Logical data independence: Changes to the logical schema level
must not require a change to an application (external schema
level) based on the structure.

Schallehn (FIN/ITI) Advanced Database Models 2019 74 / 358

Codd’s 12 Rules for RDBMS /4

Rule 10 - Integrity independence: Integrity constraints must be specified

separately from application programs and stored in the catalog.
Rule 11 - Distribution independence: The distribution of portions of the
database to various locations should be invisible to users of the
database.
Rule 12 - The non-subversion rule: If the system provides a low-level
(record-at-a-time) interface, then that interface cannot be used
to subvert the system, for example, bypassing a relational
security or integrity constraint.

Schallehn (FIN/ITI) Advanced Database Models 2019 75 / 358

SQL History

SEQUEL (1974, Chamberlin and Boyce, IBM Research Labs San

Jose)
SEQUEL2 (1976, IBM Research Labs San Jose)
SQL (1982, IBM)
ANSI-SQL (SQL-86; 1986)
ISO-SQL (SQL-89; 1989; Level 1, Level 2, + IEF)
(ANSI / ISO) SQL-92 (full relational standard)
(ANSI / ISO) SQL:1999 (most object-relational extensions,
recursive queries + more)
(ANSI / ISO) SQL:2003 (nested tables, XML, OLAP + more)

Schallehn (FIN/ITI) Advanced Database Models 2019 76 / 358

SQL Data Model

Said to implement relational database model

Defines own terms
Table name Columns

R A1 ... An } Table head

...

... Table
Row
...
Some significant differences exist

Schallehn (FIN/ITI) Advanced Database Models 2019 77 / 358

Differences between SQL and RM

Duplicate rows: The same row can appear more than once in an SQL
table(bag or list), while relations are sets.
Anonymous columns: A column in an SQL table can be unnamed (e.g.
aggregate functions).
Duplicate column names: Two or more columns of the same SQL
table can have the same name.
Column order significance: The order of columns in an SQL table is
defined and significant.
Row order significant: SQL provides operations to provide ordered
results (lists).
NULL-values: can appear instead of a value. Implies the use of
three-valued logic.

Schallehn (FIN/ITI) Advanced Database Models 2019 78 / 358

Structured Query Language

Structured Query Language (SQL): declarative language to

describe requested query results
Realizes relational operations (with the mentioned discrepancies)
Basic form: SELECT-FROM-WHERE-block (SFW)

SELECT FNAME, LNAME, MGRSTARTDATE

FROM EMPLOYEE, DEPARTMENT
WHERE SSN=MGRSSN

Schallehn (FIN/ITI) Advanced Database Models 2019 79 / 358

SQL: Selection σ
σDNO=5∧SALARY >30000 (r (EMPLOYEE))

SELECT *
FROM EMPLOYEE
WHERE DNO=5 AND SALARY>30000

Schallehn (FIN/ITI) Advanced Database Models 2019 80 / 358

SQL: Projection π
πLNAME,FNAME (r (EMPLOYEE))

SELECT LNAME,FNAME
FROM EMPLOYEE

Difference to RM: does not remove duplicates

Requires additional DISTINCT

SELECT DISTINCT LNAME,FNAME

FROM EMPLOYEE

Schallehn (FIN/ITI) Advanced Database Models 2019 81 / 358

SQL: Cartesian Product ×
r (EMPLOYEE) × r (PROJECT )

SELECT *
FROM EMPLOYEE, PROJECT

Schallehn (FIN/ITI) Advanced Database Models 2019 82 / 358

SQL: Natural Join ./
r (DEPARTMENT ) ./ r (DEPARTMENT _LOCATIONS)

SELECT *
FROM DEPARTMENT
NATURAL JOIN DEPARTMEN_LOCATIONS

Schallehn (FIN/ITI) Advanced Database Models 2019 83 / 358

SQL: Equi-Join
r (EMPLOYEE) ./SSN=MGRSSN r (DEPARTMENT )

SELECT *
FROM EMPLOYEE, DEPARTMENT
WHERE SSN=MGRSSN

Schallehn (FIN/ITI) Advanced Database Models 2019 84 / 358

SQL: Union
r (R) ∪ r (S)

SELECT * FROM R
UNION
SELECT * FROM S

Other set operations: INTERSECT, MINUS

Does remove duplicates (in compliance with RM)
If duplicates required:

SELECT * FROM R
UNION ALL
SELECT * FROM S

Schallehn (FIN/ITI) Advanced Database Models 2019 85 / 358

SQL: Other Features

SQL provides several features not in the relational algebra

I Grouping And Aggregation Functions, e.g. SUM, AVG, COUNT, . . .
I Sorting

SELECT PLOCATION, AVG(HOURS)

FROM EMPLOYEE, WORKS_ON, PROJECT
WHERE SSN=ESSN AND PNO=PNUMBER
GROUP BY PLOCATION
HAVING COUNT(*) > 1
ORDER BY PLOCATION

Schallehn (FIN/ITI) Advanced Database Models 2019 86 / 358

SQL DDL

Data Definition Language to create, modify, and delete schema

objects

CREATE DROP ALTER TABLE mytable ( id INT, ...)

DROP TABLE ...
ALTER TABLE ...
CREATE VIEW myview AS SELECT ...
DROP VIEW ...
CREATE INDEX ...
DROP INDEX ...
...

Schallehn (FIN/ITI) Advanced Database Models 2019 87 / 358

Simple Integrity Constraints

CREATE TABLE employee(

ssn INTEGER,
lname VARCHAR2(20) NOT NULL,
dno INTEGER,
...
FOREIGN KEY (dno)
REFERENCES department(dnumber),
PRIMARY KEY (ssn)
)

Additionally: triggers, explicit value domains, ...

Schallehn (FIN/ITI) Advanced Database Models 2019 88 / 358

SQL DML

Data Manipulation Language to create, modify, and delete tuples

INSERT INTO (<COLUMNS>) mytable VALUES (...)

INSERT INTO (<COLUMNS>) mytable SELECT ...

UPDATE mytable
SET ...
WHERE ...

DELETE FROM mytable

WHERE ...

Schallehn (FIN/ITI) Advanced Database Models 2019 89 / 358

Other Parts of SQL

Data Control Language (DCL):

GRANT, REVOKE
Transaction management:
START TRANSACTION, COMMIT, ROLLBACK
Stored procedures and imperative programming concepts
Cursor definition and management

Schallehn (FIN/ITI) Advanced Database Models 2019 90 / 358

 Teil III

Models for Conceptual Design

Overview
Conceptual Database Design
The Entity-Relationship Model
Basic Extensions to the ER Model
Object-oriented Extensions to the ER Model
Mapping ER to the Relational Model
UML as a Conceptual Design Model

Schallehn (FIN/ITI) Advanced Database Models 2019 92 / 358

Models for Conceptual Design

First design stages of a database system

(Mostly) independent of logical design or implementation
Most common and popular design models
I The Entity-Relationship Model (ER Model) as the still
state-of-the-art of conceptual database design
I Numerous Extensions to the ER Model covering semantic and
object-oriented aspects
I The (object-oriented) Unified Modeling Language (UML) developed
for software design but less recently often applied for database
design

Schallehn (FIN/ITI) Advanced Database Models 2019 93 / 358

Database Design Process
Requirements Analysis

Conceptual Design
Conceptual Models
e.g. ER or UML

Database Models
Logical Design
e.g. RM, ORM, OO

Concrete implementation of a database model, e.g.

Data Definition
the object−relational model of the Oracle 10g DBMS

Physical Design

Implementation

Schallehn (FIN/ITI) Advanced Database Models 2019 94 / 358

The Entity-Relationship Model

The Entity-Relationship Model is a data model or diagram for

high-level descriptions of conceptual schemata. It provides a
graphical notation for representing such schemata in the form of
entity-relationship diagrams.

Developed by P. P. Chen in 1976

Based on the Data Structure Model for conceptual design of
Network Model-based database schemata

Schallehn (FIN/ITI) Advanced Database Models 2019 95 / 358

Basic ER Modeling Constructs

Entities – or more precise Entity Types – represent sets of objects in a

given universe of discourse sharing the same properties and relationships
as other instances of this particular Entity Type. Their graphical notation are
rectangular boxes.

Relationships – or Relationship Types – represent how instances of Entity

Types can be related in the universe of discourse. Their graphical notation
are diamond-shaped boxes.

Attributes represent properties of Entity or Relationship Types. Their

graphical notation are rounded boxes or ellipses.

Schallehn (FIN/ITI) Advanced Database Models 2019 96 / 358

Further ER Modeling Constructs

Key attributes: an attribute or a set of attributes may be defined as

identifying for an entity type, i.e. the values are unique
within the set of instances
Relationship cardinalities: used to describe how many times an entity
may participate in a relationship
Relationship roles: assign special names to entities for participation in
a relation
Functional relationships: each entity of one type is assigned an entity
of another type (according to mathematical concept of a
function)

Schallehn (FIN/ITI) Advanced Database Models 2019 97 / 358

Further ER Modeling Constructs /2

N-ary relationships: a relation may be defined for only one

participating entity (unary, self-referential), two (binary,
standard), or more (ternary . . . n-ary)
Weak entities: entities with existential dependency to entity of another
type

Schallehn (FIN/ITI) Advanced Database Models 2019 98 / 358

ER Model: Basic Constructs

Student attends Course

MatrNr Semester ID

Firstname Title

Lastname

Schallehn (FIN/ITI) Advanced Database Models 2019 99 / 358

ER Model: Cardinalities

N:M and 1:N relationships, if not specified N:M

Alternative notation using minimal and maximal number of
participations

N M
Student attends Course

Alternative notation:

[0..n] [3..m]
Student attends Course

Schallehn (FIN/ITI) Advanced Database Models 2019 100 / 358

ER Model: Roles

Can be used to describe participation semantics if not obvious

from entity or relationship type

Manager managed by
Employee manages Project

Schallehn (FIN/ITI) Advanced Database Models 2019 101 / 358

ER Model: Functional Relationships

Assigns instances of one entity type exactly one instance of the

related entity type
Mathematical concept of a function
Not necessarily injective (target entities referenced only once) or
surjective (each target entity is referenced)

Car has Manufacturer

Alternative for:

[1..1] [0..n]
Car has Manufacturer

Schallehn (FIN/ITI) Advanced Database Models 2019 102 / 358

ER Model: Unary Relationship

Self-referential on type-level
Different instances of the same type are related

Husband [0..1] [0..1]

married to

Wife
Person

Schallehn (FIN/ITI) Advanced Database Models 2019 103 / 358

ER Model: N-ary Relationship

Relationship type might involve more than 1 or 2 entity types

Example for ternary relationship type

Lecturer Course

teaches

Room

Schallehn (FIN/ITI) Advanced Database Models 2019 104 / 358

ER Model: N-ary Relationship /2

N-ary relationship type can not be replaced by n binary

relationship types
Semantics of following example different from previous: allows
lecturers to use rooms without a course taking place

Lecturer teaches Course

uses takes place

Room

Schallehn (FIN/ITI) Advanced Database Models 2019 105 / 358

ER Model: Weak Entity Types

Existential dependency to other entity Types

Identity (key attribute) includes key of master entity type
Relationship between weak entity type and its master type is
called identifying relationship

N 1
Building has Room

Schallehn (FIN/ITI) Advanced Database Models 2019 106 / 358

Basic Extensions to the ER Model

Total or partial participation

Complex attributes
Derived attributes
Multi-valued attributes

Schallehn (FIN/ITI) Advanced Database Models 2019 107 / 358

ER Extensions: Total Participation

Each entity of one type must relate to at least one of the other
entity type at least once
Graphical notation: thick or double line
Difference to functional relationship: entity may participate in
relationship several time

Student of University

Alternative for:

[1..n] [0..n]
Student of University

Schallehn (FIN/ITI) Advanced Database Models 2019 108 / 358

ER Extensions: Partial Participation

Standard case: each entity of one type may or may not relate to
one or more entities of the other entity type
Graphical notation: thin line
Optional N:M-relationship

Person owns Car

Alternative for:
[0..n] [0..n]
Person owns Car

Schallehn (FIN/ITI) Advanced Database Models 2019 109 / 358

ER Extensions: Complex Attributes

Composite attributes consisting of atomic attributes of different

types

Person

SSN
City
Name
Street
Address
ZIPcode

Schallehn (FIN/ITI) Advanced Database Models 2019 110 / 358

ER Extensions: Multi-valued Attributes

Composite attributes consisting of variable set of values of the

same type

Person

SSN

Name

PhoneNumbers

Schallehn (FIN/ITI) Advanced Database Models 2019 111 / 358

ER Extensions: Complex Attributes

Virtual attribute with value that can be computed from other

attributes or via relationships

Person

SSN

Name

BirthDate

Age

Schallehn (FIN/ITI) Advanced Database Models 2019 112 / 358

Basic ER Extensions Summary

Only most common extensions were introduced here

Many others exist in books and DB design tools
Many different notations exist for the same concepts

Schallehn (FIN/ITI) Advanced Database Models 2019 113 / 358

Object-oriented Extensions to the ER Model

Specialization as the derivation of sub-types

I Semantic concept of the is_a-relationship
I Various notations exist
I Total or partial
I Disjunctive or overlapping
I Multiple inheritance
Generalization: inverse specialization, creation of a super-type
Usually no special constructs for typical OO aspects
I Description of behavior and dynamics (methods, states, etc.)
I Aggregation, grouping/association

Schallehn (FIN/ITI) Advanced Database Models 2019 114 / 358

OO ER Extensions: Notations

Can be partially expressed using previously introduced constructs

Semantic of inheritance is lost, if is_a-relationship is not defined
as “special” relation

SSN
Person
Name

is_a

MatrNr

Student
Faculty

Schallehn (FIN/ITI) Advanced Database Models 2019 115 / 358

OO ER Extensions: Notations /2

Notation used in Heuer/Saake

SSN
Person
Name

MatrNr

Student
Faculty

Schallehn (FIN/ITI) Advanced Database Models 2019 116 / 358

OO ER Extensions: Notations /3

Notation used in Elmasri/Navathe

Half circle hints at subset relation students ⊂ persons

SSN
Person
Name

MatrNr

Student
Faculty

Schallehn (FIN/ITI) Advanced Database Models 2019 117 / 358

OO ER Extensions: Total/Partial Specialization

Total specialization: every instance of a type must be an instance of at

least one sub-type (super-type is abstract)
Partial specialization: instance of a type can be instance of sub-types
or instance of only type itself (super-type can be
instantiated and is not abstract)

Schallehn (FIN/ITI) Advanced Database Models 2019 118 / 358

OO ER Extensions: overlapping/disjunctive
Specialization

Disjunctive specialization: instance of super-type can be instance of at

most one sub-type (typical in programming languages)
Overlapping specialization: instance of a super-type can be instance
of one or more sub-types (similar to role concept, where
objects can be assigned different “roles”)

Difference to multiple inheritance: MI allows several super-types

for one type

Schallehn (FIN/ITI) Advanced Database Models 2019 119 / 358

OO ER Extensions: Specialization /1

Partial specialization: employees may be neither managers nor

apprentices: managers ∪ apprentices ⊂ employees
Distinctiveness: managers ∩ apprentices = ∅

Employee

Manager Apprentice

Schallehn (FIN/ITI) Advanced Database Models 2019 120 / 358

OO ER Extensions: Specialization /2

Total specialization: a person is either a woman or a man:

men ∪ women = persons
Distinctiveness: men ∩ women = ∅

Person

Man Woman

Schallehn (FIN/ITI) Advanced Database Models 2019 121 / 358

OO ER Extensions: Specialization /3

Overlapping specialization: a person may be a lecturer, a student,

or both (a tutor)
Multiple inheritance may be used to describe overlapping type:
tutors = lecturers ∩ students

Person

Lecturer Student

Schallehn (FIN/ITI) Advanced Database Models 2019 122 / 358

OO ER Extensions: Specialization /4

Person

Lecturer Student

Tutor

Schallehn (FIN/ITI) Advanced Database Models 2019 123 / 358

Mapping ER to the Relational Model

Schemata expressed using semantically rich ER model must be

mapped to flat relation schemata with atomic attributes
I without losing information
I without introducing ambiguities
I without introducing redundancy
Straightforward rules
I Entities map to relations
I Cardinalities indicate whether relationships become relations

Schallehn (FIN/ITI) Advanced Database Models 2019 124 / 358

Mapping Rules /1
ER Model Relational Model
Entity Relation
Attribute Attribute
Primary key Primary key
N:M relationship Relation with keys of participating
entity types plus own attributes

Schallehn (FIN/ITI) Advanced Database Models 2019 125 / 358

Mapping Rules /2
ER Model Relational Model Condition
1:N or 1:1 Foreign key plus re- Relationship is total
relationship lationship attributes (not optional)
included in participa-
ting N-relation
1:N or 1:1 Relation with keys Relationship is parti-
relationship of participating entity al (optional)
types plus own attri-
butes
N-ary relati- Relation with keys
onship of participating entity
types plus own attri-
butes

Schallehn (FIN/ITI) Advanced Database Models 2019 126 / 358

Mapping Rules /3
ER Model Relational Model
Complex attributes Set of flat attributes
Derived attributes n.a.
Multi-valued attributes Additional relation with primary key
of master relation as foreign key

Schallehn (FIN/ITI) Advanced Database Models 2019 127 / 358

Mapping OO to RM

No support for specialization in the relational database model

Different ways to map OO schema have different disadvantages
I Loss of information (polymorphism not expressible)
I Inefficient access (requiring queries including union or join)
I Redundancy
Three most common mappings described here

Schallehn (FIN/ITI) Advanced Database Models 2019 128 / 358

OO to RM: Example

Person SSN

Name

MatrNr Institute
Student Lecturer
Faculty Salary

Schallehn (FIN/ITI) Advanced Database Models 2019 129 / 358

OO to RM: Solution 1

Map all types to relations with only direct attributes,

inheritance relationship expressed by foreign key
Requires join operation to access sub-types

Person(SSN, Name)

Student(SSN, MatrNr, Faculty)

Lecturer(SSN, Institute, Salary)

Schallehn (FIN/ITI) Advanced Database Models 2019 130 / 358

OO to RM: Solution 2

Map all (non-abstract) sub-types to relations with all direct

and derived attributes
Requires projection and union operations to access super-type
Not suitable for partial inheritance

Student(SSN, Name, MatrNr, Faculty)

Lecturer(SSN, Name, Institute, Salary)

Schallehn (FIN/ITI) Advanced Database Models 2019 131 / 358

OO to RM: Solution 3

Map all types to one generalized relation with all attributes of

all super- and sub-types plus a discriminator attribute to
indicate type membership
Introduces redundancy
Requires selection to access sub-types

Person(SSN, Name, PersonType, MatrNr, Faculty, Institute, Salary )

Schallehn (FIN/ITI) Advanced Database Models 2019 132 / 358

UML as a Conceptual Design Model

Object modeling and specification language by the Object

Management Group (OMG)
Developed in the early ’90s for OO software engineering
Integrates different OO modeling approaches by Grady Booch,
Ivar Jacobson, and James Rumbaugh
Becomes increasingly popular for database design

Schallehn (FIN/ITI) Advanced Database Models 2019 133 / 358

Parts of UML

Consists of several diagram types, but class diagram most

relevant for database design

Class diagram Use Case diagram

Component diagram State Machine diagram
Object diagram Sequence diagram
Composite structure Collaboration
diagram
Interaction overview
Deployment diagram diagram
Package diagram Timing diagram
Activity diagram Object Constraint
Language

Schallehn (FIN/ITI) Advanced Database Models 2019 134 / 358

UML for Database Design

In general, all concepts of ER and its extensions can be

expressed using UML class diagram
I Classes conform to entity types
I Associations conform to relationship types
Several additional concepts not required for purely relational
database design
Some concepts potentially useful for DB design, e.g.
I Aggregation from class diagrams
I Object diagrams to describe instance level
I Object Constraint Language (OCL)
I Use case diagrams to model interaction

Schallehn (FIN/ITI) Advanced Database Models 2019 135 / 358

UML classes

UML classes allow specifying many concepts typical in software

engineering: interfaces, encapsulation, templates/generics, default
values, methods, etc.

Employee
+ID: integer
+Name: string
+Department: integer = 7
-Salary
-raiseSalary(percent:integer)
+changeDepartment()

Schallehn (FIN/ITI) Advanced Database Models 2019 136 / 358

ER and UML example

Student attends Course

MatrNr Semester ID

Firstname Title

Lastname

Student Course
0..* attends 0..*
MatrNr ID
Firstname Title
Lastname
Semester

Schallehn (FIN/ITI) Advanced Database Models 2019 137 / 358

UML Specialization

Person
Firstname
Lastname

Student Lecturer
MatrNr Institute
Faculty Salary

Schallehn (FIN/ITI) Advanced Database Models 2019 138 / 358

UML Aggregation

Describes composition of complex objects from other objects

Existencial dependency:
1 *
Book Chapter

No existencial dependency:
1 5..20
Team Member

Schallehn (FIN/ITI) Advanced Database Models 2019 139 / 358

UML Object Diagram

Country Australia:Country
Name Australia
Continent Australia

China:Country

China
Asia

Germany:Country

Germany
Europe

Schallehn (FIN/ITI) Advanced Database Models 2019 140 / 358

UML Use Case Diagram

Search Courses

Create Timetable
Select Courses
Student

Save Timetable

Create Courses

Update Courses

Employee
Delete Courses

Schallehn (FIN/ITI) Advanced Database Models 2019 141 / 358

 Teil IV

NF 2 and eNF 2 Data Models

Overview
The NF 2 Database Model
The eNF 2 Database Model
eNF 2 Concepts in SQL:1999 and SQL:2003
eNF 2 in Oracle

Schallehn (FIN/ITI) Advanced Database Models 2019 143 / 358

The NF 2 Database Model

First normal form basic requirement of the relational database

model
I Unambiguous addressability of values
I Simple operations for access
Requires complex objects to be stored in various relations
I Loss of semantics not intuitive
I Often inefficient (joins required)
First (theoretical) extensions of the RM
I Nested relations: NF 2
I Type constructors and free combination: eNF 2
Today part of SQL:1999, SQL:2003, and commercial systems

Schallehn (FIN/ITI) Advanced Database Models 2019 144 / 358

The NF 2 Database Model /2

NF 2 -relations – or nested relations – provide non-atomic attributes

by allowing an attribute to be of a relation type (schema) and a value
of such an attribute to be a (nested) relation.

NF 2 = NFNF = Non First Normal Form

New Requirements
I Operations as extension to relational algebra
I Normal form to provide consistency

Schallehn (FIN/ITI) Advanced Database Models 2019 145 / 358

NF 2 Example Relation

Department Employees
SSN Name Telephones Salary
Telephone
038203-12230
4711 Todd 0381-498-3401 6000
0381-498-3427
5588 Whitman 0391-345677 6000
0391-5592-3800
Computer Science 7754 Miller 550
8832 Kowalski 2800
Mathematics 6834 Wheat 750

Schallehn (FIN/ITI) Advanced Database Models 2019 146 / 358

NF 2 Algebra

∪, −, π, ./ as in relational algebra
σ condition extended to support
I Relations as operands (instead of constants of basic data types)
I Set operations like θ: =, ⊆, ⊂, ⊃, ⊇
Recursively structured operation parameters, e.g.
I π : nested projection attribute lists
I σ : selection conditions on nested relations
Additional operations
I ν (Nu) = Nest
I µ (Mu) = Unnest

Schallehn (FIN/ITI) Advanced Database Models 2019 147 / 358

NF 2 : Nest and Unnest

A D
A B C −→ B C
1 2 7 νB,C;D (r )
2 7
1 3 6
←− 1 3 6
1 4 5
µD (r 0 ) 4 5
2 1 1
2 1 1

Schallehn (FIN/ITI) Advanced Database Models 2019 148 / 358

NF 2 : Nest and Unnest /2
Nesting not generally reversible:

A D
A B C 6−→ B C
1 2 7 νB,C;D (r )
1 2 7
1 3 6
3 6
1 4 5 ←−
µD (r 0 ) 1 4 5
2 1 1
2 1 1

Schallehn (FIN/ITI) Advanced Database Models 2019 149 / 358

NF 2 : Partitioned Normal Form

The Partitioned Normal Form (PNF) requires a flat key on every

nesting level of a nested relation.

A D
A C
B C
B D
1 2 3
PNF relation: Non-PNF relation: 1 2
4 2
2 3
2 1 1
1 3
4 1
2 4
3 1 1

Schallehn (FIN/ITI) Advanced Database Models 2019 150 / 358

NF 2 : Partitioned Normal Form /2
PNF relation and unnested equivalent relation

A D
B C A B C
1 2 3
1 2 3
1 4 2
4 2
2 1 1
2 1 1
2 4 1
4 1
3 1 1
3 1 1

Schallehn (FIN/ITI) Advanced Database Models 2019 151 / 358

The eNF 2 Database Model

Extended NF 2 Model (eNF 2 Model)

Relaxes NF 2 model by introducing various type constructors and
allowing their free combination
Type constructors:
I set: create a set type of the nested type,
I tuple: tuple type of nested type,
I list: list type of nested type,
I bag: bag (multi-set) type of nested type
I array[..]: array type of nested type
First two are also available in RM and NF 2
Additionally, can be combined freely,
e.g. set of bag of integer

Schallehn (FIN/ITI) Advanced Database Models 2019 152 / 358

eNF 2 : Combination of Type Constructors

RM/SQL NF2 eNF2

set set set list

tuple tuple tuple

atomic atomic atomic

Schallehn (FIN/ITI) Advanced Database Models 2019 153 / 358

eNF 2 : Combination of Type Constructors /2

Also called Parameterizable Data Types

Construction based on input data types:
I Basic/atomic data types
I Input data type complex itself
Define own operations for access and modification
Similar to pre-defined parameterizable data types of programming
languages
I Generics in Java java.util
I Templates in C++ STL
Array, list, bag, and set type constructors are also called collection
data types

Schallehn (FIN/ITI) Advanced Database Models 2019 154 / 358

eNF 2 : Tuple Type Constructor

Tuple Type Constructor (tuple) – fixed number of components of

different (heterogeneous) types
Access to components based on field (attribute) name
Based on idea of Cartesian product
Operations
I tuple constructor
I Component access using (.), e.g. address.street
Example: pre-defined tuple types: Date, Timestamp

Date: tuple(Day: integer, Month: integer,

Year: integer)

Schallehn (FIN/ITI) Advanced Database Models 2019 155 / 358

eNF 2 : Set Type Constructor

Set Type Constructor (set) – finite set of instances of same

(homogeneous) type
Contains no duplicates
Value domain is power set of values in input type

Telephones: set(string)

Schallehn (FIN/ITI) Advanced Database Models 2019 156 / 358

eNF 2 : Set Type Constructor /2
Set operations:
set: Constructor: create an empty set
insert: insertion of an element
remove: deletion of an element
in: test for containment of an element
union: union of two sets
intersection: intersection of two sets
difference: set difference of two sets
count: cardinality of a set

Schallehn (FIN/ITI) Advanced Database Models 2019 157 / 358

eNF 2 : Combination of Set and Tuple

Price_Supplier: set(tuple(
Supplier: string,
Article: string
Price: integer))

Prices of an article depending on supplier

Equivalent to relational model

Schallehn (FIN/ITI) Advanced Database Models 2019 158 / 358

eNF 2 : Bag Type Constructor

Bag Type Constructor (bag) – finite multi-set of instances of same

(homogeneous) type
Allows duplicates
Similar operations as set type constructor
I Insertion and deletion considers duplicate entries
I Containment test returns number of same entries
I Union of bags keeps duplicate entries (UNION ALL)
I Intersection returns minimal number of same entries of both input
bags

Schallehn (FIN/ITI) Advanced Database Models 2019 159 / 358

eNF 2 : Bag Type Constructor

List Type Constructor (list) – finite sorted collection of instances

of same (homogeneous) type
Allows duplicates
Operations similar to set +
I insert at various positions: first, last, or n
I append to concatenate two lists
I Element access using explicit position [n]

Schallehn (FIN/ITI) Advanced Database Models 2019 160 / 358

eNF 2 : Bag Type Constructor /2

Authors of a document:

Authors: list(tuple(Firstname: string,

Lastname: string))

Schallehn (FIN/ITI) Advanced Database Models 2019 161 / 358

eNF 2 : Bag Type Constructor

Array Type Constructor (array[..]) – fixed (maximal) number of

instances of a same (homogeneous) type
Allows duplicates
One-dimensional, multiple dimension by means of nesting arrays
Access and modification of an entry by means of explicit position
[n]

Schallehn (FIN/ITI) Advanced Database Models 2019 162 / 358

eNF 2 : Bag Type Constructor /2

Each employee can have up to 4 telephones

Telephones: array [1..4] of string

Schallehn (FIN/ITI) Advanced Database Models 2019 163 / 358

eNF 2 : Comparison of Type constructors

Type Dupli- #Elements Order Element Hetero-

cates access genity
√ √ √
Tuple constant Name
√ √
Array constant Index —
√ √
List variable Iterator/Pos. —
√
Bag variable — Iterator —
Set — variable — Iterator —

Schallehn (FIN/ITI) Advanced Database Models 2019 164 / 358

eNF 2 Concepts in SQL:1999 and SQL:2003

SQL:1999 introduced numerous extensions to type system

I New data types: BOOLEAN, LOB
I Distinct types
I Type constructors: ROW,ARRAY
I Structured object types with type hierarchies and methods
I Object identities and REF type constructor
I Multi-media data types
SQL:2003 focused on other parts of the language (e.g. XML
extensions), only few changes to type system
I Bag type constructor MULTISET
I XML data types
Implementations in commercial DBMS most often do NOT comply
to standard!!

Schallehn (FIN/ITI) Advanced Database Models 2019 165 / 358

ROW Type Constructor

ROW implements tuple type constructor

Example usage as embedded type:

CREATE TABLE Customers (

Name VARCHAR(40),
Address ROW (Street VARCHAR(30),
Town VARCHAR(30),
Zip VARCHAR(10)));

Schallehn (FIN/ITI) Advanced Database Models 2019 166 / 358

ROW Type Constructor /2

Creation of tuples requires call of row constructor

INSERT INTO Customers

VALUES (’Myers’, ROW(’42nd’,’NY’,’111’));

Schallehn (FIN/ITI) Advanced Database Models 2019 167 / 358

ROW Type Constructor /3

Components can be accessed using .

SELECT Name, Address.Town

FROM Customers;

Schallehn (FIN/ITI) Advanced Database Models 2019 168 / 358

ARRAY Type Constructor

ARRAY of fixed length

CREATE TABLE Contacts (

Name VARCHAR(40),
PhoneNumbers VARCHAR(20) ARRAY[4],
Addresses ROW (Street VARCHAR(30),
Town VARCHAR(30),
Zip VARCHAR(10)) ARRAY[3]);

Schallehn (FIN/ITI) Advanced Database Models 2019 169 / 358

ARRAY Type Constructor /2

Creation of tuples requires call of array constructor

INSERT INTO Contacts

VALUES (’Myers’,
ARRAY[’1234’,’5678’],
ARRAY[ROW(’42nd’,’NY’,’111’)]);

UPDATE Contacts
SET PhoneNumbers[3]=’91011’
WHERE Name=’Myers’;

Schallehn (FIN/ITI) Advanced Database Models 2019 170 / 358

ARRAY Type Constructor /3

Array components can be accessed in two ways

Explicit position: using the array position [n]
Unnesting of collection: using the UNNEST operation in the
FROM-clause allows declarative access to flattened
relation
Further operations: size CARDINALITY() and concatenation ||

Schallehn (FIN/ITI) Advanced Database Models 2019 171 / 358

ARRAY Type Constructor /4

Explicit position

SELECT Name, PhoneNumbers[1]

FROM Contacts;

Unnesting of array

SELECT Name, Tel.*

FROM Contacts,
UNNEST (Contacts.PhoneNumbers) Tel (Phone, Pos)
WITH ORDINALITY
WHERE Name=’Myers’;

Schallehn (FIN/ITI) Advanced Database Models 2019 172 / 358

MULTISET Type Constructor

MULTISET implements bag type constructor

Allows creation of nested tables (NF 2 )
Can be combined freely with other type constructors (eNF 2 )

Schallehn (FIN/ITI) Advanced Database Models 2019 173 / 358

MULTISET Type Constructor /2

Operations:
I MULTISET constructor
I UNNEST as for arrays
I COLLECT: special aggregate function to implement NEST operation
I FUSION: special aggregate function to build union of aggregated
multi-sets
I UNION and INTERSECT
I CARDINALITY as for arrays
I SET to remove duplicates
Predicates:
I MEMBER: containment
I SUBMULTISET: multi-set containment
I IS A SET: test if duplicates exist

Schallehn (FIN/ITI) Advanced Database Models 2019 174 / 358

MULTISET Type Constructor /3

CREATE TABLE Departments (

Name VARCHAR(40),
Buildings INTEGER MULTISET,
Employees ROW (Firstname VARCHAR(30),
Lastname VARCHAR(30),
Office INTEGER) MULTISET);

Schallehn (FIN/ITI) Advanced Database Models 2019 175 / 358

MULTISET Type Constructor /4

INSERT INTO Departments

VALUES (’Computer Science’,
MULTISET[29,30],
MULTISET(ROW(...)));

INSERT INTO Departments

VALUES (’Computer Science’,
MULTISET[28],
MULTISET(SELECT ... FROM ...);

UPDATE Departments
SET Buildings=Buildings
MULTISET UNION MULTISET[17]
WHERE Name=’Computer Science’;

Schallehn (FIN/ITI) Advanced Database Models 2019 176 / 358

MULTISET Type Constructor /5

Unnesting of a multi-set

SELECT Name, Emp.LastName

FROM Departments,
UNNEST (Departments.Employees) Emp;

Schallehn (FIN/ITI) Advanced Database Models 2019 177 / 358

MULTISET Type Constructor /6

Nesting using the COLLECT aggregation function

SELECT Name, COLLECT(hobby) AS hobbies

FROM Person NATURAL JOIN SpareTime,
GROUP BY Name;

Schallehn (FIN/ITI) Advanced Database Models 2019 178 / 358

eNF 2 in Oracle

Oracle supports majority of standard functionality as part of its

object-relational extension (since Oracle 8i)
I Row type constructor as OBJECT type
I Array type constructor as VARRAY type
I Multiset type constructor as NESTED TABLE type
Uses different syntax than standard

Schallehn (FIN/ITI) Advanced Database Models 2019 179 / 358

Oracle OBJECT type

Type constructor and basis for object-oriented features of Oracle

data model
User-defined object types can be used for
I Embedded structured attributes
I (Object) table types
I Variables
I Parameters and return values of methods
Needs to be defined explicitly by CREATE TYPE statement
Constructor call required where ambiguities may exist

Schallehn (FIN/ITI) Advanced Database Models 2019 180 / 358

Oracle CREATE TYPE statement

CREATE TYPE AddressType AS OBJECT(

Street VARCHAR(30),
Town VARCHAR(30),
Zip VARCHAR(10));

CREATE TYPE PersonType AS OBJECT (

Name VARCHAR(40),
Address AddressType);

CREATE TABLE Persons OF PersonType;

INSERT INTO Persons

VALUES (’M’,AddressType(’42nd’,’NY’,’1111’));

Schallehn (FIN/ITI) Advanced Database Models 2019 181 / 358

Oracle VARRAY type

Similar to ARRAY from SQL:1999

Can only be used indirectly through type definition with
CREATE TYPE
Actual array is stored as LOB
I in-line: within record
I out-of-line: separate from record
Access through unnest operation TABLE

Schallehn (FIN/ITI) Advanced Database Models 2019 182 / 358

Oracle VARRAY type /2

CREATE TYPE AddressListType

AS VARRAY(4) OF AddressType;

CREATE TYPE PhoneListType

AS VARRAY(4) OF VARCHAR(20);

CREATE TABLE Contacts (

Name VARCHAR(20),
PhoneList PhoneListType,
AddressList AddressListType);

INSERT INTO Contacts

VALUES (’Bates’,
PhoneListType((’1’),(’2’),(’3’)),
AddressListType(AddressType(...)));

Schallehn (FIN/ITI) Advanced Database Models 2019 183 / 358

Unnesting using the TABLE operator

Used similar as UNNEST in SQL:1999: computes Cartesian product

within nested record
Access to flattened records of basic types may require VALUE operator

SELECT *
FROM Contacts, TABLE(Contacts.PhoneList) tel
WHERE VALUE(tel)=’2’;

SELECT *
FROM Contacts,
TABLE(Contacts.PhoneList)
TABLE(Contacts.AddressList);

Schallehn (FIN/ITI) Advanced Database Models 2019 184 / 358

Oracle TABLE type

Similar to MULTISET from SQL:1999

Like VARRAY: can only be used indirectly through type definition
with CREATE TYPE
Actual nested table is stored as separate table – needs to be
named during outer table creation
Access through unnest operation TABLE
COLLECT aggregate function for nesting

Schallehn (FIN/ITI) Advanced Database Models 2019 185 / 358

Oracle TABLE type /2

CREATE TYPE EmployeeListType

AS TABLE OF PersonType;

CREATE TABLE Departments (

Name VARCHAR(40),
EmployeeList EmployeeListType)
NESTED TABLE EmployeeList STORE AS EmpTable;

INSERT INTO Departments

VALUES (’Product Development’,
EmployeeListType(
PersonType(’Lector’,...),
PersonType(’Jason’,...)));

Schallehn (FIN/ITI) Advanced Database Models 2019 186 / 358

Unnesting and Nesting Tables

SELECT *
FROM Departments,
TABLE(Departments.EmployeeList) emps;

SELECT Companies.Name,COLLECT(Subsidiaries.Town)
FROM Companies NATURAL JOIN Subsidiaries
GROUP BY(Companies.Name);

Schallehn (FIN/ITI) Advanced Database Models 2019 187 / 358

 Teil V

Object-oriented Data Models

Overview
Object-oriented Database Management Systems
Concepts of OO Data Models
Concepts of ODBMS
The ODMG Standard

Schallehn (FIN/ITI) Advanced Database Models 2019 189 / 358

Object-oriented Database Management Systems

Based on the development of

I Object-oriented analysis and design (OOA, OOD)
I Object-oriented programming (OOP)
I Object-oriented distributed computing (e.g. CORBA)
Objectives:
I More and advanced semantic concepts to describe real world facts
I More efficiency for non-standard applications
I Overcome impedance mismatch between RM and OOP

Schallehn (FIN/ITI) Advanced Database Models 2019 190 / 358

Definition

An Object-oriented Database Management System (ODBMS) is a

database management systems that implements an object-oriented
data model.

Problem: there is no ONE object-oriented model, but several

offering similar concepts
Basic requirements were listed in The Object-oriented Database
System Manifesto (Atkinson et al., 1989)
ODMG supposed to provide a standard for ODBMS (1993), but
limited support by commercial systems

Schallehn (FIN/ITI) Advanced Database Models 2019 191 / 358

History

First research prototypes in the early ’80s (ORION, ITASCA,

EXODUS)
First commercial systems in the late ’80s/ early ’90s (GemStone,
ONTOS, Objectivity, ObjectStore, Versant, Poet, O 2 )
First version of the ODMG standard in 1994
Heydays during the mid-’90s
Systems easily integrated support for Java, the WWW, XML,
multi-media, spatial data, etc.
Since mid-’90s: RDBMS integrated object-oriented concepts into
their systems → ORDBMS
Few commercial ODBMS survived until today

Schallehn (FIN/ITI) Advanced Database Models 2019 192 / 358

Different Approaches

Based on OOP data models: these ODBMS used the standardized data
models of popular OO programming languages such as C++
(ONTOS, Objectivity, ObjectStore, Versant, Poet) or Smalltalk
(GemStone), later on Java (Jasmine, JD4O), and added DBMS
functionality (persistence, TXNs, collection types, queries, . . . )
Extensions of relational models: introduce object-oriented concepts
(types/classes, inheritance, object identity, methods, . . . ) in a
relational model (Postgres, Illustra) or build on top of existing
DBMS (Oracle, DB2, . . . ) → object-relational DBMS
Innate OO database models: developed independently of existing models
and systems (O 2 , ORION, Itasca)

Schallehn (FIN/ITI) Advanced Database Models 2019 193 / 358

Object Database Management Systems

Most successful system were tightly integrated with OOPL

I C++: Versant, Objectivity, Poet (now Versant Fast Objects)
I Smalltalk: GemStone
→ solved problem of Impedance Mismatch!
Object-relational systems provide similar concepts but are
decoupled from programming language (advantages of logical
data independence)

Schallehn (FIN/ITI) Advanced Database Models 2019 194 / 358

Advantages of ODBMS

Provide semantically rich object-oriented modeling constructs

Solve Impedance Mismatch
Decreased implementation efforts
I Developer needs knowledge of only one data model
I No mapping code/layer required
Efficiency for applications with complex data (navigational access,
no joins required)

Schallehn (FIN/ITI) Advanced Database Models 2019 195 / 358

Disadvantages of ODBMS

No logical data independence

I Application changes may trigger schema changes
I Schema changes require application changes
Existing standard (ODMG) is hardly implemented
Lack of interoperability
Many systems with insufficient support for typical DBMS
functionality
I Logical views
I Query languages
I Query/access optimization
I TXNs
I Distribution
I ...

Schallehn (FIN/ITI) Advanced Database Models 2019 196 / 358

The Object-oriented Database System Manifesto

Though there is no common OO data(base) model, all models

share important characteristics
The Object-oriented Database System Manifesto summarized
minimum requirements
I Mandatory features: the Golden Rules
F Object-oriented concepts
F Database concepts
I Optional features: the goodies
I Open choices

Schallehn (FIN/ITI) Advanced Database Models 2019 197 / 358

OO Manifesto: Golden Rules /1

OO concepts (part I of mandatory concepts)

I Complex objects
I Object identity
I Encapsulation
I Types and/or Classes
I Class and/or Type Hierarchies
I Overriding, overloading and late binding
I Computational completeness
I Extensibility

Schallehn (FIN/ITI) Advanced Database Models 2019 198 / 358

OO Manifesto: Golden Rules /2

DBMS concepts (part II of mandatory concepts)

I Persistence
I Secondary storage management
I Concurrency
I Recovery
I Ad Hoc Query Facility

Schallehn (FIN/ITI) Advanced Database Models 2019 199 / 358

OO Manifesto: The Goodies

Optional concepts that may be implemented

I Multiple inheritance
I Type checking and type inferencing
I Distribution
I Design transactions
I Versions

Schallehn (FIN/ITI) Advanced Database Models 2019 200 / 358

OO Manifesto: Optional Choices

A very short discussion of further design considerations

I Programming paradigm
I Representation system
I Type system
I Uniformity

Schallehn (FIN/ITI) Advanced Database Models 2019 201 / 358

Complex Objects and Extensibility

System must provide basic types: integer, float, boolean,

character, strings
System must provide at least the following type constructors for
complex objects
I tuple
I set
I list
Complex objects may require specific operations, e.g.
I deep or shallow delete
I deep or shallow copy
Extensibility: user-defined types can be used in the same way as
system-defined types

Schallehn (FIN/ITI) Advanced Database Models 2019 202 / 358

Object Identity

The object identity of an object represents the fact, that it has an

existence which is independent of all its values. Two objects are
identical if they have the same object identity. Two objects are equal
if they have the same values.

Used for referencing objects (similar to OOPL pointers or

references)
Can be mapped to physical location or logical address (e.g. table,
primary key)
May be system- or user-generated

Schallehn (FIN/ITI) Advanced Database Models 2019 203 / 358

Object Identity /2

Equality for complex objects

I objects are shallow equal if they refer to identical component
objects
I objects are deep equal if they refer to (deep) equal component
objects
Object identity must be unique and non-volatile
I in time: can not change and can not be re-assigned to another
object, when the original object is deleted
I in space: must be unique within and across database boundaries

Schallehn (FIN/ITI) Advanced Database Models 2019 204 / 358

Types and/or Classes

Manifesto requires support of types or classes

Abstraction of common features of a set of objects with the same
characteristics
Differences in definitions exist for OO programing languages

A type describes the intension, i.e. the internal (the set of encapsulated,
possibly complex attributes) and external structure (the interface of the type
with methods and their signatures).

A class consists of a type description, and in addition includes the notions

of an object factory (e.g. constructors) and of a class extension which
represents the set of all instances of each particular class.

Schallehn (FIN/ITI) Advanced Database Models 2019 205 / 358

Encapsulation

Encapsulation represents the postulation, that only the interface

part of a type is visible to the users of the type, the implementation of
the object is seen only by the type designer.

Compile-time aspect of OOPL

I Access modifiers, e.g. public (accessible for all), private
(accessible within class), protected (accessible within class or
derived class) checked by compiler
I Strict encapsulation allows access to internal structure (attributes)
only via interface (methods)
Becomes run-time aspect for DBMS

Schallehn (FIN/ITI) Advanced Database Models 2019 206 / 358

Type and Class Hierarchies

Type and class hierarchies imply several aspects

Specialization inheritance, or intensional specialization, between a

super-type A and a subtype B means that the set of attributes and methods
defined in A are a subset of the attributes and methods defined in B.

Substitution inheritance, or extensional specialization, between a

superclass A and a subclass B means that the set of instances of B are a
subset of the instance of class B. Polymorphism means that all instances
of class B can be used wherever objects of class A can be used
(substitutability).

Schallehn (FIN/ITI) Advanced Database Models 2019 207 / 358

Type and Class Hierarchies /2
Intensional Specialization
Person Hart:Person
Firstname
Melissa MatrNr
Lastname Hart
Firstname
Faculty Lastname

Subtype Supertype
Smith:Student

John Extensional Specialization

Smith
154333
Student Comp Science
MatrNr Smith Hart
Faculty Jones
Jones:Student

Eva
Jones
146444
Mathematics Superclass Subclass

Schallehn (FIN/ITI) Advanced Database Models 2019 208 / 358

Overriding, Overloading and Late Binding
Different aspects of polymorphism:
Method overloading: allows method signatures to be re-defined within
a class or in derived classes with different return or
parameter types.
Method overriding: allows method implementations to be re-defined in
derived classes.
Late Binding: the correct implementation of an overridden method of
an object is determined and executed during run-time.

Schallehn (FIN/ITI) Advanced Database Models 2019 209 / 358

Computational Completeness

ODBMS require tight integration with computationally complete

programming language for
I Method implementations
I Navigational access
I Control of DBMS functionality (persistence, TXNs, etc.)
Not typical for RDBMS: only offer relational completeness
Computational completeness often realized by means of
integration with language of implemented data model (C++,
Smalltalk, Java, . . . )
O 2 and object-relational systems also offer own languages

Schallehn (FIN/ITI) Advanced Database Models 2019 210 / 358

Concepts of ODBMS

ODBMS require non-standard functionality beyond definition of

data model
I How are schemas defined (DDL) an implemented?
I How is data made persistent and modified (DML)?
I How is data accessed and queried?
I How is consistency and concurrency controlled (advanced TXN
models)

Schallehn (FIN/ITI) Advanced Database Models 2019 211 / 358

Schema Definition and Implementation
Schema definition:

Application-independent: ODMG ODL files

Application-dependent: source or object files of C++, Java, Smalltalk, C#,
etc. application

Schema implementation:

Pre-processor: tool that takes source files (.h,.java,.odl, etc.) as input

and creates modified or new (.odl) source code, possibly with
added functionality / interfaces / super-classes, and,
furthermore, installs the schema in the database
Post-processor: tool that derives the according schema information from an
object file (.o, .obj, .class, etc.), possibly modifies the
object file, and installs the schema

Schallehn (FIN/ITI) Advanced Database Models 2019 212 / 358

Sample Input Files

Java : public abstract class Person {

private String firstname, lastname;
}

C++ : class Person {

private:
char* _firstname, _lastname;
};

ODL : class Person (

extent persons) {
attribute string firstname;
attribute string lastname;
}

Schallehn (FIN/ITI) Advanced Database Models 2019 213 / 358

ODMG C++ Preprocessor

ODL File

Generated C++ .cc

ODL Preprocessor C++ .h File Source File

C++ Compiler and

Linker

Database
Schema Executable DBMS
Application
Database

Schallehn (FIN/ITI) Advanced Database Models 2019 214 / 358

Generic Java Post-processor

Database Other
Classes .java File javac Classes

.class File

Postprocessor

modified other
.class File .class Files
Database
Schema
Executable DBMS
Database Application

Schallehn (FIN/ITI) Advanced Database Models 2019 215 / 358

Persistence Concepts

Persistent-capable classes are created by schema definition and

implementation. They can have persistent as well as transient instances.

Persistence independence requires that persistent and transient objects

of a persistent-capable class can be handled uniformly.

Persistence orthogonality requires that persistence is independent of the

application schema types/classes, e.g. that no common base class or
interface must be inherited or implemented.

Schallehn (FIN/ITI) Advanced Database Models 2019 216 / 358

Persistence Concepts /2

Persistent objects can be modified by accessing their attributes and

methods according by means of the OO programming language
(restricted by encapsulation)
Persistent objects can be created in several ways
I Explicit persistence
I Named root objects
I Persistence by reachability (transitive persistence)
Persistent objects can be deleted by either
I Explicit removal from database → may lead to dangling references
and memory leaks
I Database garbage collection for unreferenced objects
Alternatively, data manipulations can be carried out using the query
language of some systems

Schallehn (FIN/ITI) Advanced Database Models 2019 217 / 358

Explicit Persistence

Database run-time system offers explicit functionality to create a

persistent object or make existing object persistent
Create a persistent object, e.g. ODMG C++ Binding with overloaded
new-operator

d_Database* db;
d_Ref<Person> p1 = new(db,"Person") Person(SSmith","C

make a transient object persistent, e.g. ODMG Java Binding

Person p1 = new Person(SSmith","Carl");

db.makePersistent(p1);
...
db.deletePersistent(p1);

Schallehn (FIN/ITI) Advanced Database Models 2019 218 / 358

Named Objects

Retrieving the first object from an ODB by unique names

Other objects can be accessed starting from this root object by following
references
Typical root objects: tree roots and collections
Example: ODMG Java Binding

City c1 = new City("NY", 45.67, 12.34);

db.bind(c1, "NY");
...
City c = (City) db.lookup("NY");

Schallehn (FIN/ITI) Advanced Database Models 2019 219 / 358

Named Objects /2

Root Objects:
NY
"NY" Boston

LA
"Paris"
Atlanta
SF

Berlin
Paris

Schallehn (FIN/ITI) Advanced Database Models 2019 220 / 358

Persistence By Reachability

Possible consistency problem: object a is made persistent and

referenced objects b and c remain transient
I References from persistent to transient storage
I References become invalid when application is stopped or b and c
are removed from memory
Solution: if one object is made persistent, all transitively reachable
objects are made persistent, too
Example: ODMG Java Binding, JDO

Schallehn (FIN/ITI) Advanced Database Models 2019 221 / 358

Persistence By Reachability /1

Primary Storage Secondary Storage

Main Memory Database

1) Transient Objects
b
a
c

2) makePersistent
b a
c

3) Program Exit
? a
?

Schallehn (FIN/ITI) Advanced Database Models 2019 222 / 358

Persistence By Reachability /2

Primary Storage Secondary Storage

Main Memory Database

1) Transient Objects
b
a
c

2) makePersistent
b a
a) object itself
c

b) all reachable Objects b

a
c

Schallehn (FIN/ITI) Advanced Database Models 2019 223 / 358

OO Query Languages

What are the results of OO queries?

I Relations of tuples (without defined object type)
I Existing objects
I Objects created by queries
How are queries used?
I Ad-hoc queries: arbitrary queries, e.g. from command line tools
I Query API: usage from within application program
How are OO features accessed by query language?
I Complex objects and navigation
I Type hierarchies
I Methods

Schallehn (FIN/ITI) Advanced Database Models 2019 224 / 358

OO Query Languages: Results

Relational query semantics: returns set, bag, or list of struct (tuple) of literal
data types as in relational query languages
Object selection semantics: selects existing persistent objects from the
database
Object creation semantics: creates new (transient) objects based on values
derived from persistent objects by calling a constructor in the
SELECT clause (π)

ODMG OQL supports all result types

Most commercial systems support only object selection

Schallehn (FIN/ITI) Advanced Database Models 2019 225 / 358

OO Query Languages: Usage /1

Ad-hoc queries, e.g. using ODMG interface OQLQuery, require input

I Named root objects
I Named extensions
I Collections bound to variable

OQLQuery query = new OQLQuery();

query.create(ßtudents");
DBag allStudents = (DBag) query.execute();

Schallehn (FIN/ITI) Advanced Database Models 2019 226 / 358

OO Query Languages: Usage /2

Alternative: query interface bound to collection classes for object

selection
I E.g. query()-method defined in ODMG collection classes
I Specification of predicate

DBag badStudents = (DBag)

students.query("grade > C");
DBag myStudents = (DBag)
students.query("
EXISTS s IN this.lectures:
lecture.title =’ADBM’");

Schallehn (FIN/ITI) Advanced Database Models 2019 227 / 358

OO Query Languages: OO Features

Complex objects and navigation

I Following path expressions using ”.”-notation
I Collection-type references require unnesting or nested queries
Type inheritance / specialization
I Access to flat or deep extension
Methods
I Overriding, Overloading, Late Binding must be supported
I Problem: may have side effects, e.g. read-only query calls method
that changes attribute values

Schallehn (FIN/ITI) Advanced Database Models 2019 228 / 358

Extended Transactional Concepts

Support for ACID transactions in most systems

Also extended transactional concepts
Nested transactions: hierarchical structure of transactions to
support complex operations on complex objects
Design transactions: typical requirement in non-standard
applications long transactions avoiding concurrency
problems, e.g. including check-out/check-in, possibly
in conjunction with workspaces and versioning

Schallehn (FIN/ITI) Advanced Database Models 2019 229 / 358

The ODMG Standard

Not well supported, but summarizes common features of ODBMS

Influenced development of, for instance, JDO mapping standard
Consists of several pieces
I ODMG Object Model
I Object Definition Language (ODL)
I Object Query Language (ODL)
I Language Bindings
F C++
F Smalltalk
F Java

Schallehn (FIN/ITI) Advanced Database Models 2019 230 / 358

Object Definition language ODL

Based on OMG IDL (CORBA Interface Definition Language)

Implementation-independent schema definition
Provides means to describe
I Modules (application schemata)
I Interfaces and Classes
I Inheritance
I Attributes and Relationships
I Operations (method declarations)
I Exceptions
Translated to implementation language using pre-processor

Schallehn (FIN/ITI) Advanced Database Models 2019 231 / 358

ODMG ODL: Classes

class Employee (
extent employees) {
attribute long employeeNr;
attribute struct Name {
string firstname;
string lastname } name;
attribute Date dob;
attribute List<string> tel;
...
void raise_salary (in short amount);
};

Schallehn (FIN/ITI) Advanced Database Models 2019 232 / 358

ODMG ODL: Classes /2

class Student : Person (

extent students, key matrnr)
attribute char matrnr[6];
attribute string faculty;
attribute set<struct<float grade, string lecture>>
grades;

relationship Person mother inverse Person::child;

relationship Person father inverse Person::child;

float avgGrade ()
raises (no_Grade);
void enlist (in string faculty)
raises (already_enlisted);
};

Schallehn (FIN/ITI) Advanced Database Models 2019 233 / 358

ODMG ODL: Inheritance

Multiple inheritance only for interfaces

interface Student { ...};

interface Employee { ...};
interface PhDStudent : Student, Employee { ...};

Class inheritance with extends supports only singular inheritances

class Book extends Publication { ...};

Schallehn (FIN/ITI) Advanced Database Models 2019 234 / 358

ODMG ODL: Relationships

m:n-Relationship
attends(Student[0,*], Course[0,*])

class Course {
relationship set<Student> attended_by
inverse Student::attends;
...
};

class Student {
relationship set<Course> attends
inverse Course::attended_by;
...
};

Schallehn (FIN/ITI) Advanced Database Models 2019 235 / 358

Object Query Language OQL

Declarative object-oriented query language based on O 2 system

Very comprehensive and flexible, but only small subset supported
by most systems
Syntax
I SFW-style queries
I Additionally: every named object (e.g. root) or collection (e.g. class
extent) is a query
I Specification of predicates for collection-bound queries

Schallehn (FIN/ITI) Advanced Database Models 2019 236 / 358

ODMG OQL: Simple Example Queries

SELECT e FROM employees e;

employees;

newyork.neighbor_cities;

Schallehn (FIN/ITI) Advanced Database Models 2019 237 / 358

ODMG OQL: SFW Queries /1

SELECT-clause
I Allows method calls and sub-queries
I Allows constructor calls
I DISTINCT for result type set<...>

SELECT DISTINCT STRUCT (e.name, projects:(

SELECT p.projectID
FROM e.particpates_in p))
FROM employee e;

Result type:
set<struct<name: string,
projects: bag<long>>>

Schallehn (FIN/ITI) Advanced Database Models 2019 238 / 358

ODMG OQL: SFW Queries /2

Single object as result type using ELEMENT

ELEMENT (SELECT p
FROM projects p
WHERE projectID = 4711)

Type casting for type hierarchies

SELECT (Employee) a
FROM apprentices a;

Schallehn (FIN/ITI) Advanced Database Models 2019 239 / 358

ODMG OQL: SFW Queries /3

Object creation by means of constructor call

SELECT Component(
productNr: p.productNr,
title: p.title,
status: p.status)
FROM products p
WHERE status = äctive";

Schallehn (FIN/ITI) Advanced Database Models 2019 240 / 358

ODMG OQL: SFW Queries /4

FROM-clause
I Class extension, collection-valued attribute or reference, result of a
method call, or sub-query
I Automatic conversion to bag

SELECT e.name
FROM (SELECT p.managed_by
FROM projects p
WHERE p.status = ’finished’) e
WHERE e.salary > 9000

Schallehn (FIN/ITI) Advanced Database Models 2019 241 / 358

ODMG OQL: Path Expressions

Inner path steps can not be multi-valued, e.g. the following is not possible:

proj.participants.name;

Instead:

SELECT e.name
FROM proj.participants e

Multiple multi-valued references

SELECT prod.name, prod.cost

FROM employees.participates_in proj,
proj.develops prod

Schallehn (FIN/ITI) Advanced Database Models 2019 242 / 358

ODMG OQL: Further Concepts

Arbitrary method calls → problem of side effects

SQL-like functionality
I Joins (can often be replaced by following path references)
I Grouping and aggregate functions
I Sorting → result is of list type
I exists and all quantifiers in predicates, e.g.

EXISTS p IN projects:
p.status = ’finished’

I Named queries as simple view concept

Schallehn (FIN/ITI) Advanced Database Models 2019 243 / 358

ODMG Language Bindings

Exist for C++, Smalltalk, and Java

Include language-dependent ODL (requires property file for DB
specific aspects, such as extents, keys, referential integrity)
Offer API and type mappings
I Type mapping for basic data types
I Type mappings for ODL type constructors (collections, struct,
references)
I Type mapping for pre-defined object types (Date, String)
I Mapping of exception classes
I Basic API for accessing database functionality (database
connections, queries, transactions)
I Schema access (catalog, reflection API)

Schallehn (FIN/ITI) Advanced Database Models 2019 244 / 358

ODMG Java Binding

Mapping of data types

ODL Java
Long int
Float float
Boolean boolean
String String
Long int
Long int
Date java.sql.Date
Time java.sql.Time
... ...

Schallehn (FIN/ITI) Advanced Database Models 2019 245 / 358

ODMG Java Binding /2

Mapping of collection classes in org.odmg

ODL Java
Set DSet
Bag DBag
Array DArray
Map DMap
... ...
In C++ template classes with prefix d_, e.g.

template<class T> class d_Set :

public d_Collection<T> { ... };

Schallehn (FIN/ITI) Advanced Database Models 2019 246 / 358

ODMG Java Binding /3

API also in org.odmg

Interfaces
I Implementation (object factory)
I Database
I Transaction
I OQLQuery
Offer method declarations for minimum functionality
Furthermore: exception classes

Schallehn (FIN/ITI) Advanced Database Models 2019 247 / 358

 Teil VI

Object-relational Data Models

Overview
Object-relational Database Models
Concepts of Object-relational Database Models
Object-relational Features of SQL:2003
Object-relational Features in Oracle10g

Schallehn (FIN/ITI) Advanced Database Models 2019 249 / 358

Object-relational Database Models

Based on relational/SQL database model

Extensions
I Type constructor for objects → object types
I Object identity and references
I Collection type constructors for nested tables and complex objects
I Reference type constructor
I Methods for object types
I Object tables
I Inheritance: type and table hierarchies
I Object views and view hierarchies
I Recursive queries

Schallehn (FIN/ITI) Advanced Database Models 2019 250 / 358

Relational vs. Object-relational

Advantages inherited from relational SQL database model

I Variety of integrity constraints
I Concept of data dictionary
I Descriptive Query language
I Views

Introduction of non-orthogonal features

I Triggers versus Methods
I Generic DML operations versus Methods
I Primary/foreign keys versus object references
ORDBMS still have impedance mismatch

Schallehn (FIN/ITI) Advanced Database Models 2019 251 / 358

Object Types

Constructor for structured types

Components can be
Can be used for object tables, as embedded data type, or for
variables and parameters
Additions compared to tuple type constructor
I Object types allow inclusion of object identity as ”hidden” attribute
I Methods can be defined for object types
I Specialization inheritance between object types (intension)

Schallehn (FIN/ITI) Advanced Database Models 2019 252 / 358

Object Identity

Non-volatile and unique property of an object that describes it

existence independently of its values
Maybe generated by system or defined by user
Used for references
”Hidden column” of a table

Schallehn (FIN/ITI) Advanced Database Models 2019 253 / 358

Reference Type Constructor

Reference types are special data types that reference objects of a

specified type
Value is OID of an object of specified type
Allows reference to an object similar to a programming language
reference or pointer
Scope of a reference can be specified → because referenced type
may be used in different places, e.g. different object tables or
views of the same type
Using references in a query can replace join computation

Schallehn (FIN/ITI) Advanced Database Models 2019 254 / 358

Methods

Methods can be defined for object types

Includes two parts
I Declaration of signature: defines interface of method
I Method implementation: encapsulated implementation in either
external programming language (e.g. C, C++, or Java) or DBMS
programming language (e.g. Oracle’s PL/SQL)
Constructors, overriding, overloading, and late binding must be
supported
Often additional aspects
I Declaration of read-only methods to avoid side effects
I Special methods for comparison to use operators =, >, <, ≤, and ≥

Schallehn (FIN/ITI) Advanced Database Models 2019 255 / 358

Object Tables

Object tables are tables defined based on object type, i.e. they
contain objects instead of tuples
I Have a ”hidden” OID column
I Always have a set semantic because of unique OID
I Can be scope of a typed reference
I Methods can be used on objects
I Can be part of an table hierarchy based on according type hierarchy
1-to-many relationship between types and tables, i.e. the same
type can be used to define several tables

Schallehn (FIN/ITI) Advanced Database Models 2019 256 / 358

Type and Table hierarchies

Type hierarchies: intensional specialization between types, i.e. a sub-type

can inherit attributes and methods from a super-type
Table hierarchies: object tables defined based on types which are in a
super-type / sub-type relationship can (optionally) be in an
extensional specialization relationship, i.e. there can be a
subset relation among object tables

Querying object tables can involve the

I flat extension, i.e. only the super-table
I deep extension, i.e. objects in super-table and all derived sub-tables

Schallehn (FIN/ITI) Advanced Database Models 2019 257 / 358

Object views and view hierarchies

Views can just like object tables be defined based on a type

To comply with type definition two possible ways
I view definition query must return objects of view type
I view definition calls type constructor in SELECT-clause, OIDs are
temporary
According to object table hierarchies, views can be in a view
hierarchy with extensional specialization

Schallehn (FIN/ITI) Advanced Database Models 2019 258 / 358

Object-relational Features of SQL:2003

Majority of object-relational concepts introduced already with

SQL:1999
Reaction to growing popularity of ODBMS and inclusion of
object-relational aspects in commercial RDBMS
Special importance: extensibility opened standard and systems for
new applications
I Multi-media
I Spatial data and Geographic Information Systems
I Engineering data
I Document management and work-flow systems
I Semi-structured data and WWW contents
I ...

Schallehn (FIN/ITI) Advanced Database Models 2019 259 / 358

SQL:2003 Type System

Support for the following type constructors

I ROW - for tables and embedded row types
I OBJECT - for object tables and embedded object types
I SET - only for object tables
I ARRAY - for embedded object types
I MULTISET - for tables and nested tables
I REF - for references to object tables and views

Schallehn (FIN/ITI) Advanced Database Models 2019 260 / 358

SQL:2003 Type System

MULTISET SET

ROW OBJECT

Base Type REF ARRAY MULTISET

Type Construction Subtyping Sub−tables Table Construction

Schallehn (FIN/ITI) Advanced Database Models 2019 261 / 358

Object Types

Object type constructor for structured types

CREATE TYPE Address_Type AS (

street VARCHAR(30),
zip VARCHAR(10),
town VARCHAR(30)
) NOT FINAL

CREATE TYPE Customer_Type AS (

cnr INT,
name VARCHAR(30),
address Address_Type
) NOT FINAL

Schallehn (FIN/ITI) Advanced Database Models 2019 262 / 358

Object Tables

CREATE TABLE customers OF Customer_Type (

REF IS oid SYSTEM GENERATED)

Customer_Type is table type

Address_Type is embedded column type

Schallehn (FIN/ITI) Advanced Database Models 2019 263 / 358

Object Identifiers

REF IS ...USER GENERATED

REF IS ...SYSTEM GENERATED
REF FROM (attributelist)
OID is derived from other attributes, e.g. primary key

Schallehn (FIN/ITI) Advanced Database Models 2019 264 / 358

Reference Type Constructor

<attributename> REF(<typename>)
[ SCOPE scopedescription ]

Scope is
One specified object table
One specified object view
Any of the tables and views of this type, if not specified

Schallehn (FIN/ITI) Advanced Database Models 2019 265 / 358

Reference Type Constructor /2

CREATE TYPE Employee_Type AS (

enr INTEGER,
name VARCHAR(30));

CREATE TABLE employees OF Employee_Type;

CREATE TABLE departments (

name VARCHAR(10),
manager REF(Employee_Type) SCOPE(employees),
members REF(Employee_Type)
SCOPE(employees) ARRAY[10]
)

Schallehn (FIN/ITI) Advanced Database Models 2019 266 / 358

Reference Type Constructor /2

Following a reference using

I DEREF-operator

SELECT DEREF(manager)
FROM departments;

I Arrow operator

SELECT name, manager->name

FROM departments;

implicit join !

Schallehn (FIN/ITI) Advanced Database Models 2019 267 / 358

Type Hierarchies

No multiple inheritance
Control of further sub-typing
I NOT FINAL: definition of sub-types allowed
I FINAL: no sub-types allowed

CREATE TYPE Person_Type AS ( ...) NOT FINAL;

CREATE TYPE Customer_Type UNDER Person_Type AS
( ...) FINAL;

Schallehn (FIN/ITI) Advanced Database Models 2019 268 / 358

Table Hierarchies

Object tables can be defined to be in extensional specialization hierarchy

if according types are in a type hierarchy

CREATE TYPE Person_Type AS ( ...) NOT FINAL;

CREATE TYPE Customer_Type UNDER Person_Type AS
( ...) FINAL;

CREATE TABLE Persons OF Person_Type;

CREATE TABLE Customers OF Customer_Type
UNDER Persons;

If defined, there is a subset relation between sub-table and super-table

If not defined, only intensional specialization holds

Schallehn (FIN/ITI) Advanced Database Models 2019 269 / 358

Type and Table Hierarchies in SQL:2003

Table of Type

under under

Sub−Table of Subtype

Schallehn (FIN/ITI) Advanced Database Models 2019 270 / 358

Table Hierarchies in SQL:2003

Super−Table
under
Super−Type
under
oid A1 ... An

oid A1 ... An B1 ... Bm

Subtype
Sub−Table

Flat Deep Deep

Extension + Extension = Extension
Super−Table Sub−Table Super−Table

Schallehn (FIN/ITI) Advanced Database Models 2019 271 / 358

Accessing Table Hierarchies

Default behavior: deep extension is queried when accessing super-table

I All persons and customers, only person attributes

SELECT * FROM Persons;

I All customers with person and customer attributes

SELECT * FROM Customers;

Flat extension of persons using keyword ONLY

I Persons, which are no customers
SELECT * FROM ONLY(Persons);

Schallehn (FIN/ITI) Advanced Database Models 2019 272 / 358

Methods

SQL-Functions/Procedures defined for object types

Implicit SELF-parameter similar to this in C++ or Java to access
object itself
Separation of declaration (part of the type) and implementation of
a method
For all attributes set and get-methods are generated
automatically, but can be overridden

Schallehn (FIN/ITI) Advanced Database Models 2019 273 / 358

Methods /2

CREATE TYPE Customer_type AS (

...
) NOT FINAL
METHOD overall_orders()
RETURNS DECIMAL(9,2));

CREATE METHOD overall_orders() FOR Customer_Type

BEGIN
...
END

Schallehn (FIN/ITI) Advanced Database Models 2019 274 / 358

Object Views

CREATE TYPE Person_Type AS (

personalnr INTEGER,
name VARCHAR(30),
salary DECIMAL(8,2),
manager REF(Person_Type))
NOT FINAL REF USING INTEGER;

CREATE VIEW RichEmployees OF Person_Type (

REF IS oid USER GENERATED,
manager WITH OPTIONS
SCOPE RichEmployees
) AS SELECT RichEmployees(personalnr),
personalnr, name, salary,
RichEmployees(manager->personalnr)
FROM ONLY (Employees)
WHERE salary > 5000;

Schallehn (FIN/ITI) Advanced Database Models 2019 275 / 358

View Hierarchies

View of sub-type with exactly one super-view of the according

super-type
OID and attribute restrictions are inherited
Table used in sub-view definition must be sub-table of table used
in super-view
Subset relation among view extensions
Definition

CREATE VIEW <viewname> OF <typename>

UNDER <super-view-name> [(
<column-options>
)] AS <view-definition-query>

Schallehn (FIN/ITI) Advanced Database Models 2019 276 / 358

Recursive Queries /1

Independent of object-relational concepts, but useful for dealing with complex

objects
Typical applications: hierarchical tree-like data (e.g. bill of material-queries,
transitive closure in networks (flight plans, street maps)
Based on re-usable query in WITH-clause

WITH <query-name> AS ( SFW-block )

SFW-block-using-named-query

Schallehn (FIN/ITI) Advanced Database Models 2019 277 / 358

Recursive Queries /2

Recursion:

WITH RECURSIVE <recursive-table> AS (

SELECT ... FROM <table> ...
UNION
SELECT ...
FROM <table>, <recursive-table> ...)
SELECT ... FROM <recursive-table> WHERE ...

Schallehn (FIN/ITI) Advanced Database Models 2019 278 / 358

Recursive Queries /3
machine part component amount partcost
car motor 1 5356
motor plunger 4 124
motor crankshaft 1 89
motor gear 1 560
gear clutch 1 290
... ... ... ...

Schallehn (FIN/ITI) Advanced Database Models 2019 279 / 358

Recursive Queries /4

WITH RECURSIVE partlist (part, amount, cost)

AS (SELECT component, 1, 0.00
FROM machine
WHERE part = ’car’
UNION ALL
SELECT m.component, m.amount,
m.amount * m.part_cost
FROM partlist p, machine m
WHERE p.component = m.part)
SELECT part, sum(amount), SUM(cost)
FROM partlist
GROUP BY part;

Schallehn (FIN/ITI) Advanced Database Models 2019 280 / 358

Recursive Queries /5

Computation: breadth first vs. depth first

I Influences result tuple order
I Can be specified

WITH RECURSIVE ...

SEARCH BREADTH | DEPTH FIRST BY <attrib-list>
...

Query safety: endless recursion (cycles) might occur → user’s

responsibility, but syntax support

CYCLE <attrib> SET cyclemark TO ’Y’ default ’N’

USING cyclepath

Schallehn (FIN/ITI) Advanced Database Models 2019 281 / 358

Object-relational Features in Oracle10g

Majority of object-relational features supported

I Object types +
I Object identity and references +
I Collection type constructors for nested tables and complex objects
+
I Reference type constructor +
I Methods for object types +
I Object tables +
I Type hierarchies +
I Table hierarchies -
I Object views and view hierarchies +
I Recursive queries +
Different syntax from standard

Schallehn (FIN/ITI) Advanced Database Models 2019 282 / 358

Object Types and Object Tables

CREATE TYPE Person_Type AS OBJECT (...);

CREATE TABLE Persons OF Person_Type;

Interpretation
I Table with columns for type attributes
I Each row gets assigned OID

Schallehn (FIN/ITI) Advanced Database Models 2019 283 / 358

Type Hierarchies

Intensional specialization

CREATE TYPE Student_Type UNDER Person_Type ( ...);

No table hierarchies (extensional specialization)

Nevertheless, substitutability granted:
I Table of super-type may contain objects of sub-types
I Column of super-type may contain embedded object of sub-type

Schallehn (FIN/ITI) Advanced Database Models 2019 284 / 358

Object Identifiers

Default: hidden, system-generated OID

I 16 Byte per OID plus extra index structure for mapping to tuples
Alternative: primary key is user-generated OID
I Save disk space, but uniqueness is not granted

CREATE TABLE Stocks OF Stock_Type (

StockID PRIMARY KEY)
OBJECT IDENTIFIER IS PRIMARY KEY ;

Schallehn (FIN/ITI) Advanced Database Models 2019 285 / 358

Reference Type Constructor

Logical references using OIDs

CREATE TYPE Employee_Type AS OBJECT (

...,
manager REF Employee_Type);

Definition of scope as integrity constraint for object tables

CREATE TABLE Employees OF Employee_Type (

manager SCOPE IS Employees);

Insert requires query to retrieve value, e.g.

INSERT INTO Employees

SELECT ’John Miller’, 20000, REF(e)
FROM Employees e WHERE e.name = ’Jake Jones’;

Schallehn (FIN/ITI) Advanced Database Models 2019 286 / 358

Methods

Implementation using PL/SQL, C, or Java)

SELF as implicit Parameter
Constructor generated implicitly
Overloading, overriding, and late binding supported
Method declaration in type definition, method implementation as part of
type body specified separately
Pre-defined interface for special functions used by DBMS for sorting and
grouping based on complex object types
I MAP MEMBER FUNCTION: test for equality
I ORDER MEMBER FUNCTION: comparison

Schallehn (FIN/ITI) Advanced Database Models 2019 287 / 358

Methods /2

CREATE TYPE Employee_type AS OBJECT (

...
salary NUMBER,
MEMBER FUNCTION yearly RETURN NUMBER
);

...

CREATE TYPE BODY Employee_type IS

MEMBER FUNCTION RETURN NUMBER IS
BEGIN
RETURN 12*salary+bonus;
END;
END;

Schallehn (FIN/ITI) Advanced Database Models 2019 288 / 358

Recursive Queries

Supported using CONNECT BY PRIOR syntax

SELECT component, SUM(part_cost), SUM(amount)

FROM machine
START WITH part = ’Auto’
CONNECT BY PRIOR component = part
GROUP BY component;

Schallehn (FIN/ITI) Advanced Database Models 2019 289 / 358

 Teil VII

Semi-structured Database Models

Overview
Introduction
XML
XML: DTDs and XML Schema
XPath and XQuery

Schallehn (FIN/ITI) Advanced Database Models 2019 291 / 358

Semi-structured Data

Semi-structured data/documents
I Data with an internally encoded, often changing, and not strongly
typed structured
I Used for data exchange or the WWW
No explicit structure
I Unknown, ambiguous, not required/needed
I Explicit description of structure too complex and expensive
Data not easily representable in tables
I Optional or alternative parts
I Repetitions
I Order is relevant

Schallehn (FIN/ITI) Advanced Database Models 2019 292 / 358

Features of semi-structured data

No centrally stored schema, schema is part of data/document

(„self-describing“)
Changing structures
May contain data without further structure
No or few data types (no integrity control)
Great number of possible attributes
Mix of data and schema

Schallehn (FIN/ITI) Advanced Database Models 2019 293 / 358

Data Models for Semi-Structured Data

Graph-based Models
Examples: Object Exchange Model (OEM), Extensible Markup
Language (XML)
Document modeled as graph with
I Edges with element tag names
I Nodes with attribute/value pairs
I Leaves with values (Strings)
I Root node
Node = object

Schallehn (FIN/ITI) Advanced Database Models 2019 294 / 358

Example Graph

Household

Address Person
Person

Town Firstname Firstname

Name
Name
ZIP
No Lisa John
Ketchikan Street Smith Smith
99950 6a
Paul Street

Schallehn (FIN/ITI) Advanced Database Models 2019 295 / 358

Flexibility

Different structures for persons

Household

Person Person Person

Firstname Email
Firstname
Name Lastname
[email protected]

Lou Lastname
John
Nico Cale
Reed

Schallehn (FIN/ITI) Advanced Database Models 2019 296 / 358

Representation of other Data Models

Simple mapping of relational structures

R2 c d
R1 a b c
c2 d2
a1 b1 c1
c3 d3
a2 b2 c2
c4 d4
R2
R1

Tupel Tupel Tupel Tupel

Tupel

a c a c c d c d c d
b b
a1 b1 c1 a2 b2 c2 c2 d2 c3 d3 c4 d4

Schallehn (FIN/ITI) Advanced Database Models 2019 297 / 358

XML - An Overview

XML = Extensible Markup Language

I Meta language based on SGML
Meta language: allows definition of valid document types (DTD)
Numerous complementary technologies and standards
I Schema description: XML Schema (more powerful than DTD)
I Query languages: XPath, XQuery
I Transformation language: XSL(T)
I ...

Schallehn (FIN/ITI) Advanced Database Models 2019 298 / 358

Building Blocks of XML Documents

Elements: denoted by Tags

<tag>contents </tag>

Alternatively also as empty elements:

<tag/>

Tag provides information about the meaning of the contents

Schallehn (FIN/ITI) Advanced Database Models 2019 299 / 358

Example Elements

<address>
<town>Ketchikan</town>
<zip>99950</zip>
<street>Paul Street</street>
</address>

<telephone>56-789012</telephone>
<fax/>

Schallehn (FIN/ITI) Advanced Database Models 2019 300 / 358

XML Document structure

XML declaration, DTD (optional), root element (with nested

contents)
XML declaration:
I version: 1.0
I encoding: font encoding used in file, e.g. utf-8, utf-16
I standalone: yes no external schema; no, external schema
required

<?xml version="1.0" encoding="utf-16"

standalone="yes" ?>

Schallehn (FIN/ITI) Advanced Database Models 2019 301 / 358

XML Documents

Two criteria for XML documents

I Well formed (necessary): document contains elements that
conform to basic XML rules (e.g. nesting, closing tags after opening
tags, etc.)
I Valid (optional): conform to a specific DTD
F DTD contained in the document, or
F DTD externally linked by a reference
XML Instance = document conforming to a given DTD

Schallehn (FIN/ITI) Advanced Database Models 2019 302 / 358

XML Example document

<?xml version="1.0" ?>

<!DOCTYPE household SYSTEM "household.dtd" >
<household name=”ALASKA1966”>
<address>
<town>Ketchikan</town>
<zip>99950</zip>
<street>Paul Street</street>
<no>6a</no>
</address>
<person>
<lastname>Smith</lastname>
<firstname>Lisa</firstname>
</person>
</household>

Schallehn (FIN/ITI) Advanced Database Models 2019 303 / 358

Document Type Definition

DTD (Document Type Definition): document structure (schema)

I Formal grammar for a specific XML language
I Names of allowed tags and their nesting
Structure: sequence of element declarations

<! ELEMENT name ( content ) >

content:
I EMPTY: no further content
I ANY: arbitrary text or elements from this DTD
I #PCDATA: „parsed character data“, i.e. element text without further
structure
I regular expression for nested element type

Schallehn (FIN/ITI) Advanced Database Models 2019 304 / 358

DTD: Regular Expressions

Sequence: (E1, E2)

Alternative: (E1 | E2)
Repetition:
I E+: 1 . . . n repetitions
I E*: 0 . . . n repetitions
I E?: 0 . . . 1 optional element

Schallehn (FIN/ITI) Advanced Database Models 2019 305 / 358

DTD Example

<!ELEMENT household (address, person+) >

<!ELEMENT address (zip, town, street, no>
<!ELEMENT zip (#PCDATA)>
<!ELEMENT town (#PCDATA)>
<!ELEMENT street (#PCDATA)>
<!ELEMENT no (#PCDATA)>
<!ELEMENT person (firstname, lastname, email?)>
<!ATTLIST person ssn CDATA #REQUIRED>
<!ELEMENT firstname (#PCDATA)>
<!ELEMENT lastname (#PCDATA)>
<!ELEMENT email (#PCDATA)>

Schallehn (FIN/ITI) Advanced Database Models 2019 306 / 358

Attributes

Attributes: local properties of elements, e.g.

<town state=”IL”>Chicago</town>
<tel no=”123459876”/>

Declaration
<! ATTLIST name type restrict default>

I type: CDATA – „character data“ (arbitrary text), ID – unique value

for identification, IDREF – reference to ID, ( value1 | value2
| ...) – enumeration, . . .
I restrict: #REQUIRED – necessary attribute, #IMPLIED –
optional attribute, #FIXED – set to default value

Schallehn (FIN/ITI) Advanced Database Models 2019 307 / 358

Element or Attribute?

Alternative 1:
<lot>
<lotnr>42-33-66</lotnr>
<address>...</address>
</lot>

Alternative 2:
<lot lotnr=”42-33-66”>
<address>...</address>
</lot>

Schallehn (FIN/ITI) Advanced Database Models 2019 308 / 358

Element or Attribute? /2

Element Attribute
Identification – ID / IDREF
Quantifier 1/?/∗/+ REQUIRED / IMPLIED
√
Alternatives –
√
Default values –
√
Enumerations –
Contents complex atomic
Fixed order yes no

Schallehn (FIN/ITI) Advanced Database Models 2019 309 / 358

Entities

Declaration of re-usable text

Notation
<! ENTITY name ’replacement’>

Example
<! ENTITY unimd "University of Magdeburg">

Usage
<description>
He studied at the &unimd; ...
</description>

Similar: parameter entities used only in DTDs

Schallehn (FIN/ITI) Advanced Database Models 2019 310 / 358

XML Schema

Schema definition for XML

More powerful alternative to DTDs
DTD shortcomings
I Weak typing
I Limited power of expression
I Document-oriented
Advantages of XML Schema
I Not limited to documents (also XML DBS, data exchange)
I More powerful means of expression
I Data-oriented

Schallehn (FIN/ITI) Advanced Database Models 2019 311 / 358

XML Schema: Concepts

Namespace (prefix for elements): xs

Schema element: consists of sub-elements
Element: element
Complex type definitions: complexType
Composition from other elements and attributes
Simple type definition: simpleType
Basic types and constraints on basic types
Comments

Schallehn (FIN/ITI) Advanced Database Models 2019 312 / 358

Schema Definition

<xs:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<xs:element name=”address” type="AddressType"/>

<xs:complexType name="AddressType">
<xs:sequence>
<xs:element name="street" type="xs:string" />
<xs:element name="town" type="xs:string" />
<xs:element name="zip" type="ZIPType" />
...
</xs:sequence>
</xs:complexType>
...
</xs:schema>

Schallehn (FIN/ITI) Advanced Database Models 2019 313 / 358

Element Declaration

Like DTD: define allowed elements and attributes

Typed elements and attributes
Notation:
<xs:element name="element-name"
type="type-name" />

Further constraints for xs:element

I minOccurs/maxOccurs: exact range for possible occurrences
I use: required, optional
I default: default value

Schallehn (FIN/ITI) Advanced Database Models 2019 314 / 358

Simple Types

Builtin-Types: string, integer, double, date, anyURI, . . .

Derived Types by restrictions on builtin-types
I Range restrictions
I Patterns
I Enumeration of possible values
I Lists and unions of other domains

Schallehn (FIN/ITI) Advanced Database Models 2019 315 / 358

Simple Types: Overview
anyType

benutzerdefinierte
anySimpleType
komplexe Typen

dateTime
benutzerdefinierte
Listen- und
string date Vereinigungstypen

normalizedString decimal

token float integer

language duration nonPositiveInteger

Name double negativeInteger

NCName time long

ID base64Binary int short

IDREF boolean byte

ENTITY anyURI nonNegativeInteger

...
...

...

Schallehn (FIN/ITI) Advanced Database Models 2019 316 / 358

Simple Types: Range Constraints

Constraining to value range (1 . . . 100)

<xs:simpleType name="AmountType">
<xs:restriction base="xs:integer">
<xs:minInclusive value="1" />
<xs:maxInclusive value="100" />
</xs:restriction>
</xs:simpleType>

Schallehn (FIN/ITI) Advanced Database Models 2019 317 / 358

Simple Types: Patterns

Constraining a value domain by a pattern (regular expression)

<xs:simpleType name="ZIPType">
<xs:restriction base="xs:string">
<xs:pattern
value="[0-9]{5}(-[0-9]{4})?" />
</xs:restriction>
</xs:simpleType>

Schallehn (FIN/ITI) Advanced Database Models 2019 318 / 358

Complex Types

„Type Constructor“ for elements with attributes and sub-elements

I Based on simple types
I Mixed Content (Sequence of sub-elements)
I Selection, Grouping
I ...

Schallehn (FIN/ITI) Advanced Database Models 2019 319 / 358

Complex Types: Example

Type definition
<xs:complexType name="AreaType">
<xs:simpleContent>
<xs:extension base="xs:decimal">
<xs:attribute name="Unit"
type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>

Application in document instance

<area unit="square meters">400</area>

Schallehn (FIN/ITI) Advanced Database Models 2019 320 / 358

Complex Types: Example /2

<xs:complexType name="StreetType">
<xs:sequence>
<xs:element name="Lot"
minOccurs="1" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="no" type="xs:integer"/>
<xs:element name="area" type="AreaType"/>
<xs:element name="owner" type="xs:string"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>

Schallehn (FIN/ITI) Advanced Database Models 2019 321 / 358

Integrity Constraints

Uniqueness: unique
Key: key
Reference to a key: keyref
Assigned to elements or attributes using XPath (discussed later on)
<xs:element name=”Lot">
<xs:complexType>
<xs:sequence> ... </xs:sequence>
<xs:attribute name=”lotno” type=”xs:integer”/>
</xs:complexType>
<xs:unique name=”LotNumber”>
<xs:selector xpath=”lot/>
<xs:field xpath=”@lotno/>
</xs:unique>
</xs:element>

Schallehn (FIN/ITI) Advanced Database Models 2019 322 / 358

XML Query Languages

Several query languages developed in late ’90s

Now: set of co-operation standards
I XQuery: fully-fledged XML query language
I XSLT: XML transformation
I XLink/XPointer: references between XML documents
I XPath: basic functionality used in all above

Schallehn (FIN/ITI) Advanced Database Models 2019 323 / 358

XPath

Language to address document fragments

Part of XSLT, XQuery, ...
Components:
I Expressions to select document parts
I Operations and functions
No XML syntax
No fully-fledged query language
I Only selection of document fragments
I No result construction, joins, grouping, etc.

Schallehn (FIN/ITI) Advanced Database Models 2019 324 / 358

Role of XPath

XSLT XLink
XPath

XPointer

XQuery

Schallehn (FIN/ITI) Advanced Database Models 2019 325 / 358

XPath: Data Model

XML document as DOM tree

I Nodes for XML elements
I Edges with element labels
Node types: root node, element nodes (references to
sub-elements, attribute nodes, text nodes), comment nodes
Data types: atomic values (strings, boolean, float), sequences of
nodes

Schallehn (FIN/ITI) Advanced Database Models 2019 326 / 358

XPath: Path Expressions

Consist of steps
Steps separated by „/“
Processed from left to right
Each step yields sequence of nodes or value
Absolute path starting from root node starts with „/“
Relative path without preceding „/“
Examples:
/book/title
/book/author/lastname
//author

Schallehn (FIN/ITI) Advanced Database Models 2019 327 / 358

XPath: Steps

(Expanded) notation for each step:

axis::node-test[predicate]

I axis: relation between steps current (context) node to nodes to be

selected
I node-test: node type and name of nodes to be selected
I predicate: logical predicate/condition to filter node set
Abbreviations and default steps discussed later on

Schallehn (FIN/ITI) Advanced Database Models 2019 328 / 358

XPath: Axis Specifiers

self: context node

child: all direct sub-elements
descendant: all direct or indirect sub-elements
descendant-or-self: descendant + self nodes
parent: parent nodes
ancestor: all nodes on path from context node to root node
preceding-sibling: previous (in document order) children of
parent of context node
following-sibling: subsequent children of parent node

Schallehn (FIN/ITI) Advanced Database Models 2019 329 / 358

XPath: Axis Specifiers /2
ancestor-or-self::
ancestor::

following::
parent::
preceding::

preceding-sibling:: following-sibling::
self::

child::

descendant::

descendant-or-self::

Schallehn (FIN/ITI) Advanced Database Models 2019 330 / 358

XPath: Node Tests

Restriction to certain node types

I node(): true for all nodes
I text(): true for text nodes
I
*: true for element nodes
I qname: true if name of element node is qname
Examples:
I descendant::* all sub-element nodes of context nodes
I child::author all sub-elements named author
I attribute::id attribute id of context node
I parent::* parent node

Schallehn (FIN/ITI) Advanced Database Models 2019 331 / 358

XML - Example document

<?xml version="1.0" ?>

<books>
<book isbn="1-55860-622-X" >
<title>Data on the Web</title>
<price>42.90</price>
<publisher><name>Morgan Kaufmann</name>
<address>San Francisco</address>
</publisher>
<author>
<firstname>Serge</firstname>
<lastname>Abiteboul</lastname>
</author>
<author>
<firstname>Peter</firstname>
<lastname>Buneman</lastname>
</author>
</book>
<book isbn="3-8266-0618-1" > ...</book>
</books>

Schallehn (FIN/ITI) Advanced Database Models 2019 332 / 358

XPath: Examples

fn:doc("books.xml")
/child::books/child::book

fn:doc("books.xml")/child::books
/child::book[attribute::isbn=’1-2345’]

fn:doc("books.xml")
/descendant-or-self::book
[child::author/child::lastname=’Sattler’]
/child::title

Schallehn (FIN/ITI) Advanced Database Models 2019 333 / 358

XPath: Abbreviations

Default axis and short syntax for node tests

I child:: default axis specifier
I @ for attribute::
I . for self::node()
I .. for parent::node()
I // for /descendant-or-self::node()/
I [n] denotes n-th element from sequence of nodes

Schallehn (FIN/ITI) Advanced Database Models 2019 334 / 358

Selection Predicates and Functions

Predicates and complex conditions

I Comparison operators: <, <=, etc.
I Logical operators: and, or
I Arithmetic operators: +, *, -, div
Functions
I fn:contains (str, substr): test for string
I fn:last (): position of last element in current context
I fn:position (): position of current element

Schallehn (FIN/ITI) Advanced Database Models 2019 335 / 358

Conditions in Path Steps

Context position:
child::author[1]
boolean predicate:
child::book[@isbn = ’1234’]
Expressions over sequences:
child::author[fn:position() = { 1, fn:last() }]
Combination of predicates:
child:author[1][child::name=’Heuer’]

Schallehn (FIN/ITI) Advanced Database Models 2019 336 / 358

Test for Existence

Test for existence of attributes

//buch[@isbn]

Test for existence of elements

//book/publisher[address]/name

Schallehn (FIN/ITI) Advanced Database Models 2019 337 / 358

XPath: Examples /2

fn:doc("books.xml")
/books/book[@isbn=’1-55860-622-X’]

fn:doc("books.xml")
//book/author[1]/lastname

fn:doc("books.xml")
//book[author/lastname=’Sattler’]/title

Schallehn (FIN/ITI) Advanced Database Models 2019 338 / 358

XQuery

Functional Query Language for XML

Combination of different possible expressions
I XPath expressions
I Element construction
I Function calls (standard, user-defined)
I Constrained and quantified expressions
I Data type-specific operations
I FLWOR-expressions

Schallehn (FIN/ITI) Advanced Database Models 2019 339 / 358

XQuery: Data Model

Result: ordered sequence of nodes or atomic values

I No nesting
I Duplicates allowed
Special cases:
I Sequence with one element ≡ element
I Empty sequence ≡ nothing

(1, (), (<e/>, 2), 3) ≡ (1, <e/>, 2, 3)

Schallehn (FIN/ITI) Advanced Database Models 2019 340 / 358

XQuery: Expressions

Variable reference: $name := "XQuery"

Value construction: xs:double(NaN), xs:float(3.1415)
Function calls: fn:compare("Goethe”, "Göthe")
Comments: (: comment :)

Schallehn (FIN/ITI) Advanced Database Models 2019 341 / 358

XQuery: Input Function

fn:doc(): URI as parameter

I yields document node for referenced document
fn:collection(): URI as parameter
I Yields sequence of nodes, e.g. from database

Schallehn (FIN/ITI) Advanced Database Models 2019 342 / 358

XQuery: FLWOR expressions

Similar to SFW-block in SQL

Notation
(for-expression | let-expression )+
[ where expression ]
[ order by expression ]
return expression

mit
for-expression ::= for $var in expression
let-expression ::= let $var := expression

Schallehn (FIN/ITI) Advanced Database Models 2019 343 / 358

XQuery: Variables

Binding results of expression evaluation to variables

Notation: $name
Characteristics:
I Type derived from result of evaluation
I No side-effects (modifications) allowed
I Only valid for current context (query, expression)

Schallehn (FIN/ITI) Advanced Database Models 2019 344 / 358

XQuery: let-clause

Set of values/nodes is bound to variable

let $var := expression

Example:
let $b := fn:doc("books.xml")//book
return $b

Evaluation:
1 All book nodes from document books.xml
2 set of values assigned to $b
3 Output of set $b

Schallehn (FIN/ITI) Advanced Database Models 2019 345 / 358

XQuery: for-clause

All elements of result set are step-wise bound to variable

for $var in expression

Example:
for $b in fn:doc("books.xml")//book
return $b

Evaluation:
1 Binding for each element to $b
2 Further clauses, e.g. (where, return, . . . ) are processed for each
element, i.e. return executed for each book

Schallehn (FIN/ITI) Advanced Database Models 2019 346 / 358

XQuery: for vs. let

for-clause
for $i in (1, 2, 3)
return <tuple><i>{ $i } </i></tuple>

<tuple><i>1</i></tuple>
<tuple><i>2</i></tuple>
<tuple><i>3</i></tuple>
let-clause
let $i := (1, 2, 3)
return <tuple><i>{ $i } </i></tuple>

<tuple><i>1 2 3</i></tuple>

Schallehn (FIN/ITI) Advanced Database Models 2019 347 / 358

XQuery: Element Construction

Creation of XML fragments

I Literal XML
I Creation of elements and attributes
Evaluation of XQuery-expressions in XML in { ...}
Example:
<authors> {
for $b in fn:doc("books.xml")//book
for $a in $b/author
return
<name> {$a/lastname/text()} </name>
} </authors>

Schallehn (FIN/ITI) Advanced Database Models 2019 348 / 358

XQuery: Element Construction /2

Explicit element construction using Element

I Element name can be derived from expression

element price {
attribute currency { "Euro"}, "59.00"}

Result:
<price currency"Euro">59.00</price>

Schallehn (FIN/ITI) Advanced Database Models 2019 349 / 358

XQuery: where-clause

Filter on result set

Condition with expressions
I Arithmetic, logical and comparison expressions
I Function calls
I Path expressions
Example:
for $b in fn:doc("books.xml")//book
where $b/price < 50
return
<book> {
<isbn> $b/@isbn </isbn>,
$b/title
} </book>

Schallehn (FIN/ITI) Advanced Database Models 2019 350 / 358

XQuery: Join

Using variables from different FOR-clauses

for $b in fn:doc("books.xml")//book,
$r in fn:doc("reviews.xml")//reviews
where $b/title = $r/booktitle
return <bookreview> { $b/title, $r/score }
</bookreview>

Schallehn (FIN/ITI) Advanced Database Models 2019 351 / 358

XQuery: Aggregate Functions

Aggregate functions with sequence of parameters

let $b := fn:doc("books.xml")//book
return <costs>
{ fn:sum($b/price) }
</costs>

let $b := fn:doc("books.xml")//book
let $avg := fn:avg($b/price)
return $b[price > $avg]

Schallehn (FIN/ITI) Advanced Database Models 2019 352 / 358

Conditional Expressions

Syntax:
if (expr1) then expr2 else expr3

Example:
for $b in fn:doc("books.xml")//book
return <book> { $b/title }
{ for $a at $i in $b/author
where $i <= 2
return <author>{ string($a/lastname), ",",
string($a/firstname)}</author> }
{ if (count($b/author) > 2)
then <author>et al.</author> else () }
</buch>

Schallehn (FIN/ITI) Advanced Database Models 2019 353 / 358

Quantifiers

Quantifiers: test, if one or all elements of a sequence fulfill a

condition
some | every $var in sequence
satisfies condition

Existential quantification: true, if at least one element yields

true for condition (false for empty sequence)
Universal quantification: true, all elements yield true for
condition (true for empty sequence)

Schallehn (FIN/ITI) Advanced Database Models 2019 354 / 358

Quantifiers /2

for $b in fn:doc("books.xml")//book
where some $a in $b/author/lastname
satisfies $a = "Ullman"
return $b

Schallehn (FIN/ITI) Advanced Database Models 2019 355 / 358

Functions

Aggregate functions
Pre-defined numeric functions: fn:abs(v ), fn:ceiling(v ),
fn:floor(v ), fn:round(v ), . . .
String functions : fn:compare(s1 , s2 ), fn:concat(s1 , s2 ),
fn:string-length(s), fn:upper-case(s),
fn:substring(s, b, e), fn:string-join(s, t), . . .
Regular expressions: fn:matches(s, p)
Functions for date and time: fn:current-date(),
fn:get-day-from-date(d), . . .

Schallehn (FIN/ITI) Advanced Database Models 2019 356 / 358

Functions: Examples

fn:ceiling(42.9) (: 43 :)

fn:substring("XQuery", 2, 2) (: "Qu":)

fn:string-join(("abc", "def"), "-")

(: "abc-def":)

fn:matches("XQuery", "ˆX.*y$”) (: true :)

fn:get-day-from-date("2005-06-30") (: 30 :)

Schallehn (FIN/ITI) Advanced Database Models 2019 357 / 358

User-defined Functions

Declared with signature

declare function name (param-list)

as sequence-type

I Default type item*

Function body
I XQuery-expression
I external: externally implemented (using programming language)

Schallehn (FIN/ITI) Advanced Database Models 2019 358 / 358