DATOR

26.선진모델(2)-상품팩토리(3) 기본 카테고리


2011.08.09 15:28 안희진 | 조회수 : 40312

'엔티티메타'를 1정규화 한 것이 속성메타라고 했습니다.

 

1정규화하면
속성이 로우가 됩니다.
속성이 로우의 차이는 무엇일까요?

속성은 로우라는 개체에 종속적인 요소이지만
로우는 그 자체로 구별되는 개체가 됩니다.

또한 구조의 변경 없이 무한정 추가가 가능합니다.

 

일반테이블의  모든 속성을 1정규화 개념으로 변환한다면 어떻게 될까요?

 

 인조식별자 , 속성명(타입, 길이, 소숫점...), 속성값 - 이렇게 3개의 속성만 있으면 됩니다. () 속성 제외

 

여기서 모든 엔티티를 한 엔티티로 통합한다면

엔티티명, 인조식별자, 속성명(타입, 길이, 소숫점...), 속성값 - 이렇게 4개의 속성만 있으면 되겠지요.  () 속성 제외

 

결론은? 

심하게 이야기하면 회사에 이 테이블 딱 하나만 있으면 됩니다.


단

위의 ( ) 에 써놓은 속성들은 모두 속성명에 종속된 속성으로  2정규화하면
1,엔티티명, 인조식별자, 속성명, 속성값
2.속성명, 타입, 길이, 소숫점...
이렇게 2개의 테이블로 나누어집니다.

 

 

자 이젠 어떤 요구사항이 와도 이 테이블 두개면 구조 변경없이 다 해결할 수 있습니다.


하지만 문제가 있습니다.
.저장은 로우로 되어 있지만 볼 때는 속성으로 보길 원하는 것.
그래서 로우를 속성으로 바꾸는 피벗 작업을 프로그램에서 모두 해줘야 한다는 것입니다.
이것이 만만치 않은 프로그램이고 속도에도 많은 영향을 끼칩니다.

그래서 이렇게 모델링 된 외국의 모 보험 패키지가 성능 문제로 국내 도입에 실패한 사례도 있습니다.

여기에 인조식별자 사용으로 인한 개체무결성 문제도 존재하게 됩니다.

 

엔티티 메타는 피벗이 필요없습니다.  이미 속성으로 추가된 형태이기 때문입니다.

 

엔티티 메타와 속성메타.


상품팩토리 이야기 하다가 여기까지 왔습니다.
국내에 상품팩토리로 유형한 모회사의 구조는 엔티티메타 구조입니다.
성능문제 때문에 속성메타로 할 순 없고 결국 엔티티메타 구조로 갈 수 밖에 없었을 겁니다.

엔티티메타의 문제는 미리만들어 놓은 속성의 개수가 넘어가면 문제가 됩니다.
그래서 상품팩토리를 납품하고서 속성 최대 개수를 확인한 후 속성의 개수를 늘려주는 작업을 하게 됩니다.

 

그럼 속성 메타는 언제사용할까요?

추가 속성 요건이 자주 발생하는데  그 속성을 자주 사용하지 않는 경우나 성능이 문제가 되지 않는 경우인데
이런 경우는 실제론 거의 없으니 속성메타의 사용 예는 거의 없다고 봐야 합니다.

 

결국 현재로선 엔티티메타가 최선의 선택일 수 밖에 없습니다.
게다가 실제 프로젝트에선 일반 개발자가 프로그램을 작성하기에
속성메타는 더욱 더 사용하기 힘든 구조가 됩니다.

 

이 랩의 제목이 실전 모델링입니다.
즉 실제 프로젝트에서 사용되는 모델링을 목표로 합니다.
실전에서 속성메타가 사용되어 실전모델링의 대상에 포함되길 바랍니다.
이를 위해
피벗의 성능이 보장되는 DBMS가 속히 개발되길 희망해 봅니다.
그 때는  ALTER 부터 해방되는 날이 되지 않을까요?

 
정리하면
상품 팩토리의 현실적인 모델 구조는 '엔티티메타'이고
이제 이 엔티티 메타구조 안에서
신속한 상품개발을 위한 새로운 기법을 적용해야 합니다.

 

 

다음에 계속


 

Tag :

Leave Comments

카테고리

전체글 (36)

최근 글

최근 댓글

최근 엮인글

태그