1 © C. HANACHI, J.M. THEVENIN Licence AES Cours d informatique 2ème Partie : Concevoir une Base de Données Cours de Mr Perrussel

Présentation au sujet: "1 © C. HANACHI, J.M. THEVENIN Licence AES Cours d informatique 2ème Partie : Concevoir une Base de Données Cours de Mr Perrussel"— Transcription de la présentation:

1 1 © C. HANACHI, J.M. THEVENIN Licence AES Cours d informatique 2ème Partie : Concevoir une Base de Données Cours de Mr Perrussel perrussel@univ-tlse1.fr Mr Thévenin thevenin@univ-tlse1.fr Polycopié réalisé par C. HANACHI, J.M. THEVENIN Introduction aux Bases de Données

2 2 © C. HANACHI, J.M. THEVENIN

3 3 2ème Partie : Concevoir une Base de Données 1. Les finesses de la modélisation Entité-Association 2. Compléments sur le modèle relationnel 3. Présenter un dossier danalyse

4 4 © C. HANACHI, J.M. THEVENIN Chapitre 1 Les finesses de la modélisation Entité-Association 1.Concepts de base 2.Eléments de description des Entités et des Associations 3.Remarques importantes 4.Démarche de conception 5.Vérifications 6.Produire un dossier complet 7.Exemple

5 5 © C. HANACHI, J.M. THEVENIN 1.1 Concepts de base : a)Entité b)Association c)contrainte dintégrité

6 6 © C. HANACHI, J.M. THEVENIN 1.1 Concepts de base : a) Entité Entité : Objet du monde réel que lon peut identifier sans ambiguité Souvent sujet ou COD dans les phrases décrivant le monde réel. Ex : Tintin embarque sur le vol 714 Classe dEntités regroupement dentités ayant les mêmes propriétés ou des caractéristiques communes caractérisée par : -lensemble de ses propriétés -son identifiant Sujet COD

7 7 © C. HANACHI, J.M. THEVENIN 1.1 Concepts de base : a) Entité Classe dEntités (suite) Les regroupements en classes dentités se font en fonction de ce que lon veut représenter -> perception du monde réel Ex : On sintéresse à l état civil : J. Travolta A.Hichkoc Personnes -nom -prénom -date naissance -profession On sintéresse au cinéma : J. Travolta Acteurs A. Hitchkoc Q. Tarantino Réalisateurs W. Allen ? ?

8 8 © C. HANACHI, J.M. THEVENIN 1.1 Concepts de base : b) Association Association : Lien qui relie 2 ou plusieurs Entités Souvent un Verbe dans les phrases décrivant le monde réel. Ex : Tintin embarque sur le vol 714 Classe dAssociations regroupement dassociations reliant des Entités appartenant aux mêmes classes dEntités caractérisée par : -lensemble des classes dEntités quelle relie -plus déventuelles propriétés qui lui sont propres Verbe

9 9 © C. HANACHI, J.M. THEVENIN 1.1 Concepts de base : c) Contraintes dintégrité Définition : contrainte dintégrité = règle de gestion qui doit être respectée quelque soit linstantiation (contenu à un instant t) de la base de données. Ex : on ne peut embarquer si lon na pas de billet. Principe : Toute mise à jour doit satisfaire lensemble des contraintes dintégrité. Garantit que la base de données évolue dun état cohérent vers un nouvel état cohérent Toute mise à jour ne satisfaisant pas une contrainte dintégrité doit être rejetée

10 10 © C. HANACHI, J.M. THEVENIN 1.1 Concepts de base : c) Contraintes dintégrité Exemples : C1: 1 vol dessert au moins une ville C2: 1 fleuve prend sa source dans un seul pays C3: le type dun espace maritime est soit mer soit océan C4: le pays ou un fleuve prend sa source doit exister C5: pour embarquer il faut avoir un billet C6: le nombre de véhicules garés dans un garage ne peut pas dépasser le nombre de places du garage C7: 1 ingénieur ne peut être affecté à un contrat pour une compétence quil n a pas

11 11 © C. HANACHI, J.M. THEVENIN 1.1 Concepts de base : c) Contraintes dintégrité Classification des contraintes : Contraintes de cardinalité : C1, C2 Contraintes de domaine : C3 Contraintes dintégrité référentielle : C4 Règles de gestion : C5, C6, C7 Représentation des contraintes dintégrité Les contraintes de cardinalité sont représentées sur le schéma E/A Les contraintes de domaine sont indiquées dans le dictionnaire des propriétés Les contraintes dintégrité référentielle sont implicites Les règles de gestion doivent être énoncées dans un section spécifique

12 12 © C. HANACHI, J.M. THEVENIN 1.2 Eléments de description : a) Propriété b) Domaine de valeur c) Identifiant d) Cardinalité et rôle

13 13 © C. HANACHI, J.M. THEVENIN 1.2 Eléments de description : a) Propriété Propriété : Unité dinformation non décomposable ex : Pas de redondance des propriétés : incohérence si on a 2 valeurs différentes pour la même propriété difficultés de mise à jour perte de place coûts Pas de redondance dans les noms de propriétés Adresse N° Rue CP Ville Liste des pays traversés Association entre Pays et Fleuve pouvant être matérialisée par un ensemble de liens

14 14 © C. HANACHI, J.M. THEVENIN 1.2 Eléments de description : b) Domaine de valeur Domaine de valeur : Ensemble de valeurs possibles pour une propriété Permet dexprimer une classe de contraintes dintégrité, les contraintes de domaine ex : -Type : { mer, océan } -Age : [7..77] -Quantité : Entier > 0 -DateDébut : Date -NomP : Texte -Superficie : Entier long

15 15 © C. HANACHI, J.M. THEVENIN 1.2 Eléments de description : c) Identifiant Identifiant dEntité Plus petit groupe de propriétés permettant de désigner une instance dune classe de Entité sans ambiguité Plusieurs identifiants peuvent être candidats Identifiants courts Eviter les N° systématiques Lidentifiant doit déterminer une seule valeur pour chaque autre propriété La valeur dune propriété ne doit pas pouvoir être déduite par dautres propriétés que lidentifiant CAMIONS NumCam Année Modèle Charge autorisée Conso Numcam Année Modèle Charge aut Conso Modèle Charge aut Conso MODELES Modèle Charge aut Conso

16 16 © C. HANACHI, J.M. THEVENIN 1.2 Eléments de description : c) Identifiant Identifiant dAssociation : Par défaut, les Associations sont identifiées par les n-uplets constitués des identifiants des Classes dEntité quelles relient Lorsque les mêmes entités peuvent être reliées par plusieurs arcs de la même classe dAssociation, il faut ajouter des propriétés de la classe dAssociation à cet identifiant par défaut ex : Lidentifiant dune classe dAssociation Dynamique est souvent complété par une propriété date Jouer Rôle Acteurs NA Nom Films Titre Durée (1,n) (0,n)

17 17 © C. HANACHI, J.M. THEVENIN 1.2 Eléments de description : d) Cardinalité et rôle Cardinalité : Couple (min, max) exprimant combien de fois une instance dune Entité peut être reliée à dautres instances par le biais dune Association min traduit le caractère obligatoire (1) ou facultatif (0) du lien max indique si le lien doit être unique (1) ou sil peut être multiple (n) E1 E2 (min,max) e11 x e12 x x e22 x e21 E2 E1 max min

18 18 © C. HANACHI, J.M. THEVENIN 1.2 Eléments de description : d) Cardinalité et rôle Cardinalité (suite) : Dépend du rôle que lon donne à la patte de lassociation : -Faire une phrase dont le sujet est une instance de lEntité reliée à cette patte -ex : un acteur joue dans combien de film au min et au max ? Exprime une contrainte sur le monde réel On est parfois amené à faire des hypothèses sur le monde réel pour exprimer ces contraintes écrire ces hypothèses Jouer Rôle Acteurs NA Nom (1,n) 1) Un acteur joue dans au moins un film (min=1) et peut jouer dans plusieurs films (max=n) Joue 1) Hypothèses :

19 19 © C. HANACHI, J.M. THEVENIN 1.3 Remarques importantes : a) Influence du concepteur b) Différents types dassociation c) Compléments sur les propriétés

20 20 © C. HANACHI, J.M. THEVENIN 1.3 Remarques importantes : a) Influence du concepteur Influence du concepteur : Le choix des classes dEntité, des classes dassociation, des cardinalité et des contraintes dintégrité traduit une perception de la réalité ex : Copropriété autorisée ? Copropriété interdite ? Multipropriété autorisée ? Multipropriété interdite ? Propriété obligatoire ? Posséder Personnes NP Nom Voitures Nv Marque Possède Appartient

21 21 © C. HANACHI, J.M. THEVENIN 1.3 Remarques importantes : a) Influence du concepteur Il y a plusieurs modélisations possibles dune même réalité Modélisation 2 plus souple : W. Allen peut être acteur et réalisateur Valeurs nulles : personnalité, notoriété pour un réalisateur Films Titre Durée Acteurs Nom Prénom Personnalité Notoriété Réalisateurs Nom Prénom Jouer Réaliser (0,n) (1,n) (1,1) (1,n) Modélisation 1 Personnes Nom Prénom Personnalité Notoriété Films Titre Durée Jouer Réaliser (1,n) (0,n) (1,1) (1,n) Modélisation 2

22 22 © C. HANACHI, J.M. THEVENIN 1.3 Remarques importantes : a) Influence du concepteur Il y a plusieurs modélisations possibles dune même réalité (suite) Avantage Modélisation 3 : évite les valeurs nulles Modélisation 3 Films Titre Durée Acteurs Na Personnalité Notoriété Personnes Nom Prénom Jouer Réaliser (0,n) (1,n) (1,1) (1,n) est un (1,1)(0,1) Films Titre Durée Acteurs Personnalité Notoriété Personnes Nom Prénom Jouer Réaliser (0,n) (1,n) (1,1) (1,n) Modélisation avancée

23 23 © C. HANACHI, J.M. THEVENIN 1.3 Remarques importantes : b) Différents types dassociation Statiques Dynamiques Films Titre Durée Acteurs Na Personnalité Notoriété Jouer (0,n) (1,n) Films Titre Durée Cinémas Nc NomC Adresse Diffuser (1,n) Date : DateDébut DateFin

24 24 © C. HANACHI, J.M. THEVENIN 1.3 Remarques importantes : b) Différents types dassociation Reflexive Films Titre Durée Suite n° précède est la suite (0,1) Emploiés Matricule Nom Prénom Encadrer encadre est encadré (0,n) (0,1)

25 25 © C. HANACHI, J.M. THEVENIN 1.3 Remarques importantes : b) Différents types dassociation Association n-aire Il y a une relation de dépendance entre les entités. ex : Pierre est affecté sur le contrat 1 comme spécialiste BD Pierre est affecté sur le contrat 5 comme spécialiste PHP Pour les cardinalités on résonne en terme de couples : Un ingénieur nest pas forcément associé à un couple (contrat, spécialité) ; à terme, il sera associé à plusieurs couples. Ingénieurs Matricule Nom Prénom Affecter Dd Df (0,n) Contrats Nc Objet Pénalités Spécialités Ns Libellé Nécessiter NbHJ Avoir nécessite (1,n) est nécessité (0,n) a (1,n) est acquise (0,n) est affecté se voit affecter est affectée (0,n)

26 26 © C. HANACHI, J.M. THEVENIN 1.3 Remarques importantes : b) Différents types dassociation Possibilité davoir plusieurs associations entre les mêmes Entités Personnes Nom Prénom Personnalité Notoriété Films Titre Durée Jouer Réaliser (1,n) (0,n) (1,1) (1,n)

27 27 © C. HANACHI, J.M. THEVENIN 1.3 Remarques importantes : c) Compléments sur les propriétés Propriété : Caractéristique dune Entité ou dune Association que le concepteur juge utile de répertorier, qui prendra 1 valeur précise pour chaque instance sur 1 domaine de variation Utile : On ne modélise que ce dont on a besoin On ne stock pas les données qui se déduisent des autres par un calcul 1 valeur pour 1 instance : Qte PrixUnitaire PrixTotalHT Produits NP Facture NFac Date Figurer (0,n) (1,n) Qte ?? Personnes Enfant1 Enfant2 Enfants

28 28 © C. HANACHI, J.M. THEVENIN 1.4 Démarche de conception : 0) Enquête / Interview / Analyse de lexistant - Documents du SI formel - Phrases de compte rendu denquête Point de départ 1) Repérer toutes les propriétés non décomposables Création du dictionnaire des propriétés 1) Eliminer les propriétés qui peuvent être déduites par calcul EX : Facture Nom : Adresse : Tel : Ref : Date : N° Facture : Code Art Désignation Qté PUHT %remise PTTC Totaux

29 29 © C. HANACHI, J.M. THEVENIN 1.4 Démarche de conception : 2) Regrouper les propriétés par Entités naturelles Certaines propriétés ne peuvent pas être regroupées par Entités Caractérisent des Associations 2) Souligner lidentifiant de chaque Entité 3) Déterminer les classes dAssociation reliant les Entités (sont sous la forme de verbes) Sélectionner uniquement les Associations dont on a besoin ! !

30 30 © C. HANACHI, J.M. THEVENIN 1.4 Démarche de conception : 3) Déterminer les rôles et les cardinalités des classes dAssociations - Mentionner les hypothèses faites sur le monde réel pour le choix des cardinalités 3) Eliminer les Associations redondantes 4) Définir les éventuelles propriétés des Associations 4) Contrôler les identifiants des classes dAssociation : - si les mêmes entités peuvent être reliées par plusieurs liens de la même classe dAssociation compléter lidentifiant avec les propriétés de la classe dassociation 5) Vérifier que lon a pas oublié de propriété : - toutes les infos de lenquête sont représentées 6) Enumérer les Contraintes dIntégrité 7) Vérifier la cohérence du schéma

31 31 © C. HANACHI, J.M. THEVENIN 1.5 Vérifications : 1) Vérifier que chaque Entité est bien conçue : -Les propriétés décrivent lEntité - 1 identifiant qui identifie effectivement lEntité lEntité -Cette clé est minimale -Chaque propriété est atomique (non décomposable) -La clé détermine toutes les propriétés -Il nexiste pas dautre propriété qui détermine un sous-ensemble des propriétés 2) Idem avec chaque Association -Est-ce que les identifiants des Entités reliées suffisent à identifier 1 lien ? 3) Il ny a pas de redondance -Toute propriété apparaît une seule fois (unicité des noms) 4) Généralement, le schéma doit être connexe -Sinon, 2 BD indépendantes 5) Le schéma est complet -Tout le texte est représenté !

32 32 © C. HANACHI, J.M. THEVENIN 1.6 Produire un dossier complet : Constitution : 1) Résultat denquête Résultat de létape 0 de modélisation 2) Schéma Entité/Association +Dictionnaire des propriétés +(description informelle) 3) Hypothèses faites pour le choix des cardinalités -Ex : 1) Un acteur joue dans au moins un film (min=1) et peut jouer dans plusieurs films (max=n) 4) Contraintes dintégrité -Indiquer CI de type règle de gestion -Ex: C7: 1 ingénieur ne peut être affecté à un contrat pour une compétence quil n a pas !

33 33 © C. HANACHI, J.M. THEVENIN 1.7 Exemple : Tennis : Chaque joueur participant à un tournoi est connu par son nom, prénom, adresse, classement ATP. Un tournoi est lui même connu par nom, un lieu et une date. On sintéresse au classement des joueurs dans les tournois. On sintéresse aussi aux sponsors qui financent les tournois et/ou les joueurs. Les joueurs négocient généralement un contrat à lannée avec leur sponsor et peuvent toucher une prime par tournoi. On connaît la raison sociale, ladresse et le téléphone des sponsors. Un contrat comporte un numéro, une année, un montant, une compensation (x stickers à tel endroit) et est signé par un joueur et un sponsor.

34 34 © C. HANACHI, J.M. THEVENIN Chapitre 2 Compléments sur le modèle relationnel 1.Définition intuitive 2.Définition formelle 3.Schéma de BD relationnelle 4.Cas particuliers de traduction E/A->Relationnel 5.Exemple

35 35 © C. HANACHI, J.M. THEVENIN 2.1 Définition intuitive : Relation : Ensemble de n-uplets de même structure ex : Voitures = {( 123XN31, Renault, Bleu ), ( 234ZX32, Citroën, vert ), ( 432AX31, Citroën, Rouge )} N-uplet : Une instance dEntité ou dAssociation constituée de toutes ses propriétés ex : la voiture ( 123XN31, Renault, Bleu )

36 36 © C. HANACHI, J.M. THEVENIN 2.2 Définition formelle : Domaine : Ensemble de valeurs que peut prendre une manifestation de la réalité Ensemble de valeurs possibles pour une propriété ex : -WE ={ Samedi, Dimanche } -Activité = { Chant, Tennis, Foot } -Entiers -[7..77] -Date

37 37 © C. HANACHI, J.M. THEVENIN 2.2 Définition formelle : Produit cartésien des domaines intervenant dans une relation : Ensemble des n-uplets possibles pour une relation Intension de la relation ex : Activité WE = {(Chant, Samedi), (Chant, Dimanche), (Tennis, Samedi), (Tennis, Dimanche), (Foot, Samedi), (Foot, Dimanche)} Relation : Sous-ensemble du produit cartésien de plusieurs domaines Extension de la relation ex : Activités = {( Chant, Samedi ), ( Tennis, Samedi ), ( Foot, Dimanche )}

38 38 © C. HANACHI, J.M. THEVENIN 2.3 Schéma de BD relationnelle a) schéma de relation Une relation est définie par son schéma qui caractérise son intension Syntaxe : nomrel (nomAtt1 : domaine1 : contrainte1; nomAtt2 : domaine2 : Contrainte2; …) Contrainte : -unique (clé) -not null -clé étrangère La clé est soulignée Les clés étrangères sont mises en italique ou suivies de * ou # Syntaxe simplifiée: nomrel (nomAtt1, nomAtt2, …, nomAttn*)

39 39 © C. HANACHI, J.M. THEVENIN 2.3 Schéma de BD relationnelle b) schéma de BD Le schéma dune Base de Données est défini par lensemble des schémas des relations constituant la base de données + la spécification des contraintes dintégrité (règles de gestion) qui ne sont pas décrites dans les schémas de relation ex : Personnes (NoP : Entier ; Nom : Texte(20) : not null ; Age : [7..77]) Voitures (NV : Entier ; Marque : {Renault, Citroên}; Type : Texte (15)) Posseder (NoP* ; NV*; DtAch : Date } C1 : Une personne de moins de 18 ans ne peut posséder de voiture

40 40 © C. HANACHI, J.M. THEVENIN 2.4 Cas particuliers de traduction : a) cas le + courant : (x,n) (x,n) ¬Chaque Entité devient une Relation aNom E nom Relation b{propriétés de E} {Attributs de R} cIdentifiant de E Clé de Relation ­Chaque Association devient 1 Relation aNom A nom Relation bIdent E1 Ident E2 {propriétés de A} {Attributs de R} cId A + Id E1 + Id E2 Clé de Relation dLes Clés importées (Id E1, Id E2) sont déclarées comme clés étrangères Ex : Acteurs (NA, Nom) Films (Titre, Durée) Jouer (NA*, Titre*, Rôle) Jouer Rôle Acteurs NA Nom Films Titre Durée (1,n) (0,n)

41 41 © C. HANACHI, J.M. THEVENIN 2.4 Cas particuliers de traduction : b) cas particulier : (x,1) (x,n) ¬Chaque Entité devient une Relation aNom E nom Relation b{propriétés de E} {Attributs de R} cIdentifiant de E Clé de Relation ­LAssociation fusionne avec la Relation reliée par la patte (x,1) aIdent de lautre E ajouté comme clé étrangère à la relation fusionnée b{propriétés de A} ajouté aux attributs de la relation fusionnée Ex : Réalisateurs (NR, Nom) Films (Titre, Durée, NR*, DateR) Réaliser DateR Réalisateurs NR Nom Films Titre Durée (1,n) (1,1) Ident autre E {propriétés de A}

42 42 © C. HANACHI, J.M. THEVENIN 2.4 Cas particuliers de traduction : b) cas particulier : (x,1) (x,1) ¬Une association ne fusionne quune fois ­Fusionner de préférence avec la relation reliée par une patte de card min = 1 Ex : Plongeurs (NP, Nom) Clubs (NC, Adresse, NP*) Présider Plongeurs NP Nom Clubs NC Adresse (0,1) (1,1) Ident autre E

43 43 © C. HANACHI, J.M. THEVENIN 2.4 Cas particuliers de traduction : c) cas n-aires : (x,n) (x,n) (x,n) ¬Chaque Entité devient une Relation idem cas a) ­Chaque Association devient 1 Relation idem cas a) Ex : Contrats (Nc, Objet, Pénalités) Ingénieurs (Matricule, Nom, Prénom) Spécialités (Ns, Libellé) Affecter (Nc*, Matricule*, Ns*, Dd, Df) Ingénieurs Matricule Nom Prénom Affecter Dd Df (0,n) Contrats Nc Objet Pénalités Spécialités Ns Libellé est affecté se voit affecter est affectée (0,n)

44 44 © C. HANACHI, J.M. THEVENIN 2.4 Cas particuliers de traduction : c b ) cas part n-aires : (x,1) (x,n)(x,n) ¬Chaque Entité devient une Relation idem cas b) ­LAssociation fusionne avec la Relation reliée par la patte (x,1) idem cas b) Ex : Joueurs (Nom, Prénom, ClassATP) Sponsors (RaisonSoc, Adresse) Contrats (Nc,Année,Montant,RaisonSoc*,Nom*,Prénom*) Joueurs Nom Prénom ClassATP Signer (0,n) (1,1) Contrats Nc Année Montant Sponsors RaisonSoc Adresse signe est signé signe (0,n)

45 45 © C. HANACHI, J.M. THEVENIN 2.4 Cas particuliers de traduction : d) cas A reflexive : (x,n) (x,n) ¬Chaque Entité devient une Relation idem cas a) ­Chaque Association devient 1 Relation idem cas a) Attention : les deux arcs aboutissent au mêmes identifiants leurs donner des noms différents Ex : Employés (Matricule, Nom, Prénom) Collaborer (Matricule1*, Matricule2*) Emploiés Matricule Nom Prénom Collaborer collabore (0,n) 1 2

46 46 © C. HANACHI, J.M. THEVENIN 2.4 Cas particuliers de traduction : d b ) cas A reflexive : (x,1) (x,n) ¬Chaque Entité devient une Relation idem cas b) ­LAssociation fusionne avec la Relation reliée par la patte (x,1) idem cas b) Attention : la clé est importée comme clé étrangère lui donner un nom différent Ex : Employés (Matricule, Nom, Prénom, MatriculeChef*) Emploiés Matricule Nom Prénom Encadrer encadre est encadré (0,n) (0,1)

47 47 © C. HANACHI, J.M. THEVENIN 2.5 Exemple : lTraduire le schéma E/A du Tennis :