Bases de Données Relationnelles

Bases de Données Relationnelles Modélisation Conceptuelle (Chapitre 3) Validation et transformations

Validation d'un schéma EA • Syntaxique: respect des règles du modèle • Par confrontation aux dépendances: • règles de normalisation • Par jeu d'essai • Complétude par rapport aux traitements • Par les utilisateurs Règles à connaître et à appliquer !!!

Etudiant liste No-carte nom prénoms date naissance adresses jour mois année no rue ville code postal N°carte nom, prénoms, date naissance, adresses 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 : «Bdépend de A», «A détermine B »

Validation d'un TE(TA) / dépendances Etudiant n°carte, nom, prénoms, date naissance et adresses sont les attributs directs d’Etudiant, qui a pour identifiant n°carte No-carte nom prénoms date naissance adresses jour mois année no rue ville code postal Règle 1: dans un TE (TA) valide,tousles attributs directs (simples et complexes) dépendent uniquement de chaque identifiant entier du TE (TA).

Etudiant mauvais No-carte nom-section directeur section nom étudiant Etudiant mauvais No-carte nom-section directeur section nom étudiant 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.

Etudiant mauvais No-carte nom-section directeur section nom étudiant Etudiant No-carte section nom étudiant nom nom directeur Normalisation Processus de modification d'un schéma qui conduit à obtenir un schéma offrant les propriétés désirées. Correct!

Dépendance et identifiant • Graphe des dépendances No-carte nom-section directeur section nom étudiant • L'identifiant est la racine du graphe No-carte nom-section directeur section nom étudiant

Laboratoire nomLab directeur chercheurs nomC adresse dateentrée %temps projets nomP budget description ligne montant 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.

Emploie Labo Chercheur mauvais Projet Dépendances entre TE • Si tout projet n'est fait que par un seul labo, le schéma est incorrect • Règle 3: un TA n-aire (n>2) avec une dépendance entre ses TE doit être decomposé

mauvais Emploie Labo Chercheur Conduit Projet Normalisation du TA: incorrect • Mauvaise décomposition du TA ternaire incorrect en deux TA binaires • Cette décomposition n'est pas correcte car elle induit une perte d'information – on ne sait plus sur quel projet travaille un chercheur !!

Normalisation du TA: correct • 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 Labo Conduit Emploie Projet Chercheur

Validation des attributs d’un TA Evaluation Etudiant Matière No-carte nom moyenne notes No-Mat coefficient • 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

Etudiant Enseignant Contrôle No-carte notes coef Nom Si Coef = fonction du nombre d'heures assurées par l'enseignant dans ce cours. mauvais Cours Nom Cours Etudiant Enseignant Contrôle Alors Coef ne dépend pas d’Etudiant No-carte notes Nom Cours Assure correct coef Nom Cours Validation des attributs d’un TA

Assure Est élève de Elimination des TA redondants Etudiant Inscrit Cours Enseignant Si "Est élève de" = Inscrit –Cours – Assure alors il y a redondance inutile. On supprime "Est élève de".

Employé Service No-emp …. no-service no étage nom Travaille Employé Service No-emp …. no étage nom Remplacement d’un attribut par un TA mauvais Règle de remplacement

Employé No-emp …. service no étage nom Elimination des TE inutiles Un TE est inutile s'il ne présente d'intérêt pour aucun traitement de l'application Travaille Employé Service No-emp …. no étage nom Si il n'existe pas pas de requête portant directement sur les services, Services est transformé en attribut.

TE répertoires ou attributs ? A lieu dans Cours Salle Nom Type Num Cours A moins que l'on souhaite gérer un répertoire des salles. Nom Type Num_salle

Transformations de schémas EA

Relativisme sémantique • La même réalité peut être modélisée de plusieurs façons différentes • Les choix sont dictés par les objectifs des applications • Si les objectifs divergent, le choix le moins contraignant est retenu

Relativité des classifications • Exemple DB Hydro logie DB Forestière DB Environnement

cable cable bleu rouge cuivre fibre cable cable materiau couleur materiau couleur Relativisme

Choix de modélisation • TE ou attribut ? • TE ou TA ? • TA ou attribut ? • Types génériques ou types spécialisés ? • Attribut optionnel ou sous-type ?

Employé no-AVS nom service nom étage Employé Service no-AVS nom ? nom étage TE ou attribut ?

Employé x:y no-AVS nom service nom étage x:y Travaille 0:n Employé Service no-AVS nom nom étage Transformation d'attribut en TE Attribut direct Le lien de composition TE-attribut devient un rôle TE-TA, avec les mêmes cardinalités

Transformation d'attribut en TE Attribut indirect Laboratoire nomLab directeur chercheurs nomC adresse date_entrée %temps projets nomP budget description ligne montant

Laboratoire ? ? nomLab directeur chercheurs nomC adresse date_entrée %temps projets projets ---> TE => chercheurs ---> TE Projet nomP budget description ligne montant Attribut  TE: 1ère étape

Laboratoire Emploie ? ? nomLab directeur Travaille Chercheur nomC adresse date_entrée %temps Projet nomP budget description Placement des attributs ? ligne montant Attribut  TE: 2ème étape

? Attribut  TE: 3ème étape Laboratoire Emploie nomLab directeur Chercheur nomC adresse date_entrée %temps Chercheur -> nomC, adresse => nomC, adresse attributs de Chercheur (Chercheur,Laboratoire) -> date_entrée,%temps => date_entrée,%temps attributs de Emploie

Attribut  TE: 3ème étape Emploie Laboratoire Chercheur nomLab directeur date_entrée %temps nomC adresse nomC -> adresse : nomC identifiant de Chercheur Projet -> nomP, budget, description => attributs de Projet nomP -> budget, description Projet nomP budget description ligne montant

Attribut  TE: résultat Emploie Laboratoire Chercheur nomLab directeur date_entrée %temps nomC adresse Travaille Projet nomP budget description ligne montant

Assure Personne Voiture nom adresse échéance No-contrat numéro type 1:1 Souscrit Personne Contrat nom adresse No-contrat échéance 1:1 Objet Voiture numéro type TE ou TA: reification (TA->TE)

Personne nom adresse assure Échéance No-contrat voiture numéro type TA ou attribut • Similaire TE ou attribut Assure Personne Voiture nom adresse échéance No-contrat numéro type Assure: TA->attribut n'est pas l'inverse de assure:attribut->TE

Personne assure:attribut->TA nom adresse assure échéance No-contrat voiture numéro type Assure Personne Voiture nom adresse échéance No-contrat numéro type Assure Personne Voiture nom adresse échéance No-contrat numéro type Attribut de TA ou attribut de TE ?

TE génériques/spécifiques • ou Personne nom adresse sexe Personne domaine: - {F ou M} - {F ou M ou vide} nom adresse sexe Femme Homme sexe = F sexe = M

Attribut optionnel ou sous-type • ou Personne nom adresse n°tél Personne nom adresse Communiquant n°tél

Conclusion • Les transformations de schéma à semantique équivalente (i.e., sans perte d'information) sont un outil puissant de flexibilité • Elles permettent d'offrir des vues différentes (personnalisées) sur un même contenu informatif • 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)

Exercice de conception

Fin du chapitre EA • Prochain chapitre: Modèle relationnel

Bases de Données Relationnelles