Master2-Module Libre الدرس مفصل sgbdr Année universitaire 2016-2017 Ens:Graini-a

Plan Généralités Modélisation Contraintes d’intégrité Définitions Propriétés des SGBD Modélisation Le Modèle Conceptuel de Données (MCD) Le Modèle Relationnel (MR) Passage du MCD au Modèle Relationnel Contraintes d’intégrité Langage de requêtes SQL Normalisation des relations - 2 -

Définitions Base de données : Ensemble de données qui modélisent une partie du monde réel pour une application informatique. Système de Gestion de Base de Données (SGBD) : Outil qui permet d’insérer, modifier, retirer et rechercher des données ; le tout de façon efficace. Interface entre les utilisateurs et l’information brute Présente les informations dans une forme exploitable - 3 -

Propriétés des SGBD (2) Accès aux données efficaces Administration centralisées des données Non redondance des données. Cohérence des données Partage des données Sécurité des données - 4 -

Types de Bases de Données (1) Les bases hiérarchiques Les bases réseaux Les bases relationnelles données sous formes de tables basées sur l’algèbre relationnelle et un langage, de manipulation, déclaratif (SQL). 75% des SGBD sont des bases relationnelles Les bases objets gagnent du terrain - 5 -

Modèle Conceptuel de Données (MCD) Modélisation Modèle Conceptuel de Données (MCD) - 6 -

Modélisation Réalité perçue Modélisation conceptuelle Modèle entité association Transformation dans un modèle supporté par un SGBD Modèle relationnel A IMPRIMER Définition de la structure de données de la base SQL - 7 -

Modélisation Le résultat de l’analyse est le Modèle Conceptuel de Données (MCD) qui décrit la future base de données à l’aide d’entités et d’associations. Employé Numéro d’employé Nom Prénom Date d’embauche Fonction Rémunération participe Tâche Nom de la tâche Coût de la tâche 0,n 1,n Date début Date fin A IMPRIMER - 8 -

Vocabulaire (1) Entité : Propriété : représentation d’un objet, matériel ou immatériel (ex. : Étudiant, Voiture, Vin, etc...). une entité est composée de propriétés. Propriété : donnée élémentaire et indécomposable (ex. : age, note, nom, adresse, date de naissance, etc...). - 9 -

Vocabulaire (2) Association Dimension Cardinalité représentation d’un lien entre différentes entités. des propriétés peuvent être attachées à une association. Dimension nombre d’entités intervenants dans l’association (1 : association réflexive; 2 : association binaire; n : association n-aire) Cardinalité caractérise le lien entre une entité et une association. Elle est constituée d’une borne minimale et d’une borne maximale. - 10 -

Vocabulaire (3) Cardinalité (suite) Identifiant Nombre de fois qu’une occurrence de l’entité participe aux occurrences de l’association. Identifiant une ou plusieurs propriétés d’une entité telles qu’à chaque valeur de l’identifiant correspond une et une seule occurrence de l’entité. l’identifiant d’une association est constitué de la réunion des identifiants des entités qui participent à l’association. - 11 -

Exemple de MCD encadre Employé Numéro d’employé Nom Prénom a pour chef 0,1 0,n Employé Numéro d’employé Nom Prénom Date d’embauche Fonction Rémunération est chef de Projet Numéro du projet Thème du projet Titre du projet Date de début Date de fin coordonne 0,n 1,1 A IMPRIMER 1,n 0,n participe Date début Date fin Tâche Nom de la tâche Coût de la tâche Constitué_de 1,n 1,1 - 12 -

Modèle Conceptuel des Données Exemple "KaafKaaf" PARTIE 1 La société "KaafKaaf" 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 où il reçoit sa première facture. Une facture concerne un et un seul client.

Modèle Conceptuel des Données Remarque: Bien que le numéro du client n'apparaisse pas en tant que tel sur la facture, il est préférable d'ajouter cette propriété artificielle à l'entité Client, et de la définir comme identifiant de cette entité. Cela nous empêche de devoir définir un identifiant composé de trop de propriétés.

Modèle Conceptuel des Données PARTIE 2 Il s'agit d'étendre le MCD de la partie 1. 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. Voici l'aspect que la facture devrait avoir: Proposez un nouveau MCD qui reflète ces modifications, en respectant que: Tous les articles disponibles sont stockés (p.ex. No=234 Libellé="Marteau" PU=470 Luf.). Même si un article n'est pas encore considéré par une facture, il existe dans le système d'information.

Modèle Conceptuel des Données Remarques: 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. Pour la même raison, on n'a pas besoin de modéliser explicitement le prix à payer pour l'achat d'une quantité d'articles donnés. Le prix pour chaque article figurant sur la facture peut être calculé à partir du prix unitaire et de la quantité

Modèle Conceptuel des Données Exemple "Gestion d'école" PARTIE 1 Dans une école, on veut informatiser le système d'information qui gère les classes. Elaborez un MCD sachant que: Un élève est caractérisé par son no. matricule, son nom et prénom, ainsi que sa date de naissance. Une classe est caractérisée par le nom de la classe et par une indication du cycle. Il faudra prévoir de connaître la fréquentation des classes des élèves sur plusieurs années consécutives. Un élève enregistré dans le système fréquente au moins une classe au cours des années.

Modèle Conceptuel des Données PARTIE 2 Il s'agit maintenant de concevoir une extension au MCD précédent qui permet de représenter la situation suivante: La direction de l'école désire également saisir tous les professeurs dans le système d'information. Un professeur est caractérisé par un code interne unique , son nom et prénom et la matière qu'il enseigne. Nous supposons que chaque professeur enseigne une seule matière. Modélisez le fait que chaque classe est enseignée chaque année par un ou plusieurs enseignants. Un enseignant peut bien sûr donner des cours dans plusieurs classes, mais peut également ne pas donner des cours pendant une ou plusieurs années.

Exercices 01 Établir le modèle conceptuel des données correspondant puis le modèle logique associé GESTION DES LOGEMENTS DANS UNE AGENCE IMMOBILIÈRE  Une agence de location de maisons et d’appartements désire gérer sa liste de logements. Elle voudrait en effet connaître l’implantation de chaque logement (nom de la commune et du quartier) ainsi que les personnes qui les occupent (les signataires uniquement).  Le loyer dépend d’un logement, mais en fonction de son type (maison, studio, T1, T2...) l’agence facturera toujours en plus du loyer la même somme forfaitaire à ses clients. Par exemple, le prix d’un studio sera toujours égal au prix du loyer + 30 € de charges forfaitaires par mois.  Pour chaque logement, on veut disposer également de l’adresse, de la superficie ainsi que du loyer.  Quant aux individus qui occupent les logements (les signataires du contrat uniquement), on se contentera de leurs noms, prénoms, date de naissance et numéro de téléphone.  Pour chaque commune, on désire connaître le  nombre d’habitants ainsi que la distance séparant la commune de l’agence.  NB : on ne gérera pas l’historique de l’occupation des logements par les individus. On considèrera de plus qu’un individu ne peut être signataire que d’un seul contrat.  .  - 19 -

Exercice 02 Une casse automobile souhaite gérer son stock de pièces. Chaque pièce est identifiée par une référence, une catégorie (carosserie, mécanique, électricité, etc.), une date de récupération et un prix de vente. On souhaite également pouvoir établir une correspondance entre les pièces et les véhicules pour lesquels elles conviennent, ces véhicules étant repérés par marque, modèle et année. Etablir le MCD adéquat dans les deux hypothèses suivantes : toutes les pièces d'une même référence possèdent un prix unique chaque pièce possède un prix propre. Etablir le MCD .

Le Modèle Relationnel - 21 -

Modèle Relationnel Les SGBD relationnels organisent les données en tables On représente symboliquement une relation R par un schéma SR de la forme : R(clé, attribut 2, attribut 3, …, attribut n). On aura donc : PRODUIT(num_produit, nom_produit, stock). - 22 -

Exemple de base de données relationnelle (1) Relation VOL (numvol, depart, arrivee, numav, numpil, jdep, hdep, jarr, harr) numvol : numéro du vol (clé) depart : ville de départ arrivee : ville d’arrivée numav : numéro d’avion numpil : numéro du pilote jdep : jour de départ (clé) hdep : heure de départ jarr : jour d’arrivée harr : heure d’arrivée

Exemple de base de données relationnelle (2) Relation PILOTE(numpilote, nom, prenom) numpilote : numéro du pilote (clé) nom : nom du pilote prenom : prénom du pilote Relation AVION(numavion, type, cap) numavion : numéro de l’avion (clé) type : type de l’avion cap : capacité de l’avion

Table, tuple, attribut LE MODELE RELATIONNEL Champs (attributs ou colonnes) fabricant modèle fréquence Intel Pentium 4 3000 Tuples (enregistrements Ou lignes) Intel Pentium M 2000 table Intel Pentium D 3000 AMD Athlon XP 2800 AMD Athlon 64 X2 3800 LE MODELE RELATIONNEL

Vocabulaire comparé - 26 -

Du MCD vers les Tables Relationnelles - 27 -

Passage du modèle entité-association au modèle relationnel (1) Il y a trois règles de passage. Règle 1 Chaque type d’entité donne naissance à une relation du même nom. Chaque propriété du type d’entité devient un attribut de la relation. L’identifiant du type d’entité devient la clé de la relation.

Passage du modèle entité-association au modèle relationnel (2) Règle 2 Si un type d’association n’a aucune patte de cardinalité maximale égale à 1, alors : ce type d’association devient une relation chaque propriété du type d’association devient un attribut de la relation l’identifiant du type d’association devient la clé de la relation.

Passage du modèle entité-association au modèle relationnel (3) Règle 3 Si un type d’association a une patte dont la cardinalité maximale est égale à 1, il s’agit d’une dépendance fonctionnelle. Le type d’association n’est pas transformé en relation, mais est matérialisé par l’ajout d’un attribut dans la relation source de la dépendance fonctionnelle. Cet attribut est la clé du type d’entité but de la dépendance fonctionnelle.

Passage du modèle entité-association au modèle relationnel (4) Type d’association “achète” Le modèle relationnel sera : CLIENT(num_client, nom_client, adresse) FOURNISSEUR(num_fournisseur, nom_fournisseur, adresse) auquel s’ajoute la relation issue du type d’association “achète” : ACHAT(num_client, num_fournisseur).

Passage du modèle entité-association au modèle relationnel (5) Type d’association “propriétaire” Le modèle relationnel sera : PERSONNE(identifiant_personne, …) APPARTEMENT(identifiant_appartement, …) auquel s’ajoute la relation, issue du type d’association “propriétaire” : PROPRIETAIRE(identifiant_personne, identifiant_appartement).

Passage du modèle entité-association au modèle relationnel (6) Type d’association “ commande ” Le type d’association “Passée par” est une dépendance fonctionnelle. Il n’est donc pas transformé en relation : on ajoute un attribut dans la source de la DF (donc dans le type d’entité Commande). L’attribut ajouté est la clé du type d’entité but de la DF, donc l’attribut num_client, clé de Client.

Passage du modèle entité-association au modèle relationnel (7) Le modèle relationnel sera donc : COMMANDE(num_commande, date, num_client*) CLIENT(num_client, nom, adresse) ARTICLE(num_article, designation, prix) auquel s’ajoute la relation issue de “ Concerne ” que l’on appellera DETAIL_COMMANDE : DETAIL_COMMANDE(num_commande, num_article, quantité).

Passage du modèle entité-association au modèle relationnel (8) Type d’association “enseignement” Le type d’associa- tion “ Enseignant ” est une DF. Il n’est pas transformé en relation, mais on ajoute dans la relation source de la DF (c’est-à-dire dans UV) l’attribut clé (code_professeur) du type d’entité but (Professeur).

Passage du modèle entité-association au modèle relationnel (9) Le modèle relationnel sera donc : ELEVE(code_eleve, nom, prenom) UV(code_UV, nom, annee, code_professeur*) PROFESSEUR(code_professeur, nom, prenom) auquel s’ajoute la relation issue de “A suivi” que l’on appellera NOTE : NOTE(code_eleve, code_UV, note).

Contraintes d’Intégrité Référentielle Un constituant d’une clé étrangère doit limiter ses valeurs à l’ensemble des valeurs présentes dans la table d’origine de la clé. Si un enregistrement d’une table est supprimé, tous les enregistrements des autres tables faisant référence à cet enregistrement, à travers des clés étrangères, doivent normalement être supprimés. - 37 -

Structured Query Language (SQL) - 38 -

Définition SQL (Structured Query Language) est un langage de définition et de manipulation de bases de données relationnelles. - 39 -

Les Trois Niveaux DDL (Data Definition Language) permet de créer, modifier, supprimer les tables DML (Data Manipulation Language) permet de manipuler les données contenues dans les tables (sélection, ajout, modification, suppression) DCL (Data Control Language) permet de gérer les accès des utilisateurs aux tables - 40 -

Principaux ordres SQL - 41 -

Tables des exemples Fournisseur Produit Commande - 42 -

Sélection simple (1) ; SELECT DISTINCT design FROM Produit ; WHERE prix > 2000 ; - 43 -

Sélection simple (2) ; SELECT DISTINCT design, prix FROM Produit ; - 44 -

Sélection simple ordonnée Présentation SELECT DISTINCT design, couleur FROM Produit WHERE couleur IN ("rouge", "vert") ORDER BY design DESC; SELECT DISTINCT design AS Nom du produit FROM Produit WHERE couleur IN ("rouge", "vert") ORDER BY design ASC; - 45 -

Jointure Produit cartésien Jointure « Donner toutes les informations concernant les commandes » SELECT * FROM Produit, Commande, Fournisseur ; SELECT * FROM Produit, Commande, Fournisseur WHERE Produit.pno = Commande.pno AND Fournisseur.fno = Commande.fno; - 46 -

Jointure Jointure (résultat) SELECT * FROM Produit, Commande, Fournisseur WHERE Produit.pno = Commande.pno AND Fournisseur.fno = Commande.fno; - 47 -

Jointure Jointure - projection SELECT cno, design, nom AS Nom fournisseur, qute FROM Produit, Commande, Fournisseur WHERE Produit.pno = Commande.pno AND Fournisseur.fno = Commande.fno; - 48 -

Calcul Jointure - projection - calcul SELECT no, design, nom AS Nom fournisseur, prix, qute, prix*qute AS Total FROM Produit, Commande, Fournisseur WHERE Produit.pno = Commande.pno AND Fournisseur.fno = Commande.fno; - 49 -

Sous requête Question liste des numéros de fournisseurs livrant au moins un produit en quantité supérieure à chacun des produits livrés par le fournisseur 19 SELECT fno FROM Commande WHERE qute > ALL (SELECT qute FROM Commande WHERE fno = 19) - 50 -

Fonctions statistiques - 51 -

Exemples d'agrégats (Regroupements) VINS CRU MILL QUANTITE CHABLIS VOLNAY MEDOC 1977 1987 1986 1985 10.9 11.9 10.8 11.2 100 250 400 300 200 DEGRE SELECT AVG(DEGRE) FROM VINS; SELECT CRU, SUM(QUANTITE) FROM VINS GROUP BY CRU; AVG DEGRE 11.2 SUM CRU SUM(QUANTITE) CHABLIS 350 VOLNAY 700 MEDOC 200 - 52 - 27

COUNT Comptage de tuples compter le nombre de commandes passées SELECT COUNT(*) FROM Commande; compter le nombre de produits de couleur rouge SELECT COUNT(*) AS NbRouge FROM Produit WHERE couleur = ‘ rouge ’; - 53 -

SUM Sommations Total des quantités commandées de produits de couleur rouge. SELECT SUM(qute) AS QuteCmdRouge FROM Commande, Produit WHERE Commande.pno = Produit.pno AND couleur = rouge; - 54 -

SUM et agrégats Calculs sur les tuples et regroupement Total des quantités commandées par numéro de produit. SELECT SUM(qute) AS QuteCmd , pno FROM Commande GROUP BY pno; - 55 -

Forme générale Consultation de tables SELECT [ALL | DISTINCT] <attributs> FROM <tables> [ WHERE <conditions> GROUP BY <attributs> HAVING <conditions> ORDER BY <attributs> ] ; - 56 -

Autres Exemples (1) Calcul sur les tuples « Donner le nom des buveurs ayant consommé plus que la moyenne » SELECT Buveurs.nom FROM Buveurs, Abus WHERE Buveurs.nb = Abus.nb AND Abus.qte > ( SELECT AVG(Abus.qte) FROM Abus ) ; - 57 -

Autres Exemples (2) Calcul sur les tuples et regroupements « Donner le nom et la quantité de vin bue par chaque buveur ayant consommé plus de 10 litres » SELECT Buveurs.nom, SUM(Abus.qte) FROM Buveurs, Abus WHERE Buveurs.nb = Abus.nb GROUP BY Buveurs.nom HAVING SUM(Abus.qte) > 10 ; - 58 -

Autres Exemples (3) Requête d’insertion « Ajouter un buveur » INSERT INTO Buveurs (nb, nom, ville, type) VALUES (8, Dupont, Lyon, Petit) - 59 -

Autres Exemples (4) Requête d’insertion « Ajouter dans la table Petit_Buveurs, les petits buveurs contenus dans la table Buveurs » INSERT INTO Petit_Buveurs (nb, nom) SELECT Buveurs.nb, Buveurs.nom FROM Buveurs WHERE Buveurs.type = ‘ Petit ’ ; - 60 -

Autres Exemples (5) Requête de mise à jour « Modifier le type des buveurs habitant Bordeaux en gros buveurs » UPDATE Buveurs SET Buveurs.type = ‘ gros ’ WHERE Buveurs.ville = ‘ Bordeaux ’ ; - 61 -

Autres Exemples (6) Requête de suppression « Supprimer tous les petits buveurs » DELETE FROM Buveurs WHERE Buveurs.type = ‘ Petit ’ ; - 62 -

Normalisations - 63 -

Nécessité des Normalisations Considérons le schéma de la relation suivante : Article(NomFnsr, AdresseFnsr, NomArt, PrixArt). Une table correspondante est : - 64 -

Anomalies de Mises à Jour Anomalie d’insertion : On ne peut mémoriser (insérer) les coordonnées d’un fournisseur s’il ne fourni pas au moins un article. Anomalie de suppression : La suppression d’un article qui est l’unique article fourni par un fournisseur entraîne la perte des informations relatives à ce fournisseur. Anomalies de modification : Si un fournisseur change de coordonnées, il faudra répercuter cette modification à tous les articles dont il est le fournisseur. - 65 -

Normalisation de l’exemple La relation Article(NomFnsr, AdresseFnsr, NomArt, PrixArt) contient certaines dépendances : NomFnsr  AdresseFnsr NomFnsr, NomArt  PrixArt Elle devrait se décomposer en deux relations : Fournisseur(NomFnsr, AdresseFnsr) et Article(NomFnsr, NomArt, PrixArt) - 66 -

Normalisation Les règles de normalisation permettent de concevoir un schéma de base de données correct : sans redondance d’information. sans anomalie de mise à jour. Elles se basent sur les dépendances fonctionnelles (DF) qui traduisent les relations entre les données. les formes normales qui définissent les relations bien conçues. - 67 -

Normalisation Il existe plusieurs niveaux de normalisation : Première forme normale (1FN) Deuxième forme normale (2FN) Troisième forme normale (3FN) ... Un modèle relationnel est dit normalisé quand toutes ses tables sont en 3FN. - 68 -

Dépendance fonctionnelle (DF) Soient R (A1, A2, …, An) un schéma de relation. X et Y des sous-ensembles d’attributs de la relation R. X  Y qui se lit X détermine Y ou Y dépend (fonctionnellement) de X signifie que si on connaît la valeur de X alors la valeur de Y est automatiquement déduite. PERSONNE N° SS --> NOM ? NOM --> N° SS ? - 69 -

Normalisation Première forme normale Deuxième forme normale But : garantir la manipulation de données élémentaires (indivisibles) Deuxième forme normale But : éliminer certaines redondances en s’assurant qu’aucun attribut n’est déterminé par une sous partie de la clé. Troisième forme normale But : Elimination des dépendances dues à la transitivité des dépendances transitives. - 70 -

Première forme normale Définition Une relation est en 1ère forme normale si tout attribut contient une valeur atomique (unique) Exemple d’une relation non en 1NF PERSONNE NOM PROFESSION DUPONT Ingénieur, Professeur MARTIN Géomètre Une telle relation doit être décomposée en répétant les noms pour chaque profession - 71 -

Première forme normale Décomposition : PERSONNE NOM PROFESSION DUPONT Ingénieur DUPONT Professeur MARTIN Géomètre - 72 -

Deuxième forme normale une relation est en 2e forme normale ssi : 1) elle est en 1ère forme normale 2) tout attribut non clé ne dépend pas d'une partie de la clé Schéma d’une relation non en 2NF : R K1   K2 X Y Une telle relation doit être décomposée en R1(K1,K2,X) et R2(K2,Y) - 73 -

Exemple Article(NomFnsr, AdresseFnsr, NomArt, PrixArt). NomFnsr, NomArt  PrixArt - 74 -

Troisième forme normale une relation est en 3e forme normale ssi : 1) elle est en 2e forme normale 2) tout attribut n'appartenant pas a une clé ne dépend pas d’attribut ne faisant pas partie de la clé Schéma d’une relation non en 3NF : R K X Y Z Une telle relation doit être décomposée en R1(K, X, Y) et R2(X,Z) - 75 -

Exemple 3ième Forme Normale Voiture (NV, marque, type, puissance, couleur) Type --> marque Type --> puissance Pas en 3eme forme normale ! Devra se décomposer en : Voiture(NV, type, couleur) et TypeVoiture(type, marque, puissance) - 76 -