Progettazione Logica [MYSQL]

[Terminator3018]

Ciao a tutti. Son nuovo di questo forum (e spero di rimanerci a lungo).:P
Ho una domanda davvero stupida da porvi.
In una progettazione di un database , quando si ha una relazione ad esempio 1:1 , e abbiamo una relazione con attributi , quando si passa allo schema logico viene creata anche la tabella della relazione con i relativi attributi??(senza chiave primaria?).
Ringrazio in anticipo :)

[paradise138]

se non ho capito male, devi passare da uno schema concettuale a uno relazionale :)
in questo caso si.. per ogni associazione su un diagramma (ER o EER) costruisci una relazione (tabella) che contiene tutti gli attributi dell'associazione di partenza

[Terminator3018]

Anche se non ci sono attributi chiave(o chiavi primarie) ?

[paradise138]

si.. se non hai chiave nel diagramma avrai un'entità debole, che si traduce sempre come una tabella, specificando però le chiavi esterne (ci saranno spero :D ) la chiave primaria della tabella appena creata sarà la combinazione delle chiavi primarie "proprietarie", quelle sulle quali vai a fare la chiave esterna, più la chiave parziale dell'entità che hai appena tradotto (se esiste).. se sono stato poco chiaro fermami ;)

[Terminator3018]

Per chiave parziale intendi la chiave dell'entità a cui l'entità debole è collegata?
Mi stai dicendo che , se una relazione non ha chiavi primarie ma comunque un attributo o piu' , essa sarà perforza collegata ad un entità debole?

[Terminator3018]

Ad esempio :
Ho fatto bene il passaggio da schema E/R a Schema Logico di queste 2 progettazioni concettuali? Ti ringrazio per la pazienza.:)

Foto riuppate sotto *

[Terminator3018]

Riuppo perchè tinypic mi aveva cancellato le foto -.- :

Schema 1 :

http://i39.tinypic.com/14jrx41.jpg

Schema 2 :

http://i44.tinypic.com/a0gnbc.jpg


Perfavore potreste aiutarmi? :(

[demos88]

così come li hai scritti sono entrambi sbagliati, in quanto la tabella che ricavi dalla relazione non ha chiavi valide. Infatti tipicamente le relazioni 1 a N si risolvono accorpando gli attributi della relazione all'entità che concorre con 1 istanza. Ovvero:
CARROZZA(numero, id_treno, merce_trasportata)
TRENO(id, nome_guidatore)

Nel secondo caso hai una relazione 1-1, nel quale però l'entità BICI partecipa con cardinalità (0,1)
Questo porterà probabilmente a valori NULL in caso di accorpamento.
E' anche da notare che potresti voler tener traccia dei dati dei noleggi passati; dallo schema non si capisce, anche se quel (1,1) al cliente mi suggerisce di no. Io comunque metterei la partecipazione di cliente come (0,N) così da poter permettere che un cliente può noleggiare più bici contemporaneamente o non noleggiarne nessuna (magari l'hai solo inserito nella base di dati, o, nel caso in cui non memorizzi i noleggi passati, semplicemente non ha nessun noleggio attivo). Sono quasi certo che la cardinalità di quella relazione non è concettualmente corretta.
Se ti interessa tenere in ogni istante le informazioni relative solo all'attuale stato di noleggio delle bici, allora puoi accorpare Data e Ora di noleggio nell'entità BICI con buona pace dei valori NULL.
Altrimenti, per una soluzione più completa, puoi creare una terza entità NOLEGGIO che poi puoi gestire come ti pare.
Se vuoi conservare solo lo stato istantaneo dei noleggi, puoi usare come chiave l'id della bici:
BICI (numero, tipo)
CLIENTE (id)
NOLEGGIO (id_bici, id_cliente, data, ora)
In questo caso memorizzi un solo noleggio alla volta per ogni bici (ovvero solo il noleggio in corso), nota che BICI e NOLEGGIO hanno la stessa chiave, quindi, volendo potresti accorparli come ho scritto sopra.
Se vuoi memorizzare anche i noleggi passati (questo prevede partecipazione 0,N di cliente), semplicemente estendi la definizione di chiave anche all'ora e alla data (in quanto consideri impossibile noleggiare la stessa bici lo stesso giorno alla stessa ora a due clienti diversi:
BICI (numero, tipo)
CLIENTE (id)
NOLEGGIO (id_bici, id_cliente, data, ora)

[Terminator3018]

Non sò come ringraziarti :) :) :)