Discussion :

[grayfox1]

Bonsoir,

Je ne sais trop si c'est faisable, tous les jours j'ai 2 fichier csv qui sont créés avec des données diverses tout les jours soit un peux prés 60 fichier csv par mois, je les ouvre avec access /excel et je fait mes rapports avec les données que j'exporte.

Je voudrais savoir si c'est possible de créer une BD avec SQL express 2010 par ex. pour mes fichiers csv, il me fait une base de données et comme ça je peux créer des liaisons avec excel à ma base de données pour créer mes rapports.

Est-ce que c'est faisable pour un nouveau en SQL?

[CinePhil]

C'est faisable mais un peu complexe.

Un fichier CSV a une structure qui ressemble à une feuille de tableur : des lignes de données avec une colonne par type de données.
Avantage : c'est facile à lire, même par un néophyte.
Inconvénient : il y a beaucoup de données redondantes et une donnée peut être écrite de plusieurs façons, ce qui est éventuellement détectable par un humain mais beaucoup plus difficile par un ordinateur.

Une BDD relationnelle va permettre d'organiser les données en tables et établir des associations entre les tables.
Avantages : cohérence et unicité des données, possibilité de mettre des contraintes sur ces données...
Inconvénient : difficile, voire impossible, à lire directement sans passer par une interface externe programmée ou au prix de requêtes multi-tables plus ou moins complexes pour rétablir une vision des données plus humaine, style feuille de tableur.

Passer de l'un à l'autre est un exercice complexe.
Il faut analyser les fichiers CSV pour modéliser celles-ci. Durant cette analyse, il faut détecter quelles colonnes vont déterminer de manière unique les informations élémentaires.
Ensuite il faut créer la structure de la BDD à partir du modèle qu'on a établi.
Puis on importe les fichiers CSV dans des tables provisoires et on fait des requêtes sur ces tables pour alimenter la nouvelle base de données. C'est loin d'être facile et nécessite des vérifications des requêtes SELECT sur les tables provisoires avant l'importation des données dans la nouvelle BDD par des requêtes INSERT... SELECT.

Par contre, l'avantage de tout ce travail fastidieux est qu'ensuite on peut interroger les données de toutes manières qu'on veut, beaucoup plus facilement et plus rapidement qu'avec un tableur.

Et si les fichiers CSV qui arrivent régulièrement ont toujours la même structure et portent sur des données similaires, la procédure d'importation des données peut ensuite être automatisée par un script SQL, éventuellement avec un peu de programmation externe, en PHP par exemple.

Mais deux choses à faire absolument avant toute importation de nouvelles données :
SAUVEGARDE de la BDD et VERIFICATION après importation que les données restent cohérentes.

J'ai eu à faire cet exercice sur un extrait de deux années de mouvements de bovins pour un thésard, représentant plusieurs dizaines de millions de lignes. En analysant les données, j'ai trouvé des choses bizarres, telles que des mâles ayant eu des veaux, des vaches ayant eu un veau avant d'être adultes, des animaux morts avant d'être nés... Incohérences dans les données dues au fait que la BDNI, d'où étaient extraites ces données, avait changé de structure récemment et que les contrôles sur les données étaient minimaux afin de ne pas empêcher la saisie des informations par les agriculteurs.

Bon courage ! Et n'hésite pas à demander de l'aide dans les forums consacrés au Schéma pour la modélisation de la BDD ou dans les forums Langage SQL et ceux consacrés à ton SGBD pour les requêtes et autres procédures en SQL.

[macsigarev]

Bonjour cinephil,

Je rebondis sur tes remarques intéressantes. en fait, je me suis lancé dans la complexe procédure d'importation de fichiers excel dans une base de données MySQL et coté modélisation j'ai pas mal galéré.

L'objectif est de faire un reporting sous l'outil QLikview à partir de ma base de donnees.

Je voulais que tu m'apporte ta vision critique sur la modélisation que j'ai faite. Dans le fichier Excel en îèce jointe, j'ai mis en VERT les colonnes que j'ai considéré comme entités au niveau de ma BD:
- Unit
- Project
- project manager
- client
- detailsprojet: toutes les autres colonnes qui contiennent les données numériques en montant.

Ce même fichier est chargé chaque mois dans la base de données mais avec des données différentes (les données numériques chagent chaque mois).

Merci d'avance pour ton aide

cherif

[macsigarev]

Salut cinephil,

suite à ta phrase ci-dessous, je souhaterais savoir que veux dire "determiner de maniere unique les informations élémentaires"

ensuite comment déterminer les colonnes en question???

Durant cette analyse, il faut détecter quelles colonnes vont déterminer de manière unique les informations élémentaires.

merci pour ton aide

[CinePhil]

Je voulais que tu m'apporte ta vision critique sur la modélisation que j'ai faite. Dans le fichier Excel en îèce jointe, j'ai mis en VERT les colonnes que j'ai considéré comme entités au niveau de ma BD:
- Unit
- Project
- project manager
- client
- detailsprojet: toutes les autres colonnes qui contiennent les données numériques en montant.

Tu peux y ajouter :
- Status, car le statut d'un projet sera une information répétitive ;
- Contact type , idem ;
- NOP type, idem, même si je ne sais pas ce qu'est "NOP" ;
- Type (de Client), idem.

Enfin, "project manager" et "sales person" sont des personnes et tu devrais avoir une entité type "personne".

suite à ta phrase ci-dessous, je souhaterais savoir que veux dire "determiner de maniere unique les informations élémentaires"

Il s'agit de trouver, dans chaque ligne du fichier CSV, la clé de la ligne. Mais aussi d'isoler dans les lignes les clés candidates des futures entités types du MCD

Dans ton cas, les codes de l'unit, du projet et du client sont des clés candidates. Cependant, un code est souvent alphanumérique et constitue une mauvaise clé primaire pour une table de BDD. Il faudra donc prévoir, dès le MCD, d'ajouter un identifiant entier qui deviendra clé primaire de la table issue de l'entité type et clé étrangère dans les tables associées.

Maintenant que tu as déterminé les principales entités types, écrit les règles de gestion qui décrivent les associations entre les entités types et dessine, à la main ou avec un logiciel de modélisation, un MCD.

Tu pourras proposer l'ensemble dans le forum Schéma.

Bon courage !

[macsigarev]

Merci pour tes précieuses réponses cinephil,

voici quelques précisions sur ce que j'ai fait:

- les colonnes "status", "nop type" et "contrct type" sont des attributs de l'entité projet. Es ce correct ?

- Pour les clés de unit, client et projet , je voulais en effet les consiéderer comme des entiers mais cela m'a causé des problémes au niveau des traitements ETL. Je m'explique, lors du chargement d'un client par exemple, si la ligne courante qu'on charge contient déjà le code du client(format alphanum), je n'ai pas su "empecher" l'insertion si j'utilisais une clé primaire sous forme d'entier dans l'entité "client cible, l'ETL insérait systématiquement la ligne. J'ai donc opté pour la clé sous forme alphanum, comme ça vu que dans la source elle est alphanum, l'ETL vérifie si elle existe ou pas avant de l'insérer dans la table entité client.

- Pour les lignes du fichier CSV, je n'ai pas de clé dans le fichier pour identifier de façon unique la ligne.
Lors du chargement, j'ai rajouté via l'ETL, la période concernée par le chargement (sous forme de date) et la date de chargement (type timestamp).
La clé qui identifierait de façon unique serait donc l'association "code projet + période + date chargement)


Merci de me donner ton avis dessus.