Discussion :

[SQLpro]

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).

Le langage SQL, la synthèse
Chapitre 1 - Les bases de données et le langage SQL

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.

Les chapitres suivants vont suivre.

Bonne lecture

Retrouvez les meilleurs cours et tutoriels pour apprendre Microsoft SQL Server.

[sergio_is_back]

Salut,

Une première partie très intéressante et bien documentée
Ça fait plaisir de te lire lorsque tu écris comme cela !!

[fsmrel]

Salut Fred,

A propos de l'ouvrage remarquable de Dominique Nanci (RIP), Ingénierie des systèmes d'information - Merise deuxième génération, il est directement accessible chez DVP :

Ingénierie des systèmes d'information - Merise deuxième génération

[SQLpro]

Salut Fred,

A propos de l'ouvrage remarquable de Dominique Nanci (RIP), Ingénierie des systèmes d'information - Merise deuxième génération, il est directement accessible chez DVP :

Ingénierie des systèmes d'information - Merise deuxième génération

A-t-on une version PDF ? Moi je l'ai en papier depuis des lustres...

A +

[SQLpro]

Chers membres du club,

J'ai le plaisir de vous présenter le chapitre 2 de mon premier livre gratuit sur le langage SQL.

Le langage SQL, la synthèse
Chapitre 2 - Définition des données : types, domaines, valeurs et NULL

Toute base de données repose sur un formalisme de données très important. Parce qu'elle est sensée stocker des données, une base de données doit posséder un typage fort qui permet de définir au mieux la façon dont les valeurs vont être placées dans les objets de la base.

Nous allons voir les types et les domaines ainsi que la spécification de valeurs (c'est à dire comment on « assigne » une valeur à un objet typé). Nous montrerons aussi le typage et le marqueur NULL qui indique l'absence de valeur. Nous donnerons un aperçu des apports de la norme SQL:1999 en matières de définition des données, qui s'est tournée vers le relationnel objet mais pêne à s'implanter dans les SGBDR.

Les chapitres suivants vont suivre.

Bonne lecture

Retrouvez les meilleurs cours et tutoriels pour apprendre Microsoft SQL Server.

[fsmrel]

A-t-on une version PDF ?

=>

Donc d'après cette image DVP propose le PDF.

[fsmrel]

 

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
 
 

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...

[SQLpro]

Chers membres du club,

J'ai le plaisir de vous présenter le chapitre 3 de mon premier livre gratuit sur le langage SQL.

Le langage SQL, la synthèse
Chapitre 3 - Création des objets : schémas, tables, vues, assertions

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…

Les chapitres suivants vont suivre.

Bonne lecture

Retrouvez les meilleurs cours et tutoriels pour apprendre Microsoft SQL Server.

[sergio_is_back]

Chers membres du club,

J'ai le plaisir de vous présenter le chapitre 3 de mon premier livre gratuit sur le langage SQL.

Bonne lecture

Je l'ai parcouru rapidement certes, mais c'est une excellente publication Frédéric
Tu as bien de mettre l'accent sur les contraintes, combien de bases de données j'ai vu sans aucune contrainte sans aucun index, sans relation entre tables, toutes les vérifications d'intégrité sont déportées dans le code des applications ce qui les rend lourdes et inefficaces alors que SGBD pourrait prendre en charge tout (ou une très grande partie) de ces vérifications d'intégrité

[tatayo]

Bonjour,
De toutes les bases de données qui sont en exploitation chez nous, une seule a des contraintes: celle dont je suis le responsable.
Et encore, j'ai dû "lourdement" insister pour que ces contraintes soient en place, mon chef a tendance à considérer qu'une base de données n'est qu'un simple contenant .

Il en est de même pour les identifiants de type "identity" d'ailleurs, parce que "si je veux faire une mise à jour, c'est plus compliqué", alors qu'une vue avec un trigger ("pas de trigger !") "instead of" résout la question.

Tatayo.

[al1_24]

C'est une rumeur qui a plus d'une trentaine d'années selon laquelle les contraintes ralentissent les traitements et bloquent des transactions (ce qui semble normal quand les règles d'intégrité ne sont pas respectées ).

Quant aux triggers, c'est le mal , parce que les développeurs applicatifs n'ont plus complètement la main sur ce qui se passe dans la base de données.
Même refus pour les vues et encore pire pour les vues modifiables, pour les mêmes raisons.

Et comme le SQL est malheureusement souvent mal enseigné voire pas du tout, on se retrouve avec des applications qui rapatrient le détail des lignes d'une facture pour en calculer le total qui est la seule information recherchée.

[SQLpro]

Bonjour,
De toutes les bases de données qui sont en exploitation chez nous, une seule a des contraintes: celle dont je suis le responsable.
Et encore, j'ai dû "lourdement" insister pour que ces contraintes soient en place, mon chef a tendance à considérer qu'une base de données n'est qu'un simple contenant ...

C'est une rumeur qui a plus d'une trentaine d'années selon laquelle les contraintes ralentissent les traitements et bloquent des transactions (ce qui semble normal quand les règles d'intégrité ne sont pas respectées )....

En réponse aux contraintes qui seraient contre performantes et ralentirait la base de données, j'ai donné il y a plus de 10 ans une conférence dans les journées SQL chez Microsoft sur le sujet en procédant à des tests... Bilan, les contraintes simple sont non seulement pratiquement indécelable en temps de réponse mais permettent à l'optimiseur de former des plans d'exécution des requêtes plus optimale, donc plus rapide, donc plus performant...

Extrait :

A +

[fsmrel]

La théorie sur laquelle repose SQL a été énoncée par le professeur Edgar Frank Codd (1924-2003)

Codd n’et pas né en 1924, mais le 19 août 1923 et il est mort le 18 avril 2003.

 

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.

 
En fait, en 1974, Codd a brossé les grands traits d’un prototype appelé Rendezvous ([Codd1974]), utilisant son langage relationnel ALPHA, décrit dans [Codd1971]. A côté de la théorie relationnelle pure et dure, Codd a effectivement voulu créer un système, le fameux Rendezvous, mais dont la fonction était de permettre de traduire en requêtes ALPHA les demandes formulées en anglais (ou autre langue) par un utilisateur lambda.

En 1977 (cf. [Codd1978]), il a développé et testé ce prototype avec la collaboration de R. S. Arnold, J-M. Cadiou, C. L. Chang, N. Roussopoulos.

@SQLpro

Il ressort que nous ne nous sommes pas compris. A te lire, Fred, j’ai cru comprendre que LE langage de référence pour les bases de données relationnelles devait être en anglais ! En fait, donc à côté de la théorie relationnelle pure et dure, Codd a effectivement voulu créer le système Rendezvous, dont la fonction était de permettre de traduire en requêtes ALPHA les demandes formulées en anglais (ou autre langue) par un utilisateur lambda.

Exemple de dialogue avec Rendezvous, extrait de [Codd1974] :

"... consider the following sample dialog between a casual user and the data base described above. We shall assume for this example that the user has an adequate idea of what each relation name and attribute denotes. However, we do not assume he knows what a relation is in the abstract sense. Neither do we assume he knows anything about the concepts of attribute, domain. Relational algebra, etc.


SYSTEM: Please proceed

USER: Give me a list of the part numbers, quantities, and suppliers of Houston parts

SYSTEM: You are requesting (among other things) a listing of quantities of parts. Do you want:
1. quantities on hand
2. quantities on order
3. quantities shipped ?

USER: I want quantities on order

SYSTEM: Fine! Now, with regard to "Houston parts”, do you mean:
1. parts supplied by Houston suppliers
2. parts supplied to Houston projects
3. parts associated with Houston in some other way ?

USER: I mean item 2

Etc.

[Codd1971]. A Data Base Sublanguage Founded on the Relational Calculus.

[Codd1974]. Seven Steps to Rendezvous with the Casual User.

[Codd1978]. Access to relational data bases for a casual user.