Discussion :

[xav67]

Bonjour,

j'ai un projet à réaliser qui est une application web pour calculer les coûts d'un datacenter.
J'ai déjà fait mon MCD mais je pense qu'il est possible de l'améliorer.
J'ai différentes tables avec des données sur les machines, applications etc.. Cette partie me semble correctement modélisé par contre j'ai un problème avec des unités qui interviennent dans les formules du prix.
J'ai 7 services pour lesquels je dois déterminer le prix, à chaque service est attribué une unité d’œuvre différentes, ces unités changent tous les ans.
J'ai 7 tables différentes qui ressemblent à ca :
Bdd (id,année,sgbd,valeur)
Os (id,année,valeur)
Application (id,année,type,environnement,valeur)
etc...
Comme vous pouvez le constater l'id (qui est virtuel), l'année et la valeur sont communs à toutes les tables par contre, les attributs peuvent varier suivant les services, certains en ont 2 d'autres 0.
Quand je souhaite calculer le prix d'un projet je dois récupérer l'ensemble des caractéristiques des machines impliquées dans ce projet puis utiliser ces caractéristiques pour récupérer la bonne unité d’œuvre. En ce moment je fais une nouvelle requête pour chaque machine. Pour déterminer le prix d'un projet j'ai donc le nombre de machine * 7 requêtes ce qui est énorme pour une application web. J'ai donc pensé à faire 7 requêtes pour récupérer les unités en une fois puis les traiter au niveau du back end (ce qui est bien plus logique d'ailleurs) malheureusement je trouve cela encore trop lourd.
Je me demandais s'il était possible d'améliorer mon MCD pour alléger la charge sur ma bdd ou bien changer de technique de calcule.
Merci d'avance pour vos suggestions.

[fsmrel]

Bonsoir xav67,

J'ai déjà fait mon MCD.

C’est très bien, mais si vous souhaitez des suggestions d’amélioration, fournissez-nous vos règles de gestion et votre MCD.

J'ai différentes tables

Là on est descendu d’un cran, on n’est plus au stade MCD mais du MLD. Veillez à être rigoureux dans les termes utilisés.

J'ai 7 services

Qu’est-ce qu’un service ? A partir des exemples que vous fournissez, définissez plus précisément chacun d’entre eux. Pour chaque attribut donnez-en là aussi la définition, sa fonction. Ceci fait, donnez une définition globale mais rigoureuse du service.

à chaque service est attribué une unité d’œuvre

Donnez votre définition de l’unité d’oeuvre.

l'id (qui est virtuel), l'année et la valeur sont communs à toutes les tables

Les noms sont les mêmes, mais fonctionnellement, rien n’est moins sûr. Qu’en est-il ? Cherchez-vous à vous orienter vers la généralisation/spécialisation des entités-types (héritage...) ?

Quand je souhaite calculer le prix d'un projet

Faites apparaître l’entité-type PROJET et ses associations, les règles de gestion des données qui vont avec (le QUOI, c'est-à-dire les éléments impliqués dans le calcul).

Je dois récupérer l'ensemble des caractéristiques des machines impliquées dans ce projet

Faites apparaître l’entité-type MACHINE et ses associations, ainsi que les règles de gestion des données concernées.

Je me demandais s'il était possible d'améliorer mon MCD

=> Retour à la 1re observation !

___________

Tout ceci manque de rigueur. Pour vous, tout est manifestement clair, mais pour nous tel n’est pas le cas, alors qu’avec plus de détails, on pourrait peut-être vous aider à améliorer votre MCD et ce qui s’ensuit.

[xav67]

Bonjour,

C’est très bien, mais si vous souhaitez des suggestions d’amélioration, fournissez-nous vos règles de gestion et votre MCD.

Une version très simplifié pour 3 services donnerait ça :

Là on est descendu d’un cran, on n’est plus au stade MCD mais du MLD. Veillez à être rigoureux dans les termes utilisés.

Je pensais qu'on pouvait déjà parler de tables au niveau du MCD, autant pour moi

Qu’est-ce qu’un service ? A partir des exemples que vous fournissez, définissez plus précisément chacun d’entre eux. Pour chaque attribut donnez-en là aussi la définition, sa fonction. Ceci fait, donnez une définition globale mais rigoureuse du service.

Les services sont les prestations que nous font payer le prestataire.
On peut retrouver : le management des OS, celui des base de données, des applications, le volume disque approvisionné et celui managé et le backup.
L'addition du prix de tous les services pour chaque machine donne la facture à la fin du mois.
En reprenant le MCD simplifié précédent :
Le prix du volume disque provisionné se calcule de la facon suivant : volume * unité d'oeuvre.
Le prix du management des base de données et des OS dépend seulement de l'unité d'oeuvre.
Par exemple pour récupérer l'unité lié au service qui est celui des base de données une jointure sera faite entre le base de données de la machine et celle de la table contenant l'unité.
En réalité le calcul est plus complexe, par exemple le volume disque peut être facturé ou non suivant l'emplacement de la machine (dans ou en dehors du datacenter). Beaucoup d'attributs sur les machines ont une influence sur le prix mais mon problème se situe uniquement sur les unités d'oeuvre, il ne me semble pas pertinent de les indiquer ici.

Donnez votre définition de l’unité d’oeuvre.

La définition de wikipédia (https://fr.wikipedia.org/wiki/Unit%C3%A9_d%27%C5%93uvre) me parait meilleur que celle que je pourrais donner.

Les noms sont les mêmes, mais fonctionnellement, rien n’est moins sûr. Qu’en est-il ? Cherchez-vous à vous orienter vers la généralisation/spécialisation des entités-types (héritage...) ?

Les noms sont les mêmes et fonctionnellement c'est pareil. En prenant du recul sur mon premier message je me dis que ce n'est pas forcément un problème de modélisation mais peut être de méthode (cf fin du premier post).

Tout ceci manque de rigueur. Pour vous, tout est manifestement clair, mais pour nous tel n’est pas le cas, alors qu’avec plus de détails, on pourrait peut-être vous aider à améliorer votre MCD et ce qui s’ensuit.

Effectivement et j'en suis désolé, je travaille dessus depuis si longtemps que ca me parait évident. J'espère que les précisions apportées suffiront.

[escartefigue]

Bonjour,

Pour bien construire le socle de votre modèle, il faut rédiger les règles de gestion sous la forme suivante :

R001 : un projet concerne une à plusieurs machines
R002 : une machine concerne un et un seul projet
R003 : une machine possède zéro à plusieurs volumes disque
R004 : un volume disque est possédé par une et une seule machine
R005 etc....
A minima, il faut une règle pour chaque "patte" de chaque relation
C'est à votre maitrise d'ouvrage de communiquer ces règles.

Vous constatez que dans ces règles de gestion, il y a des verbes : "concerner" dans R001 et R002, "posséder" dans r003 et "R004"...
Ce sont ces verbes, de préférence à l'infinitif, qui permettent de nommer vos relations dans le MCD
Ex : PROJET 1,n --- concerner --- MACHINE

Examinons l'entité-type (ET) PROJET :
Vous avez positionné 3 attributs : un identifiant technique, très bien, une date de lancement pourquoi pas, mais aussi un responsable
Modéliser ainsi signifie que un projet concerne un et un seul responsable et qu'un responsable ne gère (à vie) qu'un et un seul projet... peu probable
Un projet peut probablement changer de responsable, en cas de démission par exemple, et un responsable aura au cours de sa carrière certainement plusieurs projets à gérer.
Donc, il faut externaliser les responsables, et plus largement les personnes en général (si vous avez à gérer d'autres personnes que les responsables) dans une nouvelle ET "PERSONNE" ou "RESPONSABLE" selon le cas.

A priori, en fonction des règles de gestion que vous devrez compléter, je dirai qu'il faut modéliser une relation ternaire comme suit :
PROJET 1,n --- affecter --- 0,n PERSONNE
.........................│
ROLE 0,n --------┘

Ce "mini-MCD" ci-dessus implique qu'un projet a au moins une personne affectée, qu'une personne n'est pas forcément affectée à un projet et que certains rôles ne sont pas utilisés dans certains projets
Si de plus une personne ne peut exercer qu'un seul rôle dans un même projet, alors il faudra modéliser une règle de gestion particulière : une Contrainte d'Intégrité Fonctionnelle (CIF) (dans mon exemple, matérialisée par une flèche en direction de l'ET "PERSONNE"
Il faudra aussi vérifier si une personne peut changer de rôle en cours de projet (un développeur est promu chef de projet par exemple)...
Encore une fois, ce sera à affiner en fonction de vos règles de gestion qui sont, vous le comprenez, incontournables

Concernant l'ET MACHINE :
L'OS d'une machine est-il invariant dans le temps ? à vérifier, on peut supposer à minima que sa version varie
Et là aussi, plusieurs machines ont sans doute le même OS, du coup, même raisonnement que pour les personnes dans les projets, il faut sortir les OS des machines comme suit
MACHINE 0,n --- installer --- 0,n SYSTEME_EXPLOITATION
Ainsi vous ne décrirez chaque OS qu'une seule fois

Appliquez le même type de raisonnement avec les autres attributs des autres ET

Expliquez le role des ET orphelines "volume_disque_provisionné_unité" "mangement_os_unité" et "database_wu" dont les noms me laissent... perplexe

[xav67]

Bonjour,

Vous constatez que dans ces règles de gestion, il y a des verbes : "concerner" dans R001 et R002, "posséder" dans r003 et "R004"...
Ce sont ces verbes, de préférence à l'infinitif, qui permettent de nommer vos relations dans le MCD
Ex : PROJET 1,n --- concerner --- MACHINE

Malheureusement le logiciel que j'utilise ne permet pas d'avoir deux noms de relation identique d'ailleurs je ne nomme les relations qu'à partir du moment où elle sont de type n à n étant donné qu'il en résulte une table de relation. Sans doute une mauvaise habitude.

Examinons l'entité-type (ET) PROJET :
Vous avez positionné 3 attributs : un identifiant technique, très bien, une date de lancement pourquoi pas, mais aussi un responsable
Modéliser ainsi signifie que un projet concerne un et un seul responsable et qu'un responsable ne gère (à vie) qu'un et un seul projet... peu probable
Un projet peut probablement changer de responsable, en cas de démission par exemple, et un responsable aura au cours de sa carrière certainement plusieurs projets à gérer.
Donc, il faut externaliser les responsables, et plus largement les personnes en général (si vous avez à gérer d'autres personnes que les responsables) dans une nouvelle ET "PERSONNE" ou "RESPONSABLE" selon le cas.

A priori, en fonction des règles de gestion que vous devrez compléter, je dirai qu'il faut modéliser une relation ternaire comme suit :
PROJET 1,n --- affecter --- 0,n PERSONNE
.........................│
ROLE 0,n --------┘

Ce "mini-MCD" ci-dessus implique qu'un projet a au moins une personne affectée, qu'une personne n'est pas forcément affectée à un projet et que certains rôles ne sont pas utilisés dans certains projets
Si de plus une personne ne peut exercer qu'un seul rôle dans un même projet, alors il faudra modéliser une règle de gestion particulière : une Contrainte d'Intégrité Fonctionnelle (CIF) (dans mon exemple, matérialisée par une flèche en direction de l'ET "PERSONNE"
Il faudra aussi vérifier si une personne peut changer de rôle en cours de projet (un développeur est promu chef de projet par exemple)...
Encore une fois, ce sera à affiner en fonction de vos règles de gestion qui sont, vous le comprenez, incontournables

J'ai mis responsable mais en réalité c'est le créateur du projet, dans le cas ou j'aurais besoin d'informations supplémentaire sur les personnes alors effectivement une table Personne aurait fait son apparition mais dans ma situation uniquement un nom me suffit.

Concernant l'ET MACHINE :
L'OS d'une machine est-il invariant dans le temps ? à vérifier, on peut supposer à minima que sa version varie
Et là aussi, plusieurs machines ont sans doute le même OS, du coup, même raisonnement que pour les personnes dans les projets, il faut sortir les OS des machines comme suit
MACHINE 0,n --- installer --- 0,n SYSTEME_EXPLOITATION
Ainsi vous ne décrirez chaque OS qu'une seule fois

Je dirais que l'OS reste fixe mais ce n'est pas une certitude. En effet plusieurs machines ont le même OS mais seul le nom m'intéresse, je me vois mal faire une entité OS avec une seule colonne et une fois le MLD sorti, une clé étrangère dans la table machine vers la table OS qui ne contiendra qu'une seule colonne.
Par contre j'ai du mal à comprendre l’intérêt de la relation de type n à n. Une machine ne possède qu'un OS.

Expliquez le role des ET orphelines "volume_disque_provisionné_unité" "mangement_os_unité" et "database_wu" dont les noms me laissent... perplexe

[/QUOTE]

C'est justement ici qu'est tout mon problème, ce sont les unités d’œuvre expliquées plus haut.

[escartefigue]

Malheureusement le logiciel que j'utilise ne permet pas d'avoir deux noms de relation identique d'ailleurs je ne nomme les relations qu'à partir du moment où elle sont de type n à n étant donné qu'il en résulte une table de relation. Sans doute une mauvaise habitude.

Il ne s'agit pas d'utiliser plusieurs fois le même nom, c'est par ce que plusieurs règles (à minima 2) concernent la même relation qu'on trouve le même verbe dans deux règles
Effectivement, les relations qui ne deviennent pas des tables ne nécessitent pas obligatoirement un nom, quoi que ça puisse aider à la lecture du MCD

J'ai mis responsable mais en réalité c'est le créateur du projet, dans le cas ou j'aurais besoin d'informations supplémentaire sur les personnes alors effectivement une table Personne aurait fait son apparition mais dans ma situation uniquement un nom me suffit.

Si l'effectif de l'entreprise est tout petit, un nom suffit peut être, mais ça ne serait certainement pas le cas dans une grande entreprise où les "Martin" ou "Dupond" sont nombreux
Et encore une fois, même si "Dupond" est unique, peut être a-t-il créé plusieurs projets. S'il n'y a pas de référence à une ET des personnes, on trouvera peut être des "Dupond", "Dupont" et autres variantes alors qu'il s'agira du même créateur.

Je dirais que l'OS reste fixe mais ce n'est pas une certitude. En effet plusieurs machines ont le même OS mais seul le nom m'intéresse, je me vois mal faire une entité OS avec une seule colonne et une fois le MLD sorti, une clé étrangère dans la table machine vers la table OS qui ne contiendra qu'une seule colonne.
Par contre j'ai du mal à comprendre l’intérêt de la relation de type n à n. Une machine ne possède qu'un OS.

0,n est possible si vous partitionnez la machine pour installer deux OS. Si vous n'avez pas ce besoin, faites simple

C'est justement ici qu'est tout mon problème, ce sont les unités d’œuvre expliquées plus haut.

Expliquées où ça ?

[xav67]

Si l'effectif de l'entreprise est tout petit, un nom suffit peut être, mais ça ne serai certainement pas le cas dans une grande entreprise où les "Martin" ou "Dupond" sont nombreux
Et encore une fois, même si "Dupond" est unique, peut être a-t-il créé plusieurs projets. S'il n'y a pas de référence à une ET des personnes, on trouvera peut être des "Dupond", "Dupont" et autres variantes alors qu'il s'agira du même créateur.

Le responsable n'est pas identifié avec un nom/prénom mais avec un identifiant unique à chaque membre de l'entreprise.

Expliquées où ça ?

Les services sont les prestations que nous font payer le prestataire.
On peut retrouver : le management des OS, celui des base de données, des applications, le volume disque approvisionné et celui managé et le backup.
L'addition du prix de tous les services pour chaque machine donne la facture à la fin du mois.
En reprenant le MCD simplifié précédent :
Le prix du volume disque provisionné se calcule de la facon suivant : volume * unité d'oeuvre.
Le prix du management des base de données et des OS dépend seulement de l'unité d'oeuvre.
Par exemple pour récupérer l'unité lié au service qui est celui des base de données une jointure sera faite entre le base de données de la machine et celle de la table contenant l'unité.
En réalité le calcul est plus complexe, par exemple le volume disque peut être facturé ou non suivant l'emplacement de la machine (dans ou en dehors du datacenter). Beaucoup d'attributs sur les machines ont une influence sur le prix mais mon problème se situe uniquement sur les unités d'oeuvre, il ne me semble pas pertinent de les indiquer ici.

Ici et à la fin du premier post.

[escartefigue]

Le responsable n'est pas identifié avec un nom/prénom mais avec un identifiant unique à chaque membre de l'entreprise.

En ce cas il est étrange d'avoir choisi un type varchar

[escartefigue]

Donc à part pour les volume disque, tous les autres services ont un prix qui dépend uniquement du nombre d'Unités d'Œuvre (UE)

Peut être pouvez vous simplifier la modélisation, en créant une ET "SERVICE" qui comprendrait un attribut UE et un attribut coefficient.
Pour tous les services hors "volume disque" le coefficient vaudrait 1
Pour les services "volume disque" ce coefficient prendrait la valeur requise.

Vous pourriez ajouter une ET "TYPE-SERVICE" pour typer les services si besoin

Je vois que vous avez défini certains attributs en type FLOAT.
Attention : il s'agit d'un type consacré aux très grands nombres, pour lesquels la valeur décimale est approximative.
A voir ce que vous voulez faire avec ces attributs, peut être que du décimal serait plus approprié surtout s'il s'agit de montants comptables !

[xav67]

Peut être pouvez vous simplifier la modélisation, en créant une ET "SERVICE" qui comprendrait un attribut UE et un attribut coefficient.
Pour tous les services hors "volume disque" le coefficient vaudrait 1
Pour les services "volume disque" ce coefficient prendrait la valeur requise.

Vous pourriez ajouter une ET "TYPE-SERVICE" pour typer les services si besoin

Je n'ai pas vraiment compris.
Le calcul du prix ne se fait pas au niveau de la base de données mais dans l'application web. Ici mon principal problème est de récupérer les unités d'oeuvre.
En général la modélisation de la base de données ne me pose pas de problème par contre, c'est la première fois que je travaille sérieusement avec une base de données. J'ai malheureusement tendance à utiliser la bdd comme si c'était un tableau en mémoire et donc faire des requêtes dès que j'ai besoin d'une information, ce qui est loin d'être optimisé.
J'ai donc pensé à tout récupérer en une fois, bien que cela ne pose pas de problème pour les machines vu que toutes les informations sont dans une même table c'est un peu plus compliqué pour les unité d'oeuvre. Étant donné que les entités possède toutes un attribut valeur je me demandais s'il n'était pas possible d'optimiser la modélisation et donc de simplifier l'utilisation au niveau de l'application web.

Je vois que vous avez défini certains attributs en type FLOAT.
Attention : il s'agit d'un type consacré aux très grands nombres, pour lesquels la valeur décimale est approximative.
A voir ce que vous voulez faire avec ces attributs, peut être que du décimal serait plus approprié surtout s'il s'agit de montants comptables !

Effectivement le type décimale me semble plus adapté ! J'ai l'habitude des langages de programmation avec seulement float/double pour représenter les nombre décimaux, je n'étais pas au courant pour le type décimale.

[escartefigue]

Ce que je propose est la modélisation suivante :

MACHINE (MA_id, MA_nom...)0,n --- beneficier ---0,n SERVICE (SE_id, SE_nom, SE_nb_UE, SE_coeff...) 1,1 --- typer --- 0,n TYPE_SERVICE (YS_id, YS_code, YS_description...)

Ainsi vous enregistrez autant de service liés à chaque machine que nécessaire, les services sont d'un certain type (maintenance OS, de la BDD...) si besoin (cas des disques) vous appliquez un coefficient différent de 1 pour le service.

Et avec ces infos, l'application pourra faire le calcul des prix

[xav67]

Le fait d'avoir une entité service regroupant les unités me plait bien mais j'ai encore du mal à correctement visualiser le fonctionnement.
Prenons un cas concret, actuellement pour calculer le prix lié à la maintenance des OS je procède de cette façon :
Select valeur from management_os_unité where os like <mon OS de machine>.
Dans la proposition je n'arrive pas à voir ou se fait le lien entre l'OS de la machine et la valeur de l'unité correspondante.

[escartefigue]

Avec un modèle tel que proposé, il y a dans la table issue de l'ET "SERVICE" des lignes qui ressemblent à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SE_id   SE_nom             SE_nb_UE   SE_COEFF 
 001    windows 7              2          1,00
 002    Seagate 1TO            3          2,65
 003    SQL server 20016       4          1,00
 004    WD 500 Giga            3          3,02

La ligne 1 est de type "management OS", les lignes 2 et 4 sont de types "volume disque" et la ligne 3 est de type "database wu" ces types permettent de faire le lien grâce à la FK "YS_id" vers la table "TYPE_SERVICE"

Du coup la requête ressemblera à quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
select SE.SE_nb_UE as nombre_UE
     , SE.SE_COEFF as Coef
From service as SE
inner join TYPE_SERVICE as YS
   on YS.YS_id = SE.YS_id
where YS_code = 'OS'
  and SE_nom like '%windows 7%'

Celà étant, rechercher comme vous le faites sur le nom avec un like, n'est certainement pas la meilleure façon d'obtenir un résultat fiable et unique
Ici j'ai fiabilisé un peu en vérifiant par jointure avec la table des types qu'on est bien sur un OS, mais c'est vraiment le service minimum

[xav67]

Je comprends mieux !
Je vais partir sur cette modélisation du coup.
Merci de votre aide.

[escartefigue]

Hum, je pense que c'est prématuré : encore une fois, l'identification par un nom est hasardeuse, or, vous vous en servez pour établir un tarif !
Gare !