Discussion :

[scofield]

Bonjour, *oracle db 9i , developer 10g*
J'ai une table livraison véhicule chez un concessionnaire qui contient

num_liv,num_fact,num_matr,num_serie,type_liv,Observat,num_acess(plusieur), num_papier (5)

les tables accessoire et papier contiennent une colonne état qui informe sur (état pap/accesoire livré/non)
Comme règle une livraison a plusieurs accessoires, et 5 papiers définitifs(douane,acte vente..etc) cardinalité 1..n et 1..5

Je doit créer une vue , englobant ces attributs + ceux de véhicule et de client(depuis la clé facture).

Mais , avant ça, j'ai un problème concernant les accessoires et les papiers
car chaque véhicule a ses accessoires de bord/additionnel (pas tout le temps les même avec les autres) et comme j'ai pas de liste distincte pour chaque vehicule, j'ai décider de mettre ça en semi-auto

C'est à dire que pour chaque livraison Véhicule les accessoires seront saisis avec leurs états pour le suivi, ce qui induit une redondance de données dans accessoire à chaque occurrence de livraison.

Sachant aussi que la possibilité de saisir de nouveaux accessoires doit être permise, et qu'avec les accessoires communs préexistants dans la table accessoire la colonne état n'est pas a sa place peut prendre qu'une seule valeur (livré /non) éclatement.

Y aurait il une solution ou une quelconque suggestion??

TABLES >>ACCESSOIRE

Accessoire (num_access NUMBER NOT NULL,
des_acces VARCHAR2(20 byte),etat_ac varchar2(20),
CONSTRAINT pk_acc PRIMARY KEY(num_access)

PAPIER

papier_def (code_pap VARCHAR2(20 byte)
NOT NULL, des_pap VARCHAR2(20 byte),
CONSTRAINT pk_pap PRIMARY KEY(code_pap)

[JPhi33]

Donc, si je comprends bien :

car chaque véhicule a ses accessoire de bord/additionnel(pas tout le temps les même avec les autres)

==> chaque véhicule a ses accessoires

et comme j'ai pas de liste distinct pour chaque vehicule .

==> tu n'as pas la liste des accessoires pour chaque véhicule


C'est un peu contradictoire, non ?

[scofield]

bonjour,
c'est a peu pres ça .
contradictoire peut être bien, mais quand tu as affaire au concessionnaire du coin de la rue, c'est pas trop évident de voir l'organisation.

C'est pour un projet de fin d'étude (application a la clé): et ces gens ne se casseront pas la tte pour moi . Surtout si mon binome, et ma promotrice font de même (dernier délai pour la fac 20 novembre sinon je perd un an)

bref , trêve de balivernes.
je pourrai faire un tour a la maison mère si le service info daigne me recevoir, ou me communiquer des infos.
Pour l'option semi auto, ça sera pour chaque véhicule de la commande bien sur

Merci beaucoup

[JPhi33]

Bonjour,

Je continue avec mes questions. Désolé, mais si tu veux de l'aide, il va falloir être un peu plus explicite.

J'ai une table livraison véhicule chez un concessionnaire qui contient

num_liv,num_fact,num_matr,num_serie,type_liv,Observat,num_acess(plusieur), num_papier (5)

Aurais-tu le script de définition de la table (CREATE TABLE ...) afin de comprendre comment tu matérialises le "(plusieur)" après "num_acces" et le "(5)" après "num_papier" ?

Mais , avant ça , j'ai un probleme concernant les accessoires et les papiers:
car chaque véhicule a ses accessoire de bord/additionnel(pas tout le temps les même avec les autres) et comme j'ai pas de liste distinct pour chaque vehicule .j'ai décider de mettre ça en semi-auto

Peux-tu donner quelques exemples d'accessoires ? Juste histoire de savoir s'il s'agit de TYPES D'ACCESSOIRES.
Que signifie "pas tout le temps les même avec les autres" ? Avec les autres quoi ? Accessoires ? Véhicules ? Livraisons ?
Qu'entends-tu exactement par "mettre ça en semi-auto" ? Mettre ça quoi ? Et que signifie semi-auto ?

C.a.D ,que pour chaque livraison Véhicule les accessoires seront saisies avec leurs états
(livre/non) pour le suivie . ce qui induirait une redondance de donnés dans accessoire a chaque occurrence de livraison.

Qui a des accessoires ? C'est le véhicule ou c'est la livraison ?

Sachant aussi , que la possibilité de saisir de nouveaux accessoires doit être permise.
Et qu'avec les accessoires commun préexistants dans la table accessoire la colonne état n'est pas a sa place (peut prendre qu'une seule valeur (livré /non)éclatement.

Bon, là j'ai compris : il y a des accessoires communs préexistants et on doit pouvoir saisir de nouveaux accessoires. Mais je ne vois pas bien le rapport avec le placement de la colonne état.

Y aurait il une solution ou une quelconque suggestion??

Tout problème a au moins une solution... pour peu qu'on ait compris le problème !

[scofield]

salut ,
premièrement désole de vous embarquer tous dans ma confusion !
mais sachez que quand un développeur(newbie) descend de sa bécane (pc) pour revenir au stylo et au papier après 8 mois de conception ça fout les boule.
je reste calme d'ailleurs

1- Script total de la base de donnée ci-joint
les tables touchées par cet imbroglio sont commande_vehicule et livraison (+facture évidemment). pour le 5 et le plusieurs c'est du coté data (contenu) ça pourrait affecter les prochaine vues à créer c'est tout

2-Les accessoires EXEMPLE:
voiture1 toyota ..disont yaris (access :Radio k7, allume cigare ../cric..)
voiture2 toyota ..corola (acces : radio cd,accessoire promotionnel "portable,mp3 etc ../cric ..).
si la catégorie n'est pas très proche (camion et citadine) les accessoires peuvent être légèrements differents.
tout dépend de la référence du véhicule son genre/catégorie .

"pas tout le temps les même avec les autres" ?

Avec les autres Véhicules .

-Semi auto, avant c'était pour me débarrasser de la contrainte accessoire (répertoriage et classification unique ), je veux dire si j'ai pas de liste d'accessoires au préalable, je les laisse se débrouiller . Quitte à perdre de l'espace avec des redondances. M'enfin, c'est loin d'être tranché .
-Le véhicule a des accessoires (comme j'étais sur oracle forms je m'exprime plus en regardant l'application) mais il seront saisis dans la fenêtre livraison (il n'y a pas de liste concrète).

-La colonne état : sert a informer si l'accessoire en question est livré ou pas depuis la maison mere! (suivi).
donc si je ne peux pas répertorier les accessoires par véhicule, il faudrait juste les saisir le jour de la facture ou de la livraison. (*un accesoire ne peut prendre plusieurs états même si ce dernier est commun à plusieurs vehicules)

Merci

PS: j'avais même pensé a arrêter les études (après 6ans) alors que c'était une question de mois! poor ME !.

[JPhi33]

Bon, ça y est, en regardant ta base de données, j'ai compris tes problèmes (oui, tu en as plusieurs).

1) Ta base dit "pour une livraison_v, il y a 1 Accessoire". C'est évidemment faux, puisque pour chaque livraison il peut y avoir plusieurs accessoires. C'est la même chose pour les papiers.

2) J'ai l'impression que tu confonds un type d'accessoire (radio K7, radio CD, allume-cigare, cric, etc.) avec un accessoire physique : l'allume-cigare livré sur le véhicule Toyota Corolla de M. Machin le 25/09/2007, n° de livraison 3216498.

3) L'état de l'accessoire (ou du papier) ne peut être associé qu'à un accessoire (ou papier) physique et non pas à un type d'accessoire.

Voici comment modéliser ces règles :

A toi de traduire cette modélisation dans ta base.

4) Les accessoires non répertoriés au préalable est un faux problème. Rien ne t'empêche d'autoriser l'utilisateur à créer un nouvel accessoire dans la table Accessoire au moment où il en a connaissance. Il pourra peut-être servir pour un autre véhicule plus tard.

JPhi33

[scofield]

Salut,
Effectivement ca a l’air faisable avec deux nouvelles relations (tables) "access_liv et pap_liv’".

Mais seulement, dans mon modèle j’ai un problème qui a supplanté le précedent.
C'est-à-dire que la commande jusque là ne pouvait contenir qu’un seul véhicule. Et comme dans une commande il y en a plusieurs je crois bien, qu’il faut éclater la table commande véhicule en deux pour séparer les véhicules de la commande
(tables «detail_commande»), et avoir ainsi une cardinalité 1..n entre (comd et véhicule).

L'os se situe avec les règlements ; la vue ‘’[COLOR="Red"]fich_commande.
Je voudrais avoir dans règlement : le versement, et la somme restante déduit du prix globale de tous les véhicules de la commande (ce que je n’arrive pas a extraire).

C’est faisable ? Après ca, à la facturation un numéro de série et Matricule sera attribué à chaque véhicule de la commande (dans detail_commande).
(Je parle encore application).


Il ira de soi, que les accessoires et les papiers seront insérés pour chaque véhicule
(liaison avec «detail_commande», des tables acces_liv, pap_liv).

D’où le souci de règler d’abord le problème de la commande ! Dont j’avais posté un sujet dans le forum SQL.
Désolé d’en parler que maintenant


Voici à peu près ce que ca pourrait donner ICI

[JPhi33]

Effectivement ca a l’aire faisable .avec deux nouvelles relation (tables) "access_liv et pap_liv’".

Je ne suis pas d'accord. D'après les informations que tu as décrites, ça n'a pas l'air faisable, c'est carrément obligatoire.

Mais seulement, dans mon model j’ai un problème qui a supplanter le précedent, quand a la chronologie.
C'est-à-dire que la commande jusque la, pouvait contenir qu’un seule véhicule. Et comme dans une commande il y en a plusieurs.
Je crois bien, qu’il faut éclater la table commande véhicule en deux .pour s éparer les véhicule de la commande
(tables « detail_commande »), et avoir ainsi une cardinalité 1..n entre (comd et véhicule).

[...]

C’est faisable ?après ca, à la facturation un numéro de série et Matricule sera attribué à chaque véhicule
de la commande (dans detail_commande). (J parle encore application).

Oui effectivement, si un client peut commander plusieurs véhicules dans la même commande, tu peux modéliser comme sur ton MCD. On peut quand même remarquer plusieurs choses.

Ce que tu appelles VEHICULE semble être en fait un modèle de véhicule. Il s'agit de la même confusion entre le type et l'instance du type que je t'avais fait remarquer pour les accessoires et les papiers. Le client commande UNE Toyota Yaris rouge, pas LA Toyota Yaris rouge dont le numéro de série est XYZT1234. Donc le client commande un modèle de véhicule et on lui livre un véhicule.

Partant de là, ton détail de commande devrait être une association entre la commande et le modèle de véhicule :


[ Commande véhicule ]--1,n----( Regrouper )----0,n--[ Modèle véhicule ]


De plus, le détail de commande ne devrait pas comporter d'information comme "num_seri" (si c'est bien le numéro de série du véhicule). Il s'agit d'informations qu'on ne peut pas connaître avant la livraison.

La livraison, justement, concerne des Véhicules, pas des modèles de véhicules (comme je l'ai dit plus haut). Je te laisse le soin de trouver comment relier Livraison et Véhicule aux autres entités (là, c'est facile !)

*****Il ira de soi, que les accessoires et les papiers, seront insérés pour chaque véhicule
(liaison avec « detail_commande », des tables acces_liv, pap_liv).

Pose-toi cette simple question : les accessoires sont-ils commandés, livrés, ou les deux ? Idem pour les papiers.

Bonne fin de travail !

PS : J'ai travaillé plusieurs heures sur le script de ta base de données pour établir le MCD (rétro-conception) mais je n'y suis pas parvenu étant donné qu'il manque de nombreuses références entre tables (clés étrangères). Attention, la base risque de ne pas fonctionner comme tu le supposes.


JPhi33

[scofield]

salut,
tout d'abord je suis sincèrement désole de t'avoir fait absorber ton temps sur mon script. cela étant causé par un remaniement (modification) irrégulier sur la structure de la base (ma prof ma gracieusement aidé a faire un modèle immonde ,ce qui ma poussé a adapter sans lui redonner puisque elle va le foutre en l'aire une eniem fois) .
-les références dépendent assez du fond.
en conséquences c'est en résolvant ces quiproquo que les attributs et autres références paraîtrons évident (selon moi).
-

Partant de là, ton détail de commande devrait être une association entre la commande et le modèle de véhicule :

[ Commande véhicule ]--1,n----( Regrouper )----0,n--[ Modèle véhicule ]

cela est bien une association ,le nom étant juste une description (detail _ com ou regrouper , cela ne me pose aucun probleme).
par contre la ou je veut faire la différence.

Donc le client commande un modèle de véhicule et on lui livre un véhicule.
le détail de commande ne devrait pas comporter d'information comme "num_seri"
-La livraison, justement, concerne des Véhicules, pas des modèles de véhicules (comme je l'ai dit plus haut).

faire une relation entre véhicule et livraison aussi mettre les numéro de série dans une autre structure causerais un surplus de table dans ma base (déjà 26)
et comme dans mon application c'est des vue qui sont sensé récupérer les info , j'aurais donc plusieurs relation type (tripette).
en d'autres terme :je ne pourrait m'engouffrer dans ces entrelacement acrobatique pour récupérer, le numéro de série, accessoires et papier de chaque véhicule y compris le totale de la somme versé. déduit du montant globale(tout les véhicules ) ,correspondant a la commande.

C'est quasi impossible(ou trop difficile) avec ce qui reste comme delai + mon expériences dans les requêtes "type vue complexes"..

les liens c'est beau mais les requête fo assurer

-donc , l'utilisation de detail commande (même si au niveau sémantique ça ne veut rien dire) comme tremplin des informations lié a chaque véhicule (num_serie) et (pap, acces) depuis les relation avec pap_liv et acces_liv m'est salvateur .au niveau du code des requêtes

Comme un raccourcis
surtout que j'ai hélas deux autres service a implémenter (piece detaché et maintenance) a 60% vu le temps qui me reste .

A VOUS l'antenne et Gros MERCI jphi33 (jan filip?)

ps:je reste dependant de toute aide! le choix ne m'etant pas offert!

[scofield]

bon , ben voila
suivant ce que j'ai dit dans les précédant poste .

j'ai mit la table detail_comande (que j'ai renommé detail_achat qui est moins inapproprié)
avec numéro de série et matricule dedans .

je sais que ca doit être plus du coté facture , mais j'ai besoin de finir mon projet et par rapport au requête(vues) ca marche assez bien je doit dire.(j'ai d'autre service a attaquer).

j'allai même rajouter le pourcentage de commission dans cette table .En allant encore + dans la simplicité. la source d'information pour les commission étant ( table détail véhicule +commission calculé depuis la même table *attribut prcntage).
Mais j'ai crée une table commission ,pour limiter ces pratiques douteuses,
qui n'a pas d'identifiant mis a part ceux importé des clé(étrangère) de "DETAIL_ACHAT".(id_v+num_comd)


bref ,bien que les facture et les livraison n'ont aucun lien directe avec les véhicules achetés.
La facture a quand même ; la clé étrangère num_comv en commun avec ces véhicules la.
et la livraison a comme clé étrangère la PK de la table facture .
donc on peut tout récupérer ou qu'on soit .même si c'est pas très catholique comme manière .
en plus , dans mon application l'utilisateur n'aura aucun désagrément tout sera normal , il na pas a savoir comment le mpd est fait juste a bosser c'est tout.

LA question ,c'est de savoir si je pourrait avoir votre bénédiction sur ce modèle. genre si au niveau perf ! ca ne cause pas de problème .
je rappelle ,que c'est pour un projet de fin d'étude .
sinon , je serait pour des proposition de réajustement a condition de répondre a temps !
par ce que la dérogation que j'ai obtenue ne me laissera pas
trainer plus que ca !

voici donc, la structure de donnée concerné (tables etc..) dans le fichier detail achat *le 2eme c'est le tout (base d) au cas ou

MERCI BEAUCOUP