Salve a tutti.
Il mio problema è sostanzialmente quello di non riuscire a decifrare, tra le mille fonti consultabili sul web, un algoritmo che permetta di normalizzare ogni database possibile.

So bene che probabilmente la mia domanda è fuori luogo, perchè ogni situazione da schematizzare con un database è a sè, è un caso a parte.

Ho provato tuttavia a fare questa richiesta perchè con uguale probabilità, credo esista una procedura standard da applicare a tutti i casi, per evitare confusioni a livello logico.

Provo a entrare di più nel merito, confidando nella vostra buona volontà di leggere l'enorme flusso di parole a-tecniche che potrà venire fuori.

Vi presento un esercizio tratto da un libro ("Luke Welling, Laura Thomson, MySQL tutorial, Pearson Education Italia").

Vi è presentato un esempio di un database da normalizzare. L'esempio è il seguente:

ordini (idcliente, nomecliente, indirizzocliente, idordine, dataordine, idprodotto, nomeprodotto, quantità prodotto)

Comincio con la prima normalizzazione. Devo considerare il fatto che un singolo cliente può compiere più ordinazioni e che può ordinare più prodotti nella stessa ordinazione.

Di conseguenza, detto n il numero di ordini che un singolo cliente può fare, e m il numero di prodotti che il cliente può fare inn una singola ordinazione, si evincerebbe che il nome di un singolo cliente deve essere ripetuto n x m volte.

Questa è una prima normalizzazione, passo abbastanza algoritmico.

Provo ora a effettuare una seconda normalizzazione.
Devo individuare la superchiave della tabella, in primo luogo.

Noto che nomecliente e indirizzocliente dipendono dall'id cliente. Nel senso che ad ogni id corrispondono un solo nomeutente e un solo indirizzocliente. L'attributo dataordine dipende dall' idordine. Se invertissi l'ordine delle dipendenze, avrei che le nuove corrispondenze così introdotte non sarebbero funzioni. Infatti, ad ogni coppia nomeutente + nomeindirizzo corrisponderebbero più Id, così come ad ogni dataordine potrebbero corrispondere più idordine.

La prima domanda è la seguente: se anche le seconde corrispondenze possono essere individuate a un livello puramente logico; se quindi in un certo senso, anche queste corrispondenze possono essere chiamate "dipendenze", è possibile concludere che nella logica dei database per "dipendenza" si intende null'altro che il concetto matematico di una funzione?

Sembra una domanda poco operativa, la mia di prima; in effetti, serve a me per mettere un po' di ordine nelle cose da ricordare.

Continuando con la seconda normalizzazione, dicevo che da un singolo id dipende univocamente una singola coppia nomecliente + indirizzocliente; tuttavia la superchiave non è costituita soltanto dall’ idcliente. Infatti, come già detto a proposito della prima normalizzazione, un singolo cliente potrebbe fare più ordinazioni; inoltre, in ogni ordinazione, un singolo cliente potrebbe chiedere più prodotti.

La superchiave, quindi, sarebbe rappresentata dai tre attributi idcliente, idordine, idprodotto.

Il passo che segue all’individuazione della superchiave mi è poco chiaro.

L’esempio “svolto” che lo stesso testo presenta a proposito della seconda forma normale è quello di una siffatta tabella, che descrive il modello reale della catalogazione di impiegati e uffici in cui lavorano. Lo schema della relazione è il seguente:

impiegato (idimpiegato, nome, mansione, iddipartimento, competenza).

Il minimo numero di attributi necessari a identificare un singolo record è 2, e gli attributi che servono a tale scopo sono idimpiegato e competenza.

Una volta individuati tali attributi (operazione relativamente semplice), occorre dividere la tabella originaria in più tabelle. Qui c'è il primo punto dolente, nel senso che non riesco a trovare una procedura standard da seguire. Nell'esempio esercizio relativo alle ordinazioni di prodotti fatto da clienti (che differisce dall'esempio svolto relativo agli impiegati e agli uffici in cui lavorano), mi verrebbe da dividere la tabella unica iniziale in tre tabelle:

Tabella iniziale (che riporto per scrupolo di chiarezza)
ordini (idcliente, nomecliente, indirizzocliente, idordine, dataordine, idprodotto, nomeprodotto, quantitàprodotto)

Tabelle della seconda normalizzazione:
clienti (idcliente, nomecliente, indirizzo cliente)
ordini (idordine, dataordine)
prodotti (idprodotto, nomeprodotto, quantità prodotto)

Ovviamente questa seconda normalizzazione sarebbe comunque parziale: le tre tabelle appaiono ancora separate. Tutte e tre hanno una chiave primaria (rispettivamente idcliente, idordine, idprodotto), tuttavia non sembrano esserci collegamenti tra le varie tabelle. Collegamenti che, al mio infimo livello di conoscenza dei database, non possono prescindere dalle chiavi esterne.

A intuito, mi verrebbe da dire che due delle tre tabelle dovrebbero essere munite, almeno al livello della seconda normalizzazione (comunque parziale), di chiavi esterne, in grado di collegarle alle altre tabelle.

La seconda domanda, in definitiva è la seguente: Se è giusta la "parziale seconda normalizzazione" da me effettuata con la divisione nelle tre tabelle, il passo successivo è quello di trovare chiavi esterne in modo da predisporre le tabelle ad una definitiva "unificazione logica"? E se la "parziale seconda normalizzazione" da me svolta non è corretta, come si deve ragionare?

Questa domanda chiude questa prima mia esposizione dei miei dubbi. Infatti, non sapendo come rendere algoritmica la procedura per effettuare la seconda normalizzazione, non posso nemmeno ragionare su quella utile a effettuare la terza.

Ringrazio in anticipo chiunque voglia avere la pazienza di leggere questa serie di chiacchiere sconnesse. Mi sento davvero in alto mare, ritenendo tuttavia che, una conoscenza utile delle strutture dei database non possa prescindere dalla conoscenza profonda degli elementi di progettazione.