Discussion :

[Maxence HUBICHE]

ben... les cardinalités plus "pointues" du genre
0,1..1,2

On sait faire du n...... mais pour faire du 2, je ne connais pas d'autre solution qu'un contrôle par code.
Même les CONSTRAINT SQL n'y font rien, que je sache.
D'un autre côté, je n'ai pas la science infuse, donc peut-être que je pourrai en apprendre de quelqu'un

[Tofalu]

Ah ben si tu peux faire du 2, genre si j'ai du 0,2 entre facture et reglement

Code :

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

1
2
3
4
5
6
7
8
ALTER TABLE tblReglement 
  ADD CONSTRAINT ReglementMaxi  
    CHECK   ((
                  SELECT Count(idFacture) 
                  FROM tblFacture 
                  WHERE idFacture=tblreglement.idfacture
                  )<=2
        )

En lançant l'ordre avec ADO

[Maxence HUBICHE]

En lançant l'ordre avec ADO

On sait faire du n...... mais pour faire du 2, je ne connais pas d'autre solution qu'un contrôle par code.

On est d'accords

[EDIT]
Et même en SQL, c'est du Code
Dans la fenêtre de relations(pour être plus précis), je ne connais pas
[/EDIT]

[Tofalu]

Pas d'autre possibilité, à ma connaissance, qu'une gestion par code.

Ok, on s'est mal compris.

Pour moi ce n'est pas une gestion par code, mais une définition par code.

Une gestion par code serait pour moi : dans un formulaire, c'est le code sur before_update qui va vérifier qu'il n'y a pas trop de règlements pour la facture.

[Maxence HUBICHE]

no problemo !
Je m'étais mal exprimé.

Je voulais dire qu'à part une définition ou une gestion par code, je ne connaissais pas de moyen de définir des relations avec une cardinalité 0,1..1,2 (par exemple)

La définition de contraintes ne modifie pas les cardinalités, mais ajoutent un CHECK sur la validité des données insérées.

Or, je parlais bien de cardinalités.

Je ne sais pas créer une cardinalité "spéciale" telle que celle décrite plus haut, mais je sais la gérer.

C'est plus clair exprimé ainsi ?

[Tofalu]

Mais une cardinalité au fond, lors du passage du MCD au modèle physique, c'est essentiellement le positionnement d'une clé étrangère dans telle ou telle table, non ?
Ce qui se traduit par une clause constraint dans le modèle physique non ? Constraint Foreign Key ?

Serait ce un abus que de dire que la cardinalité du MCD se traduit par une contrainte dans le modèle physique ?

[Maxence HUBICHE]

Je presume que la constraint Foreign Key ne te dis pas si c'est du 1-1 ou du 1-n !
Ce qui te permet de le définir, c'est ton indexation du champ
Jusque là, on est d'accord ?
Ce genre de carinalités apparait dans la fenêtre des relations.

Seules les valeurs maximales apparaissent, puisque dans le cas d'un 0,1..0,n Access traduit cela par un 1-n
Cependant, tu peux définir les 0 par des NullInterdits... ou pas.
Mais, encore une fois, ce sont les maxima qui apparaissent sur le modèle

Je ne connais pas de moyen de faire apparaitre une relation 0,1..0,2 dans les relations...
Rien ne donne 1-2.... mais bien 1-n

La gestion par CONSTRAINT de ces limites est intéressante, mais j'aimerai bien savoir la traduction en Reverse Engineering que ferai un logiciel tel AMC Designer d'une telle base.
0,1..0,2 ???? ou 0,1..0,n ????

[Tofalu]

A vrai dire du moment que la base de données gère du 0,X quelque soit le mécanisme utilisé, pourquoi n'aurais je pas le droit de dire que je respecte les cardinalités fixées dans les associations de mon MCD ? Certes ces cardinalités ne sont pas affichées mais n'en sont-elles pas pour autant valable ?

- La foreign key me permet de dire qu'il y avait une association
- Le null interdit me définit la cardinalité min (0,1)
- L'indexation me définit la multiplicité
- La clause CONSTRAINT CHECK me définit la cardinalité max


Par contre, il serait intéressant de voir comment serait gérer par exemple du 4,n

[Maxence HUBICHE]

Je n'ai pas dit le contraire... et, dans tous les cas, ceci ne change en rien le fait qu'on est bien obligé de passer par du code...

[Tofalu]

Oui, mais une nouvelle fois, en te relisant, j'avais l'impression que tu sous entendais que le mécanisme n'était pas gérable directement par le moteur JET :

Une fois cette modélisation effectuée (avec logiciel ou papier crayon) on construit la base de données. Et on reproduit le schéma analysé, se servant des Index et de la propriété Null Interdit pour définir les cardinalités gérables directement par le moteur de bases de données JET :0,1..0,1 // 0,1..1,1 // 0,1..0,n
1,1..1,1 // 1,1..0,n // 1,1..1,n
Mais quid pour les autres possibilités ?

Mon but était simplement d'enfoncer le clou pour dire que le 0,X est directement gérable par le moteur JET. Certes la mise en place ne se fait pas dans le RAD Access mais le mécanisme est nativement géré par JET.

[Maxence HUBICHE]

C'est sûr qu'en retirant le début de la phrase, tu pourras me faire dire n'importe quoi ...

[bulmish]

Personnellement, je ne peux pas me passer des relations; mais je pense ici que l'enjeu ici est la question de sécurisation ou protection des droits d'auteur. Cacher les relations revient à empêcher les autres de comprendre l'étude, l'analyse qui a été faite.

[Pierre Fauconnier]

Personnellement, je ne peux pas me passer des relations; mais je pense ici que l'enjeu ici est la question de sécurisation ou protection des droits d'auteur. Cacher les relations revient à empêcher les autres de comprendre l'étude, l'analyse qui a été faite.

???

[dg78]

Bonjour à tous,

Moi aussi j'ai vu de la lumière ou plutôt un sujet (oh combien important pour qui touche aux bases de données : l'intégrité référentielle).

Mais une cardinalité au fond, lors du passage du MCD au modèle physique, c'est essentiellement le positionnement d'une clé étrangère dans telle ou telle table, non ?
Ce qui se traduit par une clause constraint dans le modèle physique non ? Constraint Foreign Key ?

Serait ce un abus que de dire que la cardinalité du MCD se traduit par une contrainte dans le modèle physique ?

Et oui, c'est la dure réalité quand on quitte le monde merveilleux de Merise (MCD, cardinalité ..) pour arriver dans le monde terre à terre des database : la cardinalité se résume à une toute bête clé étrangère.

Par contre, si je ne m'abuse, si la cardinalité est (0,1) ou (0,n), c'est à dire si elle accepte le null, alors on perd l'intégrité référentielle. Existe-t-il un moyen de la maintenir sans prendre en compte les null ? je ne sais pas.

Une gestion par code serait pour moi : dans un formulaire, c'est le code sur before_update qui va vérifier qu'il n'y a pas trop de règlements pour la facture.
09/06/2009 21h11

A mon avis, il est important que le code gère les règles de validation (ici : pas trop de réglements pour la facture) quitte à mettre en doublon dans la base des contraintes pour être sûr que les règles ne sont pas transgressées (indispensable si la base est utilisée avec d'autres codes).

[Tofalu]

Par contre, si je ne m'abuse, si la cardinalité est (0,1) ou (0,n), c'est à dire si elle accepte le null, alors on perd l'intégrité référentielle. Existe-t-il un moyen de la maintenir sans prendre en compte les null ? je ne sais pas

Non, on ne la perd pas. Il faut juste garder en tête que si la clé étrangère est de type numérique, la valeur par défaut sera 0. Il faut donc la modifier par Null dans les propriétés du champ (propriété Valeur par défaut) et non par garder 0 qu'Access vous aura recommandé. Sans quoi, évidemment, lors de l'omission de ce champ pendant la saisie, un message d'erreur signalera que l'enregistrement 0 n'est pas présent dans la table en relation (c'est à dire que la clé primaire à la valeur 0 n'existe pas, c'est d'autant plus vrai que les clé primaire sont des numéroAuto et que leur valeur commence à 1)

A mon avis, il est important que le code gère les règles de validation

Que le code transmette les erreurs à l'utilisateur (avec analyse, traduction, etc) qui lui sont transmise par le moteur : je suis d'accord. Par contre que le code VBA réalise la validation (c'est à dire qu'ici par exemple, il va aller compter les règlements pour voir si y en pas trop), je ne vois pas bien pourquoi sachant que ce travail est déjà confié au moteur, qui gère en même temps l'accès concurrentiel et le verrouillage.

Le faire dans la base et dans le code, c'est toujours mieux que pas dans la base, mais pourquoi deux fois ?

[dg78]

Non, on ne la perd pas. (l'intégrité référentielle)

Est ce que ceci s'applique aussi à SQL Server ?

Quant aux règles de validation, il est vrai qu'en Access, le moteur de la base est prépondérant par rapport au VBA. Donc effectivement il n'est pas utile de faire la validation aussi avec le VBA.

En fait je fais peu d'Access mais surtout du DotNet avec ADO.NET qui utilise une base Sql Server. Dans ce cas, il est préférable de gérer les règles de validation dans les classes métier dans le code plutôt que de confier cette tâche uniquement à Sql Server.
Avantages : pas d'aller-retour vers la base, meilleure interaction avec la couche logique métier (BLL) et puis également les développeurs en dotnet ne connaissent pas toujours toutes les finesses de gestion des bases de données.

[f-leb]

SQLPro a tranché:

Contraintes FOREIGN KEY SQL vs code client

Se poser la question d'implanter ou pas les contraintes d'intégrité référentielle dans une base de données est aussi stupide que de se demander s'il faut vraiment des roues à une voiture...

voilà, c'est pas autrement, na. Mettez des roues à vos bases, quoi !

[fsmrel]

C'est dommage que @fsmrel ne passe pas par là tiens

Il passe un peu tard, mais il laisse quelques réflexions qu'il sème à l'occasion chez DVP :

http://www.developpez.net/forums/d82...t/#post4720293

Par ailleurs, je rappelle souvent que lorsque DB2 (et a fortiori les autres SGBDR) ne gérait pas encore l’intégrité référentielle, le G.U.I.D.E. (Groupement des utilisateurs IBM) se faisait l’écho de la multitude qui la réclamait à cor et à cri. Quand au bout de quatre ans, en 1988, IBM nous la livra, changement de chanson : « Finalement, est-ce bien utile ? Est-ce que ça ne coûterait pas la feau des pesses quant aux performances ? » Concernant l’utilité, il n’y a pas photo, l’intégrité des données n’a pas de prix. Je le redis, en ce qui concerne la performance, plutôt que de faire dans l'incantation, il faut retrousser ses manches et quantifier les bienfaits/méfaits de l’IR à coups de prototypage des performances. C’est en tout cas ce que je fais systématiquement chez mes clients. Ensuite, on peut discuter objectivement avec la Direction de la Production de la mise en œuvre de l’IR. Pour ma part, avec cette approche, je n'ai jamais essuyé de refus, même quand en face ça commençait par renâcler sérieusement, pour des raisons bassement matérielles, mais bien compréhensibles.

[ilank]

Bonjour,

en relisant ce débat, je fais le constat que certains n'utiliseront donc jamais ni les triggers, ni les procédures stockées sous Access. Quelle horreur c'est du code !!

[Pierre Fauconnier]

Ilank, c'est juste pour "bêtement" troller?

Sinon, relis le sens des messages de ceux qui prônent l'intégrité référentielle dans la base plutôt que par code (forcément, jusqu'à Access 2010, hors de la structure des données) et tu comprendras que les mêmes prôneront évidemment l'utilisation des triggers et des procédures stockées en Access 2010