Exemple simple de relation Many:Many et One:Many

Version imprimable

Salut,

J'ai besoin que quelqu'un me fasse un exemple simple pour m'expliquer les relations.
Les bases de données n'étant pas mon domaine je suis perdu et je n'arrive pas avoir la différence.

Je donne un schéma Yaml :

Les 5 tables :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 Atelier: columns: name: { type: string(255), notnull: true } Annexe: columns: name: { type: string(255), notnull: true } Batiment: columns: name: { type: string(255), notnull: true } abbreviation: { type: string(20), notnull: true } Tag: columns: name: { type: string(255), notnull: true } batiment_id: { type: integer, notnull: true } atelier_id: { type: integer } annexe_id: { type: integer } zone_cmr: { type: boolean, notnull: true, default: 0 } Intervention: columns: label: { type: string(255), notnull: true } intervenant : { type: string(255), notnull: true } tag_id : { type: integer }
Les conditions :

Un atelier peut être associé à un ou plusieurs TAG
Une annexe peut être associée à un ou plusieurs TAG
Un bâtiment peut être associé à un ou plusieurs TAG
Un tag peut être associé à une ou plusieurs Intervention
Une Intervention est associée à un TAG

Comment dois-je definir mes relations et de quelle type sont-elles ?
Merci d'avance.

02/04/2011, 13h49
Michel Rotta

Est-ce qu'un même tag peut être utilisé pour un atelier, une annexe, un bâtiment ?

Il va y avoir plus de 5 tables à terme.
03/04/2011, 11h41
llaffont

J'ai peut être mal conçu mon exemple.
Je vais tenter de mieux présenter le contexte.

Un TAG est un élément unique sur lequel on doit intervenir
Ce TAG est situé (géographiquement) grâce à son Bâtiment, son Atelier et/ou son annexe.

Donc une intervention est reliée à un TAG qui lui même est relié à son Bâtiment, son Atelier et/ou son annexe.

Dsl ! Si je mon exemple devient compliqué. Mais c'est la dur réalité a laquelle je suis confronté actuellement et mon exemple est pourtant simple par rapport au projet final :(
04/04/2011, 10h09
Michel Rotta

C'est TAG qui est mal choisi. Il donne l'impression que c'est une information collée sur bâtiment ou atelier ou... alors que c'est l'élément principale.

Bon, partant de ce que tu dis, est-ce qu'un tag peut appartenir à plusieurs bâtiments (ou atelier ou annexe) ? Est-ce qu'un tag peut appartenir simultanément à un bâtiment, deux annexes et un atelier ? Ou un bâtiment, une annexe et un atelier ?
04/04/2011, 10h24
llaffont

Non, un TAG est unique.

Un bâtiment peut appartenir à plusieurs TAG
Un atelier peut appartenir à plusieurs TAG
Une annexe peut appartenir à plusieurs TAG
Un TAG contient au minimum un Atelier et Bâtiment
Une intervention contient un seul et unique TAG
Un intervenant possède plusieurs intervention.

J'ai vraiment l'impression d'abuser de toi . :calim2: J'ai pas du prendre le meilleur exemple mais comme c'est mon contexte actuel je ne m'éloigne pas trop.

Je devrais avoir un développeur dans les semaines a venir mais pour l'heure mon projet doit avancer donc je m'adapte :cry:
04/04/2011, 10h43
Michel Rotta

je cerne un peu mais j'ai du mal à voir le contexte many to many là.

Un Tag peut avoir plusieurs bâtiment ? Ou plusieurs quelque chose ?

Quel est l'intérêt d'avoir une table bâtiment, une atelier et une annexe ? Ne pourrais-tu pas avoir une table lieu avec un champ type de lieu ?

Quel est l'intérêt d'avoir une table TAG liée en one to one à une table intervention ? Pourquoi ne pas fusionner les deux ?
04/04/2011, 14h04
llaffont

C'est vrai que la question se pose "Pourquoi autant de table".

Je travaille sur un site pétrochimique tous les équipements (machine, vanne, compteur,...) sont identifiés par un TAG. Le site compte une trentaine de Bâtiments divisés en Atelier qui à leur tour peuvent être divisés en annexe.

Mon projet consiste a produire un formulaire d'intervention accessible en front.
Mais en back les gestionnaires doivent définir les intitulés des champs "select" du form.

Comme j'ai un nombre important de champs prédéfini j'ai du éclater ma table à cause de la répétition.

Un bâtiment peut se retrouver dans plus de 40 000 TAG. Il me semblait plus judicieux de stocké un ID (int) que Name (string)

Les personne identifié vont générer, puis remplir un formulaire en identifiant le TAG sur lequel ils viennent d'intervenir, puis renseigner l'opération effectuée.

Si le TAG n'existe pas dans la base il devront pouvoir le générer en renseignant les infos essentielles (Batiment, Atelier, Annexe et Name)

N'ayant aucune connaissance en BDD je cherche a différencier le One:One, One:Many et le Many:Many.

Mais mon exemple n'est peut être pas bon.
04/04/2011, 17h49
Michel Rotta

Citation:

Envoyé par llaffont

C'est vrai que la question se pose "Pourquoi autant de table".

Pas d'inquiétude, en dessous de 100 tables on va considérer cela comme un petit projet :D

Citation:

Envoyé par llaffont

Mon projet consiste a produire un formulaire d'intervention accessible en front.
Mais en back les gestionnaires doivent définir les intitulés des champs "select" du form.

Là je prend le premier cachet de paracétamol... Partons des données sans penser aux écrans de saisies, ça c'est l'étape suivante... si on survis à l'analyse du schéma :aie:

Citation:

Envoyé par llaffont

Comme j'ai un nombre important de champs prédéfini j'ai du éclater ma table à cause de la répétition.

En général, si on retrouve de nombreux champs entre plusieurs table, on aurait plutôt tendance à factoriser... C'est quoi un champ prédéfini ?

Citation:

Envoyé par llaffont

Un bâtiment peut se retrouver dans plus de 40 000 TAG. Il me semblait plus judicieux de stocké un ID (int) que Name (string)

Oui. Mais qu'il y ait une table bâtiment (qui regroupe les bâtiments, les atheliers et les annexes) ou trois tables c'est toujours vrai et c'est toujours réalisable...

Citation:

Envoyé par llaffont

Les personne identifié vont générer, puis remplir un formulaire en identifiant le TAG sur lequel ils viennent d'intervenir, puis renseigner l'opération effectuée.

"Les personnes identifiées..." va regarder du côté du plugin sfDoctrineGuardPlugin (salle plugin, sujet sur les plugins les plus utilisé, il est épinglé).

On est dans l'utilisation, étape deux...

D'abord il faut définir la structure des données...

Citation:

Envoyé par llaffont

Si le TAG n'existe pas dans la base il devront pouvoir le générer en renseignant les infos essentielles (Batiment, Atelier, Annexe et Name)

Chouette, on reste dans l'utilisation...

Citation:

Envoyé par llaffont

N'ayant aucune connaissance en BDD je cherche a différencier le One:One, One:Many et le Many:Many.

Tu n'auras pas le choix, les types de relations s’imposeront naturellement en fonction de l'analyse, encore faut-il avoir fait l'analyse ! Pour information 97% des relations sont des 1-n, 2% des n-n et le reste des trucs rare dont le 1-1.

Donc, il faut répondre au questions du message précédent.

Faire des petites listes des données regroupées par type de bâtiment, pour le TAG (j'ai toujours pas compris ce qu'était réellement le TAG), pour l'intervention (si le TAG n'est pas l'intervention), pour les intervenants (penses à sfGuard) et les données que tu ne peux pas rattacher à l'une de ces entités. Après, on fait le tris et on envisage les répartitions en entités (tables).
Mais mon exemple n'est peut être pas bon.[/QUOTE]

Citation:

Envoyé par Michel Rotta

C'est quoi un champ prédéfini ?

Les techniciens qui vont remplir les comptes rendus d'intervention vont utiliser des PC Tablette. Afin de limiter la saisie nous avons opté pour des balises "Select/Option" pour les champs ayant des informations récurrente comme le nom d'un bâtiment, d'un atelier, ...

Citation:

"Les personnes identifiées..." va regarder du côté du plugin sfDoctrineGuardPlugin

J'avais déjà prévu ce plugin. Merci de conforté mon choix :D.

Citation:

D'abord il faut définir la structure des données...

J'espère répondre à ton besoin car je ne l'ai pas vraiment compris :?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
 
sfGuardUser:
  User_testeur:
    first_name:     test
    last_name:      testeur
    email_address:  john.doe@gmail.com
    username:       testeur
    password:       testeur
 
Annexe:
  Travee:
    Name: Travée
 
Atelier:
  emul:
    Name: Emulsion
  bille:
    Name: Billes
  acry:
    Name: Acrylamide
 
Batiment:
  Batiment1:
    Name: Bâtiment 01 
    Abbreviation: B01  
  Batiment2:
    Name: Bâtiment 02 
    Abbreviation: B02  
  Batiment3:
    Name: Bâtiment 03 
    Abbreviation: B03  
  Batiment4:
    Name: Bâtiment 04 
    Abbreviation: B04  
  Batiment5:
    Name: Bâtiment 05 
    Abbreviation: B05  
 
Tag:
  b01-V1-CS1AN:
    Batiment:  Batiment1
    Atelier:  emul
    Zone_cmr:  true
    Name:  b15-V1-CS1AN
  b02-V2-CS1AN:
    Batiment:  Batiment2
    Atelier:  emul
    Annexe: Travee
    Zone_cmr:  true
    Name:  b11-V2-CS1AN
 
Intervention:
  20110315480001:
    Num_inter:      '1'
    Label:    '20110315480001'
    sfGuardUser:    User_testeur
    Poste:    matin
    Tag:      b01-V1-CS1AN
    Probleme: disjoncte
    Cause:    support
    CodeAffaire:  CA2011
    Demandeur:    dupont
    Category:    '472'
    Happel:     '2011-03-15'
    Hdeb:       '2011-03-15'
    Hfin:       '2011-03-15'
    Nppi:       '1234567890'
    Nar:        '1234567890'
    Solution:    ''
  20110315570002:
    Num_inter:      '2'
    Label:    '20110315570002'
    sfGuardUser:    User_testeur
    Poste:    soir
    Tag:      b02-V2-CS1AN
    Probleme: interms
    Cause:    recablage
    CodeAffaire:  CA2011
    Demandeur:    dupont
    Category:    '481'
    Happel:     '2011-03-15'
    Hdeb:       '2011-03-15'
    Hfin:       '2011-03-15'
    Nppi:       '1234567890'
    Nar:        '1234567890'
    Nmo:        '1234567890'
    Solution:    |
      Lorem Elsass ipsum Strasbourg Gal. mollis suspendisse sed 
      Wurschtsalad tchao bissame dui Coopé de Truchtersheim Pellentesque
      picon bière schpeck Spätzle Oberschaeffolsheim pellentesque nüdle
      hoplageiss amet orNare et purus blottkopf, merci vielmols eget
      id Richard Schirmeck barapli hopla adipiscing turpis wurscht
      consectetur libero, commodo rucksack gravida Heineken ch'ai
      tristique Yo dû. jetz gehts los rhoncus vielmols, so bredele semper
      risus, hop in, gewurztraminer quam. Pfourtz ! sit ac nullam réchime
      ftomi! auctor, Salut bisamme amet, Kabinetpapier non yeuh. id, 
      hopla varius ante Hans kuglopf morbi senectus mänele dignissim 
      bissame Carola eleifend quam, chambon Huguette und météor Morbi 
      schnaps ullamcorper salu placerat rossbolla ac kartoffelsalad sit 
      libero, turpis, Verdammi messti de Bischheim Oberschaeffolsheim 
      lacus schneck wie munster Miss Dahlias DNA, Gal ! vulputate 
      Chulien hopla habitant mamsell libero. Chulia Roberstau elit 
      tellus geht's sed aliquam gal condimentum Salu bissame elementum 
      hopla s'guelt kougelhopf sit flammekueche lotto-owe tellus 
      leverwurscht Racing. sagittis amet leo Christkindelsmärik dolor 
      geïz knack Mauris knepfle porta baeckeoffe orNare non leo. 
 
  20110316520001:
    Num_inter:      '1'
    Label:    '20110316520001'
    sfGuardUser:    User_testeur
    Poste:    soir
    Tag:      b01-V1-CS1AN
    Probleme: interms
    Cause:    recablage
    CodeAffaire:  CA2011
    Demandeur:    dupont
    Category:    '490'
    Happel:     '2011-03-16'
    Hdeb:       '2011-03-16'
    Hfin:       '2011-03-16'
    Nppi:       '1234567890'
    Nar:        '1234567890'
    Nmo:        '1234567890'
    Resolu:     true
    Solution:    'C\'est tout cassé'
  20110316290002:
    Num_inter:      '2'
    Label:    '20110316290002'
    Tag:      b02-V2-CS1AN
    CodeAffaire:  CA2011
    Demandeur:    dupont
    Category:    '490'
    Happel:     '2011-03-16'
    Hdeb:       '2011-03-16'
    Hfin:       '2011-03-16'
    Nppi:       '1234567890'
    Nar:        '1234567890'
    Nmo:        '1234567890'
    Resolu:     false

Beaucoup d'information mais c'est un simple copié collé de mes fixtures.

J'ai un dépôt GIT pour versionner mon projet si cela t'intéresse je te le communiquerais.

La structure des trois bâtiment garderait à être unifiée.

Donc on se retrouve avec un schéma simplifié suivant

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
//shema.yml
Lieu:
  columns:
    nom_court: 
      type: string(10)
      notNull: true
      unique: true
    nom: string(100)
    type: integer(1)
    // le type peut être 1 pour bâtiment, 2 pour atelier et 3 pour annexe. 
    parent_id: integer
  relations:
    EstDans:
      class: Lieu
      local: parent_id
      foreign: id
      foreignAlias: LieuInclus
 
Tag:
  columns:
    batiment_id: integer
    atelier_id: integer
    annexe_id: integer
    nom: string(100)
  relations:
    batiment:
      class: Lieu
      local: batiment_id
      foreign: id
      foreignAlias: BatimentTags
    atelier:
      class: Lieu
      local: atelier_id
      foreign: id
      foreignAlias: AtelierTags
    annexe:
      class: Lieu
      local: annexe_id
      foreign: id
      foreignAlias: AnnexeTags
 
Intervention:
  columns:
    num_inter:
      type: integer
      notnull: true
      unique: true
    label: string(50)
    user_id: integer
    tag_id: integer
    ...
  relations:
    tag:
      foreignAlias: interventions
    user:
      class: sfGuardUser:
      local: user_id
      foreign: id
      foreignAlias: interventions

Un exemple de ce que pourrait être le schéma simple.

Il est possible de l'élaborer un peu plus en passant par de l'héritage sur la table lieu. Ce qui est peut-être souhaitable.

Qu'en penses-tu ?

Cela pourrait être envisagé. c'est effectivement plus correct
Comme je voulais faire quelques chose de propre pour les acteurs devant renseigner les intitulés de ces bases, à destination des champs Select, j'avais opté pour la séparation des biens :mouarf:

Si je garde ta proposition comment tu génères le Tag.yml du data ?
Code:

1 2 3 4 5 6 7 Tag: b11-V2-CS1AN: batiment_id: Lieu1 atelier_id: Lieu3 annexe_id: Lieu5 Zone_cmr: true Name: b11-V2-CS1AN
En partant du principe que Lieu a cette tronche :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 Lieu: Lieu1: nom_court: B0 nom: Bâtiment 0 type: '1' Lieu2: nom_court: B1 nom: Bâtiment 1 type: '1' Lieu3: nom_court: nom: Billes type: '2' Lieu4: nom_court: nom: Emulsion type: '2' Lieu5: nom_court: nom: Témis type: '3'

06/04/2011, 10h19
Michel Rotta

oui :ccool:

Petite interrogation ...

C'est quoi parent_id dans Lieu ?
Il faut lui donner une valeur ou il la prend de lui même ?

Car si je tente l'injection des datas des TAG j'obtiens ceci :

Citation:

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`criels`.`tag`, CONSTRAINT `tag_atelier_id_lieu_id` FOREIGN KEY (`atelier_id`) REFERENCES `lieu` (`id`))

Mon Schéma Lieu & Tag :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
Lieu:
  columns:
    NameShort: 
      type: string(10)
      unique: true
    Name: 
      type: string(100)
      notnull: true
    Type: 
      type: integer(1)
    # le type peut être 1 pour bâtiment, 2 pour atelier et 3 pour annexe. 
      notnull: true
    Parent_id: integer
  relations:
    EstDans:
      class: Lieu
      local: Parent_id
      foreign: id
      foreignAlias: LieuInclus
Tag:
  actAs: [Timestampable]
  options:
    collate: utf8_unicode_ci
    charset: utf8
  columns:
    Name: { type: string(255), notnull: true }
    Batiment_id: { type: integer, notnull: true }
    Atelier_id: { type: integer }
    Annexe_id: { type: integer }
    Pdf_id:  { type: integer }
    Zone_cmr: { type: boolean, notnull: true, default: 0 }
  relations:
    Atelier:
      class: Lieu
      local: Atelier_id
      foreign: id
      foreignAlias: atelierTags
    Batiment:
      class: Lieu
      local: Batiment_id
      foreign: id
      foreignAlias: batimentTags
    Annexe:
      class: Lieu
      local: Annexe_id
      foreign: id
      foreignAlias: annexeTags
    Pdf:
      class: Pdf
      local: Pdf_id
      foreignAlias: tag_pdfs

Mes Data :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
Tag:
  b01-V1-CS1AN:
    Batiment_id:  Lieu1
    Atelier_id:  Lieu21
    Annexe_id: Lieu26
    Zone_cmr:  false
    Name:  b01-V1-CS1AN
 
Lieu:               
  Lieu1: 
    Name: Bâtiment 1   
    NameShort: B01     
    Type: 1       
  Lieu2: 
    Name: Bâtiment 2   
    NameShort: B02     
    Type: 1       
  Lieu3: 
    Name: Bâtiment 3   
    NameShort: B03     
    Type: 1       
  Lieu4: 
    Name: Bâtiment 4   
    NameShort: B04     
    Type: 1       
  Lieu5: 
    Name: Bâtiment 5   
    NameShort: B05     
    Type: 1       
  Lieu6: 
    Name: Bâtiment 6   
    NameShort: B06     
    Type: 1       
  Lieu7: 
    Name: Bâtiment 7   
    NameShort: B07     
    Type: 1       
  Lieu8: 
    Name: Bâtiment 8   
    NameShort: B08     
    Type: 1       
  Lieu9: 
    Name: Bâtiment 9   
    NameShort: B09     
    Type: 1       
  Lieu10  :        
    Name: Bâtiment 10  
    NameShort: B10     
    Type: 1       
  Lieu11  :        
    Name: Bâtiment 11  
    NameShort: B11     
    Type: 1       
  Lieu12  :        
    Name: Bâtiment 12  
    NameShort: B12     
    Type: 1       
  Lieu13  :        
    Name: Bâtiment 13  
    NameShort: B13     
    Type: 1       
  Lieu14  :        
    Name: Bâtiment 14  
    NameShort: B14     
    Type: 1       
  Lieu15  :        
    Name: Bâtiment 15  
    NameShort: B15     
    Type: 1       
  Lieu16  :        
    Name: Bâtiment 16  
    NameShort: B16     
    Type: 1       
  Lieu17  :        
    Name: Bâtiment 17  
    NameShort: B17     
    Type: 1       
  Lieu18  :        
    Name: Poste de Garde
    NameShort: B2      
    Type: 1       
  Lieu19  :        
    Name: Billes      
    Type: 2       
  Lieu20  :        
    Name: Faviers     
    Type: 2       
  Lieu21  :        
    Name: Emulsions       
    Type: 2       
  Lieu22  :        
    Name: Spray       
    Type: 2       
  Lieu23  :        
    Name: Liquide     
    Type: 2       
  Lieu24  :        
    Name: Travée  1   
    Type: 3       
  Lieu25  :        
    Name: Travée  2   
    Type: 3       
  Lieu26  :        
    Name: Travée  3   
    Type: 3

06/04/2011, 14h14
Michel Rotta

Dans mon id parent_id permettrait de savoir dans quel bâtiment tel atelier se trouve, idem pour les annexes aux ateliers.
06/04/2011, 14h23
llaffont

Je comprends !

Mais ce n'est pas le contexte de mon projet.
Ici on parle d'intitulé de "lieu" ils peuvent être mis en relation ou pas.

Petit exemple :
Le Bâtiment 01 comporte un atelier Billes et aucune annexe.
Le Bâtiment 02 comporte également un atelier Billes situé dans la travée 1.
Donc je ne peux pas faire de relation Parent_id.

La relation que tu voulais faire est effectué au niveau de la table TAG.
Pour chaque tag j'ai bien un bâtiment, un atelier et/aucune annexe.

Donc j'ai supprimé la contraint "LieuInclus" Mais cela ne change rien au problème j'ai toujours le même message indiquant que je ne peux pas insérer de lieu dans tag car il ne connais pas l'id que lui communique.

C'est bien ce que veut dire le message suivant ?

Citation:

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`criels`.`tag`, CONSTRAINT `tag_atelier_id_lieu_id` FOREIGN KEY (`atelier_id`) REFERENCES `lieu` (`id`))
06/04/2011, 18h32
Michel Rotta

Il faudrait plus d'information sur le contexte de ce que tu veux ajouter. Quels données, d'où viennent t-elles ?
06/04/2011, 20h43
llaffont

Ce sont les données de Test. Celles que tu injectes lors d'un

Code:

symfony doctrine:data-load

Les mêmes que j'ai présenté 4 postes plus haut.

J'ai testé l'injection individuel de chaque table via symfony doctrine:data-load nomDuFichier.yml (car j'ai scindé mes table en plusieurs fichiers cela me semble plus simple a gérer) toute fonctionne

Seule l'injection de TAG ayant une relation avec Lieu plante et bien entendu celle qui ont des relation avec TAG :mouarf:
07/04/2011, 08h27
Michel Rotta

Il faut mettre le nom de la relation dans le fixture, pas le nom du champ de liaison.
07/04/2011, 08h54
llaffont

Peux-tu me donner un exemple ?

Car il me semble avoir essayé en mettant le nom des relations et avoir obtenu un message d'erreur lors de l'intégration des datas
07/04/2011, 09h27
Michel Rotta
Il FAUT mettre le nom des relations.
Code:

1 2 3 4 5 6 7 8 Tag: b01-V1-CS1AN: Batiment: Lieu1 Atelier: Lieu21 Annexe: Lieu26 Zone_cmr: false Name: b01-V1-CS1AN
Si l'on définit sur une table du côté "n" d'une relation "1-n" il faut de plus mettre les noms (même s'il n'y en a qu'un) entre [] séparé avec des ","