Progettazione Database - Schema ER
Si vuole progettare la base di dati di una palestra. Di tutti i dipendenti della palestra si conoscono dati anagrafici, ruolo e specializzazione. Ci sono istruttori, medico sportivo, segretaria e impiegati amministrativi.
Si memorizzano le informazioni sui clienti, che includono il Codice Fiscale, il nome, l'indirizzo e un numero di telefono. Ogni cliente deve aver ottenuto un certificato di sana e robusta costituzione prima di cominciare l’attività
della palestra: occorre perciò assegnargli un appuntamento con uno dei medici sportivi che seguono la palestra.
La data di inizio dell’attività deve essere successiva alla data dell’appuntamento. Per ognuno dei clienti si memorizzano gli esercizi che deve fare per seguire il programma che gli e' stato assegnato, e quale istruttore gli sia stato assegnato. Di ogni esercizio si sa il nome, i il muscolo principale coinvolto, la durata e le controindicazioni. Inoltre di ogni cliente si conosce la situazione dei suoi pagamenti:a che tipo di corso e' iscritto, da quando, quanto ha pagato, il costo complessivo e quando scade la prossima rata. Per ogni attrezzo si conosce la matricola, alcune caratteristiche (es. peso mine peso max che può supportare), la marca, il riferimento della ditta venditrice (per motivi di manutenzione), in quale sala si trova, per quali muscoli è utile.
Ho immaginato uno schema simile:
tradotto in :Medico(Cod_med,Nome,Cognome,Data_nascita)
Cliente(Codice_fis,Nome,Indirizzo,Num_tel,Data_visita,Cod_Medico(FK))
Corso(Cod_cor,Nome,Descrizione)
Iscrizione(Data_inizio,Codice_fis(FK),Cod_corso(FK))
Programma(Codice_prog,Codice_ist(FK),Codice_fis(FK))
Rata(Mese,Codice_fis(FK),Cod_corso(FK),Importo,Data_Pagamento)
Esercizi(Cod_es,Nome,Muscolo,Durata,Controindicazioni,Matricola(FK))
Istruttore(Codice_ist,Nome,Cognome,Data_nascita)
Attrezzi(Matricola,Marca,Descrizione,Sala,Fornitore,Peso_min,Peso_max,Muscolatura)
È una progettazione valida?
Si memorizzano le informazioni sui clienti, che includono il Codice Fiscale, il nome, l'indirizzo e un numero di telefono. Ogni cliente deve aver ottenuto un certificato di sana e robusta costituzione prima di cominciare l’attività
della palestra: occorre perciò assegnargli un appuntamento con uno dei medici sportivi che seguono la palestra.
La data di inizio dell’attività deve essere successiva alla data dell’appuntamento. Per ognuno dei clienti si memorizzano gli esercizi che deve fare per seguire il programma che gli e' stato assegnato, e quale istruttore gli sia stato assegnato. Di ogni esercizio si sa il nome, i il muscolo principale coinvolto, la durata e le controindicazioni. Inoltre di ogni cliente si conosce la situazione dei suoi pagamenti:a che tipo di corso e' iscritto, da quando, quanto ha pagato, il costo complessivo e quando scade la prossima rata. Per ogni attrezzo si conosce la matricola, alcune caratteristiche (es. peso mine peso max che può supportare), la marca, il riferimento della ditta venditrice (per motivi di manutenzione), in quale sala si trova, per quali muscoli è utile.
Ho immaginato uno schema simile:
tradotto in :Medico(Cod_med,Nome,Cognome,Data_nascita)
Cliente(Codice_fis,Nome,Indirizzo,Num_tel,Data_visita,Cod_Medico(FK))
Corso(Cod_cor,Nome,Descrizione)
Iscrizione(Data_inizio,Codice_fis(FK),Cod_corso(FK))
Programma(Codice_prog,Codice_ist(FK),Codice_fis(FK))
Rata(Mese,Codice_fis(FK),Cod_corso(FK),Importo,Data_Pagamento)
Esercizi(Cod_es,Nome,Muscolo,Durata,Controindicazioni,Matricola(FK))
Istruttore(Codice_ist,Nome,Cognome,Data_nascita)
Attrezzi(Matricola,Marca,Descrizione,Sala,Fornitore,Peso_min,Peso_max,Muscolatura)
È una progettazione valida?
Risposte
Io imposterei il tutto in questo modo:
ANAGRAFICA: codice(PK), nome, cognome, codice_fiscale, tipo_anagrafica(FK)
TIPO_ANAGRAFICA: codice(PK), descrizione=(medico,cliente,istruttore,segretaria, altro,....)
CORSO: codice(PK), descrizione, costo_mensile
CORSI: codice_anagrafica(FK),codice_corso(FK), codice_programma_allenamento(FK),data_inizio, data_fine
PROGRAMMA_ALLENAMENTO: codice(PK), codice_esercizio(FK), codice_attrezzo(FK),serie, ripetizioni, durata
ESERCIZIO: codice(PK), descrizione, muscoli_coinvolti, controindicazioni
ATTREZZO: codice(PK), descrizione, marca, sala, fornitore, peso_minimo, peso_massimo, muscoli_allenati
ANAGRAFICA: codice(PK), nome, cognome, codice_fiscale, tipo_anagrafica(FK)
TIPO_ANAGRAFICA: codice(PK), descrizione=(medico,cliente,istruttore,segretaria, altro,....)
CORSO: codice(PK), descrizione, costo_mensile
CORSI: codice_anagrafica(FK),codice_corso(FK), codice_programma_allenamento(FK),data_inizio, data_fine
PROGRAMMA_ALLENAMENTO: codice(PK), codice_esercizio(FK), codice_attrezzo(FK),serie, ripetizioni, durata
ESERCIZIO: codice(PK), descrizione, muscoli_coinvolti, controindicazioni
ATTREZZO: codice(PK), descrizione, marca, sala, fornitore, peso_minimo, peso_massimo, muscoli_allenati
@GundamRX91
Non vale, sei "del settore".
Serio: nel tuo schema non si riesce a collegare le persone "medico" "istruttore" e "cliente". L'anagrafica è completa: nello schema di BHK invece non lo è. Io però userei due anagrafiche: "personale" e "clienti".
Non vale, sei "del settore".
Serio: nel tuo schema non si riesce a collegare le persone "medico" "istruttore" e "cliente". L'anagrafica è completa: nello schema di BHK invece non lo è. Io però userei due anagrafiche: "personale" e "clienti".
@Rggb: almeno in questo mi posso, un pò, difendere In che senso che si riesce a collegare "medico", "istruttore" e "cliente"?
PS. non è che ci ho pensato molto a questo schema, quindi sicuramente si può notevolmente migliorare, senza contare che mancano alcune informazioni richieste dall'esercizio, ma si possono aggiungere.
In che senso che si riesce a collegare "medico", "istruttore" e "cliente"?PS. non è che ci ho pensato molto a questo schema, quindi sicuramente si può notevolmente migliorare, senza contare che mancano alcune informazioni richieste dall'esercizio, ma si possono aggiungere.
Ok, infatti non ero convintissimo che le tipologie di personale non utili per l'esercizio potessero essere escluse dallo schema ER.
@GundamRX91: Una semplice curiosità, come mai hai deciso di separare le tipologie di persone inserendole in una relazione a parte? Mi sembra che ogni persona possa avere una sola tipologia e che quindi possa essere direttamente inserita insieme alle altre informazioni della persona. Ma ho letto tutto molto velocemente e potrei non aver colto qualcosa.
BHK aveva definito varie entità per la gestione di dati anagrafici: il medico, il cliente e l'istruttore, così ho codificato un'unica entità, l'anagrafica, che le contiene tutte e la specializza con con la tipo_anagrafica, che essendo un'entità a se stante è quindi generica, e consente di avere tutte le tipologie che si vuole con due sole entità (tabelle).
Spero di essere stato chiaro, però per quanto mi riguarda evito di avere tabelle diverse per gestire, concettualmente lo stesso dato, come dei dati anagrafici di questo esercizio. Volendo si potrebbe evitare pure la tabella TIPO_ANAGRAFICA codificando questa informazione nell'ANAGRAFICA stessa, però solitamente è più utile separare questi dati.
Spero di essere stato chiaro, però per quanto mi riguarda evito di avere tabelle diverse per gestire, concettualmente lo stesso dato, come dei dati anagrafici di questo esercizio. Volendo si potrebbe evitare pure la tabella TIPO_ANAGRAFICA codificando questa informazione nell'ANAGRAFICA stessa, però solitamente è più utile separare questi dati.
Infatti l'impostazione anagrafica adottata è corretta. Ci sono segretari, impiegati vari, istruttori, medici etc. Io li avrei separati dai clienti, ma è un modus operandi valido.
Quello che dicevo è che nello schema proposto "alla volee" da GundamRX91 non vi è correlazione su chi è il medico che ha certificato il cliente, chi è l'istruttore di un certo cliente ecc.
Quello che dicevo è che nello schema proposto "alla volee" da GundamRX91 non vi è correlazione su chi è il medico che ha certificato il cliente, chi è l'istruttore di un certo cliente ecc.
Inglobare i clienti e i dipendenti in una sola entità è una forzatura, e potrebbe causare confusione con le relazioni ricorsive.
"Rggb":
Infatti l'impostazione anagrafica adottata è corretta. Ci sono segretari, impiegati vari, istruttori, medici etc. Io li avrei separati dai clienti, ma è un modus operandi valido.
Quello che dicevo è che nello schema proposto "alla volee" da GundamRX91 non vi è correlazione su chi è il medico che ha certificato il cliente, chi è l'istruttore di un certo cliente ecc.
Si hai ragione
Ora con un pò più di tempo ho ripensato alla struttura del DB:
ANAGRAFICA: codice(PK),nome,cognome,codice_fiscale,codice_tipo_anagrafica(FK)
TIPO_ANAGRAFICA: codice(PK),descrizione=(medico,cliente,istruttore,segretaria, altro,....)
INDIRIZZO: codice_anagrafica(FK),via,cap,provincia,citta,tipo_indirizzo=(recapito,residenza)
CLIENTE: codice_anagrafica(FK),codice_medico(FK),data_visita
CORSI_CLIENTE: codice_anagrafica(FK),codice_corso(FK),codice_programma(FK),data_inizio, data_fine
CORSO: codice(PK),descrizione,costo_mensile,codice_istruttore(FK)
PROGRAMMA_ALLENAMENTO:codice(PK),descrizione
PROGRAMMA_ALLENAMENTO_DETTAGLIO:codice_prog(FK),codice_esercizio(FK),codice_attrezzo(FK),serie,ripetizioni,durata,recupero
ESERCIZIO: codice(PK),descrizione,muscoli_coinvolti,controindicazioni
ATTREZZO:codice(PK), descrizione, marca, sala, fornitore,peso_minimo, peso_massimo,muscoli_allenati
Così dovrebbe andare un pò meglio, forse...
@BHK: non è una forzatura, semmai il contrario in quanto avresti un data base poco normalizzato; pensa ad avere una tabella CLIENTE: codice, nome, cognome, indirizzo e una tabella ISTRUTTORE:codice, nome, cognome, indirizzo e una tabella MEDICO: codice, nome, cognome, indirizzo, come vedi sono logicamente informazioni differenti, ma fisicamente le puoi gestire come un'unica tabella. Il vantaggio è una maggiore coerenza del data base e una più facile manutenzione (un'unica stored procedure per inserire, modificare e cancellare i dati), e infine con l'SQL fai tutte le relazioni che vuoi.
Comunque in generale non è facile impostare un data base senza sapere bene cosa gestire, e spesso ci si ritorna sopra quando si "scoprono" nuove informazioni o, soprattutto, funzioni particolari da implementare che magari modificano un pò la struttura iniziale delle tabelle.
Accedi a tutti gli appunti
Tutor AI: studia meglio e in meno tempo