Discussion :

[eli-stein]

Bonjour à tous,
Voilà je suis entraine de crée un base se données pour gérer un service. Le principe est que les utilisateurs vont entrer les différentes opérations des clients. Il existe 5 types d'opérations. Chacune des opérations possède trois tables: conseillées, ouvertes et clôturés. Pourquoi trois tables est pas une table avec un champ statut? Parce que les informations ne sont pas du tout les mêmes suivant le statut. De l'autre côté j'ai une table qui contient les clients. Avec une clé primaire indexée sans doublon qui s'appelle N° client.
Ce champ est présent dans toute les tables des opérations donc ça fait 15 tables. Dans le schéma des relations j'ai placé la table des client au centre et ensuite toutes les tables des opérations autour et j'ai crée une relation entre le champ N° client de la table des clients et N° client de chacun des tables des opérations. Ça fait 15 relations. C’est correct ou il y a un moyen de rendre le schéma plus léger ?

[Invité]

Bonjour

Une copie d'écran du schéma serait la bienvenue pour la compréhension.

Philippe

[eli-stein]

Mais bien sur, voila je joins un schéma réduit de la structure. Tu multiplie ça par 5 tu auras le schéma globale. Le champ N° base est le numéro de l'opération qui reste le même quand l'opération passe de conseillée à ouverte. Quand l'opération passe de ouverte à clôturée alors là, la clé primaire devient N° base f, mais N° base est toujours présent pour savoir quelle est l'opération initial, car une opération peut être clôturée sur plusieurs étapes. Quand elle est complètement clôturée elle disparait de la table des opérations ouvertes mais sa trace initial reste dans la table des opérations conseillées.

PS: j'ai évité de joindre le schéma dès l'ouverture car juste avant j'ai lu le message de TOfalu qui demande de ne pas le faire.

[Tofalu]

Euh, sans la liste complète des champs et des tables, comment veux tu que l'on donne un avis ? Le choix d'un type d'héritage se fait en fonction des champs à spécialiser.

Sans plus d'infos : c'est FAUX. 5 fois le même triplet de tables, ça doit pouvoir se gérer mieux

[eli-stein]

je viens de poster un schéma dans le message d'avant. toutes les opérations sont complètement indépantes donc les tables sont independantes aussi. La seul relations qui peut existé c'est avec la table "mère": table des clients. Si le schéma que j'ai poster il y a deux messages est bien alorssi toutes les autres tables sont indépendantes ça doit d'être bien comme principe non ?

[f-leb]

Bonjour à tous,

Deux, trois petites questions car aller chercher les clients dans quinze tables ça parait pas très jojo à priori :

Parce que les informations ne sont pas du tout les mêmes suivant le statut.

D’accord mais que se passe-t-il suivant le type ? Autrement dit, il y aurait-il une raison qui interdirait de faire un schéma avec seulement 4 tables [Client], [Opérations conseillées], [opérations ouvertes], [opérations clôturées] avec un champ supplémentaire NuméroType(=1 à 5) dans la table [Opérations conseillées] ?

Quand elle est complètement clôturée elle disparait de la table des opérations ouvertes mais sa trace initiale reste dans la table des opérations conseillées.

J’ai un doute. Est-ce que cela signifie qu’une opération conseillée et clôturée peut être réouverte à nouveau ?

[eli-stein]

Bonjour,
Oui en effet il y une raison qui m'interdis de faire réunir les 15 tables dans 3: Les champs ne sont pas du tout les mêmes pour les différents type d'opération. Effectivement ça parait pas trop intelligent mais une opération de type 1 peut avoir 10 critère alors une de type de en a 20 critère. Donc c'etait impossible de la réunir malheureusement.

Pour répondre à ta deuxième question. une opération conseillées ne peut en aucun cas être exécuté plus qu'une fois.

[f-leb]

bonjour,

Effectivement ça parait pas trop intelligent mais une opération de type 1 peut avoir 10 critère alors une de type de en a 20 critère.

On peut raisonnablement penser qu’un certain nombre de ces critères sont communs aux 5 types (un client, une date, …). Pourquoi alors, dans un premier temps, ne pas généraliser [Opération conseillée type 1], [Opération conseillée type 2], etc en [Opération conseillée] reliée à [Client].

Schéma limité à deux types pour simplifier :

Ope_ConseilleeType1-1--------1-OpeConseillee-∞-----1-Client
...................................................|
...................................................1
Ope_ConseilleeType2-1--------------+

Selon les règles de gestion :
Une opération conseillée a un certain nombre de caractéristiques communes à tout type d’opération (comme une date et un client dans mon schéma).
Une opération conseillée est soit de type 1, soit de type 2 (et pas les deux) avec un certain nombre de caractéristiques spécialisées selon le type 1 ou 2.

Est-ce que ce bout de schéma est conforme à tes règles de gestion ?

[Tofalu]

De toute façon, sans le modèle dans sa globalité, inutile d'aller plus loin. Sur le peu que l'on voit sur l'image, on peut déjà noter des incohérences : Le champ Client dans les opérations qui a priori n'est pas en dépendance fonctionnelle (puisque N°Client est déjà présent), des champs communs à toutes les tables (NBase, Nclient...)
Il nous manque aussi des infos de contexte : est ce qu'il est possible que demain ou aprés, le modèle évolue et conduise à la création d'un nouveau type, d'une nouvelle opération. Aujourd'hui, il y en a 5 et demain ? Est ce que des caractèristiques peuvent être amenée à changer, etc.

[eli-stein]

je le trouve bien le principe que tu propose f-leb. c'est vrai qu'il y a pas mal de champs qui sont communs à toutes les tables. il y a en 8. je vais faire comme tu dis. et je ferai la même chose pour les opérations ouvertes et clôturées.
Merci beaucoup