Sto creando un diagramma concettuale [sì, lo so che ho incluso attributi e chiavi - ma questo è solo per me per consolidare ciò che sto facendo mentre sto imparando] - quindi per favore trattalo come Concettuale focalizzato su Relazioni e tabelle e non come diagrammi;)

Il mio ostacolo mentale è: sto cercando di accertare il modo migliore per modellare le relazioni di profilo, posizione e organizzazione.

Prima di tutto, REGOLE:

• Uno o più profili possono essere membri / amici di una o più organizzazioni ; e viceversa.
• Uno o più profili possono essere membri / amici di altri profili.
• Una o più organizzazioni possono essere membri / amici di altre organizzazioni.

Amico e membro differiscono, in quanto gli amici sono come di sola lettura e i membri [a seconda del livello] hanno pieno accesso per modificare le cose.

Per complicare ulteriormente le cose, le sedi dispongono di una propria serie di "ulteriori" regole raffinabili, ad esempio un'organizzazione possiede due posizioni , ma a seconda delle regole di posizione, un membro [ profilo ] di tale organizzazione può avere pieno accesso in una posizione, ma l'accesso limitato al altro. [Spiacenti: molto probabilmente dovrai aprire l'immagine in un'altra finestra per una migliore dimensione di visualizzazione.]

Come puoi vedere, il concetto di profili e organizzazioni è più o meno lo stesso, così come questo concetto ancora da modellare di amici e membri [... che immagino sarà gestito in modo simile alle attuali tabelle intermedie con l'impostazione Proprietario / Amministratore / Membro / Amico ecc. Nel registro]. Quindi, perché sto pensando al seguente concetto:

Vedi Option.2 nell'immagine sopra: che rimuove le tabelle Organization e Organization_Locations correnti e le loro relazioni, sostituendole con la tabella Organization Option.2 come relazione in qualche modo ricorsiva con Profile .

Suppongo che il nocciolo della questione sia se sono o meno troppo programmaticamente incentrato sul polimorfismo a scapito della semplicità e della flessibilità, confondendomi completamente nel processo;)

Grazie per i tuoi pensieri in anticipo, molto apprezzato - M :).

Schema rivisto:

In risposta alle domande di MDCCL:

1. Sì, il profilo è composto da una sola persona e ha lo stesso significato - anche se la tua logica è diretta - credo che tu abbia ragione: organizzazione e persona potrebbero essere sottotipi di profilo ; pertanto, un profilo è composto da una persona o da un'organizzazione.
2. Un indirizzo email per profilo.
3. Sì. Come sopra, l'organizzazione dovrebbe avere almeno un indirizzo e-mail.
4. Corretto, un indirizzo fisso.
5. È una possibilità, ma una rarità - anche se da quello che sto imparando - si dovrebbe quindi modellare tale per la longevità futura ecc., E solo per confermare, un Luogo potrebbe quindi essere di proprietà di più di una Persona.

6. La posizione è sicuramente l'entità integrale tra la maggior parte degli altri. Forse chiarirò cosa si può fare in modo succinto qui, quindi ti farò leggere anche se le mie altre risposte che si spera riguarderanno prima le aggiunte benefiche a questa domanda [ poi vedrai la mia risposta al numero 6 alla fine ];) Ri: Il proprietario del ruolo. An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[pertanto, come precedentemente ipotizzato; in poche parole, un profilo può essere proprietario di zero o più località.

7. Sì, un profilo che è un proprietario di una posizione assume tutti i ruoli delle autorizzazioni [super-utente]; un profilo che sia un amministratore può modificare determinati dettagli della posizione , ma aiuta / modifica principalmente i dettagli / i dati forniti tramite tutti gli altri profili - questo sarà fornito principalmente da "Membro / i di base" di tali sedi ; che lascia il Membro base , che può leggere solo tutti i dettagli relativi alla posizione e fornire i dati che devono essere verificati da un amministratore / proprietario . Oltre a questo, qualsiasi profilo[Organizzazione / Persona] è molto simile a un membro di base "sola lettura", chiamiamoli un ospite - ma solo se la posizione è impostata come pubblica [e non privata ], sebbene non possano fornire input come un membro di base può .

8. Corretta.
9. La tua intuizione è incredibile! Sì, it is foreseen that a single Location could contain one to many LocationTypes- per complicare ulteriormente le cose - si prevede che quei singoli LocationTypes possano avere autorizzazioni diverse per i profili associati alla posizione 'Parent'; di cui, le autorizzazioni filtrerebbero da Location a TypeType / s [proprio come le autorizzazioni di sicurezza della cartella del sistema operativo]. Prendo atto del tuo diagramma potresti riferirti a digitare di più come descrizione?
10. Sì.
11. Vedi 12
12. Corretta, la possibilità per Profile1 [persona o organizzazione] per agire su Profile2 [persona o organizzazione] di proprietà Sedi [se sono amico / membro con autorizzazioni corrette] è fondamentale.
13. Molto ragionevole - a) d'accordo. b) d'accordo. c) Sì, hmm? ... Forse dovrebbe essere più o meno lo stesso di Profile [person] su Profile [person] = Friends . Qualunque sia la descrizione, sarebbe ruotano attorno posizione , come Organizzazione / s sarà agire su altri Organizzazione Location / s; sebbene semanticamente, dubito che qualsiasi Organizzazione vorrebbe apparire sottomessa come "Membro" dell'Organizzazione di quel Luogo per poterlo fare, "non importa quanto sia valida la causa".

[6]. Questo è ancora un po 'grigio per me, ma qui va ... Probabilmente a mio svantaggio, la somiglianza tra relazioni Membro / Amico sono così vicine che ho pensato di combinarle; a ben vedere il tuo diagramma e la tua interpretazione, sembra che tu abbia ragione a tenerli separati [ Stavo per differenziare la singola relazione tramite la proprietà enum: Owner / Admin / Member / Friend ]. Il tuo concetto come ad esempio: una posizione che è posseduta da un'organizzazione avrà zero a molti profili [persona o organizzazione] che agiscono su di essa, sebbene ci dovrebbe essere una chiara differenza tra il modo in cui i profili agiscono sulla posizione attraverso la sua relazione [membro o amico ] indicato attraverso i ruoli.So perhaps, the default relation between any Profile is Friend [much like Guest at Answer#7], enabling them to view the read-only Location data and msg/email the Location Owner/Admin - but not allow them to receive Location updates, news, etc., as a Member would.

È fantastico che tu stia prendendo il tempo per comprendere, classificare e modellare i dati di cui ti stai occupando poiché, per esperienza personale, tutto ciò rende l'intero processo di sviluppo più semplice e molto flessibile per i cambiamenti futuri. E sono abbastanza sicuro che ne sia già consapevole.

Modello di dati preliminari e regole aziendali assunte

Ho definito un elenco di regole aziendali che ho assunto dopo aver letto la tua domanda e aver esaminato attentamente i tuoi diagrammi, al fine di descrivere la mia comprensione delle tue specifiche. Dopo aver definito tale elenco, ho derivato un modello di dati IDEF1X ^[1] che ho deciso di caricare come documento .PDF in una piattaforma esterna (Dropbox), poiché a causa del suo formato questo modello di dati non si adatta bene a un'immagine incorporata. Questi due strumenti saranno utili come riferimenti per alcuni punti importanti che enumererò di seguito nella sezione intitolata Aspetti da risolvere per continuare ad andare avanti .

Innanzitutto, ecco il ...

• Modello preliminare di dati di organizzazioni e profili .

Dal momento che è solo preliminare, considerarlo come un mezzo che ci aiuta a realizzare il modello di dati finali desiderato.

Regole aziendali presunte

Tale modello di dati preliminari è stato derivato da una raccolta di regole aziendali (desunte dalla tua domanda) che enumererò come segue:

Organizzazioni e profili

Si noti che Profileattualmente è inteso come sinonimo di Person.

• An Organizationè un amico di uno a molti Profiles .
• An Organizationè un amico di uno a molti Organizations .
• An Organizationè un membro di uno-a-molti Organizations .
• A Profileè un membro di uno-a-moltiOrganizations .
• A Profileè un amico di uno a molti Profiles .
• A Profileè un membro di uno-a-molti Profiles .

Posizioni e indirizzi

• Uno Organizationpossiede uno-a-molti Locations .
• A Locationè classificato da uno a molti LocationTypes ( solo uno in un dato momento).
• Un Locationpuò avere uno-a-molti Addresses ( uno Physical , uno per Shipping, uno per Billing, o uno che serve scopi tutti detti, o uno che combina due scopi ed altri che serve solo uno di essi).

• Un Addresspuò essere tenuto da uno a molti Profiles o, in altre parole, uno Profilemantiene uno a molti Addresses .

• Uno specifico Addresspuò essere utilizzato da uno-a-molti Profiles (che serve come Physicalper uno Profile , essendo utilizzato per Billingda uno diverso , ecc). Quindi, Addressfunziona in modo simile per Locationse Profiles.

  • Così, un individuo Addresspuò essere, allo stesso tempo , di tipo Physical, Shipping e Billing .

Posizioni e ruoli

• A Locationapre uno a molti Roles .
• A Rolepuò essere eseguito in uno-a-molti Locations .
• A Profile(una volta impostato come Memberdi Organization) può eseguire uno-a-molti Roles , in uno-a-molti Locations (ma solo uno specifico Rolein ciascuno Locationin un determinato momento, cioè mai due o più Roles contemporaneamente ).

Aspetti da risolvere per andare avanti

Per continuare ad avanzare nella risoluzione del tuo modello di dati, ecco un elenco di punti rilevanti che, una volta elaborati, ci aiuteranno a raggiungere questo obiettivo:

1. Ho ipotizzato che il termine Profilenel tuo contesto abbia un significato simile (o uguale) a quello di Person, ma potrebbe essere un po 'diverso. In questo modo, diresti che, nel tuo scenario, le entità Organizatione i Personsottotipi di Profile?

2. Può un Profile(o Person) proprio uno-a-molti EmailAddresses , o è un Profile(o Person) fissata ad esattamente un EmailAddress ?

3. Vorresti fornire la possibilità Organizationdi essere contattato tramite Telephonee Email, o vuoi limitare ciò per essere possibile solo per un Profile(o Person)?

4. Presumo che a Locationsia fissato esattamente a un Address tipo Physical, è corretto?

5. È possibile che uno Locationsia condiviso da uno a molti diversi Organizations o , in caso contrario, Locationpuò essere posseduto da uno solo Organization ?

6. Hai dichiarato tramite commenti che il fatto di essere a Membere a Friendè lo stesso. Come puoi vedere nel mio modello di dati preliminari proposto, ti ho seguito le specifiche originali e ho illustrato tutte le possibili combinazioni di appartenenza e amicizia tra Organizatione Profile(o Person) in entità diverse poiché penso che possa essere utile nello sforzo di definire il migliore possibile struttura per quella parte del tuo scenario. In questo senso:

   • Presumo che la dichiarazione an Organization is a Member of another Organizationabbia effetti diversi rispetto alla dichiarazione a Profile (or Person) is a Member of an Organizationrelativa all'entità chiamata Location.
   • Come puoi vedere nel modello di dati, penso che il Roledi Ownersia valido solo per un Organizatione, per me, il valido Rolesper un Profile(o Person), all'interno di un Locationare Admine Member. Cosa ne pensi di tutto questo? Dato che sei in diretto contatto con le regole aziendali applicabili alla tua situazione, devi dirmi se i miei presupposti sono corretti.

7. Un Profile(o Person) può suonare diversamente Rolesnello stesso Location? vale a dire, può Personessere, allo stesso tempo, Admine anche uno Memberdella stessa Location? Quali sono le regole al riguardo?

8. Penso che lo stesso Profile(o Person) possa suonare diverso Rolesin diverso Locations. Ad esempio: uno specifico Profile(o Person) è "Admin" in Location"1", e questo stesso Profile(o Person) è un " Member" in Location"2", allo stesso tempo. Ho ragione?

9. È possibile che un particolare Locationsia diverso LocationTypesallo stesso tempo, o un individuo è Locationfisso per tenerne esattamente uno LocationType?

10. L'attributo Organization.Websiterappresenta l'indirizzo del sito Web di una determinata organizzazione, ad esempio "dba.stackexchange.com"?

11. Se Profile"1" (inteso come Person) è un Member(o Friend) di Profile"2", è possibile che Profile"1" esegua un Rolein un Locationposseduto da Profile"2"? Ritengo che tali scenari siano validi solo per le relazioni tra un Organizatione un Member Personcosì, cosa ne pensi?

12. In modo simile, se Organization"1" è un Member(o Friend) di Organization"2", è possibile che Organization"1" esegua un Rolein un Locationposseduto da Organization"2"? Ancora una volta, penso che questo tipo di scenari siano validi solo per le relazioni tra an Organizatione a Member Person, è corretto?

13. A questo proposito, mentre scrivo queste domande, penso che sarebbe ragionevole dire che ci sono solo tre diversi tipi di relazioni che coinvolgono Organizationse Persons, e possiamo definire:

    • (a) La relazione tra an Organizatione a Personcome “ Membership”.
    • (b) La relazione tra a Persone un altro è diversa Personda “ Friendhip”.
    • (c) Dobbiamo ancora trovare un nome significativo per descrivere la relazione tra un individuo Organizatione un altro diverso Organization.
    • Fammi sapere cosa ne pensi di (a), (b) e (c).

14. È possibile che un Organizationsia uno Friend(o uno Member) di uno-a-molti diversi Organizationsallo stesso tempo? Oppure è possibile solo per Organizationavere un rapporto solo con uno diversoOrganization?

Modello di dati successivi raffigurante il primo anticipo

In attenzione alle tue risposte e risoluzioni agli aspetti in sospeso che ho elencato sopra, ho creato il seguente ...

• Modello preliminare di dati di organizzazioni e profili - Primo progresso .

Anche se non mi sento ancora abbastanza a mio agio con questo, questo nuovo modello di dati esprime le seguenti regole aziendali:

• Una Profileè sia un Organization o una Person. ^[2]
• A Profilepuò essere l'amico proponente dell'uno-a-molti FriendProfiles , e Profilepuò essere l'amico accettante dell'uno-a-molti FriendProfiles . ^[3]
• A Locationpuò consistere in uno-a-molti Locations . ^[4]

Risposte ai tuoi commenti specifici successivi

È davvero interessante per me notare / aggravare la separazione delle preoccupazioni [es. LocationAddress e ProfileAddress] - perché ovviamente volevo correre e trattenerle tutte senza le relazioni corrette [stranamente, non mi andava bene con il mio ERD originale].

Sì, questo è un buon confronto, anche se non lo definirei separazione delle preoccupazioni (che è, certamente, un principio fondamentale nella programmazione e progettazione delle applicazioni), poiché questo termine appartiene comunemente allo stadio di sviluppo dell'applicazione e attualmente ci troviamo nella fase di comprensione dei dati e progettazione della sua struttura logica.

Dalla mia esperienza personale, ritengo che questa fase abbia a che fare con l'inserimento delle cose significative nel loro intero contesto, ha a che fare con il vedere le associazioni esistenti tra le diverse entità che sono rilevanti nel particolare scenario di interesse, e quindi raffigurante queste cose in un modello di dati. Nel caso specifico in cui stai commentando, l' Addressentità può avere diversi tipi di connessioni con altre entità, una con Profilee una diversa con Location.

E, sì, quando qualcosa non sembra giusto o naturale , potrebbe benissimo essere un segno che bisogna fare uno sforzo maggiore per comprendere i dati pertinenti. In questo modo, l' Addressentità è una delle cose che considero che necessita di maggiore attenzione, poiché penso che la relazione tra a Profilee an Address possa essere gestita tramite l' Locationentità (a causa del fatto che ognuno Locationdeve avere almeno un fisico Address), quindi abbiamo potuto respingere l' ProfileAddressentità associativa raffigurato nel l'ultimo modello, ma è necessario continuare analizzando questi punti e fatemi sapere le vostre idee.

Inoltre, è pratica comune in IDEF1X cambiare le denotazioni PK / FK nelle entità per una migliore leggibilità [es. ProfileId - LocationOwnerProfileId]?

Sì, questa è un'osservazione molto intelligente da parte tua, poiché IDEF1X raccomanda l'uso di nomi di ruoli per denominare CHIAVI STRANIERE, al fine di acquisire il significato di tali attributi in base all'entità in cui viene utilizzato. Vale anche la pena notare che questo è anche fortemente correlato al concetto di migrazione delle chiavi primarie . È un dato di fatto, l'uso di nomi di ruoli precede IDEF1X, poiché è stato presentato in origine dal Dr. EF Codd nel suo testo seminale del 1970. In questo modo, si può vedere chiaramente la fedeltà che lo standard IDEF1X mantiene nei confronti del modello relazionale .

Sarei incuriosito dall'apprendere ciò che non ti piace / senti che non modella, con / nella soluzione?

Oltre ai dettagli già descritti sopra Addresssull'entità, non sono sicuro che il Rolesfatto che un dato Profilein un determinato Locationsia equivalente a un Organizationo un Person. Dal mio punto di vista, un Personprimo deve essere associato a un Organization, e quindi questo Organizationnominerebbe detto Persondi eseguire un Rolein un particolare Location, ma conosci meglio lo scenario, quindi queste regole potrebbero essere inutili. A questo proposito, ho intenzione di insistere sul fatto che sarebbe stato molto utile per me sapere la descrizione contestuale o significato che i futuri utenti di questa struttura dati per dare Organization, ProfileeLocation, ma capisco che queste potrebbero essere considerate informazioni riservate, quindi questa sarebbe una limitazione.

Con la struttura attuale, sembra che tutti ( Organizationo Person) possano essere collegati a chiunque (di nuovo, Organizationo Person) e possano essere / fare qualsiasi cosa ( Role) ovunque ( Location) ma, perharps, questo è precisamente ciò che tu e gli utenti vi aspettate da questo database , per il quale fornirai vincoli ben definiti, ovviamente. In questo caso, stiamo quasi fornendo una soluzione finale. Dato che, naturalmente, la tua opinione è decisiva in questa situazione, dovresti anche analizzare queste idee e quindi farmi conoscere le tue conclusioni in modo che possiamo compiere i passi finali.

Secondo anticipo fattibile

Sfortunatamente, la comunicazione si è interrotta poche settimane fa, immagino a causa degli impegni di lavoro che devi rispettare, il che è del tutto ragionevole. Sarei stato molto più contento se avessimo sviluppato un modello più stabile e robusto ma, a causa delle nostre interazioni precedenti, posso presumere che sono stato in grado di indicarti la giusta direzione.

Oltre a quanto è già stato presentato in questo processo di domande e risposte, ritengo che fornire una nuova progressione dai precedenti modelli di dati possa essere utile per altri ricercatori con un problema simile. Quindi, ho creato il ...

Modello preliminare di dati di organizzazioni e profili - Secondo avanzamento

Come si può vedere in tale modello di dati, ho rimosso la relazione molti-a-molti che ho rappresentato nei modelli precedenti tra Profilee Address, poiché un dato Profileè già correlato a uno-a-molti Addresses tramite la sua proprietà Locations.

Un altro cambiamento che viene illustrato in questo nuovo anticipo è il fatto che ora include la possibilità che un dato Locationpossa essere posseduto da uno a molti Profiles . Di conseguenza, ho cambiato la Locationchiave primaria (respingendo LocationOwnerProfileIdl'attributo) e quindi aggiunto un ente associativo ( molti-a-molti ) che si riferisce Profilecon Location.

Appunti

_{1. IDEF1X è una tecnica di modellizzazione dei dati altamente raccomandabile che è stata definita come standard nel dicembre 1993 dal National Institute of Standards and Technology ( NIST ) degli Stati Uniti .}

_{2. Questa è un'occasione di un cluster (super) di sottotipo di tipo . Nel caso siate interessati, ecco una risposta in cui mi occupo in modo più dettagliato di questo tipo di relazioni.}

_{3. Un esempio di relazione gerarchica molti-a-molti ed è molto simile alla struttura che ha dato la soluzione definitiva al "Problema di esplosione delle parti" . Tale soluzione fu, naturalmente, introdotta dal Dr. Edgar Frank Codd nel suo articolo del 1970 estremamente influente "Un modello relazionale di dati per grandi banche dati condivise" .}

_{4. Come tale, questa è un'istanza di una relazione gerarchica uno-a-molti (o molti-a-uno) .}

Penso che tu stia provando a fondere insieme concetti di modellazione di oggetti e concetti di modellazione di dati in un modo che non ti aiuta a chiarire la tua comprensione del problema. Spero di poter cancellare un po 'il disordine senza troppe chiacchiere.

Il modello relazionale, in quanto tale, non supporta l'ereditarietà, non importa il polimorfismo. Ciò significa che è necessario utilizzare un modello di progettazione piuttosto specializzato quando si modella una situazione di vita reale che può essere facilmente gestita dall'ereditarietà e dal polimorfismo in un modello a oggetti. Maggiori informazioni su quello speciale modello di design in seguito.

Quando il modello ER fu sviluppato per la prima volta, doveva essere un'alternativa agnostica all'implementazione della modellazione relazionale. Inizialmente, non aveva nemmeno qualcosa di simile all'eredità. Ma qualche tempo negli anni '80 o '90, il modello è stato esteso per fornire alcune delle stesse capacità espressive che si ottengono con l'ereditarietà. Questo era noto come "modello ER esteso", ma per tutti gli scopi pratici, il modello ER di oggi include funzionalità EER.

Una funzione EER si chiama "generalizzazione / specializzazione". Puoi cercare e leggere questo concetto sul Web. Gen-spec offre più o meno le stesse capacità espressive fornite da classi e sottoclassi in un modello a oggetti. Tuttavia, la Gen-spec non affronta i problemi relativi alla progettazione della tabella relazionale per una situazione di spec-gen. Ne parleremo più avanti.

Nella modellazione ER, una relazione coinvolge sempre le stesse entità. Pertanto, la relazione di amicizia tra un'organizzazione e un profilo non è la stessa cosa della relazione di amicizia tra un profilo e un altro profilo. Le due relazioni richiedono nomi diversi. Ti legherai solo in nodi se non segui questa regola.

O quello, o devi trovare un'entità generalizzata di cui Organizzazioni, Profili e possibilmente Posizioni siano tutte specializzazioni. Non capisco abbastanza bene il tuo caso per aiutarti.

Andando avanti, noto che stai combinando il tuo modello relazionale e il tuo modello ER in un unico modello. La maggior parte degli architetti di database esperti lo fa. Ma ti consiglio di mantenere separati i due modelli (anche se riconciliati l'uno con l'altro) fino a quando non avrai acquisito competenza.

Infine, come si progettano le tabelle relazionali che rappresentano una situazione di specifica gen? Prova a cercare questi due modelli di design "ereditarietà per classi di classi" e "ereditarietà di tabelle singole". Ci sono due tag per questi in over in StackOverflow. Ci sono anche alcune presentazioni piuttosto buone degli schemi sul web. Mi piace particolarmente il trattamento di Martin Fowler. Sembra sapere come pensano i modellatori di oggetti. Spero che questo ti aiuti.