Chapitre 3 LE MODELE RELATIONNEL ET SQL (DDL)

Chapitre 3 LE MODELE RELATIONNEL ET SQL (DDL) Un modèle de données définit un mode de représentation de l information selon trois composantes : 1. Des structures de données. 2. Des contraintes qui permettent de spécifier les règles que doit respecter une base de données. 3. Des opérations pour manipuler les données, en interrogation et en mise à jour. Les deux premières composantes relèvent du Langage de Définition de Données (DDL) dans un SGBD. Le DDL est utilisé pour décrire le schéma d une base de données. La troisième composante (opérations) est la base du Langage de Manipulation de Données (DML) dont le représentant le plus célèbre est SQL. Ce chapitre présente le modèle relationnel et essentiellement la partie du modèle relative à la définition et à la création du schéma de données. 1 Définitions Le modèle relationnel se caractérise par sa simplicité (se basant sur une seule structure : «la relation»). En effet, les objets et associations du monde réel sont représentés par un concept unique: la relation. Les relations sont des tableaux à deux dimensions, souvent appelés tables. Exemples Etudiant N Etud Nom Prénom Age 136 Rochat Jean 19 253 Aubry Annie 20 101 Duval André 20 147 Rochat Marc 21 Cours Nom C Horaire Prof Algo Lundi 10-12 Duval Système Mardi 16-17 Malin Suit N Etud NomC 253 Algo 136 Système 253 Système Cet exemple représente une relation (ou table) décrivant les étudiants. Etudiant est le nom de la relation. Les entêtes des colonnes, N Etud, Nom, Prénom et Age, sont les attributs de la relation. Chaque ligne de la table correspond à une occurrence. Par exemple <253, Aubry, Annie, 20> constitue un n-uplet ou tuple, qui décrit une occurrence, à savoir l'étudiante Annie Aubry. 1

Le modèle relationnel interdit d'avoir des doubles: deux tuples d'une même relation ne peuvent pas être identiques. Enfin, il est usuel de souligner l'attribut, ou les attributs, qui constituent l'identifiant de la relation; pour la relation Etudiant c'est l'attribut N Etudiant. On remarque que l'identifiant de la relation "Suit" (qui traduit un type d'association) est composé des identifiants des deux relations précédentes. Cette relation Suit exprime le lien entre un étudiant, désigné par son numéro, et un cours, désigné par son nom. Si on avait utilisé le modèle entité association, les relations Etudiant et Cours auraient été modélisées par des types d'entité, Etudiant et Cours, alors que la relation Suit aurait été modélisée par un type d'association reliant ces types d'entité. 1.1 Notion de domaine Un domaine est un ensemble de valeurs que peut prendre un attribut; c'est le domaine définition d'un ou plusieurs attributs. Exemple de domaines: Dnom : chaînes de caractères de longueur maximale 30 Dnum : entiers compris entre 0 et 99999 Dcouleur : {"bleu", "vert", "jaune"} Dâge : entiers compris entre 16 et 65 Les SGBDs usuels offrent des domaines prédéfinis standard, comme INTEGER, CHAR, VARCHAR, DATE 1.2 Attributs Les attributs nomment les colonnes d une relation. Il servent à la fois à indiquer le contenu de cette colonne, et à la référencer quand on effectue des opérations. Un attribut est toujours associé à un domaine. Le nom d un attribut peut apparaître dans plusieurs schémas de relations. 1.3 Schéma de Relation Une relation est définie par : - son nom - liste de couples décrivant ses attributs (nom d'attribut : domaine) - son (ses) identifiant(s) - sa définition (phrase en français) Les trois premières informations: nom de la relation, liste des couples (attribut : domaine) et identifiant(s) constituent le schéma de la relation. Exemple : schéma de la relation Etudiant : Etudiant (N Etud : Dnum, Nom : Dnom, Prénom : Dnom, Age : Dâge) 1.4 Instance d une relation (Population) La population d'une relation est constituée de l'ensemble des tuples de la relation. C'est un ensemble au sens mathématique du terme: il n'y a donc ni doubles, ni ordre (les nouveaux tuples sont rajoutés à la fin de la relation). On appelle schéma d'une base de données relationnelle l'ensemble des schémas de ses relations. On appelle base de données relationnelle, l'ensemble des populations de toutes ses relations. 1.5 Identifiant d une relation (Clé) L'identifiant (aussi appelé clé) d'une relation est un ensemble minimum d'attributs de la relation, tel qu'il n'existe pas deux tuples ayant même valeur pour cet identifiant. Un identifiant peut-être composé d'un ou plusieurs attributs. Une relation peut avoir un ou plusieurs identifiants. Une relation étant un ensemble de tuples sans double, elle a toujours un identifiant qui, dans le cas le 2

plus défavorable, est composé de tous les attributs de la relation. Par convention, l'attribut (ou les attributs) constituant l' (ou un des) identifiant(s) est souligné. Exemples Etudiant (N Etud, nom, prénom, age): Il n'y a pas deux étudiants qui ont le même numéro. La relation ci-dessus, EtudPrénoms2, possède deux identifiants qui sont (N Etud+N Prénom) et (N Etud+Prénom). On ne peut pas avoir de valeur inconnue (notée "?") pour un attribut qui fait partie d'un identifiant. Par exemple pour la relation Etudiant, on renseigne obligatoirement le numéro d'étudiant. Si l'on pouvait entrer dans la relation deux tuples sans N Etud, alors il existerait deux étudiants avec la même valeur pour l'identifiant (valeur inconnue), ce qui est impossible d'après la définition de l'identifiant. On a donc la règle suivante: Règle: Tous les attributs de tout identifiant doivent toujours avoir une valeur connue. Exemple Insérer dans Etudiant: <?, Rochat, Jean, 19> est une instruction que le SGBD va refuser. SQL offre deux concepts pour traduire la notion d'identifiant: la clé primaire (appelée "primary key") et les clés candidates (déclarée par la clause "unique"), qui se différencient lors de la déclaration des clés externes (voir le paragraphe suivant). Si la relation n'a qu'un seul identifiant, ce sera en SQL la clé primaire de la table. Si la relation a plusieurs identifiants, il faut choisir pour clé primaire "le meilleur": celui dont on est sûr que sa valeur ne sera jamais nulle ni modifiée. Les autres identifiants seront déclarés avec la clause UNIQUE. 1.6 Identifiant Externe Certains attributs référencent des tuples d'une autre relation (ou parfois de la même); c'est-à-dire que leur valeur est toujours égale à celle de l'identifiant d'un tuple existant dans l'autre relation. On les appelle identifiants externes (ou clés externes ou clés étrangères). Par exemple, la relation Suit (NomC, N Etud) possède un identifiant (NomC+N Etud), et deux identifiants externes : NomC et N Etud. En effet, NomC "référence" un Cours, c'est à dire que si une valeur NomC existe dans Suit, alors il doit nécessairement exister un cours de ce nom là dans la relation Cours. De même, N Etud "référence" un Etudiant. Le schéma d'une relation comprend donc, en plus de la définition du nom de la relation et de ses attributs et domaines associés, la définition de son (ses) identifiant, et celle de ses identifiants externes, s'il en existe. Les identifiants externes sont déclarés de la façon suivante: Suit (N Etud : Dnum, NomC : Dnom) Identifiants externes: N Etud référence un Etudiant NomC référence un Cours Dans le cas où la relation référencée possède plusieurs identifiants la clause précise alors lequel, comme ci-dessous: N Etud référence un Etudiant N Etud Définition : Soient deux relations R1(X, Y) et R2 (V, W), où X, Y, V, W, désignent des attributs ou des ensembles d'attributs, et où X est un identifiant de R1, on dit que W est un identifiant externe sur R1 (ou que W référence R1) si pour tout tuple de R2, la valeur prise par W est nécessairement la 3

valeur de X pour un tuple existant de R1. Autrement dit, à tout instant, l'ensemble des valeurs prises par W est compris dans l'ensemble des valeurs prises par X. Une fois déclaré l'identifiant externe W de R2 sur R1, le SGBD vérifie automatiquement : toutes les insertions de tuples dans R2: il vérifie que la valeur de W existe dans R1. Si ce n'est pas le cas l'insertion dans R2 est refusée; toutes les modifications de W: il vérifie que la nouvelle valeur de W existe dans R1. Si ce n'est pas le cas la modification est refusée; toutes les suppressions de tuples de R1: il vérifie qu'il n'existe pas de tuple dans R2 référençant ce tuple de R1 à supprimer. S'il en existe, selon le SGBD soit la suppression est refusée, soit la suppression est propagée: les tuples de R2 qui référençaient cette valeur de X sont eux aussi supprimés. Le SGBD assure ainsi, l'intégrité de référence (ou intégrité référentielle) de la base de données. En SQL, la clause pour déclarer une clé externe sur la clé primaire d'une table est: REFERENCES nom-table; celle pour déclarer une clé externe sur une clé candidate d'une table est: REFERENCES nom-table (nom-attribut-clé-candidate). 2 Règles de modélisation 2.1 Régles Générales Les attributs sont tous simples et monovalués: toute valeur prise par un attribut pour un tuple est atomique (non décomposable par le SGBD) et unique. Les notions d'attribut multivalué ou complexe n'existent pas dans le modèle relationnel. Cas d'un attribut facultatif du modèle entité association Certains SGBDs relationnels gèrent une valeur spéciale, appelée valeur nulle et notée "?". Cette valeur peut être prise par tout attribut (sauf si dans le schéma on a spécifié le contraire); elle signifie alors que le tuple n'a pas de valeur pour cet attribut. Par exemple, un étudiant, Marc Dumont, de numéro 123, dont on ne connaîtrait pas l'âge, serait représenté par le tuple : < 123, Dumont, Marc,? >. Une telle solution implique un traitement particulier de cette valeur nulle dans les langages de manipulation des données, notamment l'emploi d'une logique à trois valeurs : Vrai, Faux et Inconnu. En général il est bon d'éviter autant que possible l'emploi de valeurs nulles. Pour cela on peut utiliser, quand la valeur n'est pas renseignée, une valeur par défaut, par exemple 0 pour un nombre. SQL permet de définir une valeur par défaut pour un attribut grâce à la clause DEFAULT. A l'opposé, les attributs obligatoires sont traduits en SQL lors de la création de la table par la clause NOT NULL. Cas d'un attribut complexe du modèle entité association Soit par exemple, un attribut complexe en entité association, Adresse, composé des attributs: n bâtiment, nom-rue, ville, code-postal. Si on veut ajouter cet attribut dans la relation Etudiant, il y a plusieurs solutions. Solution 1: On ajoute l'attribut Adresse qui a pour domaine les chaînes de caractères. Dans ce cas, l'utilisateur ne peut pas poser de questions sur la ville, il devra lire l'adresse et chercher dans la chaîne de caractères le nom de la ville lui-même, ou par programme. Solution 2: On ajoute les attributs suivants : n bâtiment, nom-rue, ville, code-postal à la relation. Le SGBD connaît le détail de l'adresse, mais ne connaît pas la notion globale d'adresse. 4

La solution est choisie en fonction du type d'utilisation de l'attribut. Cas d'un attribut multivalué du modèle entité association Par exemple, on veut mémoriser les différents prénoms des étudiants (et non pas uniquement leur premier prénom). Solution 1: Avoir dans la relation Etudiant plusieurs attributs : Prénom1, Prénom2,... Problèmes : combien mettre d'attributs Prénom? Comment poser des questions sur cet attribut (on est obligé de poser autant de questions que d'attributs déclarés!). C'est une mauvaise solution à ne pas utiliser. Solution 2: On ne garde que N Etud, Nom, Age pour la relation Etudiant, et on crée une relation supplémentaire pour l'attribut multivalué, EtudPrénoms : EtudPrénoms N Etud Prénom 136 Jean 136 Marie 136 André 253 Annie 253 Claudette 101 André 147 Marc 147 Antoine Cette solution n'a pas les inconvénients de la solution précédente. Elle est valable pour tous les attributs multivalués, qu'ils soient simples ou complexes. Si l'on veut, plutôt que l'ensemble des prénoms, la liste ordonnée des prénoms on décrira la relation: EtudPrénoms2 (N Etud, N Prénom, Prénom) ce qui correspond en entité association à un attribut multivalué de type liste. 2.2 Traduction d'un schéma entité association en relationnel Il est possible de traduire un schéma entité association en un schéma relationnel en appliquant l'algorithme ci-dessous. Si le schéma entité association est bien construit, alors le résultat de la traduction sera un schéma relationnel normalisé en quatrième forme normale, sauf dans certains cas de dépendance à l'intérieur d'un attribut complexe. Une amélioration de l'algorithme consisterait à prendre en compte ces dépendances lors de la traduction des attributs complexes afin de ne générer que des relations en quatrième forme normale. Avec l'algorithme donné ci-dessous, il faut vérifier la forme normale de chaque relation obtenue à partir d'un attribut complexe. Algorithme de traduction : Pour chaque type d'entité, créer une relation de : - nom = nom du type d'entité; - attributs = attributs monovalués du type d'entité (pour les attributs complexes, prendre leurs attributs composants simples, avec pour nom le nom de l'attribut complexe concaténé à celui de l'attribut composant); les attributs obligatoires deviennent des attributs qui ne peuvent pas prendre la valeur nulle (NOT NULL en SQL). Si le type d'entité est sous-type d'un autre type E, alors il faut ajouter l'(un des) identifiant(s) de E aux attributs de la relation. Soit IE cet (ensemble d') attribut(s); 5

- identifiants = ceux du type d'entité qui ne font pas intervenir d'attribut multivalué. Si tous les identifiants comprennent un attribut multivalué ou s'il n'y a pas d'identifiant, alors demander à l'administrateur de la base d'ajouter à la relation un nouvel attribut identifiant. Si le type d'entité est sous-type d'un autre type E, alors IE est aussi un identifiant de la relation; - identifiants externes = si le type d'entité est sous-type d'un autre type E, alors IE est un identifiant externe qui référence la relation E, sinon il n'y a pas d'identifiant externe. Pour chaque attribut multivalué A d'un objet O (type d'entité, type d'association ou attribut multivalué complexe), créer une relation de : - nom = nom de l'objet O, concaténé à celui de l'attribut A; - attributs = l'attribut A (ou ses attributs composants simples et monovalués si A est complexe) + l'identifiant I (ou un des identifiants) de l'objet O + si la collection est de type liste un attribut ordre (de type Entier) qui définit l'ordre des valeurs + si la collection est de type multi-ensemble un attribut nombre (de type Entier) qui définit le nombre de valeurs identiques; - identifiants = si la collection est de type liste, l'identifiant de la relation est constitué de l'identifiant I de l'objet O et de l'attribut ordre qui a été ajouté; sinon l'identifiant de la relation est constitué de l'identifiant I de l'objet O + si A est un attribut simple alors A, sinon un (des) attribut composant de A (choix à faire faire par l'administrateur de la base); - identifiant externe = l'identifiant I de l'objet O. Pour chaque type d'association dont au moins un rôle a pour cardinalité maximum 1, soit R le type d'association liant : E1 avec le rôle r1 et les cardinalités: x1,1 /* si R a plusieurs rôles de cardinalité maximum 1, choisir de préférence pour E1/r1 celui (un de ceux) de cardinalités 1,1 */ E2 avec le rôle r2 et les cardinalités: x2,y2... En avec le rôle r1 et les cardinalités: xn,yn alors ajouter à la relation décrivant le type d'entité E1 : - aux attributs : l'identifiant (un des) de chacun des Ei liés sauf E1/r1, avec pour nom celui de Ei (ou celui de Ei concaténé au nom du rôle ri en cas d'homonymie), et si ce rôle ri est multivalué de type liste un attribut qui déterminera l'ordre, de domaine entier et de nom le nom du rôle ri (ou celui de Ei) concaténé à "N ordre", plus les attributs monovalués de R (pour les attributs complexes, prendre leurs attributs composants simples, avec pour nom le nom de l'attribut complexe concaténé à celui de l'attribut composant). Tous ces attributs ajoutés ne peuvent pas prendre la valeur nulle si le rôle r1 est obligatoire (x1>0). - aux identifiants externes : chaque identifiant, Ei (ou Ei.ri), ajouté à la relation est un identifiant externe qui référence la relation décrivant le type d'entité Ei. Pour chaque type d'association dont tous les rôles ont une cardinalité maximum supérieure à 1, soit R le type d'association liant : E1 avec le rôle r1 et les cardinalités : x1,y1 y1>1 E2 avec le rôle r2 et les cardinalités : x2,y2 y2>1... En avec le rôle r1 et les cardinalités : xn,yn yn>1 alors créer une relation de: - nom = nom de R (en cas d homonyme rajouter un numéro d ordre); - attributs = l'identifiant (un des) de chacun des Ei liés, avec pour nom celui de Ei (ou celui de Ei concaténé au nom du rôle ri en cas d'homonymie), et si ce rôle ri est multivalué de type liste un attribut qui déterminera l'ordre, de domaine entier et de nom le nom du rôle ri (ou celui de Ei) concaténé à "N ordre", plus les attributs monovalués de R (pour les attributs complexes, prendre leurs attributs composants simples, avec pour nom le nom de l'attribut complexe concaténé à celui de l'attribut composant); 6

- identifiants = ceux de R; - identifiants externes : chaque identifiant, Ei (ou Ei.ri), ajouté à la relation est un identifiant externe qui référence la relation décrivant le type d'entité Ei. 2.3 Contraintes Certaines contraintes exprimées dans le schéma entité association peuvent être directement exprimées dans le schéma relationnel issu de la traduction. C'est le cas par exemple, des attributs obligatoires (de cardinalité minimale non nulle) qui deviennent des attributs NOT NULL en relationnel. Les contraintes qui ne peuvent pas être directement exprimées dans le schéma relationnel, seront traduites par des CHECK, ASSERTION ou TRIGGER du SQL. Quelque soit le modèle de données (entité association, relationnel ou autre) il existe toujours des règles du monde réel qui ne peuvent pas être exprimées par les concepts du modèle. Certaines de ces règles restreignent les valeurs que peuvent prendre les données de la base. Elles sont appelées contraintes d'intégrité. Les SGBD relationnels offrent plusieurs mécanismes pour exprimer ces contraintes d'intégrité (en plus de l'intégrité référentielle des identifiants externes). Ce sont : attribut obligatoire: clause NOT NULL identifiant: clauses PRIMARY KEY et UNIQUE domaine de valeurs particulier d'un attribut: clause CHECK qui permet de vérifier que la valeur de l'attribut satisfait une condition contrainte d'intégrité quelconque: TRIGGER qui permet de spécifier que lors de toute insertion (ou suppression ou modification) d'un tuple dans telle relation telle condition doit être satisfaite sinon telle action doit être entreprise automatiquement par le SGBD, comme par exemple refuser l'insertion ou envoyer un message d'alerte. La notion de TRIGGER sera détaillée dans le TP 2. 3 Résumé Un schéma relationnel se compose: pour chaque relation de: - nom de la relation - définition - attributs + domaines - identifiant(s) - éventuellement identifiant(s) externe(s) + contraintes d'intégrité associées à cette relation. et des autres contraintes d'intégrité qui portent sur plusieurs relations. Un exemple de schéma de base de données relationnelles pour une entreprise de formation permanente est donné à la fin de ce chapitre. 4 Le langage de définition de données SQL Cette section présente le langage de définition de données (LDD) qui permet de spécifier le schéma d une base de données relationnelle. Ce langage correspond à une partie de la norme SQL (structured query language), l autre partie étant relative à la manipulation des données (LMD). La définition d un schéma logique comprend essentiellement deux parties : d une part la description des tables et de leur contenu, d autre part les contraintes qui portent sur les données de la base. Il existe plusieurs versions de SQL. Le plus ancien standard date de 1989. Il a été révisé de manière importante en 1992 : la norme résultant de cette révision est SQL-92 ou SQL2. 4. 1 Types SQL 7

La norme SQL ANSI propose un ensemble de types qui sont donnés dans le tableau suivant : 4. 2 Création des tables La commande principale est CREATE TABLE. Voici la commande de création d une table Internaute. CREATE TABLE Internaute (email VARCHAR (50) NOT NULL, nom VARCHAR (20) NOT NULL, prenom VARCHAR (20), motdepasse VARCHAR (60) NOT NULL, anneenaiss DECIMAL (4)) La syntaxe se comprend aisément. La seule difficulté est de choisir correctement le type de chaque attribut. Le NOT NULL dans la création de table Internaute indique que l attribut correspondant doit toujours avoir une valeur. Quand on parle de valeur NULL en SQL2, il s agit en fait d une absence de valeur. En conséquence : on ne peut pas faire d opération incluant un NULL; on ne peut pas faire de comparaison avec un NULL. Dans l exemple le SGBD rejettera alors toute tentative d insérer une ligne dans Internaute sans donner de mot de passe. Une autre manière de forcer un attribut à toujours prendre une valeur est de spécifier une valeur pardéfaut avec l option DEFAULT. CREATE TABLE Cinéma (nom VARCHAR (50) NOT NULL, adresse VARCHAR (50) DEFAULT Inconnue ) Quand on insérera une ligne dans la table Cinéma sans indiquer d adresse, le système affectera automatiquement la valeur Inconnu à cet attribut. 4.3 Contraintes La création d une table telle qu on l a vue précédemment est extrêmement sommaire car elle n indique que le contenu de la table sans spécifier les contraintes que doit respecter ce contenu. Or il y a toujours des contraintes et il est indispensable de les inclure dans le schéma pour assurer l intégrité de la base. 8

Voici les règles (ou contraintes d intégrité) que l on peut demander au système de garantir : 1. Un attribut doit toujours avoir une valeur. C est la contrainte NOT NULL vue précédemment. 2. Un attribut (ou un ensemble d attributs) constitue(nt) la clé de la relation. 3. Un attribut dans une table est lié à la clé primaire d une autre table (intégrité référentielle). 4. La valeur d un attribut doit être unique au sein de la relation. 5. Enfin toute règle s appliquant à la valeur d un attribut (min et max par exemple). Les contraintes sur les clés doivent être systématiquement spécifiées. La dernière (clause CHECK) s appuie en grande partie sur la connaissance du langage d interrogation de SQL et sera vue ultérieurement. Clés d une table Une clé est un attribut (ou un ensemble d attributs) qui identifie(nt) de manière unique un tuple d une relation. Il peut y avoir plusieurs clés mais l une d entre elles doit être choisie comme clé primaire. La clé primaire est spécifiée avec l option PRIMARY KEY. CREATE TABLE Internaute (email VARCHAR (50) NOT NULL, nom VARCHAR (20) NOT NULL, prenom VARCHAR (20), motdepasse VARCHAR (60) NOT NULL, anneenaiss INTEGER, PRIMARY KEY (email)) Il devrait toujours y avoir une PRIMARY KEY dans une table pour ne pas risquer d insérer deux lignes strictement identiques. Une clé peut être constituée de plusieurs attributs : CREATE TABLE Notation (idfilm INTEGER NOT NULL, email VARCHAR (50) NOT NULL, note INTEGER DEFAULT 0, PRIMARY KEY (titre, email)) Tous les attributs figurant dans une clé doivent être déclarés NOT NULL. On peut également spécifier que la valeur d un attribut est unique pour l ensemble de la colonne. Cela permet d indiquer des clés secondaires. On peut par exemple indiquer que deux artistes ne peuvent avoir les mêmes nom et prénom avec l option UNIQUE. CREATE TABLE Artiste(id INTEGER NOT NULL, nom VARCHAR (30) NOT NULL, prenom VARCHAR (30) NOT NULL, anneenaiss INTEGER, PRIMARY KEY (id), UNIQUE (nom, prenom)); La clause UNIQUE ne s applique pas aux valeurs NULL. Clés étrangères La norme SQL ANSI permet d indiquer quelles sont les clés étrangères dans une table, autrement dit, quels sont les attributs qui font référence à une ligne dans une autre table. On peut spécifier les clés étrangères avec l option FOREIGN KEY. CREATE TABLE Film (idfilm INTEGER NOT NULL, titre VARCHAR (50) NOT NULL, annee INTEGER NOT NULL, idmes INTEGER, 9

codepays INTEGER, PRIMARY KEY (idfilm), FOREIGN KEY (idmes) REFERENCES Artiste, FOREIGN KEY (codepays) REFERENCES Pays); La commande FOREIGN KEY (idmes) REFERENCES Artiste indique que idmes référence la clé primaire de la table Artiste. Le SGBD vérifiera alors, pour toute modification pouvant affecter le lien entre les deux tables, que la valeur de idmes correspond bien à une ligne de Artiste. Il faut noter que l attribut idmes n est pas déclaré NOT NULL. Quand un attribut est à NULL, la contrainte d intégrité référentielle ne s applique pas. Que se passe-t-il quand la violation d une contrainte d intégrité est détectée par le système? Par défaut, la mise à jour est rejetée, mais il est possible de demander la répercussion de cette mise à jour de manière à ce que la contrainte soit respectée. Les événements que l on peut répercuter sont la modification ou la destruction de la ligne référencée, et on les désigne par ON UPDATE et ON DELETE respectivement. La répercussion elle-même consiste soit à mettre la clé étrangère à NULL (option SET NULL), soit à appliquer la même opération aux lignes de l entité composante (option CASCADE). Voici comment on indique que la destruction d un metteur en scène déclenche la mise à NULL de la clé étrangère idmes pour tous les films qu il a réalisé. CREATE TABLE Film (titre VARCHAR (50) NOT NULL, annee INTEGER NOT NULL, idmes INTEGER, codepays INTEGER, PRIMARY KEY (titre), FOREIGN KEY (idmes) REFERENCES Artiste ON DELETE SET NULL, FOREIGN KEY (codepays) REFERENCES Pays); Dans le cas d une entité faible, on décide en général de détruire le composant quand on détruit le composé. Par exemple, quand on détruit un cinéma, on veut également détruire les salles ; quand on modifie la clé d un cinéma, on veut répercuter la modification sur ses salles. CREATE TABLE Salle (nomcinema VARCHAR (30) NOT NULL, no INTEGER NOT NULL, capacite INTEGER, PRIMAR KEY (nomcinema, no), FOREIGN KEY (nomcinema) REFERENCES Cinema ON DELETE CASCADE ON UPDATE CASCADE ) Il est important de noter que nomcinema fait partie de la clé et ne peut donc pas être NULL. On ne pourrait donc pas spécifier ici ON DELETE SET NULL. La spécification des actions ON DELETE et ON UPDATE simplifie considérablement la gestion de la base par la suite : on n a plus par exemple à se soucier de détruire les salles quand on détruit un cinéma. Énumération des valeurs possibles avec CHECK La norme SQL ANSI comprend une option CHECK (condition) pour exprimer des contraintes portant soit sur un attribut, soit sur une ligne. La condition elle-même peut être toute expression suivant la clause WHERE dans une requête SQL. Les contraintes les plus courantes sont celles consistant à restreindre un attribut à un ensemble de valeurs. Voici un exemple simple qui restreint les valeurs possibles des attributs annee et genre dans la table Film. CREATE TABLE Film (titre VARCHAR (50) NOT NULL, 10

annee INTEGER CHECK (annee BETWEEN 1890 AND 2000) NOT NULL, genre VARCHAR (10) CHECK (genre IN ( Histoire, Western, Drame )), idmes INTEGER, codepays INTEGER, PRIMARY KEY (titre), FOREIGN KEY (idmes) REFERENCES Artiste, FOREIGN KEY (codepays) REFERENCES Pays); Au moment d une insertion dans la table Film, ou d une modification de l attribut genre, le SGBD vérifie que la valeur insérée dans genre appartient à l ensemble énuméré défini par la clause CHECK. 4. 4 Modification du schéma La création d un schéma n est qu une première étape dans la vie d une base de données. On est toujours amené par la suite à créer de nouvelles tables, à ajouter des attributs ou à en modifier la définition. La forme générale de la commande permettant de modifier une table est : ALTER TABLE nomtable ACTION description où ACTION peut être principalement ADD, MODIFY, DROP ou RENAME, et description est la commande de modification associée à ACTION. La modification d une table peut poser des problèmes si elle est incompatible avec le contenu existant. Par exemple passer un attribut à NOT NULL implique que cet attribut a déjà des valeurs pour toutes les lignes de la table. Modification des attributs Voici quelques exemples d ajout et de modification d attributs. On peut ajouter un attribut region à la table Internaute avec la commande: ALTER TABLE Internaute ADD region VARCHAR(10); La taille de region étant certainement insuffisante, on peut l agrandir avec MODIFY, et la déclarer NOT NULL par la même occasion : ALTER TABLE Internaute MODIFY region VARCHAR(30) NOT NULL; Il est également possible de diminuer la taille d une colonne, avec le risque d une perte d information pour les données existantes. On peut même changer son type, pour passer par exemple de VARCHAR à INTEGER, avec un résultat imprévisible. L option ALTER TABLE permet d ajouter une valeur par défaut. ALTER TABLE Internaute ALTER region SET DEFAULT PACA ; Enfin on peut détruire un attribut avec DROP. ALTER TABLE Internaute DROP region; 5. Exemple : la base de données "FormaPerm" 11

La même base de données qui a été modélisée dans le chapitre sur le modèle entité association est maintenant modélisée en relationnel. Le schéma complet avec les définitions des tables ainsi que les contraintes d'intégrité, et enfin la population d'une mini base de données qui servira pour les chapitres sur les langages de manipulation. Schéma relationnel formel Domaines Dnom : chaînes de caractères de longueur inférieure à 30 Dch100 : chaînes de caractères de longueur inférieure à 100 Dannée : [1970 : 1990 ] Dnote : [0.0 : 10.0 ] Ddate : [1 :31 ] / [1 :12 ] / [1920 :2100 ] Relation Personne Attributs: n P : entier sans nul nom : Dnom sans nul adr : Dch100 sans nul Identifiant: (n P ) Définition: tout étudiant et tout enseignant de l'institut. Relation PersonnePrénoms Attributs: n P : entier sans nul prénom : Dnom sans nul n prénom : entier sans nul Identifiants: (n P + prénom ), (n P +n prénom ) Identifiant externe : n P référence une Personne Définition: prénoms des personnes Relation Etudiant Attributs: Identifiants: (n E ) (n P ) Identifiant externe : Définition: n P : entier sans nul n E : entier sans nul daten : Ddate sans nul n P référence une Personne tout individu qui est actuellement inscrit à l'institut, ou qui a déjà passé avec succès un des cours de l'institut Relation EtudiantEtudes Attributs: n E : entier sans nul année : Dannée sans nul diplôme : Dnom sans nul Identifiant: (n E + diplôme ) Identifiant externe : n E référence un Etudiant.n E Définition: études antérieures des étudiants Relation Enseignant Attributs: n P : entier sans nul tel: entier sans nul 12

statut : Dnom sans nul banque : Dnom sans nul agence : Dnom sans nul compte : entier sans nul Identifiant: (n P ) Identifiant externe : n P référence une Personne Définition: tout individu assurant actuellement un ou plusieurs cours à l'institut Relation Cours Attributs: nomc : Dnom sans nul cycle : entier sans nul n Ens : entier sans nul Identifiant: (nomc ) Identifiant externe : n Ens référence un Enseignant Définition: tout cours offert par l'institut Relation Obtenu Attributs: n E : entier sans nul nomc : Dnom sans nul note : Dnote sans nul année : Dannée sans nul Identifiant: (n E + nomc ) Identifiants externes : n E référence un Etudiant.n E nomc référence un Cours Définition: l'étudiant n E a réussi le cours nomc telle année et a obtenu telle note Relation Inscrit Attributs: n E : entier sans nul nomc : Dnom sans nul Identifiant: (n E + nomc ) Identifiants externes : n E référence un Etudiant.n E nomc référence un Cours Définition: actuellement, l'étudiant n E est inscrit au cours nomc Relation Prérequis Attributs: nomc : Dnom sans nul nomcprérequis : Dnom sans nul Identifiant: (nomc + nomcprérequis ) Identifiants externes : nomc référence un Cours nomcprérequis référence un Cours Définition: le cours nomcprérequis est un prérequis pour le cours nomc Contrainte d'intégrité: dans tout tuple, nomcprérequis doit être différent de nomc Contraintes d'intégrité: Pour tout tuple de Prérequis <nomc, nomcprérequis>, le cycle de nomcprérequis dans Cours doit être inférieur ou égal à celui de nomc. Pour tout tuple de Etudiant: année_en_cours - daten 18 Pour tout tuple de EtudiantEtudes <n E, année, diplome>, soit daten la date de naissance de l'étudiant dans la relation Etudiant, alors: daten < année Pour tout tuple de Obtenu <n E, nomc, note, année>, soit daten la date de naissance de l'étudiant dans la relation Etudiant, alors: daten < année 13

Pour tout tuple de Inscrit, <n E, nomc>, le n E doit exister dans Obtenu associé à tous les cours qui existent dans Prérequis associés à nomc. Schéma relationnel SQL CREATE TABLE Personne ( n P INTEGER NOT NULL, nom VARCHAR(30) NOT NULL, adr VARCHAR(100) NOT NULL, PRIMARY KEY (n P ) ) CREATE TABLE PersonnePrénoms ( n P INTEGER NOT NULL, prénom VARCHAR(30) NOT NULL, n prénom INTEGER NOT NULL, PRIMARY KEY (n P, n prénom ), UNIQUE (n P, prénom ), FOREIGN KEY (n P) REFERENCES Personne ON DELETE CASCADE ) CREATE TABLE Etudiant ( n P INTEGER NOT NULL, n E INTEGER NOT NULL, daten DATE NOT NULL, PRIMARY KEY (n E ), UNIQUE (n P ), FOREIGN KEY (n P) REFERENCES Personne ) CREATE TABLE EtudiantEtudes ( n E INTEGER NOT NULL, année INTEGER NOT NULL, diplôme VARCHAR(30) NOT NULL, PRIMARY KEY (n E, diplôme ), FOREIGN KEY (n E) REFERENCES Etudiant ) CREATE TABLE Enseignant ( n P INTEGER NOT NULL, tel INTEGER NOT NULL, statut VARCHAR(30) NOT NULL, banque VARCHAR(30) NOT NULL, agence VARCHAR(30) NOT NULL, compte INTEGER NOT NULL, PRIMARY KEY (n P ), FOREIGN KEY (n P) REFERENCES Personne ) CREATE TABLE Cours ( nomc VARCHAR(30) NOT NULL, cycle INTEGER NOT NULL, n Ens INTEGER NOT NULL, PRIMARY KEY (nomc ), FOREIGN KEY (n Ens) REFERENCES Enseignant ) CREATE TABLE Obtenu 14

( n E INTEGER NOT NULL, nomc VARCHAR(30) NOT NULL, note NUMERIC(2,1) NOT NULL, année INTEGER NOT NULL, PRIMARY KEY (n E, nomc ), FOREIGN KEY (n E) REFERENCES Etudiant.n E, FOREIGN KEY (nomc) REFERENCES Cours ) CREATE TABLE Inscrit ( n E INTEGER NOT NULL, nomc VARCHAR(30) NOT NULL, PRIMARY KEY (n E, nomc ), FOREIGN KEY (n E) REFERENCES Etudiant.n E, FOREIGN KEY (nomc) REFERENCES Cours ) CREATE TABLE Prérequis ( nomc VARCHAR(30) NOT NULL, nomcprérequis VARCHAR(30) NOT NULL, PRIMARY KEY (nomc, nomcprérequis ), FOREIGN KEY (nomc) REFERENCES Cours, FOREIGN KEY (nomcprérequis) REFERENCES Cours ) NB Les contraintes d'intégrité seront implémentées en SQL par des clauses CHECK et des TRIGGER. 15

Base de données relationnelle partielle de FormaPerm Personne n P nom adr 1111 Rochat Lausanne 6666 Walter Lausanne 5555 Bernard Yverdon 2222 Rochat Renens 3333 Muller Morges Etudiant n P n E daten 6666 22 3/3/78 1111 36 1/1/79 5555 44 2/2/78 Enseignant n P tel statut 2222 80111111 prof 3333 80222222 assistant Cours nomc cycle n Ens système 2 2222 BD 2 2222 SI 2 2222 algo 1 3333 C 1 3333 Obtenu n E nomc note année 22 algo 10 1998 22 C 9 1998 44 algo 9 1999 Inscrit n E nomc 36 algo 36 C 22 système 22 SI 44 C 44 BD Prérequis nomc nomcprérequis système algo système C BD algo SI algo SI C 16