Tipi dinamici all'interno di un modello relazionale utilizzando Object-Role-Modeling (ORM)

Question

In Modeling Object Role (ORM), data l'entità di cosa che ha avuto una relazione con un'entità di Tipo e in cui l'entità tipo può essere specificato per vivere e l'entità cosa potrebbe avere un valore per la data di nascita, come vorrei specificare un vincolo che esclude i casi di cosa da avere un valore per la data di nascita, se l'istanza di tipo associato cosa che non era pronto per vivere. Vedi diagramma sotto ...

ORM Schema del modello da vincolare http://img197.imageshack.us/ img197 / 6551 / dynamictypeorm.jpg

Lo scopo dietro le mie domande è quello di consentire per la modellazione di tipi all'interno di un sistema in cui non è chiaro quali saranno i tipi, ma le caratteristiche dei tipi sono noti. Le risposte non hanno bisogno di essere in termini di ORM, se pensate che ci sia un approccio più applicabile. Grazie per la lettura, si spera che mi può aiutare.

Answer 1

Il libro che John Sanders ha raccomandato è uno dei migliori libri che abbia mai letto. Inoltre, tutte le vostre domande ORM possono molto probabilmente avere risposta tramite una lettura di esso.

Per rispondere direttamente si mette in discussione, però, (e schivare tutte le domande della validità del modello), ci sono due modi ovvi che vedo per vincolare così com'è.

Si potrebbe utilizzare un vincolo di sottoinsieme o un vincolo di equidistanza, a seconda di ciò che è in realtà desidera catturare.

Assegnazione di un vincolo di uguaglianza (a destra) tra i ruoli, siamo in grado di generare un vincolo che concettualmente richiedere che qualunque cosa fatta di un tipo di vita ha una data di nascita e che ogni cosa con un data di nascita sia di un tipo di vita.

L'assegnazione di un vincolo di sottoinsieme (Sinistra) tra i ruoli, siamo in grado di limitare il modello in modo tale che qualsiasi cosa di un tipo con un DateOfBirth deve essere di un tipo che sta vivendo. Questo, a differenza del vincolo di uguaglianza permetterà che le cose siano di un tipo di vita, ma non ha una data di nascita.

aggiunte:
Per creare questo tipo di subset e di uguaglianza dei vincoli che funzioneranno, abbiamo bisogno di usare qualcosa chiamato un 'Join Path' . Utilizzando un percorso unirsi, possiamo creare un join-sottoinsieme Constraint e Join-Equality vincolo che occupare più ruoli su entrambi i lati del vincolo. Esempi di aderire a percorsi può a volte essere ovvio e facile da seguire. ma può anche essere un po ' schiacciante e complessa, a volte. Anche di nota, è che anche NORMA fa supporto creando unirsi percorsi, in parità, sottoinsieme, e vincoli di esclusione il verbilazation non è completo al 100% per loro, come spiegato qui . Questo è anche uno dei motivi per cui è più facile da usare sottoinsiemi alla corrente, dal momento che è più facile per convalidare la correttezza del modello concettuale.

Per creare un percorso di registrazione in NORMA durante l'assegnazione dei ruoli per un sottogruppo, Uguaglianza, o un vincolo di esclusione prima assegnare tutti i ruoli che fanno parte di un percorso con un click, e quindi fare doppio clic per passare al percorso successivo. Quando il vincolo è in grado di unire i percorsi, i ruoli coinvolti nel vincolo che saranno segnate [#. #] Invece di [#]. Così, quando stiamo creando i nostri vincoli possiamo dire qui che i ruoli [1.1] e [1.2] sono un sottoinsieme / uguale a ruoli [2,1] / [2.1]. Si noti che i fatti che giocano un ruolo in ogni ruolo deve anche corrispondere. Così si ottiene una verbalizzazione da NORMA:
Se una cosa ha qualche DateOfBirth; qualche cosa è di un certo tipo allora che cosa è di un certo tipo; che tipo sta vivendo. Quale è meglio indicata come: Se qualche cosa di qualche tipo ha qualche DateOfBirth; allora che tipo è vivere.

Tuttavia, v'è una terza (e preferibile) modo che si possa limitare questo, che sarebbe subtyping. Dal momento che le cose che sono vivi, e le cose che non sono vivi sono molto diversi, probabilmente non vogliamo essere loro mappatura agli stessi tavoli in ogni caso. Qui abbiamo diviso il nostro tipo di fatto in due sottotipi, OrganicTypes e NonOrganicTypes. L'esclusivo o un vincolo tra i due sottotipi ci dice che ogni tipo è o organici o non organici. e la nota ci dice la Regola di derivazione che usiamo per determinare quale gruppo appartiene un tipo a. Da lì, abbiamo ridefinire la nostra [cosa è di tipo] ruolo da [LivingTHing è di OrganicType]. e dal momento che OrganicThings di deffinition sono capaci di vita, il nostro vincolo per DOB / sta vivendo è ora integrato nel modello.

Answer 2

In realtà, c'è più di un problema con il vostro modello, anche il più semplice è. Una cosa può avere una data di nascita, se fosse mai di vita. Potrebbe una volta hanno vissuto, ma ormai morto.

Inoltre, ti consigliamo di chiarire se l'assenza di fatto "Tipo vite" implica "Tipo non vive" (Closed Mondiale Assunzione), oppure se essa implica solo "Tipo non è noto per vivere" (Open World Assunzione, credo).

Una preoccupazione ulteriore che ho è che la tua domanda sembra essere un po 'confuso, che unisce "modello relazionale" e "ORM" nella stessa "sentenza". Object Role Modeling è uno strumento di modellazione concettuale per la creazione di modelli concettuali, che possono poi essere associati a uno schema relazionale. Anche se si sta reverse-engineering uno schema relazionale esistente, è meglio utilizzare lo schema come solo parte delle informazioni si usa per creare un modello concettuale corretta. Inoltre, utilizzare esempi di input e output valido, e anche discussioni con gli esperti del dominio. Questo spesso aiuterà a scoprire importanti vincoli che non sono stati catturati dallo schema relazionale, o che possono essere stati catturati in modo non corretto.

---

A proposito, per uno strumento ORM eccellente, vedi NORMA . Si tratta di un add-in per Visual Studio 2005 o 2008 (Standard Edition o superiore), e utilizza la moderna notazione di ORM2. Può generare SQL per diversi database diversi, così come diagrammi ER e anche il codice.

---

Inoltre, si veda il libro:

Answer 3

In un contesto di database, a patto che abbiate tre tabelle separate, vorrei creare una funzione che conta il numero di righe in un join tra l'entità e il tipo. Utilizzare questa funzione nella tabella che tiene il DOB per garantire che il DOB è nullo o il conteggio è 1.

pseudo-codice:

 function fn_count_living(id)
     declare @count int
     select @count = count(*)
     from entities inner join types on entities.typeid = types.id
     where entities.id = id and types.living = 1
     return @count
 end

Constraint

 fn_count_living(entity_id) = 1 or dob is null

Answer 4

ORM (e modello di dominio ) come li capisco sono entrambi modello concettuale , che vengono utilizzati per analizzare il dominio aziendale, invece di progettare soluzioni. A questo livello, portando a concetti come "tipi" o "tipi dinamici" sono troppo presto, e non soddisfa lo scopo del modello.

Object Role Modeling: una panoramica

alt text http: // i .msdn.microsoft.com / Aa290383.dv_vsea_ormoverview_06% 28IT-noi, VS.71% 29.gif

Si può mettere un vincolo di uguaglianza (una linea tratteggiata con un simbolo “=” cerchiata) fra "è vivo" e "ha la data di nascita." Simile al "è di ruolo" e "viene contratta fino".