FACULTY OF ENGINEERING AND INFORMATION TECHNOLOGIES

LEARNING ACTIVITY 2 - RESEARCH: Database Models

TEACHER
JAVIER DAZA PIRAGAUTA

STUDENTS

DAZA OSPINA WILSON

STEPS GUERRERO MARCELA
USAQUEN LILA ALEJANDRA

Bogota DC
2021
 CONTENIDO

1. INTRODUCTION ....................................................................................................................... 4
2. OBJECTIVES ............................................................................................................................. 5
3. DEFINITIONS ............................................................................................................................ 6
3.1. The characteristics of a physical data model include: ......................................................... 8
4. OBJECTIVES ........................................................................................................................... 10
4.1. ENTITY / RELATIONSHIP MODEL.............................................................................. 10
4.1.1. Entities ...................................................................................................................... 10
4.1.2. Entity types .............................................................................................................. 10
5. ATTRIBUTES .......................................................................................................................... 11
5.1.1. Attribute types ......................................................................................................... 11
6. RELATIONS ............................................................................................................................. 13
6.1. THE CARDINALITY OF A RELATIONSHIP ............................................................... 14
6.1.1. ONE-TO-ONE RATIO 1: 1 .................................................................................... 14
6.1.2. ONE-TO-MANY 1: N RATIO ............................................................................... 15
6.1.3. MANY TO MANY N: M ........................................................................................ 15
6.2. PARTICIPATION OF AN ENTITY ................................................................................ 16
6.3. ATTRIBUTES OF A RELATIONSHIP ........................................................................... 18
6.4. DEPENDENCY RELATIONS: STRONG ENTITIES AND WEAK ENTITIES ........... 18
6.5. SYMBOLS OF EXCLUSIVITY OR INCLUSIVENESS BETWEEN RELATIONSHIPS
20
6.6. MODEL E / R EXTENDED ............................................................................................. 23
6.7. HIERARCHY RELATIONS ............................................................................................ 24
6.7.1. Overlapping and partial hierarchy ........................................................................ 24
6.7.2. Overlapping and total hierarchy............................................................................ 25
6.7.3. Exclusive and partial hierarchy ............................................................................. 25
6.8. RELATIONAL MODEL .................................................................................................. 26
6.8.1. RELATIONAL DATA STRUCTURE .................................................................. 27
6.8.2. Elements and properties of the relational model .................................................. 27
6.9. TRANSFORMATION OF AN E / R SCHEMA TO A RELATIONAL SCHEMA ........ 29
7. ENTITIES ................................................................................................................................. 30
7.1. Binary relations (of degree 2)............................................................................................ 30
7.2. Dependency relationships (Always of degree 2 and cardinality 1: N) .............................. 33
7.2.1. Degree relationships greater than 2 ....................................................................... 34
 7.3. HIERARCHIES ................................................................................................................ 35
7.4. STANDARDIZATION ..................................................................................................... 35
7.4.1. First Normal Form: 1FN ........................................................................................ 37
7.5. Second Normal Form: 2FN ............................................................................................... 38
7.6. A Relationship is in 2FN if and only if it is in 1FN and all attributes that are not part of
the Primary Key have complete functional dependency on it. ...................................................... 38
7.7. Third Normal Form: 3FN .................................................................................................. 40
A Relation is in 3NF if and only if it is in 2NF and there are no transitive dependencies. All
functional dependencies must be on the primary key. .................................................................. 40
Example: We continue with the previous example. We will work with the following table: ....... 40
7.8. Boyce-Codd Normal Form: FNBC ................................................................................... 42
7.9. Fourth Normal Form: 4FU ................................................................................................ 43
7.10. FIFTH NORMAL FORM: 5FN .................................................................................... 45
8. CONCLUSIONS ....................................................................................................................... 48
9. BIBLIOGRAPHY ..................................................................................................................... 49
 1.INTRODUCTION

It is important in the entity - relationship model to represent graphs that include

relative information and existing data between them, in order to perceive a real world
characterized by basic objects. The entity - relationship model is an information engineering
technique used to develop a high-quality data model. For our logical models, these evidence-
based tools are complemented very well with data to create models between entities and
relationships, the primary key for each entity is specific. To make the phases between the
entity-relationship model and the logical model a little clearer, they complement each other
to create a great tool where the properties of the physical model objects complement each
other.
 2. OBJECTIVES

❖ Information engineering continuously implements a development method focused on

information technology, as a global development strategy that is focused on strategic
information and understanding the objectives of companies.

❖ The construction of the basic method of information systems can be better integrated
if the data that is shared is centrally controlled as part of the same logical data model.

❖ That is why the entity - relationship model is important with the logical model, the
information used in the organization is a long and difficult task, professionals,
accompanied by powerful tools and adequate techniques, can help ensure that the
information of any company is accurate. and be logical.
 3.DEFINITIONS
Conceptual data modeling represents the initial phase of developing the permanent data
design and permanent data storage for the system. In many cases, persistent data for the
system is managed by a relational database management system (RDBMS). The business and
system entities that are identified at a conceptual level of business models and system
requirements will be developed during use case analysis, use case design, and database design
tasks to become detailed physical table designs to be implemented in the RDBMS.

Please note that the conceptual data model discussed in this concept paper is not a separate
work product. It consists of a composite view of information contained in business modeling
work products, requirements, and analysis and design disciplines that is important to the
development of thedata model.

The data model usually evolves through the following three general phases:

• Conceptual- This phase includes the identification of key top-level business and system
entities and their relationships, which define the scope of the problem to be addressed
by the system. These key system and business entities are defined by using modeling
elements of the UML profile for business modeling, including elements of the business
analysis model and the business analysis model.analysis class of the analysis model.

A conceptual data model identifies the highest-level relationships between different

entities.

Features of the conceptual data model include:

• It includes the important entities and the relationships between them.
• No attributes are specified.
• No primary key is specified.
The following figure is an example of a conceptual data model.
• Logic:This phase includes refining the high-level business and system entities from the
Concept phase into more detailed logical entities. These logical entities and their
relationships can optionally be defined in a logical data model by using the modeling
elements of the UML profile for database design, as described inGuideline: Data Model.
This logical data model is part of theWork Product: Data Modeland it is not a different
work product from RUP.

A logical data model describes the data in as much detail as possible, regardless of how
it will be physically implemented in the database.
The characteristics of a logical data model include:
• Includes all entities and relationships between them.
• All attributes for each entity are specified.
• The primary key for each entity is specified.
• Foreign keys (keys that identify the relationship between different entities) are specified.
• Normalization occurs at this level.

The steps to design the logical data model are as follows:

• Specify primary keys for all entities.
• Find the relationships between different entities.
• Find all the attributes for each entity.
• Solve many-to-many relationships.
• Standardization.

The following figure is an example of a logical data model.

• Physical:This phase includes transforming the logical class layouts into detailed and
optimized physical database table layouts. The physical phase also includes mapping the
database table layouts to table spaces and to the database component in the database
storage layout.

The physical data model represents how the model will be built in the database.
A physical database model displays all table structures, including column name, column
data type, column constraints, primary key, foreign key, and relationships between the
tables.

3.1. The characteristics of a physical data model include:

• Specification of all tables and columns.

• Foreign keys are used to identify relationships between tables.
• Denormalization can occur according to user requirements.
Physical considerations can make the physical data model quite different from the
logical data model.
The physical data model will be different for differentDatabase Management Systems.
For example, the data type for a column can be different between MySQL and SQL
Server.
The basic steps for designing the physical data model are as follows:
• Convert entities to tables.
• Convert relations to foreign keys.
• Convert attributes to columns.
• Modify the physical data model based on physical constraints / requirements.

The following figure is an example of a physical data model.

Here we compare these three types of data models. The table below compares the different
features:

Characteristic Conceptual Logical Physical

Entity names ✓ ✓

Entity relationships ✓ ✓

Attributes ✓

Main keys ✓ ✓

Foreign Keys ✓ ✓

Table names ✓

Column names ✓

Column data types ✓

Tasks related to database design span the entire software development life cycle, and tasks
related to initial database design can be initiated during theinitial phase.

In projects that use business modeling to describe the business context of the application,
database design can begin at a conceptual level with the identification of business actors and
business use cases in the business use case model, and the business workers and business
entities in the business analysis model.

In projects that do not use business modeling, database design can begin at the conceptual
level with the identification of system actors and system use cases in the use case model, and
the identification of analysis classes analysis model of the use case realizations.
 4.OBJECTIVES
4.1. ENTITY / RELATIONSHIP MODEL

The Entity-Relationship model is the most widely used model for the conceptual design of
databases. It was introduced by Peter Chen in 1976 and is based on the existence of objects
that are given the name of entities, and associations between them, called relationships. Its
main symbols are represented in the table below.

The basic elements of this model are detailed below.

4.1.1. Entities

An entity is any object or element about which information can be stored in the DB. Entities
can be concrete like a person or abstract like a date. Entities are represented graphically by
rectangles and their name appears inside. An entity name can only appear once in the
conceptual schema.

4.1.2. Entity types

There are two types of entities: strong and weak. A weak entity is an entity whose existence
depends on the existence of another entity. A strong entity is an entity that is not weak.
 5.ATTRIBUTES
One entity is characterized and distinguished from another by attributes, sometimes called
properties or fields, that represent the characteristics of an entity. The attributes of an entity
can take a set of allowed values known as the attribute domain. Giving values to these
attributes, the different occurrences of an entity are obtained.

In essence, there are two types of attributes: - Entity identifiers (also called primary key or
primary key): these are attributes that uniquely identify each occurrence of an entity. - Entity
descriptors: these are attributes that show characteristics of the entity.

There must always be at least one identifying attribute.

Examples of attributes:

5.1.1. Attribute types

• Identifying or identifying attributes: They are attributes whose values are not
repeated within the same entity or relationship. They serve to uniquely identify each
occurrence. They act as a primary or primary key.

For example CCC (Current Account Code) that identifies each bank account. Or
ISBN (International Standard Book Number) that identifies each book that is
published. An identifying attribute can be a composite attribute.
For example CCC could be broken down into 3 attributes: num_banco, num_sucursal
and num_cuenta.

• Discriminating or discriminating attributes: They are attributes that discriminate

different occurrences of a weak entity in identification within the strong entity on
which they depend. We will represent it with a circle filled with a color other than the
identifying and descriptive attributes. For example, num_transaction within a CCC
or num_ejemplar within an ISBN.
• Descriptive or descriptive attributes: Are the attributes that describe various
properties of an entity or relationship (¡relationships can also have attributes!). They
are the most frequent.
• Derived attributes: These are attributes whose values are calculated from the values
of other attributes. For example, we can have a birthdate attribute that would be a
normal descriptive attribute and calculate the value of the age attribute from it. The
total_price could also be calculated from the price +% VAT.
• Multi-valued attributes: They are descriptive attributes that have several values of
the same domain. For example, if we need to store several e-mails from the same
person then we must use a multivalued attribute. The same happens with the
telephone. If we only need to store a single value we will use a normal descriptive
attribute.

• Compound attributes: Many times they are confused with the previous ones,
although they have nothing to do with them. A compound attribute is an attribute that
can be decomposed into other attributes belonging to different domains.
 6.RELATIONS
A relationship is the association that exists between two or more entities. Each relationship
has a name that describes its function. Relationships are graphically represented by
rhombuses and their name appears inside. Normally we will name the first or first letters of
the entities that it relates. The entities that are involved in a certain relationship are called
participating entities. The number of participants in a relationship is called the degree of the
relationship. For example, the CUSTOMER-CAR relationship is degree 2 or binary, since
two entities are involved.

Notice that the name we give the relationship uses the first letters of each entity. In this case,
as both begin with "C", a few more letters are added to refer to CUSTOMERS. We could
also have put a more descriptive name for the relationship, for example "Purchase"
(CUSTOMER buys CAR), but this nomenclature can lead to confusion when determining
the cardinality of the relationship when we are learning. The PUBLISH relationship is grade
3, since it involves the BOOK, EDITORIAL and AUTHOR entities.
When an entity is related to itself, we speak of a reflective relationship.

Although the ER model allows relationships of any degree, most applications of the model
only consider relationships of degree 2.

The Role or Role of an entity in a relationship It is the function you have in a relationship.
The roles or roles are specified when you want to clarify the meaning of an entity in a
relationship. Next, we show the same examples from the previous point, but including the
role or role of each entity in the relationships:

6.1. THE CARDINALITY OF A RELATIONSHIP

When the relationship is binary, which is the case in most cases, cardinality is the number of
occurrences of one entity associated with one occurrence of the other entity. There are mainly
three types of binary cardinalities:

6.1.1. ONE-TO-ONE RATIO 1: 1

To each element of the first entity corresponds no more than one element of the second entity,
and vice versa. It is represented graphically as follows:

Example cardinality 1: 1
 6.1.2. ONE-TO-MANY 1: N RATIO

It means that each element of an entity of type A can be related to any number of elements
of an entity of type B, and an element of an entity of type B can only be related to one
element of an entity of type A. Its graphical representation is the following: Note in this
case that the dotted end of the arrow of the relation of A and B, indicates an element of A
connected to many of B.

Example cardinality 1: N

6.1.3. MANY TO MANY N: M

It establishes that any number of elements of an entity of type A can be related to any
number of elements of an entity of type B. The end of the arrow that is dotted indicates the
"several" of the relationship.

Example cardinality N: M
 6.2. PARTICIPATION OF AN ENTITY

The participation of an entity is also known as the cardinality of the entity within a
relationship. The same entity can have different cardinality within different relationships. To

obtain participation, you must set a specific occurrence of one entity and find out how many
occurrences of the other entity correspond to it as a minimum and as a maximum. Then do
the same in the other direction. These minimum and maximum occurrences (also called
participation of an entity) will be represented in parentheses and with lowercase letters on
the side of the relationship opposite to the entity whose occurrences are fixed. To determine
the cardinality we keep the maximum shares of both and they are represented with capital
letters separated by two points next to the symbol of the relationship. Let's see some
examples:

Example 1

A driver "drives" at least 1 car and at most 1 car → Participation (1,1) and stands on the
opposite side of DRIVER, that is, next to CAR. A car is "driven" by a minimum of 1 driver
and a maximum of 1 driver → Share (1,1) and is placed on the opposite side to CAR, that is,
next to DRIVER. To determine the cardinality we are left with the two maximum shares.
That is → 1: 1.
Example 2

A customer "buys" at least 1 car and at most can buy more than one car, that is, several cars.
This various is represented by the letter «n» → Participation (1, n)) and is placed on the
opposite side to CUSTOMER, that is, next to CAR. A car is «bought» by a minimum of 1
customer and a maximum of 1 customer → Participation (1,1) and is placed on the opposite
side to CAR, that is, next to CUSTOMER. To determine the cardinality we keep the two
maximum shares and the "n" is capitalized "N". That is → 1: N.

Example 3

An employee "works" at least 1 department and at most can work in several. This various is
represented by the letter «n» → Participation (1, n)) and is placed on the opposite side to
EMPLOYEE, that is, next to DEPARTMENT. A department "has" at least 1 employee and
at most it can have several → Participation (1, n) and it is placed on the opposite side to
DEPARTMENT, that is, next to EMPLOYEE. To determine the cardinality we keep the two
maximum shares and the "n" is capitalized "N" and to differentiate the other "several" instead
of "N" we put "M" (As when in mathematics there were two variables it was not put xex but
x and y). That is → N: M.
 6.3. ATTRIBUTES OF A RELATIONSHIP

Relations can also have attributes, they are called proper attributes. They are those attributes
whose value can only be obtained in the relationship, since they depend on all the entities
that participate in the relationship. Let's look at an example.

Example:

We have the «Purchase» relationship between customer and product. Thus a customer can
buy one or more products, and a product can be bought by one or more customers. We find
a series of attributes of each of the entities [CLIENT (Client_Code, Name, Address, age,
telephone) and PRODUCT (Product_Code, Name, Description, Unit_Price)], but we can also
observe how the attribute «Quantity» is a attribute of the relationship. Why? Well, because
the same customer can buy different quantities of different products and the same product
can be bought in different quantities by different customers. In other words, the quantity
attribute depends on the customer and the product in question.

6.4. DEPENDENCY RELATIONS: STRONG ENTITIES AND WEAK

ENTITIES
When defining the entities we speak of two types of them: strong and weak. A weak entity
is linked to a strong entity through a relationship of dependency. There are two types of
dependency relationships:

Dependency in existenceIt occurs when a weak entity needs the presence of a strong one to
exist. If the existence of the strong entity disappears, that of the weak entity is meaningless.
It is represented with a bar through the rhombus and the letter E inside. They are rare
relationships.
Example:

The figure shows the case that an employee can have none, one or more children, so the data
of the children must be taken in a separate entity, although they are still data belonging to an
employee. If a record of an employee were deleted, it would not make sense to continue to
keep information about their children in the database.

Dependence on identificationIt occurs when a weak entity needs the strong to identify itself.
By itself, the weak is not able to unequivocally identify its occurrences. The weak entity key
is formed by matching the strong entity key with the identifying attributes of the weak entity.

Example:

The figure shows that the province has one or more municipalities and that a municipality
belongs to a single province. Now, if what identifies the municipalities is the code that
appears in the postal code, the first two figures correspond to the province code and the last
three to the municipality. For example, the CP of Écija is 41400, where 41 is the code of the
province and 400 that of the municipality. In this way, there will be different municipalities
with code 400 in different provinces. One of these municipalities will be distinguished from
the rest by placing the first two digits corresponding to the province code before it.
 6.5. SYMBOLS OF EXCLUSIVITY OR INCLUSIVENESS
BETWEEN RELATIONSHIPS

Other symbols used on the E / R model are as follows:

Exclusivity restriction between two types of relationships R1 and R2 with respect to entity
E1. It means that E1 is related to either E2 or E3, but both relationships cannot occur
simultaneously.

Example: An employee can be in a company, or doing an internship, in which case he is

assigned to a group of practices and does not belong to any specific department. Or it can be
employed on a regular basis and in this case belongs to a department.

Inclusiveness constraint between two types of relationships R1 and R2 with respect to entity
E1. For entity E1 to participate in relationship R2, it must previously participate in
relationship R1.
Example: For an employee to work as a product designer, they must have attended at least
two courses.

Exclusion constraint between two types of relationships R1 and R2. It means that E1 is
related to E2 either through R1 or through R2 but that both relationships cannot occur
simultaneously.

Example: Employees, depending on their capabilities, are either designers of products or are
operators and manufacture them, it is not possible for any employee to be a designer and
manufacturer at the same time.
Inclusion constraint between two types of relationships R1 and R2. For entity E1 to
participate in relationship R2 with E2, it must previously participate in relationship R1.

Example: For a man to divorce a woman, he must have previously married her.
 6.6. MODEL E / R EXTENDED

The extended Entity / Relationship model includes everything seen in the Entity /
Relationship model but also the Hierarchy Relationships. A hierarchical relationship occurs
when an entity can be related to others through a relationship whose role would be "It is a
type of".

For example, let's imagine the following situation.

We want to make a BD about the animals in a Zoo. We have the entities ANIMAL, FELINE, BIRD, REPTILE,
INSECT. FELINE, BIRD, REPTILE and INSECT would have the same type of relationship with ANIMAL:
«they are a type of». Now, its representation using the classic E / R would be quite cumbersome:

To avoid having to repeat the rhombus of the same relationship so many times, special
symbols are used for these cases and all relationship rhombuses "is a type of" are replaced
by an inverted triangle, where the entities below are always a type of the entity above and are
called subtype and child entities. The one above will be called the supertype or parent entity.
Hierarchical relationships are always based on an attribute that is placed next to the "is_un"
relationship. In the figure below it would be "type". The example above would look like this
using symbols from the extended I / R.
 6.7. HIERARCHY RELATIONS

Let's see the different types of existing hierarchy relationships:

• Total: We subdivide the Employee entity into: Engineer, Secretary and Technician
and in our DB there is no other employee that does not belong to one of these three
types.
• Partial: We subdivide the Employee entity into: Engineer, Secretary and Technician,
but in our DB there may be employees who do not belong to any of these three types.
• Overlapped: We subdivide the Employee entity into: Engineer, Secretary and
Technician and in our DB there may be employees who are both Engineers and
secretaries, or secretaries and technicians, etc.
• Exclusive: We subdivide the Employee entity into: Engineer, Secretary and
Technician. In our database, no employee belongs to more than one sub-entity.

Examples:

6.7.1. Overlapping and partial hierarchy

In this DB an employee could be simultaneously a technician, scientist and astronaut or
technician and astronaut, etc. (overlapping). In addition, you can be a technician, astronaut,
scientist or perform a different (part) job.

6.7.2. Overlapping and total hierarchy

In this DB an employee could be simultaneously a technician, scientist and astronaut or

technician and astronaut, etc. (overlapping). In addition, it can only be a technician, astronaut
or scientist (total).

6.7.3. Exclusive and partial hierarchy

In this DB an employee can only perform one of the three occupations (exclusive). He can
also be a technician, or be an astronaut, or be a scientist or also perform a different job, for
example, he could be PHYSICAL (partial).
Exclusive and total hierarchy

An employee can only be a technician, astronaut or scientist (total) and not occupy more than
one position (exclusive).

6.8. RELATIONAL MODEL

The DBMS can be classified according to the logical model they support, the number of
users, the number of positions, the cost ... The most important classification of the DBMS is
based on the logical model, being the main models used in the market the following:
Hierarchical, Networked, Relational and Object Oriented.
Most of the current commercial DBMS are based on the relational model, which we are going
to focus on, while the older systems were based on the network model or the hierarchical
model.
The reasons for the success of the relational model are fundamentally two: - They are based
on relational algebra, which is a mathematical model with solid foundations. In this section
the relational model is presented. We will describe the basic principles of the relational
model: the relational data structure and the integrity rules. They offer simple and efficient
systems for representing and manipulating data. - The fundamental structure of the relational
model is precisely that, the «relation», that is to say, a two-dimensional table made up of
rows (records or tuples) and columns (attributes or fields). The relationships or tables
represent the entities of the E / R model, while the attributes of the relationship will represent
the properties or attributes of those entities. For instance, If the entity PERSON has to be
represented in the database, it will become a relation or table called "PEOPLE", whose
attributes describe the characteristics of the people (following table). Each tuple or record in
the "PEOPLE" relationship will represent a specific person.
 6.8.1. RELATIONAL DATA STRUCTURE
PERSONS

DNI Name Last name Birth Sex Marital status

52,768,987 Juan Crockery 06/15/1976 H Single

06,876,983 Isabel Galvez 12/23/1969 M Married

34,678,987 Micaela Ruiz 10/02/1985 M Single

Actually, being rigorous, a RELATION of the RELATIONAL MODEL is only the definition
of the structure of the table, that is, its name and the list of the attributes that compose it. A
representation of the definition of that relationship could be the following:

To distinguish one record from another, the "primary key or primary key" is used.

In a relationship there may be more combinations of attributes that allow a row to be uniquely
identified (these will be called «candidate keys or keys»), but only one will be chosen from
among these to be used as the primary key. The attributes of the primary key cannot assume
the null value.

6.8.2. Elements and properties of the relational model

• Relationship (table): They represent the entities of which you want to store
information in the DB. It's formed by:

✓ Rows (Registers or Tuples): Correspond to each occurrence of the entity.

✓ Columns (Attributes or fields): They correspond to the properties of the entity.
Being rigorous, a relationship is constituted only by the attributes, without the
tuples.
• Relationships have the following properties:

✓ Each relationship has a name and this is different from the name of all other
relationships in the same database.
✓ No two attributes are named the same in the same relationship.
✓ The order of the attributes does not matter: the attributes are not ordered.
✓ Each tuple is different from the others: there are no duplicate tuples. (At least
they will differ in the primary key)
✓ The order of the tuples does not matter: the tuples are not ordered.

• Candidate key: attribute that uniquely identifies a tuple. Any of the candidate keys
could be chosen as the primary key.
• Primary Key: Candidate key that we choose as the identifier of the tuples.
• Alternative Key: Any candidate key that is not a primary key (those that we have not
chosen as the primary key)
• A primary key cannot assume the value null (Entity Integrity).
• Domain of an attribute: Set of values that can be assumed by said attribute.
• Foreign or foreign or foreign key: the attribute or set of attributes that make up the
primary key of another relationship. The fact that an attribute is a foreign key in a
table means that, to enter data in that attribute, it must have been previously entered
in the source table. That is, the values present in the foreign key have to correspond
to values present in the corresponding primary key (Referential Integrity).
 6.9. TRANSFORMATION OF AN E / R SCHEMA TO A
RELATIONAL SCHEMA

We are now going to list the rules to translate from the E / R Model to the relational model,
using the following example:

NOTE:
When moving from the E / R schema to the Relational schema, we must add the foreign keys
necessary to establish the interrelationships between the tables. These foreign keys are not
represented in the E / R schema.
Important

The relational diagrams must be elaborated in such a way that, after entering data, there is no
foreign key to null value (NULL). For this, the rules shown below are followed.

7.ENTITIES
Each entity is transformed into a table. The identifier (or identifiers) of the entity becomes
the primary key of the relationship and appears underlined or with the indication: PK
(Primary Key). If there is an alternative key, it is put in "bold".

Example: All entities in the previous example generate table. Specifically, the
CLASSROOM entity generates the following table:

7.1. Binary relations (of degree 2)

Relationships N: M: It is the simplest case. They always generate table. A table is created
that incorporates as foreign or foreign keys FK (Foreign Key) each of the keys of the entities
that participate in the relationship. The primary key of this new table is made up of these
fields. It is important to note that it is not 2 primary keys, but a primary key composed of 2
fields. If there are attributes of their own, they go to the relationship table. It would be exactly
the same if there were minimum participations 0. Order of the attributes in the composite
keys: All the attributes that make up the key must be placed on the left. The order of the
attributes that make up the key will be determined by the queries to be made. The tuples in
the table are usually ordered following the key as an index. Therefore, it is convenient to put
first the one (s) for which the query is going to be carried out.
Example:
Let's move to tables of the N: M relationship between MODULE (1, n) and STUDENT (1,
n). This type of relationship always generates a table and the attributes of the relationship are
passed to the table that it generates.

1: N ratios:They do not generally generate a table. There are 2 cases:

• Case 1: If the entity on the "1" side presents participation (0,1), then a new table is
created for the relationship that incorporates the keys of both entities as foreign keys.
The primary key of the relationship will only be the key of the entity on the "N" side.
• Case 2: For the rest of the situations, the entity on the "N" side receives the key of the
entity on the "1" side as a foreign key. The attributes of the relationship are passed to
the table where the foreign key has been incorporated.

Case example 1:Let's move to tables of the 1: N relationship between TEACHER (1, n) and
COMPANY (0,1). Since on the «1» side we find minimum participation 0, a new table will
be generated.
Case example 2:

Let's move to tables of the 1: N relationship between MODULE (1,1) and TOPIC (1, n). As
there is no minimum participation "0" in side 1, it does not generate table and the primary
key of side "1" passes as foreign to side "n".

1: 1 ratios:They do not generally generate a table. There are 3 cases:

• Case 1: If the two entities participate with participation (0,1), then a new table is
created for the relation.
• Case 2: If some entity, but not both, participates with a minimum participation of 0
(0.1), then the foreign key is placed in said entity, to avoid null values as much as
possible.
• Case 3: If we have a 1: 1 relationship and none has a minimum participation of 0, we
choose the primary key of one of them and enter it as a foreign key in the other table.
One way or another will be chosen depending on how you want to organize the
information to facilitate consultations. The attributes of the relationship are passed to
the table where the foreign key is entered.

Case example 1: There is no such situation in the scheme studied. A situation where this
case can occur is in MAN (0,1) he marries WOMAN (0,1). It is similar to case 1 of the
previous section in 1: N relationships, although in this case we must establish a single value
constraint for FK2.
Example of case 2 (and 3): Let's move to tables of the 1: 1 relationship between STUDENT
(1,1) and SCHOLARSHIP (0,1). As the SCHOLARSHIP has a minimum participation of 0,
we incorporate into it, as a foreign key, the STUDENT key. This way of proceeding is also
valid for case 3, with the foreign key being able to accept any of the entities.

Trick

Below is a summary of the cases available in N: M, 1: N, and 1: 1 ratios.

7.2. Dependency relationships (Always of degree 2 and cardinality 1: N)

Dependency relationships in existence:They behave like a normal 1: N. The primary key

from side 1 passes to the "N" side as foreign (where the arrow points)
Example: We do not find any example, reviewed as such, in the previous case. Now, in the
passage to tables they behave like any other 1: N relationship. It would only take into account,
the fact of being weak in existence for at the time of creation of the DB, to impose that when
deleting an occurrence in the side «1», the associated ones on the «n» side are deleted.

Dependency relationships in identification:They do not generally generate tables, because

they are usually 1: 1 or 1: N. As in any 1: N relationship, the key of the strong entity must be
entered in the table of the weak entity as foreign and, also in this case, be part of the key of
the latter.
In weak entities, the key of the strong entity should go first, then the discriminators of the
weak. Example: Let's carry out the passage to tables of the weak relationship in identification
between COURSE AND GROUP.

7.2.1. Degree relationships greater than 2

N-ary relationships (we will only see up to degree 3): They always generate a table. The
primary keys of the entities participating in the relationship are passed to the new table as
foreign keys. And only those on the "n" sides form the main one. If there are attributes of the
relationship, they are included in that table. Example: We do not find any example of a
relationship of more than degree 2 in the previous assumption. They will be seen when they
appear in an exercise.

Reflective relationships

Reflective or Recursive Relationships: They generate a table or not based on cardinality. If

it is 1: 1, it does not generate a table. The key is entered twice in the entity, once as a primary
key and another as a foreign key. A modification is usually introduced in the name to
differentiate them. If it is 1: N, table can be generated or not. If there were participation 0 in
side 1, a table would necessarily be generated. If it is N: N, the relation generates a table.

Example:Let's make the step to tables of the reflective relationship of STUDENT. Since it
has no minimum participation "0" in side 1, it does not generate a table. The primary key of
STUDENTS will reappear in STUDENTS as a foreign key, as in any 1: N relationship. Now,
as there cannot be two fields with the same name in the same table, we will have to change
the name of the primary key a bit, so that it refers to the role it occupies as a foreign key.
 7.3. HIERARCHIES

Elimination of hierarchical relationships: Hierarchical relationships are a special case. You

can give some guides that serve as a reference, but in most cases, it will depend on the specific
problem. These guides are: A table will be created for the supertype entity. Unless it has so
few attributes that leaving it is a complication.

If the subtype entity has no attributes and is not related to any other entity, it disappears. If
the subtype entity has any attributes, a table is created. If it does not have its own key, it
inherits that of the supertype entity. If the relationship is unique, the attribute that generates
the hierarchy is incorporated into the table of the supertype entity. If a table has been created
for each of the subtype entities, it is not necessary to add that attribute to the supertype entity.

Example: We do not find any example of a relationship of hierarchy 2 in the previous

assumption. Its passage to tables, will be seen in when they appear in the concrete examples.

7.4. STANDARDIZATION

The design of a relational database can be carried out by applying to the real world, in a first
phase, a model such as the E / R model, in order to obtain a conceptual scheme; in a second
phase, said scheme is transformed to the relational model by means of the corresponding
transformation rules. It is also possible, although perhaps less advisable, to obtain the
relational schema without performing that intermediate step that is the conceptual schema.
In both cases, it is convenient (mandatory in the direct relational model) to apply a set of
rules, known as Normalization Theory, which allow us to ensure that a relational schema
meets certain properties, avoiding:

• Data redundancy: repetition of data in a system.

• Update anomalies - Data inconsistencies as a result of redundant data and partial
updates.
• Erasure anomalies - Unintended data loss due to other data being erased.
• Insertion anomalies: inability to add data to the database due to the absence of other
data.
In practice, if the DB has been designed using semantic models such as the E / R model,
normalization is not usually necessary. On the other hand, if they provide us with a database
created without carrying out a prior design, it is very likely that we will need to normalize.

In relational database theory, normal forms (FN) provide the criteria for determining the
degree of vulnerability of a table to inconsistencies and logical anomalies.

The higher the normal form applicable to a table, the less vulnerable it is to inconsistencies
and anomalies. Edgar F. Codd originally defined the first three normal forms (1FN, 2FN, and
3FN) in 1970.

These normal forms have been summarized as requiring that all attributes be atomic,
dependent on the complete key, and in a direct (non-transitive) way. The Boyce-Codd normal
form (FNBC) was introduced in 1974 by the two authors who appear in its name. The fourth
and fifth normal forms (4FN and 5FN) deal specifically with the representation of many-to-
many and one-to-many relationships between attributes and were introduced by Fagin in
1977 and 1979 respectively. Each normal form includes the previous ones.

Before giving the concepts of normal forms, let's see some previous definitions:

• Functional dependency: A → B, represents that B is functionally dependent on A.

For a value of A a value of B always appears. Example: If A is the DNI, and B is the
Name, it is clear that for a DNI number, the same holder name always appears.
• Complete functional dependency: A → B, if B depends on A in its entirety. Example:
It makes sense to consider this type of dependency when A is made up of more than
one attribute. For example, suppose that A corresponds to the composite attribute:
DNI_Empleado + Cod._Dept. and B is Dept._Name. In this case B depends on the
Cod_Dpto., But not on the DNI_Empleado. Therefore there would be no complete
functional dependency.
 • Transitive dependency: A → B → C. If A → B and B → C, then we say that C
depends transitively on A. Example: Let A be the ID of a student, B the locality where
he lives and C the province. It is a case of transitive dependence A → B → C.
• Functional determinant: any attribute, or set of them, on which some other attribute
depends. Example: The DNI is a functional determinant since attributes such as name,
address, location, etc., depend on it.
• Multivalued dependency: A → → B. They are a type of dependencies in which a
functional determinant does not imply a single value, but a set of them. A value of A
always implies several values of B. Example: High School Course → → Modality.
For the first year, one of the following values will always appear in the Modality
field: Sciences, Humanities / Social Sciences or Arts. Same for second year.

7.4.1. First Normal Form: 1FN

A Relation is in 1FN if and only if each attribute is atomic.

Example: Suppose we have the following table with student data from a secondary school.

STUDENTS
DNI Name Course Registration Tutor Location Province phones
Date Student Student
11111111A Eve 1ESO- 01-July-2016 Isabel Ecija Seville 660111222
A
22222222B Ana 1ESO- 09-July-2016 Isabel Ecija Seville 660222333
A 660333444
660444555
33333333C Suzanne 1ESO- July 11, Robert Ecija Seville
B 2016
44444444D Juan 2ESO- 05-July-2016 Frederick The Villar Cordova
A
55555555E Joseph 2ESO- 02-July-2016 Frederick The Villar Cordova 661000111
A 661000222
As can be seen, this table is not in 1FN since the Telephones field contains several data within
the same cell and therefore it is not a field whose values are atomic. The solution would be
the following:

STUDENTS
DNI Name Course Registration Tutor Location Province
Date Student Student
11111111A Eve 1ESO-A 01-July-2016 Isabel Ecija Seville
22222222B Ana 1ESO-A 09-July-2016 Isabel Ecija Seville
33333333C Suzanne 1ESO-B July 11, 2016 Robert Ecija Seville
44444444D Juan 2ESO-A 05-July-2016 Frederick The Villar Cordova
55555555E Joseph 2ESO-A 02-July-2016 Frederick The Villar Cordova
phones
DNI Telephone
11111111A 660111222
22222222B 660222333
22222222B 660333444
22222222B 660444555
55555555E 661000111
55555555E 661000222

7.5. Second Normal Form: 2FN

7.6. A Relationship is in 2FN if and only if it is in 1FN and all attributes that are not
part of the Primary Key have complete functional dependency on it.

Example: We continue with the previous example. We will work with the following
table:Students
DNI Name Course Registration Date Tutor Location Province
Student Student
11111111A Eve 1ESO-A 01-July-2016 Isabel Ecija Seville
22222222B Ana 1ESO-A 09-July-2016 Isabel Ecija Seville
33333333C Suzanne 1ESO-B July 11, 2016 Robert Ecija Seville
44444444D Juan 2ESO-A 05-July-2016 Frederick The Villar Cordova
55555555E Joseph 2ESO-A 02-July-2016 Frederick The Villar Cordova

Let's examine the functional dependencies. The graph that represents them is the following:
 • Whenever a DNI appears, the corresponding Name and the corresponding Student
Location will appear. Therefore DNI → Name and DNI → LocalidadAlumno. On the
other hand, whenever a Course appears, the corresponding Tutor will appear.
Therefore Course → Tutor. The attributes Name and StudentLocation do not
functionally depend on Course, and the Tutor attribute does not functionally depend
on DNI.
• The only attribute that does depend completely on the composite key DNI and Course
is Enrollment Date: (National ID, Course) → Enrollment Date.

When establishing the Primary Key of a table we must choose an attribute or set of them on
which the rest of the attributes functionally depend. Also, it must be a full functional
dependency. If we choose DNI as the primary key, we have an attribute (Tutor) that does not
functionally depend on it. If we choose Course as the primary key, we have other attributes
that do not depend on it.

If we choose the combination (DNI, Course) as the primary key, then we do have all the other
attributes with functional dependence on this key. But it is a partial dependency, not a total
one (except EnrollmentDate, where there is a complete dependency). Therefore, this table is
not in 2FN. The solution would be the following:
Students
DNI Name Location Province
11111111A Eve Ecija Seville
22222222B Ana Ecija Seville
33333333C Suzanne The Villar Cordova
44444444D Juan The Villar Cordova
55555555E Joseph Ecija Seville
License plates
DNI Course Registration Date

11111111A 1ESO-A 01-July-2016

22222222B 1ESO-A 09-July-2016
33333333C 1ESO-B July 11, 2016
44444444D 2ESO-A 05-July-2016
55555555E 2ESO-A 02-July-2016
courses
Course Tutor
1ESO-A Isabel
1ESO-B Robert
2ESO-A Frederick
 7.7. Third Normal Form: 3FN

A Relation is in 3NF if and only if it is in 2NF and there are no transitive dependencies.
All functional dependencies must be on the primary key.

Example: We continue with the previous example. We will work with the following
table:

Students
DNI Name Location Province
11111111A Eve Ecija Seville
22222222B Ana Ecija Seville
33333333C Suzanne The Villar Cordova
44444444D Juan The Villar Cordova
55555555E Joseph Ecija Seville

The existing functional dependencies are as follows. As we can see, there is a transitive
functional dependency: DNI → Locality → Province

For the table to be in 3FN, there cannot be transitive functional dependencies. To solve the
problem we will have to create a new table. The result is:

Students
DNI Name Location
11111111A Eve Ecija
22222222B Ana Ecija
33333333C Suzanne The Villar
44444444D Juan The Villar
55555555E Joseph Ecija
Localities
Location Province
Ecija Seville
The Villar Cordova
FINAL SCORE PHONES

DNI Telephone
STUDENTS
DNI Name Location 11111111A 660111222
11111111A Eve Ecija
22222222B Ana Ecija 22222222B 660222333
33333333C Suzanne The Villar 22222222B 660333444
44444444D Juan The Villar
55555555E Joseph Ecija 22222222B 660444555
Localities
55555555E 661000111
Location Province
Ecija Seville 55555555E 661000222
The Villar Cordova
LICENSE PLATES

DNI Course Registration Date

11111111A 1ESO-A 01-July-2016

22222222B 1ESO-A 09-July-2016

33333333C 1ESO-B July 11, 2016

44444444D 2ESO-A 05-July-2016

55555555E 2ESO-A 02-July-2016

COURSES
Course Tutor
1ESO-A Isabel
1ESO-B Robert
2ESO-A Frederick
 7.8. Boyce-Codd Normal Form: FNBC

A Relation is in FNBC if it is in 3FN and there is no overlap of candidate keys. We only have
to take this normal form into account when we have several composite candidate keys and
there is overlap between them. This is rarely the case.

Example: We have a table with vendor information, part codes, and quantities of that part
provided by vendors. Each provider has a unique name. The data are:

Supplies
CIF Name Part Code Quantity Pieces
S-11111111A Ferroman 1 10
B-22222222B Ferrotex 1 7
M-33333333C Ferropet 3 4
S-11111111A Ferroman 2 twenty
S-11111111A Ferroman 3 fifteen
B-22222222B Ferrotex 2 8
B-22222222B Ferrotex 3 4

The functional dependencies graph is as follows:

The PieceQuantity attribute has functional dependency on two composite candidate keys,
which are:

• (Supplier Name, Part Code)

• (Supplier CIF, PartCode)

There is also a functional dependency in two ways (which does not affect us):
NombreProveedor <-> CIFProveedor.

For this table there is an overlap of 2 composite candidate keys. To avoid the overlap of
candidate keys we split the table. The solution is:
 Providers

CIF Name

S-11111111A Ferroman

B-22222222B Ferrotex

M-33333333C Ferropet

Supplies

CIF Part Code Quantity Pieces

S-11111111A 1 10

B-22222222B 1 7

M-33333333C 3 4

S-11111111A 2 twenty

S-11111111A 3 fifteen

B-22222222B 2 8

B-22222222B 3 4

7.9. Fourth Normal Form: 4FU

A Relation is in 4FN if and only if it is in 3FN (or FNBC) and the only multi-valued
dependencies are those that depend on the candidate keys
Example: We have a table with the information of our students and the subjects they take
as well as the sports they practice.
Student body
Student Subject Sport

11111111A Mathematics, Language Basketball

22222222B Math Football swimming

Student body

Student Subject Sport

11111111A Math Swimming

11111111A Math Basketball

11111111A Tongue Swimming

 Providers

CIF Name

11111111A Tongue Basketball

22222222B Math Soccer

22222222B Math Swimming

To normalize this table, we must realize that the supply of subjects is made up of a limited
set of values. The same happens with sports. Therefore there are two multivalued
dependencies:

• Student →→ Subject
• Student →→ Sport

On the other hand, there is no dependency between the subject taken and the sport practiced.
To normalize to 4FN we create 2 tables:

Study Subject

Student Subject

11111111A Math

11111111A Tongue

22222222B Math

Sports practice

Student Sport

11111111A Swimming

11111111A Basketball

22222222B Soccer

22222222B Swimming

Equivalent E / R diagram
 7.10. FIFTH NORMAL FORM: 5FN

The fifth normal form (5NF), is a generalization of the previous one. Also known as the
projection-union normal form (PJ / NF). A table is said to be in 5NF if and only if it is in
4NF and every join dependency on it is implied by the candidate keys. Example: We have a
table with several suppliers that provide us with parts for different projects. We assume that
a Supplier supplies certain Parts in particular, a Project uses certain Parts, and a Project is
supplied by certain Suppliers, then we have the following multi-valued dependencies:

• Supplier →→ Part
• Piece →→ Project
• Project →→ Provider

You can see how a cycle occurs:

• Supplier → → Part → → Project → → Supplier (again)
Supplies
Supplier Part Project

E1, E4, E6 PI3, PI6 PR2, PR4

E2, E5 PI1, PI2 PR1, PR3

E3, E7 PI4, PI5 PR5, PR6

Supplies

Supplier Part Project

E1 PI3 PR2

E1 PI3 PR4

E1 PI6 PR2

E1 PI6 PR4

E4 PI3 PR2

E4 PI3 PR4

E4 PI6 PR2

E4 PI6 PR4

E6 PI3 PR2

E6 PI3 PR4

E6 PI6 PR2
You can see how a cycle occurs:
• Supplier → → Part → → Project → → Supplier (again)
Supplies
Supplier Part Project

E6 PI6 PR4

E2 PI1 PR1

E2 PI1 PR3

E2 PI2 PR1

E2 PI2 PR3

E5 PI1 PR1

E5 PI1 PR3

E5 PI2 PR1

E5 PI2 PR3

E3 PI4 PR5

E3 PI4 PR6

E3 PI5 PR5

E3 PI5 PR6

E7 PI4 PR5

E7 PI4 PR6

E7 PI5 PR5

E7 PI5 PR6
We decompose the table into 3 new tables: Supplier-Piece, Piece-Project, Project-Supplier.

Supplier-Part Piece-Project Project-Provider

Supplier Part Part Project Project Supplier
E1 PI3 PI3 PR2 PR2 E1
E1 PI6 PI3 PR4 PR4 E1
E4 PI3 PI6 PR2 PR2 E4
E4 PI6 PI6 PR4 PR4 E4
E6 PI3 PI1 PR1 PR2 E6
E6 PI6 PI1 PR3 PR4 E6
E2 PI1 PI2 PR1 PR1 E2
E2 PI2 PI2 PR3 PR3 E2
E5 PI1 PI4 PR5 PR1 E5
E5 PI2 PI4 PR6 PR3 E5
E3 PI4 PI5 PR5 PR5 E3
E3 PI5 PI5 PR6 PR6 E3
E7 PI4 PR5 E7
E7 PI5 PR6 E7

The natural product of these 3 tables gives us the original table. Supplier-Part | x | Piece-
Project | x | Project-Supplier = Supplies

Equivalent E / R diagram
 8.CONCLUSIONS

Entity - relationship model.

Conduct a requirements assessment.
Reflect how the data will be.
Identify the data needed to perform all important business functions.
The most widely used model is the entity-relationship model.

LOGIC MODEL

Elaboration of the logical design from diagrams.

Choose data model to use.
Choose DBMS which is implemented.
Transformation of the entity relation model to the relational model.
Eliminate redundancies.
 9.BIBLIOGRAPHY
• https://gestionbasesdatos.readthedocs.io/es/latest/Tema2/Teoria.html
• https://gestionbasesdatos.readthedocs.io/es/latest/Tema2/Teoria.html
• https://www.youtube.com/watch?v=55Neu99_aUE&ab_channel=ArrobaMedell%C
3%ADn
• https://cgrw01.cgr.go.cr/rup/RUP.es/SmallProjects/core.base_rup/guidances/concep
ts/conceptual_data_modeling_5CF78A88.html
• http://www.aulavirtual-
exactas.dyndns.org/claroline/backends/download.php?url=L0dVSUEtVFAtMjAxN
S9UNC1Nb2RMb2dpY28tTW9kUmVsYWMucGRm&cidReset=true&cidReq=IN
BD_15AP
• https://www.tecnologias-informacion.com/modelos-datos.html
• https://cgrw01.cgr.go.cr/rup/RUP.es/SmallProjects/core.base_rup/guidances/concep
ts/conceptual_data_modeling_5CF78A88.html
• https://gestionbasesdatos.readthedocs.io/es/latest/Tema2/Teoria.html
• https://www.youtube.com/watch?v=NJp-uJGwg6k&ab_channel=LoboTecnoKu
• https://www.youtube.com/watch?v=55Neu99_aUE&ab_channel=ArrobaMedell%C
3%ADn
• https://gestionbasesdatos.readthedocs.io/es/latest/Tema2/Teoria.html