Etablir son dictionnaire de données : Gestion et organisation

Bonjour à tous

Je suis actuellement novice et commence une formation, et actuellement j'ai des documents qui m'expliquent comment concevoir une base de donnée.

D'un côté, on m'explique la méthode Merise, que je pense avoir assimilé (exemple, pour un inscrit : id_i = son identifiant = Numérique N)

de l'autre on me parle des règles de gestion et d'organisation (parfois la frontière est mince mais j'ai saisi l'idée pour différencier les deux)

et on me demande maintenant de faire ma base de donnée avec une étude de cas.

Ce que je ne "saisi" pas c'est le lien entre le dictionnaire de données et les règles de gestion et d'organisation.

J'ai vu en farfouillant sur ce forum un membre dire sur un topic que le dictionnaire de données est comme son nom l'indique pour les données et que les règles de gestion / organisation n'ont rien à faire dedans, mais quelqu'un aurait il plus de précision sur ce point ?
Dans mon étude de cas par exemple, je peux différencier les régles de gestion / organisation, si je comprends bien je ne dois pas les inclure dans le dictionnaire de données ?

Si quelqu'un peut m'éclairer sur ce point je le remercie d'avance, je bloque peut être sur un truc idiot mais je préfère que ce soit clair avant de me relancer dedans :)

Merci beaucoup :)

Bonjour,

Exemple de règle de gestion des données :
R1 : Un projet est dirigé par un salarié et un salarié peut diriger un à plusieurs projets.

MCD qui en découle :
Salarie -0,n----diriger----1,1- Projet

Tables qui découlent du MCD :
te_salarie_sal (sal_id, sal_matricule, sal_nom, sal_prenom, sal_sexe, sal_date_naissance, sal_date_entree...)
te_projet_prj (prj_id, prj_id_client, prj_id_chef, prj_nom, prj_date_debut, prj_duree...)

Extrait du catalogue de données :
Table / Colonne / Type / Clé / Index / Commentaire
te_salarie_sal / sal_id / INTEGER / PK / U / Identifiant du salarié
te_salarie_sal / sal_matricule / CHAR(5) / UK / U / Matricule du salarié
te_salarie_sal / sal_nom / VARCHAR(32) / Non / X / Nom d'usage du salarié
te_salarie_sal / sal_prenom / VARCHAR(16) / Non / Non / Prénom d'usage du salarié
te_salarie_sal / sal_sexe / TINYINT(1) / Non / Non / Code du sexe du salarié (1 = homme, 2 = femme)
te_salarie_sal / sal_date_naissance / DATE / Non / Non / Date de naissance du salarié
...
te_projet_prj / prj_id / INTEGER / PK / U / Identifiant du projet
te_projet_prj / prj_id_client / INTEGER / FK / X / Identifiant du client ayant commandé le projet (clé étrangère référençant la table te_client_cli)
...

Le catalogue de données peut être généré automatiquement, sous une forme ou sous une autre, par le logiciel de modélisation qui aura permis de modéliser la BDD.

En complément de ce qu'écrit Philippe,

Au niveau conceptuel, depuis les origines, il y a un distinguo entre les données et le reste (traitements pour faire court) ainsi qu’entre le niveau des données (conceptuel, logique, physique).

Les données proprement dites (au niveau conceptuel) représentent le QUOI, ce qui sera l’objet de la base de données (niveau logique), donc les structures et les contraintes. Tout le reste représente le COMMENT : les index, les tablespaces et autres mécanismes qui visent (au niveau physique) à booster les requêtes permettant d’accéder aux tables de la base de données. Clairement, ces objets ne concernent que les DBA, et n’ont rien à faire dans le dossier de conception et le dictionnaire des données qu’il contient, mais sont décrits dans un dictionnaire propre aux DBA (Production) ; le dictionnaire des données n’est pas une auberge espagnole.

Pour en rester au niveau conceptuel, les données sont traditionnellement vues sous un angle statique, anatomique (MCD, diagramme de classes) et le dictionnaire des données les décrit en ce sens.

Le COMMENT (le MCT de Merise, les formulaires d’ACCESS, tout un tas de diagrammes UML autres que le diagramme de classes) ne participe pas à la définition des données, mais à la façon de s’en servir (aspect dynamique), bref, toutes ces choses qui à terme n’apparaîtront pas dans la base de données ; donc autant dédier au COMMENT un dictionnaire spécifique (un guide d’utilisation, un mode d’emploi), sans aller polluer un dictionnaire des données suffisamment copieux par lui-même.

Merci pour votre réponse (oui j'ai mis un moment, j'étais persuadé d'avoir répondu plus tôt.)

Ca m'a bien aidé. Pour être honnête, en avancant un peu plus et avec la pratique, à force de faire des dictionnaires et MCD, la compréhension s'est faite logiquement :)

Merci beaucoup pour vos explications claires en tout cas !

Geff