Discussion :

[crystal6]

Bonjour je debute dans la modelisation de base de donnée et puis jai lu un peu sur les relations n-n, et les tables de jonctions...

Mais je n'arrive toujour pas a comprendre, disons que jai 200 personnes qui possede chacune 200 voitures differentes

J'aurai une table voiture avec les modeles de voiture different etc, ensuite une table personne avec leur identité etc,

mais si je met une table de jonction jaurai donc 200x200 enregistrements a l'interieur... je me dit qu'il y a forcement quelque chose qui cloche... comment devrais-je procédé pour modeliser mon exemple correctement ?

merci a l'avance d'aider un debutant

[FSiebert]

Bonjour,

Il faut bien définir les cardinalités :
- une personne peut posséder plusieurs voitures vous l'avez dit
- est-ce qu'une même voiture (tout dépend ce qu'on entend par voiture, voir ci-dessous) peut être possédée par plusieurs personnes ?

Par ailleurs, vous devriez, à mon avis, différencier un modèle de voiture, d'une voiture physique : une personne possède une voiture physique, et pour une même marque/modèle il y aura des centaines ou milliers de voitures physiques. Et d'ailleurs, pour un même modèle on a plusieurs motorisations, plusieurs finitions et même des options.

Pour répondre de manière générale : oui une table de jointure peut rapidement contenir beaucoup d'enregistrements ; mais ce n'est pas du tout un problème

Précisez bien votre besoin et donnez-nous votre modèle actuel si vous souhaitez des conseils

[crystal6]

Bonjour,

Il faut bien définir les cardinalités :
- une personne peut posséder plusieurs voitures vous l'avez dit
- est-ce qu'une même voiture (tout dépend ce qu'on entend par voiture, voir ci-dessous) peut être possédée par plusieurs personnes ?

Désolé si je ne suis pas tres precis dans ma demande
mon exemple est tres mauvais...

Disons que jai plusieurs personnes qui possedent chacunes une collection de piece de monnaie physique, les pieces de monnaie qu'ils possedent peuvent etre totalement differente une des autres, il peut y en avoir une infinité de types differente des une des autres. Plusieurs personnes peuvent avoir les meme types de pieces ou meme personellement des doubles ou triples sans probleme. Une piece de monnaie physique n'appartient qu'a seulement une personne a la fois par contre.

En faites la vrai question que je me pose: dois-je avoir dans une table de jonction 1 enregistrement pour chaque pieces physiques afin de garder un modele relationnel cohérent ?

N'y a t-il pas un moyen d'ajouter un tableau/array dans ma table personne exemple avec disons tout les types differentes de pieces qu'une personne aurait disons:

Paul possede tout les pieces physique de type suivant [1,1,1,1,2,5,6,8,8,8,9]

Est ce possible de garder un modele relationnel de cette facon ? ou est ce que je propose cest du nosql et pour garder un modele relationnel cohérent je dois absolument avoir recours a une table de jonction ?

[FSiebert]

Donnez clairement votre modèle actuel pour qu'on comprenne bien où vous en êtes

Dans tous les cas, ce genre de chose "[1,1,1,1,2,5,6,8,8,8,9]" est à bannir car il n'apporte rien d'autre que des problèmes.

Quel est le problème de faire une table de jonction contenant les pièces physiques ? Je ne vois pas bien ce qui vous gêne.
Une pièce physique sera associée à un type et à un propriétaire. Avec ce modèle, vous pourrez même ajouter des informations complémentaires comme par exemple l'état de la pièce (excellent état, légèrement abîmée, etc. ; sans stocker le libellé mais avec une table de référence hein )

[crystal6]

En faites je ne connais rien au fonctionnement intrinsèque d'une base de donnée alors je me demandais si coté performance lorsque qu'une table de jonction contient disons un demi millions d'enregistrement si c'etait tres genant...

merci 1000x pour avoir pris le temp de me repondre maintenant je n'ai qu'une derniere question

All primary keys must be unique. This implies that the combination of field A and B must be unique in table A_B.

Dans mon exemple de piece de monnaie, un proprietaire de piece peut avoir plusieur fois le meme type de piece.

Alors je me suis dit, je n'ai qu'a ajouter un champ quantité dans ma table de jonctions

Est ce que c'est la bonne facon de proceder ?

Merci d'avance !

[StringBuilder]

Ajouter un champ "quantite" est une solution.

Mais si tu veux les différencier (par exemple, il vends une pièce à untel, qui la revend à un autre, et tu veux au final savoir à qui appartient LA pièce qu'il a vendu, ta quantite n'est pas assez précise).

Tu peux alors mette à la place un champ ID unique, qui sert de clé primaire. Les colonnes A et B sont alors indexées pour un accès rapide, mais sans contrainte d'unicité.

Ainsi, quand une personne vent la pièce, la colonne A change, mais ID reste identique, tu peux donc savoir à qui la pièce a été vendue.

[crystal6]

Ajouter un champ "quantite" est une solution.

Mais si tu veux les différencier (par exemple, il vends une pièce à untel, qui la revend à un autre, et tu veux au final savoir à qui appartient LA pièce qu'il a vendu, ta quantite n'est pas assez précise).

Tu peux alors mette à la place un champ ID unique, qui sert de clé primaire. Les colonnes A et B sont alors indexées pour un accès rapide, mais sans contrainte d'unicité.

Ainsi, quand une personne vent la pièce, la colonne A change, mais ID reste identique, tu peux donc savoir à qui la pièce a été vendue.

Hier j'ai beaucoup lu sur le sujet, et effectivement je crois que le mieux est d'ajouter un champ id qui sert de clé primaire.

Je developpe en java et jutilise hibernate comme ORM, en ajoutant un champ id qui sert de clé primaire j'obtient bien 2 instances differente pour un meme type de piece contrairement a ma premiere idée d'ajouter un champ quantité.

Merci beaucoup pour vos reponses, vous avez repondu a tout mes interrogations... pour l'instant

[CinePhil]

Tes règles de gestion semblent être les suivantes :
1) une personne peut posséder plusieurs pièces et une pièce est possédée par une seule personne.
2) Une pièce est d'un seul type et un type peut qualifier plusieurs pièces.

Nota : on peut affiner cette histoire de type en disant par exemple qu'il y a le type 1 euro de la famille euro et que chaque pièce en euro est d'un certain pays mais restons simple pour le moment pour expliquer la démarche de modélisation des données qui est à faire avant de plonger les mains dans le cambouis de l'applicatif qui va utiliser la BDD.

De ces règles de gestion, on déduit le MCD suivant :
personne -0,n----posséder----1,1- piece -1,1----typer----0,n- type

Il en découlera alors par exemple les tables suivantes :
personne (prs_id, prs_nom, prs_prenom...)
type (typ_id, typ_libelle)
piece (pce_id, pce_id_type, pce_id_proprietaire...)

jutilise hibernate comme ORM

Beurk !
ORM = Oh ! Réelle Merde !

[fsmrel]

Bonjour,


Comme dit CinePhil, inutile d’entreprendre la construction d’une base de données (et de programmer) sans avoir établi rigoureusement l’inventaire des règles de gestion des données, sinon, comme bien des projets ça finira en eau de boudin.

A ce propos, suivez-vous les ventes/échanges des pièces (aspect historique) ? C'est-à-dire de telle date à telle date, la pièce X1 a été en possession de la personne Y1 puis de la personne Y2, et aujourd’hui de la personne Yn ?

Ne mélangez pas les aspects conceptuels (le QUOI) et physiques (le COMMENT), chaque chose en son temps, sinon vous vous prendrez fatalement les pieds dans le tapis. Pour le moment, voyez seulement les aspects conceptuels (les règles de gestion des données), de façon exhaustive, en fonction de votre projet.

[crystal6]

A ce propos, suivez-vous les ventes/échanges des pièces (aspect historique) ? C'est-à-dire de telle date à telle date, la pièce X1 a été en possession de la personne Y1 puis de la personne Y2, et aujourd’hui de la personne Yn ?

Non, du moin pas pour maintenant

Ne mélangez pas les aspects conceptuels (le QUOI) et physiques (le COMMENT), chaque chose en son temps, sinon vous vous prendrez fatalement les pieds dans le tapis. Pour le moment, voyez seulement les aspects conceptuels (les règles de gestion des données), de façon exhaustive, en fonction de votre projet.

Bien dans les derniers jour jai beaucoup travaillé sur mon projet et je crois avoir appris beaucoup de choses.

J'ai monté ma base de donnée relationelle selon les règles (du moins je le pense ) je n'ai pas pensé a comment j'allais recuperer mes objets.
Je ne me suis pas laisser distraire par le coté programmation meme si j'etais inquiet quant a la facon que j'allais pouvoir recuperer mes objets.
C'etait la premiere fois que je procedais ainsi, mais tout a fonctionné comme sur des roulettes.

Mon âme repose en paix, programmation et base de donnée relationelle sont maintenant dissocié à tout jamais dans mon esprit
J'utilise la programmation et la base de donnée dans un but commun mais les deux ont des objectifs differents à la base

Merci beaucoup pour vos conseils, je commence l'ecole bientot, j'espere que cela va m'aider a m'amiliorer rapidement

[fsmrel]

Bonne route crystal, l'avenir vous appartient !

[FSiebert]

C'est bien un débutant qui tient compte des conseils pour s'améliorer