Colonne = Champ = Attribut = Propriété = Caractéristique

Ligne = Objet = N-uplet = Tuple = Enregistrement = Occurrence

III.1 Modèle conceptuel de données (MCD)

Il a pour objectifs de :
• Permet d'effectuer une représentation conceptuelle de l'ensemble de données manipulées et des règles de gestion auxquelles elles sont soumises.
• Donne une représentation statique du système d'information de l'entreprise.
Il nous convient de définir les terminologies utilisées dans ce modelé
Illustration d’un sous-système de notre entreprise de l’exemple précèdent
a) Propriété : Information élémentaire représentant la plus petite partie manipulée dans d'entreprise et ayant un sens, c’est donc une information élémentaire non déductible d’autres informations et chaque valeur prise par une propriété est appelée occurrence.
Une propriété est dite simple ou encore atomique si chacune des valeurs qu’elle regroupe n’est pas décomposable.

Exemples : matricule, nom, poids, prix, etc..

b) Entité (ou objet) : C’est la représentation d'un élément matériel ou immatériel ayant un rôle dans le système que l'on désire décrire. une association de propriétés correspondant à un type d'objet ayant un intérêt pour l'entreprise.
Les entités sont représentées par un rectangle. Ce rectangle est séparé en deux champs: le champ du haut contient le libellé et le champ du bas contient la liste des propriétés de la classe d'entité.
c) Identifiant : C’est une propriétés (ou plusieurs) permettant de désigner une et une seule entité.
L'identifiant est une propriété particulière d'un objet. Le modèle conceptuel des données propose de souligner les identifiants (parfois de les faire précéder d'un #). Ainsi, chaque entité doit posséder au moins un attribut identifiant.

d) Association (ou relation) : C'est un mécanisme permettant de représenter les liens entre deux ou plusieurs entités, c’est-à-dire un lien sémantique entre plusieurs entités. Il traduit le langage de l'entreprise.
Une relation peut lier plus de deux entités. Selon le nombre d’entités liés on distingue :
• Relation récursive (ou réflexive) relie une entité à elle-même.
• Relation binaire relie deux d'entité.
• Relation ternaire relie trois entités.
• Relation n-aire relie n entités.
Les relations sont représentées par des hexagones (parfois des ellipses) dont l'intitulé décrit le type de relation qui relie les entités (généralement un verbe). On peut éventuellement ajouter des propriétés aux relations.

Exemples :
Une commande "CONCERNE" des articles,
Un service "COMPREND" des employés, etc.

e) Cardinalités : Représente pour chaque couple (entité, association) les nombres minimum et maximum d'occurrences de l'association que peut avoir un objet, il permettent de caractériser le lien qui existe entre une entité et la relation à laquelle elle est reliée. Il représente le nombre minimal et maximal d’occurrences de l’entité qui peuvent participer à une occurrence de l’association.

Exemples : Une personne aime un animal au minimum" indique l'existence de deux individus (les noms "personne" et "animal") et une relation (le verbe "aimer"). La cardinalité minimum sera entre l'individu "personne" et la relation "aimer".

Les cardinalités sont des couples de valeur que l'on trouve entre chaque entité et ses associations liées et qui expriment les contraintes sur le modelé, on n’utilise que 4 combinaisons de valeurs pour les cardinalités.
• 0,1 au plus un(e)
• 1,1 un(e) et un(e) seul(e)
• 1,n un(e) ou plusieurs
• 0, n zéro ou plusieurs
La cardinalité minimale est exprimée presque toujours par l’une des deux valeurs 0 ou 1. Elle traduit combien de fois au minimum une occurrence de l’entité participe à l’association, autrement dit, si une occurrence est obligatoirement associée à une autre (1) ou pas (0).

Si la règle de gestion est « tout client doit passer au moins une commande sinon ce n’est pas un client » on met la cardinalité mini à 1
Si l’entreprise veut aussi mémoriser les clients potentiels (prospects), qui n’ont encore rien commandé. Dans ce cas, un client peut très bien ne pas avoir encore commandé, et on met la cardinalité mini à 0.
La cardinalité maximale traduit combien de fois au maximum une occurrence d'entité peut être en relation avec une occurrence de l'association. Cela peut être plusieurs fois (si c’est un nombre indéterminé, on indique la valeur n) ou une seule fois (1).
Cette cardinalité répond à la question : combien de fois au maximum une occurrence est-elle impliquée dans l'association ?
Si la réponse est « au plus une fois » (participation unique), la cardinalité maximale prend pour valeur 1.
Si la réponse est « plusieurs » (participation multiple), la cardinalité maximale prend la valeur n.
La Construction du MCD doit passer par un ensemble d'étapes dont les principales sont:
• Repérer les concepts pertinents pour la résolution du problème et déduire les entités
• Rattacher à ces entités leurs propriétés
• Identifier les associations entre entités. (reconnu en général par les verbes d'action)
• Grace aux règles de gestion, étudier les cardinalités de chaque couple Entité – Relation

III.2 Modèle logique de données (MLD)

Le modèle logique de données ou MLD décrit la structure des données qui seront utilisées dans une base de données indépendamment des langages de programmation.0
Le MLD constitue une étape intermédiaire entre le modèle conceptuel et le modèle physique de données. C'est le MCD auquel on rajoute la définition de l'organisation logique des données et en l'optimisant compte tenu des traitements à appliquer aux données.
Le MCD (Modèle Conceptuel de Données) ne peut pas être implanté dans une base de données sans modification. Il est obligatoire de transformer ce modèle. On dit qu’on effectue un passage du modèle conceptuel de données vers le modèle logique de données. Cette représentation résulte d’un MCD, en appliquant certaines règles en fonctions des types de liens entre entités.
Il convient aussi de définir les terminologies utilisées dans ce modelé

La clé primaire permet d’identifier de façon unique un enregistrement dans la table.
Les valeurs de la clé primaire sont donc uniques.
Les valeurs de la clé primaire sont obligatoirement non nulles.

Un champ (ou ensemble de champs) est une clé étrangère dans une table s’il fait référence à une clé primaire dans une autre table.

III.2.1 Règles de passage du MCD au MLD

Les règles suivantes sont appliquées pour passer d'un MCD à un MLD :
a) Règle 1 : Transformation des entités en tables
• Une entité du MCD devient une relation, c’est à dire une table.
• Son identifiant devient la clé primaire de la relation.
•Les autres propriétés deviennent les attributs de la relation.
Exempleb) Règle 2 :  Destruction de la relation 1 :n
Une association binaire ayant des cardinalités (x, 1) et (x, n), x étant égale à 0 ou 1, se traduit par :
◊ la migration de l'identifiant de l'entité ayant la cardinalité (x, n) vers l'entité ayant la cardinalité (x,1)
◊ Cet identifient devient une clé étrangère.
◊ Dans le cas d'association réflexive, l'identifiant est dupliqué puis renommé.
◊ la migration des propriétés de l'association (s'il y en a) vers l'entité de cardinalité (0, 1).
Exemplec) Règle 3 :  Destruction de la relation 1 :1 et application de la contrainte d’unicité sur la clé étrangère ;
Une association binaire ayant des cardinalités (x, n) et (x, n), x étant égale à 0 ou 1, se traduit par :
◊ la création d’une nouvelle relation
◊ la migration de l'identifiant de chacune des entités vers la nouvelle relation. L’ensemble de ces identifiant constituent la clé primaire.
◊ Chacun des identifiants devient une clé étrangère.
◊ Les propriétés de l’association constituent le reste des attribues de la nouvelle table.
◊ Dans le cas d'association réflexive, l'identifiant est dupliqué puis renommé.
Exemple 
Règle 4 : Transformation de la relation n :m en table
◊ Une association n-aire (n > 2) porteuse ou non de propriétés, se transforme en une relation ayant comme clé primaire la composition de l'ensemble des identifiants de la collection et comme attributs ceux de l’association.

IV Les règles de normalisation du MCD

Un bon schéma entités-associations doit répondre à un certains nombres de règles de normalisation, que le concepteur doit connaître par cœur afin de construire un schéma de Base de données cohérent.

1. Normalisation des entités et association
• Le nom d’une entité, d’une association ou d’un attribut doit être unique.
• Toutes les entités qui sont remplaçables par une association doivent être remplacées.
• Il faut éliminer les associations fantômes redondantes ou en plusieurs exemplaires.
• Chaque entité doit posséder un identifiant.
2. Normalisation des identifiants
• Chaque entité doit posséder un identifiant ;
3. Normalisation des attributs
• Les attributs calculables doivent être retirés des entités;
• Les attributs d'une association doivent dépendre directement des identifiants de toutes les entités en association.
4. Normalisation des cardinalités
Une cardinalité minimale est toujours 0 ou 1 (et pas 2, 3 ou n) et une cardinalité maximale est toujours 1 ou n et pas 2, 3, ...