Bases de Données Relationnelles Modélisation Conceptuelle (Chapitre 3) Validation et transformations
2 Validation d'un schéma EA n Syntaxique: respect des règles du modèle n Par confrontation aux dépendances: u règles de normalisation n Par jeu d'essai n Complétude par rapport aux traitements n Par les utilisateurs Règles à connaître et à appliquer !!!
3 Concept de dépendance A B si le fait que deux occurrences aient la même valeur pour A entraîne nécessairement qu'elles aient la même valeur pour B. A B : «B dépend de A», «A détermine B » N°carte nom, prénoms, date naissance, adresses Etudiant No-carte nom prénoms date naissance adresses jour mois année no rue ville code postal liste
4 Validation d'un TE(TA) / dépendances Règle 1: dans un TE (TA) valide, tous les attributs directs (simples et complexes) dépendent uniquement de chaque identifiant entier du TE (TA). n°carte, nom, prénoms, date naissance et adresses sont les attributs directs dEtudiant, qui a pour identifiant n°carte Etudiant No-carte nom prénoms date naissance adresses jour mois année no rue ville code postal
5 Schémas incorrects La règle est contredite si un attribut dépend d'une partie de l'identifiant ou d'un autre attribut non identifiant. No-carte nom-section directeur section nom étudiant Etudiant No-carte nom-section directeur section nom étudiant Etudiant mauvais
6 Normalisation Processus de modification d'un schéma qui conduit à obtenir un schéma offrant les propriétés désirées. Correct ! No-carte section nom étudiant nom nom directeur Etudiant No-carte nom-section directeur section nom étudiant mauvais
7 Dépendance et identifiant n Graphe des dépendances No-carte nom-section directeur section nom étudiant L'identifiant est la racine du graphe No-carte nom-sectiondirecteur sectionnom étudiant
8 Validation / attributs complexes Règle 2: Un attribut du i ème niveau peut seulement dépendre d'une combinaison d'attributs du même niveau et de niveaux supérieurs contigus. nomLabdirecteurchercheurs nomCadressedateentrée%tempsprojets nomPbudgetdescription lignemontant Laboratoire
9 Dépendances entre TE n Si tout projet n'est fait que par un seul labo, le schéma est incorrect LaboChercheur Emploie Projet mauvais n Règle 3: un TA n-aire (n>2) avec une dépendance entre ses TE doit être decomposé
10 Normalisation du TA: incorrect n Mauvaise décomposition du TA ternaire incorrect en deux TA binaires n Cette décomposition n'est pas correcte car elle induit une perte d'information – on ne sait plus sur quel projet travaille un chercheur !! Chercheur Emploie Projet Conduit Labo mauvais
11 Normalisation du TA: correct n Décomposition du TA ternaire incorrect en deux TA binaires sans perte d'information: un chercheur est employé par le labo qui conduit le projet sur lequel le chercheur travaille Chercheur Emploie Projet Conduit Labo
12 Validation des attributs dun TA Règle 4: dans un TA sans dépendance entre les TEs liés, les attributs du TA dépendent de tous les TE liés par ce TA. (No-carte,No-Mat) moyenne, notes EtudiantMatière No-carte nom moyenne notes No-Mat coefficient Evaluation
13 Validation des attributs dun TA Si Coef = fonction du nombre d'heures assurées par l'enseignant dans ce cours. Alors Coef ne dépend pas dEtudiant EtudiantEnseignant No-carte notes Nom Contrôle Nom Cours Cours Assure coef correct EtudiantEnseignant Contrôle Nom Cours Cours No-carte notes coef Nom mauvais
14 Elimination des TA redondants Si "Est élève de" = Inscrit –Cours – Assure alors il y a redondance inutile. On supprime "Est élève de". EtudiantCoursEnseignant Inscrit Assure Est élève de
15 Remplacement dun attribut par un TA EmployéService No-emp …. no-service no étage nom No-emp …. no étage nom EmployéService Travaille mauvais Règle de remplacement
16 Elimination des TE inutiles Un TE est inutile s'il ne présente d'intérêt pour aucun traitement de l'application Si il n'existe pas pas de requête portant directement sur les services, Services est transformé en attribut. No-emp …. no étage nom EmployéService Travaille No-emp …. service Employé no étage nom
17 TE répertoires ou attributs ? Nom Type Num A moins que l'on souhaite gérer un répertoire des salles. CoursSalle A lieu dans Cours Nom Type Num_salle
Transformations de schémas EA
19 Relativisme sémantique n La même réalité peut être modélisée de plusieurs façons différentes n Les choix sont dictés par les objectifs des applications n Si les objectifs divergent, le choix le moins contraignant est retenu
20 Relativité des classifications n Exemple DB Hydrologie DB Forestière DB Environnement
21 Relativisme cable bleurouge cable cuivrefibre cable couleur materiau cable couleur materiau
22 Choix de modélisation n TE ou attribut ? n TE ou TA ? n TA ou attribut ? n Types génériques ou types spécialisés ? n Attribut optionnel ou sous-type ?
23 TE ou attribut ? Employé no-AVS nom service nom étage Service nom étage Employé no-AVS nom ?
24 Transformation d'attribut en TE EmployéService no-AVS nom nom étage Travaille x:y 0:n Attribut direct Employé no-AVS nom service nom étage x:y Le lien de composition TE-attribut devient un rôle TE-TA, avec les mêmes cardinalités
25 Transformation d'attribut en TE Attribut indirect nomLabdirecteurchercheurs nomCadressedate_entrée%tempsprojets nomPbudgetdescription lignemontant Laboratoire
26 Attribut TE: 1ère étape nomLabdirecteurchercheurs nomCadressedate_entrée%tempsprojets nomPbudgetdescription lignemontant Laboratoire Projet ?? projets ---> TE => chercheurs ---> TE
27 Attribut TE: 2ème étape ?? Placement des attributs ? nomPbudgetdescription lignemontant nomLabdirecteur nomCadressedate_entrée%temps Laboratoire Projet Chercheur Emploie Travaille
28 Attribut TE: 3ème étape nomLabdirecteur nomCadressedate_entrée%temps Laboratoire ? Chercheur Emploie Chercheur -> nomC, adresse => nomC, adresse attributs de Chercheur (Chercheur,Laboratoire) -> date_entrée,%temps => date_entrée,%temps attributs de Emploie
29 Attribut TE: 3ème étape nomLabdirecteurnomCadressedate_entrée%temps LaboratoireChercheur Emploie nomPbudget lignemontant Projet nomC -> adresse : nomC identifiant de Chercheur Projet -> nomP, budget, description => attributs de Projet nomP -> budget, description description
30 Attribut TE: résultat nomLabdirecteurnomCadressedate_entrée%temps LaboratoireChercheur Emploie nomPbudget lignemontant Projet description Travaille
31 TE ou TA: reification (TA->TE) nomadresseéchéanceNo-contrat PersonneContrat Souscrit Objet numérotype Voiture 1:1 nomadressenumérotypeéchéanceNo-contrat PersonneVoiture Assure
32 TA ou attribut n Similaire TE ou attribut nomadressenumérotypeéchéanceNo-contrat PersonneVoiture Assure nomadresse assure Échéance No-contrat voiture Personne numéro type Assure: TA->attribut n'est pas l'inverse de assure:attribut->TE
33 Attribut de TA ou attribut de TE ? nomadresse numérotypeéchéanceNo-contrat PersonneVoiture Assure nomadresse assure échéance No-contrat voiture Personne numéro type assure:attribut->TA nomadressenumérotypeéchéanceNo-contrat PersonneVoiture Assure
34 TE génériques/spécifiques n ou nomadresse sexe Personne nomadresse sexe Personne sexe = F Femme sexe = M Homme domaine: - {F ou M} - {F ou M ou vide}
35 Attribut optionnel ou sous-type n ou nomadresse n°tél Personne nomadresse Personne n°tél Communiquant
36 Conclusion n Les transformations de schéma à semantique équivalente (i.e., sans perte d'information) sont un outil puissant de flexibilité n Elles permettent d'offrir des vues différentes (personnalisées) sur un même contenu informatif n Elles permettent de passer d'une structure obéissant à certaines règles à une autre structure équivalente obéissant à d'autres règles (exemple: traduction d'un schéma EA en schéma relationnel)
37 Exercice de conception
38 Fin du chapitre EA n Prochain chapitre: Modèle relationnel