Charte de conception de base de données

Le
Laurent Jordi
Salut,

J'ai publié ma charte de conception de base de données sur mon blog, au cas
où ça interesserait quelqu'un N'hésitez pas à laisser des commentaires
"constructifs". Si vous souhaitez l'adopter Elle est là pour ça.

++

Laurent Jordi
http://www.ezlogic.mc
http://www.laurentjordi.net
Nouveau blog : http://sossoa.blogspot.com/
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fred BROUARD
Le #11884791
Salut laurent,

bonne initiative, mais quelques critiques :

1) tu pourrais au moins parler de la modélisation phase importante et
même essentiel de la problématique de développement des applis BD.

2) tu parles d'_enregistrements_ : cette notion n'existe pas en matière
de SGBDR. On parle donc de lignes. Cela existait du temps des fichiers
CoBol, mais nous n'en sommes plus là !
de même tu parles de _champs_ : cette notion n'existe pas plus car le
terme champ désigne une notion purement visuelle (champ de saisie, cahmp
opératoire du chirurgien...) or les SGBDR sont dépourvus de ce concept.
On doit donc parler de colonne ou éventuellement d'attributs (au niveau
conceptuel)

3) dans ta règle 1, tu dis :
"
Première règle (R1)
Chaque enregistrement de chaque table est toujours identifié de façon
unique par un code numérique entier long à incrémentation automatique.
"
Mais ce n'est pas le cas des tables de jointure !

pour ce qui est des uniqueidentifiers il faut signaler en outre qu'ils
sont très contre performants : leur génération est très couteuse en
process et leur jointure l'est encore plus...

4) R3 : excellent idée que d'avoir toujours une clef sémantique en sus
de la clef purement informatique. Mais ne prévoyez jamais un typage pré
établis. Par exemple cela n'a pas de sens lorsque la table vient d'un
organisme externe pour lequel le code existe déjà. Exemple norme NOEMIE,
INSEE, etc...

Le nom txtNom ne peut pas être utilisé dans toutes les tables. En effet
une règle absolue dans les systèmes d'information et hélas très
largrment violée avec toutes les problématique que cela engendre est
d'utiliser un même nom de colonne dans différentes tables...
Un nom de personne n'a rien à voir avec un nom de jour ou de mois, ou de
machine !
En informatique le principe est que toute information doit avoir un nom
unique au sein du système informatique !
De plus cette caractéristique à nom unique est contraire aux règles de
modélisation et si vous utilisez un outil de modélisation il ne pourra
que faire la confusion entre toute ses rubriques !


EN CONCLUSION :

Beaucoup de vos règles s'éclairciraient d'elles mêmes si vous utilisiez
un outil de modélisation comme Power AMC ou WinDesign.

A +



Laurent Jordi a écrit :
Salut,

J'ai publié ma charte de conception de base de données sur mon blog, au cas
où ça interesserait quelqu'un... N'hésitez pas à laisser des commentaires
"constructifs". Si vous souhaitez l'adopter... Elle est là pour ça.

++

Laurent Jordi
http://www.ezlogic.mc
http://www.laurentjordi.net
Nouveau blog : http://sossoa.blogspot.com/







--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
Laurent Jordi
Le #11884041
Salut,

Je viens de lire tes remarques avec le plus grand intérêt et je t'en
remercie.

Concernant la modélisation, je n'en parle pas car il s'agit d'une chate de
nommage et non de conception. Je devrais plutôt corriger le titre.

Concernant la terminologie, je suis vieux (38 ans) d'où l'utilisation de
vieux mots mais tu as raison, je dois corriger ça.M'enfin, ligne ou
enregistrement... qui n'aurait pas compris (mais meaculpa quand même).

Idem pour attribut...

Première règle (R1)
Chaque enregistrement de chaque table est toujours identifié de façon
unique par un code numérique entier long à incrémentation automatique.
"
Mais ce n'est pas le cas des tables de jointure !



Si si, même les tables de jointures... C'est lourd et moche mais c'est fort
pratique dans certains cas. Comme je veux avoir une structure homogène ça le
fait.... Il est vrai que si la jointure a plusieurs millions
d'enregistrements il peut-être judicieux d'optimiser.

Concernant l'utilisation du txtNom c'est un raccourcis.

Toutes tes remarques sont pertinentes...

Concernant l'application de ces règles... je ne suis pas un bourrin optu,
lorsque c'est nécessaire je les adapte mais globalement ça permet de gerer
assez facilement des bases de 500 tables sans devenir dingue. Je crois qu'en
15 ans de SQL server j'ai du voir maximum 5 bases de données dont la
notation suivait une logique (même mauvaise) et je crois qu'en la matière il
vaut mieux avoir une notation pas top que pas de notation du tout...

Laurent Jordi
http://www.ezlogic.mc
http://www.laurentjordi.net
Nouveau blog : http://sossoa.blogspot.com/






"Fred BROUARD"
Salut laurent,

bonne initiative, mais quelques critiques :

1) tu pourrais au moins parler de la modélisation phase importante et même
essentiel de la problématique de développement des applis BD.

2) tu parles d'_enregistrements_ : cette notion n'existe pas en matière de
SGBDR. On parle donc de lignes. Cela existait du temps des fichiers CoBol,
mais nous n'en sommes plus là !
de même tu parles de _champs_ : cette notion n'existe pas plus car le
terme champ désigne une notion purement visuelle (champ de saisie, cahmp
opératoire du chirurgien...) or les SGBDR sont dépourvus de ce concept. On
doit donc parler de colonne ou éventuellement d'attributs (au niveau
conceptuel)

3) dans ta règle 1, tu dis :
"
Première règle (R1)
Chaque enregistrement de chaque table est toujours identifié de façon
unique par un code numérique entier long à incrémentation automatique.
"
Mais ce n'est pas le cas des tables de jointure !

pour ce qui est des uniqueidentifiers il faut signaler en outre qu'ils
sont très contre performants : leur génération est très couteuse en
process et leur jointure l'est encore plus...

4) R3 : excellent idée que d'avoir toujours une clef sémantique en sus de
la clef purement informatique. Mais ne prévoyez jamais un typage pré
établis. Par exemple cela n'a pas de sens lorsque la table vient d'un
organisme externe pour lequel le code existe déjà. Exemple norme NOEMIE,
INSEE, etc...

Le nom txtNom ne peut pas être utilisé dans toutes les tables. En effet
une règle absolue dans les systèmes d'information et hélas très largrment
violée avec toutes les problématique que cela engendre est d'utiliser un
même nom de colonne dans différentes tables...
Un nom de personne n'a rien à voir avec un nom de jour ou de mois, ou de
machine !
En informatique le principe est que toute information doit avoir un nom
unique au sein du système informatique !
De plus cette caractéristique à nom unique est contraire aux règles de
modélisation et si vous utilisez un outil de modélisation il ne pourra que
faire la confusion entre toute ses rubriques !


EN CONCLUSION :

Beaucoup de vos règles s'éclairciraient d'elles mêmes si vous utilisiez un
outil de modélisation comme Power AMC ou WinDesign.

A +



Laurent Jordi a écrit :
Salut,

J'ai publié ma charte de conception de base de données sur mon blog, au
cas où ça interesserait quelqu'un... N'hésitez pas à laisser des
commentaires "constructifs". Si vous souhaitez l'adopter... Elle est là
pour ça.

++

Laurent Jordi
http://www.ezlogic.mc
http://www.laurentjordi.net
Nouveau blog : http://sossoa.blogspot.com/







--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************


Publicité
Poster une réponse
Anonyme