효율적인 방법

Question

이 내가 요약하는 방법을 모르는 긴 질문입니다 ...

나는 그가에서 읽을 필요가 테이블이 재무 데이터에는 약 10 억 개의 세부 데이터가 기록되어 있습니다. 나는이 표의 구조를 바꿀 수 없다. 나는 단지 그것의 소비자 일 뿐이다. 이 테이블에는 트랜잭션 데이터, 트랜잭션을 설명하는 Int 데이터가 포함 된 속성 열이 있습니다 (Attribute1-20은 이름이 지정되지 않았으며 간단히하기 위해 이름이 지정되지 않았습니다). 그리고 Amount 열이 있습니다.

TABLE: FinancialData 
COLUMNS: 
    Id (BigInt IDENTITY) 
    TransactionId (Int FK) 
    TransactionDate (DateTime) 
    Attribute1 (Int) 
    Attribute2 (Int) 
    . 
    . 
    Attribute20 (Int) 
    Amount (Decimal) 

나는 사용자 정의 타임 라인이 개 데이터베이스 테이블 (한 헤더 테이블과 집계 양의 또 다른 상세 테이블)에이 FinancialData 테이블을 요약 할 필요가있는 프로세스가되도록의 스냅 샷 데이터는 다른 프로세스에서 사용할 수 있습니다. 헤더 테이블에는 사용자 정의 타임 라인 (스냅 샷) 당 하나의 레코드가 포함되며 세부 테이블에는 FinancialData 테이블의 모든 특성에 대한 집계 된 금액 레코드가 포함됩니다.

TABLE: FinancialHeader 
COLUMNS: 
    Id (Int IDENTITY) 
    BeginTransactionDate (DateTime) 
    EndTransactionData (DateTime) 


TABLE: FinancialDetail 
COLUMNS: 
Id (Int IDENTITY) 
FinancialHeaderId (Int FK) 
Attribute1 (Int) 
Attribute2 (Int) 
. 
. 
Attribute20 (Int) 
Amount (Decimal) 

, 프로세스의 예를 제공하지만 서로 다른 것 많은 중복 특성 (와 2010년 1월 1일와 2010년 6월 30일 사이 TransactionDate와 FinancialData 테이블에 2 개 천만 레코드가 말하는 것은 TransactionId 값). 위의 FinancialHeader 및 FinancialDetail 테이블에이 데이터를 요약하려면 2010 년 1 월 1 일의 BeginTransactionDate 및 2010 년 6 월 30 일의 EndTransactionDate를 사용하여 하나의 FinancialHeader 레코드를 만든 다음 여러 개의 FinancialDetail 레코드를 만듭니다. 머리글. FinancialDetail 테이블은 FinancialData에서 2,000 만 레코드를 집계합니다. 기본적으로 Attribute1 - Attribute20의 고유 값을 SUM (Amount)과 함께 그룹화하여 해당 속성의 총량을 추적합니다. 일반적으로 FinancialData 테이블에 2,000 만 개의 레코드가 약 10,000 개의 고유 한 속성 조합을 포함하고 있으며, 그러면 총 금액이있는 FinancialDetail 테이블에 10,000 개의 레코드가 생성됩니다. 따라서 필자의 예에서는 1 개의 FinancialHeader 레코드와 약 10,000 개의 FinancialDetail 레코드가 생성됩니다.

특성 데이터의 고유 한 조합 20 열을 저장하는 것과 관련된 질문 ...이 "스냅 샷"프로세스에 대해 여러 가지 날짜 범위에 대해 사용자가 반복해서 실행할 수 있습니다. 기본적으로 해당 기간 동안 금액을 저장합니다. 따라서 FinancialDetail 테이블은 집계 데이터 임에도 불구하고 많은 양의 데이터를 보유하는 경향이 있습니다. 내가 좋아하지 않는 것은 필자가 만든 FinancialDetail 테이블에 공간을 낭비하는 것으로 생각되는 20 개의 열이 있다는 사실입니다. 필자가 생각한 더 좋은 방법은 FinancialDetail 테이블의 검색 메커니즘으로 사용할 수있는 Id 열을 포함하는 FinancialAttribute라고하는 또 다른 테이블의 행에 특성의 각 고유 한 조합을 저장하는 것입니다.

TABLE: FinancialAttribute 
COLUMNS: 
    Id (Int IDENTITY) 
    Attribute1 (Int) 
    Attribute2 (Int) 
    . 
    . 
    Attribute2 (Int) 

을 그리고 FinancialDetail 테이블이로 변경 될 것입니다 : 그래서 FinancialAttribute 테이블과 같을 것이다

TABLE: FinancialDetail 
COLUMNS: 
Id (Int IDENTITY) 
FinancialHeaderId (Int FK) 
FinancialAttributeId (Int FK) 
Amount (Decimal) 

이 여러 열/속성에서 집계를 처리 할 수있는 매우 일반적인 패턴인가? 아니면 완전히 잘못된 생각으로 생각하고 있습니까? 금융 정보 테이블의 데이터를 내 로컬 사본에 저장해야합니다. 재무 정보의 이러한 사용자 정의 타임 라인 스냅 샷을 처리하거나보고해야하는 여러 다운 스트림 프로세스가 있기 때문입니다.

Answer 1

워디 질문, 말의 대답! ;)

저는 데이터웨어 하우징 전문가가 아니기 때문에 해당 영역의 패턴 (및 안티 패턴)에 익숙하지 않습니다. 나는 아마도 비슷한 것을했을지 모르는 DB 개발자로 말하고있다.

필자의 경우 처방약 정보의 큰 소스 테이블에서 스냅 샷을 찍습니다. 스냅 샷은 다운 스트림 분석 및보고에 사용됩니다. 사용자는 일반적으로 2m (20m 대) 레코드에 영향을 미치는 날짜 및 약물 유형과 같은 스냅 샷 기준을 지정합니다. 이것은 일반적으로 120k (10k 대비)의 레코드를 컴파일합니다. 소스 테이블이 시간이 지남에 따라 변경되고 히스토리가 아닌 스냅 샷은 무기한 보관됩니다. 중복 정보를 가져오고 저장하는 스냅 샷에 대한 귀하의 우려를 공유합니다.

귀하의 질문 - 당신은 바보 같은 짓을하고 계십니까? 더 좋은 방법이 있습니까?

개념적으로 말해서, 당신의 인수 분해가 "안전하다"는 것이 꽤 분명합니다. 이것에 의해, 그것은 분명히 올바른 직설적 인 변환이라는 것을 의미하며, 팩터링 된 버전을 거의 통증이없는 원본으로 다시 매핑하는 방법은 매우 분명합니다. 그 관점 (개념적 용이성)에서, 나는 그것이 장점이 있다고 생각한다.

영향에 대해서는 예상되는 테이블 크기를 고려할 것입니다.내 가정은 다음과 같습니다

가 가 가

평균 스냅 샷 기록 = 스냅 샷 당 총 순 속성 콤보는 = 10K가 시간이 지남에

총 납입 스냅 샷 = 시간에 10,000

총 순 속성 콤보 = 100,000

Amount 열 정밀도는

< 20 자리 그래서

:

01,231,592,926,814,823,224,321 0

내 가정이 공 공원 (및 내 수학 권리)에있는 경우 공간에서 78 %를 절약 할 수 있습니다. 여기에는 인덱스 또는 테이블 채우기 여유 공간이 포함되지 않으므로 실제 테이블 크기가 더 커집니다.

7GB를 절약 할 수 있습니까?

• 9GB는 현대 디스크에서 쉽게 관리되며 마스터 테이블과 비교할 필요가 없습니다.
• 어쨌든 데이터는 쿼리의 메모리에 다시 저장되므로 아마도 전선이나 캐싱을 통해 절약 할 수 있습니다. 속성에 의해
• 백업을 seaching 경우
• 쿼리 IO는 조금 더 있어야한다 /해야 복원 시간이 더
• 시간 속성을 기반으로 더 나은
• (취재) 인덱스해야한다 등의 통계를 업데이트, 색인화하는 동안 훨씬 작
• 당신의 고려 테이블에 삽입하는 쿼리 시간은

당신은이에 자신의 전화를 걸 수 있습니다 올라갈 것입니다하지만 공간이 # 1 관심사 인 경우 인수 가치가 될 수 있다는 것을 나에게 보인다 , 기술적으로 가장 최적의 솔루션이 아닐지라도 어떻게 든 0 바이트까지 당신의 속성 공간을 최적화하기 위해 관리하는 경우 효율성

말하기 ...

, 당신은 원래 떨어져 또 다른 0.09 %를 절약 할 것입니다. 따라서 공간에 대해서는 을 최적화하지 않을 것입니다.

반면에 단순히 FinancialDetail.ID를 삭제하고 (HeaderID, AttributeID)에서 PK를 사용하면 원본을 4.1 % 할인 할 수 있습니다. (가정 :이 표를 가리키는 FK가 없습니다.)

더 나은 방법이있는 한, 나는 잘 모릅니다. 얼마나 많은 스냅 샷을 얻고, 스냅 샷을 사용하며, 얼마나 빨리 사용해야하는지에 달려 있습니다.

Answer 2

보고 데이터가 차지하는 저장 공간을 줄이기 위해 합리적으로 일반적으로 사용하는 방법입니다. 데이터웨어 하우스 디자인에 사용되는 별표 패턴 패턴의 핵심에는 형태가 있습니다 (단순화하기 위해) yor 시나리오의 재무 금액)은 팩트 테이블에 저장되고 컨텍스트 제공 정적 데이터 (특성 열)는 차원 테이블에 저장됩니다.

추가 요구 사항은 FinancialAttribute 테이블을 유지 관리하는 것입니다. 이후에 새로운 속성 조합이 데이터에 표시된다고 가정하면 FinancialDetail에 연결할 수 있도록 FinancialAttribute에 추가해야합니다. 현재보고 프로세스의 구현에 따라 이는 간단한 변경 일 수 있습니다.

Answer 3

그것은

그것은이 속성에 대한 데이터를 찾기 어렵다 (NULL이됩니다 속성 값의 많은) 비효율적 인 스토리지의

• 때문에 각 속성에 대한 필드를 포함 할 수 없습니다 귀하의 제안 FinancialAttribute 테이블, 매개 변수 : SELECT ... WHERE ATTR1 = @ PARM 또는 ATTR2 = @ PARM 또는 attr3 = @ PARM ...

당신은 정상화 만들고 더 나은 것 :

TABLE: FinancialAttribute 
COLUMNS: 
    Id (Int IDENTITY) 

TABLE: FinancialAttributeValue 
COLUMNS: 
    Id (Int IDENTITY) 
    FinancialAttributeID int 
    Attribute Int 

및 특성은 단지 식별자보다 더 아무것도 경우 :

TABLE: Attribute 
COLUMNS: 
    Id (Int IDENTITY) 
    AttributeName varchar(50)