.dsy:it. - Progetto Basi 2011/2012

Pages (12): « 1 2 3 [4] 5 6 7 8 » ... Last »
Show 150 posts per page

.dsy:it. (http://www.dsy.it/forum/)
- Basi di dati ~ informatica triennale (http://www.dsy.it/forum/forumdisplay.php?forumid=211)
-- Progetto Basi 2011/2012 (http://www.dsy.it/forum/showthread.php?threadid=42537)

Posted by number15 on 03-01-2012 12:05:

Originally posted by pintu
@SanJuanWolf89: io ho messo l'attributo "contratto" nella tabella annuncio e ho creato la tabella CONTRATTO con due attributi...codice_contratto e tipo_contratto. Però non so mi sembra uno spreco..Alla fine i tipi di contatto sono solo affitto e vendita..Quindi magari sarebbe più sensato dare all'attributo contratto quel dominio! Io ne ho creata una a parte per la categoria

Prendilo con le pinze perché come detto non sto facendo il progetto, quindi ho una visione relativa dell'insieme, però potrebbe essere uno spunto.

Direi che la tabella contratto per la tipologia di annuncio è superflua, visto che non ha attributi particolari. Lo vedrei più come un equivalente di tipo_utente (quindi campo enum('affitto', 'vendita').

ANNUNCIO(id_annuncio, titolo, descrizione, tipo_contratto, id_pubblicatore_annuncio, id_unita_immobiliare, prezzo, data_pubblicazione, data_scadenza)
Eventualmente:
AFFITTO(id_annuncio, attributi_esclusivi_di_affitto)
VENDITA(id_annuncio, attributi_esclusivi_di_vendita)

Ripeto, solo a fini di discussione, non so poi se i campi son corretti (cardinalità ecc).

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by pintu on 03-01-2012 12:08:

Aspè non ho capito..ti riferisci alla parte dei criteri di similarità?

Posted by number15 on 03-01-2012 12:11:

No, parlo in generale.

Ps. mandami pm con msn o skype che se vuoi dopo pranzo ti aggiungo e ti chiarisco un paio di cose, così velocizziamo la discussione (oggi pomeriggio devo per forza mettermi a far progetto di algo )

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by pintu on 03-01-2012 16:20:

la domanda era riferita a SanJuanWolf89 Per quello che gli hai risposto tu sono d'accordo sul fatto che sia abbastanza inutile la tabella CONTRATTO anche se io l'ho fatta all'inizio.. Cmq una volta terminato lo schema er e concettuale provo a fartelo vedere cosi magari uso i tuoi preziosi consigli

PS: è già uscito il progetto di algoritmi??

Posted by number15 on 03-01-2012 16:29:

Ah ok

Comunque se sei ancora alla schema ER basta che ci metti una croce sopra a CONTRATTO e bon
In generale comunque lo schema ER cerca di tenerlo il più semplice possibile... esplichi poi tutto meglio effettuando le dovute trasformazioni nel relazionale

Se ho tempo ti aiuto volentieri, è l'unico esame che mi è piaciuto e ho trovato utile.

PS: si, ultimo appello di Torelli per i fuoricorso. Il nuovo appello deve ancora uscire e prevede mi pare dei compitini.

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by SanJuanWolf89 on 04-01-2012 09:19:

sisi cmq lo so k e abbastanza inutile xo mi e servita x la questione dei cluster..perchè ho deciso di raggruppare per tipo contratto e costo immobile quindi per definire i parametri mi serviva una tabella tipo contratto..

Posted by number15 on 04-01-2012 09:31:

Tecnicamente cosa intendete con cluster? SOn delle 'viste materializzate'?

In ogni caso mi sfugge come una tabella CONTRATTO, usata per specificare le tipologie di contratto possibili, ti possa risolvere di problemi... dovrai sempre avere una chiave esterna in ANNUNCIO per specificare il tipo di contratto su cui joinnare la tabella CONTRATTO.

A quel punto tanto vale usare un campo enum tipo_contratto in annuncio e arrivi alla stessa situazione.

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by Shaper on 04-01-2012 20:08:

Ciao a tutti, mi aggiungo anch'io a questa conversazione e riporto l'attenzione sulla questione "categorie"

Non mi è molto chiaro cosa intende il testo quando scrive "Le categorie possono avere caratteristiche specifiche"
Per esempio la categoria "condominio" avrà la caratteristica "presenza del portiere", mentre quella "ufficio" avrà la caratteristica "numero di prese ethernet" (sto sparando a caso)?
Quindi in pratica la categoria influenza il numero e tipo di attributi di un annuncio?
Anche voi l'avete interpretata così? E nel caso come si descrive questa situazione mediante un diagramma ER o relazionale?

__________________
Eidolon64|Blog

Posted by number15 on 04-01-2012 20:57:

Ciao, dai un occhio alla pagina precedente in cui se n'è discusso un minimo.

La questione è spinosa. Io risolverei 'adattando' le specifiche (senza senso) ad una implementazione più sensata.

Dato che non è chiaro dalle specifiche io farei la divisione come attico.it usando categoria come categoria e tipologia come caratteristiche

Un paio di domande (sperando di non incasinarti ancora di più le idee

)
Tu hai creato un'entità 'IMMOBILE' o fai tutto dentro ANNUNCIO?

Ad esempio se dovessi farlo io penserei ad una struttura del tipo:
IMMOBILE(id_immobile, lat, lon, indirizzo, id_città, id_categoria, ecc)
ANNUNCIO(id_annuncio, id_immobile, data di pubblicazione, titolo, descrizione, id_pubblicatore_annuncio, prezzo ecc)

Quindi io già di base molto probabilmente categoria la assocerei ad IMMOBILE e non ad ANNUNCIO.

Detto questo, per farlo come lo stai pensando tu valuterei queste possibilità:
- specializzazione di IMMOBILE in diverse tipologie, quindi vai a creare altre entità del tipo MONOLOCALE, BILOCALE, ATTICO, UFFICIO ecc oppure raggruppando mono, bilo, tri ecc sotto un'entità del tipo APPARTAMENTO con poi all'interno un campo tipo_appartamento.
In queste nuove tabelle ci saranno gli attributi esclusivi per le varie tipologie di immobile.

- unica tabella IMMOBILE con id_categoria e tutti i campi per le eventuali caratteristiche aggiuntive (che saranno NULL per le categorie non interessate).
Faccio esempio va: IMMOBILE(......, id_categoria, ha_ascensore(Y, N, NULL), ha_portineria(Y,N,NULL) ecc)

In più avrai la tabella CATEGORIA(id_cat, categoria), una tabella CARATTERISTICHE(id_cara, caratteristica) e una tabella che associa le caratteristiche alle opportune categorie (che puoi usare per vedere quali caratteristiche mostrare nel form a seconda della categoria)

Tutto comunque dipende da quali caratteristiche aggiuntive sensate si riescono a trovare e poi decidere:
1) se sono tante ed esclusive valuterei la prima opzione
2) se sono poche e/o comuni valuterei la seconda

Spero di essere stato abbastanza chiaro e che il tutto abbia senso

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by Shaper on 04-01-2012 21:23:

Grazie, sei stato molto chiaro!
A naso io preferirei la seconda opzione, alla fine non dovrebbero venire fuori tante categorie diverse, né cambiare molto col tempo (pensando all'espandibilità)

__________________
Eidolon64|Blog

Posted by number15 on 04-01-2012 21:30:

Si, direi che è la scelta più sensata.

Vedi tu se associarla ad annuncio o ad immobile, anche se le specifiche sembrano abbastanza propense verso annuncio, ma per me è sbagliato

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by Shaper on 04-01-2012 21:32:

Originally posted by number15
Si, direi che è la scelta più sensata.

Vedi tu se associarla ad annuncio o ad immobile, anche se le specifiche sembrano abbastanza propense verso annuncio, ma per me è sbagliato

Sì, infatti io ero partito con l'idea di fare tutto dentro ANNUNCIO, ma in effetti ora che mi ci fai pensare ha molto più senso dividere ANNUNCIO e IMMOBILE!

__________________
Eidolon64|Blog

Posted by number15 on 04-01-2012 21:41:

Nelle specifiche non sembra esser richiesto, ma mi sembra scelta saggia

Già solamente nel caso decidessi di mettere in vendita e in affitto lo stesso immobile oppure di rimettere in vendita lo stesso immobile dopo la scadenza del primo annuncio dovresti riscrivere in annuncio tutti i campi (che saranno una decina) relativi a quell'immobile (tra l'altro a rischio violazione della 3° forma normale)

Ma poi proprio concettualmente sono entità diverse!

__________________
Portale segnalazioni marchi-negozi di abbigliamento
http://www.ovojo.com

Posted by SanJuanWolf89 on 06-01-2012 10:58:

Ha tutto molto senso xo scusa quando un utente inserisce un annuncio cosa succede..si va a inserire una tupla sia in IMMOBILE, sia in ANNUNCIO??

La tua idea quindi e di tenere due relazioni,una x gli annunci visibili (ANNUNCIO) e una per tutti gli immobili..ma non si crea un po d confusione cosi??Soprattutto per quanto riguarda le funzioni di ricerca e di clustering. X me esce un po dagli schemi anke xk il testo parla esplicitamente di annuncio, cioe la fa mooolto piu facile di cosi anche se è un ottima idea.

Posted by SanJuanWolf89 on 06-01-2012 11:03:

Guarda t propongo una soluzione
tabella annuncio(
id, titolo, citta, categoria, lat, lon, costo, prezzo, ecc ecc)

tabella caratteristiche(
id_annuncio, portineria, giardino, ecc ecc
)

in questo modo non suddividi troppo annuncio da immobile

All times are GMT. The time now is 16:00.

Pages (12): « 1 2 3 [4] 5 6 7 8 » ... Last »
Show all 167 posts from this thread on one page