Version imprimable
Bonjour,
ca fait longtemps que je n'ai plus fait de merise, et j'aimerai savoir s'il est possible d'ameliorer le mcd joint, ou me dire ci celui ci est déjà correct..
c'est pour intégrer dans une db une liste de cron (tache planifiée sous unix/linux). j'aimerai surtout mettre en avant le fait qu'un cron n'est défini que sur un seul serveur et n'appartient qu'à un seul utilisateur.
merci d'avance pour vos réponses
Correct pour moi.
Semble correct
Pour moi aussi c'est correct mais (et vous allez tous dire que je pousse le bouchon un peu loin !) est-il possible qu'un CRON appartenant à un UTILISATEUR soit configuré sur un SERVEUR non utilisé par cet UTILISATEUR ?
Par exemple : Cron1 appartient User1 et est configuré sur Serveur1. User1 doit-il obligatoirement être utilisateur de Serveur1 ?
Si la réponse à cette 2e question est oui (donc réponse non à la 1ère question), alors il faut modéliser une contrainte exprimant la règle :
Tout Utilisateur possédant un Cron configuré sur un Serveur doit être utilisateur de ce Serveur.
Il s'agit d'une contrainte d'inclusion de "posséder" et "être configuré" dans "utiliser".
Non seulement la modélisation de la contrainte enrichira la sémantique du MCD mais elle permettra également, en phase de réalisation, de ne pas oublier d'implémenter un trigger ou un contrôle par programme qui vérifiera la règle.
JPhi33
Bonsoir,
A ceci près qu’un trigger est déclenché instantanément (norme SQL), ce qui veut dire, au niveau des opérations, que le couple {user1, server1} devra d’abord être inséré dans la table Utiliser avant de l’être dans la table CRON (incidemment, ce trigger devra aussi contrôler les modifications des couples).Citation:
Envoyé par JPhi33
Exemple SQL Server 2005
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15CREATE TRIGGER mathieu57 ON CRON For Insert, Update As Select '' As 'Cron délinquant : ', x.* From Inserted x Where Not Exists (Select * From Utiliser y Where x.id_Serveur = y.id_Serveur And x.id_Utilisateur = y.id_Utilisateur ) If @@Rowcount > 0 Begin RAISERROR ('Et l''inclusion !',18,1) Return End
Dans ces conditions, au trigger, on peut préférer une contrainte référentielle, plus simple de mise en oeuvre
En observant que les contraintes référentielles liant CRON à SERVEUR d’une part, et à UTILISATEUR d’autre part, ont disparu car faisant double emploi (application du rasoir d’Ockham).Code:
2
3
4
5
6
7
8Create Table CRON ( id_Cron Integer Not null , contenu_Cron Varchar(64) Not null , id_Serveur Integer Not null , id_Utilisateur Integer Not null , Primary Key (id_Cron) , Foreign Key (id_Serveur, id_Utilisateur) References Utiliser
Si l’on procède à une rétroconception (avec PowerAMC en l'occurrence), le MCD change de tête, mais ceci est une autre histoire...
http://img127.imageshack.us/img127/5...reverseeq2.jpg
A mon tour, j'ai poussé le bouchon un peu loin. Pour revenir à la réalité, supposons que la règle d’inclusion ait été énoncée bien après la mise en production de la base de données : à moins de disposer d’un SGBD permettant de différer les contrôles d’intégrité, il est vraisemblable que le contrôle ne fera ni l’objet d’un trigger ni d’une contrainte référentielle, mais d’un développement ad-hoc, afin de ne pas avoir à casser la structure des programmes existants (de même qu'on ne touchera pas au MCD)...
Certains SGBD (Oracle par exemple, mais pas SQL Server) permettent, conformément à la norme SQL, que soient différés les contrôles d’intégrité référentielle, faisant que l’on peut insérer un tuple dans la table CRON, avant d’insérer un tuple (de référence) dans la table Utiliser. C’est par exemple au Commit que les contrôles seront déclenchés. Pour plus d’information, se renseigner auprès du champion du SQL, SQLpro.
Maintenant, j’ai peut-être mal interprété l’énoncé de la règle d’inclusion...
En tout état de cause, bonne fête de Pâques
Bonjour,
L'interprétation de la contrainte d'inclusion est tout à fait juste. Et cette modélisation en est la conclusion logique.Citation:
Envoyé par fsmrel
Mais pour y aboutir en restant dans le modèle EA, il faut utiliser des extensions de ce modèle que bien peu connaissent (et je le déplore). Ces nombreuses extensions ont été proposées par des "pointures" en la matière (Arnold ROCHFELD, José MOREJON, pour ne citer qu'eux). Bien qu'elles existent depuis 10 à 15 ans, elles n'ont jamais été prises en compte par AMC*DESIGNOR ni par PowerAMC (son successeur).
Ici, on utilisera le concept de "Association d'association", qui aboutit à la modélisation suivante :
Pièce jointe 27432
dont le MLD dérivé est strictement identique.
JPhi33
PS : Désolé pour ma méconnaissance des possibilités des triggers...
Bonsoir,
On ne peut effectivement que regretter que PowerAMC n'ait pas intégré ces extensions (que je ne connais pas de façon exhaustive, la preuve...)Citation:
Envoyé par JPhi33
La représentation que vous proposez est élégante et illustre l’abandon de la règle "pas d’associations entre associations", abandon bien signalé par ailleurs dans OOM, en relation avec l’arbitraire de la dichotomie entre entités et associations (cf. Les Objets, page 217 dans le 2e tirage, 1998).
Je trouve votre représentation sémantiquement comparable, mais plus simple et beaucoup plus légère que celle utilisée par exemple par Korth et Silberschatz, auxquels je fais référence pour la représentation ci-dessous, auteurs qui font référence à leur tour à l’article fondateur de John et Diane Smith (1977) "Database abstractions: Aggregation and Generalization".
http://img387.imageshack.us/img387/1...regatiosb7.jpg
