Discussion :

[Yuna]

Bonjour à tous,

Contexte : J'utilise Merise pour élaborer le modèle logique de données de nos tables que nous allons mettre en place sous oracle 10.i.
Je travaille avec le oracle sql developper data model.

Problème 1: J'arrive à la relation suivante entre deux entités de mon modèle:
1 application possède (0,n) flux.
1 flux possède (2,2) applications.

Flux---------------Application
(2,2)---------------(0,n)

Je pensais traiter ce cas comme une relation (n,m) avec une table intermédiaire faite des associations des PK de "flux" et "application" mais je pourrais obtenir plus de deux enregistrements dans cette table d'association "flux_application" or nous aurons toujours 2 et seulement 2 "applications" pour un "flux".

Dois-je mettre deux champs "application" dans ma table "flux" avec à chaque fois deux PK de la table "application" dans ces champs pour former une Foreign key composite?
Est-ce judiceux et faisable au niveau script de création de table?
Qu'en pensez-vous?

Problème 2 : Un modèle de données fait uniquement de tables d'entités et de tables d'association pour répondre à des cardinalités qui sont toutes de type (n,m) suggère-t-il un problème de conception du modèle?
Hu hu hu
Je n'ai aucune table avec des foreign keys, uniquement des PKs simples ou composites dans les tables d'association (pk_table1/pk_table2) et je me pose des questions.....

Merci pour vos conseils,
j'en ai besoin pour valider tout ça.

Gaëlle.

[CinePhil]

Problème 1 :

Flux---------------Application
(2,2)---------------(0,n)

Ne serait-ce pas équivalent à ceci :
Application -0,n----Relation1----1,1- Flux
Application -0,n----Relation2----1,1- Flux

Il ne reste plus qu'à mettre de la sémantique dans les relations 1 et 2 mais dans le principe si on a ça on a tout simplement une table Flux avec deux clés étrangères faisant référence à la même table Application.

Dois-je mettre deux champs "application" dans ma table "flux" avec à chaque fois deux PK de la table "application" dans ces champs pour former une Foreign key composite?

Ce que tu proposes correspond plutôt à une relation ternaire :
Flux -1,1----Relier----0,n- Application
|--------1,1-------|

Là encore, la sémantique de la relation permettrait de trancher.

Problème 2 :

Un modèle de données fait uniquement de tables d'entités et de tables d'association pour répondre à des cardinalités qui sont toutes de type (n,m) suggère-t-il un problème de conception du modèle?

Faut voir le schéma pour en juger mais ça en me semble pas impossible.

Un joueur peut posséder plusieurs types d'objets et un type d'objet peut être possédé par plusieurs joueurs :
Joueur -0,n----Posséder----0,n- Type_Objet

Un joueur peut entreprendre plusieurs actions et une action peut être entreprise par plusieurs joueurs :
Joueur -0,n----Entreprendre----0,n- Action

Si je relie les deux, je n'ai que des relations n,m.

Je n'ai aucune table avec des foreign keys, uniquement des PKs simples ou composites dans les tables d'association (pk_table1/pk_table2)

Si tu n'as que des relations (n,m), tu ne devrais avoir que des clés étrangères composites car composées des identifiants des tables (au moins deux) entrant en jeu dans l'association.

j'en ai besoin pour valider tout ça.

Propose nous ton schéma et un petit descriptif de l'univers qu'il est censé modéliser.

[Yuna]

Bonjour CinePhil et bonjour à vous tous,

Problème 1 : En lisant ta réponse concernant mon premier problème, je pense que je n'ai pas été assez précise ou claire
Je dois modéliser dans ma base Oracle, entre autres, les flux de données entre deux applications A et B par exemple.

Application A <------------------> Application B
1 Flux X
Application A<--------------------> Application C
1 Flux Y
Application B <-------------------> Application D
1 Flux Z

Dans ce contexte, chacune de mes applications SOURCE peut avoir de 1 à n flux vers autant d'applications TARGET.
Mais chacun de ces flux (X, Y, Z ...etc...) n'appartient qu'à deux applications, il est constitué intrinséquement d'une application SOURCE et d'une application TARGET obligatoirement.

=> Et je me demande comment modéliser cela au niveau des mes tables "Flux" et "Application"?

=> Est-ce que je créé dans ma table "Flux" deux champs application_source et application_target qui sont destinés à contenir la PK issues des deux enregistrements de la table "Applications" et est-ce que ces deux champs dans ma table "Flux" doivent former la Foreign key composite? C'est "propre" ce genre de conception?

Table_Flux:
PK id
FK id_Application_source + id_application_target
name_flux varchar (20)
type_flux varchar (10)
........

J'espère que ma question est plus claire et j'attends vos avis sur ce point, en vous remerciant pour votre aide à tous,

Gaëlle.


NB : Problème 2 : Mon modèle répond à toutes les questions envisagées par mon client pour son monitoring de flux donc j'estime que la conception est valide.....Je le souhaite en tout cas

[CinePhil]

Si il ne peut y avoir qu'un seul flux entre une application A et une application B, alors la table des flux est en fait issue de l'association suivante :
Application -0,n----Flux----0,n- Application

Elle est de plus porteuse de données, ce qui donne les tables :
Application (A_Id, ...)
Flux (F_IdApplicationA, F_IdApplicationB, F_Name, F_Type)

Le couple (A, B) ne peut exister qu'une seule fois dans la table Flux.

Si par contre il peut y avoir plusieurs flux entre l'application A et l'application B, alors Flux est une entité et il faut une relation ternaire :
Application -0,n----Relier----0,n- Flux
|-----------------0,n-------|

(je constate d'ailleurs que le schéma de la ternaire proposé dans mon précédent message était faux )

Ce qui donne les tables :
Application (A_Id, ...)
Flux (F_Id, F_Name, F_Type)
Flux_Application (AF_IdApplicationA, AF_IdApplicationB, AF_IdFlux)

Cette fois, c'est le trio (AF_IdApplicationA, AF_IdApplicationB, AF_IdFlux) qui est unique.

Au passage, le type du flux est probablement à externaliser dans une autre entité. Cela peut donner alors un autre schéma, si un type de flux ne peut exister qu'une seule fois entre deux applications mais que plusieurs flux peuvent exister entre deux application :
Application -0,n----Flux----0,n- TypeFlux
|-----------------0,n-------|

La table Flux redevient une table associative :
Application (A_Id, ...)
TypeFlux (TF_Id, TF_Name)
Flux (F_IdApplicationA, F_IdApplicationB, F_IdTypeFlux)

Sans connaître précisément votre besoin, j'opterais a priori pour cette dernière solution.

[Yuna]

Si par contre il peut y avoir plusieurs flux entre l'application A et l'application B, alors Flux est une entité et il faut une relation ternaire :
Application -0,n----Relier----0,n- Flux
|-----------------0,n-------|

(je constate d'ailleurs que le schéma de la ternaire proposé dans mon précédent message était faux )

Ce qui donne les tables :
Application (A_Id, ...)
Flux (F_Id, F_Name, F_Type)
Flux_Application (AF_IdApplicationA, AF_IdApplicationB, AF_IdFlux)

Cette fois, c'est le trio (AF_IdApplicationA, AF_IdApplicationB, AF_IdFlux) qui est unique.

Voilà, c'est ça, exactement ça qu'il me faut!
Après avoir re-interroger mon client sur le fonctionnel et ses besoins, je dois modéliser la relation flux-applications comme tu me le conseilles, parfait!

Merci beaucoup!
Je m'en retourne à mon script pour générer les tables puis je dois faire mes webforms pour le website et .....aaaaah.....Tant de travail encore

Merci encore et bonne journée à toutes et tous,
Gaëlle.