Upload
chantal-bocquet
View
105
Download
0
Embed Size (px)
Citation preview
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1
Le Modèle Relationnel
Chapitre 3
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 2
Objectifs
Représenter les données en utilisant le modèle relationnel
Exprimer les contraintes d’intégrité sur les données
Créer, modifier, détruire et altérer des relations Créer, modifier, détruire, altérer, et poser des
requêtes sur les relations en utilisant SQL Obtenir une base de données relationnelle à
partir d’un diagramme ER Introduire les vues
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 3
Pourquoi Étudier le Modèle Relationnel?
Le modèle le plus largement utilisé. Vendeurs: IBM, Informix, Microsoft, Oracle,
Sybase, etc. “Legacy systems” en place dans les vieux
modèles. P.ex., IBM IMS
Récent compétiteur: modèle orienté objet. ObjectStore, Versant, Ontos Une synthèse émerge: modèle relationnel-
objet• Informix Universal Server, UniSQL, O2, Oracle, DB2
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 4
Concepts des Bases de Données Relationnelles
Relation: fait de 2 composantes: Instance : une table, avec lignes et colonnes.
#lignes = cardinalité, #colonnes = degré / arité. Schéma : spécifie le nom de la relation, plus le nom et le
domaine (type) de chaque colonne (attribut). Une relation comme est un ensemble de lignes ou
uplets (tuples) (i.e., toutes les lignes sont distinctes); chaque tuple a la même arité que le schéma de la relation.
Base de données relationnelles: un ensemble de relations, chacune ayant un nom distinct.
Schéma relationnel d’une BD: ensemble de schémas des relations dans la BD.
Schéma relationnel d’une instance de la BD: ensemble des instances relationnelles de la BD.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 5
Exemple de Relation
sid name login age gpa
53666 Jones jones@cs 18 3.4
53688 Smith smith@eecs 18 3.2 53650 Smith smith@math 19 3.8
Cardinalité = 3, arité = 5, toutes les lignes sont distinctes. Les systèmes commerciaux permettent des duplicata. Toutes les colonnes d’une instance relationnelle ont-elles à être distinctes? Dépend de la présence ou non d’un ordre.
Schema : Students(sid: string, name: string, login: string,
age: integer, gpa: real).Instance :
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 6
Langages de Requêtes Relationnels
Un avantage majeur du modèle relationnel est qu’il supporte de simples et puissantes requêtes sur les données.
Les requêtes peuvent être écrites de manière intuitive (i.e. déclarative), et le SGBD est responsable de leur évaluation efficiente. L’utilisateur dit au SGBD quoi faire et le système
cherche comment faire ce qu’il y a à faire de manière efficiente!
La clé du succès: sémantique précise des requêtes. Permet à l’optimisateur de réordonner les opérations
tout en garantissant que la réponse ne change pas.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 7
SQL: Langage des Requêtes pour Données Relationnelles
Développé par IBM (« système R ») dans les années 1970s.
Besoin d’un standard car utilisé par beaucoup de vendeurs.
Standards: SQL-86 SQL-89 (révision mineure) SQL-92 (révision majeure: triggers, oo, …) SQL-99 (extensions majeures:
datawarehousing, …)
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 8
Création des Relations en SQL
Crée la relation Students. Il est à observer que le type (domaine) de chaque attribut est spécifié et fait respecter par le SGBD chaque fois que des tuples sont ajoutés ou modifiés.
Autre exemple: La table Enrolled enregistrent des infos sur les cours que les étudiants prennent.
CREATE TABLE Students(sid: CHAR(20), name: CHAR(20), login: CHAR(10), age: INTEGER, gpa: REAL)
CREATE TABLE Enrolled(sid: CHAR(20), cid: CHAR(20), grade:
CHAR(2))
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 9
Destruction et Altération des Relations
détruit la relation Students. Le schéma et les tuples sont effacés.
DROP TABLE Students
Le schéma de Students est altéré par l’ajout d’un nouvel attribut; chaque tuple dans l’instance courrante est augmenté par une valeur null pour le nouvel attribut.
ALTER TABLE Students ADD COLUMN firstYear: integer
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 10
Ajout et Effacement des Tuples Un seul tuple est ajouté de la manière suivante:
INSERT INTO Students (sid, name, login, age, gpa)VALUES (53688, ‘Smith’, ‘smith@ee’, 18, 3.2)
Tous les tuples satisfaisant une certaine condition peuvent être effacés:
DELETE FROM Students SWHERE S.name = ‘Smith’
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 11
Contraintes d’Intégrité (ICs) IC: condition qui doit être satisfaite dans toutes
les instances de la base de données. Exemple simple: contraintes du domaine.
Les ICs sont spécifiées lorsque le schéma est défini. Les ICs sont vérifiées lorsque les relations sont
modifiées. Une instance légale d’une relation est une
instance qui satisfait toutes les ICs spécifiées. Un SGBD ne doit pas permettre des instances
illégales. Si le SGBD vérifie les ICs, les données stockées
reflètent mieux la signification du monde réel. Évite les erreurs d’entrée de données aussi!
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 12
Contraintes de Clé Primaire Un ensemble d’attributs est une clé d’une
relation si:1. Deux tuples distincts ne peuvent pas avoir les
mêmes valeurs pour tous les attributs de la clé, et
2. Cela n’est pas vrai pour un quelconque sous-ensemble de la clé.
Si la partie 2 est fausse, on a une superclé. S’il y a plus d’une clé pour la relation, une
d’elles est choisie (par le DBA) comme clé primaire.
P. ex., sid est une clé pour Students, alors que name n’en est pas une. L’ensemble {sid, gpa} est une superclé.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 13
Clé Primaire et Candidates Clé en SQL
Plusieurs candidates clé (spécifiées par UNIQUE); une d’elles est choisie comme clé primaire.
CREATE TABLE Enrolled (sid CHAR(20) cid CHAR(20), grade CHAR(2), PRIMARY KEY (sid,cid) )
“Un étudiant n’a qu’une note pour chaque cours dans lequel il est enrôlé.” vs. “Les étudiants ne peuvent prendre qu’un seul cours et n’avoir qu’une seule note pour ce cours; et deux étudiants ne peuvent recevoir la même note.”
Une IC utilisée imprudemment peut empêcher le stockage d’instances de base de données qui apparaissent dans la réalité!
CREATE TABLE Enrolled (sid CHAR(20) cid CHAR(20), grade CHAR(2), PRIMARY KEY (sid), UNIQUE (cid, grade) )
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 14
Clés Étrangères et Intégrité Référentielle
Clé étrangère : Ensemble d’attributs d’une relation qui est utilisé pour référer aux tuples d’une autre relation. (Doit correspondre à la clé primaire de la seconde relation.) C’est un ‘pointeur logique’.
P. ex. sid est une clé étrangère referant à Students: Enrolled(sid: string, cid: string, grade: string) Si toutes les contraintes de clé étrangère sont
respectées, on atteint une intégrité référentielle (IR), i.e., il n’y a aucune référence pendante (« dangling references»).
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 15
Spécification des Clés Étrangères en SQL
Seuls les étudiants listés dans la relation Students devraient être permis de s’enregistrer pour les cours !!!
CREATE TABLE Enrolled (sid CHAR(20), cid CHAR(20), grade CHAR(2), PRIMARY KEY (sid,cid), FOREIGN KEY (sid) REFERENCES Students )
sid name login age gpa
53666 Jones jones@cs 18 3.453688 Smith smith@eecs 18 3.253650 Smith smith@math 19 3.8
sid cid grade53666 Carnatic101 C53666 Reggae203 B53650 Topology112 A53666 History105 B
EnrolledStudents
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 16
Exécution (« Enforcing ») de l’IR
Considérez Students and Enrolled; sid dans Enrolled est une clé étrangère referant à Students.
Que devrait-on faire si un tuple de Enrolled ayant un étudiant non-existent est inseré? (Rejetez le!)
Que faire si un tuple de Students est effacé? Effacer également tous les tuples de Enrolled qui
réfèrent à lui. Ne pas permettre un effacement d’un tuple auquel il
est fait référence. Donner une valeur par défaut au sid des tuples de
Enrolled qui réfèrent à lui.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 17
Exécution de l’IR en SQL
SQL-92 et SQL-1999 supportent toutes les 3 options d’effacement et de modification examinées. Défaut: NO ACTION
(delete/update est rejeté) CASCADE (effacer aussi
tous les tuples qui réfèrent au tuple effacé)
SET NULL / SET DEFAULT (donner une valeur « null » défaut à la clé étrangère du tuple référant)
CREATE TABLE Enrolled (sid CHAR(20), cid CHAR(20), grade CHAR(2), PRIMARY KEY (sid,cid), FOREIGN KEY (sid) REFERENCES Students
ON DELETE CASCADE )
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 18
D’où viennent les ICs? Les ICs proviennent de la sémantique de l’entreprise à
modéliser. Nous pouvons contrôler une instance de base de
données pour voir si une IC est violée, mais nous ne pourrons jamais déduire que une IC est satisfaite juste à partir d’une instance. Une IC est déclaration au sujet de toutes les instances
possibles! De notre exemple, nous savons que name n’est pas une clé,
mais l’assertion que sid est une clé nous est donnée. Clé et clé étrangère sont les ICs les plus courants;
cependant des ICs plus généraux existent aussi.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 19
Transactions et Contraintes Un programme de transaction est une séquence
de requêtes, insertions, effacements, etc qui accèdent à la base de données.
Quand est-ce que des contraintes devraient être contrôlées dans une transaction? Immédiatement après la déclaration Différer le contrôle à plutard (p.ex., en fin de
transaction) SQL permet deux modes de contrainte.
SET CONSTRAINT MyConstraint IMMEDIATE SET CONSTRAINT MyConstraint DEFERRED Les ICs sont immédiats par défaut; les ICs différées sont
contrôlées lors de la validation (« Commit time »).
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 20
Design Logique: du Modèle ER au Relationnel
Le modèle ER représente le design initial et « high-level » de la base de données.
La tâche est de générer un schéma relationnel qui soit le plus proche possible du modèle ER.
La traduction est approximative car il est difficile de traduire toutes les contraintes du modèle ER en un modèle logique efficient.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 21
De l’Ensemble d’Entités à une Table L’ensemble d’entités devient une table.
Chaque attribut de l’ensemble d’entités devient un attribut de la table.
Les contraintes de domaine deviennent des types appropriés de SQL.
La clé primaire de l’ensemble d’entités devient la clé primaire de la table.
CREATE TABLE Employees (ssn CHAR(11), name CHAR(20), lot INTEGER, PRIMARY KEY (ssn))
Employees
ssnname
lot
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 22
De l’Ensemble des Relations à une Table
Un ensemble de relations (sans contraintes) est traduit en une table.
Les attributs de la relation doivent inclure: Clés pour chaque ensemble
d’entités participant (clés étrangères).
• Cet ensemble d’attributs forme une superclé pour la nouvelle table.
Tous les attributs descriptifs.
CREATE TABLE Works_In( ssn CHAR(1), did INTEGER, since DATE, PRIMARY KEY (ssn, did), FOREIGN KEY (ssn) REFERENCES Employees, FOREIGN KEY (did) REFERENCES Departments)
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 23
De l’Ensemble des Relations à une Table (Suite) La traduction d’un ensemble de
relations circulaires (sans contraintes) en une table doit inclure les attributs suivants: Clés construites en
concaténant les indicateurs de rôle avec la clé primaire de l’ensemble d’entités participant (clés étrangères).
• Cet ensemble d’attributs forme une superclé pour la nouvelle table.
Tous les attributs descriptifs. Une dénomination explicite
de la clé référencée.
CREATE TABLE Reports_to( supervisor_ssn CHAR(11), subordinate_ssn CHAR(11), PRIMARY KEY (supervisor_ssn, subordinate_ssn), FOREIGN KEY (supervisor_ssn) REFERENCES Employees(ssn), FOREIGN KEY (subordinate_ssn) REFERENCES Employees(ssn))
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 24
Rappel: Contraintes de Clé
Chaque dept a au plus un manager en vertu de la contrainte de clé sur Manages.
Comment traduire Tout ceci en modèle relationnel?
Many-to-Many1-to-1 1-to Many Many-to-1
dname
budgetdid
since
lot
name
ssn
ManagesEmployees Departments
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 25
Traduction des Diagrammes ER avec Contraintes de Clé
Traduire la relation en une table: Notez que le did
est la clé maintenant!
Tables séparées pour Employees et Departments.
Puisque chaque département n’a qu’un manager unique, nous pourrions aussi combiner Manages et Departments.
CREATE TABLE Manages( ssn CHAR(11), did INTEGER, since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, FOREIGN KEY (did) REFERENCES Departments)
CREATE TABLE Dept_Mgr( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR(11), since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees)
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 26
Rappel: Contraintes de Participation Chaque département a-t-il un manager?
Si c’est le cas, on a une contrainte de participation: la participation de Departments dans l’association Manages est dite être totale (vs. partielle).• Chaque valeur did dans la table Departments doit
apparaître dans une ligne de la table Manages (avec une valeur de ssn qui n’est pas nulle!)
lot
name dnamebudgetdid
sincename dname
budgetdid
since
Manages
since
DepartmentsEmployees
ssn
Works_In
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 27
Contraintes de Participation en SQL
Nous ne pouvons exprimer que les contraintes de participation impliquant un ensemble d’entités participant à une relation binaire.
Pour les relations non binaires, recourir aux contraintes CHECK (plutard).
CREATE TABLE Dept_Mgr( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR(11) NOT NULL, since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, ON DELETE NO ACTION)
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 28
Rappel: Entités Faibles Une entité faible ne peut être identifiée que par
l’entremise d’une clé primaire d’une autre entité (propriétaire) . L’ensemble des propriétaires et celui des entités
faibles doivent participer dans un ensemble de relations « one-to-many » (1 propriétaire, beaucoup d’entités faibles).
Un ensemble d’entités faibles doit avoir une participation totale dans cette ensemble de relations identifiantes.
lot
name
agepname
DependentsEmployees
ssn
Policy
cost
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 29
Traduction d’Ensemble d’Entités Faibles
Un ensemble d’entités faibles ainsi que son ensemble de relations identifiantes sont traduits en une SEULE table. Lorsque l’entité propriétaire est effacée,
toutes les entités faibles possédées par elle doivent aussi être effacées.
CREATE TABLE Dep_Policy ( pname CHAR(20), age INTEGER, cost REAL, ssn CHAR(11) NOT NULL, PRIMARY KEY (pname, ssn), FOREIGN KEY (ssn) REFERENCES Employees, ON DELETE CASCADE)
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 30
Rappel: Hiérarchies ISA
Contract_Emps
namessn
Employees
lot
hourly_wages
ISA
Hourly_Emps
contractid
hours_worked
Une déclaration A ISA B signifie que chaque entité de A est aussi à considérer comme une entité de B.
Contraintes de superposition: Joe peut-il être à la fois dans Hourly_Emps et dans Contract_Emps?
Contraintes de couverture: Y a-t-il des employés qui ne sont ni dans Hourly_Emps ni dans Contract_Emps?
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 31
Traduction des Hiérarchies ISA en Relations
Approche générale: 3 relations: Employees, Hourly_Emps et Contract_Emps.
• Hourly_Emps: Chaque employé est enregistré dans Employees. Pour les employés journaliers, de l’info supplémentaire est enregistré dans Hourly_Emps (hourly_wages, hours_worked, ssn); un tuple de Hourly_Emps doit être effacé si sa référence dans Employees est effacée.
• Les requêtes impliquants tous les employés sont faciles, mais celles impliquant juste les tuples de Hourly_Emps p.ex. requièrent un join pour accéder à des attributs supplémentaires.
Alternative: utiliser exactement Hourly_Emps et Contract_Emps. Hourly_Emps: ssn, name, lot, hourly_wages, hours_worked. Chaque employé doit être exactement dans l’une de ces 2 sous-
classes. Les contraintes de superposition et de couverture sont
exprimées en SQL par des assertions que nous verrons plutard.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 32
Rappel: Relation Binaire vs. Ternaire
Notez les contraintes additionnelles introduites dans le 2ème diagramnme.
agepname
DependentsCovers
name
Employees
ssn lot
Policies
policyid cost
Beneficiary
agepname
Dependents
policyid cost
Policies
Purchaser
name
Employees
ssn lot
Mauvais design
Meilleur design
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 33
Relation Binaire vs. Ternaire (Suite)
La contrainte de clé nous permets de combiner Purchaser avec Policies ainsi que Beneficiary avec Dependents.
Les contraintes de participation conduisent à des contraintes NOT NULL.
CREATE TABLE Policies ( policyid INTEGER, cost REAL, ssn CHAR(11) NOT NULL, PRIMARY KEY (policyid). FOREIGN KEY (ssn) REFERENCES Employees, ON DELETE CASCADE)
CREATE TABLE Dependents ( pname CHAR(20), age INTEGER, policyid INTEGER, PRIMARY KEY (pname, policyid). FOREIGN KEY (policyid) REFERENCES Policies, ON DELETE CASCADE)
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 34
Vues Une vue est simplement une relation
dont la définition est stockée plutôt que un ensemble de tuples.
CREATE VIEW YoungActiveStudents (name, grade)AS SELECT S.name, E.gradeFROM Students S, Enrolled EWHERE S.sid = E.sid and S.age<21
Les vues peuvent être détruites en utilisant la commande DROP VIEW. Comment traiter DROP TABLE s’il y a une vue sur la
table?• La commande DROP TABLE a des options pour
permettre à l’usager de spécifier cela: RESTRICT / CASCADE.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 35
Vues et Sécurité
Les vues peuvent être utilisées pour présenter de l’info nécessaire à l’usager tout en lui interdisant l’accès aux relations sous-jacentes. Étant donné la vue YoungActiveStudents,
avec les tables Students et Enrolled cachées, nous pouvons trouver les étudiants qui sont inscrits, mais pas les cid’s des cours auxquels ils sont inscrits!
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 36
Résumé Le modèle relationnel est une présentation tabulaire
des données. Il est simple et intuitif, présentement largement
utilisé. Les contraintes d’intégrité peuvent être spécifiées par
le DBA sur base de la sémantique de l’application. Le SGBD en contrôle les violations. Deux ICs importants: clé primaire et clés étrangères De plus, on a toujours les contraintes du domaine
Un langage de requêtes puissant et naturel existe. Il existe des règles (pas toujours exactes!!!!) pour
traduire les diagrammes ER en un modèle relationnel.