Bonjour, comment puis je traduire une relation de type 1 ---- 0,1 au niveau d'un schema ms sql server ?
Merci
Version imprimable
Bonjour, comment puis je traduire une relation de type 1 ---- 0,1 au niveau d'un schema ms sql server ?
Merci
Bonjour,
Vous voulez dire dans un MPD SQL Server ou un MCD ?
@++ ;)
Par une double jointure entre les clef primaires de chacune des tables.
Exemple :
Et si HOM est marié à FEM en 1:1 alors :Code:
2
A +Code:
2
3
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é ?
Oui, et il faudra faire une jointure avec les deux colonnes...
A +
Bonjour,
La double clé étrangère engendre un cycle, ce qui n’est jamais à recommander. Je propose une alternative.Citation:
Envoyé par Msysteme
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 :
http://www.fsmwarden.com/developpez/...Rejet)MCD2.jpg
Le MLD généré par l’AGL est le suivant :
http://www.fsmwarden.com/developpez/...Rejet)MLD2.jpg
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:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Diagramme proposé par SQL Server à partir du code ci-dessus :
http://www.fsmwarden.com/developpez/...SQL_Server.jpg
Oui, mais là tu triches... Car tu utilise un héritage !!!
Entre nous c'est quand même la meilleure solution !
A +
Bonsoir,
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 :Citation:
Envoyé par SQLpro
http://www.fsmwarden.com/developpez/...ritage(V0).jpg
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 :
http://www.fsmwarden.com/developpez/..._Rejet)MOO.jpg
Alors que si j’avais utilisé l’héritage, il m’aurait fourni le diagramme de classes suivant :
http://www.fsmwarden.com/developpez/...O_Heritage.jpg
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.
:D, 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 ?Citation:
Envoyé par Msysteme
Au final est tu capablme de distinguer dans le MPD la différence ? Moi pas (mais à mon âge la vue baisse !).
A +
Bonjour,
Concernant la vue, il faudra consulter un oculiste.Citation:
Envoyé par SQLpro
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 :
http://www.fsmwarden.com/developpez/...D_Heritage.jpg
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.