Discussion :

[yacine.dev]

Bonjour,je développe un logiciel et j'ai rencontré un problème dans la conception .
voici les règles de gestion:

une opération est exécuté par une personne (soit un client ou bénéficiaire)
une opération est une table.
mais j'ai plusieurs tables de personnes il y'a table client et table bénéficiaire


comment lier ces tables ?sachant qu'une opération est exécute par une seule personne

merci d'avance

[fsmrel]

Vous pouvez procéder à une généralisation des tables CLIENT et BENEFICIAIRE et mettre en oeuvre une table PERSONNE à cet effet. Ceci fait, vous rattachez la table OPERATION à la table PERSONNE :

[yacine.dev]

Oui c'est l'héritage ,merci ,j'ai un autre problème :

règle de gestion:
personne -offre -une offre (entité)->
un rendez-vous est sujet d'une offre.
un rendez-vous est réservé par une personne

ça donne un cycle idpersonne est migré vers rendez-vous et il y'a une relation de rendez-vous -> offre ->personne

et une relation

personne->rendez-vous

les deux relations sont indispensables :
est ce normal d'avoir un tel cycle dans son [MLD] ?

merci

[fsmrel]

Bonjour,


Supposons qu’une personne propose des offres à d’autres personnes.

Selon la représentation graphique ci-dessous, il n’y a pas de véritable cycle, mais seulement un pseudo-cycle, sans risque, car la personne qui propose le rendez-vous n’est pas celle à qui l’on propose ce rendez-vous (Personne contactée). Cette différence entre les personnes est signalée par un mickey traduisant une contrainte d’exclusion (le « X » dans un rond) et faisant l’objet d’un trigger au niveau SQL (ce que l'on peut du reste éviter en utilisant l'identification relative) :



Il existe des variations sur ce thème. Par exemple, si la personne contactée est un client, la relation n'est plus entre RENDEZ_VOUS et PERSONNE mais entre RENDEZ_VOUS et CLIENT.

[fsmrel]

Dans mon message précédent, j’ai écrit que l’on pouvait utiliser un trigger pour s’assurer que la personne qui contacte ne peut pas être la personne contactée. Si l’on utilise l’identification relative :



Alors au niveau SQL, on pourra se dispenser de ce trigger et l’on aura le script suivant, dans lequel la contrainte RENDEZ_VOUS_Chk_1 suffit :

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
Create Table PERSONNE (
   PersonneId           Int                  Not null,
   PersonneNom          Varchar(48)          Not null,
   Autres_Attributs_Communs Varchar(48)      Not null,
   Constraint PERSONNE_PK Primary Key  (PersonneId)
) ;
Create Table OFFRE (
   PersonneId           Int                  Not null,
   OffreId              Int                  Not null,
   Offre_Autres_Attributs Varchar(48)        Not null,
   Constraint OFFRE_PK Primary Key  (PersonneId, OffreId),
   Constraint OFFRE_PERSONNE_1 Foreign Key (PersonneId)
      References Personne (PersonneId)
) ;
Create Table RENDEZ_VOUS (
   RVId                 Int                  Not null,
   PersonneProposantId  Int                  Not null,
   OffreId              Int                  Not null,
   PersonneContacteeId  Int                  Not null,
   RV_Date              Datetime             Not null,
   RV_Heure             Datetime             Not null,
   RV_Duree             Int                  Not null,
   Constraint RENDEZ_VOUS_PK Primary Key  (RVId),
   Constraint RENDEZ_VOUS_OFFRE_1 Foreign Key (PersonneProposantId, OffreId)
      References Offre (PersonneId, OffreId),
   Constraint RENDEZ_VOUS_PERSONNE_2 Foreign Key (PersonneContacteeId)
      References Personne (PersonneId),
   Constraint RENDEZ_VOUS_Chk_1 CHECK (PersonneProposantId <> PersonneContacteeId)
) ;

[yacine.dev]

j'ai le plaisir d'avoir des réponses pareilles ,vous êtes excellent ,mais l'entité rendez-vous devra contenir un seul idpersonne de celui qui a réservé le rendez-vous et pour idPersonneCantacte on le récupére de l'entité offre (idpersonne clés étrangère)
donc la table rendez-vous:
CREATE TABLE RENDEZ_VOUS (
RVId Int NOT NULL,
PersonneProposantId Int NOT NULL,
OffreId Int NOT NULL,
RV_Date Datetime NOT NULL,
RV_Heure Datetime NOT NULL,
RV_Duree Int NOT NULL,
Constraint RENDEZ_VOUS_PK PRIMARY KEY (RVId),
Constraint RENDEZ_VOUS_OFFRE_1 FOREIGN KEY (PersonneProposantId, OffreId)
REFERENCES Offre (PersonneId, OffreId),
)
et comment vérifiera-t-on la contrainte RENDEZ_VOUS_Chk_1(contrainte d'exclusion) dans ce cas ?.
et est ce les triggers existe en mysql?

merci fsmrel

[fsmrel]

l'entité rendez-vous devra contenir un seul idpersonne

Pour quelle raison ? Vous allez vous compliquer la vie inutilement.

D’après la structure de votre table RENDEZ_VOUS, l’attribut PersonneProposantId correspond à la personne qui propose une offre (cf. la contrainte RENDEZ_VOUS_OFFRE_1). En conséquence, cet attribut correspond à l’attribut PersonneId de la table OFFRE.

Puisqu’elle ne figure pas dans la table RENDEZ_VOUS, où figure la personne qui a été contactée ? Quel lien permet de l’associer à un rendez-vous ?


Je n’utilise pas MySQL, mais d’après Internet, ce SGBD permet de mettre en oeuvre des triggers, cf. My SQL, CREATE TRIGGER.

[yacine.dev]

ce sont les règles de gestion qui m'exige ça:

qu 'on on applique les cardinalités sur le MCD

*personne -> propose plusieurs -> offre .
*une offre est proposé par une seule personne.
*une autre personne réserve un rendez-vous ->
*un rendez-vous est le sujet d'une seule offre


donc d'après les cardinalités idpersonneProposant ne va pas être migré vers rendez-vous(directement) en revanche idpersonneProposant va être migré vers offre et idOffre va être migré vers rendez-vous (annuler la transitivité)
et pour la relation
personne réserve rendez-vous est simple idPersonneCantacte( id de personne qui a fait la résevation) il va être migré vers rendez-vous.

[fsmrel]

Il va falloir que vous montriez votre MCD, car il y a trop de flou.

En attendant, quand vous écrivez (je ne sais pas quel est le rôle joué par les flèches...) :

personne -> propose plusieurs -> offre
une offre est proposé par une seule personne.

Alors j’interprète cela ainsi :

Une personne peut proposer plusieurs offres.
Une offre est proposée exactement par une personne.

D'où une relation entre Personne et Offre :

[PERSONNE] ---- 0,N ---- (Proposer) ---- 1,1 ---- [OFFRE]

Quand vous écrivez :

une autre personne réserve un rendez-vous ->

Je suppose qu’il faut interpréter ainsi cette phrase bizarre (toujours cette flèche curieuse...) :

Une personne (différente de chaque personne proposant des offres) peut réserver plusieurs rendez-vous.

Mais vous ne précisez pas si un rendez-vous est réservé par exactement une personne. On va néanmoins admettre qu’il en est ainsi, mais sans certitude :

[PERSONNE] ---- 0,N ---- (Réserver) ---- 1,1 ---- [RENDEZ_VOUS]

Quand vous écrivez :

un rendez-vous est le sujet d'une seule offre ->

On ne sait toujours pas à quoi correspond votre flèche, mais en tout cas vous établissez une relation entre RENDEZ_VOUS et OFFRE, sans que l’on puisse savoir si un rendez-vous fait référence à exactement une offre ou bien si c’est une offre qui fait exactement référence à une offre. On ne peut pas non plus interpréter les autres cardinalités.

Avant d’aller plus loin, le mieux est donc que vous commenciez par fournir votre MCD, sinon on n’en sortira jamais.

donc d'après les cardinalités idpersonneProposant ne va pas être migré vers rendez-vous(directement) en revanche idpersonneProposant va être migré vers offre et idOffre va être migré vers rendez-vous (annuler la transitivité)
et pour la relation
personne réserve rendez-vous est simple idPersonneCantacte( id de personne qui a fait la résevation) il va être migré vers rendez-vous.

Vous parlez du MLD. On y reviendra seulement quand on sera d’accord sur le MCD.

[yacine.dev]

Bonjour,

voici mon [MCD]

[PERSONNE] ---- 0,N ---- (Proposer) ---- 1,1 ---- [OFFRE]

[PERSONNE] ---- 0,N ---- (Réserver) ---- 1,1 ---- [RENDEZ_VOUS]

[OFFRE] ---- 0,N ---- (référence) ---- 1,1 ---- [RENDEZ_VOUS]

tu peux annuler les flèches

[fsmrel]

Bonjour,

On y voit plus clair. Reprenons les entités-types PERSONNE et OFFRE de votre MCD :

[PERSONNE] ---- 0,N ---- (Proposer) ---- 1,1 ---- [OFFRE]
[OFFRE] ---- 0,N ---- (référence) ---- 1,1 ---- [RENDEZ_VOUS]

Lors de la dérivation du MCD en MLD, on obtiendra la structure suivante :

Code :

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

1
2
3
4
5
6
PERSONNE {PersonneId, PersonneNom, ...}
    PRIMARY KEY {PersonneId} ;

OFFRE {OffreId, PersonneOffrantId, ...}
    PRIMARY KEY {OffreId}
    FOREIGN KEY {PersonneOffrantId} REFERENCES PERSONNE {PersonneId} ;

(Pour plus de clarté, dans la table OFFRE, j’ai renommé PersonneId en PersonneOffrantId.)

Complétons avec l’entité-type RENDEZ_VOUS :

[PERSONNE] ---- 0,N ---- (Réserver) ---- 1,1 ---- [RENDEZ_VOUS]

Lors de la dérivation du MCD en MLD, la structure devient la suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
PERSONNE {PersonneId, PersonneNom, ...}
    PRIMARY KEY {PersonneId} ;

OFFRE {OffreId, PersonneOffrantId, ...}
    PRIMARY KEY {OffreId}
    FOREIGN KEY {PersonneOffrantId} REFERENCES PERSONNE {PersonneId} ;

RENDEZ_VOUS {RVId, OffreId, PersonneReservantId, ...}
    PRIMARY KEY {RVId}
    FOREIGN KEY {OffreId} REFERENCES OFFRE {OffreId} ;
    FOREIGN KEY {PersonneReservantId} REFERENCES PERSONNE {PersonneId} ;

(Pour plus de clarté, dans la table RENDEZ_VOUS, j’ai renommé PersonneId en PersonneReservantId.)

Mais on peut faire mieux, en identifiant OFFRE relativement à PERSONNE. Les AGL proposent chacun leur notation à cet effet. Par exemple :

Win’Design :

[PERSONNE] ---- 0,N ---- (Réserver) ---- 1,1 (R) ---- [RENDEZ_VOUS]

Power AMC :

[PERSONNE] ---- 0,N ---- (Réserver) ---- (1,1) ---- [RENDEZ_VOUS]

Open ModelSphere (gratuit) :

[PERSONNE] ---- 0,N ---- (Proposer) ---- 1,1 ---- [OFFRE]

Etc.

Quelle que soit la notation, lors de la dérivation du MCD en MLD, on obtiendra la structure suivante pour la table OFFRE dérivée de l’entité-type OFFRE (l’identifiant de la personne qui a fait l’offre devenant un élément de la clé primaire de la table, et OffreId étant alors un simple numéroteur prenant les valeurs successives 1, 2, ..., n, relativement à chaque personne) :

Code :

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

1
2
3
OFFRE {OffreId, PersonneOffrantId, ...}
    PRIMARY KEY {PersonneOffrantId, OffreId}
    FOREIGN KEY {PersonneOffrantId} REFERENCES PERSONNE {PersonneId} ;

Par conséquent la structure de la table RENDEZ_VOUS devient automatiquement la suivante :

Code :

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

1
2
3
4
5
6
RENDEZ_VOUS {RVId, PersonneOffrantId, OffreId, PersonneReservantId, ...}
    PRIMARY KEY {RVId}
    FOREIGN KEY {PersonneOffrantId, OffreId} 
        REFERENCES OFFRE {PersonneOffrantId, OffreId} ;
    FOREIGN KEY {PersonneReservantId} 
        REFERENCES PERSONNE {PersonneId} ;

Cette fois-ci, vous avez bien deux références à des personnes, l’une étant celle qui a fait l’offre, l'autre étant celle qui a réservé. Puisque la personne qui a réservé ne peut pas être celle qui a fait l’offre, le code SQL ad-hoc doit en tenir compte (contrainte RENDEZ_VOUS_CHK_1) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TABLE RENDEZ_VOUS (
   RVId                 Int                  NOT NULL,
   PersonneOffrantId    Int                  NOT NULL,
   OffreId              Int                  NOT NULL,
   PersonneReservantId  Int                  NOT NULL,
   RV_Date              Datetime             NOT NULL,
   RV_Heure             Datetime             NOT NULL,
   RV_Duree             Int                  NOT NULL,
   CONSTRAINT RENDEZ_VOUS_PK PRIMARY KEY (RVId),
   CONSTRAINT RENDEZ_VOUS_OFFRE FOREIGN KEY (PersonneOffrantId, OffreId)
      REFERENCES Offre (PersonneOffrantId, OffreId),
    CONSTRAINT RENDEZ_VOUS_RESERVER FOREIGN KEY (PersonneReservantId)
      REFERENCES Personne (PersonneId),
   CONSTRAINT RENDEZ_VOUS_CHK_1 CHECK (PersonneOffrantId <> PersonneReservantId)
) ;

Ainsi, on retrouve ce que j'avais déjà proposé.

[yacine.dev]

Lors de la dérivation du MCD en MLD, la structure devient la suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
PERSONNE {PersonneId, PersonneNom, ...}
    PRIMARY KEY {PersonneId} ;

OFFRE {OffreId, PersonneOffrantId, ...}
    PRIMARY KEY {OffreId}
    FOREIGN KEY {PersonneOffrantId} REFERENCES PERSONNE {PersonneId} ;

RENDEZ_VOUS {RVId, OffreId, PersonneReservantId, ...}
    PRIMARY KEY {RVId}
    FOREIGN KEY {OffreId} REFERENCES OFFRE {OffreId} ;
    FOREIGN KEY {PersonneReservantId} REFERENCES PERSONNE {PersonneId} ;

jusqu'ici je suis d'accords

Par conséquent la structure de la table RENDEZ_VOUS devient automatiquement la suivante :

Code :

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

1
2
3
4
5
6
RENDEZ_VOUS {RVId, PersonneOffrantId, OffreId, PersonneReservantId, ...}
    PRIMARY KEY {RVId}
    FOREIGN KEY {PersonneOffrantId, OffreId} 
        REFERENCES OFFRE {PersonneOffrantId, OffreId} ;
    FOREIGN KEY {PersonneReservantId} 
        REFERENCES PERSONNE {PersonneId} ;

.
.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TABLE RENDEZ_VOUS (
   RVId                 Int                  NOT NULL,
   PersonneOffrantId    Int                  NOT NULL,
   OffreId              Int                  NOT NULL,
   PersonneReservantId  Int                  NOT NULL,
   RV_Date              Datetime             NOT NULL,
   RV_Heure             Datetime             NOT NULL,
   RV_Duree             Int                  NOT NULL,
   CONSTRAINT RENDEZ_VOUS_PK PRIMARY KEY (RVId),
   CONSTRAINT RENDEZ_VOUS_OFFRE FOREIGN KEY (PersonneOffrantId, OffreId)
      REFERENCES Offre (PersonneOffrantId, OffreId),
    CONSTRAINT RENDEZ_VOUS_RESERVER FOREIGN KEY (PersonneReservantId)
      REFERENCES Personne (PersonneId),
   CONSTRAINT RENDEZ_VOUS_CHK_1 CHECK (PersonneOffrantId <> PersonneReservantId)
) ;

comment tu 'as passé à ça et tu as migré PersonneOffrantId vers RENDEZ_VOUS
Par conséquent de quoi ?

[fsmrel]

Bonsoir,

Par conséquent de quoi ?

En conséquence de l’utilisation de l’identification relative.

Je corrige ce que j’avais écrit dans mon message précédent, car suite à un copier/coller, j’avais conservé la table RENDEZ_VOUS alors qu’il s’agissait de la table OFFRE. Je cite donc en corrigeant :

Mais on peut faire mieux, en identifiant OFFRE relativement à PERSONNE. Les AGL proposent chacun leur notation à cet effet. Par exemple :

Win’Design :

[PERSONNE] ---- 0,N ---- (Réserver) ---- 1,1 (R) ---- [OFFRE]

Power AMC :

[PERSONNE] ---- 0,N ---- (Réserver) ---- (1,1) ---- [OFFRE]

Open ModelSphere (gratuit) :

[PERSONNE] ---- 0,N ---- (Proposer) ---- 1,1 ---- [OFFRE]

Etc.

Illustrons ceci en utilisant par exemple Power AMC. Identifions OFFRE relativement à PERSONNE. Le MCD est le suivant (notez les parenthèses encadrant la cardinalité 1,1) :



En conséquence de l’utilisation de l’identification relative, Power AMC produit scrupuleusement le MLD suivant dans lequel, pour plus de clarté, j’ai renommé PersonneId en PersonneOffrantId dans la table OFFRE (avec propagation dans la table RENDEZ_VOUS) et PersonneId en PersonneReservantId dans la table RENDEZ_VOUS) :


La clé primaire (symbolisée par le mickey <pk>) de la table OFFRE est la paire {PersonneOffrantId, OffreId}.

Concernant la table RENDEZ_VOUS, Power AMC produit le code SQL figurant dans mon message précédent, où je m'étais contenté d’ajouter la ligne suivante pour la table RENDEZ_VOUS :

CONSTRAINT RENDEZ_VOUS_CHK_1 CHECK (PersonneOffrantId <> PersonneReservantId).

Le code SQL produit par Power AMC est le suivant en ce qui concerne la table OFFRE :

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE OFFRE (
   PersonneOffrantId    Int                  NOT NULL,
   OffreId              Int                  NOT NULL,
   Offre_Autres_Attributs Varchar(48)        NOT NULL,
   CONSTRAINT OFFRE_PK PRIMARY KEY (PersonneOffrantId, OffreId),
   CONSTRAINT OFFRE_PERSONNE FOREIGN KEY (PersonneOffrantId)
      REFERENCES Personne (PersonneId)
) ;

En passant, il est peut-être bon de rappeler qu’une clé peut être constituée d’un nombre quelconque d’attributs. Selon la théorie relationnelle, la définition de la clé est la suivante (traduisez relvar par table en SQL) :

Une clé est un sous-ensemble d’attributs K de l’en-tête d’une relvar R, respectant les deux contraintes suivantes :

• Unicité. Deux tuples distincts de R ne peuvent avoir même valeur de K.
• Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.

Et quand on parle de sous-ensemble, c’est au sens de la théorie des ensembles, théorie à laquelle se rattache la théorie relationnelle.

[yacine.dev]

bonjour fsmrel


(En conséquence de l’utilisation de l’identification relative on aura ceci

rendez_vous ->(détermine) personne offrante

mais en conséquence de l'application de règles d'annuler la transitivité cette dépendance fonctionnelle doit être annulée

rendez_vous détermine offre et offre détermine personne offrante
rendez_vous -> offre -> personne offrante

[fsmrel]

Bonjour,

En conséquence de l’utilisation de l’identification relative on aura ceci

rendez_vous ->(détermine) personne offrante

Vous traitez manifestement des dépendances fonctionnelles. Vous ne précisez pas s’il s’agit des dépendances fonctionnelles définies il y a trente ans dans leur contexte originel, c'est-à-dire celui de la théorie relationnelle (E. F. Codd. Further Normalization of the Data Base Relational Model. IBM Research Report, RJ909, San Jose - August 31, 1971), ou bien des dépendances fonctionnelles utilisées bien plus tard dans le contexte du formalisme Merise. A vous lire, je pense que vous vous situez dans le contexte merisien et je ne parlerai donc pas des dépendances fonctionnelles de la théorie relationnelle.

Rappelons quelques définitions.

En Merise, on dit qu’il existe une dépendance fonctionnelle entre deux entités-types X et Y :

X → Y

si à toute occurrence de X correspond une seule occurrence de Y (ce qui peut encore se formuler ainsi : si toute occurrence de X détermine une occurrence de Y). Appelons cette règle : Règle d'unicité.

Ainsi, le dernier MCD que j’ai proposé comporte trois dépendances fonctionnelles, DF1, DF2 et DF3, qui sont les conséquences des cardinalités 1,1.

1) Entre les entités-types RENDEZ_VOUS et OFFRE (via l’association Etre sujet) :

DF1 : RENDEZ_VOUS → OFFRE

2) Entre les entités-types OFFRE et PERSONNE (via l’association Proposer) :

DF2 : OFFRE → PERSONNE

3) Entre les entités-types RENDEZ_VOUS et PERSONNE (via l’association Reserver) :

DF3 : RENDEZ_VOUS → PERSONNE

Maintenant, la dépendance fonctionnelle DF3 est-elle une conséquence de la transitivité ? La réponse est négative. En effet, par transitivité vous déterminez la personne qui a proposé un rendez-vous (occurrence 1), laquelle doit être différente de la personne qui fait la réservation (occurrence 2) : on a deux occurrences différentes, en contradiction avec la règle d’unicité. La dépendance fonctionnelle DF3 n'est pas transitive et doit donc être conservée.

[yacine.dev]

Bonjour,



je ne parle pas de la relation personne ----réserve----rende_vous on est d'accords.
ce je vois illogique .
quand tu as appliqué l'identification relative tu as migré la clé personneOffrant vers rendez-vous donc comme on a passé de cette relation (seule différence c'est que idpersonneOffrant migré et mis clé primaire dans la table rendez-vous):


personne (1,n)------ propose-----(1,1) rendez-vous

qui corresponde à DF4 : rendez-vous-> personne (qui a proposé l'offre)

ce qui contredit (la transitivité)

DF1 : RENDEZ_VOUS → OFFRE
et
DF2 : OFFRE → PERSONNE

donc le DF4 doit être annulé =>la relation personne (1,n)------propose-----(1,1) rendez vous aussi doit être annulé donc la clés idPersonneOffrant ne sera pas migré vers rendez-vous ,et toi tu l'as migré par application de règle d'identification relative je pose la question est ce que l'application d'identification relative =transitivité dans ce cas ?

[fsmrel]

Bonsoir,


Terminons-en avec la dépendance fonctionnelle au sens merisien du terme. Je rappelle ce que j’ai déjà écrit :

En Merise, on dit qu’il existe une dépendance fonctionnelle entre deux entités-types X et Y :

X → Y

si à toute occurrence de X correspond une seule occurrence de Y.

Revenons au triplet PERSONNE, OFFRE, RENDEZ_VOUS.

1) Cas de l’identification absolue



D’après cette représentation graphique, on a les dépendances fonctionnelles merisiennes suivantes :

DF1 : RENDEZ_VOUS → OFFRE
DF2 : OFFRE → PERSONNE

Donc par transitivité :

DF4 : RENDEZ_VOUS → PERSONNE

2) Cas de l’identification relative



On a exactement les mêmes dépendances fonctionnelles :

DF1 : RENDEZ_VOUS → OFFRE
DF2 : OFFRE → PERSONNE

Et par transitivité :

DF4 : RENDEZ_VOUS → PERSONNE

Autrement dit, que l’identification soit relative ou absolue, cela ne joue en rien quand on traite des dépendances fonctionnelles merisiennes et a fortiori de la la transitivité.


Considérons maintenant votre affirmation à propos de la transitivité :

personne (1,n)------ propose-----(1,1) rendez-vous

qui corresponde à DF4 : rendez-vous-> personne (qui a proposé l'offre)

ce qui contredit (la transitivité)

Puisque du point de vue de Merise, votre affirmation ne s’applique pas, si elle avait un sens, ça serait dans le contexte de la théorie relationnelle. Traitons donc des dépendances fonctionnelles dans ce contexte.

Dépendance fonctionnelle dans le contexte de la théorie relationnelle

Une dépendance fonctionnelle est une contrainte entre les attributs d’une variable relationnelle (en abrégé relvar) ou plus informellement d’une table si on se situe dans le contexte SQL. Notons déjà qu’une dépendance fonctionnelle ne met plus en relation des entités-types, mais des sous-ensembles d'attributs au sein d’une relvar.

Une dépendance fonctionnelle (DF) est une instruction de la forme :

X → Y

où X et Y sont deux sous-ensembles d’attributs de l’en-tête d’une relvar R, et satisfaisant à la règle : pour une valeur de X, correspond exactement une valeur de Y, c'est-à-dire que si deux tuples (ou lignes dans le cas des tables) ont la même valeur vx pour X, alors ils ont aussi la même valeur vy pour Y.
On dit encore que Y est fonctionnellement dépendant de X, ou que X détermine fonctionnellement Y. X est appelé le déterminant de la DF et Y le dépendant.

Examinons maintenant les structures tabulaires.

a) Utilisation de l’identification absolue :



Concernant la relvar PERSONNE, on a les dépendances fonctionnelles suivantes (notez l’utilisation des accolades, car les déterminants et les dépendants sont des ensembles (au sens de la théorie des ensembles), alors que les attributs ne sont que des éléments de ces ensembles) :

DFa : {PersonneId} → {PersonneNom}
DFb : {PersonneId} → {Autres_Attributs_Communs}

Il existe d’autres dépendances fonctionnelles dites triviales, mais qui ne nous intéressent pas ici.

Concernant la relvar OFFRE, on a les dépendances fonctionnelles non triviales suivantes :

DFc : {OffreId} → {PersonneId}
DFd : {OffreId} → {Offre_Autres_Attributs}

Concernant la relvar RENDEZ_VOUS, on a les dépendances fonctionnelles non triviales suivantes :

DFe : {RVId} → {OffreId}
DFf : {RVId} → {PersonneReservantId}
DFg : {RVId} → {RV_Date}
DFh : {RVId} → {RV_Heure}
DFi : {RVId} → {RV_Duree}

b) Utilisation de l’identification relative :



Concernant la relvar PERSONNE, rien de changé.

Concernant la relvar OFFRE, on a la dépendance fonctionnelle non triviale suivante :

DFc’ : {PersonneOffrantId, OffreId} → {Offre_Autres_Attributs}

Mais il n’existe pas cette fois-ci d'autres dépendances fonctionnelles non triviales telles que :

{OffreId} → { PersonneOffrantId}
{OffreId} → {Offre_Autres_Attributs}

Car OffreId est relatif à PersonneOffrantId : il s'agit par exemple d'un banal numéroteur dont les valeurs recommencent à 1 pour chaque valeur de PersonneOffrantId. Exemple :

Code :

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

1
2
3
4
5
6
7
PersonneOffrantId  OffreId  Offre_Autres_Attributs
        1             1            v11
        1             2            v12
        1             3            v13
        2             1            v21
        2             2            v22
       ...           ...           ...

On voit clairement que pour une valeur de OffreId, on a plus d’une valeur de PersonneOffrantId et de Offre_Autres_Attributs.

Concernant la relvar RENDEZ_VOUS, comme dans le cas de l’identification absolue, on a les dépendances fonctionnelles non triviales suivantes :

DFe : {RVId} → {OffreId}
DFf : {RVId} → {PersonneReservantId}
DFg : {RVId} → {RV_Date}
DFh : {RVId} → {RV_Heure}
DFi : {RVId} → {RV_Duree}

Avec en plus la dépendances fonctionnelle non triviale suivante :

DFj : {RVId} → {PersonneOffrantId}

Mais il n’existe pas de dépendance fonctionnelle non triviale dont {PersonneOffrantId, OffreId} constituerait le déterminant, puisqu’on sait que pour une offre on peut avoir plus d’un rendez-vous.

En conclusion, parmi l'ensemble des dépendances fonctionnelles, on constate qu'aucune n'est transitive : votre affirmation concernant la transitivité ne s’applique pas plus dans le contexte de la théorie relationnelle que dans celui du formalisme de Merise.

Accessoirement, s’il y avait d’autres dépendances fonctionnelles à rechercher, ça serait en relation avec des règles de gestion des données sans relation avec le choix du type d’identification, que celle-ci soit absolue ou relative. Exemple : peut-on effectuer plus d’une réservation le même jour, à la même heure pour la même personne ?

Question subsidiaire :

mais en conséquence de l'application de règles d'annuler la transitivité cette dépendance fonctionnelle doit être annulée

D’où tirez-vous cette expression « en conséquence de l'application de règles d'annuler » ? Serait-ce en relation avec la troisième forme normale ?

[yacine.dev]

Bonsoir fsmrel,

On voit clairement que pour une valeur de OffreId, on a plus d’une valeur de PersonneOffrantId et de Offre_Autres_Attributs.

Non ,pour une valeur de OffreId il y'a une seule valeur de PersonneOffrantId et de Offre_Autres_Attributs

OffreId --> personne (qui l'a offert)

et ça se voit dans la relation

une seule personne offre une ou plusieurs offres et une offre est offerte par une seule personne

personne (1,n)------ offrir-----(1,1) offre

D’où tirez-vous cette expression « en conséquence de l'application de règles d'annuler » ? Serait-ce en relation avec la troisième forme normale ?

oui

[fsmrel]

Non ,pour une valeur de OffreId il y'a une seule valeur de PersonneOffrantId et de Offre_Autres_Attributs

OffreId --> personne (qui l'a offert)

et ça se voit dans la relation

une seule personne offre une ou plusieurs offres et une offre est offerte par une seule personne

personne (1,n)------ offrir-----(1,1) offre

Tout d’abord, je vous ai expliqué qu’il y a d’une part les dépendances fonctionnelles selon le formalisme Merise, c'est-à-dire entre entités-types, et d’autre part les dépendances fonctionnelles selon la théorie relationnelle, c'est-à-dire entre sous-ensembles d’attributs d’une relvar donnée.

Quand vous écrivez :

OffreId --> personne

vous utilisez une flèche entre un attribut et une entité-type, ce qui syntaxiquement et mathématiquement ne veut rien dire. Vous faites une salade de concepts de nature différente, avec un attribut d’une part, une entité-type d’autre part.

Quand vous écrivez :

ça se voit dans la relation

Non. Ce qu’on « voit dans la relation », c’est une dépendance fonctionnelle merisienne entre les deux entités-types OFFRE et PERSONNE :



Ceci dit, je reprends l’exemple que vous n’avez manifestement pas pris la peine d'étudier et qui concerne l’identification relative :

Code :

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

1
2
3
4
5
6
7
PersonneOffrantId  OffreId  Offre_Autres_Attributs
        1             1            v11
        1             2            v12
        1             3            v13
        2             1            v21
        2             2            v22
       ...           ...           ...

On voit que pour la valeur 1 de OffreId, on a deux valeurs de PersonneOffrantId, donc la dépendance fonctionnelle

{OffreId} → {PersonneOffrantId}

n’existe pas. Votre affirmation « Pour une valeur de OffreId il y a une seule valeur de PersonneOffrantId » est donc fausse dans le cas de l’identification relative. Est-ce clair ?

Concernant la troisième forme normale (3NF).

Vous me ferez le plaisir de me donner votre définition de la 3NF. En attendant je vous donne la mienne, qui est en fait celle du Dr. Carlo Zaniolo, qui n’est pas un perdreau de l'année :

Soit R une relvar, X un sous-ensemble d’attributs de l’en-tête de R et A un attribut de cet en-tête. R est en troisième forme normale si et seulement si, pour chaque dépendance fonctionnelle X → {A} vérifiée dans R, au moins une des conditions suivantes est satisfaite :
1. Cette dépendance fonctionnelle est triviale (A est un élément de X).
2. X est une surclé de R.
3. A appartient à une clé candidate de R.

Pour la définition des concepts de surclé, de clé candidate, de dépendance fonctionnelle, de dépendance fonctionnelle triviale, etc. voyez ma réponse à la discussion Unicité d'une clef composée entamée par highlander03.

Que vous le vouliez ou non, la relvar RENDEZ_VOUS respecte la troisième forme normale. En effet, les dépendances fonctionnelles non triviales qu’elle comporte sont les suivantes :

DFe : {RVId} → {OffreId}
DFf : {RVId} → {PersonneReservantId}
DFg : {RVId} → {RV_Date}
DFh : {RVId} → {RV_Heure}
DFi : {RVId} → {RV_Duree}
DFj : {RVId} → {PersonneOffrantId}

Et elles respectent toutes la condition 2. On démontre même que la relvar RENDEZ_VOUS respecte la cinquième forme normale. Que demander de mieux ?

Maintenant, soit vous faites l’effort de lire et de comprendre ce que je vous explique de façon suffisamment rigoureuse, soit vous restez dans vos approximations personnelles et fausses, auquel cas on en restera là.

Suis-je assez clair ?

[yacine.dev]

Bonjour,

vous n’avez manifestement pas pris la peine d'étudier et qui concerne l’identification relative :

si j'ai cherché pour comprendre de quoi me parlez-vous

n’existe pas. Votre affirmation « Pour une valeur de OffreId il y a une seule valeur de PersonneOffrantId » est donc fausse dans le cas de l’identification relative. Est-ce clair ?

je laisse coté les formes normales pour vous parler de notre point de divergence .
Je ne suis pas d'accords qu'il y'a une identification relative(offre/personneOffrant) dés le début et je vous ai posé la question pourquoi vous avez appliquer l'identification relative vous m'avez dis que idOffre est un banal numérotateur et que pour une valeur de idOffre on aura plusieurs valeurs de {offre attributs}
et plusieurs valeurs idPersonneOffrant ce que j'ai compris de :

Code :

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

1
2
3
4
5
6
7
PersonneOffrantId  OffreId  Offre_Autres_Attributs
        1             1            v11
        1             2            v12
        1             3            v13
        2             1            v21
        2             2            v22
       ...           ...           ...

On voit clairement que pour une valeur de OffreId, on a plus d’une valeur de PersonneOffrantId et de Offre_Autres_Attributs.

ça contredit mes règles de gestion consistant en :

une seule personne offre une ou plusieurs offres et une offre est offerte par une seule personne.

donc je vois qu'il n'y a pas d'identification relative car on a idOffre-->{offre attribut}
idOffre-->IDpersonneOffrant (car pour une offre dont l' IDpersonneOffrant = 10 ,la personne qui elle a offert est celle dont l'IDPersonneOffrant=13)

et comme ça nous revenons au point de départ

(même que Identification relative dans ce cas me facilitera la tâche dans les jointures j'aurai pas une longue jointure et par conséquent il n'aura pas une lourdeur dans l'exécution de requête )

a) Utilisation de l’identification absolue :

Sans appliquer l'identification relative on est d'accords et je vous remercie beaucoup vous êtes serviable et j'ai pris vos messages avec beaucoup d'intérêt (voir je les lisais plusieurs fois pour vous comprendre même que j'ai commis cette erreur offreId->personne : ).


D'après ce que je viens de vous dire insistez-vous sur l'identification relative ?