현재 SQL Server, SSIS 및 SSAS를 사용하는 데이터웨어 하우스의 팩트 및 차원 테이블을 디자인하고 있습니다. 차원과 사실 테이블 간의 관계를 SQL로 프로그래밍하면 어떤 실질적인 이점을 얻을 수 있습니까? 큐브를 만들 때가되면 수동으로 관계를 정의하는 것이 더 낫지 않습니까?스타 스키마 테이블 디자인에 관계를 포함하면 어떤 이점이 있습니까?
테이블에 데이터를 삽입 할 때 아무런 제약이 없다면 데이터를로드하고 변환하는 것이 쉬우므로 관계를 제외하십시오.
테이블에 외래 키 제약 조건을 넣으려는 의미로 "관계 성 프로그래밍"을 해석합니다.
아니요, 데이터웨어 하우스에서 팩트 테이블에 기본 키 또는 외래 키 제약 조건을 적용해서는 안됩니다.
몇 가지 문제에 대해 언급했지만 또 다른 문제점은 이러한 제약 조건으로 인해 행을 삽입 할 때 성능 오버 헤드가 발생하여 ETL 프로세스의 비용이 높아진다는 것입니다.
트랜잭션 데이터베이스 디자인에 경험이있는 사람에게 이것은 학습하고 경험 한 모든 것에 반대 할 수 있습니다. 외래 키 제약 조건은 동시에 데이터를 수정하는 여러 프로세스가있는 데이터베이스에서 매우 중요합니다. 개발자의 최선의 노력에도 불구하고 두 가지 프로세스가 어떻게 든 데이터를 엉망으로 만들 위험이 있습니다. 제약 조건은 근본적으로 중요한 안전망입니다.
차원 모델에서 데이터베이스는 하나의 ETL 프로세스에 의해, 그리고 고도로 제어 된 방식으로 만 채워집니다. 이렇게하면 데이터가 손상 될 위험이 크게 줄어들어 추가 비용 제약 조건이 발생하지 않을 수 있습니다.
DW에 대한 업데이트가 '대부분'제어되지만 항상 그런 것은 아니기 때문에 FK 제약이 필요하다고 생각합니다. 예를 들어, 수동 데이터 수정은 데이터 문제 등으로 인해 발생합니다. [이상]이 일은해서는 안되지만 .... :)]
키가 성능에 영향을 미치지 않도록로드하기 전에 해제하고 다시 사용하도록 설정할 수 있습니다. 이렇게하면 데이터가 정확하다는 확신이 생길 수 있으며로드하는 동안 성능 문제가 제거 될 수 있습니다. 또 다른 사실은 처리 시간이 대부분의 데이터웨어 하우스의 주요 제약 조건이 아니라는 것입니다.
잠재적 인 데이터 무결성 문제를 해결하는 데 필요한 시간을 고려하면 FK를 사용하는 것이 좋습니다.
완벽한 답변! 감사! – rrydman