Discussion :

[Kropernic]

Ouais, c'est pas faux.

C'est la faute à fmsrel ! *siffle*

J'ai vu "période" dans son mcd et vu qu'il avait expliqué qu'une période avait une date de début et une date de fin...

(au cas où, c'est pour rire hein ! j'avais qu'à réfléchir plus loin que le bout de mon nez)

[fsmrel]

Encore une question pour fsmrel et sa sulfateuse à NULL ^^

Du temps de ma folle jeunesse, je réglais les problèmes à coups de canon de 90 mm si ma RIA de 50 ne suffisait pas (je fus chef de char...)

j'imagine que rien n'empêche d'ajouter une entité type nommée entrepot_stock qui serait du même acabit que centrale_stock et store_stock avec une contrainte d'exclusion mutuelle entre les trois liaisons qui partent de gift vers les stocks. (au passage, comment vous notez cette contrainte sur un mcd ? comment se concrétise-t-elle en DB ? (un trigger à l'insert qui vérifie qu'on peut mettre le gift dans le stock demandé ?))

Je n’ai pas encore examiné les conséquences de l’arrivée de l’entrepôt. Cela dit, d’un point de vue strictement théorique, en ce qui concerne l’exclusion, la norme énonce :

Je fais référence au document « Journée afcet, 15 novembre 1990 » où sont normalisées les représentations des contraintes dans les MCD.

Je pense que l’on peut représenter les choses ainsi en ce qui concerne la centrale, l’entrepôt et les magasins, où GIFT joue le rôle de pivot (à vérifier) :



Le gift G1 ne peut pas participer à plus d’une des associations R1, R2, R3.

Maintenant, au niveau SQL, on doit développer ex nihilo une assertion, ou des triggers si le SGBD (je repose la question : quel est le vôtre ?) ne propose pas l'instruction CREATE ASSERTION.

Je replonge dans vos problèmes, ma RIA de 50 à la main (en passant, j'entends que CinePhil commence à canarder ).

[fsmrel]

Suis-je trop maniaque (peut-on autoriser ce NULL-là ?) ?

On n’autorise rien !

Du point de vue théorique, on considère ce qui est en cours d’une part et ce qui est passé d’autre part (aspect historique des choses). Chris Date traite en long et en large du SINCE / DURING (DEPUIS / DURANT). J’ai effleuré le sujet avec la 6NF, mais je ne voudrais pas vous traumatiser avec ça et on va être pragmatiques, d’autant qu’on n’a pas ici les opérateurs qui vont bien. On va donc isoler l’attribut DATE_OUT (que de mon côté j’ai renommé en DateSortie, mais utilisez les noms dont vous avez l’habitude, l’essentiel est qu’on se comprenne) :



On sait que le MLD produit comporte des cycles, car PowerAMC n’a pas compris (au moins avec la V11) que du fait de l’identification relative, CENTRALE_STOCK_SORTIE n’est qu’une propriété (monovaluée) de CENTRALE_STOCK, en vertu de quoi il n'a pas à générer de cycles dans le MLD. Tout comme il n’a pas à exiger un identifiant pour CENTRALE_STOCK_SORTIE puisque justement l'identifiant est relatif, et donc qu’il générera une clé primaire au niveau MLD. C’est quand même un peu agaçant...

Pour ne pas devoir bricoler le MLD, j’utilise la notation E/R et le rôle dominant comme je l’ai déjà expliqué. Mais comme vous préférez rester en Merise pur (sinon CinePhil frappe ! Espérons toutefois que, lorsqu'il rentre un peu trop tard à la maison, madame nous venge... ), on va en passer par le subterfuge du feignant dont j’ai déjà fait mention, en disant que : soit un gift est dans le stock de la centrale (même principe pour les autres stocks), soit il en est sorti :



Le MLD obtenu est le suivant :



Où l'on notera au passage que la paire {GiftId, DateSortie} est clé alternative pour la table CENTRALE_STOCK_SORTIE (idem pour ses homologues).

A signaler qu’AMC a oublié là aussi que le type d’entité CENTRALE_STOCK_SORTIE hérite de l’identifiant de CENTRALE_STOCK :



Donc, quand on se prend ça dans les dents au moment où l'on demande la génération du MLD :



Alors on décoche la case « Existence d’attribut d’entité » :



Plus généralement, quand AMC a des faiblesses et nous injure à tort, il suffit en général de décocher la case qui va bien.

[fsmrel]

je ne suis toujours pas sûr des cardinalités pour l'association COMMANDER qui a lieu entre GIFT_GFT - FOURNISSEUR_FRN - COMMANDE_CMD.

On va essayer de vous administrer une potion façon Volfoni, Naudin et compagnie. Votre association COMMANDER est une ternaire dont chaque patte porte une cardinalité maximum N. Les choses se lisent donc littéralement ainsi :

Un fournisseur peut participer plus d’une fois à l’association, pour une ou plusieurs commandes et un ou plusieurs gifts.

Une commande peut participer plus d’une fois à l’association, en relation avec un ou plusieurs fournisseurs, pour un ou plusieurs gifts.

Un gift peut participer plus d’une fois à l’association, en relation avec un ou plusieurs fournisseurs, pour une ou plusieurs commandes.

Descendons dans la soute. Au niveau logique, l’en-tête de la table COMMANDER est le suivant (elle n’est pas porteuse d’attributs) :

COMMANDER {GftId, CmdId, FrnId}

Elle a pour clé :

K = {GftId, CmdId, FrnId}

Les instances qui suivent sont donc légales :

Code :

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

1
2
3
4
5
6
7
8
9
GftId    CmdId    FrnId
-----    -----    -----
G1       C1       F1
G1       C1       F2
G1       C2       F1
G1       C2       F3
G2       C1       F1
G2       C1       F4
...

Manifestement c’est le bôdel !


Je n’ai pas fouillé dans la discussion pour voir ce qu'il en est exactement mais, dans le cadre cet exercice sur les associations ternaires, admettons qu’un gift puisse se retrouver dans plus d’une commande.

Comme dit CinePhil avec bon sens, je le cite :

« Moi j'ai de gros doutes, a priori et sans avoir relu les messages précédents, qu'un gift puisse être commandé plusieurs fois à un fournisseur ! »

Pour des raisons de complétude, j’ajouterai explicitement — ce que sous-entend CinePhil — que je serais étonné qu’une commande puisse aussi avoir été passée auprès de plus d’un fournisseur.

Dans ces conditions, la présence simultanée des paires <G1, F1> et <G1, F2> n'est plus possible, ainsi que celle des paires <C1, F1> et <C1, F2>.

Vous nous direz si l’approche formelle et mécanique, qui suit nous permet d’enfoncer un clou...

Allons-y. Du point de vue de la théorie des dépendances, les doutes manifestés peuvent être traduits sous forme de dépendances fonctionnelles :

DF1 : {GftId} -> {FrnId} (traduisant le doute cinephilien),
DF2 : {CmdId} -> {FrnId} (traduisant le doute complémentaire fsmrelien).

Et la forme normale de Boyce-Codd (BCNF) est violée, car les déterminants {GftId} et {CmdId} de ces dépendances fonctionnelles ne sont pas clés candidates de la table COMMANDER (la seule clé étant K = {GftId, CmdId, FrnId}).

On se sert alors du théorème de Heath pour normaliser COMMANDER, qui est décomposable en deux tables.

Version cinephilienne :

T1 {GftId, FrnId}, de clé {GftId},
T2 {GftId, CmdId}, de clé {GftId, CmdId}.

Version fsmrelienne :

T1 {CmdId, FrnId}, de clé {CmdId},
T2 {GftId, CmdId}, de clé {GftId, CmdId}.

Autrement dit, l’approche synthétique (disons platonicienne) utilisée par CinePhil a donné lieu à la solution :

Gift -0,n----concerner----1,n- Commande -1,1----passer----0,n- Fournisseur

Solution que l’on retrouve par l’approche analytique (disons aristotélicienne) en procédant à la rétro-conception de la version tabulaire cinephilienne. On dispose en plus d'une solution fsmrelienne, juste et rigolote, mais manifestement sans intérêt du point de vue conceptuel si on en fait la rétro-conception, puisqu'on perd le lien Commande - Fournisseur :

[Commande] -- 1,n --(composer) --0,n-- [Gift] -- 1,1 -- (vendre) -- 0,n -- [Fournisseur]

J’espère que le clou ne s’est pas tordu en cours de frappe...

[CinePhil]

On se sert alors du théorème de Heath pour normaliser COMMANDER, qui est décomposable en deux tables.

Version cinephilienne :

T1 {GftId, FrnId}, de clé {GftId},
T2 {GftId, CmdId}, de clé {GftId, CmdId}.

À l'instar de M. Jourdain, je ferais du Heath sans le savoir ? C'est chaud !

Quelle belle chose que de savoir quelque chose !

l’approche synthétique (disons platonicienne) utilisée par CinePhil

Zut ! Démasqué !

[fsmrel]

À l'instar de M. Jourdain, je ferais du Heath sans le savoir ? C'est chaud !

Et encore, ça pourrait être plus chaud si l'on tenait compte de la règle de Rissanen, voire brûlant avec l’algorithme de Bernstein de production de relations 3NF, avant de mourir d’amour pour les beaux yeux de la marquise...

je ne suis toujours pas sûr des cardinalités pour l'association COMMANDER qui a lieu entre GIFT_GFT - FOURNISSEUR_FRN - COMMANDE_CMD.

Dans mon message précédent, je me suis appuyé sur la règle : Un gift peut concerner plusieurs commandes, chacune passée à un seul fournisseur.

Mais quid si un gift ne peut figurer au plus que dans une seule commande ? En moins de temps qu’il n’en faut à Usain Bolt pour gagner une médaille d’or sur 100 mètres, CinePhil aura fournir le MCD qui va bien :

[Gift] --0,1----(Composer)----1,n-- [Commande] --1,1----(Passer)----0,n-- [Fournisseur]

Et en moins de temps qu’il n’en faut au susdit pour gagner une médaille supplémentaire sur 200 mètres, comme vous avez été bien chapitré par CinePhil, vous aurez ensuite procédé à la transformation qui suit :

[Gift]-- 0,1---- (Être)----(1,1)--[Gift commandé] --1,1----(Composer)----1,n-- [Commande]

Je précise à cette occasion que PowerAMC ne crée pas de table associative dans la configuration (0,1 — 0,n) et que le concepteur-feignant-qui-ne-veut-pas-bricoler-les-MLD modélisera ainsi dans le contexte de cet AGL (mais vous pouvez préférer l'autre modélisation, c'est vous qui voyez) :



A noter que la commande est ici datée.

Quelle que soit la modélisation que vous retiendrez, vous conviendrez que la ternaire COMMANDER a du plomb dans l’aile...

Je vous fais grâce de l’épreuve d’endurance que représente la production du modèle à partir de la ternaire en utilisant l’approche analytique car, outre la connaissance du théorème de Heath et de la règle de Rissanen, il faut être rodé à l’utilisation de l’algorithme du seau (encore un qui est dû à Bernstein), ne serait-ce que pour produire l’inventaire complet des clés candidates ; il faut aussi maîtriser la technique de production des ensembles irréductibles de dépendances fonctionnelles (couvertures minimales), maîtriser divers algorithmes de Bernstein, bon j’arrête là avant que vous ne partiez en courant...

[Kropernic]

Vous ne vous reposer jamais le week-end ? ^^

Quoi qu'il en soit, je m'en vais de ce pas modifier cette ternaire qui ne me plaisait guère.

J'imagine que la bonne manière de formuler les relations en français (pour bien les modéliser) viendra avec l'expérience.

C'est tellement rapide de dire qu'une commande concerne plusieurs gifts et un fournisseur.
C'est tellement plus précis de dire qu'une commande peut concerner plusieurs gifts et est passée chez un fournisseur.

Après cela, je pense qu'il ne me reste plus qu'à aller taper sur la table du service concerné (qui s'apparente le plus à la MOA dans mon cas) pour avoir des affirmations ou infirmations quant à certaines règles car jusqu'ici, c'était plutôt des conditionnelles (réponse typique à une de mes question : "oui, cela pourrait arriver").

Encore merci !

[CinePhil]

C'est tellement rapide de dire qu'une commande concerne plusieurs gifts et un fournisseur.

Même en formulant ainsi, on parle bien d'une commande (un nom, donc potentiellement une entité type) et non pas de commander (un verbe, donc potentiellement une association).

Le verbe est ici "concerne". Comme il a 2 compléments, on voit rapidement qu'il y a en fait deux associations "concerner" entre commande et gift d'une part, entre commande et fournisseur d'autre part.

Si tu relis mon billet sur les règles de gestion, j'y préconise de toujours employer des noms pour les entités et des verbes pour les associations, ce qui permet de lire un MCD comme un livre !

[Kropernic]

Tant que j'y pense et avant que je n'oublie de nouveau, mon SGDBR est SQL SERVER 2005 (édition standard).

(un upgrade vers 2008 est prévu)

[Kropernic]

De nouveau une question par rapport au bonhomme NULL.

Je ne l'ai encore jamais précisé jusqu'ici, car sans intérêt d'un point de vue sémantique, mais dans chaque table, j'ajoute systématiquement 4 colonnes.
A savoir :

Code :

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

1
2
3
4
PFX_CREATED_BY VARCHAR(100) NOT NULL DEFAULT SYSTEM_USER; 
PFX_CREATED_ON DATETIME NOT NULL DEFAULT GETDATE(); 
PFX_MODIFIED_BY VARCHAR(100) NULL; 
PFX_MODIFIED_ON DATETIME NULL.

Ces colonnes sont uniquement là de manière à tracer qui fait quoi.
Cela est-il à prendre en compte lors de la conception ?
Ces colonnes ne sont évidemment jamais interrogée par un applicatif.

[CinePhil]

Ben déjà, au lieu de stocker X milliers de fois le nom de l'utilisateur dans un VARCHAR(100), crée une table des utilisateurs et met une clé étrangère référençant son identifiant.

Ensuite, si ce ne sera jamais interrogé, pourquoi le stocker ?

Ceci dit, ta manière de faire est assez courante mais il y a d'autres solutions pour historiser les actions sur les données. Fais une recherche sur le forum, l'historisation a déjà été abordée.

Avec ton système, tu enregistres la création et la dernière modification mais pas les modifications intermédiaires. À toi de voir si c'est suffisant. Et si c'est suffisant, autant se demander s'il est important de conserver la création au bout de la 12ème modification !
Auquel cas tu pourrais te contenter de seulement deux colonnes qui seraient toujours renseignées :
- l'identifiant de l'utilisateur qui a agit en dernier (le créateur ou le dernier modificateur) ;
- la date de l'action.

Demande-toi aussi s'il faut vraiment faire ça pour toutes les tables. Ce qui semble important dans ton processus, c'est le cycle de vie des gifts et celui-ci semble pouvoir être intégralement reconstitué par le schéma existant, sans besoin d'y ajouter ces colonnes de mise à jour. Ce qu'il manque peut-être ici ou là, c'est l'identifiant de l'utilisateur qui fait chaque action sur les gifts.

À méditer... et à creuser avec la MOA.

Bon courage !

[Kropernic]

J'ai dit que ce ne serait jamais interrogé par un applicatif. Pas jamais interrogé du tout.

C'est une habitude qui a été prise ici que d'ajouter ces colonnes partout (au passage, j'ai oublié de préciser que "PFX" est a remplacé par le trigramme de la table).

Pour ce qui est d'une table des utilisateurs et de faire le lien, si un jour un utilisateur est supprimée de cette table, je fais quoi ?

On ne garde que la dernière modification car en général, quand quelqu'un à fait un bourde et que du coup, il y a un truc qui cloche, ça se remarque tout de suite. On a donc besoin uniquement du dernier modificateur (on pourrait argumenter l'avant-dernier aussi mais passons).

Sinon ma question était : Doit-on tenir compte de cela à l'étape de la modélisation alors qu'il s'agit d'informations purement techniques ?

Je vais aller faire une recherche sur historisation comme tu le suggères et voir ce qu'il en ressort.
EDIT : Malheureusement, une recherche sur historisation me donne des méthodes (des mcd's en fait) sur comment établir un historique. Or ce n'est pas ce que je désire ^^.

[CinePhil]

J'ai dit que ce ne serait jamais interrogé par un applicatif. Pas jamais interrogé du tout.

Dont acte !

C'est une habitude qui a été prise ici que d'ajouter ces colonnes partout

Ben se poser de temps en temps la question de l'utilité de la chose ne serait peut-être pas superflu !

Pour ce qui est d'une table des utilisateurs et de faire le lien, si un jour un utilisateur est supprimée de cette table, je fais quoi ?

Tu peux marquer que l'utilisateur est supprimé, via par exemple une colonne booléenne "usr_actif" et ainsi ne pas perdre le lien et comprendre que ces rogntudju de données pourries sont causées par le bashibouzouk qu'on a justement viré le mois dernier !

On ne garde que la dernière modification car en général, quand quelqu'un à fait un bourde et que du coup, il y a un truc qui cloche, ça se remarque tout de suite. On a donc besoin uniquement du dernier modificateur (on pourrait argumenter l'avant-dernier aussi mais passons).

Donc si seulement besoin du dernier, inutile de stocker le premier (créateur) et le dernier modificateur !
=> Et hop ! Déjà deux colonnes de moins par table !

Sinon ma question était : Doit-on tenir compte de cela à l'étape de la modélisation alors qu'il s'agit d'informations purement techniques ?

Oui, puisque ça fait partie du modèle de données.
Et, encore une fois, ça permet de se poser la question, dès la conception, de l'utilité de poser ces informations dans les bonnes entités et associations types. Pas forcément toutes !

Je vais aller faire une recherche sur historisation comme tu le suggères et voir ce qu'il en ressort.

Ce que tu vas trouver sera peut-être trop luxueux pour ton besoin car, quand on parle d'historisation des données, il s'agit généralement d'enregistrer toutes les valeurs successives prises par certaines données avec la date de leur modification et éventuellement l'utilisateur qui a modifié la donnée.

[Kropernic]

Je capitule !

C'est vrai que je n'ai pas besoin de ces colonnes partout.

La recherche sur historisation me donne des résultats trop luxueux en effet (bien trouvé le terme luxueux !).

Par contre, je persiste sur le créateur. Je connais mes users et je sens venir la tuile ^^.

Mais je vais tabler sur le fait que le créateur est le premier modificateur. Du coup, à la création, les champs qui tracent les modifs seront remplis aussi et adieu monsieur NULL. Par contre, cela va introduire une légère redondance (dans le cas où la ligne n'est pas modifiée).

P.S. : Au passage, cette idée des 4 champs supplémentaires avait été introduite lors d'une formation suivie par mon collègue et moi-même il y a un an (ou deux ? je n'ai jamais eu la notion du temps). C'est marrant mais plus j'en apprends sur les DB, plus y a des trucs que le formateur disait qui se font démonter (faudra penser à ne plus se former chez eux).

[fsmrel]

Vous ne vous reposer jamais le week-end ? ^^

Ne vous en faites pas, après avoir été actif pendant 45 ans, je me repose maintenant toute l’année, et puis j’ai ma guitare et mon PC pour me détendre quand j’en ai assez de siester !

Après cela, je pense qu'il ne me reste plus qu'à aller taper sur la table du service concerné (qui s'apparente le plus à la MOA dans mon cas) pour avoir des affirmations ou infirmations quant à certaines règles car jusqu'ici, c'était plutôt des conditionnelles (réponse typique à une de mes question : "oui, cela pourrait arriver").

Bien parlé. Comme je vous l’ai déjà dit, n’oubliez jamais : Scripta manent, verba volant, d'où la nécessité du coup de tampon de la direction sur les documents énumérant les règles de gestion. A défaut, en cas de dysfonctionnement fonctionnel, ça sera forcément la faute à Kropernic qui, dira la MOA en toute mauvaise foi , aura pris des initiatives mal-t-à-propos...

Tant que j'y pense et avant que je n'oublie de nouveau, mon SGBDR est SQL SERVER 2005.

Bon. Au moins vous pourrez traiter des hiérarchies et des nomenclatures sans problème, vous pourrez mettre à jour des vues (important, ça !), ces genres de choses aujourd’hui non réalisables avec MySQL...

De nouveau une question par rapport au bonhomme NULL.

Je ne l'ai encore jamais précisé jusqu'ici, car sans intérêt d'un point de vue sémantique, mais dans chaque table, j'ajoute systématiquement 4 colonnes.
A savoir :

Code :

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

1
2
3
4
PFX_CREATED_BY VARCHAR(100) NOT NULL DEFAULT SYSTEM_USER; 
PFX_CREATED_ON DATETIME NOT NULL DEFAULT GETDATE(); 
PFX_MODIFIED_BY VARCHAR(100) NULL; 
PFX_MODIFIED_ON DATETIME NULL.

Ces colonnes sont uniquement là de manière à tracer qui fait quoi.
Cela est-il à prendre en compte lors de la conception ?
Ces colonnes ne sont évidemment jamais interrogée par un applicatif.

Tracer l'activité est légitime, au point que Richard Snodgrass a théorisé et anticipé votre besoin, et les résultats de ses travaux allaient même être injectés dans la norme SQL ; mais heureusement pour nous, les veilleurs ont détecté des erreurs logiques sévères (horresco referens !), faisant que tout a été reporté aux calendes grecques...

Je vous renvoie notamment à la discussion dans laquelle j'évoque cela.

En tout cas, l’idée d’ajouter des colonnes directement dans les tables pour suivre les mises-à-jour n’est pas une bonne idée.

Il faut commencer par mettre en évidence que la notion de date recouvre deux choses bien distinctes :

• Ce que Date appelle valid time ou encore stated time, à l’usage de l’application (donc des utilisateurs), et qui correspond aux dates permettant de savoir par exemple qu’un gift est dans le stock de la centrale ou ailleurs ;

• Ce qu’il appelle d’autre part transaction time ou encore logged time, qui ne concerne pas l’application mais pour faire court, le DBA et la Production :

« Valid times are kept in the database, while transaction times are kept in the log. »

Si donc le log de SQL Server ne suffit pas pour répondre à votre besoin en ce qui concerne la table GIFT, il faudra que vous doubliez celle-ci d’une table GIFT_LOG dont l’en-tête comporte les colonnes PFX_CREATED_BY, PFX_CREATED etc. et que vous gérerez vous-même à coups de triggers dédiés, vues (exemple GIFT JOIN GIFT_LOG), procédures et autres facilités connues seulement du DBA et de la Production.

Je capitule !
P.S. : Au passage, cette idée des 4 champs supplémentaires avait été introduite lors d'une formation suivie par mon collègue et moi-même il y a un an (ou deux ? je n'ai jamais eu la notion du temps). C'est marrant mais plus j'en apprends sur les DB, plus y a des trucs que le formateur disait qui se font démonter

Faut pas pleurer ! mais se dire que si ça ne marche pas par la face Sud, c’est peut-être possible par une autre face.
Recensez les tables pour lesquelles vous estimez que les doubler par une table log est nécessaire et bâtissez un modèle dédié (par exemple au moyen d'une vue au sens PowerAMC).

[fsmrel]

En passant...

Il faudra que j’examine votre message #49 dans lequel vous remettez pas mal de choses à plat, mais j’irai d’abord acheter de l’aspirine...


Votre MCD du 14/09/2012 (message #41) appelle quelques commentaires quant à la forme. Notamment, l’emploi du verbe « Être » ne convient quand vous mettez en relation GIFT et ENTREPOT_STOCK :

[GIFT] ---- 0,N ----(ETRE) ---- (1,1) ----[CENTRALE_STOCK]

En effet on pourrait interpréter cela comme : un gift est un stock. Soyez plus précis, en remplaçant ÊTRE par ÊTRE DANS, ou en utilisant un verbe du genre LOCALISER. Même principe pour les autres associations nommées ÊTRE.


D’après votre MCD du 12/09 (message #42), un gift ne pouvait être détruit qu'une seule fois, et maintenant ça peut être plusieurs fois (message #56 du 14/09)...
=>
En arrière toutes ! Pour en revenir au subterfuge du feignant-qui-ne-veut-pas-bricoler-le-MLD :

Ou, pour sortir du train-train et du ronron, prendre le taureau par les cornes, son courage à deux mains et faire appel à la notation E/R façon PowerAMC, ça n’est quand même pas la mer à boire :

Dans le MLD, la paire {GFT_ID, TRN_DATE} de l’en-tête de la table TRANSACTION devra faire l’objet d’une clé alternative, sinon on pourra engranger deux transactions au même moment pour le même gift. Je dirais même qu’en fait l’attribut TRN_ID peut disparaître et l’attribut TRN_DATE le remplacer pour participer à l’identifiant du type d’entité TRANSACTION : la paire {GFT_ID, TRN_DATE} sera alors clé primaire de la table qui en sera dérivée.

Bon bin il n'est pas possible de représenter des contraintes d'inclusion/d'exclusion dans power amc ^^

Il est vrai qu’avec la Rolls on ne peut pas représenter cela, auquel cas on peut préférer passer à la Bentley (WinDesign) ou compléter avec ce brave Paint...

[fsmrel]

Pour compléter mon message précédent qui évoque le subterfuge du feignant-qui-ne-veut-pas-bricoler-le-MLD :

Pourquoi est-ce que j'obtiens deux relations CONCERNER et CONCERNER2 entre les entités-types GIFT et DESTRUCTION ?

C’est pour des raisons de symétrie...

j'aimerais savoir ce vous entendez exactement par symétrie ici.

Well. Comme on a une cardinalité maximale 1 de chaque côté dans le MCD, PowerAMC n’hésite pas à symétriser et mettre en œuvre une double contrainte référentielle dans le MLD, sans apprécier le poids sémantique relatif des 2 entités-types : pour lui, malgré 0,1 d’un côté et (1,1) de l’autre (notez les parenthèses encadrant 1,1). C’est comme s’il ne cherchait pas à distinguer injection et bijection. J'accepterai néanmoins un démenti charpenté.

Pour l’anecdote, un des pères de Merise déclare indispensable la double contrainte entre les tables, voyez le 5e exemple de Dénormalisation vs amélioration (optimisation), mais il n’a pas compris le Modèle Relationnel de Données. En effet, il justifie cette nécessité par le besoin de « faciliter la communication » ! Ce qui est un non sens : en relationnel on ne communique pas, on ne navigue pas, on n’est pas dans le paradigme Codasyl, mais on en reste au quoi, on effectue des jointures et on crée au besoin des vues pour les utilisateurs (programmes ou terminalistes).

A la manière d’Antoine de la Foy (dans Les Tontons flingueurs), j’ai envie de dire à l’inconscient :

Vous faites sans doute autorité en matière de modélisation conceptuelle, mais vos opinions sur la modélisation dans un contexte relationnel, je vous conseille de ne les utiliser qu’en suppositoire !... Voilà !... Et encore... Pour enfant...

Pour ma part, je ne me prétends pas être spécialiste de Merise, mais en revanche je suis très chatouilleux quant à l’esprit du Modèle Relationnel de Données...

[Kropernic]

Si donc le log de SQL Server ne suffit pas pour répondre à votre besoin en ce qui concerne la table GIFT, il faudra que vous doubliez celle-ci d’une table GIFT_LOG dont l’en-tête comporte les colonnes PFX_CREATED_BY, PFX_CREATED etc. et que vous gérerez vous-même à coups de triggers dédiés, vues (exemple GIFT JOIN GIFT_LOG), procédures et autres facilités connues seulement du DBA et de la Production.

Vous parlez dans ce paragraphe du log de SQL Server. De quel log exactement parlez-vous ? Le transaction log (fichier .ldf ?) ou bien s'agit d'un autre log dont j'ignore l'existance ?

F.y.i., je suis également novice dans l'administration de base de données.

[Kropernic]

Je reviens sur les adresses. (j'ai bien tenté de trouvé un exemple de modélisation sur le net mais je ne vois des choses du genre Client(client_id, adresse, ...))

Concernant les adresses, j'ai pour le moment le schéma en pièce jointe.
Comme l'indique la flèche rouge, j'ai un bonhomme NULL pour lequel je vous emprunterais bien une pièce d'artillerie .

Je pensais apporter la modification suivante (pour une fois, j'apporte une possible solution) pour extraire ce numéro de boîte et j'aimerais votre avis :

Code :

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

[ADDRESS_ADR]-0,1----(PRECISER)----1,1-[BOXNUMBER_BOX]

Où ADDRESS_ADR a les attributs suivant :
- ADR_ID ;
- ADR_STREET ;
- ADR_NUM ;

Et où BOXNUMBER_BOX a les attributs suivant :
- BOX_ID ;
- BOX_NUM ;


De cette manière, je pense avoir totalement éradiquer les NULLs de la surface du schéma.

Est-ce correct ? Y a-t-il de meilleures manières de normaliser une adresse postale* ?

*Je sais que je pourrais encore créer une colonne pour le type de voirie mais cette donnée est, en ce qui me concerne, purement informative et non pas fonctionnelle (j'espère avoir utilisé les bons termes).

[CinePhil]

Pour les adresses, tu peux commencer par lire cette partie d'article de SQLPro.

Il avait aussi publié, sur son blog je crois, un article sur la modélisation d'une personne et/ou d'une adresse qui était très (trop ?) complète. Faudrait chercher un peu.