2. Agenda
• About Mii
• Theory of databases
• Relational databases
• Relationships
• ERM/ERD
• Normalization
3. About Mii
I know… the picture is my Live Avatar… because he is simply
beautiful
4. About Mii
Health
Developer Level 38
Mana
Strength:
Agility:
Intelligence:
Willpower:
Vitality:
•
•
•
•
•
•
•
3745
5467
56
89
423
345
212
25 years
past Bigpoint, currently InnoGames
studied at Games Academy
worked many years as freelancer
lecturer for game development
focused on high level architecture for
frontend and backend
aka Ezio Auditore da Firenze
6. Theory of databases
A database is an organized collection of data
• 1960s - navigational DBMS
• 1970s - relational DBMS
• late 1970s - SQL DBMS
• 1980s - desktop DBMS and object-oriented DBMS
• 2000s - NoSQL & NewSQL DBMS
• DBMSs (database management systems): software that interacts
with the user, other applications, and the database itself to
capture and analyze data
• different kinds of data models
7. Theory of databases
Common logical data models for databases include:
• Hierarchical database model
• Network model
• Relational model
• Entity–relationship model
• Enhanced entity–relationship model
• Object model
• Document model
• Entity–attribute–value model
• Star schema
8. Theory of databases
Physical data models include:
• Inverted index
• Flat file
Other models include:
• Associative model
• Multidimensional model
• Multivalue model
• Semantic model
• XML database
• Named graph
10. Relational databases
• a relational database is a database that has a collection of tables
of data items
• all of which are formally described and organized according to
the relational model
• tables may have additionally defined relationships with each
other
• each table scheme must identify a column or group of columns
called primary key
• a relationship can then be established between each row in the
table and a row in another table by creating a foreign key
• relational model offers various levels of refinement of table
organization and reorganization called database normalization
12. Relationships
• relationships between tables have quantities, called cardinalities
• this shows how many entities of an entity type can or have to
stand in relation with exactly one entity of the other entity type
involved in the relationship type (and the other way around)
• to display cardinality there are different notation forms (we use
Chen)
• types of cardinalities
•
1:1
•
1:n
•
n:m
13. Relationships
•
1:1
•
•
•
1:n
•
•
•
in a 1:1 relationship there is exactly one entity assigned to exactly one
other entity
the primary key of one of the two tables is used as foreign key of the
other table in an additional column
an entity on one side of the relationship (master) is confronted by none,
one or more than one entities on the other side (detail)
the detail table gets an additional column, that receives the primary key
of the master table as foreign key
n:m
•
•
there can be any amount of entities in relationships with each other.
an additional table is generated for implementation, that contains the
primary keys of both tables as foreign keys
15. ERM/ERD
• Entity Relationship Model/Diagram
• part of software engineering (SE)
• abstract way of describing a database
• three levels of models
•
Conceptual data model
•
Logical data model
•
Physical data model
• the first stage of information system design uses these models
during the requirements analysis
• different notations (part of UML, we use Chen)
• Tools: MySQL Workbench and Open ModelSphere
17. ERM/ERD
Chen proposed the following "rules of thumb" for mapping
natural language descriptions into ER diagrams
English grammar structure
ER structure
Common noun
Entity type
Proper noun
Entity
Transitive verb
Relationship type
Intransitive verb
Attribute type
Adjective
Attribute for entity
Adverb
Attribute for relationship
19. Normalization
• Normalization
• is a process of organizing fields and tables of a relation database
• minimizes redundancy and dependency
• usually involves dividing large tables into smaller tables and
defining relationships between them
• selective denormalization can be performed for performance
reasons
• Edgar F. Codd, the inventor of the relational model introduced
the concept of normalization and the first normal form
• currently there are nine normal forms (first three are interesting
for us)
20. Normalization
first normal form
A relation is in first normal form if the domain of each
attribute contains only atomic values, and the value of each
attribute contains only a single value from that domain.
23. Normalization
id
name
track
title
2001
1
Baby Please Don't Go
2001
High Voltage
2
She's Got Balls
2002
id
High Voltage
T.N.T.
1
It's a Long Way to the Top
name
2001
High Voltage
2002
T.N.T.
cd_id
track
title
2001
1
Baby Please Don't Go
2001
2
She's Got Balls
2002
1
It's a Long Way to the
Top
24. Normalization
third normal form
Every non-prime attribute is non-transitively dependent on
every candidate key in the table. The attributes that do not
contribute to the description of the primary key are removed
from the table. In other words, no transitive dependency is
allowed.
25. Normalization
id
2001
High Voltage
AC/DC
1
Baby Please Don't Go
2002
id
name
interpret
Queen
Queen
1
Keep Yourself Alive
name
track
id
title
track
title
cd_id
101
AC/DC
10
1
Baby Please Don't Go
12001
102
Queen
11
1
Keep Yourself Alive
12002
id
name
interpret_id
12001
High Voltage
101
12002
Queen
102
26. Normalization
Elementary Key normal Form
Every non-trivial functional dependency in the table is either
the dependency of an elementary key attribute or a
dependency on a superkey.
Boyce–Codd normal form
Every non-trivial functional dependency in the table is a
dependency on a superkey.
27. Normalization
Fourth normal form
Every non-trivial multivalued dependency in the table is a
dependency on a superkey.
Fifth normal form
Every non-trivial join dependency in the table is implied by
the superkeys of the table.
28. Normalization
Domain/key normal form
Every constraint on the table is a logical consequence of the
table's domain constraints and key constraints.
Sixth normal form
Table features no non-trivial join dependencies at all (with
reference to generalized join operator).