Maison > Article > base de données > Qu'est-ce que le processus de normalisation aborde principalement dans la structure logique de la base de données ?
Le processus de normalisation consiste principalement à surmonter les défauts d'anomalies d'insertion, d'anomalies de suppression et de redondance élevée dans la structure logique de la base de données. La normalisation des bases de données permet aux concepteurs de bases de données de mieux comprendre la structure actuelle des données au sein de l'organisation, ce qui aboutit finalement à une série d'entités de données. La standardisation des bases de données peut réduire efficacement la redondance des bases de données grâce à la conception de tables de base de données.
Processus de normalisation des bases de données
La standardisation des bases de données relationnelles est simplement une question de table de standardisation.
Nécessité de normalisation :
Selon les besoins du projet, nous créerons des tables de base de données correspondantes pour compléter les données dans le projet de stockage. C'est devenu un processus fixe pour réaliser des projets, mais lorsque vous commencerez réellement à répondre aux besoins de votre entreprise, vous vous rendrez compte que les paramètres de votre table sont déraisonnables, ce qui entraîne un stockage répété des données, des exceptions d'insertion, des exceptions de suppression, des exceptions de mise à jour et d'autres problèmes. À ce stade, il est nécessaire de replanifier la table, ce qui représente une perte de temps, de main-d'œuvre et de ressources financières, et est très peu économique. Par conséquent, la normalisation est très nécessaire, je vais donc vous apprendre aujourd'hui comment standardiser la table.
Avant d'enseigner la méthode de base de données normalisée, permettez-moi de vous présenter les connaissances :
Points de connaissance clés dépendance fonctionnelle
peut être un peu difficile à comprendre. Laissez-moi l'expliquer brièvement ici : la dépendance fonctionnelle décrit une relation de mappage entre deux collections. Par exemple, y = x^2, ici pour x, un x correspond à une valeur y, mais il n'existe aucune situation où un x correspond à plusieurs valeurs y, on peut donc dire que la fonction y dépend de x. pour Pour y, il existe une situation où une valeur y correspond à plusieurs valeurs x, donc x ne dépend pas fonctionnellement de y. C'est une dépendance fonctionnelle.
Ensuite, nous introduisons plusieurs dépendances fonctionnelles spéciales :
Dépendance fonctionnelle complète
Définition :
Si X-> ;Y, et pour tout sous-ensemble propre X' de X n'existe pas, X'->Y, alors nous disons que la dépendance fonctionnelle de X->Y est une dépendance fonctionnelle complète.
Une brève explication : Fonction z = x + y, pour z : la fonction z dépend de x et y, mais z ne dépend pas uniquement de x ou y seul, ce qui signifie que la fonction z Cette dépendance de x et y est une dépendance fonctionnelle complète.
Dépendance fonctionnelle partielle :
Définition :
Si X->Y, mais Y ne dépend pas complètement de X, alors cette dépendance s'appelle Pour dépendance totale partielle. C'est-à-dire : la fonction z = x + 0y peut être considérée comme , c'est-à-dire que la fonction z dépend de x et y, mais z dépend uniquement de x, alors c'est une dépendance fonctionnelle partielle.
Dépendance fonctionnelle transitive :
Définition :
Si X->Y, Y -> ; X n'est pas vrai non plus. On dit alors que la fonction de transfert Z dépend de X.
C'est relativement simple. Le groupe de fonctions z = x^2, x = 2y peut être simplifié en z = 4y ^2 C'est facile à voir : z est une fonction qui dépend de x, x dépend. sur y, et z ->x ne tient pas, il s'agit d'une dépendance de fonction de transfert.
Point de connaissance clé deux-----Clé
Clé du candidat : un attribut (champ) ou Un Le groupe d'attributs (plusieurs champs) peut être entièrement déterminé par d'autres attributs (champs) dans le schéma relationnel (table). C'est-à-dire que d'autres attributs (champs) dépendent entièrement de cet attribut (champ) ou groupe d'attributs (champs multiples).
Clé primaire : S'il existe plusieurs clés candidates, sélectionnez-en une comme clé primaire. La valeur de l'attribut ou du groupe d'attributs sélectionné comme clé primaire dans chaque tuple (ligne) du schéma de relation (table) ne peut pas être répétée et la valeur est nulle.
Attributs principaux : Les attributs signalés dans toute clé candidate sont appelés attributs principaux. Si la clé candidate est composée de plusieurs attributs, chaque attribut de ces groupes d'attributs est un attribut principal.
Attributs non principaux : Les attributs qui ne sont inclus dans aucune clé sont appelés attributs non principaux.
Clé étrangère : Un attribut ou un groupe d'attributs n'est pas une clé primaire dans le schéma relationnel actuel (table), mais sert de clé primaire dans un autre schéma relationnel (table), alors le l'attribut ou le groupe d'attributs est appelé Les groupes de propriétés sont des clés étrangères.
Après avoir présenté les points de connaissances de base ci-dessus, commençons à apprendre le processus de standardisation des tables de base de données :
Si vous souhaitez standardiser une table, vous avez d'abord besoin d'une norme pour mesurer si la table a été standardisé. Cette norme est ---- paradigme.
Il existe six formes normales : première forme normale (1NF), deuxième forme normale (2NF), troisième forme normale (3NF), forme normale BC (BCNF), quatrième forme normale (4NF) et cinquième forme normale (5NF). ).
Dans les six paradigmes ci-dessus, dans des circonstances normales, nous devons standardiser la table à BCNF, ce qui est parfait dans les projets réels, il suffit d'atteindre 3NF.
Ce qui suit se concentre sur les quatre premières formes normales :
Première forme normale : tous les attributs du schéma relationnel R sont des éléments de données inséparables.
Pour faire simple, tant que vous pouvez créer un tableau, le tableau satisfait déjà à la première forme normale. Par exemple, la table des étudiants (student_id, course_id, student_name, age, sex, grade, sdept, sdept_director). Dans cette table, il est évident que l'élément de note est déterminé conjointement par student_id, course_id, ces deux éléments doivent donc être combinés. comme clé primaire.
Deuxième forme normale : Sur la base de la satisfaction de la première forme normale, la satisfaction des attributs non primaires dépend entièrement de la clé primaire de R.
Cela nécessite l'utilisation du contenu précédent pour déterminer si les attributs non primaires dépendent complètement de la clé primaire. Si vous n'êtes pas satisfait, ce sera lourd Changez la structure du tableau. Par exemple, la table des étudiants (student_id, course_id, student_name, age, sex, grade, sdept_id, sdept_director) utilise la combinaison de student_id et course_id comme clé primaire, mais pour d'autres attributs tels que le nom, l'âge et le sexe, ils sont complètement dépendants. S'appuient sur l'attribut student_id, ils dépendent donc partiellement de student_id et course_id comme clé primaire. Cela ne répond pas à la définition de la deuxième forme normale, nous devrions donc supprimer la note et diviser ce grand tableau en deux petits tableaux : student(student_id, name, age, sex, sdept_id, sdept_director), student_score(student_id, course_id , grade);
Troisième forme normale : Supprimez les dépendances transitives tout en satisfaisant la deuxième forme normale.
Par exemple : table des étudiants (student_id, student_name, age, sex, sdept, sdept_director). Évidemment, chaque spécialité détermine un directeur professionnel, donc sdept_director dépend transitivement de student_id, il doit donc être divisé en un autre. Les tables student (student_id, student_name, age, sex) et sdept (sdept_id, sdept_name, sdept_director) satisfont à la troisième forme normale.
Paradigme BC : Pour satisfaire au troisième paradigme, trois points supplémentaires doivent être remplis :
1 Tous les attributs principaux dépendent complètement des autres Contient les siens. clé candidate ;
2. Tous les attributs non principaux dépendent entièrement de chaque clé candidate
3. attribut principal.
Les trois paradigmes précédents imposent tous diverses contraintes sur les attributs non primaires. Le paradigme BC est basé sur eux et contraint ensuite les attributs principaux pour résoudre le problème de dépendance partielle entre les attributs principaux, et là. Il n'y a aucun problème si l'attribut principal dépend entièrement de l'attribut non principal. Notre table étudiant student (student_id, student_name, age, sex), la clé primaire est student_id, donc l'attribut principal est student_id. Évidemment, les deux premiers sont satisfaits, car le nom de l'étudiant peut être répété, il n'y a donc pas de dépendance fonctionnelle entre student_id. et la relation student_name, de sorte que la table student satisfait à la forme normale de BC.
Ce qui précède est le processus de normalisation de la base de données
Recommandations associées : "Tutoriel mysql"
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!