ERD diagramma e SQL rapporti di collegamento utente, progetto e del set di dati tabelle

Question

Ho diversi tavoli nella mia ERD che che vorrei coniugare in modo relazionale.

Ho diversi casi d'uso, ma ho perso completamente traccia di ciò che tipo di relazioni da utilizzare tra i tavoli.

• Ogni utente può lavorare su più progetti.
• Ogni utente ha un ruolo specifico per progetto (manager, collaboratore, utente)
• Ogni progetto ha più set di dati (colonne currDataXXX a 'progetti') che devono essere collegate ai dati della tabella.
• L'applicazione non mancherà di tenere traccia delle serie di dati che sono stati aggiunti dagli utenti. Così presumo ho bisogno di una relazione tra le tabelle degli utenti 'e 'data' troppo?

ho usato un modello di ponte nella tabella 'ruoli' con 2 PK di collegare gli utenti e progetti insieme e che definiscono un ruolo per l'utente e di progetto allo stesso tempo (è questo il modo corretto?).

Potrebbe qualcuno aiutarlo prego assistere il corretto rapporto tra le tabelle? e magari suggerire colonne (che mancano) da tavole (o tabelle nel suo insieme, naturalmente).

Tipo di perso di vista questo.

Cordiali saluti,

B.

REVISIONE ERD: (Immagine originale: http://i55.tinypic.com/2mq2ejs.jpg )

Answer 1

  

Ogni progetto ha più set di dati (colonne currDataXXX a 'progetti')

Questo significa che c'è una relazione uno-a-molti da progetto a set di dati. Come tale, l'ID progetto dovrebbe essere una chiave esterna nella tabella di dati, mentre le colonne currDataXX devono essere rimossi dalla tabella progetto. (Il design attuale rappresenta un denormalizzazione.)

Dopo aver fatto questo, ora avete due molti-a-molti tra progetto e l'utente - una con un ente di collegamento di ruoli, e una con un ente di collegamento di set di dati. Tali rapporti sono normalmente ridondante - in questo caso, presumo che a) solo gli utenti con un ruolo in un progetto possono aggiungere set di dati, e b) che un singolo utente può aggiungere molti set di dati per un singolo progetto

.

Se entrambe queste ipotesi sono corrette, allora v'è in realtà un uno a molti da ruolo a set di dati, e quindi l'ID ruolo dovrebbe essere una chiave esterna sulla tabella di set di dati, mentre gli ID utente e di progetto diventano ridondanti sulla tavolo set di dati e può essere rimosso. In questo modo:

+----------+    +----------+    +----------+
|   User   +---<|   Role   |>---+  Project |
+----------+    +----+-----+    +----------+
                     |
                    /|\
                +----------+
                |  Dataset |
                +----------+

[Se ipotesi b) non è corretta, allora il ruolo e set di dati possono essere combinati in un unico tavolo, mentre se assunto a) non è corretto ruolo allora e set di dati rimangono due entità di collegamento distinti, non collegati tra di loro.]

EDIT - aggiornato struttura proposta, a seguito di modifiche Rhizosis':

                +----------+
                |   Role   |
                +----+-----+
                     |
                    /|\
+----------+    +----------+    +----------+
|   User   +---<|  Users/  |>---+  Project |
|          |    | Projects |    |          |
+----------+    +----+-----+    +----------+
                     |
                    /|\
                +----------+
                |  Dataset |
                +----------+

Answer 2

Ogni utente può lavorare su più progetti.

Questa è una relazione molti-a-molti, così deve essere con un tavolo centrale, come hai fatto con l'ID dell'utente e il progetto.

Ogni utente ha un ruolo specifico per progetto (manager, collaboratore, utente)

Si dovrebbe aggiungere terzo campo in questa tabella di cui sopra e lo chiamano "ID ruolo" e hanno un'altra tabella chiamata "ruoli" che contengono due campi "ID ruolo" e "Ruolo"

Answer 3

Non è progettare le tabelle poi elaborare i rapporti -. Dovrebbero entrambi evolvere allo stesso tempo

In particolare quando si utilizza un database che non richiede dichiarazioni chiave esterna, mi consiglia di utilizzare una rigida convenzione di denominazione. Anche se ti sembra di fare che per le tabelle che avete mostrato per le relazioni, il resto dei nomi di campo sembra un po 'hap-pericolo.

Ma senza vedere tutte le analisi (e sapendo che è corretto) non è davvero possibile per chiunque di dirvi come le tabelle dovrebbero essere unite, né ciò che può mancare