Discussion :

[Huviel]

Bonjour à tous, premier post sur le forum même si je passe le plus clair de mon temps à le lire.

Je plante un peu le décor. Je fais un stage dans un lycée et j'avais comme idée de développer une petite application en php qui aurait pour but de mettre dans une base de donnée les interventions que mon maître de stage et moi effectuons(type d’intervention, temps passé,n°salle etc…). L'idée à tellement plu à mon maitre de stage à l'admin réseau qu'il m'ont proposé d'étendre mon projet pour faire en sorte que les profs puissent via un formulaire envoyer une demande d'intervention.

Donc il faut passer par l'étude d'un MCD et c'est là où je bloque.
En fait, je n'arrive pas à savoir ce que je dois modéliser ou non. J'ai commencé par faire 4 entités qui sont:
MATERIEL: (etat_pc, num_pc)
UTILISATEUR: (Nom_util, prenom_util, code_matière)
SALLE: (nom_salle)
PANNES: (type_panne)

Je n'ai pas encore relié les entités entre elles pour le moment. Je n’arrive pas à voir ce qu’il faudrait que je modélise, en fait ce qui me manque c’est la démarche de réflexion.
Si vous pouviez me donner des pistes

Merci

[CinePhil]

Apparemment, il n'y a pas vraiment de cahier des charges ou de recueil de besoin ou un truc qui y ressemble. La première étape de la méthode Merise a donc été oubliée.
Il faudrait donc peut-être commencer par une étude du besoin non ?
Ca devrait aboutir à pouvoir rédiger des règles de gestion du style :
"Un matériel peut faire l'objet de plusieurs pannes et une panne concerne un seul matériel."
"Une panne appartient à un seul type de panne et un type de panne peut concerner plusieurs pannes"

D'où il découlera le début de MCD suivant :
Matériel -0,n----Avoir----1,1- Panne -1,1----Typer----0,n- Type de panne

Bon courage pour la suite.

[Huviel]

Merci pour ta réponse, je vais donc essayer de faire un petit cahier des charges avec des règles. Je posterai ça cet après-midi

[Huviel]

Cahier des charges:

1:Un matériel peut faire l’objet de plusieurs pannes.
2:Un matériel est identifié par un numéro.
3:Un matériel est identifié par un état et un type.(portable, pc, serveur,imprimante,copieur,téléphone)
4:Un matériel peut changer de salle au fur et à mesure des années.
5:Une panne concerne un seul type de panne. (Pb sessions => Pb réseau)
6:Un type de panne peut concerner plusieurs pannes. (Pb software => maj. logiciel, bug logiciel)
7:Une panne est identifiée par un type panne.
8:Un utilisateur peut avoir plusieurs pannes sur une même machine.
9:Un utilisateur peut utiliser plusieurs salles (mais pas en même temps).
10:Un utilisateur est identifié par un nom, prénom et un statut.
11:Un statut est représenté par un code_statut.
12:Une salle contient plusieurs machines.
13:Une salle est identifiée par un numéro.
14:Une intervention est identifiée par une date, un type de panne, un nom de prof et une salle et une heure début intervention et une heure fin intervention et un nom technicien.
15:Une intervention est réalisée par un ou plusieurs techniciens.
16:Un technicien est identifié par un nom, prénom.

MCD:

http://img1.arserve.org/FNTHL/VVELU_AMC.jpg

Notes:

Pourriez vous me dire si ce début de MCD est à peu près correct et si non, me dire quelles sont mes erreurs. Je pense avoir fait à peu près le tour du problème. Je ne suis pas certain de certaines cardinalités non plus.

Merci pour votre aide.

[CinePhil]

Deux remarques générales pour commencer :
1) éviter les cardinalités minimales à 1 des deux côtés d'une association, c'est rarement nécessaire et ça pose des problèmes à l'implémentation.

1:Un matériel peut faire l’objet de plusieurs pannes.

==> cardinalité 0,n.

A vérifier pour toutes les associations.

2) Préférer les clés primaires anonymes de type entier non nul non signé et auto-incrémenté.

2:Un matériel est identifié par un numéro.

Pourquoi la clé primaire est elle 'type_machine' ?
==> Matériel(M_Id, M_Numéro, ...)

A noter ci-dessus que le numéro de la machine sera probablement plutôt un code d'identification de type alphanumérique. Il sera certes unique et constitue une clé candidate mais n'est pas une bonne clé primaire.

3:Un matériel est identifié par un état et un type.(portable, pc, serveur,imprimante,copieur,téléphone)

Evitons la redondance des données et les éventuelles erreurs de saisie et externalisons le type dans une entité séparée. Peut-être que l'état est aussi à externaliser si ce n'est pas une valeur booléenne.

5:Une panne concerne un seul type de panne. (Pb sessions => Pb réseau)
6:Un type de panne peut concerner plusieurs pannes. (Pb software => maj. logiciel, bug logiciel)

Attention à la différence entre une panne (un événement arrivant sur une machine à une date donnée) et un type de panne (Pb sessions => Pb réseau) !
Il y a donc ici normalement deux entités et le schéma suivant :
Matériel -0,n----Avoir----1,1- Panne -1,1----Typer----0,n- Type de panne
C'est le schéma que j'avais déjà fait dans mon précédent message !

7:Une panne est identifiée par un type panne.

Euh... non ! Une panne est identifiée par un numéro de panne. Par contre elle est affiliée à un certain type de panne. Dans le schéma ci-dessus j'ai utilisé Typer, on peut remplacer éventuellement par Affilier ou Caractériser.

8:Un utilisateur peut avoir plusieurs pannes sur une même machine.

Ce n'est pas l'utilisateur qui est en panne mais la machine !
D'ailleurs cette règle telle qu'énoncée n'est pas modélisée dans le schéma.
Elle est redondante avec la règle 1.

9:Un utilisateur peut utiliser plusieurs salles (mais pas en même temps).

Je ne vois pas l'utilité de cette règle dans la gestion des pannes mais bon...

10:Un utilisateur est identifié par un nom, prénom et un statut.
11:Un statut est représenté par un code_statut.

Ceci n'est pas modélisé.

12:Une salle contient plusieurs machines.

Je dirais plutôt :
"Une salle peut contenir plusieurs machines."
==> Salle -0,n----Contenir----1,1- Machine
Equivalent à ce qui est sur le schéma mais en corrigeant la cardinalité :
Machine -1,1----Se situer----0,n- Salle

15:Une intervention est réalisée par un ou plusieurs techniciens.

OK sauf cardinalité mini à passer à zéro du côté du technicien.

16:Un technicien est identifié par un nom, prénom.

Exemple de mauvais choix de clé primaire : Si deux techniciens portent le même nom, il faut revoir le modèle !
==> Technicien(T_Id, T_Nom, T_Prénom, ...)

14:Une intervention est identifiée par une date, un type de panne, un nom de prof et une salle et une heure début intervention et une heure fin intervention et un nom technicien.

On arrive au point le plus délicat...
Il me semble que l'intervention est effectuée suite à une panne. Il y a alors deux possibilités :
- l'intervention caractérisée par sa date et ses heures de début et de fin sont des attributs de la panne ;
- une panne peut faire l'objet de plusieurs interventions qu'on veut mémoriser et il faut laisser les deux séparées.

Ce qui est sûr par contre, c'est que l'éventuelle entité Intervention ne doit pas contenir le nom du technicien ni le nom du prof (utilisateur ?) ni le numéro de la salle, lesquels seront effectivement des clés étrangères mais ne doivent pas figurer dans le MCD.

Ce que j'écrirais plutôt, en supposant qu'on mémorise séparément les pannes et les interventions, c'est :
14.1 : Une intervention est caractérisée par sa date, son heure de début, son heure de fin.

14.2 : Une intervention concerne une panne sur une machine et une panne peut faire l'objet de plusieurs interventions.

14.3 : Une intervention est demandée par un utilisateur et un utilisateur peut demander plusieurs interventions.

Ce qui donnerait le schéma :
Utilisateur -0,n----Demander----1,1- Intervention -1,1----Concerner----0,n- Panne

[Huviel]

Merci pour ta réponse très bien fournie
Je vais remodéliser tout ça, changer les cardinalitées, mettre des types à mes champs et tout revérifier avant de te faire voir la nouvelle version.

[Huviel]

Nouveau MCD:



Il doit y avoir encore des erreurs au niveau des cardinalités mais je dois pas avoir la la bonne démarche. J'espère quand même que ce nouveau MCD n'est pas catastrophique

Merci encore pour votre aide