[MCD] Gestion de parc informatique

[dodo69]

Bonjour,

Je suis en phase d'apprentissage de la modélisation de données mais je suis complètement perdu.
Pour mieux comprendre nous avons un projet et la première phase consiste a la modélisation d'un MCD mais je ne comprend rien et n'arrive pas a mettre en place ne serait-ce que le schéma d' Entité-Association.

J'aimerai énormément que vous mettiez sur la voie... cela serait bien sympa, je suis complètement largué dès le début de ce projet :s

je joins un document word avec la présentation ainsi que les entité que j'ai déjà trouver, c'est un peu brouillon, mais comme je l'ai dis je suis vraiment perdu et j'ai besoin de votre aide

Je vous remercie d'avance.

Bien cordialement,
Dodo


PS: ce projet est a rendre dans 1 mois, mais cette étape est blocante...

[fsmrel]

Bonjour,


Pourriez-vous présenter le contenu des fichiers WORD ? Je ne peux pas ouvrir les .docx

[dodo69]

Bonjour,

je les joint en .doc

Il s'agit de la gestion d'un parc informatique.

Merci d'avance

Cordialement
Dodo

[fsmrel]

Bonsoir Dorian,


Il va falloir que vous utilisiez un outil vous permettant de produire des modèles conceptuels de données (MCD), sinon vous aurez du mal.

Il y a Power AMC, qui est payant (la version d’évaluation est valable quinze jours, avec prolongation éventuelle) et WinDesign payant lui aussi.

Si vous ne pouvez pas disposer de ces poids lourds, vous pouvez utiliser Open ModelSphere qui est gratuit, mais moins riche fonctionnellement (pas de possibilité de modéliser l’héritage, mais on s’en sort à peu près quand même...)

Vous avez produit quelques entités-types, mais comme des cheveux sur la soupe et sans expliquer ce que veulent dire les concepts.

Par exemple, à quoi correspond l’entité-type CARACTERISTIQUE ? Mystère complet.

Concernant l’entité-type MACHINE, la liste de ses attributs (propriétés) est plutôt succincte, alors qu’elle vous est fournie.

Il va falloir très vite établir les relations entre entités-types, sinon au plan sémantique la représentation graphique ne vaudra pas un fifrelin.

Un exemple de début :



Vous noterez que chaque entité-type est dotée d’un identifiant, en l’occurrence un attribut artificiel (le plus souvent un auto-incrément), dénué de toute signification, qui ne changera jamais de valeur (invariance), ne concernant pas l’utilisateur, mais surtout les relations entre objets. L’identifiant permet de garantir la règle d’unicité selon laquelle chaque occurrence d’entité-type est unique. Par contraste, les autres attributs sont naturels, c'est-à-dire qu’ils sont chargés de sens et valorisés par l’utilisateur. L’usage est de souligner l’identifiant dans le cartouche utilisé pour l’entité-type et accessoirement de l’accompagner d’un mickey (« <pi> » comme « primary identifier » dans le cas de Power AMC). Certains attributs naturels peuvent avoir besoin d’être soumis à une règle d’unicité, ça peut être le cas du nom de l’ordinateur, car par exemple l’utilisateur doit en fournir le nom pour signaler une panne : ça serait embêtant si plusieurs ordinateurs avaient le même nom. En l’occurrence, on définit l’attribut OrdinateurNom comme étant un identifiant alternatif (mickey « <ai> », comme alternate identifier avec Power AMC).

N’hésitez pas à illustrer. Par exemple :

Code :

1
2
3
4
5
TYPE_ORDINATEUR    OrdinateurTypeId    OrdinateurTypeNom 
                                  1    fixe
                                  2    portable
                                  3    tablette
                                ...    ...

Code :

1
2
3
4
5
SYSTEME_FAMILLE    FamilleSystemeId    FamilleSystemeNom
                                  1    Unix  
                                  2    Windows  
                                  2    MAC  
                                ...    ...

Code :

1
2
3
4
5
SYSTEME_EXPLOITATION    SystemeId    SystemeNom        DateNaissance    FamilleSystemeId
                                1    Windows XP        2001                            1
                                2    Windows Vista     2007                            1
                                3    Solaris 10        2005                            2
                              ...    ...               ...                           ...

Comme on anticipe sur la représentation des données dans la base de données, vous noterez que, la relation APPARTENIR a donné lieu dans le dernier cas à un attribut FamilleSystemeId.

De la même façon, si l’on fournit un exemple pour l’entité-type ORDINATEUR, les relations CATEGORISER et UTILISER donneront lieu respectivement aux attributs OrdinateurTypeId et SystemeId :

Code :

1
2
3
OrdinateurId    OrdinateurNom    OrdinateurTypeId    SystemeId    IPfixe          ...
           1    Oscar                           1            3    123.45.678.98   ...
         ...    ...                           ...          ...    ...             ...

On peut tiquer en voyant l’entité-type ORDINATEUR dotée d’un attribut DisqueDurVitesse, car s’il s’agit de représenter un nombre de tours/minute, un jour ça n’aura plus de sens. Mais si c’est un problème certes intéressant, il n’est pas prioritaire dans votre cas.


De la généralisation/spécialisation (héritage)

Vous avez quelques profils d’utilisateurs (enseignants, chercheurs, étudiants, etc.) avec à chaque fois des rôles distincts et variés. Ça sent la spécialisation...

Exemple : on peut considérer les utilisateurs du parc comme formant un bouquet de personnes : les étudiants d’une part, les collaborateurs d’autre part. Les données communes, disons le nom et le prénom des personnes constituent les attributs d’une entité-type racine UTILISATEUR. Ensuite, les étudiants sont séparés des collaborateurs et ont leurs données propres, par exemple leur matricule (qui n’a rien à voir avec celui des collaborateurs). Représentation graphique façon Power AMC :



Exemples de valeurs (à chaque fois il y a héritage de l’attribut UtilisateurId) :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
UTILISATEUR    UtilisateurId    UtilisateurNom    UtilisateurPrenom
                           1    Dac               Francis
                           2    Ebasque           Albert
                           3    Patausabre        Carole
                           4    Blanche           Pierre
                           5    Haddock           Archibald
                           6    Naudin            Fernand
                           7    Volfoni           Raoul
                           8    Volfoni           Paul
                           9    Zorbec            Zoé
                          10    Dantès            Edmond
                          11    Bovary            Emma
                          12    Valjean           Jean
                          13    Diafoirus         Thomas
                          14    Durand            Sophie

Code :

1
2
3
ETUDIANT    UtlisateurId    MatriculeEtudiant
                       4    1234567 
                       8    4789712

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
COLLABORATEUR   UtilisateurId    MatriculeCollaborateur    TelephoneBureau    TelMobile
                            1    AB8788                               1245    06********
                            2    B124XQ                               5487    06********
                            3    87BV45                               1258    06********
                            5    U25Y41                               1999    06********
                            6    45P017                               2578    06********
                            7    321K2S                               3659    06********
                            9    C40013                               0147    06********
                           10    1247KJ                               1178    06********
                           11    2UT654                               4141    06********
                           12    AR1458                               3940    06********
                           13    A01296                               5278    06********
                           14    558736                               2252    06********

A leur tour les collaborateurs peuvent être spécialisés en fonction de leur profil :

L’administrateur qui gère le parc, les enseignants, les chercheurs et les administratifs. Comme les enseignants utilisent certains services communs, on peut dans un 1er temps les regrouper pour ensuite les spécialiser pour ce qui les diffère :

Code :

1
2
3
4
5
CHERCHEUR_ADMINISTRATIF   UtilisateurId
                                      3
                                      5
                                     12
                                     14

Code :

1
2
3
4
5
6
7
8
ENSEIGNANT    UtilisateurId
                          2
                          6
                          7
                          9
                         10
                         11
                         13

Code :

1
2
ADMINISTRATEUR    UtilisateurId
                              1

Spécialisation des chercheurs et des administratifs pour les rôles qu'ils ne partagent pas :

Code :

1
2
3
CHERCHEUR    UtilisateurId
                         5
                        14

Code :

1
2
3
ADMINISTRATIF    UtilisateurId
                             3
                            12

Spécialisation des enseignants

Il y a ceux qui sont responsables de formation, ceux qui sont responsables d’UE et ceux qui n’ont pas de responsabilité :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
RESPONSABLE_UE    UtilisateurId
                              6
                             10
                             11

RESPONSABLE_FOR   UtilisateurId
                              7
                             13

ENS_SANS_RESP     UtilisateurId
                              2
                              9

Je n’ai pas parcouru votre document à fond, aussi l’arborescence que j’ai proposée est peut-être simplifiable, mais au début on déplie au maximum le modèle quitte à replier ensuite.

Il va falloir maintenant que vous commenciez à modéliser les autres entités-types et « tirer » les relations qui unissent tout ce petit monde... Je vous engage à illustrer par des exemples à votre tour.

Courage.

[fsmrel]

Bonsoir Dorian,


Hum... Où êtes-vous bloqué ?

Je reprends la discussion, car elle semble intéresser quelques forumeurs.

A propos des ordinateurs

On peut compléter la partie qui concerne les ordinateurs en précisant leur affectation :

- Ordinateurs affectés aux salles où ont lieu les TP,
- Ordinateurs affectés aux utilisateurs,
- Ordinateurs non affectés (disponibles, hors-service...)

La date d’affectation (ou de non affectation pour les ordinateurs non affectés) fait l’objet de l’attribut DateAffectation :



Rappel : Arbre des utilisateurs

L’administrateur étant seul, il est inutile de faire figurer une entité-type ADMINISTRATEUR dans le diagramme. Ça n’est fait ici qu’à titre indicatif. Le jour où il y aura plus d’un administrateur, alors la présence de cette entité-type sera nécessaire.


Cas des étudiants

Concernant les déclarations par un étudiant des défaillances de l’ordinateur qui lui est affecté, étant donné que ces déclarations valent pour les autres utilisateurs, elles seront traitées de façon globale dans un autre diagramme.
Concernant les demandes d’ordinateur : on peut par exemple dire que le formulaire rempli par un étudiant demandeur est composé d’une ligne (détail) par composant pour lequel il précise son besoin. Comme l’énoncé demande de tenir compte du format des données (numérique/texte), on peut spécialiser la ligne détail à cet effet :




Cas des enseignants

Le diagramme ci-dessous représente les demandes d’affectation d’ordinateurs par les responsables d’UE. La contrainte d’inclusion qui y figure exprime la règle selon laquelle un responsable d’UE qui formule une demande pour une UE doit diriger cette UE. Les associations-types Effectuer demande et Diriger sont appelées respectivement la portée et la cible de la contrainte, tandis que l’entité-type RESPONSABLE_UE est appelée pivot de la contrainte. Se reporter au fil qui traite des
contraintes d’inclusion (figure 9).



Le diagramme ci-dessous représente l’affectation des salles par les responsables de formation. Y figure aussi l’affectation des ordinateurs aux salles de TP. Je fais observer que l’énoncé qui vous est proposé est ambigu et mal formulé : on ne sait pas trop si les TP d’une UE ne peuvent se dérouler à un instant donné que dans une salle (groupement des étudiants d'une UE dans une seule salle), ou bien si ces TP peuvent se dérouler simultanément dans plusieurs salles (répartition des étudiants d'une UE dans les salles). Je prendrai donc des exemples dans les deux cas.

Supposons que la salle 1 ait été affectée à l’UE 1 :

1er cas : les TP d’une UE peuvent se dérouler dans plus d’une salle en même temps

Code :

1
2
3
UE    Salle    Annee    Semestre    SalleTPJour    SalleTPTrancheHoraire
 1    1        2010     1           lundi          [09:12]    
 1    2        2010     1           lundi          [09:12]            légal

2e cas

Code :

1
2
3
UE    Salle    Annee    Semestre    SalleTPJour    SalleTPTrancheHoraire
 1    1        2010     1           lundi          [09:12]    
 1    2        2010     1           lundi          [09:12]            illégal

Note : pour éviter des mélanges fâcheux, on veillera à ce que le même jour et à la même heure deux UE différentes n’occupent pas la même salle. Cette contrainte donne lieu à la dépendance fonctionnelle :

{Salle, Annee, Semestre, SalleTPJour, SalleTPTranche horaire} -> {UE}

Code :

1
2
3
UE    Salle    Annee    Semestre    SalleTPJour    SalleTPTrancheHoraire
 1    1        2010     1           lundi          [09:12]    
 2    1        2010     1           lundi          [09:12]            illégal

Diagramme correspondant au 1er cas :



Diagramme correspondant au 2e cas. Noter la contrainte d’unicité (cf. contraintes d’unicité, figures 3-4) :




La suite au prochain numéro...

Si vous avez besoin d’éclaircissements sur tout cela, n’hésitez pas à poser vos questions. De même dites quand vous avez une approche différente sur tel ou tel point.

[fsmrel]

Un complément

Rôle des enseignants dans les UE :

[fsmrel]

Diagramme relatif aux défaillances



Cas de la contrainte d’inclusion relative aux ordinateurs affectés à des salles.

Étant donné les variables relationnelles (dérivées des entités-types et associations-types du diagramme conceptuel et donnant lieu à des tables dans le contexte SQL) :

UE {UEId, UtilisateurIdResponsableFor, UtilisateurIdResponsableUE, ...},
ENSEIGNER {UEId, UtilisateurId, ...},
AFFECTER_SALLE {UEId, SalleNo, Annee, Semestre, ...},
ORDINATEUR_AFFECTE_A_SALLE {OrdinateurId, SalleNo, ...},
DECLARATION_DEFAILLANCE_SALLE_TP {DefaillanceNo, OrdinateurId, ...},
DECLARATION_DEFAILLANCE {DefaillanceNo, DefaillanceDateDeclaration, ...}.

La contrainte se traite ainsi au niveau relationnel :

Projection de la variable UE sur les attributs UEId et UtilisateurIdResponsableFor,
Projection de la variable UE sur les attributs UEId et UtilisateurIdResponsableUE,
Projection de la variable ENSEIGNER sur les attributs UEId et UtilisateurId,
Union des trois projections,
Jointure naturelle de cette union avec les variables AFFECTER_SALLE, ORDINATEUR_AFFECTE_A_SALLE, DECLARATION_DEFAILLANCE_SALLE_TP, DECLARATION_DEFAILLANCE.

La date de déclaration (attribut DefaillanceDateDeclaration de la variable DECLARATION_DEFAILLANCE) doit appartenir à la fourchette de dates obtenue à partir des attributs Annee et Semestre (cf. variable AFFECTER_SALLE).

[fsmrel]

Bonsoir,


Diagramme relatif aux chercheurs et aux administratifs

Achats, renouvellements (pour les défaillances, voir la figure 8).



Si vous avez besoin de compléments d’information, n’hésitez pas à poser vos questions.


P.-S. Je suis d’une autre époque , aussi quelqu’un pourrait-il m’expliquer, vu de l’intérieur, ce à quoi correspond une UE ? De combien d’étudiants est-elle composée en moyenne ? Etc. J’ai jeté un coup d'oeil à Wikipedia, mais bon, ça manque de piment...

[albu68]

Merci beaucoup pour ses informations, ça m'a donnés des idées pour un projet de Gestion de Parc en VB sous Studio 2010 via MySQL.