Discussion :

[bonelzez]

Bonjour,

Je travaille pour une organisation sur les migrations (non pas l'OIM ) et nous allons devoir développer une base de donnée sur... les migrations!

En gros, elle devra contenir des données type nombre de migrants retour, nombre de migrants refoulés, parcours migratoire... 70% des données seront récoltées à partir d'enquêtes (donc des formulaires papier) et 30% à partir d'une base de données MySQL déjà existante.

Il a été demandé qu'un consultant écrive le modèle conceptuel de cette base et ensuite le développement serait fait par un prestataire local (en Afrique).

Ma question est simple : que chercher comme compétences pour un tel consultant? Je me suis dit que de chercher une personne connaissant les BDD ne suffirait pas et qu'il faudrait un profil "assistance à maîtrise d'ouvrage" ?

Merci de vos conseils

[SQLpro]

Il faut surtout un spécialiste de la modélisation de données. En effet le point crucial des performances d'une application SGBDR est liée à 70% au modèle de données. Si un mauvais modèle a été réalisé, vous ne vous en appercevrez pas au début... Mais quand la base aura beaucoup de données. Et ce sera trop tard !
Et cela coutera très cher avec deux solutions :
1) la fuite en avant : rajouter le la RAM du processeur, des disques au serveur !
2) le remodelage de la base avec des impacts forts sur l'applicatif

Lisez les articles que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/optimisation/
Notament :
http://sqlpro.developpez.com/optimisation/3/

Sachez qu'avec un bon modèle de données et si possible un style de développement serveur épais (thick database dev.) les temps de développement seront raccourcis et les temps de réponse améliorés.
Lisez cet article sur le sujet :
http://www.dulcian.com/Articles/Thic...ited_final.htm

Sachez par exemple qu'en ce moment je m'occupe de modéliser et de conseiller ensuite le développement d'un projet de refonte du système informatique de gestion des crues du grand delta du Rhône, avec une base de données critique ou nous attendons quelques centaines de millions de ligne dans la table principale, et avec des temps de réponse exigé de l'ordre de 10 ms quelque soit les requêtes et une disponibilité de 99,999 % du temps soit moins de 6 minutes d'interruption par an !

Lisez les autres articles que j'ai publié sur mon site d'entreprise, rubrique "ressource" : http://www.sqlspot.com

A +

[bonelzez]

Merci Frédéric de ta réponse.

J'ai parcouru tes docs, et, ma foi, celles-ci m'ont l'air bien complètes. Mon oeil débutant et non avisé en base de données ne peut apprécier toute la qualité du travail, mais ca sent le professionnalisme

J'avoue être un peu perdu dans toutes les considérations techniques : je retiens qu'il faut que je cite des mots clefs comme "Types de données, clefs, tables, normalisation" dans ma demande et que j'insiste sur "spécialiste de modèle de données".

Question pratique : un spécialiste de modèle de données rend pour livrable un modèle de données et les différents choix technologiques permettant de l'implémenter? il fait déjà un choix? cela se passe comment concrètement?

Je continue de lire tes docs

[SQLpro]

Question pratique : un spécialiste de modèle de données rend pour livrable un modèle de données et les différents choix technologiques permettant de l'implémenter? il fait déjà un choix? cela se passe comment concrètement?

Excellentes questions !

Un spécialiste de modèle de données rend pour livrable un modèle de données et les différents choix technologiques permettant de l'implémenter?
Lors de la livraison du Modèle Conceptuel de Données (MCD) résultant de l'analyse des données, aucun choix de SGBDR cible ne doit être fait. Cela n'a aucune importance d'ailleurs car un MCD doit être indépendant de toute considération physiques.
C'est à partir de la lecture du MCD et en sus de l'analyse de la volumétrie et de problèmes pratiques d'administration (haute dispo ou pas, réplication, bases de données réparties...) que va se faire le choix du SGBDR cible.

A partir du choix du SGBDR, on va pouvoir trouver les technologies et les outils les plus adaptés pour développer l'application. Par exemple certains SGBDR supportent mal un grand nombre d'accès simultanés (MySQL par exemple) tant est si bien qu'il faudra rajouter des technologies particulières si l'on tient à cette solution (serveur d'objet par exemple)...

il fait déjà un choix?

En principe non, sauf si le système lui est imposé (par exemple dans le cadre d'une politique "maison" d'achat de licence en volume...)

Cela se passe comment concrètement?

1) Analyse des données => dictionnaire des données et des règles de gestion
2) élaboration d'un premier MCD
3) affinage du MCD suivant les formes normales
4) mise à l'épreuve du MCD (vérification logique)
5) vérification auprès des futurs utilisateurs
cyclage possible

Temp consommé : 30 % du temps global du projet

6) A partir de là le choix du SGBDR doit être fait.

7) Passage du MCD au Modèle Logique de Donées (MLD)
8) Rectification du MLD en fonction des spécifications particulières
9) Passage du MLD en Modèle Physique de Données (MPD)
10) Rectification du MPD en fonction des particularités du SGBDR
11) Détermination des espaces de stockage et des schémas SQL

Temp consommé : 50 % du temps global du projet

12) Élaboration de la couche programme au niveau Bases de données (Fonctions UDF, Triggers, Procédures stockées)

Temp consommé : 70 % du temps global du projet

13) Développement de l'application et des interfaces.

Temp consommé : 95 % du temps global du projet

14) Tests

Pour les points de 1 à 11, l'utilisation d'un outil de modélisation est fortement recommandé. Il est indispensable dès que le projet à plus de trentaine de tables...
Pour ma part j'utilise Power AMC depuis 15 ans

Là ou on voit les mauvais projets, c'est lorsque la;phase d'analyse est minimisé. En général lorsque la phase d'analyse (au moins 30% du projet) est bâclée, la perte de temps au final est multiplié par un facteur 2 à 5 du manque de temps d'analyse.
Par exemple pour un projet estimé à 100 jour avec une analyse limitée à 10 jours, alors il est courant d'avoir un dérapage de 20 à 100 jours...
En fait il faut comprendre qu'avec une bonne analyse le développement est rapide parce que le développeur n'a pas de question à se poser !

A +

[bonelzez]

1) Analyse des données => dictionnaire des données et des règles de gestion
2) élaboration d'un premier MCD
3) affinage du MCD suivant les formes normales
4) mise à l'épreuve du MCD (vérification logique)
5) vérification auprès des futurs utilisateurs
cyclage possible

Temp consommé : 30 % du temps global du projet

Merci pour le détail des étapes. Pour aller droit au but, plus l'analyse est performante, plus le travail du développeur est facilité... Donc il faut bien réfléchir en amont.

Une question importante : cette étape d'analyse dépend bien sûr des compétences du spécialiste chargé de la faire, mais aussi de l'utilisateurs qui exprime ses besoins, non? Que souhaites-tu entendre d'un utilisateur afin qu'il te facilite la tâche?

Avoir les idées claires sur mes besoins, OK.
Savoir expliquer clairement mes besoins, OK.
Mais que donner comme "matériel" pour aider au mieux notre spécialiste?

Bonne journée
Arthur

[chaplin]

cette étape d'analyse dépend bien sûr des compétences du spécialiste chargé de la faire, mais aussi de l'utilisateurs qui exprime ses besoins, non? Que souhaites-tu entendre d'un utilisateur afin qu'il te facilite la tâche?

L'analyse est la l'étape la plus dur, car il faut accoucher les âmes comme disait Platon.

Celui qui connait le sujet s'exprimera clairement et inversement.

Ecrivez ce que vous faites, faites des procédures.

Commencez par analyser l'existant. Faites l'inventaire de votre entreprise.
Exprimez vos souhaits par rapport au besoins futurs.

Est ce que vous savez ce que vous voulez ? Si oui, c'est un point fort pour la réussite d'un projet.

C'est beaucoup de bon sens, avant même de parler d'informatique. C'était une petite parenthèse, place aux experts.

[bonelzez]

C'est beaucoup de bon sens, avant même de parler d'informatique.

Exactement, je pense savoir ce dont j'ai besoin, enfin j'ai une vision claire de ma base de données :-)

Je me pose plus de questions sur le chemin pour y arriver, d'où toutes mes questions ci-dessus.

7) Passage du MCD au Modèle Logique de Donées (MLD)
8) Rectification du MLD en fonction des spécifications particulières
9) Passage du MLD en Modèle Physique de Données (MPD)
10) Rectification du MPD en fonction des particularités du SGBDR
11) Détermination des espaces de stockage et des schémas SQL

Réaliser un MCD par un expert en base de données puis confier le développement à une boîte est-il pertinent comme démarche ? Du MCD au MPD puis l'écriture des schémas SQL se fait "facilement" si le MCD est clair ? Faut-il confier à la personne élaborant le MCD plus de tâches ?

[chaplin]

Faire appel à un expert en base de données, c'est une excellente idée pour faire les "fondations". Au vu de ce qui vous a été présenté, vous avez immédiatement des points de repère.

Il n'y a rien de plus "chiant" que de refaire les tables en cours de route parce que l'analyse était insuffisante. Donc, c'est dans votre intêret d'avoir recours à un expert en BDD, d'autant plus que votre MCD est grand.

Pour la sous traitance, Quel langage? Quelle architecture? Quelle BDD ? Quel OS ? C'est à vous de savoir ce que vous voulez ou de vous faire conseiller.
J'ai développé en interne, je ne saurais vous répondre sur ce sujet.

[bonelzez]

Merci pour toutes ces informations

[SQLpro]

Une question importante : cette étape d'analyse dépend bien sûr des compétences du spécialiste chargé de la faire, mais aussi de l'utilisateurs qui exprime ses besoins, non? Que souhaites-tu entendre d'un utilisateur afin qu'il te facilite la tâche?

L'analyse des données se fait par ... un analyste. J'oserais dire pour l'avoir longuement pratiqué, le pratiquer toujours et l'enseigner depuis quelques années, que c'est comparable au psychanalyste : on fait s'assoir les patients sur un divan et on leur torture l'esprit pour qu'il vous disent enfin ce qu'ils font.

Tâche simple en apparence ? Pas vraiment ! En effet les gens qui pratiquent un métier tous les jours ont un jargon que l'analyste débutant peu ne pas comprendre. Il faut donc commencer par le vocabulaire. Et puis comme le métier des personnes que l'on analyse leur est parfaitement connu, ils ont tendance à parler par ellipses...
Un petit exemple :
"Lorsque nous devons allotir une expédition multiple faites a partir de facture unaire, nous utilisons un poste dédié..."
Il fallait comprendre : "lorsque nous faisons des lot d'objets à expédier pour laquelle les factures ne comportent qu'un seul objet, alors nous utilisons un bureau spécifique..."
Comme les mauvaises interprétations peuvent conduire à des désastres, il faut souvent se faire confirmer certaines choses qui peuvent apparaître triviales, mais en fait qui ne le sont pas. Pour cela il existe différentes techniques par exemple la requestion... ; je repose la même question deux ou trois fois dans la journée mais sous des formes différentes. Du style "Vous m'avez bien dit que ..." et là je donne tout de travers afin que la personne me dise "non, non, vous ne m'avez pas compris... " et là la personne commence à s'expliquer un peu plus...

En ce sens que l'analyse est un travail d'interrogation, de fouille, comme l'enquêteur de la police. Colombo aurait fait un excellent analyste de données ! Mieux vaut d'ailleurs que l'analyste n'ait pas de connaissances particulière du métier de son client, ou alors qu'il en soit un spécialiste et qu'il feint de n'y rien connaître afin de débusquer les spécificité de ce cas particulier au lieu d'imposer sa manière de voir les choses. Sinon, s'il en connait quelque chose de superficiel, il peut là aussi déraper !

Réaliser un MCD par un expert en base de données puis confier le développement à une boîte est-il pertinent comme démarche ?

Oui, c'est pertinent.

Du MCD au MPD puis l'écriture des schémas SQL se fait "facilement" si le MCD est clair ?

Oui, c'est simple.

Faut-il confier à la personne élaborant le MCD plus de tâches ?

Il conviendrait de lui laisser aussi la partie SGBDR en développement, mais tout dépend du style que vous voulez. Si vous voulez des performances extrême et un développement des plus rapides avec une très grande fiabilité, alors laissez luis aussi le soin d'implémenter toutes les vues et de réaliser le mapping relationnel objet, donc les triggers et les procédures stockées qui vont avec (ou de montrer comment on fait cela sur quelques objets : monitorat...).
Lisez ce papier sur le "Thick Database Development" c'est ma tasse de thé et j'ai sauvé bien des projets en faisant ce style de dev...
http://www.dulcian.com/Articles/Thic...ited_final.htm
Moins cher, plus rapide, plus performant et plus fiable.
Cela dit cela nécessite des SGBDR capable de choses qui ne sont pas à la portée de tous les éditeurs, par exemple des trigger INSTEAD OF, des vues indexées, des vues mise à jourable, etc...

A +

[chaplin]

L'analyse des données se fait par ... un analyste. J'oserais dire pour l'avoir longuement pratiqué, le pratiquer toujours et l'enseigner depuis quelques années, que c'est comparable au psychanalyste : on fait s'assoir les patients sur un divan et on leur torture l'esprit pour qu'il vous disent enfin ce qu'ils font.

Tâche simple en apparence ? Pas vraiment ! En effet les gens qui pratiquent un métier tous les jours ont un jargon que l'analyste débutant peu ne pas comprendre. Il faut donc commencer par le vocabulaire. Et puis comme le métier des personnes que l'on analyse leur est parfaitement connu, ils ont tendance à parler par ellipses...

Je n'ai rien a rajouter, c'est tout à fait exact.

En ce sens que l'analyse est un travail d'interrogation, de fouille, comme l'enquêteur de la police. Colombo aurait fait un excellent analyste de données ! Mieux vaut d'ailleurs que l'analyste n'ait pas de connaissances particulière du métier de son client

C'est drôle, c'est à peu près ça que je voulais écrire dans ma lettre de motivation.

[bonelzez]

L'

Tâche simple en apparence ? Pas vraiment ! En effet les gens qui pratiquent un métier tous les jours ont un jargon que l'analyste débutant peu ne pas comprendre. Il faut donc commencer par le vocabulaire. Et puis comme le métier des personnes que l'on analyse leur est parfaitement connu, ils ont tendance à parler par ellipses...
Un petit exemple :
"Lorsque nous devons allotir une expédition multiple faites a partir de facture unaire, nous utilisons un poste dédié..."

en effet c'est un très bon exemple... avec une dimension culturelle en plus (occidental/afrique) et une langue étrangère (français, anglais, bambara), cela ne fait "rajouter du bois sur le dos de l'âne"!

je ne comprends pas tout quant au lien sur Dulcian (à cause du jargon technique que je ne maîtrise pas entièrement) mais vais prendre le temps de bien comprendre. Merci.