Può una tabella essere sia di fatto che di dimensione

Naviga le tue risposte
3

Ok, sono un principiante e non penso davvero "dimensionalmente" ancora, ho la maggior parte del mio schema iniziale malmesso ma continuo a girare avanti e indietro su un tavolo.

Ho una tabella di contratti e contiene una colonna di quantità (tonnellate) e una colonna di prezzo netto, che devono essere riassunti in vari modi, e il contratto ha molte chiavi esterne (produttore, merce, futures mese ecc.) e date quindi sembra essere una tabella dei fatti. Anche il contratto non viene mai aggiornato, se questo fa la differenza.

Tuttavia, creiamo biglietti in contanti che utilizziamo per pagare una parte o tutto il contratto e che hanno un ID contratto su di essi, in modo che il contratto assomiglia a una dimensione nello schema a stella del ticket di cassa.

Questo è un problema? Qualche idea sul processo per risolvere questo, perché la gente non sembra gradire l'idea di unire due tabelle dei fatti.

Dovrei inserire producerId e commodityId sul biglietto in contanti? Sembrerebbe davvero strano non avere un contratto su di esso.

    
posta PatFromCanada 12.11.2012 - 18:19
fonte

3 risposte

2

Should I put producerId and commodityId on the cash ticket?

Se ciascun ticket in contanti è direttamente correlato a un contratto e il produttore e la merce sono correlati al contratto, non ha senso spostarli dal contratto al biglietto di cassa. Questa è un'informazione sul contratto, quindi dovrebbe rimanere con il contratto.

Io lavoro con un sistema simile e penso che ciò avvenga dove si hanno due distinti gruppi di fatti che sono correlati in una relazione uno a molti. Qui, un contratto è legato a molti ticket in contanti. Ciò significa che i contratti possono essere utilizzati per filtrare i biglietti di cassa e viceversa, nonostante entrambe le tabelle memorizzino i fatti.

L'unico problema che vedo qui è che, a seconda della tecnologia, potrebbe esserci un limite al numero di record in una tabella su cui una dimensione può basarsi; abbiamo raggiunto il limite delle dimensioni delle dimensioni di Analysis Services in questo modo (con una dimensione di molti milioni di membri ... Non so se è cambiato in SS 2012). Quindi con questo voglio dire, se le tue tabelle diventano molto grandi, potresti non essere in grado di usarle direttamente come dimensioni.

Tuttavia, puoi utilizzare le dimensioni relative a una tabella dei fatti per tagliare una tabella dei fatti collegata. Ad esempio, puoi applicare un filtro di dimensione alla tabella dei contratti e mostrare un conteggio dei record collegati nella tabella dei ticket in contanti, ecc.

Non vedo un problema con questo e non abbiamo riscontrato problemi inaspettati; alcune query possono essere un po 'dispendiose in termini di risorse, ma questo è stato gestibile non abbiamo trovato un modo migliore per ottenere gli stessi risultati.

    
risposta data 22.11.2012 - 18:45
fonte
3

Semplificherai e amplificherai il tuo pensiero se dimentichi tutto ciò che sai della "dimensionalità". La nozione di Star Schema non esiste nella teoria relazionale. Quanto prima lo si elimina, i primi rapporti rimarranno da soli chiaramente nella tua mente.

La tua domanda, in sostanza, è: l'ID di un contratto è una proprietà di un biglietto in contanti? Sembra che sia così. Se aggiungerlo non denormalizza il tuo tavolo, se dipende funzionalmente dalla chiave, aggiungerlo è la cosa giusta da fare, punto e basta. Qualsiasi considerazione sulla dualità o sulla dualità fatto / dimensione può essere scartata in sicurezza.

    
risposta data 06.02.2013 - 10:09
fonte
2

I have a Contract ... it appears to be a fact table.

Penso che questo sia ciò che sta causando la confusione. Come ha sottolineato James K. Lowden, dimentica la teoria relazionale.

Prova questo:

  1. Crea una tabella ContractDim con un contratto_PK, l'ID contratto originale e qualsiasi altra cosa correlata al contratto TRANNE le colonne che verranno sommate
  2. Crea una tabella (o entrate) SalesFact con tutte le chiavi e le colonne estere da sommare come: tonnellate e prezzo netto. Pre-calcolerei anche una sorta di totale.

In questo modo il tuo biglietto cash può collegarsi a contractdim (inizio di uno schema di fiocchi di neve) oppure puoi avere una chiave esterna di ticket in contanti nella tabella dei fatti per collegarti direttamente ai valori di vendita.

Puoi fare lo stesso con CashTicketDim e PayoutFact. In questo modo non collegheresti mai SalesFact al PayoutFact.

    
risposta data 01.11.2014 - 13:37
fonte

Leggi altre domande sui tag

In che modo una CPU carica più byte contemporaneamente se la memoria è indirizzata a byte? La SRS sarà sufficiente per consentire ai programmatori di svolgere il proprio lavoro, senza il sovraccarico aggiuntivo di FS?