Discussion :

[logiclogic]

Bonjour,

Je dois créer une base de données de A à Z. Je connais la méthode avec le schéma conceptuel (SC), logique (SL) et physique (SP).
Néanmoins, cela paraît moins évident en pratique :

J'ai des données de sources différentes. Je dois vérifier ces données, les nettoyer, les compléter, les connaître (ex : longueur du char) pour définir le SC.
Ex : fichier excel ou .txt contenant des adresses. Je dois vérifier si les codes postaux sont tous présents, s'ils sont corrects (notamment, en les comparant à une base de référence, celle de La Poste en opendata).

Comment est-ce que j'intègre les données ? En faisant d'abord un SC/SL/SP avec toutes mes données puis en faisant la vérification des données ?
En faisant un SC/SL/SP entre un fichier de données et un fichier de référence, en nettoyant puis en réajustant le SC/SL/SP ? Ainsi de suite avec chaque fichier à vérifier ? Enfin, quand deux fichiers de données sont vérifiés, les intégrer dans un SC/SL/SP commun (LA base de données).
Ou est-ce autrement ?
En effet, il y a un problème : pour utiliser du SQL pour vérifier la donnée (par ex, s'il y a redondance dans la donnée), il faut intégrer le fichier dans le SGBD. Cette étape est le SP. Or, il faudrait avoir le SC et SP en amont. Mais comment faire ces schémas sans avoir vérifier les données.

Merci par avance

[escartefigue]

bonjour,

Analyser le typage des données des trois sources est une étape nécessaire mais pas suffisante, il faut aussi vérifier la présence d'attributs homonymes ou synonymes qui sont souvent une source d'erreurs.
Dans les S.I. d'origine la même notion fonctionnelle peut avoir des noms d'attributs différents et à l'inverse, des objets ou attributs qui portent le même nom n'ont pas toujours le même sens fonctionnel.

Attention aussi aux divergences de valeurs, par exemple dans un S.I. le code pays pour la france est FR, dans l'autre c'est 001, dans le troisième il peut y avoir plusieurs valeurs, une pour la France métropolitaine, une autre pour les DOM, une pour les TOM...
Il faut donc prévoir des étapes de qualification et transcodification

Attention enfin aux doublons fonctionnels : les M. Pierre Dupont présents dans 2 ou 3 S.I. sont ils les mêmes ou pas ? il faut donc prévoir des règles métier de détection des vrais doublons fonctionnels

Concernant l'initialisation de la DB, vu qu'à priori vous partez sur une base toute neuve, un chargement par utilitaire sera plus performant

[Bloon]

Bonjour,

Pour commencer, je te conseille de passer par des tables intermédiaires dans lesquelles tu vas déverser toutes tes sources de données. Ces tables intermédiaires te permettront de faire des requêtes de contrôle en SQL : détection des codes postaux invalides, des doublons, des tailles max de chaque champ, etc... S'agissant de tables qui ont vocation à être supprimées, tu peux te permettre d'être assez souple dans la définition des champs afin d'avoir un minimum de rejets lors de l'intégration des fichiers.

En fonction des résultats de ces requêtes, tu pourra répondre aux questions concernant ton SC cible (qui lui doit être conçu en fonction du besoin métier). Par exemple, s'il y a beaucoup de codes postaux invalides, il faudra peut-être être plus souple sur la contrainte finale (s'il n'est pas possible de corriger les données).

Tu devras corriger tes données dans les tables intermédiaires et quand tout sera ok, "il n'y aura plus qu'à" les copier dans le SP cible via des insert into...

Concernant le chargement des données, il faut essayer d'utiliser les utilitaires de chargement fournis avec ton sgbd. Si tu dois retravailler ces fichiers avant, tu peux le faire via Excel si la volumétrie n'est pas trop importante. Excel présente l'avantage de proposer des imports que l'on peut retravailler directement (éventuellement avec des formules et/ou du VBA) puis ré-exporter au format texte.

Bloon