[Database] schema E-R

[}gu|do[z]{®©]

di database si parla qui o dovevo postare su programmazione? in caso spostatemi

Devo fare uno schema E-R per l'uni.. l'ho presa un po' sottogamba e mi sono ridotto agli ultimi giorni.. ma sopratutto: non riesco a raccapezzarmi su cosa devo rappresentare come entità e cosa come relazione...

provo a farla breve (riassunto delle specifiche):
--------------------------
Si vuole progettare la base di dati di una rete di agenzie turistiche.

Occorre tenere traccia di tutte le prenotazioni, comprese quelle relative a viaggi già effettuati, con costo complessivo, data completa di partenza, città di partenza. Le prenotazioni possono essere per gruppi, ma vanno registrati tutti i nominativi dei diversi partecipanti.

Si suppone che siano previste le possibilità di prenotare spostamenti, soggiorni e combinazioni di spostamenti e soggiorni in Italia ed all’estero (es. Roma-Parigi; 5 giorni a Parigi; Parigi-Amsterdam; 3 giorni ad Amsterdam; Amsterdam-Roma).

Il soggiorno può essere in albergo o residence, con costo giornaliero che varia con il periodo (alta o bassa stagione) categoria (classica categoria alberghiera da una a cinque stelle) e numero di pasti (colazione, mezza pensione, pensione completa, nulla). I residence possono essere forniti di cucina. Al momento dell’organizzazione del viaggio, il cliente desidera avere una lista di servizi disponibili per ogni albergo o residence.

Sono previsti diversi mezzi di trasporto, con diversi tempi di percorrenza (per semplicità assumiamo che ogni mezzo abbia un proprio tempo di percorrenza sempre uguale per ogni tratta), prezzo e classe di biglietto (a seconda del mezzo possiamo avere classe unica, o due classi).
--------------------------

l'unica cosa di cui sno sicuro è la parte riguardante le strutture alberghiere [2 entità con generalizzazione] e la loro relazione con i servizi

I problemi principali che ho al momento riguardano la relazione madre: la prenotazione.
Ammesso che sia una relazione, come ad intuito credo, cosa deve essere messo in relazione? sicuramente i clienti (tralasciando il problema dei gruppi che vedrò dopo).. e poi? una relazione ternaria con un'entità "soggiorno" ed una "tappe"? e come sarebbero fatte queste?

Gira e rigira, ogni volta che butto giù qualcosa, andando avanti devo cambiare tutto

Suggerimenti please

tnx

[ghety]

L'argomento è complicato ma quello che so è:
entità è una tabella ancora astratta con i suoi attributi (campi)
mentre le relazioni sono le azioni che si possono fare tra le tabelle

Generalmente si fanno 3 "progetti": concettuale (E-R); logico (le relazioni che ci sono); fisico (come realizzare le tabelle e le relazioni)

Spero di non aver detto str...

[Gianni_T]

Io metterei le prenotazioni in una entità (quella principale) con attributi "costo tot", "data partenza" e "città partenza".
La legherei con una relazione "uno a molti" ad una entità "partecipanti". La relazione "uno a molti" ti risolve già il problema dei gruppi.
Poi farei 2 entità: una per gli spostamenti (con attributi "partenza" e "arrivo") ed una per i soggiorni (con attributi città e durata"
Per quanto riguarda l'albergo o residence dovresti vedere se creare una o due entità e legarle all'entità soggiorno. Poiché tutti i servizi sono collegati direttamente alla sistemazione, questi andranno messi come attributi a queste entità.

Per i mezzi di trasporto e le tratte servono altre 2 entità, legate da una relazione che contiene i prezzi dei biglietti come attributi.

E' solo un'idea.

[Fayble]

Io farei così (scusami, rapidissima lettura):

CLIENTE - PRENOTAZIONEC - SOGGIORNO
CLIENTE - APPARTENENZA - GRUPPO
GRUPPO - PRENOTAZIONEG - SOGGIORNO

Queste sono tutte molti a molti.

Poi:

SOGGIORNO - IN - STRUTTURA, TAPPE (ternaria)
STRUTTURA è la generalizzazione di ALBERGO e RESIDENCE
STRUTTURA - PREVEDE - SERVIZIO

Questo schema-scheletro devi poi "aggiustarlo" con i giusti attributi sulle entità ma, anche, sulle relazioni.

[}gu|do[z]{®©]

Originariamente inviato da ghety
L'argomento è complicato ma quello che so è:
entità è una tabella ancora astratta con i suoi attributi (campi)
mentre le relazioni sono le azioni che si possono fare tra le tabelle

Generalmente si fanno 3 "progetti": concettuale (E-R); logico (le relazioni che ci sono); fisico (come realizzare le tabelle e le relazioni)

Spero di non aver detto str...

sì questo lo so.. ma siccome ho poca pratica.. non riesco a tirar fuori no schema decente

per glialtri.. vi ringrazio.. io + o meno avevo tirato fuori qualcosa come quello che dice gianni... stasera sono un po' stanco... domani ci rifletto meglio e se riesco posto un schemino [con cosa li disegno velocemente? senza avere altre funzioni.. mi interessa solo avere i simboli d atrascinare con drag and drop... ] ed eventuali dubbi e perplessità...

danke

[}gu|do[z]{®©]

dunque.. ci sto pensando un pochino.
Anche Fayble c'ha preso un po' con quello che avevo fatto io.. ovvero la seconda parte del suo post...

Cmq oggi ho le idee più chiare.. provo a descrivere cosa ho fatto:

1)gruppi e clienti:

CLIENTE->appartiene->GRUPPO->effettua->PRENOTAZIONE

in maiuscolo le entità, in minuscolo le relazioni...
un cliente che non apparteien ad un gruppo.. formerà un gruppo composto da lui stesso.

L'unica cosa che mi lascia perplesso è che gruppo sarebbe un'entità senza attributi.. e non ha molto senso credo? però non posso mettere l'id del gruppo nella tabella clienti, perchè nel tempo il cliente potrebbe appartenere a diversi gruppi...

forse potrei mettere l'id in prenotazione (idprenotazione, idcliente, idgruppo) visto che avrò un record per ogni cliente..
CLIENTE->effettua->PRENOTAZIONE

giusto? in quel modo sono in grado di fare select che prendano tutti i partecipanti ad un gruppo...
ma non so perchè.. non mi sento sicuro di sta cosa

2)Soggiorno.
come vedete:
PRENOTAZIONE -> soggiorno -> STRUTTURA
???

Sulle strutture alberghiere non ho problemi, esattamente come dice Fayble: generalizzazione e relazione con servizi...
quindi soggiorno avrebbe: idprenotazione, idstruttura, numero di giorni.

3) spostamento
questa è la zona logica dello schema su cui ho più difficoltà.
Istintivamente avevo fatto
PRENOTAZIONE->spostamento e spostamento relazione ternaria tra mezzo e città (due volte, una per partenza ed una per arrivo)... ho preferito creare un'entità città perchè usando un id risolvo le omonimie (roma italia e roma california.. o giù di lì) e perchè anche da altre parti mi è utile (prenotazione è in relazione con città per avere la città di partenza... struttura è in relazione con città per indicare dove si trova la struttura).

Il problema è che così mi viene fuori una tabella spostamento così:
idpren, idmezzo, idcittàpartenza, idcittàarrivo, durata

Ma durata è in funzione SOLO di idmezzo, idcittàpartenza, idcittàarrivo.. che non può essere chiave chiave.... quindi la dipendenza funzionale di cui sopra sarebbe parziale ela base non sarebbe in 3NF... nn è un dramma che non sia in 3NF perchè potrei benissimo fingere, nella relazione, di non essermene accorto prima, e, al momento della verifica della 3NF, scomporre... il che farebbe vedere alla prof che non è uscita bene per caso ma ci ho ragionato. Che dite? secondo voi è meglio questa "finta"?

Quanto alla scomposizione che dovrei fare.. avevo pensato:
PRENOTAZIONE -> comprende -> VIAGGIO -> spostamenti (ternaria come sopra)

Questo mi permetterebbe di avere in spostamenti solo la terna mezzo, partenza, arrivo, e la durata in lro funzione, senza ridondanze... e poi associare id prenotazione con la chiave di spostamento.. ma a questo punto mi sorge il dubbio che spostamento possa diventare un'entità...

Insomma.. questa è la parte che mi intriippa di più.. help!

4) dubbi generali:
Le specifiche richiedono che si possano prenotare tanto solo spostamenti, quandto solo soggiorni, quanto entrambe le cose.... per come hho fatto io sembra fattibile (ho un record in soggiorno solo se la prenotazione comprende il soggiorno etc etc)... ma sembra troppo semplice. C'è qualche cosa che non ho considerato, o era un'informazione che serviva più che altro a "far paura" e confondere un po'?


per ora è tutto.. se riesco posto uno schema più tardi..

[}gu|do[z]{®©]

up

[}gu|do[z]{®©]

[}gu|do[z]{®©]

non mi abbandonate

[Gianni_T]

1)gruppi e clienti:

CLIENTE->appartiene->GRUPPO->effettua->PRENOTAZIONE

in maiuscolo le entità, in minuscolo le relazioni...
un cliente che non apparteien ad un gruppo.. formerà un gruppo composto da lui stesso.

L'unica cosa che mi lascia perplesso è che gruppo sarebbe un'entità senza attributi.. e non ha molto senso credo? però non posso mettere l'id del gruppo nella tabella clienti, perchè nel tempo il cliente potrebbe appartenere a diversi gruppi...

forse potrei mettere l'id in prenotazione (idprenotazione, idcliente, idgruppo) visto che avrò un record per ogni cliente..
CLIENTE->effettua->PRENOTAZIONE

giusto? in quel modo sono in grado di fare select che prendano tutti i partecipanti ad un gruppo...
ma non so perchè.. non mi sento sicuro di sta cosa

CLIENTE->effettua->PRENOTAZIONE
la relazione "effettua" è "molti a uno" risolve intrinsecamente il problema dei gruppi, senza creare un'altra entità, che come hai notato non avrebbe attributi.

2)Soggiorno.
come vedete:
PRENOTAZIONE -> soggiorno -> STRUTTURA
???

Sulle strutture alberghiere non ho problemi, esattamente come dice Fayble: generalizzazione e relazione con servizi...
quindi soggiorno avrebbe: idprenotazione, idstruttura, numero di giorni.

Così come l'hai scritta sembra che "soggiorno" sia una relazione ma dato che deve prendersi l'attributo "numero di giorni" potresti renderla una entità. Infatti se passi al diagramma relazionale soggiorno diventerebbe una tabella.

3) spostamento
...
Che dite? secondo voi è meglio questa "finta"?

No Crea un'entità con città partenza, città arrivo e mezzo come chiave primaria e come ulteriore attributo il tempo e chiamala "SPOSTAMENTO", quindi
PRENOTAZIONE -> effettua -> SPOSTAMENTO
se vuoi puoi usare delle entità città e mezzo di trasporto e legare SPOSTAMENTO a queste
Evita le relazioni ternarie.

4) se PRENOTAZIONE è legata con due distinte relazioni a SOGGIORNO e SPOSTAMENTO