Section 3. Modélisation logique des
données
3.1. Définition et but
Le modèle logique de données consiste à
décrire la structure des données utilisées sans faire
référence à un langage de programmation. Il s'agit donc de
préciser le type des données utilisées lors des
traitements. Ainsi, le modèle logique de données est
dépendant du type de base de données utilisé.
3.2. Définition des concepts de base du MLD
Les concepts techniques du MLD sont :
- Table
- Attribut
- Clé
- Enregistrement
a. Table : est un tableau composé des
lignes (enregistrements) et de colonnes (champs). C'est un container dans
lequel sont stockées les données. Elle constitue l'objet
fondamental d'une base de données.
b. Attribut : c'est l'unité
d'information d'une table
c. Clé : est un attribut permettant
d'identifier les enregistrements d'une manière ou d'une autre
? Une clé est dite primaire :
lorsqu'elle peut distinguer les enregistrements d'une façon
unique et placée en première position dans la table.
? Une clé est dite secondaire :
lorsqu'elle joue le même rôle que la clé primaire Mais
placée en deuxième position, on parle de la clé
étrangère.
? Une clé est dite composée :
lorsqu'il y a la concaténation de deux clés provenant de
deux tables différentes.
67
3.3. Formalisme et règles de passage Le
passage s'effectue à deux niveaux
- Changement des vocabulaires et - Traitement des relations
Du point de vu changement des vocabulaires :
Les objets deviennent des tables, les propriétés
deviennent les attributs, et les identifiants deviennent les clés
primaires des tables et on n'utilise pas de relation.
Du point de vue traitement des relations, nous avons :
Cas de relation Père et fils « CIF
»
Pour ce cas, nous avons les cardinalités ci-après
:
(0,1) et (1,n) ; (0,1) et (0,n) ; (1,1) et (1,n) ; (1,1) et
(0,n)
? L'objet fils hérite l'identifiant de l'objet père
et devient sa clé secondaire ;
? Dans les cas où la relation est porteuse des
propriétés, elles deviennent des attributs de la table fils.
Cas de relation Père et Père «
cardinalité multiple » Pour ce cas, nous avons les
cardinalités ci-dessous : (1,n) et (1,n) ; (1,n) et (0,n) ; (0,n) et
(0,n)
? La relation devient une table de lien et hérite les
identifiants des tables qu'elle relie ;
? Dans le cas où la relation est porteuse des
propriétés, celles-ci deviennent les attributs de la table de
lien.
# Code_rec Libelle_recu Montant_paie_recu Motif_recu Code_ag#
68
3.4 Présentation du Modèle Logique de
Données Brut
T_SEJOUR
T_RESERVATION
# Code_reserv Date_reserv Libelle_reserv Numcli#
T_PAIEMENT
#code_sej Date_debut_sej Date_fin_sej Num_cli#
T_CLIENT
#Num_cli Nom_cli Postnom_cli Prenom_cli Sexe_cli Adresse_cli
Datenais_cli Tel_cli
Code_ag#
# Code_paie Date_paie Montant_paie Num_cli# Code_ag#
T_REÇU
T_AGENT
|
#code_ag Nom_ag Postnom_ag Prenom_ag Sexe_ag Adresse_ag Tel_ag
Fonction_ag Grade_ag
|
T_ASSISTER
|
#Code_ass Libelle_ass Date_ass Code_ag# Num_cli#
|
69
3.5. Normalisation du MLD Brut 3.5.1. Définition
et but
La normalisation est une opération qui permet
d'éliminer les redondances dans la base de données. Pour ce
faire, le concepteur fait recours aux différentes formes normales.
3.5.2. Formes normales
a) Première forme normale :
Une table doit avoir au moins une clé et ses attributs
doivent être élémentaires.
b) Deuxième forme normale :
Une table est à la deuxième forme normale,
lorsqu'étant déjà en 1ère forme normale,
et que ses attributs non clés sont en dépendance fonctionnelle de
la clé primaire.
c) Troisième forme normale :
Une table est en troisième forme normale,
lorsqu'étant en 2ème forme normale, et que ses
attributs non clés ne sont pas en dépendance transitive de la
clé primaire.
70
2.4 Présentation du Modèle Logique de
Données Relationnel ou valide
T_CLIENT
#Num_cli Nom_cli Postnom_cli Prenom_cli Sexe_cli Adresse_cli
Datenais_cli Tel_cli
Code_ag#
T_SEJOUR
T_RESERVATION
# Code_reserv Date_reserv Libelle_reserv Numcli#
T_PAIEMENT
#code_sej Date_debut_sej Date_fin_sej Num_cli#
# Code_paie Date_paie Montant_paie Num_cli# Code_ag#
T_AGENT
#code_ag Nom_ag Postnom_ag Prenom_ag Sexe_ag Adresse_ag Tel_ag
Fonction_ag Grade_ag
T_ASSISTER
|
#Code_ass Libelle_ass Date_ass Code_ag# Num_cli#
|
T FONCTION
|
#Code_fon Libelle_fon Code_ag#
|
T_REÇU
# Code_rec Libelle_recu Montant_paie_recu Motif_recu Code_ag#
71
Schéma relationnel associé au MLDR
normalisé
T_ Client : (#Num_cli int auto increment
primary Key, Nom_cli :Varchar [15], Postnom_cli :Varchar[25], Prenom_cli
:Varchar[25], Sexe_cli :Varchar[1], Adresse_cli :Varchar[60], text [5], Tel_cli
:Varchar [25] )
T_Agent : (#code_ag int Auto Increment
Primary key, Nom_ag :Varchar[25],
Postnom_ag :Varchar[25], Prenom_ag :Varchar[25], Sexe_ag
:Varchar[1],
Adresse_ag :Varchar[55], Tel_ag :Varchar[25], Fonction_ag
:Varchar[25], Grade_ag :Varchar[25] )
T_Séjour : #code_sej int Auto
Increment Primary key, Num_cli# int, Date_debut :date, Date_fin :date )
T_Paiement : # Code_paie int Auto Increment
Primary key, Num_cli# Int, Date_paie Date, Montant_paie
Num)
T_Réservation : (# Code_reserv :num,
Libelle :varchar[15] Num_cli# :num, Date_reserv :Date)
T_assister( #code_as Increment Primary key,
libelle_ass : varchar[15], date_ass :date/heure date, num_cli# int, code_ag#
int)
T_Fonction :( #code_Fonc Increment Primary
key, Lib_Fonc :Varchar[25], code_ag : index)
T_Recu :(#Code_rec Increment Primary key,
Libelle_rec :Varchar[25],
Montant_paie_rec :Int, Motif_rec :Int, Code_ag# Int )
72
| 
