Déja
Il vous a été demandé de développer une base de données de suivi de maintenance sur plusieurs
machines pour un
constructeur de taille moyenne
. La maintenance programmée est simple,
mais lorsque quelque chose ne va pas, une équipe de travailleurs est généralement appelée pour résoudre le
problème.
Maintenance de la
machine ID de la machine : A202 Date d'achat : 23 août 2002
Emplacement : étage C Responsable : Daniel Hugh
Adresse : 22 Castle Street, Luton Département : Fabrication
Date
prévue
Objectif Travailleur Commentaire
2 janv. Vérification de l'huile Peter Wood Fine
5 fév Désalignement Darren Hill Fine
9 fév Réparation de roue Peter Wood Incomplète
Non programmée
Date Problème Travailleur Spécialité Description du correctif
13 janvier Échec de l'instrument John Smith Reporté
Vous devez normaliser la table en
tables relationnelles interconnectées
afin qu'une
base de données puisse être conçue dans Microsoft Access conformément aux tables normalisées.
A) Normaliser le tableau en tableaux relationnels (jusqu'à la 3 e forme normale) ; lister les
attributs dans chaque tableau.
Clotilde
La première forme normale (1NF) définit les règles de base d'une base de données organisée :
* Éliminer les colonnes en double de la même table.
* Créez des tableaux séparés pour chaque groupe de données associées et identifiez chaque ligne avec une colonne unique (la clé primaire).
Que signifient ces règles lorsqu'on envisage la conception pratique d'une base de données ? C'est en fait assez simple.
La première règle dicte que nous ne devons pas dupliquer les données dans la même ligne d'un tableau. Au sein de la communauté des bases de données, ce concept est appelé l'atomicité d'une table. Les tables qui respectent cette règle sont dites atomiques. Explorons ce principe avec un exemple classique - une table dans une base de données de ressources humaines qui stocke la relation gestionnaire-subordonné. Pour les besoins de notre exemple, nous imposerons la règle métier selon laquelle chaque responsable peut avoir un ou plusieurs subordonnés alors que chaque subordonné ne peut avoir qu'un seul responsable.
Intuitivement, lors de la création d'une liste ou d'une feuille de calcul pour suivre ces informations, nous pouvons créer un tableau avec les champs suivants :
* Manager
* Subordinate1
* Subordinate2
* Subordinate3
* Subordinate4
Cependant, rappelons la première règle imposée par 1NF : Éliminer les colonnes en double d'une même table. De toute évidence, les colonnes Subordinate1-Subordinate4 font double emploi. Prenez un moment et réfléchissez aux problèmes soulevés par ce scénario. Si un gestionnaire n'a qu'un seul subordonné - les colonnes Subordinate2-Subordinate4 sont simplement un espace de stockage gaspillé (un précieux produit de base de données). De plus, imaginez le cas où un manager a déjà 4 subordonnés - que se passe-t-il s'il embauche un autre employé ? Toute la structure de la table nécessiterait une modification.
À ce stade, une deuxième idée brillante vient généralement aux novices en bases de données : nous ne voulons pas avoir plus d'une colonne et nous voulons permettre une quantité flexible de stockage de données. Essayons quelque chose comme ceci :
* Manager
* Subordonnés
Lorsque le champ Subordonnés contient plusieurs entrées sous la forme « Mary, Bill, Joe »
Cette solution est plus proche, mais elle est également en deçà de la marque. La colonne des subordonnés est toujours dupliquée et non atomique. Que se passe-t-il lorsque nous devons ajouter ou supprimer un subordonné ? Nous devons lire et écrire tout le contenu de la table. Ce n'est pas grave dans cette situation, mais si un manager avait cent employés ? En outre, cela complique le processus de sélection des données de la base de données dans les futures requêtes.
Voici un tableau qui satisfait à la première règle de 1NF :
* Manager
* Subordonné
Dans ce cas, chaque subordonné a une seule entrée, mais les managers peuvent avoir plusieurs entrées.
Maintenant, qu'en est-il de la deuxième règle : identifiez chaque ligne avec une colonne ou un ensemble de colonnes unique (la clé primaire) ? Vous pouvez consulter le tableau ci-dessus et suggérer l'utilisation de la colonne subordonnée comme clé primaire. En fait, la colonne subordonnée est un bon candidat pour une clé primaire en raison du fait que nos règles métier spécifiaient que chaque subordonné ne pouvait avoir qu'un seul responsable. Cependant, les données que nous avons choisi de stocker dans notre table en font une solution loin d'être idéale. Que se passe-t-il si nous embauchons un autre employé nommé Jim ? Comment stockons-nous sa relation gestionnaire-subordonné dans la base de données ?
Il est préférable d'utiliser un identifiant vraiment unique (comme un identifiant d'employé) comme clé primaire. Notre table finale ressemblerait à ceci :
* ID de gestionnaire
* ID de subordonné
2ème forme normale
Au cours du mois dernier, nous avons examiné plusieurs aspects de la normalisation d'une table de base de données. Tout d'abord, nous avons discuté des principes de base de la normalisation des bases de données. La dernière fois, nous avons exploré les exigences de base imposées par la première forme normale (1NF). Maintenant, continuons notre voyage et couvrons les principes de la deuxième forme normale (2NF).
Rappelez-vous les exigences générales de 2NF :
* Supprimez les sous-ensembles de données qui s'appliquent à plusieurs lignes d'un tableau et placez-les dans des tableaux séparés.
* Créer des relations entre ces nouvelles tables et leurs prédécesseurs grâce à l'utilisation de clés étrangères.
Ces règles peuvent être résumées en un énoncé simple : 2NF tente de réduire la quantité de données redondantes dans une table en les extrayant, en les plaçant dans de nouvelles tables et en créant des relations entre ces tables.
Regardons un exemple. Imaginez une boutique en ligne qui conserve les informations client dans une base de données. Ils peuvent avoir une seule table appelée Customers avec les éléments suivants :
* CustNum
* FirstName
* LastName
* Address
* City
* State
* ZIP
Un bref examen de ce tableau révèle une petite quantité de données redondantes. Nous stockons les entrées "Sea Cliff, NY 11579" et "Miami, FL 33157" deux fois chacune. Maintenant, cela peut ne pas sembler être trop de stockage supplémentaire dans notre exemple simple, mais imaginez l'espace perdu si nous avions des milliers de lignes dans notre table. De plus, si le code postal de Sea Cliff devait changer, nous aurions besoin de faire ce changement à de nombreux endroits dans la base de données.
Dans une structure de base de données conforme 2NF, ces informations redondantes sont extraites et stockées dans une table séparée. Notre nouvelle table (appelons-la ZIPs) pourrait avoir les champs suivants :
* ZIP
* City
* State
Si nous voulons être super efficaces, nous pouvons même remplir ce tableau à l'avance - le bureau de poste fournit un répertoire de tous les codes postaux valides et de leurs relations ville/état. Vous avez sûrement rencontré une situation où ce type de base de données a été utilisé. Une personne prenant une commande peut vous avoir demandé votre code postal d'abord, puis connaître la ville et l'état d'où vous appeliez. Ce type d'agencement réduit les erreurs de l'opérateur et augmente l'efficacité.
Maintenant que nous avons supprimé les données en double de la table Customers, nous avons satisfait à la première règle de la deuxième forme normale. Nous devons toujours utiliser une clé étrangère pour lier les deux tables ensemble. Nous utiliserons le code postal (la clé primaire de la table ZIPs) pour créer cette relation. Voici notre nouvelle table Clients :
*CustNum
* Prénom
* Nom
* Adresse
* ZIP
Nous avons maintenant minimisé la quantité d'informations redondantes stockées dans la base de données et notre structure est en seconde forme normale !
3RD Forme normale
Il y a deux exigences de base pour qu'une base de données soit en troisième forme normale :
* Répond déjà aux exigences de 1NF et 2NF
* Supprimer les colonnes qui ne dépendent pas entièrement de la clé primaire.
Imaginons que nous ayons un tableau de commandes de widgets contenant les attributs suivants :
* Numéro de commande
* Numéro de client
* Prix unitaire
* Quantité
* Total
N'oubliez pas que notre première exigence est que la table doit satisfaire aux exigences de 1NF et 2NF. Y a-t-il des colonnes en double ? Non. Avons-nous une clé primaire ? Oui, le numéro de commande. Par conséquent, nous satisfaisons aux exigences de 1NF. Existe-t-il des sous-ensembles de données qui s'appliquent à plusieurs lignes ? Non, nous satisfaisons donc également aux exigences de 2NF.
Maintenant, toutes les colonnes dépendent-elles entièrement de la clé primaire ? Le numéro de client varie avec le numéro de commande et il ne semble dépendre d'aucun des autres champs. Et le prix unitaire ? Ce champ peut dépendre du numéro de client dans une situation où nous facturons à chaque client un prix fixe. Cependant, en regardant les données ci-dessus, il semble que nous facturons parfois des prix différents au même client. Par conséquent, le prix unitaire dépend entièrement du numéro de commande. La quantité d'articles varie également d'une commande à l'autre, nous sommes donc d'accord.
Qu'en est-il du total ? Il semble que nous pourrions avoir des problèmes ici. Le total peut être obtenu en multipliant le prix unitaire par la quantité, il ne dépend donc pas entièrement de la clé primaire. Il faut le retirer du tableau pour se conformer à la troisième forme normale. Peut-être utilisons-nous les attributs suivants :
* Numéro de commande * Numéro de
client
* Prix unitaire
* Quantité
Maintenant, notre table est en 3NF. Mais, pourriez-vous demander, qu'en est-il du total? Il s'agit d'un champ dérivé et il est préférable de ne pas le stocker du tout dans la base de données. Nous pouvons simplement le calculer "à la volée" lors de l'exécution de requêtes de base de données. Par exemple, nous avons peut-être déjà utilisé cette requête pour récupérer les numéros de commande et les totaux :
SELECT OrderNumber, Total
FROM WidgetOrders
Nous pouvons maintenant utiliser la requête suivante :
SELECT OrderNumber, UnitPrice * Quantity AS Total
FROM WidgetOrders
pour obtenir les mêmes résultats sans enfreindre les règles de normalisation.
Avant de commencer notre discussion sur les formulaires normaux, il est important de souligner qu'il ne s'agit que de lignes directrices et de lignes directrices. Parfois, il devient nécessaire de s'en écarter pour répondre aux exigences commerciales pratiques. Cependant, lorsque des variations ont lieu, il est extrêmement important d'évaluer toutes les ramifications possibles qu'elles pourraient avoir sur votre système et de tenir compte des éventuelles incohérences.