Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

COURS DE BASES DE DONNEES © Luc Bouganim Méthode MERISE : Niveau Conceptuel • R

COURS DE BASES DE DONNEES © Luc Bouganim Méthode MERISE : Niveau Conceptuel • Réponse à la question : QUOI ? – Qu’est ce qu’on va gérer comme données, comment sont elles organisées Modèle Conceptuel de Données MCD – La définition sémantique des données permet l’appréhension complète des informations – Qu’est ce qu’on va réaliser comme traitement Modèle Conceptuel de Traitements MCT – La reconnaissance des traitements fondamentaux met en évidence les objectifs du système Méthode MERISE : Niveau Logique – Description du système, indépendamment du logiciel SGBD – Passage ‘automatique’ au modèle relationnel Modèle Logique de Données MLD – Description indépendante de la machine – Structuration en procédure Modèle Logique de Traitements MLT • Réponse à la question : QUI ? QUAND ? OU ? Validation et Optimisation du MLD par rapport aux traitements Méthode MERISE : Niveau Physique – Description interne des données en fonction du logiciel SGBD – Définition des contraintes, structures d’accés, etc.. Modèle Physique de Données MPD – Description de l’architecture des traitements – Spécifications détaillées de la programmation (Algorithmes) Modèle Physique de Traitements MPT • Réponse à la question : COMMENT ?, AVEC QUOI Notre démarche 1/ Définir l’application (~MCT) – Que veut-on faire exactement – Définir les sorties 2/ Définir les données (~MCD) – quelles sont les données nécessaires ? – Comment organiser les données ? 3/ Définir les requêtes nécessaires pour l’application (~MLT) 4/ Validation – Est ce que la structure choisie permet de répondre aux requêtes ? retour en 1/ ou 2/ 5/ Définir le MLD, vérifier 4/ puis définir le MPD Définitions • Entité : ‘Objet’ pourvue d’une existence propre – Client, Fournisseur, Produit sont des entités. • Association :Relation entre entités, dépourvue d’existence propre. – ‘Enseigne’ est une association entre l’entité Prof et l’entité Cours • Propriété : Plus petit élément d’information caractérisant partiellement une entité ou une association. – Nom, Code, Quantité, etc... sont des propriétés • Occurrence : Valeur d’une propriété, d’une entité ou d’une association – ‘Toto’ est une occurrence de la propriété Nom – ‘Dupont’ ‘louis’ ‘23 rue Mirbel’ est une occurrence de l’entité Prof – ‘Dupont’ ‘2h’ ‘Math’ est une occurrence de l’association Enseigne Exemple : Profs et cours... Profs Nom Prénom Adresse Cours NomCours Description Enseigne NbreHeures Exemple : Profs et cours... Profs Lewis Jerry .... Profs Ohana Yollande ... Profs Crenn Isabelle .... Cours Anglais .... Profs Bouganim Luc ..... Cours Math ..... Cours Info ... Enseigne 20 Enseigne 17 Enseigne 26 Enseigne 5 Enseigne 9 Cardinalités • Nombre minimum et maximum d’occurrences d’une association pour une occurrence d’entité • Elles sont indiqués sur chaque arc Profs Nom Prénom Adresse Cours NomCours Description Enseigne NbreHeures Profs Nom Prénom Adresse Cours NomCours Description Enseigne NbreHeures Profs Nom Prénom Adresse Cours NomCours Description Enseigne NbreHeures Profs Nom Prénom Adresse Cours NomCours Description Enseigne NbreHeures 0,1 0,1 0,1 1,3 0,n 1,n 1,1 1,n Notre problème : Gérer les notes des étudiants • Détailler le problème : Que veut dire gérer les notes – Que veut on faire ? • établir les bulletins semestriels ? • établir des bulletins provisoires ? • établir des moyennes ? • Faire des statistiques sur plusieurs années ? • Evaluer les notes en fonction des profs... • Premier brouillon des données à gérer... – Notes, étudiants, Cours... Identifiant • Pour une entité, c’est une (ou plusieurs) propriété(s) qui définissent chaque occurrence de l’entité – Permet de s’assurer que c’est une entité (et non une association). • exemples : prof, enseigne, ... – Plusieurs identifiants peuvent co-exister. • exemples : nom du prof, n° de sécu, code... • Pour une association, l’identifiant n’existe pas vraiment. • On défini l’ ‘‘identifiant’’ d’une association, comme la concaténation des identifiants des entités associées. • exemple : pour enseigne : nom du prof, nom du cours. Comment produire le MCD ? • ‘‘Enoncer le réel’’ avec des phrases. • Exemple pour la gestion de rendez vous (hôpital) – Les patients ont des rendez vous avec des médecins • Un patient peut avoir plusieurs RDV (voire aucun) • Un médecin reçoit plusieurs patients (voire aucun) – Un médecin exerce dans une salle • Un médecin n’exerce que dans une seule salle • Une salle peut être partagée par plusieurs médecins Patient Médecin a un rdv 0,n 0,n Médecin Salle Exerce 1,1 1,n Patient Médecin a un rdv 0,n 0,n Salle Exerce 1,1 1,n Pour connaître la salle, pour un rendez vous, on passe par le médecin.... Et si maintenant le médecin peut exercer dans plusieurs salles ? Patient Médecin a un rdv 0,n 0,n Salle Exerce 1,n 1,n Comment connaître la salle d’un rendez vous ?? Patient Médecin a un rdv 0,n 0,n Salle 1,n Patient Médecin a un rdv 0,n 0,n Salle Exerce 1,n 1,n OU Où s'arrêter ?? – Un étudiant obtient des notes à des cours – Un étudiant habite dans une ville – Un étudiant a eu un bac d’un certain type – Les étudiants sont regroupés en sous groupes – Les sous groupes sont regroupés en groupes – Les groupes sont regroupés en promotions • Ne faire des entités que si elles ont une utilité – il y a plus d’une propriétés dans l’entité – les entités sont liées à d’autres entités • Dépend de l’objectif de la base de données et de l’application Verification du modèle : (1) Identifiant • Une occurrence d’entité peut être identifié (sans ambiguité) grâce à l’occurrence d’une propriété....c.a.d il existe un identifiant • Il faut vérifier que cet identifiant a bien été choisi – nom et prénom de l’étudiant peut être l’identifiant de l’étudiant, mais ça peut ne pas être suffisant.... Remarque importante – il ne faut pas concevoir le MCD en observant les données telles qu’elles sont - par exemple l’IUT tel qu’il est. – il faut concevoir le MCD pour le cas général (qui est le cas restreint de l’application qu’on se fixe) - l’IUT tel qu’il peut être.... et tel que l’on se prpose de le gérer.... (2) Propriété répétitive ou sans signification • Pour une occurrence d’entité, il ne peut y avoir qu’une occurrence de chaque propriété de l’entité – exemple: Cours ne peut être une propriété de Prof, puisqu’un prof enseigne plusieurs cours... – Remarque : Si un prof ne peut enseigner qu’un seul cours, cours peut être une propriété de prof • Une propriété ne peut être sans signification pour une partie des entités – exemple : si un prof ne peut enseigner qu’un seul cours, mais qu’on a choisi de créer une entité ‘personnel’ et non ‘prof’, on ne stockera pas le cours dans l’entité ‘personnel’ car il serait sans signification pour une secrétaire... – contre exemple : Téléphone et Fax pour un étudiant... (3) Dépendance pleine des entités • Les propiétés d’une association doivent dépendre de la totalité des entités associées. Si certaines propriétés ne dépendent que d’un sous ensemble des entités, on devra – les rattacher à une des entités – créer une nouvelle association associant ce sous ensemble • Exemple: 1/ Un prof enseigne toujours dans la même salle 2/ La salle dépend du prof et du cours Prof Groupe Cours enseigne Heure Salle (4) Respect des règles de gestion • Il faut vérifier que le MCD correspond bien au ‘réel’, c’est à dire aux règles fixées (celles que l’application doit respecter) • par exemple, à l’IUT: – un prof enseigne plusieurs courss (Mme Maadani) – une matière est enseignée par plusieurs profs (info/anglais) – les notes peuvent être données par n’importe quel prof ou par plusieurs profs enseignant une matière... (info par exemple) – On peut redoubler une fois.... – etc... Les formes normales • Les formes normales sont des règles que l’on doit suivre pour éviter d’avoir des redondances dans notre base de données. – La redondance entraîne une perte de place – des risques d’incohérences – des difficultés de mise à jour • Il existe 5 formes normales, de plus en plus complexes, de moins en moins utiles... • Nous verrons les 3 premières (déjà bien compliquées) Première forme normale • Toute propriété doit être élémentaire. – Sinon, on introduit une complexité de traitement • Propriétés élémentaires : Age, Salaire, N° de rue • Propriétés non-élémentaires : Adresse (complete), N°SS • Attention, la notion d’élémentaire dépend de l’application. – L’adresse peut devenir élémentaire si elle est toujours manipulé comme tel (on ne cherchera jamais a faire un tri par ville) • «Il n’est pas génant d’éclater des propriétés qui devrait être groupés, mais on ne peut grouper des propriétés qui devrait être éclatées» Deuxième forme normale • Toute propriété doit dépendre pleinement de l’identifiant (et non d’une partie de celui-ci) – sinon on introduit des redondances. • Exemple: l’association ‘‘enseigne’’ possède comme identifiant nomprof, nomcours, nomgroupe 1/ la salle ne dépend que du prof donc d’une partie de l’identifiant 2/ la salle ne dépend que du prof et du cours.... • Cette règle rejoint la règle 2 de vérification... Prof Groupe Cours enseign e Heure Salle Troisième forme normale • Pas de uploads/Sante/ c020-meriselight.pdf