안녕하세요,

type_id라는 정보를 데이터 테이블에서 각각 5개가 동시에 참조하는 형태인가요?

 제가 이해한게 맞는지 모르겠지만...

어떤 응용(쿼리)가 많을 지에 따라 물리모델이 많이 다르겠지만,

위와 같이 데이터 테이블(참조하는)에 같은 데이터를 중복하는 거보다, 참조당하는 코드테이블을 코드가 쓰이는 영역을 구분해서 두는 것도 생각해 볼 수 있겠네요.

코드보다는 데이터 테이블이 더 커질 가능성이 크지 않겠습니까?

보기엔 CDR 데이터 같은데요, 작은 사이즈의 코드 테이블을 중복하더라도 CDR 데이터(Fact)가 작게 유지하는 쪽으로 방향을 잡아야 할 듯합니다.

그리고 쿼리 성격이 Analytics인지 특정 목적에 제한된 것인지도 고려해야겠죠.

CDR데이터를 가지고 DW를 구성하시는 과정이라면, 그것도 PostgreSQL을 가지고 하는 것이라면 먼저 응용을 먼저 따져보고 가장 접한한 모습을 만들어가야 하는데요. 보기엔 바로 코드 테이블과 조인을 생각하시는 것으로 봐서는 중간 스테이징쪽은 아니고 본 DW로 판단이 됩니다. fact-dimensional 모델로 구성할지 single fact 형태 일지는 데이터사이즈나 별도의 분석장비(OLAP)가 있는지도 고려대상이 됩니다. single fact 형태로 구성하고 분석 엔진이 없는 상황이라면 나중에 성능유지가 어렵더군요. (테이블 하나가 옆으로 밑으로 커지게 되는 구조라서...) 쓰다보니 횡성수설이 되어 버렸군요. 암튼 제가 하고 싶은 이야기는 뭐냐하면... 데이터의 응용방식에 따라 모델이 달라진다는 겁니다. CDR데이터라서 OLTP는 아닐 것이고 DW/OLAP응용일 가능성이 큰데... 그렇다면 위에 말씀드린 것 같이 코드(차원)에 구분컬럼을 두어 늘리고, 그 대신 데이터(Fact) 테이블은 '구분, 코드' 데이터 사이즈를 줄이는 방법도 있습니다. DW에서는 Fact 줄이는게 최곱니다. 코드(차원)은 일반적은 경우가 아니라면 아주 크게 늘어나지 않습니다. 응용을 조금 더 설명해주세요.....

그리고 데이터 테이블의 5개의 컬럼의 독립적으로 쿼리에 쓰이는 경우가 많다면 합치는게 오히려 안 좋을 수 있겠죠?

자꾸 결론이 삼천포로 가는데요.

암튼 코드테이블이 DW, 그것도 fact-dim 모델이라면 응용에 맞게 계층구조로 만드시면 됩니다.

쿼리는 걱정하지 마시고 다차원모델을 먼저 고민하세요. Fact-dim 모델이라면 대부분 '스타쿼리'에서 크게 벗어나지 않습니다.

예.. 정확합니다..ㅋ CDR이 맞습니다

아무 자료도없이 하나하나 머리로 들이박으면서 하는것이라
아직은 많이 미숙합니다만, 남겨주신 댓글을 보며 이해하려고 하고있습니다


type_id 는 참조하는 컬럼중에 하나일뿐이고, 다른 여러개의 컬럼들이 각각의 값을 참조합니다

type_id 는 ref_peg 테이블의 description 컬럼의 type_id 를 참조하고
record_type 은 ref_peg 테이블의 description 컬럼의 record_type 을 참조하는방식으로
진행하려고했습니다.(이런식으로 나머지 참조영역도 description 항목을 참조하게 하려고했음)
그래서 서브쿼리란것을 이용해보려고했는데 잘 안되네요..
그래서 질문을 올린것인데, 답글해주신게 생각보다 더 많은정보를 주신것같아 다행입니다


지금 만드려고 하는것은 아주 단순한 형태의 CDR조회 프로그램을 만드려고합니다.
착/발 번호 조회, 오류콜조회, 커즈벨류 기준조회 등등, CDR파일을 일일이 까내서 찾던것을
특정 처리 서버로 복사해서 DB화한다음 조회/출력 등을 용이하게 만들 생각이었습니다.

이것의 최종형태는 사용한 트렁크라인이라던가 등을 시각화하여
관리자가 쉽게 피크타임에 사용하는 라인을 체크가능하게 하여 라인증설/감축 등의
정보를 제공하고, 회선다운에 대한 시각적인 정보제공을 목표로... 

그냥 혼자 삽질하고있습니다-_-




DB는.. 지금 아주 기초서적 가지고 잡고있기에 정확하게 남겨주신 댓글이 무슨내용인지는
이해하기 어려우나 대략적으로 이해하고있습니다.


쿼리성격은.. Analytics 한것이겠구요,
DW는 dataware 인것같습니다. 맞는것같아요
중간 스테이징이라는것은 ETL을 통한 가공인지요?
fact-dimensional 과 single fact 라는것은 잘 모르겠군요...
아, 그리고 데이터를 작게 잡으란 얘기는 어떤뜻인지요?
컬럼수를 최대한 줄이고 출력할때 JOIN 으로 엮어서 뿌리란 말씀인지요? 
단순 CDR조회기능으로 쓰기엔 성능이 상당히 떨어질것같아서요..

그게 아니라면 위에 예시에서 ref_peg 에 참조를 여러개 집어넣은것을
각각의 테이블로 쪼개서 보관하라는 말씀이신지..



아마도 교환기 몇개에서 나오는 CDR을 처리하는것이 목표긴하지만 지금은
특정 타겟만 파고있습니다.
몇개의 교환기에서 쏟아져나오는 CDR을 처리할때쯤되면 아마도 ETL이나 PERL,PYTHON을 이용해
CDR가공이 필요하겠지요

지금은 교환기 한개만잡고 씨름중입니다.
나오는 CDR 가공없이 그대로 넣고있구요..


데이터 테이블의 5개 컬럼(아마도 참조영역인것같군요)이 따로 쓰이는경우가..
아마도 있긴하겠지요, 특정 커즈벨류 기준 정렬이라던가, 사용된 인터페이스 종류별로 정렬이라던가

아마도 그런게 있긴하겠는데.. 그럼 역시 따로 떨어뜨려놓는게 성능상 이롭단 말씀이겠군요
쏟아져나오는 CDR이 하루 수십~수백만건은 될거같으니.. 조금이라도 성능에 이로운게 좋을거같네요...


말씀하시는 용어에 대해서 이해하려면 대략적으로 DB 라는 분야의 어느부분을 참고해야할지 지적해주시면 연구해보겠습니다


아직은 학생인데..

학교돌아가면 DB과목 제대로 배워봐야할거같네요..ㅠㅠ 
두분다 정성스럽게 답글주셔서 감사합니다.

특히 김영우님께는 CDR가공건때부터 계속 도움받고있어서 항상 감사히생각하고있습니다 ...^^...

안녕하세요, 성제호님.

방금 장문의 댓글을 쓰다가 날려먹어서 의욕상실입니다. ㅡ.ㅡ;;

모델에 대한 간단한 설명과 함께 응용에 대한 설명을 메일로 주시면 제가 아는 범위내에서 정리하여 회신드리겠습니다.

warwithin@gmail.com

감사합니다.

그리고 아직 논리모델링에 대한 부분을 고민하고 계시다면,

http://www.redbooks.ibm.com/abstracts/sg247138.html

위 문서나, Kimball 의 The Data Warehouse Toolkit이라는 책이 있습니다. 참고하시면 도움이 될겁니다.