Le langage SQL, la synthèse - Chapitre 1 - Les bases de données et le langage SQL
Chers membres du club,
J'ai le plaisir de vous présenter le chapitre 1 de mon premier livre gratuit sur le langage SQL pour remplacer tous mes écrits précédents (livre papier et articles sur le langage SQL publiés sur developpez.com).
Citation:
Le langage SQL est le fruit d'années de réflexion sur la problématique de manipulation des données. Formalisé et normalisé, ce langage est né dans les années 80 et a vite été adopté par la majorité des éditeurs.
Grâce à un comité de normalisation dynamique, il s’est constamment adapté aux besoins des utilisateurs. Ainsi après la norme SQL 2 de 1992 formant le cœur du langage on trouve des versions majeures et mineures en 1999, 2003, 2006, 2008, 2011, 2016, 2019 et 2023 !
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 qui elle-même repose sur des concepts mathématiques (théorèmes de Heath et Fagin-Date, axiomes d’Armstrong…) traduit en un formalisme pratique (formes normales).
Ce sont les sujets que nous allons aborder dans ce chapitre et nous terminerons en présentant la base de données qui nous servira de fil rouge pour la majorité des exemples du livre et certains exercices.
:fleche: Les chapitres suivants vont suivre.
Bonne lecture ;)
:fleche: Retrouvez les meilleurs cours et tutoriels pour apprendre Microsoft SQL Server.
A propos du § I-1. Historique des systèmes de gestion de bases de données (SGBD)
Citation:
Envoyé par Fred
la théorie sur laquelle repose SQL a été énoncée par le professeur Edgar Frank Codd
Le Dr. Codd n’a jamais été professeur ! Inventeur génial, chercheur ayant trouvé, conférencier à l’occasion, oui. Pour plus de détails : https://en.wikipedia.org/wiki/Edgar_F._Codd
Citation:
Envoyé par Fred
Codd voulait créer un système où l’interrogation des données devait utiliser le vocabulaire anglais
Certainement pas ! Codd était un mathématicien, et comme tout mathématicien il écrivait des équations. A nous de nous en accommoder.
Dans son article fondateur de 1970 A Relational Model of Data for Large Shared Data Banks (voir le § 1.5 Some Linguistic Aspects), au § 2.1 Operations on Relations, Codd définit et nomme évidemment les opérateurs relationnels en anglais (permutation, projection, join, composition, restriction). Pour leur utilisation, c’est une autre paire de manches...
Exemple (§ 2.1.3 Join) :
The natural linear 3-join of three binary relation R, S, T is given by Codd n’a pas mis beaucoup d’anglais dans cette jointure...
Ou encore (§ 2.1.4 Composition) :
« Corresponding to the natural join of R with S is the natural composition of R with S defined by R.S = π₁₂(R*S). »
Dans son article de 1971, A Data Base Sublanguage Founded on the Relational Calculus, Codd propose le langage ALPHA, toujours pas d’anglais en vue.
Ainsi au paragraphe 4.3 :
« Find the name and location of all suppliers, each of whom supplies all projects » :
Plus british tu meurs...
Cela dit, Codd est conscient que les pauvres humains que nous sommes souhaiterions requêter en langage naturel, mais il ne propose pas de solution, sinon des directions envisageables à prendre (dialogue utilisateur lambda/système relationnel, façon IA) (cf. (Seven steps to RENDEZVOUS with the casual user (1974). A noter, à la fin de l’article de Codd, sa discussion avec certains intervenants, dont Claude Delobel.
Au fil des ans, ça n’évolue pas Ainsi, dans Extending the database relational model to capture more meaning publié en 1979, Codd fournit l’exemple suivant, caractéristique de son style pas so british :
Example B. Obtain the employee name and jobtype for all employees with an excellent rating, assuming that:
(1) There are distinct entity types for each jobtype (e.g., secretary, trucker, engineer, etc.) and the jobtype category partitions the set of employees.
(2) The immediate generalization of these types is to the entity type employee.
(3) Employee name and jobtype are recorded in one or more of the P-relations associated with employee.
(4) Rating is recorded separately in a P-relation for each jobtype.
Solution :
R1 ← UGI[SUP = emp, PER = jobtype] [SUB].
Je doute à nouveau de l’utilisation pleine et entière du vocabulaire anglais.
Et ça n’est pas dans son ouvrage de référence ultime que les choses auront évolué The Relational Model for Database Management...
A leur tour, en 1973, Boyce et Chamberlin s’y sont collés, avec SQUARE, cf. leur article (postdaté 1975) Specifying Queries as Relational Expressions: The SQUARE Data Sublanguage. On lit notamment :
SQUARE is intended for use by the nonprogramming professional
Mais en 1974, il ont proposé SEQUEL (SEQUEL: A Structured English Query Language) :
SEQUEL language is equivalent in power to SQUARE, but is intended for users who are more confortable with an English-keyword format than with the terse mathematical notation of SQUARE.
Raymond Boyce (qui a aidé Codd à accoucher de la BCNF (forme normale de Boyce Codd) est mort cette année-là. A propos de cet accouchement, voir le § 3 (Normalization of Relations) de l’article : Recent Investigations in Relational Data Base Systems.
Enfin, en 1976, l’article fondateur SEQUEL 2 (SEQUEL 2: A Unified Approach to Data Definition, Manipulation, and Control)), (renommé ensuite en SQL pour les raisons de copyright que vous savez).
Ainsi naquit SQL et on y trouve quand même plus de mots anglais que dans les équations et formules de Codd...
Chapitre 3 - Création des objets : schémas, tables, vues, assertions
Chers membres du club,
J'ai le plaisir de vous présenter le chapitre 3 de mon premier livre gratuit sur le langage SQL.
Citation:
Si la modélisation conduit à la structuration de la base, le type des données, comme la composition des objets et les règles de validation par contraintes sont une composante fondamentale de la qualité d'une base de données :
une qualité de données de plus en plus demandée notamment pour couvrir les besoins du décisionnel (analyse de cubes OLAP en particulier, BI temps réel…) ;
une structuration de plus en plus précise pour coller à la réalité des objets procéduraux (mapping relationnel objet par exemple) ;
des règles de validation de plus en plus sophistiquées se rapprochant de la logique « métiers » des applicatifs.
La création des objets SQL répond donc à cette triple approche.
Dans ce chapitre, nous allons nous intéresser à la construction des tables (CREATE TABLE), à leurs interdépendances au travers de l'intégrité référentielle, et nous montrerons l'intérêt des vues. Nous terminerons par la modification et la suppression des objets existant (ordre SQL ALTER et DROP) et finalement présenterons un moyen de créer des tables à la volée. Pour cela nous aurons besoin de définir ce que sont les contraintes parmi lesquelles nous avons déjà mentionné au chapitre précédent celles de domaines et nous découvrirons les assertions qui sont des contraintes générales exprimées au niveau de la base de données. Tous ces éléments, et les types du chapitre précédent, composent le DDL, la subdivision du SQL qui s'occupe de créer, modifier et supprimer les schémas et les objets qu'ils contiennent.
Mais avant tout cela il nous faut porter un regard attentif à la règle de formation des noms des objets SQL ainsi qu’à la façon dont on se connecte à un serveur de bases de données relationnelles…
:fleche: Les chapitres suivants vont suivre.
Bonne lecture ;)
:fleche: Retrouvez les meilleurs cours et tutoriels pour apprendre Microsoft SQL Server.
