Bonjour,
Je ne sais pas si je vais bien répondre aux questions mais de manière générale la meilleur façon d'aborder la constitution d'une base de donnée est de normaliser la structure ... Et de "dénormaliser" après coup si le besoin s'en fait sentir. Pour cela, je me reporte aux travaux de Boyce Codd qui utilise la théorie de la normalisation en se basant sur le concept des formes normalisées (FN.)
Les FN sont basées sur les relations, des types particuliers de tables, possédant certains attributs.
- Elles doivent décrire une entité.
- Elles n'ont pas de doublons (clé primaire "obligatoire".)
- Pas d'ordonnancement des colonnes.
- Pas d'ordonnancement des enregistrement.
Boyce Codd a décris cinq FN.
- 1ère FN
La première forme normale dit que toutes les valeurs des colonnes doivent être indivisibles. Cette règle nous permettra de pouvoir faire des tris ou des recherches sur l'intégralité des champs constituant les enregistrements.
1FN interdit aussi de répéter des groupes d'informations même si ceux-ci sont situés dans des colonnes différentes. Ceci évitera le gaspillage de place et bannira les tables contenant une colonne par item à rattacher à un enregistrement. (Comme je ne suis pas certain d'être très clair je vais donner un exemple de ce qu'il ne faut pas faire. Une table "Caisse à outils" contenant les champs "Outils1", "Outils2", "Outils3", ... Tant que le nombre d'outils reste en dessous du nombre de colonnes prévues, pas de souci (hormis les places laissées libres et chargeant donc la mémoire inutilement) mais quid du jour où on aura un outil de trop à renseigner ? Il faudra donc créer une table "Outils" les listant et une table "Caisse à outils" avec le numéro de la caisse et les numéros des outils à y joindre enregistrement par enregistrement. (Hum... je ne suis pas sûr d'avoir fait plus limpide
.))
- 2ème FN
Une table est dite conforme à 2FN si elle respecte la première FN et si toutes les colonnes qui ne sont pas des clés dépendent entièrement de la ou des clé(s) primaire(s). Si nous voulions adjoindre un descriptif des outils précédemment cités, nous devrions les intégrer à la table Outils et non à la table principale. Dans ce cas, ça semble logique mais parfois il faudra créer une nouvelle table pour répondre à cette forme normale.
- 3ème FN
Une table est dite conforme à 3FN si elle respecte la seconde FN et si toutes les colonnes hormis les clés sont mutuellement indépendantes. Autrement dit, si nous voulions calculer le prix des outils en fonction de la valeur de l'un d'entre-eux et de sa quantité il ne faudrait pas créer une colonne de calcul car cette dernière serait dépendante des deux autres colonnes. L'objectif de cette FN est d'éviter de gérer la mise à jour de plusieurs champs lorsque l'on a besoin de n'en changer qu'un seul.
Les formes normales plus évoluées viennent ensuite pour palier aux manques de la 3ème FN. Elles interviennent dans des cas plus spécifiques qu'il n'est pas réellement utile de commenter. En respectant 3FN, on a pratiquement atteint le niveau de la FN de Boyce Codd et il s'avère improbable de devoir revenir sur la structure à postériori.
Ces règles ne sont que des règles de bon sens et une fois intégrées, nous pouvons nous permettre de dénormaliser certaines tables dans certains cas précis.
Pour la question 2, oui et oui. Basic sera suffisant pour mettre en forme les données en fonction des attributs ou autres.
Pour la 3, je ne connais pas encore assez Base pour me prononcer mais je pense qu'il est possible d'utiliser une BDD (de données pures) grâce à une ou plusieurs autre bases dites moteurs et sans données. Comme il sera également possible de créer un base SQL indépendante.
J'espère ne pas être trop parti hors sujet et avoir été assez clair.
