Bonjour je dois analyser une base de données à partir d’un fichier descriptif :
Soient :  
Table Contrat(ContratId, responsableId, AnimateurId, date, …)
Table ContactLoueur(ContLoueurId,LoueurId,nom ,…)
Table Loyer(LoyerId,ContratId,montant,…)
 
Dans la table contrat, un responsable et un animateur sont une spécialisation de ContactLoueur.
Un lien a été défini entre les tables Contrat et ContactLoueur. Je serais tenté de créer une table de liens contrat_contacts(ContratId,ContactLoueurId,responsableId,AnimateurId)
 
Un lien « direct » existe entre Contrat et Loyer, avec pour champ commun ContratId, le lien est-il implicite, ou dois-je créer une table ?
 
N’ayant que peu d’expérience dans ce domaine je voudrais être sûre de mon analyse concernant les liens. Pouvez vous m’expliquer les différents liens possibles ?

A priori, je ne pense que la la création de la table contrat_contacts soit utile, mais cela dépend de la manière dont le lien a été défini, et cela dépend de ce que l'on veut obtenir.
 

Il est inutile de créer une table supplémentaire.
Les liens sont "implicites", où plus exactement, les liens sont définis, non pas dans la base de données elle-même, mais dans les requêtes de sélection des données, dans la clause "WHERE". C'est le principe utilisé pour les bases de données qui sont gérées au moyen de requêtes SQL.
 
Avec certaines base de données, il est possible de définir des contraintes d'intégrité, mais même avec elles, il faudra que les liens adéquats soient spécifiés dans les requêtes.
 

Contraintes d'intégrité et liens ne s'agit -il pas de la même chose au final. Il s'agit bien de déclarer des clés primaires et secondaires. Dans le cas où 2 tables n'ont aucun champ en commun, il faut bien créer une table de relation, y a t'il un autre moyen?

Un lien est un lien, et une contrainte est une contrainte.
Un lien est ce qui permet de trouver les tuples d'une table qui sont liés aux tuples d'une autre table pour une requête donnée. Comme dit précédemment, le lien se fait dans la clause WHERE de la requête. Par exemple, pour avoir tous les contrat avec leur date et montant, on pourra faire :

Une contrainte d'intégrité ne fait pas de lien. Elle n'agit pas au niveau des requêtes de sélection, mais uniquement au niveau des requêtes d'insertion et de mises à jour, en vérifiant que, par exemple Loyer.ContratId existe déjà dans Contrat.ContratId.
Un lien et une contrainte ne sont pas la même chose du tout, même si un lien et une contrainte peuvent concerner les même champs.

Cela dépend de ce que l'on appelle par "champ commun". Par exemple, il n'est pas du tout obligatoire de faire un lien sur des champs qui ont le même nom. On peut écrire ...WHERE colonne_toto = colonne_titi... On peut faire une jointure sur la valeur maximum d'une colonne. On peut faire une jointure sur une sous-chaine d'une colonne. On peut faire une jointure entre une colonne d'un côté et plusieurs colonnes de l'autres côté en fonction d'une condition grâce au DECODE en Oracle ou à l'appel d'une procédure en VB. Etc. Il peut exister de nombreux cas de jointures sur des champs qui ne sont pas "communs", dans le sens où ils ne sont pas exactement similaires. La notion de "commununalité" n'existe pas dans la base. Je répète encore une fois. La mise en commun (le lien, la jointure appelons comme on le veut) est réalisé au niveau de la requête. C'est justement la grande force des bases de données relationelles. Les données sont là. Puis, ce sont les requêtes qui font les liens. Comme cela, si un jour, on veut faire des liens qui n'étaient pas prévus au départ, cela se passe sans avoir à redéfinir la base.

Je te remercie de cet éclaircissement sur les liens. Cependant mon problème actuel porte essentiellement sur les contraintes d'intégrité.  
Je suppose qu'une foreign key ne porte pas nécessairement le même nom que sa référence dans l'autre table, mais les valeurs doivent être identiques.
Soient 2 tables liées par une contrainte d'intégrité :  
2 choix possibles :  
-je crée un champ supplémentaire dans une des tables pour créer un champ commun qui sera déclaré en foreign key
-je fais une table de relation des champs qui m'intéressent en reportant les 2 clés primaires.
 
Quel choix pour quelle stratégie??
 
 

Tout dépend des cardinalités.
 
Si l'on a une relation de type n:m, alors il faut une table intermédiaire.
 
Si l'on a une relation de type 0 ou 1:n, alors une foreign key suffit.
 
Mais, attention, une erreur que l'on voit parfois, consiste à vouloir mettre des foreign keys dans les deux sens, alors que d'une part, ce n'est pas nécessaire, car il suffit de faire sa requête de sélection dans le bon sens, et d'autre part, cela fait une redondance qui peut entrainer des problèmes d'intégrité.
 
Par exemple, avec une table des employés et une table des entreprises, il peut y avoir plusieurs cas possibles selon l'univers que l'on considère :
 
Si un employé travaille dans zéro ou une entreprise, et qu'une entreprise à de 0 à n employés, alors on a une relation de type 0 : n.
Il suffit de mettre l'id de l'entreprise dans l'enregistrement de chaque employé.
Il est bien sûr impossible de mettre l'id des employé dans la table des entreprises.
Il est inutile de créer une table des liens entre les entreprises et les employés.
 
Si un employé peut travailler dans plusieurs entreprses différentes, alors on a une relation de type n : m.
Il n'est pas possible de mettre plusieurs id d'entreprise dans l'enregistrement d'un employé.
Il n'est pas possible de mettre plusieurs id d'employés dans l'enregistrement d'une entreprise.
Il faut donc créer une table des liens entre les entreprises et les employés, dans ce cas-là.
 
 
 

Merci beaucoup, tout s'éclaircit!!
 
 

Que veux-tu faire avec ces relations?Quelles sont les clés dans ta relation?

 
Avec les informations que je récupère, je dois générer les clés primaires et étrangères, qui n'ont pas été générées lors de la création des tables, en respectant les contraintes d'intégrités.
 
Je récupère les informations sous la forme :  
 
{nom du lien,table source, table destinataire, champ clé,cardinalité,type de relation, lien reverse}
 
Un exemple simple:
 
{Commande, CONTRAT, commande, contratid, n, owncopy, Contrat}
{Contrat, COMMANDE, contrat, contratid, 1, normal, -}
 
Interprétation :
1 contrat peut contenir plusieurs commandes, mais une commande est associée à un seul contrat
La suppression d'une commande n'implique pas la suppression du contrat
La suppression d’un contrat implique la suppression de toutes les commandes associées
Contratid est la clé primaire de Contrat, donc on génère une foreign key dans la table commande, avec delete on cascade pour permettre la suppression des commandes associées au contrat lors de la suppression de ce dernier.
 
 
Là, le cas est simple, mais les cas particuliers se multiplient :  
autre exemple qui me pose un peu plus de difficultés :  
 
{Fournisseur, COMMENT, fournisseur, cmtid, 1, neutral, Comment}
{Comment, FOURNISSEUR, comment, commentid, 1, owncopy, -}
 
Si on supprime un fournisseur liée à un commentaire, le commentaire associé est supprimé.
La suppression du commentaire n'implique rien sur l'entité fournisseur, ce champ n'étant pas obligatoire à l'origine.
Ici la clé primaire appartient à la table comment, ma foreign key est donc dans la table fournisseur.
Un delete on cascade implique que la suppression du commentaire engendre la suppression du fournisseur.  
Comment faire cette relation à l'inverse.
 
 
 
 

Autre type de relation problématique :  

{LoueurAssi, CONTACTLOUEUR, contrat, contloueurid, n, normal, Assistant}
{Assistant, CONTRAT, contactloueur, assistantid, 1, normal, -}
 
Interprétation :
1 Contrat est associé à un contactLoueur  
1 contactLoueur est lié à plusieurs contrats
Les 2 liens sont de type "normal", ce qui veut dire :  
la suppression d'un contrat n'implique pas la suppression du contact
La suppression du contact ne doit pas générer non plus la suppression des contrats qu'il a saisi
 
Comment ceci se traduit au niveau des contraintes d'intégrité?