Discussion :

[vivicente]

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.

Oui je suis d'accord avec toi, mais si je supprimer cette notion de sérialisation , je ne serais pas capable de créer plusieurs licences pour un logiciel, ou plusieurs n° de série pour un équipement .....
Comment je pourrais faire pour éviter celà du coup ?

Presque la finnnnnn,

[CinePhil]

Oui je suis d'accord avec toi, mais si je supprimer cette notion de sérialisation , je ne serais pas capable de créer plusieurs licences pour un logiciel, ou plusieurs n° de série pour un équipement .....
Comment je pourrais faire pour éviter celà du coup ?

Plusieurs numéros de série pour un équipement me semble bizarre !

Pour ce qui est du numéro de licence de l'application, dans la mesure où tu as laissé la date d'installation dans Application, je reprends ce que j'ai dit dans un précédent message :

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.

Ou bien tu enregistres dans Application le Mandriva Linux de Benoît + celui de Fabrice (2 lignes pour le même logiciel mais installé sur deux machines différentes à deux dates différentes), ou bien tu enregistres dans Application la distribution Mandriva Linux et dans Sérialisation la date d'installation de chaque instance de la distribution.

La deuxième solution est effectivement plus propre mais il faut déplacer la date d'installation dans Sérialisation, et même peut-être dans Equipement si tu enregistres une date d'installation aussi pour les équipements hardware.

[vivicente]

En fait, j'avais oublié de supprimer les attributs communs de l'entité applications ...il ne reste plus que l'attribut version du coup...

Plusieurs numéros de série pour un équipement me semble bizarre !

Je sais que ça peut semblait bizarre mais ça peut arriver ...
Quels sont les changements que je dois effectuer pour prendre en compte ce besoin sur mon MCD ? (si il y en a ....) (je n'en vois pas .... )

[vivicente]

voici le MCD corrigé

[CinePhil]

Je sais que ça peut semblait bizarre mais ça peut arriver ...
Quels sont les changements que je dois effectuer pour prendre en compte ce besoin sur mon MCD ? (si il y en a ....) (je n'en vois pas .... )

Donc tu me dis qu'un Equipement peut avoir plusieurs numéros de série et qu'un numéro de série est propre à un équipement.
Ce qui donne le schéma :
Equipement -1,n----Avoir----1,1- NumSerie

Et la nouvelle entité NumSerie ne contiendra qu'un identifiant anonyme idNumserie et le vrai numéro de série qui sera de type VARCHAR(longueur optimale à déterminer).

En regardant ton dernier MCD, je constate que j'avais raison en disant que Analyse SI n'accepte pas les entités sans identifiant. Il faudra donc corriger des choses à la main lors de la génération du MLD, en espérant qu'AnalyseSI se laissera faire.

Je crois que pour le MCD on a terminé !

[vivicente]

Ok je vais rajouter cet entité ...

Par contre maintenant, l'entité "Sérialisation ne sert plus à rien" ...On peut la supprimer ....Non?

Tu me conseille quoi comme outil pour remodéliser mon MCD (qui autorise l'héritage) ou des entités sans identifiants ...??

Merci pour tout cinephile, tu gères !!

[CinePhil]

Par contre maintenant, l'entité "Sérialisation ne sert plus à rien" ...On peut la supprimer ....Non?

Euh... Sérialisation était l'intermédiaire entre Application et Serveur.
C'est un peu moins évident de chercher les numéros de licence des logiciels installés sur le serveur 12 si on supprime l'entité Sérialisation pour la remplacer par l'entité NumSerie raccordée à Equipement mais c'est faisable.
Alors je pense qu'on peut supprimer.

Tu me conseilles quoi comme outil pour remodéliser mon MCD (qui autorise l'héritage) ou des entités sans identifiants ...??

Sans l'avoir essayé mais en ayant vu plusieurs exemples de schémas élaborés à l'aide de ce logiciel, je pense que PowerAMC est le plus complet. Si tu peux le faire acheter par ta boîte c'est bien, sinon il parait qu'il existe une version d'évaluation. Perso, comme je suis allergique à Windows...

Moi j'utilise OpenModelsphere qui est gratuit et qui tourne (très bien) sous Windows et (un peu plus difficilement) sous Linux mais je n'ai encore jamais fait de schéma élaboré avec des héritages et des contraintes d'exclusion entre les associations.

Après il y en a d'autres, il existe quelque part sur DVP un récapitulatif des outils de modélisation.

[vivicente]

on supprime l'entité Sérialisation pour la remplacer par l'entité NumSerie raccordée à Equipement mais c'est faisable

C'est fait, j'ai supprimer l'entité sérialisation .....et j'en ai créer une autre que j'ai appellé aussi "Sérialisation"...

Du coup, étant donné du mécanisme d'héritage, je me demande s'il faut que je laisse tout les attributs dans l'entité OS .....car on pourrait considérer un OS comme un logiciel et donc comme un "équipement" ...Faut il garder tous les attributs dans OS ou juste conserver les attribut qui lui sont propres ???


Par la suite, j'ai donc recréer à nouveau mon MCD à partir du début (j'aurais du commencer au départ par PowerAMC (très complet) ...J'ai donc mis en place mes 3 héritages ( équipements, connexions, composants ..) .. Les enfants sont mutuellement exclusifs ....
Voici mon nouveau MCD en pièce jointe ....


Par la suite, j'ai donc générer le MLD à partir du MCD ....je trouve la représentation faite par PowerAmc un peu étrange à ce que j'attendais mais ça me semble cohérent .... (cf PJ MLD)


Enfin, j'ai généré le MPD et là ça me semble pas mal du tout au niveau du modèle et de la constitution des tables ...
L'héritage semble être bien géré .... (cf PJ MPD)

Alors vos observations ?

[CinePhil]

Du coup, étant donné du mécanisme d'héritage, je me demande s'il faut que je laisse tout les attributs dans l'entité OS .....car on pourrait considérer un OS comme un logiciel et donc comme un "équipement" ...Faut il garder tous les attributs dans OS ou juste conserver les attribut qui lui sont propres ???

Le principe de l'héritage est qu'on ne laisse dans l'entité fille que les attributs qui sont propres à la fille. Or OS est un héritage de Application qui est elle-même un héritage de Equipement.
- id OS hérite de Application donc on supprime id OS
- Nom OS est équivalent de Nom équipement donc on supprime Nom OS.
- Version est déjà dans Application donc on supprime dans OS.
- Date est déjà dans Equipement donc on supprime dans OS.
- Note est déjà dans Equipement donc on supprime dans OS, à moins que cette 'note' ait un sens différent pour un OS par rapport au fait qu'il s'agit aussi d'un équipement.
- Idem pour commentaires.
Au final, selon moi, il ne devrait rester dans l'entité OS que Service Pack. Au fait, n'y a t-il de service pack que pour les OS ? Ca ne s'applique pas aussi à certains logiciels autre que les OS ?
Pendant que j'y pense, tu aurais peut-être besoin de savoir ce que c'est comme type d'application (Traitement de texte, suite bureautique, comptabilité, ERP, Dessin...). Auquel cas il te faudrait aussi une entité TypeApplication associée à Application selon le schéma :
Application -1,1----Typer----0,n- TypeApplication

Par la suite, j'ai donc générer le MLD à partir du MCD ....je trouve la représentation faite par PowerAmc un peu étrange à ce que j'attendais mais ça me semble cohérent .... (cf PJ MLD)

Enfin, j'ai généré le MPD et là ça me semble pas mal du tout au niveau du modèle et de la constitution des tables ...
L'héritage semble être bien géré .... (cf PJ MPD)

C'est vrai que je suis un peu étonné de la représentation de l'héritage dans le MLD moi aussi mais c'est compréhensible quand même et effectivement bien traduit en MPD ensuite.

Tu approches du but !

Il te faut maintenant vérifier ton schéma dans tous les sens pour voir s'il ne permet pas des associations impossibles.
Par exemple, dans l'état actuel, un équipement de type application peut avoir des composants !
Il manque donc des contraintes que je ne saurais pas représenter ici mais qui sont peut-être représentables par PowerAMC. Il s'agit de contraintes d'inclusion ou d'exclusion entre certaines associations ou entités.
Dans l'exemple cité, il s'agirait d'exclure l'entité Application de l'association Composer. Je ne sais pas si c'est faisable par un outil sémantique de PowerAMC vu que je ne connais pas ce logiciel.

Bon courage !

[vivicente]

OS est un héritage de Application qui est elle-même un héritage de Equipement.

J'ai arrangé ça


Pour la gestion des types :

Application -1,1----Typer----0,n- TypeApplication

Tout a fait d'accord !

contraintes d'inclusion ou d'exclusion entre certaines associations ou entités.

J'ai commencé à chercher des informations sur le sujet mais apparemment c'est possible que pour la notion d'héritage ...mais après pour créer des contraintes d'inclusion ou d'exclusion entre des entités et des associations, ça semble plus compliqué .... (J'espère que fsmrel aura la réponse à notre question ...)

Je reposte en PJ mon nouveau MCD , MLD ..MPD ....

[vivicente]

J'ai fais multiples recherches sur les possibilités de créer des contraintes d'inclusion ou d'exclusion entre certaines associations ou entités.

Apparemment au niveau du MCD, c'est seulement possible en créant des relations d'héritage ...pas très pratique dans mon cas (exemple entre l'entité application et composants) ....

Sinon, il est possible de faire àu niveau MySQL en créant des TRIGGERs ...

Le sujet a déjà était traité sur cette discussion ...

http://www.developpez.net/forums/d72...sion-totalite/


Etant donné que mon MCD me semble bon, la génération du MPD aussi, est ce que je peux passer à la génération de mes tables ......? ( Un peu pressé ... mais pas trop ...)


J'ai une question au niveau de l'interaction avec ma base de données (peut être bête mais je débute...) (Langage PHP que je vais utiliser par la suite), comment est ce que je vais pouvoir créer par exemple un serveur ???

Etant donné que pour créer un serveur, il va falloir faire appel aux tables équipement, type_equipement et serveur , il va donc falloir créer des jointures entre ces tables, je me trompe ??
Même chose pour composants, par exemple pour créer un nouveau disque, il faudra faire une jointure entre la table composant, disque et type_composant, j'ai bon ou j'y suis pas du tout ???
Merci de m'éclairer sur ce point ....


Merci

[CinePhil]

Attends peut-être une journée si quelqu'un d'autre peut t'aider sur Power AMC.
Il y a aussi un forum qui est consacré à ce logiciel.

comment est ce que je vais pouvoir créer par exemple un serveur ???

Etant donné que pour créer un serveur, il va falloir faire appel aux tables équipement, type_equipement et serveur , il va donc falloir créer des jointures entre ces tables, je me trompe ??
Même chose pour composants, par exemple pour créer un nouveau disque, il faudra faire une jointure entre la table composant, disque et type_composant, j'ai bon ou j'y suis pas du tout ???

Tu as compris le principe !
Mais l'aide qui pourra t'être apportée sur ce sujet est dans le forum MySQL/Requêtes.
Et si tu as des difficultés dans le mariage entre PHP et MySQL, c'est dans le forum PHP & MySQL.

[vivicente]

Ok je te remercie vraiment pour ton aide Cinéphile

J'ai posté un sujet sous le forum de PowerAmc ...je vais voir si j'ai des réponses ..et sinon, demain je m'attaque à créer mes tables ...

Sachant que mon projet intervient dans l'évolution d'un outils déjà existant, je vais reprendre la structure des tables que j'utilise dans l'évolution (table societe, et table user ...)

Merci encore

[fsmrel]

Bonsoir,


Quelques observations sur le MCD.

vivicente, vous utilisez l'héritage pour l’entité-type equipements (spécialisée en Serveur, Switch, etc.) : l’entité-type type_equipement devient redondante et devrait disparaître.

Même chose concernant les entités-types type_composants, type_connexion (et peut-être type_application, en fonction du sens que vous donnez à cette entité-type).

Il faudrait que fournissiez une description entité-type par entité-type, avec des exemples, pour lever les ambiguïtés. Par exemple, quelle signification exacte, exhaustive, donnez vous au terme Application ? S’agit-il des applications développées par votre entreprise ? Et/ou de progiciels ? Et/ou de logiciels acquis auprès des éditeurs ? Etc.

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. [...]Les entités filles Serveur, Switch...

Attention à la précision du vocabulaire et aux contresens en embuscade. Vous écrivez qu’une mère (Equipement) a des filles (Serveur, Switch). En réalité, les liens ne sont pas ici à être des liens de parenté, mais des liens d’héritage, ce qui impose que l’on écrive :

Un serveur est un équipement
Un Switch est un équipement.

Ce n’est plus le verbe avoir qui gouverne ce que nous écrivons ici, mais bien le verbe être.

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

Dans le sens de ma réflexion précédente, le MCD contient une relation « Est » entre les entités-types OS et Application. Si un système d’exploitation est une application, alors il faudrait établir un lien d’héritage entre les deux entités-types. A défaut, l’entité-type OS n'ayant pas d’identifiant (ce qui est un bug du point de vue de Merise), la table qui en dérivée n’a pas de clé primaire, ce qui est à considérer comme un bug, non pas d’un point de vu syntaxique SQL, mais du point de vue de la théorie relationnelle. En outre, les entités-types OS et APPLICATION sont porteuses des mêmes propriétés, ce qui est pour le moins suspect.
Par ailleurs, un système d’exploitation n’est pas une application à proprement parler car son objet est de permettre l’exploitation d’un ordinateur. Mais bon, si vous tenez à en faire une application spécialisée, alors renommez APPLICATION en LOGICIEL, ça choquera un peu moins.

A partir des quelques indications que vous fournissez, le MCD peut être revu ainsi (il y a d’autres scénarios possibles) :

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.

Supposons que la contrainte soit que seuls les serveurs et les switchs sont concernés par les configurations. Au plan conceptuel, une première possibilité consiste à représenter les choses ainsi :






Mais cette façon de procéder a un inconvénient :

Il faudra ajouter manuellement une contrainte (appelons-la EXCLUSION) pour la table CONFIG. Exemple (aux noms près) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
create table Serveur
(    ServeurId    char(4)  not null
   , ServeurNom   varchar(40)  not null 
  , constraint Serveur_pk primary key (ServeurId)
) ;
create table Switch
(    SwitchId    char(4)      not null
   , SwitchNom   varchar(40)  not null 
  , constraint Switch_pk primary key (SwitchId)
) ;
create table Config
(    ConfigId    char(4)      not null
   , ConfigNom   varchar(40)  not null
   , AdressIP    varchar(20)  not null
   , ServeurId   char(4)      null    
   , SwitchId    char(4)      null   
  , constraint Config_pk primary key (ConfigId)
  , constraint Config_ak unique (AdressIP)
  , constraint c_Serveur_fk foreign key (ServeurId) references Serveur
  , constraint c_Switch_fk foreign key (SwitchId) references Switch
  , CONSTRAINT EXCLUSION 
        CHECK (ServeurId IS NULL AND SwitchId IS NOT NULL 
               OR 
               ServeurId IS NOT NULL AND SwitchId IS NULL)
) ;
 
insert into Serveur values ('srv1', 'serveur 1') ;
insert into Serveur values ('srv2', 'serveur 2') ;
 
insert into Switch values ('sw1', 'switch 1') ;
insert into Switch values ('sw2', 'switch 2') ;
 
insert into Config values ('c1', 'config 1', 'adrIP1', 'srv1', null) ;
insert into Config values ('c2', 'config 2', 'adrIP2', null, 'sw1') ;
insert into Config values ('c3', 'c3', 'adrIP3', 'srv1', 'b1') ;
insert into Config values ('c4', 'c4', 'adrIP4', null, null) ;
 
Select * from Config

N.B. Vous observerez que l’attribut AdresseIP de la table Config fait l’objet d’une clé alternative (contrainte d’unicité). Ce genre de clé est à mettre en œuvre pour chaque entité-type susceptible d’en être porteuse.


Une autre façon de traiter de l’exclusion consisterait à spécialiser les objets « à configuration » :



Par ailleurs, je ne vois pas de liens entre les OS et les serveurs. Est-ce voulu ? Sinon, il n’y a plus qu’à établir une association-type, par exemple (dans le contexte du schéma précédent) :

j'ai donc générer le MLD à partir du MCD ....je trouve la représentation faite par PowerAmc un peu étrange à ce que j'attendais mais ça me semble cohérent ....

Je n’ai pas la version de Power AMC permettant de générer le MLD, mais seulement celle qui permet de passer du MCD au MPD. Toutefois, avec la version dont vous disposez, il doit exister une option permettant de remplacer la « version étrange » (mais qui ne date pas d’aujourd’hui !) par une représentation graphique plus proche de celle du MCD. Voyez à ce sujet le MLD d’Heledir.

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)

Utiliser un terme plus générique, tel que « fournisseur ».

Il y a certainement encore des choses à dire, mais je n'ai procédé que par sondages...

[vivicente]

vivicente, vous utilisez l'héritage pour l’entité-type equipements (spécialisée en Serveur, Switch, etc.) : l’entité-type type_equipement devient redondante et devrait disparaître.

Même chose concernant les entités-types type_composants, type_connexion (et peut-être type_application, en fonction du sens que vous donnez à cette entité-type).

Il faudrait que fournissiez une description entité-type par entité-type, avec des exemples, pour lever les ambiguïtés. Par exemple, quelle signification exacte, exhaustive, donnez vous au terme Application ? S’agit-il des applications développées par votre entreprise ? Et/ou de progiciels ? Et/ou de logiciels acquis auprès des éditeurs ? Etc.

Application est une application acquis auprès d'un éditeur ...
(ça peut être virtualisation, sécurité, filtrage, .....)
Comment est ce que je dois gérer les types d'équipements (surtt pour les controleurs réseaux : firewall, passerelle SSL, appliance de filtrage ...), les composants (disque, ram, processeur et autre ....), les connexions (de type SSH, PPTP et web ) ??

vous utilisez l'héritage pour l’entité-type equipements (spécialisée en Serveur, Switch, etc.) : l’entité-type type_equipement devient redondante et devrait disparaître.

Dois je supprimer ces entités et associations Type / Typer de mon modèle .....?
Comment est ce que je vais gérer les "types" du coup ?

Dans le sens de ma réflexion précédente, le MCD contient une relation « Est » entre les entités-types OS et Application. Si un système d’exploitation est une application, alors il faudrait établir un lien d’héritage entre les deux entités-types. A défaut, l’entité-type OS n'ayant pas d’identifiant (ce qui est un bug du point de vue de Merise), la table qui en dérivée n’a pas de clé primaire, ce qui est à considérer comme un bug, non pas d’un point de vu syntaxique SQL, mais du point de vue de la théorie relationnelle. En outre, les entités-types OS et APPLICATION sont porteuses des mêmes propriétés, ce qui est pour le moins suspect.

Ok je corrige ça .....tu as raison ...

A partir des quelques indications que vous fournissez, le MCD peut être revu ainsi (il y a d’autres scénarios possibles) :

Tu penses que je devrais séparer les entités Matériel et logiciel à l'aide d'une relation d'héritage ....Un logiciel est un "équipement" dans mon sens ...
Un matériel est un "équipement" ... Et les logiciels et les matériels forment les équipements ...Les enfants (logiciel et matériel) sont mutuellement exclusif ...

Faut il rajouter la notion " d' héritage complet " dans mes relations d'héritage ...je n'ai pas totalement compris cette notion...

Il faudra ajouter manuellement une contrainte (appelons-la EXCLUSION) pour la table CONFIG.

Très bien ,je ferais ces exclusions au niveau de la création de mes tables en SQL...

Par ailleurs, je ne vois pas de liens entre les OS et les serveurs. Est-ce voulu ?

En effet, j'ai considérer qu'un serveur pouvait avoir d'installer un ou plusieurs logiciels qui peut être un OS ...



Merci pour ces remarques .. je vais en tenir compte ...

[fsmrel]

Bonsoir,

Application est une application acquis auprès d'un éditeur ...
(ça peut être virtualisation, sécurité, filtrage, .....)

Le mot « application » sous-entend le plus souvent « métier » (comptabilité, catalogue produits, gestion des contrats, des cotisations, des titres, des commandes, des achats, etc.), qui plus est dans le contexte d'un développement au sein de l'entreprise. Le mot qui conviendrait mieux ici serait celui de « logiciel ».

Quoi qu’il en soit, vous en faites l’acquisition auprès d’un éditeur. Il serait donc pas mal de mettre en œuvre une entité-type EDITEUR, en relation avec l’entité-type APPLICATION (suite à ce que j’ai écrit, désormais j’utiliserai le terme LOGICIEL).

Par ailleurs, un logiciel est un équipement. Selon votre MCD, un équipement fait obligatoirement référence à un modèle fabriqué obligatoirement par un constructeur, mais si je vous lis bien :

« 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 »

ces choses-là n’ont rien à voir des logiciels ou des applications, auquel cas le lien avec MODELE devrait être établie à un autre niveau :



Si les sociétés ne sont pas concernées par les logiciels, là encore le lien entre EQUIPEMENT et SOCIETE est à déplacer.

Comment est ce que je dois gérer les types d'équipements (surtt pour les controleurs réseaux : firewall, passerelle SSL, appliance de filtrage ...), les composants (disque, ram, processeur et autre ....), les connexions (de type SSH, PPTP et web ) ??

Veuillez préciser ce que vous entendez par là.

vous utilisez l'héritage pour l’entité-type equipements (spécialisée en Serveur, Switch, etc.) : l’entité-type type_equipement devient redondante et devrait disparaître.

Dois je supprimer ces entités et associations Type / Typer de mon modèle .....?
Comment est ce que je vais gérer les "types" du coup ?

Du coup, il faudrait que vous vous reportiez à la discussion avec Heledir (Le pavé du jour), quand je traite des vues et des triggers associés.

Disons qu’au niveau logique, (en faisant référence à vos MCD/MLD) on définit une vue par entité-type qui est une spécialisation de l’entité-type EQUIPEMENT : LOGICIEL, OS, SERVEUR, SWITCH, CONTROLEUR.

Exemple des serveurs (pour éviter les longueurs, je me limite à quelques attributs de la table EQUIPEMENT) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
CREATE VIEW SERVEUR_V
(Id_Serveur, fonction, format, bios, nom_serveur, date, statut)
AS SELECT
       x.id_equipement, y.fonction, y.format, y.bios, 
       x.nom_equipement, x.date, x.statut 
   FROM EQUIPEMENT AS x 
           INNER JOIN 
        SERVEUR AS y
              ON x.id_equipement = y.id_equipement   
;

Exemple pour les logiciels :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
CREATE VIEW LOGICIEL_V
(Id_Logiciel, version, service_pack, nom_logiciel, date, statut)
AS SELECT
       x.id_equipement, y.version, y.service_pack,
       x.nom_equipement, x.date, x.statut 
   FROM EQUIPEMENT AS x 
           INNER JOIN 
        LOGICIEL AS y
               ON x.id_equipement = y.id_equipement   
;

Exemple pour les OS :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
CREATE VIEW OS_V
(Id_OS, version, service_pack, nom_OS, date, statut)
AS SELECT
       x.id_equipement, y.version, y.service_pack 
       x.nom_equipement, x.date, x.statut 
   FROM EQUIPEMENT AS x 
           INNER JOIN 
        OS AS y
               ON x.id_equipement = y.id_equipement   
;

Etc.

Pour consulter les données, il suffit de faire référence aux vues plutôt qu’aux tables.

Pour les mises à jour, on fait là encore référence aux tables, mais, par trigger, on intercepte chaque INSERT, UPDATE, DELETE, pour ventiler dans les tables sous-jacentes.

Par exemple, pour créer un serveur, si on utilise l’instruction suivante :

Code SQL :

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

1
2
3
INSERT INTO SERVEUR_V  
    (Id_Serveur, fonction, format, bios, nom_serveur, date, statut)
    VALUES (123, 'fonction ...', 5, 'bios truc', 'serveur z', '15/09/2009', 0) ;

Le trigger suivant (dans le cas de MS SQL SERVER) permet d’intercepter les insertions :

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TRIGGER SERVEUR_INSERT ON SERVEUR_V Instead of INSERT AS
 
    INSERT INTO EQUIPEMENT  
        SELECT  Id_Serveur, nom_serveur, date, statut
        FROM    INSERTED ;
 
    INSERT INTO SERVEUR  
        SELECT  Id_Serveur, fonction, format, bios
        FROM    INSERTED  ;

Etc. Reportez-vous à la discussion avec Heledir.

Maintenant, si vous ne souhaitez pas utiliser les vues et les triggers, alors vous conservez les entités-types TYPE_EQUIPEMENT, etc. Mais je vous conseille néanmoins d’étudier ce qui est écrit dans la discussion avec Heledir.

Tu penses que je devrais séparer les entités Matériel et logiciel à l'aide d'une relation d'héritage ....Un logiciel est un "équipement" dans mon sens ...
Un matériel est un "équipement" ... Et les logiciels et les matériels forment les équipements ...Les enfants (logiciel et matériel) sont mutuellement exclusif ...

Je reprends l’exemple des figures géométriques (voir une fois de plus la discussion avec Heledir) :



Un serveur est un matériel tout comme un cercle est une ellipse, mais tous les matériels ne sont pas des serveurs (il y a aussi des contrôleurs, etc.), de même que certaines ellipses ne sont pas des cercles (celles dont la longueur du demi-grand axe est supérieure à celle du demi-petit axe). Comme je l’ai écrit précédemment, il ne faut pas confondre être et avoir, un cercle n'est pas l'enfant d'une ellipse (qui n'est pas non plus la fille d'une figure plane, mais est bien une figure plane).

Faut il rajouter la notion " d' héritage complet " dans mes relations d'héritage ...je n'ai pas totalement compris cette notion...

On parle plutôt de contrainte de totalité, ce qui veut dire que pour un surtype (exemple EQUIPEMENT) on a toujours un sous-type (par exemple SERVEUR dans votre MCD). Si en plus ces sous-types sont exclusifs (ce qui est à espérer !) on dit alors qu’un surtype a toujours un et un seul sous-type. Exclusion + Totalité = Partitionnement.

Par ailleurs, je ne vois pas de liens entre les OS et les serveurs. Est-ce voulu ?

En effet, j'ai considérer qu'un serveur pouvait avoir d'installer un ou plusieurs logiciels qui peut être un OS ...

Autrement dit, vous ne modélisez pas la réalité mais la possibilité : chaque OS peut être installé sur n’importe quel serveur et chaque serveur peut héberger n’importe quel OS. N’est-il pas intéressant de savoir que tel OS est installé sur tel serveur ?

[vivicente]

Bonjour,

Premièrement, j'ai modifié mon MCD et séparer l'entité équipement en 2 avec un héritage : En effet , les 2 entités "Logiciel" et "matériel" hérite de l'entité mère "équipement"....
Je ne vois aucun attribut commun à mettre dans l'entité matériel ....j l'ai donc laissé vide ...

cf mon nouveau MCD pour les modifications ...


Ensuite, j'ai compris le principe des "vues", ça semble plus simple pour interagir avec les données ...mais débutant, je trouve ça un peu compliqué à mettre en place ... Je vais rester sur les types au niveau du MCD....

On parle plutôt de contrainte de totalité, ce qui veut dire que pour un surtype (exemple EQUIPEMENT) on a toujours un sous-type (par exemple SERVEUR dans votre MCD). Si en plus ces sous-types sont exclusifs (ce qui est à espérer !) on dit alors qu’un surtype a toujours un et un seul sous-type. Exclusion + Totalité = Partitionnement.

Ok je reste donc en héritage complet avec enfants mutuellement exclusifs....

Autrement dit, vous ne modélisez pas la réalité mais la possibilité : chaque OS peut être installé sur n’importe quel serveur et chaque serveur peut héberger n’importe quel OS. N’est-il pas intéressant de savoir que tel OS est installé sur tel serveur ?

En effet , tu as raison ....
J'ai donc rajouter une relation entre OS et serveur ....


En pièce jointe, mon nouveau MCD (en tenant compte des remarques de fsmrel, ça semble judicieux en effet de séparer la partie logiciel et la partie matériel ....) .....
Et en PJ toujours, le MPD ...

Qu'en pensez vous ?

[fsmrel]

Bonjour,


J’en reviens aux entités-types TYPE_EQUIPEMENT, etc. Vous préférez les conserver : soit. Pour votre culture, retenez quand même qu’elles contiennent ce qu’on appelle des métadonnées, c'est-à-dire des données d’un niveau supérieur, et qui parlent des données que nous décrivons. Par exemple, le nom d’un équipement correspond à une donnée intervenant dans la structure de l’entité-type EQUIPEMENT, sous la forme d’un attribut et a pour valeur par exemple « serveur 1234 ». En revanche, les attributs de l’entité-type TYPE_EQUIPEMENT parlent de l’entité-type EQUIPEMENT pour préciser que celle-ci prend pour valeurs des noms d’entités-types (par exemple "LOGICIEL", "MATERIEL", ...) A titre d’analogie, retenez encore que vous faites dans la métadonnée comme M. Jourdain faisait de la prose. Quand vous aurez acquis une certaine assurance, vous pourrez envisager de supprimer ces métadonnées et les remplacer par les vues auxquelles je faisais allusion dans mon message précédent, pour parler du vrai QUOI lors des accès à la base données : SERVEUR, CONTROLEUR, OS, etc.

Typage des métadonnées :

Prenons l’exemple de la table SQL TYPE_EQUIPEMENT. Tant qu’à faire, plutôt qu’utiliser le type INT pour l’attribut id_type_equipement, vous pouvez utiliser le type CHAR, plus parlant, tandis que les valeurs prises par cet attribut sont invariantes (c’est vous qui les maîtrisez et vous n’avez aucune raison de les changer). Cela dit, quels types d’équipements sont décrits ? Concrètement, prévoyez-vous deux valeurs ("matériel", "logiciel") ou la panoplie complète : "OS", "logiciel non OS", "serveur", "switch", "contrôleur") ?

En tout état de cause, vous pouvez prévoir directement un attribut type_equipement dans la table EQUIPEMENT et définir au moyen d’une contrainte la valeur que prendra cet attribut :

Code SQL :

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

1
2
3
4
5
6
7
8
 
create table EQUIPEMENT 
(      id_equipement   INT          not null
     , nom_equipement  VARCHAR(30)  not null
     , type_equipement CHAR (8)     not null
     , ...
    , check (type_equipement IN ('OS', 'serveur', ...))
) ;

C'est-à-dire que vous faites l’économie de la table TYPE_EQUIPEMENT. Mais une fois de plus, libre à vous.

A noter que si l’ attribut type_equipement prend seulement deux valeurs ("matériel", "logiciel"), votre système ne décrit pas par ailleurs les types de matériels.

J'ai donc rajouter une relation entre OS et serveur

Très bien. Mais de la même façon, n’existe-t-il pas des relations entre les différents matériels ?


Concernant le MPD

Il existe un cycle qu’il faut casser « à la main » entre les tables MODELE et PROCEDURE. Ce cycle est la conséquence des cardinalités 0,1/1,1 entre les entités-types correspondantes. Quand vous choisissez de produire votre MCD selon la notation Merise, Power AMC ne se pose aucune question et crée le cycle. Si vous utilisez la notation Entité/Relation, alors vous avez la possibilité de demander à l’AGL de ne pas créer le cycle.
Pour casser, clic gauche à la souris sur l’arc ayant pour source MODELE, et à question de confirmation de suppression : suppression des objets.