Problème de conception (Gestion de facturation)

**Ohcomand** · 04/05/2010, 10h55

Bonjour,

Je suis actuellement en stage et je dois créer une application de gestion de facture en termes de télécommunication.

Et maintenant j’ai besoin de vos lumières pour un point particulier dans mes schémas de conception

:

Alors tout d abord il faut savoir que la base de donnée a l’air assez grande à première vue donc j’ai identifié par des images la partie qui nous intéresse

:

Ici je représente le fait qu’un groupe peut être constitué de lignes fixes et de lignes GSM.

Aussi une ligne fixe ainsi qu’une ligne GSM peuvent être dans différents groupes (qui représentent des pôles, des directions, bref appelez çà comme vous le voulez).

Enfin une communication peut être effectuée soit par une ligne fixe, sois par une ligne GSM.

Ainsi j’en arrive au schéma suivant

:

Ici nous voyons donc que la ligne de "contenir" est référencé soit par Le numéro de la "ligne fixe", sois par le numéro de la "ligne GSM" ! Et de même pour Le numéro d’appel de "communication".

Je sais pertinemment que la généralisation des lignes est possible mais cela créerait une autre table et ma question est la suivante (ou plutôt mes questions) :

Est-ce que sans cette généralisation possible, la base de données suivante engendre des problèmes au niveau des clés étrangères référencées par 2 tables (dans contenir mais aussi communication)

?

Est-ce possible en fait de créer la base de données telle qu’elle ? Et si oui cela va-t-il alourdir considérablement les requêtes au niveau de ces tables

?

Ensuite si cela reste possible, comment génère-t-on ces clés étrangères en sql

?

Voilà merci de vos réponse que j'attends avec impatience

**@omzo** · 04/05/2010, 11h45

Salut Ohcomand,

Est-ce que sans cette généralisation possible, la base de données suivante engendre des problèmes au niveau des clés étrangères référencées par 2 tables (dans contenir mais aussi communication) ?

Je crois que vous auriez dû avoir dans votre MLD deux tables "Contenir" (l'une en relation avec les tables Groupe et Ligne_Fixe et l'autre en relation entre Groupe et Ligne_GSM) si vous respectez les règles de traduction d'un MCD en MLD. Il me semble que vous voyez par là une généralisation.
Dans ce cas comment pourriez vous différencier une ligne fixe d'une ligne mobile dans votre future BDD? Ou mieux est ce possible qu'un champ d'une table référence deux champs de deux tables différentes? A mon avis, c'est non?
Dans la table Communication aussi il devrait y avoir deux clés étrangères qui référencent respectivement les clés primaires des tables Ligne_Fixe et Ligne_GSM.

Est-ce possible en fait de créer la base de données telle qu’elle ? Et si oui cela va-t-il alourdir considérablement les requêtes au niveau de ces tables?

Compte tenu de ce que j'ai dit tantôt, je crois que ce serait mieux de revoir votre modèle.

comment génère-t-on ces clés étrangères en sql ?

Pour la réponse, voir ici

Si j'était à votre place, j'aurai opté pour la solution avec la généralisation des tables Lignes et bien suivre les règles de traduction d'un MCD en MLD.

J'espère avoir été clair.

**Oishiiii** · 04/05/2010, 11h53

Bonjour,

Envoyé par Ohcomand

Ici nous voyons donc que la ligne de "contenir" est référencé soit par Le numéro de la "ligne fixe", sois par le numéro de la "ligne GSM" ! Et de même pour Le numéro d’appel de "communication".

Deux clé étrangères sur une même colonne ne fonctionnent pas comme un "OU" mais bien comme un "ET".
Chaque valeur prise par la colonne doit bien être présente dans les deux tables à laquelle elle fait référence.

Si vous avez les numéros de ligne suivant : 1, 4, 9, 12
et les numéros de GSM suivant : 2, 3, 4, 9

La seule valeur possible dans la colonne Ligne de la table Contenir sera 9.
Tout autre valeur violerai au moins une des contraintes de clé étrangère.

Dans votre cas chaque association doit devenir une table comme ceci (clé primaire soulignées, clé étrangères en italique):
Groupe_LigneFixe(groupe, numLigne)
Groupe_LigneGSM(groupe, numLigne)

La démarche est la même pour les associations Consommer, à un petit détail près au niveau de la clé primaire.
Voyez ce sujet concernant la génération de table jointure pour les associations ayant des cardinalité 0,N et 0,1:
Passage MCD vers MLD. Créer la table jointure.

Je pense que vous devriez utiliser une colonne artificielle (sans signification) pour les clé primaires de vos tables Groupe et Communication. Une colonne de type entier dont les valeurs sont auto-incrémentées.

**CinePhil** · 04/05/2010, 11h59

Le MLD a t-il été généré automatiquement par le logiciel de modélisation ou est-ce votre interprétation du MCD ?

Dans le MCD, il y a deux associations distinctes appelées 'contenir', ce qui suppose qu'un groupe puisse être constitué à la fois de lignes fixes et de lignes GSM.
Les cardinalités (0,n - 1,n) de ces deux associations engendrent normalement deux tables associatives dont la clé primaire sera constituée des identifiants des tables participant à l'association :
Goupe_Contenir_Fixe (gcf_num_fixe, gcf_nom_groupe)
Groupe_Contenir_GSM (gcg_num_gsm, gcg_nom_groupe)

Au passage, vous devriez ajouter un identifiant anonyme de type entier car une colonne de type alphanumérique telle que nom_groupe ne constitue pas une bonne clé.

Les deux associations 'Consommer' ayant les cardinalités (0,1 - 0,n) devraient elles aussi engendrer deux tables associatives sur le même principe, de manière à éviter les clés étrangères nulles dans la table Communication.

En fait dans votre cas vous auriez peut-être intérêt à faire un héritage de Ligne vers Ligne_fixe et Ligne_GSM et d'associer Groupe et Communication à Ligne :
Ligne_fixe -(1,1)----Etre----0,1- Ligne -1,n----Contenir----0,n- Groupe
Ligne_GSM -(1,1)----Etre----0,1--| |----0,n----Consommer----1,1- Communication

Ce qui donnerait les tables :
Groupe (g_id, g_nom)
Ligne (l_id, l_numero)
Ligne_fixe (lf_id_ligne, lf_adresse, lf_cp, lf_id_ville, lf_libelle_adresse)
Ligne_GSM (lg_id_ligne, lg_numero_abonne, lg_nom_abonne)
Groupe_Contenir_Ligne (gcl_id_ligne, gcl_id_groupe)
Communication (c_id, c_id_ligne_appelante, c_numero_appele, c_date_heure, c_duree, c_destination, c_tarif, c_montant)

Remarques complémentaires :
1) J'ai mis dans la table Ligne_fixe une clé étrangère vers l'identifiant de la ville. Il vaut mieux externaliser les villes pour ne pas répéter 200 000 fois Toulouse ou 1000 fois Saint-Rémy-En-Bouzemont-Saint-Genest-Et-Isson !
2) Qu'est censée contenir la colonne lf_libelle_adresse ? Cela ne fait-il pas doublon avec l'ensemble des colonnes stockant l'adresse ?
3) Idem pour la colonne c_destination ?

**Ohcomand** · 04/05/2010, 13h56

Bonjour à vous tous : @omzo, Oishiiii, CinePhil et merci d’abord de vos réponses aussi rapide ! J’en ai été réellement surpris !
Bon je vais vous répondre à chacun dans l’ordre pour ne rien oublier même si ce n’est pas ce que j’ai retenu à la fin !

Tout d’abord @omzo

« Je crois que vous auriez dû avoir dans votre MLD deux tables "Contenir" (l'une en relation avec les tables Groupe et Ligne_Fixe et l'autre en relation entre Groupe et Ligne_GSM) si vous respectez les règles de traduction d'un MCD en MLD »

Oui mais dans ce cas il me semble largement préférable de faire une généralisation au niveau des lignes !

Mais le plus intéressant est ici :

« Dans ce cas comment pourriez-vous différencier une ligne fixe d'une ligne mobile dans votre future BDD? Ou mieux est ce possible qu'un champ d'une table référence deux champs de deux tables différentes? A mon avis, c'est non? »

C’est pour çà que je pose cette question en fait puisque une ligne fixe est facilement repérable par rapport à une ligne mobile (04 ou 06), donc ce MLD me paraissait convenable (et au plus simple).
De plus il me semblait ici que je ne faisais que sauter l’étape de la généralisation puisque celle-ci se fait entre guillemet dans la table « Contenir » et la table « Communication ».

Ensuite :

« Dans la table Communication aussi il devrait y avoir deux clés étrangères qui référencent respectivement les clés primaires des tables Ligne_Fixe et Ligne_GSM. »

Là par contre ce n’est pas possible parce qu’une communication est effectuée soit par une ligne fixe soit par une ligne mobile mais pas par les 2 à la fois

.

Et enfin pour la question sur la génération en sql de clé étrangère c’étais dans le cas présenté là

c'est-à-dire avec un attribut référencé par 2 colonnes issues de tables différentes si c’étais possible donc. Mais cela semble être en fait une erreur de conception.

=> Ici donc la généralisation semble être la meilleure chose à faire, merci donc à vous pour votre avis

.

Ensuite Oishiiii :

« Deux clé étrangères sur une même colonne ne fonctionnent pas comme un "OU" mais bien comme un "ET".
Chaque valeur prise par la colonne doit bien être présente dans les deux tables à laquelle elle fait référence. »

Donc cette règle par contre identifie correctement ce que je demandais et la réponse à la question

Et pour la suite c’est une solution j’entends bien mais alors la généralisation d’une ligne semble bien plus simple à mon gout notamment au niveau du nombre de table

.

=>Ici encore généralisation retenue, merci à vous aussi pour votre avis

.

Enfin CinePhil :

« Le MLD a t-il été généré automatiquement par le logiciel de modélisation ou est-ce votre interprétation du MCD ? »

C’est bien la mienne et c’est pour çà qu’il y a beaucoup de fautes

Et pour le reste bin vous m’avais mâché le boulot donc je n’ai rien à dire mis à part un grand merci !!

Enfin :

« 2) Qu'est censée contenir la colonne lf_libelle_adresse ? Cela ne fait-il pas doublon avec l'ensemble des colonnes stockant l'adresse ?
3) Idem pour la colonne c_destination ? »

Libellé de l’adresse est en fait par exemple pour une adresse « 1 rue Dupont » le libellé de l’adresse de l’adresse sera « école maternelle jules ferry » et je dis n’importe quoi mais voilà pour voir à quoi cela correspond donc il est nécessaire mais pourra être inclus dans la table des villes (et comme vous l’aviez dit vaut mieux l’externaliser)

=> Donc merci à vous pour cette réponse plus que suffisante

!

Je vais repartir donc sur un autre schéma avec la généralisation en prenant en compte toutes vos remarques et vous le soumettrais par la suite pour toutes remarques, objections, etc.
Merci encore de votre rapidité !

**Ohcomand** · 12/05/2010, 15h01

Voilà je tiens juste à vous préciser que je n'est pas encore poster mon nouveau schémas parce que j'attend de nouvelles données pour aussi analyser correctement la facturation des GSM

.

Je vais donc dire que ce topic est terminé

et je vous soumettrai mon schémas global dans un autre topic la semaine prochaine (Eh oui j'ai d'autres choses à faire avant notament un petit traitement de fichier CSV)...

Donc j'ouvrirai un autre sujet dans cette section pour pouvoir avoir le privilège d'avoir toutes vos remarques et conseils pour le futur schémas relationnel !

Merci et à bientôt, ce qui ne va pas tarder !