Lors de la mise en correspondance d'un diagramme ER avec un schéma relationnel, mon manuel indique qu'à l'étape .. quelle que soit .. une nouvelle relation S doit être créée pour les attributs multivalués. Mais si l'attribut multivalué est la clé primaire de R ... qui laisse le R sans clé primaire et S sans clé primaire?Mappage ER-to-relationnel: clé primaire multi-valu
Ceci est une excellente question et quelque chose qui m'a toujours dérangé au sujet des explications de manuel sur la façon d'éliminer les types "complexes".
La question que vous devez vous poser est: Qu'est-ce qui est identifié par les ensembles de valeurs? Qu'essayez-vous de modéliser? La plupart des architectes de bases de données travaillant avec SQL diraient probablement que vous devriez inventer un nouvel attribut pour identifier les ensembles de choses qui auraient constitué votre attribut à valeurs multiples. Une autre solution consiste à inclure les types "complexes" en tant qu'attributs de première classe - non des attributs "multivalués" mais des ensembles ou des tableaux qui peuvent être affectés à une variable comme une valeur unique comme n'importe quelle autre valeur. Le langage Tutorial D permet des relations relationnelles avec des types relationnels. par exemple:
VAR r BASE RELATION {foo RELATION {bar INTEGER} } KEY {foo};
où foo est une relvar imbriquée dans r. SQL ne supporte cependant rien de ce genre. Les tables imbriquées sont prises en charge dans SQL, mais ne sont généralement pas autorisées à faire partie des clés. Dans SQL, vous devez donc toujours créer un nouvel attribut d'identification. Dans un vrai SGBDR, vous ne devriez sans doute pas avoir à créer un autre attribut car tout type supporté devrait supporter de faire partie d'une clé - si ce n'était pas le cas, vous ne seriez même pas capable de projeter sur cet attribut car le résultat ne le serait pas t contient une clé.