Architecture base de données.
Résolu/Fermé
Creutzou
Messages postés
550
Date d'inscription
lundi 17 mai 2010
Statut
Membre
Dernière intervention
30 mai 2013
-
Modifié par Creutzou le 20/07/2011 à 16:37
Creutzou Messages postés 550 Date d'inscription lundi 17 mai 2010 Statut Membre Dernière intervention 30 mai 2013 - 22 juil. 2011 à 13:01
Creutzou Messages postés 550 Date d'inscription lundi 17 mai 2010 Statut Membre Dernière intervention 30 mai 2013 - 22 juil. 2011 à 13:01
A voir également:
- Architecture base de données.
- Logiciel architecture gratuit - Télécharger - Architecture & Déco
- Formules excel de base - Guide
- Tnt base de données vide - Forum TNT / Satellite / Réception
- Célia doit nettoyer le tableau ci-dessous pour l’ajouter à la base de données de son entreprise. les données sont ensuite traitées automatiquement. quelles sont les 4 cellules qui risquent de poser problème ? ✓ - Forum Excel
- Exemple base de données access à télécharger gratuit ✓ - Forum Logiciels
4 réponses
a.laumiere
Messages postés
18
Date d'inscription
mardi 7 juin 2011
Statut
Membre
Dernière intervention
16 septembre 2011
3
20 juil. 2011 à 20:14
20 juil. 2011 à 20:14
Bonjour,
Vu le contexte, j'opterais pour l'ajout d'une table intermédiaire:
etude(id,nom,adresse,mail.....)
vente(id,id_etude,titre,description,date....)
vente_item(id_vente,id_item)
item(id,titre,description,photo....)
Peut-être très utile dans le cas où un item n'est pas vendu lors de la première vente et est proposé sur une autre vente, tout cela en gardant la possibilité de voir facilement l'historique des ventes d'un item.
A voir en fonction des besoins métiers...
Vu le contexte, j'opterais pour l'ajout d'une table intermédiaire:
etude(id,nom,adresse,mail.....)
vente(id,id_etude,titre,description,date....)
vente_item(id_vente,id_item)
item(id,titre,description,photo....)
Peut-être très utile dans le cas où un item n'est pas vendu lors de la première vente et est proposé sur une autre vente, tout cela en gardant la possibilité de voir facilement l'historique des ventes d'un item.
A voir en fonction des besoins métiers...
Creutzou
Messages postés
550
Date d'inscription
lundi 17 mai 2010
Statut
Membre
Dernière intervention
30 mai 2013
30
21 juil. 2011 à 09:06
21 juil. 2011 à 09:06
Je n'avais pas pensé à la table intermédiaire. C'est vrai que cela résoudrait quelque problème que je n'avais pas encore rencontré.
je te remercie, je laisse le thread ouvert , si jamais d'autre contraintes insolvable me viennent.
je te remercie, je laisse le thread ouvert , si jamais d'autre contraintes insolvable me viennent.
Creutzou
Messages postés
550
Date d'inscription
lundi 17 mai 2010
Statut
Membre
Dernière intervention
30 mai 2013
30
21 juil. 2011 à 14:58
21 juil. 2011 à 14:58
Compte tenue de vos remarques, j'ai établis un nouveau modèle.
Puis nous avons donc :
une Etude a 0 ou N Vente.
Une Vente est a 1 et 1 seule Etude.
Une Vente a 0 ou N Item.
Un Item est dans 0 ou N vente.
Un Item a 1 ou N statut.
Un statut a 0 ou N Item .
Je commence à y voir un petit peu plus clair.
Etude ( id , nom_etude.... ) Statut ( id , libel ) Vente ( id , id_etude , id_statut , titre ... ) Item ( id, id_vente , id_statutVente , id_statutItem ... ) Vente_item ( id_vente , id_item , id_statut)
Puis nous avons donc :
une Etude a 0 ou N Vente.
Une Vente est a 1 et 1 seule Etude.
Une Vente a 0 ou N Item.
Un Item est dans 0 ou N vente.
Un Item a 1 ou N statut.
Un statut a 0 ou N Item .
Je commence à y voir un petit peu plus clair.
a.laumiere
Messages postés
18
Date d'inscription
mardi 7 juin 2011
Statut
Membre
Dernière intervention
16 septembre 2011
3
21 juil. 2011 à 18:12
21 juil. 2011 à 18:12
Là c'est moi qui n'y vois plus clair.
Pourquoi tout ces id_statut ?
Pourquoi tout ces id_statut ?
Creutzou
Messages postés
550
Date d'inscription
lundi 17 mai 2010
Statut
Membre
Dernière intervention
30 mai 2013
30
22 juil. 2011 à 08:26
22 juil. 2011 à 08:26
heu , je me suis dis qu'un objet pouvait avoir plusieurs statut . Mais qu'une vente aussi.
Après réflexion, c'est complétement nouille de l'avoir mis aussi dans la table vente_item.
On peut le retrouver facilement.
Après réflexion, c'est complétement nouille de l'avoir mis aussi dans la table vente_item.
On peut le retrouver facilement.
a.laumiere
Messages postés
18
Date d'inscription
mardi 7 juin 2011
Statut
Membre
Dernière intervention
16 septembre 2011
3
22 juil. 2011 à 10:12
22 juil. 2011 à 10:12
ok. l'id_statut de la table vente est donc justifié.
Par contre, pour moi, le statut dans la table vente_item me gène moins que les statuts dans la table item.
Si on souhaite connaître le statut "final" d'un item, alors le statut dans la table item suffit, par contre pour avoir un historique des statuts (phrase: un item peut-être au statut "en stock" sur la première vente et "vendu" sur la seconde vente), le statut dans vente_item est nécessaire.
Par contre, pour moi, le statut dans la table vente_item me gène moins que les statuts dans la table item.
Si on souhaite connaître le statut "final" d'un item, alors le statut dans la table item suffit, par contre pour avoir un historique des statuts (phrase: un item peut-être au statut "en stock" sur la première vente et "vendu" sur la seconde vente), le statut dans vente_item est nécessaire.
Creutzou
Messages postés
550
Date d'inscription
lundi 17 mai 2010
Statut
Membre
Dernière intervention
30 mai 2013
30
22 juil. 2011 à 10:31
22 juil. 2011 à 10:31
je pensais effectivement avoir un historique des statut pour un item. Et connaitre le statut "du moment" de ce même item. Mais c'est vrai qu'en rajoutant une date ou en jouant avec les id on pourrait trouver son dernier statut.
Je ne pensais pas ça, si compliquer au début ^^
Je ne pensais pas ça, si compliquer au début ^^
a.laumiere
Messages postés
18
Date d'inscription
mardi 7 juin 2011
Statut
Membre
Dernière intervention
16 septembre 2011
3
22 juil. 2011 à 10:48
22 juil. 2011 à 10:48
oui, c'est pour ça qu'il faut lister tout les besoins dès le départ.
Si tu te rends compte à posteriori que, par exemple, tu peux avoir une vente réalisée sur 2 jours avec 2 commissaires priseurs différents ... tu devra revoir ton modèle et ça te prendra plus de temps que si tout est correct au départ.
Si tu te rends compte à posteriori que, par exemple, tu peux avoir une vente réalisée sur 2 jours avec 2 commissaires priseurs différents ... tu devra revoir ton modèle et ça te prendra plus de temps que si tout est correct au départ.
Creutzou
Messages postés
550
Date d'inscription
lundi 17 mai 2010
Statut
Membre
Dernière intervention
30 mai 2013
30
22 juil. 2011 à 13:01
22 juil. 2011 à 13:01
Merci, je vais jeter un coup d'oeil a ça, et j'ouvrirais un nouveau thread en cas de besoin.
J'ai déjà pas mal avancé !
Merci beaucoup.
J'ai déjà pas mal avancé !
Merci beaucoup.
21 juil. 2011 à 13:21
J'aurais plutôt fait :
etude(id,nom,adresse,mail.....)
vente(id,titre,description,date.... id_etude)
item(id,titre,description,photo.... id_vente)
Modifié par Creutzou le 21/07/2011 à 13:29
lorsque que l'on créer une vente, on " place" des objets dans cette vente.
Un objet A ne peut être présent que dans UNE et UNE seule vente à la fois. Il peut en faire plusieurs à la suite, mais pas simultanément.
je ne sais pas si je me fais bien comprendre, c'est déjà un peu embrouiller dans mon esprit. Donc c'est pas facile à expliquer. Désoler.
21 juil. 2011 à 13:34
21 juil. 2011 à 14:29
- une vente contient 0-n item, un item apparaît dans 0-n vente
- un statut a 0-n item, un item a ... statut
Pour la relation item-statut, ce n'est que mon avis mais je pense que le statut d'un item est aussi lié à la vente, un item peut-être au statut "en stock" sur la première vente et "vendu" sur la seconde vente ... dans ce cas cela se traduirait par un id_statut dans le table intermédiaire.
Le mieux est de se poser un maximum de questions avant pour sortir toutes ces règles ... après le modèle suivra.