déterminant étrangers, clés primaires, 1nf, 2nf, 3nf table donnée et les dépendances fonctionnelles

Question

d'abord et avant tout je voudrais dire que c'est pour un devoir de devoir passé que je ne pouvais pas comprendre et suis venu ici pour demander des éclaircissements. J'ai des problèmes avec la normalisation pour cette question spécifique.

données

1.PetStore(storeBranchName, storeAddr, storeManager,(customerName, customerAddr, customerPhone,(petName, petBreed, petSex, price))) 

FDs

storeBranchName → storeAddr, storeManager 
customerName → customerAddr, customerPhone 
customerName, petName → petBreed, petSex 
customerName,storeBranchName → petName 
petBreed → price 

a. Cette relation est-elle en 1NF? Si non, pourquoi n'est-ce pas? Ensuite, mettez-le en 1NF.

b. Cette relation est-elle en 2NF? Si non, pourquoi n'est-ce pas? Ensuite, mettez-le en 2NF.

c. Cette relation est-elle en 3NF? Si non, pourquoi n'est-ce pas? Ensuite, mettez-le en 3NF.

d. identifiez les clés primaires (souligné) et les clés étrangères (italique) pour la relation.

Ma question est maintenant comment puis-je déterminer de quelle forme il s'agit? ma tentative de solution.

a. la table est pas 1FN parce que chaque valeur est à la valeur atomique

1FN

PetStore(storeBranchName, storeAddr, storeManager,customerName, customerAddr, customerPhone,petName, petBreed, petSex, price) 

**** est ici où je commence à avoir des problèmes ****

b. la relation ne peut pas être en 2NF parce qu'il n'a pas été dans 1FN

2FN

store(storeBranchName, storeAddr, storeManager) 
customer(customerName, customerAddr, customerPhone) 
pet(petName,petbreed,petsex) 

c.?

3NF

store(storeBranchName, storeAddr, storeManager) 
customer(customerName, customerAddr, customerPhone) 
pet(petName, petBreed, petSex) 
petCust(customerName,storeBranchName, petName) 
petPrice(petBreed, price) 

d. J'ai vraiment du mal à décider ce que les clés primaires seraient ici et ne comprennent pas vraiment le cocnept des clés étrangères. Si quelqu'un peut me donner des indices ou des indices, je préfère vraiment ne pas recevoir une réponse directe à moins que ce soit en corrigeant quelque chose que j'ai peut-être mal fait. Toute aide serait appréciée.

Answer 1

L'affectation n'est pas bien structurée. Les questions a, b et c se réfèrent à "cette relation", et si elle est interprétée comme se référant à la relation donnée originale, la réponse à b et c commencera par "parce que ce n'est pas dans 1NF". Ce serait un meilleur test de la compréhension d'un étudiant si b et c se référaient à la réponse à la question précédente. De plus, la question d devrait être appliquée à chaque étape.

Je questionne aussi le FD donné customerName,storeBranchName → petName. Cela choque le bon sens (un client ne peut acheter qu'un animal de compagnie par magasin), et si c'était le cas, la relation imbriquée originale n'aurait pas besoin d'être nichée (petName, petBreed, petSex, price). Peut-être l'a-t-on ajouté à une question existante pour la compliquer.

Votre réponse à a est correcte, mais j'aimerais voir les attributs set-, tuple- ou relationship-valued identifiés dans la relation d'origine, ou une mention des «groupes récurrents» traditionnels. Comme je l'ai dit plus haut, j'aimerais aussi voir les clés identifiées à chaque étape. À partir des FD donnés, nous pouvons déterminer que customerName,storeBranchName est une clé candidate pour la relation 1NF - démontrer cela en dérivant la fermeture des FD pour cet ensemble d'attributs.

Pour la question b, expliquez pourquoi votre réponse à la question a n'est pas dans 2NF en démontrant une dépendance partielle. Vos relations 2NF ne découlent pas de la normalisation de la réponse 1NF. Vous devriez avoir 3 relations, entrées par customerName, storeBranchName et customerName,storeBranchName respectivement.

Pour la question c, expliquez pourquoi la réponse à la question b n'est pas dans 3NF en démontrant une dépendance transitive. Vos relations 3NF ne découlent pas de votre réponse 2NF, mais elles sont proches de la bonne réponse. La relation d'animal de compagnie correcte est pet (customerName PK, petName PK, petBreed, petSex).

Les clés primaires doivent être conservées/dérivées par le processus de normalisation, et non "décidées" après le fait. Vous avez seulement besoin d'identifier une clé primaire une fois, pour 1NF, les autres devraient suivre la normalisation.

Le concept de clés étrangères signifie différentes choses dans le modèle relationnel et l'ancien modèle de réseau. Dans le modèle relationnel, une contrainte de clé étrangère est juste une contrainte d'intégrité de sous-ensemble, par ex. petCust.customerName ⊆ customer.customerName. Dans le modèle de réseau, il représente une relation entre petCust et customer enregistrements. Je recommande d'étudier et de comparer les deux modèles.

Espérons que cela aide, n'hésitez pas à poser des questions dans les commentaires.