Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Des tables sans clés étrangères ni clés primaires
Je trouve une base de données qui en cours d'utilisation et qui ne contient aucune clé étrangère ni clé primaire ni de relation entre les tables. On fait tout le traitement dans le code et il y a plein de jointures.
Ce ci est normal?
Comment je peux corriger ça?
Bonjour,
Non, sinon ce n'est pas une base de données relationnelle.Ce ci est normal?
Comme dans les traitements qui ont été codés il y a des jointures, cela veut dire qu'il n'y a aucune garantie d'intégrité des données (par exemple une table de lignes de factures dans factures), donc vous aurez une qualité de données très pauvre.
Il ne vous reste plus qu'à les ajouter ... Jetez un oeil par iciComment je peux corriger ça?
@++
+1Envoyé par elsuket
Je vous souhaite bon courage!
J'ajoute également que c'est vraiment désagréable de voir des gens qui n'y comprennent rien et qui ne cherchent pas à comprendre. Ces personnes font alors des grosses conneries dont celle que vous nous décrivez et ce sont aux suivants de réparer les pots cassés... Les bases de données, c'est un métier!
Le problème est que cela coûte extrêmement cher, et qu'il est difficile de justifier un tel coût à la hiérarchie, puisqu'il n'y a pas de valeur ajouté directe.
Pourtant une entreprise sans données, ou une entreprise avec une qualité de données pauvre, c'est un peu comme une voiture sans roues : ça ne va pas loin
@++
On a commencé par créer une table, puis selon les besoins on crée une autre. Sans conception ni relation ni rien..
Puis celui qui a fait tout ça se plaint de la lenteur des requêtes.
Moi je dois optimiser la base
Hé bien celui qui a créé la base de données devrait savoir que dans une base de donnée relationnelle, il y des .... relations.
Donc ne pas en mettre c'est faire du COBOL, avec des fichiers, comme il y a 40 ans.
Il vous faut donc rajouter les contraintes, rajouter les indexes de base (ceux sur les colonnes de clé étrangère, les indexes de clé primaire et de contrainte d'unicité son créés implicitement à l'ajout de la contrainte).
Je vous souhaite à mon tour bon courage ...
@++
Bonjour,
Si la conception de votre base s'est faite au fur et à mesure, je crains que même en rajoutant des index ceci ne soit qu'une solution de secours (peut être la solution la moins coûteuse en terme de ressource quoi que ...). Rien dans votre base ne garantit que l'intégrité des données ne soit respecté .. de même que l'optimisation du stockage (duplication des données etc ...)
Je pense qu'à terme si votre projet et votre base prennent de l'importance , vous auriez intérêt à reprendre la conception de votre projet pour revoir tout ceci ...
++
Hello,
Je voudrais juste reagir sur le point de vue "normalite":
J'ai rencontrer des bases de donnees applicative dans lesquelles les relations d'integrite de donnees etaient gerees au niveau applicatif et des tables de meta-donnees. En effet je trouve ca un peu "hors-norme" et pourtant parfois il faut vivre avec.
D'autres cas ou pour une raison mystique les gens etaient persuade qu'implementer ces relations ralentirait le systeme... Il est toujours bien de leur expliquer qu'ils se trompent, cependant ca tient la route et ils veulent pas changer.
Comme le dit elsuket:
- Pas de valeur ajoutee a premiere vue
- Ca fonctionne jusque la...
- ...
Et autres arguments dans le genre.
Comme je disais à Elsuket lors de nos nombreuses discussions, il arrive souvent que ce choix (il y a en d'autres bien évidemment) soit fait pour des raisons marketing et financière.
Je prends l'exemple des ERP où ce genre de choses arrive souvent. Les éditeurs choisissent de gérer et d'implémenter les contraintes au niveau applicatif pour une bonne (ou mauvaise ???) raison : Leur application doit tourner sur différents SGBD pour évidemment toucher le plus grand nombre de clients.
Il est alors plus facile de gérer les contraintes au niveau application que directement dans le SGBD qui a quelques fois son propre langage .... Je ne parle évidemment pas des inconvénients que cela génère ...
++
La vie serait si simple si tout etait noir ou blanc...
Je regrette, mais quand on vend un ERP, qui est un produit qui coûte cher à l'achat, en matériel, en paramétrage et en formation, la moindre des choses me semble-t-il, c'est d'avoir des versions de l'ERP adaptées au SGBDR utilisé par l'entreprise.
Comme il faut toujours diminuer les coûts de production, on fait quelque chose de "générique", et le résultat c'est une daube.
Et puis comme le client ne se plaint pas, puisque c'est "l'autre" qui administre la BD, c'est de sa faute ... imaginez bien que l'"autre" coûte bien moins cher que l'ERP, donc c'est forcément "l'autre" qui est en cause ...
@++
Bonsoir,
Comme les collègues le suggèrent, en définissant les clés primaires, alternatives et référentielles, mais ça peut prendre beaucoup de temps, selon la quantité d’infractions (j’ai vu des gens passer un an à remettre les choses d’équerre). Voyez le cas de l’assureur dans la discussion avec Raynord.
Et pour vous y retrouver, commencer par un construire un MCD (Modèle Conceptuel de Données). Voyez l'ouvrage de Michel Diviné et l'article de Cyril Gruau.
Bonsoir à nouveau,
Hum... Tout dépend du sens que vous donnez au mot « relation ».
Je reprends la définition donnée par Ted Codd, père du Modèle Relationnel de Données (cf. l’article sur la normalisation) :
Le terme de relation est utilisé ici dans son acception mathématique. Étant donnés les ensembles S1, S2, ..., Sn (non nécessairement distincts), R est une relation sur ces n ensembles si c'est un ensemble de n-uplets, le 1er élément de chacun d'eux tirant sa valeur de S1, le 2e de S2, et ainsi de suite (de manière plus concise, R est un sous-ensemble du produit cartésien S1 X S2 X ... X Sn). On fera référence à Sj comme étant le jième domaine de R. Suite à ce qui vient d'être énoncé, on dit que R est de degré n. Les relations de degré 1 sont souvent dites unaires, celles de degré 2 binaires, de degré 3 ternaires, et celles de degré n n-aires.Je cite encore Codd (Information Principle) :
Toute l’information contenue dans une base de données relationnelle est représentée d’une seule façon : par des valeurs prises par les attributs au sein des n-uplets au sein des relations.Si donc pour vous le mot « relation » représente bien ce que Codd a défini, on est d’accord et dans ces conditions, la relation coddienne prend le nom de table en SQL (un peu abusivement, car la norme SQL permet qu’une table puisse légalement contenir des doublons — la clause PRIMARY KEY est en effet facultative pour une table de base et pour une table résultat, la clause DISTINCT l’est aussi — ce qui du fait de sa nature, est impossible dans le cas d’une relation quelle qu’elle soit).
En revanche, si pour vous le mot « relation » exprime un lien entre tables, alors il n’a pas d’équivalent formel dans le modèle de Codd : disons qu’on établit des liens explicites, par le canal des contraintes d’intégrité référentielle, sinon ces liens sont implicites du fait du caractère strictement associatif du Modèle Relationnel de Données (voyez l’opération de jointure).
Hum... A cette époque, avec COBOL on utilisait le SGBD hiérarchique IMS-DL/1 (IBM), qui permettait de garantir l’intégrité d’entité (clés de type unique) de façon déclarative, l’intégrité référentielle grâce aux RULES P (Physical Pairing), L (Logical Pairing), V (Virtual Pairing) affectées à ce que l’on appelle en DL/1 des relations logiques. Et l’on claquait des index comme on voulait. Il est convenu de dire que DL/1 est du type hiérarchique, mais il était loisible de bâtir une structure en réseau grâce aux relations logiques. Je parle à l’imparfait, car ça fait près de 25 ans que je n’ai plus pratiqué DL/1 et je ne sais pas comment il a évolué... Mais comme toujours et partout, on notera que certains ont le souci de l’intégrité des données en la sous-traitant au SGBD, alors que d’autres ne procèdent que de manière applicative, que ce soit avec ce brave vieux COBOL ou avec les langages en vogue d'aujourd'hui ou de demain.
Pour la petite histoire, le chiffre d’affaires d’IMS doit bien représenter son petit milliard de dollars (à vérifier auprès d'IBM).
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager