progettazione schema er

[thaiboxer89]

a scopo didattico stiamo facendo la progettazione di una base di dati, ora ho disegnato lo schema er, vi riporto la consegna, potreste dirmi se il mio schema ER presenta incorrettezze o ridondanze?
successivamente devo tradurlo in shcema logico ma per il momento mi interessa completare questo step
testo:
"Si vuole realizzare la base di dati per la gestione di una piattaforma in cui gli utenti
possono caricare, salvare e gestire immagini (si veda il file foto.pdf​), organizzandole in
contenitori dette bacheche (si veda il file board.pdf​).
Le immagini possono essere di proprietà dell’utente o scaricate da pagine web.
I contenuti che vengono manipolati dagli utenti possono essere sfogliati nella pagina
principale (si veda il file utente.pdf che mostra un esempio di pagina principale
associata ad un utente). Gli utenti possono quindi salvare con "pin" (puntine) le
immagini ad una delle loro tavole.
Nella piattaforma le foto sono anche organizzate in categorie (topic, si veda il file
topic.pdf​) che forniscono un sistema di navigazione articolato in modo da aiutare gli
utenti a condividere interessi.
Per ogni topic vengono segnalati topic simili: 2 topic si definiscono simili se e solo se
almeno il 20% degli utenti possiede immagini di entrambi topic in una delle proprie
bacheche.
Quando un utente disattiva il proprio profilo vengono cancellati tutti i pannelli da lui
creati e le foto di cui e’ proprietario."

qui trovate board.pdf : http://s32.postimg.org/j5776vqo5/board.jpg
foto.pdf: http://s32.postimg.org/5zedex9l1/foto.jpg
utente.pdf: http://s32.postimg.org/iinhw8p8l/utente.jpg
topic.pdf: http://s32.postimg.org/yy8izvykl/topic.jpg


qui il mio schema er che ho fatto: http://s32.postimg.org/dtbccv2dh/schema_ER.png

[pgcor]

Ciao
Allora cominciamo.
Non ho capito bene perchè hai messo che una board/bacheca (vedi tu se preferisci che ci riferiamo ai nomi in italiano o in inglese) può anche non avere creatori.
Stesso discorso per le varie associazioni tra Utente e Foto: non so se sia possibile che una foto non sia caricata da nessun utente (boh magari è caricata di default già dalla creazione dagli amministratori del sito, ma questo lo devi vedere tu, se il testo è precisamente quello che hai postato, io sarei propenso per il no).
Non mi piace troppo il fatto che tra Utente e Foto ci siano le due associazioni Caricamento utente e Caricamento web: non so se hai già trattato l'argomento del DBMS e penso di SQL: pensando al futuro, e quindi alla gestione del database, a me non piacerebbe dover eseguire ogni volta il controllo se la foto sia presente in una oppure nell'altra tabella generata dall'associazione N-N.
Mi sembra ridondante l'associazione Gestione: il proprietario della foto lo vedi di già dall'associazione Caricamento utente .
Di getto, ho fatto uno schema così:


Mi rendo conto che è una notazione diversa rispetto a quella che hai usato tu, ma se vuoi imparare a progettare database, meglio che impari pure questa ci sono passato anch'io
Praticamente la linea tratteggiata tra due entità è lo stesso che il tuo scrivere 0 come primo elemento della cardinalità. Ti faccio un esempio: l'associazione Organizza, tra Utente e Bacheca: un utente può creare N bacheche, ma anche non crearne nessuna. Una bacheca può avere un solo utente come creatore.
Oppure l'associazione Like tra Utente e Foto: un utente può mettere "like" a N foto, ma anche a nessuna, e una foto può avere il "like" di N utenti, ma anche di nessun utente.
Ti chiedo scusa, avrei potuto usare anche la tua stessa notazione, ma ho cominciato a farlo leggendo il post, e solo dopo, a progettazione inoltrata, ho guardato il tuo modello
Mi rendo anche conto che è un po' incasinato

Per quanto riguarda il caricamento dell'immagine da parte di un utente, io userei una sola associazione, e nell'attributo Fonte dell'entità Foto, specificherei: il valore 0, o comunque un valore noto che non possa essere interpretato come URl, se l'immagine è stata caricata direttamente dall'utente; altrimenti, vi inserirei il link di provenienza.

In Utente, va da sé che come chiave primaria puoi benissimo usare la mail, lo deciderai tu, io avevo scritto username sempre per il discorso che il tuo modello l'ho guardato dopo.


Se non capisci qualcosa, naturalmente sono disponibile per chiarimenti altrimenti domani con calma ti ridisegno il modello usando la tua stessa notazione.

[thaiboxer89]

Ciao
Allora cominciamo.
Non ho capito bene perchè hai messo che una board/bacheca (vedi tu se preferisci che ci riferiamo ai nomi in italiano o in inglese) può anche non avere creatori.
Stesso discorso per le varie associazioni tra Utente e Foto: non so se sia possibile che una foto non sia caricata da nessun utente (boh magari è caricata di default già dalla creazione dagli amministratori del sito, ma questo lo devi vedere tu, se il testo è precisamente quello che hai postato, io sarei propenso per il no).
Non mi piace troppo il fatto che tra Utente e Foto ci siano le due associazioni Caricamento utente e Caricamento web: non so se hai già trattato l'argomento del DBMS e penso di SQL: pensando al futuro, e quindi alla gestione del database, a me non piacerebbe dover eseguire ogni volta il controllo se la foto sia presente in una oppure nell'altra tabella generata dall'associazione N-N.
Mi sembra ridondante l'associazione Gestione: il proprietario della foto lo vedi di già dall'associazione Caricamento utente .
Di getto, ho fatto uno schema così:


Mi rendo conto che è una notazione diversa rispetto a quella che hai usato tu, ma se vuoi imparare a progettare database, meglio che impari pure questa ci sono passato anch'io
Praticamente la linea tratteggiata tra due entità è lo stesso che il tuo scrivere 0 come primo elemento della cardinalità. Ti faccio un esempio: l'associazione Organizza, tra Utente e Bacheca: un utente può creare N bacheche, ma anche non crearne nessuna. Una bacheca può avere un solo utente come creatore.
Oppure l'associazione Like tra Utente e Foto: un utente può mettere "like" a N foto, ma anche a nessuna, e una foto può avere il "like" di N utenti, ma anche di nessun utente.
Ti chiedo scusa, avrei potuto usare anche la tua stessa notazione, ma ho cominciato a farlo leggendo il post, e solo dopo, a progettazione inoltrata, ho guardato il tuo modello
Mi rendo anche conto che è un po' incasinato

Per quanto riguarda il caricamento dell'immagine da parte di un utente, io userei una sola associazione, e nell'attributo Fonte dell'entità Foto, specificherei: il valore 0, o comunque un valore noto che non possa essere interpretato come URl, se l'immagine è stata caricata direttamente dall'utente; altrimenti, vi inserirei il link di provenienza.

In Utente, va da sé che come chiave primaria puoi benissimo usare la mail, lo deciderai tu, io avevo scritto username sempre per il discorso che il tuo modello l'ho guardato dopo.


Se non capisci qualcosa, naturalmente sono disponibile per chiarimenti altrimenti domani con calma ti ridisegno il modello usando la tua stessa notazione.

ti ringrazio [per il tuo prezioso aiuto e ti chiedo scusa se ti rispondo solo ora, volevo chiederti delle cose:
- io nell' utente ho dimenticato di mettere la relazione ricorsiva follower e following con se stesso, nel caso un utente sia seguito o segue altri utenti, ho notato che tu non hai messo questa relazione.
- la linea non tratteggiata, equivale a 1?
- in questo schema noto che ci sono delle line una sopra l'altra con delle gobbe, non significa niente vero? scusa per la domanda stupida

Per il resto quello che mi hai scritto e' tutto molto chiaro

[pgcor]

- io nell' utente ho dimenticato di mettere la relazione ricorsiva follower e following con se stesso, nel caso un utente sia seguito o segue altri utenti, ho notato che tu non hai messo questa relazione.

A dire il vero non vedo questa opzione nel testo dell'esercizio.. Ma in caso basta fare una relazione che da Utente va ad Utente, naturalmente un utente può seguire minimo zero - massimo N altri utenti, mentre un utente può essere seguito da minimo zero - massimo N utenti.

- la linea non tratteggiata, equivale a 1?

In pratica la linea tratteggiata indica che il minimo è 1, mentre il massimo è da specificare (o equivale anch'esso ad 1, oppure ad N).

- in questo schema noto che ci sono delle line una sopra l'altra con delle gobbe, non significa niente vero? scusa per la domanda stupida

Ma figurati il forum è fatto apposta
Sì le gobbe sono una mia cosa che uso per non accavallare le varie linee e mantenere una parvenza d'ordine (anche se i miei schemi sono sempre molto aggrovigliati )

[thaiboxer89]

- io nell' utente ho dimenticato di mettere la relazione ricorsiva follower e following con se stesso, nel caso un utente sia seguito o segue altri utenti, ho notato che tu non hai messo questa relazione.

A dire il vero non vedo questa opzione nel testo dell'esercizio.. Ma in caso basta fare una relazione che da Utente va ad Utente, naturalmente un utente può seguire minimo zero - massimo N altri utenti, mentre un utente può essere seguito da minimo zero - massimo N utenti.

- la linea non tratteggiata, equivale a 1?

In pratica la linea tratteggiata indica che il minimo è 1, mentre il massimo è da specificare (o equivale anch'esso ad 1, oppure ad N).

- in questo schema noto che ci sono delle line una sopra l'altra con delle gobbe, non significa niente vero? scusa per la domanda stupida

Ma figurati il forum è fatto apposta
Sì le gobbe sono una mia cosa che uso per non accavallare le varie linee e mantenere una parvenza d'ordine (anche se i miei schemi sono sempre molto aggrovigliati )

scusa se ti disturbo ancora! avrei bisogno del tuo prezioso aiuto!
ho creato lo schema logico:

utente(email,nome,cognome,data_nascita,foto_profilo)
follow_board(utente,bacheca)
organizazione_board(utente,bacheca)
likes(utente,foto)
caricamento_foto(utente,foto)
pin(utente,foto,data_pin)
contenimento_foto_board(bacheca,foto)
foto(id,fonte,descrizione)
appartenenza_foto_topic(foto,topic)
topic(id,titolo)
correlazione_topic(topic,topic_simile)
bacheca(id,titolo)

e ho steso il codice su postgres

Codice: Seleziona tutto

create table follow_board (
 utente varchar(25),
 bacheca bigint,
 primary key(utente,bacheca)
);



          

          create table organizazione_board(
          utente varchar (25),
          bacheca bigint,
          primary key(utente,bacheca)
          );

          create table likes (
          utente varchar (25),
          foto bigint,
          primary key(utente,foto)
          );

          create table caricamento_foto (
          utente varchar (25),
          foto bigint,
          primary key(utente,foto)
          );

          create table pin (
          utente varchar (25),
          foto bigint,
          data_pin timestamp(2) not null,
          primary key(utente,foto)
          );
          
          create table contenimento_foto_board (
          bacheca bigint,
          foto bigint,
          primary key(bacheca,foto)
          );

          create table appartenenza_foto_topic (
          topic bigint,
          foto bigint,
          primary key(topic,foto)
          );

          create table correlazione_topic(
          topic bigint,
          topic_simile bigint,
          primary key (topic,topic_simile)
          );
          
          create table utente(
email varchar (25) not null,
nome varchar (20) not null,
cognome varchar (20) not null,
data_nascita date not null,
foto_profilo varchar(255),
primary key(email),
          foreign key(email) references follow_board (utente)
          on delete no action,
          foreign key(email) references organizazione_board (utente)
          on delete no action,
          foreign key(email) references likes (utente)
          on delete no action,
          foreign key(email) references caricamento_foto (utente)
          on delete no action,
          foreign key(email) references pin (utente)
          on delete no action 
          );

          create table bacheca(
id bigint,
titolo varchar (30) not null,
primary key(id),
          foreign key(id) references follow_board (bacheca)
          on delete no action,
          foreign key(id) references organizazione_board (bacheca)
          on delete no action,
          foreign key(id) references contenimento_foto_board (bacheca)
          on delete no action
          );


          create table foto(
          id bigint,
          fonte varchar(255) not null,
          descrizione varchar(255),
          primary key(id),
          foreign key(id) references likes (foto)
          on delete no action,
          foreign key(id) references caricamento_foto (foto)
          on delete no action,
          foreign key(id) references pin (foto)
          on delete no action,
          foreign key(id) references caricamento_foto_board (foto)
          on delete no action,
          foreign key(id) references appartenenza_foto_topic (foto)
          on delete no action
          );

          create table topic (
          id bigint,
          titolo varchar(30) not null,
          primary key (id),
          foreign key(id) references correlazione_topic (topic)
          on delete no action
          );

          create table bacheca (
          id bigint,
          titolo varchar(30) not null,
          primary key (id),
          foreign key(id) references follow_board (bacheca)
          on delete no action,
          foreign key(id) references organizazione_board (bacheca)
          on delete no action,
          foreign key(id) references contenimento_foto_board (bacheca)
          on delete no action
          );

quando vado per eseguire mi riporta questo errore:
ERRORE: non c'è alcun vincolo univoco che corrisponda alle chiavi indicate per la tabella referenziata "follow_board"
********** Error **********

ERRORE: non c'è alcun vincolo univoco che corrisponda alle chiavi indicate per la tabella referenziata "follow_board"
SQL state: 42830

cosa potrebbe essere? oltre questo secondo te come ho scritto il codice può andare bene o dovrei aggiungere altro?


un ultima domanda avrei che non capisco come risolverla, come posso rappresentare un topic simile? non riguarda più a livelo di ddl ma a livello di dml?
ti riporto qua tutta la consegna dell'esercizio così puoi comprendere anche tu

Schema guida:
1. Progettazione concettuale
1.1. Requisiti iniziali
1.2. Glossario dei termini
1.3. Requisiti rivisti
1.4. Requisiti strutturati in gruppi di frasi omogenee
1.5. Analisi di coerenza dei requisiti ristrutturati rispetto al glossario
1.6. Schema E­R + regole aziendali
1.7. Autovalutazione dello schema E­R (+ business rules):
1.7.1. Correttezza: controllare se i costrutti sono usati propriamente.
Inoltre nella stesura dello schema E­R non bisogna considerare come verrà
tradotto in relazionale (evitate errori come: omettere gli identificatori delle entità,
aggiungere identificatori alle associazioni, aggiungere alle associazioni gli
identificatori delle entità coinvolte, non indicare il tipo di generalizzazione, dare lo
stesso nome a due entità o associazioni, riportare come business rule
un’informazione che può essere rappresentata nell’E­R, usare un identificatore
esterno basato su associazioni non (1,1) o un identificatore basato su attributi
opzionali o multivalore)
1.7.2. Completezza: rileggere i requisiti iniziali e considerare se ogni
informazione rilevante è stata rappresentata nelle entità, associazioni, attributi,
identificatori, cardinalità dell’E­R o nelle business rules. Verificare la coerenza
degli identificatori delle entità e delle sottoentità gerarchiche con i requisiti
riscritti.
1.7.3. Leggibilità: L’E­R è intuitivo? I nomi dati alle entità/associazioni
sono facilmente comprensibili? È chiaro cosa rappresentano?
1.7.4. Minimalità: Sono presenti ridondanze indesiderate? È possibile
rappresentare le stesse informazioni in modo più semplice?
2. Progettazione logica
2.1. Tavola dei volumi (motivare le scelte effettuate)
2.2. Tavola delle operazioni (basandosi anche sui requisiti includere le operazioni
piu’ rilevanti e motivare le scelte effettuate)
2.3. Ristrutturazione dello schema E­R
2.3.1. Analisi delle ridondanze
Per ogni ridondanza:
per ogni operazione significativa su cui la presenza/assenza della ridondanza
può avere effetto:
● Schema di operazione in presenza e in assenza di ridondanza
● Tavola degli accessi in presenza e in assenza di ridondanza
● Confronto in spazio e tempo tra presenza e assenza di ridondanza
● Scelta se introdurre o non introdurre la ridondanza con motivazione
2.3.2. Eliminazione delle generalizzazioni (motivare le scelte effettuate)
2.3.3. Eventuale partizionamento/accorpamento di entità e associazioni
(motivare le scelte effettuate)
2.3.4. Eventuale scelta degli identificatori principali (motivare le scelte effettuate)
2.4. Schema E­R ristrutturato + regole aziendali
2.5. Schema relazionale (indicare anche i vincoli di integrità referenziale)
3. DDL di creazione del database
4. DML di popolamento di tutte le tabelle del database (se popolate il database con dati
verosimili potreste rendervi conto di errori commessi nella fase di progettazione
concettuale e di cui avreste dovuto rendervi conto prima)
5. Qualche operazione di cancellazione e modifica per verificare i vincoli ed effetti
causati da operazioni su chiavi esterne.
Requisiti iniziali
Si vuole realizzare la base di dati per la gestione di una piattaforma in cui gli utenti
possono caricare, salvare e gestire immagini (si veda il file foto.pdf​), organizzandole in
contenitori dette bacheche (si veda il file board.pdf​).
Le immagini possono essere di proprietà dell’utente o scaricate da pagine web.
I contenuti che vengono manipolati dagli utenti possono essere sfogliati nella pagina
principale (si veda il file utente.pdf che mostra un esempio di pagina principale
associata ad un utente). Gli utenti possono quindi salvare con "pin" (puntine) le
immagini ad una delle loro tavole.
Nella piattaforma le foto sono anche organizzate in categorie (topic, si veda il file
topic.pdf​) che forniscono un sistema di navigazione articolato in modo da aiutare gli
utenti a condividere interessi.
Per ogni topic vengono segnalati topic simili: 2 topic si definiscono simili se e solo se
almeno il 20% degli utenti possiede immagini di entrambi topic in una delle proprie
bacheche.
Quando un utente disattiva il proprio profilo vengono cancellati tutti i pannelli da lui
creati e le foto di cui e’ proprietario.
Nota ​L’esercizio e’ ispirato alla piattaforma https://it.pinterest.com/

grazie ancora per tutto!

[thaiboxer89]

ti aggiorno! inserendo unique nei campi giusti e correggendo un errore di distrazione ora il codice viene eseguito

Codice: Seleziona tutto

create table follow_board (
 utente varchar(25) unique,
 bacheca bigint unique,
 primary key(utente,bacheca)
);



          

          create table organizazione_board(
          utente varchar (25) unique,
          bacheca bigint unique,
          primary key(utente,bacheca)
          );

          create table likes (
          utente varchar (25) unique,
          foto bigint unique,
          primary key(utente,foto)
          );

          create table caricamento_foto (
          utente varchar (25) unique,
          foto bigint unique,
          primary key(utente,foto)
          );

          create table pin (
          utente varchar (25) unique,
          foto bigint unique,
          data_pin timestamp(2) not null,
          primary key(utente,foto)
          );
          
          create table contenimento_foto_board (
          bacheca bigint unique,
          foto bigint unique,
          primary key(bacheca,foto)
          );

          create table appartenenza_foto_topic (
          topic bigint unique,
          foto bigint unique,
          primary key(topic,foto)
          );

          create table correlazione_topic(
          topic bigint unique,
          topic_simile bigint unique,
          primary key (topic,topic_simile)
          );
          
          create table utente(
email varchar (25) not null,
nome varchar (20) not null,
cognome varchar (20) not null,
data_nascita date not null,
foto_profilo varchar(255),
primary key(email),
          foreign key(email) references follow_board (utente)
          on delete no action,
          foreign key(email) references organizazione_board (utente)
          on delete no action,
          foreign key(email) references likes (utente)
          on delete no action,
          foreign key(email) references caricamento_foto (utente)
          on delete no action,
          foreign key(email) references pin (utente)
          on delete no action 
          );

          create table bacheca(
id bigint,
titolo varchar (30) not null,
primary key(id),
          foreign key(id) references follow_board (bacheca)
          on delete no action,
          foreign key(id) references organizazione_board (bacheca)
          on delete no action,
          foreign key(id) references contenimento_foto_board (bacheca)
          on delete no action
          );


          create table foto(
          id bigint,
          fonte varchar(255) not null,
          descrizione varchar(255),
          primary key(id),
          foreign key(id) references likes (foto)
          on delete no action,
          foreign key(id) references caricamento_foto (foto)
          on delete no action,
          foreign key(id) references pin (foto)
          on delete no action,
          foreign key(id) references contenimento_foto_board (foto)
          on delete no action,
          foreign key(id) references appartenenza_foto_topic (foto)
          on delete no action
          );

          create table topic (
          id bigint,
          titolo varchar(30) not null,
          primary key (id),
          foreign key(id) references correlazione_topic (topic)
          on delete no action
          );

          

aspetto allora di sapere cosa ne pensi del codice e quello che ti ho scritto qui sopra

[pgcor]

Ciao
Riesci a postare il modello concettuale definitivo?

[thaiboxer89]

Ciao
Riesci a postare il modello concettuale definitivo?

Sostanzialmente come mi hai consigliato tu e dato che come mi hai fatto notare l'esercizio non lo richiedeva ho tolto la relazione di follow tra gli utenti, qui il mio Scema
p.s ho provato a fare un inserimento nella tabella utenti, ma mi da questo errore
ERRORE: la INSERT o l'UPDATE sulla tabella "utente" viola il vincolo di chiave esterna "utente_email_fkey"
DETAIL: La chiave (email)=(maury@gmail.com) non è presente nella tabella "follow_board".
********** Error **********

ERRORE: la INSERT o l'UPDATE sulla tabella "utente" viola il vincolo di chiave esterna "utente_email_fkey"
SQL state: 23503
Detail: La chiave (email)=(maury@gmail.com) non è presente nella tabella "follow_board".
per fare inserire i dati a cascata nelle tabelle o eliminarli senza questi errori cosa devo fare?

[pgcor]

C'è sempre una cosa che non capisco: praticamente, stando al tuo modello, una Bacheca può essere creata da minimo 0 utenti, quindi può esistere una bacheca che non ha creatori, e da massimo N utenti, quindi una bacheca può avere anche più di un creatore. È veramente così? Perchè da come l'avevo pensata io, una Bacheca può essere creata da minimo un utente (quindi deve avere un creatore) e da massimo un utente.

EDIT
L'errore che ti da' è per lo stesso motivo di quelli prima: hai invertito la dichiarazione delle chiavi esterne la chiave esterna va dichiarata nell'entità "lato N", non in quella "lato 1", non so se parlando così mi spiego
Ecco il codice SQL come l'ho pensato io, manca la parte relativa ai topic, intanto vediamo di metterci a posto con questa

Codice: Seleziona tutto

create table utente (
	email varchar(25) not null,
	nome varchar(20) not null,
	cognome varchar(20) not null,
	data_nascita date not null,
	foto_profilo varchar(255),
	primary key(email)
);

create table bacheca (
	id bigint auto_increment not null,
	titolo varchar(30) not null,
	email_utente varchar(25) not null,
	primary key(id),
	foreign key(email_utente) references utente(email) on delete cascade
);

create table foto (
	id bigint auto_increment not null,
	fonte varchar(255) not null,
	descrizione varchar(255),
	email_utente varchar(25) not null,
	primary key(id),
	foreign key(email_utente) references utente(email) on delete cascade
);

create table follow_board (
	email_utente varchar(25) not null,
	id_bacheca bigint not null,
	primary key(email_utente_ id_bacheca),
	foreign key(email_utente) references utente(email) on delete cascade,
	foreign key(id_bacheca) references bacheca(id) on delete cascade
);

create table likes (
	email_utente varchar(25) not null,
	id_foto bigint not null,
	primary key(email_utente, id_foto),
	foreign key(email_utente) references utente(email) on delete cascade,
	foreign key(id_foto) references foto(id) on delete cascade
);

create table pin (
	email_utente varchar(25) not null,
	id_foto bigint not null,
	primary key(email_utente, id_foto),
	foreign key(email_utente) references utente(email) on delete cascade,
	foreign key(id_foto) references foto(id) on delete cascade
);

create table contenimento_foto_board (
	id_bacheca bigint not null,
	id_foto bigint not null,
	primary key(id_bacheca, id_foto),
	foreign key(id_bacheca) references bacheca(id) on delete cascade,
	foreign key(id_foto) references foto(id) on delete cascade
);

[thaiboxer89]

C'è sempre una cosa che non capisco: praticamente, stando al tuo modello, una Bacheca può essere creata da minimo 0 utenti, quindi può esistere una bacheca che non ha creatori, e da massimo N utenti, quindi una bacheca può avere anche più di un creatore. È veramente così? Perchè da come l'avevo pensata io, una Bacheca può essere creata da minimo un utente (quindi deve avere un creatore) e da massimo un utente.

EDIT
L'errore che ti da' è per lo stesso motivo di quelli prima: hai invertito la dichiarazione delle chiavi esterne la chiave esterna va dichiarata nell'entità "lato N", non in quella "lato 1", non so se parlando così mi spiego
Ecco il codice SQL come l'ho pensato io, manca la parte relativa ai topic, intanto vediamo di metterci a posto con questa

Codice: Seleziona tutto

create table utente (
	email varchar(25) not null,
	nome varchar(20) not null,
	cognome varchar(20) not null,
	data_nascita date not null,
	foto_profilo varchar(255),
	primary key(email)
);

create table bacheca (
	id bigint auto_increment not null,
	titolo varchar(30) not null,
	email_utente varchar(25) not null,
	primary key(id),
	foreign key(email_utente) references utente(email) on delete cascade
);

create table foto (
	id bigint auto_increment not null,
	fonte varchar(255) not null,
	descrizione varchar(255),
	email_utente varchar(25) not null,
	primary key(id),
	foreign key(email_utente) references utente(email) on delete cascade
);

create table follow_board (
	email_utente varchar(25) not null,
	id_bacheca bigint not null,
	primary key(email_utente_ id_bacheca),
	foreign key(email_utente) references utente(email) on delete cascade,
	foreign key(id_bacheca) references bacheca(id) on delete cascade
);

create table likes (
	email_utente varchar(25) not null,
	id_foto bigint not null,
	primary key(email_utente, id_foto),
	foreign key(email_utente) references utente(email) on delete cascade,
	foreign key(id_foto) references foto(id) on delete cascade
);

create table pin (
	email_utente varchar(25) not null,
	id_foto bigint not null,
	primary key(email_utente, id_foto),
	foreign key(email_utente) references utente(email) on delete cascade,
	foreign key(id_foto) references foto(id) on delete cascade
);

create table contenimento_foto_board (
	id_bacheca bigint not null,
	id_foto bigint not null,
	primary key(id_bacheca, id_foto),
	foreign key(id_bacheca) references bacheca(id) on delete cascade,
	foreign key(id_foto) references foto(id) on delete cascade
);

forse ho scritto male la cardinalità, volevo intendere che un utete può avere da 0 a N a bacheche, anche perchè come tu mi stai facendo notare non avrebbe senso, cmq grazie che me lo hai fatto notare così posso correggere pure questo
ahhhhh...adesso ho capito...si ti sei inteso benissimo! ho fatto l'esatto opposto ...ok quindi anche per topic dovrò fare così

[pgcor]

Riguardo al topic non ho capito quale sia la tua domanda, a dire la verità cioè se intendi la faccenda della correlazione tra i varî topic, o la realizzazione del modello fisico

[thaiboxer89]

Riguardo al topic non ho capito quale sia la tua domanda, a dire la verità cioè se intendi la faccenda della correlazione tra i varî topic, o la realizzazione del modello fisico

a livello fisico...non riesco a capire nell'affermazione dell'esercizio "Per ogni topic vengono segnalati topic simili: 2 topic si definiscono simili se e solo se
almeno il 20% degli utenti possiede immagini di entrambi topic in una delle proprie
bacheche." nel senso quando avrò la mia lista delle query di inserimento dovrò sviluppare una query che verifichi i toipc correlati e li inserisca nella tabella se così fosse, oppure è possibile (anche se ho grossi dubbi ) farlo direttamente in fase di inserimento un pò come l'inserimento o eliminazione a cascata? non so se mi sono spiegato bene

[pgcor]

Per quello ci sono i trigger, delle procedure che vengono eseguite in automatico per esempio all'aggiornamento dei dati presenti in una data colonna, a dir la verità non sono molto esperto a riguardo
però c'è una marea di documentazione su internet

[thaiboxer89]

Per quello ci sono i trigger, delle procedure che vengono eseguite in automatico per esempio all'aggiornamento dei dati presenti in una data colonna, a dir la verità non sono molto esperto a riguardo
però c'è una marea di documentazione su internet

ok ho scritto al professore e vediamo cosa mi dice se gestirlo come regola aziendale o i trigger, se non ci fossero i trigger tu come scriveresti le tabelle per topic? ti volevo chiedere una cosa ma io ho notato che ad esempio nella tabella tipo bacheca

Codice: Seleziona tutto

create table bacheca (
   id serial   not null,
   titolo varchar(30) not null,
   email_utente varchar(25) not null,
   primary key(id),
   foreign key(email_utente) references utente(email) on delete cascade
);

hai aggiunto email_utente, ma in realtà non basta la relazione (che appunto fisicamente è una tabella) che sta in mezzo a utente e bacheca?

[pgcor]

... se non ci fossero i trigger tu come scriveresti le tabelle per topic?

Le tabelle per i topic, sia che i trigger si usassero o no, le scriverei nello stesso modo.

Codice: Seleziona tutto

create table topic (
	id int unsigned auto_increment not null,
	titolo varchar(20) not null,
	primary key(id)
);

create table appartenenza_foto_topic (
	id_topic int unsigned auto_increment not null,
	id_foto bigint auto_increment not null,
	primary key(id_topic, id_foto),
	foreign key(id_topic) references topic(id) on delete cascade,
	foreign key(id_foto) references foto(id) on delete cascade
);

create table correlazione_topic (
	id_topic_1 int unsigned auto_increment not null,
	id_topic_2 int unsigned auto_increment not null,
	primary key(id_topic_1, id_topic_2),
	foreign key(id_topic_1) references topic(id) on delete cascade,
	foreign key(id_topic_2) references topic(id) on delete cascade
);

Il trigger è una procedura che viene gestita dal DBMS, non è direttamente inerente alle tabelle, cioè non è che tu vai a occuparti dei trigger nel codice che crea le tabelle (o almeno questo è quel poco che so, potrei anche sbagliarmi, ho dato solo un occhiata su Internet stamani).

hai aggiunto email_utente, ma in realtà non basta la relazione (che appunto fisicamente è una tabella) che sta in mezzo a utente e bacheca?

Eh qua bisogna chiarire: una Bacheca da QUANTI Utenti viene gestita? Se sono più di uno (il che mi pare improbabile ), allora si va a creare una tabella "intermedia", come hai detto tu, per ogni Utente che crea una Bacheca.
Ma se una Bacheca può essere (creata e) gestita da un solo Utente, allora è una regola della progettazione di una base di dati che non si vada a creare una tabella intermedia, bensì la chiave primaria della tabella "lato 1" (o "lato 1-1", stando alla notazione che usi tu), viene portata come chiave esterna nella tabella "lato N" (o "lato 0-N", sempre stando alla notazione da te usata ).
Difatti se guardi nello script di creazione che ho postato, non c'è la tabella intermedia per la creazione della Bacheca da parte dell'Utente, appunto perchè avevo supposto che una Bacheca possa essere creata da un solo Utente.
La questione era già stata posta :

C'è sempre una cosa che non capisco: praticamente, stando al tuo modello, una Bacheca può essere creata da minimo 0 utenti, quindi può esistere una bacheca che non ha creatori, e da massimo N utenti, quindi una bacheca può avere anche più di un creatore. È veramente così? Perchè da come l'avevo pensata io, una Bacheca può essere creata da minimo un utente (quindi deve avere un creatore) e da massimo un utente.

[thaiboxer89]

... se non ci fossero i trigger tu come scriveresti le tabelle per topic?

Le tabelle per i topic, sia che i trigger si usassero o no, le scriverei nello stesso modo.

Codice: Seleziona tutto

create table topic (
	id int unsigned auto_increment not null,
	titolo varchar(20) not null,
	primary key(id)
);

create table appartenenza_foto_topic (
	id_topic int unsigned auto_increment not null,
	id_foto bigint auto_increment not null,
	primary key(id_topic, id_foto),
	foreign key(id_topic) references topic(id) on delete cascade,
	foreign key(id_foto) references foto(id) on delete cascade
);

create table correlazione_topic (
	id_topic_1 int unsigned auto_increment not null,
	id_topic_2 int unsigned auto_increment not null,
	primary key(id_topic_1, id_topic_2),
	foreign key(id_topic_1) references topic(id) on delete cascade,
	foreign key(id_topic_2) references topic(id) on delete cascade
);

Il trigger è una procedura che viene gestita dal DBMS, non è direttamente inerente alle tabelle, cioè non è che tu vai a occuparti dei trigger nel codice che crea le tabelle (o almeno questo è quel poco che so, potrei anche sbagliarmi, ho dato solo un occhiata su Internet stamani).

hai aggiunto email_utente, ma in realtà non basta la relazione (che appunto fisicamente è una tabella) che sta in mezzo a utente e bacheca?

Eh qua bisogna chiarire: una Bacheca da QUANTI Utenti viene gestita? Se sono più di uno (il che mi pare improbabile ), allora si va a creare una tabella "intermedia", come hai detto tu, per ogni Utente che crea una Bacheca.
Ma se una Bacheca può essere (creata e) gestita da un solo Utente, allora è una regola della progettazione di una base di dati che non si vada a creare una tabella intermedia, bensì la chiave primaria della tabella "lato 1" (o "lato 1-1", stando alla notazione che usi tu), viene portata come chiave esterna nella tabella "lato N" (o "lato 0-N", sempre stando alla notazione da te usata ).
Difatti se guardi nello script di creazione che ho postato, non c'è la tabella intermedia per la creazione della Bacheca da parte dell'Utente, appunto perchè avevo supposto che una Bacheca possa essere creata da un solo Utente.
La questione era già stata posta :

C'è sempre una cosa che non capisco: praticamente, stando al tuo modello, una Bacheca può essere creata da minimo 0 utenti, quindi può esistere una bacheca che non ha creatori, e da massimo N utenti, quindi una bacheca può avere anche più di un creatore. È veramente così? Perchè da come l'avevo pensata io, una Bacheca può essere creata da minimo un utente (quindi deve avere un creatore) e da massimo un utente.

ok ora la questione mi è più chiara, in alternativa al trigger, che query si potrebbe fare secondo te per questa tabella? una join su se stessa?

[pgcor]

No praticamente il trigger è una procedura che viene eseguita in automatico, la quale nel nostro caso andrebbe ad effettuare periodicamente, topic per topic (provo a buttarla giù in una specie di pseudocodice):

Codice: Seleziona tutto

1- seleziono tutti i topic presenti
2 - inizio un ciclo FOR in cui prendo sotto esame un topic per volta. Chiameremo A il topic che viene preso in esame di volta in volta
3 - per ogni topic A, seleziono nuovamente tutti gli altri topic. Chiameremo B il topic che di iterazione in iterazione (vedi punto 4) verrà confrontato con il topic A
4 - inizio un altro ciclo FOR, in cui effettuo ogni volta questo controllo:
  "questo topic A ha almeno il 20% di foto in comune con questo topic B?"
5 - Se il riscontro è positivo, effettuo la query che va ad inserire unan  uova riga nella tabella correlazione_topic:
  INSERT INTO correlazione_topic values(id_topic_A, id_topic_B);

Non so se ho reso l'idea.
Se vuoi fare a meno del trigger, dovresti farlo a mano, magari potresti aiutarti con una procedura (il che ti farebbe scrivere meno codice, di volta in volta), ma comunque dovresti andare a scrivere a mano

[thaiboxer89]

No praticamente il trigger è una procedura che viene eseguita in automatico, la quale nel nostro caso andrebbe ad effettuare periodicamente, topic per topic (provo a buttarla giù in una specie di pseudocodice):

Codice: Seleziona tutto

1- seleziono tutti i topic presenti
2 - inizio un ciclo FOR in cui prendo sotto esame un topic per volta. Chiameremo A il topic che viene preso in esame di volta in volta
3 - per ogni topic A, seleziono nuovamente tutti gli altri topic. Chiameremo B il topic che di iterazione in iterazione (vedi punto 4) verrà confrontato con il topic A
4 - inizio un altro ciclo FOR, in cui effettuo ogni volta questo controllo:
  "questo topic A ha almeno il 20% di foto in comune con questo topic B?"
5 - Se il riscontro è positivo, effettuo la query che va ad inserire unan  uova riga nella tabella correlazione_topic:
  INSERT INTO correlazione_topic values(id_topic_A, id_topic_B);

Non so se ho reso l'idea.
Se vuoi fare a meno del trigger, dovresti farlo a mano, magari potresti aiutarti con una procedura (il che ti farebbe scrivere meno codice, di volta in volta), ma comunque dovresti andare a scrivere a mano

Sono riuscito a sentire il professore e i miei compagni, è semplicemente una regola aziendale , quindi niente problemi, al massimo quando scriverò la tesi dell'esercizio scriverò che per mostrare i topic correlati bisogna fare una query, io opterei per selezionare un topic e joinarlo con un topic che il 20 degli utenti possiede quelle foto

[pgcor]

Quindi per ora tutto a posto?

[thaiboxer89]

Quindi per ora tutto a posto?

direi proprio di si , ti posso dolo chiedere una cosa secondo te? se la metto come regola aziendale in teoria la relazione topic_correlati possiamo anche toglierlo? io lo toglierei a sto punto... la query per verificare i topic correlati, la query su se stessa sulla tabella topic come potrei scriverla per verificare i topic correlati e da scrivere nella relazione? grazie veramente per tutto dovrei farti una statua