J'essaie de comprendre ce que BCNF est et j'ai une relation comme celle-ci:
étudiant (ID, SSN, email, nom, nom de famille) où < / p> Y a-t-il quelque chose qui enfreint la BCNF et si oui, comment puis-je remédier à cette situation avec un meilleur design? EDIT J'essaie d'écrire mes dépendances fonctionnelles, mais veuillez me corriger si je me trompe côté des équations. Il semble que cette relation ne soit pas dans BCNF, mais il doit y avoir quelque chose de problème :)
3 Réponses :
Le moyen de répondre correctement à votre question est d'identifier les dépendances fonctionnelles censées s'appliquer. Écrivez ce que vous pensez que les dépendances sont. Si le côté gauche de chaque dépendance non triviale est un surcharge, la relation satisfait BCNF.
Oui, votre table est en BCNF. En effet, vous n'avez pas de clés candidats qui se chevauchent - c'est-à-dire, il n'y a pas d'attributs qui apparaissent dans deux clés différentes.
Si vous avez eu un autre attribut, X, qui faisait partie des clés - par exemple. (SSN, X) et (e-mail, x) - Ensuite, votre table échouerait BCNF car X devrait être identique à une paire de SSN et de courriel donnée. Ces définitions clés permettraient différentes valeurs de x pour le SSN et les courriels donnés.
Pour une bonne explication de BCNF, lisez cette réponse .
Si l'ensemble de dépendances de Sedran est terminé, alors oui. Mais en règle générale, l'absence de touches superposées ne signifie pas automatiquement une relation de BCNF. S'il y avait des dépendances non clés ou des dépendances clés partielles, cela ne satisferait pas à BCNF.
@sqlvogel - Je ne peux pas penser à la façon dont vous pouvez ne pas être en BCNF s'il n'y a pas de clés superposées. Pourriez-vous me montrer un exemple s'il vous plaît?
Par exemple. La dépendance A-> B où A et B sont non physiques seraient une violation de la BCNF (et 3NF) quelles que soient les clés candidates.
@sqlvogel - Je vois ce que tu veux dire maintenant. Je pensais à avoir déjà rencontré 3NF. Est-il correct de dire que si une conception se réunit 3NF, il doit y avoir des clés qui se chevauchent pour empêcher sa satisfaction de BCNF?
Les contraintes de courrier électronique ou SSN étant unique ou nulable sont trop fortes. Vous pouvez les exécuter, mais vous ne devez pas les imposer . (Pensez: étudiants étrangers.)
En règle générale, il est une mauvaise idée d'imposer des contraintes sur les principaux domaines qui ne sont pas sous votre juridiction, même s'ils sont proches d'uniques (comme dans le cas SSN).
Par exemple: la typographie. Supposons que certaines personnes veuillent s'engager en tant qu'étudiant, mais il semble que sa SSN soit déjà utilisée par une autre personne, probablement causée par une faute de frappe. Devez-vous refuser le nouvel élève ou supprimer l'ancien? (Ou si vous autorisez le champ SSN à être non unique ou nullable?)
mise à jour / finale Remarque: cette rubrique est marquée "DaTatBase-Design" et "Normalisation des données". J'ai réagi sur les choix de conception (qui sont discutables). D'autres ont tenté de réagir sur les aspects BCNF (qui sont triviaux, compte tenu des clés candidates uniques et de l'hypothèse non nulle)
Normaliser un modèle de données Bad Data vous donnera un modèle normalisé mais toujours tout faux.
La sagesse ou autrement de choisir certaines clés particulières n'a rien à voir avec la question de normalisation, car les clés sont déjà données. C'est sûrement pas une mauvaise idée d'exiger que les étudiants aient une adresse électronique unique et une carte d'impôt unique de quelque nature que ce soit. Beaucoup de systèmes du monde réel do nécessitent des adresses électroniques uniques comme identifiants car elles sont facilement mémorisées, vérifiées et relativement stables. Et si une duplication SSN vient alors, il est parfaitement raisonnable de ne pas le permettre et de demander à quelqu'un de vérifier lequel de ces doublons pourrait être erroné ou invalide.
L'OP est un exemple de jouet, et c'est IMHO A BAD exemple de jouet, car cela fait des hypothèses implicites sur les domaines "étrangers". Pour de vrais-exemples de jouets, l'enseignant doit utiliser de vrais problèmes de jouets (tels que Sudoku, Scrabble ou Mots-puis croisés)
HMMM, allez dire à Amazon ou à Microsoft que le fait qu'ils nécessitent des adresses électroniques uniques pour leurs systèmes en font un "jouet"! Je pense que vous êtes celui qui fait des hypothèses sur un problème qui définit un exemple parfaitement réaliste dans la théorie de la normalisation.
Amazon et Microsoft sont des entreprises commerciales, qui peuvent imposer des restrictions à leurs clients (ou les refuser). Un gouvernement, une école ou une université ne peut rien imposer, ils devraient modéliser et décrire la réalité. En tant que bizarre exemple: polygamie; Si un polygamiste est naturalisé à une certaine nationalité occidentale, comment être enregistré ses mariages? Ou devrait-il être dévocé N-1 fois pour être entré dans le système ?
Certes, ils devraient modéliser et décrire la réalité. Et si la réalité est que chaque élève est soit alloué une adresse électronique unique ou peut utiliser l'une des leurs deux, c'est la réalité de la base de données. Il est très courant que toutes sortes d'organisations exigent que les utilisateurs disposent d'adresses électroniques uniques pour l'accès aux systèmes et services internes. Plusieurs institutions gouvernementales et publics que j'ai des relations avec l'exigent. Je suis très surpris si vous n'en avez pas au courant.
Je suis très bien conscient de cela. Mais le fait que les gens rendent souvent cela (imho faux, évidemment) la décision de conception n'implique pas que le modèle choisi est correct. (À titre d'exemple: beaucoup d'administration néerlandaise supposait faussement que chaque personne a un a-nummer ou au moins un BSN (efficacement un SSN), causant des personnes sans ces Nombres (étrangers plus des personnes des Antilles néerlandaises) ne sont pas entrées dans le système , avec en conséquence plusieurs administrations shadows à coexister. Tous causés par une faille de conception fondamentale ...)
Frame de conception ou non, il n'a rien à voir avec la normalisation, qui était la question posée. Avait la question de la normalisation d'une base de données sur les raisins et les régions viticoles, diriez-vous de quelque chose sur le vin français ou non mieux que l'italien? Bien sûr, il s'agit d'une "faille de conception" si un système applique un caractère unique de quelque chose qui n'est pas ou n'appelle la présence de quelque chose qui n'est pas. Pas la question posée.