Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke1 Algèbre Relationnelle Chapitre 4, Sections 4.1 – 4.2

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke2 Langages de Requêtes relationnels Langages de requêtes: Permettent la manipulation et lextraction des données dune base de données. Le modèle relationnel supporte de simples et puissants LRs: Solide fondation formelle basée sur la logique. Permet beaucoup doptimisation. 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.

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke3 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 limplémentation de ceux-ci : Algèbre relationnelle : Plus opérationnelle, très utile pour représenter les plans dexécution. Calcul relationnel : Permet aux utilisateurs de décrire ce quils veulent, plutôt que la manière dont ce quils veulent doit être calculé. (Non opérationnel, déclaratif.)

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke4 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 dentrée dune requête sont fixes (la requête exécutera cependant indépendamment de linstance!) Le schéma du résultat dune 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.

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke5 Exemple dInstances R1 S1 S2 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 dentrée des requêtes.

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke6 Algèbre Relationnelle Opérations de base: Sélection ( ) Sélectionne un sous-ensemble des lignes dune relation. Projection ( ) Efface des colonnes dune 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 ! (Lalgèbre est close.)

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke7 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 quils portaient dans la seule relation dentrée de la projection. Lopérateur de projection doit éliminer les duplicata ! (Pourquoi?) Note: les systèmes réels néliminent pas les duplicata, à moins que lutilisateur le fasse explicitement. (Pourquoi?)

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke8 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 dentrée. Le résultat peut être lentrée dune autre opération algébrique ( Composition dopérateurs).

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke9 Union, Intersection, Différence Toutes ces opérations prennent comme entrées deux relations qui doivent être compatible vis-à-vis de lunion : 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.

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke10 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 dattributs 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 :

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke11 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.

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke12 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.

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke13 Division Nest pas supportée comme opérateur primitif, mais est utile pour lexpression 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 lensemble 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 nimporte quelles listes dattributs; y est la liste des attributs de B, et x y est la liste des attributs dans A.

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke14 Examples of Division A/B A B1 B2 B3 A/B1A/B2A/B3

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke15 Définition de A/B La division nest pas essentielle car elle peut être définie à laide des opérateurs de base. (Cela est vrai aussi pour les joins –- on la 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 nest pas dans A. Valeurs disqualifiées de x : A/B: tous les tuples disqualifiés

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke16 Trouver les noms de tous les navigateurs qui ont réservé le bateau #103 Solution 1: Solution 2 : Solution 3 :

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke17 Trouver les noms de tous les navigateurs qui ont réservé un bateau rouge Linfo au sujet de la couleur des bateaux ne peut être enregistrée que dans Boats; doù le besoin dun 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!

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke18 Trouver les navigateurs qui ont réservé un bateau rouge ou vert Dabord identifier tous les bateaux rouges ou verts, ensuite trouver les navigateurs qui ont réservé lun de ces bateaux: On peut aussi définir Tempboats en utilisant une union. Que se passe-t-il si lon remplace la disjonction par une conjonction?

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke19 Trouver les navigateurs qui ont réservé une bateau rouge et vert On ne peut ici utiliser lapproche précédente! On doit dabord identifier qui a réservé des bateaux rouges, ensuite qui a réservé des bateaux verts, et enfin calculer lintersection. (Rappel: sid est la clé de Sailors):

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke20 Trouver les noms des navigateurs qui ont réservé tous les bateaux Utiliser la division; les schémas des relations dentrée à diviser doivent être choisis avec soins: Trouver ceux qui réservé tous les bateaux VIP:.....

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke21 Résumé Le modèle relationnel a des langages de requêtes rigoureusement définis et qui sont simples et puissants. Lalgèbre relationnelle est plus opérationnelle; elle est utile comme représentation interne des plans dévaluation des requêtes. Plusieurs voies dexpression dune requête donnée existent; un optimisateur choisira la voie la plus efficiente.