26.선진모델(2)-상품팩토리(3) 기본 카테고리
2011.08.09 15:28
'엔티티메타'를 1정규화 한 것이 속성메타라고 했습니다.
1정규화하면
속성이 로우가 됩니다.
속성이 로우의 차이는 무엇일까요? 속성은 로우라는 개체에 종속적인 요소이지만
로우는 그 자체로 구별되는 개체가 됩니다. 또한 구조의 변경 없이 무한정 추가가 가능합니다. 일반테이블의 모든 속성을 1정규화 개념으로 변환한다면 어떻게 될까요? 인조식별자 , 속성명(타입, 길이, 소숫점...), 속성값 - 이렇게 3개의 속성만 있으면 됩니다. () 속성 제외 여기서 모든 엔티티를 한 엔티티로 통합한다면 엔티티명, 인조식별자, 속성명(타입, 길이, 소숫점...), 속성값 - 이렇게 4개의 속성만 있으면 되겠지요. () 속성 제외 결론은? 심하게 이야기하면 회사에 이 테이블 딱 하나만 있으면 됩니다.
단 위의 ( ) 에 써놓은 속성들은 모두 속성명에 종속된 속성으로 2정규화하면
1,엔티티명, 인조식별자, 속성명, 속성값
2.속성명, 타입, 길이, 소숫점...
이렇게 2개의 테이블로 나누어집니다. 자 이젠 어떤 요구사항이 와도 이 테이블 두개면 구조 변경없이 다 해결할 수 있습니다.
하지만 문제가 있습니다.
.저장은 로우로 되어 있지만 볼 때는 속성으로 보길 원하는 것.
그래서 로우를 속성으로 바꾸는 피벗 작업을 프로그램에서 모두 해줘야 한다는 것입니다.
이것이 만만치 않은 프로그램이고 속도에도 많은 영향을 끼칩니다. 그래서 이렇게 모델링 된 외국의 모 보험 패키지가 성능 문제로 국내 도입에 실패한 사례도 있습니다. 여기에 인조식별자 사용으로 인한 개체무결성 문제도 존재하게 됩니다. 엔티티 메타는 피벗이 필요없습니다. 이미 속성으로 추가된 형태이기 때문입니다. 엔티티 메타와 속성메타.
상품팩토리 이야기 하다가 여기까지 왔습니다.
국내에 상품팩토리로 유형한 모회사의 구조는 엔티티메타 구조입니다.
성능문제 때문에 속성메타로 할 순 없고 결국 엔티티메타 구조로 갈 수 밖에 없었을 겁니다. 엔티티메타의 문제는 미리만들어 놓은 속성의 개수가 넘어가면 문제가 됩니다.
그래서 상품팩토리를 납품하고서 속성 최대 개수를 확인한 후 속성의 개수를 늘려주는 작업을 하게 됩니다. 그럼 속성 메타는 언제사용할까요? 추가 속성 요건이 자주 발생하는데 그 속성을 자주 사용하지 않는 경우나 성능이 문제가 되지 않는 경우인데
이런 경우는 실제론 거의 없으니 속성메타의 사용 예는 거의 없다고 봐야 합니다. 결국 현재로선 엔티티메타가 최선의 선택일 수 밖에 없습니다.
게다가 실제 프로젝트에선 일반 개발자가 프로그램을 작성하기에
속성메타는 더욱 더 사용하기 힘든 구조가 됩니다. 이 랩의 제목이 실전 모델링입니다.
즉 실제 프로젝트에서 사용되는 모델링을 목표로 합니다.
실전에서 속성메타가 사용되어 실전모델링의 대상에 포함되길 바랍니다.
이를 위해
피벗의 성능이 보장되는 DBMS가 속히 개발되길 희망해 봅니다.
그 때는 ALTER 부터 해방되는 날이 되지 않을까요?
정리하면
상품 팩토리의 현실적인 모델 구조는 '엔티티메타'이고
이제 이 엔티티 메타구조 안에서
신속한 상품개발을 위한 새로운 기법을 적용해야 합니다. 다음에 계속
속성이 로우가 됩니다.
속성이 로우의 차이는 무엇일까요? 속성은 로우라는 개체에 종속적인 요소이지만
로우는 그 자체로 구별되는 개체가 됩니다. 또한 구조의 변경 없이 무한정 추가가 가능합니다. 일반테이블의 모든 속성을 1정규화 개념으로 변환한다면 어떻게 될까요? 인조식별자 , 속성명(타입, 길이, 소숫점...), 속성값 - 이렇게 3개의 속성만 있으면 됩니다. () 속성 제외 여기서 모든 엔티티를 한 엔티티로 통합한다면 엔티티명, 인조식별자, 속성명(타입, 길이, 소숫점...), 속성값 - 이렇게 4개의 속성만 있으면 되겠지요. () 속성 제외 결론은? 심하게 이야기하면 회사에 이 테이블 딱 하나만 있으면 됩니다.
단 위의 ( ) 에 써놓은 속성들은 모두 속성명에 종속된 속성으로 2정규화하면
1,엔티티명, 인조식별자, 속성명, 속성값
2.속성명, 타입, 길이, 소숫점...
이렇게 2개의 테이블로 나누어집니다. 자 이젠 어떤 요구사항이 와도 이 테이블 두개면 구조 변경없이 다 해결할 수 있습니다.
하지만 문제가 있습니다.
.저장은 로우로 되어 있지만 볼 때는 속성으로 보길 원하는 것.
그래서 로우를 속성으로 바꾸는 피벗 작업을 프로그램에서 모두 해줘야 한다는 것입니다.
이것이 만만치 않은 프로그램이고 속도에도 많은 영향을 끼칩니다. 그래서 이렇게 모델링 된 외국의 모 보험 패키지가 성능 문제로 국내 도입에 실패한 사례도 있습니다. 여기에 인조식별자 사용으로 인한 개체무결성 문제도 존재하게 됩니다. 엔티티 메타는 피벗이 필요없습니다. 이미 속성으로 추가된 형태이기 때문입니다. 엔티티 메타와 속성메타.
상품팩토리 이야기 하다가 여기까지 왔습니다.
국내에 상품팩토리로 유형한 모회사의 구조는 엔티티메타 구조입니다.
성능문제 때문에 속성메타로 할 순 없고 결국 엔티티메타 구조로 갈 수 밖에 없었을 겁니다. 엔티티메타의 문제는 미리만들어 놓은 속성의 개수가 넘어가면 문제가 됩니다.
그래서 상품팩토리를 납품하고서 속성 최대 개수를 확인한 후 속성의 개수를 늘려주는 작업을 하게 됩니다. 그럼 속성 메타는 언제사용할까요? 추가 속성 요건이 자주 발생하는데 그 속성을 자주 사용하지 않는 경우나 성능이 문제가 되지 않는 경우인데
이런 경우는 실제론 거의 없으니 속성메타의 사용 예는 거의 없다고 봐야 합니다. 결국 현재로선 엔티티메타가 최선의 선택일 수 밖에 없습니다.
게다가 실제 프로젝트에선 일반 개발자가 프로그램을 작성하기에
속성메타는 더욱 더 사용하기 힘든 구조가 됩니다. 이 랩의 제목이 실전 모델링입니다.
즉 실제 프로젝트에서 사용되는 모델링을 목표로 합니다.
실전에서 속성메타가 사용되어 실전모델링의 대상에 포함되길 바랍니다.
이를 위해
피벗의 성능이 보장되는 DBMS가 속히 개발되길 희망해 봅니다.
그 때는 ALTER 부터 해방되는 날이 되지 않을까요?
정리하면
상품 팩토리의 현실적인 모델 구조는 '엔티티메타'이고
이제 이 엔티티 메타구조 안에서
신속한 상품개발을 위한 새로운 기법을 적용해야 합니다. 다음에 계속
- Tag :
- Modeling
Comments 5
-
관계형 모델링 이론이 대부분 정규화 부분에 치우쳐 위의 내용에 관한 책들이 거의 없습니다. 용어는 저의 회사 내에서 정의해서 사용한 것입니다. 참고할 가치가 있는 외국 책... 제가 운이 없어서 그런 것인지 거의 못 보았습니다. (실전 모델링 내용 기준해서 말씀드린 것입니다.) 소개해 드리지 못해 죄송합니다. 그리고 말씀하신 대로 메타 형식의 프로그램은 복잡합니다. 그래서 상품팩토리라는 패키지 프로그램이 판매되기도 합니다. 사용자는 내부 구조와 프로그램 모르고 사용만 하는 것이죠. 하지만 부분적으로 이런 모델을 사용할 경우가 있으니 반드시 알아 두는 것이 좋습니다.
-
안녕하세요?
오늘 데이토(dator)라는 포탈이 있는지 처음 알았습니다.
유용한 내용이 많고 유익한듯 합니다. 요즘 모델링에 관심이 많아서 안희진님의 글을 읽어 봤는데 정말 많은 도움이 됩니다.
감사합니다. 꾸벅^^
그런데, 몇가지 궁금한 사항이 있어서 질문해 봅니다.
"선진모델, 엔티티메타, 속성메타, 피벗" 이런 용어는 처음 들어서
안희진님의 글을 몇번 반복해서 읽고서 이제 겨우 이해 되는듯 합니다.
"엔티티메타"는 클라이언트쪽 개발자들의 작업 부담이 오히려 증가하고,
프로그램 코드 판독성이 복잡해져서 선진모델에 역행할 수도 있다고 봅니다만...
그래서 언급하신 것처럼 "속성메타"를 지원하는 새로운 DBMS가 나오면 좋은데,
이것도 "피벗"에 상당한 어려움이 있을듯 합니다.
왜냐하면, DBMS가 "피벗"을 스스로 알아서 하지는 못하고
사용자가 결국은 학습시켜 주어야 할듯 해서요... 그런데, "엔티티메타, 속성메타, 피벗"
이런 용어들은 어디에서 참고한 것인지 궁금합니다.
아무래도 외국서적에 있는 영단어를 한글로 표현한 느낌이 있는데,
혹시 외국서를 참고하고 계시다면, 어떤 참고서적인지 알 수 있을까요?
예상대로 유지보수 측면에서보면 개발자는 천국이지만 사용자 입장에서 보면 속도에 역시 문제가 있네요.........그나마 제일 많은 건 수의 설비가 400이라 아직은 참으면서 사용하여 달라고 부탁하는 수준입니다......
VIEW 형태로 처리를 하여도 근본적인 속도 개선은 아직인 거 같습니다.....
좋은 글 잘 읽었습니다.