Objectif général : Concevoir une base de données Objectifs opérationnels : - Comprendre les différents concepts entourant les BD - Comprendre les concepts associés aux BD relationnelles - Établir un dictionnaire de données (DD) - Structurer les données du DD - Construire un Modèle Conceptuel des Données (MCD) - Transformer un MCD en Modèle logique de données (MLD) - Normaliser un MLD

1. Introduction aux
bases de données
M. DIENG Abdoulaye
UCAD/FST/DMI/LPCM

2. Objectif général
Concevoir une base de données

3. Objectifs opérationnels
• Comprendre les différents concepts entourant les BD
• Comprendre les concepts associés aux BD relationnelles
• Établir un dictionnaire de données (DD)
• Structurer les données du DD
• Construire un Modèle Conceptuel des Données (MCD)
• Transformer un MCD en Modèle logique de données (MLD)
• Normaliser un MLD

4. Sommaire
2. Conception d’une BD
a) Introduction
b) Etablissement du
dictionnaire de données
c) Structuration des données
d) Construction du MCD
e) Transformation du MCD
en MLD
f) Normalisation du MLD
1. Généralités sur les BD
a) Historique
b) Système d’information
c) Donnée
d) Élément de données
e) Structure de données
f) Base de données
g) SGBD
h) Modèle de données
i) Modèle relationnel

5. 1ère partie
1. Généralités
a) Historique
b) Système d’information
c) Données
d) Élément de données
e) Structure de données
f) Base de données
g) SGBD
h) Modèle de données
i) Modèle relationnel
2. Conception d’une base de données

6. Historique
• Avant l ’informatique : informations sous formes de fiches,
classées par ordre alphabétique, chronologique, …
• 1950 – 1965 : organisation classique en fichiers (SGF)
• 1965 - 1970 : 1ère génération de SGBD avec le niveau
conceptuel (l'arrangement des données) étant très lié aux
supports physiques.
– modèle hiérarchique, modèle réseau
• 1970-1980 : 2ème génération de SGBD, basé sur les
mathématiques et plus indépendant des supports.
– modèle relationnel (DB2, Oracle, MySQL, MsAcess…)
• débuts des années 80 : 3ème génération, combinaison des
SGBDR et des langages de programmation orienté objet
– modèle à objets (O2, Objectstore, Objectivity..)

7. Système d’information
• Un système d’information (SI) est un ensemble organisé
d'éléments (formulaires, téléphone, …) en interaction
dynamique qui a pour objectifs de rassembler, de traiter, de
manipuler et de fournir les informations nécessaires à
certaines activités.
• Un des moyens techniques pour faire fonctionner un SI est
d’utiliser un système informatique.
• Ce système informatisé aura pour objet de recueillir des
données qui, accumulées et transformées en informations,
seront à leur tour distribuées et enfin utilisées à la
préparation de rapports destinés à couvrir des besoins variés.

8. Donnée
• Élément immatériel qui sert de base à un SI
• Considérée comme un objet qui entre dans le SI où il sera soumis à
un ou plusieurs traitements pour répondre aux besoins des
utilisateurs du système
• Selon l’interprétation, une données peut correspondre à un
élément de donnée ou à une structure de données.
• Exemple:
– Date en tant qu’élément de donnée
04-04-2010
– Date en tant que structure de données
Jour : 04 ; Mois : 04 ; Année : 2010

9. Elément de donnée
• La plus petite unité porteuse d’une signification pour les
utilisateurs du système
• Exemples :
– numéro de téléphone
– prix d’un article
– description d’un produit
• Souvent représenté par un type de donnée élémentaire:
– chaine de caractères ;
– numérique (entier, réel)

10. Structure de données
• Ensemble d’éléments de données
• Peut inclure :
– des éléments de données ;
– d’autres structures de données.
• Exemples :
– Facture ( numéro de facture, prix total, etc.)
– Client ( nom, prénom, etc.)

11. Bases de données
• Une base de données (database) est un ensemble structuré et
cohérent de données enregistrées avec le minimum de
redondance pour satisfaire simultanément plusieurs
utilisateurs de manière sélective et dans un temps opportun.
• Exemples
– Annuaire téléphonique
– Dictionnaire
– Encyclopédie
• Contre exemple
– Ensemble de factures dans un tiroir car non organisé

12. SGBD
• Le Système de Gestion de Base de Données est le logiciel qui
permet d ’interagir avec une base de données.
• Ses principales fonctions :
– Définition des données (structuration)
– Manipulation et restitution des données (insertion, mise à
jour, interrogation, suppression)
– Contrôler l'intégrité des données (contraintes d’intégrités)
– Assurer la sécurité de fonctionnement (transaction,
journalisation, sauvegarde)
– Gérer les accès concurrents (autorisation d’accès multiples en
consultation et verrouillage en cas d’accès en modification )
– Assurer la confidentialité (identifiants et privilèges d’accès)

13. Les principaux SGBD
• DB2 : logiciel commercial (IBM), puissant et très complet ,
surtout destiné à des mainframes;
• Oracle : logiciel commercial (Oracle Corp.), le best seller,
disponible sur mainframes et micro-ordinateurs;
• PostgreSQL : logiciel libre (Berkeley), puissant et complet,
disponible dans tout le monde Unix, interface d’administration
rustique.
• MySQL : logiciel libre selon l’utilisation (racheté par Sun puis
Oracle Corp. depuis le 21 janvier 2010 ), très répandu dans le
petit monde web, simple à utiliser pour de petites applications.
• SQL-Server : logiciel commercial (MS Corp.), disponible
uniquement sur plateforme MS-Windows.

14. Modèle de données
• Dans une BDD, les informations sont généralement classées par
nature connexes (ex : nom_client, prenom_client, adr_client) pour
former des entités.
• Ensuite, les entités créées sont reliées par des associations.
• Un modèle de données permet d'identifier les entités d’une BDD et
les dépendances entre ces entités.
• Dans un modèle hiérarchique, les entités sont reliées entre elles
par des associations père-fils selon un diagramme en arbre.
• Dans un modèle réseau, les entités sont reliées entre elles par des
associations de-à (utilisant des pointeurs) selon un graphe .
• Dans un modèle relationnel, les entités sont des tables reliées par
des associations de-à (utilisant des informations contenues dans les
enregistrements).

15. Modèle relationnel
introduction
• Le modèle relationnel a été initié par Edgar CODD à IBM en 1970
mais fut surtout utilisé à partir des années 1980.
• Actuellement, la plupart des SGBD se réclament de ce modèle.
• L'explication d'un tel succès tient à la simplicité qu’il apporte, par
rapport à ses prédécesseurs de type "hiérarchique" ou "réseau" .
• Une BDD relationnelle est composée de tables.
• Une table étant un tableau à deux dimensions ou toute ligne
correspond à un enregistrement et une colonne à un champ de
cet enregistrement.
• Toute opération relationnelle sur une ou plusieurs tables génère
une nouvelle table comme résultat.
• Théoriquement, le modèle relationnel est fondé sur la théorie
des ensembles et la notion de relation.

16. Modèle relationnel
les concepts (1/4)
• Un domaine est un ensemble de valeurs.
• Le produit cartésien d’un ensemble de domaines D1,
D2, …, Dn est l’ensemble des tuples (v1, v2, …,vn) tels que tout
vi ε Di . On le note : D1 x D2´x … x Dn
Ex: les domaines
Prenom={Yéro, Ngor, Nogoye, Pendy} et Ethnie={Peul, Sérère}
donnent le produit cartésien suivant :
Prenom x Ethnie={
(Yéro,Peul),(Yéro,Sérère),(Ngor,Peul),(Ngor,Sérère)
(Nogoye,Peul),(Nogoye,Sérère),(Pendy,Peul),(Pendy,Sérère)
}

17. Modèle relationnel
les concepts (2/4)
• Une relation (ou table) est un sous ensemble nommée du
produit cartésien d’une liste de domaines.
Ex: les domaines Prenom={Yéro, Ngor,Nogoye,Pendy} et
Ethnie={Peul,Sérère} peuvent donner la relation suivante
nommée Personnes:
• On appelle enregistrement (ou tuple) d'une relation, une ligne
de cette relation. Ex: (Ngor, Sérère) ou (Pendy,Peul)
• Un attribut est une colonne d’une relation caractérisée par un
nom. Ex: Prénom ou Ethnie
Prénom Ethnie
Yéro Peul
Ngor Sérère
Nogoye Sérère
Pendy Peul

18. Modèle relationnel
les concepts (3/4)
• Une clé primaire est un attribut ou un groupe d'attributs qui
permet d'identifier de manière unique un enregistrement dans
une table. (ex: ajoutons id_pers à la relation Personnes)
• Une clé étrangère représente un attribut (ou des attributs) qui
pointe vers la clé primaire d’une autre table (la table référencée).
ex : Ds la relation Personne, remplaçons ethnie par id_eth pour
référencer une nouvelle relation qu’on nommera Ethnie.
Nous nous retrouverons avec les deux relations suivantes :
Id_pers prenom id_eth
1 Yéro 1
2 Ngor 2
3 Nogoye 2
4 Pendy 1
id_ethnie nom_ethnie
1 Peul
2 Sérère
PersonneEthnie

19. Modèle relationnel
les concepts (4/4)
• Une clé étrangère permet de lier deux tables et de maintenir la
cohérence entre les enregistrements des deux tables.
Exemple:
– on ne peut pas insérer une ligne dans la table Personne avec
un id d’ethnie qui n'existe pas dans la table Ethnie ;
– on ne peut pas supprimer une ligne de la table Ethnie si au
moins une ligne de la table Personne a une valeur d'id
d’ethnie correspondant à la ligne à supprimer.
• Un schéma de relation est le nom de la relation suivi de la liste
de ses attributs avec leurs domaines (qu’on omet en général) .
Exemples :
Personne (id_pers, prenom,id_eth)
Ethnie(id_ethnie,nom_ethnie)
les clès primaires sont soulignées et la clé étrangère est en italique

20. 2ème partie
1. Généralités
2. Conception d’une base de données
a) Introduction
b) Etablissement du dictionnaire de données
c) Structuration des données
d) Construction du MCD
e) Transformation du MCD en MLD
f) Normalisation du MLD

21. Conception d’une BD
1. Etablissement du dictionnaire des données (DD) qui
recense toutes les informations utiles au SI
2. Structuration des données qui permet de regrouper les
données du DD en "paquets" homogènes
3. Construction du MCD (Modèle Conceptuel des Données)
qui permet de représenter graphiquement les paquets de
données ainsi que les relations qui les lient.
ex : Le modèle E-A est un formalisme de MCD.
4. Transformation du MCD en MLD (Modèle Logique des
données ) qui est une représentation du SI tel qu'il sera
implémenté dans un ordinateur.
ex : Le modèle relationnel est un formalisme de MLD.
5. Normalisation du MLD qui permet d’éviter la redondance
d’information et les risques d'anomalie de mise à jour.
6. Implémentation dans un SGBD.

22. Etablissement du DD
introduction
• Le dictionnaire de données est établi à partir :
– des interviews des acteurs impactés par le projet
– de l'analyse des documents existants (bon de commande,
factures, devis…)
• Il est formalisé par un tableau afin de caractériser chaque
donnée (nom, description, types et taille).
• Types: numérique, alphanumérique, texte et date
• NB 1 : ne pas retenir les données calculée ou paramétrée
(ex: taux de TVA, durée).
• NB 2 : éliminer toutes les données synonymes (ex: Code Client
et N° Client) ou polysèmes (ex: qte_produit sur un bon de
commande et qte_produit sur un état de stock)

23. Etablissement du DD
exemple
Nom Description Type taille Exemple
Adr_client Adresse d’un client Alphanumérique 30
Date_cmde Date d’une commande Date 8
Date_facture Date d’une facture Date 8 16/10/1985
Designation Nom d’un produit Texte 15 clavier
Nom_client Nom d’un client Texte 15 Fall
Num_bon_cmde Numéro de bon d’une
commande
Numérique 4
Num_client numéro d’un client numérique 4 2039
Num_facture numéro d’une facture numérique 4
Prenom_client Prénom d’un client Texte 20 Mamadou
Prix_unit Prix de vente unitaire d’un
produit
Numérique 6 50000
Qte_commandee Quantité commandée d’un
produit
Numérique 4
Ref_produit Référence d’un produit Alphanumérique 10 Hard003

24. Structuration des données
dépendance fonctionnelle
• Pour regrouper les données du DD en "paquets" (ou entité)
homogènes, on utilise un élément structurant qui s'appelle la
dépendance fonctionnelle (DF).
• On dit qu'il existe une dépendance fonctionnelle entre une
donnée A et une donnée B, on note A -> B, si connaissant une
valeur de A on ne peut lui associer qu'une seule valeur de B.
• Une DF est dite élémentaire si sa source ne comporte pas de
données superflues.
ex : AB -> C est élémentaire si ni A, ni B pris individuellement ne
déterminent C.
• On dit qu'une DF est simple si sa source n'est composée que
d'une seule donnée. Elle est dite composée sinon.
• Une DF est dite directe si elle ne peut pas être obtenue par
transitivité.

25. Structuration des données
étapes 1, 2 et 3
• La structuration des données du DD s'effectue en 5 étapes :
1. Détermination de la liste des DF simples
Exemple :
num_client -> nom_client, prenom_client, adr_client
Num_facture -> date_facture
Ref_produit -> designation, prix_unit
Num_bon_cde -> date_cde
2. Prise en compte des éventuelles données non classés dans
l'étape 1 et détermination des DF composées
Exemple :
Ref_produit, num_bon_cde -> qte_commandee
3. Elimination des éventuelles transitivités du schéma des DF

26. Structuration des données
étapes 4 et 5
4. Construction, à partir des DF simples, des entités de la base
de données
Exemple :
Client (Num_client, Nom_client, Prenom_client, Adr_client)
Facture (Num_facture, Date_facture)
Produit (Ref_produit, Designation)
Commande (Num_bon_cde, Date_cde)
5. Construction, à partir des DF composées, des associations de
la base de données
Exemple :
Contenir (Num_bon_cde, Ref_produit, Qte_commandee)

27. Construction du MCD
introduction
• La modélisation conceptuelle des données est la
représentation de l'ensemble des données du système
d’information étudié, sans tenir compte des aspects
techniques liés à leur mise en œuvre dans tel ou tel
traitement.
• Le modèle conceptuel des données décrit la sémantique,
c'est-à-dire le sens attaché aux données et à leurs rapports les
unes avec les autres.
• Il permet de représenter de manière visuelle les liens entre
les différentes données.
• Nous allons le construire en quatre étapes

28. Construction du MCD
Regroupement des données du DD par entités
• Une entité regroupe toutes les données du dictionnaire de
données se rapportant à un même ensemble.
• Toute donnée d’une entité est appelée propriété de l’entité.
• Une propriété ne peut qualifier qu'une entité et une seule
• Toute entité doit avoir un identifiant qui est une propriété
(ou ensemble de propriétés) particulière permettant
d’identifier de façon unique une occurrence de l’entité.
• Exemple:
Client (Num_client, Nom_client, Prenom_client, Adr_client)
Facture (Num_facture, Date_facture)
Produit (Ref_produit, Designation)
Commande (Num_bon_cde, Date_cde)

29. Construction du MCD
recherche des associations
• Les associations permettent d’établir des liens entre les
entités
• On utilise souvent les verbes décrivant le modèle
• une association peut avoir des propriétés
• Exemples :
un client passe une commande => passer
une facture correspond à une commande => correspondre
une commande contient au moins un produit => contenir

30. Construction du MCD
Déterminer les cardinalités de chaque entité
• Pour chaque entité, il y a autant de cardinalités que
d’associations qui l’impliquent
• À une occurrence donnée d’une entité, combien
d’occurrences de l’autre entité peuvent y être associées ?
– Nombre minimum : 0 ou 1
– Nombre maximum : 1 ou n
• les cardinalités dépendent des règles de gestion en vigueur
dans l'entreprise qui souhaite la conception du SI

31. Construction du MCD
Déterminer les cardinalités de chaque entité
(exemple)
Associations Entités Règles de gestion de l’entreprise Card
Passer
Client Un client passe une ou plusieurs commandes 1,n
Commande Une commande est passée par un client et un seul 1,1
Correspondre
Commande Une commande correspond à une facture au plus 0,1
Facture Une facture correspond à une commande et une seule 1,1
Contenir
Commande Une commande peut contenir un ou plusieurs produits 1,n
Produit Un produit peut ne figurer sur aucune ou plusieurs
commandes
0,n

32. Construction du MCD
Représentation graphique

33. Transformation du MCD en MLD
• Le MLD est une représentation du SI tel qu'il sera implémenté
dans un ordinateur.
• Cette transformation consiste à remplacer les entités et les
associations par des relations.
• Cette transformation est facilitée par 6 règles de bases.

34. Transformation du MCD en MLD
règle 1
• Une entité du MCD devient une table (ou relation);
• L'identifiant de l’entité devient la clé primaire de la table;
• Les propriétés de l’entité deviennent les colonnes (ou
attributs) de la tables.
• Exemples :
les 4 entités du MCD de l’exemple donnent les tables:
Client (Num_client, Nom_client, Prenom_client, Adr_client)
Facture (Num_facture, Date_facture)
Produit (Ref_produit, Designation)
Commande (Num_bon_cde, Date_cde)
Les clés primaires sont soulignées
• NB : ces tables vont évoluer par la suite

35. Transformation du MCD en MLD
règle 2
• La règle 2 gère la transformation d'une association binaire de
type 1,n çàd de cardinalité x,n d'un coté et y,1 de l'autre avec
x,y ∈ {0,1}
• Notons par E1 l'entité sur laquelle la cardinalité x,n est définie
et par E2 l'autre entité.
• L'association disparaît et une clé étrangère est ajoutée dans E2
qui référence la clé primaire de E1;
• Si y=1, ce nouvel attribut dans E2 doit être non NULL (non vide).
• S'il y a des propriétés dans l'association disparue, ils deviennent
toutes des colonnes de la table E1.

36. Transformation du MCD en MLD
règle 2 (exemple)
L’association Passer part en modifiant la table Commande :
Commande (Num_bon_cde, Date_cde, Num_client)
la clé étrangère est en italique

37. Transformation du MCD en MLD
règle 3
• La règle 3 gère la transformation d'une association binaire de
cardinalité n,m cad de cardinalité x,n d'un coté et y,n de l'autre
avec x,y ∈ {0,1}
• Une telle association devient une table (parfois appelée table
de jonction, table de jointure, ou encore table d'association).
• Sa clé primaire est composée de deux clés étrangères, chacune
référençant la clé primaire d'une des deux tables en relation.
• Les propriétés de l'association deviennent des colonnes de la
nouvelle table.

38. Transformation du MCD en MLD
règle 3 (exemple)
L’association Contenir devient la table :
Contenir (Num_bon_cde, Ref_produit, Qte_commandee)

39. Transformation du MCD en MLD
règle 4
• La règle 4 gère la transformation d'une association binaire de
cardinalité 1,1 cad de cardinalité x,1 d'un coté et y,1 de l'autre
avec x,y ∈ {0,1}
• Une telle association est transformée comme une association
binaire de type 1,n.
• S’il y a une cardinalité 0,1 d'un coté, c'est de l'autre coté que
doit être ajoutés la clé étrangère.
• Si les 2 cotés sont 0,1, alors l'emplacement de la clé étrangère
est indifférent.
• En plus, la clé étrangère se voit imposer une contrainte
d’unicité en plus d’une éventuelle contrainte de non vacuité.
• La contrainte d’unicité impose à la clé étrangère de ne
prendre que des valeurs distinctes.

40. Transformation du MCD en MLD
règle 4 (exemple)
L’association Correspondre part en modifiant la table Facture:
Facture (Num_facture, Date_facture, Num_bon_cde)

41. Transformation du MCD en MLD
règle 5
• La règle 5 gère la transformation d'une association binaire
réflexive
• C'est comme si l'entité se dédoublait, on applique alors la
règle 2 ou 3 (suivant les cardinalités) puis on fusionne les 2
tables.
• Cas 1 : cardinalité x,n et y,1 : une nouvelle colonne se crée et
devient une clé étrangère sur la clé primaire de cette même
table (+ contrainte de non vacuité).
• Cas 2 : cardinalité x,n et y,n : création d'une nouvelle table et
ajout d'une clé étrangère.

42. Transformation du MCD en MLD
règle 5: exemple
• L'association Repondre sur l'entité Message :
message(num_message, titre, contenu, date_publi,
num_auteur, num_message_initial)
• la colonne num_message_initial est du même type que
num_message et stocke la valeur de l'identifiant du message
auquel celui-là est une réponse.
• Cette colonne peut être NULL (vide) mais doit être UNIQUE.

43. Transformation du MCD en MLD
règle 6
• La règle 6 gère la transformation d'une association n-aire çàd
liant plus de deux entités.
• Quelles que soient les cardinalités, Il y a création d'une table
supplémentaire ayant comme clé primaire la concaténation
des identifiants des entités participant à la relation.
• Si l'association est porteuse de données (propriétés), celles-ci
deviennent des colonnes de la nouvelle table.

44. Transformation du MCD en MLD
schéma de la BD
• Le MLD donne le schéma de la base de données
relationnelle çàd l’ensemble des schémas des relations
composantes
• Exemple :
Client (Num_client, Nom_client, Prenom_client, Adr_client)
Facture (Num_facture, Date_facture, Num_bon_cde)
Produit (Ref_produit, Designation)
Commande (Num_bon_cde, Date_cde, Num_client)
Contenir (Num_bon_cde, Ref_produit, Qte_commandee)
Les clés primaires sont soulignées
Les clés étrangères sont en italique
• Une dernière étape avant l’implémentation permettra
d’optimiser la base de données : la normalisation

45. Normalisation du MLD
Introduction
• La normalisation est destinée à concevoir un bon schéma
d’une BD sans redondance d’informations et sans risques
d'anomalie de mise à jour.
• Elle est fondée sur les dépendances fonctionnelles (DF) qui
traduisent des contraintes sur les données et sur les formes
normales qui définissent des relations bien conçues.
• Sa mise en œuvre est fondée sur la décomposition
progressive des relations jusqu'à obtenir des relations
normalisées.
• L'objectif de la décomposition est de "casser" une relation en
relations plus petites afin d'en éliminer les redondances, sans
perte d'information et d’en préserver les DF.
• Pour ce faire, on se sert de quatre formes normales

46. Normalisation du MLD
Première forme normale (1FN)
• Une relation est en 1FN si elle possède une clé et si tous ses
attributs sont atomiques .
• Elle vise simplement à éviter les domaines composés de
plusieurs valeurs.
• NB : L'atomicité d'un attribut est souvent relative : on peut
décider qu'un attribut contenant une date ou une adresse
n'est pas atomique
• Contre exemple :
Formateur(nom, modules) peut être décomposée en
Formateur(nom, module,sous_module1, sous_module2, …)

47. Normalisation du MLD
Deuxième forme normale (2FN)
• Une relation est en 2FN si elle est en 1FN et si toutes les DF
entre la clé et les autres attributs sont élémentaires.
• Elle permet d'éliminer les dépendances entre des parties de clé
et des attributs n'appartenant pas à une clé.
• NB : Si la clé primaire d'une relation est constituée d'un unique
attribut, et que la relation est en 1FN, alors la relation est en
2FN.
• Pour passer de 1FN à 2FN, il faut :
a) créer une nouvelle table ayant pour clé la partie de la clé
primaire dont dépend les attributs, ainsi que ces attributs
eux-mêmes;
b) éliminer les attributs dépendants de la table originale.
c) conserver la clé de la nouvelle table dans l’ancienne en tant
que clé étrangère.

48. Normalisation du MLD
Deuxième forme normale (exemple)
• Supposons qu’au lieu des tables Commande et Produit
précédentes, notre MCD et notre MLD nous donnent la table :
Produit_commandé (Num_bon_cmde, Ref_produit, Designation)
Qte_commandee)
• Il y a donc une DF entre Ref_produit (une partie de la clé
primaire) et Designation
• Il faudra donc diviser cette table en deux comme suit :
Produit (Ref_produit, Designation)
Commande (Num_bon_cmde, Ref_produit, Qte_commandee)

49. Normalisation du MLD
Troisième forme normale (3FN)
• Une relation est en 3FN si elle est en 2FN et si toutes les DF
entre la clé et les autres attributs sont directes.
• Elle permet d'éliminer les dépendances entre les attributs
n'appartenant pas à une clé.
• Pour passer de 2FN à 3FN, il faut :
a) créer une nouvelle table qui aura comme clé l’attribut dont
provient la dépendance et comme attributs, ceux qui en
dépendent;
b) éliminer les attributs dépendants de la table originale;
c) conserver la clé de la nouvelle table dans l’ancienne en tant
que clé étrangère.

50. Normalisation du MLD
Troisième forme normale (exemple)
• Supposons qu’au lieu des tables Commande et Client
précédentes, notre MCD et notre MLD nous donnent la table :
Commande (Num_bon_cmde, date_cmde, Num_client, Nom_client,
Prenom_client, Adr_client)
• Il y a donc une DF entre Num_client (attribut non-clé primaire
dans la table) et Nom_client, ainsi qu’entre Num_client et tous
les attributs relatifs au client ayant fait la commande.
• Il faudra donc diviser cette table en deux comme suit :
Client (Num_client, Nom_client, Prenom_client, Adr_client)
Commande (Num_bon_cde, Date_cmde, Num_client)

51. Normalisation du MLD
Forme normale de Boyce-Codd (FNBC)
• Une relation est en FNBC si elle est en 3FN et si tous ses
attributs non-clé ne sont pas source de DF vers une partie de la
clé.
• Les cas de tables modélisées et transformées en 3FN qui ne sont
pas déjà en FNBC sont très rares.
• Une base de donnée peut généralement être considérée
comme implémentable sur un Système de Gestion de Bases de
Données Relationnel lorsqu’elle est en FNBC.