Problème de modélisation avec Case Studio

[soso78]

Salut,

Dans le cadre de la modélisation de ma base de données, j'utilise Case Studio.

Or, j'ai un problème pour modéliser le schéma suivant :

- j'ai une entité nommé "RUBRIQUE",
- une autre nommé "FOURNISSEUR"

Je souhaite créer une relation entre l'entité RUBRIQUE et FOURNISSEUR. Jusque là, tout va bien. Le hic, c'est que l'on peut choisir jusqu'à 4 rubriques par fournisseurs.

Comment faire ?

J'ai essayé de créer plusieurs relations entre RUBRIQUE et FOURNISSEUR mais Case Studio m'affiche une erreur signalant que l'attribut est identique "CODE_RUBRIQUE".

Idéalement, je souhaiterais que la table "FOURNISSEURS" corresponde à ceci :

- IDFRS (clé primaire),
- FOURNISSEUR (nom),
- CODE_RUBRIQUE1 (1ère rubrique pointant sur l'entité "RUBRIQUE"),
- CODE_RUBRIQUE2 (2ème rubrique pointant sur l'entité "RUBRIQUE"),
- CODE_RUBRIQUE3 (rubrique pointant sur l'entité "RUBRIQUE"),
- CODE_RUBRIQUE4 (4ème rubrique pointant sur l'entité "RUBRIQUE");

Pouvez-vous m'aider à modéliser ce schéma ?

Merci par avance.

[Médiat]

Non, car cela ne ressemble pas une relation en première forme normale...

[al1_24]

Tu pourras éventuellement faire ça au niveau de la modélisation physique de ta base, mais au niveau logique tu auras :
une entité Fournisseur
une entité Rubrique
une relation entre les deux avec les cardinalités qui vont :

Rubrique -> Fournisseur : 0,n
Fournisseur -> Rubrique : 0,4

[soso78]

Salut,

Si je comprends bien, au niveau logique, on n'aura qu'une relation "RUBRIQUE" <--> "FOURNISSEUR".

Comment gérer ce modèle pour la modélisation "physique" ?

[al1_24]

Envoyé par esoso

Comment gérer ce modèle pour la modélisation "physique" ?

Soit la structure que tu proposais (pabo )
Soit une table de relation (ID_FRNSR, CODE_RUBRIQUE) beaucoup plus propre au niveau de la normalisation !

[soso78]

Salut,

Effectivement ta solution me semble meilleure. Cependant, j'avais appris, il y a déjà quelques temps qu'on pouvait réaliser un CIF (Contrainte d'Intégrité Fonctionnelle). Et que c'était là l'exemple adéquat.

Dans quelle cas doit-on utiliser un CIF plutôt qu'une entité / relation ?

Merci.

[qi130]

Concernant ton problème initial d'attributs de même nom, ce n'est pas bloquant.

J'ai aussi fait quelques modèles ayant ce cas de figure, et rien n'empêche CaseStudio de générer le SQL de création.

2 manières de faire:
1/ tu crées normalement tes 4 "relations", puis tu reviens en edit sur la table ayant les FK, tu édites ces FK pour en changer le nom physique (on ne peut pas changer le nom logique)
A la sauvegarde de la table par [Ok] tu auras le msg, tu fais Yes. Tu auras aussi ce warning lors de la vérification du modèle...

Mais comme la génération utilise le nom physique, tout va bien.

2/ au lieu de créer directement une relation donnant une FK, tu commences par ajouter dans ta table un attribut qui servira de cible à ta FK. Puis tu crées une relation "informative" en partant de la table foreign. Puis, edit de la relation pour positionner son type à Non identifying, puis [Ok]. la FK "classique" apparait, en plus de l'attribut que tu viens d'ajouter.
Puis, clic-droit sur la relation, choisir Foreign Keys. Dans la fenêtre, clic sur la cellule de la colonne New FK, 1 combobox se dessine, tu n'as plus qu'à choisir ton attribut, puis [Ok].
Alors, dans ta table, ton attribut est marqué FK, et l'attribut hérité de la modification de la relation a disparu.

C'est la méthode académique , mais perso, j'utilise plus souvent la première...