[논리모델링연습] DA 공모대회 2018년 학생부 개인 답안

  DBA, 데이터엔지니어 업무를 수행하다보니 이 문제를 처음 봤을 때에 낯익은 로직이라 기뻤었다. 굉장히 과거형으로 얘기하였는데 사실 지금 이 글을 쓰는 시점에서 풀었던 해당 문제는 이미 3번째 풀어보는 것이였다. 1, 2번째는 4월 DAP 시험을 응시하면서 풀어봤다.

  여하튼 문제를 풀면서 관건은 아래와 같았다고 생각한다.

• 중요한 엔터티와 중요하지 않은 엔터티를 구분
• 중요하지 않은 엔터티는 최대한 통합하여 재귀관계나 별도 엔터티로 빼서 관리
• 재귀관계가 항상 정답은 아님을 유념할 것
• 엔터티가 너무 복잡해질 경우 복제 엔터티를 과감하게 사용할 것
• NOT NULL 속성의 경우 또한 디테일이므로 신경 써서 선정할 것
• 도메인 단어는 신중하게 선정해야 나중에 표준 도메인 정의서 작성 시 간결하게 적을 수 있음
• 엔터티명이 명확해야 엔터티정의가 명확해지고 다른 엔터티와 충돌이 덜 발생함
• 실체 엔터티인지 아닌지를 구분하는 것이 가장 중요함

논리 ERD

ERD 해설

• 사용자의 경우 통합코드 엔터티처럼 어디든 연결될 수 있어 관계를 직접 맺지 않고 복제 엔터티 적극 사용함
• 정보시스템, DB, 스키마, 서버의 경우 중요하지 않으므로 최대한 통합해서 재귀관계로 사용함. 분산환경구성도 고려해서 BOM 구조로 해볼까 했는데 해당되지 않는 서브타입도 있고 관계가 너무 복잡해질 것 같아 분리함
• 테이블 엔터티에는 현행, 목표만 관리함
• 컬럼 엔터티를 정의하는게 좀 긴가민가 했는데 컬럼한글명을 컬럼 엔터티에서 관리하면 동음이의어(하나의 영문명에 여러 한글명을 정의)를 관리할 수 없게 됨. 실제 로직에서는 동음이의어도 있을 수 밖에 없다고 생각하여 컬럼한글명은 테이블컬럼구성 엔터티로 뺐음
• 테이블매핑이나 컬럼매핑구성은 현행이 아닌 목표를 기준으로 적용하였음. 하나의 목표에 여러 현행이 있을 수 있지만 하나의 현행에 여러 목표가 대응되는 경우는 거의 없을 것이라 생각하였음
• 통합코드의 경우 그룹코드와 코드가 상하관계이므로 재귀관계로 해볼까 했는데 코드 엔터티에서 자식 엔터티가 많이 생성되는 것 같아 별도 코드그룹 엔터티로 빼서 관리하였음
• JOB의 경우 기준 정보를 관리하는 기준 엔터티로 관리함
• 이행검증 엔터티를 JOB실행결과 엔터티와 관계 맺어줄까 했는데 어차피 스크립트 엔터티에서 이행, 검증이 구분되므로 부모 엔터티와 관계 맺어주는게 덜 복잡할 것 같아 상위 관계에서 풀어주었음
• 연관 테이블의 경우 인조식별자는 최대한 지양하여 관계를 명확하게 보여주고자 본질식별자를 표기하고자 노력함
• 부모-자식 테이블의 경우에도 인조식별자는 최대한 지양함

총평

  하나의 테이블을 관리한다고 하더라도 다차원적으로 접근하는 것이 조금 어려웠다. 현행,목표를 구분해야 하고 선행, 후행을 구분해야 했다. 이런 부분들을 초기에 제대로 잡지 못하면 야근요소라 생각하니 더 열심히 고민했던 것 같다. 문제 자체가 익숙한 로직이라 전반적으로 크게 부담은 없었다.

 

참고

• DA 공모대회 2018 학생부 문제는 시중에서 쉽게 구할 수 있음
• 엔터티 정의서, 표준화 정의서 또한 어렵지도 않고 시중에서 쉽게 구할 수 있어 제외함