SI & SGBD : comment/où gérer les règles métier ?
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
Une petite couche supplémentaire
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).
Citation:
Envoyé par SQLpro
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...)
Citation:
Envoyé par SQLpro
... 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 !
Citation:
Envoyé par fsmrel
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).
Citation:
Envoyé par SQLpro
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).
Citation:
Envoyé par SQLpro
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.
Citation:
Envoyé par fsmrel
... 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.
Citation:
Envoyé par SQLpro
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....
Citation:
Envoyé par SQLpro
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 :
Citation:
Envoyé par Le binôme Date & Darwen
... 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).