제7절 데이터 활용 관리

1. 정의 및 관리 목적

데이터 활용 관리란 데이터의 활용 여부를 점검하거나 활용도를 높이기 위해 측정 대상 데이터와 품질 지표를 선정하여 품질을 측정하고 분석하여 품질을 충족시키지 못하는 경우, 원인을 분석하여 담당자로 하여금 조치하도록 하는 작업을 말한다. 애플리케이션에서 활용되지 않는 데이터를 점검하 여 데이터베이스의 사용 환경을 개선하고 업무적 중요도가 높은 데이터에 대한 품질의 평가와 개선 으로 데이터의 활용도를 높인다. 데이터 활용 관리를 통해 데이터의 정확성을 저하시키는 원인을 분 석하고 개선함으로써 지속적인 데이터의 품질을 높이고 활용성을 높일 수 있다.

품질 저하를 개선하기 위해서는 조직 간의 원활한 협조 체계와 지속적인 활동이 필요하다. 미활용 테이블/칼럼에 대해 정리를 할 경우, 관련 항목을 사용하는 다른 애플리케이션이 있는지를 철저히 검토해야 한다. 데이터 품질 평가는 한 번의 수행을 통해 이루어지는 것이 아니라 반복적이고 지속적 으로 진행되었을 때 고품질의 데이터를 유지할 수 있다.

2. 세부 관리 대상

가. 핵심 데이터

핵심 데이터는 회사의 고객, 프로세스, 시장 환경, 재무 정보 등에 직접적으로 영향을 미치는 중요성이 높은 데이터를 말하며, 다음과 같은 기준에 따라 관리되어야 한다.

완전성

데이터의 모든 값은 의미 있게 채워져 있어야 한다.

일관성

데이터의 값은 동일하게 관리되어야 한다.

최신성

데이터의 값은 실제 세계의 객체들이 가지고 있는 값과 같아야 한다.

유효성

데이터의 값은 업무 규칙을 준수해야 한다.

유일성

데이터의 값은 동일 테이블에서 중복 관리되어서는 안 된다.

명확성

데이터의 의미가 혼동되지 않도록 분명하게 관리되어야 한다.

핵심 데이터는 업무 프로세스상의 중요성, 재무적 관점에서 관리의 필요성, 최종적인 사용자의 활용성 등을 기준으로 도출해 해당 테이블의 칼럼 수준으로 관리한다.

나. 측정 방법

데이터의 업무적인 규칙 및 물리적 특성(도메인, 유효성 등)을 반영한 데이터 품질 측정 기준을 말한다. 업무적인 규칙과 물리적인 특성이 정확하게 반영되도록 하며, 핵심 데이터별로 측정 방법을 관 리한다.

3. 데이터 활용 관리 프로세스

가. 데이터 활용 관리 프로세스

[그림 6-3-25] 데이터 활용 관리 프로세스
DQ7.1.1 핵심 데이터 수집

[그림 6-3-25]의 DQ7.1.1 핵심 데이터 수집은 개선 대상이 되는 데이터를 선정 기준에 따라 선정 하고, 업무부하 및 시스템 부하를 고려하여 측정 데이터 량을 조정한다.

DQ7.1.2 데이터 활용도 측정 기준 수립

[그림 6-3-25]의 DQ7.1.2 데이터 활용도 측정 기준 수립은 데이터별 활용도 측정 기준을 정량적으 로 마련하고 데이터 활용 개선 목표치를 설정하여 향후 개선 작업에 대한 평가 작업 수행 시 활용한다.

[그림 6-3-26] 데이터 활용도 측정 결과서 예
DQ7.1.3 데이터 활용 측정

[그림 6-3-25]의 DQ7.1.3 데이터 활용 측정은 데이터 활용도 측정 기준에 따른 활용도 평가 작업을 수행하고, 데이터 활용도 측정 결과서를 작성한다. [그림 6-3-26]과 같은 형식으로 작성할 수 있다.

DQ7.1.4 활용 저하 요인 분석

[그림 6-3-25]의 DQ7.1.4 활용 저하 요인 분석은 데이터 활용의 저하를 유발한 비즈니스적, IT 적 원인을 데이터의 생성, 갱신, 변환, 활용 관점에서 도출하고, 데이터 활용 저하 원인 분석서를 작성한다. [그림 6-3-27]과 같은 형식으로 작성할 수 있다.

[그림 6-3-27] 데이터 활용 저하 원인 분석서 예
DQ7.2.1 개선 방안 마련

[그림 6-3-25]의 DQ7.2.1 개선 방안 마련은 활용 저하 원인별로 개선 방안을 마련한다. 개선 방 안은 주로 프로세스 개선, 표준화, 클린징의 범주로 분류될 수 있다.

DQ7.2.2 개선 활동 수행

[그림 6-3-25]의 DQ7.2.2 개선 활동 수행은 승인된 개선 방안과 원인별로 도출된 개선 방안의 활동 계획에 따라서 개선 활동을 추진한다.

DQ7.2.3 개선 활동 평가

[그림 6-3-25]의 DQ7.2.3 개선 활동 평가는 개선 활동을 평가하는 과정으로, 측정 목표치를 초 과한 데이터에 대해서는 개선 항목에서 제외시키거나 목표치를 조정한다. 종합적인 수행 결과를 정리하여 향후 활동에 활용할 수 있도록 한다.

장 요약

제1절 데이터 관리 정책
- 데이터 관리 정책은 기업의 비전과 목표 달성에 필요한 데이터의 확보 계획과 확보된 데이터에 대한 효과적인 운영 관리 체계 및 계획을 정의하는 작업이다.
제2절 데이터 표준 관리
- 데이터 표준 관리는 데이터 표준화 원칙에 따라 정의된 표준 단어 사전 및 도메인 사전, 표준 용어사전, 표준 코드, 데이터 관련 요소 표준 등을 기관에 적합한 형태로 정의하고 관리하는 작업이다.
제3절 요구 사항 관리
- 요구 사항 관리는 데이터를 비롯하여 관련 애플리케이션 및 시스템 전반에 걸친 사용자의 요구를수집하고 분류하여 반영하는 작업 절차이다.
제4절 데이터 모델 관리
- 데이터 모델 관리는 데이터 요구 사항 관리에 의해 변경되는 데이터 구조를 모델에 반영하는 작업절차와 데이터베이스 시스템 구조와 동일하게 데이터 모델을 유지하도록 하는 작업 절차이다.
제5절 데이터 흐름 관리
- 데이터 흐름 관리는 소스 데이터(문서, Text, DB 등)를 수기로 생성하거나 추출, 변환, 적재를 통해 생성하여 타깃 데이터베이스에 저장·가공하는 것을 관리하는 절차이다.
제6절 데이터베이스 관리
- 데이터베이스 관리는 원활한 데이터 서비스를 위해 필요한 데이터베이스를 안정적으로 운영, 관리하는 데 필요한 작업을 체계화하는 것으로 백업, 보안, 튜닝, 모니터링 등의 작업이 포함된다.
제7절 데이터 활용 관리
- 데이터 활용 관리는 데이터의 활용 여부를 점검하거나 활용도를 높이기 위해 측정 대상 데이터와품질 지표를 선정하여 품질을 측정·분석하여 품질을 충족시키지 못하는 경우에 원인을 분석하여담당자로 하여금 조치하도록 하는 작업이다.

연습문제

문제 1. 다음 설명과 가장 관계가 먼 것은?

데이터를 비롯하여 관련 애플리케이션 및 시스템 전반에 걸친 사용자의 요구를 수집하고 분류하여 반영하는 작업 절차
사용자의 정보 요구 사항을 종합적으로 검토, 확인함으로써 요건에 맞게 시스템을 개선, 반영하여 사용자의 만족도를 높이고 고품질의 서비스를 가능하게 함
- ① 외부 인터페이스 요건
- ② 기능 개선 요건
- ③ 보안 개선 요건
- ④ 품질 개선 요건
  
  요구 사항 관리에서는 외부 인터페이스 요건, 기능 개선 요건, 성능 개선 요건, 보안 개선 요건 등을 다룬다.

문제 2. 데이터 흐름 프로세스는 원천 데이터(문서, Text, DB 등)를 수기로 생성하거나 추출, 변환, 적재, 가공 등을 통해 목표 데이터베이스에 저장하는 데이터 생명주기를 통제 및 관리하는 작업이다. 여기에는 정기 및 비정기적인 배치 작업 및 정형 · 비정형 데이터의 배치 작업을 포함한다. 다음 중 데이터 흐름을 개선하기 위해 상세 업무 흐름을 정의한 것으로 가장 부적절한 것은?

① 데이터 흐름 점검 기준 도출 : 데이터 오류의 최소화를 위해서 지속적인 품질 점검을 실시하여 관리되어야 할 기준을 도출하는 과정이다.
② 데이터 흐름 점검 지표 생성 : 사용자가 설정한 품질 지표별로 데이터 이동에 대한 규칙들의 구체적인 기준들을 생성하여 관리한다.
③ 데이터 정합성 체크 : 데이터 흐름 점검 지표에 따른 구체적인 제크 모듈들을 실행하여 성합성을 체크한다.
④ 흐름 오류 데이터 분석 : 데이터 정합성 검증을 통하여 추출된 오류 데이터에 대한 분석을 수행하고, 오류의 원인 분석 결과에 따라 데이터 관리의 각 요소에 적절한 조치를 수행한다.

문제 3. 데이터의 정확성을 저하시키는 원인을 분석하고 개선함으로써 지속적으로 데이터의 품질을 높일 수 있게 하기 위해 가장 관련이 있는 것은?

① 요구 사항 관리
② 데이터 흐름 관리
③ 데이터 표준 관리
④ 데이터 활용 관리

문제 4. A 기업은 최근에 새로운 데이터베이스를 도입하여 신규 정보 시스템을 구축한 바 있다. 이와 같은 경우에 데이터아키텍처(DA, Data Architecture) 담당자는 원활한 데이터 서비스를 위해 필요한 데이터베이스를 안정적으로 운영·관리하는 데 필요한 작업이 어떤 것들이 있는지 체크할 필요성이 있다. 다음 중 이때 수행되는 작업의 순서로 적합한 것은?

① 데이터베이스 생성 → 백업 주기 및 스케줄 정의 → 데이터베이스 백업 수행 → 데이터 보안 대상 선정
② 데이터베이스 생성 → 데이터 보안 대상 선정 → 백업 주기 및 스케줄 정의 → 데이터베이스 백업 수행
③ 백업 주기 및 스케줄 정의 → 데이터베이스 생성 → 데이터베이스 백업 수행 → 데이터 보안 대상 선정
④ 백업 주기 및 스케줄 정의 → 데이터 보안 대상 선정→데이터베이스 생성 → 데이터베이스 백업 수행

데이터베이스 관리 프로세스는 데이터베이스 생성, 백업 주기 및 스케줄 정의, 데이터베이스 백업 수행, 데이터 보안 대상 선정, 데이터 보안 적용, 데이터 보안 교육 수행, 데이터베이스 성능 개선, 데이터베이스 보안 개선, 데이터베이스 복구, 테스트 데이터베이스 변경, 데이터베이스 이관 등으로 구성된다.

문제 5. 다음 설명과 가장 관련 있는 것은?

기관의 비즈니스 목적에 맞는 최적화된 데이터 서비스를 제공하기 위한 데이터베이스를 구성하고 유지하기 위해 필요한 개념 데이터 모델 및 논리 데이터 모델, 물리 데이터 모델, 데이터 참조 모델 등의 설계서를 체계적으로 관리
- ① 데이터 표준 관리
- ② 데이터 활용 관리
- ③ 데이터 모델 관리
- ④ 데이터베이스 관리
  
  데이터 모델 관리란 데이터 요구사항 관리에 의해 변경되는 데이터 구조를 모델에 반영하는 작업 절차와 데이터베이스 시스템 구조와 동일하게 데이터 모델을 유지하도록 하는 작업 절차를 말한다.

문제 6. 데이터의 효과적인 확보, 유지 관리를 위해 수립된 규정이나 계획, 지침 등에 포함된 데이터 관리 방향이 의미하는 것은?

① 데이터 관리 원칙
② 데이터 활용 원칙
③ 데이터 관리 정책
④ 데이터 표준 관리

데이터의 효과적인 확보, 유지 관리를 위해 수립된 규정이나 계획, 지침 등에 포함된 데이터 관리 방향이 의미하는 것은 데이터 관리 원칙이다. 데이터 관리 정책은 데이터 관리 원칙, 데이터 관리 조직, 데이터 관리 프로세스를 포함하는 개념이다.

문제 7. 다음 설명에서 데이터 관리 조직에 대한 관리 기준에 따라 보완이 필요한 것으로 판단할 수 있는 것은 무엇인가? 매년 초에 데이터 관리 상태를 점검하기 위한 정기적인 점검 계획을 수립한다.

① 준수성
② 완전성
③ 명확성
④ 운영성

데이터 관리 조직 정의시 이에 대한 관리 기준 중 명확성은 데이터 관리르 ㄹ담당할 관리자가 선정되어 있고, 담당자별로 수행해야 할 역할이 명확하게 정의되어 있어야 함을 의미한다. 문제에 명시한 설명은 누가 수행해야 하는지에 대해 명확하게 지정하고 있지 않기 때문에 명확성 측면에서 보완이 필요하다.

문제 8. 다음 중 데이터 관리 프로세스를 수립하는 기준으로 고려하기에 적합하지 않은 것은?

① 데이터 관리 프로세스는 데이터 관리 원칙에 맞게 정의되어야 한다.
② 각 조직의 기존 프로세스에 대한 특성을 고려하여 정의해야 한다.
③ 데이터와 관련된 모든 요소가 빠짐없이 관리될 수 있도록 정의되어야 한다.
④ 기존의 다른 프로세스와의 상호 연관관계를 고려하는데 있어서 변화 관리 프로세스는 제외된다.

데이터 관리 프로세스는 변화 관리, 프로젝트 관리 등 기존의 다른 프로세스와 상호 연관관계가 명확하게 정의되어 적용함에 문제가 없어야 한다.

문제 9. 데이터 표준 관리 프로세스를 정의하는데 있어서 연관관계를 고려해야 할 프로세스로 보기에 가장 연관성이 적은 것은?

① 데이터 흐름 정의
② 데이터베이스 정의
③ 데이터 모델 정의
④ 데이터 관리 정책 수립

문제 10. 데이터의 활용 여부를 점검하고 활용도를 높이기 위해 필요한 데이터 활용 관리 프로세스를 수립하는데 있어서 고려할 사항으로 가장 거리가 먼 것은?

① 회사의 고객, 프로세스, 시장 환경, 재무 정보 등에 직접적으로 영향을 미치는 중요성이 높은 핵심 데이터를도출하고 해당 테이블의 칼럼 수준으로 관리한다.
② 데이터의 모든 값은 의미 있게 채워져 있어야 한다.
③ 관련된 동일 항목의 데이터는 동일한 값으로 관리되어야 한다.
④ 저장된 데이터의 값은 업무 규칙 수립에 중요한 기준이 된다.

연습문제 실기

아래 내용의 요건을 충족하는 최적의 데이터 표준화 정의서 및 논리 데이터 모델을 제시하시오. (단, 표준화 정의서는 기본원칙, 표준 용어, 표준 코드, 표준 도메인으로 정의되어야 하고, 논리 데이터 모델에는 엔터티, 속성, 관계(명), 식별자 등이 명시되어야 하며, 표기법은 “논리 데이터 모델 표기법 예시” 중에 택일할 수 있다.)
우리 회사는 정부가 추진하는 산업기술진흥을 위해 다양한 사업을 수행하고 있다. 우리가 수행하는 사업은 장·단기 여부, 사업비 규모, 산학협력 여부 등에 따라서 여러 가지로 나누어지는데, 각 사업별로 참여 희망 기업으로부터 해당 기업이 수행하고자 하는 과제에 대해 과제수행계획과 사업비편성내역 등을 접수 받아 과제의 성공 가능성이 보이는 기업을 선정하고 정부로부터 위탁 받은 기금을 지원하고 관리하는 일이 주된 업무이다.
이를 위해 다양하고 복잡한 사업에 대해 개별적인 관리시스템을 만들어 운영해 왔으나 전체 사업에 대해 일관성 있게 체계적인 관리를 하고, 전체 사업을 대상으로 정부기금을 유연하게 운영하여 보다 많은 기업에 헤택이 돌아가도록 하며, 사업에 응모하는 기업들에 대해서도 중복지원이나 부적격업체 지원을 방지할 수 있도록 체계적인 통합시스템으로 개편하고자 한다.
우리가 하는 사업은 3년 이상의 중·장기 사업과 1년 이내의 단기 사업으로 나눌 수 있는데, 중·장기 사업의 경우는 여러 기관이 하나의 총괄과제에 대해 여러 개의 세부과제를 구성하여 수행하는 형태로 구성된다.
우리는 사업별로 예산이 확정되면 사업공고를 통해 과제를 신청 받게 되는데, 사업공고는 사업번호, 사업명, 공고일자, 접수기간, 사업예산금액 등의 내용을 포함하여 상세한 사업별 운영지침을 다양한 매체를 통해 공지하게 되며, 이러한 기본적인 공지내용과 공지매체 등에 대한 사항은 시스템에 등록하여 우리 회사의 홈페이지에서 볼 수 있게 하는 한편 신청되는 과제들에 대한 근거로 관리해야 한다.
사업공고가 나가면 공고된 내용에 따라 많은 기관들이 과제신청을 하게 되는데, 우리는 과제신청이 효율적으로 이루어질 수 있도록 온라인으로 과제를 접수한다.
총괄·세부과제와 단기과제에 참여하는 기관은 국공립연구소나 정부출연연구소, 정부투자연구기관, 민간기업 및 민간연구소 등일 수 있으며, 단기과제의 경우는 이들 기관이 대학교와 산학협력의 형태로 하나의 개별과제를 공동 수행할 수도 있다.
중·장기 사업의 경우 총괄과제를 수행하고자 하는 기관은 총괄과제를 세분화한 세부과제를 구성하여 각 세부과제를 수행할 기관을 모집하고, 이렇게 구성된 총괄·세부과제에 대하여 총괄과제 수행기관은 해당 기관들을 대표하여 과제 신청을 하게 된다.
과제 신청시 신청기관, 신청일자, 수행하고자 하는 공지과제, 과제수행기간, 주관기관, 참여기관, 위탁기관, 총괄책임자, 과제책임자, 참여연구원 등의 내용이 입력되어야 하며, 중·장기 사업에 대한 과제수행기간은 총 수행기간과 총괄·세부과제별 수행기간으로 구분해야 한다. 하나의 총괄과제에 대한 세부과제들은 총괄과제와 수행기간이 같을 수도 있고, 다를 수도 있다. 그러나 총괄과제의 총 수행기간을 벗어나진 않는다.
주관기관은 해당 과제를 주도적으로 수행하고자 신청하는 기관이 되고, 감여기필은 수행기관과 해당 과제를 공동으로 수행 할 기관을 의미하고, 위탁기관은 과제 내용 중 일부를 위탁하여 수행하게 되는 경우 그 해당 기관이 된다. 참여기관이나 위탁기관은 과제별로 지정하며, 없을 수도 있고, 복수 기관일 수도 있다.
신청하는 과제에는 과제책임자와 참여연구원이 반드시 지정되어야 하며, 총괄·세부과제의 경우에는 총괄책임자를 추가로 지정한다. 총괄책임자는 총괄과제의 과제책임자가 겸임하거나 총괄과제의 주관기관에 속한 별도의 개인일 수 있다.
과제 등록은 과제에 대한 기본사항 외에 과제수행계획과 사업비편성내역, 과제책임자 및 참여연구원의 인적사항과 과제참여율 등이 추가로 입력되어야 하며, 과제수행계획과 사업비편성내역은 미리 정해진 항목과 사업비목에 따라 내용을 기입하게 된다. 과제별 사업비 중액에 대해서는 일정 비율을 정부부담금으로 하고, 나머지는 신청기관의 부담으로 하며, 사업비는 현금과 현물로 구분하여 편성하고, 사업비목별로는 현금, 현물 구분만 하고 분담내역에 대한 구분은 하지 않는다. 과제등록이 완료되면 과제번호, 가 부여된다. 세부과제의 경우는 해당 총괄과제에 대한 과제번호를 입력해야 한다. perti Type
과제를 신청하기 위해서는 신청 과제에 관련된 모든 주관기관, 참여기관, 위탁기관이 우리 시스템에 등록되어 있어야 한다. 또한 주관기관의 대표자와 과제책임자의 인적사항을 비롯하여 참여연구원의 인적사항도 등록해야 한다. 과제 신청에 관련된 기관 중 민간기업의 경우 이노비즈, 벤처인중 등을 보유한 중소기업에 대해서는 가점을 부여하기도 한다.
과제에 관련된 모든 기관에 대해서는 사업자번호, 기관명(한글, 영문), 설립일, 연락처 및 소재지 사항, 대표자 등의 기본정보가 등록되어야 한다. 또한 기관 대표자나 과제책임자, 참여연구원 등에 대해서는 < 주민등록번호, 이름, 거주지 사항(주소, 연락처 등), 근무지 사항(소속기관, 근무지주소, 연락처 등) 등과 같은 기본인적사항 외에도 다른 정부출연과제에 참여한 실적, 최종학력사항, 연구논문 및 저서 등에 대한 추가사항이 필요하다.
등록된 기관들에 대한 관리 목적상 사업장 소재지를 기준으로 우편번호 외에 우리가 임의로 분류한 지역구분을 지정하는 것도 중요한 사항이다.
우리는 신청된 과제들에 대해 그 내용의 타당성, 성공 가능성, 사업비편성의 적절성 등을 평가하여 지원대상 과제들을 선정하고 사업비를 지원하게 되는데, 총괄·세부과제의 경우에는 총괄과제에 대한 주관기관에 총 사업비를 지원한다. 선정된 총괄과제의 주관기관은 해당 세부과제 수행기관들에 대해 개별협약 내용에 따라 사업비를 배분하고 전체 세부과제들의 진행을 관리하면서 총괄과제를 수행하게 된다.
선정된 과제에 대해 사업비를 지원하기 위해서는 해당 주관기관과 협약을 맺게 되는데, 중·장기 사업의 경우는 하나의 총괄과제를 중심으로 여러 개의 세부과제가 동시에 진행되는 형태이기 때문에 사업비 지원 규모도 크고, 관리도 매우 복잡하다. 관리상의 복잡성을 줄이기 위해 우리는 총괄과제의 주관기관과 총괄협약만 관리하고, 총괄과제에 대한 각 세부과제 수행기관과 총괄과제 주관기관 간의 개별협약은 관리하지 않는다. 그러나 개별협약의 내용만 관리하지 않을 뿐이고, 과제의 구성과 진행에 대한 이력은 매우 중요하게 관리해야 한다. 총괄과제에 대한 세부과제는 그 수행 기관이 변경될 수도 있고, 세부과제간에 사업비 조정도 가능하다. 그러나 세부과제 구성을 변경할 수는 없다.

표준화 정의서 정답

데이터 표준화 기본원칙

구성 요소	표준화 기본원칙 내용
공통 원칙	관용화된 용어를 우선하여 사용한다.
공통 원칙	영문명(물리명) 전환시, 발음식은 지양한다.
공통 원칙	일반적인 명명규칙 시 띄어쓰기는 하지 않는다.
공통 원칙	한글명에 대해서는 복수의 영문명을 허용하지 않는다.(동음이의어 불가)
공통 원칙	영문명에 대해서는 복수의 한글명을 허용한다.(이음동의어 허용)
표준 용어	1. ‘~ 일자’, ‘~ 일’ 등 날짜를 의미하는 용어는 ‘~일자’로 통일하여 사용한다.
표준 용어	2. 적용일자, 유효일자 등의 내용은 유효일자로 통일하여 사용한다.
표준 용어	3. 용어는 띄어쓰기를 허용하지 않는다.
표준 용어	4. 용어의 길이는 한글의 경우 12자 이내, 영문의 경우 24자 이내로 제한한다.
표준 용어	5. 단독 인조식별자로서의 일련번호, ID,SEQ는 ID로 통일한다.
표준 용어	6. 영문약어의 경우 5자 이내로 제한한다.
표준 용어	7. 필요시 단어와 단어의 구분은 (언더바) 로 한다.
표준 코드	1. 코드성 속성은 맨 뒤에 ‘코드’를 붙인다. 예) 상태코드, 결과코드
표준 코드	2. 코드는 알파벳과 문자열을 조합하여 일정한 길이로 구성한다.
표준 코드	3. 코드 속성에는 기본적으로 3자리 문자열인 코드 도메인을 지정한다.
표준 코드	4. 코드는 전체 모델 내에서 유일하게 정의한다.
표준 도메인	1. 표준 도메인은 기본적으로 Number, String, Datetime으로 정의한다.
표준 도메인	2. 원화금액 도메인은 (18,0)로 정의한다.
표준 도메인	3. 외화금액 도메인은 (18,2)로 정의한다.
표준 도메인	4. 상세 도메인의 구별이 필요한 경우는 별도의 원칙으로 정의한다.

표준용어

표준 용어	설명
과제	정부출연금 및 기관분담금으로 필요한 경비를 마련하여 일정한 기간과 계획에 따라 결과를 만들어내는 활동
개별과제	단기과제의 경우에 한하여 참여하는 대학이나 산학연이 공동으로 수행할 수 있는 과제 단위를 말함.
개인	과제를 신청하는 단위로 순수 개인을 말함.
과제수행 계획	과제를 수행고자 하는 참여기관 또는 단체에서 작성하는 과제 수행계획서를 말함.
과제참여율	여러 기관이 하나의 과제에 복수 참여할 경우 각 과제별 해당 기관의 과제 참여율을 말함.
과제책임자	참여 및 위탁기관에서 과제를 책임지고 수행하게 될 수행 책임자를 말함.
단기과제	1년 이내의 수행기간을 갖는 과제를 단기과제라고 말함.
부적격업체	사업에 응모하는 기업들의 부적격 지원 방지를 위해 관리하고자 함.
사업	하나의 사업은 여러 개의 과제를 담을 수 있는 관리단위를 말함.
사업공고	산업기술진흥을 위해 추진 하는 사업에 대한 홈페이지 등의 공고를 말함.
사업번호	산업기술진흥을 위해 추진 하는 사업을 관리하기 위하여 부여하는 관리번호를 말함.
사업비	사업에 필요한 예산을 말함.
사업비 편성내역	사업 추진 시 필요한 예산에 대한 항목별 편성내역을 말함.
세부과제 소재지	총괄과제의 경우 이를 구성하는 세부과제를 말하는 것으로 각 세부과제는 별도의 기관별로 수행할수 있음.
수행기간	사업에 필요한 수행 기간을 말함.
신청기관	사업을 신청한 신청 기관을 말함.
신청일자	사업을 신청한 신청일자를 말함.
우편번호	사업 신청 기관의 행정동 우편번호를 말함.
위탁기관	과제 중 일부를 별도의 기관에게 위탁하여 수행하고자 하는 경의 기관을 말함.
정부분담금	전체 사업비 총 액 중에서 정부가 분담하게 되는 일정 비율의 금액을 말함.
주관기관	사업 또는 과제를 주도적으로 수행하게 되는 기관을 말함.
지역구분	행정동 우편번호에 의한 분류가 아닌 본 사업의 발주자가 별도로 관리하고자 하는 지역구분 성격의 분류단위
총괄과제	중.장기 사업의 경우 총괄과제를 구성할 수 있으며 이는 별도의 세부과제를 구성할 수 있는 단위를 말함.

표준 코드

표준코드	코드 값	설명
상세경력정보구분	01	정부출연과제수행실적
상세경력정보구분	02	산업재산권
상세경력정보구분	03	연구 논문 및 저서
권리구분	01	특허
권리구분	02	실용신안
권리구분	03	프로그램저작권
권리구분	04	의장권
권리구분	05	상표권
저술구분	01	저서
저술구분	02	논문
계좌구분	01	사업비계좌
계좌구분	02	평가수당지급계좌
수행주체구분	11	기관 - 연구소 - 국공립연구소
수행주체구분	12	기관 - 연구소 - 정부출연연구소
수행주체구분	13	기관 - 연구소 - 정부투자연구기관
수행주체구분	14	기관 - 연구소 - 민간연구소
수행주체구분	15	기관 - 대학교
수행주체구분	16	기관 - 기업
수행주체구분	20	개인
수행주체구분	30	직원
참여역할코드	11	총괄책임자
참여역할코드	12	과제책임자
참여역할코드	13	참여연구원
참여역할코드	21	주관기관
참여역할코드	22	참여기관
참여역할코드	23	위탁기관
수행결과코드	01	성공
수행결과코드	02	실패
관계구분	01	대표자
관계구분	02	소속
연락처구분	11	기관대표전화번호
연락처구분	12	개인무선전화번호
연락처구분	13	개인근무지팩스번호
연락처구분	14	기관대표팩스번호
연락처구분	15	개인거주지전화번호
연락처구분	16	개인근무지전화번호
연락처구분	21	기관 대표 이메일
연락처구분	22	개인 이메일
연락처구분	31	기관소재지주소
연락처구분	32	개인거주지주소
연락처구분	33	개인근무지주소

표준 도메인

도메인 유형	도메인	도메인 값
번호	사업번호	VARCHAR(10)
번호	사업자등록번호	VARCHAR(10)
번호	법인등록번호	VARCHAR(11)
번호	주민등록번호	VARCHAR(13)
번호	접수번호	VARCHAR(5)
번호	과제번호	VARCHAR(3)
문자	ID	VARCHAR(10)
문자	명	VARCHAR(100)
문자	기준	VARCHAR(200)
문자	설명	VARCHAR(1000)
문자	적요	VARCHAR(100)
일자	년도	CHAR(4)
일자	년월	CHAR(6)
일자	일자	Date
일자	일시	Timestamp
금액	차수	NUMBER(5)
금액	비율	NUMBER(5,2)
금액	원화금액	NUMBER(18,0)
금액	외화금액	NUMBER(18,2)

표준화 정의서 해설

데이터 표준화를 정의한다는 것은 기업 내 서로 다른 사용자들에게 동일한 사실을 왜곡되지 않고 정확하게 전달하고 의사소통 하기 위한 표준을 수립하는 것이다. 이는 기업 내 현업 사용자 뿐만 아니라 정보시스템을 사용하거나 개발하는 모든 사용자 (사내 직원 및 프로젝트 개발을 위한 외주사 포함)를 대상으로 하고 있는 만큼 중요한 작업중의 하나이다. 데이터 표준화를 진행하기 위해서 가장 우선 실시해야 하는 일은 해당 기업의 비즈니스를 철저하게 분석하고 숙지해야 한다는 것이다. 실제 비즈니스를 이해해야 이음동의어, 동음이의어, 금칙어 등 표준화 시스템에서 작업해야 하는 일에 대한 정확성이 높아진다. 즉, 현업 사용자들이 어떤 용어를 어떤 의미로 사용하고 있는지 확인을 해야 하며, 사용하는 그 용어들은 전사적으로 보편 타당하게 사용하고 있는지 아니면 특정 부서나 특정 사용자들만 사용하고 있는지, 또 해당 시스템은 현업들이 사용하는 업무 용어와 일치하게 시스템이 개발되고 표준들이 만들어져 있고 유지보수 되는지 등등의 사항들을 점검한다.

표준화 정의 작업은 번거롭고 복잡하며 절차 또한 반복작업이 필요한 관계로 전체적으로 충분한 사례로 살펴보기에는 한계가 있기 때문에, 본 예제에서는 원칙 및 표준화 구성요소 (용어, 단어, 코드, 도메인)별 간단한 정의를 하는 것으로 대신하고자 한다.

첫번째, 데이터 표준화 기본원칙에 대한 작업이다.

표준화 기본원칙이라는 것은 세부 지침을 구성하는 대 원칙에 준하는 내용으로 구체적이거나 상세적으로 정의하지 않고 반드시 준수해야 할 기본사항에 대한 부분을 정의한다. 이는 각 구성요소별 세부 원칙이 있기 때문이다. 표준화 기본 원칙을 정의하는 경우, 현행 시스템에서 사용하고 있던 표준화 원칙 문서의 분석을 통한 개선사항들을 찾아서 정리하고, 아울러 시스템을 운영해오면서 필요했던 추가적인 보완사항 및 시정할 사항에 대한 내용을 전체적인 관점에서 누락 없이 정리하고 이를 포함하여 작성한다. 물론 지침 수순의 상세한 작성은 표준화 구성요소(용어, 단어, 코드, 도메인)별 별도의 문서를 작성한다.

[표 부록B-1] 데이터 표준화 기본원칙

구성 요소	표준화 기본원칙 내용
공통 원칙	관용화된 용어를 우선하여 사용한다.
공통 원칙	영문명 (물리명) 전환시, 발음식은 지양한다.
공통 원칙	일반적인 명명규칙 시 띄어쓰기는 하지 않는다.
공통 원칙	한글명에 대해서는 복수의 영문명을 허용하지 않는다. (동음이의어 불가)
공통 원칙	영문명에 대해서는 복수의 한글명을 허용한다. (이음동의어 허용)
표준 용어	1. ‘~일자’, ‘~일’ 등 날짜를 의미하는 용어는 ‘~일자’로 통일하여 사용한다.
표준 용어	2. 적용일자, 유효일자 등의 내용은 유효일자로 통일하여 사용한다.
표준 용어	3. 용어는 띄어쓰기를 허용하지 않는다.
표준 용어	4. 용어의 길이는 한글의 경우 12자 이내, 영문의 경우 24자 이내로 제한한다.
표준 용어	5. 단독 인조식별자로서의 일련번호 ID, SEQ는 ID로 통일한다.
표준 용어	6. 영문약어의 경우 5자 이내로 제한한다.
표준 용어	7. 필요시 단어와 단어의 구분은 (언더바) 로 한다.
표준 코드	1. 코드성 속성은 맨 뒤에 ‘코드’를 붙인다. 예) 상태코드, 결과코드
표준 코드	2. 코드는 알파벳과 문자열을 조합하여 일정한 길이로 구성한다.
표준 코드	3. 코드 속성에는 기본적으로 3자리 문자열인 코드 도메인을 지정한다.
표준 코드	4. 코드는 전체 모델 내에서 유일하게 정의한다.
표준 도메인	1. 표준 도메인은 기본적으로 Number, String, Datetime으로 정의한다.
표준 도메인	2. 원화금액 도메인은 (18,0)로 정의한다.
표준 도메인	3. 외화금액 도메인은 (18, 2)로 정의한다.
표준 도메인	4. 상세 도메인의 구별이 필요한 경우는 별도의 원칙으로 정의한다.

두번째, 표준 용어에 대한 작업이다.

표준 용어 작업은 서두에서 이야기 했듯이 기업의 비즈니스를 이해하는 가장 중요한 작업이다. 따라서, 해당 기업에서 사용하는 업무적 용어에 대한 뜻과 의미를 전사적으로 통일되고 정확하게 정리해야 한다. 이는 현업 및 정보시스템 사용자를 비롯한 외부 관련자들까지도 당사의 비즈니스를 정확하게 이해할 수 있는 효율적인 의사소통의 선결 도구 이다. 많은 업무적 용어들이 있을 수 있으나 본 예제에서는 중요한 용어의 성의로 마무리 한다.

[표 부록B-2] 표준 용어

표준 용어	설명
과제	정부출연금 및 기관분담금으로 필요한 경비를 마련하여 일정한 기간과 계획에 따라 결과를 만들어내는 활동
개별과제	단기과제의 경우에 한하여 참여하는 대학이나 산학연이 공동으로 수행할 수 있는 과제 단위를 말함.
개인	과제를 신청하는 단위로 순수 개인을 말함.
과제수행 계획	과제를 수행고자 하는 참여기관 또는 단체에서 작성하는 과제 수행계획서를 말함.
과제참여율	여러 기관이 하나의 과제에 복수 참여할 경우 각 과제별 해당 기관의 과제 참여율을 말함.
과제책임자	참여 및 위탁기관에서 과제를 책임지고 수행하게 될 수행 책임자를 말함.
단기과제	1년 이내의 수행기간을 갖는 과제를 단기과제라고 말함.
부적격업체	사업에 응모하는 기업들의 부적격 지원 방지를 위해 관리하고자 함.
사업	하나의 사업은 여러 개의 과제를 담을 수 있는 관리단위를 말함.
사업공고	산업기술진흥을 위해 추진 하는 사업에 대한 홈페이지 등의 공고를 말함.
사업번호	산업기술진흥을 위해 추진 하는 사업을 관리하기 위하여 부여하는 관리번호를 말함.
사업비	사업에 필요한 예산을 말함.
사업비편성내역	사업 추진 시 필요한 예산에 대한 항목별 핀성내역을 말함.
세부과제 소재지	총괄과제의 경우 이를 구성하는 세부과제를 말하는 것으로 각 세부과제는 별도의 기관별로 수행할 수 있음.
수행기간	사업에 필요한 수행 기간을 말함.
신청기관	사업을 신청한 신청 기관을 말함.
신청일자	사업을 신청한 신청일자를 말함.
우편번호	사업 신청 기관의 행정동 우편번호를 말함.
위탁기관	과제 중 일부를 별도의 기관에게 위탁하여 수행하고자 하는 경의 기관을 말함.
정부분담금	전체 사업비 총 액 중에서 정부가 분담하게 되는 일정 비율의 금액을 말함
주관기관	사업 또는 과제를 주도적으로 수행하게 되는 기관을 말함
지역구분	행정동 우편번호에 의한 분류가 아닌 본 사업의 발주자가 별도로 관리하고자 하는 지역구분 성격의 분류단위
총괄과제	중.장기 사업의 경우 총괄과제를 구성할 수 있으며 이는 별도의 세부과제를 구성할 수 있는 단위를 말함.

세번째, 표준 코드에 대한 작업이다.

표준 코드 정의는 수 많은 값에 대한 분류를 한다는 것과 이를 활용한 분석을 하는 것을 함께 염두에 두고 작업을 한다. 데이터 관리의 최종 목적은 다양한 데이터를 이용한 효율적인 분석작업의 결과로써 경영의 의사결성을 지원하는 것으로 이는 표준 코드로부터 시작한다. 본 예제 외에도 데이터를 분류하기 위한 표준 코드들이 있으나 추가적인 작업은 생략한다.

[표 부록B-3] 표준 코드

표준 코드	코드값	설명
상세경력정보구분	01	정부출연과제수행실적
상세경력정보구분	02	산업재산권
상세경력정보구분	03	연구 논문 및 저서
권리구분	01	특허
권리구분	02	실용신안
권리구분	03	프로그램저작권
권리구분	04	의장권
권리구분	05	상표권
저술구분	01	저서
저술구분저술구분	02	논문
계좌구분	01	사업비계좌
계좌구분	02	평가수당지급계좌
수행주체구분	11	기관 - 연구소-국공립연구소
수행주체구분	12	기관 - 연구소- 정부출연연구소
수행주체구분	13	기관 - 연구소- 정부투자연구기관
수행주체구분	14	기관 - 연구소-민간연구소
수행주체구분	15	기관 - 대학교
수행주체구분	16	기관 기업
수행주체구분	20	개인
수행주체구분	30	직원
참여역할코드	11	총괄책임자
참여역할코드	12	과제책임자
참여역할코드	13	참여연구원
참여역할코드	21	주관기관
참여역할코드	22	참여기관
참여역할코드	23	위탁기관
사업수행결과코드	01	성공
사업수행결과코드	02	실패
관계구분	01	대표자
관계구분	02	소속
연락처구분	11	기관대표전화번호
연락처구분	12	개인무선전화번호
연락처구분	13	개인근무지팩스번호
연락처구분	14	기관대표팩스번호
연락처구분	15	개인거주지전화번호
연락처구분	16	개인근무지전화번호
연락처구분	21	기관 대표 이메일
연락처구분	22	개인 이메일
연락처구분	31	기관소재지주소
연락처구분	32	개인거주지주소
연락처구분	33	개인근무지주소

네 번째, 마지막으로 표준 도메인에 대한 작업이다. 표준 용이, 표준 코드를 정의하였다면 이제는 각 표준 용어가 시스템에서 관리되기 위해 필요한 물리적 자릿수를 결정하기 위한 도메인 표준을 정의하고 모든 표준 용어에 정의된 도메인을 매핑 또는 연결함으로써 표준을 준수하고 유지보수를 용이하게 할 수 있다. 표준 도메인은 표준어의 물리적 성격을 대표하는 것이므로 불필요한 도메인을 많이 만들기 보다는 필요한 도메인만을 정의하고 활용하는 것으로 한다.

[표 부록B-4] 표준 도메인

도메인 유형	도메인	도메인 값
번호	사업번호	VARCHAR(10)
번호	사업자등록번호	VARCHAR(10)
번호	법인등록번호	VARCHAR(11)
번호	주민등록번호	VARCHAR(13)
번호	접수번호	VARCHAR(5)
번호	과제번호	VARCHAR(3)
문자	ID	VARCHAR(10)
문자	명	VARCHAR(100)
문자	기준	VARCHAR(200)
문자	설명	VARCHAR(1000)
문자	적요	VARCHAR(100)
일자	년도	CHAR(4)
일자	년월	CHAR(6)
일자	일자	Date
일자	일시	Timestamp
금액	차수	NUMBER(5)
금액	비율	NMBER(5,2)
금액	원화금액	NUMBER(18,0)
금액	외화금액	NUMBER(18,2)

표준화 작업은 해당 기업의 정보시스템 구축을 위해서만 필요한 것이기 보다는 현업사용자와 현업사용자, 현업 사용자와 정보시스템 사용자, 정보 사용자와 정보시스템 사용자간 다자 간의 의사소통의 중요한 도구로서 인식되어야 한다.

논리 데이터 모델 정답

논리 데이터 모델 해설

먼저 이 회사에서 구축하고자 하는 통합시스템의 업무 요건을 충분히 숙지하여야 한다. 이를 통해 해당 업무에서 요구하고 있는 데이터 집합(엔터티)의 후보를 도출하고 이를 정련시키는 일련의 작업을 수행해야 한다. 엔터티 후보의 식별을 위해서는 업무 요건 중에서 명사형으로 사용된 단어들에 대해 다음의 세가지 단계를 간략하게 검증함으로써 객관화가 가능하다.

후보 엔터티의 개념 정립을 명확히 한다.
‘우리가 관리하고자 하는 것인지를 따져 본다.
‘가로와 세로를 가진 면적(집합)’인지를 확인하는 것이다.

이러한 기준으로 엔터티 후보를 도출하여 보면 엔터티 후보로는 과제, 과제수행계획, 기관, 주관기관, 참여기관, 위탁기관, 대학교, 국공립연구소, 정부출연연구소, 정부투자연구기관, 민간기업, 민간연구소, 개인, 사업공고, 사업비편성내역, 지역(아마도 행정지역을 뜻하는 것이다.), 총괄책임자, 과제책임자, 참여연구원, 총괄과제, 세부과제 등을 추출할 수 있다.

이들 중에서 핵심(KEY) 즉, 데이터 구조의 골격에 해당하는 데이터 집합을 구분하여 보면 다음과 같다. 이 범주에 해당하는 데이터 집합들이 데이터 모델의 가장 상위에 존재하는 데이터 집합이라고 할 수 있다.

사업 공고 : 아마도 사업이라는 상위 엔터티(KEY Entity에 속한다.)가 존재할 수도 있겠지만 여기에서는 생략되었다고 보여진다.
과제(과제 신청) : 여기에서는 과제신청 보다는 과제라는 엔터티 명이 더 바람직하다. 왜냐하면 과제 신청이라는 행위자체를 관리하는 것 보다는 신청되어진 과제 자체를 관리하는 목적이기 때문이다. 이 엔터티는 현재의 업무내용에서는 핵심 엔터티라고 할 수 있다.
과제수행계획 : 업무요구사항을 보면 과제를 생성하기 위해서 과제수행계획을 제출하도록 요구 받고 있고 또한 이를 관리하여야 한다. 하지만 이것은 각 과제에 대한 수행계획이므로 핵심 엔터티라고 볼 수는 없다. 행위 엔터티에 속한다.
사업비편성내역 : 위의 과제수행계획과 비슷한 성격의 데이터 집합이라고 볼 수 있다. 즉, 각 과제당 정해진 항목과 비목 별로 각 사업비에 대한 내역을 제출하게 되어 있다. 이 부분 또한 행위 엔터티라고 볼 수 있다.
기관 : 이 부분에 대한 정의는 전체 데이터 구조의 완전성, 확장성을 담보하기 위해서는 신중한 접근이 필요한 부분이라고 할 수 있다. 과제를 수행하는 다양한 형태의 기관들과 해당 기관에 속해있는 사람들에 대한 정의를 어떤 모습으로 할 것인가가 중요하다. 과제 수행의 주체로서의 역할을 하는 매우 중요한 개체 집합이라고 할 수 있다. 따라서 이 데이터 집합은 핵심 엔터티이다.
주관기관, 참여기관, 위탁기관 : 이러한 형태의 엔터티 후보들은 특징적으로 보면 마치 무슨 기관을 관리하는 개체집합처럼 보이지만 실제로는 그렇지 않는 것이 보통이다. 즉, 위의 주관기관을 보면 ‘주관’이라는 행위(과제 참여에 있어서의 참여 형태가 ‘주관참여’라는 형태 임)와 위의 ‘기관’ 이라는 물리적인 개체와의 혼합된 형태임을 알 수 있다. 대개 이러한 형태의 후보들은 엔터티가 되기 보다는 각 엔터티사이의 관계(Relationship)일 가능성이 높다. 여기에서는 ‘기관’ 엔터티와 ‘과제’ 엔터티 사이의 관계이다. 마찬가지로 ‘참여기관’, ‘위탁기관’도 동일한 형태의 엔터티 후보라고 할 수 있다.
대학교 : 여기에서의 대학교는 큰 의미에서는 ‘기관’의 하나의 형태라고 볼 수 있다. 그래서 향후에 ‘기관’ 엔터티의 하나의 서브타입이 될 가능성이 높다.
국공립연구소, 정부출연연구소, 정부투자연구기관, 민간기업, 민간연구소 : ‘기관’과 같이 과제를 수행함에 있어서 여러 가지의 역할로 참여할 수 있는 과제참여 주체의 한 형태라고 볼 수 있다. 과제 참여 형태는 가까운 미래에는 더욱 확대될 가능성도 가지고 있다고 보여진다. 그렇기 때문에 이러한 형태의 행위의 주체들이 될 가능성이 있는 집합이 유연성을 가지고 있어야 한다. 데이터 모델링 단계에서 데이터 집합 차원의 이러한 판단들이 향후 업무의 유연성, 확장성에도 지대한 영향을 미치게 된다.
개인 : 과제에 참여하는 관련자를 지칭하는 단어이다. 참여의 구분을 과제 책임자, 참여 연구원, 총괄책임자 등으로 구별하여 해당 과제에 참여할 수 있다고 보고 있다. 여기에서 중요하게 생각해야 할 부분이 있다. 문제에서 정확하게 표현하고 있는 것처럼 과제에 참여하고 있는 개인의 역할 (책임자, 참여 연구자, 총괄책임자 등)을 관리하여야 하고 또한 개인이 특정기관, 기업체에 근무하는 근무이력 사항에 대한 데이터도 관리하고자 하고 있다. 과제에 참여하는 주체는 기관도 될 수 있고 개인도 될 수 있다. 또한 각 기관, 개인은 해당 과제에 특정 역할로 참여할 수 있다. 이러한 것들은 만족할 수 있는 데이터 구조가 필요하다.
지역 : 문제에서는 우편번호와 구분되어지는 지역을 관리할 필요가 있다고 명시하고 있다. 공식적으로 관리되고 있는 우편번호는 일반적인 주소를 관리하는 용도로 사용한다. 하지만 기관 소재지에 대해서는 우편번호와는 별개의 임의의 지역구분을 가지고 관리하고자 한다. 여기에서 지역구분은 몇 개의 우편번호를 임의로 그룹핑하여 사용하는 것으로 간주할 수 있겠다.

이 정도의 엔터티 후보들에 대해서 단어를 도출하고 개략적인 개념을 정리하였다. 이 것들에 대해서 엔터티를 우선순위 기준으로 분류하여 중요한 엔터티(핵심 엔터티)를 먼저 정의하고 이들간의 관계를 구분하여 아래와 같은 형태의 개념적인 데이터 모델을 완성하게 된다.

[그림 부록B-4] 개념 데이터 모델

[그림 부록B-4] 개념 모델을 살펴보면 해당 업무에서 사용되는 모든 데이터 집합이 도출되고 정의되어 있지는 않다. 개념단계에서는 해당 업무에서 사용되는 핵심 데이터 집합을 정의하고 그들간의 관계를 정의할 수 있다. 여기에서는 핵심 데이터 집합에 해당하는 것은 과제를 수행하고 해당 시스템에서의 모든 행위의 주체가 되는 집합인 ‘과제수행주체’가 정의될 수 있다. 또한 모든 행위의 대상이 되는 ‘과제’도 핵심 데이터 집합의 범주에 속한다. 과제는 크게 단기 사업과제와 중장기 사업과제로 구분할 수 있다. 특기, 중장기 사업과제에 대해서는 여러 기관이 하나의 총괄과제에 대해 여러 개의 세부과제를 구성하여 수행할 수 있기 때문에 과제에 대한 구분을 가지고 구분하고 있다. 정리하자면 결국은 행위의 주체인 ‘과제수행주체’와 행위의 대상인 ‘과제’를 정의하고 그들간의 관계(다양한 형태의 행위 및 업무)를 정의해 나아가면서 논리 데이터 모델이 정의되어 진다.

또 하나의 다른 형태의 핵심 데이터 집합이라고 할 수 있는 것이 지역이다. ‘지역’은 ‘과제수행주체’들의 다양한 형태의 지역(기관 소재지 주소, 개인 거주지 주소, 개인 근무지 주소)을 관리하고자 하는 목적으로 우편번호와 임의의 지역구분을 동시에 관리할 수 있는 형태의 핵심 데이터 집합을 정의할 수 있다. 위 개념 모델에서 ‘과제수행주체’ 집합을 살펴보자. 일단, 이 집합은 우리 회사에서 구축하고자 하는 과제통합관리 시스템에서 사용될 행위의 주체에 해당하는 모든 데이터 집합을 통합한 형태이다. 크게 ‘기관’과 ‘개인’으로 구분하여 통합하였고 기관 내에서는 연구소, 대학교, 기업 등으로 구분하여 통합하였다. 설계에서는 단계적 기법의 데이터 구조를 상위 데이터 집합을 통합하고 이들의 형태를 결정하는 것은 매우 중요한 부분이다. 상위 데이터 집합의 형태에 따라서 해당 정보 시스템의 효율성과 확장성이 좌우되고 더 나아가서는 해당 업무 또는 그 기업의 비즈니스의 확장성과 효율성과 유연성을 결정짓는 중요한 요소이기 때문이다. 만약, 대학교, 국공립연구소, 정부출연연구소, 정부투자연구기관, 민간기업, 민간연구소등의 엔터티 후보를 도출하고 이것들을 별개의 각각의 엔터티로 정의한다고 가정해 보자. 이러한 형태의 데이터 모델이 불가능한 것은 아니다. 하지만 이것들을 각각 별개의 엔터티를 정의한 시스템에서는 가까운 미래에 조금 다른 형태의 연구기관, 정부기관이 추가된다면 그 때에는 또 다른 형태의 엔터티를 추가하여 대응할 수 밖에는 없다. 즉, 조그만 업무의 확장에 대응하기 위해서 데이터 구조의 추가, 변경은 불가피한 상황이 초래될 것이다. 이렇듯 데이터 구조의 피라미드에서 상위에 속하는 데이터 집합들(대개의 경우 Key Entity가 여기에 속한다.)은 최대한 통합을 고려해야 한다.

위에서 작성된 개념 데이터 모델을 조금 더 상세화 하면 먼저 ‘과제수행주체’ 엔터티와 ‘지역’ 엔터티에는 현재 ‘과제수행주체주소’라는 M:M 관계가 존재한다. M:M 관계를 해소하게 되면 다음과 같은 교차 엔터티를 추가 생성하게 된다.

[그림 부록B-5] 개체수행주체와 지역의 M:M 관계 해소

[그림 부록B-5]의 데이터 모델에서와 같이 개체수행주체’와 ‘지역’ 엔터티의 M:M 관계를 해소하게 되면 ‘수행주체 연락처’와 같은 교차엔터티를 생성할 수 있다. 여기에서는 문제의 지문에서 요구하는 연락처, 주소에 관련된 모든 사항들이 관리될 수 있는 형태로 구성되게 된다. 향후의 각각의 행위의 주체들이 기 정의된 연락처의 유형 이외의 다른 형태의 연락처가 추가된다고 하더라도 위의 구조에서는 이를 자연스럽게 수용할 수 있는 형태의 데이터 구조가 된다.

다음으로는 ‘과제수행주체’ 엔터티와 ‘과제’ 엔터티 사이의 M:M 관계를 살펴보자. 이들간에는 ‘과제 수행역할’이라는 관계가 존재한다. 과제수행주체인 각 기관, 연구소, 대학교, 일반기업 등이 과제와 직접적인 과제수행기관으로써의 관계를 가진다. 또한 둘 간에는 ‘과제’ 엔터티와 ‘과제수행주체’ 엔터티의 ‘개인’과의 관게가 또 존재하게 된다. 이것은 문제의 지문에 설명하고 있는 것처럼 총괄책임자, 과제책임자, 참여 연구원의 역할을 수행하게 된다. 실제 데이터 모델이 완성된 모습에서는 위의 두 가지 형태의 과제 수행 역할을 통합한다면 아래와 같은 형태의 데이터 구조가 생성되게 된다.

아래와 같이 ‘과제수행주체’와 ‘과제’ 엔터티의 M:M 관계를 통합하여 ‘과제참여주체구성’ 이라는 새로운 형태의 엔터티를 추가할 수 있다. 이러한 형태의 데이터 구조에서는 앞으로 추가적으로 생겨날 수 있는 다양한 형태의 과제참여주체의 역할에 대해서도 유연하게 대응할 수 있는 형태의 데이터 구조라고 할 수 있다.

[그림 부록B-6] 개체수행주체와 과제의 M:M 관계 해소

다음은 ‘과제수행주체’ 사이의 자기관계인 M:M 재귀관계의 해소에 대해서 살펴보자. ‘과제수행주체’에는 [그림 부록B-7]에서 보는 바와 같이 여러 형태의 수행주체 구분이 존재한다. 이들은 자기 자신들과의 관계를 가지고 있다. 즉 수행주체의 각 구분들끼리 관계를 가지고 있고 그 형태가 M:M 관계이다. 특히 기업의 대표자, 기관의 대표, 또는 개인이 각 기관, 기업에 소속된 관계를 관리하고자 한다면 다음과 같은 M:M 재귀관계가 존재한다. 이 M:M 관계를 해소하면 다시 새로운 교차 엔터티가 추가된 데이터 모델이 생성되게 된다. 즉, M:M 관계를 관리하기 위한 새로운 엔터티가 생성되고 이 엔터티는 ‘과제수행주체’ 엔터티와 두 개의 관계를 맺게 된다. 이 M:M 관계 엔터티에서도 향후 추가되어진 다양한 형태의 과제수행주체들 간의 관계에 대해서 유연하게 대응할 수 있는 확장성 있는 모델이 될 수 있다.

[그림 부록B-7] 과제수행주제 M:M 재귀관계 해소

주요 핵심엔터티를 정의하고 핵심엔터티들 간의 M:M 관계를 해소하게 되면 기본적인 형태의 데이터 모델의 골격이 만들어 진다. 아래와 같은 데이터 모델의 골격에 각 엔터티에서 필요로 하게 되는 속성을 정의해 나아간다. 또한, 각각의 속성을 검증하는 단계에서의 정규화 과정을 통해 새로운 엔터티가 태어나기도 한다. 물론, 업무 요구사항에서 기술된 추가적인 내용에 대해서도 새로운 엔터티가 추가될 수 있다. 이러한 일련의 과정들을 각 엔터티에 대해서 반복적으로 수행해 나아가면 전체 논리 데이터 모델이 완성되게 된다.

[그림 부록B-8] 중요 M:M 관계가 해소된 후의 데이터 모델

[그림 부록B-8]의 데이터 모델에서 추가적으로 생성되어야 할 부분으로는 과제수행주체의 각종 경력 정보가 있다. 예를 들자면 정부출연과제수행실적, 연구논문, 저서 등에 대한 관리를 추가할 수 있다. 이 부분에서는 각 과제수행주체(기관, 개인 포함)들이 가지고 있는 모든 경력사항을 통합하여 관리할 수 있는 형태가 바람직하다.

그 다음으로 추가할 수 있는 영역으로는 과제수행계획부분이 존재한다. 문제에서 요구하는 내용을 살펴보면 과제수행계획이 미리 정해진 항목에 따라서 계획의 내용을 등록하고 관리하고자 하고 있다. 이러한 형태의 모델이 되기 위해서는 과제계획 항목과 각 과제 사이에는 M:M 관계가 존재하게 된다. 이 M:M 관계를 해소한 형태가 다음과 같은 ‘과제수행계획’ 엔터티가 될 수 있다.

[그림 부록B-9] 과제수행계획

과제를 등록하면서 제출하는 내용 중에 또 한가지가 사업비편성내역에 대한 내용이다. 문제에서 요구하는 정보 요구사항으로는 사업비 편성 내역은 미리 정해진 사업비목에 따라서 내용을 기입하게 되어 있다. 또한 사업비는 현금과 현물로 구분하여 편성하게 되어 있다. 또한 사업비 편성에 대해서는 사업비 총액에 대한 것을 정의하여 정부 분담금과 신청기관 분담금에 대해서 정의하게 하고 있다. 이러한 규칙을 데이터 구조로 표현하는 것이 중요하다.

[그림 부록B-10] 사업비 편성내역

[그림 부록B-10]의 모델에서 보듯이 사업비 비목구성을 분담구성과 사업비비목구성으로 분리하여 각 구성구분 별로 사업비에 대한 내용을 정의하게 하고 이를 필요에 따라서 현금과 현물로 구분하여 정의하게 하였다. 이렇게 하면 문제에서 요구하는 사항을 충족할 수 있는 유연한 모델이 생성되게 된다. 여기까지가 완성되면 데이터 구조의 대부분이 완성이 된다. 마지막으로 남은 부분이라면 과제의 구성과 진행에 대한 이력이다. 이 부분은 반드시 관리되어야 한다고 명시하고 있고 각 과제가 변경되는 내용도 관리하고 또한 각 과제의 수행되어가는 진행에 대한 것도 관리할 수 있는 형태의 모델을 요구하고 있다. 문제에서 요구하는 형태의 과제 이력은 [그림 부록B-11]과 같이 정의할 수 있고, 여기에 조금 상상력을 추가한다면 과제내용의 모든 변경사항을 관리할 수 있는 엔터티로 확장할 수도 있을 것이다.

![](../images_files/boor12.gif

[그림 부록B-11] 과제이력 모델

이상과 같이 주어진 지문이 복잡하고 많은 내용의 데이터들이 얽혀 있는 것처럼 보이지만, 체계적으로 하향식 접근을 통해 데이터 모델링의 각 단계를 진행해 보면, 첫째, 문제에서 요구하는 모든 데이터가 아닌 핵심 데이터에 대해 인식하고 이것들을 먼저 정의한다. 둘째, 핵심 엔터티들간의 관계를 정의하고 그 관계를 기반으로 각각의 부분들을 조금씩 상세화해 나아가면 어느새 전체 데이터 구조의 골격이 만들어지게 된다. 이러한 골격들의 각각들을 세부적인 내용(속성, 상세화, 정규화)으로 정의해 나아가면 전제 데이터 구조가 완성된다.

[그림 부록B-12] 완성된 논리 데이터 모델