Relations entre les tables 1:n etc

Bonjour.

J'ai fait le tour à propos des jointures et avec l'aide de programme tel que Workbench et Navicat, je me suis mis à pratiquer des jointures.

Être capable de le faire me suffit pas. Je veux en savoir plus sur les relations entre les tables.

Alors, en utilisant Workbench, ça m'a permis de mieux saisir à propos des "clé étrangère".

J'ai tombé sur n:m, 1:m etc.

Un exemple de ce que j'ai compris:

A ---- 1,n ---- B

A peut contenir plusieurs B, mais pas B.

Je cherche pour trouver la définition de tout les syntaxes possibles.

Bon, à propos de LEFT JOINT, oui, je suis tombé sur une image qui illustre l'idée mais j'aimerais phraser ça. Ça ressemble à l'illustration de A et B.

A mon poste, précédent, je vais y revenir pour mon devoir Cyrano :-)
et merci de m'aider à persévérer.

Salut Dancom5,
tes découvertes ont un nom : lorsqu'on modélise une base de données, on commence en général par créer un modèle conceptuel et on manie le concept de relation Entité/Propriété. Si on crée un annuaire, on a par exemple un certain nombre de mots-clés : nom, prénom, abonné, téléphone, numéro : à partir de ce micro-dictionnaire de données, on va devoir isoler ceux qui sont des entités de ceux qui sont des propriétés d'une de ces entités. Ainsi, on détermine rapidement que abonné et téléphone sont des entités, nom et prénom sont des propriétés de l'entité abonné, numéro est une propriété de l'entité téléphone.

Là, je simplifie à l'extrême bien entendu pour que ça reste clair : si on continue sur cet exemple, on conçoit rapidement qu'un abonné peut avoir 1 à n numéros de téléphones, mais dans l'autre sens, un téléphone appartient à un et un seul abonné

C'est au niveau conceptuel qu'on définit ces relations : lorsque le modèle conceptuel est au point, on avance vers le « modèle physique » : les entités deviennent des tables, leurs propriétés en sont les colonnes.

Et les jointures, elle permettent de relier les informations entre les différentes entités : au niveau conceptuel, on indique jamais de clé étrangères et on ne parle pas de tables ni de colonnes : c'est lorsqu'on avance au niveau du modèle physique que les tables apparaissent, y compris parfois des tables qui, sur le modèle conceptuel, n'apparaissent pas du tout : si on a une relation 1:n/1-n, c'est à dire, pour garder l'exemple de mon annuaire, que si on songe à un numéro de téléphone fixe, on dirait qu'il peut appartenir à plusieurs abonnées qui résident au même endroit, ma relation entre l'entité abonné et l'entité téléphone devient 1:n/1:n et lors du passage au modèle physique, j'aurai une table abonne, une table telephone et entre les deux apparaitra une table abo_has_tel : pour créer une liste avec mes abonnées et leurs numéros, ma requête SQL comportera alors deux jointures permettant de lier le tout.

Est-ce que c'est moins nébuleux comme ça ?