개념, 논리 모델링

모델링의 정의

• 모델링의 정의는 영속성을 갖는 데이터에 대한 시스템 구조를 사람이 이해할 수 있도록 형상화하는 과정임
• 개념적 모델링을 거쳐 식별한 것을 기호 등을 통해 추상화하여 표현, 논리적 모델링을 하고 정보 시스템의 데이터베이스로 구축하기 위해 추상화된 모델을 구체화된 형태로 변환하는 것을 물리적 모델링이라고 함

 

식별자 상속

• 집합 간의 베타 관계를 해소하고 두 집합을 통합 테이블 형태로 설계한 경우 개인 개발 생산성이 증대되고 성능 향상 효과도 기대할 수 있음
• 개인 고객 속성과 법인 고객 속성이 같은 테이블에 혼합되어 존재함으로 속성의 의미가 불분명해지고, not null 제약 조건을 반영할 수 없어 데이터 무결성 문제가 발생할 수 있음
• 데이터 정합성 문제가 발생하지 않도록 응용 프로그램에서 업무 규칙을 추가로 설계하고 반영해야 함
• 식별자 상속은 식별 관계와 비식별 관계로 구분할 수 있음
• 식별 관계는 참조되는 상위 엔티티, 식별자가 참조하는 하위엔티티 비식별자로 상속되는 경우를 말하고, 비식별 관계는 식별자가 아닌 일반 속성으로 상속되는 관계를 말함

 

 

데이터 모델링의 정규형

• 유형을 만족하지 못하는 모델은 개념이 명확하지 않거나 다수의 개념을 하나의 엔티티에 포함한 것이므로 개념을 분리하여 모델링을 하면 대부분 정규형을 만족하는 결과를 얻게 됨
• 별도 정규화 과정을 거치지 않았다 해도 데이터 모델링 완전성을 확인해 본다는 측면에서 정규형을 만족하고 있는지 검토할 수 있음
• 정규화를 너무 심하게 할 경우 응용 프로그램에서 조인이 빈번하게 발생해 성능이 저하되지 않을까 걱정할 수 있음

 

 

정규화의 개념

• 정교화는 물리모델링이 아닌 논리모델링 과정에서 ER 모델과 함께 적용하는 것이 일반적임
• 부채꼴 함정은 제3정규형에서 발생하는 문제임
• 부채꼴 함정은 엔티티 사이의 관계가 정의되어 있지만 관계가 모호한 경우 m:n 관계를 해결하기 위해 교차 엔티티를 도입하면서 1대 1 관계를 만들 때 일어날 수 있음
• 엔티티 간 관계를 잘못 설계하여 연계된 정보를 추적하지 못해 발생함으로 이들 간 관계를 명확히 하여 해결할 수 있음

 

 

데이터 모델링의 개념

• 데이터 모델링은 데이터 아키텍처의 핵심 구성 요소임
• 데이터 모델링은 프로젝트 상황에 따라 하향식 접근 방식과 상향식 접근 방식 두 가지가 있음

 

 

리버스 모델링의 개념

• 직무 면접을 갔을 때 소통 성향이라든지 외향적인 성향이라든지 이런 것들이 중요하게 여겨질 수 있음
• 리버스 모델 활용이라는 개념이 새로워서 알면 좋을 것 같음
• 리버스 모델링은 데이터 모델을 현행화하는 과정을 말함
• 보충 설명: DB 메타 정보로 기초 데이터 모델을 생성, 즉 엔티티를 생성하고 컬럼에 대한 코멘트 정보를 이용하거나 시스템 운영자의 지원을 받아 한글명으로 속성을 수정하는데 FK 제약 조건이 없는 경우가 대부분이므로 현행 시스템 산출물을 최대한 활용하고 업무나 시스템을 잘 아는 시스템 운영자에게 도움을 요청할 수 있다

 

 

데이터 분산 전략

• 할당된 it 자원을 파악할 수 있어 정보 시스템 구축에 따른 중복 투자를 방지할 수 있고 이미 투입된 자원을 효율적으로 재분배할 수 있음
• 데이터 관리 차원에서는 데이터에 대한 통합, 연계, 중복 등에 대한 방안을 수립하는 데 기초 자료로 활용할 수 있음
• 데이터 분산 전략 수립 시 데이터 주제 영역별로 분산 아키텍, 주제 영역 단위로 담당자를 지정하여 데이터 모델링 작업을 수행하고 각각의 데이터 모델을 통합할 수 있는 근간을 제공하여 시스템 개발 및 유지보수 활동을 효율적으로 수행할 수 있음

 

 

개념 모델의 속성 정의

• 데이터를 바라보는 관점에 따라 완전히 다른 주제 영역으로 분류될 수 있으므로 데이터 관점으로 접근할지, 업무나 기능 중심으로 분류할지 고객을 포함한 이해관계자와 충분히 협의하여 진행하는 것이 좋음
• 식별자 및 속성 정의에 대한 이야기
• 개념 모델링을 하다 보면 모델러에 따라 속성 전체를 노출해야 한다는 사람도 있고, 식별자와 일부 속성 정도로 극히 일부만 노출하면 된다는 사람도 있음
• 개념 모델을 누가 어떤 용도로 사용할지를 생각한다면 답은 대충 나오는 것 같음

 

 

논리 데이터 모델링

• 논리 데이터 모델링은 모든 업무 영역에 필요한 데이터 모델을 설계하고 시스템 관점에서 필요한 데이터 항목은 반영하지 않음
• 데이터에 대한 이력 관리 대상은 업무 측면에서 꼭 관리할 필요가 있는 부분은 반영해야 함
• 논리모델링은 개념 데이터 모델과 지속해서 구조적 일관성을 유지하면서 진행함

 

 

엔티티 통합의 개념

• 데이터를 수집할 수 있는 대상이 고객이 될 수도 있고, 동의 절차를 통과해야 비로소 고객 집합에 포함될 수도 있어서 까다로움
• 엔티티는 업무 행위에 대한 상세 배역 및 업무 결과에 대한 상태를 나타내는 엔티티이며, 중요 엔티티에 종속되거나 다른 행위 엔티티에 종속됨
• 엔티티 통합은 엔티티 일반화를 통해 구조적인 측면에서 하나의 엔티티로 설계하는 경우도 있고, 여러 시스템이나 업무에서 개별적으로 관리하던 데이터를 모아 관리하는 데이터 통합도 있음
• 투비 데이터 모델의 설계 방향을 수립할 때 데이터 및 엔티티 통합이 핵심 개선 요소로 많이 언급됨

 

 

식별자 상속 관계와 비식별자 상속 관계

• 식별자 상속 관계와 비식별자 상속 관계의 차이는 FK가 어디에 위치하느냐임
• 식별자 상속 관계는 FK가 곧 PK키를 갖는 엔티티를 구별하는 역할까지 동시에 수행하는 것임
• 비식별적 상속 관계인 경우에는 관계를 통해서 FK를 받긴 하지만 그게 곧 FK이 갖고 있는 엔티티의 PK까진 아닌 거임

 

 

 

M:N 관계

• 고객과 상품, 주문과 배송처럼 핵심 엔티티나 중요한 엔티티 간 관계를 개념적으로 표현할 때 나타난다.
• 논리 모델에서는 엔티티를 상세화하거나 교차하는 엔티티를 설계하여 m:n 관계를 1대 1 관계로 표현한다.
  M:N 관계가 완전히 해소될 때까지 1대 m 관계를 분해해야 한다.

 

 

속성

• 데이터 표준 도메인과 매우 깊은 관계가 있으며, 번호, 코드, 명칭, 설명, 금액, 날짜, 비율 등 도메인을 중심으로 데이터 성격을 식별할 수도 있다.
• 데이터 발생 규칙을 기술하기도 한다.

 

 

식별자 지정

• 유일하게 식별 가능하고 최소 속성으로 구성하고 변하지 않으면서 반드시 존재하는 값
• 자세한 얘기는 SQLD 요약본에. 모든 엔티티는 식별자가 있어야 되는데 없는 경우는 로그 성격 데이터거나 데이터로서 가치를 갖지 않는 임시 저장 성격의 데이터 가능성이 높다.
• 그래서 데이터 간 특성의 구분이 식별자로 이루어질 수도 있다는 걸 배우게 됐고, 엔티티 개체가 처음부터 유일하게 존재하는 것이 아니라 업무 처리나 이벤트 성격의 데이터인 경우 회원 아이디, 계좌번호처럼 아이디나 일련번호 등을 부여하여 식별하는 경우도 흔하다. 이 경우라 하더라도 일련번호 등을 부여하는 기준이 뭔지 반드시 식별해야 한다.
• 인조 식별자는 결제 번호처럼 결제를 상실할 때 본질 식별자인 사원번호 등을 대신하여 인위적으로 부여한 일련번호 형식의 식별자를 말한다.
• 본질 식별자를 주 식별자로 하는 경우 주민등록번호보다는 사원번호처럼 엔티티를 대표하거나 변하지 않는 혹은 식별자 특성에 더 적합한 속성을 우선하는 것이 좋다. 사원번호가 주식별자가 되는 경우 주민등록번호는 자연스럽게 대체 식별자가 된다.
• 인조 식별자를 주 식별자로 사용하면서 본질 식별자를 식별하지 않은 경우를 종종 볼 수 있다.
  결제에 상실할 때 상신자가 상신했을 때 본질 식별자는 데이터를 발생하는 규칙을 제공하며 유일하게 데이터를 식별할 수 있는 기준을 제공한다.
• 본질 식별자를 정확하게 정의하지 않았다면 핵심적인 정의가 누락되었다고 볼 수 있으며, 개발자가 데이터 집합을 자의적으로 해석하여 중복 데이터를 발생시킬 수 있는 여지를 주게 된다.
• 결제번호처럼 인조 식별자를 주 식별자로 정의한 경우 문제 식별자인 상신자, 사원번호, 플러스 결제 일시를 대체 식별자로 지정할 수 있다.
• 본질 식별자 또는 인조 식별자가 주식별자 역할이라든지 대체 식별자 역할이라든지 데이터 발생 규칙을 정의하고 실체의 무결성, 제약 조건을 설계해야 한다.
• 논리 데이터 모델은 업무 변경에 유연하게 대응할 수 있어야 하고 확장성을 가져야 한다.
• 향후 식별자를 변경하게 된다면 해당 엔티티와 관계를 갖는 다른 엔티티도 영향을 받게 된다.
• 본질 식별자를 사용하는 것보다 인조 식별자를 사용한다면 식별자를 변경할 가능성이 낮아지고 이로 인한 설계 변경을 최소화할 수 있다.
• 이처럼 본질 식별자 대신 인조 식별자를 사용하여 유연하고 확장 가능한 논리 모델을 설계할 수 있는 경우가 있다.
• 업무적으로 중요성은 덜하지만 본질 식별자에 (발주 번호 + 입찰 마감일자) 대신 인조 식별자인 입찰 번호를 부여하여 관리할 수도 있다.
• 하위 엔티티에 대한 하위 엔티티가 존재할 때 식별자를 계속 상속받게 되므로 하위 엔티티로 내려갈수록 식별자 속성 개수가 많아지게 되며 모델이 복잡해진다.
• 데이터 모델을 단순화하고 물리 모델로 변환했을 때 개발 편의성 및 성능적인 이점을 제공하기 위해 인조 식별자를 추가하여 주 식별자로 사용한다.
• 또 개인정보 암호화 대상에 해당하여 본질 식별자를 주식별자로 사용하지 못하는 경우도 있고, 본질 식별자에 대한 데이터가 들어오지 않은 상태에서 업무 처리를 위해 인조 식별자를 추가하는 경우도 있다.
• 도메인을 지정하거나 데이터 타입을 지정할 때 가장 중요한 원칙은 속성이 관리할 때 데이터에 맞는 데이터 타입을 지정하는 것이다.

 

 

데이터 타입

• 데이터 유형을 고려하여 문자형, 숫자, 날짜형 데이터 타입을 지정해야 한다. 식별자 속성은 좀 애매하다. 업무적으로 부어 코드, 연도, 일련번호와 같은 식별 체제 체계를 갖는다면 문자형을 지정해야 하고, 의미없이 시스템에서 순차적으로 부여한다면 숫자형으로 지정한다.
• 자식 엔티티에서 식별자로 상속받으려면 무조건 not null로 지정되고, 비식별자, 즉 일반 속성으로 상속받으면 옵셔널리티 지정에 따라 not null 여부가 결정된다.