Enforcing constraint across databases

2

Questa è una domanda di progettazione / pianificazione , non specifica per un particolare software / implementazione. Le cose di cui sto parlando non esistono ancora, ma spero di evitare errori all'inizio del processo.

Ecco la situazione che mi piacerebbe dare consigli su:

  1. Abbiamo 7 "verticali" aziendali (ad esempio vendite, marketing, ecc.) con ogni verticale che mantiene separatamente i suoi dati e un'API RESTful che usano per consentire l'accesso ai propri dati.
  2. I dati grezzi vengono mantenuti separatamente dalla rispettiva verticale. Ciò conferisce a ciascun verticale più libertà di definire la propria architettura, la pipeline dei dati e l'elaborazione.
  3. L'API per ogni verticale viene utilizzata per definire un "contratto" di livello superiore che dovrebbe rimanere invariato (sintatticamente e semanticamente) indipendentemente dalle modifiche all'architettura dei dati sottostante.

Ecco il problema:

Ci piace l'idea di cui sopra perché disaccoppia ogni business unit. Tuttavia, il disaccoppiamento è anche un problema --- dal momento che facciamo parte di una singola azienda, ci siamo resi conto che condividiamo un modello di dati comune per un ampio sottoinsieme dei nostri dati.

Ad esempio: i potenziali siti di progetto sono tracciati dal team di marketing, quindi perseguiti dal team commerciale come un'opportunità, poi persi / vinti dalle vendite, quindi progettati dall'ingegneria e mantenuti dai servizi.

Ogni verticale tiene traccia di cose diverse su queste entità e potrebbe non avere cardinalità one-to-one (ad es. opportunità multiple per potenziale progetto).

Un altro esempio è l'applicazione dei vincoli di denominazione: abbiamo un insieme comune di nomi per concorrenti, modelli, paesi, ecc. e vogliamo applicarlo nei nostri set di dati così, ad esempio, "Acme X-35" è l'unico modo per descrivere questa marca e modello su tutti i nostri set di dati.

le mie idee

Indirizzamento delle connessioni tra modelli di dati (meta modello)

O applichiamo il modello di dati cross-database "per convenzione" (sembra fragile) o creiamo un "meta database" che estrae da ciascuna API in un database relazionale composto da "viste" ... creiamo e mettiamo in relazione un Mazzo di viste materializzate (senza tabelle non elaborate). Questo database conterrà campi e tabelle normalizzati che implementano il modello comune.

Applicazione dei vincoli di denominazione

L'assunto chiave è che i nomi sono immutabili dopo che decidiamo su di loro. Supponendo che ciò valga, possiamo fornire un semplice "server di convalida" che serve i nomi consentiti per un campo (una tabella di ricerca RESTful, in sostanza) e ogni database può incorporare questo nel proprio flusso di lavoro di convalida.

Ok, come puoi vedere, ho provato a riflettere su questo, ma non sono sicuro che ci sia un modo più standard per coordinare e sincronizzare il modello di dati cross-database con i vincoli.

    
posta Robert Harvey 17.08.2017 - 17:44
fonte

2 risposte

1

In generale è una cattiva idea cercare di far rispettare questo attraverso i database. Hai già detto che ogni business unit ha la sua architettura. Quindi fintanto che tutti sanno chi possiede quale dato devono essere "forzati" a seguire quel sistema.

Quale dipartimento decide quali prodotti hai. Quel reparto avrà una API che contiene un elenco di prodotti correnti. Se quel dipartimento vuole aggiungere altri campi, dovrebbe essere un piccolo problema.

Ricorda anche che un sistema di ingegneria non traccia le opportunità. Soprattutto non le opportunità che sono perse. Engineering si preoccupa solo delle offerte che hai effettivamente vinto. Quindi l'intuizione qui è che un'opportunità non è la stessa cosa di un contratto firmato. (Anche se sono entrambi chiamati Acme X35)

Ovviamente ogni sistema può pubblicare la propria API (eventualmente formalizzata con ad esempio un wsdl). In questo modo ogni dipartimento può espandere il modo in cui sono rilevanti per loro.

E naturalmente non c'è niente di meglio che parlarsi a vicenda su base regolare su come si desidera cambiare le cose.

    
risposta data 27.09.2017 - 19:14
fonte
0

RDF è una soluzione migliore rispetto a SQL, poiché consente di creare collegamenti a un altro database in base alla progettazione. Ci sono alcuni successi nelle prestazioni con negozi tripli, specialmente quelli grandi, ma se ti puoi permettere questo è un'opzione.

Uno schema RDF è espresso in RDF e può naturalmente importare le definizioni da un altro schema. In questo modo puoi avere i vantaggi di un data warehouse senza un negozio separato.

    
risposta data 28.08.2017 - 18:23
fonte