Notez que dans les données, la valeur SocialIN 987 cartes à la fois "Giroux, Jill" et "Williams, Tot", de sorte que le SocialIN ⟶ EmpName FD est incorrect si les données sont correctes. En fait, je pense que les données de la table/image sont erronées. Très probablement, il y a une erreur et Jill et Tot doivent avoir différentes valeurs de SocialIN. Et puis, en tant que Mike Sherrill 'Cat Recall'suggested, le {SocialIN, ProjectID} ⟶ Heures FD devrait tenir. Cependant, en supposant que les données sont correctes, le FD EmpName ⟶ SocialIN est valide (plutôt que le reverse FD), et le FD {EmpName, ProjectID} ⟶ Hours est valide.
Non seulement FD ProjectID ⟶ ProjectName contient-il les données, mais ProjectName ⟶ ProjectID est également conservé dans les données affichées. Compte tenu de cela, ProjectName ⟶ Location contient également, ainsi que {EmpName, ProjectName} ⟶ Hours.
Il existe également plusieurs FD triviaux qui ne valent pas la peine d'être signalés (comme EmpName ⟶ EmpName).
Par conséquent, je pense que l'ensemble des IFD non triviales dans les données fournies est:
- EmpName ⟶ SocialIN
- ProjectID ⟶ ProjectName
- ProjectID ⟶ Lieu
- ProjectName ⟶ ProjectID
- ProjectName ⟶ Emplacement
- {EmpName, ProjectName} ⟶ Heures
- {EmpName, ProjectID} ⟶ Heures
Si le mappage de Gill et Tot est incorrect et ils ont des valeurs SocialIN séparées, vous pouvez ajouter:
- SocialIN ⟶ EmpName
- {SocialIN , ProjectName} ⟶ Heures
- {SocialIN, projectID} ⟶ Heures
SocialIN, projectID -> Heures? –
Évidemment non! 987, 30 -> 5; 987, 30 -> 20 donc la contradiction ici –
Y at-il une faute de frappe dans les données? SocialIN 987 vous donne à la fois 'Giroux, Jill' et 'Williams, Tot'. Si les données sont correctes, alors SocialIN-> EmpName est faux. –