structure base de données

[bloomberg99]

Bonjour, je dois créer une BDR relié au domaine de la finance. Avant de faire appel à ce forum, j'ai lu sur le sujet, mais j'aimerais avoir de l'aide de professionnel à certains niveau.

Question 1 :J'ai lu la théorie sur les clefs primaires et les clefs étrangères, mais j'ai quand même des interrogations par rapport à cela. Pour vous mettre en contexte, je dois créer une BDR qui va répertorier les transactions passées dans une domaine financier. Donc la table transaction aura comme clef primaire :numéro de transaction. Chacune des transaction que je dois répertorier se caractérise selon plusierus éléments . Exemple de caractéristique: secteur d'activité, type de transaction, Acheteur, vendeur, et beaucoup d'autres. Au départ j'avais créé différentes table ayant comme objet chacune des caractéristiques. Exemple: Table secteur, table Acheteur, table vendeur, etc. Chacune de ces tables(table secteur, table Acheteur, etc) avait comme clef primaire l'obejet relié en (format texte). Exemple: La table secteur avait comme clef primaire Secteur(format texte). Cette dernière était relié à une clef étrangère secteur(format texte) qui se retrouvait dans la table transaction(relation un-à-plusieurs). Bon j'en viens au point maintenant. D'abord, est-ce correct de créer une table pour chaque caractéristique de ma transaction, donc pour secteur, acheteur, vendeur, etc. et de les relier de la façon j'ai procédé. Si oui pourquoi?Je demande cela, car mes requête ne semble pas fonctionner avec ce type de structure. Mes requêtes fonctionnent si je créé seulement une table et que je nomme un champ pour cahcune des caractéristiques de ma transaction. Donc avec aucune relation entre les tables. Bref, j'aimerais qu'on m'explique un peu quelle serait la structure la plus logique selon le contexte..

Merci beaucoup pour l'aide, ceci est vraiment important pour moi

[marot_r]

Dificile de répondre à ta question spécfique mais voici une réponse plus générale qui, j'espère, t'aidera.

Dans une base en 3ième forme normale, qui est l'architecture recommandée pour une base de données relationnelle, tu ne dois avoir qu'un seul exemplaire d'une information et ensuite te référer à cette information. L'intérêt c'est que si tu changes l'information, tu n'as à le faire qu'à une seule place ET elle est mise à jour pour tous ceux qui l'utilisent.

Note qu'il faut parfois contourner cette règle pour des raisons d'efficacité mais cela doit rester le modèle de base.

Pour en revenir à un cas plus concret, je vais prendre un exemple simplifié de ton problème :

Une transaction a une date, un client, un code action, et un nombre d'action.

Dans ce modèle très simple tu vas avoir :

Table Client : 'Liste des clients
ClefClient
Nom et autres infos

Table CodeAction : 'Liste des codes actions
ClefCodeAction
CodeAction
Nom et autres infos

Table Transaction :
ClefTransaction 'Optionnel mais pratique, permet de facilement changer le No de transaction sans conséquence pour les données.
DateTransaction
NumeroTransaction 'Identifiant unique
ClefClient 'Se réfère à la table des clients
ClefCodeAction 'Se réfère à la tables des codes Action
NombreAction

Comme tu peux le voir tu as 4 champs qui sont spécifiques à la transaction (ClefTransaction, NumeroTransaction, DateTransaction, NombreAction) et 2 champs qui réfèrent à des listes d'éléments autorisés (ClefClient, ClefCodeAction).

Donc chaque fois que tu peux te référer à quelque chose, ce quelque chose devrait être dans une table, ou une combinaison de tables à laquelle tu te référeras par une jointure dans une requête.

Note : Parfois il est intelligent de regrouper des concepts, par exemple tu as des vendeurs et des acheteurs mais en réalité se sont des personnes donc tu pourrais avoir une table des personnes avec une table des rôles et une association entre la personne et le rôle.

Si tu n'as qu'un seul rôle possible cela donne :

Table PersonneRole :
ClefPersonne
Autres infos utiles
ClefRole

Table Role :
ClefRole
Autres infos utiles

Si une personne peut avoir plusieurs rôles :

Table Personne :
CLefPersonne
Autres infos utiles

Table Role :
ClefRole
Autres infos utiles

Table PersonneRole :
ClefPersonne
ClefRole

De même il est parfois utile d'avoir une structure plus large que nécessaire pour réduire le nombre de table. En gardant l'exemple des personnes, tu as des personnes physiques (des hommes et des femmes) et des personnes morale (Entreprise).

Les personnes physiques ont des attributs comme le sexe qu'on ne retrouvent pas pour une personne morale. De même les personnes morales ont des attributs comme le statut légal (incorporé, en nom propre, etc.) qu'on ne retrouvent pas pour une personne physique.

La logique stricte voudrait qu'on ai 2 tables ou 3 tables séparées (1 pour les attributs communs, et 2 pour les attributs spécifiques). Mais cela peut compliquer le modèle pour par grand chose, il peut être plus simple d'avoir une seule table qui comprend tous les attributs des personnes morales et physiques et d'avoir un champ qui indique si c'est une personne morale ou physique (avec un code et une référence à la tables des types de personne :-).

A+

[bloomberg99]

Merci pour cet aide!
P-A