Normalisation en anglais clair

Question

Je sorte de comprendre le concept de normalisation de base de données, mais a toujours du mal à expliquer dans un anglais courant - surtout pour une entrevue d'emploi. J'ai lu le wikipedia de poste, mais toujours trouver qu'il est difficile d'expliquer le concept de non-développeurs. "Conception d'une base de données de façon à ne pas obtenir les données dupliquées" est la première chose qui vient à l'esprit.

Est-ce quelqu'un a une belle façon d'expliquer le concept de normalisation de base de données en anglais? Et ce sont quelques bons exemples pour montrer les différences entre les première, deuxième et troisième formes normales?

Dire que vous allez à un entretien d'embauche et la personne demande: Expliquer le concept de normalisation et comment aller sur la conception d'une base de données normalisée.

Quels sont les principaux points sont les enquêteurs à la recherche?

Answer 1

Eh bien, si je devais l'expliquer à ma femme qu'il aurait été quelque chose comme ça:

L'idée principale est d'éviter la duplication de grandes quantités de données.

Jetons un coup d'oeil à une liste de personnes et le pays de provenance. Au lieu de mettre le nom du pays qui peut être aussi longue que "la Bosnie-Herzégovine" pour chaque personne, nous avons simplement détenir un numéro qui fait référence à une table de pays. Donc, au lieu de tenir les 100 "Bosnie-Herzégovine"s, nous détenons 100 #45. Maintenant, dans l'avenir, comme il arrive souvent avec les pays des Balkans occidentaux, ils se sont séparés dans deux pays: la Bosnie-Herzégovine, je vais devoir le changer dans un seul endroit. eh bien, en quelque sorte.

Maintenant, pour expliquer 2FN, j'aurais changé l'exemple, et supposons que nous tenons la liste de pays chaque personne visitée. Au lieu de la tenue d'une table:

Person   CountryVisited   AnotherInformation   D.O.B.
Faruz    USA              Blah Blah            1/1/2000
Faruz    Canada           Blah Blah            1/1/2000

J'aurais créé trois tables, une table avec la liste des pays, un tableau avec la liste des personnes et une autre table pour les connecter à la fois. Qui me donne le plus de liberté que je peux obtenir de l'évolution de la personne des renseignements ou des informations sur le pays. Cela me permet de "supprimer les doublons", puisque la normalisation attend.

Answer 2

Un-à-plusieurs relations devraient être représentés comme deux tableaux distincts reliés par une clé étrangère. Si vous essayez de pousser la logique à plusieurs relations dans un seul tableau, alors vous êtes en violation de normalisation qui conduit à des problèmes.

Disons que vous avez une base de données de vos amis et de leurs chats. Étant donné qu'une personne peut avoir plus d'un chat, nous avons un un-à-plusieurs relations entre les personnes et les chats. Ceci appelle deux tables:

Friends
Id | Name | Address
-------------------------
1  | John | The Road 1
2  | Bob  | The Belltower


Cats
Id | Name   | OwnerId 
---------------------
1  | Kitty  | 1
2  | Edgar  | 2
3  | Howard | 2

(Cats.OwnerId est une clé étrangère vers Friends.Id)

La conception ci-dessus est entièrement normalisée et est conforme à toutes connu la normalisation des niveaux.

Mais dire que j'ai essayé de représenter les informations ci-dessus dans une seule table comme ceci:

Friends and cats
Id | Name | Address       | CatName
-----------------------------------
1  | John | The Road 1    | Kitty     
2  | Bob  | The Belltower | Edgar  
3  | Bob  | The Belltower | Howard 

(C'est le genre de design que j'ai pu faire si j'avais l'habitude d'Excel-feuilles, mais pas de bases de données relationnelles.) Une table unique approche qui m'oblige à répéter certaines informations si je veux que les données soient cohérentes. Le problème avec ce modèle est que certains faits, comme les informations que Bob l'adresse est "Le clocher" est répété deux fois, ce qui est redondant, et il est difficile d'interroger et de modifier les données et (le pire) possible d'introduire des incohérences logiques.

Par exemple. si Bob se déplace, je dois m'assurer de changer l'adresse dans les deux lignes. Si Bob obtient un autre chat, je dois être sûr de répéter le nom et l'adresse exactement comme tapé dans les deux autres lignes. E. g. si je fais une faute de frappe dans Bob l'adresse dans l'une des lignes, du coup la base de données comporte des informations incohérentes sur l'endroit où Bob vie. L'onu-base de données normalisée ne peut pas empêcher l'introduction de incohérentes et contradictoires de données, et donc de la base de données n'est pas fiable. Ce n'est clairement pas acceptable.

La normalisation ne peut pas vous empêcher de saisir des données erronées. Ce que la normalisation empêche, c'est la possibilité de incohérent de données.

Il est important de noter que la normalisation dépend des décisions d'affaires. Si vous avez une base de données de clients, et que vous décidez d'enregistrer uniquement une seule adresse par le client, la conception de la table (#CustomerID, CustomerName, CustomerAddress) est fine. Si toutefois, vous décidez de permettre à chaque client de s'inscrire plus d'une adresse, puis la même conception de table n'est pas normalisée, car vous avez maintenant un un-à-plusieurs relation entre le client et l'adresse. Par conséquent, vous ne pouvez pas il suffit de regarder une base de données afin de déterminer si elle est normalisée, vous devez comprendre le modèle d'affaires derrière la base de données.

Answer 3

Voici ce que je demande aux personnes interrogées:

Pourquoi n'utilisons-nous pas une seule table pour une application plutôt que d'utiliser plusieurs tables?

La réponse est bien sûr la normalisation. Comme déjà dit, c'est pour éviter la redondance et il y a des anomalies de mise à jour.

Answer 4

Ce n'est pas une explication approfondie, mais un but de la normalisation est de permettre la croissance sans maladresse.

Par exemple, si vous avez un user tableau, et chaque utilisateur va avoir un et un seul numéro de téléphone, c'est bien d'avoir un phonenumber colonne dans la table.

Toutefois, si chaque utilisateur va avoir un nombre variable de numéros de téléphone, il serait maladroit d'avoir des colonnes, comme phonenumber1, phonenumber2, etc. C'est pour deux raisons:

• Si vos colonnes aller jusqu'à phonenumber3 et quelqu'un a besoin d'ajouter un quatrième numéro, vous devez ajouter une colonne à la table.
• Pour tous les utilisateurs avec moins de 3 numéros de téléphone, il y a des colonnes vides sur leurs lignes.

Au lieu de cela, vous voulez avoir un phonenumber tableau, où chaque ligne contient un numéro de téléphone et une référence de clé étrangère à la ligne dans l' user table à laquelle il appartient. Pas de colonnes vides sont nécessaires, et chaque utilisateur peut avoir aussi peu ou beaucoup de numéros de téléphone nécessaires.

Answer 5

D'un côté point à noter à propos de la normalisation: Une entièrement normalisée de la base de données est l'espace efficace, mais n'est pas nécessairement la plupart du temps efficace de l'organisation des données selon les modes d'utilisation.

Sauter autour de plusieurs tables pour rechercher tous les morceaux de l'info de leur dénormalisée endroits prend du temps. Dans les situations de charges importantes (plusieurs millions de lignes par seconde qui volent autour, des milliers de clients simultanés, comme, disons, la carte de crédit de traitement des transactions) où le temps est plus précieux que l'espace de stockage, de manière appropriée dénormalisée tables peuvent donner un meilleur temps de réponse que les tables normalisées.

Pour plus d'info sur ce, cherchez la documentation de SQL écrit par Ken Henderson.