Discussion :

[del__k]

Bonjour,

J'ai un projet à réaliser sous VBA/access (une base de données) et j'ai vraiment du mal à réaliser la conception de ma BD. Je voudrais prendre vos avis sur ce schéma relationnel:

En fait la base de données gére l'historisation et le pricing d'un produit financier (les obligations convertibles) j'ai choisi ce schéma:

Une table principale : ObligationsConvertibles <CodeObligConv , Nom, Type >
Des sous tables (qui ont chacune pour identifiant : CodeObligConv ):

- Option <CodeObligConv , .....>
- SousJacent <CodeObligConv , PrixSousJacent,....>
- Emetteur <CodeObligConv , .....>
- Pricing <CodeObligConv , .....>
- DataMarket <CodeObligConv , Prix, Vol,...>
- Rating <CodeObligConv , .....>

Est ce qu'on peut envisager le bon fonctionnement- de tels schémas ?

Je vous remercie d'avance de vos aides.

Cordialement

[Heureux-oli]

Je pense que tu commets une Erreur.

La table principale qui identifie ton produit doit bien avoir un identifiant unique.
CodeObligConv

Mais les sous-tables doivent avoir une identifiant unique propre et un rappel de ton identifiant de table principale pour avoir une référence.

Option : Id_Option;CodeObligConv;.....
Rating : Id_Rating; CodeObligConv;.....

[del__k]

Tout d'abord merci de ta réponse.

En fait je sous-entends par des sous tables , des entités faibles de ma table pricipale à savoir ObligationsConvertibles. Par exemple pour la table Options: une option est liée à une Obligation Convertible et elle est bien identifiée via l'identifiant de la table ObligationsConvertibles, en fait je voudrais remplir cette table en utilisant une fonction VBA (déjà codée) qui retourne tous les champs de la table options et qui prend en paramètre l'identifiant de l'obligation convertible.

[Heureux-oli]

Si c'est pour une relation 1 à 1 il n'est pas utile de faire plusieurs tables.
L'intérêt de plusieurs tables réside dans les relation de 1 à n, sauf si la quantité de champs totale est trop importante.

[del__k]

Oui effectivement ils ont tous des cardinalités (1,1) mais si je regroupe tous les champs dans une seule table j'aurai un truc monstrueux en nombre d'attributs, de plus le fait de regrouper les données homogènes dans des nouvelles tables me paraît très commodes pour faciliter l'ajout le calcul et l'extraction des données.
Est ce que vous pensez que mon schéma est cohérente ?

[Heureux-oli]

Combien de champs y aura-t-il au total ?

C'est un choix. Mais pour ce qui est des calcul ça ne change rien.

Certaines données sont-elle appelées à évoluer dans le temps ou toutes les données sont fixes?

[del__k]

Bonjour,

J'ai pas encore evalué le nombre total des champs mais je peux vous donner une estimation: 45 champs.

Oui il y a des champs qui évoluent au cours du temps exemple: dans la table DataMarket les prix d'une oblogation convertible ainsi que de son sous jacent changent quotidiennement. Est ce que ceci aura une influence sur mon choix de modélisation ?

Merci de votre aide

[Heureux-oli]

Oui mais c'est une question de choix.

Plutôt que de remplacer les données, je les ajouterais à une autre table, ce qui me permettrais d'avoir un historique des variations.

[del__k]

D'accord , donc c'est j'ai bien compris vous me conseillez de créer une nouvelle table par exemple Historique où je peux enregistrer les cours des obligations et de leurs sous jacents pour avoir un historique des prix ?

[Heureux-oli]

C'est juste une suggestion, mais elle me semble très raisonnable.

Dans le cas d'obligations, avoir un historique est une bonne option je pense.
Avec comme avantage, de pourvoir rectifier et retrouver une erreur.

[del__k]

Tout à fait d'accord ! Merci bien de vos réponses.