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
dictionnaire de données
bonjour bonjour,
Voilà, en cours on a une modélisation à faire selon merise et il nous est demandé de faire le "dictionnaire de données" en plus des MCC, MOC, MCT, MOT. Mais seulement voilà... personne ne sait de quoi ça parle (apparement). Serait-il possible d'en avoir une brève description?
Merci bcp
Sam
PS : il me semble n'avoir rien trouvé dans la FAQ ;-)
Bonjour,
Alors le dictionnaire des données permet de recencer toutes les données qui vont se trouver dans ta modélisation. Tu dois donc indiquer le nom de ton attribut, son type, sa longueur, une description (ce à quoi elle va correspondre).
Je crois qu'il y a d'autres informations a y indiquer mais c'est un peu loin et je n'en ai que de vagues souvenirs....
J'espère avoir pu t'aider un peu.
Isa
nom fonctionnel de ton attribut, nom "technique", type, longueur, contraintes/calcul (regles de gestion)
Exemple pour un agenda :
Nom personne, nom_pers, String, 20, non null
Prenom personne, prenom_pers, String, 15, non null
Date de naissance, date_nais, Date, 8, <date du jour
Age, age, int, 3, date du jour-date de naissance
...
Ca te permettra :
- de ne rien oublier
- de pointer les données qui seront en base (date de naissance) et cellesw qui seront calculées (age)
- de définir les contraintes, les types et longueur
NB : soit le plus précis possible ! parfois on ne met pas quelque chose parce que ça parait évident, et on l'oublie ensuite et ça fout la merde!
Meme si parfois ce qu'on met parait con, il vaut mieux trop en mettre que par assez dans tout ce qui est analyse.
(quand on commence les systeme d'information (merise... analyse préalable, dossier de specif...), ca fait chié et on ne voit pas trop l'intérêt, mais (je pense que personne dans ce cas ne sera pas d'accord avec moi !), à l'utilisation, on se rend compte que les spécif, c'est TRES important ! je dirais meme déterminant ! )
Bon courage
Cours et tutoriels pour apprendre Java , FAQ Java, et Forum Java
"La liberté de tout être s'arréte là où commence celle de l'autre... Respecter l'autre, c'est préserver sa liberté d'être, de penser et de vivre"
Bonjour,
voici un exemple concret de dictionnaire de données :
NOM Légende Type Règles de gestion
date_rdv Date du rendez-vous Date date du jour … Obligatoire
code_ser Code du service 9(3) séquentiel unique > 0
nom_ser Nom du service X(32)
Comme le dit viena, il faut être le plus exhaustif possible dans un premier temps. Ce dictionnaire se construit dès le début, en notant toutes les données que tu lis, récupères dans de la doc, énoncé, expression de besoins, etc... Ensuite il sera mis à jour au fil de l'eau du projet par exemple .
Un dictionnaire de données ne doit pas contenir d'élément technique relatif à l'implémentation, ni de règles de gestion.
Un dictionnaire ne fait que recenser les données (comme son nom l'indique...)
-> pas de règle de gestion car une règle de gestion est propre à une application alors que le dico est propre au système d'information
-> pas de caractéristique technique (genre nom de la colonne) car il faut séparer le conceptuel du physique
Allons plus loin: les qq exemples fournis:
-date de rendez-vous
-date de naissance
-age
n'ont pas vocation à figurer dans 1 dico de données (surtout pas l'âge !)
Par contre, la donnée DATE doit y figurer, car elle caractérise complètement un concept "universel" parfaitement défini.
Ensuite cette donnée permet de définir les éléments dont on a besoin : date de naissance, date de rendez-vous, date de ?????? qui vont bénéficier des caractéristiques invariantes de la donnée DATE.
En définitive, une date reste une date, qu'elle soit de naissance, de rendez-vous, etc...
Un dernier mot sur l'aspect "physique": il m'a été donné de "vérifier" un dico d'entreprise dans lequel figuraient pour les données, notament:
-le nom de la colonne dans le SGBD
-le format de la colonne dans le SGBD
-le nom de manipulation de la donnée dans le langage de la boite (COBOL en l'occurrence)
-le format COBOL de la variable avec laquelle on manipule la donnée
et bing : 4 énormes bêtises :
- au niveau SGBD les règles de nomage des colonnes peuvent variées : 18 caractères sous DB2, 64 sous MySQL
- format de colonne il existe des formats spécifiques à certains SGBD
- nom dans le langage : une variable COBOL peut être :question à 0,01€: c'est bon ça en Pascal/Delphi ou en C
Code : Sélectionner tout - Visualiser dans une fenêtre à part MA-VARIABLE(sans parler de la taille maxi de l'identifiant)
- format du langage: là c'est la tarte à la crême : PIC X(10) en COBOL -> String ailleurs
Donc, il faut rester très conceptuel dans le dico.
"Il n'y a pas de bonnes réponses à une mauvaise question." (M. Godet)
-----------------------
Pensez à cloturer votre sujet- Aucune réponse aux sollicitations techniques par MP
Usus magister est optimus
je ne suis pas tout à fait d'accord avec toi. En effet, si les règles de gestion n'apparaissent pas, comment faire pour savoir quel type de données tu as écris...Envoyé par qi130
Un dictionnaire de données ne doit pas contenir d'élément technique relatif à l'implémentation, ni de règles de gestion.
Un dictionnaire ne fait que recenser les données (comme son nom l'indique...)
-> pas de règle de gestion car une règle de gestion est propre à une application alors que le dico est propre au système d'information
-> pas de caractéristique technique (genre nom de la colonne) car il faut séparer le conceptuel du physique
....
Les règles de gestion ne sont pas toujours propre.à une application, par exemple dans la gestion, il est évident que les règles de gestion ne sont pas propre à l'application, mais au droit (fiscal, comptable).
De plus ton dictionnaire de données est basé sur l'analyse de l'existant, ou sur le recueil des besoins utilisateurs, donc tu as des contraintes (si tu as un numéro de SS, tu dois bien noter que ta donnée doit avoir 13 chiffres (+ clé éventuellement), idem avec le numéro de siret. Donc tes règles de gestion ou "contrainte"(le mot me parait plus adapté - Il est bon de se relire avant de publier :-) ) peuvent apparaitre ici.
Dernier exemple basé sur les dates : si dans ton entreprise tu as des données "client" et "facture" les dates apparaissant ne sont les même et non pas la même finalité; donc déclaré une donnée DATE générique oui mais aussi les autres types de date (qui en plus n'auront pas obligatoirement le même format). Et puis cela peut être une date calculée, donc pas tout à fait le même fonctionnement (ex: année d'ancienneté)
Sinon pour le reste je suis ok. L'esemple que je donne est une finalité dans un projet, donc un dico un peu plus "application" que SI. d'où par exemple le type apparaissant =>X(32). Dans la logique, on devrait écrire plutôt entier,calculé, numérique (n chiffres), etc...
Mais je n'ai pas la science infuse :-)
CARPE DIEM
Eh bien oui, c'est toute la difficulté de la chose, et dans la majorité des cas, on la contourne en spécifiant dans le dico...
Egalement, évoquer comme tu le fais le "type" de données, c'est déjà selon moi sortir du dico pour aller vers le langage de programmation
Et donc selon toi, il convient de déclarer autant de données que de dates présentes dans le système d'information ?
Il parait plus judicieux de spécialiser (=typer) la date client au moment où on s'en sert, en lui appliquant à ce moment là les règles de gestion; en plus celà évite les 2 aberrations suivantes: (restons dans le Droit et la date de naissance)
- soit déclarer plusieurs occurrences de date de naissance parceque des règles de gestions différentes s'appliquent selon le contexte : 18 ans pour être électeur, mais 25 pour être éligible
- soit "blinder" de règles de gestion la définition de la date de naissance dans le dico, ce qui revient à en faire un cahier des charges
Tu évoques également le n° de SS en admettant explicitement 2 expressions physiques du même concept... alors ? 2 entrées dans le dico ?
Si 2 entrées il y a, elles concernent:
1/ le n° de SS sur 13 caractères
2/ la clé de contrôle
Grattons un peu ce n° de SS: on y trouve:
- le code "sexe" du titulaire
- année de naissance
- n° de mois de naissance
- n° de département de naissance
- n° de la commune de naissance
- rang d'inscription sur le registre des naissances de la commune
Bref, le n° de SS est déjà un montage de données :o
On a le même phénomène pour le RIB, et sûrement plein d'autres "candidats" au dico de données (n° de téléphone à 7 chiffres puis 8 puis 10...).
Je ne suis pas "jusqu'au boutiste" malgré tout, et je conçois la présence dans un dico d'un n° de SS, de téléphone, d'immatriculation, simplement parce que la théorie à ses limites, dictées par "l'utilisabilité" (il est + facile de parler du n° SS que de manipuler les 6 notions qui le composent hein?).
Mais je reste réserver sur les dates évoquées...
"Il n'y a pas de bonnes réponses à une mauvaise question." (M. Godet)
-----------------------
Pensez à cloturer votre sujet
Usus magister est optimus
[HS]
SQLPRO a expliqué brillamment il y a quelques temps que le N° de SS ne fait pas une bonne clé
[/HS]
Désolé pour ce hors sujet mais je pensais que cet élément pourrait vous interesser
7 fois à terre, 8 fois debout
En relisant le question de samiroquai et la discussion avec Qi130, je m'aperois que nous parlons finalement de 2 choses quelques peu différentes :
La problématique de samiroquai est bien de faire un dico pour son appli/métier/ ....
et QI130 a remonté le sujet à un dictionnaire de données d'entreprise.
Dans les faits et pour samiroquai :
Ton cours et ton exo/tp/dossier/projet est avec Merise. Puique cela part d'une analyse de l'existant (courbe du soleil), le Dico des données est fait de tout ce que tu récupères dans la documentation (même si ultérieurement ce ne sont plus des données). Exemple on te parle d'un client et des informations que l'on a de lui :
donc tu te fais un tableau ou tu écris tout ce que tu lis /entend... :
client, nom, prenom, date, adresse, cp, ville, teléphone;
Ensuite tu confrontes tout ceci pour éventuellement éliminer les doublons
C'est pas ceci que tu pourras faire tes différents schéma d'analyse de l'existant. Tu verras également les pb qui peuvent exister.
SI TU AS BESOIN, J'AI UN DOSSIER COMPLET (Sujet DESS sur un Hôpital)
je peux te le passer via mon adresse perso....
POur QI130, je suis d'accord avec toi si on se positionne sur un dico de données d'entreprise et pas d'application. Acun intérêt de détailler tous les types de dates par exemple.
Le dico d'entreprise est du haut niveau : les informations primordiales et qui servent au SI...
On y arrive comme cela :-)
qi130, il eu été judicieux de bien lire le problème avant de se lancer dans ton exposé, ne crois tu pas ?
jacktheripper a raison, il ne s'agit pas de dictionnaire d'entreprise.
J'espere que les débutants qui liront ce sujet iront jusqu'au bout de ce post et ne s'arréterons pas à ton message, parce que pour s'embrouiller, il y a pas mieux !
Donc, pour etre clair :
- dictionnaire de données d'entreprise : permet de définir les format des données utilisées au sein de l'entreprise. (Donc, on spécifie juste la Date et pas les différentes date (naissance, majorité...)
- dictionnaire de données applicatives : permet dedéfinir les différentes données utilisées lors dans une application. Cel permet de mettre en place la base et de définir par avance les liens qui les unissent et les contraintes qui sont liées.
"La liberté de tout être s'arréte là où commence celle de l'autre... Respecter l'autre, c'est préserver sa liberté d'être, de penser et de vivre"
Mais qu'avez-vous tous à me tomber dessus ????????? (restons zen et didactique)
Bien lire le sujet
J'ai trop l'impression que vous faites tous une confusion de la même veine que DBA= administrateur de bases de données, en faisant l'abstraction facile de l'administrateur des données.
D'autre part je vous recommande de chercher la forêt derrière l'arbre qui vous aveugle...et d'adopter une démarche rationnelle "top down", c'est à dire du conceptuel vers le physique (dont on est loin !):
il n'est pas question d'implémentation physique, mais de modélisation.en cours on a une modélisation à faire selon merise
Là encore conceptuel et organisationnel, pas de physique (=pas de base=pas d'appli)MCC, MOC, MCT, MOT
Et puis, il ne parait pas très professionnel de foncer ventre à terre vers la description de données applicatives, sans savoir si le traitement censé les manipuler sera informatisé...
Une fois le dico d'entreprise bouclé, il sera toujours temps et peu coûteux de le décliner (si besoin).
Allez donc expliquer à votre DI que la consolidation de vos différents dico applicatifs au sein du dico d'entreprise va lui coûter les yeux de la tête 8)
et que quand ça sera fait, il faudra "ajuster" nombre d'applications pour être en phase avec le dico.
Enfin, chacun voit midi à sa porte, et j'espère que l'étudiant qui nous a sollicité ne sera pas affecté par le décalage horaire.
"Il n'y a pas de bonnes réponses à une mauvaise question." (M. Godet)
-----------------------
Pensez à cloturer votre sujet
Usus magister est optimus
Là je crois que tu te laches un peu. Nous n'avons rien contre toi, au contraire cher membre éclairé
Comme je le disais dans mon dernier message, si on prend la méthode MERISE, on part d'un existant :
la démarche se veut ainsi (tout n'est pas posé-chacun fais sa sauce!!) :
Modèle physique(MPD...) => rarement fait mais pourtant une des bases de l'approche merisienne (analyse de l'existant donc BD en général même si c'est du access, ou xml ou je ne sais quoi encore)
Modèle Organisationnel (MLD-MOF-MOT)
Modèle Conceptuel (MCF-MCT-MCD)
Et c'est pendant ton analyse que tu construis ton dictionnaire des données existants. Ce dico sert de base au MCD, sinon tu risques d'avoir des pb pour sa construction...
Et ainsi de suite pour la méthode MERISE...
Effectivement lorsque tu rentreras dans tes nouvelles propositions, ton nouveau dico sera à revu & corrigé et devra correspondre à un Modèle de Données de l'entreprise. Mais pour cela faut-il qu'il y ai un Administrateur des Données - un vrai... Ce qui est rarement le cas...
Je comprends donc ce que tu veux exprimer mon cher QI130 et je suis d'accord avec toi sur le Fond (c'est comme avec UML et le Process de dév => l'un ne sert à rien sans l'autre). IL ABSOLUMENT FAIRE UN DICTIONNAIRE D'ENTREPRISE qui sera décliné dans les applic...
CARPE DIEM Et bon courage aux Etudiants
Ah me voici rassuréLà je crois que tu te laches un peu. Nous n'avons rien contre toi, au contraire cher membre éclairé
Tant que tu ne dis pas illuminé....
C'est vrai qu'on n'a pas des métiers faciles, toujours le nez dans le guidon...
"Il n'y a pas de bonnes réponses à une mauvaise question." (M. Godet)
-----------------------
Pensez à cloturer votre sujet
Usus magister est optimus
comment construire le dictionnaire de données
Bonjour,
je suis en BTS AD 2ème année par correspondance avec le CNED et je suis en train d'étudier le dictionnaire des données mais je ne comprends pas comment on le construit. Mon cours est assez léger sur le sujet.
Merci
salut
pour le dictionnaire de données il faut indiquer les rubriques qu'on peut trouver dans chaque flux.
Par exemple un passager qui n'a pas trouvé son bagage sur le tapis roulant dans l'aéroport, donc il se dérige vers le guichet de réclamation voyageur et il fait une reclamation.
içi f1 c'est la réclamation
dans le dictionnaire on met:
f1: réclamation
1- Nom et prénom de passager
2-numéro de passeport
3-numéro de vol
4-date vol
5-numéro de bagage perdu
6-aéroport départ
7-aéroport arrivé
...
c'est à dire toutes les informations qu'on peut trouver dans la rélamation
et ainsi de suite pour tout les autres flux.
j'espère que mon exemple était claire.
Dictionnaire de données
Le dictionnaire de données, c'est un tableau récapitulatif de toutes les données manipulées au sein d'un Système de gestion. Ces données sont récensées et analysées. Les propriétés sont récensées à partir des documents inventoriés par les schémas de circulation ou après une interview.
Va dans Google et tape dictionnaire de données, tu auras plein de bonnes réponses. Sinon, voici un lien pour toi : http://www.phportail.net/articles/46-methode-merise.php
Bon courage et bientôt
Micky65
Bonjour à tous,
Après ces nombreuses réponses, il reste à espérer que samiroquai y trouve son compte. Beaucoup de choses ont été dites sur ce fameux dictionnaire de données, du bon et du moins bon. Comme tout le monde a donné son avis, je ne vais pas me priver de donner le mien aussi.
Quand on parle du dictionnaire de données dans un contexte de démarche Merise (ce qui est bien le cas), on se situe au niveau conceptuel dans une étape de recueil d'informations qu'il est d'usage de nommer propriétés conceptuelles. Il s'agit donc de recenser les données sur lesquelles s'appuiera la modélisation conceptuelle des données aboutissant au MCD. Le dictionnaire de données de cette étape aurait pu, afin éviter toute confusion, se nommer dictionnaire des propriétés conceptuelles.
Dans un dictionnaire de données au sens où en l'entend ci-dessus, on s'attache à définir la sémantique des propriétés faisant partie du périmètre d'étude. Chaque concept rencontré lors de l'étude est nommé et décrit. Le nom doit être unique et la description sémantique doit être la plus complète et précise possible. Par exemple, on ne pourra pas trouver de propriété "date" car aucune sémantique n'est véhiculée par ce type d'information - la description en serait trop floue : "c'est une date" (!).
Il n'y a pas non plus de règle de gestion au sens applicatif du terme mais la description sémantique peut comporter des règles constitutives de la propriété (liste de valeurs, contrainte fondamentale, etc.) Et, bien entendu, il n'y a pas de nom technique, de type ni de longueur.
Enfin, il faut souligner que la constitution du dictionnaire de données n'a pas été identifié (du moins au début) comme une étape à part entière dans la démarche Merise. On en parle beaucoup plus dans les cours des professeurs que dans la littérature. On n'en parle pas dans La Méthode Merise "Principes et Outils" (tome 1) et le sujet est à peine effleuré dans le tome 2 "Démarche et Pratiques". Le dictionnaire de données relève plus des bonnes pratiques qui se sont installées dans les entreprises au fur et à mesure de l'utilisation de Merise.
Moi non plus je n'ai pas la science infuse et ceci n'est que mon avis personnel (mais étayé par quelques années de pratique).
JPhi33
N'oubliez pas de consulter les Cours Merise et la F.A.Q. Merise
_______________________________________________________
Les Règles du Club Developpez.com
Vous avez votre réponse ? Merci de cliquer sur
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