Bonjour a tous,
 
je suis chargé a mon travail de travailler sur une BDD access 97.
 
Un problème se pose lorsque j'ai affaire à une association reflexive de type n,n alors que je ne sais pas comment la traduire dans le schéma des relations sous access.
 
Voici le type d'asociation :
 

 
Si vous pouviez m'aider pour la traduction dans access sa serait bien gentil  

Ajoute un champ "ComposantDe" qui stock l'ID du CodeArticle du produit composé.
 
Pour les produits composés, ce champ est NULL.
 
Si un même composant peut composer deux articles composés, alors il faut faire une table "composition" liant les deux CodeArticle (CodeComposé/CodeComposant avec pkoi pas une quantité) et si les composants ne peuvent pas être vendus seuls, alors ajoute un flag "B" pour "baseunit" (produit de base/composé) ou "C" (composant) qui permettra de ne chercher que les produits vendables lors de relations ultérieures.

Ah oui je n'avait pas pensé à une table a part (je ne suis qu'en 1ere année de bts ig )
 
Merci a toi Arjuna je vais essayer !

Et bien merci bien cela a fonctionné parfaitement :  
J'ai créé une table LigneNomenclature Qui comporte les codes des produits "composés", les codes des "composants", les quantités et l'ordre d'insertion dans la fabrication.
 
Encore merci !!!!

au niveau meurise c'est pas bien du tout comme solution,même si certes cela marche, mais c'est un peu brouillon. Cours meurise => sur une association 0,n - 0,n il afut crée une table intermédiaire, c'est à dire une table par exemple 'est_compose' avec deux clés étrangères dont la concaténation des deux est la clé primaire,
genre  
1 | article toto
2 | article titi
 
dans la table intermédiaire
2 | 1
et voilà comme ça toto et titi sont liés
enfin tu peux récup tous les éléments d'un article à partir d'un autre, partique (sauf poru les requetes qui grossisent bcp plus) et surtout répond à meurise. Et enfin ça évite de laisser des trous partout! euh forme normale humm 3 ou4 je sais plus...

euh... c'est un peu ce que je lui ai dit de faire, et ce qu'il a fait.

peut etre que notre ami lordashram pensait que zergoll avait 3 tables :  
 
composant------composant_de------------composés
 
alors que lui il prodigue une solution avec 2 tables :  
 
composant-------composant_de_composant

merci Gatsusat de préciser...
plus il y a des tables plus les données sont éclatées et donc spécialisées et donc plus c'est précis, plus l'optimisateur du sgbd sera performant donc plus ça sera rapide aussi. Enfin d'un autre côté on s'retrouve avec des jointures de ouf et tt et les requtes font 50km mais bon faut skil faut pour l'optimisation !

heu tu crois que ça sera optimisé si tu fais des requêtes aussi sauvages ? j'en doute un peu. Peut être que ton appli est mega énorme, et donc BDD de fou.
 
mais, ya pas moyen parfois de spécialiser les tables ?
 
exemple : dans un batiment, tu as des pieces, dans chaque piece tu as des objets.
 
tu spécialise tout dans une table entités, et bon après je sais plus j'ai po la tête à reflechir

Euh, je suis pas vraiment d'accord en ce qui concerne l'optimisation par éclatement.
Même au contraire dans la plupart des cas.
 
L'optimiseur se moque royalement du nombre de lignes ou de colonnes des tables. Par contre, s'il doit faire une jointure sur 3 tables au lieu de 2, il sera forcément plus lent.
Idem ensuite lors de la lecture des données. A moins d'avoir une base gérant les tablespace, et avoir mis chaque table sur un disque dur physiquement différent, je ne vois pas comment séparer physiquement les données dans le fichier (les tables occupent des places séparées dans le fichier de la bdd) pourrait accélérer leur lecture, généralement, un HD il n'aime pas aller plein de petits bouts un peu partout sur le disque, par contre un gros bout à un seul endroit, c'est instantané.
 
Bref, je doute énormément que dans des conditions "classiques" des tables plus spécialisées n'apportent quoi que ce soit. Mise à part des bugs peut-être.

hum cours de fichier accès direct =>
les fameux fichiers d'index!
plusieurs tables=plusieurs fichiers d'index = accès super rapide!
Donc lui fait ses jointures, il sait où taper, puis il a ses clé primaires, sont indexées, et yop! merci pour la data à priori sur les bon SGBD ça marche! Et c'est rapide et je l'ai vérifié asez svt.

Euh... Ouais m'enfin un fichier d'index, il est censé être en mémoire dès le démarrage du serveur, et c'est la raison pourquoi un SGBD doit systématiquement avoir au grand minimum 2 GB de mémoire pour tourner convenablement.
Ensuite, un index, c'est un arbre (binaire ou avec plus de pattes), donc quelle que soit sa taille, il sera toujours extrêment rapide à lire... surtout s'il est en mémoire.
 
Non, je maintiens, éclater en petits fichier ne peut, au mieu, qu'apporter des erreurs (confusion dans les noms de tables) voir ralentir la base (plus il y a de fichier, et surtout petits, et plus ça fragmente.

arf pour le serveur, on est codeurs et pas responsables matériel, normalement ils sont sencés avoir des servs "puissants".  
Sinon pour les désavantages :  
1 - se mélanger sur les noms de tables :
certain, mais il faut se faite un p'tit MCD/MLD avant personnellement j'ne fait à 95% du temps et ça fait gagner un temps fou après , non seulement ça clarifie l'analyse, mais en plus ça permet d'avoir son MLD devant pour faire ses requetes correctement. Un peu de rigueur et tout passe facilement=>PB résolu
2 - la fragementation
toujours un pb serveur, ils faut faire des défrag de tps en tps ça fait gagner du temps à tout le monde surtout sur un serveur.
 
Voilà de l'organisation, de la rigueur pour tout ce monde certes, et comme ça tout marche pour le mieux.Lol
Perso j'suis pas vraiment fan des tables à 2M lignes!

 
Et alors ? Tu crois vraiment qu'un SGBD est capable de mettre les données à la queueleleu et surtout de les maintenir ainsi ?  
 
Et enfin, est-ce que tu crois vraiment que dans une baie SAN en RAID avec x disk et y plateau tu as beaucoup de chance d'avoir des blocs contigus ? Est ce que ce serait pas au contraire une belle démo de la non utilisation de la parallélisation ?
 
La fragmentation quand on parle de SGBD n'a absolument aucune importance, ça fait un soucis en moins

je partage l'avis de lordashram. Il vaut mieux un bon modèle qui à faire des requêtes plus complexe (merci les vues ) plutôt qu'un mauvais modèle pour simplifier le dév. Un MPD n'est pas fait pour économiser des caractères dans les requêtes n'en déplaise aux développeurs
 
J'ajouterai que c'est la base de la modélisation -> voir les formes normales

pour info : http://oracle.developpez.com/guide [...] spaces/#L5

euh... le problème de la fragmentation d'un fichier de base de données, c'est que c'est pas le même type de fragmentation que des fichiers sur un disque... c'est à l'intérieur du fichier que c'est fragmenté. et tu peux pas te permettre de faire un tablespace sur chaque table, puisqu'au sein d'une requête, un SGBD est incapable de lire deux tablespace en même temps, donc je te raconte pas les perfs en cas de jointure sur 10 tables.
 
ensuite, pour le MCD euh... comment dire... là je bosse sur une base qui a 199 tables, justement en partie parceque les concepteurs du programme n'ont pas été foutu de faire de la généricité. j'ai pas de papier A0 ni de mur assez grand pour garder le MCD sous les yeux pendant que je développe.

clairement, on n'a pas du tout la même approche des sgbd. j'ai l'expérience des deux types de bases, et y'a pas photo, que ce soit d'un point de vue évolutivité, maintenance ou développement, la généricité est reine.
 
sans parler des performances, qui sont au pire, strictement les mêmes.

 
  quoi ??? Heureusement que c'est possible, laisse tomber les problèmes de perf sinon... en tout cas, Oracle le fait sans problème.
 
Quand à la fragmentation du tablespace, ça n'a aucune espère d'importance. Le tablespace est un espace logique c'est bien l'emplacement physique des blocs sur les disques qui pourraient éventuellement poser problème.
 

 
Ca je t'accorde que c'est pas des plus pratiques mais pour un SGBD performant c'est le passage obligé... comme je le disais, pour le dév c'est lourd mais bon... tous les process qualités sont lourd
 

 
Evolutivité avec la généricité ?
 
Exemple : un individu a 2 parents et des enfants. Si tu mets tout dans une seule table et qu'un jour on te demande de remonter une génération plus haut t'es mort. Alors qu'avec une table enfant et une table parent, tu peux ajouter une table grand-parents sans perturber le code existant. Là évidemment c'est un exemple bidon (c'est le 1° qui est venu ) mais c'est pour te faire comprendre le principe
 
La généricité en revanche c'est la base du datawarehouse et dans ce cas en effet c'est intéressant. Mais comme tu dois le savoir, on pense pas un modèle de la même manière pour un DW et un OLTP

la généricité, c'est pas faire UNE table avec 20000 lignes, mais faire UNE table, permettant de stocker, de façon séparée, plusieurs informations différentes.
 
Dans ton exemple justement, à vouloir faire 20000 tables, on va avoir les tables suivantes :
 
enfants
individu
parents
grand-parents
 
super.
 
moi, j'ai une table individu, avec deux champs "père" et "mère" qui sont liés à des individu.id différents.
 
une seule table. et je peux stocker l'arbre généalogique de toute l'humanité en parant d'adam et eve.

idem pour un produit : entre un composé et un composant, c'est quoi la différence ?
les deux peuvent être stockés, les deux peuvent faire l'objet d'une commande, et les deux on un certain nombre de propriétés communes (nom, volume, prix, etc.)
 
alors une seule table avec un flag "composant" actif ou non, ainsi qu'une table de correspondance pour assicier les composants aux composé et c'est terminé. tu pourras même t'amuser à faire des produits composés d'autres produits composés, ce qui est impossible en dissociant les deux types de produits dans des tables distincts.
 
bref, la généricité, ça fait des lignes de plus de 2M lignes, mais au moins on n'a aucune limitation.

 
 
Comme je te l'ai dit l'exemple n'est pas super mais restons dessus. Comment fait tu pour ajouter les époux ? Tu ajoutes une colonne ? Et comment tu crois que vont réagir les dévs basés sur la table ?

En fait, c'est plutôt les relations n-n moi que je remettais en cause, c'est pourquoi l'exemple familial est mauvais et je te rejoins, pour cet exemple plusieurs tables n'est pas forcément utile.
 
Imagine alors, la liste des départements et des zones géograhique. On peut définir une zone par 1-n départements, département pouvant être dans 0-n zone. Dans ce cas, les caractèristiques entre une zone et un département sont trop différentes pour ne faire qu'une seule table sans multiplier de manière incosidérée la duplication des données.

ton exemple est très bon, puisque la colonne "epoux" peut être null. donc j'ai juste à ajouter la colonne sans rajouter rien d'autre, et j'ai pas une ligne d'aucun code existant à modifier.
 
quand on rajoute une table par contre, une fois sur deux on a des trigger à modifier, sans parler des chemins de jointures qui sont parfois impactés.
 
bref, non, t'arriveras pas à bloquer mon système avec le tiens.
 
d'autant plus que toi, tu fais quoi dans le cas de l'ajout d'un époux ? tu fais une table époux ? elle contient quoi ? l'identifiant d'un individu, qui a lui-même comme époux le premier ?
 
moi j'appelle ça de la redondance d'informations.

je suis pas d'accord.
une table unique avec un champ "typezone" fonctionne parfaitement.
il y aura dans tous les cas une table de correspondance joingnant les deux types de zones.
dans le cas où les données sont très différentes, t'as plusieurs solutions :
- tu générises la structure de la table (au lieu de nommer "capitale_de_zone" et "chef_lieu" ), ben tu n'utilises qu'un seul champ, puisque ça contient le même type d'information, c'est à dire une ville.
- tu optes pour un modèle de colonnes "dynamiques", c'est à dire une table contenant, ligne par ligne, les colonnes manquantes.
 
par exemple :
 
region
--------
type_reg
id_reg
nom
 
region_detail
-------------
type_reg
id_reg
nom_detail
valeur_detail
 
avec une règle permettant pour un type 'R' d'avoir les 'nom_detail' suivant : code_depot, informations_bancaires, etc.
et avec le type 'D', les 'nom_detail' suivant : 'superficie', 'population', 'chef_lieu', 'est_prefecture', etc.
 
ainsi, t'as pas une seule colonne de trop dans la base, et les requêtes sont simplissimes.
quant aux index, aucun problème, la recopie de 'type_reg' dans la table de détail, t'as bien un index performant sur la PK. couplé à la règle fonctionnelle, t'as même une cohérence parfaite.
 
le gros intérêt de n'avoir qu'une seule table, permettant de lier "n'importe quoi" avec "n'importe quoi", c'est que justement t'as pas de limite.
 
Imagie, tu veux représenter la france politique.
 
"normalement", t'as les éléments :
hameau, ville, canton, département, région, (pays)
 
mais... t'en fait quoi des DOM TOM ?
 
comment tu vas les modéliser ? tu va encore rajouter deux tables, une DOM et une TOM ? (les informations sont très différentes entre les deux types) et transformer en joyeux bordel ton code ?
 
avec mon sytème, j'ai les types 'H' (hameau), 'V' (ville), 'C' (canton), 'D' (département), 'R' (région), 'DOM', 'TOM', avec dans ma table de correspondance les H liés aux V, les V aux C, DOM ou TOM, les C liés aux D, puis les D aux R, et les DOM et TOM liés à rien.
quand je veux proposer à l'utilisateur un filtre pour retrouver un ville par exemple (associée à un canton, dom ou tom), alors j'ai qu'à afficher en premier niveau la liste des zones associées à aucune autre (régions et dom/tom, sans besoin d'expliciter la liste des type), puis dans le sous-filtre je peux filtrer au fur et à mesure, jusqu'à ce que le dernier niveau soit H. En plus, pour les dom tom, un simple "group by" permet de les isoler dans la requête. un petit coup de décode pour les forcer à rester en bas dans la liste, et j'ai corriger le seul bug mineur en 5 minutes maxi.
 
Je pourrai rajouter autant de niveau que je veux, je n'ai qu'à rajouter des types dans ma base, et refaire les liens.
avec une application convenablement pensée, je n'aurai même pas besoin de changer une seule ligne de code.

 
non j'ajoute une colonne... c'était pour aider ta théorie
 
J'ai précisé que dans ce cas en effet une autre table c'est idiot

t'as pas compris l'exemple des zones je pense
 
J'ai l'europe occidentale et la CEE qui auront des pays en commun mais pas tous. Relation n-n, il me faut une table pays, une table zone et une table de relation :
 
ID Pays  
-- ----
1  France
2  Suisse
3  Espagne
 
ID Zone
-- ----
1  CEE
2  Europe occidentale
3  Affrique
 
Pays zone
---- ----
1    1
1    2
2    2
3    1
3    2
 
Avec les tables pays et zone qui contiennent chacun d'autre champs spécifiques bien sûr

Table ZONE :
TYPE ID Nom
---- -- -------
P        1 France
P        2 Suisse
P        3 Espagne
Z        1 CEE
Z        2 Europe occidentale
Z        3 Afrique
 
Table ZONE_LIG :
TYPE1 ID1 TYPE2 ID2
----- --- ----- ---
    Z   1     P   1
    Z   1     P   3
    Z   2     P   1
    Z   2     P   2
    Z   2     P   3
 
Sauf que moi en plus, je peux rajouter autant de types de zones de de liaisons (et même des liaisons qui sautent des étapes) sans changer mon modèle. Alors que toi, si tu rajoutes continent pour mettre tes zones dedans, ou alors les régions des pays, t'es mal.
et le jour où tu dois rajouter les états entre les régions et le pays, t'es mal, parceque t'as pas forcément d'état dans le pays. moi je peux sauter le lien comme je veux
 
c'est moi qu'ai raison d'abord

avec une table "zone_detail" biensûr

J'aime déjà pas les DB mais alors là Arjuna tes solutions bonjour le cauchemard, à ce train là autant tout foutre dans une seule table, je suis sure que t'y arriverais  
 
Mais plus sérieusement, pour maintenir ce genre de modèle sur de gros systèmes c'est pas cauchemardesque pour un DBA ?
 

Quelle battaille quelle battaille, cela dit pour les champs pour ces fameux produits, je dit que les flags c'est bien mais d'1 pas évolutif et de 2 ça marche que sut de la petite quantité, sinon je t'explique même pas le bordel pour retrouver tous les composants! Alors qu'une liaison par une table c'est si simple , OK la requte se complique ces sacrosaintes liaisons de tables qui n'en finissent plus et qui le plus souvent avec les GROUP BY pourrissent toute la requete qui la font doubler boir tripler de volume, mais bon on y gagne en performance, en clarté du MCD/MLD et en évolutivité de la BDD.  
Personellement j'aime bien refaire les choses par moi-même, mais de là à remettre en cause tout le modèle Meurise, faut pas abuser non plus. Je n'ai pas de lien sous la main là, mais c'est trict et les SGBD à mon avis fonctionnement sous le même type de norme, les 0,n 0,n faut faire une table intermédiaire, c'est tout! Ah de plus c'est plus court de stocker des integers qui n'existent que qd il doivent être là que de stocker des flags qui sont renseignés quoi qu'il arrive enfin sur une BDD assez grosse on y gagne énormément (après c'est sûr que si c'est pour 200 lignes autant pas s'embèter mais ça m'chiffonne qd même, quite à respecter le modèle Meurise autant le faire jusqu'au bout!).
Voilà, donc sur quasiment tous les moints je pense que je rejoins Orafrance.

nan au contraire. je détiens ce système justement d'un gros système alors là t'es mal tombé
 
PS: ce système est d'ailleurs certifié merise et iso chais plus quoi, donc niveau qualité de la base, y'a aucun problème.

Je comprends pas bien la différence entre :
 
Pays zone
---- ----
1    1
1    2
2    2
3    1
3    2  
 
Et  
 
Table ZONE_LIG :
TYPE1 ID1 TYPE2 ID2
----- --- ----- ---
    Z   1     P   1
    Z   1     P   3
    Z   2     P   1
    Z   2     P   2
    Z   2     P   3  
 
Avec 3 tables dans ton cas aussi...  
 
Edit : autre le fait de se prendre la tête avec un type supplémentaire  

 
copaing    
 
De toute façon, Merise a dit : "les relations n-m c'est le mal incarné, c'est une invention des démons de l'apocalypse  

la table de liaison reprenant le type, ça permet de lier "n'importe quoi" à "n'importe quoi". Je n'aurai donc qu'une seule table de jointure quelle que soit le nombre de type de zones.
 
ensuite, moi j'ai 3 tables quelque soit le nombre de zones.
 
toi, t'en a n * 2 - 1 avec n = nombre de zones
 
et en plus, tu ne peux pas modéliser la différence entre un pays qui a directement des régions, et le pays qui a un niveau état avant les régions

vi mais ça faut le prévoir et étudier tout ça dans un MCD enfin diagrame de contexte et tout, enfin en gros on tombe finalement tous sur la même solution, plutôt que de se dépatouiller avec le code, la BDD et les optimisations, rien ne vaut une belle analyse qui REPONDE au pb, et faire souvent le dur choix entre évolutivité et optimisation (des fois les deux sont possibles effectivement mais pas tjrs...)

Surtout, le principal souci des développeurs et analystes, c'est que clairement, il y a très souvent une lacune au niveau de la connaissance du fonctionnement des SGBD.
Premier problème, y'a pas deux SGBD qui bossent de la même manière : là où certaines (Access, MySQL, etc.) préfèrent des petites tables en très grand nombre, d'autres (Oracle, SQL Server, etc.) se moquent éperdument de la taille des tables, à condition d'être correctement indexées.
 
Ensuite, idem niveau optimisations des requêtes complèxes : certains supportent mal, et rament avec des sous-requêtes, alors que chez d'autres, ça ne poste pas de problème. Idem pour l'ordre des tables dans les requêtes, et bein d'autres points.
 
Ce que je veux dire, c'est que la même optimisation n'est pas forcément vraie pour deux produits. Pour cette raison, je pars du principe qu'un serveur, c'est fait pour être une grosse machine, et le faire évoluer coûtera certes un prix certain, il restera en dessous du prix d'un développement interminable. Pour cette raison, je préfère laisser de côté l'aspet optimisation, et me concentrer sur une architecture à la fois claire (peu de tables, mais bien pensées) et une forte évolutivité (réutilisabilité au maximum des objets créés) afin d'avoir, en cas de maintenance ou évolution, le moins à toucher au niveau du code et de la base. Ensuite, rien n'empêche de faire des optimisations au niveau de l'écriture des requêtes, mais cet aspect, selon moi, ne dois jamais impacter l'architecture des données.
 
C'est vrai que pour un forum, faire une table par catégorie, c'est vachement bien pour MySQL. Mais au niveau du code, voilà le bordel. Je suis fondamentalement contre. D'autant plus que le jour où la base de données change, cette optimisation de charcutier devient inutile.

arf pour le moment pour mon forum j'ai fait une table pour :
domaine
zone
topic
post
 
j'pense que c'est plutôt correct, mais j'ai qq pb pour la gestion des droits, arf tien j'vais faire un nouveau topic pour ça tien j'en fais un topic : http://forum.hardware.fr/hardwaref [...] 5617-1.htm