Concurrency Control

DBMS must support ACID (Atomicity, Consistency, Isolation, Durability) properties

– Atomicity requires that a transaction should either be executed in its entirety or not all
– Consistency assures that a transaction brings the database from one consistent state
to another
– Isolation ensures that the e ect of concurrent transactions should be the same as if
they would have been executed in isolation
– Durability ensures that the database changes made by a transaction declared
successful can be made permanent under all circumstances

Architecture of a DBMS
ff
 • Categorisation based on data model:
- Hieararchical DBMSs
- Network DBMSs
- Relational DBMSs
- Object-orientated DBMSs
- Object-Relational DBMSs (ORDBMSs)
- XML DBMSs
- NoSQL DBMSs

• Categorization based on degree of simultaneous access

- Single user versus multi user systems

• Categorization based on architecture

- Centralized DBMS architecture
- Client server DBMS architecture
- n-tier DBMS architecture
- Cloud DBMS architecture
- Federated DBMS
- in-memory DMS

• Categorization based on usage

- On-line transaction processing (OLTP)
- On-line analytical processing (OLAP)
- Big Data & Analytics
- Multimedia
- Spatial Applications
- Sensoring
- Mobile
- Open source

Entity Relationship (ER) model

• Entity Types
• Entity
• Attribute Types
- Domains (ie. gender only takes male or female or maybe null) (not displayed in an ER model)
- Key Attribute Types (distinct for each individual entity) (also in a combination of attribute types)
- Simple versus Composite Attribute Types (simple: name composite: address (street, box, etc.) )
- Single-Valued versus Multi-Valued Attribute Types
- Derived Attribute Type (age can be derived from date_of_birth)

ENTITY TYPE ATTRIBUTE TYPE

SUPPLIER
SUPNR SUPNAME SUPADDRESS SUPCITY SUPSTATUS
21 Deliwines 240, Avenue of the Americas New York 20
32 Best Wines 660, Market Street San Francisco 90
37 Ad Fundum 82, Wacker Drive Chicago 95
ENTITIES 52 Spirits & co. 928, Strip Las Vegas NULL
68 The Wine Depot 132, Montgomery Street San Francisco 10
69 Vinos del Mundo 4, Collins Avenue Miami 92
…

ATTRIBUTES
 • Relationship Types
- De nition
- Degree and Roles (Unary: degree 1, binary: degree 2, ternary: degree 3)
- Cardinalities (if min If 0: partial participation / If 1: total participation or existence dependency)
- Relationship Attribute Types RNR
HNR

• Weak Entity Types (always existent dependent from owner entity type) HNR Room
0..N

BELONGS TO
1..1 Hotel

• Ternary Relationship Types

Beds
Hname

• Limitations of the ER model

• ER model presents a temporary snapshot and cannot model temporal constraints
- Examples: a project needs to be assigned to a department after one month, an
employee cannot return to a department…
• ER model cannot guarantee the consistency across multiple relationship types
- Examples: an employee should work in the department that he/she manages,
employees should work on projects assigned to departments…
• Domains are not included in the ER model
- Examples: hours should be positive; prodtype must be red, white or sparkling,
supstatus is an integer between 0 and 100.
• Functions are not included in the ER model
- Examples: calculate average number of projects an employee works on; determine
which supplier charges the maximum price for a product

Specialization
Process of de ning a set of subclasses of an entity type. “IS A” relationship.
(ie. Artist superclass with subclasses Singer and Actor)
• Disjointness constraint
ANR

- Disjoint specialization: entity can be a member of at aname

ARTIST

most one of the subclasses o

- Overlap specialization: the same entity can be a

SINGER ACTOR
member of more than one subclass music
style

• Completeness constraint
- Total specialization: every entity in the superclass must be a member of some
subclass
- Partial specialization: an entity to only belong to the superclass and to none of the
subclasses

Generalization (abstraction) is the reverse process of specialization.

Categorization
A category is a subclass that has several possible
superclasses (di erent entity types)
The category represents a collection of entities that is a
subset of the union of the superclasses. (Represented as U)
• Disjointness constraint
- Total categorisation: all entities of the superclasses belong to the subclass
- Partial categorisation: not all entities of the superclasses belong to the subclass
• Note: total categorization can also be represented as a specialization/
generalization!

Aggregation
Particular relationship type combined or aggregated into a higher-
CNR PNR

level aggregate entity type.

1..M 0..N
PROJECT
CONSULTANT

Useful when the aggregate entity type has its own attribute types 1..M
PARTICIPATION

date
1..1

CONTRACT CONTNR
fi
fi
ff
 Designing the EER Model
1. Identify the entity types
2. Identify the relationship types and assert their degree
3. Assert the cardinality ratios and participation constraints (total versus partial participation)
4. Identify the attribute types and assert whether they are simple or composite, single or
multiple valued, derived or not
5. Link each attribute type to an entity type or a relationship type
6. Denote the key attribute type(s) of each entity type
7. Identify the weak entity types and their partial keys
8. Apply abstractions such as generalization/specialization, categorization and aggregation
9. Assert the characteristics of each abstraction such as disjoint or overlapping, total or
partial

ER Model Relational model

Entity type Relation
Weak entity type Foreign key
1:1 or 1:N relationship type Foreign key
M:N relationship type New relation with two foreign keys
N-ary relationship type New relation with N foreign keys
Simple attribute type Attribute type
Composite attribute type Component attribute type
Multivalued attribute type Relation and foreign key
Key attribute type Primary or alternative key

EER model Relational Model

Entity type Relation
Entity Tuple
Attribute Cell
Attribute type Column name
 Relational Model
Student (Studentnr, Name, HomePhone, Address)

Professor (SSN, Name, HomePhone, E-mail)

Course (CourseNo, CourseName)

Domain
• speci es the range of admissible values for an attribute type (ie. gender domain, time
domain // or takes NULL value
• the value of each attribute type must be an atomic and single value from its domain.

Keys
- Superkeys
• uniqueness constraint
• redundant attribute types

- Candidate Keys
• an attribute or set of attributes that can uniquely identify a tuple (other than primary
key)

- Primary Keys
• identify tuples in the relation, to establish connections and for storage purposes
• Entity integrity constraint: satisfy a NOT NULL constraint
- Alternative key
• Other candidate keys are then referred to as alternative keys

- Foreign Keys
• (referential integrity constraint)
• The same domains as the primary key attributes
• Either a value of PK for some tuple in a state or is NULL

Relational Constraints

The value of each attribute type A must be an atomic and single value from
Domain constraint
the domain dom(A).
Key constraint Every relation has a key that allows to uniquely identify its tuples.
The attribute types that make up the primary key should always satisfy a
Entity integrity constraint
NOT NULL constraint.
Referential integrity A foreign key has the same domain as the primary key attribute type(s) it
constraint refers to and either occurs as a value of PK or NULL.
fi
Normalization
- Logical Level: to understand the meaning of the data and formulate correct queries)
- Implementation level: e cient storage usage and reduced risk of inconsistent updates

• First Normal Form (1 NF)

- every attribute type of a relation must be atomic and single valued
no composite or multivalued attribute types (domain constraint!)

• Second Normal Form (2 NF)

- (2 NF) if it satis es 1 NF and every non-prime attribute type A in R is
fully functional dependent on any key of R

• Third Normal Form (3 NF)

- (3NF) if it satis es 2 NF and no non-prime attribute type of R is transitively dependent
on the primary key

• Boyce-Codd Normal Form (BCNF)

- (BCNF) provided each of its non-trivial functional dependencies X → Y, X is a superkey.
that is, X is either a candidate key or a superset thereof.
- Every relation in BCNF is also in 3 NF (not vice versa!)

• Fourth Normal Form (4 NF)

- (4 NF) if it is in Boyce-Codd normal form and for every one
of its non-trivial multivalued dependencies X →→ Y, X is a
superkey—that is, X is either a candidate key or a superset

Data Warehousing and Business Intelligence

fi
fi
ffi
 Data Warehousing Schemas
1. Star schema
2. Snow ake schema: In case dimension tables grow too large
3. Fact constellation
4. Speci c schema issues

• Isolation Levels
fl
fi
 Compatibility Matrix

Isolation Levels

Database API Summary

Objects in host
Embedded or Early or late programming
Technology Data sources Other
call-level binding language
represent
Late binding,
Mainly rela onal
though prepared Microso -based
databases, though
SQL statements A result set with technology, not
ODBC Call-level other structured
possible as well as rows of elds object-oriented,
tabular sources
calling stored mostly outdated
possible as well
procedures
Late binding, Mainly rela onal Java-based
though prepared A result set with databases, though technology,
JDBC Call-level
SQL statements rows of elds other structured portable, s ll in
possible as well as tabular sources wide use
Java-based
Rela onal
A result set with technology, uses a
SQLJ Embedded Early binding databases
rows of elds pre-compiler,
suppor ng SQL
mostly outdated
A result set with
rows of elds, Examples: jOOQ
some mes Rela onal and LINQ, works
Language- Uses an Uses an
converted to a databases together with
integrated query underlying call- underlying late-
plain collec on of suppor ng SQL or another API to
technologies level API binding API
objects other data sources convert
represen ng expressions to SQL
en es
ti
ti
ti
ti
ti
ti
ti
fi
fi
fi
fi
ft
ti
ti
ti
ti
ti
 Objects in host
Embedded or Early or late programming
Technology Data sources Other
call-level binding language
represent
Late binding, Microso -based
Mainly rela onal
though prepared technology,
databases, though
SQL statements A result set with backwards
OLE DB and ADO Call-level other structured
possible as well as rows of elds compa ble with
tabular sources
calling stored ODBC, mostly
possible as well
procedures outdated
A result set with
rows of elds
Late binding, provided by a
Microso -based
though prepared DataReader, or a
technology,
SQL statements DataSet: a Various data
ADO.NET Call-level backwards
possible as well as collec on of sources
compa ble with
calling stored tables, rows, and
ODBC and OLE DB
procedures elds, retrieved
and stored by
DataAdapters
Java-based
Mainly rela onal
technology, works
Enterprise Uses an Uses an Plain Java en ty databases, though
together with
JavaBeans (EJB underlying call- underlying late- Beans as the main other structured
another API to
2.0) level API binding API representa on tabular sources
convert
possible as well
expressions to SQL
Java-based
Mainly rela onal
technology, works
Java Persistence Uses an Uses an Plain Java objects databases, though
together with
API (JDA in EJB underlying call- underlying late- as the main other structured
another API to
3.0) level API binding API representa on tabular sources
convert
possible as well
expressions to SQL
Uses an Uses an Plain Java objects
Java Database Various data Java-based
underlying call- underlying late- as the main
Objects (JDO) sources technology
level API binding API representa on
Plain objects
Various
ORM APIs de ned in the
Uses an Uses an implementa ons
(Ac veRecord, programming Rela onal
underlying call- underlying late- available for each
En ty Framework, language as the databases
level API binding API programming
SQL Alchemy) main
language
representa on
fi
ti
fi
ti
ti
ti
ti
ti
fi
fi
ft
ft
ti
ti
ti
ti
ti
ti
ti
ti
ti