IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

association reflexive pour une nomenclature [MLD]


Sujet :

Schéma

  1. #1
    Membre du Club
    Étudiant
    Inscrit en
    Mai 2006
    Messages
    56
    Détails du profil
    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mai 2006
    Messages : 56
    Points : 51
    Points
    51
    Par défaut association reflexive pour une nomenclature
    Salut,

    Je modélise (enfin j'essaie) un stock et j'en bave un peu.
    L'idée est de relier d'associer une nomenclature à chaque nouveau projet puis de confronter cette nomenclature avec le stock existant.
    La présence du champ "Projet_id" dans la table "Articles en stock" est-elle concevable ou c'est n'importe quoi ?


    Modélisation modifié après le message de Fsmrel

    N'hésitez pas à critiquer...

    Armagnak

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir Armagnak,


    Concernant Nomenclatures : il ya quelque chose qui cloche. En effet il y a deux associations entre Références Articles et Nomenclatures (ce qui est normal pour une nomenclature) : je suppose que la première concerne le rôle Composant et la deuxième le rôle Composé, autrement dit, Article Id devrait apparaître deux fois dans Nomenclatures (avec bien sûr des noms différents, par exemple Art_Enfant_Id et Art_Parent_Id). Or, dans la liste des attributs on retrouve Nom_Article qui existe déjà dans Références Articles où, puisque Article_Id est clé primaire, il existe la dépendance fonctionnelle :

    Article_Id -> Nom_Article

    Nom_Article doit dégager de la clé de Nomenclatures et même dégager de Nomenclatures pour que la 2e forme normale soit respectée.

    D’autre part, votre nomenclature est-elle une hiérarchie ou un graphe acyclique ? (autrement dit, un article peut-il entrer dans la composition de plus d’un article ? Ce qui serait le plus vraisemblable).
    Un couple {article enfant, article parent} n’existe-t-il qu’une fois dans Nomenclatures, ou peut-il exister en plusieurs exemplaires, un par projet ? (pour le moment je retiens la 1ère hypothèse).

    Par ailleurs, que fait l’attribut Projet_Id dans Articles en stock ?
    Prix d’achat est-il vraiment à sa place ?

    Je suppose que dans Projet, l’attribut Nom_Article est à renommer ?

    Pourriez-vous utiliser un outil qui effectue des contrôles ? Ci-dessous, un petit MLD fait avec DBDesigner 4 (sans prétention mais gratuit et qui génère les Create Table) :


    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  3. #3
    Membre du Club
    Étudiant
    Inscrit en
    Mai 2006
    Messages
    56
    Détails du profil
    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mai 2006
    Messages : 56
    Points : 51
    Points
    51
    Par défaut
    Salut et merci de ta réponse.

    J'ai commencé par rectifier les champs de "nomenclatures" pour qu'ils correspondent à ce que j'avais fait sur papier

    J'aimerais que ma table "articles_en_stock" comporte un enregistrement par article qui est (ou a été) en stock. Dans mon idée "articles_en_stock.stock_id" sert à distinguer plusieurs articles identiques en stock et "articles_en_stock.quantité" est obtenu en sommant les enregistrements ayant le même "articles_en_stock.article_id".

    Par ailleurs, j'aimerais qu'il y ait autant de couple {article enfant, article parent} dans "nomenclatures" que de projet utilisant cette liaison. L'utilité étant de créer une nomenclature par projet (les nomenclatures seront souvent proches mais jamais exactement similaire dans la pratique).

    Enfin, la présence de "articles_en_stock.projet_id" me permet de déterminer si l'article est disponible si ce champs est nul ou déjà utilisé/réservé par un projet. Le plus dur pour moi sera de concevoir l'interface PHP pour remplir ce champs lorsqu'on utilise des articles en stock.


    En fait, mon MCD est cyclique C'est grave docteur ?

    Armagnak

  4. #4
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonjour Armagnak,


    Remarque préliminaire, du genre point de détail, mais un peu de précision ne fait pas de mal. Vous écrivez : "...mon MCD..." : en fait nous étudions ici un MLD (modèle logique de données) avec des liens à la sauce conceptuelle (associations). De même, utilisez le terme "attribut" ou colonne" de préférence à celui de "champ" qui sert plutôt quand on parle de fichiers.


    Dans mon idée "articles_en_stock.stock_id" sert à distinguer plusieurs articles identiques en stock
    Excellent reflexe dans la mesure où Stock_Id est relatif à Article_Id (identification relative au sens conceptuel).


    la présence de "articles_en_stock.projet_id" me permet de déterminer si l'article est disponible si ce champs est nul ou déjà utilisé/réservé par un projet
    Par conformité avec votre représentation graphique, l’attribut Projet_Id ne peut pas prendre la valeur nulle, puisque les cardinalités minimales de l’association Est_utilisé_par sont à 1. Si vous prévoyez qu’à un article en stock ne soit pas nécessairement associé à un projet, alors la cardinalité 1,1 doit devenir 0,1. Mais en conséquence, la clé étrangère Projet_Id pourra prendre la valeur nulle, ce qui peut provoquer de gros problèmes avec le comportement des opérateurs relationnels, SQL pouvant en l’occurrence se révélant dangereux. Pour éviter les clés étrangères pouvant prendre la valeur nulle, le mieux est de prévoir la mise en œuvre d’une table ad-hoc, telle que Réserver (cf. la représentation graphique ci-dessous, en notant les cardinalités 0,1/1,1 entre Stock et Réserver).


    En fait, mon MCD est cyclique C'est grave docteur ?
    Graphiquement on a un cycle, mais ça n’est pas grave. Ça pourrait l’être si une table était "delete-connected to itself", c'est-à-dire si le serpent pouvait se mordre la queue, si la suppression d’une ligne d’une table pouvait entraîner la suppression d’autres lignes de cette table, via d’autres tables. En fait, on ne peut en juger qu’à condition d’observer le comportement métabolique de la base de données. Cela suppose que vous ayez défini les règles de comportement associées aux liens représentés par les clés étrangères : choix Cascade ou Restrict (No action pour certains SGBD), Set Null ou Set Default. Je ne préjuge pas de ce que sera votre choix final, mais j’ai retenu à titre d’exemple les options suivantes :

    La suppression d’un article dans la table Article entraîne la suppression des lignes correspondantes dans la table Stock (effet Cascade). Elle entraîne la suppression de cet article en tant que composant dans la table Nomenclature. La suppression de cet article en tant que composé est refusée (Restrict) si d’autres articles sont présents en tant que composants de l’article.






    La suppression d’un article dans la table Stock entraîne la suppression de la ligne correspondante dans la table Réserver.

    La suppression d’un projet dans la table Projet entraîne la suppression des lignes correspondantes dans les tables Réserver et Nomenclature.

    Par définition, la suppression d’une ligne dans la table Stock n’a aucun effet sur la table Article. Même principe pour la table Réserver vis-à-vis des tables Stock et Projet. Même principe pour la table Réserver vis-à-vis des tables Article et Projet.

    Conclusion : manifestement le serpent ne peut pas se mordre la queue (même si le seul Restrict était remplacé par un Cascade) : la suppression d’un article ne touche même pas la table Projet et réciproquement. Les tables Réserver et Nomenclature jouent le rôle de barrières de sécurité.

    J’ai dit que je ne préjugeais pas de vos choix, mais n’oubliez pas que l'utilisation systématique de Restrict pétrifie la base données, les opérations de suppression deviennent particulièrement pénibles.

    En outre, pour des raisons de cohérence, les SGBDR fonctionnent selon le mode "tout ou rien" : si vous tentez de supprimer un article qui a des composants, du fait du Restrict, l’opération sera globalement annulée : le stock ne sera pas altéré.


    Le plus dur pour moi sera de concevoir l'interface PHP
    Je ne connais pas PHP. A titre de curiosité, quelle est la nature de la difficulté ? (Si ça n’est pas trop long à exposer...)
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  5. #5
    Membre du Club
    Étudiant
    Inscrit en
    Mai 2006
    Messages
    56
    Détails du profil
    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Mai 2006
    Messages : 56
    Points : 51
    Points
    51
    Par défaut
    Salut et merci de vous intéresser à mon MLD

    Citation Envoyé par fsmrel
    (...)
    Par conformité avec votre représentation graphique, l’attribut Projet_Id ne peut pas prendre la valeur nulle, puisque les cardinalités minimales de l’association Est_utilisé_par sont à 1.
    (...)
    Au lieu d'ajouter la table de jonction "reserver", ne puis-je pas tout simplement créer un enregistrement "pas de projet" dont la table "projet" et l’attribut stock.Projet_Id ne serait jamais nul ?
    ça fait un peu bricolage mais cela simplifie le tout sans nuire, non ?

    Je dois vous avouer que je ne m'étais même pas poser la question des suppression mais j'ai lu attentivement votre analyse et elle me sera précieuse.
    Je vais m'atteler à comprendre les règles de comportement associées aux liens représentés par les clés étrangères.

    Pour le contexte, j'utilise MySQL avec des tables de type MyISAM.

    Je ne connais pas PHP. A titre de curiosité, quelle est la nature de la difficulté ? (Si ça n’est pas trop long à exposer...)
    Je parle de "difficulté" parce que je vais devoir m'aider de PHP pour réaliser certaines opérations sur ma base de données.
    En particulier, je n'arrive pas à mettre à jour les attributs projet_id lorsqu'on fabrique un article à partir d'autres articles avec une unique requête SQL (en utilisant MySQL).

    Armagnak

  6. #6
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut
    Bonsoir Armagnak,


    Au lieu d'ajouter la table de jonction "reserver", ne puis-je pas tout simplement créer un enregistrement "pas de projet" dont la table "projet" et l’attribut stock.Projet_Id ne serait jamais nul ?
    ça fait un peu bricolage mais cela simplifie le tout sans nuire, non ?
    Techniquement, il est effectivement possible de créer un enregistrement "pas de projet". Cela dit, dans vos requêtes SQL, vous devrez en tenir compte, par exemple pour ne pas fausser des calculs d’agrégation (telles que SUM, Count, AVF, MIN, MAX). Ça sera une sorte de boulet. Par ailleurs il faut tenir compte d’éléments tels que la volumétrie, la concurrence d’accès, les cycles (que nous évoquions...) Par exemple, si vous avez 90% des articles en stock affectés à des projets, on peut discuter. S’il n’y en a que 10%, les requêtes portant sur la seule table Reserver seront plus efficaces et la concurrence d’accès moins polluante globalement pour le système. Personnellement, j’ai pris l’habitude dans l’univers des bases de données d’appeler un chat un chat et ne pas le déguiser : les applications n’en ont pas souffert, au contraire. Certes, les jointures peuvent entraîner un peu plus de complexité dans les requêtes, mais enfin l’opérateur de jointure est l’opérateur relationnel par excellence, il ne faut pas en avoir peur et en cas de doute on monte un petit prototype de performance pour comparer et trancher. Mais sachez que déguiser a toujours des effets secondaires, sinon pervers.


    Je vais m'atteler à comprendre les règles de comportement associées aux liens représentés par les clés étrangères.
    Ceci est capital, car au lieu de se limiter à l’anatomie de la base de données, on passe au niveau métabolique et il n’est pas rare que cela entraîne des modifications dans les modèles. A chaque fois la question à se poser est la suivante : « Si l’entité X reçoit un stimulus de la part de l’entité Y parce que celle-ci doit être supprimée, X est-elle obligée de s’incliner ou bien est-elle légitimement habilitée à faire jouer son droit de veto ? »
    Par exemple, si une ligne de facture est en relation avec une facture d’une part et un article d’autre part, clairement cette ligne de facture n’a aucune raison de s’opposer à la mort de la facture donc à la sienne propre, puisqu’elle n’en est qu’un composant. En revanche, si c’est l’article avec lequel elle est en relation qui veut disparaître : que nenni, sinon on pourrait avoir des problèmes avec les gestionnaires des factures de l’entreprise... Il y a une dimension sémantique qui émerge très nettement et c’est bon pour la modélisation, la pertinence et la compréhension de la base de données.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  7. #7
    Membre confirmé
    Avatar de Darkaurora
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mai 2010
    Messages
    382
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2010
    Messages : 382
    Points : 549
    Points
    549
    Billets dans le blog
    1
    Par défaut Compréhension
    Bonjour, j'ai moi même à traiter un cas semblable de gestion de stock et un article peut être composé ou composant. Cependant j'ai du mal à comprendre l'association réflexive pour mon cas. Je m'explique:
    puisqu'un article peut être composant d'un ou plusieurs autres...
    puisqu'un article composé peut lui même être un article composant...
    ...(le reste étant identique au problème ci dessus)...

    Si je créé une entité (nomenclature) avec les id respectifs de mes articles composées et composant comment cela se traduit il concrètement dans ma base données??

    Mon problème est là en fait, je fait un blocage complet à ce niveau la.

    J'aurais forcément des lignes similaires et des redondances d'informations, or comment éviter ou limiter cet inconvénient?

    d'avance merci
    Je préfère fermer ma gueule et passer pour un con que de l'ouvrir et ne laisser aucun doute à ce sujet.

  8. #8
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 945
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 945
    Points : 30 716
    Points
    30 716
    Billets dans le blog
    16
    Par défaut Faut pas rester bloqué...
    Bonsoir Darkaurora,


    Citation Envoyé par Darkaurora Voir le message
    Je fais un blocage complet.
    Comme dit mon chiropraticien (non reconnu par la sécu, hélas !) : « On va essayer d’y aller doucement... »

    Je reprends un des exemples proposés par Donald Chamberlin (père de SQL) et qui figure dans son article Recursion in SQL: Tips and Techniques, paru en mai 1996 dans Database Programming and Design. Cet exemple concerne plus précisément les pièces qui entrent dans la composition des ailes d’avion et je m’en sers de temps en temps dans les forums DVP. On a deux tables, une pour décrire les pièces et une seconde pour représenter la nomenclature des pièces.


    Table des pièces



    (J’ai utilisé le type Texte pour la clé {PieceId} car c’est plus parlant, mais en principe on utilise le type Entier).


    Table (nomenclature) des composants et des composés :




    Sous forme de graphe :



    Où l’on voit que pour une aile d’avion façon Chamberlin on a besoin de 183 rivets.


    Pour représenter graphiquement une telle nomenclature sous forme de MLD (Modèle Logique de Données), on peut utiliser le successeur de DBDesigner, à savoir MySQL Workbench :



    Ce qui se lit :
    — Une pièce peut jouer plusieurs fois le rôle de composant ;

    — Une pièce peut jouer plusieurs fois le rôle de composé.
    Pour reprendre l’exemple des ailes d’avion : la pièce rivet peut entrer directement dans la composition d’une charnière, d’un train, d’un longeron, d’un aileron, d'une aile.

    Dans le sens inverse, une aile peut être composée directement de longerons, ailerons, trains et rivets.

    On peut observer qu’une charnière est la fois composant pour les trains et les ailerons, et composée de rivets.

    Quand on demande (très poliment) à Workbench le code SQL de déclaration des tables, il produit les deux instructions CREATE TABLE suivantes :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    CREATE TABLE PIECE
    (
            PieceId         INT              NOT NULL
          , PieceNom        VARCHAR(48)      NOT NULL
       , CONSTRAINT ARTICLE_PK PRIMARY KEY (PieceId)
    ) ;
    CREATE TABLE COMPOSITION
    (
            ComposantId       INT          NOT NULL
          , ComposeId         INT          NOT NULL
          , Quantite          INT          NOT NULL
       , CONSTRAINT COMPOSITION_PK PRIMARY KEY (ComposantId, ComposeId)
       , CONSTRAINT COMPOSITION_ENFANT FOREIGN KEY (ComposantId)
             REFERENCES PIECE (PieceId) ON DELETE CASCADE ON UPDATE NO ACTION
       , CONSTRAINT COMPOSITION_PARENT FOREIGN KEY (ComposeId)
             REFERENCES PIECE (PieceId) ON DELETE NO ACTION ON UPDATE NO ACTION) ;

    Complétons avec un jeu d’essai :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    INSERT INTO PIECE (PieceId, PieceNom) VALUES (1, 'aile') ;
    INSERT INTO PIECE (PieceId, PieceNom) VALUES (2, 'train') ;
    INSERT INTO PIECE (PieceId, PieceNom) VALUES (3, 'longeron') ;
    INSERT INTO PIECE (PieceId, PieceNom) VALUES (4, 'aileron') ;
    INSERT INTO PIECE (PieceId, PieceNom) VALUES (5, 'charnière') ;
    INSERT INTO PIECE (PieceId, PieceNom) VALUES (6, 'rivet') ;
     
    SELECT '' AS 'PIECE', * FROM PIECE ;
     
    INSERT INTO COMPOSITION (ComposeId, ComposantId, Quantite) VALUES (1, 2, 1) ;
    INSERT INTO COMPOSITION (ComposeId, ComposantId, Quantite) VALUES (1, 3, 5) ;
    INSERT INTO COMPOSITION (ComposeId, ComposantId, Quantite) VALUES (1, 4, 1) ;
    INSERT INTO COMPOSITION (ComposeId, ComposantId, Quantite) VALUES (1, 6, 100) ;
    INSERT INTO COMPOSITION (ComposeId, ComposantId, Quantite) VALUES (2, 5, 3) ;
    INSERT INTO COMPOSITION (ComposeId, ComposantId, Quantite) VALUES (2, 6, 8) ;
    INSERT INTO COMPOSITION (ComposeId, ComposantId, Quantite) VALUES (3, 6, 10) ;
    INSERT INTO COMPOSITION (ComposeId, ComposantId, Quantite) VALUES (4, 5, 2) ;
    INSERT INTO COMPOSITION (ComposeId, ComposantId, Quantite) VALUES (4, 6, 5) ;
    INSERT INTO COMPOSITION (ComposeId, ComposantId, Quantite) VALUES (5, 6, 4) ;
     
    SELECT '' AS 'COMPOSITION', * FROM COMPOSITION ;

    Une jointure récursive pour connaître le nombre de rivets utilisés en tout pour une aile d’avion (à condition que votre SGBD le permette, c'est-à-dire à peu près tous, sauf MySQL et Access) :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    WITH COMPOSITION_VUE (ComposantId, Quantite) AS
       ((SELECT ComposantId, Quantite
         FROM   COMPOSITION
         WHERE  ComposeId = 1)
    UNION ALL
       (SELECT y.ComposantId, x.Quantite * y.Quantite
        FROM   COMPOSITION_VUE AS x JOIN COMPOSITION AS y
                  ON x.ComposantId = y.ComposeId))
    SELECT SUM(Quantite) AS Quantite
    FROM   COMPOSITION_VUE 
    WHERE  ComposantId = 6 ;
    Réponse : 183 rivets pour une aile.


    Comme dit encore mon chiropraticien : « Ressentez-vous un léger mieux ? »
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  9. #9
    Membre confirmé
    Avatar de Darkaurora
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mai 2010
    Messages
    382
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2010
    Messages : 382
    Points : 549
    Points
    549
    Billets dans le blog
    1
    Par défaut
    Merci pour cette réponse précise c'est tout à fait ce que je cherchais (un avis d'expert ).

    A vrai dire j'avais donc bien fait mon MCD et MLD et donc bien créer ma table mais je trouvais qu'il y avait trop de redondance à savoir (pour reprendre l'exemple ci-dessus) :

    Plusieurs fois l'apparition d'un composant et d'un composé sans toutefois avoir la même répétition d'un composant ET d'un composé.

    Je pense que la réponse ne me satisfaisait pas et je me disais (à tort) que je pouvais créer dynamiquement une liste de composant pour un produit composé.

    En tout cas merci problème résolut !
    Je préfère fermer ma gueule et passer pour un con que de l'ouvrir et ne laisser aucun doute à ce sujet.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 6
    Dernier message: 04/07/2011, 18h12
  2. Recherche associé / collaborateur pour une SSII
    Par grandsorcier dans le forum Autres
    Réponses: 0
    Dernier message: 02/02/2011, 22h35
  3. Réponses: 6
    Dernier message: 24/01/2007, 09h15
  4. [Access 2003] Probleme avec une association reflexive
    Par softstar dans le forum Langage SQL
    Réponses: 7
    Dernier message: 17/08/2006, 14h43
  5. Combien demander en "défraiements" pour une association
    Par Anne1969 dans le forum Association
    Réponses: 9
    Dernier message: 21/09/2004, 13h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo