Discussion :

[Fran34]

Bonjour,
Je ne sui spas sur d'être au bon endroit
Si c'est le cas, où puis-je soumettre ces propositions d'organisation de tables

Je suis en train de constuire (re-construire en fait) une BDD pour gérer mes divers types de documents : livres, articles de revues, articles d'ouvrages collectifs, thèse, documents numériques, etc.

En suivant les conseils constamment donnés par les experts j'ai tenu compte des messages précédents et des tutoriels en ligne

Pouvez-vous me cnfirmer que je suis sur la bonne piste pour ma création dont les éléments actuels sont les suivants :
- une table auteurs, autant de tables que de types de documents (donc une table livres, une art de revues, une art d'ouvrcollectifs, une de thèse, etc), puis une table infoDoc (regroupant des caractéristiques de ces types de documents (par exemple, origine (d'où vient le doc) ; rangement (où il est dans ma bibliothèque), motsclés (les divers thèmes qui sont traités dans ce document, etc)

Question : est-il judicieux d'avoir effectivement une table par type de doc (puisqu'en effet, chaque auteur peut avoir écrit un livre, mais aussi des art de rev, des art d'ouv collectifs, une thèse, etc)

Ensuite, pour les relations,
- puisque chaque auteur peut "écrire" dans chaque type de doc, il faut une relation 1 (auteur) à plusieurs (typ de doc)
- puisque les infos peuvent se retrouver dans plusieurs typ de doc (ces docs peuvent en effet traités de memes thèmes (motsclés) communs, avoir été trouvés dans une meme bibliothèque, etc.

Question : Mais ils ne sont pas rangés au meme endroit dans ma bibliothèque, ils n'ont d'ailleurs pas le meme n° dans la bibliothèque d'origine

Donc, si j'arrive assez bien, grace aux diverses aides trouvées ici et là à comprendre les relations entre tables, j'ai encore du mal à trouver ce qui est bien à sa place dans une table ou ce qui devrait plutot être ailleurs, donc dans une nouvelle table

Merci pour votre attention à mes préoccupations

Je viens de passer sous Access 2007 (pour pouvoir mettre plusieurs motsclés dans le meme champ) mais j'ai toujours accès à la version 2003

Merci
A+
Fran34

[hed62]

Peux tu envoyer un schéma s'il te plait ? Ce sera plus simple que bcp de blabla

Je ne sui spas sur d'être au bon endroit

Si si

Question : est-il judicieux d'avoir effectivement une table par type de doc (puisqu'en effet, chaque auteur peut avoir écrit un livre, mais aussi des art de rev, des art d'ouv collectifs, une thèse, etc)

Je pense que ça l'est, surtout si certain doc sont completement different des autres.

(pour pouvoir mettre plusieurs motsclés dans le meme champ)

J'ai peur de comprendre que tu souhaite mettre plusieurs valeur dans un meme champs, le tout séparé par un délimiteur quelconque... C'est absolument à proscrire.

[Fran34]

Merci
Voici en doc joint un début de schéma avec les relations

Concernant les motsclés (valeur) dans un seul champ, quels sont les inconvénients ??
Je ne peux pas définir autant de champs que de motsclés probables car je ne sais pas à l'avance combien de motsclés seront définis pour caractériser ce qu'il y a donc un doc

Et surtout cela cerait plus fastidieux à al saisie et plus problématique pour les requêtes ?

Merci pour l'aide à l'analyse
Fran34

[fsmrel]

est-il judicieux d'avoir effectivement une table par type de doc (puisqu'en effet, chaque auteur peut avoir écrit un livre, mais aussi des art de rev, des art d'ouv collectifs, une thèse, etc)

Le nombre de types de documents n’est sans doute pas figé dans le temps : prévoir une entité-type Document en relation (plusieurs à un) avec une entité-type TypeDocument.

Ensuite, si vous souhaitez mettre en évidence des types de documents en particulier parce qu'ils ont des propriétés qu'ils ne partagent pas, vous pourrez envisager de spécialiser Document (sous-typer), à la façon d'un Darwin, si je puis dire. En tout état de cause, Une entité-type Document permet au moins de factoriser ce qui est commun à tous les documents, quel que soit leur type (généralisation).

Si un livre peut être un ouvrage collectif, prévoir une association plusieurs à plusieurs entre les entités-types Document et Auteur.

Si les mots-clés doivent faire partie d’une nomenclature de mots prédéfinis, prévoir une association plusieurs à plusieurs entre les entités-types Document er MotClé.

Prévoir au besoin une entité-type LieuStockage, qui soit en relation un à plusieurs avec Document.

Il est temps que vous représentiez tout cela sous forme d’un graphe (Access, Barre de menus \ onglet Relations).

[Fran34]

le schéma en doc joint n'est pas assez clair ??
FC

[fsmrel]

le schéma en doc joint n'est pas assez clair ??

Désolé, j'ai envoyé mon message sans avoir rafraîchi l'écran et donc je n'ai pas vu votre message précédent.

Cela dit, dans votre document, il manque les associations entre entités-types, sans lesquelles la représentation n'a guère de valeur. Je réitère mon conseil : modélisez en partant de l'onglet Relations d'Access (ou utilisez un outil ad-hoc, genre Toad Data Modeler, DBDesigner et consorts).

[hed62]

Concernant les motsclés (valeur) dans un seul champ, quels sont les inconvénients ??

L'inconvénient, outre de ne pas respecter le premier niveau de forme normale d'une base de données, est de devoir gérer des valeurs multiples au sein d'un même champs... Ce qui est très anti relationnel : en ce cas, tu peux tout aussi bien tout mettre dans une table unique !

Je ne peux pas définir autant de champs que de motsclés probables car je ne sais pas à l'avance combien de motsclés seront définis pour caractériser ce qu'il y a donc un doc

En effet , c'est à cela que servent les relations plusieurs à plusieurs :

Vue conceptuelle :
Document -1..n-----[se rapporte à ] -----1..n-MotClef

Vue Physique :

Document (idDoc, autres_propriétés)
MotClef (idMC, autres_propriétés)
SeRapporteA (idDoc, idMC)

Document.idDoc est une clef primaire
MotClef.idMC est une clef primaire

SeRapporteA.idDoc est une clef etrangere
SeRapporteA.idMC est une clef etrangere

le couple {SeRapporteA.idDoc, SeRapporteA.idMC} est la clef primaire

[fsmrel]

L'inconvénient, outre de ne pas respecter le premier niveau de forme normale d'une base de données, est de devoir gérer des valeurs multiples au sein d'un même champs...

Dans le cadre de la théorie relationnelle, par construction, une variable relationnelle (en abrégé relvar, informellement table) respecte automatiquement la première forme normale. Supposons que l’en-tête de la relvar Document contienne un attribut MotsClés, de type VarChar(1784). Cet attribut peut contenir la valeur "Bases de données, modélisation, 1970, Ted Codd, Éditions Développez", il n’y a rien à redire. Du point de vue de la théorie relationnelle, Varchar(1784) est un type scalaire, donc légal. Pour faire chic, disons que la donnée est encapsulée.
Maintenant, si l’on cherche tous les ouvrages pour lesquels on a le mot-clé "Bases de données", il faudra coder par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Select    OuvrageNom, ...
From      Ouvrage
Where     MotsClés Like "%Bases de données%"  ;

Requête qui n’est pas indexable, et donc peut à voir avec la performance. Mais cet aspect des choses ne concerne pas le Modèle relationnel.

Je reconnais que si, dans cet exemple, la 1re forme normale est respectée à la lettre, elle ne l’est pas dans l’esprit et que l’on peut préférer mettre en œuvre une relvar MotClé (notez le passage du pluriel au singulier). C’est l’étude fonctionnelle du projet qui permettra de trancher.

[Fran34]

Ok Merci
Je vais prendre le temps de tout comprendre et je vous tiens au courant
Hed62, comment je fais avec mes dix motsclés qui caractérisent un livre

Merci
A+
FC

[hed62]

@fsmrel : bon, d'accord, dans la plus pure théorie, c'est correct, et même jouable dans le cas des mots clefs. Mais quand même, je préfère nettement déconseiller ce type de pratique. Personnellement, je trouve que insérer plusieurs valeurs dans un champs n'est pas une bonne chose. Mais bon, on pourrais certainement en débattre un certains temps, avant que je ne succombe à mon manque d'expérience et votre maîtrise de la théorie

Donc, Fran34, forge toi une idée selon ce qui vient d'être dit

Hed62, comment je fais avec mes dix motsclés qui caractérisent un livre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Livre
-----------
id  |  Titre
01  | Livre1
02  | Livre2
 
MotCle
-----------
id  |  Mot
1   | Bases de données
2   | modélisation
3   | 1970
4   | Ted Codd
 
LivreMotCle
-----------
idLivre | idMot
01      | 1
01      | 2
01      | 3
01      | 4
02      | 4

Par exemple.

[fsmrel]

Bonsoir,

bon, d'accord, dans la plus pure théorie, c'est correct, et même jouable dans le cas des mots clefs. Mais quand même, je préfère nettement déconseiller ce type de pratique

Don’t worry! Votre remarque est pleine de bon sens et votre conseil est le bon. Simplement, je tiens à faire observer que la théorie est une chose et la pratique une autre. Au plan pratique, je suis comme vous, je déconseille d’utiliser des listes de valeurs au sein d’un même attribut, même quand il s’agit de simples mots-clés : S’ils sont là, c’est que l’on va effectuer des recherches devant répondre rapidement, en moins d’une seconde. Ainsi, pour une table comportant trois cents millions de lignes, le temps de réponse sera encore exécrable et la CPU pourra stresser si nous sommes 2000 à soumettre simultanément une transaction comportant la requête non indexable (cf. mon précédent message) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Select    OuvrageNom, ...
From      Ouvrage
Where     MotsClés Like "%Bases de données%"  ;

En revanche, comme je sais que vous aurez correctement indexé les colonnes de vos tables Livre, MotCle et LivreMotCle, le temps de réponse de vos requêtes sur mots-clés sera conforme à l’attente des utilisateurs et la CPU ne sera pas inutilement dévastée. J’engage vivement Fran34 à vous suivre ! (Jusqu’à ce que les ordinateurs quantiques rendent nos réflexions sans objet...)

Pourquoi insisterai-je au sujet de la théorie relationnelle ? Parce que nous ne pouvons pas nous contenter d'être pragmatiques. Nous avons besoin d'elle, parce que nous ne pouvons pas nous contenter d’approximations, de bouts de ficelles, de recettes, de contraintes bassement matérielles, de résultats parfois non prévisibles, comme j’ai connu cela avant que Ted Codd ne nous livre son papier fondateur, c'est-à-dire du temps des SGBD pré-relationnels. Mais, la théorie n’est pas concernée par ces contingences : la théorie relationnelle relève des mathématiques appliquées et de la logique du 1er ordre. Dans son 1er papier ("Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks" IBM Research Report RJ599 (August 19th, 1969)), Codd lui-même acceptait qu’une relation (ce que l’on appelle une table en SQL) soit une valeur d’une autre relation. En 1970, il a préféré qu’il n’en soit plus ainsi, pour que sa théorie ne soit pas rendue compliquée et dans son papier fondateur du mois de juin ("A Relational Model of Data for Large Shared Data Banks", Comm. ACM, V13, N6, June 1970, pp. 377-387), il a demandé que l’on procède à la normalisation des relations emboîtées, ce que l’on a appelé par la suite "normalisation en 1re forme". Sinon, il risquait un rejet de son Modèle de la part de la communauté. Il a réussi à vendre son Modèle parce que celui-ci était simple. Et ça n'est pas Lawrence Ellison qui aura pu s'en plaindre...

La normalisation au sens originel de Codd a engendré des problèmes de redondance des données et les mathématiciens ont eu du grain à moudre pendant près de 10 ans, ils ont théorisé sur les fameuses formes normales (NF), de la 2e à la 5e. Néanmoins celles-ci n’ont rien à voir avec la 1re, laquelle impose comme on vient de le voir qu’une relation ne soit pas la valeur d’une autre relation. Ces autres formes normales nous disent comment découvrir des redondances inopportunes et comment s’en débarrasser, sachant qu’elles ont pu être la conséquence d’une normalisation 1NF.

Au tout début des années quatre-vingt-dix, donc vingt ans après la parution des premiers papiers de Codd, Date et Darwen ont démontré qu’une relation pouvait, sans que la théorie perde en simplicité, être une valeur pour une autre relation, à condition que cette théorie nous permette de définir nos propres types Relation et qu’elle fournisse les opérateurs permettant le cas échéant d’emboîter/désemboîter les relations.

Par exemple, on peut définir le type de relation LigneCommande, puis définir pour la variable relationnelle (relvar) Commande un attribut LigneCde de type LigneCommande et dont la structure correspond à celle de l’entité-type merisienne Ligne de Commande.

Je tiens surtout à faire observer à tous ceux qui écrivent avec assurance sur la 1re forme normale qu’il faudrait qu’ils revoient le sujet et évitent de recopier des énoncés formulés il y a bien longtemps et désormais surannés. Je suis complètement d’accord pour recommander de ne pas utiliser de listes de valeurs pour un attribut, mais ceci ne relève pas de la 1NF. Sinon pourquoi ne pas considérer qu’une chaîne de caractères ne représente pas un viol de 1NF ? Ça n’est jamais qu’une liste de caractères... Simplement, il n’est pas très fréquent d’avoir à utiliser une requête du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Select  PersonneNom, ...
From    Personne
Where   Prenom Like "%e%"  ;

Pour en revenir au côté pratique des choses, je recommande une fois de plus à Fran34 de suivre hed62 dans ses recommandations !

[hed62]

(Jusqu’à ce que les ordinateurs quantiques rendent nos réflexions sans objet...)

Cela risquerait d'arriver dans quelques années seulement d'ailleurs

Pourquoi insisterai-je au sujet de la théorie relationnelle ? Parce que nous ne pouvons pas nous contenter d'être pragmatiques. ... Et ça n'est pas Lawrence Ellison qui aura pu s'en plaindre...

Au moins je sais d'où elles viennent maintenant!

Néanmoins celles-ci n’ont rien à voir avec la 1re, laquelle impose comme on vient de le voir qu’une relation ne soit pas la valeur d’une autre relation.

Il faudra donc que je revoie les enseignements reçus, qui m'assuraient que "1NF = une valeur par colonne" !

Je suis complètement d’accord pour recommander de ne pas utiliser de listes de valeurs pour un attribut

Ca me rassure

Sinon pourquoi ne pas considérer qu’une chaîne de caractères ne représente pas un viol de 1NF ? Ça n’est jamais qu’une liste de caractères...

Effectivement, vu comme ca...

Je savais ne pas être au top sur les NF, mais là, pour le coup, je sais qu'il vaut mieux que je m'abstienne d'en parler de manière franche