Discussion :

[Jichaels]

Bonjour à tous,

Je suis actuellement en stage et ai pour mission de reprendre et restructurer une base de données vieilles de plus de 20 ans. Ce n'est même pas une base relationnelle (quelques liens sont présents mais rien à voir avec de vraies relations).
J'ai survolé les MCD dans le cadre des bases de données l'année passée, et devoir réaliser un travail aussi conséquent sur une base aussi énorme ma parait vraiment compliqué. J'ai tout de même essayer de reprendre une première partie des tables et de lier celles que je pensais entre elles, pour avoir un début de structure cohérente, mais les modèles relationnels sont assez flou pour moi (surtout sur le choix des clés primaires/étrangères et comment relier les tables).

Je vous propose ma version actuelle de cette ''partie'' de la base, mais j'ai peur qu'on ne puisse vraiment m'aider sans connaitre les règles et contraintes qui régissent la base ( que je ne connais pas moi même )

Merci à ceux qui prendront le temps de m'aider, si c'est tout de même possible.

[escartefigue]

Bonjour,

Je n'arrive pas à ouvrir le document en PJ

Quelle est la base de données d'origine ?

[Jichaels]

Bonjour, merci de votre réponse, je joins à nouveau l'image (j'arrive à ouvrir l'autre je ne comprends pas pourquoi vous ne pouvez pas )

Pour faire relativement simple, la société pour laquelle j'effectue mon stage utilisait le logiciel Paradox développé par Corel. Cependant, ce logiciel n'est plus maintenu depuis 2003... et plante très régulièrement, soucis techniques... etc
Ce logiciel m'a l'air d'être un SGBD qui permet de créer des interfaces et d’interagir directement avec son propre système de base de données.

Je n'ai aucune réelle idée de la structure de la base de données actuelle, il n'y a aucun lien entre les tables, Paradox semble piocher les données un peu là où il veut... Je peux générer une sorte de diagramme mais c'est incompréhensible (rien à voir avec du MCD/UML).

J'essaye donc de reconstruire la base avec les tables actuelles, en faisant moi même les liens, sans connaitre vraiment la moitié des attributs présents et l'utilité de certaines table. La base a été créée, modifié (bidouiller) depuis plus de 20ans, autant dire que c'est un sacrée foutoir...

[escartefigue]

Bonjour,

Pas de souci avec la nouvelle image

Comme vous le mentionnez, il est difficile de critiquer un modèle sans avoir la liste exhaustive des règles de gestion

Toutefois il apparait que ce modèle mélange de la modélisation conceptuelle et logique.
Par exemple, l'entité-type Matériel, au niveau conceptuel, ne peut partager les mêmes identifiants que l'entité-type société. C'est la dérivation du MLD qui permet de propager les identifiants dans certaines tables, celles issues des associations d'une part, et celles dont la cardinalité maxi est 1 d'autre part

Quelques remarques d'ordre général :
- Pour les associations, on utilise le plus souvent des verbes à l'infinitif, et il ne faut pas de doublons (appartient ou possède sont utilisés plusieurs fois)
- Vous n'avez quasiment que des attributs de type texte, à modifier d'urgence à minima pour toutes vos dates, et aussi pour vos identifiants primaires.
- Pour les identifiants primaires, privilégiez des attributs stables, donc asémantiques, et concis. Idéalement des colonnes de type small ou integer. Ca ne vous empêchera pas par la suite de définir des identifiants alternatifs plus fonctionnels et du type qui vous conviendra.

Si la base de données d'origine est pleine de verrues et mal conçue, vous serez gagnant de repartir de la base (pas de la base de données, mais de la base du processus de modélisation), à savoir la collecte des règles de gestion actuelles, qui ont pu évoluer depuis la conception de l'ancienne base de données. Ce sera ensuite plus facile de modéliser quelque chose de propre.

[Jichaels]

Par exemple, l'entité-type Matériel, au niveau conceptuel, ne peut partager les mêmes identifiants que l'entité-type société. C'est la dérivation du MLD qui permet de propager les identifiants dans certaines tables, celles issues des associations d'une part, et celles dont la cardinalité maxi est 1 d'autre part

C'est bien ce qui me semblait, j'avais vu que lors d'une cardinalité 1,1 - 0,n on basculait l'attribut dans la table portant la cardinalité 1,1. C'est bien cela ?

Pour les associations, on utilise le plus souvent des verbes à l'infinitif, et il ne faut pas de doublons (appartient ou possède sont utilisés plusieurs fois)

J'avoue ne pas être très inspiré à ce niveau là . Cependant toutes les associations ne donnerons pas lieu à des tables (si j'ai bien compris) et j’éviterais évidement les doublons lors du passage au code (je vais tout de même essayer de modifier cela)

Pour les identifiants primaires, privilégiez des attributs stables, donc asémantiques, et concis. Idéalement des colonnes de type small ou integer. Ca ne vous empêchera pas par la suite de définir des identifiants alternatifs plus fonctionnels et du type qui vous conviendra.

Est ce que rajouter un attribut du type MaterielID à chaque table est une bonne pratique ? J'y avais pensé mais le fait de rajouter des attributs me semblait assez ''lourd''. Qu'en est il des clés primaires composées de plusieurs attributs ?

Vous n'avez quasiment que des attributs de type texte, à modifier d'urgence à minima pour toutes vos dates, et aussi pour vos identifiants primaires.

Je pense utiliser SQLite pour la mise en place du remplacement du logiciel Pradox (avec une interface web plus facile à utiliser / pas d’installation nécessaire), qui ne gère que les types NULL, INTEGER, REAL, TEXT, et BLOB. Pourquoi est qu'un champ texte est un problème pour le cas d'une date / d'une clé primaire ?

Si la base de données d'origine est pleine de verrues et mal conçue, vous serez gagnant de repartir de la base (pas de la base de données, mais de la base du processus de modélisation), à savoir la collecte des règles de gestion actuelles, qui ont pu évoluer depuis la conception de l'ancienne base de données. Ce sera ensuite plus facile de modéliser quelque chose de propre.

C'est bien évidement aussi mon point de vue, mais vu la taille gigantesque de la base, et le nombres de données déjà présentes et utilisée (les techniciens se servent du logiciel tout les jours malgré les problèmes), je ne pense pas que je puisse le faire (je le rappelle je suis en stage pour une assez courte durée, jusqu'en juin). Une liste exhaustive des règles pour cette base (dont il reste encore beaucoup de tables que je n'ai pas encore traitées), j'ose difficilement l'imaginer

Merci encore pour vos précieux conseils, je vais en avoir bien besoin

[escartefigue]

C'est bien ce qui me semblait, j'avais vu que lors d'une cardinalité 1,1 - 0,n on basculait l'attribut dans la table portant la cardinalité 1,1. C'est bien cela ?

Oui mais c'est au moment où l'on génère le MLD, il ne faut pas dupliquer les identifiants dans le MCD

J'avoue ne pas être très inspiré à ce niveau là . Cependant toutes les associations ne donnerons pas lieu à des tables (si j'ai bien compris) et j’éviterais évidement les doublons lors du passage au code (je vais tout de même essayer de modifier cela)

il est vrai que ce n'est pas toujours facile de trouver des verbes bien distincts pour toutes les associations, aucune importance, vous pouvez mettre par exemple relation_1, relation_2 etc... comme noms en attendant d'être plus inspirés

Est ce que rajouter un attribut du type MaterielID à chaque table est une bonne pratique ? J'y avais pensé mais le fait de rajouter des attributs me semblait assez ''lourd''. Qu'en est il des clés primaires composées de plusieurs attributs ?

Oui, un identifiant technique est souvent la solution faute d'identifiant naturel répondant aux critères d'une clefs primaire, à savoir stable, asémantique et concise. Un identifiant composé est bien sur possible, c'est le cas par exemple des entités-types faibles dont l'identifiant est composé pour partie de l'identifiant de l'entité-type forte. Cas typique : l'ET "ligne de facture" dont l'identifiant est composé du n° de facture (hérité de l'ET facture) et du numéro de ligne

Pourquoi est qu'un champ texte est un problème pour le cas d'une date / d'une clé primaire ?

Une date dans une colonne non date c'est un ENORME problème car
- une colonne de type date est contrôlée automatiquement par le SGBD quel qu'il soit (validité, année bissextile ou pas etc...)
- une colonne de type date s'affranchit du format de saisie (JJ-MM-AAAA ou AAAA/MM/JJ etc...)
- une colonne de type date vous permet de trier (order by), contrôler les chevauchements, effectuer des calculs (+/- njours) etc... ce que ne permet pas n'importe quel autre format
- une colonne de type date, dans certains SGBD, prend moins de place qu'un format texte ou char
Pour les clefs primaires, il faut privilégier les données de format smallint ou integer (ou bigint si volumes énormes) car ces formats permettent de très nombreuses valeurs dans un faible encombrement.
Exemple une clef de type char(12) pèse 12*8 = 96 bits ce qui pour un processeur 32 bits coute 3 cycles CPU et 2 cycles pour un processeur 64 bits
Une clef de type integer ne pèse que 32biits et permet de stocker beaucoup plus de valeurs qu'un char(12)

[Jichaels]

Bonjour escartefigue,

J'ai donc supprimé les attributs ''dupliqués'' et modifié les noms des relations.

Cependant, je ne sais pas vraiment quand rajouter un identifiant technique plutôt que d'utiliser une clé primaire composée

Je vais, comme vous me le conseillez, passer les dates en format DATE mais encore une fois SQLite ne gère pas les dates (des fonctions sont disponible pour travailler avec en temps que date, mais sont tout de même stockées en format TEXT).

Je ne remet pas le diagramme tout de suite car seul ce que j'ai cité plus haut à changé.

Merci encore pour votre aide.

[SQLpro]

Bonjour escartefigue,

J'ai donc supprimé les attributs ''dupliqués'' et modifié les noms des relations.

Cependant, je ne sais pas vraiment quand rajouter un identifiant technique plutôt que d'utiliser une clé primaire composée

Au niveau du MCD, jamais de clé composées ni sémantique. Si clé sémantique la transformé en clef subrogée . Les clef composées viendront naturellement au niveau du MPD. Cas des associations n-aires en particulier.

A +

[JPhi33]

Bonjour à tous,

Je peux générer une sorte de diagramme mais c'est incompréhensible (rien à voir avec du MCD/UML)

Jichaels, il y a peut-être une possibilité de rétro conception en partant du diagramme généré par Paradox.
Il existe un forum Paradox sur Developpez.net. Tu pourrais y poser la question.

Le problème avec la voie dans laquelle tu t'es engagé, c'est l'injection des données dans ta nouvelle base de données à partir de l'ancienne. Si les modèles ne correspondent pas et sans connaissance solide des règles de gestion (ce qui est le cas), tu t'exposes à des pertes de données et à des incohérences.

[Jichaels]

Bonjour,

Je suis conscient de cette possibilité, le problème est que la base n'est pas relationnelle, part dans tout les sens, faire de la retro conception avec cela me parait très très mauvais.

De plus, énormément de doublons, ligne inutiles... etc sont présentes et je dois donc les supprimer. Je ne pense pas perdre de données car j'ai toutes les tables sous la main cependant, et j'ai trouvé une technique plutôt sympa pour passer les bases Paradox en fichiers CSV, et des les importer ensuite avec SQLite.

Merci tout de même de votre réponse, j'ai bientôt terminé mon MCD, je le posterais même si je ne pense pas qu'on puisse en faire grand chose

EDIT :



Si vous voyez des énormités dites le moi, par exemple je sais pas si les héritages sont pertinent ici

[JPhi33]

Bonjour,

Si vous voyez des énormités dites le moi, par exemple je sais pas si les héritages sont pertinent ici

En ce qui concerne "l'héritage", le concept mis en oeuvre est la généralisation / spécialisation. Une entité générale est spécialisée en 1 (rarement) ou plusieurs entités. Sous réserve que ma compréhension des entités de type "document" soit la bonne, il apparaît qu'un document (i.e. une occurrence de l'entité Document) est relatif soit à un essai, soit à une prestation, soit à un contrat, etc. Dans ce cas, il s'agit du même ensemble de spécialisations de l'entité Document (DocHist semble échapper à cet ensemble). Cela se traduit par un seul symbole "triangle" relié d'une part à Document (généralisation) d'autre part à chacune des autres entités de type document (spécialisations).
En ce qui concerne les tables du modèle logique inféré à partir du MCD, ça ne changera rien. En revanche, concernant l'expression sémantique du MCD, ça permet de poser un opérateur indiquant la disjonction ou non et la couverture ou non (voir mon explication à hyperion13) et d'implémenter cet opérateur soit dans le SGBD soit dans l'applicatif).

Il subsiste encore beaucoup d'identifiants redondants : RefDoc, NoInventaire, ... et d'une manière générale beaucoup de propriétés ("attributs") dans le même cas : DateDebut, Titre, etc. Certaines entités ne sont pas identifiées (Planification, Intervention, ...)

Tout ne se fera pas en une fois et le chemin est encore long mais nous sommes là pour t'aider. Courage !

[Jichaels]

Bonjour Jphi33,

Il est vrai que mes multiple Doc_X (sauf DocHist) n'apporte rien de plus, je vais donc supprimer ces héritages.

Pour le cas des table non-identifiées, c'est dû au fait que j'ai enlevé certains attribut comme me l'a conseillé Escartefigue. Le problème c'est que certains de ces attributs étaient clés primaires.

Le ''seul'' dernier problème qu'il me reste est le suivant :

Je ne sais pas quelle modélisation est pertinente entre :
et

Merci encore

[JPhi33]

Bonjour Jichaels,

Je ne sais pas quelle modélisation est pertinente

La 2e sans hésitation ! (voir le post #8 de SQLpro)

[Jichaels]

Bonjour,

J'ai suivi tous les conseils qui m'ont été donné et j'ai (enfin) fini mon MCD. Il perdure surement des erreurs mais n'ayant aucune règle de gestion je pense que c'est déjà pas mal.
Comme j'ai changé énormément les tables je vais surement avoir du mal à faire la migration des données par contre.

Je poste la dernière version et passe le sujet en résolue, merci encore à tous.