Florent_BTS1
New Member
Voila mon MCD ... final ou non je ne sais guère ... merci de vos impressions
TP Gérence Système Informatique.
- Auteur de la discussion Florent_BTS1
- Date de début
vestale974
Well-Known Member
Bonsoir,
Un premier jet intéressant.
D'accord pour la contrainte de partition verticale.
Pour les associations Etat..., elles portent des données temporelles forcément, tout comme la CIM Etat / Intervention
Un responsable gère une salle ou des matériels ?
Comment traîtes-tu les classes, les ads IP ?
@+
Un premier jet intéressant.
D'accord pour la contrainte de partition verticale.
Pour les associations Etat..., elles portent des données temporelles forcément, tout comme la CIM Etat / Intervention
Un responsable gère une salle ou des matériels ?
Comment traîtes-tu les classes, les ads IP ?
@+
Florent_BTS1
New Member
vestale974 link=topic=68198.msg740170#msg740170 date=1192131493 a dit:
Pourrait-on parler des cardinalités? je n'ai pas encore bien compris le principe?!
vestale974
Well-Known Member
Salut Florent,
Pour les associations État X, État Y et État Z, il te faut une donnée porteuse d'information, puisqu'il est question dans l'étude de ce système d'information du suivi d'un parc de matériel informatique et équipement, d'où la nécessité d'en historiser l'organisation.
Car il faut considérer que dans le CVo d'un périphérique, d'un équipement ou d'un ordinateur il y aura plusieurs interventions et donc plusieurs états (fonction, panne, intervention).
Si tu n'historises pas et si tu ne mets pas de donnée porteuse, tu ne pourras enregistrer qu'un et un seul état sur les trois que tu proposes dans l'entité ÉTAT, sans parler de CVo.
Je rappelle aussi qu'une clé composée (CIM) n'est ni plus ni moins que la concaténation de plusieurs clés étrangères (CIF).
Donc, à titre d'exemple ÉTAT PÉRIPHÉRIQUE (#id_périphérique, #id_état, date_début_état, date_fin_état)
Concernant la notion de responsable, je pense que le SI en cours d'étude est une organisation (administrations, entreprises, établissements, etc.).
Je ne pense pas que l'étude porte aussi sur les diagrammes de flux de niv1 ou 2 !
On part alors du principe que l'entité RESPONSABLE contient les noms de tous les techniciens intervenant sur le matériel.
Donc nul besoin de schématiser une contrainte de totalité (T). C'est mon avis !
Concernant la notions de "classes", je parlais de "classes" d'élèves (voir tâches d'exploitation de ton 1er post), et non pas de "classes" de rzo.
Si tu ne dois pas ou ne veux pas traiter cette notion, ok.
Concernant les ads IP, je serais plutôt d'avis de créer une table ADRESSE_IP, sauf si tu laisses aux bons soins du DHCP de tout régler !
Un administrateur de rzo qui se respecte va créer sa ou ses tables d'adresses IP. Vous avez dû aborder le cours sur l'architecture des rzo et l'adressage IP.
Concernant le routeur, pour moi c'est un matériel.
Concernant les cardinalités :
- elles expriment le nombre de solutions mini et maxi d'un rôle entre une entité et son association,
- elles ont l'ordre suivant card(0,1), card(1,1), card(0,n) ou card(1,n)
- la règle veut que les liens d'héritage entre entités génériques et entités spécifiques ne portent pas de cardinalités. Idem pour les liens d'héritage des associations.
@+
Pour les associations État X, État Y et État Z, il te faut une donnée porteuse d'information, puisqu'il est question dans l'étude de ce système d'information du suivi d'un parc de matériel informatique et équipement, d'où la nécessité d'en historiser l'organisation.
Car il faut considérer que dans le CVo d'un périphérique, d'un équipement ou d'un ordinateur il y aura plusieurs interventions et donc plusieurs états (fonction, panne, intervention).
Si tu n'historises pas et si tu ne mets pas de donnée porteuse, tu ne pourras enregistrer qu'un et un seul état sur les trois que tu proposes dans l'entité ÉTAT, sans parler de CVo.
Je rappelle aussi qu'une clé composée (CIM) n'est ni plus ni moins que la concaténation de plusieurs clés étrangères (CIF).
Donc, à titre d'exemple ÉTAT PÉRIPHÉRIQUE (#id_périphérique, #id_état, date_début_état, date_fin_état)
Concernant la notion de responsable, je pense que le SI en cours d'étude est une organisation (administrations, entreprises, établissements, etc.).
Je ne pense pas que l'étude porte aussi sur les diagrammes de flux de niv1 ou 2 !
On part alors du principe que l'entité RESPONSABLE contient les noms de tous les techniciens intervenant sur le matériel.
Donc nul besoin de schématiser une contrainte de totalité (T). C'est mon avis !
Concernant la notions de "classes", je parlais de "classes" d'élèves (voir tâches d'exploitation de ton 1er post), et non pas de "classes" de rzo.
Si tu ne dois pas ou ne veux pas traiter cette notion, ok.
Concernant les ads IP, je serais plutôt d'avis de créer une table ADRESSE_IP, sauf si tu laisses aux bons soins du DHCP de tout régler !
Un administrateur de rzo qui se respecte va créer sa ou ses tables d'adresses IP. Vous avez dû aborder le cours sur l'architecture des rzo et l'adressage IP.
Concernant le routeur, pour moi c'est un matériel.
Concernant les cardinalités :
- elles expriment le nombre de solutions mini et maxi d'un rôle entre une entité et son association,
- elles ont l'ordre suivant card(0,1), card(1,1), card(0,n) ou card(1,n)
- la règle veut que les liens d'héritage entre entités génériques et entités spécifiques ne portent pas de cardinalités. Idem pour les liens d'héritage des associations.
@+
Florent_BTS1
New Member
Bonsoir
Bon j'ai rajouté les histoire de date et de périphérique que vous m'avez définit. Je pense que je peux conclure mon MCD ici et le rendre.
Je vous remercie des informations apportées. Si vous avez d'autres suggestions n'hésitez merci.
Et puis à bientôt pour le T.P. N°2 qui est une suite logique jusqu'à la base de donnée incrémentée sur ACCES.
vestale974 link=topic=68198.msg740390#msg740390 date=1192187408 a dit:
Bon j'ai rajouté les histoire de date et de périphérique que vous m'avez définit. Je pense que je peux conclure mon MCD ici et le rendre.
Je vous remercie des informations apportées. Si vous avez d'autres suggestions n'hésitez merci.
Et puis à bientôt pour le T.P. N°2 qui est une suite logique jusqu'à la base de donnée incrémentée sur ACCES.
vestale974
Well-Known Member
Salut,Florent_BTS1 link=topic=68198.msg740596#msg740596 date=1192209016 a dit:
Cycle de vie, voulais-je dire !
En attache, le schéma que j'aurai créé d'après les infos que tu as laissé sur ce forum.
- on a du mal à situer l'organisation du SI étudié !
- les tâches et les règles ne sont pas très claires !
- on ne sait pas si on doit ou non situer le temporel dans certaine relation !
-> l'état d'un matériel va forcément évoluer dans le temps (1 jour, il sera fonctionnel, 1 autre jour il sera en maintenance et 1 autre il sera retiré et réformé).
-> si changement d'état, cela signifie intervention ou maintenance.
-> etc.
- des classes fréquentent des salles, mais dans quel ordre ? Doit-on supposer qu'une classe fréquentera toujours la même classe ou bien doit-on admettre qu'en fonction du jour et d'une heure précise les fréquentations diffèreront ?
- le responsable, on ne le situe pas précisément dans le SI ! Il est responsable de quoi ? des travaux finis, des maintenances, du site, des salles, des classes ?
- dans mon schéma je n'utilise pas d'héritage, j'utilise une association unaire, parce qu'un matériel est un élément unique dans le stricte sens du terme. Ce qui me permet d'affirmer qu'un matériel peut être le composant en quantité d'un matériel composé et de suivre alors la gestion du stock.
- il ya une DF entre ETAT et INTERVENTION, puisqu'une intervention normalement dans ce contexte abouti à un changement d'état.
- etc.
Je viens de MàJ le MCD, j'avais oublié la gestion du consommable (cartouches, lampes, etc.) :blink:
@+