Sono al campo Normalize.
Ecco alcuni suggerimenti per iniziare:
Inizia con un processo di assegnare un certo identificatore univoco arbitrario ad ogni "persona" . Chiama questo il PersonId o qualcosa del genere. Questo identificatore è chiamato una chiave surrogata. L'unico scopo di una chiave surrogata è di garantire una relazione 1 a 1 tra esso e una persona reale nel mondo reale. Utilizzare la chiave surrogata quando si associa il valore di qualche altro attributo a una "persona" nel proprio database .
Man mano che si sviluppa il layout del database, è possibile trovare chiavi surrogate necessarie (o almeno utili) per alcuni altri attributi.
Guarda tutti gli attributi che desideri gestire. Poni la seguente domanda: Qualunque persona ha un solo valore per questo attributo?
Ad esempio, ogni persona ha esattamente una "Data di nascita". Ma come possono "Hobby" avere? Probabilmente zero a molti. Gli attributi a valore singolo (ad esempio data di nascita, altezza, peso, ecc.) Sono candidati per entrare in una tabella comune con PersonId come chiave. Il numero di attributi in ciascuna tabella non dovrebbe essere preoccupante a questo punto.
Gli attributi multivalore come Hobby necessitano di un trattamento leggermente diverso. Potresti voler creare tabelle separate per ogni attributo multivalore. Usando Hobby come esempio potresti creare la seguente tabella PersonHobby(PersonId, Hobby). Una riga in questa tabella potrebbe sembrare qualcosa come: (123, "Stamp Collecting"). In questo modo è possibile registrare il numero di hobby necessario per ogni persona, uno per riga. Fai lo stesso per "Interesse", "Abilità" ecc.
se ci sono un certo numero di attributi multivalore dove la combinazione di PersonId + Hobby determinano niente altro (es. Non avete nulla di interessante per registrare su questa persona a fare questo "hobby" o "Interesse" o "Abilità") potresti raggrupparli in una tabella Valore attributo con una struttura come PersonAV(PersonId, AttributeName, Value). Qui una riga potrebbe essere come: (123, "Hobby", "Stamp Collecting").
Se seguire questa strada, è anche una buona idea per sostituire il AttributeName nella tabella PersonAV per una chiave surrogata e creare un altro tavolo di mettere in relazione questo chiave per la sua descrizione. Qualcosa come: Attribute(AttributeId, AttributeName). Una riga in questa tabella sarà simile a (1, "Hobby") e una riga PersonAV corrispondente potrebbe essere (123, 1, "Stamp Collecting"). Questo è comunemente fatto in modo che se hai mai bisogno di sapere quale AttributeNames sono validi nel tuo database/applicazione hai un posto dove cercarli. Pensate a come si potrebbe convalidare se "interesse" è un valore valido per AttributeName o no - se non si è registrata una certa persona che ha che AttributeName poi c'è alcuna traccia di quel AttributeName sul database - come fai a sapere se dovrebbe esistere o no? Bene, guarda nel tavolo Attribute!
Alcuni attributi possono avere più relazioni e anche questo influenzerà il modo in cui le tabelle vengono normalizzate. Non ho visto nessuna di queste dipendenze nel tuo esempio, quindi considera quanto segue: Supponiamo di avere un magazzino pieno di parti, il PartId determina il suo WeightClass, StockCount e ShipCost. Questo suggerisce una tabella qualcosa come: Part(PartId, WeightClass, StockCount, ShipCost). Tuttavia, se esiste una relazione tra gli attributi non chiave , questi devono essere scomposti. Ad esempio, supponiamo che WeightClass direttamente determini ShipCost. Ciò implica che solo WeightClass è sufficiente per determinare ShipCost e ShipCost deve essere preso in considerazione dalla tabella Part.
La normalizzazione è un'arte piuttosto sottile. È necessario identificare le dipendenze funzionali esistenti tra tutti gli attributi nel modello di dati per eseguirlo correttamente. Solo venire con le dipendenze funzionali prende un bel po 'di pensiero e considerazione - ma è è fondamentale per ottenere il corretto design del database.
Vi invito a dedicare del tempo a alla normalizzazione dello studio un po 'di più prima di costruire il vostro database. Alcuni giorni trascorsi qui, , si ripagheranno più che sulla strada. Prova a fare alcune ricerche su Google/Wikipedia per "Dipendenza funzionale", "Normalizzazione" e "Progettazione database". Leggi, studia, impara, poi costruisci bene.
I suggerimenti che ho fatto riguardo alla normalizzazione della progettazione del database sono solo un suggerimento sulla direzione che potrebbe essere necessario prendere. Senza avere una conoscenza approfondita di tutti i dati che stai cercando di gestire nella tua applicazione, qualsiasi consiglio dato qui dovrebbe essere preso con un "granello di sale".
+1 per la normalizzazione –
I dati verranno utilizzati in un motore di ricerca, per trovare le corrispondenze del profilo. Questo influenza ciò che sto facendo? – Ash
se si sta recuperando da un RDBMS, si prega di normalizzare.Influirà su ciò che stai facendo in modo positivo – Randy