Synchronisation logique > physique : les Associations
La synchronisation des associations est disponible avec l'ancien formalisme UML qui prend en compte les associations et non les parties. Voir Formalisme logique et synchronisation.
Association contrainte (multiplicités : 0,1 ou 1,1) 
Une association contrainte est une association binaire dont la multiplicité maximum d'un de ses rôles est 1. Dans ce cas, il n'est pas nécessaire de créer une table correspondant à cette association. Une colonne rajoutée dans la table correspondant à l'entité suffit.
Une association contrainte (une de ses multiplicités maximum est à 1) ne donne pas lieu à une table. Dans l'exemple suivant, une commande comporte un client et un seul.
La synchronisation de ce diagramme de données donne l'un des deux résultats suivants :
L'association ne donne pas lieu à une table
Une colonne correspondant à la clé de l'entité "Client" est créée dans la table "Commande".
Une colonne est également créée pour chaque attribut de l'association.
Une clé étrangère "FK_Client" est ajoutée pour assurer le contrôle de la colonne "ID_Client" de la table "Commande". Elle indique que les valeurs possibles pour la colonne "Numéro Client" de la table "Commande" sont celles qui existent dans la colonne "Numéro Client" de la table "Client".
La clé étrangère ("foreign key") est créée à partir de l'identifiant de l'entité.
L'association est transformée en table
Pour que l'association se transforme en table :
1. Ouvrez la fenêtre de propriétés de l'association.
2. Cliquez sur l'onglet Caractéristiques.
3. Dans le champ Correspondance potentielle, sélectionnez la valeur "Table".
Association contrainte (multiplicités : 0,1 et 0,1) 
Dans ce cas particulier, la combinaison des multiplicités est ambiguë. Il n'y a pas d'élément permettant de choisir dans quelle table on va créer la colonne correspondant à l'attribut.
La synchronisation propose une colonne dans chaque table.
Verrous croisés (dead locks) 
Les multiplicités 1..x, 1..x signifient que chacun des deux objets doit être relié à au moins un objet de l'autre type pour pouvoir exister.
Ceci pose un problème pour créer les premiers objets de chaque type. En effet :
Un objet de type A doit exister pour pouvoir créer un objet de type B et le lui relier.
Réciproquement, un objet de type B doit exister pour pouvoir créer un objet de type A et le lui relier.
C'est le cas en particulier pour les couples de multiplicités suivants :
Multiplicités 1..*, 1..*
Multiplicités 1, 1..*
Ces cas n'amènent cependant pas d'impossibilité physique car le problème se cantonne à la création des premiers objets de chaque type. De plus, aucune clé étrangère pour effectuer le contrôle d'intégrité n'est générée dans le premier cas, et une seule dans le deuxième cas, ce qui n'amène pas à une situation de verrou croisé ("dead lock").
Les multiplicités 1, 1 génèrent plusieurs clés étrangères obligatoires croisées :
On est alors dans une situation de blocage total, car on devrait, pour respecter les contraintes, créer plusieurs tables à la fois.
Certains SGBD interdisent complètement la création de tables de ce type.
Pour permettre une synchronisation correcte, il vous faut éviter les situations de ce genre.
*Choisissez une des clés étrangères pour laquelle vous mettez la multiplicité 1 et sur l'autre, mettez 0..1. Vous pouvez également retirer la clé étrangère de la table après la synchronisation, mais c'est moins pratique.
Pour ne pas perdre l'information concernant la multiplicité minimum à 1, vous pouvez ajouter une contrainte comme celle présentée dans le diagramme qui suit. Cette contrainte ne sera pas prise en compte dans la synchronisation.
Voici un autre exemple dans le cas d'une nomenclature : Nomenclature 1, 1 ou 0..1, 1.
On veut exprimer que chaque sortie du boulevard périphérique précède une sortie et en suit une autre.
Cette modélisation oblige à créer toutes les sorties à la fois, puisque pour chaque sortie, on doit avoir créé la précédente.
Pour éviter cela, il faut mettre les deux multiplicités à 0..1 et 0..1.
Association non-contrainte  
Une association dont les multiplicités maximum sont différentes de 1 donne lieu à une table :
Une colonne est créée pour chacun des attributs des identifiants des entités reliées.
La clé primaire de la table porte sur l'ensemble de ces colonnes.
Une clé étrangère est également constituée pour chaque entité reliée.
Une colonne supplémentaire est créée pour chaque attribut de l'association.

Avant de lancer la synchronisation, il est souhaitable de contrôler la validité du diagramme de données, et de contrôler que le paramétrage de la synchronisation est correct. Voir Préparer la synchronisation.
Classe associative  
Les associations reliant des classes associatives ne sont pas prises en compte dans la synchronisation.