Chapitre 07 Le modèle relationnel des données Introduction Ce chapitre est un prolongement de l'étude du modèle relationnel vu en classe de première. L'idée principale est de faire comprendre aux élèves comment est organisée une base de données relationnelle. Les modèles relationnels proposés dans le manuel tiennent compte de l'évolution du formalisme qui permet de montrer plus aisément le lien entre les relations (clés étrangères) et qui facilite la rédaction des jointures des requêtes en SQL. La mise en situation propose de revoir les principaux concepts du modèle relationnel (vocabulaire spécifique, principe de construction d'une relation ) et d'étudier la normalisation c'est-à-dire la suppression de toutes les incohérences du modèle relationnel en suivant des règles strictes. Pour plus de simplicité, le sujet proposé concerne la facturation client. L'étude d'une base de données de comptabilité financière (plus complexe) sera étudiée dans les exercices. L'ensemble des modèles relationnels contenus dans le chapitre sont disponibles sur le CDROM sous forme de base de données Access. Si l'enseignant le souhaite, les élèves pourront intervenir directement dans les bases de données et voir les liens avec les modèles relationnels. Mise en situation La base de données est fournie sur le CDROM. Il peut être intéressant d'étudier le modèle relationnel des données en parallèle de la base de données. Doc. 1 Modèle relationnel des données Clé primaire : un ou plusieurs attributs permettant d'identifier de manière unique une occurrence d'une relation (ou un enregistrement d'une table sous une base de données). Clé étrangère : attribut relié à la clé primaire d'une autre relation. Attribut : nom permettant de décrire une relation. Relation : ensemble cohérent d'attributs et contenant une clé primaire. Une relation comprend l'ensemble des attributs qui dépendent de la clé primaire. Dans la relation FACTURE, pour un numéro de facture donné (clé primaire) on ne trouve qu'une date (attribut) et qu'un numéro de client (clé étrangère). Par contre l'attribut "Désignation_produit" ne dépend pas fonctionnellement de numéro de facture (pour un numéro de facture donné, on peut avoir plusieurs désignations de produit). "Désignation_produit" dépend donc de "Num_produit": à un numéro de produit correspond une et une seule désignation.
Les relations sont reliées entre-elles par les clés étrangères. La clé primaire d'une relation devient clé étrangère dans une autre relation en suivant le principe de dépendance fonctionnelle. Une facture peut comporter plusieurs lignes de produits. On ne peut donc pas mettre les produits vendus dans la relation FACTURE (on ne pourrait avoir qu'un seul produit vendu par facture). La création de la relation LIGNE_FACTURE permet donc de résoudre ce problème : la clé primaire est constituée du numéro de facture et du numéro de produit et permet d'identifier une ligne d'une facture. Par exemple : F001 P001 F001 P002 Par contre, il sera impossible de facturer sur une même facture deux fois le même produit puisque la clé primaire doit être unique. Doc. 2 Comparaison entre des relations non normalisées et normalisées 1ère forme normale : L'attribut "Adresse" est remplacé par les attributs "Rue", "Ville" et "CP". Il a donc été décomposé. Principe : pour être en 1 e forme normale, une relation ne peut pas contenir un attribut décomposable. 2ème forme normale : L'attribut "Désignation_produit" a été supprimé de la relation puisqu'il ne dépend que de "Num_produit". Principe : pour être en 2 e forme normale, une relation ne peut pas comporter d'attribut qui ne dépend que d'une partie de la clé primaire. Elle doit déjà être aussi en 1 e forme normale. 3ème forme normale : Les attributs "Num_produit", "Désignation_produit", "Prix_HT" ont été supprimés de la relation FACTURES pour créer une nouvelle relation PRODUIT. En effet, ces attributs ne dépendent pas de Num_facture mais de Num_produit (un attribut non clé) Principe : pour être en 3 e forme normale, une relation ne peut avoir d'attribut non clé qui dépend d'un autre attribut non clé. Elle doit être aussi en 2 e forme normale. 2 Chapitre 07
Exercices Ex. 1 Modification d'un modèle relationnel SALARIÉ (Matricule, Nomsal, Prénomsal, Rue, Ville, CP, Matricule : clé primaire POSTE (Codeposte, Libelléposte, Niveauposte, SALAIRE (Codesalaire, Montantsal, Codesalaire : clé primaire - Un salarié occupe un poste unique donc la relation SALARIÉS prend comme clé étrangère "Codeposte". Pour un salarié donné, on n'obtiendra qu'un seul code de poste. - D'après l'énoncé, les salaires dépendent uniquement des postes. L'attribut "Codesalaire" devient donc clé étrangère de la relation POSTE. SALARIÉ (Matricule, Nomsal, Prénomsal, Rue, Ville, CP, Codeposte) Matricule : clé primaire Codeposte : clé étrangère en référence à Codeposte de POSTE POSTE (Codeposte, Libelléposte, Niveauposte, Codesalaire) Codesalaire : clé étrangère en référence à Codesalaire de SALAIRE SALAIRE (Codesalaire, Montantsal) Codesalaire : clé primaire Primerisque dépend du poste (un poste donnera lieu à l'octroi d'une prime de risque ou non). POSTE (Codeposte, Libelléposte, Niveauposte, Primerisque, Codesalaire) Codesalaire : clé étrangère en référence à Codesalaire de SALAIRE Ex. 2 Normalisation d'un modèle relationnel Cet exercice propose dans le modèle relationnel des noms de clés étrangères différents des noms des clés primaires. Ce modèle relationnel est destiné à gérer les frais engendrés par les visites des représentants commerciaux d'une société. Oui, chaque visite sera identifiée par un numéro unique (ex : V01, V02 ). La date et le numéro de représentant peuvent ne pas varier ; ils ne sont pas clé primaire. 3
Non, c'est impossible car pour un numéro de visite il ne peut y avoir qu'un seul représentant (Num_repr est clé étrangère de la relation VISITE). Les relations REPRESENTANT et VISITE sont en 1 e, 2 e et 3 e forme normale La relation OCCASIONNER est en 1 e forme normale, mais pas en 2 e forme normale. L'attribut Montant_frais ne dépend que d'une partie de la clé primaire (Code_frais). Montant_frais doit donc être transféré dans la relation FRAIS. OCCASIONNER (Nvisite, Cfrais) Nvisite, Cfrais : clé primaire Nvisite : clé étrangère en référence à Num_visite de VISITE Cfrais : clé étrangère en référence à Code_frais de FRAIS La relation FRAIS n'est pas en 1 e forme normale : Libellé_frais est décomposable. Il faut créer l'attribut Type_frais (Remboursable, non remboursable) et Libellé_frais (restaurant, hôtel ) Elle est en 2 e et 3 e forme normale. FRAIS (Code_frais, Type_frais, Libellé_frais, Montant_frais) Code_frais : clé primaire Ex. 3 Gestion comptable : étude du modèle relationnel PLAN_DE_COMPTE : 607, Achats de marchandises ECRITURE : 0001, 12/05/N, facture n 12345 ENREGISTREMENT : 0001, 607, 100, 0 Si on avait écrit seulement la relation ECRITURE, on n'aurait pu saisir qu'une seule ligne par numéro d'écriture (donc à l'encontre du principe de la partie double). La relation ENREGISTREMENT permet donc pour un numéro d'écriture d'avoir plusieurs lignes donc plusieurs comptes (au moins deux). Non, dans la pratique ce n'est pas cohérent et le modèle relationnel ne le permet pas. L'attribut "Libellé_écriture" dépend de la clé primaire "Num_écriture". Il ne peut donc y avoir qu'un seul libellé par numéro d'écriture Libellé de la classe ne dépend que du numéro de la classe. Les deux attributs forment donc une relation CLASSE. Attention, il faut modifier la relation PLAN_DE_COMPTE pour insérer la clé étrangère Num_classe (Pour un numéro de compte on n'obtient qu'un numéro de classe) : CLASSE (Num_classe, Libellé_classe) Num_classe : clé primaire PLAN_DE_COMPTE (Num_compte, Libellé_compte, Num_classe) Num_compte : clé primaire Num_classe : clé étrangère en relation avec Num_classe de CLASSE 4 Chapitre 07
Ex. 4 Création d'un modèle relationnel Il faut penser à renommer les champs (il existe plusieurs fois le champ "numéro"), à mettre en première forme normale la relation BANQUE (décomposition de l'adresse). La mise en place des clés étrangères correspond aux règles de gestion. FACTURE (Num_facture, Date_facture, Net_à_payer) Num_facture : clé primaire REGLEMENT (Num_règlement, Type, Num_facture, Num_banque) Num_règlement : clé primaire Num_banque : clé étrangère en référence à Num_banque de BANQUE Num_facture : clé étrangère en référence à Num_facture de FACTURE BANQUE (Num_banque, Nom_banque, Rue, CP, Ville) Num_banque : clé primaire Il suffit juste d'ajouter l'attribut "Numérocompte" dans la relation banque. BANQUE (Num_banque, Nom_banque, Rue, CP, Ville, Numérocompte) Num_banque : clé primaire Ex. 5 Application informatique Le corrigé complet est proposé dans le fichier Access C07 Ex5 Appli info Corrigé.mdb contenu dans le CDROM. Il faut prendre garde à la longueur des champs (Num_compte: longueur = 6). Pour éviter une double saisie, le champ Num_écriture ne doit être sélectionné qu'une fois dans le formulaire. Les données doivent être affichées par écriture. 5. 6. L'écriture d'achat de timbres en espèces ne peut être saisie puisque le numéro de compte 530000 Caisse n'a pas été créé dans le plan de compte (contrainte d'intégrité référentielle). Il faut donc saisir le compte 530000 dans la table PLAN_DE_COMPTE pour passer l'écriture. 5