1. Digital recordkeeping and preservation I
ER Modelling
ARK2100
Digital recordkeeping and preservation I
2016
Thomas Sødring
P48-R407

2. ER Modelling ER modelling stands for "Entity Relationship" modelling
It is used when you want to develop a database that stores data for a specific scenario
It can be used to define and resonate about a particular scenario
It is a conceptual modelling technique that defines entities (concepts) and relationships between these concepts
It is a process used to create a data model for a given problem area

3. ER Modelling
Conceptual data model without reference to any particular technology
Not solely used to develop databases, but we look at it for database development
Can be used to model the information needs of an organisation or for a given project
The end product of a data modelling process is a relational database schema
Carried out using a Top-down approach

4. Why we model
A good and correct representation of the data requirements is important so that
The database will support desired operations and requests
Simplify changes or updates to functionality
Remember the database sits underneath the application
If the data model is wrong, the application will be wrong
Application
Database

5. Why we model
Allows us to visualise something that can often be abstract
A model gives us a good overview
Easier to find mistakes
Models can be used as a basis for dialog between the customer / supplier
Simplifies implementation
Easier to change a model
Cheaper to correct errors in a model
The model serves as documentation
Source:

6. Why we model
The final outcome of the modelling process is a working schema in a DBMS
When working with ER-modelling we work with the following
Conceptual model
Abstract model independent of technology
Logical model
Logical Database structure implementable in any RDBMS
Physical model
Database structure in a particular RDBMS

7. How do we model
Starts with an analysis of the scenario you wish to model that leads to various descriptions
Declarative - what, not how
Precise - clear, agreed opinion
Atomic - a statement
Consistent - internally and externally
Expressible - structured, natural language
Unambiguous - no redundancy
Process-oriented
Source: unsure, many online resources use this

8. How do we model Very much an iterative process
You will probably develop a number of drafts
A whiteboard is very useful when you are a beginner
Later the draft is finalised in software tools
With experience you work directly on your PC
Use Professional Development Tools
The database structure made directly from the model
There are free online programs that can be used* *

9. How do we model You have to create a description of your scenario
You have to think conceptually
Often useful to have "janitor" or "chef" to talk to
Often when trying to explain a problem to someone who is not technically inclined it triggers new thoughts
useful if
You lock yourself in a particular train of thought
You are not progressing for some reason
Very much group work

10. Characteristics of a good model
What are the characteristics of a good conceptual data model
It reflects all relevant aspects of the scenario
Easily understandable and unambiguous even for people with limited technical ability
Can be systematically translated into a logical data model, which forms the basis for an actual implementation

11. Other resources
If you search online, you will see various descriptions of ER-Modelling
Some courses are very technical and these are intended for programmers
ER-Modelling is an abstraction of a given scenario at a level that can be understood by developers as well end-users
This course gives you a foundation to build an understanding from a customer perspective, not a developer perspective

12. ER versus UML
Modern software development may use a Modelling language called UML (Unified Modelling Language)
Remember ER-Modelling is from the 70s
ER-Modelling has been subsumed into UML
ER-Modelling is still important
Relational databases have not gone away and understanding how to model for the relational model is still important
Especially if you want to try understand an existing database from a preservation perspective

13. Modern software development
Modern software development is undertaken in a more iterative fashion than before with a greater focus on the business logic than database design
Application
Interface
Application
Business logic
Database
Database

14. What is an entity?
An entity represents a conceptual object, not a physical thing
“Car”
not “VW Golf” or “Toyota Yaris”
“Airport”
not, “Gardermoen” or “Heathrow”
“Building”
Not “P48” or “P52”
The object can be represented by only one entity
An entity must be uniquely identifiable

15. An entity

16. The entity name
Entity Name

17. An entity contains attributes
Entity Name
Attribute 1
Attribute 2
Attribute 3
Attribute 4
Attribute 5

18. Entities and Attributes
Attributes are used describe something about an entity
An entity describing modelling a car could have the following attributes
Registration number, chassis number, colour, manufacturer, model
An entity describing modelling an airport could have the following attributes
Name, International Code, Town, Country

19. Entity examples Car Airport Building RegistrationNr ChassisNr Colour
Manufacturer
Model
Name
Name
Location
Int Code
Address
Town
Country
Postnumber
Town

20. Entities and relations
It is important to understand
that an entity is implemented as a relation (table) in a schema (database)
that entity attributes become attributes (columns) in a relation (table)
In many ways the following slides show the conceptual model and physical models together

21. Entity Example : Car Car RegistrationNr ChassisNr Colour Manufacturer
Model
RegistrationNr
ChassisNr
Colour
Manufacturer
Model
LH12984
Red
Volkswagen
Golf
DK23491
Blue
Toyota
Yaris
BP12349
Green
Skoda
Fabia
ZT97495
White
Seat
Leon

22. Entity Example : Airport
Name
Int Code
Town
Country
Name
IntCode
Town
Gardermoen
OSL
Oslo
Heathrow
LHR
London
Stanstead
STN
Dublin
DUB
Country
Norway UK
IreCountry

23. Entity Example : Building
Name
Location
Address
Postnumber
Town
Name
Location
Address
Postnumber
Town
P48
Frydenlund
Pilestredet 48
0176
Oslo
P52
Pilestredet 52
Fyrhuset
Wergelandsv. 27 F5
Falbesgate
Falbesgate 5
0170

24. Relationship types one-to-one one-to-many many-to-one many-to-many
Mandatory relationship
Optional relationship

25. What one-to-one means
A one-to-one relationship between two tables, Table A and Table B, arises when each row of Table A can only have one related row in Table B
Student
StudentNr
Firstname
Surname
Surname
12345
Jan
Karlson
Karlson
23456
Pål
Solberg
Solberg
34567
Mette
Johansen
Johansen
45678
Ingrid
Aleksandersen
Aleksandersen
StudentTelephoneNr
StudentNr
TelephoneNr
12345
23456
34567
45678

26. What one-to-one means This is illegal in a one-to-one relationship
Student
StudentNr
Firstname
Surname
Surname
12345
Jan
Karlson
Karlson
23456
Pål
Solberg
Solberg
34567
Mette
Johansen
Johansen
45678
Ingrid
Aleksandersen
Aleksandersen
StudentTelephoneNr
StudentNr
TelephoneNr
12345
12345
Illegal in a one-to-one relationship
34567
45678

27. What one-to-many means
A one-to-many relationship between two tables, Table A and Table B, occurs when each row in Table A can have many related rows in Table B (while each row of Table B has only one related row in Table A)
Student
StudentNr
Firstname
Surname
Surname
12345
Jan
Karlson
Karlson
23456
Pål
Solberg
Solberg
34567
Mette
Johansen
Johansen
45678
Ingrid
Aleksandersen
Aleksandersen
StudentTelephoneNr
StudentNr
TelephoneNr
12345
12345
34567
34567

28. Mandatory versus Obligatory
We commented that there are both mandatory and optional relationships
Using the Student/Telephone example
Mandatory relationship
Every student must have a telephone number
Optional relationship
Every student can have a telephone number

29. Many-to-many relationships
A many-to-many relationship is problematic for the relational model
Can not be implemented in a relational database
Primary keys can not be duplicates
Within the relational model, it has to be handled
A many-to-many relationship typically conceals a hidden entity
Handled by identifying and dissolving the original many-to-many into two one-to-many relationships

30. Remember why we model
The final outcome of the modelling process is a working schema in a DBMS
When working with ER-modelling we work with the following
Conceptual model
Abstract model independent of technology
Logical model
Logical Database structure implementable in any RDBMS
Physical model
Database structure in a particular RDBMS

31. From conceptual to logical
So given an ER conceptual model, the next stage is to convert it to a logical model
This can be done by following a few straight forward steps
First we look at a simple example, the Car, Airport and Building entities
There are no relationships between these so the logical model is simple

32. Our entities Car Airport Building RegistrationNr ChassisNr Colour
Manufacturer
Model
Name
Name
Location
Int Code
Address
Town
Country
Postnumber
Town

33. Logical model Airport (Name, IntCode, Town, Country)
Car (RegistrationNr, ChassisNr, Colour, Manufacturer, Model)
Airport (Name, IntCode, Town, Country)
Building (Name, Location, Address, Postnumber, Town)

34. From a logical to a physical model
So given an ER logical model, the next stage is to convert it to a physical model
This is also pretty straight forward, but dependent on the DBMS you are using
We will take a look at our logical models and convert them to a physical implementation in MySQL

35. From a logical to a physical model
CREATE TABLE Car (
RegistrationNr VARCHAR(20),
ChassisNr VARCHAR(20),
Manufacturer VARCHAR(30),
Model VARCHAR(20),
Colour VARCHAR(20),
PRIMARY KEY (RegistrationNr) )
The examples show
how the various
entities would
be implemented
in MySQL
CREATE TABLE Airport (
Name VARCHAR(20),
IntCode CHAR(3),
Town VARCHAR(20),
Country VARCHAR(20),
PRIMARY KEY (Name) )
CREATE TABLE Building (
Name VARCHAR(20),
Location VARCHAR(30),
Address VARCHAR(30),
Postnumber VARCHAR(4),
Town VARCHAR(100),
PRIMARY KEY (Name) )

36. ER Modelling
If we go back to our car rental example, we have two related entities
Customer
CustomerNr
Car
Firstname
RegistrationNr
Surname
DOB
Manufacturer
LicenseType
Model
Telephonenr*
Fuel
Address
Colour
Postnumber
Town
*Telephonenr is a multivalue attribute

37. Conversion to logical model
Entities become relations
Many-to-many relationships are converted to two one-to-many relationships
Multi-valued attributes are converted to their own relation
For one-to-many relationships, foreign keys are inserted on the many side
For one-to-one relationships, foreign keys are inserted
Identify primary and foreign keys

38. 1. Entities become relations
Customer (CustomerNr, Firstname, Surname, DOB, LicenseType, TelephoneNr, Address, Postnumber, Town)
Car (RegistrationNr, Manufacturer, Model, Fuel, Colour)

39. 2. Many-to-many relationships are converted to two one-to-many relationships
Customer (CustomerNr, Firstname, Surname, DOB, LicenseType, Telephonenr, Address, Postnumber, Town)
Car (RegistrationNr, Manufacturer, Model, Fuel, Colour)
Rental (FromDate, ToDate, Mileage)
Rental
FromDate
ToDate
Mileage
Customer
CustomerNr
Firstname
Surname
DOB
LicenseType
Address
Postnumber
Town
Telephonenr*
Car
RegistrationNr
Manufacturer
Model
Fuel
Colour

40. 3. Multi-valued attributes are converted to their own relation
Customer (CustomerNr, Firstname, Surname, DOB, LicenseType, Address, Postnumber, Town)
Car (RegistrationNr, Manufacturer, Model, Fuel, Colour)
Rental (FromDate, ToDate, Mileage)
Telephonenr (telephoneNumber)
Rental
FromDate
ToDate
Mileage
Customer
CustomerNr
Firstname
Surname
DOB
LicenseType
Address
Postnumber
Town
Telephonenr*
Car
RegistrationNr
Manufacturer
Model
Fuel
Colour
Telephonenr
telephonenr

41. 4. For one-to-many relationships, foreign keys are inserted on the many side
Customer (CustomerNr, Firstname, Surname, DOB, LicenseType, Address, Postnumber, Town)
Car (RegistrationNr, Manufacturer, Model, Fuel, Colour)
Rental (CustomerNr, RegistrationNr, FromDate, ToDate, Mileage)
Telephonenr (CustomerNr, telephoneNumber)
Rental
FromDate
ToDate
Mileage
CustomerNr
RegistrationNr
Customer
CustomerNr
Firstname
Surname
DOB
LicenseType
Address
Postnumber
Town
Telephonenr*
Car
RegistrationNr
Manufacturer
Model
Fuel
Colour
Telephonenr
telephonenr
CustomerNr

42. 5. For one-to-one relationships, foreign keys are inserted
Customer (CustomerNr, Firstname, Surname, DOB, LicenseType, Address, Postnumber, Town)
Car (RegistrationNr, Manufacturer, Model, Fuel, Colour)
Rental (CustomerNr, RegistrationNr, FromDate, ToDate, Mileage)
Telephonenr (CustomerNr, telephoneNumber)

43. 6. Identify primary and foreign keys
Customer (CustomerNr, Firstname, Surname, DOB, LicenseType, Address, Postnumber, Town)
Car (RegistrationNr, Manufacturer, Model, Fuel, Colour)
Rental (CustomerNr*, RegistrationNr*, FromDate, ToDate, Mileage)
Telephonenr (CustomerNr*, telephoneNumber)

44. Remember why we model
The final outcome of the modelling process is a working schema in a DBMS
When working with ER-modelling we work with the following
Conceptual model
Abstract model independent of technology
Logical model
Logical Database structure implementable in any RDBMS
Physical model
Database structure in a particular RDBMS

45. From a logical to a physical model
So given an ER logical model, the next stage is to convert it to a physical model
This is also pretty straight forward, but dependent on the DBMS you are using
We will take a look at our Car rental logical model and convert it to a physical implementation in MySQL

46. From a logical to a physical model
CREATE TABLE Customer (
CustomerNr INT NOT NULL AUTO_INCREMENT,
Firstname VARCHAR(30),
Surname VARCHAR(30),
DOB DATE,
LicenseType VARCHAR(10),
Address VARCHAR(100),
Postnumber VARCHAR(4),
Town VARCHAR(100),
PRIMARY KEY (CustomerNr)
) engine = innoDB;
CREATE TABLE Car (
RegistrationNr VARCHAR(20),
Manufacturer VARCHAR(30),
Model VARCHAR(20),
Fuel VARCHAR(10),
Colour VARCHAR(20),
PRIMARY KEY (RegistrationNr)
CREATE TABLE Rental (
CustomerNr INT,
FromDate DATE,
ToDate DATE,
Mileage INT,
PRIMARY KEY (CustomerNr, RegistrationNr, FromDate, ToDate),
FOREIGN KEY (CustomerNr) REFERENCES Customer (CustomerNr),
FOREIGN KEY (RegistrationNr) REFERENCES Car (RegistrationNr)
CREATE TABLE Telephonenr (
TelephoneNumber VARCHAR(20),
PRIMARY KEY (CustomerNr, TelephoneNumber),
FOREIGN KEY (CustomerNr) REFERENCES Customer (CustomerNr)
The example on the
left shows how the car
rental schema would
be implemented
in MySQL

47. ER modelling and normalisation
Thinking back to the disastrous model we had for Car rental when we looked at normalisation
It is clear that had we undertaken ER- modelling instead of just using Excel, we would have had a decent model to begin with
You should also be able to see that normalisation happens as part of the ER-modelling process
Normalising to 2NF may lead to new entities being identified
3NF and above done at the end of ER- modelling process
In many ways, they are undertaken in parallel

48. Another example
You have been asked model and develop a database that can be used at a school to keep track of the subjects students take and who teaches the different modules
What is the 'system' we want to model?
How do we describe it?

49. Remember
Starts with an analysis of the scenario you wish to model that leads to various descriptions
Declarative - what, not how
Precise - clear, agreed opinion
Atomic - a statement
Consistent - internally and externally
Expressible - structured, natural language
Unambiguous - no redundancy
Process-oriented
Source: unsure, many online resources use this

50. School database Clarifications
Subjects and modules in this case means the same
A student may take additional modules
A module is taken by many students
A module is taught by only one teacher
A teacher teaches several modules
These are the kind declarative statements you need to agree upon with the client

51. Identifying entities Define the boundaries for the scenario
What are the 'physical' entities?
Teacher
Student
Student
Teacher

52. Identifying entities
At the same time you can see that Module is also an entity, even though a Module is not something that is physical
Sometimes it can be easy to see the entities that represent something physical but difficult to see the ones that are not physical
In this regard ER-modelling is more of an art than just a science
Teacher
Student
Module

53. School database What about the attributes?
A teacher has the following attributes
ID, firstname, surname, address, telephone number
A student has the following attributes
ID, firstname, surname, address, semester address, telephone number

54. Ambiguities There are still ambiguities in the description
What is a semester address?
Can a student have multiple addresses
Often students change address during the semester, what about their home address?
Can a module really only be taught by one teacher?
The fewer ambiguities you have now, the better the model will be
We will give it a go anyway

55. School conceptual model
This conceptual model has the main entities covered
But we are missing the attributes
In a large model (100's of entities) the attributes could make the model difficult to read
Student
Module
moduleId
moduleName
Teacher
empNr
firstname
lastname
Address
address
telephoneNumber
studentNr
firstname
lastname
Address
semesterAddress
telephoneNumber

56. Conversion to logical model
Entities become relations
Many-to-many relationships are converted to two one-to-many relationships
Multi-valued attributes are converted to their own relation
For one-to-many relationships, foreign keys are inserted on the many side
For one-to-one relationships, foreign keys are inserted
Identify primary and foreign keys

57. 1. Entities become relations
Student (studentNr, firstname, lastname, Address,
semesterAddress, telephoneNumber)
Teacher (empNr, firstname, lastname, Address, address,
telephoneNumber)
Module (moduleId, moduleName)

58. 2. Many-to-many relationships are converted to two one-to-many relationships
Student (studentNr, firstname, lastname, Address,
semesterAddress, telephoneNumber)
Teacher (empNr, firstname, lastname, Address, address,
telephoneNumber)
Module (moduleId, moduleName)
Enrollment (year)
Teacher
Student
Module
Enrollment

59. 4. For one-to-many relationships, foreign keys are inserted on the many side
Student (studentNr, firstname, lastname, Address,
semesterAddress, telephoneNumber)
Teacher (empNr, firstname, lastname, Address, address,
telephoneNumber)
Module (moduleId, moduleName, empNr)
Enrollment (studentNr, moduleId, year)

60. 5. For one-to-one relationships, foreign keys are inserted
Student (studentNr, firstname, lastname, Address,
semesterAddress, telephoneNumber)
Teacher (empNr, firstname, lastname, Address, address,
telephoneNumber)
Module (moduleId, moduleName, empNr)
Enrollment (studentNr, moduleId, year)

61. 6. Identify primary and foreign keys
Student (studentNr, firstname, lastname, Address,
semesterAddress, telephoneNumber)
Teacher (empNr, firstname, lastname, Address, address,
telephoneNumber)
Module (moduleId, moduleName, empNr*)
Enrollment (studentNr*, moduleId*, year)

62. From a logical to a physical model
CREATE TABLE Student (
studentNr VARCHAR(10),
firstname VARCHAR(30),
lastname VARCHAR(30),
Address VARCHAR(10),
semesterAddress VARCHAR(100),
telephoneNumber VARCHAR(4),
PRIMARY KEY (studentNr)
) engine = innoDB;
CREATE TABLE Teacher (
empNr VARCHAR(10),
address VARCHAR(10),
PRIMARY KEY (empNr)
CREATE TABLE Module (
moduleId CHAR(7),
moduleName VARCHAR(20),
PRIMARY KEY (moduleId),
FOREIGN KEY (empNr) REFERENCES Teacher (empNr)
CREATE TABLE Enrollment (
moduleId VARCHAR(20),
year CHAR(4),
PRIMARY KEY (studentNr, moduleId, year),
FOREIGN KEY (studentNr) REFERENCES Student (studentNr),
FOREIGN KEY (moduleId) REFERENCES Module (moduleId)
The example on the
left shows how the school
schema would
be implemented
in MySQL

63. School database solution
Enrollment
Module
studentNr
year
moduleId
moduleId
moduleName
empId
12345
2012 1 1
Matte 3
12345
2012 2 2
Fysikk 3
12345
2012 5 3
Norsk 1
34567
2012 1 4
Engelsk 2
34567
2012 3 5
Fransk 4
45678
2012 4
45678
2012 5
45678
2012 3
Teacher
Student
firstname
surname
empId
studentNr
firstname
surname
Surname
Thomas
Hansen 1
12345
Jan
Karlson
Karlson
Markus
Haugen 2
34567
Mette
Johansen
Johansen
Mette
Dahl 3
45678
Ingrid
Aleksandersen
Aleksandersen
Hilde
Berg 4

64. Some thoughts
The more ambiguous the description, the greater the chance
errors will be introduced in the model
that the model does not cover the scenario adequately
More than likely that many teachers will teach many modules
Fixing this once the system has been developed can be expensive
Teacher
Student
Module

65. Some thoughts
Even a small database will likely have many entities, entities
Also, it his highly likely that this data will be used by other applications
Timetable scheduling
Payroll
Classroom booking
Exams
A good designer will foresee this and even though the model currently has a limited scope will ensure that the model can easily be adapted

66. Final example Gerd Berget has an example Cinema database in her book
The ER conceptual model is given
We will convert the conceptual model to a logical model
We go through the 6 steps
Finally we convert it the logical model to a physical model

67. Theater
theaterNr
capacity
Distributor
distributorID
name
address
postnr
town
Contributor
personId
firstname
surname
dob
deathDate
filmId
title
year
length
manufacturer
Film
customerNr
Customer

68. 1. Entities become relations
Contributor (personId, firstname, surname, dob, deathDate)
Film (filmId, title, year, length, manufacturer)
Distributor (distributorId, name, address, postnr, town)
Customer (customerNr, firstname, surname, address, postnr, town)
Theater (theaterNr, capacity)

69. 2. Many-to-many relationships are converted to two one-to-many relationships
Contributor (personId, firstname, surname, dob, deathDate)
Film (filmId, title, year, length, manufacturer)
Distributor (distributorId, name, address, postnr, town)
Customer (customerNr, firstname, surname, address, postnr, town)
Theater (theaterNr, capacity)
Participation (role)
Booking (bookingDate, time, amount)

70. Theater
theaterNr
capacity
Distributor
distributorID
name
address
postnr
town
Contributor
personId
firstname
surname
dob
deathDate
role
Participation
Booking
bookingDate
time
amount
filmId
title
year
length
manufacturer
Film
customerNr
Customer

71. 4. For one-to-many relationships, foreign keys are inserted on the many side
Contributor (personId, firstname, surname, dob, deathDate)
Film (filmId, title, year, length, manufacturer, distributorId)
Distributor (distributorId, name, address, postnr, town)
Customer (customerNr, firstname, surname, address, postnr, town)
Theater (theaterNr, capacity)
Participation (filmId, personId, role)
Booking (filmId, customerNr, bookingDate, time, amount)

72. Distributor
distributorID
name
address
postnr
town
Contributor
Film
filmId
personId
firstname
surname
dob
deathDate
title
year
length
manufacturer
Participation
distributorID
filmId
personId
role
customerNr
Customer
firstname
surname
address
postnr
town
Booking
bookingId
time
amount
filmId
customerNr
Theater
theaterNr
capacity

73. 5. For one-to-one relationships, foreign keys are inserted
Contributor (personId, firstname, surname, dob, deathDate)
Film (filmId, title, year, length, manufacturer, distributorId)
Distributor (distributorId, name, address, postnr, town)
Customer (customerNr, firstname, surname, address, postnr, town)
Theater (theaterNr, capacity, filmId)
Participation (filmId, personId, role)
Booking (filmId, customerNr, bookingDate, time, amount)

74. Distributor
distributorID
name
address
postnr
town
Contributor
Film
filmId
personId
firstname
surname
dob
deathDate
title
year
length
manufacturer
Participation
distributorID
filmId
personId
role
customerNr
Customer
firstname
surname
address
postnr
town
Booking
bookingId
time
amount
filmId
customerNr
Theater
theaterNr
capacity
filmId

75. 6. Identify primary and foreign keys
Contributor (personId, firstname, surname, dob, deathDate)
Film (filmId, title, year, length, manufacturer, distributorId*)
Distributor (distributorId, name, address, postnr, town)
Customer (customerNr, firstname, surname, address, postnr, town)
Theater (theaterNr, capacity, filmId)
Participation (filmId*, personId*, role)
Booking (filmId*, customerNr*, bookingDate, time, amount)

76. Distributor
distributorID
name
address
postnr
town
Contributor
Film
filmId
personId
firstname
surname
dob
deathDate
title
year
length
manufacturer
Participation
distributorID
filmId
personId
role
customerNr
Customer
firstname
surname
address
postnr
town
Booking
bookingId
time
amount
filmId
customerNr
Theater
theaterNr
capacity
filmId

77. CREATE TABLE Contributor (
personId INT NOT NULL AUTO_INCREMENT,
firstname VARCHAR(30),
surname VARCHAR(30),
dob DATE,
deathDate DATE,
PRIMARY KEY (personId)
) engine = innoDB;
CREATE TABLE Theater (
theaterNr INT NOT NULL,
capacity INT,
filmId INT,
PRIMARY KEY (theaterNr),
FOREIGN KEY (filmId) REFERENCES Film (filmId)
) engine = innoDB;
CREATE TABLE Distributor (
distributorId INT NOT NULL AUTO_INCREMENT,
address VARCHAR(100),
postnr VARCHAR(4),
town VARCHAR(100),
PRIMARY KEY (distributorId)
) engine = innoDB;
CREATE TABLE Participation (
filmId INT,
personId INT,
role VARCHAR(100),
PRIMARY KEY (filmId, personId, role),
FOREIGN KEY (filmId) REFERENCES Film (filmId),
FOREIGN KEY (personId) REFERENCES
Contributor (personId)
) engine = innoDB;
CREATE TABLE Film (
filmId INT NOT NULL AUTO_INCREMENT,
tittle VARCHAR(30),
year CHAR(4),
length INT,
manufacturer VARCHAR(30),
distributorId INT,
PRIMARY KEY (filmId),
FOREIGN KEY (distributorId) REFERENCES
Distributor (distributorId)
) engine = innoDB;
CREATE TABLE Booking (
filmId INT,
customerNr INT,
bookingDate DATE,
time TIME,
amount INT,
PRIMARY KEY (filmId, customerNr, bookingDate, time),
FOREIGN KEY (filmId) REFERENCES Film (filmId),
FOREIGN KEY (customerNr) REFERENCES
Customer (customerNr)
) engine = innoDB;
CREATE TABLE Customer (
customerNr INT NOT NULL AUTO_INCREMENT,
firstname VARCHAR(30),
surname VARCHAR(30),
address VARCHAR(100),
postnumber VARCHAR(4),
town VARCHAR(100),
PRIMARY KEY (customerNr)
) engine = innoDB;

78. Recap
We have looked at ER-modelling and have seen the three different phases we go through
Conceptual, logical and physical
Conceptual and logical are most important today, we will do a lot more work on the physical model during the semester
You cannot expect to understand ER-modelling after this introduction
You learn through practice
The process is important

79. Recap We have seen four various examples Car, Airport, Building
Car Rental
School
Cinema
The complexity increases each time, but we always follow the same steps

80. Recap
The process is very individual and based on your knowledge and experience
Describe the scenario and refine until necessary granularity has been achieved
Using descriptions define entities and relationships between them
Identify the attributes of entities
Conceptual to logical to physical
Larger scenarios will have many iterations and some suggestions that are discarded before a solution is reached
Work with small parts of the problem at a time and let your conceptual model evolve
Do not try to solve it in one go – iteration!

81. Finally We have explored The concept of databases
The relational model and related issues
ER-modelling
Conceptual, logical and physical
We should now have a basic understanding in how these all hang together
Next we explore how to implement a model in the database, insert, update and retrieve data from a database
Finally look at how the Noark standard is implemented in a relational database