IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Gestion des informations techniques


Sujet :

Schéma

  1. #1
    Membre du Club
    Inscrit en
    Juin 2008
    Messages
    116
    Détails du profil
    Informations forums :
    Inscription : Juin 2008
    Messages : 116
    Points : 44
    Points
    44
    Par défaut Gestion des informations techniques
    Bonjour, je travaille actuellement sur un projet de gestion des informations techniques sur les clients de mon entreprise et des moyens d'accès pour se connecter à leurs systèmes d'informations ...
    Ce projet a pour but d'être plus réactif et mieux organisé au niveau du support technique.

    Je vais expliquer en détails les différents besoins de mon projet et savoir si le MCD que j'ai réalisé correspond bien à la situation:

    Tout d'abord, nous avons des clients représentés par l'entité societe.
    Il y a plusieurs moyens de se connecter à l'architecture informatique d'un client....donc on peut se connecter à une societe par 0 ou plusieurs connexions ...

    Chaque client possède des équipements et des logiciels ...
    j'ai divisé les différents équipements que nous gérons en 3 catégories :
    Les serveurs, les switchs et les contrôleurs réseaux.
    Un serveur est un équipement où est installé en général un seul OS et où plusieurs applications peuvent être installées dessus. (Un OS peut acceuillir 0 ou plusieurs applications.
    Pour chaque application, chaque OS et chaque équipement (serveur, contrôleur réseau, switch), on a une ou plusieurs licences associés.
    Un équipement / logiciel peut avoir un ou plusieurs numéro de série (licence)...Un logiciels peut avoir une ou plusieurs licences.
    Un serveur est composé de composants :RAM, disque, processeur et autre ...
    Un serveur peut avoir un ou plusieurs composants...

    Chaque équipement est lié à un constructeur.
    Un constructeur peut proposer 0 ou plusieurs modèles d'équipements.
    Chaque constructeur a un support.
    Pour chaque constructeur, il y a des procédures d'accès au support différentes.(lorsqu'un matériel est défectueux par exemple) Il peut y avoir plusieurs procédures pour un constructeur.
    Une procédure est lié au support d'un constructeur.
    Des documents peuvent être associés à une procédure. Une procédure est rédigé par un auteur (utilisateur)


    Je pense qu'il manque une entité éditeur pour les logiciels dans mon MCD ou sinon est ce que je peux relier les entités OS et applications à constructeur ...étant donné que ce sont les mêmes informations dont j'ai besoin pour gérer les éditeurs de logiciels (à savoir le nom de l'éditeur et facultativement, un commentaire sur cet éditeur...)

    Chaque équipement peut avoir une ou plusieurs configurations réseaux ...

    Chaque équipement et logiciel disposent d'une ou plusieurs méthodes de management, c'est à dire que pour un logiciel ou un équipement, on peut définir une ou plusieurs méthode d'accès à cet équipement...
    La méthode dans l'entité management est un champs texte qui indique toutes les indications pour se connecter à tel ou tel équipement / logiciel...


    Voilà, pouvez vous me dire ce que vous pensez de mon MCD, y a t-il des choses incorrectes ? (surement que oui :roll : , je suis débutant ....)

    Merci de votre aide .....

    Mon MCD est en Piece jointe .....

  2. #2
    Membre du Club
    Inscrit en
    Juin 2008
    Messages
    116
    Détails du profil
    Informations forums :
    Inscription : Juin 2008
    Messages : 116
    Points : 44
    Points
    44
    Par défaut
    Apparemment , j'ai plusieurs problèmes au niveau de mon MCD sur les associations qui sont reliés à plusieurs entités ....
    ( associations : dispose, a (2), possède , fabrique ..)

    Comment faire pour pallier à ce problème ?
    Dois je créer plusieurs associations ayant la meme signification mais pas les relier avec les mêmes entités...


    Merci de m'éclairer !

  3. #3
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    7 965
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 7 965
    Points : 30 774
    Points
    30 774
    Billets dans le blog
    16
    Par défaut Associations-types quaternaires et plus, si affinité...
    Bonsoir,

    Les associations-types de votre MCD méritent effectivement d’être revues...

    Déjà, dans un MCD normalement constitué, il y a un maximum d’associations-types binaires, plus quelques associations-types ternaires. Pour votre part, vous battez des records : associations-types quaternaires (Fabrique, a(2), Possède, Correspond une), quintenaires (a), sextaires (Dispose)...

    Donc forcément, il y a quelque chose qui cloche.

    Considérez une association-type comme une rencontre (terme employé par le grand Yves Tabourier). Voyons la signification de l’association-type « a » : littéralement, elle symbolise la rencontre d’un serveur, d’un processeur, d’un disque et d’une mémoire (je laisse tomber l’entité-type « autre »). Ceci n’est pas faux, mais au vu des cardinalités portées par les pattes connectant les entités-types sur l’association-type, un disque donné peut être associé à N serveurs, à N mémoires, à N processeurs. La même mémoire peut être associée à N serveurs, N disques et N processeurs, etc. Est-ce bien cela que l’on veut ?

    Si la participation d’une mémoire et d’un disque a une même rencontre n’est pas pertinente (viol du principe d'indépendance), l’association-type quaternaire« a » doit être cassée en deux associations-types de degré inférieur, c'est-à-dire ternaires, la 1ere représentant la rencontre d’un disque, d’un processeur et d’un serveur et la 2e représentant la rencontre d’une mémoire, d’un processeur et d’un serveur.

    Cette fois-ci, selon la 1re ternaire, un disque donné peut-être associé à N serveurs et N processeurs. Si l’association d’un processeur et d’un disque n’est pas pertinente, alors il faudra casser la ternaire en deux binaires, etc. et quand on ne pourra plus rien casser, il faudra s’assurer des cardinalités. Ceci fait, il faudra reformuler avec la plus grande rigueur les règles qui régissent la participation des entités-types aux rencontres.

    Voilà déjà une 1re tâche à entreprendre...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  4. #4
    Membre du Club
    Inscrit en
    Juin 2008
    Messages
    116
    Détails du profil
    Informations forums :
    Inscription : Juin 2008
    Messages : 116
    Points : 44
    Points
    44
    Par défaut
    Bonjour, non ce n'est pas réellement les besoins de mon projet au niveau des composants (processeur, ram , disque) ....
    Ce que je veux exprimé, c'est qu'un serveur est composé de 0 ou plusieurs disques, 0 ou plusieurs RAM, 0 ou plusieurs processeurs...
    Il n'y a pas de lien entre les composants ....genre un disque n'a pas besoin d'un processeur ni d'une memoire ....


    J'espere que j'ai été clair ....

    Je crois que je doi revoir mon MCD effectivement ....mais je ne sais pas vraiment comment supprimer ces assosiations n-aire ...

  5. #5
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Il faut prendre les règles de gestions l'une après l'autre.
    Citation Envoyé par vivicente Voir le message
    un serveur est composé de 0 ou plusieurs disques,
    MCD :
    Serveur -0,n----Contenir----0,n- Disque

    un serveur est composé de 0 ou plusieurs RAM
    MCD :
    Serveur -0,n----Contenir----0,n- RAM

    un serveur est composé de 0 ou plusieurs processeurs...
    MCD :
    Serveur -0,n----Contenir----0,n- Processeur

    Et voilà ! Il n'y a plus que des associations binaires !

    Je vous invite de nouveau à réfléchir au fait que tous les composants techniques ont un fabricant ou constructeur qui figure par ailleurs dans votre MCD mais n'est pas associé à Processeur, Disque, Mémoire, Autre alors qu'il est logiquement relié à Switch, Serveur et Contrôleur.

    Commencez déjà à corriger votre MCD avec ces quelques principes et proposez-nous une nouvelle version. Il y aura encore d'autres points à aborder ensuite.

    Bon courage !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  6. #6
    Membre du Club
    Inscrit en
    Juin 2008
    Messages
    116
    Détails du profil
    Informations forums :
    Inscription : Juin 2008
    Messages : 116
    Points : 44
    Points
    44
    Par défaut
    Merci pour vos réponses ...
    J'ai modifié mon MCD en tâchant d'enlever toutes ces associations n-aires pour avoir que des associations binaires ...
    Par contre maintenant, c'est légèrement illisible ...

    Concernant ta question Cinephile sur les constructeurs des composants, je ne l'ai pas relié à constructeur car je veux le gérer par un champs texte, et non le remplir à l'aide d'une liste déroulante par exemple ....


    J'attends vos remarques ....
    Encore merci de votre aide très précieuse ...

  7. #7
    Membre du Club
    Inscrit en
    Juin 2008
    Messages
    116
    Détails du profil
    Informations forums :
    Inscription : Juin 2008
    Messages : 116
    Points : 44
    Points
    44
    Par défaut
    voici le MCD

  8. #8
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Concernant ta question Cinephile sur les constructeurs des composants, je ne l'ai pas relié à constructeur car je veux le gérer par un champs texte, et non le remplir à l'aide d'une liste déroulante par exemple ....
    Saisir dans une colonne de type texte Intel ou HarwdareTrucmuche s'il ne fait qu'un produit, pourquoi pas. Mais il me semble que certains font à la fois des processeurs et des contrôleurs ou des mémoires et des cartes ou des disques et autre chose...
    Bref, pour moi les différentes entités de composants devraient être reliées au constructeur.

    Venons-en au MCD, effectivement un peu fouilli mais ça reste lisible.

    Je ne sais pas ce que recouvre sémantiquement l'entité Management mais je lis sur le MCD qu'un Management ne dispose que d'un exemplaire des entités Application, Serveur (ah ben non en fait il y a deux associations entre management et serveur !), Controleur et Switch.

    Je lis aussi qu'un serveur peut ne faire tourner aucun OS ! Euh... il fonctionne comment le serveur ?

    L'association 'est' entre OS et Application est un héritage. En principe, dans ce cas, l'entité fille hérite de l'identifiant de l'entité mère mais n'a pas son propre identifiant. Ceci dit, ce n'est peut-être pas facile à représenter en MCD avec AnalyseSI vu qu'on ne représente pas les clés étrangères dans le MCD. Je crois qu'il faudrait représenter l'association de cette manière :
    OS -(1,1)----Est----0,1- Application
    La cardinalité 1,1 entre parenthèses indique une identification relative. Et dans la description complète de l'entité avec ses attributs dans le MCD, ID_os ne devrait pas figurer.

    Comme il y a une date d'installation de l'application, le Mandriva Linux du serveur 1 est différent du Mandriva Linux du serveur 2. En fait, je déplacerais la date d'installation plutôt dans la licence qui elle est bien unique.
    On aurait alors le schéma :
    Serveur -0,n----Tourner----1,1- Licence -1,1----Correspondre----0,n- Application -0,1----Etre----(1,1)- OS
    - Un serveur peut faire tourner plusieurs licences (sous-entendu d'application) et une licence ne tourne que sur un serveur.
    - Une licence correspond à une seule application et une application peut avoir plusieurs licences.
    - Une application peut être un OS et un OS est une application.
    Par le jeu de ces relations, on peut bien arriver à savoir quel OS tourne sur le serveur 1.

    Je vois que les licences peuvent aussi correspondre à des switches et des contrôleurs.
    Que recouvre sémantiquement cette notion de "licence" ?
    Est-ce bien, comme je l'ai supposé ci-dessus, la licence logicielle ?

    Un serveur, un contrôleur ou un switch sont fabriqués par un constructeur, lequel peut proposer des modèles. S'il s'agit des modèles de matériels figurant à son catalogue, je verrais plutôt une relation directe entre le modèle et le serveur, le contrôleur ou le switch (et par extension avec ce que j'ai déjà dit plus haut, idem avec les autres types de matériels - disques, mémoire...).
    Ce qui donnerait le schéma (pour le cas du serveur mais idem pour les autres produits) :
    Serveur -1,1----Référencer----0,n- Modèle -1,1----Fabriquer----0,n- Constructeur

    Je me demande si le support d'un constructeur n'est pas plutôt lié à un modèle qu'à un constructeur. Peut-être que certains constructeurs proposent du support sur certains produits et pas sur d'autres ?

    Un serveur peut avoir plusieurs réseaux et un réseau n'a qu'un serveur. Je suis étonné de la deuxième partie de cette règle, donc de la cardinalité 1,1. Il me semble que dans beaucoup d'entreprises, il y a plusieurs serveurs sur le même réseau !

    Est-ce qu'un serveur peut vraiment être possédé par plusieurs sociétés ?
    Idem pour les contrôleurs et les switches.

    Je crois avoir fait le tour du MCD.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  9. #9
    Membre du Club
    Inscrit en
    Juin 2008
    Messages
    116
    Détails du profil
    Informations forums :
    Inscription : Juin 2008
    Messages : 116
    Points : 44
    Points
    44
    Par défaut
    Merci de ton aide cinephil , je me rends compte que je suis pas encore au point :s
    Je vais essayer de répondre point par point :

    Je ne sais pas ce que recouvre sémantiquement l'entité Management mais je lis sur le MCD qu'un Management
    En faite, chaque équipement (switch, serveur, et contrôleur réseau) et logiciels (appliacations et OS) disposent d'une méthode de management, c'est à dire une méthode (indications sous forme de texte ) permettant de se connecter à cet équipement ou logiciel et les informations d'identification qui sont associées à cette méthode...

    Comme il y a une date d'installation de l'application, le Mandriva Linux du serveur 1 est différent du Mandriva Linux du serveur 2. En fait, je déplacerais la date d'installation plutôt dans la licence
    Je suis plutôt d'accord avec toi ...mais dans le casoù un logiciel n'a pas de licence ...je gère comment la date d'installation de celui ci ...


    Je vois que les licences peuvent aussi correspondre à des switches et des contrôleurs.
    Que recouvre sémantiquement cette notion de "licence" ?
    Est-ce bien, comme je l'ai supposé ci-dessus, la licence logicielle ?
    En faite, cette notion de licence couvre la sérialisation. Pour les logiciels, on a des licences logicielles. Pour le matériel, il est possible d'avoir des licences matériels mais on parle généralement de numéro de série (c'est le même type de données a fournir, un nom et un n°), c'est pour celà que j'avais regrouper ces 2 notions dans la même entité ...


    Je me demande si le support d'un constructeur n'est pas plutôt lié à un modèle qu'à un constructeur. Peut-être que certains constructeurs proposent du support sur certains produits et pas sur d'autres ?
    Je pense qu'il faut relier le support au constructeur car en faite, je souhaiterais que lorsqu'on aura défini le constructeur, toutes les procédures de support pour ce constructeur s'affichent (peu importe le modèle choisi)....


    Un serveur peut avoir plusieurs réseaux et un réseau n'a qu'un serveur. Je suis étonné de la deuxième partie de cette règle, donc de la cardinalité 1,1. Il me semble que dans beaucoup d'entreprises, il y a plusieurs serveurs sur le même réseau !
    Tu as entièrement raison jevais changer la cardinalité
    Mais moi je parle de configurations réseau, c'est à dire par exemple si un serveurs a 3 cartes réseaux, il peut avoir 3 configurations réseaux différentes ...je pense que ça revient au même au niveau des cardinalités ...?




    Est-ce qu'un serveur peut vraiment être possédé par plusieurs sociétés ?
    J'ai changé les cardinalités, tu as encore raison ...

    je joins mon MCD corrigé, c'est mieux ??

  10. #10
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Je comprends mieux la notion de "management".
    chaque équipement (switch, serveur, et contrôleur réseau) et logiciels (appliacations et OS) disposent d'une méthode de management,
    Mais ce que tu viens d'écrire ne laisse pas supposer qu'un serveur puisse avoir plusieurs Management mais plutôt l'inverse.
    J'ai plutôt l'impression que le schéma serait celui-ci :
    Serveur -1,1----Disposer1----0,1- Management
    Switch -1,1----Disposer2----0,1--------|
    ...
    Autrement dit il y a des procédures de management des équipements dont chacune s'appliquent au plus à un seul élément (serveur switch...) et chaque élément n'a qu'une seule procédure de management.
    J'ai juste ou j'ai rien compris ?

    Comme il y a une date d'installation de l'application, le Mandriva Linux du serveur 1 est différent du Mandriva Linux du serveur 2. En fait, je déplacerais la date d'installation plutôt dans la licence
    Je suis plutôt d'accord avec toi ...mais dans le casoù un logiciel n'a pas de licence ...je gère comment la date d'installation de celui ci ...
    Il faut peut-être entendre "licence" non pas stricto sensu comme un numéro de licence compliqué à la PetitMou mais comme une installation d'un logiciel.
    Les logiciels à licence ont alors un numéro de licence et les logiciels libres par exemple sont simplement installés sur une machine sans numéro de licence spécifique. En conservant mon schéma, ça peut tout à fait se faire mais il conviendrait peut-être de renommer l'entité par exemple en "Exemplaire" ou "Installation". Le numéro de licence restant un attribut qui engendrera une colonne pouvant être nulle dans la table.

    Je vois que les licences peuvent aussi correspondre à des switches et des contrôleurs.
    Que recouvre sémantiquement cette notion de "licence" ?
    Est-ce bien, comme je l'ai supposé ci-dessus, la licence logicielle ?
    En faite, cette notion de licence couvre la sérialisation. Pour les logiciels, on a des licences logicielles. Pour le matériel, il est possible d'avoir des licences matériels mais on parle généralement de numéro de série (c'est le même type de données a fournir, un nom et un n°), c'est pour celà que j'avais regrouper ces 2 notions dans la même entité ...
    Donc tu viens de trouver le nouveau nom de l'entité : "Serialisation" !

    Je pense qu'il faut relier le support au constructeur car en faite, je souhaiterais que lorsqu'on aura défini le constructeur, toutes les procédures de support pour ce constructeur s'affichent (peu importe le modèle choisi)....
    Là tu réfléchis implémentation du logiciel alors que tu n'en es qu'à la phase de modélisation des données.

    En regardant mieux ton entité Support, je vois qu'il faut prendre ceci dans le sens "hotline de support technique" plutôt que comme "contrat de support technique".
    Auquel cas j'associerais effectivement le support au constructeur :
    Constructeur -0,1----Proposer----1,1- Support

    Mais j'associerais la partie procédure au modèle :
    Modèle -0,1----Disposer----1,1- Procédure ...

    Cette branche modèle --> procédure se raccordant au schéma que j'ai proposé :
    Serveur -1,1----Référencer----0,n- Modèle -1,1----Fabriquer----0,n- Constructeur
    Le serveur X est référencé sous le modèle N fabriqué par le constructeur Z.
    Le constructeur Z propose le support n° 12.
    Le modèle N dispose d'une procédure n° 8.

    Ainsi au passage, rien n'empêche qu'un modèle dispose d'une procédure rédigée en interne et non pas par un support du constructeur, alors que dans ton schéma c'est impossible.

    Mais moi je parle de configurations réseau, c'est à dire par exemple si un serveurs a 3 cartes réseaux, il peut avoir 3 configurations réseaux différentes ...je pense que ça revient au même au niveau des cardinalités ...?
    OK alors change peut-être le nom de l'entité en "ConfigReseau".

    je joins mon MCD corrigé, c'est mieux ??
    C'est mieux mais encore perfectible...

    Puisqu'une licence correspond soit à un logiciel, soit à un contrôleur, soit à un switch, il faut une cardinalité 0,1 sur toutes les branches côté Licence.
    Et à la réflexion, je trouve que le numéro de série d'un matériel est directement un attribut du matériel et ne devrait pas être externalisé dans une entité séparée. La licence ne concerne que le logiciel. Auquel cas la cardinalité 1,1 peut être conservée.
    Au fait, pourquoi le serveur n'a pas de numéro de série ?

    Euh... le serveur peut toujours tourner sans OS !
    Et comme l'OS est un héritage de Application qui est reliée à Serveur via la Licence, l'association entre OS et Serveur est inutile.
    Selon ton schéma, dans l'absolu on pourrait avoir un serveur qui fait tourner un autre OS que l'application installée sur celui-ci. Ce ne serait pas faux dans le cas de serveurs virtuels (Nous avons une grappe de serveur VMWare tournant sous Windows et qui virtualise des serveurs Linux) mais bon... à voir si c'est vraiment ce que tu souhaites modéliser.

    Si tu pouvais réorganiser ton MCD pour que les traits se croisent un peu moins, ce serait plus agréable à lire.

    Dernier détail pour cette fois : Ton MCD se transformera en MLD puis en implantation physique en tables dans un SGBDR SQL. Alors évite tout de suite de donner des noms de colonnes avec des espaces et des accents.
    nom appli ==> NomAppli ou Nom_Appli par exemple.
    Pense aussi que certaines associations deviendront des tables alors tu peux choisir des noms plus explicites pour différencier les associations qui se ressemblent telles que disposer1, disposer2...
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  11. #11
    Membre du Club
    Inscrit en
    Juin 2008
    Messages
    116
    Détails du profil
    Informations forums :
    Inscription : Juin 2008
    Messages : 116
    Points : 44
    Points
    44
    Par défaut
    Je m'exprime un peu mieux :

    Serveur -1,1----Disposer1----0,1- Management
    Switch -1,1----Disposer2----0,1--------|
    ...
    Autrement dit il y a des procédures de management des équipements dont chacune s'appliquent au plus à un seul élément (serveur switch...) et chaque élément n'a qu'une seule procédure de management.
    J'ai juste ou j'ai rien compris ?
    C'est pas tout à fait ça ....En faite, un équipement ou un logiciel peut avoir 0 ou plusieurs méthodes de management ...
    J'ai donc les cardinalités suivantes :
    Serveur -0,N----Disposer1----1,1- Management
    Comme ça , un serveur peut avoir 0 ou plusieurs méthodes de management , et une méthode de management appartient qu'a un seul équipement/logiciel ?
    je me trompe ?
    je ne sais pas trop quoi mettre comme cardinalités entre l'association Disposer1 et Management...




    Le serveur X est référencé sous le modèle N fabriqué par le constructeur Z.
    Le constructeur Z propose le support n° 12.
    Le modèle N dispose d'une procédure n° 8.

    Ainsi au passage, rien n'empêche qu'un modèle dispose d'une procédure rédigée en interne et non pas par un support du constructeur, alors que dans ton schéma c'est impossible.
    Ok , trèsbien, c'est exactement ce que je veux ....Mais est ce que maintenant je pourrais associer une procédure à un constructeur ?
    Je pense que oui vu le modèle ...



    Puisqu'une licence correspond soit à un logiciel, soit à un contrôleur, soit à un switch, il faut une cardinalité 0,1 sur toutes les branches côté Licence.
    Et à la réflexion, je trouve que le numéro de série d'un matériel est directement un attribut du matériel et ne devrait pas être externalisé dans une entité séparée. La licence ne concerne que le logiciel. Auquel cas la cardinalité 1,1 peut être conservée.
    Au fait, pourquoi le serveur n'a pas de numéro de série ?
    En faite, je n'ai pas comme attribut le N° de série dans l'ententité seveur, switch , contrôleur car je voudrais être capable de gérer plusieurs N° de série pour un même serveur ..., ça parâit peu logique mais parfois ça arrive ...


    Euh... le serveur peut toujours tourner sans OS !
    On va me dire que je pense déjà à l'application mais je voudrais être capable de créer un serveur sans forcément qu'il y ait l'OS dessus ....je sais, ce n'est pas tellement logique mais je veux dire que ce n'est pas indispensable que l'OS soit saisi pour pouvoir créer un nouveau serveur...


    Selon ton schéma, dans l'absolu on pourrait avoir un serveur qui fait tourner un autre OS que l'application installée sur celui-ci. Ce ne serait pas faux dans le cas de serveurs virtuels (Nous avons une grappe de serveur VMWare tournant sous Windows et qui virtualise des serveurs Linux) mais bon... à voir si c'est vraiment ce que tu souhaites modéliser.
    Je pense que je vais laisser comme celà, ça peut me servir, on gère pas mal de serveurs ESX Vmware dans mon entreprise


    Ton MCD se transformera en MLD puis en implantation physique en tables dans un SGBDR SQL.
    Une fois que l'on obtient le MLD, on est capable de construire les tables ??
    ( dsl pour mes questions bêtes... je debute)
    Je renommerais les attributs lorsque je créerais les tables ..
    Je compte les créees sous PHPmyAdmin...et donc redonner des noms concrets à mes tables et attributs

    Voilà mon nouveau MCD avec les modifications appportées, j'ai modifié un peu la disposition mais c'est assez difficile de ne pas se faire croiser les éléments ...

    Merci pourton aide précieuse cinéphile

  12. #12
    Membre du Club
    Inscrit en
    Juin 2008
    Messages
    116
    Détails du profil
    Informations forums :
    Inscription : Juin 2008
    Messages : 116
    Points : 44
    Points
    44
    Par défaut
    je me pose des question au niveau de la cardinalités entre l'entité ConfigReseau
    et l'association relier .....

    Un équipement peut avoir une ou plusieurs configurations réseaux ....ça c OK
    Par contre, une configuration ne peut appartenir qu'à un seul serveur ...
    Ne serait ce donc pas ...

    ConfigReseau ...1,1....Relier ......0,N ....Serveur
    ConfigReseau ...1,1....Relier ......0,N ....Switch
    .......

    Est ce que je me trompe ?

  13. #13
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    C'est pas tout à fait ça ....En faite, un équipement ou un logiciel peut avoir 0 ou plusieurs méthodes de management ...
    J'ai donc les cardinalités suivantes :
    Serveur -0,N----Disposer1----1,1- Management
    Comme ça , un serveur peut avoir 0 ou plusieurs méthodes de management , et une méthode de management appartient qu'a un seul équipement/logiciel ?
    je me trompe ?
    S'il n'y avait qu'une association entre Serveur et Management, les cardinalités seraient bonnes. Mais comme Management est associé à plusieurs autres entités sur le même principe et qun management ne concerne qu'un seul équipement ou logiciel, donc qu'une seule autre entité, il faut une cardinalité 0,1 avec une exclusion entre les branches de toutes ces associations similaires (représentée en principe par un X dans un rond, lequel est relié à toutes branches concernées par un trait pointillé. Je ne crois pas que le développement d'Analyse SI soit allé si loin. Il faudrait utiliser un logiciel plus professionnel. Je ne suis même pas sûr que Open ModelSphere, pourtant plus complet que AnalyseSI contienne la représentation des contraintes dans le MCD.

    En fait, on pourrait mettre un peu plus d'héritage dans ton MCD, ce qui diminuerait probablement le nombre d'associations.

    On aurait tout d'abord cette partie de MCD :
    Management -1,1----Manager----0,n- Equipement -1,1----Typer----0,n- TypeEquipement

    Et l'héritage :
    Serveur -(1,1)----Etre----0,1- Equipement
    Switch -(1,1)----Etre----0,1----------|
    Controleur -(1,1)----Etre----0,1-----|
    Application -(1,1)----Etre----0,1----|

    Mais aussi pourquoi pas :
    Disque -(1,1)----Etre----0,1-------- Equipement
    Memoire -(1,1)----Etre----0,1--------------|
    Processeur -(1,1)----Etre----0,1----------|
    AutreEquipement -(1,1)----Etre----0,1--|

    Là aussi il faut une exclusion entre toutes les branches à cardinalité 0,1.

    Ce qui permet de relier facilement Equipement avec Fabricant (ou constructeur si tu préfères garder cette appellation mais un "constructeur" d'application ça fait bizarre) :
    Equipement -1,1----Référencer----0,n- Modèle -1,1----Fabriquer----0,n- Fabricant

    Une fois que l'on obtient le MLD, on est capable de construire les tables ??
    Ben les "pavés" du MLD sont déjà quasiment les futures tables qui seront implémentées dans le SGBD. Les "pavés" contiennent en tout cas tous les attributs qui deviendront les colonnes des tables, y compris les clés étrangères.
    Il ne restera plus qu'à préciser les types des colonnes, les index et les contraintes pour générer les tables.
    Et cela peut se faire dès le MLD (ou un schéma "Entity/relation" qui s'en rappoche beaucoup) sur certains logiciels de modélisation tel que Open Modelsphere je crois ou MySQL Workbench et probablement aussi sur des logiciels payants tels que PowerAMC.

    je me pose des question au niveau de la cardinalités entre l'entité ConfigReseau
    et l'association relier .....

    Un équipement peut avoir une ou plusieurs configurations réseaux ....ça c OK
    Par contre, une configuration ne peut appartenir qu'à un seul serveur ...
    Ne serait ce donc pas ...

    ConfigReseau ...1,1....Relier ......0,N ....Serveur
    ConfigReseau ...1,1....Relier ......0,N ....Switch
    Si c'est comme ça qu'il faut faire.
    Et donc avec mon héritage proposé ci-dessus, tu peux n'avoir qu'une association entre Configreseau et Equipement. Ca ne concernera bien sûr pas tous les équipements mais on s'en fout. Il faudra prévoir éventuellement une contrainte pour vérifier que le type de l'équipement peut bien recevoir une config réseau.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  14. #14
    Membre du Club
    Inscrit en
    Juin 2008
    Messages
    116
    Détails du profil
    Informations forums :
    Inscription : Juin 2008
    Messages : 116
    Points : 44
    Points
    44
    Par défaut
    ok , je vais suivre tes indictions, je vais modifier mon MCD.... je le reposte ensuite

  15. #15
    Membre du Club
    Inscrit en
    Juin 2008
    Messages
    116
    Détails du profil
    Informations forums :
    Inscription : Juin 2008
    Messages : 116
    Points : 44
    Points
    44
    Par défaut
    Par contre, qu'est ce que va contenir l'entité équipement ?
    un id et un nom ??
    pareil pour type équipement ?

  16. #16
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Citation Envoyé par vivicente Voir le message
    Par contre, qu'est ce que va contenir l'entité équipement ?
    un id et un nom ??
    pareil pour type équipement ?
    L'entité Equipement est l'entité mère de tous les équipements et doit donc contenir tous les attributs qui sont communs à tous les types d'équipement. A minima :
    - E_Id
    - E_Nom
    - E_Commentaire

    A noter que la table qui en sera issue accueillera aussi la clé étrangère pour le type d'équipement.

    Les entités filles Serveur, Switch... ne comportent que les attributs spécifiques aux serveurs, aux switches... Et pas d'identifiant au niveau MCD puisque l'identifiant sera hérité de l'entité mère Equipement.

    Pour TypeEquipement, oui, simplement un id et un nom, à moins que tu aies d'autres données à y ajouter, un commentaire par exemple ou un code alphanumérique qui pourrait être utile pour une liste des équipements sans avoir besoin d'une colonne large pour dire de quel type est l'équipement et que le contenu affiché puisse quand même être compréhnesible grâce à un code mnémotechnique (SRV pour serveur, SW pour switch...).
    Imaginons qu'un jour il y ait une notion de coùut fixe par type d'équipement, hop ! une colonne de plus dans la table des types pour ce coût fixe et le tour est joué sans chambouler le MCD.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  17. #17
    Membre du Club
    Inscrit en
    Juin 2008
    Messages
    116
    Détails du profil
    Informations forums :
    Inscription : Juin 2008
    Messages : 116
    Points : 44
    Points
    44
    Par défaut
    J'ai donc recréer mon MCD en suivant tes indications Cinéphile et c'est vrai qu'on y voit sacrément plus clair .....

    cf MCD1



    Il y a quelque chose que je ne comprends moyennement, c'est les associations Typer, sont elles faites pour pallier au manque de représentation d'héritage dans AnalyseSI ??


    J'ai donc créer une autre version de mon MCD en incluant, la RAM, le disque, le processeur comme des composants; ça fait donc ceci :
    Equipement--0,N--Composer--1,1---Composants----1,1----Typer-----0,N--Typecomposants



    et on relie les différents composant à l'entité composants comme suit:
    composant ---0,1------être---1,1----disquedur

    cf MCD2


    Est ce bon??



    J'ai ensuite fais une 3ème version de mon MCD en incluant des types de connexions..(connexion_pptp, ssh et web ) .......Est ce bon pour ça ?
    de plus , les connexions SSH peuvent être composés de tunnels SSH ....
    J'ai donc créer une association "Tunneller" relier à une entité Tunnel...
    (J'avais déjà étudié ce sujet avec toi, Cinéphile, lors d'un précédent sujet ....)

    cf MCD3


    Est ce que mon MCD semble au point ?

    Merci de votre aide !!!

  18. #18
    Membre du Club
    Inscrit en
    Juin 2008
    Messages
    116
    Détails du profil
    Informations forums :
    Inscription : Juin 2008
    Messages : 116
    Points : 44
    Points
    44
    Par défaut
    L'entité Equipement est l'entité mère de tous les équipements et doit donc contenir tous les attributs qui sont communs à tous les types d'équipement. A minima :
    - E_Id
    - E_Nom
    - E_Commentaire
    Ahhh Ok, donc en faite, dans mes 3 héritages que j'ai appliqué dans mon MCD (équipement , connexion, composants ...), je dois mettre l'ensemble des attributs communs aux entités ... et enlever les identifiants dans chaque entité fille ....??

    je corrige ça de suite

  19. #19
    Membre du Club
    Inscrit en
    Juin 2008
    Messages
    116
    Détails du profil
    Informations forums :
    Inscription : Juin 2008
    Messages : 116
    Points : 44
    Points
    44
    Par défaut
    voilà mon nouveau MCD, c'est mieux au niveau de l'héritage ?
    Le MCD commence à ressembler a quelquechose ?

  20. #20
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Il y a quelque chose que je ne comprends moyennement, c'est les associations Typer, sont elles faites pour pallier au manque de représentation d'héritage dans AnalyseSI ??
    Pas du tout !
    Si je veux lister tous les équipements et connaître leur type, il faut bien qu'il y ait une association entre Equipement et TypeEquipement.
    Si par contre je ne veux lister que les serveurs, j'interroge directement la table des serveurs, je connais déjà le type.
    Si je veux la liste de tous les types d'équipements, j'interroge seulement la table des types d'équipement.

    La première version du MCD est déjà pas mal !

    J'ai donc créer une autre version de mon MCD en incluant, la RAM, le disque, le processeur comme des composants; ça fait donc ceci :
    Equipement--0,N--Composer--1,1---Composants----1,1----Typer-----0,N--Typecomposants



    et on relie les différents composant à l'entité composants comme suit:
    composant ---0,1------être---1,1----disquedur
    Je vois que tu as compris le principe de l'héritage.

    J'ai ensuite fais une 3ème version de mon MCD en incluant des types de connexions..(connexion_pptp, ssh et web ) .......Est ce bon pour ça ?
    de plus , les connexions SSH peuvent être composés de tunnels SSH ....
    J'ai donc créer une association "Tunneller" relier à une entité Tunnel...
    (J'avais déjà étudié ce sujet avec toi, Cinéphile, lors d'un précédent sujet ....)
    C'est toujours bon !
    Effectivement, je me souviens de cette histoire de types de connexions.

    Ahhh Ok, donc en faite, dans mes 3 héritages que j'ai appliqué dans mon MCD (équipement , connexion, composants ...), je dois mettre l'ensemble des attributs communs aux entités ... et enlever les identifiants dans chaque entité fille ....??
    Dans Equipement figurent l'identifiant + les attributs communs à tous les types d'équipement et dans les entités filles (Serveur, Switch, Controleur, Application) figurent les attributs spécifiques à chaque entité et sans identifiant (je ne sais pas si AnalyseSI accepte une entité sans identifiant mais il serait toujours temps d'y remédier lors du passage au MLD).

    OK pour le dernier MCD.

    Un dernier truc me chiffonne un peu, c'est l'association Tourner entre Equipement et Sérialisation.
    Tu as fait :
    Equipement -0,n----Tourner----0,1- Sérialisation et la sérialisation ne s'applique plus qu'à Application.
    Si tu veux vraiment faire comme ça et restreindre cette notion aux applications, il me semble que les applications ne tournent que sur les serveurs donc l'association devrait plutôt raccorder Application et Sérialisation.

    Pendant qu'on y est, il me semble plus simple d'intégrer le numéro de licence dans l'application.
    Mais comme un équipement hardware a en principe aussi un numéro de série qui est l'équivalent du numéro de licence pour une application, ce numéro de licence/série devient un attribut commun aux 4 types d'équipement et peut être rappatrié dans l'entité Equipement.

    Du coup on supprime l'entité Sérialisation et l'association Tourner se trouve entre Application et Serveur.

    Je crois qu'avec ça on approche de la fin !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

Discussions similaires

  1. gestion des informations de sécurité (SIM)
    Par salmasec dans le forum Sécurité
    Réponses: 0
    Dernier message: 14/05/2011, 15h58
  2. Réponses: 0
    Dernier message: 10/02/2010, 10h49
  3. [SSIS] [2K5] Gestion des rejets techniques
    Par alaa00 dans le forum SSIS
    Réponses: 1
    Dernier message: 18/12/2009, 14h56
  4. [MySQL] gestion des informations d'actualité
    Par Abou Zar dans le forum PHP & Base de données
    Réponses: 4
    Dernier message: 18/11/2009, 19h29
  5. [Toutes versions] Gestion des doublons dans une liste technique.
    Par Lorenzogazier dans le forum Requêtes et SQL.
    Réponses: 7
    Dernier message: 02/04/2009, 23h45

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo