Newsgroup: it.comp.software.database
Titolo: problema "logico" su un database

Ciao a tutti,
ho un dilemma che mi affligge da un po' di tempo ovvero:
ESEMPIO
ho un db che gestisce la prenotazione di una sala in un ristorante che
per ora ha tre sale...ma ovviamente potrà averne altre in futuro:-)
quindi le tabelle saranno
T_sala (ID_sala, Nome_sala,Numero_posti_sala )
T_cliente (ID_cliente, Nome_cliente etc etc etc)
T_prenotazione (ID_prenotazione, Data_prenotazione, ID_sala,
ID_cliente)
fin qui nulla di difficile ed è abbastanza intuitivo come funzione il
db.
si popola la tabella sala, quella del cliente e poi ogni volta che un
cliente fa una prenotazione, si popola la tabella prenotazione.
Il dilemma che non mi fa dormire di notte è che se sfortunatamente,
dopo un po' di tempo che il gestore del ristorante usa il db, questo si
dovesse inventare di modificare la tabella 'sala' e invertire i numeri
delle sale, la tabella prenotazione sarebbe tutta sballata e priva di
utilità.
cerco di farmi capire con un esempio:
'pincopalla' prenota per il gg 01/01/06 la sala con ID '1' che oggi si
chiama 'sala con caminetto'
tra venti gg il gestore si INVENTA di modificare i nomi delle sale e
chiama la sala con ID '1'
 "sala con vetrata" e inserisce un nuovo record (esempio con ID 4 ) e
la chiama "sala con caminetto".
facendo una ricerca sulla tabella prenotazioni verrà fuori che
'pincopalla' prenota per il gg 01/01/06 la sala conn ID '1' che si
chiama 'sala con vetrata'
e NON é QUELLO CHE VERAMENTE é SUCCESSO!
volevo solo sapere se devo bastonare il gestore del ristorante
affinchè non modifichi i nomi delle sale o se per caso c'è un modo
per ovviare a questo problema?!
ciao e grazie

 e NON é QUELLO CHE VERAMENTE é SUCCESSO!
Domanda eccellente; hai la mentalità del data modeler.
Mi limito ad osservare che:
1) Gli ID autoincrementanti distruggono l'integrità _logica_ dei
dati, forgiando dipendenze funzionali *errate* su attributi non-key
(anzi neppure attributi per definizione, in quando non facenti parte
dello schema concettuale, ma valori generati pseudo-casualmente)
2) Un tale design ha bisogno SEMPRE di etichette descrittive per
interpretare cosa significa l'ID, in quanto non significa NIENTE
che il db possa capire, ma l'integrità è tutta in mano all'umano:
il dbms si limita a mettere il testo da interpretare sul video; questo
sistema è come fare fotocopie, solo senza usare la carta, ma pochi se
ne rendono conto.
3) Una buona chiave primaria (questa sconosciuta) ha varie qualità,
tra cui:
 - ha un significato SIA nel db SIA nella realtà, ed è pertanto
   VERIFICABILE
 - è stabile sia nel tempo sia in tutto lo schema (anche in differenti
   db!)
4) Uno schema di db relazionalmente corretto permette il mantenimento
del significato logico dei dati nei confronti di tutte le operazioni di
manipolazione di dati, incluse subsezioni di schema; ora, com'è
possibile che, cambiando un attributo non-chiave (es. il nome della
sala), in UNA tabella, cambio contemporaneamente anche il significato
di una riga in un'ALTRA tabella?
 4.1) Potrei fare un inserimento SENSATO nella tabella Prenotazioni
      senza conoscere il contenuto della tabella Sale?
 4.2) Quali informazioni ottengo se esporto la tabella prenotazioni
      da sola?
 4.3) Se le re-importo a distanza di tempo, sono sicuro che riavranno
      lo stesso significato?
Sono 37 anni che la teoria relazionale ha fatto piazza pulita di ogni
concetto fisico, eppure...

 concetto fisico, eppure...
Grazie della veloce risposta, quindi tu mi consigli di eliminare la
chiave primaria ID_... (che effettivamente uso per una cattiva
abitudine trascinatami dai db acces:-(  ) e di inserire come chiave
primaria il "nome della sala" ?
Ma così facendo l'utente medio (o anche qualcosa meno del medio)
potrà comunque modificare sostanzialmente il nome delle sale (magari
invertendole)?! o no?!!
Ora faccio una tabellina di prova...grazie ancora

 
Usa le FOREIGN KEY.
Ad esempio
CREATE TABLE Prenotazioni (
  nome_sala TEXT REFERENCES Sale(nome_sala) ON UPDATE CASCADE,
  ...
);
In questo modo se cambi il nome della sala, le altre tabelle che fanno
riferimento ad essa vengono modificate di conseguenza, mantenendo
l'integrità dei dati.
Saluti  Manlio Perillo

 invertendole)?! o no?!!
L'utonto farà sempre danni; si può adottare una strategia che
minimizza (vedi il mex. di Manlio) o una ancora più restrittiva
(proibire tutto, anche i nuovi inserimenti, da parte degli utenti);
inoltre, in questa maniera i danni saranno minori, esempio:
Sale
------------------------
HALL  Salone principale
VERA  Veranda riscaldata
GIAR  Giardino sul retro
Prenotazioni
------------------
HALL  Mario   8:30
GIAR  Gino    9:00
VERA  Pino    9:10
Esempio di casino: si scambiano due descrizioni e si cancella la terza:
Sale
------------------------
HALL  Veranda riscaldata
VERA  Salone principale
GIAR  asdfasdf
Prenotazioni
------------------
HALL  Mario   8:30
GIAR  Gino    9:00
VERA  Pino    9:10
Come noterai, i danni sono molto più limitati: non ho cambiato il
significato logico della tabella prenotazioni, ed inoltre ho la
possibilità di accorgermi prontamente che qualcosa non va nella
tabella Sale, in quanto le chiavi sono verificabili nel mondo reale.
Prova ad immaginare la stessa cosa fatta a ID, vedrai che la
possibilità di fare danni è maggiore; in ogni caso il massimo che
un db può fare è controllare che i dati siano verosimili, non di più.
Naturalmente mi riservo una serata di testing in loco :-PPPPP

 Naturalmente mi riservo una serata di testing in loco :-PPPPP
grazie mille, ora mi è tutto molto più chiaro.
Avevo comunque già una mezza idea di far inserire all'utente i nomi
delle sale in maniera "definitiva", cioè una volta salvati i nomi
(previa ovviamente una paginetta di conferma del tipo: questi sono i
tuoi dati...sei sicuro di volerli salvare?), sono possibili solo
inserimenti (ovvimanete non duplicati!) e NON modifiche.
ciao e grazie ancora