Reader

1. Introduction databases
1.1 Introduction
Una organization is a partnership de personas que es fundado with a certain
purpose. Many resources are needed to achieve the goal of this organization.
Information that is needed must be use in the right moment for the organisation
to function properly.
La necesidad por la data aumenta, we can look at data processing in a
organisation in 2 ways.
The proces-oriented approach, how the data is flowing en la organization y en
que actividades en usada.
The data-oriented approach, la forma en que la data es guardada. (ESTO ES)

1.2 Databases
1.2.1 Why databases?
The computer is mostly used for data storage. Before automation, around 1950,
data was store in separate files. This could lead to many problems, having the
same data store separately in many places creates the risk that the data in one
place does not match the same data in another file.
This is solve by centrally managing all data and making available to
everybody.
Ejemplo:
A separate article file for each department, a single article file was kept
centrally, which all departments involved could use. Such a collection of
centrally managed data is called a database.

1.2.2 The structure of a database

No se puede poner toda la data junta e intentar administrarla de esa manera,
porque la data se repite y termina en redundancy.

Reader 1
 The occurrence of the same data multiple times is what we call redundancy.
Esto trae muchos problemas, almacenar la misma data ocupa mucho espacio
en el disco, además no improve the reliability of the data.
To avoid redundancy it needed to think before setting the database. The
Relational Model offers a solution to it, the columns that repeat data become
separate files.

In addition to the existing sales file, two new files arise: the CUSTOMERS file
and the ARTICLES file. In these new files, every customer and each article
appears only once. All we have to do now is refer to the right customer and the
right article from the SALES file. This is usually done by means of a number or
code.

1.2.3 Concepts

Reader 2
 1.2.4 Keys
Primary key: Key are the things that make a record unique, this are called
primary key or unique identifier. It has more than one attribute.
Composite key: This are keys that combine one or more attributes combine to
uniquely identify a record in a table. Are use when no single attribute is
sufficient to uniquely identify the records in a table.

1.2.5 Referential integrity

When we enter customer number 3006 in the table SALES from the example
while there is no customer with that number in the table CUSTOMERS, a
problem arises. In such cases, the references between the tables, and
therefore the data, are no longer reliable (integrity). The reliability of the
references in a database is called referential integrity.

This ensures that the relationships between different tables in a database

remain valid and reliable. It prevents errors where records reference data that
does not exist.

Most modern database systems automatically monitor referential integrity by:

Restricting deletions: Preventing the deletion of a customer record if linked

sales exist.

Reader 3
 Enforcing correct references: Ensuring that every customer number in the
SALES table corresponds to an existing customer.

2. The Entity Relationship Diagram

We use entity, relationship, attributes and cardinality.

Entity
Is something we want to capture data about, is a rectangle. The entities
become tables in the database.

Relationships
There are references between the tables in a relational database, the
references are included in the ERD and are called relationships. They are a
connection between entities, they are represented by a diamond.

As the figure above shows, the name of the

relationship is chosen in such a way that from left to right (or from top to
bottom) a readable "sentence" is created. In the example we can read: "a
customer buys an article" and "an employee works in a department.".

Attributes
Properties of an entity or relationship that we want to keep track of. Is an
ellipse.

The attributes are not required for every relationship, if an entity has no
atributes is because we don't want to keep track of anything about it, so it's
usually pointless to include this "blank" entity in the design.
They can also be presented as a list attached to the ERD.

Reader 4
 Cardinality
Type Meaning Example

One entity is related to

One-to-One (1:1) Each person has one passport
exactly one of another

One-to-Many One entity can be related to One customer can place many
(1:N) many others orders

Many-to-Many Many entities relate to many Students take many courses, and
(M:N) others courses have many students

Functionality
The maximum number of occurrences for one entity in relation to another is
called the Functionality. When a certain entity can occur at most once in
relation to another entity, we write down a 1 near the relationship, on the side of
that entity. If she can occur multiple times, we write down an n.

Historical y uptodate database

Historical databases retain both past and present data, making them ideal
for organizations that need long-term records for analysis, such as tracking
annual sales performance or employee work history. These databases store
data over time, ensuring that previous records remain accessible.

Reader 5
 Current databases, by contrast, only store data relevant to the present
moment. They do not retain historical records, meaning that once
information is updated, previous data is lost.

Generalización
Its when two or more entities have a lot of attributes in common.

In data modeling, generalization is shown using a special IS_A relationship. It

represents a 1-to-1 connection between a subclass (e.g., Student ) and a
superclass (e.g., Person ).
The general entity side is optional (O) — not every Person has to be a Student .

The specific entity side is total (T) — every Student must be a Person .

Reader 6
 The name IS_A is reserved and only used for generalization. It never has its
own attributes — they belong to either the superclass or subclass.

Specialization
Specialization in an ERD (Entity-Relationship Diagram) is the process of
creating sub-entities from a more general super-entity based on some
distinguishing characteristics.

In simple terms:
It means breaking down a general entity into more specific types.

Example:
You have a general entity called Employee.
You can specialize it into Teacher and Administrator, since they have different
attributes or roles.

markdown
Copy code
Employee
▲
┌────┴────┐
Teacher Administrator

IS_A
In an Entity-Relationship Diagram (ERD), the IS_A relationship used in
specialization or generalization represents a 1-to-1 relationship between the
specialized entity and the general entity.
This means that each instance of the specialized entity (e.g., Teacher)
corresponds to exactly one instance of the general entity (e.g., Employee).
Additionally, every specialized entity must be a general entity (total
participation), but not every general entity has to be a specialized one (optional
participation).
Therefore, the IS_A relationship is both 1:1 in functionality and has T/O totality
(Total on the specialized side, Optional on the general side).

Reader 7
 When working with the special relationship with the name IS_A a number of
rules apply. A IS_A Relationship:

must have the name IS_A

should only be used in generalisation and specialisation

has no attributes

is always two-dimensional

has always had the functionality 1-to-1

always has totality T-to-O :

- when specialization: the T on the side of specialisation

- in generalization: the O on the side of generalization

Multidimensional relationship
It connects one or more than two entities.
A multidimensional relationship in an Entity-Relationship Diagram (ERD) is a
relationship that involves more than two entities at the same time. Unlike binary
relationships, which connect two entities, multidimensional (or n-ary)
relationships connect three or more.
For example, if we want to represent which student is taught by which teacher
in which course, we need a relationship that includes all three entities. This
type of relationship captures the combined meaning of all the involved entities
and is used when the interaction between them cannot be fully described with
just pairs.

Multidimensional relationships are useful for modeling complex real-world

scenarios where several entities are related together in a single context.

Some students coach several

fellow students. All students are
coached by one
fellow student.

Reader 8
 3. From ERD to relational model
Condition 1: Give each entity type and relationship type a unique name.
All the entities and relationships have a unique name, only is_a can appear
more than once.

Condition 2: All entity types have a primary key.

A primary key is:

uniquely identifying;

minimal (with as few attributes as possible);

not empty (a key attribute must have a value for each entity).

Conversion Rule 1
Conversion Rule 1 explains how to handle n-to-m (many-to-many)
relationships when converting an ERD (Entity-Relationship Diagram) into a
relational database model.

Here's a step-by-step breakdown of the rule:

1. n-to-m Relationship:
This is a relationship where many entities from one side are related to many
entities from the other side. For example:

A Student can enroll in many Courses, and a Course can have many
Students.

A Project can have many Employees, and an Employee can work on

many Projects.

2. Conversion Process:

To represent an n-to-m relationship in a relational database:

You need three tables:

1. One table for the first entity.

Reader 9
 2. One table for the second entity.

3. One table for the relationship itself.

3. Relationship Table:

The relationship table stores the connection between the two entities.

This table will contain foreign keys that reference the primary keys of
the two entity tables.

The combination of these two foreign keys together forms the primary
key of the relationship table, ensuring that each relationship instance is
unique.

4. No redundancy:

The relationship table ensures there is no duplication in the data and

properly links the two entities with a many-to-many relationship.

Example:
Let’s consider the entities Student and Course with a many-to-many (n-to-m)
relationship (a student can enroll in many courses, and a course can have
many students).

ERD:
Student has an attribute Student_ID .

Course has an attribute Course_ID .

The relationship is: "A Student can enroll in many Courses, and a Course
can have many Students."

Conversion:
We need three tables:

1. Student table

2. Course table

3. A relationship table (e.g., Enrollment ) linking the two.

In the relationship table, we’ll have foreign keys pointing to the Student_ID and
Course_ID , and the combination of these foreign keys will be the primary key.

Reader 10
 Final Database Model:
1. Student table:

Student_ID Name

1 John

2 Jane

2. Course table:

Course_ID Course_Name

101 Math

102 Science

3. Enrollment table (Relationship Table):

Student_ID (FK) Course_ID (FK)

1 101

1 102

2 101

Enrollment table holds foreign keys ( Student_ID , Course_ID ) from both the
Student and Course tables.

The combination of Student_ID and Course_ID forms the primary key of the
Enrollment table.

Summary:
n-to-m relationships are represented by three tables: two for the entities
and one for the relationship.

The relationship table contains foreign keys to both entities, and the
combination of these foreign keys forms the primary key.

This setup allows for a many-to-many relationship without redundancy.

Conversion rule 2
Conversion Rule 2 explains how to handle n-to-1 or 1-to-n relationships when
converting an ERD (Entity-Relationship Diagram) into a relational database

Reader 11
 model.

Here's a step-by-step breakdown of the rule:

1. n-to-1 or 1-to-n Relationship:
This is a relationship where many entities from one side (n-side) are related
to one entity on the other side (1-side). For example:

A Student can be enrolled in many Courses (1-to-n).

Many Employees can work in one Department (n-to-1).

2. Conversion Process:

For these relationships, no separate table is created for the relationship

itself.

The 1-side entity (the one with the "one" side of the relationship) will
have a foreign key pointing to the n-side entity.

The n-side entity remains unchanged and doesn’t require modification.

The n-side entity stays as is in its own table.

1. How it works:

The 1-side entity is converted into a table that includes a reference key
(foreign key) to the n-side entity.

2. Foreign Key:

The foreign key is added to the 1-side entity table and it refers to the
primary key of the n-side entity.

Example:
Let’s consider the entities Department and Employee with a 1-to-n relationship
(one department can have many employees).

ERD:
Department has an attribute Department_ID .

Employee has an attribute Employee_ID .

The relationship is: "Each Department has many Employees" (1-to-n).

Conversion:

Reader 12
 We add a foreign key ( Department_ID ) to the Employee table to represent the
relationship.

The Department table stays unchanged.

Final Database Model:

Department table:

Department_ID Name

1 HR

2 IT

Employee table:

Employee_ID Name Department_ID (FK)

101 John 1

102 Jane 1

103 Bob 2

In this case:

The Employee table holds the foreign key ( Department_ID ) to establish the 1-
to-n relationship with the Department table.

The Department table stays unchanged.

Summary:
In a 1-to-n or n-to-1 relationship, you don’t create a separate relationship
table.

The 1-side entity gets a foreign key reference to the n-side entity.

The n-side entity remains unchanged.

Conversion Rule 3
Conversion Rule 3 explains how to handle a 1-to-1 relationship when
converting an ERD (Entity-Relationship Diagram) into a relational database
model.

Reader 13
 Here's what it means, step by step:
1. 1-to-1 Relationship:

This is when each entity in one table is associated with only one entity in
another table, and vice versa. For example, a Person might have exactly
one Passport.

2. Conversion Process:
When converting a 1-to-1 relationship into a relational model:

No separate table is created for the relationship itself.

One entity (table) contains the relationship's attributes and a

reference key (foreign key) pointing to the other entity.

You choose one entity to hold the foreign key of the other entity.

3. How it works:

The foreign key is unique for each record, ensuring that each
relationship instance is one-to-one.

The other entity does not change and stays as is.

Example:
Let’s consider the entities Employee and Office with a 1-to-1 relationship.

ERD:
Employee has an attribute Employee_ID .

Office has an attribute Office_ID .

The relationship is: "Each Employee works in exactly one Office".

Conversion:
You can place a reference to Office_ID inside the Employee table as a
foreign key.

The foreign key Office_ID in the Employee table must be unique.

The Office table remains unchanged.

Final Database Model:

Employee table:

Reader 14
 Office_ID Location

101 New York

102 London

Employee_ID Name Office_ID (FK)

1 John 101

2 Jane 102

Office table:

In this case, the Employee table holds the foreign key ( Office_ID ) to represent the
1-to-1 relationship with the Office table.

Summary:
For a 1-to-1 relationship, the foreign key is placed in one table (typically
the one with fewer attributes or more logical association).

This foreign key must be unique to maintain the 1-to-1 relationship.

The other table remains unchanged.

Conversion Rule 4
Conversion Rule 4 explains how to handle total relationships in the context of
relational database design when there is a foreign key involved.

Here's a breakdown of what this means:

1. Total Relationship:
A total relationship means that every record in one entity must be
associated with a record in another entity. In other words, there is
mandatory participation of an entity in the relationship. For example:

Every Order must be associated with a Customer.

Every Employee must be assigned to a Department.

2. Foreign Key in a Total Relationship:

Reader 15
 When a foreign key is involved in a total relationship, it is mandatory to fill
the foreign key field in the table that participates in the relationship. This
ensures that there is always a valid reference to the related entity, adhering
to the total participation rule.

3. Implication:
If a record in one table is required to be linked to a record in another table
(due to the total relationship), you cannot leave the foreign key column null
— it must contain a valid reference to the related table.

Example:
Let’s consider two entities:

Employee (with Employee_ID )

Department (with Department_ID )

The relationship is: "Each Employee must belong to a Department." This is a

total relationship because every Employee must be assigned to a Department.

Conversion Process:
If we add a foreign key ( Department_ID ) in the Employee table, it must be
filled for each Employee.

The Department table remains unchanged.

Final Database Model:

1. Department table:

Department_ID Department_Name

1 HR

2 IT

2. Employee table:

Employee_ID Name Department_ID (FK)

101 John 1

102 Jane 2

In this case:

Reader 16
 Every Employee has a Department_ID (foreign key) that must be filled.

There can be no Employee without a valid Department_ID, fulfilling the

total relationship requirement.

Summary:
When a foreign key is part of a total relationship, the foreign key must
always be filled with a valid reference to the related entity.

This ensures that the entity on the "many" side of the relationship always
has an associated entity on the "one" side, maintaining data integrity.

Conversion Rule 5
Conversion Rule 5 deals with total relationships where the "1-side" entity
does not have a reference key (foreign key), but still participates in the
relationship in a way that requires all key values to appear at least once in the
"many-side" table.

Here's a breakdown of what this means:

1. Total Relationship:
A
total relationship means that every record in one entity must be associated
with a record in another entity. This implies mandatory participation.

2. Table Without a Reference Key:

In this case, one of the tables
does not have a foreign key pointing to the other table. This is typical when
the "1-side" entity doesn't contain the reference but the "many-side" table
does.

3. Key Values Must Appear:

For a
total relationship to be properly maintained:

Every key value in the table that does not have the foreign key (the 1-
side entity) must appear at least once in the foreign key field in the
other table (the many-side entity).

Reader 17
 This ensures that every record on the "1-side" has at least one matching
record on the "many-side," maintaining the integrity of the total
relationship.

Example:
Let’s consider two entities:

Department (with Department_ID )

Employee (with Employee_ID )

The relationship is: "Each Employee must belong to a Department." This is a

total relationship.

Scenario:
In this case, the Department table does not have a foreign key pointing to
the Employee table. But the Employee table has a foreign key ( Department_ID )
that links back to the Department table.

According to Conversion Rule 5, since Employee is associated with

Department and the relationship is total, every Department must be
associated with at least one Employee. That means:

Conversion Process:
Every Department_ID must appear at least once in the Employee table
as a Department_ID foreign key.

If a Department does not have any employees, it violates the total relationship
rule.

Final Database Model:

1. Department table:

Department_ID Department_Name

1 HR

2 IT

2. Employee table:

Employee_ID Name Department_ID (FK)

Reader 18
 101 John 1

102 Jane 2

In this case:

Department 1 (HR) is associated with Employee 101 (John).

Department 2 (IT) is associated with Employee 102 (Jane).

Key Rule:
Even if the Department table does not have a reference key, each
Department must appear in the Employee table at least once to satisfy the
total relationship.

Summary:
When a table without a reference key participates in a total relationship,
the key values in the table must appear at least once as a foreign key in
the related table.

This ensures that each entity in the "1-side" of the relationship is properly
linked to the "many-side" entities, maintaining the integrity of the total
relationship.

4. Logical Notion
Is a detailed version of a conceptual data model, the attributes are added to
each entity, can also be introduced to represent areas for storing data in the
system.

4.2 Entities
The entities become tables, with the atributes as part of them.

Reader 19
 4.3 Relationships and Cardinality

4.4 N-to-1 Relationship

AUTHOR: author code, name, residence

BOOK:
ISBN, title, author code, start date, end date
Foreign key ‘author code’ refers to
author code in AUTHOR

Reader 20
 In the AUTHOR table, an author appears at most once and cannot be null. In the
BOOK table, an author appears at least once but can also appear multiple
times.

4.5 1-to-1 Relationships

Relational Model
EMPLOYEE:
personnel number, name, address, residence
CAR:
license plate, brand, type, color, personnel number, start date
Personnel number is unique in CAR.
Foreign key ‘personnel number’ refers to personnel number in EMPLOYEE.

In the EMPLOYEE table, personnel number appears at most once and cannot be
null. The personnel number in the CAR table must exist in the EMPLOYEE table.

Reader 21
 In the CAR table, the personnel number from the EMPLOYEE table appears at
most once, but it may also not appear at all.

4.6 n-to-m Relationships

The relational model is as follows:

MEMBER:
member number, name, address, residence
BOOK:
ISBN, title
RESERVATION:
member number, ISBN, reservation date
Foreign key ‘member number’ refers to member number in MEMBER
Foreign key ‘ISBN’ refers to ISBN in BOOK

The member number from the MEMBER table can appear in the RESERVATION
table with a minimum of 0 and a maximum of infinity. The member number in
the RESERVATION table must appear at most once in the MEMBER table. The
ISBN in the RESERVATION table must appear at most once in the BOOK table.

Reader 22
 The ISBN in the BOOK table can appear in the RESERVATION table with a
minimum of 0 and a maximum of infinity.

5 Designing an ERD
Irrelevant entities:
Entities that become a table that always contain one record, are irrelevant and
are not included in an ERD.

Attributes list:

keys may not be declared

basic rules may not be applied

should not be restructured

6 Normalization
Introduction to Normalization
The goal is to minimize redundancy and prevent anomalies (errors during
insert, update, or delete operations) by structuring data logically.

Over-normalization can lead to performance issues, so it’s important to

balance normalization with practical usability.

Normalization Process
The document outlines the steps to achieve the Third Normal Form (3NF),
starting from the Zeroth Normal Form (0NF).

1. Zeroth Normal Form (0NF)

Definition: Lists all attributes derived from information needs and identifies
the primary key and repeating groups.

Steps:

1. Identify constants and process data (e.g., school code, enrollment

date).

Reader 23
 2. Inventory all attributes (e.g., student number, name, course code).

3. Assign a meaningful name to the entity (e.g., "STUDENT").

4. Determine the primary key (e.g., student number).

5. Identify repeating groups (e.g., course-related attributes for a student).

Example:

entity with indented

STUDENT

repeating group (course details).

2. First Normal Form (1NF)

Definition: 0NF + all attributes must be atomic (indivisible and single-
valued).

Steps:

1. Ensure atomicity (e.g., address can be split into street, house number,
etc., but only if necessary).

2. Separate the repeating group into a new entity (e.g., "ENROLLMENT").

3. Carry over the primary key to the new entity and create a composite
key (e.g., Student Number + Course Code ).

Example:

Reader 24
 Two tables:

STUDENT (student details).

ENROLLMENT (student-course relationship with composite key).

3. Second Normal Form (2NF)

Definition: 1NF + remove partial dependencies (attributes dependent on
only part of the key).

Steps:

1. Identify attributes not fully dependent on the composite key (e.g., Course

Name depends only on Course Code , not Student Number ).

2. Separate these into a new entity (e.g., "COURSE").

3. Link the original entity to the new one via a foreign key.

Example:

Reader 25
 Three tables:

STUDENT .

ENROLLMENT (now only includes Start Date , Building , etc.).

COURSE (course details).

Reader 26
 4. Third Normal Form (3NF)
Definition: 2NF + remove transitive dependencies (attributes not dependent
on the key but on other non-key attributes).

Steps:

1. Identify such attributes (e.g., Building Name depends on Building , not on

Student Number or Course Code ).

Reader 27
 2. Separate them into a new entity (e.g., "LECTURE BUILDING").

3. Link via a foreign key (e.g., Building in ENROLLMENT references LECTURE

BUILDING ).

Example:

Four tables:

STUDENT .

ENROLLMENT (minimized attributes).

COURSE .

LECTURE BUILDING (building details).

Entity-Relationship Diagrams (ERD)

The final 3NF structure is visualized in two ERDs:

1. Initial ERD (Figure 6.6): Shows a direct STUDENTCOURSE relationship with

LECTURE BUILDING as a separate entity.

2. Refined ERD (Figure 6.7): Reflects the normalized tables with proper
relationships (e.g., ENROLLMENT as an associative entity between STUDENT

and COURSE ).

Key Takeaways
Normalization ensures data integrity by eliminating redundancy and
dependencies.

Trade-offs: Over-normalization can complicate queries and reduce

performance.

Practical Use: The example demonstrates how to normalize a student

enrollment system step-by-step, resulting in four tables linked by foreign
keys.

This process is foundational for designing efficient, scalable databases.

Reader 28
 Rrrresummen
Database
In an organisation people work together to achieve a certain goal. In order to
achieve this goal, all kinds of data are used, which also need to be stored
somewhere. Nowadays, this usually happens in one central storage: a
database.

Database Structure
When all the data is stored in a database on one large pile, redundancy quickly
arises: the same data occurs several times, with all the dangers that entails.
The relational model offers a solution to this problem: the large pile of data is
split into a number of small piles: tables. These tables are
connected by keys (numbers or codes that make a record unique). The
references between the tables that emerge must of course be correct, this is
what we call referential integrity.

Concepts:
Process-oriented approach: Focuses on how data flows through processes in
a system.
Data-oriented approach :Focuses on organizing and storing data efficiently,
independent of processes.

File: A collection of data stored on a computer, often in a structured format.

Database: An organized collection of data that can be easily accessed,
managed, and updated.
Redundancy: Unnecessary repetition of data, which can lead to waste and
errors.
Relational model: A way of organizing data into tables with relationships
between them.
Table: A set of rows and columns in a database used to store data.
Attribute: A column in a table that describes a property of the data.
Record: A row in a table; a complete set of related data.

Reader 29
 Key: A field (or fields) used to uniquely identify a record in a table.
Composite key: A key made up of two or more attributes to uniquely identify a
record.
Referential integrity: Ensures relationships between tables remain consistent
and valid.
Inconsistency: Conflicting or mismatched data in a system, often due to
redundancy.

ERD
Before we build a database, it's wise to create a design first. The entity
relationship diagram (ERD) is a technique for designing databases. We have
three symbols at our disposal:

Cardinality
For a relationship the cardinality is also captured in an ERD. The cardinality
consists of functionality and totality. The functionality indicates whether an
entity can occur multiple times in relation to another entity (n), or up to once (1).
Totality can indicate whether an entity always occurs in relation to another
entity (T), or not always (O).

Special relationship
In order to design the most efficient database possible, we have a number of
special relationships at our disposal:

Reader 30
 From ERD to Database/Conversion
The ERD must be translated into the relational model before we can actually
build a database. The complete process:

Translation to the Relational Model

The translation to the relational model occurs in two steps: applying the basic
rules and restructuring. Broadly, the following happens:

Reader 31
 In the above example, (in two steps) the key from A is also included in B via R,
where it will function as a reference to A.

Basic Rules
The first step in translating to the relational model is applying the three basic
rules:

1. Assign each entity and relationship a unique name

2. Convert each entity into a table (with its attributes) and assign each table a
key (for IS_A, inheritance applies)

3. Convert each relationship into a table (with its attributes), except for IS_A.
The key is formed by adding the keys of the connecting entities.

Restructuring
After applying the basic rules, restructuring must take place. This involves
considering functionality and totality:

All attributes of A, B and R

can be merged into one table.

Reader 32
 Attributes are not subsumed on one
side with the totality O.

Relevance
When designing an ERD, we need to make sure that we only include relevant
entities and relationships. A tool to discover irrelevant entities is to imagine
what records will appear in that entity once it has become a table. If such a
table always contains only one record or meaningless data, the entity is
irrelevant.
In the case of relationships, the situation in the organisation should be looked
at in particular: what links are one interested in? Only the relationships that the
organization needs are included in the ERD.

Floor
In addition to the theory, the following can be noted:

Attributes of relationships are usually dates or numeric data.

N-to-m relationships (also multidimensional) can possibly be replaced by

an entity, i.e.:

We use a multidimensional relationship when we are interested in the joint

coupling of more than two entities.

A multidimensional relationship can only be used when each record from

that relationship always occurs up to once(T1)in relation to the connecting
entities.

Pitfalls
When designing an ERD, the following matters should be taken into account:

Reader 33
 Sometimes we accidentally model attributes as entities.

Sometimes we accidentally model entities as attributes

When using the relationship IS_A we need to take into account a number of
rules.

In an ERD's attributes list, we are not yet allowed to indicate keys and not
yet restructure.

An attribute list does not include process data.

Reader 34