Sinceramente non capisco cosa viene chiesto nell'esercizio 2 in quanto è mia abitudine partire da uno schema ottimale che preveda a monte un cerco carico. L'esercizio 2 implica un'errata progettazione della base dati nell'esercizio 1.

Salve Deramer; salve Spatu; salve Joey Santiago.

Invito caldamente tutti ad una nuova lettura delle Regole del nostro Forum, che prevedono innanzitutto il rispetto degli altri utenti ed interlocutori.

Ho editato le frasi OT lasciando le parti in cui ciascuno ha espresso chiaramente - e con toni consoni al Forum gt - le proprie posizioni sugli aspetti "etici" della discussione.

Vi esorto d'ora in avanti a discutere unicamente gli aspetti tecnici; ulteriori fuori-tema non saranno tollerati.

Grazie della collaborazione e buon proseguimento.

Nella progettazione della base dati, partendo dall'enunciato del problema io creerei sicuramente una tabella libri (iban, titolo, autore, curatore, anno) ed una tabella autori_curatori (codfisc, nome, cognome, telefono). Utilizzo una sola tabella in quanto gli attributi sono gli stessi ed in alcuni casi gli uni possono svolgere l'attività degli altri.
A questo punto vediamo che tra la tabella libri e la tabella autori_curatori sussiste una relazione n:m in quanto un libro ha almeno un autore ed almeno un curatore e lo stesso vale per autori e curatori. Ciò comporta l'introduzione di altre due tabelle di relazione aut_lib (iban_libro, codfisc_aut_cur) e cur_lib (iban_libro, codfisc_aut_cur) che relazionano appunto i libri con i rispettivi autori e curatori.

Grazie mille Deramer
E per quanto riguarda queste richieste:

Inoltre, la casa editrice e ettua le seguenti principali o perazioni con una
certa frequenza (indicata tra parentesi):

         • operazione 1: inserimento di un nuovo libro (5 volte al   giorno);
    

         • operazione 2: stampa di tutti i libri in catalogo (1   volta al giorno);
    

         • operazione 3: stampa di tutti gli autori che scrivono per   la casa editrice (1 volta al giorno).

E questo come l'inserisco?

"Ristrutturare lo schema concettuale dell’esercizio precedente, tenendo conto del carico applicativo indotto dalle operazioni 1,2 e 3, descritte sopra."

Ci sono delle righe di codice in mysql per queste operazioni?

Grazie ancora dell'aiuto

Come ti accennavo in precedenza non mi è ben chiaro cosa si voglia nell'esercizio 2. In pratica si chiede di ristrutturare lo schema concettuale ottenuto nell'esercizio 1 in base all'aumento del carico applicativo. A questo punto prova a postare o a descrivere il modo in cui hai risolto l'esercizio 1 in modo da poterlo migliorare nell'esercizio 2.
Non c'è alcuna riga SQL da scrivere in quanto si parla di schema concettuale che, successivamente (vedi esercizio 3) diventerà uno schma logico e solo in un secondo momento coinvolgerà l'SQL.

La differenza tra il punto 1 e il punto 2 è fondamentale.

Non so quanti di voi abbiamo studiato Basi di Dati ma, in pratica succede che nel primo diagramma E/R realizzato possono esserci delle relazioni non implementabili in SQL o difficilmente mantenibili e usabili (ad. esempio una relazione molti a molti tra due tabelle); proprio per questo si passa ad un raffinamento e ottimizzazione della tabella iniziale, quella richiesta nel punto 2.

Nello specifico se ad esempio nel primo caso hai fatto due tabelle:
-libri
-autori
è ovvio che a primo impatto viene una relazione molti a molti dato che più libri possono essere scritti da più autori e viceversa. Il punto 2 richiede proprio il raffinamento di queste relazioni; ad esempio se tra due tabelle c'è una relazione 1 ad 1 è buona norma inglobare le due tabelle in una soltanto, se c'è una relazione molti a molti è buona norma creare una terza tabella che servirà a "smistare" i dati in maniera da facilitare le query e cosi via.

Allora ragazzi il primo esercizio l'ho svolto (anche graficamente ma qui ve lo scrivo) cosi:

Entità: Libro,Autore,Curatore
Attributi: -Libro (romanzo,saggio,poesia,titolo,autore,curatore,ISBN (autenticatore),anno di edizione)

-Autore (cognome,nome,telefono,codice fiscale(identificatore)
-Curatore(cognome,nome,telefono,codice fiscale(identificatore)

Associazione: Casa editrice

Le cardinalita' non so come scriverle.....

Ora....purtroppo non posso disegnarvi qui il modello E-R....._al modello logico so arrivare..._ma non capisco i comandi di stampa e immissione..._che simboli hanno?_Come li scrivo?

Grazie ancora del supporto!

@dymissy said:

La differenza tra il punto 1 e il punto 2 è fondamentale.

Non so quanti di voi abbiamo studiato Basi di Dati ma, in pratica succede che nel primo diagramma E/R realizzato possono esserci delle relazioni non implementabili in SQL o difficilmente mantenibili e usabili (ad. esempio una relazione molti a molti tra due tabelle); proprio per questo si passa ad un raffinamento e ottimizzazione della tabella iniziale, quella richiesta nel punto 2.

Nello specifico se ad esempio nel primo caso hai fatto due tabelle:
-libri
-autori
è ovvio che a primo impatto viene una relazione molti a molti dato che più libri possono essere scritti da più autori e viceversa. Il punto 2 richiede proprio il raffinamento di queste relazioni; ad esempio se tra due tabelle c'è una relazione 1 ad 1 è buona norma inglobare le due tabelle in una soltanto, se c'è una relazione molti a molti è buona norma creare una terza tabella che servirà a "smistare" i dati in maniera da facilitare le query e cosi via.

Quanto dici è corretto, ma la domanda dell'esercizio è mal posta in quanto chiede di ristrutturare lo schema concettuale sulla base di tre operazioni che nulla hanno a che vedere con un'eventuale modifica di tale schema. La modifica può avere un senso al subentrare di nuove condizioni o relazioni tra le entità e non in base al numero di inserimenti o ricerche effettuate sulla base dati.

In effeti ho omesso parte del concetto.

Io ho interpretato il punto 2 in questa maniera:

"Ristrutturare il diagramma E/R affinchè si ottimizzino le operazioni x,y".

Ovvero, ristrutturare il diagramma affinchè le query per le operazioni x,y siano più veloci. Volendo essere più precisi, la struttura deve consentire l'esecuzione di determinate operazioni con meno query possibili.

Un database progettato in maniera da facilitare l'inserimento di un libro penalizzando le prestazioni per la stampa di tutti gli autori è un database che soddisfa tale richiesta. E' pur vero però che in questo caso le tabelle sono talmente poche che un'effettiva ottimizzazione nemmeno la si nota.

@spatu said:

...
Entità: Libro,Autore,Curatore
Attributi: -Libro (romanzo,saggio,poesia,titolo,autore,curatore,ISBN (autenticatore),anno di edizione)

-Autore (cognome,nome,telefono,codice fiscale(identificatore)
-Curatore(cognome,nome,telefono,codice fiscale(identificatore)
...

Una prima modifica andrebbe effettuata all'entità Libro. Non è corretto inserire un attributo per ciascuna tipologia (se esse aumentassero oppure mutassero dovresti modificare l'entità). Sarebbe più corretto inserire un attributo tipologia ad una nuova entità Tipologia con una relazione 1:1, oppure inserire direttamente la tipologia di libro (Romanzo, Saggio o Poesia) all'interno di tale attibuto.
Inoltre la relazione esistente tra le entità Libro, Autore e Curatore è di n:m
per cui è necessaria l'introduzione di una terza entità che relazioni le entità Libro ed Autore e un'altra per relazionare le entità Libro e Curatore.
Ancora, le entità Autore e Curatore sono praticamente identiche inoltre (come da enunciato del problema) un autore può essere anche curatore e viceversa, per cui io non distinguerei tra Autori e Curatori, ma farei un unica entità (ad esempio Aut_Cur)
Quindi:
Libro (iban, titolo, tipologia, autore, curatore, anno), Aut_Cur (codfisc, nome, cognome, telefono) ed infine le due entità di relazione Aut_Lib (iban_libro, codfisc_aut_cur) e Cur_Lib (iban_libro, codfisc_aut_cur).