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
). Code devise à ajouter également dans le règlement.
ca c'est fait j'ai ajoute monnaie juste pour vous faire plaisir!
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
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 ?
Partager