3.2. 논리 모델

• 논리 모델링 단계에서는 개념 모델을 상세화 함

• 개념 모델링에서 도출된 핵심적인 엔터티에 대해서는 이미 도출된 중요 속성 이외의 전체 속성을 도출해야 하고
  개념 모델링 단계에서 도출되지 않은 대부분의 엔터티가 도출돼야 함

• 관계를 포함한 사실상 모든 데이터 요소가 도출돼야 하므로 전체 데이터 모델링 과정에서 가장 오랜 시간이 소요됨

• 논리 모델 구조는 물리 모델과 거의 유사하므로 논리 모델이 완료되면 사실상 모델 구조적으로는 거의 모든 결정이 이루어짐

• 물리 모델링 단계에서 엔터티의 합체나 분해에 따라 구조가 약간 바뀔 수 있음

• 비정규화를 수행하고 파티션 등의 물리적 요소를 고려하면 속성이 바뀔 수 있지만,
  만약 모델 구조상으로 큰 변화가 발생하면 논리 모델링을 잘못 수행한 것

• 논리 모델링이 끝나면 모델 구조적으로 거의 완성된 모델이 됨

• 개념 모델은 태생이 정량적이지 않지만, 논리 모델은 모델링 완료 여부를 정량적으로 가늠해볼 수 있어 경계가 비교적 분명함

• 논리 모델링의 목적은 비즈니스 요건을 빠짐없이 정확히 반영하는 것이며 완료되면 사실상 데이터 모델링은 완료됨

• 논리 모델에는 실체,행위,목적 엔터티 등 모든 엔터티가 도출돼야 하며 시스템 속성을 제외한 전체 속성이 도출돼야 함

• 개념 모델은 중요한 비즈니스에 대한 개념을 이해하는데 도움을 주는 모델임

• 단순히 데이터의 표현 범위로 얘기할 수 있는 모델이 아니며 개념 모델에 적은 엔터티와 적은 속성이 도출돼도
  해당 업무에 대한 개념을 파악하는 사람이 있을 것이고 그렇지 않은 사람도 있음

• 업무를 얘기하고 의견을 교환하고 진행해 나가는데 도움을 주는 모델이 개념 모델임

• 논리 모델은 더는 삭제할 엔터티나 속성 및 관계가 없는 모델임

• 반면에 물리 모델은 업무적으로 필요한 속성이 모두 존재하면서 삭제할 요소들이 명백한 모델임

• 조인하지 않으려고 가져다 놓은 중복 속성, 미리 계산해 놓은 추출 속성, 감사 추적 용도로 사용하는 속성 등은 삭제해도 업무를 수행하는 데 지장이 없음

• 분석 과정에서 필요하다고 판단된 중복, 추출 속성 등이 커뮤니케이션에 도움되면 논리 모델에 포함함

• 상세화된 논리 모델에 성능 측면을 고려하지 않을 이유는 없음

• 주 식별자도 업무 식별자의 효율성을 판단해 인조 식별자를 채택할지를 결정함

엔터티 정의

• 핵심적인 중요 엔터티만을 대상으로 모델의 핵심 토대를 구축하는 것이 개념 모델링 단계의 목적

• 논리 모델링 단계에서는 구축된 핵심 엔터티를 중심으로 전체 엔터티를 상세화해야 함

• 상세화히는 과정에서 실체, 행위, 목적, 기준 엔터티가 모두 도출되며 누락되는 업무가 없어야 함

• 엔터티를 정의할 때 가장 중요한 원칙은 데이터의 성격(정체성)에 맞도록 엔터티를 도출해야 함

• 유사한 데이터가 여러 엔터티에 존재해서도 안 되며 하나의 엔터티에 여러 가지 데이터가 혼재돼 있어서도 안 됨

• 엔터티를 정의하는 것과 주 식별자를 정의하는 것은 불가분의 관계임

관계 도출

• 논리 모델링 단계에서는 엔터티 간의 모든 관계(1촌 관계)를 도출해야 함

• 관계는 속성으로 나타나므로 모든 속성을 도출해야하는 논리 모텔에는 모든 관계가 도출됨

• 일부 추출 관계는 물리 모델링 단계에서 추가될 수 있음

• 관계를 도출할 때는 실제로 참조 무결성(Referential Integrity) 제약으로 관리되지 않는 관계를 추가하지 않도록 주의해야 함

속성 도출

• 논리 모델에는 업무적으로 필요한 모든 속성이 도출돼야 함

• 즉 엔터티를 묘사하는 속성이 모두 존재해야 함

• 더 삭제할 것이 없는 모델이 논리 모델지만, 현실적으로 중복, 추출 속성 등이 다소 포함됨

• 전체 엔터티에 포힘돼 감사 추적(Audir Trail) 용도로 사용되는 시스템 속성만이 제외됨

• 시스템 속성은 작업의 편이성을 위해 물리 모델에 일괄 적용히는 것이 효율적

• 논리 모델에는 모든 요구 사항을 반영해야하므로 모든 속성이 도출되며, 성능문제는 개발에 종속적임

• SQL의 작성 능력에 따라 성능 문제가 발생하지 않을 수도 있으머,
  SQL에 따른 인덱스 설계가 주로 개발 도중에 진행되므로 성능 문제를 인지히는 시점이 달라질 수 있어
  논리 모델링 단계에서 성능 문제를 추측하는 것은 무리임
  개발 시점에 성능 문제가 도출되면 인덱스나 SQL 튜닝으로 해결하고 여의치 않으면 여러 비정규화 방안을 고려함
  이때 중복 속성이나 추출 속성이 추가돼 모델 변경이 발생함

• 비정규화에 의한 속성 추가, 삭제, 일대일 엔터티의 협체, 분해 등은 발생할 수 있음

• 개발중에 업무의 변경이나 추가로 속성이 변경되기도함

주 식별자 확정

• 주식별자는 중요한 속성이기도 히지만 엔터티 정의와 관련된 속성임

• 주식별자는 엔터티를 정의하는 것과 동시에 도출돼야 함

• 엔터티를 정의하는 과정에서 주 식별자는 대부분 결정됨

• 이 단계에서는 이미 도출된 주 식별자를 다시 한번 확인하는 단계임

• 엔터티를 도출할 당시에는 자신의 견해에서만 주 식별자를 판단할 수 밖에 없지만,
  주변 엔터티까지 도출된 상태에서는 다른 엔터티와 관계로 고려할 사항이 생길 수 있음
  다른 엔터티의 관계끼지 고려해 주 식별자를 최종적으로 확정하는 단계임
  물론 물리 모델링 단계에서 PK(Primary Key)가 최종적으로 확정됨
  대부분 논리 모델의 주 식별자가 물리 모델의 PK가 되지만 간혹 물리 모델링 단계에서 PK가 비뀔 수도 있음

정규화

• 정규화는 RDB(Relational Database)에서 가장 중요한 개념이므로 논리 모델링 단계에서 반드시 고려해야 함

• 원칙적인 논리 모델은 완전한 형태의 정규형 모델임

• 중복 데이터를 제거해 아노말리가 발생하지 않도록 하는 게 논리 모델링 단계의 기본적인 목표이므로 정규화는 반드시 거쳐야함

이력 관리

• 데이터가 새로 생기는 것은 내역 데이터임
  이미 생성된 데이터가 변경되면 이력 데이터가 됨
  내역과 이력은 발생 시점과 변경 시점에 생성되는 차이가 있음

• 이력 데이터를 어떻게 관리할지는 개념 모델링 단계에서도 고려해야함

• 이력 관리 방법에 따라 주 식별자가 달라질 수 있고 이로 다른 엔터티와 관계가 변경될 수 있으므로
  모델링 초반이라도 중요한 업무에 대해서는 반드시 고려해야 함

• 이력 관리 방법을 결정하는 시점은 다소 유동적일 수 있음

• 엔터티를 정의할 때 이력 관리 방법까지 종합적으로 판단히는 것이 바람직함

• 특히 핵심 엔터티에 대해서는 이력 데이터까지 고려

• 대부분의 엔터티처럼 주변 엔터티에 미치는 영향이 없거나 미미하면 논리 모델링이 마무리되는 시점에 이력 관리 방안을 반영

논리 모델 검증

• 논리 모델은 현행 엔터티를 기준으로 작업 진도를 어느 정도 정량적으로 계산할 수 있음

• 논리 모델에 대한 검증도 정량적으로 이루어질 수 있음

• 물론 모델링에서 가장 중요한 엔터티 정의는 정량적으로 계산하기 대단히 어려움

• 논리 모델을 검증하는 가장 기본적인 방법은 현행 엔터티와 매핑(Mapping)하면
  현행 업무가 빠진 것이 있는지를 검증할 수 있음. 더욱 상세한 검증은 현행 속성과의 매핑임

• 또 한 가지의 매핑은 어플리케이션과의 매핑임
  어플리케이선 분석, 설계에 의해서 많은 산출물이 나오는데 그중에서 일부를 선정할 수 있음
  가장 바람직한 매핑은 향후(To be) 화면과의 매핑임. 향후(Tobe) 화면과 향후 엔터티,
  더 나아가서 화면에서 사용한 항목과 엔터티의 속성까지 매핑하면 상호 검증이 됨

• 또 다른 엔터티 검증방법은 사례 데이터를 작성하는 것
  중요한 엔터티는 사례 데이터를 작성하고 의도한 대로 데이터가 생성되는지를 검증함
  그리고 사례 데이터를 활용해 모델을 리뷰함. 빠른방법이 될 수 있어 핵심적인 엔터티는 반드시 수행할 것을 적극적으로 권장함

• 코드매핑은 현행 코드와 향후 코드를 매핑함으로써 모델을 더욱 심도 있게 검증할 수 있음

• 검증 방법은 모델링 기간에 따라 절대적으로 영향을 받음
  현실적으로 요구 사항을 파악하고 모델을 설계하는 것만으로도 버거운 상황에서 위와 같이 다양한 방법으로 검증하는 것은 쉽지 않음.
  오히려 부족한 시간내에서 현행, 향후 데이터 매핑 등의 업무로 인해 정작 중요한 모델 설계를 소홀히 할 수 있음
  엔터티 정의가 제대로 되지 않은 상황에서 매핑과 같은 정량적인 검증은 형식적이고 무의함으로 엔터티를 명확하게 정의하는 것이 우선임