Bases de données et SGBD relationnels

Bases de données et SGBD relationnels (1) Une base de données représente un ensemble de données d’entreprise, mémorisé par un ordinateur, organisé selon un modèle de données accessible à de nombreuses personnes. Un Système de Gestion de Bases de Données (SGBD) représente un ensemble coordonné de logiciels permettant de décrire, mémoriser, manipuler, traiter, interroger les ensembles de données constituant la base.

Bases de données et SGBD relationnels (2) Un SGBD doit satisfaire 5 conditions : être une bonne représentation du monde réel, fiable et à jour : des contraintes d’intégrité doivent assurer un état cohérent de la base. assurer la non-redondance de l’information : une information doit être implantée une et une seule fois. maintenir l’indépendance des programmes par rapport aux données, permettant aux applications de partager les mêmes données.

Bases de données et SGBD relationnels (3) assurer la sécurité et la confidentialité des données : les données doivent être protégées contre les accès non autorisés et contre les pannes intempestives. autoriser le partage des données, permettant à plusieurs utilisateurs de modifier des données quasiment en même temps tout en assurant un résultat cohérent pour un utilisateur consultant la base.

Historique des SGBD (1) Première génération (années 70) : modèle hiérarchique ou modèle en réseau. Modèle hiérarchique : les données sont représentées sous forme d’une hiérarchie arborescente à plusieurs niveaux. Chaque niveau est constitué d’un ou de plusieurs groupes de données pouvant se décomposer à leur tour. Modèle en réseau : extension du précédent, où les liens entre objets peuvent exister sans restrictions, indépendamment de la structure de l’arbre.

Historique des SGBD (2) Deuxième génération (années 80) : modèle relationnel. Les données sont représentées sous forme tabulaire, avec indépendance totale entre les logiciels et le support de stockage. Langages spécifiques permettant d’accéder aux données de manière assez naturelle : QBE, SQL. Quelques SGBD relationnels : ORACLE, INGRES, SYBASE, DBASE2, ACCESS, mySQL. Troisième génération (fin des années 90) : modèle objets. SGBD objets : O2, ORACLE.

Objectifs d’un modèle relationnel Les principaux objectifs d’un modèle relationnel sont : utiliser des structures de données simples  une table relationnelle est un tableau proposer des langages permettant d’accéder aux données de manière assez naturelle  QBE, SQL proposer l’indépendance entre les données et les traitements exécutés sur ces données permettre à chaque utilisateur d’avoir une vue de la base de données appropriée à ses besoins.

Le modèle relationnel (1) Le concept de base du modèle relationnel est la relation, de structure tabulaire Une relation a plusieurs attributs  Le degré de la relation est le nombre de ces attributs Exemple : la relation PRODUIT, de degré 3, comporte les attributs : num_produit, nom_produit et stock

Le modèle relationnel (2) Occurrence : chaque ligne du tableau (un n-uplet) correspond à une occurrence de la relation. Cardinalité : nombre d’occurrences de la relation dans la base. La relation PRODUIT est donc de cardinalité 4. Clé : chaque relation contient un attribut particulier (ou un ensemble d’attributs) appelé clé, dont la valeur permet de distinguer une occurrence de toutes les autres. Pour la relation PRODUIT, l’attribut clé est num_produit.

Le modèle relationnel (3) 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).

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

Exemple de base de données relationnelle (3) Les liens entre ces relations sont appelés des jointures : l’attribut NUMAV de VOL représente le même type d’information que l’attribut NUMAVION de AVION. On écrira : VOL.NUMAV = AVION.NUMAVION l’attribut NUMPIL de VOL représente le même type d’information que l’attribut NUMPILOTE de PILOTE. On écrira : VOL.NUMPIL = PILOTE.NUMPILOTE

Éléments de SQL, le langage relationnel

Éléments de SQL, le langage relationnel (1) Le langage SQL (Structured Query Language) est le langage d’interrogation le plus utilisé. Il permet de déclarer les relations, de créer les occurrences, de les modifier, d’interroger et de manipuler les SGBD relationnelles. La forme générale d’une interrogation SQL (appelée une requête) est : SELECT liste d’attributs FROM noms de relations WHERE conditions ; Dans les conditions de la clause optionnelle WHERE, on peut utiliser les opérateurs AND et OR.

Éléments de SQL, le langage relationnel (2) Recherche des noms et prénoms des pilotes SELECT NOM, PRENOM FROM PILOTE  réalise une projection, c’est-à-dire ne prend qu’un sous-ensemble des attributs de la relation PILOTE.

Éléments de SQL, le langage relationnel (3) Recherche des attributs des pilotes de prénom Georges SELECT * FROM PILOTE WHERE PRENOM= 'Georges' ; réalise une sélection, c’est-à-dire affiche tous les attributs de la relation PILOTE mais ne prend qu’une partie des occurrences, celles vérifiant la condition : prenom= 'Georges'.

Éléments de SQL, le langage relationnel (4) Attributs croisés de tous les pilotes et de tous les vols SELECT * FROM VOL, PILOTE ; réalise le produit cartésien de la relation VOL par la relation PILOTE, en combinant toutes les occurrences de VOL avec toutes les occurrences de PILOTE. etc...

Éléments de SQL, le langage relationnel (5) Recherche sur les vols et sur les pilotes effectifs de ces vols SELECT * FROM PILOTE, VOL WHERE PILOTE.NUMPILOTE = VOL.NUMPIL réalise une jointure naturelle, c’est-à-dire une sélection sur le produit cartésien de la relation VOL par la relation PILOTE, sélection réalisée par l’égalité d’attributs identiques : PILOTE.NUMPILOTE = VOL.NUMPIL.

Éléments de SQL, le langage relationnel (6) Numéro des vols et noms des pilotes de ces vols SELECT VOL.NUMVOL, PILOTE.NOM FROM PILOTE, VOL WHERE PILOTE.NUMPILOTE = VOL.NUMPIL réalise une projection à partir d’une jointure naturelle.

Éléments de SQL, le langage relationnel (7) Numéro des vols sur l’avion de numéro ‘A0006’ et noms des pilotes de ces vols SELECT VOL.NUMVOL, PILOTE.NOM FROM VOL, PILOTE WHERE VOL.NUMPIL = PILOTE.NUMPILOTE AND VOL.NUMAV='A0006' ; réalise une projection d’une sélection sur une jointure naturelle, sélection réalisée par une condition sur un attribut : VOL.NUMAV='A0006'.

Éléments de SQL, le langage relationnel (8) Numéros de vols, types d’avion, capacités et noms des pilotes de ces vols SELECT VOL.NUMVOL, AVION.TYPE, AVION.CAP, PILOTE.NOM FROM AVION, PILOTE, VOL WHERE PILOTE.NUMPILOTE = VOL.NUMPIL AND VOL.NUMAV = AVION.NUMAVION réalise une projection sur le résultat de deux jointures naturelles entre trois relations.

Éléments de SQL, le langage relationnel (9) Numéros de vols, types d’avion, capacités et noms des pilotes des vols de capacité comprise entre 200 et 350 Deux formulations possibles : 1) SELECT VOL.NUMVOL, AVION.TYPE, AVION.CAP, PILOTE.NOM FROM AVION, PILOTE, VOL WHERE PILOTE.NUMPILOTE = VOL.NUMPIL AND VOL.NUMAV = AVION.NUMAVION AND (AVION.CAP BETWEEN 200 AND 350)

Éléments de SQL, le langage relationnel (10) 2) SELECT VOL.NUMVOL, AVION.TYPE, AVION.CAP, PILOTE.NOM FROM AVION, PILOTE , VOL WHERE PILOTE.NUMPILOTE = VOL.NUMPIL AND VOL.NUMAV = AVION.NUMAVION AND AVION.NUMAVION IN (SELECT AVION1.NUMAVION FROM AVION AVION1 WHERE (AVION1.CAP BETWEEN 200 AND 350))

Éléments de SQL, le langage relationnel (11) Les fonctions ensemblistes MAX fournit la valeur maximale d’un attribut Capacité de l’avion de capacité maximale SELECT MAX(AVION.CAP) FROM AVION Capacité maximale des avions allant à Madrid SELECT MAX(AVION.CAP) FROM AVION, VOL WHERE AVION.NUMAVION = VOL.NUMAV AND (VOL.ARRIVEE='Madrid')

Éléments de SQL, le langage relationnel (12) MIN fournit la valeur minimale d’un attribut Capacité de l’avion de capacité minimale SELECT MIN(AVION.CAP) FROM AVION Heure de départ du premier vol du 15/5/2004 SELECT MIN(VOL.HDEP) FROM VOL WHERE (VOL.JDEP={d '2004-05-15'})

Éléments de SQL, le langage relationnel (13) COUNT permet de compter le nombre d’occurrences Nombre d’avions au départ de Paris SELECT COUNT(VOL.DEPART) FROM VOL WHERE (VOL.DEPART='Paris') Nombre de Boeing 747 SELECT COUNT(AVION.NUMAVION) FROM AVION WHERE (AVION.TYPE='Boeing 747')

Éléments de SQL, le langage relationnel (14) SUM permet d’additionner des attributs Capacité totale des avions SELECT SUM(AVION.CAP) FROM AVION Capacité totale des avions au départ de Paris FROM AVION, VOL WHERE VOL.NUMAV = AVION.NUMAVION AND (VOL.DEPART='Paris')

Éléments de SQL, le langage relationnel (15) AVG permet de calculer des moyennes d’attributs Moyenne des capacités des Boeing 747 SELECT AVG(AVION.CAP) FROM AVION WHERE (AVION.TYPE='Boeing 747') Moyenne des capacités des avions à destination d’Amsterdam SELECT AVG(AVION.CAP) FROM AVION, VOL WHERE VOL.NUMAV = AVION.NUMAVION AND (VOL.ARRIVEE='Amsterdam')

Éléments de SQL, le langage relationnel (16) VAR permet de calculer des variances d’attributs Variance des capacités des avions SELECT VAR(AVION.CAP) FROM AVION Variance des capacités des Boeing 747 WHERE (AVION.TYPE='Boeing 747')

Éléments de SQL, le langage relationnel (17) Autres fonctions DISTINCT permet de n’obtenir qu’une seule fois chaque occurrence Types des avions SELECT DISTINCT AVION.TYPE FROM AVION Différentes capacités des avions SELECT DISTINCT AVION.CAP

Éléments de SQL, le langage relationnel (18) ORDER BY permet d’ordonner par ordre croissant ou décroissant (DESC) Type et capacité des avions par type croissant (ordre alphabétique) SELECT DISTINCT AVION.TYPE, AVION.CAP FROM AVION ORDER BY AVION.TYPE Liste des pilotes par ordre alphabétique décroissant SELECT DISTINCT PILOTE.NOM FROM PILOTE ORDER BY PILOTE.NOM DESC

Éléments de SQL, le langage relationnel (19) LIKE permet d’utiliser des jokers dans les chaînes de caractères _ veut dire un caractère quelconque % veut dire un nombre quelconque de caractères Numéros des vols dont le nom du pilote a pour deuxième lettre la lettre “ r ” SELECT VOL.NUMVOL FROM PILOTE, VOL WHERE PILOTE.NUMPILOTE = VOL.NUMPIL AND (PILOTE.NOM LIKE '_r%')

Éléments de SQL, le langage relationnel (20) Villes de départ dont la deuxième lettre est la lettre “ o ” SELECT DISTINCT VOL.DEPART FROM VOL WHERE VOL.DEPART LIKE '_o%')

Exercices (1) Heure de départ du premier avion pour Madrid SELECT MIN(VOL.HDEP) FROM VOL WHERE (VOL.ARRIVEE='Madrid')

SELECT COUNT(VOL.NUMVOL) Exercices (2) Nombre de vols pilotés par Dupuis SELECT COUNT(VOL.NUMVOL) FROM VOL, PILOTE WHERE VOL.NUMPIL=PILOTE.NUMPILOTE AND PILOTE.NOM='Dupuis'

Capacité totale des avions partant ou arrivant à Paris Exercices (3) Capacité totale des avions partant ou arrivant à Paris SELECT SUM(AVION.CAP) FROM AVION, VOL WHERE VOL.NUMAV=AVION.NUMAVION AND ((VOL.DEPART='Paris') OR (VOL.ARRIVEE='Paris'))

Exercices (4) Moyenne des capacités des avions pilotés par Dupuis SELECT AVG(AVION.CAP) FROM VOL, PILOTE, AVION WHERE PILOTE.NOM='Dupuis' AND VOL.NUMPIL=PILOTE.NUMPILOTE VOL.NUMAV=AVION.NUMAVION

Types d'avions pilotés par Simon Exercices (5) Types d'avions pilotés par Simon SELECT DISTINCT AVION.TYPE FROM AVION, PILOTE, VOL WHERE PILOTE.NOM='Simon' AND VOL.NUMPIL=PILOTE.NUMPILOTE AND VOL.NUMAV=AVION.NUMAVION

Exercices (6) Types des avions fabriqués par Boeing SELECT DISTINCT AVION.TYPE FROM AVION WHERE (AVION.TYPE Like 'Boeing%')

Type des avions atterrissant dans une ville commençant par la lettre M Exercices (7) Type des avions atterrissant dans une ville commençant par la lettre M SELECT DISTINCT AVION.TYPE FROM AVION, VOL WHERE VOL.NUMAV=AVION.NUMAVION AND (VOL.ARRIVEE LIKE 'M%')

Exercices (8) Nom du pilote et heure de départ du vol partant le plus tôt SELECT PILOTE.NOM, VOL.HDEP FROM PILOTE, VOL WHERE PILOTE.NUMPILOTE = VOL.NUMPIL AND VOL.HDEP = (SELECT MIN(VOL1.HDEP) FROM VOL VOL1 )

Éléments de SQL, le langage relationnel (21) GROUP BY permet d’effectuer des groupements Sommes des capacités des avions, groupés par ville de départ SELECT VOL.DEPART, SUM(AVION.CAP) FROM AVION, VOL WHERE VOL.NUMAV = AVION.NUMAVION GROUP BY VOL.DEPART

Éléments de SQL, le langage relationnel (22) GROUP BY est souvent utilisé avec la clause HAVING pour spécifier des caractéristiques du groupement : Heure de départ, ville de départ et d’arrivée du premier vol du 15/5/2004 SELECT VOL1.HDEP, VOL1.DEPART, VOL1.ARRIVEE FROM VOL, VOL VOL1 WHERE (VOL.JDEP={d '2004-05-15'}) AND (VOL1.JDEP={d '2004-05-15'}) GROUP BY VOL1.HDEP, VOL1.DEPART, VOL1.ARRIVEE HAVING (VOL1.HDEP=MIN(VOL.HDEP))

Éléments de SQL, le langage relationnel (23) Retour sur l’exercice 8 : Nom du pilote et heure de départ du vol partant le plus tôt Deuxième solution (sans requête imbriquée) : SELECT PILOTE.NOM, VOL.HDEP FROM PILOTE, VOL VOL, VOL VOL1 WHERE PILOTE.NUMPILOTE = VOL.NUMPIL GROUP BY PILOTE.NOM, VOL.HDEP HAVING (VOL.HDEP=MIN(VOL1.HDEP))

Éléments de SQL, le langage relationnel (24) BETWEEN a AND b teste un intervalle Départ et arrivée des vols partant entre 10 h et 14 h 30 SELECT DISTINCT VOL.DEPART, VOL.ARRIVEE FROM VOL WHERE (VOL.HDEP BETWEEN '10:00' AND '14:30')

Éléments de SQL, le langage relationnel (25) Départ et arrivée des vols de capacité comprise entre 250 et 410 SELECT VOL.DEPART, VOL.ARRIVEE, AVION.CAP FROM AVION, VOL WHERE VOL.NUMAV = AVION.NUMAVION AND (AVION.CAP BETWEEN 250 AND 410)

Éléments de SQL, le langage relationnel (26) IS NULL et IS NOT NULL permettent de vérifier si l’attribut est renseigné ou pas Numéros des vols auxquels sont affectés des pilotes SELECT VOL.NUMVOL FROM VOL WHERE (VOL.NUMPIL IS NOT NULL)

Exercices (1) Nombre d’avions à destination de Madrid SELECT COUNT(VOL.NUMAV) FROM VOL WHERE (VOL.ARRIVEE='Madrid')

Exercices (2) Moyenne des capacités des avions pilotés par le pilote P0002 SELECT AVG(AVION.CAP) FROM AVION, VOL WHERE (VOL.NUMPIL='P0002') AND (VOL.NUMAV=AVION.NUMAVION)

Exercices (3) Variance des capacités des avions qui arrivent à Madrid SELECT VAR(AVION.CAP) FROM AVION, VOL WHERE (VOL.ARRIVEE='Madrid') AND (VOL.NUMAV=AVION.NUMAVION)

Exercices (4) Capacité totale des avions qui partent le 15/05/2004 SELECT Sum(AVION.CAP) FROM AVION, VOL WHERE VOL.NUMAV = AVION.NUMAVION AND (VOL.JDEP={d '2004-05-15'})

Nombre de pilotes volant sur Boeing Exercices (5) Nombre de pilotes volant sur Boeing SELECT Count(VOL.NUMPIL) FROM avion avion, vol vol WHERE vol.NUMAV = avion.NUMAVION AND ((avion.TYPE Like 'Boeing%')) Un même pilote est compté plusieurs fois s’il effectue plusieurs vols sur Boeing

Exercices (5) Version correcte (où on ne compte pas deux fois le même pilote) avec deux requêtes imbriquées : SELECT COUNT(PILOTE.NUMPILOTE) AS nombre FROM PILOTE WHERE PILOTE.NUMPILOTE IN (SELECT DISTINCT VOL.NUMPIL FROM VOL, AVION WHERE VOL.NUMAV=AVION.NUMAVION AND AVION.TYPE LIKE 'Boeing%')

Exercices (6) Ville de départ, ville de destination et capacité totale des avions reliant ces villes SELECT VOL.DEPART, VOL.ARRIVEE, SUM(AVION.CAP) FROM AVION, VOL WHERE VOL.NUMAV = AVION.NUMAVION GROUP BY VOL.DEPART, VOL.ARRIVEE

Exercices (7) Destination et capacité totale des avions partant de Paris, regroupés selon leur destination SELECT VOL.ARRIVEE, SUM(AVION.CAP) FROM AVION, VOL WHERE VOL.NUMAV = AVION.NUMAVION GROUP BY VOL.DEPART, VOL.ARRIVEE HAVING (VOL.DEPART='Paris')

Noms des pilotes et nombre maximum de passagers de ces pilotes Exercices (8) Noms des pilotes et nombre maximum de passagers de ces pilotes SELECT PILOTE.NOM, MAX(AVION.CAP) FROM AVION, PILOTE, VOL WHERE VOL.NUMAV = AVION.NUMAVION AND VOL.NUMPIL = PILOTE.NUMPILOTE GROUP BY PILOTE.NOM ORDER BY PILOTE.NOM

SELECT VOL1.HDEP, VOL1.JDEP FROM VOL VOL, VOL VOL1 Exercices (9) Heure et jour de départ du dernier vol au départ de Londres SELECT VOL1.HDEP, VOL1.JDEP FROM VOL VOL, VOL VOL1 WHERE (VOL.DEPART='Londres') AND (VOL1.DEPART='Londres') GROUP BY VOL1.HDEP, VOL1.JDEP HAVING (VOL1.HDEP=MAX(VOL.HDEP))

Exercices (10) Heure et jour de départ du premier vol au départ de Paris SELECT VOL1.HDEP, VOL1.JDEP FROM VOL VOL, VOL VOL1 WHERE (VOL.DEPART='Paris') AND (VOL1.DEPART='Paris') GROUP BY VOL1.HDEP, VOL1.JDEP HAVING (VOL1.HDEP=Min(VOL.HDEP))

Algèbre relationnelle

Algèbre relationnelle L’algèbre relationnelle définit des opérateurs sur les relations, produisant de nouvelles relations. Il est donc possible de construire de nouvelles informations à partir des relations de départ et d’une composition séquentielle d’opérateurs. Ces opérateurs se divisent en trois classes : les opérateurs unaires portant sur une seule relation, les opérateurs binaires portant sur deux relations de même schéma les opérateurs binaires portant sur deux relations de schémas différents.

Opérateurs unaires (1) L’affectation permet de sauvegarder le résultat d’une expression de recherche comme une nouvelle relation ou de renommer une relation et ses attributs. R(A1, …, An)  expression de sélection Exemple : Considérer le résultat d’une requête comme une nouvelle relation NUMPILOTE  SELECT PILOTE.NUMPILOTE FROM PILOTE

Opérateurs unaires (2) La sélection produit une nouvelle relation de même schéma en supprimant les occurrences de la relation qui ne satisfont pas une condition donnée Elle s’écrit : SELECTION(R, condition-de-sélection) La condition est construite à partir des connecteurs logiques et, ou, non et de conditions simples du type : attribut de R – opérateur de comparaison – constante attribut de R – opérateur de comparaison – attribut de R Exemple : Vols arrivant le 16/5/2004 SELECTION(VOL, JARR = 16/05/2004)

Opérateurs unaires (3) Le complément consiste à construire la relation qui contient toutes les occurrences qui n’existent pas à partir de toutes les valeurs des occurrences de la relation. Exemple : Relation “ ne pilote pas ” Il ne se programme pas directement en SQL ; il faut passer par l’opérateur MINUS (pas implanté partout) : (SELECT VOL.NUMVOL, PILOTE.NUMPILOTE FROM PILOTE, VOL) MINUS (SELECT VOL.NUMVOL, PILOTE.NUMPILOTE FROM PILOTE, VOL WHERE VOL.NUMPIL=PILOTE.NUMPILOTE)

Opérateurs unaires (4) La projection consiste à supprimer des attributs d’une relation. PROJECTION(R, A1, …, Ap) produit une nouvelle relation ayant comme n-uplets ceux de R mais restreints à un sous-schéma A1, …, Ap. Sa cardinalité est inférieure ou égale à celle de R car des doublons ont pu être supprimés. Exemple : Numéros des vols et des pilotes de ces vols PROJECTION(VOL, NUMVOL, NUMPIL)

Opérateurs binaires sur relations de même schéma (1) L’union permet de fusionner deux relations ayant les mêmes attributs en une seule relation. UNION(R, S) produit une nouvelle relation de même schéma ayant les n-uplets de R et ceux de S, les doublons étant supprimés. Exemple : Union de deux relations PILOTE En SQL : (SELECT * FROM PILOTE) UNION (SELECT * FROM PILOTE1)

Opérateurs binaires sur relations de même schéma (2) L’intersection permet de fournir les occurrences présentes dans deux relations à la fois. INTERSECTION(R, S) comporte les n-uplets présents dans R et dans S. Exemple : Pilotes de nom commençant par A et de prénom commençant par B En SQL (non implanté partout) : (SELECT * FROM PILOTE WHERE PILOTE.NOM LIKE 'A%') INTERSECT (SELECT * FROM PILOTE WHERE PILOTE.PRENOM LIKE 'B%')

Opérateurs binaires sur relations de même schéma (3) La différence permet d’obtenir les occurrences d’une relation qui n’appartiennent pas à une autre relation. Elle se note DIFFERENCE(R, S) Exemple : Pilotes dont le nom ne commence pas par A En SQL (non implanté partout) : (SELECT * FROM PILOTE) MINUS (SELECT * FROM PILOTE WHERE PILOTE.NOM LIKE 'A%')

Opérateurs binaires sur relations de schémas différents (1) R et S sont des relations de schémas respectifs SR et SS. Le produit cartésien se construit en combinant toutes les associations d’occurrences possibles entre les deux relations. PRODUIT(R, S) produit donc une relation qui est l’union des schémas SR et SS et dont les n-uplets sont la concaténation des n-uplets de R avec ceux de S. Sa cardinalité est le produit des cardinalités de R et de S. Exemple : Avions et pilotes susceptibles de les piloter En SQL : SELECT * FROM AVION, PILOTE

Opérateurs binaires sur relations de schémas différents (2) Le thêta-produit est une sélection effectuée sur un produit cartésien, par une condition logique. Elle se note THETA-PRODUIT(R, S, condition-logique) Exemple : avions de capacité < 300 et pilotes susceptibles de les piloter En SQL : SELECT * FROM AVION, PILOTE WHERE (AVION.CAP<300)

Opérateurs binaires sur relations de schémas différents (3) La jointure naturelle est un cas particulier de thêta-produit où la condition logique est l’égalité et porte sur des attributs identiques Elle se note JOINTURE(R, S, condition) où la condition est du type R.A = S.A, A étant commun à R et S. Le schéma résultant est l’union de SR et SS ; les n-uplets sont la concaténation de ceux de R avec ceux de S, s’ils ont la même valeur pour l’attribut A. Exemple : Vols et avions assurant ces vols En SQL : SELECT * FROM VOL , AVION WHERE VOL.NUMAV=AVION.NUMAVION

Opérateurs binaires sur relations de schémas différents (4) L’auto-jointure est une jointure (réalisée par une condition logique) dans laquelle la même table est utilisée deux fois. On utilise des variables différentes pour distinguer les deux entrées. Exemple : Départ et arrivée du vol de capacité minimale En SQL : SELECT VOL.DEPART, VOL.ARRIVEE FROM AVION AVION, AVION AVION1, VOL WHERE (VOL.NUMAV=AVION.NUMAVION) GROUP BY VOL.DEPART, VOL.ARRIVEE, AVION.CAP HAVING (AVION.CAP=MIN(AVION1.CAP))

Opérateurs binaires sur relations de schémas différents (5) La jointure extérieure Basée sur le même principe que la jointure naturelle, elle conserve cependant les occurrences d’une relation qui n’ont pas d’occurrence “associée” dans l’autre relation. Les attributs non renseignés prennent la valeur NULL. La jointure extérieure n’est généralement pas implantée en SQL.

Opérateurs binaires sur relations de schémas différents (6) La semi-jointure permet de faire apparaître toutes les occurrences de la première relation (même celles sans occurrence “associée” dans la deuxième) mais ne fait pas apparaître les occurrences de la seconde relation qui n’ont pas d’occurrence “associée” dans la première. Exemple : Vols et pilotes assurant ces vols, même si aucun pilote n’est encore désigné pour ces vols En SQL (non implanté partout) : SELECT * FROM VOL, PILOTE WHERE VOL.NUMPIL=PILOTE.NUMPILOTE (+)

Opérateurs binaires sur relations de schémas différents (7) La division concerne une relation qui est “ divisée ” par une autre qui contient exclusivement des attributs de la première. Elle détermine quelles sont les occurrences de la première relation qui sont associées à toutes les occurrences de la seconde relation.

Opérateurs binaires sur relations de schémas différents (8) Si la relation R est définie sur un schéma X U Y (réunion des schémas X et Y) et si S est définie sur Y, alors DIVISION(R, S) produit une relation définie sur X et comprend tous les n-uplets dont la concaténation avec tous les n-uplets de S appartient à R. Dans l’exemple, X={A} et Y={B, C}. Le résultat de la division est R/S de schéma {A} ; la concaténation de a1 avec (b1 c1) et avec (b2 c1) appartient effectivement à R. La division n’est généralement pas implantée en SQL.

Exercices (1) Heures de départ des avions pour Madrid PROJECTION( SELECTION( VOL, ARRIVEE='Madrid'), HDEP)

Exercices (2) Types des avions fabriqués par Boeing PROJECTION( SELECTION( AVION, TYPE LIKE 'Boeing%'), TYPE)

Exercices (3) Numéros des vols qui partent le 15/05/2004 PROJECTION( SELECTION( VOL, VOL.JDEP={d  ’2004-05-15'}), VOL.NUMVOL)

Exercices (4) Vols pilotés par Dupuis PROJECTION( SELECTION( JOINTURE( PILOTE, VOL, PILOTE.NUMPILOTE = VOL.NUMPIL), PILOTE.NOM='Dupuis'), VOL.NUMVOL)

Exercices (5) Capacités des avions pilotés par le pilote P0002 PROJECTION( SELECTION( JOINTURE( AVION, VOL, VOL.NUMAV=AVION.NUMAVION), VOL.NUMPIL='P0002'), AVION.CAP)

Capacité des avions partant ou arrivant à Paris PROJECTION Exercices (6) Capacité des avions partant ou arrivant à Paris PROJECTION (SELECTION( JOINTURE(AVION, VOL, AVION.NUMAVION =VOL.NUMAV), VOL.DEPART='Paris') UNION SELECTION( AVION.NUMAVION = VOL.NUMAV), VOL.ARRIVEE='Paris')), AVION.CAP)

Capacités des avions pilotés par Dupuis PROJECTION( Exercices (7) Capacités des avions pilotés par Dupuis PROJECTION( SELECTION( JOINTURE( JOINTURE(AVION, VOL, AVION.NUMAVION = VOL.NUMAV), PILOTE, PILOTE.NUMPILOTE = VOL.NUMPIL), PILOTE.NOM='Dupuis'), AVION.CAP)

Application à la base de données FILMS (1) FILM1 : Films où joue Léaud ? En algèbre relationnelle R1 : Selection(acteur, acteur.NOM='Léaud') R2 : Jointure(R1, joue, R1.CODE = joue.CODEACTEUR ) R3 : Jointure(film, R2, film.CODE=R2.CODEFILM) FILM1 : Projection(R3, R3.TITRE) En SQL SELECT film.TITRE projection FROM acteur acteur, film film, joue joue WHERE (acteur.NOM='Léaud') sélection AND joue.CODEACTEUR = acteur.CODE jointure AND joue.CODEFILM = film.CODE jointure

Application à la base de données FILMS (2) FILM2 : Acteurs du film “ La nuit américaine ” ? En algèbre relationnelle R1 : Selection(film, film.TITRE='La nuit américaine') R2 : Jointure(R1, joue, R1.CODE=joue.CODEFILM) R3 : Jointure(R2, acteur, R2.CODEACTEUR = acteur.CODE) FILM2 : Projection(R3, R3.NOM, R3.PRENOM) En SQL SELECT acteur.NOM, acteur.PRENOM projection FROM acteur acteur, film film, joue joue WHERE (film.TITRE='La nuit américaine') sélection AND joue.CODEACTEUR = acteur.CODE jointure AND joue.CODEFILM = film.CODE jointure

Application à la base de données FILMS (3) FILM3 : Films de plus de 120 min réalisés par un réalisateur américain ? En algèbre relationnelle R1 : Selection(film, film.DUREE>120) R2 : Selection(realis, realis.PAYS=’USA’) R3 : Jointure(R1, R2, R1.REALIS=R2.CODE) FILM3 : Projection(R3, R3.TITRE) En SQL SELECT film.TITRE projection FROM film film, realis realis WHERE (film.DUREE>120) sélection AND (realis.PAYS='USA') sélection AND film.REALIS = realis.CODE jointure

Application à la base de données FILMS (4) FILM4 : Acteurs qui sont réalisateurs ? En algèbre relationnelle R1 : Jointure(realis, acteur, realis.NOM=acteur.NOM) R2 : Sélection(R1, R1.PRENOM(realis)=R1.PRENOM(acteur)) FILM4 : Projection(R2, R2.NOM, R2.PRENOM) En SQL SELECT acteur.NOM, acteur.PRENOM projection FROM acteur acteur, realis realis WHERE acteur.NOM = realis.NOM jointure AND (acteur.PRENOM = realis.PRENOM) sélection

Application à la base de données FILMS (5) FILM5 : Titres des films réalisés par des réalisateurs qui sont acteurs dans leur film ? En algèbre relationnelle R1 : Jointure(realis, film, realis.CODE=film.REALIS) R2 : Jointure(R1, acteur, R1.NOM=acteur.NOM) R3 : Sélection(R2, R2.PRENOM(realis)=R2.PRENOM(acteur)) R4 : Jointure(R3, joue, R3.CODE(acteur)=joue.CODEACTEUR) R5 : Sélection(R4, R4.CODEFILM=R4.CODE(film)) FILM5 : Projection(R4, R4.TITRE)

Application à la base de données FILMS (6) En SQL SELECT film.TITRE projection FROM acteur acteur, film film, joue joue, realis realis WHERE realis.CODE = film.REALIS jointure AND realis.NOM = acteur.NOM jointure AND (realis.PRENOM = acteur.PRENOM) sélection AND acteur.CODE = joue.CODEACTEUR jointure AND joue.CODEFILM = film.CODE sélection

Application à la base de données FILMS (7) FILM6 : Films réalisés par des Américains ou de durée inférieure à 95 min ? En algèbre relationnelle R1 : Selection(realis, realis.PAYS=’USA’) R2 : Jointure(R1, film, R1.CODE=film.REALIS) R3 : Projection(R2, R2.TITRE) R4 : Selection(film, film.DUREE<95) R5 : Projection(R4, R4.TITRE) FILM6 : R3 UNION R5

Application à la base de données FILMS (8) En SQL SELECT film.TITRE projection FROM film, realis WHERE (realis.PAYS='USA') sélection AND film.REALIS = realis.CODE jointure UNION union SELECT film1.TITRE projection FROM film film1 WHERE (film1.duree < 95) sélection

Application à la base de données FILMS (9) FILM7 : Acteurs qui jouent dans des films où joue Arditi ? En algèbre relationnelle   R1 : SELECTION(acteur, acteur.NOM='Arditi') R2 : JOINTURE(R1, joue, R1.CODE=joue.CODEACTEUR) R3 : SELECTION(acteur, acteur.NOM<>'Arditi') R4 : JOINTURE(R3, joue, R3.CODE=joue.CODEACTEUR) R5 : JOINTURE(R2, R4, R2.CODEFILM=R4.CODEFILM) FILM7 : PROJECTION(R5, R5.NOM(R3))

Application à la base de données FILMS (10) 1ère Solution SQL SELECT DISTINCT acteur.NOM FROM acteur acteur, acteur arditi, joue joue, joue jouard WHERE arditi.NOM = 'Arditi' AND arditi.CODE = jouard.CODEACTEUR AND acteur.NOM <> 'Arditi' AND acteur.CODE = joue.CODEACTEUR AND jouard.CODEFILM = joue.CODEFILM

Application à la base de données FILMS (11) 2ème Solution SQL SELECT acteur.NOM FROM acteur acteur, film film, joue joue WHERE film.CODE = joue.CODEFILM AND joue.CODEACTEUR = acteur.CODE AND (acteur.NOM<>'Arditi') AND film.CODE IN (SELECT film1.CODE FROM acteur acteur1, film film1, joue joue1 WHERE joue1.CODEACTEUR = acteur1.CODE AND joue1.CODEFILM = film1.CODE AND (acteur1.NOM='Arditi'))

Application à la base de données FILMS (12) FILM8 : Acteurs qui jouent dans tous les films de Truffaut ? En algèbre relationnelle R1 : Selection(realis, realis.NOM=’Truffaut’) R2 : Jointure(R1, film, R1.CODE=film.REALIS) R3 : Projection(R2, R2.CODE(film)) R4 : Division(joue, R3) R5 : Jointure(acteur, R4, R4.CODEACTEUR=acteur.CODE) FILM8 : Projection(R5, acteur.NOM) En SQL Non traduisible directement. Dans certains SQL, on peut utiliser une formulation équivalente à la division n'utilisant que la différence et le produit cartésien.

Application à la base de données TENNIS (1) Soit la base TENNIS comportant les relations : JOUEUR(numjoueur, nom, prénom, date_naissance, nationalité) RENCONTRE(numgagnant, numperdant, lieu_tournoi, année, score) GAIN(numjoueur, lieu_tournoi, année, prime, nom_sponsor) SPONSOR(nom, adresse, chiffre_affaires) et où : - numgagnant et numperdant sont définis sur le même domaine que numjoueur - dès qu’il participe à un tournoi, un joueur touche une prime.

Application à la base de données TENNIS (2) Formuler en français la relation R définie par : Q1 =Sélection(SPONSOR, chiffre_affaires > 1000) Q2 =Jointure(GAIN, Q1, nom_sponsor = nom) Q3 =Jointure(Q2, Sélection(RENCONTRE, année>1990), numgagnant = numjoueur) Q4 =Jointure(Q3, Sélection(JOUEUR, nationalité=France), numjoueur=numgagnant) R =Projection(Q4, nom, prénom)

Fonctionnalités des SGBD relationnels

Fonctionnalités des SGBD relationnels (1) Un SGBD est dit relationnel s’il respecte une norme composée de trois conditions : toutes les informations sont représentées par des valeurs contenues dans des relations (tables). l’utilisateur n’a pas à établir des pointeurs entre les relations (les jointures établissent ces relations). le SGBD permet la sélection d’occurrences (sélection), la sélection d’attributs (projection) et l’opération de jointure.

Fonctionnalités des SGBD relationnels (2) Un SGBD relationnel est dit totalement relationnel s’il respecte en outre les deux conditions suivantes : il permet d’utiliser les (autres) opérateurs de l’algèbre relationnelle (excepté la division). il permet de prendre en compte la contrainte d’unicité des clés et l’intégrité référentielle. Query est un SGBD relationnel, mais pas totalement relationnel car il ne gère pas les clés et ne respecte pas l’intégrité référentielle. ACCESS est totalement relationnel (problème d’unicité des clefs et d’intégrité référentielle à gérer).

Base et métabase Une base de données comporte des relations, dont les descriptions sont elles-mêmes mémorisées dans une base de données appelée métabase. Si on crée une nouvelle relation, on agit sur la métabase ; si on crée une occurrence d’une relation, on agit sur la base. Des mots différents sont employés par SQL pour différencier la base destinataire : ainsi, CREATE crée une relation et agit donc sur la métabase, tandis qu’INSERT crée une occurrence et agit sur la base.

Gestion de la métabase : création de relations La plupart des SGBD permettent de créer les relations de manière interactive à l’aide de fenêtres de dialogue et d’assistants (Query, Access). La création d’une relation est cependant prévue en SQL via l’instruction CREATE TABLE (mySQL). Lors de la création d’une relation, de nombreux SGBD imposent de préciser le (les) attribut(s) clé (Access, mySQL). Une relation peut avoir une clé principale (un ou plusieurs attributs) et d’autres clés secondaires. La clé principale assure qu’il est impossible de donner la même clé à deux occurrences différentes de la même relation.

Gestion de la métabase : : gestion des clés Si la déclaration de la relation est faite directement en SQL (mySQL), la clé principale est signalée par PRIMARY KEY et les clés secondaires par UNIQUE : CREATE TABLE Etudiant num_etudiant NUMBER(6) NOT NULL, PRIMARY KEY, nom CHAR(20), adresse CHAR(30), date_naissance DATE, code_diplôme NUMBER(3), num_ss NUMBER(13) UNIQUE ;

Gestion de la métabase : gestion des clés Si l’on souhaite que la clé principale soit composée de plusieurs attributs, elle doit alors être définie à la fin de l’instruction de la manière suivante : CREATE TABLE Etudiant num_etudiant NUMBER(6) NOT NULL, nom CHAR(20), adresse CHAR(30), date_naissance DATE, code_diplôme NUMBER(3), num_ss NUMBER(13) NOT NULL, PRIMARY KEY(num_etudiant, num_ss) ;

Gestion de la métabase : intégrité référentielle Lorsque les relations sont créées, les jointures naturelles entre ces relations doivent être déclarées - avant d’effectuer une requête (Access) ou dans la requête (Query, mySQL). L’intégrité référentielle est respectée si, lors de la création d’une occurrence d’une relation dont un attribut fait référence à un attribut clé d’une autre relation, la valeur correspondante de ce dernier attribut est déjà définie. Exemple : puisqu’une occurrence de la relation VOL  comporte les attributs numav et numpil, cette occurrence ne peut être créée que si les occurrences de PILOTE et AVION auxquelles elle fait référence existent déjà.

Gestion de la métabase : intégrité référentielle Il faut donc (par exemple) que l’occurrence de PILOTE et que l’occurrence de AVION existent avant que l’on puisse créer l’occurrence de VOL.

Gestion de la métabase : modification de relations On peut généralement modifier une relation par des fenêtres de dialogue (manière graphique). Mais SQL permet de modifier une relation par l’instruction ALTER, suivie d’une spécification de l’opération à effectuer. L’ajout d’un attribut est déclaré par le mot-clé ADD, la modification d’un attribut par MODIFY : ALTER TABLE Etudiant ADD (moyenne NUMBER(2)) ; ALTER TABLE Etudiant MODIFY adresse CHAR(100) ; La suppression d’une relation se fait par DROP TABLE Exemple : DROP TABLE Etudiant ;

Insertion, suppression et modification d’occurrences Gestion de la base Insertion, suppression et modification d’occurrences L’insertion d’une occurrence par SQL se fait grâce à INSERT : INSERT INTO TABLE Etudiant VALUES (.., …,…,…) La suppression d’une occurrence se fait par DELETE : DELETE FROM TABLE Etudiant WHERE num_etudiant = … (valeur de la clé précisée) La modification d’une occurrence se fait par UPDATE : UPDATE Etudiant SET adresse=… WHERE num_etudiant = …

Dépendances et normalisation (1)

Qu’est-ce que la normalisation ? Normaliser une relation consiste à la représenter sous une forme qui respecte certains critères assurant l’intégrité des données (correspondance au réel) et évitant au concepteur de la base des erreurs graves La théorie de la normalisation propose des méthodes systématiques visant à assurer la cohérence de cette représentation.

Nécessité de la normalisation (1) Soit la relation R (produit, client, adresse, date, quantité_commandée, montant) Cette relation pose des problèmes...

Nécessité de la normalisation (2) L’adresse du client est répétée autant de fois qu’il y a de commandes  redondance des informations

Nécessité de la normalisation (3) Si l’adresse change, il faut modifier la base à plusieurs endroits  anomalie de modification

Nécessité de la normalisation (4) Si on insère la ligne (Disquettes, Dubois, Dijon, 10/03/01, 100, 200), Dubois aura deux adresses  anomalie d’insertion

Nécessité de la normalisation (5) Si Martin annule sa commande, on perd son nom et son adresse…  anomalie de suppression

Nécessité de la normalisation (6) Cette relation n’est donc pas cohérente, alors que la base formée des trois relations : R1 (code_client, nom_client, adresse) R2 (code_produit, nom_produit, prix_unitaire) R3(code_commande, code_client, date, code_produit, quantité) n’aura aucun problème de cohérence.

Nécessité de la normalisation (7)

But de la normalisation Fixer des règles permettant de passer de la première représentation (incohérente) à la deuxième (cohérente).

Dépendances fonctionnelles (1) Une dépendance fonctionnelle (DF) traduit le fait qu’à une valeur d’une donnée, on associe dans une relation, à un instant donné, une valeur au plus d’une autre donnée. Exemple Dans la relation VOL, à une certaine date, un vol ne peut être associé qu’à un seul pilote. Il y a une DF entre (NUMVOL, JDEP) et NUMPIL. On écrit (NUMVOL, JDEP)  NUMPIL (NUMVOL, JDEP) est la source de la DF, NUMPIL en est le but.

Dépendances fonctionnelles (2) Remarque Il s’agit bien d’une dépendance, car s’il existe une occurrence où NUMVOL = V0010, JDEP=15/5/2004 et NUMPIL = P0005, alors on ne peut pas introduire une nouvelle occurrence où NUMVOL = V0010, JDEP=15/5/2004 et NUMPIL = P0001 sans supprimer la première (problème de l’unicité de la clé).

Clé d’une relation : définition Lorsque, dans une relation, un attribut ou un groupe d’attributs est source de plusieurs DF ayant respectivement pour buts chacun des autres attributs de la relation, cet attribut ou ce groupe d’attributs est appelé clé de la relation. Un attribut est appelé attribut clé s’il fait partie d’au moins une clé. Un attribut est dit attribut non clé s’il ne participe à aucune clé.

Clé d’une relation : exemples Dans la relation PILOTE (numpilote, nom, prenom), on a deux DF de source NUMPILOTE : NUMPILOTE  NOM NUMPILOTE  PRENOM NUMPILOTE est donc bien la clé de la relation PILOTE et le seul attribut clé.

Clé d’une relation : exemples Dans la relation VOL (numvol, depart, arrivee, numav, numpil, jdep, hdep, jarr, harr), on a sept DF de source (NUMVOL, JDEP) : (NUMVOL, JDEP)  DEPART (NUMVOL, JDEP)  ARRIVEE (NUMVOL, JDEP)  NUMAV (NUMVOL, JDEP)  NUMPIL (NUMVOL, JDEP)  HDEP (NUMVOL, JDEP)  JARR (NUMVOL, JDEP)  HARR Le couple (NUMVOL, JDEP) est donc bien la clé de la relation VOL. Il y a donc deux attributs clé.

Dépendance fonctionnelle élémentaire et directe Soit X un groupe d’attributs et Y un attribut unique n’appartenant pas à X. La DF X  Y est dite élémentaire si aucun sous- ensemble de X ne suffit pour être source de la DF (X est donc la plus petite quantité d’information permettant de déduire Y). Une DF de source A et de but B est dite directe s’il n’existe pas d’attribut C tel que A  C et C  B.

Propriétés des dépendances fonctionnelles Les règles d’Amstrong Réflexivité : si X est inclus dans Y, alors Y  X Augmentation : si X  Y alors X, W  Y, W Transitivité : si X  Y et Y  Z alors X  Z Les règles qui s’en déduisent Union : si X  Y et X  Z alors X  Y, Z Décomposition : si X  Y, Z alors X  Y et X  Z Pseudo-transitivité : si X  Y et W,Y  Z alors X,W  Z

Première forme normale : définition Une relation est dite normalisée ou en première forme normale (1 FN) si un même attribut n’est pas représenté plusieurs fois et si un attribut n’est pas décomposable en d’autres attributs. Exemple de relation non normalisée - l’attribut enfants est décomposable en deux attributs, - Les attributs diplôme et enfant sont représentés plusieurs fois pour une même personne.

Première forme normale : exemple La relation VENTE(num_client, num_article, nom_client, nom_article) où (num_client, num_article) est la clé, est en première forme normale. Les dépendances fonctionnelles sont : (num_client, num_article)  nom_client (num_client, num_article)  nom_article.

Première forme normale : inconvénients Certaines DF élémentaires qui devraient exister, telles que : num_client  nom_client, num_article  nom_article n’existent pas, ce qui permet d’introduire sans détecter d’anomalies les trois occurrences : (23, A10, Durand, lit) (23, A15, Laurent, table) (35, A10, Michel, table). Dans ce cas, A10 correspond à des articles différents : lit et table, tandis que 23 correspond à des clients différents : Durand et Laurent.

Deuxième forme normale : définition Une relation est en deuxième forme normale (2 FN) si elle est en 1 FN et si toutes les DF issues de la clé sont élémentaires. Exemple de relation qui n’est pas en 2 FN VENTE(num_client, num_article, nom_client, nom_article) est en 1 FN, mais pas en 2 FN car des deux DF : (num_client, num_article)  nom_client (num_client, num_article)  nom_article on peut extraire les DF élémentaires : num_client  nom_client num_article  nom_article.

Deuxième forme normale : exemple La relation REPRESENTANT(num_client, nom_client, num_représentant, nom_représentant) où num_client est la clé, est en 2 FN car les trois DF qui en découlent : num_client  nom_client num_client  num_représentant num_client  nom_représentant sont toutes les trois élémentaires.

Deuxième forme normale : inconvénients Il existe une DF « naturelle » num_représentant  nom_représentant. La DF num_client  nom_représentant n’est alors pas directe, puisqu’on a : num_client  num_représentant  nom_représentant On peut dès lors introduire les deux occurrences  (10, Berger, R10, Dupuis) (11, Dupont, R10, Durand) sans détecter d’erreur, alors que deux représentants différents, Dupuis et Durand, ont le même numéro.

Troisième forme normale : définition Une relation est en troisième forme normale (3 FN) si elle est en deuxième forme normale (2 FN) et si toutes les DF issues de la clé sont directes. Alors - aucune DF n’est issue d’un sous-ensemble de la clé. - aucune DF n’est issue d’un attribut non clé vers un autre attribut non clé.

Troisième forme normale : démonstration (1) « Aucune DF n’est issue d’un sous-ensemble de la clé. » En effet, si X, Y, Z forment la clé et s’il existe une DF : Y  U alors : X, Y, Z  Y  U et la DF X, Y, Z  U n’est donc pas directe.

Troisième forme normale : démonstration (2) « Aucune DF n’est issue d’un attribut non clé vers un autre attribut non clé. » En effet, si X, Y forment la clé et s’il existe une DF : Z  U (Z et U non clés) alors : X, Y  Z  U et la DF X, Y  U n’est donc pas directe.

Troisième forme normale : exemples Les relations CLIENT(num_client, nom_client, adresse) et VENTE(num_commande, num_article, quantité) sont en 3 FN. On a les DF élémentaires et directes : num_client  nom_client num_client  adresse num_commande, num_article  quantité.

Dépendances et normalisation (2)

Rappels Une relation est en 1 FN si un même attribut n’est pas représenté plusieurs fois et si un attribut n’est pas décomposable en d’autres attributs. Une relation est en 2 FN si elle est en 1 FN et si toutes les DF issues de la clé sont élémentaires (aucun sous-ensemble de la clé ne suffit pour être source de la DF). Une relation est en 3 FN si elle est en 2 FN et si toutes les DF issues de la clé sont directes.

Exemples (1) R1(num_client, num_produit, nom_produit, quantité_commandée) R1 est en 1 FN. DF issues de la clef : num_client, num_produit  nom_produit num_client, num_produit  quantité_commandée La DF num_client, num_produit  nom_produit n’est pas élémentaire, car il existe une DF : num_produit  nom_produit. Donc R1 est uniquement en 1FN.

Exemples (2) R2(num_commande, num_produit, quantité_commandée) R2 est en 1 FN. num_commande, num_produit  quantité_commandée est une DF élémentaire. Donc R2 est en 2 FN. C’est la seule DF issue de la clé et elle est directe. Donc R2 est en 3FN.

Exemples (3) R3(num_client, nom_client, nom_représentant) R3 est en 1 FN. Les deux DF : num_client  nom_client num_client  nom_représentant sont élémentaires et directes. Donc R3 est en 3FN.

Exemples (4) R4(num_produit, nom_produit, num_atelier, chef_atelier) R4 est en 1 FN. Les DF : num_produit  nom_produit num_produit  num_atelier num_produit  chef_atelier sont élémentaires. Donc R4 est en 2 FN. num_produit  chef_atelier n’est pas directe : num_produit num_atelier et num_atelier chef_atelier. Donc R4 n’est pas en 3 FN.

Exemples (5) R5(num_client, nom_client, num_représentant, nom_représentant) R5 est en 1 FN. Les DF : num_client  nom_client num_client  num_représentant num_client  nom_représentant sont élémentaires. Donc R5 est en 2 FN. num_client  nom_représentant n’est pas directe : num_client  num_représentant  nom_représentant. Donc R5 est en 2FN.

Exemples (6) R6 (num_produit, num_fournisseur, nom_fournisseur, prix) R6 est en 1 FN. DF issues de la clef : num_produit, num_fournisseur  nom_fournisseur num_produit, num_fournisseur  prix La DF num_produit, num_fournisseur  nom_fournisseur n’est pas élémentaire, car il existe une DF : num_fournisseur  nom_fournisseur. R6 n’est donc pas en 2 FN.

Exemples (7) R7(produit, client, adresse, quantite_commandée, montant) R7 est en 1 FN. DF issues de la clef : produit, client  adresse produit, client  quantité_commandée produit, client  montant La DF produit, client  adresse n’est pas élémentaire, car il existe une DF : client  adresse. Donc R7 n ’est pas en 2 FN.

Exercice (1) Soit la relation : R(propriétaire, occupant, adresse, num_appart, nb_pièces, nb_personnes) La création d’une occurrence (p, o, a, n, n1, n2) traduit le fait que la personne o habite avec n2 personnes l’appartement numéro n à l’adresse a, ayant n1 pièces et de propriétaire p.

Exercice (2) Un certain nombre de dépendances fonctionnelles ont déjà été identifiées : (1) occupant  adresse (2) occupant  num_appart (3) occupant  nb_personnes (4) adresse, num_appart  propriétaire (5) adresse, num_appart  occupant (6) adresse, num_appart  nb_pièces On demande de déterminer l’ensemble des DF élémentaires engendrées par cet ensemble de DF.

Exercice (3) Rappels Règles d’Amstrong (a) Réflexivité : si X est inclus dans Y, alors Y  X (b) Augmentation : si X  Y alors X, W  Y, W (c) Transitivité : si X  Y et Y  Z alors X  Z Règles qui s’en déduisent (d) Union : si X  Y et X  Z alors X  Y, Z (e) Décomposition : si X  Y, Z alors X  Y et X  Z (f) Pseudo-transitivité : si X  Y et W,Y  Z alors X,W  Z

(1) occupant  adresse Exercice (4) (2) occupant  num_appart (d) si X  Y et X  Z alors X  Y, Z Conséquence : (7) occupant  adresse, num_appart

Exercice (5) (7) occupant  adresse, num_appart (4) adresse, num_appart  propriétaire (c) si X  Y et Y  Z alors X  Z Conséquence : (8) occupant  propriétaire

Exercice (6) (7) occupant  adresse, num_appart (6) adresse, num_appart  nb_pièces (c) si X  Y et Y  Z alors X  Z Conséquence : (9) occupant  nb_pièces

Exercice (7) (1) occupant  adresse (2) occupant  num_appart (3) occupant  nb_personnes (8) occupant  propriétaire (9) occupant  nb_pièces (d) si X  Y et X  Z alors X  Y, Z Conséquence : (10) occupant  adresse, num_appart, nb_personnes, propriétaire, nb_pièces

(5) adresse, num_appart  occupant Exercice (8) (5) adresse, num_appart  occupant (3) occupant  nb_personnes (c) si X  Y et Y  Z alors X  Z Conséquence : (11) adresse, num_appart  nb_personnes

(4) adresse, num_appart  propriétaire Exercice (9) (4) adresse, num_appart  propriétaire (5) adresse, num_appart  occupant (6) adresse, num_appart  nb_pièces (11) adresse, num_appart  nb_personnes (d) si X  Y et X  Z alors X  Y, Z Conséquence : (12) adresse, num_appart  propriétaire, occupant, nb_pièces, nb_personnes

Exercice (10) Déterminer les clés potentielles de R. Il y a deux clés potentielles : - occupant car on a la DF : (10) occupant  adresse, num_appart, nb_personnes, propriétaire, nb_pièces - adresse, num_appart car on a la DF : (12) adresse, num_appart  propriétaire, occupant, nb_pièces, nb_personnes

Exercice (11) On aura donc soit : R(occupant, propriétaire, adresse, num_appart, nb_pièces, nb_personnes) soit : R(adresse, num_appart, propriétaire, occupant, Attributs clés : occupant, adresse, num_appart Attributs non clés : nb_personnes, propriétaire, nb_pièces

Modèle entité-association

Modèle entité-association C’est un modèle de représentation de l’information, permettant de comprendre et de visualiser l’organisation des données, mais qui n’est pas destiné directement à l’implémentation de ces données. Lors de la conception d’une base de données, on commence par réaliser un modèle entité-association que l’on transforme ensuite en modèle relationnel normalisé, implémentable.

Concepts de base (1) Une entité est un objet ayant une existence propre présentant un intérêt pour l’entreprise : le client Dupuis, le fournisseur Durand, etc. Un type d’entité est une classe d’entités ayant en commun un ensemble de propriétés : Client, Fournisseur, etc. Type d’entité Objet (entité) client client

Concepts de base (2) Une association est un lien entre entités. Elle représente un verbe matérialisant une relation entre entités. Un type d’association est un lien-type abstrait entre types d’entités : “achète” est un type d’association entre les types d’entités Client et Fournisseur.

Concepts de base (3) Une propriété est une caractéristique d’une entité ou d’une association d’entités. Exemple : adresse est une propriété des entités de type Client et de type Fournisseur. Le type d’une propriété peut être simple (mois, prix, etc) ou composé (date, adresse).

Concepts de base (4) Un identifiant est une propriété particulière permettant de distinguer entre elles les occurrences d’une entité ou d’un type d’association. La relation entre chaque entité ou association avec son identifiant doit être bijective. L’identifiant est souvent utilisé comme clé.

Concepts de base (5) Un type d’entité est entièrement défini par son nom, son identifiant et ses propriétés. Exemple : Client identifiant : num_client propriétés : nom_client, adresse L’identifiant d’un type d’association est obtenu en concaténant les identifiants des types d’entité concernés par l’association. Exemple : “achète” identifiant : num_client, num_fournisseur

Cardinalités (1) Cardinalité d’une entité dans une association : nombre de fois minimum et nombre de fois maximum qu’une même occurrence de l’entité peut intervenir dans les occurrences de l’association : minimum maximum 0 l’occurrence peut ne pas participer 1 l’occurrence participe l’occurrence peut participer obligatoirement au plus une fois n (ou ) l’occurrence peut participer plusieurs fois

Cardinalités (2) Type d’association “achète” Un client achète à un nombre de fournisseurs allant de 0 à n. Un fournisseur a de 0 à n clients qui achètent ses produits. Le type d’association “achète” a ainsi deux “pattes” de cardinalités minimales 0 et de cardinalités maximales n.

Cardinalités (3) Type d’association “propriétaire” Une personne peut ne pas avoir d’appartement (0) ou être propriétaire de plusieurs appartements (n). Un appartement est possédé par au moins une personne (1), et peut l’être par plusieurs personnes (n). Le type d’association “propriétaire” a ainsi deux pattes de cardinalités maximales égales à n.

Cardinalités (4) Type d’association “ commande ” Une commande est passée par un et un seul client. Un client passe de 0 à n commandes Une commande concerne un ou plusieurs articles. Un article participe à 0 à n commandes.

Cardinalités (5) A remarquer : Le type d’association “passée par” a une patte de cardinalité maximale égale à 1, qui traduit le fait qu’une commande particulière ne peut être passée que par un et un seul client. Tout type d’association ayant une patte de cardinalité maximale égale à 1 est une dépendance fonctionnelle (DF).

Cardinalités (6) Type d’association “ enseignement ” Un élève suit de 1 à n unités de valeurs. Une UV est suivie par un nombre d’élèves allant de 0 à n. Une UV est enseignée par un et un seul professeur. Un professeur enseigne de 1 à n UV.

Cardinalités (7) A remarquer : Le type d’association “enseignant” a une patte de cardinalité maximale 1, qui traduit le fait qu’une UV ne peut être enseignée que par un et un seul enseignant. C’est donc une dépendance fonctionnelle.

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).

Applications

Application à l’édition de livres (1) Dictionnaire des données : Numéro ISBN du livre Titre du livre Numéro de l’auteur Nom de l’auteur Numéro de l’éditeur Nom de l’éditeur Année d’édition Quantité en stock par éditeur et par dépôt Numéro de dépôt Nom du dépôt

Application à l’édition de livres (2) Informations à noter pour les cardinalités : Un livre peut être écrit par plusieurs auteurs Un livre peut être édité par plusieurs éditeurs, mais une seule fois par chacun d’entre eux Un livre peut être stocké dans plusieurs dépôts, et cela pour chaque éditeur.

Application à l’édition de livres (3) Les types d’entités sont : LIVRE, AUTEUR, EDITEUR et DEPOT. Propriétés d’un LIVRE : num_livre, titre Propriétés d’un AUTEUR : num_auteur, nom_auteur Propriétés d’un EDITEUR : num_éditeur, nom_éditeur Propriétés d’un DEPOT : num_dépôt, nom_dépôt

Application à l’édition de livres (4) Les types d’association sont : ECRIRE, EDITER, STOCKER ECRIRE relie un livre et un auteur EDITER relie un livre et un éditeur Propriété : année_édition. STOCKER relie un livre, un éditeur et un dépôt Propriété : quantité_stock.

Application à l’édition de livres (5)

Application à l’édition de livres (6) Les relations provenant des types d’entités sont : LIVRE(num_livre, titre) AUTEUR(num_auteur, nom_auteur) EDITEUR(num_éditeur, nom_éditeur) DEPOT(num_dépôt, nom_dépôt)

Application à l’édition de livres (7) Celles issues des types d’association sont : ECRITURE(num_livre, num_auteur) EDITION(num_livre, num_éditeur, année d’édition) STOCK(num_livre, num_éditeur, num_dépôt, quantité_stock).

Application à une bibliothèque (1) Gestion d ’une bibliothèque Une bibliothèque enregistre chaque lecteur à qui elle donne un numéro de lecteur. Elle note son nom et son adresse. Le lecteur peut éventuellement être membre d’une société adhérente ; on enregistre alors l’identification de cette société. Un lecteur peut emprunter plusieurs livres chaque jour. A chaque prêt, on enregistre une date de retour. Un lecteur appartient à un type de lecteur, qui lui permet ou non d’avoir accès à certaines catégories de livres.

Application à une bibliothèque (2) La durée du prêt dépend de la catégorie du livre et du type de lecteur. Elle est la même pour tous les livres d’une catégorie donnée, empruntés par un lecteur quelconque d’un type donné. Un livre est caractérisé par un numéro d’inventaire. Il est nécessaire de connaître sa catégorie, le nom de son auteur, de son éditeur, ainsi que le nombre d’exemplaires disponibles. La catégorie d’un livre se repère par un numéro et possède un libellé. Il en est de même pour le type de lecteur. Une société adhérente possède un nom et une adresse ; elle s’engage à envoyer un minimum de 500 lecteurs.

Application à une bibliothèque (3) Dictionnaire des données : Numéro de lecteur Nom du lecteur Adresse du lecteur Date de retour de prêt Numéro d’inventaire du livre Nom de l’auteur Nom de l’éditeur Nombre d’exemplaires disponibles Numéro de catégorie de livre Libellé de catégorie Numéro de type de lecteur Libellé de type de lecteur Numéro de la société adhérente Nom de société adhérente Adresse de société adhérente

Application à une bibliothèque (4) Les types d’entités sont : LECTEUR, TYPE_LECTEUR, SOCIETE_ADHERENTE, LIVRE, CATEGORIE_LIVRES Propriétés d’un LECTEUR : numéro de lecteur, nom du lecteur, adresse du lecteur Propriétés d’une SOCIETE_ADHERENTE : numéro de la société, nom de la société, adresse de la société

Application à une bibliothèque (5) Propriétés d’un LIVRE : numéro d’inventaire, nom de l’auteur, nom de l’éditeur, nombre d’exemplaires disponibles Propriétés d’une CATEGORIE_LIVRES : numéro de catégorie, libellé de catégorie Propriétés d’un TYPE_LECTEUR : numéro de type, libellé de type

Application à une bibliothèque (6) Il y a cinq types d’associations : APPARTIENT entre un livre et une catégorie de livres MEMBRE entre un lecteur et une société adhérente. APPARTIENT entre un lecteur et un type de lecteur. A_ACCES entre un type de lecteur et une catégorie de livres. Propriété : durée du prêt EMPRUNTE entre un lecteur et un livre. Propriétés : date, date de retour.

Application à une bibliothèque (7)

Application à une bibliothèque (8) Les types d’association : APPARTIENT entre un lecteur et un type de lecteur et MEMBRE entre un lecteur et une société adhérente sont des DF. Ils sont donc matérialisés par l’ajout des attributs num_type et num_société dans la relation LECTEUR, source des deux DF.

Application à une bibliothèque (9) Le type d’association : APPARTIENT entre un livre et une catégorie de livre est aussi une DF. Il est donc matérialisé par l’ajout de l’attribut num_catégorie dans la relation LIVRE, source de la DF.

Application à une bibliothèque (10) Les relations provenant des types d’entités sont donc : SOCIETE_ADHERENTE(num_société, nom, adresse) TYPE_LECTEUR(num_type, libellé) LECTEUR(num_lecteur, nom, adresse, num_type*, num_société*) CATEGORIE_LIVRE(num_catégorie, libellé) LIVRE(num_inventaire, nom_auteur, nom_éditeur, nb_exemplaires, num_catégorie*)

Application à une bibliothèque (11) auxquelles s’ajoutent les deux relations issues des types d’association : ACCES(num_type, num_catégorie) issue du type d’association A_ACCES PRÊT(num_lecteur, num_inventaire, date, date_retour) issue du type d’association EMPRUNTE

Application à la gestion d’une cinémathèque (1) Une cinémathèque stocke des bobines de films qu’elle loue à des ciné-clubs abonnés. Chaque ciné-club abonné, qui a un nom et une adresse, a un numéro d’identification. Chaque film a une référence, un titre, une durée et un nombre d’exemplaires disponibles. Les films sont classés en catégories, un film n’appartenant qu’à une seule catégorie. Une catégorie a un numéro et un intitulé. Un ciné-club ne peut pas emprunter plus de 3 films simultanément, la location d’un film étant concédée pour un certain nombre de jours, dépendant de sa catégorie.

Application à la gestion d’une cinémathèque (2) Chaque film a un réalisateur et plusieurs acteurs principaux. Un réalisateur a un numéro, un nom, un prénom et une nationalité. Un acteur a un numéro, un nom et un prénom. Un film peut avoir été primé lors de certaines manifestations (Palme d’Or au festival de Cannes, Ours d’Argent au festival de Berlin, etc). Dans ce cas, la ville, l’intitulé et l’année de la récompense sont mémorisés, et un numéro est attribué à cette récompense. Une récompense peut ne pas être attribuée, être attribuée à un seul film ou être attribuée à deux films ex-aequo.

Application à la gestion d’une cinémathèque (3) Dictionnaire des données : Numéro du ciné-club Nom du ciné-club Adresse du ciné-club Référence du film Titre de film Durée de film Nombre d’exemplaires de film Numéro de catégorie Intitulé de catégorie Numéro de réalisateur Nom de réalisateur Prénom de réalisateur Nationalité de réalisateur Numéro d’acteur Nom d’acteur Prénom d’acteur Numéro de récompense Ville de récompense Intitulé de récompense Année de récompense

Application à la gestion d’une cinémathèque (4) Les types d’entités sont : CINE_CLUB, FILM, CATEGORIE, REALISATEUR, ACTEUR, RECOMPENSE. Propriétés de CINE_CLUB : numéro, nom, adresse Propriétés de FILM : référence, titre, durée, nombre_exemplaires

Application à la gestion d’une cinémathèque (5) Propriétés de CATEGORIE: numéro, intitulé Propriétés de REALISATEUR : numéro, nom, prénom, nationalité Propriétés de ACTEUR : numéro, nom, prénom Propriétés de RECOMPENSE : numéro, ville, intitulé, année

Application à la gestion d’une cinémathèque (6) Les types d’associations sont : LOUE, APPARTIENT, REALISE_PAR, JOUE, A_RECU LOUE entre un ciné-club et un film Propriété : durée de la location APPARTIENT entre un film et une catégorie REALISE_PAR entre un réalisateur et un film JOUE entre un acteur et un film A_RECU entre un film et une récompense

Application à la gestion d’une cinémathèque (7)

Application à la gestion d’une cinémathèque (8) Les deux types d’association APPARTIENT entre un film et une catégorie et REALISE_PAR entre un film et un réalisateur sont des DF. Ils sont donc matérialisés par l’ajout des attributs numero(catégorie) et numero(réalisateur) dans la relation FILM, source des deux DF.

Application à la gestion d’une cinémathèque (9) Les relations issues des types d’entités sont donc : CINE_CLUB(numéro, nom, adresse) FILM(référence, titre, durée,nombre_exemplaires, numéro (catégorie)*, numéro (réalisateur)*) CATEGORIE(numéro, intitulé) REALISATEUR(numéro, nom, prénom, nationalité) ACTEUR(numéro, nom, prénom) RECOMPENSE(numéro, ville, intitulé, année)

Application à la gestion d’une cinémathèque (10) auxquelles s’ajoutent les trois relations issues des types d’association : LOUE(numéro (ciné-club), référence (film), durée) JOUE(numéro (acteur), référence (film)) RECU(référence (film), numéro(récompense))

Application à la gestion de matériel (1) Une entreprise veut améliorer sa gestion de matériel. Les matériels sont classés en catégories pour faciliter leur gestion. L’entreprise veut connaître à tout instant la quantité disponible d’un matériel dans un magasin donné. On doit pouvoir connaître les composants d’un matériel.

Application à la gestion de matériel (2) Lors d’une rupture de stock, un matériel peut être remplacé par un matériel de substitution. Chaque client a un seuil maximal de commandes autorisé par catégorie de matériel pour une période donnée. Un client ne peut passer une commande que dans un magasin et un seul. Une commande est définie par un numéro ; elle concerne un seul client et différents matériels, et précise pour chaque matériel la quantité commandée.

Application à la gestion de matériel (3) Un matériel a un numéro et une désignation. Une catégorie a un code et un nom. Un magasin a un numéro et une adresse. Un client a un numéro de client et un nom. Une période est caractérisée par un numéro

Application à la gestion de matériel (4) Dictionnaire des données : numéro de matériel désignation de matériel code catégorie nom catégorie quantité en stock numéro de magasin adresse de magasin numéro de client nom de client droit d’approvisionnement numéro de période numéro de commande date de commande quantité commandée

Application à la gestion de matériel (5) Les types d’entités sont : MATERIEL, CATEGORIE, COMMANDE, MAGASIN, PERIODE, CLIENT Propriétés de MATERIEL : numéro_matériel, désignation Propriétés de CATEGORIE : code_catégorie, nom_catégorie

Application à la gestion de matériel (6) Propriétés de COMMANDE : numéro_commande, date_commande Propriétés de MAGASIN : numéro_magasin, adresse Propriétés de PERIODE : numéro_période Propriétés de CLIENT : numéro_client, nom_client

Application à la gestion de matériel (7) Les types d’association sont : SUBSTITUER entre un matériel et un autre SE_COMPOSER_DE entre un matériel et un autre CLASSER entre un matériel et une catégorie STOCKER entre un matériel et un magasin Propriété : quantité en stock POUVOIR_COMMANDER entre un client, une période et une catégorie Propriété : droit d’approvisionnement

Application à la gestion de matériel (8) PASSER entre un client et une commande CONCERNER entre une commande et un matériel Propriété : quantité commandée APPROVISIONNER entre une commande et un magasin

Application à la gestion de matériel (9)

Application à la gestion de matériel (10) Le type d’association : CLASSER entre un matériel et une catégorie est une DF. Il est donc matérialisé par l’ajout de l’attribut code_catégorie dans la relation MATERIEL, source de la DF.

Application à la gestion de matériel (11) Les types d’association PASSER entre une commande et un client APPROVISIONNER entre une commande et un magasin sont des DF. Ils sont donc matérialisés par l’ajout des attributs numero_client et numéro_magasin dans la relation COMMANDE, source de la DF.

Application à la gestion de matériel (12) Les relations issues des types d’entités sont donc : MATERIEL(numéro_matériel, désignation, code_catégorie*) CATEGORIE(code_catégorie, nom_catégorie) COMMANDE(numéro_commande, date_commande, numéro_client*, numéro_magasin*) MAGASIN(numéro_magasin, adresse) PERIODE(numéro_période) CLIENT(numéro_client, nom_client)

Application à la gestion de matériel (13) auxquelles s’ajoutent les relations provenant des types d’association : SUBSTITUER(numéro_matériel, numéro_matériel) SE_COMPOSER_DE(numéro_matériel, numéro_matériel) STOCKER(numéro_matériel, numéro_magasin, quantité en stock) POUVOIR_COMMANDER(numéro_client, numéro_période, code_catégorie, droit_d’approvisionnement) CONCERNER(numéro_commande, numéro_matériel, quantité_commandée)

Application à un hôpital (1) Un hôpital emploie du personnel : des médecins et des infirmier(e)s. Un médecin a un numéro, un nom, un prénom, une adresse, un numéro de téléphone et une spécialité. Un(e) infirmier(e) a un numéro, un nom, un prénom, une adresse, un numéro de téléphone et est rattaché à un service unique. Un directeur de service est un médecin. Les médecins ne sont autorisés à diriger qu’un seul service et ne sont pas affectés à un service particulier.

Application à un hôpital (2) L’hôpital comporte plusieurs bâtiments, distingués par leur nom. Chaque bâtiment comporte plusieurs salles ; chaque salle a un numéro et possède un certain nombre de lits. Il y a un infirmier responsable de chaque salle. Un service est localisé dans un seul bâtiment. Un malade a un numéro de sécurité sociale, un nom, un prénom, une adresse, un numéro de téléphone et une mutuelle. Il vient à l’hôpital pour une consultation ou pour une hospitalisation.

Application à un hôpital (3) Un malade est suivi par un ou plusieurs médecins. S’il est hospitalisé dans une salle, on doit connaître son numéro de lit et le diagnostic le concernant. Déterminer le dictionnaire des données, les entités avec leur identifiant et leurs attributs, les associations et leurs attributs et construire le modèle entité-association en indiquant les cardinalités. Déterminer la structure des tables relationnelles correspondant à ce modèle entité-association.

Application à un hôpital (4)

Application à un hôpital (5) Les relations issues des types d’entités sont : MEDECIN(numéro, nom, prénom, adresse, tel, spécialité) INFIRMIER(numéro, nom, prénom, adresse, tel, num_service*) MALADE(num_SS, nom, prénom, adresse, tel, mutuelle, num_salle*, num_lit) BATIMENT(nom) SALLE(numéro, nb lits, numéro(infirmier)*, nom(bâtiment)*) SERVICE(num_service, nom(bâtiment)*, numéro(médecin)*) La seule relation issue des types d’association est : SUIVI(numéro(médecin), num_SS(malade), diagnostic)

Compagnie d’assurance (1) Une compagnie d’assurance développe un système informatique qui s’appuie sur une base de données relationnelles décrite par le schéma suivant : ASSURE(num_assuré, nom, prénom, num_compte) num_assuré : numéro d’assuré unique nom, prénom : nom et prénom de l’assuré num_compte : numéro de compte bancaire POLICE(num_police, date_début, date_fin, prix, num_assuré) num_police : numéro unique de la police d’assurance date_début, date_fin : dates de validité de la police prix : montant annuel de l’assurance

Compagnie d’assurance (2) SINISTRE(num_sinistre, date, num_assuré, dommage) num_sinistre : numéro unique du sinistre date : date du sinistre dommage : le dommage subi (incendie, dégât des eaux, etc) RISQUE(num_police, dommage) Une police couvre un certain nombre de dommages. DOMMAGECOUVERT(dommage) Décrit les dommages couverts par la compagnie d’assurance. A l’aide des règles de passage d’un modèle entité / association à un modèle relationnel appliquées “ à l’envers ”, proposer un modèle entité / association équivalent à ce modèle relationnel.

Compagnie d’assurance (3)