Validation MCD Telecom et les operateurs gestion des appels mobile

Version imprimable

03/08/2017, 14h35
beddiaf

1 pièce(s) jointe(s)

Validation MCD Telecom et les operateurs gestion des appels mobile

Salut à tous tous

voici mon sujet:

je travaille ds une sociète telecom qui voudrait automatiser les traitements de ses CDR(call data records) avec une appli qui gère les opérateurs pour les appels mobile.

la sociète telecom vend des acces (num tel ou bande passante ) à des op qui eux meme les distribue sur des users ).

l'objectif et de sortir les factures par opérateurs ayant signé un contrat avec la societe telecom nationale.

-gestion donc des numéros de tel par opérateurs ainsi que leurs facturation (facture par operateurs ,ensuite par client de cet operateur)

-sortir les factures payés et impaye (de chaque operateur /et des clients de cet operateur).

-faire un historique des factures dans la tab

pensez vous que c'est correcte comme mcd??? ou il manque des trucs car j'ai tjrs des doutes

voila j'espère avoir été clair,merci vraiment à la communauté .
cf piece jointe pour MCD

pour infos aussi voici le CDR que recoit telecom des CRPI create table IpPbxCDR (

CallId int not null,

OriginationNumber nvarchar(50) null,

OriginationName nvarchar(80) null,

CalledNumber nvarchar(50) null,

CalledName nvarchar(80) null,

DestinationNumber nvarchar(50) null,

DestinationName nvarchar(80) null,

StartTime datetime null,

ScriptConnectTime datetime null,

DeliveredTime datetime null,

ConnectTime datetime null,

EndTime datetime null,

Currency nvarchar(5) null,

Costs nvarchar(10) null,

State nvarchar(15) null,

PublicAccessPrefix char(1) null,

LCRProvider nvarchar(10) null,

ProjectNumber nvarchar(50) null,

AOC bit null,

OriginationDevice nvarchar(50) null,

DestinationDevice nvarchar(50) null,

TransferredByNumber nvarchar(50) null,

TransferredByName nvarchar(80) null,

TransferredCallId1 int null,

TransferredCallId2 int null,

TransferredToCallId int null,

TransferTime datetime,

DisconnectReason nvarchar(50),

MEMCallID int null

) on [PRIMARY]
04/08/2017, 14h09
escartefigue
Bonjour,

Ne soyez pas impatiente, d'une part c'est la période des congés d'autre part les contributeurs sont tous des bénévoles ;)

D'une façon générale :
- Vos règles de gestion sont très incomplètes, il est donc difficile de critiquer votre MCD
  Par exemple vous ne dites rien des entités-type ADMIN, ARCHIVE, REGLEMENT, APPEL et NUMERO
  Ce qui est sans doute évident pour vous ne l'est pas pour les lecteurs de votre sujet, à compléter donc (en identifiant les règles par un numéro, c'est plus facile pour en parler ensuite)
- Attention aux synonymes et faux amis, dans vos quelques règles de gestion vous parlez de client et dans votre MCD il n'y en a pas, par contre il y a une entité-type USER
  Si c'est la même chose il faut le préciser, et de préférence n'utiliser qu'un seul terme pour éviter les confusions
- Il ne doit jamais y avoir d'identifiant dans une relation, id_fact et id_appel n'ont donc rien à faire dans la relation "Produit", ces identifiants viendront naturellement dans les tables issues des relations quand vous génèrerez le MLD depuis le MCD
- l'attribut "nombre d'appels" de la relation "produit" est à la fois une colonne calculée et une redondance. Deux bonnes raisons pour le supprimer !
  Une redondance est un risque d'incohérence : si vous rattachez une nouvelle occurrence d'appel, ou supprimez un appel, vous êtes contraints de mettre à jour cet attribut, sinon il devient faux.
  Il suffit de compter le nombre d'appels en relation avec la facture pour connaitre cette valeur
Concernant les personnes
- Il faut des adresses en lien avec les personnes, sinon comment allez vous leur envoyer une facture pour celles qui veulent un envoi par la poste ?
- Une même personne doit pouvoir souscrire un abonnement chez plusieurs opérateurs différents.
- Il vous manque une notion d'abonnement qui vous permettra de gérer la personne de façon unique ainsi que ses adresses.
La bonne modélisation est donc :
[TYPE ADR] 0,n ---(Typer)---1,1 [ADRESSE] (1,1) --- (Adresser) --- 0,n [PERSONNE] 0,n --- Souscrire --- (1,1) ABONNEMENT (1,1) --- (Proposer) --- 1,n [OPERATEUR]
Notez les parenthèses autour de certaines cardinalités : c'est pour mettre en exergue l'identification relative (ex : adresse identifiée relativement à la personne)

Concernant les factures et les règlements :

Ce qui me surprend dans l'énoncé c'est que la société qui distribue les accès aux opérateurs, facture elle même les clients de ces opérateurs et encaisse les règlements de ces clients, c'est bien ça ?
Si c'est le cas, il faut donc un système de reversement d'une partie du règlement de la société de telecom vers les opérateurs, or vous n'en parlez pas
Si au contraire, le client final effectue son règlement directement à l'opérateur, alors comment savez vous quelle facture est payée et quelle autre ne l'est pas ?
04/08/2017, 15h14
beddiaf

1 pièce(s) jointe(s)

tt d'abord merci pour la réponse et les remarques pertinentes ;

concernant la table produit avec 2 fk je vais tacher de faire la modif .
idem pour la table abonnement (mais un abonnement possede id,nom, une duree et un tarif ) donc y'a t il pas incoherance logique avec la table tarif ?

ensuite pour repondre à votre question; c'est vrai qu'on paie l opérateur et non pas la sociète de telecom (d'ailleurs je sais pas comment faire à ce niveau )car je me suis basé sur les appels des users à facturer .
mais est il possible pour la societe telecom de sortir le mt total des appels passés par lui ainsi que de lui (operateur ) editer les factures .
04/08/2017, 15h54
beddiaf

3 pièce(s) jointe(s)

mcd avec correction

j'ai un pb pr envoyer en pièce jointe

Pour ADMIN, ARCHIVE, REGLEMENT, APPEL et NUMER
admin c'ete dans le cas d'un acces ecurise mais je vais le remlpacer par un espace de connexion (don je vais la supprimer
les archives c 'est pour archiver mes factures c'est important
les appels ce sont la masse d appels passant par telecom et qui lui sont transmises dans des fichiers appelles CDR call details records

la table numéro je l'avais rajoutter au cas ou un client peut avoir plusieurs numeros ??

concernant les adresses des clients ils sont dans la table client adr-rue et adr-ville,
autre question est ce c'est obligé de mettre les tables CLIENT ET FACTURE EN RELATION ?
enfin j'ai ajouter une relation entre operateur et facture (est ce que c'est ok?) pour avoir les factures de tel ou tel operateur ?
04/08/2017, 16h34
beddiaf

est ce que c'est bon ?
j'ai enleve l'entite admin
lier les tables operateur et factures
ainsi que client et facture
04/08/2017, 16h45
escartefigue

Le plus important est de commencer par bien énumérer les règles de gestion sous la forme
- R001 : un client est une personne qui a souscrit au moins un abonnement auprès d'un opérateur
- R002 : un opérateur peut fournir un ou plusieurs abonnement à un client
- R003 etc..
avec "peut" qui implique une cardinalité mini zéro, "doit" qui implique mini 1, au moins qui implique un maxi de n, et enfin un seul qui implique un maxi 1

Sauf erreur de ma part, tout abonnement comporte le n° de téléphone en attribut, l'entité-type numéro n'a donc pas de raison d'être. Les appels sont passés par une personne au titre de son abonnement.

Attention, au niveau MCD il ne faut pas parler de TABLES, mais d'entité-type (vos rectangles) et de relations ou associations (les ovales).
04/08/2017, 17h53
beddiaf

2 pièce(s) jointe(s)

milles merci ,au moins on à l impression d'avancer
"Sauf erreur de ma part, tout abonnement comporte le n° de téléphone en attribut, l'entité-type numéro n'a donc pas de raison d'être. Les appels sont passés par une personne au titre de son abonnement."
bref j'ai supp client maintenant c'est l abonnement qui effectue des appels

Pour "Le plus important est de commencer par bien énumérer les règles de gestion sous la forme
- R001 : un client est une personne qui a souscrit au moins un abonnement auprès d'un opérateur
- R002 : un opérateur peut fournir un ou plusieurs abonnement à un client
- R003 etc..
avec "peut" qui implique une cardinalité mini zéro, "doit" qui implique mini 1, au moins qui implique un maxi de n, et enfin un seul qui implique un maxi 1"
je n'ai pas d'ennoncé on à comme base de travaille le fichier CDR généré par d'autres equipements!! et c'est tout

et merci pour "Attention, au niveau MCD il ne faut pas parler de TABLES, mais d'entité-type (vos rectangles) et de relations ou associations (les ovales)."

ceci dit l entite abonnement je me pose plus de questions avec le volume d 'appels (en temps) et les prefixes utilises (national ,international,06,07,08):
donc est ce que je dois lier l entite abonnement à tarif ?
et ou je dois inclure la propriete volume d 'appels (en temps) entre appels et facture c'est a dire dans produit
ou entre appels et tarif dans soumis
04/08/2017, 20h00
escartefigue

Citation:

Envoyé par beddiaf

je n'ai pas d'ennoncé on à comme base de travaille le fichier CDR généré par d'autres equipements!! et c'est tout

Et bien c'est très très insuffisant !
Le MCD c'est comme les fondations d'une maison, s'il est mal fait alors la base de donnée sera mal faite, et tout va en pâtir : intégrité des données, fiabilité des résultats, performances des traitements et bien sur satisfaction du donneur d'ordre, qui ne manquera pas de vous blâmer.
Exigez des règles de gestion précises, validées et signées sans lesquelles vous allez vous engouffrer dans une impasse, et vous le payerez cash vos utilisateurs aussi !

Citation:

Envoyé par beddiaf

ceci dit l entite abonnement je me pose plus de questions avec le volume d 'appels (en temps) et les prefixes utilises (national ,international,06,07,08):
donc est ce que je dois lier l entite abonnement à tarif ?

Là aussi, c'est à votre maitrise d'ouvrage de fournir les règles de gestion. Désolé je me répète mais c'est un fait incontournable.

Après ça je me déclare officiellement en WE, je ne garantis donc pas de réponse d'ici lundi, sauf si je m'ennuies fort :mrgreen: ce qui vous laisse du temps pour rédiger les premières règles de gestion ;)
04/08/2017, 21h09
beddiaf

ah Vraiment ca fait mal
ça fait tres tres mal
05/08/2017, 11h16
beddiaf

1 pièce(s) jointe(s)

juste pour infos

pour continuer la discussion voici mon nv mcd

pour les regls de gestion:
un operateur souscrit un contrat chez ftelecom
un operateur offre des abonnement avec une( duree incluse d'appels et des prefix inclus ) aux clients.
un abonnement coresspond a une ou plusieurs factures.
un appel contient (id,num appellant,num appelle,duree)
le cout/min de l'appel est calcule en fonction du prefix et de l'operateur.

j'espère que c'est bon :lol:
05/08/2017, 13h15
escartefigue

Bonjour,

Je fais une petite entorse à ma pause du WE :D

Vous pouvez utiliser le bouton "répondre avec citation" en bas à droite pour conserver tout ou partie des messages des contributeurs ;)
Il vaut mieux ne pas citer en totalité mais seulement les extraits sur lesquels vous voulez réagir. Pour ce faire, supprimez le texte inutile en prenant soin de conserver les balises de début et de fin.

Dans votre MCD il manque le type des attributs, leur longueur et le caractère obligatoire ou non.

Pour les règles de gestion, il faut à minima 1 règle par patte de chaque relation donc il vous en manque encore beaucoup.
Par exemple pour la relation entre opérateur et tarif, on pourrait écrire :
R020 : un opérateur applique au moins un tarif
R021 : un tarif ne concerne qu'un et un seul opérateur.
Ce qui donne l'extrait de MCD suivant
[OPERATEUR] 1,n --- Appliquer --- 1,1 [TARIF]
Dans votre MCD vous avez mis une cardinalité 0,n coté opérateur, ce qui signifie que certains opérateurs n'ont pas de tarif :weird: :aie: Sympa le téléphone gratuit :P

Bon courage pour la suite et bon we :)
05/08/2017, 16h32
beddiaf

[QUOTE=escartefigue;9512979]Bonjour,

Je fais une petite entorse à ma pause du WE :D
merciii:ptdr:

R020 : un opérateur applique au moins un tarif
R021 : un tarif ne concerne qu'un et un seul opérateur.
Ce qui donne l'extrait de MCD suivant
[OPERATEUR] 1,n --- Appliquer --- 1,1 [TARIF]
Dans votre MCD vous avez mis une cardinalité 0,n coté opérateur, ce qui signifie que certains opérateurs n'ont pas de tarif :weird: :aie: Sympa le téléphone gratuit :P

ok je vais rectifier cela ,je travaille sur power amc ,il me dit circularite entre operateur abonnement appel et tarif (est ce que c'est grave?)
faut il supprimer le lien entre appels et tarif? (donc je serais obligee de passer par des jointures entre tables plus tard! )
06/08/2017, 11h31
JPhi33

Bonjour beddiaf (Manon ?),

Citation:

Envoyé par beddiaf

ok je vais rectifier cela ,je travaille sur power amc ,il me dit circularite entre operateur abonnement appel et tarif (est ce que c'est grave?)
faut il supprimer le lien entre appels et tarif? (donc je serais obligee de passer par des jointures entre tables plus tard! )

Je ne vois pas de circularité entre Operateur, Abonnement, Appel et Tarif.
Cependant, l'opérateur lié à un appel via Abonnement peut être différent de l'opérateur lié à un appel via Tarif. C'est peut-être ce qui gêne PowerAMC.

Autre point : du fait de l'identification relative de Tarif par rapport à Prefixe (au singulier !) d'une part, et par rapport à Operateur d'autre part, induira l'identification de la table issue de l'entité Tarif au moyen des clés primaires de Prefixe et Operateur. Par conséquent, les propriétés num_op et id_prefix sont superflues dans l'entité Tarif et doivent en être éliminées. Sinon, la table Tarif sera :

Tarif (id_op, id_prefixe, num_op, id_prefix, cout_min)
06/08/2017, 11h46
beddiaf

1 pièce(s) jointe(s)

Citation:

Envoyé par JPhi33

Bonjour beddiaf (Manon ?),

Je ne vois pas de circularité entre Operateur, Abonnement, Appel et Tarif.
Cependant, l'opérateur lié à un appel via Abonnement peut être différent de l'opérateur lié à un appel via Tarif. C'est peut-être ce qui gêne PowerAMC.

Autre point : du fait de l'identification relative de Tarif par rapport à Prefixe (au singulier !) d'une part, et par rapport à Operateur d'autre part, induira l'identification de la table issue de l'entité Tarif au moyen des clés primaires de Prefixe et Operateur. Par conséquent, les propriétés num_op et id_prefix sont superflues dans l'entité Tarif et doivent en être éliminées. Sinon, la table Tarif sera :

Tarif (id_op, id_prefixe, num_op, id_prefix, cout_min)

tt d'abord merci de votre réactivité,j'ai eu une coupure internet depuis hier,c'est affreux la qualite de service ici
enfin la table sur mysql est bien :
Tarif (id_op, id_prefixe, cout_min) ayant pour deux cles etrangères (id_op, id_prefixe)

j'ai pas bien saisi l'explication de la circularite sur le dessin mcd il y'a bien un cercle?

autre question est ce que je peux mettre l'attribut paye(bool 0/1) dans la relation paye entre facture et reglement? ou la date suffit ?
07/08/2017, 13h54
escartefigue

Bonjour Beddiaf

Le WE est fini :? ;)

Citation:

Envoyé par beddiaf

j'ai pas bien saisi l'explication de la circularite sur le dessin mcd il y'a bien un cercle?

Tout comme Jphi33 je ne vois aucun cycle dans votre MCD, de toutes façon si cycle il y avait, la warning au niveau MCD deviendrait une erreur bloquante au niveau MLD
Exemple de cycle (bloquant donc) ce serait le modèle suivant :
[ENTITE-1] 0,n --- (Relation1) --- 1,1 [ENTITE2] 0,n--- (Relation2)--- 1,1 [ENTITE3] 0,n ---(relation3) --- 1,1[ENTITE1]
Avec un tel modèle, la suppression ou MàJ d'une occurrence de E1 provoque la suppression ou MàJ des E2 liées, puis E3 puis ... E1 ! la boucle est bouclée

Citation:

Envoyé par beddiaf

autre question est ce que je peux mettre l'attribut paye(bool 0/1) dans la relation paye entre facture et règlement? ou la date suffit ?

Quel serait l'usage de ce booléen ? S'il s'agit de signifier que la facture est payée, alors il est préférable d'utiliser un attribut dans l'ET facture, et permettant plusieurs valeurs

Concernant la facturation :
vous autorisez plusieurs règlements pour une facture, mais pas plusieurs factures pour un règlement, que se passe-t-il si un client paye ses 2 dernières factures avec un seul chèque ou virement ?
Il est plus prudent d'avoir un attribut pour identifier la devise de facturation : ça vous permet une facturation multidevise si souhaité et/ou un changement de devise le cas échéant (ex : retour au franc souhaité par certains :roll:). Code devise à ajouter également dans le règlement.

Concernant la tarification :
Dans votre dernier MCD, vous avez supprimé l'ET "TARIF"
Si on en croit cette nouvelle version, le coût à la minute dépend notamment de l'appel et donc de l'abonnement et donc de l'abonné, soit un prix à la tête du client :weird:
Dans la version précédente, le coût ne dépendait que de l'opérateur et du préfixe, ça semblait plus équitable ;)
C'est sans doute pour ca que vous avez un attribut prix dans l'ET abonnement ? à supprimer en ce cas (sauf bien sur si chaque abonné a la latitude pour négocier son tarif par rapport à un tarif de base, mais ça m'étonnerait beaucoup ;))

Concernant les users :
Le terme "Abonné" me semble plus adéquat
Il faut externaliser l'adresse : [ABONNE] 0,n --- (Adresser) --- (1,1) ADRESSE
Ainsi vous pourrez gérer 0 à n adresses par abonné

Concernant les opérateurs :
Que sont les attributs AdresR_OP et AdresV_OP ?
07/08/2017, 15h37
JPhi33

Bonjour beddiaf et escartefigue,

Citation:

Envoyé par beddiaf

autre question est ce que je peux mettre l'attribut paye(bool 0/1) dans la relation paye entre facture et reglement? ou la date suffit ?

Ce qui indique qu'une facture est réglée c'est la cardinalité 0,1 de la patte [ Facture ]---( paye ).

Lorsqu'elle vaut 0, aucune occurrence de Réglement n'est liée à l'occurrence de Facture. Par conséquent la facture n'est pas payée.
Lorsqu'elle vaut 1, une occurrence (et une seule) de Réglement est liée à l'occurrence de Facture. Et donc, la facture est payée.
La propriété date_regl peut rester dans l'association "paye" ou migrer dans l'entité Réglement.

Concernant l'association "tarification" de ta nouvelle version du MCD :

Une association ternaire ne peut pas contenir une patte de cardinalités 1,1 faute de quoi, au niveau logique, les tables résultantes seront liées par un lien 1,1 des deux côtés. En l'occurrence, le résultat serait qu'une ligne de la table Tarification ne pourrait être liée qu'à une seule ligne de la table Appel. Or, selon ton précédent MCD, une tarification peut concerner plusieurs appels.

Deux solutions :
1. La patte [ Appel ]---( tarification ) de cardinalité 1,1 doit être décomposée en deux associations :

[ Appel ]--1,1----( )----0,n--[ Préfixe ]
[ Appel ]--1,1----( )----0,n--[ Operateur ]

2. Si tu dois associer chaque occurrence de Appel à un couple {Préfixe, Operateur} existant, alors il faut en revenir au précédent schéma.
07/08/2017, 21h38
beddiaf

Reponse à escartefigue

Citation:

Envoyé par escartefigue

Bonjour Beddiaf

Le WE est fini :? ;)

Tout comme Jphi33 je ne vois aucun cycle dans votre MCD, de toutes façon si cycle il y avait, la warning au niveau MCD deviendrait une erreur bloquante au niveau MLD
Exemple de cycle (bloquant donc) ce serait le modèle suivant :
[ENTITE-1] 0,n --- (Relation1) --- 1,1 [ENTITE2] 0,n--- (Relation2)--- 1,1 [ENTITE3] 0,n ---(relation3) --- 1,1[ENTITE1]
Avec un tel modèle, la suppression ou MàJ d'une occurrence de E1 provoque la suppression ou MàJ des E2 liées, puis E3 puis ... E1 ! la boucle est bouclée
Merci à tt la je comprends mieux que dans un cours

Quel serait l'usage de ce booléen ? S'il s'agit de signifier que la facture est payée, alors il est préférable d'utiliser un attribut dans l'ET facture, et permettant plusieurs valeurs
Concernant la facturation :
vous autorisez plusieurs règlements pour une facture, mais pas plusieurs factures pour un règlement, que se passe-t-il si un client paye ses 2 dernières factures avec un seul chèque ou virement ?
donc si je comprends bien : ça deviendrait Reglement( 1,n)-----(paye) -----(0,1)Factures

Il est plus prudent d'avoir un attribut pour identifier la devise de facturation : ça vous permet une facturation multidevise si souhaité et/ou un changement de devise le cas échéant (ex : retour au franc souhaité par certains :roll:). Code devise à ajouter également dans le règlement.
ca c'est fait j'ai ajoute monnaie juste pour vous faire plaisir!:ptdr:

Concernant la tarification :
Dans votre dernier MCD, vous avez supprimé l'ET "TARIF"
Si on en croit cette nouvelle version, le coût à la minute dépend notamment de l'appel et donc de l'abonnement et donc de l'abonné, soit un prix à la tête du client :weird:
Dans la version précédente,fix le coût ne dépendait que de l'opérateur et du prée, ça semblait plus équitable ;)
C'est sans doute pour ca que vous avez un attribut prix dans l'ET abonnement ? à supprimer en ce cas (sauf bien sur si chaque abonné a la latitude pour négocier son tarif par rapport à un tarif de base, mais ça m'étonnerait beaucoup ;))
Effectivement le cout depends de sa duree(dans L ENTITE appels) du prefix et de l 'operateur :

exemple :
un appel de sfr vers sfr coute 10€/min
un appel de sfr vers free coute 20€/min
un appel de sfr vers argentine coute 100€/min
un appel de free vers sfr coute 200€/min
et c'est rectifie avec la table tarif entre operateur et prefix.

Concernant les users :
Le terme "Abonné" me semble plus adéquat
Il faut externaliser l'adresse : [ABONNE] 0,n --- (Adresser) --- (1,1) ADRESSE
Ainsi vous pourrez gérer 0 à n adresses par abonné

le pb est que j'ai deja cree mes tables et inserer des donnes la dans donc pour client( id_clt ,,,) faut que je change tt abonnee( id_abonne ,,) ca va faire bq
d'ailleurs en voulant remmetre la table tarif c'est a dire remmetre (les FK :id_prefix ,id operateur )dans appels qui est pleine de clients phpmyadmin me dit #1452 - Cannot add or update a child row: a foreign key constraint fails (`bdappels`.<result 2 when explaining filename '#sql-3d8_2a1'>, CONSTRAINT `#sql-3d8_2a1_ibfk_1` FOREIGN KEY (`FKID_OP`) REFERENCES `prefixes` (`ID_PREFIX`))
,meme en changeant fkid_op il veut pas et en les mettant à default null Concernant les opérateurs :
Que sont les attributs AdresR_OP et AdresV_OP ?

ce sont adresse rue et adresse ville operateur , mais c'est bon j'ai mis une table adresse apres vos conseils toi et PHIL

milles &milles merci encore je commence à saisir des termes oublies (depuis 15 ans mini)
07/08/2017, 22h22
beddiaf

2 pièce(s) jointe(s)

Citation:

Envoyé par JPhi33

Bonjour JPhi33

Ce qui indique qu'une facture est réglée c'est la cardinalité 0,1 de la patte [ Facture ]---( paye ).
Vraiment tu sais pas quelle lumière tu viens de m'apporter merci j'ai bien saisi
Lorsqu'elle vaut 0, aucune occurrence de Réglement n'est liée à l'occurrence de Facture. Par conséquent la facture n'est pas payée.
Lorsqu'elle vaut 1, une occurrence (et une seule) de Réglement est liée à l'occurrence de Facture. Et donc, la facture est payée.
La propriété date_regl peut rester dans l'association "paye" ou migrer dans l'entité Réglement.
c'est fait:date_regl est maintenant dans l entite Reglements
Concernant l'association "tarification" de ta nouvelle version du MCD :
Une association ternaire ne peut pas contenir une patte de cardinalités 1,1 faute de quoi, au niveau logique, les tables résultantes seront liées par un lien 1,1 des deux côtés. En l'occurrence, le résultat serait qu'une ligne de la table Tarification ne pourrait être liée qu'à une seule ligne de la table Appel. Or, selon ton précédent MCD, une tarification peut concerner plusieurs appels.
[B]Encore milles merci ça me torturé le cerveau cette relation maintenant je sais que ça ne peut pas

Deux solutions :
1. La patte [ Appel ]---( tarification ) de cardinalité 1,1 doit être décomposée en deux associations :

[ Appel ]--1,1----( )----0,n--[ Préfixe ]
[ Appel ]--1,1----( )----0,n--[ Operateur ]

2. Si tu dois associer chaque occurrence de Appel à un couple {Préfixe, Operateur} existant, alors il faut en revenir au précédent schéma.

j'ai remis l'entite tarif entre operateur et prefix ,comme je l"ai dit

un appel sfr vers prefix sfr n'est pas au meme prix qu'un
un appel sfr vers prefix lycamobile n'est pas au meme prix qu'un et aussi
un appel sfr vers prefix chili n'est pas au meme prix qu'un
un appel lycamobile vers chili
pour inserer les donnes c'est plus simple dans l entite tarif (id_op,id_prefix,cout_min) que d'utiliser
[ Appel ]--1,1----( )----0,n--[ Préfixe ]
[ Appel ]--1,1----( )----0,n--[ Operateur ]

Voila tt encore milles merci pour vos lumières ,je vous joints mon nv MCD
pardon power amc à bugger du coup il à pas pris en compte mes modifs voila donc le nv mcd
d'ailleurs je peux pas generer de MLD il me dit :
lien asso :facture-lie-reglement-paye
lien asso :appel passee abonnement offre
lien asso :operateur offre
lien asso :tarif applique
lien asso: prefix ???
et les 2 erreurs sur identifiant d entite adresse.id adresse et contrat id contrat
(pour info j'ai ajoute la table contrat d'un operateur avec ftelecom,car au debut j ai mis just un champs nom_contrat dans la table operateur(pensant que c'etait unitile)

d'ailleurs y'a pas un truc qui cloche pour facturer les appels ?(faut il un lien entre facture et appels ou facture et operateur?

Resolu pour et les 2 erreurs sur identifiant d entite adresse.id adresse et contrat id contrat
faut aller sur les propriete de lentite ensuite les proprietes de lid primaire là on se trouve dans l'onglet general tt en bas faut cocher cle primaire.Merci
me reste les avertissements existence d'identifiant sur l entite tarif
et encore et toujours la circularite
08/08/2017, 14h53
JPhi33

Citation:

Envoyé par beddiaf

me reste les avertissements existence d'identifiant sur l entite tarif

C'est normal qu'il y ait un avertissement, vu que l'entité Tarif n'a pas d'identifiant.
Tarif est en réalité une association modélisée sous forme de pseudo-entité pour permettre l'association avec Appel.
Dans ton dernier MCD, l'association entre Tarif et Appel n'existe plus. Par conséquent, tu peux transformer Tarif en association et ainsi éliminer l'avertissement.

Citation:

Envoyé par beddiaf

et encore et toujours la circularite

Dans PowerAMC, lorsqu'on supprime un objet (entité, association ou patte), il y a normalement une fenêtre qui demande si on veut effacer ou supprimer. Si on n'y prête pas garde, il est possible de simplement effacer l'objet sans pour autant le supprimer. Il faudrait vérifier que des objets que tu aurais voulu supprimer ne sont pas simplement effacés du schéma et donc provoqueraient cette circularité indétectable de visu.
08/08/2017, 16h20
beddiaf

Citation:

Envoyé par JPhi33

C'est normal qu'il y ait un avertissement, vu que l'entité Tarif n'a pas d'identifiant.
Tarif est en réalité une association modélisée sous forme de pseudo-entité pour permettre l'association avec Appel.
Dans ton dernier MCD, l'association entre Tarif et Appel n'existe plus. Par conséquent, tu peux transformer Tarif en association et ainsi éliminer l'avertissement.

Mecri pour votre réactivite ,donc c'est bon mon mcd est validé?8O8O8O

Dans PowerAMC, lorsqu'on supprime un objet (entité, association ou patte), il y a normalement une fenêtre qui demande si on veut effacer ou supprimer. Si on n'y prête pas garde, il est possible de simplement effacer l'objet sans pour autant le supprimer. Il faudrait vérifier que des objets que tu aurais voulu supprimer ne sont pas simplement effacés du schéma et donc provoqueraient cette circularité indétectable de visu.