PDA

Visualizza versione completa : aiuto progetto database



Skywalker87
02-09-11, 16: 43
Salve gente,
sono alle prese con un progetto personale che consiste nel realizzare un'applicazione per la gestione delle ore di lavoro di un gruppo di camerieri. L'applicazione sarà un sito web, ogni utente/cameriere potrà accedere all'applicazione con le sue credenziali, il sito darà quindi la possibilità ai sui utenti di registrare le ore di lavoro.

L'idea nasce da due necessità: la prima è l'esigenza di avere uno strumento comune per la gestione delle ore di lavoro, io stesso faccio parte del gruppo di camerieri che andrebbe ad usufruire dell'applicazione. La seconda è la necessità di un'idea per il progetto dell'esame di basi di dati che devo affrontare.

Vi starete chiedendo come mai ho aperto questa discussione. Bene il mio intento è quello di ottenere un supporto durante la realizzazione del progetto. Non è mia intenzione delegare del lavoro, ma solo avere delle spiegazioni, dei chiarimenti, dei consiglio lungo lo sviluppo dell'applicazione.

Inizio subito ad esporvi la "tabella di marcia" che ho stilato:


raccolta dei requisiti e stesura di una descrizione completa (o quasi) dell'applicazione in linguaggio naturale
realizzazione del database:

schema concettuale
schema logico
modello relazionale
realizzazione del database vero e proprio tramite il DBMS scelto

realizzazione dell'interfaccia utente


Bene per il momento mi fermo qui. Aspetto qualche vostra prima considerazione. Non tarderanno ad arrivare le mie richieste di aiuto, quindi a presto! Grazie!

pierino_89
02-09-11, 22: 41
Beh, io prima di tutto ti dico la cosa più importante in assoluto: NON REINVENTARE LA RUOTA. Mai.
E tieni da conto la sicurezza.
E soprattutto, ricorda che lo sviluppo è bene, senza sviluppo non si crea niente. Però, prima di sviluppare, devi valutare gli strumenti a disposizione.

Punto uno: il ferro.
- dove intendi infilare il sito? Onestamente, un gestionale non può permettersi di stare online: è la tipica cosa che deve stare in intranet, quindi devi valuare cosa c'è già in rete, che hw hai disponibile, piattaforma software sottostante, etc etc.

Punto due: il software di base
- PHP, ASP? MySQL, PostGres, SQL Server (scarto volontariamente access e sqlite)? Framework? CMS?

Punto tre: budget. È tutto bello, tutto divertente, ma hai presente quanto costa una licenza di SQL server :cry3?

Per ora non mi viene in mente altro, anche perché si parla di un ristorante suppongo, quindi non sto a pensare cose tipo integrazione AD. Poi dimmi tu cosa può servire, insomma :bgg2

Skywalker87
03-09-11, 12: 21
Grazie per la risposta pierino_89!! :fleurs

Cerco di rispondere a tutti gli spunti che mi hai dato:

Come ho già accennato il programma, oltre ad essere un'esigenza e/o sfizio personale, vorrei sfruttarlo anche come progetto per un esame all'università. Il professore pretende che ogni studente si presenti all'esame con un'applicazione (funzionante!!) che incameri un database (l'esame è per l'appunto quello di basi di dati). Quindi, per rispondere al tuo "punto zero" (non reinventare la ruota), volendo o non volendo sono costretto a reinventare la ruota per l'esame! Non posso presentarmi dal professore con qualcosa che non ho scritto io!

Dove intendo infilare il sito? Io ho pensato al caro vecchio altervista.org, i motivi sono sostanzialmente due: primo perché è un "ambiente" che già conosco e quindi posso muovermi più liberamente; e secondo, a dire la verità non ho familiarità con altri fornitori di web hosting. Detto questo ho risposto anche al tuo "punto due". Altervista, come penso saprai, mette a disposizione due strumenti: PHP e MySQL, quindi saranno questi gli strumenti con cui dovrò forgiare il programma, se rimango su altervista.org ovviamente.

Apro una parentesi. Il professore ha più volte dichiarato: "odio ACCESS e MySQL" (in realtà si lasciava andare ad esternazioni ben più volgari :bgg2). Per questo motivo avevo pensato di sfruttare PostgreSQL, ma non conosco un fornitore di web hosting (gratuito!!) che lo supporti. È anche vero che per l'esame non sono tenuto a trasferire il progetto online, potrei realizzare il database con PostgreSQL in locale per l'esame e poi tradurlo in MySQL per l'applicativo "reale". Questo comporterebbe maggiore fatica e se si considera che non ho esperienza con PostgreSQL la cosa si fa alquanto dispendiosa. Va detto inoltre che il 99% degli studenti che sostiene l'esame si presenta con un progetto realizzato in ACCESS e questo non inficia il voto finale (si può tranquillamente prendere il massimo dei voti anche se si usa ACCESS). Quindi io ho deciso di tagliare la testa al toro e di usare direttamente MySQL sia per l'esame che per l'applicazione "reale".

A questo punto la domanda sul budget diventa superflua direi... :tong2

Infine hai sollevato dei dubbi sul fatto che un programma di questo tipo sia meglio gestirlo in locale piuttosto che online. Mi rendo conto che con la panoramica che ho dato non risultino evidenti i benefici nel realizzare un database in condivisione. Cerco di spiegare un po' meglio la situazione:

Il gruppo di camerieri a cui il programma è dedicato (almeno all'inizio) è a disposizione di una società interinale, la quale ha come clienti svariati ristoranti, bar, alberghi, aziende di catering, ecc ... I camerieri quindi non hanno un datore di lavoro unico ma cambia quasi regolarmente ad ogni servizio. Lo strumento in condivisione è utile perché una volta creata l'istanza di un servizio tutti i camerieri che ne hanno preso parte possono semplicemente iscriversi all' "evento". Così a fine mese il resoconto dei servizi, con il totale delle ore di lavoro, risulta essere corretto e privo di incongruenze, facile da spedire (tramite l'applicazione) alla società interinale.

Forse non sono stato ancora abbastanza chiaro e convincente sulla necessità di uno strumento online, spero che dai requisiti (che posterò a breve) sia tutto più evidente.

:bai

pierino_89
04-09-11, 16: 41
Uh che fastidio, l'ho dato pure io due mesi fa l'esame di laboratorio applicazioni di reti (che sostanzialmente era un esame su php+mysql+javascript).
Essendo che il tuo è concentrato sulla base dati, potresti perlomeno usare cose tipo jquery con tutti i fantastici plugin che si porta dietro, e magari un framework php se ne conosci già qualcuno. A me sarebbe piaciuto fare un giro su Symfony, ma ero a corto di tempo per imparare.

No beh, il concetto è molto più semplice, un gestionale online neanche su https sta implorando di essere sfondato.
Potresti pensarlo con una parte pubblica e una solo interna, ma potrebbe diventare complesso.
La questione che ora mi lascia perplesso è un'altra: ognuno può segnare le ore come gli pare, senza alcun controllo?
Sarebbe più logico fare una cosa tipo:
- il datore crea un evento
- il cameriere conferma la propria partecipazione
- il datore valida in seguito l'eventuale partecipazione indicando il numero di ore
- infine l'agenzia chiude l'evento e tutte le ore vengono archiviate nel gestionale
in questo modo, per dire, hai un'interfaccia web che fornisce solo una API per introdurre ore nel gestionale al termine dell'evento (e quindi può restare pubblica), e poi ti inventi qualche procedura automatizzata tipo che so, esportazione in xml del report dell'evento via ftp e import automatico nel gestionale (che figurati se non ne hanno già uno, a parte tutto).

Per concludere, postgres e mysql derivano entrambi da ansi sql, quindi le differenze non sono molte. In fase di inserimento/estrazione dati se non vai ad usare funzioni strane la sintassi è identica. Durante la progettazione ci sono alcune discrepanze, tipo se devi creare una chiave ad autoincremento su psql è un po' più complesso perché segue la sintassi ansi (prima crei una sequenza e poi leghi la sequenza al field).

Skywalker87
13-09-11, 03: 03
Ciao, eccomi qua! Sono già passati nove giorni, mamma mia come corre il tempo! Non ho risposto subito perché volevo avere qualcosa da mostrare, così ho scritto una bozza dei requisiti e ho realizzato uno (approssimativo) schema concettuale.

Ma prima di tutto rispondo a pierino_89:


La questione che ora mi lascia perplesso è un'altra: ognuno può segnare le ore come gli pare, senza alcun controllo?
Sarebbe più logico fare una cosa tipo:
- il datore crea un evento
- il cameriere conferma la propria partecipazione
- il datore valida in seguito l'eventuale partecipazione indicando il numero di ore
- infine l'agenzia chiude l'evento e tutte le ore vengono archiviate nel gestionale

Hai perfettamente ragione. L'ideale infatti sarebbe che l'agenzia interinale creasse l'evento, come già lo comunica ai camerieri. Ed è proprio così che voglio far evolvere il programma, però al momento non posso contare sull'agenzia interinale, ma solo su i miei colleghi camerieri. Perciò il programma sarà impostato in modo tale che solo gli utenti con i privilegi adeguati potranno creare gli eventi, ma in un primo momento tali privilegi saranno concessi a tutti gli utenti.

Per capire meglio cosa intendo, ti faccio un esempio concreto. L'agenzia interinale riceve una richiesta di cinque camerieri da un ristorante. L'agenzia chiede disponibilità ai sui “dipendenti” e una volta confermata la squadra comunica a tutti e cinque i dettagli del servizio (luogo, orario, abbigliamento, …). Il primo dei cinque camerieri ad accedere al sito, dopo essersi accertato che l'evento non sia già esistente, crea l'evento. Agli altri camerieri non resta che iscriversi. Una volta terminato il servizio, l'utente creatore dell'evento aggiungerà l'ora di fine servizio.

Questo era il punto su cui mi premeva risponderti.


Ora veniamo ai fatti! :hap

I requisiti, ovvero quello che l'applicazione dovrebbe essere a parole:

* Presentazione generale

L'applicazione che si vuole realizzare è un gestionale per camerieri in cui essi possono programmare e archiviare i servizi svolti. I camerieri a cui è dedicato il programma sono a disposizione di un'agenzia interinale, la quale ha come clienti svariate aziende di ristorazione.

* Caratteristiche principali del programma

Il programma si presenta come un sito web. Ogni cameriere/utente accede al sito tramite un account. L'utente può iscriversi ad un servizio o eventualmente crearne uno nuovo, visualizzare l'elenco dei servizi svolti, visualizzare le informazioni sulle aziende di ristorazione e sugli altri utenti.


* Database

Il database dovrà raccogliere i dati relativi ai camerieri, alle aziende di ristorazione e ai servizi.

Per ogni cameriere/utente vanno memorizzati obbligatoriamente una mail e una password, necessarie per accedere al sito. I dati per la compilazione di un contratto (facoltativi ad eccezione della coppia nome/cognome): nome, cognome, comune di nascita (sigla provincia), data di nascita, indirizzo di residenza (comune, sigla provincia, via, numero civico, cap), cittadinanza, codice fiscale. A discrezione dell'utente viene memorizzato anche un recapito telefonico. Infine per ogni cameriere viene registrato l'ammontare del compenso orario, valore che può variare nel tempo e in determinati servizi.

Per ogni azienda di ristorazione vanno archiviati il nome dell'azienda (campo obbligatorio), il tipo di azienda (ristorante, bar, albergo, servizio catering, altro), l'indirizzo e un numero telefonico della sede o, nel caso in cui l'azienda avesse più sedi, un indirizzo e un numero telefono per ogni sede, l'indirizzo del sito web e un indirizzo di posta elettronica; se si esclude il nome dell'azienda che è obbligatorio, gli altri dati possono essere facoltativi. Inoltre, se sono noti, si vuole memorizzare il nome, il numero di telefono e la mail di una persona di riferimento dell'azienda. Ad ogni cameriere viene data la possibilità di esprimere un giudizio sull'azienda di ristorazione, tale giudizio viene memorizzato sotto forma di commento testuale.

Per ogni servizio vanno memorizzati la data, l'ora di inizio/fine servizio e il luogo in cui esso si svolge. Questi dati insieme all'azienda di ristorazione identificano univocamente il servizio e sono obbligatori. In aggiunta è possibile dare un titolo esplicativo al servizio, ad esempio “Premio Nonino”. Oltre ai dati già citati si vuole archiviare i chilometri percorsi dai camerieri che hanno messo a disposizione la propria auto e una “nota ufficiale” a margine del servizio. Ogni cameriere potrà lasciare un commento in merito ai servizi svolti.


* Altre caratteristiche del programma

L'applicazione permetterà in modo semplice di spedire tramite mail un resoconto in forma tabellare di uno o più servizi (ad esempio i servizi svolti durante un mese) all'agenzia interinale.

Lo schema concettuale, lo linko perché l'immagine è piuttosto grande: http://img8.imageshack.us/img8/9918/97872782.jpg

Immagino che ci siamo parecchi errori... Ho perso molto tempo a pensare se creare o meno un entità INDIRIZZO, in questa versione dello schema ho preferito trattare questa caratteristica come attributo composto. Cosa ne pensate?


Aspetto qualche parere o qualche consiglio per migliorare il progetto. Grazie! :bai

pierino_89
17-09-11, 17: 29
Onestamente io posso dirti poco, perché il corso di database non l'ho ancora fatto, quindi li ho sempre creati a braccio :lol:

MarcoStraf
17-09-11, 18: 31
Ciao skywalker, mi ricordo di te dal p2pforum

Qualche suggerimento, dalla mia esperienza personale. Anzi, un unico suggerimento: non mischiare un progetto scolastico con uno lavorativo. Sono due cose diverse. Con il primo si imparano le basi, ha poca importanza che funzioni o meno, lo si fa per fare capire all insegnate di sapere le cose, e si ha un tempo limitato per portarlo a termine e poche o limitate risorse. Fatti le ossa con quello, e sarai poi pronto per qualcosa di "serio". Non sprecare più tempo del dovuto, non è che il voto dipende dalla mole e quanto tempo ci hai passato, questo vale sia per usame che per una tesi.

In altre parole, l'idea del progetto lavorativo che hai in mente è parecchio complessa e solo una minima parte di essa ha a che fare con l'esame in questione, che mi pare limitato alla base dati. Quindi limitati a quello. Progetta le tabelle del database, con i giusti campi, chiavi e indici (è quello che guarda l'insegnante) e progetta una semplice interfaccia utente. Questo è il mio spassionato consiglio. Fai una cosa ma falla bene, invece che farne due ma male, te lo dico da studente, da professore e da chi lavora professionalmente nel campo da una ventina di anni.

Sono a disposizione per eventuali chiarimenti e sarò felice di darti una mano.

Skywalker87
20-09-11, 16: 48
Ciao MarcoStraf! :bai
Ti ringrazio moltissimo per il consiglio, che vado a commentare.

Ti do ragione, il tuo discorso non fa una grinza, ci sono però alcune considerazioni che vorrei fare. Scegliere il tema del progetto non è stato facile, ho cambiato più volte il soggetto. L'abbandono di un progetto per un altro non è sempre dipeso da una mia scelta, ma quando ciò è accaduto, il motivo era sempre lo stesso: il progetto non mi "prendeva", non era stimolante. Gli esami come questo, secondo me, sono un'occasione per fare qualcosa di stimolante, qualcosa che si vuole e ci piace fare, non solo che si deve fare. Poi mi preme sottolineare il fatto che non si tratta di un progetto lavorativo vero e proprio, anzi non lo è per niente. Non devo rispondere a nessuno se non a me stesso.
Io sono disposto ad accollarmi un po' di lavoro in più, se il progetto è interessante e alla fine penso che la soddisfazione sarà maggiore. Detto ciò, la complessità del progetto non si allontana poi molto dalla media dei progetti presentati.
Infine del tuo discorso, non condivido la seguente frase:


Fai una cosa ma falla bene, invece che farne due ma male, te lo dico da studente, da professore e da chi lavora professionalmente nel campo da una ventina di anni.
Io penso che le cose si possano fare bene entrambe.


Sono a disposizione per eventuali chiarimenti e sarò felice di darti una mano.
Te ne sarei eternamente grato! :forgive :bgg2 :thx



Onestamente io posso dirti poco, perché il corso di database non l'ho ancora fatto, quindi li ho sempre creati a braccio
:lol: Beh magari seguendo la discussione puoi farti un'idea di quello che ti aspetta al corso di basi. Puoi comunque darmi dei consigli, la progettazione di un database è un lavoro di ragionamento più che di concetto. :sisi



Venendo al programma, ho rivisto lo schema concettuale. Le differenze sostanziali tra questa nuova versione e quella precedente sono due: l'aggiunta di una nuova entità RITROVO e la trasformazione dell'attributo INDIRIZZO in un'entità. Ho poi corretto la cardinalità a qualche relazione.

Mi sono reso conto che a prima vista lo schema (nella sua interezza) possa risultare complicato. Penso sia normale, ma se lo si analizza con un po' più di attenzione, la sua comprensione non dovrebbe essere un grosso problema. Per agevolare ulteriormente la lettura, vi posto una descrizione passo passo dello schema.


Innanzi tutto per realizzare lo schema ho adottato una strategia mista. Partendo dallo schema scheletro, ho sviluppato separatamente i tre concetti fondamentali cioè camerieri, aziende di ristorazione e servizi.

http://img825.imageshack.us/img825/8057/86887515.jpg


Inizio considerando i camerieri. Essi possono essere visti come entità figlia di un'entità più astratta PERSONA, la generalizzazione che ne risulta è parziale ed esclusiva. Inoltre, siccome la generalizzazione ha una sola entità figlia, l'entità CAMERIERE è un sottoinsieme dell'entità PERSONA.
Tra i dati da memorizzare di ogni cameriere ci sono la retribuzione e la residenza, essi sono rappresentati dalle rispettive relazioni. L'entità COMPENSO rappresenta la paga oraria percepita; l'entità INDIRIZZO rappresenta appunto l'indirizzo di residenza.
Per completare lo schema parziale, aggiungo gli attributi, le cardinalità e gli identificatori. Ogni cameriere viene identificato dall'attributo id, ereditato dall'entità PERSONA. Anche per quanto riguarda la retribuzione, l'entità COMPENSO è identificata dall'attributo id. Infine anche l'entità INDIRIZZO ha come identificatore l'attributo id. Un appunto sulla cardinalità della relazione RESIDENZA, ogni istanza dell'entità INDIRIZZO partecipa opzionalmente alla relazione o più volte nel caso di due o più camerieri aventi la stessa residenza (ad esempio camerieri fratelli).

http://img716.imageshack.us/img716/3859/59669848.jpg


* Nota: Oltre alle residenza dei camerieri e agli indirizzi delle aziende, ci sono altri indirizzi che possono comparire più volte; sono gli indirizzi di luoghi come castelli, ville, centri commerciali, ecc ..., dove è usuale svolgere servizi di catering. Questo fatto viene rappresentato dalla relazione AGENDA e dall'entità INDIRIZZO UTILE. L'identificatore di questa entità è la stessa entità INDIRIZZO.


Passo ora ad analizzare le aziende di ristorazione. Esse possono avere una o più sedi, perciò introduco la relazione COMPOSIZIONE. Ogni sede sarà poi in relazione con l'entità INDIRIZZO, vista in precedenza.
Aggiungo gli attributi, le cardinalità e gli identificatori. Le aziende sono identificate dal solito attributo id. Ogni sede è identificata dalle entità AZIENDA e INDIRIZZO.

http://img593.imageshack.us/img593/1753/87081785.jpg


Infine analizzo i servizi. Sono ovviamente in relazione con l'entità INDIRIZZO e vengono identificati ancora una volta dall'attributo id.

http://img813.imageshack.us/img813/783/74401202.jpg


Posso ora integrare gli schemi ottenuti fino a questo momento. Dallo schema scheletro l'integrazione risulta immediata; posso aggiungere le cardinalità alle relazioni PARTECIPAZIONE e DATORE DI LAVORO. Inoltre, alla relazione PARTECIPAZIONE, aggiungo gli attributi compenso e km rimborso.

http://img853.imageshack.us/img853/589/53868866.jpg


Completo lo schema aggiungendo i concetti mancanti. Il cameriere che ha creato il servizio viene rappresentato dalla relazione CREATORE. Ogni azienda può avere una persona di riferimento, ciò viene rappresentato dalla relazione REFERENTE. I commenti dei camerieri sulle aziende e sui servizi, vengono rappresentati rispettivamente dalle relazioni COMMENTO AZIENDA e COMMENTO SERVIZIO. Queste due relazioni hanno gli attributi data, testo ed il solito identificatore id. Infine ogni servizio può avere uno o più ritrovi per i camerieri, aggiungo quindi l'entità RITROVO in relazione con i servizi, i camerieri e con l'entità INDIRIZZO. L'identificatore dell'entità RITROVO è costituito dalle entità SERVIZIO e INDIRIZZO.

http://img43.imageshack.us/img43/3541/schemaconcettuale.jpg


Cosa ne dite? Le modifiche apportate sono corrette?


Mi è venuto un dubbio. Come ho già accennato, in futuro solo determinati utenti (gli amministratori) avranno i privilegi per creare/modificare i servizi (e altre possibilità). Siccome vorrei già impostare l'applicazione in quest'ottica, mi sto appunto chiedendo come gestire questi privilegi.

Io ho pensato di gestire la situazione in questo modo. Aggiungo un'entità AMMINISTRATORE e la metto in relazione con i camerieri. A livello fisico, si avrà una tabella con un solo campo, cioè l'identificatore dei camerieri ai quali si vuole assegnare i privilegi di amministratore. Poi, nel momento in cui un utente effettua l'accesso, il programma riconosce se l'utente è un amministratore o meno. In funzione di questo caricherà la pagina con opzioni aggiuntive.

È il modo corretto di trattare il problema?

Grazie a tutti! :thx

MarcoStraf
20-09-11, 20: 46
Ti dico subito che in quelle figure io mi perdo, non mi ricordano nessuno dei grafici da me usati per creare lo schema di un database relazionale... sorry. Il problema e' che non so cosa voglia l'insegnante, potresti darci il testo originale del lavoro?

Da quello che hai spiegato io partirei con concetti parecchio diversi, per esempio per me la tabella principale e' quello che io chiamerei EVENTO, rappresentato da un contratto di lavoro, con vari parametri: datore di lavoro, agenzia, quanti camerieri ci lavorano, la data (inizio, fine) e la paga oraria di ciascun cameriere (che quindi puo' essere diversa da evento a evento e da cameriere a cameriere) L'evento viene creato da un "manager", che definisce anche i camerieri assegnati e la loro paga oraria. Il cameriere che arriva al lavoro dopo avere fatto login seleziona l'evento e seleziona INIZIO; finito il turno di lavoro, fa ancora login, sceglie lo stesso evento e seleziona FINE, automaticamente il database memorizza gli orari di inizio e fine. Quando l'evento si "chiude" (cosa che deve essere fatta da un manager, o avviene automaticamnte quando la sua data finisce), automaticamente vengono calcolate le paghe dei camerieri che ci hanno lavorato su, in base alla paga oraria e al tempo che hanno lavorato; ovvio che per un evento "chiuso" nessuno puo' aggiungere turni di lavoro. Questo schema permette per esempio al singolo cameriere di lavorare in piu' eventi allo stesso tempo (ovviamente con orari diversi, per esempio uno al mattino e uno al pomeriggio o alla sera)

In base a questo schema possiamo definire poi le altre varie tabelle di cui abbiamo bisogno (le indispensabili sono azienda, manager, cameriere, paga oraria e orari di inizio/fine, possiamo poi aggiungere qualsiasi informazione aggiuntiva), e le varie relazioni tra loro (in pratica il "cuore" del database), e quali campi usare come indici e come chiavi, per potere accedere velocemente ai vari parametri. Tutto il resto e' secondario, per esempio quali campi vogliamo assegnare al "cameriere" quali indirizzo, telefono, codice fiscale e via dicendo (sono solo "attributi", ne possiamo mettere quanti vogliamo) Personalmente, vedo il problema implementabile con sole cinque tabelle di base, ovvio che poi lo possiamo fare tanto complicato quanto vogliamo.

Per me l'importante e' fare capire che si ha una conoscenza di cosa sia una tabella, di quali campi assegnare a una tabella, come scegliere tra usare un campo o una tabella, e ovviamente la relazione tra le varie tabelle. Ma ripeto, questo e' quello che che "io" richiedo da un corso di base dati.

Skywalker87
21-09-11, 13: 39
Ti dico subito che in quelle figure io mi perdo, non mi ricordano nessuno dei grafici da me usati per creare lo schema di un database relazionale... sorry. Il problema e' che non so cosa voglia l'insegnante, potresti darci il testo originale del lavoro?

Veramente?! Mi dispiace! :ops: Forse ho fatto male io lo schema. :boh
Per realizzarlo, mi sono attenuto alla “sintassi“ del modello entità-relazione (wiki (http://it.wikipedia.org/wiki/Modello_E-R)) illustrata nei libri di testo che utilizziamo per il corso, che sono:

* Basi di dati - Modelli e linguaggi di interrogazione (http://www.amazon.it/dati-Modelli-linguaggi-interrogazione-College/dp/8838666008/ref=sr_1_3?ie=UTF8&qid=1316552176&sr=8-3)
* Basi di dati - Architetture e linee di evoluzione (http://www.amazon.it/dati-Architetture-evoluzione-Istruzione-scientifica/dp/883866370X/ref=sr_1_4?ie=UTF8&qid=1316552176&sr=8-4)

In breve:

* i rettangoli rappresentano le entità (relation)
* i rombi rappresentano le relazioni (relationship)
* gli attributi vengono rappresentati con il nome, gli attributi identificatori sono in grassetto
* gli identificatori esterni sono evidenziati con delle linee che intersecano gli attributi e le entità chiave


Mi chiedi la “comanda” (giusto per rimanere in tema :tong2) del professore. L'esame consiste in una prova orale; ogni studente deve portare un progetto, che consiste nella realizzazione di un database, dalla progettazione concettuale, fino all'implementazione vera e propria. Il progetto va sviluppato seguendo le linee guida del libro, ovvero:

* raccolta dei requisiti
* progettazione concettuale (da cui si ottiene lo schema concettuale)
* progettazione logica (da cui si ottiene lo schema logico)
* progettazione fisica (da cui si ottiene lo schema fisico)
* seguendo lo schema fisico, si realizza concretamente il database secondo le specifiche del DBMS scelto

Queste linee guida sono tassative. Presentarsi all'esame senza, ad esempio, uno schema concettuale simile a quello che vi ho proposto, comprometterebbe pesantemente l'esito della prova.



Da quello che hai spiegato io partirei con concetti parecchio diversi, per esempio per me la tabella principale e' quello che io chiamerei EVENTO, rappresentato da un contratto di lavoro, con vari parametri: datore di lavoro, agenzia, quanti camerieri ci lavorano, la data (inizio, fine) e la paga oraria di ciascun cameriere (che quindi puo' essere diversa da evento a evento e da cameriere a cameriere) L'evento viene creato da un "manager", che definisce anche i camerieri assegnati e la loro paga oraria. Il cameriere che arriva al lavoro dopo avere fatto login seleziona l'evento e seleziona INIZIO; finito il turno di lavoro, fa ancora login, sceglie lo stesso evento e seleziona FINE, automaticamente il database memorizza gli orari di inizio e fine. Quando l'evento si "chiude" (cosa che deve essere fatta da un manager, o avviene automaticamnte quando la sua data finisce), automaticamente vengono calcolate le paghe dei camerieri che ci hanno lavorato su, in base alla paga oraria e al tempo che hanno lavorato; ovvio che per un evento "chiuso" nessuno puo' aggiungere turni di lavoro. Questo schema permette per esempio al singolo cameriere di lavorare in piu' eventi allo stesso tempo (ovviamente con orari diversi, per esempio uno al mattino e uno al pomeriggio o alla sera)

La tua idea è molto simile alla mia in realtà! :bgg2
L'entità principale che tu chiami EVENTO, io l'ho chiamata semplicemente SERVIZIO. Si compone esattamente come la tua, cioè un'istanza della relazione SERVIZIO sarà composta dai campi:


Only registered members can view code.

più altri campi (come titolo, nota) superflui; id è la chiave della relazione.

Come vedi le nostre idee sono simili. Dove invece non collimano, è su un altro punto. Come avevo già spiegato a pierino_89, sono pienamente d'accordo sul fatto che l'ideale sia che l'agenzia interinale crei il servizio (evento) e poi i camerieri si iscrivano ad esso, compilando esclusivamente l'ora di fine servizio. Ma il programma non è realizzato per l'agenzia, ma per noi camerieri. Quindi sono i camerieri stessi a creare il servizio e a gestirlo.


Vi illustro ulteriormente la situazione attuale, per farvi comprendere meglio perché sto affrontando in questo modo la questione.

Quasi tutti, diciamo pure tutti, i camerieri tengono il conteggio delle proprie ore di lavoro su un foglio di carta o su una tabella excel. Io ad esempio uso excel e questo è un esempio di un resoconto mesile:

http://img16.imageshack.us/img16/5844/lug2011.jpg

L'agenzia (anche se dovrebbe poterlo fare dai contratti) ci chiede di comunicarle il resoconto ogni mese. In questo modo si possono formare delle incongruenze tra i resoconti di più camerieri con servizi in comune.

In pratica con il programma, i camerieri hanno uno strumento per archiviare i servizi e quindi le ore di lavoro, come fanno già. A fine mese ogni cameriere continuerà a comunicare le ore di lavoro, ma tramite il programma, evitando così le incongruenze (teoricamente ovviamente).

Altri vantaggi del programma sono:

* possibilità di informarsi sul datore di lavoro in base ai commenti degli altri utenti
* conoscere in anticipo gli altri camerieri con cui si affronterà il servizio



In base a questo schema possiamo definire poi le altre varie tabelle di cui abbiamo bisogno (le indispensabili sono azienda, manager, cameriere, paga oraria e orari di inizio/fine, possiamo poi aggiungere qualsiasi informazione aggiuntiva), e le varie relazioni tra loro (in pratica il "cuore" del database), e quali campi usare come indici e come chiavi, per potere accedere velocemente ai vari parametri. Tutto il resto e' secondario, per esempio quali campi vogliamo assegnare al "cameriere" quali indirizzo, telefono, codice fiscale e via dicendo (sono solo "attributi", ne possiamo mettere quanti vogliamo) Personalmente, vedo il problema implementabile con sole cinque tabelle di base, ovvio che poi lo possiamo fare tanto complicato quanto vogliamo.

Anche qui la pensiamo sostanzialmente allo stesso modo. Dallo schema che ho fatto, trascurando lo schema logico ed ulteriori raffinamenti, si possono individuare tre tabelle principali (schema scheletro): SERVIZIO, AZIENDA, CAMERIERE. Ne aggiungerei una quarta, cioè INDIRIZZO. Le altre, come hai già detto tu, sono di contorno.
L'applicazione girerebbe alla grande anche con solo queste quattro più una (la tabella PARTECIPAZIONE, relazione molti a molti, tra SERVIZIO e CAMERIERE) tabelle.


Se non ci sono altri dubbi, io proseguirei con lo schema logico. :sisi
Ovviamente se pensate che stia sbagliando tutto fermatemi e fatemelo capire! :thx