Normalisation des tables SQL vs dénormalisation

Question

J'utilise MS SQL Server 2012. J'ai deux tables, une pour les médecins et une autre pour les centres de chirurgie. Chaque table contient actuellement des colonnes qui décrivent comment ils (les médecins et les centres de chirurgie) devraient recevoir des rapports (email, fax ...) Les colonnes qui contiennent ces données dans les deux tableaux sont identiques. Je pense à tirer les colonnes de la méthode de livraison de chaque table et de faire une table de méthode de livraison commune, mais je devrais avoir des clés étrangères pour le médecin et le centre de chirurgie dans chaque rangée. Ceci est gênant car il existe une relation un à un entre la méthode de livraison et les médecins. Cette même relation existe pour la table du centre de chirurgie.

Question:

1. Est-il bon d'avoir une table avec deux clés étrangères et l'un d'entre eux serait toujours nulle?
2. Quelle est la meilleure stratégie pour gérer un tel cas.

La raison pour laquelle je souhaite extraire les informations de la méthode de livraison des tables des médecins et des centres de chirurgie est de réduire la taille globale des tables. Aussi, cela permettra de mieux normaliser mes données. J'apprécie toute l'aide et l'orientation.

Answer 1

Vous avez la relation qui va de la méthode de livraison aux dr/centres, plutôt que du dr/centre à la méthode de livraison.

Si vous inversez la relation, non seulement vous éliminez le besoin d'avoir une table avec une colonne potentiellement unsed, vous pouvez partager des méthodes de livraison parmi plusieurs drs et centres.Vous dites qu'il y a une relation 1 à 1, mais s'il n'y a pas de règle métier empêchant un dr ou un centre d'avoir la même méthode de livraison que n'importe quel autre dr ou cent, alors ce que vous avez est une relation de plusieurs à un (beaucoup de dr/centres peuvent avoir la même méthode de livraison) même si dans la pratique c'est unique.

Answer 2

Une option est d'avoir deux tables intermédiaires qui relient les PKs de DeliveryMethod table pour Doctors et SurgeryCenter tables, de sorte que, par exemple, DoctorDeliveryMethod a deux colonnes: Doctor.id et DeliveryMethod.id.

Cela vous oblige à joindre trois tables pour obtenir les méthodes pour chacun d'eux. Une autre consiste à lier le DeliveryMethod.id à une colonne dans le tableau Doctor, appelez-le DeliveryMethodID. Vous devrez faire la comptabilité de toute façon

Answer 3

Une idée est d'avoir une seule table DeliveryMethod. Chaque enregistrement de ce tableau aura un identifiant (probablement substitut - par exemple identité ou séquence). Ensuite, la table Doctor aura une clé étrangère DeliveryMethodID, et de même la table SurgeryCenter aura une clé étrangère DeliveryMethodID.

Dans une conception de base de données typique, vous ne voulez pas deux tables identiques. Si la taille de la table devient un problème, il existe différentes approches pour y remédier, y compris la création d'un partitioned table.

Answer 4

Une autre conception possible est la suivante:

• Tableau '': DeliveryMethods colonnes ID (PK), Fax_number, email_address, préférés, ...
• Table '': SurgeryCentres colonnes SC_ID (PK), nom, ..., DeliveryMethodID (FK référencement DeliveryMethods), ...
• table 'Médecins': colonnes MD_ID (PK), nom, ..., DeliveryMethodID (FK référencement DeliveryMethods), ...

Cela évite les zéros mais vous donne des données normalisées.