Déterminer les clés à partir de dépendances fonctionnelles
Je suis un cours théorique sur les bases de données, et après avoir lu, je ne sais pas bien comment en déduire des clés, étant donné un ensemble de dépendances fonctionnelles.
J'ai un exemple de problème:
Trouver toutes les clés de la relation R(ABCDEFG) avec les dépendances fonctionnelles
AB → C
CD → E
EF → G
FG → E
DE → C
BC → A
Démontrez vos connaissances en identifiant laquelle des clés suivantes est une clé.
a. BCDEF
b. ADFG
c. BDFG
d. BCDE
Quelqu'un peut-il m'expliquer comment décomposer les dépendances fonctionnelles pour conclure qu'une combinaison d'attributs est une clé? Je m'attends à ce que je sois confronté à un certain nombre de problèmes de ce type et j'ai besoin de comprendre comment l'aborder.
Prenez un FD, par exemple AB → C
Augmentez jusqu'à ce que tous les attributs soient mentionnés, par exemple. ABDEFG → CDEFG (notez que cela équivaut à ABDEFG → ABCDEFG car il est trivialement vrai que A-> A et B-> B).
Cela vous dit qu'ABDEFG est une super clé.
Vérifiez les autres FD dans lesquelles le LHS est un sous-ensemble de votre super-clé, et celui sur son RHS contient un autre attribut de votre super-clé.
Il y en a deux. EF → G et FG → E. Supprimez les attributs de la RHS de ceux-ci de votre super clé. Cela vous donne deux clés, qui sont certes des superkeys, mais pas nécessairement irréductibles: ABDEF et ABDFG.
Cependant, AB → C et CD → E permettent également de déduire que ABD → E. Par conséquent, nous pouvons également supprimer le E de notre clé ABDEF. Ce qui est désagréable, c’est que, lorsque j’ai dit «Vérifier les autres FD», cela signifie apparemment que vous devriez également vérifier toute FD qui apparaît dans la fermeture de votre ensemble de FD (c’est-à-dire tout FD pouvant être dérivé de votre ensemble de FD). ... Et c'est un peu peu pratique de le faire à la main ...
Un site utile pour vérifier si vos résultats sont corrects:
http://www.koffeinhaltig.com/fds/ueberdeckung.php
Vous devriez maintenant pouvoir déterminer que l'option c est une clé.
METTRE À JOUR
lien est maintenant brisé, aucune idée où le site a disparu. Peut-être pouvez-vous encore trouver quelque chose d’utile sur des sites qui gardent une trace de l’histoire d’Internet.
Cette vidéo l'explique très bien
Eh bien, cela devrait être assez simple. Tout ce que vous avez à faire est de prendre la fermeture de chaque clé donnée et de voir si elle contient tous les attributs de R. Par exemple, la fermeture de BCDEF = ABCDEFG puisque BC -> A et BC est un sous-ensemble de BCDEF et ainsi, si EF pour FD EF -> G. Comme cette fermeture contient tous les attributs de R, BCDEF est la clé. Le but principal des fermetures est de voir si nous pouvons "atteindre" chaque attribut à partir d'un ensemble d'attributs donné. La fermeture est l'ensemble des attributs que nous pouvons réellement atteindre en naviguant dans les FD.
Étant donné que vous suivez un cours théorique sur la base de données, je suppose que vous avez une expérience de SQL et que vous essayez de relier la théorie au contexte de mise en œuvre.
Fondamentalement, une relation est ce que vous appelleriez une table dans l'implémentation et une clé est TOUT ensemble d'attributs (colonnes de lecture) pouvant être utilisé pour identifier une ligne UNIQUE (dans la théorie de la base de données, il s'agirait d'un tuple). L'analogie la plus simple ici est qu'une clé est votre clé primaire, ainsi que tout autre ensemble de colonnes que vous pouvez utiliser pour identifier un seul Tuple dans votre relation (ligne dans votre table). Donc, voici les étapes de base pour le faire (je vais passer à l’exemple A et vous pourrez essayer le reste):
- Répertoriez tous les attributs qui ne sont PAS dans la clé proposée (donc BCDEF n’inclut pas A et G).
Pour chaque attribut manquant, parcourez la liste des dépendances fonctionnelles et voyez si la clé proposée est capable de déduire l'attribut manquant.
a. So for A, you have BC -> A. Since both B and C are in the proposed key BCDEF, you can infer that BCDEF -> A. Your set now becomes BCDEFA. b. For G, again going through your FDs you find EF -> G. Since both E and F are in BCDEFA, you can infer BCDEFA -> G.
Comme vous avez pu déduire A et G de BCDEF, l'option a est une clé de la relation ABCDEFG. Je sais qu'il existe un algorithme pour cela, et c'est probablement dans votre texte de cours quelque part. Il y a aussi probablement un exemple. Vous devriez le parcourir manuellement jusqu'à ce que le motif soit intuitif.
EDIT: La raison pour laquelle je reviens dans le texte à la recherche de cet algorithme est qu’il est probable que votre examen sera rédigé plutôt que par choix multiple, car il s’agit d’un cours théorique. Si cela est vrai, vous obtiendrez un crédit plus partiel si vous pouvez suivre méthodiquement la notation indiquée dans le texte/les notes de votre cours.
L'objectif principal est de transformer la clé en relation, ce qui devrait prouver que la clé proposée est en fait une clé.
eh bien, je ne suis pas un expert en la matière, alors corrigez-moi si je me trompe, mais mon approche serait d'éliminer les réponses impossibles
dans ce cas:
aucun de vos FD ne vous "donne" B, D ou F ... puisque ceux-ci font partie de la relation, il ne peut y avoir de super clé qui ne contient pas B, D et F ... supprimez la réponse b (B est manquant). .. supprimer la réponse d (F est manquant)
vérifions maintenant les réponses restantes si elles contiennent suffisamment d’informations pour obtenir toutes les parties de la relation
answer a (BCDEF) vous "donnera" B, C, D, E et F pour que vous ayez besoin de trouver A et G en utilisant les FD ... A peut être atteint par BC et G par EF, alors répondez a est une clé
la réponse c (BDFG) vous "donnera" B, D, F et G, vous devez donc rechercher A, C et E à l’aide des FD ... E peut être atteint par FG ... C peut être atteint par DE (après atteindre E par FG) ... et enfin A peut être atteint par BC (après avoir atteint C) ...
donc la réponse c est une sorte de clé puisque toute la relation peut être accédée de cette façon ... mais je ne sais pas si cela suffit pour correspondre à la définition formelle ... si je devais deviner, je dirais non
Code
Si le code vous parle plus que de longues explications, voici une implémentation de 25 lignes d'un algorithme qui recherche les clés en fonction de dépendances fonctionnelles:
https://github.com/lovasoa/find-candidate-keys/blob/master/find-candidate-keys.js
Exemple
candidate_keys(["A","B","C","D","E","F","G"], [
[['A','B'], 'C'],
[['C','D'], 'E'],
[['E','F'], 'G'],
[['F','G'], 'E'],
[['D','E'], 'C'],
[['B','C'], 'A']
])
renvoie [["B","D","F","G"],["B","D","E","F"],["B","C","D","F"],["A","B","D","F"]]