Discussion :

[Msysteme]

Bonjour, comment puis je traduire une relation de type 1 ---- 0,1 au niveau d'un schema ms sql server ?

Merci

[elsuket]

Bonjour,

Vous voulez dire dans un MPD SQL Server ou un MCD ?

@++

[SQLpro]

Par une double jointure entre les clef primaires de chacune des tables.

Exemple :

Code :

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

1
2
T_HOM (HOM_ID, HOM_NOM)
T_FEM (FEM_ID, FEM_NOM)

Et si HOM est marié à FEM en 1:1 alors :

Code :

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

1
2
3
ALTER TABLE T_HOM ADD FEM_ID INT NULL CONSTRAINT FK_HOM_FEM FOREIGN KEY REFERENCES T_FEM (FEM_ID)
 
ALTER TABLE T_FEM ADD HOM_ID INT NULL CONSTRAINT FK_FEM_HOM FOREIGN KEY REFERENCES T_HOM (HOM_ID)

A +

[Msysteme]

Ma relation est la suivante : une demande peut avoir 0 ou 1 rejet mais le rejet a automatiquement une seule demande, si j'ai trés bien compris j'aurais une clé étrangère dans les deux coté ?

[SQLpro]

Oui, et il faudra faire une jointure avec les deux colonnes...

A +

[fsmrel]

Bonjour,

Ma relation est la suivante : une demande peut avoir 0 ou 1 rejet mais le rejet a automatiquement une seule demande, si j'ai très bien compris j'aurais une clé étrangère dans les deux coté ?

La double clé étrangère engendre un cycle, ce qui n’est jamais à recommander. Je propose une alternative.

Dans ce qui suit, j’utilise l’AGL Power AMC (V11).

Le rejet est une propriété de la demande. Conceptuellement, si vous décidez de définir une entité-type Demande et une entité-type Rejet, le MCD (représentation Entité/Relation) est alors le suivant :




Le MLD généré par l’AGL est le suivant :



La table Demande a pour clé primaire DemandeId.
La table Rejet a aussi pour clé primaire DemandeId, qui est simultanément clé étrangère.

Le code SQL généré par l’AGL est le suivant :

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
 
Create Table Demande (
   DemandeId            Int                  Not null,
   DemandeTexte         Varchar(128)         Not null,
   Constraint Demande_PK Primary Key  (DemandeId)
) ;
 
Create Table Rejet (
   DemandeId            Int                  Not null,
   RejetMotif           Varchar(128)         Not null,
   Constraint Rejet_PK Primary Key  (DemandeId),
   Constraint Rejet_Demande_FK1 Foreign Key (DemandeId)
      References Demande (DemandeId)
         On Delete Cascade
) ;

Diagramme proposé par SQL Server à partir du code ci-dessus :

[SQLpro]

Oui, mais là tu triches... Car tu utilise un héritage !!!
Entre nous c'est quand même la meilleure solution !

A +

[fsmrel]

Bonsoir,

Oui, mais là tu triches... Car tu utilise un héritage !!!

Je réfute. J'ai écrit que Rejet est une entité-type faible, relativement à l'entité-type Demande. Si j'en étais passé par l’héritage, j’aurais utilisé la représentation suivante :

Qui signifie qu’un rejet est une demande spécialisée, ce qui est sémantiquement absurde. Mon MCD initial met en jeu le mécanisme de composition au sens UML du terme. Autrement dit, une demande comporte facultativement un rejet.

Si je remplace Demande et Rejet par Guitare et Rosace, je dis qu’une guitare comporte parfois une rosace, dont je peux donner toute description. Il serait absurde en l’occurrence de parler d’héritage, car cela reviendrait à dire qu’une rosace est une guitare.

Si je demande à Power AMC de produire un diagramme de classes à partir de mon MCD initial, il me fournit le résultat suivant, qui correspond bien à une composition :



Alors que si j’avais utilisé l’héritage, il m’aurait fourni le diagramme de classes suivant :


Ce qui n’est quand même pas pareil.

=> Ne pas confondre héritage et composition, car ce genre d’erreur peut inciter à parler à tort de tricherie.

Quod erat demonstrandum.

[Msysteme]

, mais est ce que cela ne va pas me crée des problèmes au niveau developpement ?

[fsmrel]

, mais est ce que cela ne va pas me crée des problèmes au niveau developpement ?

A quel message faites-vous référence ?

[SQLpro]

Au final est tu capablme de distinguer dans le MPD la différence ? Moi pas (mais à mon âge la vue baisse !).

A +

[fsmrel]

Bonjour,

Au final est tu capablme de distinguer dans le MPD la différence ? Moi pas (mais à mon âge la vue baisse !)

Concernant la vue, il faudra consulter un oculiste.

S’il fallait chercher une différence, je le ferais au niveau du MLD, car je ne pense pas que le MPD, c'est-à-dire la quincaillerie (index, buffer pools, méthodes d’accès aux fichiers et toutes ces sortes de choses propres à chaque SGBD) ait à voir avec le sujet.

Quoi qu’il en soit, au niveau conceptuel où l’on doit appréhender les choses d’un point de vue sémantique, on doit être à même de bien percevoir la différence qu’il y a entre avoir et être, c'est-à-dire entre composition et généralisation/spécialisation.

Ainsi, j’ai défendu la thèse selon laquelle un rejet n’est pas une demande. Mais, si ma prime de fin d’année en dépendait (le chef étant très chatouilleux et se piquant en effet de mieux connaître que quiconque des sujets pour lesquels il est incompétent), je défendrais la thèse inverse, à savoir qu’une demande rejetée est une demande et j’aménagerais mon MCD de la façon suivante :



Tout en observant qu’une demande rejetée ne naît pas directement en tant que telle, sinon ça n’est pas la peine d’effectuer la demande. En réalité, une demande naît, puis il s’écoule un laps de temps avant qu’elle puisse faire l’objet d’un rejet, ce qui revient à dire, que dans cet exemple, la généralisation/spécialisation ne se justifie pas sémantiquement parlant et que la modélisation que je viens de proposer est fortement critiquable. Ne confondons pas classification et changement d’état. Ainsi, le chat le chien et la souris sont des animaux mais un chat restera toujours un chat, en vertu de quoi la classification et l’héritage s’imposent dans cet exemple animalier.

En tout cas, quelle que soit l’option de modélisation que j’ai retenue : composition ou généralisation/spécialisation, il est évident que le MLD produit par dérivation sera le même, donc qu’une rétroconception effectuée à l’aide d’un AGL donnera vraisemblablement lieu à un MCD orienté composition, au risque de décevoir celui qui attendait autre chose.

Mais, est-il important au niveau logique de faire la différence et savoir si l’on est en présence, soit d’une composition, soit d’une généralisation/spécialisation ? Vu du Modèle Relationnel de Données, cet aspect sémantique des choses est indifférent. En effet, l’algèbre relationnelle ne comporte pas d’opérateurs en ce sens. Ainsi, quand en 1979, Ted Codd a publié son article Extending the Database Relational Model to Capture More Meaning, il s’est positionné au niveau conceptuel et il a repris en long et en large le thème de la généralisation/spécialisation en s’inspirant des travaux de Smith et Smith. Mais quand dans son ouvrage de 1990 The Relational Model for Database Management: Version 2 il en revient au Modèle Relationnel de Données pur et dur, il n’en souffle pas un mot.

Quoi qu’il en soit, à l’attention de celui qui a modélisé une généralisation/spécialisation au niveau conceptuel, il me paraît nécessaire et suffisant que l’on crée une vue (par exemple Rejet) qui soit la jointure naturelle de la table Demande et de la table Demande_Rejetee.

Ainsi, on pourra :

Accéder aux propriétés qui concernent toutes les demandes (table Demande).
Accéder aux propriétés propres aux demandes rejetées (table Demande_Rejetee).
Accéder à toutes les propriétés concernant les demandes rejetées (vue Rejet).
Insérer des demandes non rejetées (table Demande).
Insérer des demandes rejetées d’office (vue Rejet, et à condition bien sûr que le SGBD soit à niveau, qu'il n’interdise pas les mises à jour des vues de jointure).
Etc.

Le Modèle Relationnel de Données prend bien entendu en compte les concepts de généralisation/spécialisation et d’héritage, qui font l’objet des chapitres 12 à 16 de l’ouvrage de Date et Darwen Databases, Types, and the Relational Model, The Third Manifesto, mais ce sont les types qui sont concernés et non pas les tables. Il s’agit d’un autre sujet.