Algèbre Relationnelle Chapitre 4, Sections 4.1 – 4.2 The slides for this text are organized into chapters. This lecture covers relational algebra from Chapter 4. The relational calculus part can be found in Chapter 4, Part B. Chapter 1: Introduction to Database Systems Chapter 2: The Entity-Relationship Model Chapter 3: The Relational Model Chapter 4 (Part A): Relational Algebra Chapter 4 (Part B): Relational Calculus Chapter 5: SQL: Queries, Programming, Triggers Chapter 6: Query-by-Example (QBE) Chapter 7: Storing Data: Disks and Files Chapter 8: File Organizations and Indexing Chapter 9: Tree-Structured Indexing Chapter 10: Hash-Based Indexing Chapter 11: External Sorting Chapter 12 (Part A): Evaluation of Relational Operators Chapter 12 (Part B): Evaluation of Relational Operators: Other Techniques Chapter 13: Introduction to Query Optimization Chapter 14: A Typical Relational Optimizer Chapter 15: Schema Refinement and Normal Forms Chapter 16 (Part A): Physical Database Design Chapter 16 (Part B): Database Tuning Chapter 17: Security Chapter 18: Transaction Management Overview Chapter 19: Concurrency Control Chapter 20: Crash Recovery Chapter 21: Parallel and Distributed Databases Chapter 22: Internet Databases Chapter 23: Decision Support Chapter 24: Data Mining Chapter 25: Object-Database Systems Chapter 26: Spatial Data Management Chapter 27: Deductive Databases Chapter 28: Additional Topics 1

Langages de Requêtes relationnels Langages de requêtes: Permettent la manipulation et l’extraction des données d’une base de données. Le modèle relationnel supporte de simples et puissants LRs: Solide fondation formelle basée sur la logique. Permet beaucoup d’optimisation. Langages de requêtes != langages de programmation! Les LRs ne sont pas équivalents à la machine de Turing. Ils ne sont pas destinés à être utilisés pour des calculs complexes. Ils supportent un accès facile et efficient à de larges ensembles de données. 2

Langage de Requêtes Relationnels (Suite) Deux langages de requêtes à caractère mathématique forment le soubassement des langages réels comme SQL et de l’implémentation de ceux-ci : Algèbre relationnelle: Plus opérationnelle, très utile pour représenter les plans d’exécution. Calcul relationnel: Permet aux utilisateurs de décrire ce qu’ils veulent, plutôt que la manière dont ce qu’ils veulent doit être calculé. (Non opérationnel, déclaratif.)

Préliminaires Une requête est appliquée aux instances relationnelles et son résultat est aussi une instance relationnelle. Les schémas des relations d’entrée d’une requête sont fixes (la requête exécutera cependant indépendamment de l’instance!) Le schéma du résultat d’une requête donnée est aussi fixe! Il est déterminé par la définition des éléments du langage des requêtes. Notation positionnelle vs. notation nominale: La notation positionnelle est plus facile à utiliser dans les définitions formelles. La notation nominale est plus lisible. Les deux notations sont utilisées dans SQL. 4

Exemple d’Instances R1 Nous utilisons les relations “Sailors” et “Reserves” pour nos exemples. Nous utiliserons les notations positionnelles et nominales selon les cas et assumeront que les noms des attributs des résultats des requêtes seront hérités des noms des attributs des relations d’entrée des requêtes. S1 S2 5

Algèbre Relationnelle Opérations de base: Sélection ( ) Sélectionne un sous-ensemble des lignes d’une relation. Projection ( ) Efface des colonnes d’une relation. Produit Cartésien ( ) Permet de combiner deux relations. Différence ( ) Contient des tuples de la relation 1, moins ceux de la relation 2. Union ( ) Contient les tuples des relations 1 et 2. Opérations additionnelles: Intersection, join, division, « renaming »: Pas essentielles; utiles. Les opérations retournant une relation, elles peuvent être composées! (L’algèbre est close.) 6

Projection Efface les attributs qui ne sont pas dans la liste de projection. Le Schéma du résultat contient exactement les attributs de la liste de projection, avec les mêmes noms qu’ils portaient dans la seule relation d’entrée de la projection. L’opérateur de projection doit éliminer les duplicata! (Pourquoi?) Note: les systèmes réels n’éliminent pas les duplicata, à moins que l’utilisateur le fasse explicitement. (Pourquoi?) 7

Sélection Sélectionne les lignes qui ne satisfont pas une condition de sélection. Pas de duplicata dans le résultat. Schéma du résultat identique au schéma de la seule relation d’entrée. Le résultat peut être l’entrée d’une autre opération algébrique (Composition d’opérateurs). 8

Union, Intersection, Différence Toutes ces opérations prennent comme entrées deux relations qui doivent être compatible vis-à-vis de l’union: même nombre de colonnes. colonnes correspondantes ont le même type. Par convention, le schéma du résultat sera le schéma de la 1ère relation. 9

Produit Cartésien Chaque ligne de S1 est appariée avec chaque ligne de R1. Le schéma du résultat contient les attributs de S1 et R1, avec les noms d’attributs hérités si possible. Conflit: S1 et R1 ont chacun un attribut portant le nom sid. Solution: changer le nom des attributs (« renaming »). Opérateur de renaming: 10

Joins Join conditionnel: Le Schéma du résultat est le même que celui du produit Cartésien. Moins de tuples que dans le produit Cartésien; pourrait être calculé de manière plus efficiente. Parfois appelé theta-join. 11

Joins (Suite) Equi-Join: Un cas spécial du join conditionnel où la condition c contient seulement des égalités. Schéma du résultat similaire au produit Cartésien, mais contient seulement une copie des attributs pour lesquels l’égalité est spécifiée. Join naturel: Equi-join dans lequel il y a égalité entre tous les attributs ayant le même nom dans les deux relations. 12

Division N’est pas supportée comme opérateur primitif, mais est utile pour l’expression des requêtes telles que: Trouver tous les navigateurs qui ont réservé tous les bateaux. Soit A une relation avec 2 attributs, x et y; B a seulement un attribut y: A/B = i.e., A/B contient tous les tuples x (navigateurs) tels que pour chaque tuple y (bateau) de B, il y a un tuple xy dans A. Ou: Si l’ensemble des valeurs de y (bateaux) associées avec une valeur x (navigateur) de A contient toutes les valeurs de y dans B, la valeur de x est dans A/B. En général, x et y peuvent être n’importe quelles listes d’attributs; y est la liste des attributs de B, et x y est la liste des attributs dans A. 13

Exemples de Division A/B 14

Définition de A/B La division n’est pas essentielle car elle peut être définie à l’aide des opérateurs de base. (Cela est vrai aussi pour les joins –- on l’a vu ! --, mais les joins sont si répandus que les SGBDs les implémentent directement.) Idée: Pour A/B, calculer toutes les valeurs de x qui ne sont disqualifiées par une valeur de y dans B. Une valeur de x est disqualifiée si en attachant une valeur de y venue de B, nous obtenons un tuple xy qui n’est pas dans A. Valeurs disqualifiées de x: A/B: tous les tuples disqualifiés 15

Trouver les noms de tous les navigateurs qui ont réservé le bateau #103 Solution 1: Solution 2: Solution 3: 16

Trouver les noms de tous les navigateurs qui ont réservé un bateau rouge L’info au sujet de la couleur des bateaux ne peut être enregistrée que dans Boats; d’où le besoin d’un join supplémentaire: Une solution plus efficiente: Un optimisateur des requêtes peut trouver cette dernière solution, Si on lui donne la première solution! 17

Trouver les navigateurs qui ont réservé un bateau rouge ou vert D’abord identifier tous les bateaux rouges ou verts, ensuite trouver les navigateurs qui ont réservé l’un de ces bateaux: On peut aussi définir Tempboats en utilisant une union. Que se passe-t-il si l’on remplace la disjonction par une conjonction? 18

Trouver les navigateurs qui ont réservé une bateau rouge et vert On ne peut ici utiliser l’approche précédente! On doit d’abord identifier qui a réservé des bateaux rouges, ensuite qui a réservé des bateaux verts, et enfin calculer l’intersection. 19

Trouver les noms des navigateurs qui ont réservé tous les bateaux Utiliser la division; les schémas des relations d’entrée à diviser doivent être choisis avec soins: Trouver ceux qui ont réservé tous les bateaux ‘VIP’: ..... 20

Résumé Le modèle relationnel a des langages de requêtes rigoureusement définis et qui sont simples et puissants. L’algèbre relationnelle est plus opérationnelle; elle est utile comme représentation interne des plans d’évaluation des requêtes. Une requête donnée peut être exprimée de diverses manières; un optimisateur choisira la voie la plus efficiente.