Commentaires

Merci pour ton retour.

Envoyé par CinePhil

la contrainte CHECK produite mais commentée qui est due à la cardinalité mini de 1 dans l'association entre commande et ligne_commande !
Pourquoi est-elle commentée et marquée comme non-implémentée ?
Sous MySQL, ça peut se comprendre puisque MySQL n'a toujours pas, à ma connaissance, implémenté les contraintes CHECK mais sous PostgreSQL qui respecte mieux la norme, je ne comprends pas.

Dans le cas de PostgreSQL, certaines contraintes peuvent être codées, mais seulement les plus simples. Par exemple :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
CREATE TABLE S
(
    A             integer            NOT NULL
,   B             integer            NOT NULL
, CONSTRAINT S_PK PRIMARY KEY (A)
, CONSTRAINT S_CHK_01 CHECK (A > B)
) ;

Dans ces conditions, si on tente

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
INSERT INTO S (A, B) VALUES (5, 6) ;

Alors, à juste titre, on se fait jeter :

Envoyé par PostgreSQL

la nouvelle ligne viole la contrainte de vérification « s » de la relation « chk_01 »

A ceci près que PostgreSQL devrait permuter les éléments entre guillemets :

la nouvelle ligne viole la contrainte de vérification « chk_01 » de la relation « s »

En tout cas, dès qu’il y a une fonction ou une sous-requête, PostgreSQL abandonne :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
ALTER TABLE S ADD CONSTRAINT CHK_02 CHECK (EXISTS (SELECT 'vrai' FROM S WHERE A = 5)) ;

=>

Envoyé par PostgreSQL

ERREUR: ne peut pas utiliser une sous-requête dans la contrainte de vérification

Ou encore (avec des approximations orthographiques de sa part) :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
ALTER TABLE SP ADD CONSTRAINT CHK_03 CHECK (COUNT(*) > 0) ;

Envoyé par PostgreSQL

ERREUR: les fonctions d'agrégats ne sont pas autorisés dans les contraintes CHECK

Autrement dit, comme c’est précisé dans la doc de PostgreSQL, la règle F671 de la norme SQL est laissée de côté (à savoir « Enhanced integrity management ») :

Envoyé par le père de PostgreSQL

Subqueries in CHECK intentionally omitted.

On doit donc laisser les contraintes sous forme de commentaires.

Envoyé par CinePhil

Un point négatif : il ne semble pas y avoir de visualisation du script avant sa sauvegarde. Ce serait plus simple de vérifier et corriger le script directement dans DB-Main. Comme ce logiciel semble avoir été fait sur une base de l'AGL Eclipse, il doit pourtant avoir un éditeur intégré.

Quand tu as choisi le SGBD, DB-MAIN génère d’office le DDL présenté en fin du billet. Pour le visualiser, tu cliques sur le nom du fichier, comme précisé dans l’image que je viens d’ajouter. Pour le modifier, ça n’a pas l’air possible, il y a bien une case « lock », mais elle ne semble pas pouvoir être décochée (et la doc est muette). Soit tu reviens sur le MLD, soit tu modifies hors DB-MAIN...

Envoyé par CinePhil

Petit détail d'interface peu pratique sur cette partie du tutoriel mais peut-être que cela est dû à mon utilisation de DB-Main sous Linux : Lorsqu'on choisit la cardinalité dans la liste déroulante, cette dernière se réduit mais reste active en mode sélection. Il faut spécifiquement cliquer sur le bouton de validation pour reprendre la main. Même l'usage de la touche entrée est inopérant.

C'est effectivement un mode de fonctionnement propre à DB-MAIN et un peu agaçant (cela vaut aussi dans le contexte Microsoft Windows) : d’une façon générale quand on a agi dans liste déroulante, il faut cliquer sur le bouton de validation pour entériner l’action. La touche Entrée est sans effet...

Suite à ta remarque, j’ai ajouté une phrase à ce sujet (cf. (4) Cardinalités).

Envoyé par alassanediakite

Salut
Avec vous on prend plaisir à lire la science.
François, quel peut être l'intérêt d'avoir une table "reglement" si la facture ne peut avoir qu'au plus un règlement?
Si c'est pour éviter le NULL, le champ (la colonne ) "montantreglement" est une "redondance inutile".
Ah! le temps des dinosaures .
@+

Eh bien, Bunny !
Le MCD initial (ainsi que le MLD et le script SQL qui en sont dérivés) comporte les identifiants « naturels » dont se sert l’utilisateur : codeClient (entité-type CLIENT), numeroFacture (entité-type FACTURE), numeroReglement (entité-type REGLEMENT). Si donc au stade relationnel la relvar (variable relationnelle) REGLEMENT était phagocytée par la relvar FACTURE, il faudrait donc que cette dernière soit dotée d’un attribut numeroReglement, clé candidate, mais pouvant être marquée NULL ! Par ailleurs, il n’y a pas redondance, on ne peut pas faire l’économie de l’attribut montantReglement (pouvant lui aussi être marqué NULL), car le montant d’un règlement peut parfaitement être différent du montant de la facture.

Laissons les relvars de base comme elles sont, et si tu tiens à n’avoir qu’une relvar, alors celle-ci prendra la forme d’une relvar dérivée, représentée en SQL par la vue FACTURE_REGLEMENT que j’ai proposée.

Envoyé par Lino Léum

Ça m'avait effectivement amusé, à l'époque, de voir que la SNCF avait appelé Socrate son calamiteux système de réservation alors que, par ailleurs, elle utilisait encore le SGBD Socrate. La confusion était probable.
Les bases de Socrate ont été posées au début des '70 par une équipe constituée autour de Jean-Raymond Abrial à l'IMAG, aidée par des travaux de Georges Gardarin et Claude Delobel, entre autres.
Quant au Professeur S., ça ne m'étonne pas qu'il ait pu faire l'éloge de ce SGBD, dont le système interne de gestion d'espace virtuel était une superbe mécanique, mais qui avait une tare certaine : une taille physique figée (non extensible automatiquement) de la base de données sur le disque ; certes, des outils permettaient de modifier aussi bien le nombre limite d'occurrences de chaque entité (précision obligatoire dans le schéma) et la taille physique du fichier support, mais ça n'avait strictement rien de dynamique.
Constatant que le modèle relationnel écrasait tout sur son passage, Syseca s'est alors lancée dans le développement du projet MUST, un successeur relationnel à Socrate-Clio. Sauf qu'ils ont eu la très mauvaise idée de cibler OS/2 comme système d'exploitation support du SGBD. On sait ce qu'il est advenu de ce système. Et les coûts de développement de MUST on fait que Thomson-CSF a finalement décidé de jeter l'éponge.

À part ça, j'ajoute que vos articles sont extrêmement intéressants. Découverts depuis peu avec un vrai plaisir.

Merci, Lino, pour l’intérêt que vous portez à mes articles, en espérant ne pas vous trop décevoir ici ou là... Vous évoquez J.-R. Abrial, C. Delobel et G. Gardarin, des grands parmi les grands dans le monde des base de données. Les séminaires animés par G. Gardarin m’ont beaucoup apporté, ainsi que son remarquable ouvrage « Bases de données, les systèmes et leurs langages ». Je me sens coupable de ne m’être que très modérément intéressé aux travaux de J.-R. Abrial, mais à ma décharge, je n’ai jamais eu l’occasion d’utiliser Socrate et de modéliser avec Z : pour la peine, j’ai donc rouvert un de mes anciens et néanmoins précieux livres de chevet, « bases de données et systèmes relationnels », de C. Delobel et M. Adiba, et parcouru la partie décrivant le modèle réseau Socrate, sans oublier Z, tout cela avec l’âme du débutant...

Dans mon article (mal remis en forme par DVP, mais bon...) traitant de la normalisation des bases de données, j’ai eu à m’insurger contre un clerc inconscient, prétendant démontrer (cf. paragraphe 2.8, le 2e exemple) que Delobel et Adiba auraient eu tout faux quand ils prouvèrent que la quatrième forme normale implique la forme normale de Boyce-Codd (cf. paragraphe 4.14) : ça m’a donné l’occasion de citer Flaubert...

Dommage pour MUST. De son côté, Larry Ellison avait fait le bon pari en implémentant, vampirisant littéralement System R (non brevetable semble-t-il), et en le renommant Oracle... Un papier instructif à ce sujet : Codd almighty! How IBM cracked System R.

Envoyé par Lino Léum

Pour ce qui est des SGBD pré-relationnels, z'avez oublié de citer Socrate (devenu Clio ensuite) de Syseca (filiale de Thomson-CSF), qui a permis à de grosses (et moins grosses) entreprises françaises de bâtir des applications stratégiques (EDF, SNCF, la Défense...).

Je bats volontiers ma coulpe. Cela dit, vous mentionnez la SNCF : il y a environ 25 ans, j’y ai audité non pas le SGBD Socrate, mais une partie du système de réservation du même nom, à l’occasion de l’audit que j’avais fait du cœur du MCD (surréaliste, pour ne pas dire plus) de son partenaire (back-office) Aristote, suite à la mise en production calamiteuse de ce dernier, en l’absence de tout prototypage de performance (entre autres manques). En discutant un peu plus tard de Socrate avec le Professeur S., celui-ci avait fait à juste titre l’éloge du SGBD alors que je pensais avec étonnement qu’il parlait du système de réservation, plutôt catastrophique à l’époque (décidemment...) et qui agaçait le public (tandis que les agents de la SNCF essayaient de se faire leur propre sous-système dans le système). J’ai mis un moment pour me rendre compte du quiproquo...

Envoyé par ring0

Bonjour,

J'apprécie beaucoup vos articles, sur le fond, sur la forme, les sujets et leur traitement. Continuez! Nous voulons plus, du plus fort. Les Formes normales par exemple.

Cela dit, NULLIF je ne connais pas, ne serait-ce pas IFNULL ? (par exemple : https://dev.mysql.com/doc/refman/5.7...unction_ifnull ) ?

Merci encore pour votre travail,

Dans l'espoir de vous lire.

-- ring0

Merci ring0 pour vos appréciations. Je réponds tardivement, mais le comptage des commentaires par DVP laisse à désirer (il est aujourd’hui à 0) et du coup je n'ai pas vu qu'en fait il y avait du courrier...

Pour les formes normales, c'est ici que ça se passe !

Quant à NULLIF, je l’ai utilisé avec PostgreSQL, lequel est conforme à la norme SQL, selon laquelle l’expression NULLIF(x,y) est définie comme équivalente à l’expression

CASE WHEN x = y THEN NULL ELSE x END

.

linker.storm, merci pour votre appréciation.

Quant au verbe pallier, je suis quand même au courant depuis bien des décennies. Cela dit, je ne cherche pas à « pallier le moyen d’une représentation graphique », ce qui n'aurait aucun sens, mais c'est bien « au moyen d'une représentation graphique que je cherche à pallier les imprécisions des auteurs ». Autrement dit, je persiste et signe, ce que j'ai écrit est correct et ne relève pas du solécisme ou autre faute grossière de français. Afin d’éviter les quiproquos, tout au plus pourrais-je intercaler une virgule entre les mots « pallier » et « au ».

Ave Philippe,

Je te renvoie à Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), page 138 paragraphe « Propriété à valeurs calendaires », figure 7.49.

Ave Philippe,

Jusqu’ici je n’avais pas vu ton commentaire, car dans la page d’accueil de mes billets, le compteur des commentaires est à 0...

Comme je manque d’entraînement en MySQL et SQL Server et que je me remets actuellement un peu à PostgreSQL, je passe à celui-ci.

La norme SQL (depuis SQL/92) permet que n’importe quelle contrainte puisse être dans l’état soit immédiat, soit différé. PostgreSQL l’a pris en compte, d’où la possibilité de différer le contrôle de l’intégrité référentielle (INITIALLY DEFERRED), et je déclare donc les clés étrangères par ALTER TABLE, à la suite des CREATE TABLE initiaux (et en plus je code ON UPDATE CASCADE, ça sera utile lors de l’exécution des instructions UPDATE, remplacement par exemple de Raoul par Paul à la tête de l’agence Volfoni :

ALTER TABLE DIRECTEUR ADD CONSTRAINT DIRECTEUR_AGENCE_FK FOREIGN KEY (AgenceId)
       REFERENCES AGENCE (AgenceId) ON UPDATE CASCADE 
       INITIALLY DEFERRED ;
;

ALTER TABLE AGENCE ADD CONSTRAINT AGENCE_DIRECTEUR_FK FOREIGN KEY (DirecteurId)
       REFERENCES DIRECTEUR (DirecteurId) ON UPDATE CASCADE 
       INITIALLY DEFERRED ;
; 

Ceci fait, comme le contrôle de l’intégrité référentielle est dans l’état différé, j’effectue les INSERT sans problème, directement dans les tables :

INSERT INTO AGENCE (AgenceId, DirecteurId, AgenceNom)
       VALUES (314, 456, 'Agence Volfoni') ;

INSERT INTO AGENCE (AgenceId, DirecteurId, AgenceNom)
       VALUES (271, 123, 'Agence Naudin') ;

INSERT INTO DIRECTEUR (DirecteurId, AgenceId, DirecteurNom)
       VALUES (456, 314, 'Raoul') ;

INSERT INTO DIRECTEUR (DirecteurId, AgenceId, DirecteurNom)
       VALUES (123, 271, 'Fernand') ;

Suite à quoi, j’active sans différer (sic !) le contrôle de l’intégrité référentielle :

SET CONSTRAINTS AGENCE_DIRECTEUR_FK IMMEDIATE ;
SET CONSTRAINTS DIRECTEUR_AGENCE_FK IMMEDIATE ;

Et si l’intégrité référentielle a été violée lors des INSERT qui précèdent, la patrouille nous rattrapera...

Je te prie de noter que l’enchaînement :

ALTER TABLE

INSERT

SET CONSTRAINTS

est un mélange ad-hoc de DDL et de DML, ce qui est laid et bien lourd comparativement à la solution de l’affectation multiple exposée dans le billet, et ne doit pas concourir à la performance ; quant aux conséquences sur les tâches concurrentes, croisons les doigts pour que le SGBD garantisse la règle d’isolation (voir les propriétés ACID) tant que l’intégrité référentielle est débranchée.

En tout cas, si le coup de l’oeuf et de la poule est ici résolu, en l’état rien n’empêche une fois de plus que Raoul dirige l’agence Naudin et l’on intuite qu’il va falloir encore des triggers pour l’en empêcher (sinon gare au bourre pif...), alors que la solution en Tutorial D est concise, élégante, et ne mélange pas les genres. Je rappelle :

    CONSTRAINT DIRECTION_CHK01
        DIRECTEUR {DirecteurId, AgenceId} = AGENCE {DirecteurId, AgenceId} ;

Certes, coder une instruction SQL CREATE ASSERTION permettrait de se simplifier la vie, d’éviter la mise en oeuvre de triggers, car contrôler les règles de gestion des données n’est pas leur vocation, c’est bien celle des assertions, mais les SGBD mettront-ils un jour cette instruction à notre disposition ?

Pour en venir au remplacement de Raoul par Paul, pas de problème, grâce à l’action de compensation CASCADE retenue lors de la déclaration des clés étrangères :

 
UPDATE DIRECTEUR SET DirecteurId = 789, Directeurnom = 'Paul' WHERE DirecteurId = 456 ;

PostgreSQL met à jour la table AGENCE, dans laquelle on vérifie donc désormais DirecteurId = 789 (je m’en suis assuré).

En me focalisant sur PostgreSQL, je n’ai répondu qu’en partie à ta question, il faudrait voir l’impact de l’action de compensation CASCADE dans le cas de SQL Server (SQLpro a certainement la réponse ), quant à MySQL, I give my tongue to the cat...

Merci Zizoua !

@ blemjid,

Les 12 règles de Codd concernent tous les SGBD. Vous aurez noté qu'elles datent de 1985, époque à laquelle SQL Server n'existait pas...

Envoyé par ALWEBER

Le SIRET est à la base un clé primaire fournie par l'organisme générateur de ce numéro.

Que l’INSEE définisse le numéro SIRET comme étant un identifiant d'établissement, d’accord, mais cet organisme n’est évidemment pas habilité à donner la définition de la clé primaire, concept relevant de la théorie relationnelle (qui est une branche des mathématiques appliquées). C’est Ted Codd qui a défini pour la première fois ce concept en 1970, dans A Relational Model of Data for Large Shared Data Banks, avant d'en faire évoluer la définition.

Pour l’utilisateur de la base de données, le SIRET est un point d’entrée dans le système pour accéder aux données d’un établissement, avec la garantie que deux établissements n’auront pas le même SIRET.

Que le SIRET fasse l’objet d’une clé alternative, rien de plus légitime, et les administrateurs des données de la banque dont j’ai fait mention (sans la nommer, mais il ne s'agit pas de la moindre !) l’ont bien compris, en mettant à la poubelle un paquet de routines et de tables devenues inessentielles, après avoir déchu le SIREN de son rang initial de clé primaire, concept stratégique dans le contexte de l’intégrité référentielle, et l'avoir ravalé au rang de dauphine, de clé alternative.

Le système d’information doit avoir la maîtrise complète de l’affectation des clés primaires, lesquelles n’ont à dépendre d’un système externe, aussi respectable soit-il, ni des lubies de l’utilisateur.

Envoyé par ALWEBER

Si tu veux travailler correctement tu dois gérer des ensembles de SIRET et gérer la manière dont ils sont assemblés.

En l’occurrence on se situe plutôt au niveau du COMMENT, mais la base de données n’est concernée que par ce qui est essentiel, à savoir le QUOI : le COMMENT (la manière d’assembler) aura toujours sa solution, quitte à développer des contraintes ad-hoc, directement attachées à la base de données quand c'est possible (cf. l’instruction CREATE ASSERTION de la norme SQL ou l'instruction CREATE TRIGGER).