Discussion :

[Mistigri5]

Bonjour à toutes et à tous,

Comment allez-vous ? Je me permets de venir vous déranger quelques instants car je suis en train de céer une base de donnée liée à Excel.

Le fichier Excel se compose de 5 colonnes :

*première Colonne : Nom de l'action
*Les colonnes suivantes se composent de différentes notes.

Le ficheir Excel se mets à jour quotidiennement avec de nouvelles notes. Je voudrais créer une base de donnée pour historiser les veilles notes. Malheureusmenent, je ne sais pas par ou m'y prendre. Je pensais mettre enc lé primaire le nom de l'action puis créer des champs pour les notes.

Je ne sais cependant pas comment faire intervenir la date dans tout ça... Est ce que je dois utiliser une sorte de clé primaire composite du nom de l'action et de la date...?

Avant de m'aider, est-ce que vous avez peut etre des tutoriaux ou des pistes de réflexion avant que j'entame la création?

Merci à vous,

Cordialement,

Boris Rochereuil

[fsmrel]

Bonsoir Boris,


Supposons que vous mettiez en œuvre une table, appelons-la ACTION, ayant pour en-tête le triplet {NomAction, Note, DateNote}, où les noms d’attributs NomAction, Note, DateNote, représentent respectivement le nom d’une action, une note associée à cette action et la date à laquelle la note a été associée à l’action :

ACTION {NomAction, Note, DateNote}

Les lignes de la table en constituent le corps, lequel est en fait un ensemble. A ce titre, les éléments de cet ensemble (c'est-à-dire les lignes de la table) sont distincts, il n’y a pas de possibilité de doublons, à défaut la table serait ravalée au rang de sac et les opérations relationnelles, qui sont ensemblistes, ne fonctionneraient plus. Pour garantir l’unicité des lignes de la table, on dote celle-ci d’un dispositif ad-hoc, à savoir une clé primaire, qui est un sous-ensemble (non strict) des noms des attributs composant l’en-tête de la table. Cette clé, appelons-la K, doit vérifier les deux règles suivantes :

1. Unicité. Deux lignes distinctes ne peuvent pas avoir simultanément la même valeur de K.

2. Irréductibilité. Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.

Maintenant entrent en jeu les règles de gestion :

Si on a la règle suivante :

(R1) Pour une action quelconque A, à une date quelconque D, il peut y avoir plusieurs notes (distinctes), alors la clé primaire K est le triplet suivant :

{NomAction, DateNote, Note}

=>

 
NomAction    DateNote    Note
a1           d1          n1
a1           d1          n2
a1           d1          n3
a1           d2          n4
a1           d2          n5
...          ...         ...
 

Si la règle est plutôt la suivante :

(R2) Pour une action quelconque A, à une date quelconque D, il ne peut y avoir qu’une seule note, alors le triplet est réductible et la clé primaire K est donc la paire (non réductible) :

{NomAction, DateNote}

=>

 
NomAction    DateNote    Note
a1           d1          n1
a1           d2          n2
...          ...         ...
 

Si c’est la règle R1 qui est la bonne, évitez les représentations du genre (où la clé est réductible, soulignée ici) :

{NomAction, DateNote, Note1, Note2, ..., Noten}

En effet, les tables sont faites pour être manipulées verticalement et non pas horizontalement.