IdentifiantMot de passe
Loading...
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 3 - Création des objets : schémas, tables, vues, assertions,
Un livre gratuit de Frédéric BROUARD

Le , par SQLpro

712PARTAGES

18  0 
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.
Vous avez lu gratuitement 145 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 !

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