Discussion :

[fredx76]

Bonjour,
Je suis en train de développer un petit intranet et je bloque depuis pas mal de temps sur mon MCD pour ma base de données je m'explique :

- Un client signe un contrat, un contrat peut être signé par un seul client.
- Un contrat (prix, date) contient un logiciel(nom logiciel) et un logiciel peut être sur plusieurs contrats).
- Un logiciel peut contenir plusieurs module(nom module), un module correspond a un seul logiciel.

et c'est la que je bloque :
- Ou puis je stocké la date d'installation du module d'un logiciel pour un client sachant que chaque client n'opte pas pour les même modules pour un même produit?

Merci par avance.

[fsmrel]

Bonsoir fredx76,


Commencez déjà par construire un MCD sans tenir compte du point sur lequel vous bloquez. Vous présentez ce MCD et on verra ensuite pour vous aider.

[fredx76]

Voila le MCD,
maintenant comment et ou puis je insérer la date d'installation du module choisit par le client pour un logiciel, sachant que tous les clients ne choisissent pas le(s) même(s) module pour un même logiciel.

Merci par avance.

[CinePhil]

- Un client signe un contrat, un contrat peut être signé par un seul client.
- Un contrat (prix, date) contient un logiciel(nom logiciel) et un logiciel peut être sur plusieurs contrats).
- Un logiciel peut contenir plusieurs module(nom module), un module correspond a un seul logiciel.

En fait, dans ton MCD, tu as modélisé ces règles de gestion :
1) Un client peut avoir un contrat et un contrat n'appartient qu'à un client.
2) Un contrat peut concerner un logiciel et un logiciel est concerné par un à plusieurs contrats.
3) Un logiciel peut contenir plusieurs modules et un module est contenu dans un seul logiciel.

Au passage, nommez vos entités types au singulier car elles sont issues des règles de gestion qui décrivent ce qui se passe successivement pour 1 instance de chaque entité type.

Ou puis je stocké la date d'installation du module d'un logiciel pour un client sachant que chaque client n'opte pas pour les même modules pour un même produit?

D'après le MCD, un client peut avoir un contrat concernant un logiciel sans module. Correct ?
Il y aurait donc potentiellement :
- des contrats sans logiciel ;
- des contrats avec logiciel sans module ;
- des contrats avec logiciel + un à plusieurs modules.

Ce que je viens d'écrire ressemble à une spécialisation des contrats, c'est à dire à la modélisation d'un héritage de données.

[fredx76]

Tout d'abord merci de vos réponse rapide.

Si j'ai bien compris le MCD devra ressemblé à ça (voir PJ).
Je ne vois toujours pas ou stoker les date d'installation des modules choisi par les clients et comment je faire pour savoir quel module à choisit un client?

Merci par avance.

[CinePhil]

Non, ce n'est pas ça du tout !

contrat_avec_logiciel -(1,1)----être----0,1- contrat
contrat_avec_module -(1,1)----être----0,1------|

Nota : Les cardinalités entre parenthèses signifient une identification relative et entraînent une absence d'identifiant propre dans les entités types filles. La future clé primaire des tables "contrat_avec_logiciel" et "contrat_avec_module" sera une clé étrangère référençant la clé primaire de la table "contrat".

Ensuite on associe les entités types filles à la bonne entité type selon leur nature :
logiciel -0,n----concerner----1,1- contrat_avec_logiciel -(1,1)----être----0,1- contrat
module -0,n----concerner----1,n- contrat_avec_module -(1,1)----être----0,1------|

L'association "concerner" entre "module" et "contrat_avec_module" contiendra la date d'installation du module.

[fredx76]

Je ne vois pas bien ce qu'est contrat_avec_logiciel et contrat_avec_module est des tables supplémentaire?des associations? ou les placées?

Voila le début du MCD est il correct?
C'est la première fois que je travail avec les heritations de données, je ne comprends pas tout.

[CinePhil]

Tu conserves ton association entre logiciel et module de ton premier schéma et tu remplaces l'association entre contrat et logiciel par le schéma que je t'ai donné.
En format texte pas beau, ça donne à peu près ça :

logiciel -0,n----concerner----1,1- contrat_avec_logiciel -(1,1)----être----0,1- contrat
|
0,n
|
Contenir
|
1,1
|
module -0,n----concerner----1,n- contrat_avec_module -(1,1)----être----0,1------|

[fredx76]

Voila ou j'en suis (voir schéma).

Est ce normal d'avoir deux associations nommée Être et Concerner?

[Richard_35]

Bonjour Fredx76, Fsmrel, et Philippe,

Je me permets de m'immiscer, Philippe...

Intéressante problématique qui revient souvent : l'inclusion d'un niveau sans, forcément, l'ensemble de ses sous-niveaux.

Suggestion (direct en table car je ne vois comment établir le schéma correspondant : ce sont, peut-être, les 2% manquants à Merise) :

Client(IdClient, Nom, ...)
Logiciel(IdLogiciel, ...)
Module(IdModule, #IdLogiciel, ...)
Contrat(IdContrat, #IdClient, #IdLogiciel, DateInstallationLogiciel, ...)
Contrat_Module(IdContrat, #IdModule, DateInstallationModule, ...)

=> Module trigger avant modification : ancien IdLogiciel/IdModule n'existe pas dans Contrat_Module
=> Module trigger avant suppression : IdLogiciel/IdModule à supprimer n'existe pas dans Contrat_Module
=> Contrat_Module trigger : contrôle IdLogiciel/IdModule existant dans Module

[fredx76]

Bonjour Richard_35, voici le MCD que j'ai réalisé en suivant tes instructions,
cela te parait il correct?

[Richard_35]

cela te parait il correct?

==> conceptuellement : oui. Mais ce sont les triggers qui sont importants, dans l'histoire. Dans ton schéma (seul), un contrat peut contenir un module qui n'appartient pas à un logiciel sous contrat...
==> fonctionnellement : c'est à toi de le dire en faisant "tourner l'application finale dans ta tête".

[CinePhil]

Voila ou j'en suis (voir schéma).

Est ce normal d'avoir deux associations nommée Être et Concerner?

Ça ne pose pas de problème mais je sais que certains logiciels de modélisation n'aiments pas ça (Analyse SI je crois).

Pour compléter ton MCD avec héritage de données, il faudrait ajouter :
- une contrainte d'exclusion entre les deux associations "être" car un contrat est soit un contrat_logiciel, soit un contrat_module, soit aucun des deux (ce n'est donc pas une contrainte d'exclusion + totalité) ;
- une contrainte (sous forme de note car je ne pense pas que ce soit une contrainte d'inclusion) précisant que tous les modules d'un contrats doivent êtres contenus dans le même logiciel.

Client(IdClient, Nom, ...)
Logiciel(IdLogiciel, ...)
Module(IdModule, #IdLogiciel, ...)
Contrat(IdContrat, #IdClient, #IdLogiciel, DateInstallationLogiciel, ...)
Contrat_Module(IdContrat, #IdModule, DateInstallationModule, ...)

Petit détail : la clé étrangère #IdLogiciel ne peut pas figurer dans la table Contrat puisqu'il peut, d'après le MCD de Fred, y avoir des contrats sans logiciel. Il faut donc une table associative puisque les cardinalités sont 0,1 - 0,n ce qui revient à créer la table contrat_logiciel, c'est à dire faire l'héritage que j'ai préconisé !

[fsmrel]

Bonsoir à vous trois,


Je propose de surseoir un instant et de revenir à la case Départ...

J’observe en effet une contradiction entre l’énoncé que j’appellerai RG01 et la représentation graphique.

RG01 :

Un contrat (prix, date) contient un logiciel (nom logiciel) et un logiciel peut être sur plusieurs contrats.

Représentation graphique proposée par fredx76 :



Si on traduit l’énoncé, la représentation graphique est différente (corrections en rouge) :



Je propose qu’avant d’empiler des choses compliquées nous acceptions que la règle RG01 soit correcte, c'est-à-dire que chaque contrat porte sur un logiciel.

Cela dit, je suis d’accord avec l’approche du problème par Richard, et avec les aménagements d’usage concernant le dernier MCD de fredx76, la représentation graphique ci-dessous devrait être satisfaisante (noter en passant l’utilisation de l’identification relative de MODULE par rapport à LOGICIEL, car sémantiquement parlant un module est une propriété multivaluée d’un logiciel, même si par piratage on peut le retrouver ailleurs, mais ce ci est une autre histoire...) :



La contrainte d’inclusion en rouge signifie que si pour un contrat x il est fait mention de l’installation de modules z entrant dans la composition du logiciel y, alors le contrat x doit aussi faire mention de l’installation du logiciel y.

Dans la série ceinture, bretelles et épingle à nourrice, prenons en compte les pivots (pointillés en bleu) :



Sachant que le plus sûr est — au niveau du cambouis — de coder l’assertion SQL garantissant la contrainte...

Tables :

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
39
40
41
42
43
44
45
46
47
48
49
CREATE TABLE LOGICIEL
(
        LogicielId            INT              NOT NULL
      , LogicielNom           VARCHAR(64)      NOT NULL    
    , CONSTRAINT LOGICIEL_PK PRIMARY KEY (LogicielId)
) ;
 
CREATE TABLE MODULE
(
        LogicielId              INT              NOT NULL
      , ModuleId                INT              NOT NULL
      , ModuleNom               VARCHAR(64)      NOT NULL
    , CONSTRAINT MODULE_PK PRIMARY KEY (LogicielId, ModuleId)
    , CONSTRAINT MODULE_LOGICIEL_FK FOREIGN KEY (LogicielId)
                 REFERENCES LOGICIEL (LogicielId) ON DELETE CASCADE 
) ;
 
CREATE TABLE CLIENT
(
        ClientId                INT              NOT NULL
      , ClientNom               VARCHAR(64)      NOT NULL
    , CONSTRAINT CLIENT_PK PRIMARY KEY (ClientId)
) ;
 
CREATE TABLE CONTRAT
(
        ContratId               INT              NOT NULL
      , ClientId                INT              NOT NULL
      , LogicielId              INT              NOT NULL
      , LogicielDateInstal      DATETIME         NOT NULL
    , CONSTRAINT CONTRAT_PK PRIMARY KEY (ContratId)
    , CONSTRAINT CONTRAT_CLIENT_FK FOREIGN KEY (ClientId)
                 REFERENCES CLIENT (ClientId) 
    , CONSTRAINT CONTRAT_LOGICIEL_FK FOREIGN KEY (LogicielId)
                 REFERENCES LOGICIEL (LogicielId) 
) ;
 
CREATE TABLE CONTRAT_MODULE
(
        ContratId               INT              NOT NULL
      , LogicielId              INT              NOT NULL
      , ModuleId                INT              NOT NULL
      , ModuleDateInstal        DATETIME         NOT NULL
    , CONSTRAINT CONTRAT_MODULE_PK PRIMARY KEY (ContratId, LogicielId, ModuleId)
    , CONSTRAINT CONTRAT_MODULE_CONTRAT_FK FOREIGN KEY (ContratId)
                 REFERENCES CONTRAT (ContratId) 
    , CONSTRAINT CONTRAT_MODULE_MODULE_FK FOREIGN KEY (LogicielId, ModuleId)
                 REFERENCES MODULE (LogicielId, ModuleId) 
) ;

Assertion :

Code SQL :

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

1
2
3
4
5
6
CREATE ASSERTION fredx76_ASSERT_01 CHECK 
    (NOT EXISTS (
                 SELECT x.ContratId
                 FROM   CONTRAT AS x JOIN LOGICIEL AS y ON x.LogicielId = y.LogicielId
                                     JOIN CONTRAT_MODULE AS z ON x.LogicielId <> z.LogicielId
    )) ;

Si le SGBD ne permet pas la mise en oeuvre des assertions, on palliera bien sûr avec un trigger.


Maintenant, s’il faut spécialiser les contrats dans la mesure où certains d’entrée eux ne concerneraient que des modules, d’accord pour aménager, mais on part alors plutôt sur une histoire d’avenants aux contrats, car signer un contrat pour des modules sans avoir d’abord acquis contractuellement le logiciel correspondant me paraît pour le moins bizarre, mon cher cousin (Moi, j'ai dit bizarre, bizarre, comme c'est étrange !)


@fredx76

Dans l'état actuel des choses, on n’a pas traité du cas du client qui fait l'acquisition du logiciel, tous modules confondus. Comment traite-t-on de la chose ?


P.-S. Parmi les contrôles à sous-traiter au SGBD (à coup d’assertions ou de triggers), on peut par exemple s’assurer qu’une date de signature pour l’installation d’un module n’est pas antérieure à la date d’installation du logiciel correspondant : au niveau SQL, ceci reviendrait à compléter l’assertion fredx76_ASSERT_01 (à tester).

[fredx76]

Bonjour fsmrel,
Un contrat peut ne pas concerner un logiciel car ce contrat peut être un contrat matériel défini par type_cont dans la table contrat

[Richard_35]

Bonjour à tous,

Petit détail : la clé étrangère #IdLogiciel ne peut pas figurer dans la table Contrat puisqu'il peut, d'après le MCD de Fred, y avoir des contrats sans logiciel. Il faut donc une table associative puisque les cardinalités sont 0,1 - 0,n ce qui revient à créer la table contrat_logiciel, c'est à dire faire l'héritage que j'ai préconisé !

==> dû à la contradiction relevée par Fsmrel :

J’observe en effet une contradiction entre l’énoncé que j’appellerai RG01 et la représentation graphique.

:

- Un contrat (prix, date) contient un logiciel(nom logiciel) et un logiciel peut être sur plusieurs contrats).

==> Fredx76 semble maîtriser les "peut" et "doit", le MCD est donc en contradiction avec cette phrase re-.