05. Regole di nomenclatura

La progettazione concettuale, come si è visto, si pone al massimo livello possibile di astrazione e modella la realtà senza traguardare al modello dei dati che verrà utilizzato successivamente.

Anche la nomenclatura suggerita per le entità e le associazioni riflette questa esigenza di astrazione.

La progettazione logica, d'altra parte, si pone l'obiettivo di rappresentare i concetti astratti della progettazione concettuale in elementi ben precisi, coerenti con il modello dei dati adottato. Nel caso del modello relazionale, tutti i concetti astratti vengono espressi in termini di tabelle e di vicoli sugli attributi.

In questo contesto la nomenclatura utilizzata per le tabelle e i suoi attributi deve rispondere ad esigenze diverse e riflettere il più possibile ciò che la tabella rappresenta.

Ad esempio, se l'associazione che lega le entità Studente e Classe è denominata coerentemente Appartenere le tabelle corrispondenti potrebbero essere denominate Studenti, Classi e GruppiClasse.

Mentre la corrispondenza tra le entità e le rispettive tabelle è immediata, l'associazione cambia significativamente il nome.

Oggettivamente la denominazione Appartenere per una tabelle proprio non aiuta a capire cosa può contenere a differenza della denominazione GruppiClasse che esprime esattamente quale tipo di associazione è inclusa nella tabella.

In generale la nomenclatura suggerita, ma non prescrittiva, per le tabelle e gli attributi prevede:

    • nomi al plurale per le tabelle;

    • nomi al singolare per gli attributi, tranne nei casi in cui la natura dell'attributo esprime di per sé una pluralità (es. Figli per esprimere il numero di figli);

    • per le chiavi primarie che sono codici progressivi, lo stesso nome della tabella seguita da ID (ad esempio StudenteId per la tabella Studenti);

    • per le chiavi esterne, lo stesso nome della chiave primaria cui si riferisce, se il nome include quello della tabella.