Discussion :

[Franck_P]

Bonjour,

Je souhaiterais savoir si le fait de concentrer l'ensemble des regles métiers (Via SQL, triggers, ...) sur une base de donnée d'un SI est un facteur générateur de probleme pour le SGBD.

Cette technique permet de centraliser les regles métiers en 1 seul point et donc une meilleur admin du SI et des evolution. Mais quel est l'impact que l'on peut attendre de cette technique (perte de perf ou pratique a privilégier) ????

Quelle reflexion faut-il privilégier dans la l'etude d'un SI (PME) concernant le cadre SGBD ?

Merci

NB : La base concernée serait du type SQL server 2005

Franck_P

[qi130]

Un des inconvénients que je vois est que, implémenter le fonctionnel au sein du SGBD oblige à remonter l'ensemble des données (y compris celles non stockées) vers le serveur pour les valider fonctionnellement.

Ensuite, cette manière de procéder peut trouver rapidement ses limites:
- les capacités de manipulation des données d'un SGBD restent inférieures à ce que permet un L4G (calculs par exemple)
- les architectures distribuées font appel à des données pouvant se situer sur des bases différentes, voire des serveurs différents, et là ça coince !

Si dans ton cas (PME), la question ne se pose pas dans l'immédiat, il faut à mon sens privilégier l'évolutivité de la solution. Demain, cette PME pourrait avoir besoin de données administratives, bancaires ou des données de ses fournisseurs (serveur externe).

[fsmrel]

Bonsoir Franck,

Votre interrogation concernant la sous-traitance des règles métier au SGBD est de première importance car elle met en évidence l’alternative du QUOI et du COMMENT : en effet, faut-il continuer à développer du code procédural, plus ou moins maintenable, à raison de deux ou trois cents lignes de code par règle (le COMMENT) ? Ou bien décrire ces règles (le QUOI) selon le mode déclaratif du SGBD, en deux ou trois lignes ?

Avant d’aller plus loin, une anecdote. Alors que tous les utilisateurs de DB2 réclamaient à cors et à cris la mise en œuvre de l’intégrité référentielle par le SGBD, début 1988 IBM annonça enfin qu’ils avaient été entendus et que la fonctionnalité leur était offerte. En juillet 1988, avant l’arrivée officielle en France de la nouvelle version de DB2, j’ai pu disposer de celle-ci car je travaillais en partenariat avec IBM pour le développement d’une application sensible, chez un grand industriel français. J’avais pour mission de valider le modèle de données et d’engager IBM et mon entreprise sur les performances attendues par le maître d’ouvrage (temps de réponse des transactions avec un nombre donné d’utilisateurs simultanément connectés et modifiant à tour de bras les stocks et autres objets sensibles).

J’ai donc très rapidement mis en œuvre et secoué l’intégrité référentielle selon DB2 afin de quantifier le surcoût qu’elle représentait en termes de CPU et d’entrées/sorties, par rapport à un développement selon lequel c’est le développeur qui programme les contrôles d’intégrité. Bilan final : il n’y eut pas photo, avantage décisif à DB2, alors qu’au départ j’étais plutôt inquiet. Et il s’agissait ici de l’aspect performance. Quant à l’intégrité des données proprement dite, inutile d’en parler, le SGBD contrôle tout, 24 heures sur 24, il ne laisse rien passer. Au contraire, les contrôles programmés dans les applications finissent avec le temps par laisser passer bien des choses, je vous renvoie à ce sujet au commentaire que j’ai fait sur ce forum :

http://www.developpez.net/forums/sho...d.php?t=241850

Mais dans le même temps, à en croire la presse du cœur informatique de l’époque, le sentiment général des "experts" était le suivant : « DB2 sait maintenant gérer l’intégrité référentielle, mais finalement, n’est-il pas plus raisonnable de continuer à faire comme avant, de manière applicative ? En effet il risquerait bien d’y avoir de très gros problèmes de performance... » Moralité, ceux qui réclamaient à juste titre une fonctionnalité fondamentale devinrent très réservés une fois qu’ils en bénéficièrent : ils eurent mieux fait de retrousser leurs manches et de juger sur pièce...

Le QUOI et le COMMENT

Il est clair qu’il faut détricoter le QUOI du COMMENT. Si l’on part du principe que le SGBD est moins performant que le code procédural que l’on développe soi-même, on reste là, chacun rentre chez soi, et conserve ses petites habitudes. Vous aurez compris que par rapport à votre alternative : "perte de perf ou pratique à privilégier", je vous propose de vous occuper d’abord du QUOI. En effet, la validité de l’information (son intégrité) passe avant le reste et se situe au niveau conceptuel. Le COMMENT n’intervient qu’au niveau de la réalisation et vu la puissance des moteurs relationnels, on n’a pas de raisons de s’inquiéter de façon systématique d’une hypothétique perte de performance.

Je me base sur ma longue expérience de DBA ayant eu à concevoir des bases de données relationnelles, en qualifier d’autres, à en auditer, parfois à en sauver du naufrage. Si votre SI est sain, complet et non contradictoire, si votre modèle conceptuel est correct, si votre base de données est normalisée, si votre DBA connaît bien son affaire, vous ne connaîtrez pas de déboires (que de si, mais il d’agit du SI...) Fi de l’émotion et des oiseaux de mauvais augure. Mais bien sûr, il ne faut pas être naïf et se jeter à corps perdu dans une direction ou dans l’autre : rien de tel que de prototyper de façon sérieuse, pour juger objectivement. Je retiens pour ma part que le code procédural que l’on a développé ne fait pas le poids au plan de la performance, face aux moteurs relationnels pour peu qu’on les utilise pour ce qu’ils savent faire : ce sont de grands brasseurs d’ensembles (de lignes), peu faits pour traiter ligne par ligne, ne perdons pas de vue que les opérateurs relationnels sont ensemblistes, ne leur enlevons pas leur turbo.

Pour en revenir au niveau conceptuel, je vous conseille d’écrire vos règles de manière formelle, en vous appuyant sur le Modèle relationnel de données, en l’occurrence à l’aide de Tutorial D, l’enfant de Date et Darwen. On y apprend à exprimer de façon dense mais formelle des règles aussi diverses que :

_ Le salaire d’un employé ne peut pas régresser.

_ Le total des salaires d’un département de l’entreprise ne peut pas dépasser la moitié du budget de ce département.

_ Une facture comporte au moins une ligne de facture.

_ Le montant total des factures non réglées par un client ne peut pas dépasser le crédit autorisé pour ce client.

_ Etc.

Ces règles sont des contraintes. Mais il existe aussi des processus qui peuvent être déclenchés. Par exemple :

_ Si la quantité disponible en stock devient inférieure à la limite, déclencher le processus de réapprovisionnement.

A cette occasion, on peut se rendre compte qu’une contrainte n’est pas un processus, elle est un élément de la loi, ne mélangeons pas. Dressons deux catalogues, un pour les contraintes, l’autre pour les déclencheurs de processus.

Pour en venir aux SGBD commercialisés (sans oublier le standard SQL), leur problème est qu’ils n’aident pas outre mesure à l’expression des contraintes.

Ainsi, d’une manière générale, certaines contraintes sont des contraintes de type, préexistant par définition aux tables dont les colonnes y feront référence. Supposons par exemple qu’une cinquantaine de tables soient dotées de colonnes de type date soumises à la contrainte : la date ne peut être antérieure au 01/01/2000. En Tutorial D, on peut définir un type du genre :

TYPE Date_Min POSSREP {D Date
CONSTRAINT D >= 01/01/2000} ;

Mais avec le standard SQL:1999 et les SGBD qui s’en réclament, si vous pouvez définir des types, vous n’avez pas la possibilité d’y intégrer des contraintes : vous apprendrez au SGBD, autant de fois qu’il y a de colonnes impliquées, que le 01/01/2000 est une limite inférieure. Le standard propose bien l’instruction Create Domain permettant de contourner la difficulté, mais on perd alors la possibilité de typer les données. Un cauchemar...

Avec SQL Server, vous pouvez définir une contrainte d’intégrité avec l’instruction Create Rule, mais là encore, attention. Il est écrit (et ça tempère l'enthousiasme) :

"CREATE RULE will be removed in a future version of Microsoft SQL Server. Avoid using CREATE RULE in new development work, and plan to modify applications that currently use it. We recommend that you use check constraints instead. Check constraints are created by using the CHECK keyword of CREATE TABLE or ALTER TABLE."

Autrement dit, avec SQL on ne peut pas exprimer de contrainte qui ne fasse pas intervenir au moins une table. Dommage.

Qui plus est, si avec le standard SQL, grâce à l’instruction CREATE ASSERTION vous pouvez au moins exprimer des contraintes (avec la réserve donc de faire mention d’au moins une table), avec les SGBD cela devient problématique, il faudra en passer par des triggers, lesquels ne sont pas faits par définition pour garantir le respect des règles mais pour déclencher des processus quand se produisent certains événements. Si l’on considère à nouveau la contrainte suivante :

"Le montant total des factures non réglées par un client ne peut pas dépasser le crédit autorisé pour ce client".

Il s’agit bien d’une contrainte et non pas d’une règle de production. En passant, cette contrainte est relativement simple à exprimer en Tutorial D :

With Quantité_Commandée * Montant_Unitaire As Montant_Ligne,
_____Sum (Montant_Ligne) As Montant_Commande,
_____Sum (Montant_Commande Where Not Réglé) As A_Régler :
_____A_Régler =< Seuil_Crédit ;

(Disons que Quantité_Commandée et Montant_Unitaire sont des colonnes de la table Ligne de Commande, Réglé une colonne (de type booléen) de la table Commande et Seuil_Crédit une colonne de la table Client).

Je n’ai pas le courage de traduire cette contrainte au sein d’un trigger car interviennent un certain nombre de paramètres étrangers la règle, tels que la nature des instructions impliquées (Insert, Update, Delete), le moment où le trigger agit (Before, After), etc. toutes choses étrangères aux contraintes à vérifier et qui compliquent tout.

Le but n’est pas de faire un cours sur Tutorial D, mais plutôt de montrer qu’il est possible d’exprimer en quelques lignes les règles de gestion. Maintenant, pour en revenir aux SGBD tels que SQL Server, on est obligé aujourd’hui d’en passer par ce qu’on a sous la main pour arriver tant bien que mal à ses fins :

_ La clause CHECK pour certaines règles simples, ne mettant en jeu qu’une seule ligne d’une table (exemple : la date de début d’un projet doit être antérieure à sa date de fin).

_ Les triggers quand les contraintes ne peuvent pas être garanties par la clause CHECK.

_ Les vues à l’occasion (Create View... With Check Option).

_ Les facilités du SGBD que l’on utilise, avec le risque de s’en rendre prisonnier, si les autres SGBD ne les proposent pas.

En conclusion.

Vous avez posé une question de fond. Je vous suggère la lecture d’un petit ouvrage (130 pages) qui permet d’aborder un sujet délicat, le vôtre, de manière très claire et didactique :

“What Not How, The Business Rules Approach to Application Development” par C. J. Date, chez Addison- Wesley.

Ensuite, si vous êtes pugnace, vous pourrez aborder l’étude de Tutorial D, en commençant par la référence incontournable et incontestable, toujours par C. J. Date :

An Introduction to Database Systems, 8th edition. (Pearson: Addison-Wesley (International Edition), 2004).

Vous consulterez avec profit le site http://www.thethirdmanifesto.com/

Le but n’est pas ici de faire du D pour le plaisir de faire du D (quoique...) mais bien d’aller plus loin dans la réflexion du sujet qui vous préoccupe.

Pour reprendre votre message, à la question :

"Quelle réflexion faut-il privilégier dans la l'étude d'un SI (PME) concernant le cadre SGBD ?"

Je répondrai qu’il faut aborder le problème à la façon de Sir Edmund Hillary quand celui-ci a envisagé l’ascension de l’Everest : il a longuement étudié son sujet et s’est entraîné, il ne s’est pas lancé chaussé de simples baskets. Prenez le temps d’étudier “What Not How” et mesurez SQL Server (ou autre !) à l’aune de cet ouvrage, modeste par la taille mais très riche par son contenu et source d’inspiration.

A la question :

"Je souhaiterais savoir si le fait de concentrer l'ensemble des règles métiers (Via SQL, triggers, ...) sur une base de données d'un SI est un facteur générateur de problèmes pour le SGBD."

Je répondrai : aucun problème pour le SGBD, par contre lui-même ne vous facilite pas la vie, c’est un peu le parcours du combattant car son offre est incomplète. Il pourrait faire beaucoup mieux. Mais, envisagez d’y aller. Écrivez vos règles dans langage formel à la façon de D, ça ne sera pas en vain, cela vous permettra au moins de débusquer d’éventuelles anomalies et ambiguïtés indiscernables quand les règles sont écrites en français. Certaines de ces règles sont peut-être trop complexes en regard des possibilités offertes aujourd’hui pour votre SGBD (demain ça ne sera peut-être plus le cas) : au besoin développez en procédural, mais le moins possible.

A la question

"Cette technique permet de centraliser les règles métiers en 1 seul point et donc une meilleur admin du SI et des évolutions. Mais quel est l'impact que l'on peut attendre de cette technique (perte de perf ou pratique à privilégier) ????"

Je reprendrai ce que je viens d’écrire :

Meilleure administration et pratique à privilégier : Il n’y a aucun doute à ce sujet. Quant aux performances, je ne vois pas en quoi elles seraient dégradées : il est plus facile de procéder à un tuning efficace et rapide d’une requête de type SQL (moins de 10 lignes) que d’un programme d’application figé, comportant deux ou trois cent lignes de code à vérifier.

N’oubliez quand même pas de prendre des garanties, prototypez afin de vérifier que d'un bout à l'autre de la chaîne (c'est-à-dire jusqu'au poste client) les choses se passent de manière correcte et efficace.

Souvenez-vous de Sir Edmund Hillary à qui l’on posait la question : "Pourquoi avez-vous gravi l’Everest ?" Réponse : "Parce qu’il était là". Il était préparé et il n’a pas reculé.

[Fabien Celaia]

Fsmrel, ça, c'est que l'on appelle une réponse CCP : claire, complète et pertinente

Le jour ou l'on généralisera ce genre de réponse, on pourra virer les modérateurs des sites... et replacer les forums par des Faq !

Encore merci d'avoir pris le temps de répondre de la sorte.

Ce vaste débat refait surface avec les environnements 3 tiers où l'on considère à tord le SGBDR comme un simple réceptacle de données et où toutes les règles devraient se trouver dans le 2e tiers.

A cette "évolution", je vois 2 causes majeures :

1. les règles métiers complexes sont souvent difficilement gérables via triggers (attention aux perfs) ou contraintes, compte tenu de la faiblesse du SQL en tant que languigage de programmation, d'où l'introduction de Java, CLR et autres PL-SQL dans les SGBDR)
2. les éditeurs de 2e tiers tentent de nous faire croire que le développement C/S est un développement trop "propriétaire" ou vous vous alliénez à l'éditeur de SGBDR. L'indépendance à la base de donnée revient alors à la dépendance du 2e tiers.

Cela pose un réel problème si vous n'êtes pas en mesure d'assurer que 100% de vos demandes passeront par le 2e tiers. Dans le cas d'un accès direct client-serveur, vos données se retrouveraient alors démunies, désarmées, nues comme un vers, prêtes à subir les pires outrages de la moindre violation de règle...


Je suis quant à moi pour la solution mixte (c'est bien Suisse, ça !) : les règles complexes via le 2e tiers, et l'intégrité "de base" dans ... la base, préservant au moins ce qui peut l'être...

[Franck_P]

Merci a tous pour vos réponses.

Je me suis fais une idée plus precise des différents aspects du probleme. Les implémentations natives des SGBD sont capable de prendre en charge certaines choses et pas d'autres. L'avantage est la centralisation des regles pour peu que les données ne soient pas dispersées sur plusieurs BD...

Merci

Franck

[SQLpro]

J'ai sursauté à la lecture du long laïus de fsmrel ...

notamment la phrase suivante :

Ainsi, d’une manière générale, certaines contraintes sont des contraintes de type, préexistant par définition aux tables dont les colonnes y feront référence

... qui avec le texte qui suit semble indiquer que les contraintes dans SQL c'est pas bien car elle sont attachées à la table.
C'est oublier cepandant qu'un SGBDR n'est pas fait pour faire de l'IHM et que la notion de qualification de données est intimement affecté à son usage, donc à la table !

Et je voudrais rectifier quelques éléments...

1) certains SGBDR implémentent parfaitement les DOMAINEs SQL et contraintes associées.

2) ce n'est pas parce que SQL Server à prévu de supprimer les rules et defaults qu'il n'y aura pas dans l'avenir quelque chose de similaire

Mais avec le standard SQL:1999 et les SGBD qui s’en réclament, si vous pouvez définir des types, vous n’avez pas la possibilité d’y intégrer des contraintes

3) c'est effectivement dans ce sens que va la norme SQL (désolé SQL c'est une norme et pas un standard). En particulier Jim Melton le rapporteur de la norme nous dit dans son bouquin en 2 tomes sur SQL:1999 que le DOMAIN sera probablement considéré comme déprécié.

... lesquels [triggers] ne sont pas faits par définition pour garantir le respect des règles mais pour déclencher des processus quand se produisent certains événements.

4) et si ! C'est justement parce que les éditeurs trouvait trop complexe et peu performant d'implémenter les ASSERTION qu'ils ont décidé de mettre en oeuvre les biens plus fin déclencheurs.

Je n’ai pas le courage de traduire cette contrainte au sein d’un trigger car interviennent un certain nombre de paramètres étrangers la règle, tels que la nature des instructions impliquées (Insert, Update, Delete), le moment où le trigger agit (Before, After), etc. toutes choses étrangères aux contraintes à vérifier et qui compliquent tout.

5) Dommage car c'est justement la finesse des triggers qui permettent à la fois l'élégance du code et la performance.

La clause CHECK pour certaines règles simples, ne mettant en jeu qu’une seule ligne d’une table

6) SQL n'a pas prévu de limiter la contrainte check à la ligne. Il accepte tout : la validation ligne à ligne, ligne à table (par exemple avec un calcul d'agrégat), ligne à base (par exemple en faisant une jointure avec une autre table). mais peu d'éditeurs l'ont implémenté en ce sens.

ENFIN

Sur le sens général de l'article et son fond, je vous approuve entièrement. Mais même si Date, Darwen et Fabian (ne l'oublions pas non plus celui là car il commence à contredire le défunt Date...) posent aujourd'hui les pierres des futurs SGBDR, le sol est mouvant et la distance est longue entre la théorie et la pratique...
Reste que l'extraction des règles métiers est encore et toujours un travail d'analyste et non celui d'une méthode ou d'un algorithme, lequel (méthode ou algoritme) n'est là au final que pour permettre une expression finale plus parlante à l'image des notations graphiques des modèles relationnels.

NOTA : une norme est INDEPENDANTE des éditeurs parce que élaboré par un organisme qui n'est pas financé par l'industrie, tandis qu'un standard émane d'organisme financés directement par les industriel, ce qui nous à par exemple donnée les fameux standards de TV couleur PAL, SECAM et NTSC...
En l'occurence la norme SQL est élaborée par l'ANSI (l'équivalent de l'AFNOR, donc un organisme d'état) et aujourd'hui par l'ISO, un organisme international...

A +

[fsmrel]

Bonjour à tous et bonne année 2007,

Pour tout ce qui suit, je vous renvoie à l'ouvrage de référence de Chris Date (dont SQLpro m’apprend le décès : j’enverrai quand même mes vœux à Chris...) :

C.J. Date. An Introduction to Database Systems, 8th edition. (Pearson: Addison-Wesley (International Edition), 2004).

J'ai sursauté à la lecture du long laïus de fsmrel

Tant que vous ne sautez pas au plafond...
Vous pouvez faire l’économie de l’adjectif "long", puisque par définition un laïus est long...
J’en profite pour en remettre une couche, car cela peut intéresser ceux qui ont participé à cette discussion ou qui l’ont suivie (Scripta manent, verba volant...)

... qui avec le texte qui suit semble indiquer que les contraintes dans SQL c'est pas bien car elle sont attachées à la table.
C'est oublier cepandant qu'un SGBDR n'est pas fait pour faire de l'IHM et que la notion de qualification de données est intimement affecté à son usage, donc à la table !

Ainsi, d’une manière générale, certaines contraintes sont des contraintes de type, préexistant par définition aux tables dont les colonnes y feront référence.

Avec LE Modèle relationnel, outre les contraintes de type (facultatives), il est bien sûr tout à fait légitime et légal de définir des contraintes table par table, contraintes qui viennent au besoin compléter les premières. Les contraintes de table sont un peu en quelque sorte ce que la confection sur mesure est au prêt-à-porter.

En plus de définir des types (dont la finalité première est d’assurer un typage fort lors des opérations sur les données), leur adjoindre des contraintes permet de mieux préciser l’ensemble de leurs valeurs et d’exprimer ainsi certaines règles de gestion de données de l'entreprise, s’appliquant à un nombre quelconque de tables plutôt qu’à l’une d’entre elles en particulier. Considérons par exemple la règle : "Concernant les référentiels Fournisseurs et Articles, les dates ne doivent pas être antérieures au 1er janvier 2000" (date de naissance de l’entreprise). Si l’on a en conséquence cent colonnes de type date concernées, éparpillées dans plusieurs tables dans la base de données, il préférable de définir une seule fois la contrainte au moyen d’un type approprié, plutôt que cent fois sur le métier remettre le même ouvrage. (En passant, toutes les dates dans la base de données ne sont pas nécessairement concernées : les employés de l’entreprise auront toujours le droit d’être nés au XXe siècle, dans une fourchette de dates pertinentes.)

Supposons maintenant que l'on définisse un type T et qu'on le dote d'une contrainte TC. Si l'on a besoin d’une contrainte plus restrictive au niveau d'une colonne donnée d'une table donnée, alors que cette colonne est du type T, rien ne s'y oppose (Par exemple "La date d’embauche d’un employé ne doit pas être antérieure au 5 janvier 2000"). Pour chaque colonne de type T, on peut définir des contraintes de table supplémentaires comme l'on veut. Simplement, ces contraintes ne peuvent pas enfreindre la contrainte TC, ce qui est la moindre des choses.

Au regard de ce qui précède, nous ne sortons pas du strict Modèle relationnel de données, défini par Codd et entretenu par Date et Darwen et je ne vois pas ce que vient faire l'IHM dans cette affaire. Je ne vois pas non plus ce que vous entendez par qualification des données, mais ce que je sais, c'est que chaque colonne de chaque table est typée, que le type mentionné par la colonne soit fourni par le système (CHAR, INTEGER, etc.) ou par l’utilisateur (T).

certains SGBDR implémentent parfaitement les DOMAINEs SQL et contraintes associées.

Certes, mais le Standard SQL (terme employé aussi bien par Chris Date que Peter Gulutzan —cela dit, je veux bien parler de norme, ce qui en l’occurrence me chaud, je l’avoue...) traite de domaines qui ne sont qu’une version très limitée des types. En effet, à partir d’un domaine SQL, on ne peut pas définir un domaine arbitrairement complexe, ce qui est pour le moins frustrant et surtout, on est privé du typage fort et de l’héritage : le domaine est limité à un type système de référence (si j’ai bien perçu l’objet de ce qu’est le domaine selon SQL).

et si ! C'est justement parce que les éditeurs trouvait trop complexe et peu performant d'implémenter les ASSERTION qu'ils ont décidé de mettre en oeuvre les biens plus fin déclencheurs.

... lesquels [triggers] ne sont pas faits par définition pour garantir le respect des règles mais pour déclencher des processus quand se produisent certains événements.

Et non. "Trigger" se traduit par "gâchette" ou "déclencheur", sous-entendu d’un certain traitement (ou action), en fonction d’un certain type d’opération. Je cite le professeur Georges Gardarin : "Déclencheur (trigger) : Mécanisme permettant d’activer une procédure cataloguée lors de l’apparition de conditions particulières dans la base de données" (Bases de Données objet et relationnel. Éditions Eyrolles, 1999 - Notion II.24).

Par exemple, dans le cadre de l’intégrité référentielle, quand une clé étrangère de la table Compte fait référence à une clé candidate de la table Client, la règle ou contrainte se résume seulement à ce qui suit et relève plus de la logique des prédicats que d’autre chose : "Tout compte est associé à un client", indépendamment de toute action du genre trigger. Dans un 2e temps seulement, en réponse à un certain type d’événement, à cette contrainte on peut (on doit) se préoccuper d’associer une action à déclencher suite à un certain type d’opération (triggered action), du genre "Si on supprime un client, alors ses comptes doivent être supprimés" (On Delete Cascade). Certes, SQL permet de façon ramassée d’exprimer d’une part une contrainte de type prédicatif (aspect statique) et d’autre part une réaction à un type d’événement (aspect dynamique), il n’en demeure pas moins qu’il faut faire la distinction, sans amalgame. Dans un dossier de conception détaillé et pour mentionner Merise, une règle relève du MCD tandis que le traitement provoqué relève du MCT.

Prenons encore le cas d’une règle de gestion de l’entreprise, du genre "Le total des salaires pour un département de l’entreprise ne doit pas dépasser la moitié du budget de ce département". Y voyez-vous figurer l’équivalent des termes INSERT, UPDATE, DELETE ? BEFORE, AFTER ? Par exemple : "Avant (ou après) ajout d’un employé dans la table des employés, ou bien avant(ou après) modification du salaire d’un employé, ou avant (ou après) son changement de département, ou avant modification ou après création d’ un budget, etc., s’assurer que le total des salaires ne dépasse pas la moitié du budget de ce département... " ? Que nenni. Le contenu d’une instruction du genre ASSERTION (sans clause DEFERRABLE), qui n’est que la traduction en langue formelle de la règle de gestion, fait que cette instruction n’exprimant que le quoi et rien du comment est clairement ce qui suffit pour prendre en compte la règle de gestion au niveau du SGBD. En plus, ne pensez-vous pas que celui qui n’est pas un champion du trigger puisse laisser passer des bugs quand il code un déclencheur ? (quid, si le salaire d’un employé n’est pas modifié, mais que ce dernier change simplement de département : quelqu’un d’averti comme vous ne laissera rien passer, mais quelqu’un de moins expérimenté ?)

Maintenant, si en conséquence d’une règle de gestion, une action est à déclencher, rien ne s’oppose à la mise en œuvre d’un trigger ad-hoc, mais chaque chose à sa place et en son temps. Pourquoi mélanger la partie statique et la partie dynamique, au risque de tout compliquer ?

Par ailleurs, les éditeurs ont bien tort d'affaiblir un système au nom de la performance et/ou de la difficulté de la mise en œuvre de l’instruction Create Assertion. Dans ce sens, IBM n’a, par exemple, proposé l’intégrité référentielle pour DB2 qu’en 1988, parce que les utilisateurs ne cessaient de la réclamer avec insistance (ce qui n’a pas empêché nombre d’entre eux d’éviter finalement de s’en servir, car la jugeant a priori peu performante...) Le temps a passé et aujourd’hui cela fait sourire bien des DBA DB2. Devrons-nous attendre les ordinateurs quantiques pour disposer de l’instruction Create Assertion ?

C’est à l’utilisateur de choisir d’utiliser ou non des assertions et de préférer les remplacer par des triggers s’il en a envie. Pour ma part, quand IBM a fourni la jointure externe (pour DB2), je ne l’ai pas utilisée et j’ai choisi de continuer à jouer de l’UNION en relation avec une jointure naturelle et un NOT EXISTS. En effet, le moteur passait systématiquement à côté des index et une requête qui aurait dû durer 2 minutes se traînait pendant des heures. Mon choix ne portait pas évidemment sur les concepts mais était dicté par la nécessité d’avoir des temps de réponse corrects. Libre à moi de revoir ma façon de procéder du jour où cette jointure externe est devenue performante, une fois le défaut corrigé.

Encore une anecdote. Du temps où Ted Codd insistait pour que l’on mît en œuvre l’intégrité référentielle, il précisait que l’action à déclencher (referential (triggered) action) en cas de modification de clé primaire fût le plus souvent ON UPDATE CASCADE. Par la suite, quand IBM tint son grand show en juin 1988 à la tour Descartes à La Défense, pour présenter la V2 de DB2 qui enfin permettait notamment la mise en œuvre de l’intégrité référentielle, l’orateur de service précisa qu’il n’y avait pas de choix : c’était exclusivement ON UPDATE RESTRICT. Je l’avais interpellé pour lui en demander la raison. Réponse : "Parce que les théoriciens l’ont dit !" Fermez le ban ! J’ai préféré ne pas insister. J’ai quand même découvert le pot aux roses dans le document d’IBM GG24-3312-0, consacré à l’intégrité référentielle et cela relevait de l’incantation : "The reason for this restriction is philosophical". Parfaitement, DB2 s’était pris pour Platon. Suite à quoi, il était expliqué dans le document en question comment monter une usine à gaz pour modifier une clé primaire. Encore une fois, ça n’est pas à l’éditeur du SGBD de prendre des initiatives de ce genre : choisir ON UPDATE CASCADE ou RESTRICT est de la responsabilité du concepteur et/ou du DBA et non pas de l’éditeur qui craindrait pour la performance de son système.

Reste que l'extraction des règles métiers est encore et toujours un travail d'analyste et non celui d'une méthode ou d'un algorithme, lequel (méthode ou algoritme) n'est là au final que pour permettre une expression finale plus parlante à l'image des notations graphiques des modèles relationnels.

Je ne sais pas ce que vous entendez par extraction, mais je suis d’accord que l’expression des règles métiers est un travail du ressort de l’analyste qui les rédige en français (ou dans la langue qu’on lui impose). Maintenant lors de leur prise en compte au niveau du SGBD, parmi ces règles il en est qui relèvent du typage et des contraintes de type, puis d’autres qui s’appliquent à une ligne d'une table, ou bien à une table ou encore à un ensemble de tables et faisant l’objet de l’instruction CREATE ASSERTION (ou de l'instruction CONSTRAINT chez Date & Darwen). Il en va ainsi de la règle que j’ai prise en exemple ci-dessus : "Le total des salaires pour un département de l’entreprise ne doit pas dépasser la moitié du budget de ce département".

Par ailleurs, une règle rédigée en français ou autre est souvent ambiguë et il vaut mieux l’exprimer en 2 ou 3 lignes dans une langue formelle, à l'aide d'une contrainte, sans y rajouter du comment. Utiliser du code procédural n'est pas approprié, car souvent long à mettre au point et qui plus est délicat à maintenir (par ceux qui prennent le relais de ceux qui sont partis).

Qu’entendez-vous par notations graphiques des modèles relationnels ? Il n’y a qu’ UN modèle relationnel, proposé en 1969-1970 par Ted Codd, lequel sa vie durant n’a fait que le faire évoluer, mais sans jamais proposer la moindre notation graphique. Tout au plus a-t-il représenté quelques en-têtes de tables et quelques lignes de ces tables, afin d’illustrer ses propos, comme tout à chacun.


En résumé :

Dans tout ce qui précède, je ne cherche à convaincre personne, mais simplement rappeler ce qu’enseignent les héritiers de Ted Codd (The relational bigots) investis de la mission de faire évoluer le Modèle relationnel pour le bien de la communauté Bases de Données. Modèle relationnel sans lequel, il ne faut pas l’oublier, SQL n’existerait pas (et a fortiori sa norme). On en serait encore au système navigationnel de Charlie Bachman, Turing Award en 1973, le pauvre qui s’est fait mettre KO debout au 1er round par Ted Codd, lors d’une fameuse joute à Ann Arbor, l’année suivante....

une norme est INDEPENDANTE des éditeurs parce que élaboré par un organisme qui n'est pas financé par l'industrie, tandis qu'un standard émane d'organisme financés directement par les industriel, ce qui nous à par exemple donnée les fameux standards de TV couleur PAL, SECAM et NTSC...
En l'occurence la norme SQL est élaborée par l'ANSI (l'équivalent de l'AFNOR, donc un organisme d'état) et aujourd'hui par l'ISO, un organisme international...

Je vous l’accorde volontiers. Maintenant, Jim Melton que vous avez mentionné comme étant le rapporteur de la norme, émarge quand même chez Oracle. Hugh Darwen a pour sa part représenté IBM (de 1988 à 2004) au comité ISO SQL.

Chris Date parle du standard SQL plutôt que de la norme SQL : je ne chercherai personnellement pas à être plus royaliste que le roi. Ce genre de distinguo ne m’excite pas particulièrement.


Pour finir, je cite Date & Darwen qui en connaissent un rayon sur le sujet :

... the design and implementation of established products might have an adverse on the feasibility and cost-effectiveness of proposed SQL extensions.

... an SQL standardizer whose participation is funded by an employer say, might sometimes feel obliged to place the commercial interests of that employer above his or her own personal opinions, should there be any conflict.

… an SQL standardizer has to make compromises within a large group of people with perhaps widely differing opinions and interests. By contrasts, coauthors with closely shared opinions and interests have to make hardly any compromises at all, especially on matters considered by both to be very important.

Référence : C.J. Date, Hugh Darwen. Databases, Types, and the Relational Model, The Third Manifesto, Third Edition (Pearson Addison-Wesley Longman, 2006).

[SQLpro]

1) "me chaud" du verbe chaloir s'écrit chaut.

2) standard en anglais se traduit par NORME en français (faux amis)

3) Gardarin dit bien des énormités dans ses bouquins. En particulier sur le trigger, vous dites qu'il affirme :

Mécanisme permettant d’activer une procédure cataloguée lors de l’apparition de conditions particulières dans la base de données

Or il n'y a aucune condition particulière de déclenchement des triggers par définition autre que INSERT ou UPDATE ou SELECT.

J'ai pas le temps de développer plus en avant, mais je le ferais à tête reposée !

A +

[fsmrel]

Bonjour,

1) "me chaud" du verbe chaloir s'écrit chaut

Exact. Il m’arrive de garder une paille orthographique dans l’œil.

2) standard en anglais se traduit par NORME en français (faux amis)

Merci du tuyau. Et alerter Google qui fait lui aussi la mauvaise traduction. Pour mon information et pour être complet, n’existe-t-il qu’un seul terme anglais pour les deux termes français "standard" et "norme" ?

3) Gardarin dit bien des énormités dans ses bouquins.

Je vous laisse juge pour tout ce qui sort du cadre des fondations du modèle relationnel. Sinon, en ce qui concerne ce dernier, Georges Gardarin est irréprochable et très clair (Cf. "G. Gardarin. Bases de données. Les systèmes et leurs langages. Eyrolles, 1988" : état de l’art d’il y a pratiquement 20 ans, mais qui reste une excellente référence). Pour mémoire, les triggers ne font pas partie de ces fondations, même si D & D reconnaissent qu’il s’agit d’une fonctionnalité importante des SGBD commercialisés et du Askew Wall.

il n'y a aucune condition particulière de déclenchement des triggers par définition autre que INSERT ou UPDATE ou SELECT.

Et peut-être DELETE ? (Je suis désolé, ça m’a échappé...)

[SQLpro]

fsmrel :

Qu’entendez-vous par notations graphiques des modèles relationnels ? Il n’y a qu’ UN modèle relationnel, proposé en 1969-1970 par Ted Codd, lequel sa vie durant n’a fait que le faire évoluer, mais sans jamais proposer la moindre notation graphique.

Les notations introduites par CHEN, puis TARDIEU, ect, comme E/R, MERISE, UML2, IDEF1X...

fsmrel :

Maintenant, Jim Melton que vous avez mentionné comme étant le rapporteur de la norme, émarge quand même chez Oracle.

C'est là toute l'ambiguité puisque Oracle est très en retard sur les aspects normatif. De toutes façon ce n'est pas Jim qui "fait" la norme, mais un commité composé de nombreuses personnes dont les intérêt sont à cheval entre théorie et industrie...

Enfin, en ce qui concerne les CONTRAINTES, je viens de poster un exemple intéressant que je reproduit ici pour information...

Dernière petite chose, on me demande souvent si les contraintes (par exemple intégrité référentielle) c'est pas contre performant... Oui cela demande du traitement supplémentaire lors des INSERT / UPDATE. MAIS... les meilleurs moteurs des SGBD relationnels savent en tirer un parti très puissant qui permet d'accélérer notablement les traitements. Et je vais vous donner un exemple spectaculaire...
Soit la requête suivante :

Code :

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

1
2
3
4
5
SELECT ...
FROM   T_CLIENT C
       FULL OUTER JOIN T_FACTURE F
             ON C.CLI_ID = F.CLI_ID
WHERE  F.CLI_ID = 53

Avec 1 000 clients, 50 000 factures
Imaginons que le client 53 n'existe pas (ni client ni facture). S'il n'y a pas d'intégrité référentielle il faudra faire une recherche du client dans les factures puis une recherche des clients dans les clients et joindre tout cela => 51 000 lignes lues si pas d'index.
Maintenant que va faire le moteur s'il y a une intégrité référentielle sur CLI_ID entre les deux tables et que le moteur SQL est bien pensé ?
Il ira juste voir D'ABORD dans les clients et s'il ne trouve pas il s'arrête immédiatement puisqu'il sait que grâce à la contrainte d'intégrité référentielle il n'est pas possible que cette référence de client soit présente dans la table des factures => 1 000 lignes lues si pas d'index

A votre avis faut-il ou pas mettre des intégrité référentielles si vous voulez obtenir des performances ???
Il en est de même généralement avec toutes les autres contraintes. Par exemple, mettre une contrainte CHECK value >= 0 sur des colonnes prix, quantité, dimensions... fera que si jamais vous faites une requête du style :

Code :

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

... WHERE PRIX < 0

Alors la réponse sera instantanée car il n'y aura même pas besoin de lire les données pour retourner un résultat vide !

A +