The Logical Data Model
it is also called the relational model.
The following abbreviation is often used: LDM: Logical Data Model.
Sometimes, the following abbreviations are used:
LDRM: Logical Model of Relational Data
RDM: Relational Data Model
RLD: Relational Logical Data Model
The conceptual data model cannot be implemented in a database
without modification.
It is necessary to transform this model. This process is referred to as
transitioning from the conceptual data model to the logical data
model.
The logical data model can be implemented in a relational database.
Rules for Transitioning from the Conceptual Data Model (CDM) to the
Logical Data Model (LDM):
Rule Number 1:
a) An entity in the CDM becomes a relation, meaning a table.
In a relational database management system (RDBMS), a table is a tabular
structure where each row corresponds to the data of a recorded object (hence
the term record) and each column corresponds to a property of that object. A
table will contain a set of records.
A row corresponds to a record.
A column corresponds to a field.
The value of a field for a given record is located at the intersection of the
corresponding row and column.
There is no theoretical limit to the number of records that a table can contain;
however, the limit is related to storage space.
b) Its identifier becomes the primary key of the relation.
The primary key allows for the unique identification of a record in the table.
The values of the primary key are unique.
The values of the primary key must be non-null.
In most RDBMSs, defining a primary key automatically creates an index.
c) The other properties become the attributes of the relation.
Example:
Client
noClient
firstName Client(noClient,firstName,lastName,address)
lastName
address
Rule Number 2:
1:N association (meaning one side has a maximum cardinality of "1"
and the other side has a maximum cardinality of "n") is represented
by the creation of a foreign key in the relation corresponding to the
entity on the "1" side.
This foreign key references the primary key of the relation
corresponding to the other entity.
Example:
Client Order
noClient 0:N 1:1 noOrder
Request dateOrder
firstName
lastName
address
Client(noClient,firstName,lastName,address)
Order(noOrder,dateOrder,#noClient)
Rule Number 3:
N:N association (meaning both sides have a maximum cardinality of
"N") is represented by the creation of a relation whose primary key is
composed of the foreign keys referencing the relations corresponding
to the entities linked by the association.
Any properties of the association become attributes of the relation.
Example:
Order Product
1:N Concerned 1:N
noOrder refProduct
dateOrder quantity labelProduct
Order(noOrder,dateOrder)
Product(refProduct,labelProduct)
Concerned(#noOrder, #refProduct,quantity)
Special Cases: 1:1 Associations: 1:1 association is one in which
the maximum cardinalities are 1 on each side.
Example:
In a building, an apartment can have a parking space or not, but
never more than one.
APARTEMENT PARKING_SPACE
numApartment 0:1 benefits 1:1 numSpace
area floor
numApartment
APARTMENT (numApartment, area)
Primary Key: numApartment
PARKING_SPACE (numSpace, floor, numApartment)
Primary Key: numSpace
Foreign Key: numApartment referencing numApartment in the
APARTMENT table.
Example:
A cultural activity can have an instructor or not, but never more than
one. An instructor can be responsible for at most one cultural activity.
ANIMATOR(numAnimator, name)
Primary Key: numAnimator
CULTURAL_ACTIVITY (idActivity, activityName)
Primary Key: idActivity
ANIMATE (#numAnimator,# idActivity)
Primary Key: numAnimator + idActivity.
