Discussion :

[fsmrel]

Bonjour,

Pourriez-vous présenter un exemple de ce que vous voulez faire ?

Quel est le message d'erreur ?

[nouras]

Bonjour ,

[fsmrel]

Vous cherchez à définir un attribut Date_debut pour l’entité-type ABSENCE_EN_COURS, alors qu’une autre entité-type (disons ABSENCE_PERIODE) comporte un attribut dont le code porte déjà ce nom. PowerAMC parle de règles de normalisation qui en l’occurrence ne présentent strictement aucun intérêt et nous cassent plutôt les pieds.

Avec ma version antique de PowerAMC, je décoche la case servant à contrôler la règle :




Avec la version moderne dont vous disposez, vous devez avoir une fenêtre du même genre.

D’après la documentation en ligne de PowerAMC V16 :

Contrôle de l'unicité et de la réutilisation des informations :

« Vous pouvez contrôler les contraintes de dénomination et de réutilisation pour les informations à l'aide des options de MCD, en sélectionnant Outils > Options du modèle. »

[nouras]

Merci

[fsmrel]

Si vous avez des problèmes avec le MLD et SQL, n'hésitez pas...

[nouras]

Merci
en fait j'ai eu cet erreur pendant la génération du MLD que je n'ai pas compris

"Package Dépendance circulaire Lien d'héritage 'Personne - Inheritance_1 - Animateur', Relation 'etre_abscent', Relation 'etre_abscent2' "

Le MCD complet est ci-joint

[fsmrel]

Bonsoir nouras,


Je vous conseille de télécharger le document de référence de PowerAMC : Modélisation des données.

j'ai eu cet erreur pendant la génération du MLD que je n'ai pas compris

"Package Dépendance circulaire Lien d'héritage 'Personne - Inheritance_1 - Animateur', Relation 'etre_abscent', Relation 'etre_abscent2' "

Votre MCD est correct. Cela dit, lorsqu’il cherche à produire le MLD, en affichant ce message PowerAMC dit que l’entité-type ANIMATEUR boucle sur elle -même (cf. page 363 du document de référence). En toute logique, ça serait à cause de l’association « etre_abscent2 » qui serait donc une scorie que vous avez conservée et qui n’apparaît pas dans le MCD. Ouvrez l’explorateur d’objets et si elle est bien là, supprimez cette scorie pour ne conserver que l’association « etre_abscent », comme ci-dessous :




Si en fait « etre_abscent2 » ne figure pas dans l’explorateur d’objets, peut-être PowerAMC cherche-t-il à anticiper des contrôles de niveau MLD, mais je suis septique. De toute façon, ne perdez pas de temps avec le MLD, au stade du MCD demandez directement la génération du MPD (qui en réalité contient le MLD). Attention ! Lors de cette génération, PowerAMC a la fâcheuse manie de produire un cycle dans les configurations telles que celle-ci dans le MCD (notation Merise) :

[ANIMATEUR]----0,1----(ETRE_ABSENT)----(1,1)----[ABSENCE_EN_COURS]

En effet, concernant ce qui est généré :

ABSENCE_EN_COURS fait référence à ANIMATEUR, c’est ce qu’on attend, mais ANIMATEUR n’a absolument pas à faire référence à ABSENCE_EN_COURS ! En conséquence il faut supprimer cette référence.




Après suppression de la référence à ABSENCE_EN_COURS, tout rentre dans l’ordre (l’attribut Colonne_5 produit par PowerAMC disparaît automatiquement) :




Concernant les relations d’héritage

Quand avec ma version antique de PowerAMC on clique sur la demi-lune symbolisant l’héritage il y a ouverture d’une fenêtre « Propriété de l’héritage », comportant un onglet « Génération ». Une fois ouvert cet onglet, il faut alors activer le bouton « N’hériter que des attributs primaires » (c'est-à-dire l’identifiant), sinon tous les attributs du surtype (PERSONNE en l’occurrence) seront recopiés dans les sous-types (ANIMATEUR, EXTERIEUR) : obésité des tables garantie !

[nouras]

Merci

J'ai choisi de travailler avec une base de donnée embarqué telle que le hsqldb .Est-ce que vous avez une idée sur cette base ?

[fsmrel]

Bonsoir nouras,


Avez-vous pu générer le MPD ?

Je ne connais pas HSQLDB, mais avant de créer les tables, il serait préférable qu’on procède à la validation du code SQL produit par PowerAMC...

[nouras]

Bonsoir ,
Voici le MPD généré .
Comment peuvons-nous valider le code SQL?

[fsmrel]

Bonsoir nouras,

Comment pouvons-nous valider le code SQL?

Il faut en demander la génération : si PowerAMC produit effectivement le code SQL de création des tables sans signaler d’erreur, c’est que MLD est pour lui correct, donc le code SQL aussi. Mais il peut y avoir des contrôles que PowerAMC n’effectue pas, par exemple ceux qui ont trait à la normalisation. Ainsi l’attribut Type_Parenté n’a pas à figurer dans la table AVOIR (qu’il serait opportun de renommer en PARENTÉ ou FILIATION), mais dans la table PARENT. En effet, le type de parenté ne caractérise que le parent (il serait opportun en plus de prévoir une contrainte précisant que l’attribut Type_Parenté ne peut prendre que les valeurs « père », « mère »).

Après un examen visuel, table par table, il faudra ensuite soumettre le code à HSQLDB qui rouspètera peut-être sur des points valides selon les autres SGBD, et qui peut en plus avoir des exigences qui n’ont pas lieu chez les autres...


N.B.

Pour éviter que le bonhomme Null vienne semer la panique, il faudrait rendre tous les attributs obligatoires.

Il faudrait remplacer le type FLOAT par INTEGER ou DECIMAL.

MLD, table AVOIR : pour y voir plus clair, il serait bien de renommer Par_PersonneId en ParentId et PersonneId en EndantId.

Table ANIMATEUR : si le CIN est propre à un animateur, il devra faire l’objet d’une clé alternative.

[nouras]

Comment ajouter une contrainte sur l'attribut Type_parenté ? En y créant un table ?

[fsmrel]

Avec un SGBD conforme à la norme SQL, il suffit d'ajouter la contrainte ad-hoc dans la table PARENT :

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE PARENT 
(
   PersonneId           INT                  NOT NULL,
   TypeParent           VARCHAR(5)           NOT NULL,
   CONSTRAINT PARENT_PK PRIMARY KEY (PersonneId),
   CONSTRAINT PARENT_ADULTE_FK FOREIGN KEY (PersonneId) REFERENCES ADULTE,
   CONSTRAINT PARENT_ADULTE_CHK1 CHECK (TypeParent IN ('père, mère'))
) ;