1. From conceptual to relational data model
Karolina Muszyńska
Based on: J. A. Hoffer, J. F. George, J. S. Valacich „Modern Systems Analysis and Design”, Pearson, 2014

2. Topics Conceptual data model Logical data model Relational data model
Transformation of conceptual model into a relational data model

3. Modeling in databases life cycle
Databases lifecycle consists of the following 5 stages:
Analysis
Analyst creates a conceptual data model of this part of reality which is of interest from the system point of view
Design
Designer, basing on the conceptual data model, creates an implementation model, which precisely describes the schema of the database
Programming
Programmer, basing on the implementation model, creates the database system
Implementation
System is installed on the default hardware platform, and initial data is inserted
Maintenance
Administrator takes care of the system, so that it is functional

4. Conceptual data model
Conceptual data model is a kind of a filter set on reality
It ignores everything that is outside the scope of the modeled part of reality (which is always perceived from a certain perspective)
Includes everything that belongs to the modeled part of reality
It is a model of reality, not of the target system
It does not include most of the details, which are determined during design phase
May include elements, which will be ignored during the design phase

5. Elements of the conceptual data model
Conceptual data model includes three types of elements:
Entities – types of objects existing in the modeled scope of reality
Attributes – features assigned to objects in the modeled scope of reality
Relationships – dependencies among objects in the modeled scope of reality

6. Entities Rules corresponding to modeling entities:
Each entity has a unique name
Each entity has a set of attributes
Entities form relations with other entities
Any object can be represented by only one entity (no duplication is allowed)
Entity name should be a singular noun

7. Attributes Identifier Descriptor
Unambiguously indicates a certain instance of an entity
i.e. Registration_number for a CAR entity
May be natural (existing in reality, i.e. Registration_number) or artificial (inserted for the purpose of the model, i.e. Company_Car_Number)
Descriptor
Every attribute, which is not an identifier
May be:
Obligatory (its value is always determined, i.e. Second_name attribute for the PERSON entity), or
Optional (its value may be undefined, i.e. Phone_number for the PERSON entity)

8. Relationships
Relationships among entities are classified according to:
Degree of the relation
Binary, unary, ternary, n-ary
Cardinality of the relation
One-to-one, one-to-many, many-to-many
Optionality
Optional, mandatory

9. Binary relationships- examples
One-to-one
Car – Driver (is driven by)
Student – Thesis (writes)
One-to-many
Examiner – Subject (examines in)
Producer – Product (produces)
Many-to-many
Author – Book (wrote, was written by)
Musician – Music Band (plays in, consists of)

10. Unary relationships - examples
Unary relationships are relations which have only one participating entity, which is related to itself.
One-to-one
Society_member (invited by)
One-to-many
Worker (is superior)
Many-to-many
Employee (can substitute)

11. Ternary relationships - examples
Ternary relationships are relations binding three entities
One-to-one
Go-kart – Driver – Time (driven by, obtained)
Seminar student – Diploma Thesis – Deadline (submits, within)
One-to-many
Examiner – Subject – Group (examines in, in)
Producer – Product – Trademark (produces, under)
Many-to-many
Author – Book – Literary_category (wrote, in)
Muscian – Music_Band – Instrument (plays in, on)
N-ary relationships bind n entities

12. Optionality of relationships
Optionality concerns each side of the relationship separately
Go-kart /mandatory/ – Driver /mandatory/
Every go-kart has a driver and every driver has a go-kart
Go-kart /mandatory/ – Driver /optional/
Not every go-kart has a driver but every driver has a go- kart
Go-kart /optional/ – Driver /mandatory/
Every go-kart has a driver but not every driver has a go- kart
Go-kart /optional/ – Driver /optional/
Not every go-kart has a driver and not every driver has a go-kart

13. Hierarchy of entities
Parent entity is an entity whose all attributes are attributes of other entities (are included in child entities)
Child entity is an entity which includes all attributes of the parent entity and can have some additional attributes
The relationship between parent and child entities is called generalization-specialization relationship
Example: Employee (parent entity), Teacher (child), Researcher (child), Administration staff (child)

14. Exclusive relationships
Exclusive relationships are used to show that a certain instance of an entity can be at a certain moment of time in relation with only one of two or more possible relationships
Example
Car –(belongs to)– Natural_person or Car –(belongs to)– Legal_person
Cabin –(assigned to)– Passenger or Cabin –(assigned to)– Crew_member or Cabin –(assigned to)– Ship-owner

15. Formalization of the model
Conceptual data model created in the analysis phase must be precisely and unambiguously presented, so that it can be used in further phases of databases design
The most common way of presenting the conceptual model is with the use of graphical methods, i.e. the entity-relationship diagrams (ERD)

16. ERD (entity-relationship diagram)

17. Logical data model
In order to create a database, the conceptual data model must be transformed into a logical data model
Logical data model defines:
Data structures
Operations
Integrity constraints

18. Types of logical data models
File
Hierarchical
Network
Relational
Object
Semi-structural

19. Relational model
In a relational model a database is a set of relations
Relations are shown as two-dimensional tables
This type of model:
Is not so much linked with physical implementation
Makes it easier to avoid redundancy
Makes it easier to ensure data integrity and access control

20. Relation characteristics
Each relation (table) in the database has a unique name
Each column in a table has a unique name (attribute)
All values in a column must be of the same type (must belong to the same domain)
The order of columns in a relations (table) is not important
The order of rows in a relation (table) is not important
Each row in a relation (table) must be unique, which means that it has to differ with at least one value
Relation (table) must have at least one column but it can have zero rows

21. Simple and compound keys
If a key consists of only one attribute it is a simple key (i.e. Personal identifier)
If a key consists of two or more attributes it is a compound key (i.e. Second_name, First_name)

22. Primary and candidate keys
If a relation has only one key it is the primary key of this relation
If a relation has more than one key, they are called candidate keys and the designer chooses one of them to be the primary key

23. Foreign key
Foreign key of a relation is an attribute or a set of attributes, which is a primary key of another relation (table)
Foreign keys make it possible to represent relationships among tables

24. Integrity constraints
Primary key
Must have unique values
Cannot have NULL values
Foreign key
Attributes which make up the foreign key must be of the same domain as the corresponding primary key attributes of the related table
For each value of the foreign key (except NULL) there must be a corresponding record from the related table with the same value of the primary key

25. Domain constraint
Attribute domain constraint is a limitation of possible values of a certain attribute to a subset of its type by defining a list, intervals or a pattern of possible values
Examples:
Hair: blond, red, brown, black
Hours_worked: 0-24
Postal_code: [0-9][0-9]-[0-9][0-9][0-9]

26. Transformation of conceptual data model into a relational data model
All elements of the conceptual data model must be transformed:
Entities
Attributes
Relationships
1:1, 1:n, m:n
Unary, binary
Hierarchical, exclusive

27. Transformation of entities and their attributes
Entity is transformed into a relation (table)
Name of the entity becomes the name of the relation (table)
Names of the relations are usually plural nouns
Entity attributes become table attributes. Names of entity attributes become names of columns
Unique identifier of the entity becomes the primary key of the relation
Entity attribute data types become relation attribute data types

28. Transformation of 1:1 binary one-sidedly optional relationships
A 1:1 binary one-sidedly optional relationship is transformed to a foreign key in the table, which is on the mandatory side
The integrity constraint is defined for the attribute of the foreign key: the foreign key cannot assume null values

29. Transformation of 1:1 binary two-sidedly optional relationships
A 1:1 two-sidedly optional binary relationship is transformed to a foreign key in the table of a smaller dimension.
The integrity constraint is defined for the attribute of the foreign key: the foreign key can assume null values because the relationship is optional

30. Transformation of 1:N binary relationships
The foreign key is added to the relation which is on the „many” side of the relationship, no matter what is the optionality of this relationship
Integrity constraints are defined for the attribute representing the foreign key
The obligation of the relationship on the „one” side is represented by the NOT NULL integrity constraint on the foreign key of the relation
The optionality on the „one” side is represented by the NULL integrity constraint defined on the foreign key of the relation
Optionality or obligation of the relationship on the „many” side is not represented in the relational model

31. Transformation of M:N binary relationships
A M:N binary relationship is represented by an additional relation (table)
The additional relation has foreign keys related to the primary keys of the relations (tables) created on the bases of the related entities
Foreign keys make up the primary key of the additional table: their values can therefore never be NULL

32. Transformation of unary relationships
A 1:1 or 1:N unary relationship is transformed to the foreign key in the same table
A M:N unary relationship is transformed into an intermediate table

33. Transformation of hierarchical relationships
Hierarchy of entities can to transformed into the relational model in 3 ways:
By creating one table with all attributes and foreign keys, that is with those common and specific for child entities
By creating a separate table for each child entity. Each table includes common attributes and specific for each child entity
By creating a separate table for common attributes and a separate table for each child entity. The tables created from child entities include the primary key and specific attributes. The common table and the tables created from child entities are related by integration constraints.

34. Transformation of exclusive relationships
Like in 1:N transformations but foreign keys may have NULL values
Only one foreign key (for both tables), a necessary type discriminant