IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le langage SQL, la synthèse - Chapitre 2 : définition des données : types, domaines, valeurs et NULL,
Un livre gratuit de Frédéric BROUARD

Le , par SQLpro
12 commentaires

286PARTAGES

27  0 

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.


:fleche: Les chapitres suivants vont suivre.

Bonne lecture ;)

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

Vous avez lu gratuitement 6 365 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

12 commentaires
Commenter Signaler un problème
fsmrel
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 30/07/2024 à 17:42


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

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

5  0 
SQLpro
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 24/09/2024 à 9:17
Citation Envoyé par tatayo Voir le message
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 ...
Citation Envoyé par al1_24 Voir le message
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 +
5  0 
sergio_is_back
Avatar de sergio_is_back
Expert confirmé https://www.developpez.com
Le 19/09/2024 à 9:11
Citation Envoyé par SQLpro Voir le message
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é
3  0 
tatayo
Avatar de tatayo
Expert éminent sénior https://www.developpez.com
Le 19/09/2024 à 9:42
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.
3  0 
al1_24
Avatar de al1_24
Modérateur https://www.developpez.com
Le 19/09/2024 à 12:22
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.
3  0 
fsmrel
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 13/10/2024 à 19:07
Citation Envoyé par SQLpro
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.

 
Citation Envoyé par fsmrel

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.
 
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.
3  0 
fsmrel
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 27/05/2024 à 14:25
Citation Envoyé par SQLpro Voir le message
A-t-on une version PDF ?

=>

Donc d'après cette image DVP propose le PDF.
2  0 
Commenter Signaler un problème