3 - Principe de conception des bases de données ( 1ère Partie )

On a vu dans l’article «Qu’est-ce qu’une base de données» qu’une base de données est une manière particulière d’organiser les données en Tables et Relations dans le but est de stocker les données dans un espace minimum sans en altérer l’information.


Mais avant de commencer à programmer (configurer) les tables et leurs relations dans Access il faut savoir que la conception de bases de données est un processus à trois étapes :


- Détermination du model conceptuel de données (MCD) à partir de l’analyse du monde réel;

- Détermination du model logique de données à partir du MCD pour pouvoir l’intégrer dans un SGBD;

- La création effective dans le SGBD des Tables et la configuration de leurs relations.

1 Détermination du model conceptuel de données (MCD)

Le MCD est la représentation sous forme graphique des besoins décrivant la réalité à modéliser qui donnera une vue d’ensemble des données et des liens qui les caractérisent.

Il introduit la notion d’entités, d’associations et de propriétés .

1.1 Les propriétés

Par exemple une voiture possède un numéro de châssis, un nom de marque, un nom de model …Ces informations élémentaires avec lesquelles on décriait une voiture son des Propriétés.

Chaque propriété possède un type, par exemple numérique, alphabétique, date… mais il ne sera pas représenté dans le MCD (sera introduit dans la phase de la création effective dans le SGBD).

1.2 Les entités

En regroupant certaines Propriétés on crée une entité ou en d’autres termes une entité est définie par certaines propriétés

Par exemple : les voitures sont définies par les propriétés (un numéro de châssis, un nom de marque, un nom de model…), les clients par les propriétés (numéro de client, nom, prénom, adresse, numéro de téléphone…)

On représente une entité par un rectangle qui contient le nom de l’entité et ses propriétés comme sur la  Figure 3.1 :

Figure 3.1

1.2.1 L’identifiant

L’identifiant de l’entité ou nommé aussi la clé est une propriété qui permet d’identifier de manière unique un représentant ou une occurrence de cette entité.

Dans l’entité Clients seule la propriété « Numéro de client » permet l’identification de chaque client

Ainsi, lorsque le Numéro de client est connu, son nom, son prénom et toutes les valeurs des autres propriétés qui s’y rattachent sont connues de façon sûre et unique.

Les identifiants sont soulignés. La Figure 3.2 montre le schéma modifié de l’entité Clients et ses occurrences.

La Figure 3.2

• Il est impératif que l’entité ait un identifiant quitte à le créer si aucune de ses propriétés ne peut remplir ce rôle. 

• Chaque propriété hors identifiant d’une entité doit être en dépendance élémentaire et directe avec l’identifiant (c'est le but à atteindre).

1.2.2 Les dépendances fonctionnelles

Définition : Une donnée B dépend fonctionnellement (ou est en dépendance fonctionnelle) d’une donnée A lorsque la connaissance de la valeur de la donnée A nous permet la connaissance d’une et au maximum une seule valeur de la donnée B.

Exemple :

La connaissance de la valeur d’un numéro de client nous permet de connaître sans ambiguïté la valeur d’un et d’un seul nom de client.

Représentation :

Numéro de client → (Nom, Prénom, Adresse, Numéro de téléphone)

Numéro de client sera appelé la clé de la relation ou clé primaire ou encore identifiant de la relation.

La partie droite de la dépendance fonctionnelle est appelée le but de la dépendance fonctionnelle.

1. Dépendances fonctionnelles composées : Une dépendance fonctionnelle qui comporte plusieurs attributs est dite composée.

Exemple :

(Numéro Spectacle, Numéro représentation) → (Nombre de spectateurs)

Connaissant le numéro du Spectacle et le numéro de la représentation, nous connaissons de façon certaine le nombre de spectateurs présent à une représentation d’un spectacle.

Autre exemple :

(Numéro de l’article, Numéro de client) → (Quantité)

Connaissant le numéro de l’article et le numéro de client nous pouvons connaître de façon sûre et unique la quantité d’article commandée par un client. Comme nous pouvons le constater la seule connaissance du Numéro de client ou Numéro d’article ne nous permet pas de connaître la quantité.

2. Dépendance fonctionnelle élémentaire :

Une dépendance fonctionnelle A → B est élémentaire s’il n’existe pas une donnée C, sous-ensemble de A, décrivant une dépendance fonctionnelle de type C → B

Par exemple :

RéférenceProduit → Désignation

NuméroCommande, RéférenceProduit → Quantité

NuméroCommande, RéférenceProduit → Désignation

La première dépendance fonctionnelle est correcte car ayant deux rubriques elle est élémentaire.

La deuxième dépendance fonctionnelle est correcte également car la connaissance d’un numéro de commande et d’une référence produit nous permet de connaître la quantité commandé du produit. Elle est aussi élémentaire car c’est la connaissance du couple (NuméroCommande, RéférenceProduit) et pas seulement d’un des éléments qui permet la connaissance de la quantité.

La troisième dépendance fonctionnelle n’est pas élémentaire car il existe à l’intérieur d’elle RéférenceProduit → Désignation qui était déjà une dépendance fonctionnelle élémentaire. Pour connaître la Désignation, NuméroCommande est dans ce cas en plus.

3. Dépendance fonctionnelle élémentaire directe :

On dit que la dépendance fonctionnelle A → B est directe s’il n’existe aucun attribut C tel que l’on puisse avoir A → C et C → B. En d’autres termes, cela signifie que la dépendance fonctionnelle entre A et B ne peut pas être obtenue par transitivité.

Exemple :

NuméroClasse → NuméroElève 

NuméroEleve → NomElève 

NuméroClasse → NomElève

La troisième dépendance fonctionnelle n’est pas directe car nous pourrions écrire : NuméroClasse → NuméroElève → NomElève

1.3 Les associations

Les associations représentent les liens qui existent entre les entités.

Figure 3.3

La Figure 3.3 représente deux entités (Clients, Articles) liées par une association (Commande), le schéma obtenu peut être une interprétation de la phrase : « Un client commande des articles » où le verbe « commander » représente l’association qui lie les deux entités (Clients, Articles).

Il n’est pas nécessaire de disposer d’un identifiant pour une association car les occurrences de cette association sont identifiées par un identifiant composé des identifiants de chaque entité reliée par elle. Dans notre exemple (Numéro de client et Numéro de l’article)

La manière avec laquelle les entités sont liées par une association est symbolisée par les cardinalités.

1.3.1 Les cardinalités

Elles expriment le nombre de fois où l’occurrence d’une entité participe aux occurrences de la relation (ou association).

Figure 3.4

Dans l'exemple de la Figure 3.4 on peut se poser les questions suivantes :

•  Combien de fois au minimum un client peut-il commander un article (on a le choix entre 0 et 1) ? 

Si on répond par 0 signifiera qu’on autorise le fait d’avoir dans l’entité Clients certains ou tous les clients qui n’auront jamais commandés d’articles, on peut dire aussi qu’on considère comme client, même des personnes qui n’ont jamais commandés d’article.

Et si on répond par 1 le cas dans notre exemple, signifiera que tous les Clients de l’entité Clients auront commandés au moins un article, on peut aussi dire qu’on ne considère une personne comme client que si elle a commandée au moins une fois un article.

•  Combien de fois au maximum un client peut-il commander un article (on a le choix entre 1, n) ? 

Si on répond par 1 signifiera qu’un client ne pourra commander qu’une seule fois un article parmi l’ensemble des articles de l’entité Articles.

Et si on répond par n le cas dans notre exemple, signifiera qu’un client pourra commander plusieurs fois et plus précisément des articles différents à chaque fois car chaque occurrence de l’association « commande » est identifiée par un identifiant composé de l’identifiant de l’entité Client et l’identifiant de l’entité Article et qui est unique .

Le n représente la notion de « plusieurs ».

Les cardinalités concernant l’entité « Clients » sont 1, n

Posons les mêmes questions pour l’entité « Article » : 

• Combien de fois au minimum un article peut-il être commandé par un client ? 

Si on répond par 0 le cas dans notre exemple, signifiera que certains ou tous les Articles peuvent ne jamais être commandés.

Et si on répond par 1, signifiera que tous les Articles de l’entité Articles auront été commandés au moins une fois par un Client.

• Combien de fois au maximum un article peut-il être commandé par un client ? 

Si on répond par 1 signifiera qu’un article ne pourra être commandé qu’une seule fois par un client.

Et si on répond par n le cas dans notre exemple, signifiera qu’un article pourra être commandé plusieurs fois et plus précisément par des clients différents à chaque fois.

Les cardinalités concernant l’entité « Articles » sont 0, n 

Définitions : La cardinalité minimale (0 ou 1) exprime le nombre de fois minimum qu’une occurrence d’une entité participe aux occurrences d’une association.

La cardinalité maximale (1 ou n) exprime le nombre de fois maximum qu’une occurrence d’une entité participe aux occurrences de l’association.

1.3.2 Les relations porteuses

Définition : Une relation est dite porteuse lorsqu’elle contient des propriétés.

Si on voulait connaître la quantité de chaque articles commandés par chaque clients, il nous faudrait utiliser une nouvelle propriété Quantité. Cette nouvelle propriété dépend de clients, d’articles ou des deux ? La bonne réponse est que Quantité dépend des deux entités.

Voici le modèle conceptuel correspondant Figure 3.5 :

Figure 3.5

Nous pouvons interpréter ce schéma de la façon suivante : Le client A a commandé la quantité B d’articles C. Si nous désirons connaître la date d’achat, il nous suffit de créer une entité Date à la relation Commande.( Figure 3.5.1 )

Figure 3.5.1

Et si on ajoutait la propriété « Date » à la relation « Commande » comme sur la Figure 3.5.2

Figure 3.5.2

Quelle est la différence entre ces deux possibilités ?

Dans le deuxième cas, l’association « commande » est définie par l’identifiant composé de l’identifiant de Clients et l’identifiant d’Articles ce qui pourrait être interprété par un client commande plusieurs articles mais un client ne peut pas commander deux fois un même article, mais pour chaque un des articles que le client est autorisé à commander par cette association on à la quantité commandée et la date de la commande.

Par contre dans le premier cas, l’association « Commande » est définie par un identifiant composé cette fois de l’identifiant de Clients, l’identifiant d’Article et l’identifiant de Dates ce qui autorise les clients à commander plusieurs fois le même produit mais à des dates différentes et à chaque commande on a la quantité commandée.

• Une relation faisant intervenir deux entités est dite binaire, et une relation faisant intervenir trois entités est dite ternaire.

La suite en cours ...

Merci de me laisser vos commentaires