La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

de la théorie à la pratique Faculté Polytechnique de Mons

Présentations similaires


Présentation au sujet: "de la théorie à la pratique Faculté Polytechnique de Mons"— Transcription de la présentation:

1 de la théorie à la pratique Faculté Polytechnique de Mons
Les Bases de données relationnelles de la théorie à la pratique Mohammed BENJELLOUN Service d’Informatique Faculté Polytechnique de Mons

2 Objectifs - Comprendre les concepts et techniques sur lesquels reposent les fonctions principales d'un système de gestion de bases de données. - Pouvoir représenter dans une base de données le contenu d'information d'un domaine d'application. - Pouvoir utiliser ces fonctions pour mettre en oeuvre une application simple reposant sur une base de données (Analyse, conception, structuration des données, mise en oeuvre d’une base de donnée relationnelles avec intéraction... ). Contenu L'approche base de données Conception d'une base de données Bases de données relationnelles Pratique d'un SGBD

3 Etapes et Démarche de modélisation
1. Analyse de la situation existante et des besoins 2. Création d'une série de modèles qui permettent de représenter tous les aspects importants 3.  A partir des modèles, implémentation d'une base de données

4 Un modèle de base de données est un ensemble d’éléments qui décrit les données et permet d’exprimer les propriétés et les liens entre ces données. Le modèle est souvent représenté de manière graphique. Il se compose d’une description des données et de leurs relations ainsi que d’un ensemble de contraintes concernant la valeur que peuvent prendre les données ou concernant les liens qui les relient. Un schéma de base de données est une description de la structure des données à gérer via l’utilisation d’un langage déterminé.

5 Définitions Information : Une information est un élément qui permet de compléter notre connaissance sur un objet, un événement, une personne ... . Exemple: Le nom d'une personne est une information concernant cette personne. Système d'information : Un système d'information est constitué par l'ensemble des informations relatives à un domaine bien défini. Exemple: Librairie : stock, commandes, ventes … Un S. I. existe indépendamment des techniques informatiques. Il contient les données et les traitements nécessaires pour assimiler et stocker les informations entrantes et produire les informations sortantes.

6 Définitions Base de données : Une base de données (BD) est un ensemble bien structuré de données relatives à un sujet global. Ces données peuvent être de nature et d'origine différentes.   Les données sont des faits, connus et qui ont un sens pour l’utilisateur. Ces données doivent avoir une relation entre elles. “collection de données enregistrées ensemble, sans redondance pénible ou inutile, pour servir plusieurs applications, on y enregistre les données de façon à ce qu’elles soient indépendantes des programmes qui les utilisent, on utilise une approche commune et contrôlée pour ajouter, modifier, retrouver des données” James Martin Collection de données persistantes utilisées par des systèmes d’application de certaines entreprises …

7 Exemples: FPMs ⇨ BD ⇨ sur tous les étudiants.
Définitions Une base de données correctement construite permet de partager les données entre plusieurs utilisateurs, de restreindre l’accès ou la modification des données, d’assurer l’intégrité des données et d’équilibrer les conflits des besoins tout en réduisant les redondances et en évitant les incohérences Exemples: FPMs ⇨ BD ⇨ sur tous les étudiants. Une banque ⇨ BD ⇨ sur tous les clients. Une société d'assurances ⇨ BD ⇨ contrats d'assurances et sinistres.

8 ---- une base de données ?
Qu'attendre Pourqoui ---- une base de données ? Lorsqu’on a besoin d’organiser les données en un ensemble structuré et : Contrôle centralisé des données Redondance réduite Incohérence évitée Données partagées Normes imposées Restrictions de sécurité possibles Intégrité assurée (36/15/2005 est impensable) Conflits des besoins équilibrés Et stocker, consulter, modifier des informations

9 SGBD Système de gestion de bases de données :
Un système de gestion de bases de données (SGBD) est un programme qui permet la représentation informatique des données, qui nous permet de créer, de modifier et d'exploiter des bases de données. Ce système constitue donc notre interface pour accéder aux données. SGBD BD logiciel gérant une BD. Il permet à un utilisateur de communiquer (requêtes) avec une base de données pour : - décrire et organiser les données sur les mémoires, - rechercher, sélectionner et modifier les données.

10 SGBD Qu'attendre Pourqoui ---- un SGBD? Un SGBD assure
- la description des données, - leur recherche et mise à jour, - la sûreté : vérifier les droits d’accès des utilisateurs ; limiter les accès non autorisés ; crypter les informations sensibles - la sécurité : sauvegarde et restauration des données ; limiter les erreurs de saisie, de manipulation - l’intégrité : définir des règles qui maintiennent l’intégrité de la base de données (contraintes d’intégrité) - la concurrence d’accès : détecter et traiter les cas où il y a conflit d’accès entre plusieurs utilisateurs et les traiter correctement. SGBD

11 SGBD +ieurs MODELES de BASES de DONNEES  •b) •a) •d) •c)
•a) le modèle hiérarchique: les données sont classées hiérarchiquement, selon une arborescence descendante. Ce modèle utilise des pointeurs entre les différents enregistrements. Le plus ancien, peu souple. •b) le modèle réseau: Comme le modèle hiérarchique ce modèle utilise des pointeurs vers des enregistrements. Moyennement souple, complexe pour le développement, performance moyenne. •c) le modèle relationnel (SGBDR, Système de gestion de bases de données relationnelles): les données sont enregistrées dans des tables. La manipulation de ces données se fait selon la théorie mathématique des relations , théorie ensembliste. (du mathématicien CODD). Fort souple, aisé à développer. •d) le modèle objet (SGBDO, Système de gestion de bases de données objet): les données sont stockées sous forme de classes. fort souple, aisé à développer •b) •a) •d) •c)

12 SGBD Les caractéristiques
L'architecture à trois niveaux définie par le standard ANSI/SPARC permet d'avoir une indépendance entre les données et les traitements. D'une manière générale un SGBD doit avoir les caractéristiques suivantes: SGBD • Indépendance physique: Le niveau physique peut être modifié indépendamment du niveau conceptuel. Cela signifie que tous les aspects matériels de la base de données n'apparaissent pas pour l'utilisateur, il s'agit simplement d'une structure transparente de représentation des informations • Manipulabilité: des personnes ne connaissant pas la base de données doivent être capables de décrire leur requêtes sans faire référence à des éléments techniques de la base de données • Rapidité des accès: le système doit pouvoir fournir les réponses aux requêtes le plus rapidement possible, cela implique des algorithmes de recherche rapides • Administration centralisée: le SGBD doit permettre à l'administrateur de pouvoir manipuler les données, insérer des éléments, vérifier son intègrité de façon centralisée • Limitation de la redondance: le SGBD doit pouvoir éviter dans la mesure du possible des informations redondantes, afin d'éviter d'une part un gaspillage d'espace mémoire mais aussi des erreurs • Vérification de l'intégrité: les données doivent être cohérentes entre elles, de plus lorsque des éléments font références à d'autres, ces derniers doivent être présents • Partageabilité des données: le SGBD doit permettre l'accès simultané à la base de données par plusieurs utilisateurs • Sécurité des données: Le SGBD doit présenter des mécanismes permettant de gérer les droits d'accès aux données selon les utilisateurs

13 Historique

14 Modèle relationnel Les concepts mis en oeuvre dans le modèle relationnel sont fondés sur une théorie mathématique directement issue de l'algèbre relationnelle, de la théorie des ensembles et de la logique formelle. Cette technologie a vu le jour dans les années 70 avec les travaux de Codd * Objets simples : table, ligne, colonne * Basé sur des objets mathématiques bien connus : - Relation, n-tuple, ensemble, etc. * Opérations d'interrogation - Sélection, projection, jointure Actuellement le modèle le plus répandu (de loin) 1980 : Les systèmes de gestion de bases de données relationnels apparaissent sur le marché. 1990 : Les systèmes de gestion de bases de données relationnels dominent le marché.

15 Les objectifs du modèle relationnel :
· proposer des schémas de données faciles à utiliser, · fournir une approche méthodologique dans la construction des schémas. · améliorer l'indépendance logique et physique, · mettre à la disposition des utilisateurs des langages de haut niveau pouvant éventuellement être utilisés par des non informaticiens, · optimiser les accès à la base de données, · améliorer l'intégrité et la confidentialité, Manipulations relationnelles, en général exprimées en SQL, transforment des tables en une table Algèbre Relationnelle Les données sont perçues par l’utilisateur comme des tables JOIN: relie 2 tables grâce aux valeurs communes de 2 colonnes communes

16 Opérations relationnelles
Sélection : Projection Restriction Jointure Division Agrégation Opération suppl. Mise à jour Création d ’une vue

17 Liste non exhaustive de SGBD relationnels :
Adabas de Software AG Access de Microsoft DB2 : IBM Informix : Unix Ingres : Vax, IBM, Sun, HP, Dos MS-sql MySQL (logiciel libre) Oracle : Oracle (multi plateforme) Progress : Unix, Dos, VMS, OS/2 PostgreSQL (logiciel libre) SqlServer de Microsoft Sybase de Sybase

18 Mise en oeuvre d’un SGBD
On distingue trois niveaux d’appréhension définis par la norme ANSI/SPARC (architecture de référence d'un SGBD). A chaque niveau correspond un schéma de représentation : le niveau interne avec le schéma physique Description du stockage des données au niveau des unités de stockage le niveau conceptuel avec le schéma conceptuel Description de la structure des données de la base, description de leurs propriétés (relations qui existent entre elles), sans soucis d'implémentation physique ni de la façon de s'en servir. le niveau externe avec les vues (comment l’utilisateur voit les données) Description pour chaque utilisateur de sa perception des données. ES CS IS

19 CS IS ESs : Schémas Externes CS : Schéma Conceptuel
IS : Schéma Interne ES ES ES CS L'administrateur aura pour rôle : la conception du modèle à partir du monde réel à représenter, le réglage du schéma physique pour certaines optimisations de performances, le maintien de la base de données physique, la description des schémas externes à l'usage des utilisateurs finaux. IS

20 Schémas Externes (ESs)
Définit une vue de la BD Vues SQL, Vbasic, orientés Web notamment (HTML, XML…) … ES CS IS Une BD est en général munie de plusieurs différentes ESs Mais tous ont le CS comme racine commune

21 CS Merise Schéma Interne (IS) Schéma Conceptuel
Comment transformer les objets? Comment ils seront stockés? Comment y accèdes? Schéma Interne (IS) CS Schéma Conceptuel Merise Merise est une des méthodes de conception et de développement de projets informatiques. Cette méthode date de , et fait suite à une consultation nationale lancée en 1977 par le ministère de l’Industrie français dans le but de choisir des sociétés de conseil en informatique dont la mission était de définir une méthode de conception de systèmes d’information. Une des techniques permettant de concevoir une base de données relationnelle est basée sur cette méthode. En effet, une des caractéristiques principales de la méthode Merise est la séparation des données et des traitements du futur système d’information.

22 Objets relationnels: domaines et relations
Terme relationnel formel Equivalent informel relation relation perçue entre entités (!!table) n-uplet ligne ou enregistrement cardinalité nombre de lignes attribut colonne ou champ degré nombre de colonnes clé primaire identificateur unique clé étrangère référence = attribut principal ailleurs domaine Ensemble de valeurs légales (ensemble des valeurs d’un attribut)

23 Tables, Requêtes, Formulaires, Rapports.
Les composants d'une base de données relationnelle Quatre types d'objets. Tables, Requêtes, Formulaires, Rapports. 1. Les Tables Une table est une collection de données relatives à un domaine bien défini. N° Mat NOM SALAIRE Code post. 159 Donald 1500 € 7000 132 Obélix 1900 € 5060 1187 Picsou 1134 € 1000 354 ….. …. Table : Employés_Disney Enregistrement, N_Uplet Valeurs de l’attribut Un champ de données (Attribut)

24 Analyser et Exécuter la requête
Clé primaire Pour identifier de manière unique chaque enregistrement de la table. La clé primaire, constituée d'un ou de plusieurs champs, nous permet d'identifier de manière unique chaque enregistrement d'une table. Pour définir des liens entre plusieurs tables la clé primaire est indispensable.  2.   Les requêtes (angl. Queries) Les requêtes ≡ "questions" qu'on pose au SGBD. Le résultat est toujours un sous-ensemble d'une ou de plusieurs tables. Il existe 4 types de requêtes: 1. Requêtes de sélection. Select 2. Requêtes d'insertion. Insert 3. Requêtes de modification. Update 4. Requêtes de suppression. Delete Pour chaque requête nous retrouvons le cycle suivant: Formuler la requête Analyser et Exécuter la requête Résultat de la requête

25 3. Les formulaires (angl. Forms)
3.    Les formulaires (angl. Forms) Les formulaires pour ajouter, modifier ou supprimer des données dans les tables. Les formulaires offrent certains avantages: facilité d'utilisation, sécurité des donnée 4.     Les rapports (angl. Reports) Pas de dialogue interactif avec l'utilisateur. Un rapport se base généralement sur une ou plusieurs tables ou le résultat d'une requête.

26 Niveaux d’abstraction
Cahier des charges en accord avec le client (activité et besoins)  créer une représentation virtuelle de la réalité. produire quatre modèles de données relatifs à quatre niveaux d’abstraction. Le niveau conceptuel identifie et décrit formellement l’ensemble des informations du domaine géré par le futur système d’information. Ce niveau amène donc le concepteur à construire une représentation formelle de la signification des données. Le niveau organisationnel exprime la répartition organisationnelle des données informatisées, la sécurité des données par rapport aux acteurs des unités organisationnelles et précise quelles sont, parmi les données définies au niveau conceptuel, celles qui seront prises en compte par le futur système informatisé. On ne développera pas cet aspect vu qu’il dépend fortement de l’environnement d’intégration du système d’information. Le niveau logique fournit une description des données prenant en compte les moyens informatiques de mémorisation et l’implémentation du système par un SGBD. C’est également ici que l’on retrouvera l’algèbre relationnelle. Le niveau physique exprime les choix techniques et décrit les données de la base de données dans la syntaxe du système de gestion adopté.

27 Cycle d'abstraction de conception des S.I.
La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitement afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues. Cette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information: Niveau Statique (données) Dynamique (traitements) Conceptuel MCD MCT Organisationnel ou logique MLD MOT (QUI ? QUAND ?) Opérationnel ou physique MPD MOPT

28 Univers de l’application
Donc la démarche classique d'un projet en BD comprend les étapes suivantes: 1. Analyse de la situation existante et des besoins 2. Création d'une série de modèles qui permettent de représenter tous les aspects importants 3.    A partir des modèles, implémentation d'une base de données Méthodologie pour traduire un système d'information naturel en une base de données Univers de l’application Analyse MCD MLD MPD Réel Perçu Schéma Conceptuel Schéma Logique Niveaux d’abstractions Elaboration du Modèle E-R Niveau Conceptuel Passage au Modèle Relationnel Niveau Logique Implémentation Sur SGBD-R Niveau Physique

29 Univers de l’application Implémentation Sur SGBD-R
Choix de l’application / groupe Rapport Univers de l’application Def. Dom. C.Chg Niveau Conceptuel Niveau Logique Niveau Physique Elaboration du Modèle E-R Passage au Modèle Relationnel Implémentation Sur SGBD-R Schéma Conceptuel Schéma Logique Schéma Physique Implémentation Sur SGBD-R

30 1er rapport : mars 2006 Cahier de charges.
2ème rapport : … Cahier de charges et MCD. 3ème rapport : … Rapport final   Votre rapport doit respecter scrupuleusement la table des matières suivante : 1.     Cahier de charges de l’application 2.     MCD 3.     MLD 4.     MPD (qlq tables et relations) 5.     Implémentation 6.     Conclusion 7.     Explications du fonctionnement de votre base de données Utilisez : Formulaires, index, requêtes, rapport. Pouvoir faire : Trier, exécuter des requêtes en SQL, utiliser des macros en SQL. Genre de documents à éditer : Liste alphabétique des clients,( étudiants, … ) par ville (secteur …) .. Liste par chiffre d’affaire des clients (moyenne pour les étudiants) … Lors de la conclusion : Les besoins futurs ! N’oubliez pas de joindre une disquette ou un CD de votre base de données. Indiquez aussi les noms des étudiants qui composent le groupe sur le support informatique et le rapport. Quelles seront les évolutions possibles de votre base de données ?

31 Modèle conceptuel des données MCD
Analyse Elaboration du Modèle E-R Niveau Conceptuel Schéma Conceptuel 1. Le niveau conceptuel, se base directement sur l'analyse, c’est une représentation du monde réel par un seul modèle. Il décrit, de façon formelle, l'ensemble des données du système d'information, sans tenir compte de l'implémentation informatique de ces données. Ce niveau représente donc la signification des données, se traduit par un formalisme que nous appelons: Modèle conceptuel des données MCD Permet de définir les informations pertinentes pour l’application et d’envisager leur structure. Doit refléter le plus fidèlement possible la réalité à modéliser dans la BD, à tout niveau : données, relation, contraintes de cohérence de données, ..

32 modélisation directe :
 La construction du schéma conceptuel comporte normalement les étapes suivantes : • Définir les objectifs • Analyser la réalité • Tracer le schéma conceptuel Pour la construction du modèle conceptuel, beaucoup de méthodes ont été mises en place mais aucune ne donne réellement satisfaction. On peut cependant les répartir en deux catégories : modélisation directe : Elle consiste à identifier, à partir d’une description exprimée en langage naturel, les entités et les associations en appliquant les règles suivantes : les noms deviennent des entités les verbes deviennent des associations La partie analytique consiste essentiellement à transformer des phrases décrivant certains aspects de la réalité en entités, relations et cardinalités.

33 modélisation par analyse des dép. fonctlles
Identifier toutes les propriétés du S.I. à analyser. Cette étape aboutit au dictionnaire des données épuré qui devra comporter ni synonyme, ni donnée calculée ... Il semble que la bonne approche de construction d’un modèle conceptuel des données soit un compromis entre la méthode directe, qui laisse une large part à l’intuition et la méthode basée sur l’étude des dépendances fonctionnelles. Quelle que soit la technique utilisée, le modèle doit être vérifié, normalisé et enrichi de concepts étendus pour représenter le plus fidèlement possible l’application.

34 Modèle logique des données : MLD Modèle physique des données : MPD
Passage au Modèle Relationnel Niveau Logique Schéma Logique 2. Le niveau logique se base sur le modèle conceptuel des données. Ce niveau introduit la notion des tables logiques, et constitue donc le premier pas vers les tables des SGBD. Ce niveau est représenté par le: Modèle logique des données : MLD Niveau Physique Implémentation Sur SGBD-R Schéma Physique 3. Le niveau physique, qui se base sur le modèle logique des données, contient finalement toutes les définitions et détails relatifs à l'utilisation d'un SGBD spécifique (p.ex. Access, dBASE, Oracle, Caché ...). A partir de ce niveau, on peut directement créer la base de données. Ce niveau est représenté par le: Modèle physique des données : MPD

35 Le schéma conceptuel Un des modèles possibles pour le schéma conceptuel est le modèle “entité-association”. Proposé par Peter Chen en 1976, il est notamment utilisé dans la méthodologie Merise.  Traduire l’analyse du système réel établie préalablement en entité, en relations, en propriétés et en cardinalités. Une entité permet de modéliser un ensemble d’objets de même nature. 1, N 1,1 CLIENT Numéro Nom Passer Commande Numéro Date Quantité Les relations sont des liens sémantiques qui peuvent exister entre plusieurs entités. Les “cardinalités” représentent le nombre possible d’interactions entre les entités et les “attributs” .

36 Relation ou Association Propriété de la Relation
Le Modèle Conceptuel des Données (MCD) Analyse ⇨ (MCD) : "Schéma Entité-Relation" ou "Schéma Entité-Association". Relation ou Association ENTITE Nom d’entité Nom de la Relation COMMANDE No Cde Date Cde PRODUIT No Prod Désignation Prix Unitaire CONCERNER Quantité Cdée Propriété de la Relation Propriété d’entité

37 ENTITE Choix ? Dans l'exemple,
l'entité Produit ∑ produits S.I.. et l'entité Commande ∑ commandes S.I. PRODUIT No Prod Désignation Prix Unitaire Nom de l’entité Propriété 1 Propriété 2 Propriété 3 Propriété 4 NOM Identifiant Attributs L'identifiant est une propriété (une ou plusieurs) particulière d'un objet telle qu'il n'existe pas deux occurrences de cet objet pour lesquelles cette propriété pourrait prendre une même valeur. Un identifiant est une colonne dont les valeurs permettent de repérer une seule ligne Le choix d'un identifiant correcte est très important pour la modélisation: Choix ?

38 Le modèle conceptuel des données propose de souligner les identifiants
Choix ? Comme choix pour l'identifiant d'une entité nous distinguons généralement 3 possibilités: Une propriété naturelle Exemple: Le nom d'un pays pour une entité Pays 2. Une propriété artificielle qui est inventée par le créateur du MCD Exemple: Le numéro d'un client pour une entité Client, Produit, Commande, … 3. Une propriété composée d'autres propriétés naturelles Exemple: Le nom et la localité pour une entité Entreprise Le modèle conceptuel des données propose de souligner les identifiants

39 Attributs caractéristiques des entités obligatoires ou facultatives
avec un domaine (type) de valeurs CLIENT VEHICULE Personnes No Nom Adresse No_Matric. Marque Modèle Année Cylindrée ID_Personne Nom Prénom Sexe Adresse Qu'est ce qu'un bon schéma Entité-Relation (« formes normales ») ? ni perte d'information ni redondance contraintes (d’intégrité) entre les valeurs des attributs le but: indépendance / applications (vues particulières)

40 Associations ou Relations
Personnes Diplômes Obtenir ID_Personne Nom Prénom Sexe Adresse Téléphone Code_diplôme Titre_diplôme Abréviation Année_d_obtention CLIENT No Nom Adresse CONTRAT Type Date VEHICULE Marque Modèle Année Cylindrée APPARTIENT SIGNE

41 MCD La notion de relation Relation binaire Relation ternaire
Une relation décrit un lien entre deux ou plusieurs entités. Chaque relation possède un nom, qui est généralement constitué par un verbe à l'infinitif. Chaque relation a implicitement un identifiant, qui est composé par les identifiants des entités auxquelles elle est liée. Passer CLIENT Numéro Nom Prénom Adresse Code_postal Localité Commande Date Quantité MCD Relation binaire Déverser LAC RIVIERE Décharge Relation ternaire Relation réflexive EMPLOYE N° Matricule CONJOINT (relation récursive)

42 Cardinalité Les cardinalités précisent la participation de l'entité concernée à la relation. cardinalité minimale cardinalité maximale 1, N 1,1 CLIENT Numéro Nom Prénom Adresse Code_postal Localité Passer Commande Numéro Date Quantité Entre l'entité CLIENT et la relation Passer, nous avons les cardinalités suivantes: * Cardinalité minimale = 1, ce qui veut dire que chaque client passe au moins une commande. * Cardinalité maximale= N, ce qui veut dire que chaque client peut passer plusieurs (N) commandes. Entre l'entité Commande et la relation Passer, nous retrouvons les cardinalités suivantes: * Cardinalité minimale = 1, donc chaque commande est passée par au moins un client. * Cardinalité maximale =1, chaque commande est passée au maximum par un seul client.

43 Autres exemples 1,N 0,N COMMANDE PRODUIT
No Cde Date Cde 0,N PRODUIT No Prod Désignation Prix Unitaire CONCERNER Quantité Cdée Une occurrence de commande est concernée au moins 1 fois. Une occurrence de commande peut être concernée plusieurs (N) fois. Une occurrence de produit peut ne pas être concernée (0). Une occurrence de produit peut être concernée plusieurs (N) fois. Utiliser 0,N 1,N Employé Numéro Nom Prénom Adresse Code_postal Service Ordinateur Numéro_PC Type Configuration Entre l'entité Employé et la relation Utiliser, nous avons: ·   Cardinalité minimale = 0 Certains employés n'utilisent pas d'ordinateur ·   Cardinalité maximale = N Entre l'entité Ordinateur et la relation Utiliser, nous avons: ·    Cardinalité minimale = 1 ·       Cardinalité maximale =N

44 1,1 : Un COUREUR Provient au min d’1 PAYS et au max d’1 PAYS.
Un COUREUR Provient d’un et d’un seul PAYS. un plusieurs plusieurs 0,n : Un PAYS est représenté au min par 0 COUREUR et au max n. Un PAYS est représenté par aucun ou plusieurs COUREURS. plusieurs

45 ! CONFIGURATIONS POSSIBLES :
0, Une occurrence participe au moins 0 fois et au plus 1 fois à l’association 1, Une occurrence participe exactement 1 fois à l’association 0,N Une occurrence peut ne pas participer ou participer plusieurs fois 1,N Une occurrence participe au moins 1 fois, voire plusieurs  Le fait d'indiquer pour cardinalité minimale '1' implique une contrainte forte : elle signifie qu'une entité ne peut exister indépendamment d'une autre. De telles entités sont dites ''faibles'' . ! Insistons sur le point suivant : les cardinalités n'expriment pas une vérité absolue, mais des choix de conception. Ils ne peuvent être déclarés valides que relativement à un besoin. Plus ce besoin sera exprimé précisément, et plus il sera possible d'apprécier la qualité du modèle.

46 RELATIONS Optionnelles
Les cardinalités, du point de vue de l'association, dans une interprétation ensembliste  RELATIONS OBLIGATOIRES Notation E-A Explication Relation ensembliste 1,1 <-> 1,1 TOUTE occurrence de A a un homologue UNIQUE parmi les occurrences de B et réciproquement ???? 1,N <-> 1,N TOUTE occurrence de A a AU MOINS un homologue parmi les occurrences de B et réciproquement RELATIONS Optionnelles Notation E-A Explication Relation ensembliste 0,N <-> 0,1 UNE occurrence de A peut avoir 0,1,N vis-à-vis.  UNE occurrence de B est limitée à 0 ou 1 homologue 1,N <-> 0,N TOUTE occurrence de A a AU MOINS un homologue.  Mais UNE occurrence de B peut ne pas en avoir, en avoir 1 ou plusieurs. 

47 Exercice 0: Cardinalités?
CLIENT APPARTIENT No Nom Adresse SIGNE 0-N 1-1 1-N CONTRAT No Type Date VEHICULE No Marque Modèle Année Cylindrée ACCIDENT CONCERNE No Date (Montant)

48 Exercice 1: Laquelle des deux modélisations est correcte ?
Passer 1,N 1,1 CLIENT Numéro Nom Prénom Adresse Code_postal Localité Commande Date Quantité Passer 0,N 1,1 CLIENT Numéro Nom Prénom Adresse Code_postal Localité Commande Date Quantité Une commande est toujours passée par au moins un client. Une commande est également passée au maximum par un client. Une commande est donc toujours passée par un et un seul client. Un client passe au moins une commande et au maximum plusieurs (N) commandes. Cette modélisation ne tient pas compte des clients qui ne passent aucune commande. Un client est uniquement considéré comme tel s'il passe au moins une commande Un client peut passer aucune commande et au maximum plusieurs (N) commandes. Cette modélisation tient compte des clients qui ne passent aucune commande.

49 Exemple CLIENT Numéro Nom Prénom Adresse Code_postal Localité Disposer Carte_Membre No_Carte Type_Abonnement Date_création 0,N 1,1 On dit que CLIENT est l'entité indépendante par rapport à l'association Disposer, tandis que Carte_Membre est l'entité dépendante. Une occurrence d'un client peut très bien exister sans carte de membre, mais une carte de membre ne peut pas exister sans client. ! La cardinalité minimale indique donc quelle entité est indépendante(0) et quelle entité est dépendante(1). On dit qu'une entité est indépendante par rapport à une relation lorsque sa cardinalité minimale vaut 0. Une relation ne peut pas être liée uniquement à des entités dépendantes qui ont une cardinalité maximale de 1. !

50 ! La modélisation suivante par exemple n'est pas correcte !!!
CLIENT Numéro Nom Prénom Adresse Code_postal Localité Carte_Membre No_Carte Type_Abonnement Date_création Disposer 1,1 1,1 ! Dans ce cas, il faut réunir les propriétés des deux entités dans une seule.

51 Exercice 2 Voici le résultat simplifié d'une analyse faite auprès d'une compagnie d'assurance qui désire informatiser la gestion des contrats auto. ·     Un client peut assurer plusieurs voitures auprès de la compagnie. Chaque voiture est assurée par un seul contrat. Un contrat assure une seule voiture. ·    En ce qui concerne un client, la compagnie désire connaître son nom, prénom, adresse complète, numéro de téléphone ainsi qu'un numéro de compte bancaire avec indication de la banque. ·    Chaque contrat contient un numéro de contrat unique, la prime annuelle à payer, la date de paiement annuel, la marque de la voiture, le modèle de la voiture, le numéro d'immatriculation de la voiture, la valeur de la voiture et la date d'acquisition de la voiture.

52 Visites dans un centre médical
1,1 0,N Medecin Marticul Nom Patient No_SS Mutuelle Medicament Code Libelle Prescrit Nb Prises Donner Assister 1,N Consultation No_Cons Date Oui Non Un patient peut-il effectuer plusieurs visites? Un médecin peut-il recevoir plusieurs patients dans la même consultation? Peut-on prescrire plusieurs médicaments dans une même consultation? Deux médecins différents peuvents-ils prescrire le même médicament.

53 désire informatiser son système de facturation. Les factures devraient
Exercice 3 " LabDB " Obtenir 1,N 1,1 CLIENT No_Client Nom Prénom Adresse Code_postal Localité Facture No_Facture Date Montant La société "LabDB" désire informatiser son système de facturation. Les factures devraient se présenter de la façon suivante:  Créez un MCD, qui permet de modéliser correctement le système d'information nécessaire, sachant que: ·  Un client peut bien sûr recevoir plusieurs factures, mais il est uniquement considéré comme tel à partir du moment ou il reçoit sa première facture. ·  Une facture concerne un et un seul client. PARTIE 1 LabDB SPRL Facture No. 0001 5, avenue SGBD 7000 FPMs Mons, le Client Nom  : Nom_Client Prénom  : Pre_Client Adresse  : Serv. Info, 15 Code_postal : Localité  : Mons Montant de la facture : €

54 la facture devrait avoir:
PARTIE 2 Le responsable de la facturation de la société désire rendre les factures plus informatives. Comme un client peut acheter plusieurs articles différents en même temps, la facture devrait indiquer pour chaque article le numéro , un libellé, le prix unitaire, la quantité vendue et le prix total pour ce type d'article. la facture devrait avoir: LabDB SPRL Facture No. 0002 5, avenue SGBD 7000 FPMs Mons, le Voici l'aspect que la facture devrait avoir: Client Nom  : Nom_Client Prénom  : Pre_Client Adresse  : Serv. Info, 15 Code_postal : Localité  : Mons Proposez un nouveau MCD qui reflète ces modifications, en respectant le fait que tous les articles disponibles sont stockés (p.ex. No=233 Libellé="Analyse" PU=1000 €). Même si un article n'est pas encore considéré par une facture, il existe dans le système d'information. No. Article Libellé Prix unitaire Quantité Prix 233 Analyse 1000 € 1 025 MCD 700 € 2 1400 € 142 MLD Montant total de la facture : €

55 ! Solution de l’exercice " LabDB " PARTIE 1 PARTIE 2 Remarque:
PARTIE 1 Obtenir 1,N 1,1 CLIENT No_Client Nom Prénom Adresse Code_postal Localité Facture No_Facture Date Montant Remarque: No_Client en + ⊵ propriété artificielle définit comme identifiant. Sinon il faut définir un identifiant composé de +ieur propriétés. Obtenir 1,N 1,1 CLIENT No_Client Nom Prénom Adresse Code_postal Localité Facture No_Facture Date Porter 0,N Article No_Article Libellé Prix_Unitaire Quantité PARTIE 2 Remarque: L'entité Facture ne contient plus la propriété Montant. Il existe une règle générale de conception qui dit: Aucune propriété qui peut être calculée à partir d'autres propriétés existantes ne devra être stockée dans le MCD. !

56 Exercice 4 : Structure administrative
On considère un sous-ensemble d’une structure administrative. D’une direction (caractérisée par un nom unique et le nom de son PDG) dépendent plusieurs départements (dotés chacun d’un nom unique dans sa direction et du nom de son directeur). Un département est découpé en services, ayant un nom (unique dans son département) et un responsable. Un service a la charge d’un certain nombres de dossiers (identifiés par un numéro et dotés d’un titre, d’une date et d’une description). Dans chaque service travaillent des employés identifiés par un numéro et caractérisés par leur nom et leur adresse.

57 Structure administrative
DIRECTION dir-dép Nom PDG 0-N 1-1 DEPARTEMENT dép-serv Nom_Dep Directeur 0-N 1-1 SERVICE Nom_Serv Responsable traite travaille 0-N 0-N 1-1 1-1 DOSSIER PERSONNE No_Dos Titre Date Description No_Pers Nom Adresse

58 Peut – il devenir comme cela ?
Entité Nom Responsable traite travaille 0-N 0-N 1-1 1-1 DOSSIER PERSONNE No_Dos Titre Date Description No_Pers Nom Adresse

59 Notion de dépendance fonctionnelle
Une dépendance fonctionnelle (df) existe lorsqu'un ensemble d'attributs détermine parfaitement un autre ensemble d'attributs. Pour une table T(relation R), un attribut Y de T dépend fonctionnellement d ’un attribut X de T ssi chaque valeur de X est associée a une et une seule valeur de Y X  Y Ex: {Nom, Tel.} définit {ID} {Nom, Prénom}  {Adresse,Sexe,Téléphone, } //Vrai s’il n’y a pas de problème d’homonymie Les formes normales 2NF, 3NF et BCNF sont basées sur des contraintes en relation avec la notion de dépendance fonctionnelle.

60 Notion de dépendance fonctionnelle
Considérons l’entité suivante et quelques une de ses occurrences : Cette entité est juste mais elle implique une redondance d’information relative à la catégorie. L’association entre le numéro de la catégorie et son libellé est en effet répétée dans chaque occurrence de l’entité ARTICLE.

61 Normalisation Le processus de normalisation du modèle relationnel à pour objectif d’établir une meilleure représentation conceptuelle des données d’une application par des tables relationnelles. Cela consiste, essentiellement, à décomposer les tables (entités, relations) contenant trop d’informations en tables (E/R) plus petites. Un mauvais schéma relationnel pouvant entraîner des anomalies lors des manipulations. Définition: Le processus de Normalisation permet, par étapes, d'aboutir à des relations ayant les bonnes propriétés. 1 FN (Codd, 1971) 2 FN (Codd, 1971) 3 FN (Codd, 1971) BCFN (Boyce, Codd, 1971) 4 FN (Fagin, 1977) 5 FN (Fagin, 1979) On peut mesurer la qualité d’une relation par son degré de normalisation. Ainsi, au plus une relation appartient à une forme normale avancée, au plus sa qualité augmente. FN=Forme Normale.

62 Normalisation NORMALISATION   Programmation plus facile des applications  Relations plus simples à gérer Normaliser un schéma relationnel c'est le remplacer par un schéma équivalent où toutes les relations vérifient certaines propriétés. Ces propriétes sont basées sur l'analyse des dépendances fonctionnelles à l intérieur de chaque relation. La normalisation permet de: - éviter les redondances (perte de place et incohérences) - minimiser l’espace de stockage - éviter les problèmes de mises à jour.

63 Normalisation 1FN Définition: Une relation est en Première Forme Normale (1FN) si et seulement si elle ne contient que des valeurs simples et élémentaires (si tout attribut est atomique= non décomposable ). Personnes Nom Adresse Picsou 9, rue de Houdain, 7000 Mons Non 1FN ID_Personne Adresse Nom Rue CP Ville Picsou 9 Houdain 7000 Mons En 1FN PERE ENFANT P1 Enf11 Enf12 Enf13 P2 Enf21 Enf22 Non 1FN PERE ENFANT P1 { Enf11, Enf12, Enf13 } P2 { Enf21, Enf22, Enf23 } En 1FN

64 COMMANDE PRODUIT PRIX en € Cd1 Bureau 50 Chaise 49 Ecran 199 Cd2
Normalisation Exercice: Normaliser la relation COMMANDE COMMANDE PRODUITS Cd1 { Bureau 50€, Chaise 49€ , Ecran 199€ } Cd2 { Ecran 199€, Souris 19€ } COMMANDE PRODUIT PRIX en € Cd1 Bureau 50 Chaise 49 Ecran 199 Cd2 Souris 19 Solution:

65 Normalisation 2FN et 3FN Une relation est en 2FN si elle est en 1FN et si tout attribut n’appartenant pas à la clé dépend totalement et non-partiellement de la clé. On dit alors que chaque attribut est en dépendance irréductible avec la clé. C’est la phase d’identification des clés. Cette étape est très importante vu qu’elle évite de nombreuses redondances. ( 2FN: 1FN + si tous les attributs qui ne participent à aucune clé pour l'entité, sont des attributs d'entités et non pas d'autres entités.) (2FN: 1FN + toute colonne qui n'appartient pas à une clé dépend pleinement de la clé et ne peut se déduire d'un sous-ensemble de cette clé. ) Une relation est en 3FN si elle est en 2FN et si tous les attributs qui n’appartiennent pas à la clé primaire sont mutuellement indépendants. Ceci correspond à la non transitivité des dépendances fonctionnelles et permet d’éviter les redondances. La forme 3FN implique que chaque attribut peut être mis à jour indépendamment des autres. 3FN si: Elle est en 2FN, Il n’existe aucune DF entre deux attributs non clé primaire (tout attribut n'appartenant pas à une clé ne dépend pas d'un attribut non-clé.)

66 2e ET 3e FORME NORMALE Picsou Disney Pas de sous 10 € 3/10/99 12 €
Normalisation 2e ET 3e FORME NORMALE Exemple : Soit la relation concernant des dons de bienfaiteurs pour une association. Nom Ville Rue Montant Date Picsou Disney Pas de sous 10 € 3/10/99 12 € 13/1/01 30 € 23/7/03 Donald Bcp de sous 500€ 15/6/05 redondance Supposer Picsou change d'adresse (VILLE = Mons, RUE = Houdain). Risque de ne pas corriger toutes les lignes concernées. D'où BD incohérente • Difficulté maintenance intégrité.

67 «Le Bon Attribut au Bon Endroit»
Normalisation Problème dit «Anomalies de Mise à Jour»: Cause: Les Redondances d'informations sont sources d'Incohérences Solution: On aurait aimé la structure suivante: PERSONNE DONS Nom Ville Rue Picsou Disney Pas de sous Donald Bcp de sous Nom Montant Date Picsou 10 € 3/10/99 12 € 13/1/01 30 € 23/7/03 Donald 500€ 15/6/05 • L'adresse de Picsou figure une seule fois. • On a séparé des informations distinctes (sur la personne, sur les dons). «Le Bon Attribut au Bon Endroit»

68 Normalisation du schéma - élimination des redondances internes 1 fait
1 donnée DEPARTEMENT IdDepart Localisation EMPLOYE NumEmp Nom dépend 1-1 0-N Localisation ne dépend que de DEPARTEMENT 2FN EMPLOYE NumEmp Nom DEPARTEMENT Localisation

69 Soit la table décrivant des fournisseurs d'une société
Normalisation Autre Exemple : Soit la table décrivant des fournisseurs d'une société NOM_FOUR VILLE CD_POSTAL PIECE QTE_EXP F1 Mons 7000 Bureau 300 Ecran 500 Armoire 20 F2 Charleroi 6000 600 F3 Keumiée 5060 FOUR1 deux tables distinctes : fournisseur (info fournisseur) pièces fournies. Quelques anomalies: • Redondances. • Difficulté de maintenance. • Mémoriser l’adresse fournisseur impossible si pas de pièce fournie. e.g. <F4, Mons, 7000> • Suppression de toutes les pièces fournies par F2, fait perdre aussi son adresse.

70 On décompose donc (PROJECTION)
Normalisation On décompose donc (PROJECTION) NOM_FOUR VILLE CD_POSTAL PIECE QTE_EXP F1 Mons 7000 Bureau 300 Ecran 500 Armoire 20 F2 Charleroi 6000 600 F3 Keumiée 5060 FOUR1 EXPEDITION 2FN NOM_FOUR PIECE QTE_EXP F1 Bureau 300 Ecran 500 Armoire 20 F2 600 F3 FOUR2 NOM_FOUR VILLE CD_POSTAL F1 Mons 7000 F2 Charleroi 6000 F3 Keumiée 5060 F4

71 (on a pu insérer F4... par exemple).
Normalisation • Dans la relation FOUR1, des attributs non clé (e.g. VILLE), «dépendaient» d'une partie de la clé (NOM_FOUR). • Les anomalies précédentes ont ainsi été éliminées, renforçant l'intégrité de la base. (on a pu insérer F4... par exemple). En fait, les redondances ont juste été minimisées. Car la relation FOUR2 souffre encore de quelques anoma1ies. Exercice: Lesquelles? Considérer toujours le tuple supplémentaire <F4, ..., Mons, 7000> FOUR2 NOM_FOUR VILLE CD_POSTAL F1 Mons 7000 F2 Charleroi 6000 F3 Keumiée 5060 F4

72 • On décompose encore la relation FOUR2
Normalisation • On décompose encore la relation FOUR2 FOUR3 3FN COMMUNE NOM_FOUR VILLE F1 Mons F2 Charleroi F3 Keumiée F4 VILLE CD_POSTAL Mons 7000 Charleroi 6000 Keumiée 5060 On dit qu'on est passé à la 3e Forme Normale Dans la relation FOUR2, des attributs non clé (e.g. CD_POSTAL), «dépendaient» d'un autre attribut non clé ( ici VILLE) . Il n'y a plus de redondances RÉSULTAT FINAL: FOUR3 COMMUNE EXPEDITION NOM_FOUR VILLE VILLE CD_POSTAL NOM_FOUR PIECE QTE_EXP

73 Deuxième forme normale (2FN)!!!
Normalisation Exces : Deuxième forme normale (2FN)!!! Une relation est en 2FN si: Elle est en 1FN, Tout attribut, non clé primaire, est dépendant de la clé primaire. Exemple de relation en 1FN mais pas en 2FN: Pourquoi? Projet NumProjet NumEmployé Fonction NomEmployé Problèmes - on ne peut enregistrer un employé que s'il participe à un projet - si un employé participe à plusieurs projets, on doit répéter les informations sur cet employé (redondance et problèmes de m-à-j) Une solution peut être proposée qui consiste à extraire la dépendance fonctionnelle: 1. On créé une nouvelle relation contenant l'attribut déterminé par une partie de la clé primaire 2. La clé primaire de la nouvelle relation est cette partie de la clé Employé NumEmployé NomEmployé Projet NumProjet NumEmployé Fonction NumEmployé est à la fois clé primaire et clé externe dans Projet

74 Pourquoi? Pourquoi? Pourquoi?
Normalisation On peut aussi étudier d'autres relations comme: CLIENT N°client nom prénom date de naissance rue ville Cette relation est en 2FN par contre la suivante n'est pas en 2FN. COMMANDE_PRODUIT N°produit quantité N°fournisseur ville Pourquoi? Pourquoi? Relation en 2FN mais pas en 3FN Employé NumEmployé NomEmployé NumService NomService Pourquoi? Un autre exemple: COMPAGNIE Vol Avion Pilote

75 Contraintes d’intégrité
Après MLD Le modèle d'une base de données relationnelle implique, par sa conception, un certain nombre de contraintes d'intégrité (C. I. ) qui traduisent les propriétés sémantiques des données : Intégrité de domaine : concerne le contrôle des valeurs des attributs, le contrôle entre valeurs des attributs ainsi que le contrôle des opérateurs entre attributs.  Contraintes d’intégrité statiques :  utilisant le mot réservé CHECK Le concepteur peut également définir ses propres domaines : CREATE DOMAIN Domaine_Sexe CHAR(1) CHECK (VALUE IN (‘M’, ‘F’)) ; Intégrité de clé primaire : la contrainte de clé primaire d'une relation implique la non duplication des lignes, c'est-à-dire que chaque objet du monde réel peut être enregistré sans ambiguïté par une seule ligne, un seul "tuple"; - on peut ajouter à une colonne la contrainte de non-nullité qui implique que cette colonne ne peut pas avoir de valeur nulle, c'est-à-dire ne peut pas être indéfinie ou inutilisable; Les contraintes de domaine et de non-nullité sont gérées en langage SQL, lors de la création de la table.

76 C. I. Intégrité de référence :
L’intégrité de référence (ou intégrité référentielle) est un ensemble de contraintes contrôlant les dépendances et indépendances des relations. Elle concerne principalement l’intégrité des clés étrangères dont les valeurs sont ‘NULL’ ou des valeurs de la clé primaire. L’objectif des clés étrangères étant de repérer un enregistrement dans différents espaces, des contraintes d’intégrité référentielle doivent assurer la validité des références entre tables. L’intégrité référentielle signifie qu’il n’y a pas de valeurs de clés étrangères invalides. Pour cela, il faut donc prendre des décisions quant à la suppression ou la modification de la cible que référence la clé étrangère. FOREIGN KEY Nom_Clé REFERENCES Nom_Table [ON DELETE option] [ON UPDATE option]

77 C. I. Intégrité de relationnelle :
L’intégrité relationnelle contrôle la sémantique et gère les contraintes de type if…then… Voici l’exemple d’une règle d’intégrité qui assure la suppression du numéro de téléphone d’une personne décédée. CREATE INTEGRITY RULE Règle_Décès FORALL Personnes (IF Personnes.Décédé = True THEN Personnes.Téléphone = NULL) ON ATTEMPTED VIOLATION Reject ;

78 Contraintes d’intégrité fonctionnelle
Les contraintes d’intégrité fonctionnelles (CIF) contrôlent la détermination absolue d’une entité participant à une association du modèle conceptuel par une ou plusieurs autres participant à la même association. Ce type de contrainte permet donc d’identifier les dépendances entre entités. Les CIFs ne doivent pas être confondues avec les dépendances fonctionnelles, qui permettent de déterminer les dépendances qui existent entre deux groupes d’attributs au sein d’une même relation L’identification des CIFs permet de corriger certaines erreurs de conception de bases de données relationnelles. En effet, si la connaissance d’une ou plusieurs entités d’une association conduit à la détermination complète d’une autre entité participant à la même association, on peut considérer qu’il y a redondance d’information dans le modèle.

79 CIF N Personnes Diplômes CIF 0 N Universités
N Obtenir Année_d_obtention N Personnes Diplômes CIF ID_Personne Nom Prénom Sexe Adresse Téléphone Code_diplôme Titre_diplôme Abréviation 0 N Universités Code_université Nom_université Abréviation Si on imagine re-normaliser les diplômes de telle manière que chaque université possède l’exclusivité du diplôme qu’elle délivre, dans ce cas, la connaissance du diplôme implique celle de l’université. Il y a donc une contrainte d’intégrité fonctionnelle entre l’entité Diplômes et l’entité Universités. Personnes N Obtenir Année_d_obtention Universités Diplômes Délivrer 1

80 Trouver un MCD équivalent à ce MCD :
CIF Trouver un MCD équivalent à ce MCD : Camion No_Camion 1,1 0,N Mois Activité 0,N Conduire Cumul Nb H d’activité Chauffeur Matri_Chauf. 1,N 0,N Activité Cumul Nb H d’activité Chauffeur Matri_Chauf. Camion No_Camion Conduire Mois 1,1 1,N 0,N Un camion n’ayant qu’un chauffeur, l’activité du chauffeur par camion est l’activité du camion

81 Relation binaire non porteuse de données avec 1,1 sur l’une des pattes
CIF Principe de simplification par les contraintes d’intégrité fonctionnelles Relation binaire non porteuse de données avec 1,1 sur l’une des pattes 1,1 2 Relation 4 3 Entité 2 Entité 1 CIF 1 ! On supprime la patte n°3. CONTRAINTE D'INTEGRITE FONCTIONNELLE Une Contrainte d'Intégrité Fonctionnelle (en abrégé : CIF) se définit par le fait que l'une des entités participant à l'association est complètement déterminée par la connaissance d'une ou plusieurs autres entités participant dans cette même association.

82   CIF Affecter Affecter Activité Activité 1,1 0,N 1,N 1,1 0,N 1,N
Chauffeur Matri_Chauf. Camion No_Camion Client N°Client Type de Client Type Activité Cumul Nb H d’activité Affecter 1,1 0,N 1,N Chauffeur Matri_Chauf. Camion No_Camion Client N°Client Type de Client Type Activité Cumul Nb H d’activité Affecter

83 Les associations transitives Considérons le modèle suivant :
CIF Les associations transitives Considérons le modèle suivant : L’association binaire qui relie l’entité « CONTRAT » et l’entité « PROPRIETAIRE» doit être ôtée du modèle car on peut retrouver le propriétaire à partir des associations « Concerner » et « Appartenir ». Il s’agit d’une association transitive.

84 Gestion FPMS_Etudiants
La FPMs veut ré-informatiser son système d'information qui gère les étudiants, Groupes d’étudiants (classes)(1er_A,... , 3eme_IG,…) . Sachant que : · Un étudiant est caractérisé par [no. matricule, nom, prénom, date de naissance, adresse, ]. · Une classe est caractérisée par le nom de la classe (p.ex 1er) et par une indication du groupe ou spécialité (P.ex : 1er_A, 4eme_Elec) ainsi que par le nombre d’étudiants qui la fréquente. · Un étudiant enregistré dans le système fréquente au moins une classe au cours des années. On désire également saisir tous les enseignants dans le système d'information. Un enseignant est caractérisé par un code interne (CodeProf) , nom, prénom, et la matière qu'il enseigne. Une matière (cours) peut être composée de cours, T.P. et Exercices. Chacun des modules présente un poids en pourcentage de la côte globale à l’examen. Un module peut être donné par un ou plusieurs enseignants. Une matière est représentée au moins par un code matière (p.ex. INF_B = Informatique de base, BD = Base de données, etc.) et un libellé complet qui exprime le terme général ( p.ex "Informatique" etc.).

85 Modélisez le fait que chaque classe soit enseignée chaque année par un ou plusieurs enseignants. Un enseignant peut bien sûr donner des cours (cours, Labo., Exercices) à plusieurs classes, enseigner plusieurs matières différentes pendant une ou plusieurs années, mais peut également ne pas donner de cours pendant une ou plusieurs années. ·    Exprimez aussi le fait que l’étudiant puisse suivre des cours en deux années différentes. ·   Exprimez la contrainte suivante : connaissant le code postal de l’étudiant, nous pouvons choisir parmi les localités, celle qui correspond à l’adresse de l’étudiant, ou connaissant la localité le code postal est capté automatiquement.

86 Le Modèle Logique des Données (MLD)
Analyse MCD MLD Réel Perçu Schéma Conceptuel Schéma Logique Définition Le niveau logique, qui se base sur le modèle conceptuel des données, introduit la notion des tables logiques, et constitue donc le premier pas vers les tables des SGBD. Passage du MCD au MLD Le passage du schéma conceptuel à la structure relationnelle (MLD) se fait facilement et obéit à certaines règles. Le MLD est toujours basé sur MCD. Un MLD est essentiellement composé de tables logiques reliées entre elles par des flèches…

87

88 Toute entité est transformée en table.
modèle conceptuel   modèle logique Entité Toute entité est transformée en table. Les propriétés de l'entité deviennent les attributs de la table. L'identifiant de l'entité devient la clé primaire de la table. Identifant Clé primaire EMPLOYE EMPLOYE (Mat, Nom, Fonc) Matricule Nom Fonction Propriété Attribut

89 Association ou relation
Notion Père_fils ou mère_fille Les relations du modèle conceptuel peuvent, sous certaines conditions, soit disparaître, soit devenir une table.

90 Porter dans la relation fille la clé primaire de la relation mère.
Relation un-à-plusieurs (participation totale) (1,1) (1,N) : (1,1) (0,N) Porter dans la relation fille la clé primaire de la relation mère. L'attribut ainsi ajouté s'appelle clé étrangère. Par convention, nous la symboliserons au moyen de #. Une clé étrangère est une colonne constituée de l’identifiant d’une autre table (et joue le rôle de référence à une ligne de cette table) (contrainte référentielle)

91 (1,1) - (0,N) : se fait comme une relation un-à-plusieurs normale.
DEPARTEMENT DEPARTEMENT Nom Adresse Nom Adresse 0-N Occupe 1-1 EMPLOYE EMPLOYE Matricule Nom Fonction Matricule Nom Fonction NomDpt

92 Relation plusieurs-à-plusieurs (1,N) - (1,N) : (0,N) - (0,N) :
CLIENT Cde Client Nom Adresse PRODUIT Référence Désignation Prix Unitaire COMMANDER Quantité CLIENT(CdCli, Nom, Adresse) PRODUIT(Ref, Des, Prix) COMMANDER(#CdCli, #Ref, Quant) Clé primaire Clés étrangères

93 0,N : La même règle s'applique
CLIENT Cde Client Nom Adresse PRODUIT Référence Désignation Prix Unitaire COMMANDER Quantité CLIENT PRODUIT CdCli Nom Adresse Ref Des Prix COMM CdCli Ref Qu

94 ! Relation un-à-un (1,1)—(1,1) :
L'une des entités devient un attribut de l'autre entité. Exemple : Client(No_Client, Nom, Adresse) Carte_Membre(No_Carte,Type_Abonnement) Deviennent: Client(No_Client, Nom, Adresse, #No_Carte,Type_Abonnement).

95 Idem que précédemment avec choix.
Disposer 0,1 1,1 CLIENT Numéro Nom Prénom Adresse Code_postal Localité Carte_membre No_Carte Type_Abonnement Date_création CLIENT NoClient Nom Prénom Adresse Cde_postal Localité Carte_membre No_Carte Type_Abonnement Date_création Disposer Relation (0,1) – (0,1) : Idem que précédemment avec choix. Si l’association contient elle même des propriétés, alors >>> ajouter avec la clé étrangère.

96 Pratiquer(#Nom-Med, #Cd-Acte, #NSS, Lieu)
DIMENSION SUPERIEURE A 2: Si la relation entre chacune des paires d'entités ne peut déterminer la troisième entité. Une table pour chacune des entités et une table pour la relation. Cette dernière possédera une clé primaire composée d'au moins trois champs. Médecin Acte 0-N 0-N Pratiquer Nom-médecin Adresse Code-acte Désignation Lieu 1-N Patient N°Sec.Soc Nom Medecin(Nom-Med, Adr) Acte(Cd-Acte, Des) Patient(NSS, Nom-Pat) Pratiquer(#Nom-Med, #Cd-Acte, #NSS, Lieu)

97 Résumé : A A-B B Relation binaire :
(1,1) – (1,N)  et (1,1) - (0,N) : A ( id_A, a1, a2, …, #id_B) (1,1) - (0,N) B ( id_B, b1,b2,…) (1,N) - (1,N) , (0,N) - (1,N) :  A ( id_A, a1, a2, …,) (0,N) - (0,N) B ( id_B, b1,b2,…) A-B (#id_A, #id_B, a-b,…) (1,1) - (1,1) : A ( id_A, a1, a2, …, id_B, b1,b2,…) (0,1)- (1,1) : A ( id_A, a1, a2, …) B ( id_B, b1,b2,…, #id_A) (0,1) – (0,1) : Idem que (0,1)- (1,1) avec choix du placement de la clé étrangère.

98 A-B-C (#id_A, #id_B, #id_C, a-b-c,…)
Relation ternaire -N -N A-B-C A B C -N A ( id_A, a1, a2, …,) B ( id_B, b1,b2,…) C ( id_B, b1,b2,…) A-B-C (#id_A, #id_B, #id_C, a-b-c,…)

99 EXCE :

100

101 Exercice "LabDB" Transformez le MCD suivant, qui représente la facturation de la société "LabDB" en un MLD en respectant toutes les règles du passage MCD à MLD. Obtenir 1,N 1,1 CLIENT No_Client Nom Prénom Adresse Code_postal Localité Facture No_Facture Date Porter 0,N Article No_Article Libellé Prix_Unitaire Quantité Obtenir CLIENT No_Client Nom Prénom Adresse Code_postal Localité Facture N°_Facture N°Client Date Article No_Article Libellé Prix_Unitaire Porter N° Facture Quantité

102 Exercice_Obélix La société Obélix et Compagnie fournit des menhirs dans le monde entier et gère les commandes à l’aide d’un micro-ordinateur. Exemple d’une commande: Obélix et Compagnie Livreur de menhirs Village gaulois Date commande: Nº commande: Nº client 012 Nom client: BISCORNUS Prénom: M. Adresse: BABAORUM Code Libellé Quantité Prix unitaire 12 MENHIR CLASSIC 2 500 21 MENHIR SE/ 25 MENHIR II FX Donner : Le MCD Les cardinalités et leur signification. Le Modèle des données.

103 Schéma Entité-Association
Rep_Obélix Schéma Entité-Association 0,N 1,1 CLIENT CLI_COM COMMANDE 1,N Signification: - Une commande est passée par un (1) client. - Un client peut passer plusieurs (N) commandes. - Une commande peut concerner plusieurs (N) produits. - Un produit peut intervenir dans plusieurs (N) commandes. COM_PRO 0,N PRODUIT L’association CLI_COM est du type (1,N). L’association COM_PRO est du type (N,N). Modèle des données CLIENT(NUM_CLI, NOM_CLI, PRE_CLI, ADR_CLI) COMMANDE(NUM_COM, DAT_COM, #NUM_CLI) PRODUIT(NUM_PRO, LIB_PRO, PRI_UNI) COM_PRO(#NUM_COM, #NUM_PRO,QTE_COM)

104 Modèle relationnel textuel : Client(NoClient, Nom, Prénom)
Commande (NoCde, DateCde, NoClient#) Produit(RefPdt, Désignation, Prix) Ligne(NoCde#, RefPdt#, Qté) Client Commande NoClient Nom Prénom NoCde DateCde NoClient# 1 Lassus Annick 100 14/04/2001 2 Mundubeltz Armelle 101 3 Chaulet Bernadette Produit Ligne RefPdt Désignation Prixen € NoCde# RefPdt# Qté VE45 Vélo 150 100 1 VE32 Kit 2 roues 30 VE21 Kit éclairage 15 101 2

105 CLIENT PRODUIT COMMANDE
NumClient Nom Ville 001 Albert Bruxelles 002 Francois Liège 003 Brabo Anvers NumPiece Descr. Cout 0001 Table 500 0002 Chaise 300 0003 Armoire 1.000 COMMANDE NumClient NumPiece Quantite 001 0002 3 002 1 0003 5 des relations existent entre les tableaux d ’une BD, ici: Albert de Bruxelles a commandé 3 chaises à 300 EUR

106 CLIENT 0-N 0-N 1-1 1-1 1-1 0-1 0-N 0-N (1-N) APPARTIENT NumCli Nom
Adresse SIGNE 0-N 0-N 1-1 CONTRAT 1-1 NumCtr Type Date VEHICULE 1-1 0-1 COUVERT NumVeh Marque Modèle Année Cylindrée 0-N 0-N ACCIDENT CONCERNE NumAcc Date (Montant) (1-N)

107 CLIENT NumCli Nom Adresse CONTRAT VEHICULE Numcli NumCtr Type Date NumVeh ... NumCli NumCtr ACCIDENT NumAcc Date (Montant) CONCERNE NumVeh NumAcc

108 Exemple - SQL create table VEHICULE ( NumVeh char (16) not null,
Marque char (30) not null, Modele char (30) not null, Annee decimal (4) not null, Cylindree decimal (6) not null, NumCli char (12) not null, Ncli char (12) not null, NumCtr decimal (8) not null, primary key (NumVeh), unique (Numcli, NumCtr), Foreign key (Numcli) references CLIENT, (Numcli, NumCtr) references CONTRAT ) create table CLIENT ( NumCli char (12) not null, Nom char (38) not null, Adresse char (60) not null, primary key (NumCli) ) create table CONTRAT ( NumCli char (12) not null, NumCtr char (8) not null, Type decimal (4) not null, Date date not null primary key (NumCtr) Foreign key (NumCli) references CLIENT )

109 create table ACCIDENT (
NumAcc char (10) not null, Date date not null, Montant decimal (6), not null, primary key (NumAcc)) create table CONCERNE ( NumVeh char (16) not null, NumAcc char (10) not null, primary key (NumVeh, NumAcc), foreign key (NumVeh) references VEHICULE, foreign key (NumAcc) references ACCIDENT)

110 Access

111

112 SQL S.Q.L. « Structured Query Language », "langage structuré de requête" est un langage pour interroger et gérer les bases de données relationnelles. Il permet de créer, modifier et sélectionner des données. Le SQL peut se diviser en trois parties: DDL (data definition language), sert à définir la structure: créer, modifier, effacer... DML (data manipulation language), sert à manipuler les données: choisir, ajouter, effacer des tuples. DCL (data control language), sert à contrôler l'accès à l'information.

113 CREATE INDEX Création d'un index CREATE VIEW Création d’une vue
On retrouve dans le DDL les commandes principales suivantes: CREATE TABLE Création d'une table CREATE INDEX Création d'un index CREATE VIEW Création d’une vue ALTER TABLE Modification de la structure DROP TABLE Effacement d'une table  On retrouve dans le DML les commandes principales suivantes: INSERT Insérer un tuple UPDATE Modifier un tuple DELETE Effacer un tuple SELECT Choisir un ensemble de tuples

114 Il existe de plus des fonctions:
De tri (ORDER BY) et de regroupement (GROUP BY) arithmétiques, mathématiques et statistiques (moyenne, maximum, minimum, etc.) logiques (UNION, INTERSECTION, etc.) etc. Les données sont définies selon des types (entier,caractères, date,etc.). Types de données SMALLINT entier (16 bits) INTEGER entier (32 bits) DECIMAL (m,n) décimaux de m chiffres (dont n après la virgule) FLOAT réels flottants CHAR (n) chaîne de n caractères VARCHAR chaîne variable d’au plus n caractères DATE dates (année, mois et jour) TIME instants (heure, minute, seconde)

115 On peut aussi inclure dans la définition des attributs des mots de contrôle pour forcer la saisie.
Par exemple: NOM CHAR(20) NOT NULL définit une variable "NOM" qui sera constituée d'un champs de 20 caractères auquel on devra obligatoirement attribuer une valeur si on désire ajouter un tuple contenant cet attribut.

116 Exercice "LabDB" CLIENT Facture CLIENT Facture Article Article
Obtenir 1,N 1,1 CLIENT No_Client Nom Adresse Facture No_Facture Date Porter 0,N Article No_Article Libellé Prix_Unitaire Quantité Obtenir 1,N 1,1 CLIENT No_Client Nom Boite_Post Rue Code_postal Localité Facture No_Facture Date Porter 0,N Article No_Article Libellé Prix_Unitaire Quantité

117 Obtenir CLIENT Facture Article CLIENT Facture Porter Article
1,1 CLIENT No_Client Nom Boite_Post Rue Code_postal Localité Facture No_Facture Date Porter 0,N Article No_Article Libellé Prix_Unitaire Quantité CLIENT No_Client Nom Boite_Post Rue Code_postal Localité Facture N°_Facture #N°Client Date Porter N° Facture No_Article Quantité Article No_Article Libellé Prix_Unitaire

118 Aperçu des opérations les plus courantes
create table Création d’une table CREATE TABLE Client ( No_Client CHAR (4), Nom CHAR (12), Bte_Post INTEGER, Rue CHAR(30), Code_P INTEGER, Localite CHAR (20) ); CLIENT No_Client Nom Boite_Post Rue Code_postal Localité

119 Identifiant not null CREATE TABLE Client (
No_Client CHAR (4) NOT NULL, Nom CHAR (12), Code_P INTEGER, Localite CHAR (20), PRIMARY KEY (No_Client) ); primary key CLIENT No_Client Nom Boite_Post Rue Code_postal Localité

120 Clé étrangère foreign key CREATE TABLE Porter(
No_Facture CHAR (8) NOT NULL, No_Article CHAR (8) NOT NULL, Quantité INTEGER, PRIMARY KEY (No_Facture, No_Article), ); Facture N°_Facture #N°Client Date Porter N° Facture No_Article Quantité FOREIGN KEY (No_Facture) REFERENCES Facture, FOREIGN KEY (No_Article) REFERENCES Article Article No_Article Libellé Prix_Unitaire foreign key Clé étrangère

121 Ajouter une colonne à une table
ALTER TABLE Client ADD Prenom CHAR(25); Détruire une table DROP TABLE FOURNISSEUR; CLIENT No_Client Nom Prenom Boite_Post Rue Code_postal Localité Créer un index CREATE INDEX PR-Cli1 ON Client (Localite); Détruire un index DROP INDEX PR-Cli1

122 Consultation d’une BD SELECT Nom, Localite
précise les valeurs (colonnes, valeurs calculées) qui constituent chaque ligne du résultat FROM Client indique les tables desquelles le résultat tire ses valeurs WHERE Localite = ‘Charleroi’ donne la condition de sélection que doivent satisfaire les lignes qui fournissent le résultat

123 Manipulation des données :
Sélection de tous les attributs: SELECT * FROM Client; Sélection de certains attributs: SELECT Nom, Prenom FROM Client; Sélection de certains attributs et tuples: SELECT Nom, Code_P FROM Client WHERE Code_P < 7000 AND …; Sélectionner le nom de tous les Clients qui vivent à Mons: SELECT Nom FROM Client WHERE VILLE= ‘MONS’;

124 Extraction SELECT ID_Personnel, Nom, Code_Postal FROM Client

125 Extraction SELECT * FROM Client

126 Extraction SELECT ID_Personnel, Nom, Code_Postal FROM Client
WHERE Nom = ‘Bros’

127 SELECT DISTINCT Localite FROM Client WHERE Categorie = ‘1’
Le DISTINCT permet d'obtenir une liste qui ne contient qu'une fois chaque Localite. DISTINCT AVANT SELECT DISTINCT Localite FROM Client WHERE Categorie = ‘1’ APRES SANS DISTINCT APRES AVEC DISTINCT

128 Conditions de sélection
and or not () Conditions de sélection SELECT TableClient.Nom, TableClient.compte FROM TableClient WHERE (((TableClient.Localite)='Charleroi') AND ((TableClient.compte)>=0)); Access SELECT Nom, Compte FROM Client WHERE Localite = ‘Charleroi’ AND Compte >= 0

129 EXCE : Trouver les N°_Com avec leur date de tous les Clients de Charleroi.
Facture N°_Facture #N°Client Date

130 Sous-requêtes SELECT No, Date AVANT FROM Commande WHERE NoClient in
Facture N°_Facture #N°Client Date Sous-requêtes SELECT No, Date FROM Commande WHERE NoClient in (SELECT No FROM Client WHERE Localite = ‘Charleroi’) AVANT

131 EXCE : Trouver les noms de tous les fournisseurs qui vendent la pièce numéro 2. Rep : SELECT NOM FROM FOURNISSEUR WHERE NOFOUR IN (SELECT NOFOUR FROM ASSOCIATION WHERE NOPCE=2); Le IN signifie inclus dans. Il existe une autre méthode : JOIN Pour comprendre les requêtes (ou query) imbriquées, il faut exécuter d'abord la requête entre parenthèses.

132 Les clients qui habitent dans la même localité que le client n°2
SELECT * FROM Client WHERE Localite IN ( SELECT Localite WHERE Client.No = ‘3’)

133 Différents opérateurs Différentes fonctions
= IN NOT IN CONTAIN DOES NOT CONTAIN COUNT SUM AVG MIN MAX COUNT(*) nombre de lignes trouvées AVG(colonne) moyenne des valeurs de la colonne SUM(colonne) somme des valeurs de la colonne MIN(colonne) minimum des valeurs de la colonne MAX(colonne) maximum des valeurs de la colonne On peut également se servir de mots de contrôle tels: BETWEEN, NULL, LIKE, EXISTS, IN, ALL, SOME, etc..

134 Données calculées et duplication de lignes
distinct nombre de commandes ??? SELECT COUNT (NoClient) FROM Commande nombre de commandes !!! APRES 9 SELECT COUNT (DISTINCT NoClient) FROM Commande nombre de commandes !!! APRES 6

135 Mise à jour : Suppression :
UPDATE ASSOCIATION SET PRIX=23 WHERE NOPCE=5 AND NOFOUR="ZZ"; Dans la table ASSOCIATION pour tous les enregistrements dont le NOPCE=5 et NOFOUR=ZZ, la colonne PRIX sera mise à 23. Suppression : DELETE FOURNISSEUR WHERE NOFOUR="ZZ"; Dans la table FOURNISSEUR supprime l'enregistrement dont NOFOUR=ZZ. Il faut s'assurer que ce fournisseur n'est pas utilisé dans la table ASSOCIATION.

136 Création : (NOPCE,NOFOUR,PRIX) VALUES(1,"KK",10);
INSERT INTO ASSOCIATION (NOPCE,NOFOUR,PRIX) VALUES(1,"KK",10); Crée dans la table ASSOCIATION un enregistrement en assignant des valeurs aux colonnes.


Télécharger ppt "de la théorie à la pratique Faculté Polytechnique de Mons"

Présentations similaires


Annonces Google