1 chapitre 1 chapitre 1 Chapitre 1 Les bases de données et SQL Le langage SQL e

1 chapitre 1 chapitre 1 Chapitre 1 Les bases de données et SQL Le langage SQL est le fruit d’années de réfl exion sur la problématique de manipulation des données. Formalisé et normalisé, il est né dans les années 1980 et a été rapidement adopté par la majorité des éditeurs. Ses dernières normalisations (SQL:1999/SQL:2003) l’ont fait s’orienter vers ce que l’on appelle désormais le relationnel objet , c’est-à-dire l’introduction de certains principes de la programmation objet au sein des bases de données relationnelles. SQL repose sur deux principes fondamentaux : l’algèbre relationnelle (une branche des mathé- matiques conçue pour traiter des données de manière ensembliste) et la modélisation des données à base d’entités et de relations. Ce sont les sujets que nous allons aborder dans ce chapitre et nous terminerons en présen- tant la base de données qui nous servira de fi l conducteur pour la majorité des exemples du livre et certains exercices. © 2010 Pearson Education France – SQL, 3e éd. – Frédéric Brouard, Rudi Bruchez, Christian Soutou SQL 2 1. Historique des systèmes de gestion de bases de données (SGBD) Comme beaucoup de technologies de l’informatique aujourd’hui matures, les bases de données relationnelles sont nées des travaux d’IBM entre les années 1960 et 1970. De nombreuses recherches ont été menées au cours de cette période sur des modèles de données hiérarchiques, réseaux et relationnels. Le relationnel a été unanimement adopté par la suite et programmé à l’aide du langage SQL (Structured Query Language). La théorie sur laquelle repose SQL a été énoncée par le professeur Edgar Frank Codd (1924-2003), un mathématicien d’Oxford, alors qu’il travaillait comme chercheur pour IBM au laboratoire de San Jose. L’article « A relational model of data for large shared data banks », publié en juin 1970 dans la revue Association for Computing Machinery, fait toujours office de référence et a initié tous les travaux qui ont suivi et qui perdurent. Codd voulait créer un système où l’interrogation des données utilisait le vocable anglais. Les travaux de la NASA, sur la base de données modélisant les rochers rapportés du voyage sur la lune, a aidé au développement de ce langage en lui donnant de la crédibilité. Dès 1974, IBM entamait un prototype de bases de données relationnelle appelé System/R. Ce projet se termina en 1979, prouvant ainsi la viabilité d’un tel système. Le langage de programmation utilisé par IBM pour System/R fut appelé SEQUEL (Structured English Query Language) rebaptisé par la suite SQL (Structured Query Language) pour des raisons phonétiques (entendre en français si-qu-el). Comme tout langage, SQL a eu ses concurrents, le plus connu fut QUEL du SGBD Ingres du début des années 1980. Bien qu’étant le précurseur de SQL, IBM ne fut pas le premier vendeur de SGBD. Ce privilège revint à Honeywell Information Systems, qui commercialisa, en juin 1976, un produit tombé depuis en désuétude. À cette même période, un groupe d’ingénieurs attentif aux résultats du projet System/R réalisa le premier produit commercial vraiment opérationnel au sein de la société Relational Software. En 1979, ils appelèrent leur sys- tème Oracle Version 2 (premier d’une longue lignée…). Concurremment, System/R évo- lua vers le produit commercial SQL/DS qui devint DB2, nom toujours employé pour désigner le serveur de données d’IBM. Microsoft n’est entré dans le marché des éditeurs de SGBDR qu’en 1994, après le rachat du code du serveur de données de Sybase. Aujourd’hui IBM, Oracle et SQL Server se partagent majoritairement le marché des gros systèmes, tandis que MySQL, PostgreSQL ou encore Firebird jouent les outsiders avec plus ou moins de liberté. H d 1. © 2010 Pearson Education France – SQL, 3e éd. – Frédéric Brouard, Rudi Bruchez, Christian Soutou Chapitre 1 Les bases de données et SQL 3 2. Évolution récente des SGBD Au cours des vingt dernières années, l’évolution des SGBD s’est effectuée en trois étapes : • SGBD relationnels mettant en œuvre les théories de Codd (INGRES par exemple) ; • SGBD orientés objet afin de coller à la conception et la programmation objet (O2 par exemple) ; • SGBD relationnel objet (Oracle et IBM DB2 par exemple). Ces derniers sont aujourd’hui les plus répandus car ils constituent une approche mixte – comme les langages C ++ ou java – reconnue et entérinée par la norme SQL, car propo- sant une évolution souple vers l’objet, en conservant les avantages et la simplicité de l’approche relationnelle. 2.1. SGBD relationnels Voici ce qui fait le succès des SGBDR : • Le modèle de données relationnel repose sur une théorie rigoureuse (théorie des bases de données et algèbre relationnelle) avec des principes simples. • L’indépendance données/traitements améliore la maintenance des programmes d’application (la modification d’une structure de données a peu de répercussion en théorie sur les programmes). • Les données de la base sont indépendantes du système d’exploitation et des couches bases réseaux. • La gestion des privilèges mixe éléments de la base de données et actions (ordre SQL) pour une sécurité maximale. • Les systèmes sont bien adaptés aux grandes applications informatiques de gestion et ont acquis une maturité sur le plan de la fiabilité et des performances (évolution d’échelle – « scalabilité »). • Le langage SQL est puissant et concis ; il peut souvent s’interfacer avec des langages de troisième génération (C, Ada, Cobol), mais aussi avec des langages plus récents (C ++, Java, C#). • Les systèmes répondent parfaitement à des architectures de type client-serveur (pas- serelles ODBC et JDBC notamment) et intranet ou Internet (configurations à plu- sieurs couches, ou tiers). Les limitations de la majorité des systèmes actuels sont les suivantes : • La simplicité du modèle de données et le fait que le langage SQL soit natif et déclaratif nécessitent d’interfacer le SGBDR avec un langage de programmation évolué. De ce fait, le dialogue entre la base et le langage n’est plus direct et implique de maîtriser plusieurs technologies. • La faible capacité de modélisation fait que seules les structures de données tabulaires sont permises. Il est ainsi difficile de représenter directement des objets complexes. • La normalisation conduit à l’accroissement du nombre de relations. Ainsi, si deux objets doivent être liés en mémoire, il faut simuler ce lien au niveau de la base par un É Au cours des 2. © 2010 Pearson Education France – SQL, 3e éd. – Frédéric Brouard, Rudi Bruchez, Christian Soutou SQL 4 mécanisme de clés étrangères ou de tables de corrélations. Parcourir un lien implique souvent une jointure dans la base. Il en résulte un problème de performance dès que le style d’interrogation devient navigationnel : manipulation d’arbres, de graphes ou toute autre application mettant en relation un grand nombre d’objets. Ce dernier point est d’ailleurs moins crucial aujourd’hui qu’autrefois. Les éditeurs ont, pour la plupart, trouvé des algorithmes et des techniques pour rendre les jointures très performantes, notamment en améliorant les techniques d’indexation et en fournissant des générateurs de clés, au prix, cependant, d’un léger décalage entre un modèle théo- rique parfait et un modèle physique performant. 2.2. SGBD objet Gemstone a été le premier SGBD objet, dérivé du langage Smalltalk. Des produits com- merciaux existent, citons db4o, Objectivity, ObjectStore, Orient, Ozone, FastObjects, Versant (produit issu du système O2). Ces systèmes permettent de manipuler des objets persistants. Ils concernent un segment très limité du marché des SGBD. Parallèlement à ces initiatives individuelles, l’ODMG (Object Database Management Group) propose une API objet standard s’adaptant à tout SGBD par passerelles C ++, Java et Smalltalk. En 1998, les compagnies qui soutenaient l’action de l’ODMG étaient Computer Associates, ObjectDesign, Versant, Poet, Objectivity, Ardent Software et Objectmatter. L’ODMG a soumis à la communauté Java la partie « Java Binding » pour définir la spécification JDO (Java Data Objects). 2.3. SGBD relationnel objet La technologie relationnelle objet est apparue en 1992 avec les SGBD UNISQL et Open ODB d’Hewlett-Packard (appelé par la suite Odapter). En 1993, la firme Montage Systems (devenue Illustra) achète la première version commerciale du système Postgres. À la fin de l’année 1996, Informix adopte la technologie objet avec l’achat du SGBD d’Il- lustra. La stratégie d’Informix repose sur la spécialisation exclusive du SGBD. Il se diffé- rencie d’autres éditeurs comme Oracle qui propose, outre son serveur de données, une offre que certains jugent disparate (outils de messagerie, AGL, etc.). En juillet 1995, IBM inclut des aspects objets dans DB2 puis rachète Informix en 2001. Oracle 8 propose en juin 1997 des aspects objets mais les premières versions (avant la 8.1.7) étaient bien limitées en termes de fonctionnalités au niveau des méthodes et l’héritage n’était pas supporté. Microsoft SQL Server n’offre pas de fonctions objet dans son langage SQL. En revanche, il permet d’intégrer des objets et méthodes à SQL via un langage de la plateforme .NET, par l’intermédiaire d’un run time (CLR, ou Common Language Runtime). Computer Associates propose à son catalogue le produit Jasmine (fruit des travaux menés depuis 1996 avec Fujitsu). Le système PostgreSQL est un autre dérivé du SGBD objet Postgres développé en 1986 à l’université de Berkeley par les concepteurs d’Ingres. PostgreSQL uploads/Ingenierie_Lourd/ bd.pdf

  • 30
  • 0
  • 0
Afficher les détails des licences
Licence et utilisation
Gratuit pour un usage personnel Attribution requise
Partager