데이터 표준화 원칙 문서.ver1.0.0

1 원칙(原則, Principle) vs 규칙(規則, Rule)

1.1 원칙 (Principle)

• 기본적인 방향과 기준을 제공하는 근본적인 개념
• 규칙이 만들어지는 근거가 되는 상위 개념
  
• 일반적으로 변하지 않는 보편적인 기준을 의미하며, 조직이나 시스템이 따라야 하는 방향성을 제시
  
• 강제성보다는 가이드라인 역할을 하며, 다양한 상황에서 응용될 수 있고 예외가 있을 수 있음
  
• 예시:
  • 표준 단어는 조직 내에서 일관되게 사용되어야 한다. (일관성 유지 원칙)
    
  • 데이터 용어는 사용자가 이해하기 쉽게 정의해야 한다. (가독성 원칙)
    
  • 표준 단어 사전은 지속적으로 관리 및 개선되어야 한다. (지속성 원칙)

1.2 규칙 (Rule)

• 원칙을 구체적으로 실현하기 위한 세부적인 기준이나 명령
  
• 특정한 행위나 절차를 강제하는 성격을 가지며, 보통 예외가 적고 엄격하게 적용됨
  
• 원칙이 방향성을 제시하는 개념이라면, 규칙은 실제 실행 방법을 명확하게 정의하는 것
  
• 규칙이 존재함으로써 혼선을 방지하고, 특정 행동이나 절차를 표준화할 수 있음
  
• 예시:
  • 표준 단어는 한글, 영문, 숫자로만 구성하고, 띄어쓰기를 허용하지 않는다.
    
  • 영문 단어의 첫 글자는 대문자로, 나머지는 소문자로 작성한다.
    
  • 영국식 영어(Colour, Centre)는 사용하지 않고 미국식 영어(Color, Center)를 사용한다.

[표준화 원칙 문서 예시]

2 목적 및 범위

2.1 표준화의 목적

• 연구소 내 데이터 표준화를 통한 데이터 품질 향상
• 부서(팀) 간 데이터 호환성 및 활용성 증대
• 실험 데이터의 일관성 있는 관리 체계 구축
• 연구 프로세스의 효율성 향상
• 데이터 기반 의사결정 지원 강화

2.2 적용 범위

• 대상 조직: SW연구소 내부
• 대상 서비스
  • SG IDEA (실험 프로세스 전산화 및 자동화 서비스)
  • LabIDE (well 단위 신호 분석 서비스)
  • PDA (대량 신호 분석 서비스)

3 데이터베이스 표준 수립 및 적용

• 코드, 용어 및 도메인 표준 수립을 위해 다음 각 호의 항목을 표준화 지침에 따라 데이터 표준사전으로 작성하여야 하고 최신성을 유지하여야 한다.

1. 표준단어
2. 표준도메인
3. 표준코드
4. 표준용어

4 개요

4.1 문서 이력

버전	작성일자	작성자	검토자	승인자	변경내용
ver1.0.0	2024.11.22	김광민 과장	홍길동 부장	이순신 상무	최초 작성 및 표준 단어 사전 원칙 작성
ver1.1.0	2025.02.21	김광민 대리	홍길동 부장	이순신 상무	표준 단어 사전 원칙 초안 완성
ver1.1.1	2025.03.05	김광민 과장	홍길동 부장	이순신 상무	표준 단어 사전 원칙 피드백 반영 완료
ver1.2.0	2025.04.28	김광민 과장	홍길동 부장	이순신 상무	표준 도메인 사전 원칙 초안 완성
ver1.3.0	2025.05.19	김광민 과장	홍길동 부장	이순신 상무	표준 용어 사전 원칙 초안 작성
ver1.3.1	2025.07.04	김광민 과장	홍길동 부장	이순신 상무	표준 용어 사전 원칙 보완
ver1.4.0	2025.08.13	김광민 과장	홍길동 부장	이순신 상무	표준 코드 테이블 원칙 초안 완성
ver1.5.0	2025.08.13	김광민 과장	홍길동 부장	이순신 상무	표준 데이터 계층 구조 원칙 초안 완성

4.1.1 참고사항

• 신규 표준화 정책 수립에 따른 최초 제정
• 표준화 체계 수립 후 분기별 검토를 통해 필요시 개정 예정
• 검토 의견은 담당자에게 전달
  • Core 개발팀
  • 김광민 과장
  • kmkim@seegene.com
  • 02)2240-4708
• 문서 버전 관리
  • 큰 변경: v2.0.0 (예: 표준화 범위 확대)
  • 중간 변경: v1.1.0 (예: 장/절 추가)
  • 작은 변경: v1.0.1 (예: 오타 수정, 일부 내용 보완)
• 용어 정의
  1. “데이터베이스”란 정보가 체계적으로 구조화되어 저장된 전자적 집합물을 말한다.
  2. “표준화”란 단어, 도메인, 코드, 용어, 메타데이터, 데이터셋 등의 표준을 수립하여 데이터베이스에 일관되게 적용하는 일련의 활동을 말한다.
  3. “표준용어”란 데이터 사용자 간의 명확한 의사소통을 위해 데이터베이스에서 업무적으로 사용되고 있는 용어의 표준을 정의한 것을 말한다.
  4. “표준단어”란 표준용어를 구성하기 위하여 공통적인 단어의 표준을 정의한 것을 말한다.
  5. “표준도메인”이란 표준용어에서 사용하는 데이터의 값이 공통으로 갖는 데이터 형식과 값의 영역 표준을 정의한 것을 말한다.
  6. “공통표준”이란 공통표준용어, 공통표준단어, 공통표준도메인을 통칭한 것을 말한다.
  7. “데이터베이스 표준용어”란 개별 데이터베이스 구축ㆍ운영 시 일관된 용어를 적용하기 위해 정한 표준용어를 말하며, 표준용어를 준용한다.
  8. “데이터베이스 표준단어”란 개별 데이터베이스 구축ㆍ운영 시 일관된 단어를 적용하기 위해 정한 표준단어를 말하며, 표준단어를 준용한다.
  9. “데이터베이스 표준도메인”이란 개별 데이터베이스 구축ㆍ운영 시 일관된 도메인을 적용하기 위해 정한 표준도메인을 말하며, 표준도메인을 준용한다.
  10. “데이터베이스 표준코드”란 개별 데이터베이스 구축ㆍ운영 시 일관된 코드를 적용하기 위해 정한 표준코드를 말한다.
  11. “데이터베이스 표준”(이하 “DB표준”이라 한다)이란 데이터베이스 표준용어, 데이터베이스 표준단어, 데이터베이스 표준도메인, 데이터베이스 표준코드를 통칭한 것을 말한다.
  12. “도메인”이란 데이터값이 공통으로 갖는 데이터 형식과 허용되는 값의 영역을 정의한 것을 말한다.
  13. “데이터셋”이란 데이터베이스, 스프레드시트 등과 같이 구조화된 데이터의 묶음 및 집합을 말한다.
  14. “메타데이터”란 데이터베이스 내 데이터의 체계적인 관리와 편리한 검색 및 활용을 위하여 데이터의 구조, 속성, 특성, 이력 및 용어 등이 표현된 자료를 말한다.

5 표준화 원칙

• 조직 내 메타데이터 용어를 일관되게 정의하고 관리하여 정보 공유 및 데이터 품질을 유지한다.
• 명명 규칙, 약어 사용, 데이터 형식 등의 기준을 수립하여 데이터 표준화를 실현한다.
• 조직의 요구사항을 반영하며, 공공 기관이나 권위 있는 조직의 양식을 반드시 따를 필요는 없다.
• 외부 표준과 내부 요구사항 간의 균형을 유지하여 현실적인 표준을 수립한다.

6 표준 단어사전 원칙

• 조직 내에서 사용되는 데이터 용어를 표준화하고 관리하기 위한 도구이다. 이는 데이터 거버넌스와 데이터 품질 관리의 중요한 구성 요소이다.
• 표준 단어 사전을 만드는 과정은 반복적이고 지속적으로 이루어져야 하며, 조직의 변화와 새로운 요구사항을 반영하여 계속 발전시켜 나가야 한다.
  
• 조직의 모든 구성원이 쉽게 접근하고 활용할 수 있어야 한다.
• 또한, 기술적인 구현뿐만 아니라 조직 문화를 함께 고려해야 한다.

6.1 표준 단어 사전의 구성 요소

표준단어는 단어명, 영문명, 영문약어명 및 정의 등으로 구성되며 약어는 영문명을 축약하여 작성한다.

• [단어 ID]

  • 단어를 고유하게 식별하기 위한 식별자
  • ‘W’(Word) + 5자리 일련번호로 구성 (예: W00001)
    

• [단어명]

  • 표준단어를 구성하는 최소단위의 단위를 의미하며 한글 및 영문, 숫자로 정의한다.
  • 표준단어의 최대길이는 15자로 하며, 10자 이내로 작성할 것을 권장한다.

• [한자]

  • 한자 표기가 필요한 경우 해당 단어의 한자를 기재
  • 한자 표기가 없는 경우 빈칸으로 둠
    

• [영문명]

  • 표준단어명의 영문 명칭을 의미한다.
  • 영문명의 첫 자리의 알파벳은 대문자로 하고 나머지 부분은 소문자로 하며,영문 단어 간에는 띄어쓰기를 한다.

• [영문약어명]

  • 영문명의 축약된 형태의 영문명칭을 의미하며 영문명을 바탕으로 영문약어를 정의한다.
  • 영문약어의 최대 길이는 4자로 한다.(권장)
  • 단, 고유명사나 관용적인 표현 등의 경우 글자수에 대한 예외를 허용한다.

• [단어 설명]

  • 해당 단어가 뜻하는 것 혹은 내용을 의미한다.
  • 데이터 명칭을 그대로 서술하거나 약어 또는 전문 용어를 이용한 기술은 가급적 지양한다.

• [형식 단어 여부]

  • 해당 단어가 도메인 특성을 지닌 형식단어(분류어)인지의 여부를 기재
  • 형식 단어 여부는 단어의 용어 구성에서의 역할(위치와 기능)을 구분하는 것이므로, 관용어 여부와는 다른 차원의 분류이다.
  • 0: 기본단어 (수식어성)
    • 용어를 구성하는 단어로 용어의 마지막에 위치할 수 없는 단어
    • 주제어(무엇을 설명하는지), 수식어, 접두사/접미사, 복합명사의 수식명사 등이 이에 속한다
    • 예시: 주문, 고객, 상품, 거래
  • 1: 분류단어 (도메인성)
    • 용어를 구성하는 단어로 용어의 마지막에 위치하는 단어
    • 용어가 가질 수 있는 속성 정보(데이터 형식 및 길이)를 구체적으로 표현하기 위해 사용한다
    • 분류단어는 도메인과 매핑 되어 그 속성정보를 정의한다
    • 예시: 금액, 수량, 성명, 코드, 번호, 일자
  • 용어 구성(단어 조합) 예시
    • 기본 단어: 고객, 주문
    • 분류 단어: 금액
    • 표준 용어: 고객주문금액
      
    • 시약코드 (시약 + 코드): 여기서 분류단어는 코드로 string(or varchar) datatype을 암시한다.
    • 시약이름 (시약 + 이름): 여기서 분류단어는 이름으로 string(or varchar) datatype을 암시한다.
    • 시약농도 (시약 + 농도): 여기서 분류단어는 농도로 float datatype을 암시한다.
    • 농도단위 (농도 + 단위): 여기서 분류단어는 단위로 string(or varchar) datatype을 암시한다.

• [이음동의어 목록]

  • 소리는 다르나 의미가 동일한 단어 (예) 연도/년도, 비율/율
  • 이음동의어는 공통표준단어와 한글명 이외에는 동일하여 한글명만 관리

• [금칙어 목록]

  • 해당 표준단어에 대한 금칙어 목록을 기재
  • 금칙어 : 사용이 허락되지 않거나 일정기간 사용하다가 특정시점 이후 사용이 중지된 단어
    • (예시) 파일 (표준어) \(\leftrightarrow\) 화일 (금칙어. 사용×)
    • 금칙어는 표준단어 정의대상이 아니며 금칙어의 한글명만 관리

• [등록일]

  • 해당 단어가 표준단어사전에 최초 등록된 날짜
  • YYYYMMDD 형식으로 기재

• [수정일]

  • 해당 단어의 정보가 최종 수정된 날짜
  • YYYYMMDD 형식으로 기재
  • 최초 등록시에는 등록일과 동일

• [승인 상태]

  • 해당 단어의 현재 승인 상태를 표시
  • 임시저장/승인요청/승인완료/반려 중 하나로 표시

• [관용어]

  • 관용어 (1): 업무상 관례적으로 사용되거나 일반적으로 통용되는 단어/용어
  • 일반단어 (0): 관용어를 제외한 모든 단어

• 예시

  항목	내용
  단어ID	W00001
  단어명	시약
  한자	試藥
  영문명	Reagent
  영문약어명	RGNT
  단어설명	화학 실험이나 분석에 사용되는 화학물질
  형식단어여부	0
  이음동의어목록	-
  금칙어목록	리에이전트
  등록일	20241122
  수정일	20241122
  승인상태	승인완료
  관용어	0

6.1.1 단어 구성관점에서의 단어 종류

• 단일어
  • 하나의 형태소(形態素: 의미의 기능을 부여하는 언어의 형태론적 수준에서의 최소단위)로 성립된 단어
    • 고유명사(기관명 포함), 지명(명사) 단일어로 사용함
    • 접사(접두사 및 접미사)와 합성된 단어
    • 두 개의 단일어로 구성되나 영문단어가 각각의 단일어의 영문단어의 조합과 일치 하지 않고 다른 영문단어가 존재하는 경우
  • 예시: 고객, 지점, 가격,시설
• 복합어
  • 둘 이상의 어근(실질 형태소)이 결합 이루어진 단어
  • 예시: 전화번호, 휴대폰번호, 차용지점
• 외래어
  • 원래 외국어였던 것이 국어의 체계에 동화되어 사회적으로 그 사용이 허용된 단어
  • 예시: 이메일, 팩스, 네비게이션
• 관용어
  • 한글 단어와 외래어가 결합되어 사용되거나 기타 국어 체계에 부합하지 않더라도 관용적으로 자주 사용되며 의미가 명확한 단어
  • 일반 사회나 기관에서 관습적으로 널리 쓰는 말
  • 예시: VDC, ABS, 셀프계약서, MT
• 접사 (접두사/접미사)
  • 접두사(Prefix): 어떤 낱말 앞에 붙어서 의미를 첨가하여 다른 낱말을 이루는 말
  • 접미사(Suffix): 낱말의 끝에 붙어 의미를 첨가하여 다른 낱말을 이루는 말
  • 예시: 미사용, 보증료

6.1.2 단어 관계관점에서의 단어 종류

• 동음이의어
  • 발음은 동일하나 의미가 다른 단어(Homonym)
  • 예시: 기술(Description) / 기술(Technology) / 기술(Skill) / 기술(Trick) / 기술(Artistry)
• 이음동의어
  • 동일한 의미를 표현하는 두 개의 다른 단어 (Synonym)
  • 즉, 발음은 다르나 동일하거나 매우 유사한 의미를 표현하는 단어
  • 예시: 설명(Explanation) / 기술(Description) / 해설(Commentary) / 문서화(Document) / 상세(Description) / 해석(Interpretation) 등
• 금칙어
  • 표준단어 사용의 일관성을 위하여 사용하지 못하게 지정된 단어
  • 예시: 이해당사자(X), 이해관계자(O)
• 유사어
  • 표준단어 사용의 일관성을 위하여 권장어(대체어) 사용을 권고하는 단어
  • 예시: 수정, 변경, 정정
• 축약어
  • 줄여서 간략하게 표현하는 단어
  • 주민번호(X), 주민등록번호(O)

6.2 표준 단어 원칙

• 표준 단어 정의 원칙은 데이터 거버넌스를 강화하기 위해 조직 내 데이터 용어를 일관되게 정의하는 기준을 제공한다.
• 표준 단어 사전을 체계적으로 구축하기 위한 세부 규칙들을 만들고 준수한다.
• 조직 구성원 간 원활한 정보 공유를 지원한다.
• 데이터 모델링 및 시스템 개발에서 명확한 기준을 제공하는 역할을 한다.

6.2.1 표준 단어 정의 규칙

구분	규칙 및 설명
문자	• 표준단어는 한글, 영문, 숫자로만 구성한다. 예시: 실험, FAM, 12월
	• 띄어쓰기를 허용하지 않으며, 특수문자(“/”, “&”, “-”, 등)는 허용하지 않는다. • 고유명사에 포함된 ‘&’의 경우, ’n’ 등 알파벳으로 대체하여 사용한다. 예시: 고객 구분(X) \(\rightarrow\) 고객구분(O), MnA
품사	• 한글 단어는 체언(명사, 대명사, 수사)으로 정의하며, 용언(동사, 형용사), 수식언(관형사,부사), 관계언(조사, 토씨, 접속사), 복수표시 또는 소유격 형태의 단어는 사용하지 않는다. 예시: -하다, -이다, 의, 대한, 에, 관한, 에서, 등, 하는, 들, 과, 와의 등 • 영어 단어는 명사, 형용사(순수형용사, 분사), 동명사를 포함하며 관사, 부사, 전치사, 동사, 감탄사를 제외한다. (단, 예외 허용 동사: is, has, exist) 예시) uid: 고유한식별자(X) \(\rightarrow\) uid: 고유식별자(O) before baseline transformation data (X) \(\rightarrow\) pretransformation baseline data
길이	• 표준단어의 최대 길이는 15자로 하며, 10자 이내로 작성할 것을 권장한다.
적용 순위	• 회사에서 관용화된 단어를 최우선으로 적용한다 (사용 빈도수나 업무를 고려). 예시: 올리고믹스, TOCE, MuDT
	• 복합어가 단일어 + 단일어 조합보다 우선순위로 적용된다. (예를 들어, “전화번호”가 자주 쓰이는데, 표준화를 위해 무조건 “전화 + 번호”로 쪼개면 오히려 혼란이 발생할 수 있음. 사용자가 “전화번호”를 찾고 싶을 때, 데이터베이스나 시스템에서 “전화”와 “번호”가 각각 나뉘어 있으면 원하는 데이터를 쉽게 찾을 수 없음)

6.2.2 한글 단어 사용 규칙

순번	규칙 및 설명	예시
1	• 표준단어는 단일어 형태의 명사형 낱말을 표준단어로 정의하는 것을 기본 원칙으로 한다.	고객, 가격, 금액, 지점, 실험, 분석, 검출
2	• 동일한 의미의 단어를 한글과 영문으로 중복해서 정의하지 않는다.	RENT(X) \(\rightarrow\) 렌트(O)
3	• 축약된 형태의 단어로 정의하지 않는다. 단, 범용 또는 공식적으로 사용이 승인된 약어는 표준 원칙에 의거하여 사용할 수 있다. • 또한 원래 단어가 너무 길거나 잘 활용하지 않아서 업무적으로 축약된 단어를 주로 사용하는 경우에 한하여 사용할 수 있다 • 용어명 길이 제약을 해결하기 위해 부득이하게 약어를 사용해야 할 경우에는 약어와 전체 단어를 모두 표준단어로 등록하도록 한다	주민번호(X) \(\rightarrow\) 주민등록번호(O) 등평(X) \(\rightarrow\) 등급평가(O)
4	• 한글 축약어는 다른 단어와 붙여서 쓸 경우 혼동이 될 우려가 있으므로 가급적 풀어 쓴 단어를 사용한다. 단, 어감상 필요시 예외로 적용할 수 있다. (이음동의어)	가(假)(X) \(\rightarrow\) 임시(O) 현(X) \(\rightarrow\) 현재(O) 전(X) \(\rightarrow\) 이전(O) 후(X) \(\rightarrow\) 이후(O)
5	• 과거 단어와 현대 단어를 함께 사용하고 있는 경우 가급적 현대 단어를 사용한다.	계리(X) \(\rightarrow\) 계산(O) 구좌(X) \(\rightarrow\) 계좌(O) 매상(X) \(\rightarrow\) 매출(O) 연혁(X) \(\rightarrow\) 이력(O)
6	• 접두사 및 접미사는 가급적 별도로 분리 하지 않으며 표준단어(단일어)로 등록함을 원칙으로 한다.	불, 합격 (X) \(\rightarrow\) 불합격(O)
7	• 고유명사(기관명 포함)는 한글 단어를 사용하는 것을 원칙으로 한다	Seegene(X) \(\rightarrow\) 씨젠(O)

6.2.3 영문 단어 사용 규칙

순번	규칙 및 설명	예시
1	• 외국에서 들어온 말로 국어처럼 쓰이는 외래어는 영문을 쓰지 않고 외래어 한글 표기법에 따라 정의하는 것을 원칙으로 한다.	Fax(X) \(\rightarrow\) 팩스(O) Email(X) \(\rightarrow\) 이메일(O) Database(X) \(\rightarrow\) 데이터베이스(O)
2	• 영문을 대체할 적절한 한글이 없거나 영문자체에 고유한 업무적 의미를 담고 있는 경우, 또한 관용적으로 두음문자 표현이 사용되고 있는 경우에는 해당 영문을 그대로 사용한다. 단, 표준단어로 등록 시 해당 영문의 전체명이 아닌 두음문자 형식의 대문자로 등록한다.	dfc, df, R2, URL, HTML, SQL
3	• 영문 단어 첫글자는 알파벳 대문자로 나머지는 소문자로 작성한다.	SEEGENE(X) \(\rightarrow\) Seegene(O) SHIFT(X) \(\rightarrow\) Shift(O)
4	• 통용되는 접두사(pre-, post-, multi-로 한정)를 독립적으로 사용하고 싶은 경우 통용되는 접두사와 단어를 분리하여 처리한다. 이때 연결사는 띄어쓰기(’ ‘),하이픈(’-‘),밑줄(’_’)을 사용하며 접두사는 독립된 단어로 취급한다. • 단, 하나의 단일어로 취급하려면 통용되는 접수사와 단어를 분리하지 않는다.	preprocessing \(\rightarrow\) pre-processing multiprocessing \(\rightarrow\) multi processing postanalysis \(\rightarrow\) post_analysis
5	• 영문 단어를 한글화 할 경우, 영문 의미로 한글화 한 경우와 소리 나는 대로 한글화한 경우 둘 다 자주 사용될 경우, 소리 나는 대로 한글화한 영어발음을 표준으로 하고, 의미로 한글화 한 단어는 금칙어로 등록한다.	ERROR(X), 오류(X) \(\rightarrow\) 에러(O)
6	• 한글 단어 보다 더 친숙하게 사용되는 영문 단어의 경우에는 그 영문단어를 사용한다.	인터넷프로토콜(X), 아이피(X) \(\rightarrow\) IP(O)
7	• 관용적으로 사용하는 단어나 고유명사인 경우 특수문자 중 ‘/’, ‘-’, ’&’만을 사용할 수 있으나, 가급적 특수문자를 사용하지 않는다	M&A(O), MnA(O, 권장)
8	• 한글, 영문, 숫자의 혼용이 가능하다	회사(O), 12월(O)
9	• 한글과 영문만 표준 단어로 인정하며 기타 외국어(한자, 일본어 등)는 사용하지 않는다.
10	• 영국식 영어를 지양하고 미국식 영어를 지향한다.	expiry(영국, X) \(\rightarrow\) expiration(미국,O) colour(영국, X) \(\rightarrow\) color(미국,O) centre(영국, X) \(\rightarrow\) center(미국,O) postcode(영국, X) \(\rightarrow\) zip code(미국,O)

6.2.4 영문 약어 사용 규칙

영문 약어 사용 원칙은 물리명 작성에 직접적인 연관이 있기 때문에 가급적 프로그래밍으로 구현하여 검증을 자동화하도록 한다.

단계	규칙 번호	내용	예시
1단계		기본 검증 및 예외 처리
	1	접속사, 전치사, 관사는 사용을 금지한다. 단, 단어 목록에 있으면 제거하고 용어 목록에 있을 경우 제거 후 축약	“and”, “of”는 제외 일과 끝 (용어) : End of Day \(\rightarrow\) endy
	2	범용적으로 사용되는 두문자 또는 통용되는 약어가 있는 경우 해당 두문자어 또는 약어를 그대로 사용한다. (예: ID, UI, OS 등)	“User Interface” \(\rightarrow\) “UI”
	3	일반적으로 통용되는 접두사(pre-, post-, multi-, pre_, post_, multi_, pre , post , multi 등)가 포함된 단어의 경우, 접두사는 독립적으로 처리하고 용어를 만들때 밑줄(_)로 구분하여 결합한다.	pre-process \(\rightarrow\) pre_prcs multi process \(\rightarrow\) multi_prcs post_analysis \(\rightarrow\) post_anly
	4	입력 단어가 4글자 이하일 경우 그대로 사용한다.	“data” \(\rightarrow\) “data”
2단계		문자 분류 규칙
	5	모음(A, E, I, O, U) 외 모든 알파벳이 자음이다.	“pattern”에서 P, T, T, R, N은 자음
	6	Y, W와 같이 자음이지만 모음으로 혼동하는 알파벳도 모두 자음으로 간주한다. 즉, 2개의 단모음이 결합하여 하나의 음절을 이루는 이중모음(diphthong)의 반모음(semivowel)은 자음으로 간주한다. 즉, 이중모음의 첫 음은 모두 자음이다. - 예시. ㅑ(ㅑ=ㅣ+ㅏ, ㅣ는 자음으로 간주), ㅕ, ㅛ(ㅛ=ㅣ+ㅗ, ㅣ는 자음으로 간주), ㅠ, ㅒ, ㅖ, ㅘ (ㅘ = ㅗ+ㅏ, ㅗ는 자음으로 간주), ㅝ, ㅢ, ㅟ 등	Yellow \(\rightarrow\) YLLW Window \(\rightarrow\) WNDW
	7	단어의 첫 글자가 모음인 경우, 해당 모음을 자음으로 취급한다.	“apple” \(\rightarrow\) a는 자음 처리
3단계		약어 생성 핵심 로직
	8	단어의 대표 자음으로 영문 약어를 구성한다. 대표 자음의 적용 우선 순위는 앞 자리의 자음부터 4 글자까지 적용한다.	“management” \(\rightarrow\) “mngm”
	9a	연속된 동일 자음 처리: 두 자음이 원본 단어에서 서로 인접해 있으며, 그 사이에 모음이 없는 경우 두 번째 자음을 제거한다.	“attitude” \(\rightarrow\) “attd”
	9b	모음 삽입: 연속 자음 제거 후 결과 약어의 길이가 4글자 미만일때,
		1. 원본 단어에서 자음과 모음의 상대적 위치를 기준으로 모음을 삽입.
		2. 자음을 유지하며 원본 단어에서 추출된 모음 중 필요한 만큼만 삽입하여 4글자로 만든다.	“attire” \(\rightarrow\) “atir”
		3. 자음을 우선적으로 배치하고, 4글자가 될 때까지만 모음을 추가한다.	“pattern” \(\rightarrow\) “ptrn”
	10	자음만으로 만든 약어가 4글자 미만인 경우:
	10a	원본 단어에서 첫 모음의 상대적 위치를 파악한다.
	10b	추출된 자음 사이의 동일한 상대적 위치에 해당 모음을 삽입한다.
		그래도 4글자가 안되면 다음 모음에 대해 a, b를 반복한다.	“title” \(\rightarrow\) “titl”
4단계		후처리 및 검증
	11	생성된 모든 약어는 기존 약어들과 중복되지 않아야 한다.
	12	약어 중복이 발생하면, 먼저 4글자 약어를 생성하고 남은 자음을 차례로 추가한다. 그래도 약어 중복이 발생하면 원래 단어의 모음을 앞에서부터 순서대로 하나씩 추가하여 새로운 약어를 생성한다. 이 과정은 중복이 해결될 때까지 반복한다. 따라서, 4글자를 초과할 수 있다.	출력: print \(\rightarrow\) prnt (중복) 부모: parent \(\rightarrow\) prnt (중복) 출력: print \(\rightarrow\) prnt 부모: parent \(\rightarrow\) parnt
5단계		표현 규칙
	13	영문 약어는 물리명과 직결되기 때문에 단어 사전과 프로그래밍 모두에서 소문자로 사용한다.	“ptrn” (코드에서 “ptrn”)
	14	약어는 기본적으로 4글자로 구성하되, 널리 알려진 고유명사나 관용적 표현(예: TCP/IP, RAM 등)의 경우 글자 수 제한을 적용하지 않는다.	“RAM” 그대로 유지

6.2.5 복합어 사용 규칙

순번	규칙 및 설명	예시
1	• 업무적 또는 관용적으로 자주 쓰이는 표현이나 단일어 단위로 구분해서 사용할 경우 의미 전달이 불분명해질 수 있는 단어에 대해서는 복합어로 구성하여 사용한다	양성대조군(Positive Control) = 양성(Positive) + 대조군(Control) 계좌번호(Account Number) = 계좌(Account)+번호(Number)
2	• 고유명사(기관명 포함)는 단일어 형태로 사용한다.	See+gene (X) Seegene (O)
3	• 접두사 및 접미사와 합성된 단어는 단일어 형태로 사용한다	재[再]발급 지급처[處] 비[非]활성화
4	• 두 개 이상의 단일어로 이루어졌으나 별도의 영문 단어가 존재하며 각 단일어의 조합과는 다른 의미를 지니게 되는 경우 단일어 형태로 사용한다.	매개변수 (Parameter) ≠ 매개 (Medium) + 변수(Variable) 변화비율(rate) ≠ 변화(Change) + 비율(Proportion) 감가상각(Depreciation) ≠ 감가(Reduction) + 상각(Repayment)
5	• 한글과 외래어가 결합되어 사용되거나 기타 사용 원칙에 부합하지 않더라도 관용적으로 자주 사용되며 의미가 명확한 경우 사용한다. (관용적 표현)	지블록 (gblock) 파레트수량
6	• 유형의 구분을 나타내는 복합 단어는 단어로 식별하지 않도록 한다. 이때에는 유형을 대표하는 다른 단어 또는 용어로 대체하도록 한다. 단, 관용적으로 자주 쓰이는 표현이면서 대체 단어 또는 용어 구성이 어렵다면 사용을 허용한다.	제품유형(X) \(\rightarrow\) 제품코드(O) 계정유형(X) \(\rightarrow\) 계정등급(O)

6.2.6 숫자와 단위 사용 규칙

순번	규칙 및 설명	예시
1	• 숫자 사용 시 아라비아 숫자 사용을 원칙으로 한다	삼순위(X) \(\rightarrow\) 3순위(O)
2	• 숫자만으로는 단어가 될 수 없고 해당 숫자의 의미를 나타내는 단어와 함께 조합하여 사용한다	6(X) \(\rightarrow\) 6개월(O)
3	• 숫자와 단위의 합성어는 단일어로 등록한다	100퍼센트, 91일
4	• 모든 단위는 US Customary system이 아닌 SI 단위계(Système International d’Unités, 국제단위계) 또는 Metric System을 기본으로 한다.	inch(X) \(\rightarrow\) cm(O) ft(X) \(\rightarrow\) m(O) oz(X) \(\rightarrow\) g(O) lb(X) \(\rightarrow\) kg(O)
5	• 단위 앞에 올 수 있는 숫자의 유효값이 제한적인 경우 유효한 단어를 모두 등록한다.	1월, 2월 ~ 12월 1분기, 2분기, 3분기, 4분기 1순위, 2순위, 3순위
6	• 단위 앞에 올 수 있는 숫자의 유효값이나 범위가 제한이 없는 경우 해당 단위를 등록하고 최소 1단위와 합성된 단어를 등록한다	퍼센트 - 1퍼센트 개월 -1개월 차 - 1차 급 - 1급
7	• 숫자 단위 대에 따라 표준을 다르게 정의할 경우 각각을 단어로 등록할 수 있다	1원, 1십원, 1천원, 1만원, 1십만원, 1백만원, 1천만원
8	• 숫자와 조합된 단어의 의미가 불분명한 경우는 해당 단어의 사용을 지양한다 단, 의미가 불분명한 단어임에도 업무상의 필요로 인해 등록이 불가피한 경우 단어 뒤에 숫자를 붙여서 정의한다	컬럼1(X) ※ 단 불가피한 경우 사용

6.2.7 동음이의어 및 이음동의어 사용 규칙

순번	규칙 및 설명	예시
1	• 동음이의어(Homonym)는 허용하지 않는다 - (대체방안1) 다른 한글단어로 교체하여 표준 단어로 등록하여 사용한다. - (대체방안2) 어감상 동음이의어인데도 불구하고 ’의사’라는 단어를 꼭 써야 하는 경우는 ’의사결정’식의 복합 단어를 표준단어로 등록하여 사용한다 • 단, 대체 단어가 없는 경우 사용할 수 있다 (한글 명이 같더라도 영문 명은 반드시 달라야 한다) 이 경우 데이터 표준관리자 및 모델관리자에게 검토 요청을 신청 한다	설명(explanation) : 설명 설명(description) : 상세설명 설명(comment) : 코멘트 다리(leg) : 다리 다리(bridge) : 교량 의사(doctor) : 의사 의사(idea)결정(Decision):의사결정
2	• 이음동의어(Synonym)는 용어의 혼돈과 용어생성 시 중복발생 가능성 때문에 가급적 사용하지 않는다. • 대표단어를 정하고, 그 대표 단어만을 사용하도록 하며 나머지는 금칙어로 등록하여 사용을 제한하도록 한다 • 단어명에 해당되는 모든 비표준어는 금칙어로 등록한다.	핸드폰(X), 셀폰(X), 폰(X), 핸폰(X), 핸펀(X) \(\rightarrow\) 휴대폰(O) ※ 핸드폰(X), 셀폰(X), 폰(X), 핸폰(X), 핸펀(X)은 금칙어로 등록 로그인ID, 로그인명, 로그인이름, 어카운트 (X) \(\rightarrow\) 계정(Account) (O) ※ 로그인ID, 로그인명, 로그인이름, 어카운트 (X)는 금칙어로 등록

6.2.8 금칙어 사용 규칙

순번	규칙 및 설명	예시
1	• 이음동의어는 대표 단어만을 표준단어로 정의하여 사용하도록 하며, 나머지 이음 동의어의 단어들은 금칙어로 정의하여 사용을 사전에 방지한다.	나이(X) \(\rightarrow\) 연령(O) 금일(X) \(\rightarrow\) 당일(O)
2	• 축약된 형태의 단어(축약어)는 금칙어로 정의하여 사용을 사전에 방지한다.	주민번호(X) \(\rightarrow\) 주민등록번호(O)
3	• 사람에 해당하는 접미사 “자”와 “인”으로 구성된 복합어의 경우에는 사용빈도가 높은 단어를 표준단어로 정의하고, 다른 나머지 단어를 금칙어로 관리하여 사용을 사전에 방지한다	장애자(X) \(\rightarrow\) 장애인(O) 신청인(X) \(\rightarrow\) 신청자(O)
4	• 한글 맞춤법을 고려하지 않고 관용적으로 사용되던 단어들은 금칙어로 정의하여 사용을 사전에 방지한다.	갯수(X) \(\rightarrow\) 개수(O) 써비스(X) \(\rightarrow\) 서비스(O)
5	• 영문 단어의 경우 한글화를 원칙으로 한다. 단, 한글 단어 보다 더 친숙하게 사용되는 영문 단어의 경우에는 그 영문 단어를 사용한다. 이렇게 선정된 단어에 대응되는 영문 혹은 한글 단어는 금칙어로 등록하고 사용을 제한하도록 한다	ERROR(X) \(\rightarrow\) 에러(O) FAX(X) \(\rightarrow\) 팩스(O) EMAIL(X) \(\rightarrow\) 이메일(O) 아이피(X) \(\rightarrow\) IP(O)
6	• 범용적으로 사용되는 외래어의 경우 사용할 수 있지만 표기법을 고려하여 표준 단어를 지정하고, 나머지 단어는 금칙어로 등록하여 사용을 제한하도록 한다	EXPOSURE(X), 익스포저(X) \(\rightarrow\) 익스포져(O), 화일(X), FILE(X) \(\rightarrow\) 파일(O)
7	• 전문 업무용어 중 관용적으로 영문의 두문자어(頭文字語:Acronyms)를 사용하는 경우 한글단어는 금칙어로 정의한다.	디엔에이 \(\rightarrow\) DNA(O) 피씨알 \(\rightarrow\) PCR(O) 자주하는질문(X) \(\rightarrow\) FAQ(O)
8	• 기관명 등이나 고유명사 등은 전체 단어를 표준으로 사용하고, 한글 약어는 금칙어로 등록한다.	진시연(X) \(\rightarrow\) 진단시약연구소(O) 질본(X) \(\rightarrow\) 질병관리본부(O)
9	• 시스템명 중 관용적으로 영문의 두문자어(頭文字語:Acronyms)를 사용하는 경우 한글단어는 금칙어로 정의한다	데이터웨어하우스(X) \(\rightarrow\) DW(O)

7 표준 도메인 사전

• 표준 도메인 사전(Standard Domain Dictionary)은 데이터의 성격과 형식을 분류하고, 동일한 속성에 대해 일관된 데이터 관리 기준을 제공하는 체계적인 목록이다.
• 데이터 표준화를 통해 속성(컬럼)의 의미, 유효한 데이터 범위, 데이터 타입 및 길이를 명확히 정의하고, 데이터 모델에서 일관성을 유지할 수 있도록 한다.

7.1 목적

• 동일한 형식을 가진 데이터에 대해서 같은 도메인을 적용함으로써 속성의 의미 및 유효한 데이터 범위를 명확히 할 수 있고, 칼럼에 대한 일관적인 관리가 가능하다.
• 동일한 도메인을 사용하는 칼럼의 속성 성격을 변경하고자 할 때 도메인만을 변경함으로써 데이터 타입 및 길이를 동시에 부여하여 변경할 수 있다.

7.2 표준 도메인의 정의

• 비즈니스적으로 의미 있고 데이터의 성격을 분류한 것으로 동일한 형식을 가진 집합을 도메인이라 하며, 하나의 용어에 하나의 도메인만을 지정한다.
• 동일한 형식을 가진 데이터에 대해서 같은 도메인을 적용함으로써 속성의 의미 및 데이터의 범위를 명확히 할 수 있고 컬럼에 대한 일관적인 관리가 가능하다.
  • 데이터의 형식, 길이, 허용 가능한 값의 범위 등을 명시
• 표준 단어 조합의 마지막에 위치하는 분류(도메인성) 단어가 도메인의 후보가 된다.
• 예시
  • 표준 단어 (주제어): 소모품
  • 표준 단어 (수식어): 구입
  • 표준 단어 (분류단어): 금액
  • 표준 용어: 소모품구입금액
  • 메타데이터 (속성명): 소모품구입금액 with datatype = NUMBER(13)
  • 도메인: 금액

7.3 표준 도메인 사전 원칙

• 일관성과 표준화
  • 데이터 표준 도메인은 비즈니스적으로 의미 있고 동일한 형식을 가진 데이터 집합을 체계적으로 관리하기 위한 기준이다.
  • 동일한 속성 유형에는 일관된 도메인을 적용하여 데이터 품질과 재사용성을 높이고, 중복을 방지한다.
• 정합성과 무결성
  • 하나의 용어는 하나의 도메인만 지정하여 중복을 방지하고, 속성의 형식과 길이, 유효값 범위를 명확히 정의함으로써 데이터 품질을 보장한다.
  • 도메인은 업무적·기술적 요구사항을 동시에 충족해야 하며, 데이터 형식, 길이, 허용값 등을 명확히 규정해야 한다.
  • 허용된 값의 범위를 명확히 정의하여 데이터 무결성을 보장하고, 변경 시 정합성을 유지해야 한다.
• 유연성과 확장성
  • 도메인은 도메인 그룹, 도메인, 인포타입, DBMS별 데이터 타입의 계층 구조로 체계화되어 효율적인 변경 관리가 가능하다.
  • 새로운 데이터 요구사항에 유연하게 대응할 수 있도록 설계하며, 시스템 변경에도 쉽게 확장될 수 있어야 한다.
• 관리와 유지보수
  • 도메인은 지속적으로 관리·개선되며, 명명 규칙과 데이터 타입을 전사적으로 표준화해야 한다.
  • 변경 이력을 추적하여 체계적인 데이터 품질 관리와 유지보수를 보장한다.

7.3.1 도메인의 데이터 타입 분류 체계

• 도메인은 데이터베이스에서 속성이나 컬럼이 가질 수 있는 데이터 타입을 정의한다.
• 데이터를 다루는 전문 분야(SW개발, Data Engineering, 수학, 통계, 머신러닝, 역학 등)마다 용어와 데이터 타입에 차이가 있다.
  • 예를 들어, 데이터베이스의 ’속성(Attribute)’을 수학과 통계학에서는 ’변수(Variable)’라고 부른다.
  • 하지만, 이러한 용어의 차이는 실제 데이터 타입의 특성에는 영향을 주지 않는다.
• 본 표준화 원칙의 데이터 타입은 ISO SQL 표준과 관계형 모델의 창시자 에드거 F. 코드(Edgar F. Codd)의 이론을 참고하여 분류한다.
• 도메인의 인포타입과 DBMS별 데이터 타입은 아래의 분류 체계를 따른다.
  • 숫자형 데이터 타입
    • 정수형: INTEGER, SMALLINT, BIGINT
    • 실수형: FLOAT, REAL, DOUBLE PRECISION, DECIMAL(또는 NUMERIC)
  • 문자형 데이터 타입
    • 고정 길이: CHAR(n)
    • 가변 길이: VARCHAR(n), TEXT, CLOB(Character Large Object)
  • 날짜/시간 데이터 타입
    • 날짜: DATE
    • 시간: TIME
    • 타임스탬프: TIMESTAMP, INTERVAL
  • 이진 데이터 타입
    • 이진 문자열: BINARY, VARBINARY
    • 대용량 이진: BLOB(Binary Large Object)
  • 불리언 데이터 타입
    • 논리값: BOOLEAN (TRUE/FALSE)
  • 집합 데이터 타입
    • 구조형(Structured) 타입
      • ROW 타입: 여러 필드를 포함하는 복합 구조
      • 사용자 정의 타입(UDT): CREATE TYPE 문으로 정의
    • 중첩 타입
      • 배열(ARRAY): 동일한 타입의 요소 모음
      • XML: XML 문서 및 조각 저장
      • JSON 데이터 타입
    • RDBMS(관계형 데이터베이스 관리 시스템)에서는 이러한 다차원 구조 데이터를 네이티브 형태로 직접 저장하는 것은 일반적이지 않다. 관계형 데이터베이스의 기본 원칙은 데이터를 2차원 테이블(행과 열)로 저장하는 것이기 때문이다. 다차원 데이터는 주로 BLOB, JSON, 또는 특수 확장 기능을 통해 저장된다. 단, 기존 데이터베이스에서 이미 다차원 구조 데이터를 저장하고 있는 경우, 이를 그대로 유지하고자 하는 경우 이를 유지할 수 있다.
  • 참조 타입
    • REF: 다른 객체를 참조하는 타입
  • 특수 데이터 타입
    • 공간 데이터 타입
      • POINT, LINESTRING, POLYGON 등 지리정보 데이터 타입
        
    • 네트워크 데이터 타입
      • INET, CIDR, MAC: 네트워크 주소 저장

7.3.2 표준 도메인 유형

• 표준 도메인 유형
  • 범위형 (Range) 도메인
    • 보통 numeric (수치형)과 string (문자열) 데이터를 표현하기 위한 도메인으로 속성(컬럼)에 허용되는 데이터 값을 데이터의 유형과 길이로 그 범위를 제한하며, DBMS에서 지원하는 기본 데이터 타입과 매핑된다.
      
  • 열거형 (Enumeration) 도메인
    • categorical (범주형) 데이터를 표현하기 위한 도메인으로 속성(컬럼)에 허용되는 데이터 값을 사전에 정의된 값들 중 하나만 선택 가능하므로 정의된 범위 내에서 구체적으로 열거 또는 목록화하여 범위를 제한
  • 예시

  도메인 유형	도메인 그룹	정의	도메인 예시	데이터 타입
  범위형 도메인	날짜	• 특정 사건이 일어난 시점 또는 시점과 시점 간의 정해진 기간을 표현하기 위한 도메인	일자, 일시, 연도, 연월, 월, 일, 시각, 시분, 분기, 반기 등	DATE, DATETIME, TIMESTAMP, YEAR, etc.
  범위형 도메인	명칭	• 문자 형식으로 객체에 대한 식별을 표현하기 위한 도메인	명, 성명, 영문성명, 주소, 우편번호주소, 상세주소, 이메일주소 등	VARCHAR(N), CHAR(N), TEXT
  범위형 도메인	내용	• 서술 형식의 상세 내용을 자유 형식의 텍스트로 표현하기 위한 도메인	내용	TEXT, CLOB (Character Large Object)
  범위형 도메인	수	• 객체의 개수나 양을 수로써 표현하기 위한 도메인 • 일반적인 측량 단위도 포함됨	수, 일수, 개월 수, 매수, 좌수, 건수, 양, 평점, 연령, 면적, 평형 등	INT, BIGINT, DECIMAL(p, s), FLOAT, NUMERIC
  범위형 도메인	율	• 비율을 수로 표현하기 위한 도메인	율, 이율, 이자율, 지분율, 할인율 등	DECIMAL(p, s), FLOAT, NUMERIC
  범위형 도메인	번호	• 각 자리별 특정 의미를 가지거나 체계를 가지고 관리되어야 하는 속성을 정의하기 위한 도메인 • 용어별 고유의 번호 도메인을 부여	전사고객번호, 실험번호, 직원번호, 주문번호, 법인등록번호, 일련번호 등	VARCHAR(N), CHAR(N), BIGINT, UUID
  열거형 도메인	코드	• 코드화하여 관리되는 속성을 정의하기 위한 도메인	부서코드, 과제상태코드 등	VARCHAR(N), CHAR(N), ENUM, SMALLINT
  열거형 도메인	분류	• 상반된 상태의 값을 갖는 속성을 정의하기 위한 도메인	여부, 유무	BOOLEAN, CHAR(1), TINYINT(1) (1: Yes, 0: No)
  열거형 도메인	상태	• 프로세스나 객체의 현재 상태를 나타내기 위한 도메인	처리상태, 승인상태, 계정상태	VARCHAR(N), CHAR(N), ENUM, SMALLINT
  열거형 도메인	등급	• 객체나 서비스의 품질, 중요도, 우선순위 등의 등급을 표현하기 위한 도메인	회원등급, 신용등급, 상품등급, 우선순위	VARCHAR(N), CHAR(N), ENUM, SMALLINT

7.4 표준 도메인 사전의 구성 요소

표준 도메인 사전은 도메인 그룹, 도메인, 인포타입, 예시로 구성된다.

• [도메인그룹]
  • 도메인 그룹(Domain Group)은 성격이 유사한 도메인들을 그룹화해서 관리하는 관리 단위
  • 예를 들면, 금액, 날짜, 내용, 율 등의 도메인 그룹이 존재
    • 금액 도메인 그룹의 하위 도메인: 금액, 외화금액, 세액 등의 도메인이 존재
• [도메인]
  • 도메인(Domain): 데이터 값의 범위를 컬럼(속성)의 특성에 따라 분류한 것
  • 업무적으로 또는 비즈니스적으로 의미가 있는 도메인명을 부여해야 하며, 표준단어를 사용하여 명명
• [인포타입]
  • 인포타입(Info Type): Information Type의 약어
  • 해당 도메인에서 사용할 수 있는 데이터 타입과 길이가 결합된 형태로 속성이 가질 수 있는 데이터 타입과 길이를 나타낸다.
  • 생성규칙
    • 일반 데이터 타입: [도메인][데이터 타입 약어][길이]
      • [데이터 타입 약어] 부분 Acronyms 적용: 단일어의 경우 한 글자, 복합어의 경우 첫 글자씩만 사용
        • VARCHAR(50) \(\rightarrow\) VC50
        • NUMBER(10,2) \(\rightarrow\) N10,2
        • BINARY(16) \(\rightarrow\) B16
        • TEXT \(\rightarrow\) T
        • DATETIME \(\rightarrow\) DT
          
        • UUID \(\rightarrow\) U
          
      • [길이] 표기 규칙
        • 단일 길이: 숫자로 표기 (예: VC10)
        • 소수점 포함: 콤마로 구분 (예: N5,2 \(\rightarrow\) 5자리 숫자에 소수점 2자리가 포함됨)
        • 길이 없는 경우: 길이 제한이 없는 타입(TEXT, JSON, CLOB 등)은 생략 (예: T for TEXT)
    • 집합 데이터 타입: [도메인][집합 데이터 타입 약어][데이터 타입 약어][길이][N차원 집합 요소 수]
      • [집합 데이터 타입 약어]
        • A: Array (배열), 고정된 크기와 동일한 데이터 타입 요소들을 연속된 메모리에 저장
        • S: Set (집합), 중복 없는 요소들의 모음
        • J: JSON, {“key”: “value”}
        • X: XML, 값
          
    • 예시
      • 성명VC50: 성명 도메인의 VARCHAR(50) - 홍길동
      • 금액N12,2: 금액 도메인의 NUMBER(12,2) - 1234567890.12
      • 비밀번호B16: 비밀번호 도메인의 BINARY(16) - 0xA57C4F92E8D96F5D479F5B3BE5CF2C82
      • 설명T: 설명 도메인의 TEXT - 동해물과 백두산이 마르고 닳도록
      • 생성일시DT: 생성일시 도메인의 DATETIME - 2021-01-01 12:00:00
      • N5,3 = NUMBER 5,3은 다음을 의미
        • 총 5자리의 숫자를 저장
        • 그중 3자리는 소수점 이하 숫자
        • 결과적으로 소수점 앞에는 2자리의 숫자만 올 수 있다.
        • 예시,
          • 12.345 (유효)
          • 1.234 (유효)
          • 0.123 (유효)
          • 123.45 (무효 - 소수점 이상 자릿수 초과)
          • 1.2345 (무효 - 소수점 이하 자릿수 초과)
      • RFU데이터배열AN17,12[45]: RFU data가 45개의 float(정수부5자리,소수부12자리) 값으로 구성된 1차원 배열 도메인
      • 채널배열AVC50[5]: 채널 데이터가 5개의 VARCHAR(50) 값으로 구성된 1차원 배열 도메인
      • 장비이미지배열AN10,5[128,128,3]: 픽셀값이 128x128x3의 float(정수부5자리,소수부5자리) 값으로 구성된 3차원 배열 도메인
      • 시그모이드계수JSONJ[N10,5][4]: 시그모이드 계수 4 종류의 float(정수부5자리,소수부5자리) 값이 key-value 형식으로 구성된 1차원 JSON 형식. 단, 중첩 구조일 경우 [N차원 집합 요소 수]를 생략한다.
• [DBMS]
  • DBMS(Database Management System)는 데이터를 저장, 관리, 검색, 수정할 수 있도록 지원하는 소프트웨어 시스템으로, 대표적으로 Oracle, MySQL, PostgreSQL 등이 있다.
• [데이터타입]
  • 데이터타입(Data Type)은 DBMS에서 데이터가 저장되는 방식과 형식을 정의하는 속성으로 다양한 유형들이 존재한다.
• [길이]
  • 길이(Length)는 데이터 타입이 허용하는 최대 저장 크기를 의미. 예를 들어, VARCHAR(50)은 최대 50자의 문자열을 저장할 수 있음을 나타낸다.
  • 길이 제한이 없는 타입(TEXT, CLOB, JSON 등)은 ’NA’로 표기한다.
• [유효값범위]
  • 유효값범위(Valid Value Range)는 해당 도메인이 허용하는 값의 범위를 의미한다.
  • 숫자형: 최소값-최대값 (예: 0-100, 1-999)
  • 문자형: 패턴 또는 형식 (예: 영문+숫자, YYYY-MM-DD)
  • 코드형: 허용되는 코드 목록 (예: Y/N, 1/2/3)
• 예시
  • 예시(Example)는 해당 도메인이 실제로 어떻게 사용되는지를 보여주는 구체적인 사례를 의미한다.
    
  • 예시
    • “실험시작일시”에서 “일시”는 날짜 도메인 그룹의 일시 도메인 적용
    • “시약제품명”에서 “제품명”은 명 도메인 그룹의 제품명 도메인 적용
    • “실험단계설명”에서 “설명”은 내용 도메인 그룹의 설명 도메인 적용 >주의) DBMS별 데이터 타입 (Data Type)
      >DBMS 종류에 따라 다양한 제약 사항이 존재하기 때문에 데이터베이스를 설계할 DBMS의 특성도 반영해야 한다.
• 표준 도메인 사전 예시

도메인그룹	도메인	인포타입	DBMS	데이터 타입	길이	유효값범위	예시
날짜	일시	일시VC16	MySQL	VARCHAR	16	YYYYMMDDHHMMSS	실험시작일시
날짜	년월	년월VC6	MySQL	VARCHAR	6	YYYYMM (000001-999912)	생산년월
명	성명	성명VC10	MySQL	VARCHAR	10	한글/영문 문자	실험자성명
명	제품명	제품명VC50	MySQL	VARCHAR	50	제품 명칭	시약제품명
내용	설명	설명T	MySQL	TEXT	NA	자유 텍스트	실험단계설명
내용	비고	비고T	MySQL	TEXT	NA	자유 텍스트	실험비고
값	측정값	측정값N10,2	MySQL	DECIMAL	10,2	실수값	농도측정값
값	항목값	항목값VC100	MySQL	VARCHAR	100	항목별 적용	옵션항목값
수	건수	건수N10	MySQL	INTEGER	10	0 이상 정수	실험건수
수	개수	개수N10	MySQL	INTEGER	10	0 이상 정수	샘플개수
율	비율	비율N5,3	MySQL	DECIMAL	5,3	0-1 사이 소수	농도비율
율	백분율	백분율N5,2	MySQL	DECIMAL	5,2	0-100 사이 소수	순도백분율
코드	구분코드	구분코드VC5	MySQL	VARCHAR	5	정의된 코드값	소모품유형코드
코드	상태코드	상태코드VC2	MySQL	VARCHAR	2	정의된 코드값	실험상태코드
분류	여부	여부C1	MySQL	CHAR	1	Y/N	완료여부
분류	유무	유무C1	MySQL	CHAR	1	Y/N	오류유무
번호	전화번호	전화번호VC15	MySQL	VARCHAR	15	숫자와 하이픈(-)	연락처전화번호
번호	계좌번호	계좌번호VC20	MySQL	VARCHAR	20	숫자와 하이픈(-)	대금수취계좌번호
식별	UUID	UUIDU	MySQL	CHAR	36	표준 UUID 형식	트랜잭션UUID
식별	고객식별자	고객식별자VC20	MySQL	VARCHAR	20	영문+숫자 조합	거래처고객식별자
보안	비밀번호	비밀번호B64	MySQL	BINARY	64	해시된 값	로그인비밀번호
보안	암호화키	암호화키B32	MySQL	BINARY	32	암호화된 값	데이터암호화키
단위	길이단위	길이단위VC5	MySQL	VARCHAR	5	표준 단위 코드	측정길이단위
단위	무게단위	무게단위VC5	MySQL	VARCHAR	5	표준 단위 코드	시료무게단위

7.5 도메인 그룹

• 도메인 그룹은 성격이 유사한 도메인들을 그룹화해서 관리하는 관리 단위
• 대표적인 도메인 그룹을 아래에 정의하고 그 도메인 그룹에 속할 수 있는 일부 도메인 예시들을 들어 이해를 돕는다.
• 실무에서는 도메인 사전을 통해 아래의 도메인 그룹과 일부 예시들을 참고하여 도메인 그룹과 그 그룹에 속하는 도메인을 정의하고 관리한다.
  • 14개 도메인 그룹: 날짜, 보안, 코드, 분류, 명, 번호, 식별, 내용, 값, 수, 율, 단위, 집합, 일반 단어 도메인 그룹으로 관리한다.

7.5.1 ‘날짜’ 도메인 그룹 규칙

• 날짜 도메인 그룹은 특정 사건이 일어난 시점 또는 시점과 시점 간의 정해진 기간을 표현하기 위한 도메인들을 그룹화하여 관리한다.
• 도메인 일부 예시

도메인명	설명	데이터타입	길이	유효값범위	예시
일	‘DD’ 형식의 도메인명은 일로 정의하여 사용한다	VARCHAR	2	DD (01~31)	25 (실험종료일)
시각	‘HHMMSS’ 형식의 도메인명은 시각으로 정의하여 사용한다	VARCHAR	6	HHMMSS (000000~235959)	143022 (오후 2시 30분 22초)
일자	‘YYYYMMDD’ 형식의 도메인명은 일자로 정의하여 사용한다	VARCHAR	8	YYYYMMDD (00000101~99991231)	20160420 (계약해지일자)
년도	형식의 도메인명은 년도로 정의하여 사용한다	VARCHAR	4	YYYY (0000~9999)	1966 (출생년도), 2016 (기준년도)
년월	‘YYYYMM’ 형식의 도메인명은 년월로 정의하여 사용한다	VARCHAR	6	YYYYMM (000001~999912)	201604 (과제개시년월)
월	‘MM’ 형식의 도메인명은 월로 정의하여 사용한다	VARCHAR	2	MM (01~12)	04 (결산월)
월일	‘MMDD’ 형식의 도메인명은 월일로 정의하여 사용한다	VARCHAR	4	MMDD (0101~1231)	1010 (과제종료월일)
시분	‘HHMM’ 형식의 도메인명은 시분으로 정의하여 사용한다	VARCHAR	4	HHMM (0000~2359)	1430 (오후 2시 30분)
시분초	‘HHMMSS’ 형식의 도메인명은 시분초로 정의하여 사용한다	VARCHAR	6	HHMMSS (000000~235959)	143022 (오후 2시 30분 22초)
일시	년월일+시분초 형식의 도메인명은 일시로 정의하여 사용한다.	DATETIME 또는 VARCHAR	14	YYYYMMDDHHMMSS (00000101000000~99991231235959)	20160420143022 (과제종료일시)
타임스탬프	‘YYYYMMDDHHMMSS.FFF’ 형식의 도메인명은 타임스탬프로 정의하며 시스템 로그일시를 표시하기 위해 사용한다.	TIMESTAMP	-	YYYYMMDDHHMMSS.FFF (00000101000000.000~99991231235959.999)	20160420143022.123 (2016년 4월 20일 오후 2시 30분 22초 123밀리초)

7.5.2 보안 도메인 그룹 규칙

• 보안 도메인 그룹은 시스템 보안, 인증, 암호화와 관련된 속성들을 그룹화하여 관리한다.
• 핵심 특성
  • 보안성 - 암호화 저장 필수, 마스킹 처리 필요
  • 규제성 - 보안정책 적용 대상
  • 주기성 - 정기적인 변경 요구사항 존재
  • 복잡성 - 복잡도 규칙 적용 (문자, 숫자, 특수문자 조합 등)
  • 비노출성 - 로그, 화면 등에서 원문 노출 제한
  • 검증성 - 규칙 기반 유효성 검증 필요
• 보안 도메인 구성 규칙:
  1. 원문 저장 금지 - 항상 암호화/해시 처리하여 저장
  2. 접근 제한 - 필요한 시스템/사용자만 접근 가능
  3. 변경 관리 - 이력 관리 및 주기적 갱신 체계 구축
  4. 복잡성 정책 - 보안 강도에 따른 명확한 정책 적용
  5. 안전한 전송 - 네트워크상 전송 시 암호화 필수
• 도메인 일부 예시:

도메인명	설명	데이터타입	보안 특성	예시
비밀번호	사용자 인증용 비밀 문자열	VARCHAR(128)	• 해시 저장(SHA-256 이상) • 90일 주기 변경 • 영문/숫자/특수문자 조합 • 최소 8자 이상	(암호화 저장)
인증토큰	시스템 간 인증용 보안 토큰	VARCHAR(1024)	• 암호화 저장 • 최대 24시간 유효 • 무작위 생성 • 1회용	eyJhbGciOiJIUzI…
API키	외부 시스템 연동용 키	VARCHAR(64)	• 암호화 저장 • 주기적 갱신 • 접근 권한 제한 • 사용 내역 기록	sk_live_34a1c2b…
암호화키	데이터 암호화용 키	VARCHAR(256)	• HSM(Hardware Security Module) 저장 • 주기적 갱신 • 키 분할 관리 • 사용 내역 기록	(이중 암호화 저장)
PIN번호	간편 인증용 숫자 조합	VARCHAR(8)	• 해시 저장 • 5회 오류 시 잠금 • 숫자만 사용 • 생체인증 병행	(암호화 저장)
개인식별정보	개인 식별 가능 정보	VARCHAR(가변)	• 암호화 저장 • 부분 마스킹 표시 • 접근 권한 제한 • 처리 내역 기록	홍*동, 010-****-1234
생체인증정보	생체 기반 인증 데이터	BLOB	• 템플릿만 저장 • 원본 저장 금지 • 고급 암호화 • 대체 인증 필수	(암호화 템플릿)
보안질문답변	계정 복구용 질문 답변	VARCHAR(100)	• 해시 저장 • 다중 질문 필수 • 추가 인증 병행 • 시도 제한	(암호화 저장)
접근제어토큰	권한 부여 및 접근 제어용	VARCHAR(2048)	• JWT(JSON Web Token) 형식 • 제한된 유효기간 • 권한 범위 명시 • 서명 검증	eyJhbGciOiJSUzI…

7.5.3 ‘코드’ 도메인 그룹 규칙

• 코드 도메인 그룹은 특정 도메인 값(코드값)과 이 값에 대한 의미(코드값명)를 표현하기 위해 코드 도메인을 그룹화하여 표준코드로 분류하여 별도로 관리한다.
• 핵심 특성:
  • 분류 목적 - 항목의 유형이나 범주를 나타냄
  • 정형성 - 고정된 길이와 형식을 가짐 (20자 이하 권장)
  • 참조성 - 항상 코드값-코드값명 쌍으로 존재
  • 안정성 - 생성 후 변경이 적음
  • 재사용성 - 여러 시스템과 업무에서 공통으로 사용
• 코드 도메인 구성 원칙:
  1. 문자 중심 - 영문자나 의미 있는 문자로 구성 (숫자만으로 구성되지 않음)
  2. 계층성 - 상위 개념에서 하위 개념으로 세분화 가능 (예: 지역코드)
  3. 그룹화 - 동일 유형의 항목들의 묶음으로 존재 (예: 부서코드 그룹)
  4. 고정성 - 새로운 유형이 추가되지 않는 한 변경되지 않음
• 코드 생성 규칙:
  1. 프리픽스는 의미를 가진 영문자 사용 (10자 이하 권장)
  2. 숫자 부분은 일반적으로 순차적이나 의미를 포함할 수 있음
  3. 길이는 일관성 있게 유지 (예: 부서코드는 항상 5자리)
  4. 구분자(-) 사용
• 도메인 일부 예시

도메인	설명	예시	데이터 타입	형식	값 의미
코드	• 코드값을 가지는 속성은 반드시 ‘코드’를 도메인으로 정의하여 사용한다. • 속성명은 해당 속성이 사용하는 코드 도메인명과 일치시키는 것을 원칙으로 하나, 속성명에 수식어를 붙여서 사용할 수 있다. • 코드의 의미가 ’여부’ 또는 ’유무’인 경우 ’코드’를 도메인으로 사용할 수 없고, ’여부/유무’를 도메인으로 정의하여 사용한다. • 코드 도메인은 ’수식어 + 코드유형수식어 + 코드’로 명명한다.	거래코드 수신거래코드 상품코드	VARCHAR, CHAR	-	-
부서코드	조직 내 부서 분류용 코드	HR01, MK02, FN03	VARCHAR, CHAR	영문2자+숫자2자	HR: 인사, MK: 마케팅, FN: 재무
제품코드	제품 카테고리 분류용 코드	ELEC001, FOOD001	VARCHAR, CHAR	영문4자+숫자3자	ELEC: 전자제품, FOOD: 식품
직급코드	직원 직급 분류용 코드	S01, M02, J03	VARCHAR, CHAR	영문1자+숫자2자	S: 수석, M: 중간, J: 주니어
고객지역코드	고객구역 분류용 코드	A0101, B0201	VARCHAR, CHAR	영문1자+숫자2자+숫자2자	A01: 미국, A0101: 뉴욕주

7.5.4 ‘분류’ 도메인 그룹 규칙

• 분류 도메인 그룹은 코드의 하위 그룹으로 코드값이 binary 또는 이진분류 특성을 가지는 도메인들을 그룹화하여 관리한다.
  
• 도메인 일부 예시

도메인	설명	허용값	비고
여부	• 특정 사실이나 행위의 ‘그러함/그러하지 아니함’을 의미 • 인스턴스는 반드시 ’Y’ 또는 ’N’만 허용	Y/N	NULL, N/A, SPACE 등 불가
유무	• 존재, 소유, 또는 특정 사실이나 행위의 ‘있음/없음’을 의미 • 인스턴스는 반드시 ’Y’ 또는 ’N’만 허용	Y/N	NULL, N/A, SPACE 등 불가
여부/유무	Y/N 이외의 값 허용하지 않음	Y/N	• 기타 값 필요 시 코드 도메인으로 분류하여 사용 • 미정의 값은 속성의 인스턴스로 사용 불가 • 미정의 값 표현 시 ’*’ 등 대체값 정의 필수(Not Null) • 단, 대외 인터페이스 테이블의 경우 업무 특성에 따라 Null 예외 허용 가능

7.5.5 ‘명’ 도메인 그룹 규칙

• 명 도메인 그룹은 객체(사람 또는 사물)에 대한 이름의 식별을 표현하기 위한 도메인들을 그룹화하여 관리한다.
• 주요 특징:
  • 사람이 읽고 이해하며 부르기 위한 목적으로 사용
  • 자연어로 된 이름/명칭을 주로 사용
  • 객체의 식별 목적이지만 언어적, 텍스트적 표현에 중점
  • 형식이나 패턴에 대한 제약이 적음
  • 중복이 발생할 수 있음
• 도메인 일부 예시

도메인	설명	예시	데이터 타입
명	• 사람을 제외한 상품, 사물 등 모든 명칭을 식별하기 위해 ‘명’ 도메인을 사용한다. • 단독으로 사용하지 않고 표준 단어 사전 또는 표준 국어 대사전을 참조하여 복합어로 생성한다. • ‘명’ 도메인을 속성(컬럼)에 사용할 때, 만약 그 앞에 ‘한글’, ‘영문’, ‘한자’, ‘약어’ 등과 같은 수식어가 없는 경우에는, 그것은 ’한글명’을 의미하는 것으로 간주한다.	상품명(한글), 종목명(한글), 종목영문명(영문), 한자고객명(한자)	VARCHAR, CHAR, TEXT
성명	사람의 성명을 관리할 경우 ’성명’이라는 도메인을 사용한다.	고객영문성명	VARCHAR, CHAR, TEXT
주소	사람이 살고 있는 곳이나 기관, 회사 등이 자리 잡고 있는 곳을 행정 구역으로 나타낸 이름은 ‘주소’ 도메인을 사용한다.	직장주소	VARCHAR, CHAR, TEXT

7.5.6 ‘번호’ 도메인 그룹 규칙

• 번호 도메인 그룹은 순수한 숫자로만 구성된 식별 체계를 관리한다.
• 번호 도메인의 공통 도메인은 생성하지 않는다.
• 핵심 특성:
  • 숫자 전용 - 숫자로만 구성 (영문자 없음)
  • 고유성 - 중복 불가 및 범위내에서 유일함
  • 순차성 - 일반적으로 순차적으로 증가할 수 있음
  • 수치성 - 숫자로서의 의미를 가질 수 있음 (산술 연산 가능)
  • 패턴성 - 자릿수별 특정 의미를 가질 수 있음
  • 표준성 - 많은 경우 외부 표준을 따름
• 번호 도메인 구성 원칙:
  1. 순수 숫자만 사용 - 영문자나 특수문자 사용 불가
  2. 고정 길이 - 대부분 정해진 자릿수를 가짐
  3. 유효성 - 자체 검증 알고리즘이 존재하는 경우 많음 (예: 주민등록번호)
  4. 구분자(-) 사용 가능하나 데이터 저장 시 제외 가능
• 번호 생성 규칙:
  1. 순차 번호는 일정 범위 내에서 중복 없이 부여
  2. 표준 번호는 해당 표준의 생성 규칙을 준수
  3. 확장성을 고려하여 충분한 자릿수 확보
  4. 숫자만으로 구성되어야 함
• 도메인 일부 예시

도메인명	설명	데이터 타입	길이	유효값 범위	예시
번호	• 객체를 식별하기 위한 고유 식별자 • 단독 사용 불가, 반드시 복합어로 생성 • 명확한 대상 표현 필수	VARCHAR 또는 INTEGER	가변적	대상별 상이	서열일련번호: 12345 계좌번호: 110-352-123456 데이터처리번호: 202312001
일련번호	• 순차적으로 부여되는 식별자 • 특정 집합 내 순서 표현	INTEGER	가변적	숫자	1234567, 0000123
계좌번호	• 금융기관 계좌 식별 번호 • 금융 기관에 예금하려고 설정한 개인명이나 법인명의 계좌에 부여된 번호	VARCHAR	14-20	금융기관별 규칙	입금계좌번호: 110-435-123456 가상계좌번호: 123-4567-89012345
전화번호	• 통신망 연결용 번호 • 가입된 전화마다 매겨져 있는 일정한 번호	VARCHAR	10-20	국가/통신사 규칙	휴대전화번호: 010-1234-5678 팩스번호: 02-1234-5678
주민등록번호	• 주민등록법상 고유 식별번호 • 주민등록을 할 때에, 국가에서 국민에게 부여하는 고유 번호	VARCHAR	13	XXXXXX-XXXXXXX	911201-1234567
사업자등록번호	• 세무서 발급 사업자 식별번호 • 세무에서, 신규로 개업하는 사업자에게 부여하는 사업체의 고유번호	VARCHAR	10	XXX-XX-XXXXX	123-45-67890
법인등록번호	• 사무소의 소재지에서 설립등기를 함으로써 성립하는데 이때 부여된 일련번호	VARCHAR	13	XXXXXX-XXXXXXX	123456-1234567
외국인등록번호	• 국내 체류 외국인에게 부여되는 고유 식별번호	VARCHAR	13	XXXXXX-XXXXXXX	123456-5234567
우편번호	• 우편물을 쉽게 분류하기 위하여 정보 통신부에서 각 지역마다 매긴 번호	VARCHAR	5-6	국가별 규칙	우편번호: 06234

7.5.7 ‘식별’ 도메인 그룹 규칙

• 식별 도메인 그룹은 객체를 고유하게 식별하는 다양한 형태의 식별자를 관리한다.
• 식별 도메인 그룹 공통 특성:
  • 고유성 - 중복 불가 및 범위내에서 유일함
  • 불변성 - 생성 후 변경 불가
  • 참조성 - 다른 객체에서 참조됨
  • 식별성 - 단일 객체 지정 가능
• 구조화된 업무 식별자
  • 의미 있는 prefix + 구분자 + 식별부의 복합 구조로 업무적 의미와 추적성을 포함
  • 예: CS-0000123456, OR-20231201-0001
• 식별 도메인 유형
  • 기술 식별자
    • 해시, UUID 등 기술적으로 생성된 식별자
    • 의미 없는 고유 문자열
    • 예: 550e8400-e29b-41d4-a716-446655440000, 7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069
  • 로그인 식별자
    • 시스템 접근 및 로그인용 식별자
    • 사용자 기억성 고려
    • 예: user123, hkd123
• 도메인 일부 예시

도메인명	설명	데이터 타입	길이	유효값 범위	예시
업무식별자	• 업무 객체 식별을 위한 구조화된 식별자	VARCHAR	가변적	프리픽스+식별부	CS-0000123456
UUID	• 범용 고유 식별자	VARCHAR	32	32자리 16진수+하이픈	550e8400-e29b-41d4-a716-446655440000
해시ID	• 해시 알고리즘 기반 식별자	VARCHAR	가변적	알고리즘별 고정 길이	7f83b1657ff1fc53b92dc18…
사용자ID	• 시스템 로그인용 식별자	VARCHAR	5-50	영숫자	user123, admin_sys
이메일	• 이메일 형식의 로그인 식별자	VARCHAR	가변적	이메일 형식	john.doe@example.com
ID	• 시스템 오브젝트 등을 식별하기 위해 사용되는 도메인으로서 체계 없이 순차적으로 체번하여 사용하는 일련번호와는 구별하여 사용한다	VARCHAR	가변적	사용자ID	user123
여권번호	• 외국을 여행하는 사람의 신분이나 국적을 증명하고 상대국에 그 보호를 의뢰하는 문서번호	VARCHAR	9	국가별 규칙	M12345678
주문번호	• 상품/서비스 주문 시 생성되는 고유 식별번호 • 연도+월+일+일련번호 조합	VARCHAR	16	YYYYMMDD+8자리	2023120100000123
고객번호	• 고객 식별을 위한 고유번호 • 고객유형코드+일련번호 조합	VARCHAR	12	영문2자+숫자10자	CS0000123456
거래번호	• 금융거래 식별을 위한 고유번호 • 거래일자+거래구분+일련번호	VARCHAR	20	YYYYMMDD+12자리	20231201TR0000000123
계약번호	• 계약 건별 식별을 위한 고유번호 • 계약유형+연도+일련번호	VARCHAR	15	영문2자+연도2자+11자리	CT230000012345
직원번호	• 조직 내 직원 식별을 위한 고유번호 • 입사연도+부서코드+일련번호	VARCHAR	10	연도2자+부서2자+6자리	23HR000123
회원번호	• 서비스 이용 회원 식별번호 • 회원유형+가입연월+일련번호	VARCHAR	14	영문1자+연월6자+7자리	U202312123456
상품번호	• 상품 식별을 위한 고유번호 • 상품카테고리+제조사+일련번호	VARCHAR	16	영문4자+숫자12자리	ELECLG000000123
문서번호	• 공식 문서 관리를 위한 식별번호 • 부서코드+연도+문서종류+일련번호	VARCHAR	18	부서2자+연도2자+14자리	HR23DOC00000123

7.5.8 보안, 코드, 분류, 명, 번호, 식별 도메인 그룹 선택 시 고려사항

단, 번호 도메인의 특성상 숫자 데이터 타입을 사용해야 하나, 실무에서는 문자와 숫자를 조합한 형태가 많이 사용된다. 따라서, 이 도메인 그룹들끼리 완벽한 구별을 하기 어려울 수 있다. 이러한 혼란을 최소화하기 위해 다음과 같은 그룹핑 기준 가이드를 제시한다.

• 1차 분류 기준: 목적성 분류
  • 명 도메인 그룹: 사람 인식용 (사람이 보고 읽고 이해하며 부를 수 있는 의미있는 명칭)
  • 번호 도메인 그룹: 시스템 식별용 (시스템 내 객체를 고유하게 식별하기 위한 번호) & 순수 숫자로만 구성된 번호
  • 식별 도메인 그룹: 시스템 식별용 (시스템 내 객체를 고유하게 식별하기 위한 번호) & 문자와 숫자의 조합으로 구성된 번호
  • 코드 도메인 그룹: 시스템 식별용 (시스템 내 객체를 고유하게 식별하기 위한 코드) & 다중 분류용
  • 분류 도메인 그룹: 시스템 식별용 (시스템 내 객체를 고유하게 식별하기 위한 코드) & 이진분류용
  • 보안 도메인 그룹: 보안 및 인증용
• 2차 분류 기준: 결정 트리 방식
  • 우선순위 규칙: 보안 > 코드 > 분류 > 명 > 번호 >= 식별
  • 질문 트리 방식
    • Q1: 보안/암호화가 필요한가? → YES: 보안 (예: 비밀번호, 주민등록번호)
    • Q2: 분류/범주화 목적인가? → YES: 코드 (예: well번호, 데이터처리과정)
    • Q3: 다중 분류가 필요한가? → YES: 코드, NO: 분류 (예: well번호, 데이터처리과정)
    • Q4: 사람이 읽고 부르는 개체의 명칭인가? → YES: 명, NO: 식별 (예: 상품명, 고객성명)
    • Q5: 순수 숫자인가? → YES: 번호, NO: 식별 (예: 전화번호, 우편번호)
    • Q6: 문자와 숫자의 조합인가? → YES: 식별, NO: 번호 (예: 부서코드, 상품유형코드)
• 실무 적용 예시
  • 진단키트 정보
    • 제품명: SARS-CoV-2 Kit (명 - 사람이 인식하는 자연어 명칭)
    • 제품코드: SCOV-KIT (코드 - 제품명의 주요 부분에서 추출한 약어)
    • 제품번호: SCOV-KIT-2023-001 (식별 - 제품코드 + 연도 + 일련번호)
  • 의료기관 정보
    • 고객성명: 서울대학교병원 (명 - 고객의 공식 명칭)
    • 환자성별: M (분류 - 고객의 성별)
    • 고객유형코드: SNUMC (코드 - 고객성명의 이니셜(SNU) + 기관유형(MC))
    • 일련번호: 1234567890 (번호 - 순수 숫자 구성의 식별자)
    • 환자주민등록번호: 123456-1234567 (보안 - 보안 정책)
    • 고객번호: SNUMC-1234567890 (식별 - 고객성명 이니셜(SNUMC) + 일련번호)

7.5.9 ‘내용’ 도메인 그룹 규칙

• 내용 도메인 그룹은 자유 형식의 상세 내용을 서술 형식의 텍스트로 표현하기 위한 도메인들을 그룹화하여 관리한다.
• 도메인 일부 예시

도메인	설명	예시	데이터 타입
내용	• 사실이나 사물에 대해 전하고자 하는 정보를 형식 없이 서술형으로 저장하는 경우 사용된다. • “내용” 단일 도메인으로만 정의하여 사용한다. • 즉, “명세”, “설명”, “비고”, “적요”, “내역”, “의견”, “사유”, “사항” 등 유사 도메인은 별도로 정의하지 않고 “내용” 도메인으로 통합 관리한다. • 예: “평가자의견 (X)” → “평가자의견내용 (O)”	사고내용 평가자의견내용 운영비고내용	TEXT, CLOB, VARCHAR(MAX)

7.5.10 ‘값’ 도메인 그룹 규칙

• 값 도메인 그룹은 평가값, 항목값 등 특정 항목이나 속성의 값을 그룹화하여 관리한다.
• 도메인 일부 예시

도메인	설명	예시	데이터 타입
값	• 평가값, 항목값 등 특정 항목이나 속성의 값을 의미하는 경우 사용된다. • ’값’은 단일 단어로 허용하지 않고, 반드시 복합어로 생성한다. • 항상 어떤 항목이나 속성의 ’값’인지 명확히 표현해야 한다. • “값(X)” → “항목값 (O)”, “평가값 (O)”	항목값 입력값 측정값 계산값	VARCHAR, NUMBER, DECIMAL

7.5.11 ‘수’ 도메인 그룹 규칙

• 수 도메인 그룹은 객체의 개수나 양을 수로써 표현하기 위한 도메인들을 그룹화하여 관리한다.
• 도메인 일부 예시

도메인	설명	예시	데이터 타입
수	• 셀 수 있는 사물의 크기를 나타내는 값(복합어로 생성) • 금액을 제외한 정보의 수치 및 합계 등을 정의하는 경우에 사용한다. • 일반적인 수량을 나타낼 때 사용한다. • 구체적인 수량 유형(횟수, 연령, 기간 등)은 해당 도메인을 사용한다.	종업원수 고객수 상품수	INTEGER, DECIMAL
일수	• 일을 기준으로 헤아리는 수. • 시간의 길이를 일(day) 단위로 측정하여 정수로 표현한다. • 일 단위의 기간을 나타내는 경우 사용한다.	연체일수 휴가일수 지연일수	INTEGER, SMALLINT
개월수	• 월을 기준으로 헤아리는 수 • 시간의 길이를 월(month) 단위로 측정하여 정수로 표현한다. • 월 단위의 기간을 나타내는 경우 사용한다.	견적개월수 연장개월수 계약개월수	INTEGER, SMALLINT
년수	• 년을 기준으로 헤아리는 수 • 시간의 길이를 년(year) 단위로 측정하여 정수 또는 소수점으로 표현한다. • 연 단위의 기간을 나타내는 경우 사용한다.	근무년수 대출년수 보증년수	INTEGER, DECIMAL
매수	• 종이나 유리 등의 장으로 셀 수 있는 물건의 수효 • 장(張)으로 셀 수 있는 대상의 수량을 표현할 때 사용한다.	기본매수 인쇄매수 복사매수	INTEGER
개수	• 한 개씩 낱으로 셀 수 있는 물건의 수효 • 개별 물건을 셀 때 사용한다.	보유개수 상품개수 부품개수	INTEGER
건수	• 사물이나 사건의 가짓수 • 업무 처리나 사건의 수를 나타낼 때 사용한다.	조회건수 거래건수 접수건수	INTEGER
횟수	• 돌아오는 차례의 수효 • 되풀이되는 일이나 차례의 수효를 나타내는 경우 사용한다. • 반복적인 행위나 이벤트의 빈도를 나타낼 때 사용한다.	기존인출횟수 방문횟수 시도횟수	INTEGER
점수	• 성적을 나타내는 숫자 • 평가나 시험 등의 결과를 수치로 표현할 때 사용한다.	평가대상점수 시험점수 만족도점수	INTEGER, DECIMAL
연령	• 나이, 사람이 세상에 나서 현재 또는 기준이 되는 때까지 살아온 햇수 • 나이와 관련된 용어를 정의할 때 사용한다. • ‘나이’ 대신 ’연령’을 도메인으로 사용한다.	보험연령 가입자연령 평균연령	INTEGER, SMALLINT
수량	• 수와 양이 혼재된 수량을 자연수로 표현한 수 • 셀 수 있는 물건의 양을 나타낼 때 사용한다. • 일반적인 수량을 표현할 때 사용한다.	재고수량 주문수량 생산수량	INTEGER, DECIMAL

7.5.12 ‘율’ 도메인 그룹 규칙

• 율 도메인 그룹은 둘 이상의 수를 비교하여 그 중 하나의 수를 기준으로 하여 나타낸 다른 수의 비교 값을 표현하기 위한 도메인들을 그룹화하여 관리한다.
• 도메인 일부 예시

도메인	설명	예시	비고
율	• 비율의 뜻을 나타내는 말 “~율”은 모음으로 끝나거나 ‘ㄴ’ 받침을 가진 일부 명사 뒤에 붙임(복합어로 생성) • ‘율’ 또는 ‘률’은 단일 단어로 사용하지 않고 사전을 참조하여 복합어로 생성한다. • 확률, 비율 등’%’로 관리되는 속성에 대해 ’율’을 도메인으로 정의하여 사용한다.	할인율 연체율 성공률
이율	• 원금에 대한 이자의 비율, 즉 이자 산출에 기초가 되는 비율	연체이율 대출이율 예금이율
세율	• 과세 표준에 의하여 세금을 계산하여 매기는 법정률	소득세율 부가가치세율 법인세율
요율	• 요금의 정도나 비율	보증요율 보험요율 수수료요율
금리	• 자금의 사용료로 대외적으로 공시되는 기준의 의미로 사용	대출금리 예금금리 기준금리
환율	• 외국환 시세	기준환율 매매환율 현물환율
비율	• 둘 이상의 수를 비교하여 나타낼 때 그 중 한 개의 수를 기준으로 하여 나타낸 다른 수의 비교 값 • 확률, 비율 등 ’%’로 관리되는 속성에 대해 ’비율’을 도메인으로 정의하여 사용한다.	사고MT비율 담보비율 적용비율

7.5.13 ‘단위’ 도메인 그룹 규칙

• 단위 도메인 그룹은 측정값의 크기나 양을 표현하기 위한 표준화된 척도를 그룹화하여 관리한다.
• ’단위’는 단일 단어로 허용하지 않고, 반드시 복합어로 생성한다
• SI 기본단위 및 metric system 준수
  • 기본단위: m(길이), kg(질량), s(시간), A(전류), K(온도), mol(물질량) 등
  • 파생단위: N(뉴턴) = kg·m/s², Pa(파스칼) = N/m², J(줄) = N·m
  • 업계 표준단위의 관용적 허용: inch(인치), pound(파운드), feet(피트), yard(야드)
• 단위 표기 규칙
  • 국제표준 표기법 준수: kg/m³, mol/L, copies/mL
  • 복합단위는 곱하기(·), 나누기(/) 사용: N·m, kg·m/s²
  • 제곱단위는 윗첨자 사용: m², km³, cm², mm³
• 단위 분류
  • 기본단위: 미터(m), 킬로그램(kg), 초(s), 암페어(A), 켈빈(K)
  • 유도단위: 뉴턴(N), 파스칼(Pa), 줄(J), 와트(W)
  • 특수단위: copies/mL(바이러스 및 DNA 농도), CFU/mL(세균 농도)
• 도메인 명명: ‘측정대상 + 단위’
  • 예: 길이단위(m, cm, mm), 무게단위(kg, g, mg), 시간단위(s, min, h)
• 단위 변환
  • 변환 규칙 명시: 1 kg = 1000 g, 1 m = 100 cm
  • 정밀도 기준 정의: 소수점 3자리까지 표현
  • 기준단위 지정 및 통일: 길이는 m, 무게는 kg 기준
• 도메인 일부 예시

도메인	설명	예시	데이터 타입
길이단위	거리나 길이를 나타내는 단위	m, cm, mm, km, etc.	VARCHAR(50)
무게단위	질량이나 무게를 나타내는 단위	kg, g, mg, etc.	VARCHAR(50)
온도단위	온도를 나타내는 단위	°C, °F, K	VARCHAR(50)
시간단위	시간을 나타내는 단위	초, 분, 시, 일, etc.	VARCHAR(50)
농도단위	용액의 농도를 나타내는 단위	%, ppm, mol/L, copies/ml, etc.	VARCHAR(50)
부피단위	부피를 나타내는 단위	L, mL, cm³, etc.	VARCHAR(50)

7.5.14 ‘집합’ 도메인 그룹 규칙

• 집합 도메인 그룹은 여러 값들의 모음을 구조화하여 저장하는 데이터 유형을 그룹화하여 관리한다.
• 집합 도메인의 공통 도메인은 생성하지 않는다.
• 집합 도메인은 단일 값이 아닌 여러 값의 집합체를 표현하는 데이터 구조를 정의한다.
• 복잡한 데이터 구조를 표준화된 방식으로 표현한다.
• 집합성 도메인의 크기를 가급적 고정한다.
• 주요 특성:
  • 복합성 - 여러 값들의 조합으로 구성된 데이터 구조
  • 구조화 - 특정 패턴이나 규칙에 따라 데이터가 구조화됨
  • 중첩성 - 단일 또는 다중 차원의 계층 구조 가능
  • 동질성 - 일반적으로 동일한 도메인의 값들로 구성 (특히 배열)
• 복합 도메인 구성 원칙:
  1. 명확한 구조 정의 - 포함되는 데이터 요소와 관계를 명확히 문서화
  2. 직렬화 규칙 - 저장 및 전송 시 직렬화 방식 지정 (JSON, XML 등)
  3. 검증 룰 - 복합 데이터 유효성 검증을 위한 규칙 정의
  4. 버전 관리 - 스키마 변경 시 버전 관리 체계 수립
• 도메인 일부 예시

도메인	설명	인포타입	데이터 타입	유효값범위	예시
JSON	• 단일어 사용 불가, 복합어 형태로 생성 • 키-값 쌍으로 구성된 계층적 데이터 구조 • 복잡한 객체와 중첩된 데이터를 표현할 때 사용 • 웹 API 및 문서 저장에 적합		JSON		온도데이터JSON RFU데이터JSON
배열	• 단일어 사용 불가, 복합어 형태로 생성 • 동일한 데이터 타입의 값들을 순차적으로 저장하는 구조 • 순서가 있는 데이터 집합을 표현할 때 사용 • 가급적 JSON 형식으로 저장		ARR		온도데이터배열 RFU데이터배열
XML	• 단일어 사용 불가, 복합어 형태로 생성 • 태그 기반의 계층적 문서 구조 • 구조화된 문서와 메타데이터 표현에 사용 • 데이터 교환 표준으로 활용 • 가급적 JSON 형식으로 저장		XML		온도데이터XML RFU데이터XML
집합	• 단일어 사용 불가, 복합어 형태로 생성 • 중복되지 않는 고유 값들의 모음 • 순서가 없는 데이터 집합을 표현할 때 사용 • 멤버십 검사에 최적화 • 가급적 JSON 형식으로 저장		ARR/XML/JSON		사원명단집합 RFU데이터집합
RFU데이터JSON	• BioRad CFX 계열에서 측정된 데이터 JSON	RFU데이터JSONJN17,12[45]	JSON	45개의 요소, 각 요소는 N10,6	{“rfu_data”: [1234.567890, 2345.678901, 3456.789012, …, 4567.890123]}
RFU데이터배열	• BioRad CFX 계열에서 측정된 데이터 배열	RFU데이터배열AN17,12[45]	ARR	45개의 요소, 각 요소는 N10,6	[1234.567890, 2345.678901, 3456.789012, …, 4567.890123]
RFU데이터XML	• BioRad CFX 계열에서 측정된 데이터 XML	RFU데이터XMLXN17,12[45]	XML	45개의 요소, 각 요소는 N10,6	<RFUData><value>2234.567890</value><value>2345.678901</value>...</RFUData>
RFU데이터집합	• BioRad CFX 계열에서 측정된 데이터 집합	RFU데이터집합SN17,12[45]	ARR	45개의 요소, 각 요소는 N10,6	[1234.567890, 2345.678901, 3456.789012, …, 4567.890123]

7.5.15 ‘일반 단어’ 도메인 그룹 규칙

• 일반 단어 도메인 그룹은 위의 13개 도메인 그룹에 속하지 않는 단어들을 그룹화하여 관리한다.

8 표준 용어사전

8.1 표준 용어 사전 정의

• 표준 용어 사전(Standard Terminology Dictionary)은 조직 내에서 사용되는 모든 데이터 요소의 명칭과 의미를 일관되게 정의한 공식 참조 자료이다.
• 표준 단어를 조합하여 생성된 용어들의 집합으로, 데이터 모델링과 시스템 개발 과정에서 일관된 용어 사용을 보장한다.
• 표준 용어는 데이터 모델링에서 속성명으로 사용되며, 조직 전체에서 유일한 의미를 갖는 공식 명칭이다.
• 비즈니스 영역과 기술 영역 간의 의사소통을 위한 공통 언어 역할을 하며, 데이터 거버넌스의 핵심 구성요소이다.
• 동일한 개념이 모든 부서와 시스템에서 일관되게 해석되고 사용될 수 있도록 보장하여, 데이터 통합 과정에서 발생할 수 있는 의미적 불일치를 방지한다.

8.2 용어 사전의 사용 목적

표준 용어 사전은 데이터 모델링과 시스템 개발에서 일관된 용어 사용을 위한 기술적 도구로, 다음과 같은 목적을 가진다:

• 명확한 모델 구성요소 정의: 데이터베이스 스키마, API 필드, 변수명 등에 일관된 명칭 부여 및 유지
• 중복 정의 방지: 동일 개념에 대한 중복 정의를 방지하여 데이터 구조의 일관성 확보
• 데이터 매핑 간소화: 시스템 간 데이터 변환 및 매핑 작업 시 명확한 참조점 제공
• 스키마 설계 효율화: 표준화된 용어를 활용한 데이터베이스 스키마 설계 시간 단축 및 가독성 향상
• 데이터 구조 변경 관리: 용어 정의 변경 시 영향 범위를 명확히 파악하여 리팩토링 지원

8.3 표준용어의 정의

• 표준 용어(Standard Term)는 업무 영역에서 사용되는 개념을 명확하게 표현하기 위해 표준 단어들을 결합하여 만든 명칭이다.
• 표준 용어는 일반적으로 수식어(Modifier Word)와 주제어(Entity Word)의 조합으로 구성되며, 데이터 모델의 엔티티와 속성을 명명하는 데 사용된다.
• 각 표준 용어는 고유한 의미를 가지며, 동일한 개념에 대해 하나의 표준 용어만 존재한다.

8.4 표준 용어 사전의 구성요소

• [용어ID]
  • 용어ID는 용어의 고유 식별자로 표준 용어 사전에서 유일한 값이다.
• [용어]
  • 한글 용어는 기본적으로 구분자없이 작성하고 한글 용어 논리명의 구분자를 제거하면 용어가 되도록 작성한다.
  • 영어 용어는 기본적으로 단어 사이에 구분자 언더바(_)를 사용하여 작성한다.
• [한글 용어 논리명]
  • 한글 용어 논리명은 데이터의 의미를 나타내는 명칭으로 표준단어로 구성하여 작성한다.
  • 용어 논리명의 최대길이는 30자로 한다. 단 20자 이내로 작성할 것을 권장한다
  • 표준 용어 구성 시 5개 단어를 넘지 않도록 한다.
• [영어 용어 논리명]
  • 한글 용어 논리명은 데이터의 의미를 나타내는 명칭으로 표준단어로 구성하여 작성한다.
  • 용어 논리명의 최대길이는 30자로 한다. 단 20자 이내로 작성할 것을 권장한다
  • 표준 용어 구성 시 5개 단어를 넘지 않도록 한다.
• [용어 물리명]
  • 용어 물리명은 단어의 영문 약어 조합으로 이루어지며 단어의 영문약어들끼리 연결 할 때는 언더바(_)를 사용한다.
  • 영문 물리명의 약어는 표준 단어사전의 영문 약어 생성 규칙을 준수하여 축약된다.
  • 용어 물리명은 최종적으로 데이터베이스 테이블 또는 컬럼명으로 사용되는 명칭이다.
  • 용어 물리명은 논리명을 줄여서 사용할 수 있으며, 물리명의 최대길이는 28자로 한다.
  • 단, 20자 이내로 작성할 것을 권장하며 DBMS에 따라 최대길이가 제한될 수 있다.
• [인포타입]
  • 인포타입은 데이터의 타입(범위,길이,소수점자리수)을 나타낸다.
    
• 도메인 그룹
  • 도메인그룹은 데이터의 도메인을 나타내는 명칭이다.
    
• [코드]
  • 입력할 수 있는 유효 값 데이터 값을 정의할 수 있다면 용어는 코드와 매핑 한다.
• [정의]
  • 용어가 업무적으로 사용되는 의미를 기술한 내용으로 간단 명료하게 작성한다.
    
• 표준 용어 사전 예시

용어ID	용어	한글 용어 논리명	영어 용어 논리명	용어 물리명	인포타입	도메인 그룹	코드	정의
T001	실험시작일시	실험 시작 일시	experiment start datetime	expr_strt_dttm	일시VC16	날짜	-	실험이 시작된 정확한 날짜와 시간
T002	생산년월	생산 년월	production year month	prdc_year_mnth	년월VC6	날짜	-	제품이 생산된 년도와 월
T003	실험자성명	실험자 성명	experimenter name	expr_name	성명VC10	명	-	실험을 수행한 담당자의 성명
T004	시약제품명	시약 제품명	reagent product name	rgnt_prod_name	제품명VC50	명	-	실험에 사용된 시약의 제품명
T005	실험단계설명	실험 단계 설명	experiment step description	expr_step_dscr	설명T	내용	-	실험 진행 단계에 대한 상세 설명
T006	실험비고	실험 비고	experiment remark	expr_rmrk	비고T	내용	-	실험과 관련된 특이사항 및 비고
T007	농도측정값	농도 측정값	concentration measured value	cncn_msrd_val	측정값N10,2	값	-	시료의 농도 측정 결과값
T008	옵션항목값	옵션 항목 값	option item value	optn_item_val	항목값VC100	값	-	설정 가능한 옵션의 항목값
T009	실험건수	실험 건수	experiment count	expr_cont	건수N10	수	-	수행된 실험의 총 건수
T010	샘플개수	샘플 개수	sample count	smpl_cont	개수N10	수	-	분석에 사용된 샘플의 개수
T011	농도비율	농도 비율	concentration ratio	cncn_rati	비율N5,3	율	-	전체 대비 해당 성분의 농도 비율
T012	순도백분율	순도 백분율	purity percentage	prty_prct	백분율N5,2	율	-	시료의 순도를 백분율로 표현한 값
T013	소모품유형코드	소모품 유형 코드	consumable type code	cnsm_type_cd	구분코드VC5	코드	CT
T015	완료여부	완료 여부	completion yn	cmpl_yn	여부C1	분류	YN	작업 완료 여부 (Y/N)
T016	오류유무	오류 유무	error yn	err_yn	유무C1	분류	YN	처리 과정에서 오류 발생 유무
T017	연락처전화번호	연락처 전화번호	contact_phone_number	cntc_phon_num	전화번호VC15	번호	-	담당자 연락을 위한 전화번호
T018	대금수취계좌번호	대금 수취 계좌번호	payment account number	pymn_acnt_num	계좌번호VC20	번호	-	대금 수취를 위한 은행 계좌번호
T019	트랜잭션UUID	트랜잭션 UUID	transaction uuid	trns_uuid	UUIDU	식별	-	거래 처리를 위한 고유 식별자

8.5 표준용어의 원칙

• 표준용어는 누구나 쉽게 이해할 수 있도록 작성해야 한다.
• 지나치게 전문적이거나 장황한 설명은 지양하고, 간결하면서도 명확하게 표현하여 모호함이 없어야 한다.
• 표준용어 작성 시 다음과 같은 기본 원칙을 준수해야 한다:
  • 일관성: 동일한 개념은 항상 동일한 용어로 표현되어야 한다.
  • 명확성: 각 용어는 그 의미가 명확하게 정의되어야 하며, 모호함이 없어야 한다.
  • 유일성: 하나의 개념에는 하나의 표준 용어만 존재해야 한다(동의어 배제).
  • 업무 적합성: 용어는 실제 업무 프로세스와 요구사항을 정확히 반영해야 한다.
  • 확장성: 새로운 개념이나 요구사항을 수용할 수 있도록 유연하게 설계되어야 한다.
  • 간결성: 용어는 가능한 간결하게 구성하되, 의미 전달에 필요한 모든 요소를 포함해야 한다.
  • 표준 단어 활용: 모든 표준 용어는 승인된 표준 단어만을 사용하여 구성되어야 한다.

8.5.1 표준 용어의 기본규칙

순번	원칙 및 설명	예시
1	• 표준용어는 관용적으로 사용하는 용어를 우선적으로 사용한다	TOCE, MuDT
2	• 표준용어를 구성할 때에는 가독성을 높이고, 의미를 명확히 전달하기 위해 수식어를 사용하여 구성하도록 한다.	등록일자(X) → 장비자산등록일자(O)
3	• 용어 구성 시 단어는 반드시 표준 단어 사전에 등록된 단어를 사용하며, 단어 사전에 등록되어 있지 않은 경우에는 표준 담당자와 협의 후에 신규 단어로 등록하도록 한다.
4	• 일반적인 의미와 전혀 다르게 사용된 용어는 적절한 다른 용어로 대체하고, 유사한 의미의 용어가 중복 개발되어 혼재되지 않도록 하며 새로운 용어의 개발은 자제한다.	반환일자(X) → 반납일자(O)
5	• 표준용어로 등록된 명칭은 전사적으로 사용되어야 하므로 용어 선정 시 신중하게 고려하여야 한다
6	• 표준용어는 1개 이상의 표준단어와 표준도메인을 조합하여 구성하며 한 개의 표준용어로 구성된다	렌탈 + 가능(X) → 렌탈 + 가능 + 금액(O)
7	• 표준용어 명명 규칙 - 표준용어는 누구나 이해하기 쉽도록 구체적이고 명확하고 간결하게 정의한다 - 복합어를 단일어 보다 우선 적용한다 - 복합어가 중첩되어 사용될 경우 도메인이 포함된 복합어를 우선 적용한다 - 의미 있는 숫자를 포함한 용어의 경우에는 숫자를 포함하여 하나의 표준단어를 등록한 후 그 표준 단어를 사용하여 용어를 정의한다 - 용어의 의미를 모호하게 하는 의미 없는 일련번호를 부여하기 위한 숫자는 사용하지 않으며 용어에 수식어를 사용하여 용어가 유일하게 식별되도록 정의해야한다.

• 표준용어 명명 규칙 예시
  • 구체적이고 명확하고 간결한 정의
    • “번호” (모호, X) → “고객주문번호” (고객이 발생시킨 주문 식별 번호, O)
    • “고객관련주문관련번호정보” (잉여적 표현으로 불필요하게 복잡함) → “고객주문번호” (고객이 발생시킨 주문 식별 번호, O)
    • “농도” (모호, X) → “시약농도” (시약의 농도를 나타내는 수치, O)
      
  • 복합어를 단일어보다 우선 적용
    • “계좌” or “번호”를 별도로 사용(X) → “계좌번호” (복합어로 사용, O)
    • “양성” or “대조군” 별도로 사용(X) → “양성대조군” (복합어로 사용했지만 도메인 X) → “양성대조군여부” (복합어로 사용 O, 도메인 O)
  • 도메인 포함
    • “양성대조군” (복합어로 사용했지만 도메인 X) → “양성대조군여부” (복합어로 사용 O, 도메인 O)
    • “시작일시” (모호, X) → “실험시작일시” (“실험시작”+“일시”, 여기서 “일시”는 도메인, O)
    • “고객금액” (모호, X) → “고객주문금액” (“고객주문”+“금액”, 여기서 “금액”은 도메인, O)
    • “시약준비” (도메인, X) → “시약준비일시” (“시약준비”+“일시”, 여기서 “일시”은 도메인, O)
  • 의미 있는 숫자를 포함한 용어
    • “차원3좌표” (숫자를 뒤에 배치, X) → “3차원좌표” (“3차원”을 하나의 표준단어로 등록, O)
    • “단계2검증” (숫자를 뒤에 배치, X) → “2단계검증” (“2단계”를 하나의 표준단어로 등록, O)
    • “1분기_매출” (특수문자, X) → “1분기매출” (“1분기”를 하나의 표준단어로 등록, O)
      
  • 의미 없는 일련번호 지양, 수식어 사용하여 모호성을 최소화
    • “고객주소1” vs “고객주소2” (의미 없는 일련번호, X) → “홈페이지고객주소” vs “모바일고객주소” (일련번호 대신 수식어 사용, O)
    • “사용자코드1” vs “사용자코드2” (의미 없는 일련번호, X) → “내부사용자코드” vs “외부사용자코드” (일련번호 대신 수식어 사용, O)
    • “실험결과1” vs “실험결과2” (의미 없는 일련번호, X) → “정규실험결과” vs “반복실험결과” (일련번호 대신 수식어 사용, O)

8.5.2 표준 용어의 구성 규칙

• 용어 구성의 기본 구조: 다음과 같은 계층적 구조로 구성된다.

[수식어] + [주제어] + [수식어] + [주제어] + ... + [도메인 or 분류어]

• 수식어(Modifier): 주제어를 구체화하고 한정하는 단어
• 주제어(Entity): 핵심 개념을 나타내는 업무 영역별 단어 (비즈니스성 도메인)
• 도메인(Domain): 데이터의 타입과 성격을 나타내는 최종 분류 단어 (데이터성 도메인)

기본 구성 원칙

• 수식어 우선 배치: 구체화하는 수식어를 앞쪽에 배치
• 주제어 중심 배치: 핵심 개념인 주제어를 중간에 배치
• 분류어 최종 배치: 데이터 타입을 나타내는 분류어를 가장 마지막에 배치
• 최소 구성: [주제어] + [도메인]
  • 의미의 모호성 때문에 최소 구성 단위는 권장하지 않음
  • 의미가 구체적이지 않아 표준 용어 등록에 거절당할 가능성 높음
  • 예시
    • 고객(주제어) + 번호(도메인) → 고객번호
    • 시약(주제어) + 농도(도메인) → 시약농도
      
    • 주문(주제어) + 일자(도메인) → 주문일자
• 권장 구성: [수식어] + [주제어] + [도메인]
  • 예시
    • 등록(수식어) + 고객(주제어) + 번호(도메인) → 등록고객번호 (시간수식어)
    • 홈페이지(수식어) + 고객(주제어) + 주소(도메인) → 홈페이지고객주소 (장소수식어)
    • 최종(수식어) + 승인(주제어) + 일시(도메인) → 최종승인일시 (시간수식어)
• 복합 구성: [수식어] + [주제어] + [수식어] + [주제어] + [도메인]
  • 용어는 수식과 수식의 대상이 되는 단어가 여러 개 존재 할 수 있고 도메인은 용어의 끝에 위치한다
  • 수식어는 기간, 장소, 특징, 계산의 성격을 가지는 단어가 순서대로 위치하고 기간을 수식하는 단어는 맨 앞에 위치한다
  • 수식어 중 계산의 성격을 가진 단어는 합계, 누계, 총합계, 총누계, 소계 중 하나를 선택하여 사용여야 한다. (도메인 그룹이 금액과 수량과 같이 계산이 필요한 도메인을 수식함)
  • 대상이 되는 단어가 여러 개 일 때는 중 범위가 큰 것 순서대로 용어의 앞부분에 위치한다
  • [수식어]는 다른 [수식어]를 수식할 수 있다.
  • [주제어]는 다른 [주제어]를 수식할 수 있다.
  • [도메인]은 다른 [도메인]을 수식할 수 있다.
• 예시 (이해를 위한 단순 예시로 인위적으로 만든 예시이며 권장되지 않는 용어들이 포함되어 있을 수 있음)
  • 고객(주제어) + 분류(도메인) + 일자(도메인) → 고객분류일자
  • 주문(수식어) + 등록(수식어) + 일시(도메인) → 주문등록일시
  • 홈페이지(수식어) + 고객(주제어) + 주문(수식어 or 주제어) + 내역(주제어) + 번호(도메인) → 홈페이지고객주문내역번호
  • 내부(수식어) + 사용자(주제어) + 접근(수식어 or 주제어) + 권한(주제어) + 코드(도메인) → 내부사용자접근권한코드
  • 월(수식어) + 매출(주제어) + 목표(주제어) + 달성(주제어) + 금액(도메인) → 월매출목표달성금액
  • 수식어와 대상 단어가 여러 개인 경우
    • 최초서울지역고객매출합계금액
    • 월별부산지점상품재고수량
    • 분기별전국직원급여총합계금액
    • 실시간PCRDNA농도측정값
    • 시제품정량RFU원본값
    • 정성VnV양성총누계빈도수
    • 구조 분석
      • 기간 수식어: 2023년도, 월별, 분기별
      • 장소 수식어: 서울지역, 부산지점, 전국
      • 특징 수식어: 실시간, 정량, 역전사, 정성
      • 대상 단어: 고객매출, 상품재고, 직원급여, PCRDNA농도, PCRRNA발현량, PCRCDNA합성량
      • 계산 성격: 합계, 총합계
      • 도메인 분류어: 금액, 수량, 측정값, 상대값, 절대값
  • 범위가 큰 것부터 순서대로 배치
    • 아시아씨젠의료재단PCR시약검사수량 (아시아지역 > 씨젠의료재단 순)
    • 유럽독일지점새약판매수량 (유럽 > 독일지점 순)
  • 계산 성격 단어 사용 예시
    • 월간PCR키트사용총수량 (합계 사용)
    • 연간진단시약생산비용누계금액 (누계 사용)
    • 분기PCR장비수익총합계금액 (총합계 사용)
    • 주간분자진단서비스총누계수량 (총누계 사용)
  • 복합적인 예시
    • 2024년1분기본사연구개발본부분자진단연구소COVID19PCR키트매출총합계금액
  • 구조:
    • 기간: 2024년1분기
    • 장소: 본사연구개발본부분자진단연구소
    • 특징: COVID19PCR키트
    • 대상: 매출
    • 계산: 총합계
    • 도메인: 금액

수식어 사용 예시

• 목적: 주제어의 의미를 구체화하고 명확화
• 위치: 수식하고자 하는 주제어의 앞에 배치
• 표준 단어 사전에 등재되어 있는 단어를 사용
• 표준 단어 사전에 등재되어 있지 않은 경우에는 담당자와 협의하여 표준 단어 사전에 등재하여 사용할 것
• 시간/기간 수식어
  • 시점: 시작, 종료, 등록, 수정, 삭제, 승인 등
  • 기간: 개월, 분기, 연간, 일일, 주간, 년초, 연말 등
  • 순서: 최초, 최종, 이전, 다음, 현재, 과거, 미래, 중간 등
  • 예시: 시작실험일시, 종료실험일시, 전처리Ct, 최종승인일자, 최초등록일자, 최근등록일자 등
• 장소/위치 수식어
  • 조직: 내부, 외부, 본사, 지사, 부서 등
  • 지역: 국내, 해외, 북미, 유럽, 중동, 지점, 본사, 법인 등
  • 예시: 북미고객주소, 내부사용자코드, 고객소모품유형, 등
• 특징/상태 수식어
  • 상태: 활성, 비활성, 임시, 정규, 예비 등
  • 유형: 양성, 음성, 정상, 비정상, 표준 등
  • 등급: VIP, 일반, 우수, 신규, 기존 등
  • 예시: 활성사용자번호, 양성대조군여부, 표준장비번호, 시제품실험명 등
• 계산/처리 수식어
  • 집계: 총, 평균, 최대, 최소, 합계 등
  • 누적: 누적, 당월, 당년, 전월, 전년 등
  • 처리: 예상, 실제, 계획, 목표, 달성 등
  • 예시: 총매출금액, 누적소모품수량, 예상완료일자 등
• 관계/소속 수식어
  • 소유: 고객, 관리자, 시스템, 사용자 등
  • 참조: 연결, 매핑, 참조, 기준, 대상 등
  • 관계: 주, 부, 상위, 하위, 연관 등
  • 예시: 고객주문번호, 기준환율금액, 상위메뉴코드 등

주제어 사용 예시

• 목적: 용어의 핵심 비즈니스 개념 표현
• 특성: 업무 영역(비즈니스 도메인)이나 스키마에서 DB에서 테이블로 존재할 수 있는 핵심 엔티티를 나타내는 단어
• 표준 단어 사전에 등재되어 있는 단어를 사용
• 표준 단어 사전에 등재되어 있지 않은 경우에는 담당자와 협의하여 표준 단어 사전에 등재하여 사용할 것
• 예시:
  • 시작실험일시, 종료실험일시, 최종승인일자, 최초등록일자, 최근등록일자 등
  • 북미고객주소, 내부사용자코드, 고객소모품유형, 표준장비번호 등
  • 원액농도단위, 스탁농도단위, 추출시약코드, NCBI병원체명 등

도메 사용 예시

• 목적: 데이터의 최종 타입 및 성격 정의
• 위치: 용어의 가장 마지막에 배치
• 모든 표준 용어는 반드시 하나의 분류어로 종료
• 표준 도메인 사전에 등재되어 있는 도메인을 사용
• 표준 도메인 사전에 등재되어 있지 않은 경우에는 담당자와 협의하여 표준 도메인 사전에 등재하여 사용할 것

8.5.3 활용 규칙

순번	규칙	예시
1	표준용어에 적절한 명칭을 부여 및 구체적으로 정의한다 - 표준용어정의는 그 활동 내용이 무엇이, 어디서, 무엇을, 어떻게에 대한 정보가 포함되도록 작성되어야한다. (6하 원칙에 기반한 작성 권장)	대여차량입고일자: 렌트차량이 반환되어 차고지에 입고 된 일자이다.
2	표준용어의 명칭이 주는 의미가 불분명하면 좀더 상세하게 정의해야 한다.	유효기간(X) → 회원멤버쉽유효기간(O) RP2: 부분 R2값이다. (X) → RP2: 전처리 이후 RFU의 Baseline 부분 (SFC 부터 EFC까지)의 R2값이다.
3	동일한 의미의 용어가 중복되지 않도록 표준용어 구성 순서를 고려해 생성한다	현금서비스최종3개월총합계금액(X) → 최종3개월현금서비스총합계금액(O)
4	표준용어의 한글명 또는 영문명 길이 제한으로 인해 축약된 형태로 사용해야 하는 경우 용어를 구성하는 단어 중 연관도와 활용도가 높은 단어들을 합하여 복합어를 정의해야 한다	고객신용카드대출상환금액정보(X) → 고객카드대출상환금액(O) 시스템데이터베이스백업스케줄관리번호(X) → DB백업스케줄관리번호(O)
5	표준용어 중 ‘여부’ 도메인으로 끝나는 것들은 대표로 하나의 코드명과 코드 값(Y, N)을 등록하여 모든 공통적으로 사용하도록 한다.	과제승인여부, 과제완료여부, 분석활성여부, 실험기록삭제여부 - Y: 예/있음/완료 - N: 아니오/없음/미완료
6	‘비밀번호’ 자체로는 그 의미가 불분명하여 로그인비밀번호, 시스템관리자비밀번호 등으로 좀더 상세화하여 표준용어를 정의한다	비밀번호(X) → 로그인비밀번호(O) 비밀번호(X) → 관리자비밀번호(O) 비밀번호(X) → 거래비밀번호(O)

8.5.4 용어 구성 예시

바람직하지 않은 용어	바람직한 용어	비고
실험 중 적어놔야할 중요한 내용	실험노트	서울형 용어
시약농도	추출시약농도단위	주제어 및 분류어 누락
실험실번호	PCR실험실등록번호	주제어 누락 및 약어 사용
검사순번	분자진단검사일련번호	주제어 누락
등록자	검체등록자성명	주제어 및 분류어 누락
PCR결과(양성)확인여부	PCR양성결과확인여부	특수문자 사용
접수일	검체접수일자	주제어 및 분류어 누락
연구원	호흡기실험자원성명	주제어 및 분류어 누락
Ct값	PCR전처리완료Ct값	약어 사용 및 주제어 누락
시약LOT	시약로트번호	영문 사용 및 분류어 누락
검사_결과	분자진단검사결과코드	특수문자 사용 및 분류어 누락
양성대조군	양성대조군여부	분류어 누락
전처리시간	검체전처리소요시간	주제어 누락
장비ID	PCR장비식별번호	영문 사용 및 주제어 누락
최종확인	검사결과최종확인일시	주제어 및 분류어 누락
RFU	원본RFUJSON	수식어 및 분류어 누락

8.5.5 씨젠 용어 수정 예시

시스템	원본 물리명	원본 한글 논리명	원본 영어 논리명	표준 한글 논리명	표준 영어 논리명	표준 물리명
PDA	absd	baseline 차감 후 데이터	after baseline subtraction data	baseline 차감 이후 rfu 데이터	baseline subtracted rfu data post-baseline-subtraction rfu data	bsln_sbtr_rfu_data post_bsln_sbtr_rfu_data
PDA	channel	채널	channel	채널 코드	channel code	chnl_cd
PDA	well	웰 웰번호 웰이름	well well number well name	웰 코드	well code	well_cd
PDA	eat	이른 증폭 임계값	early amplification threshold	이른 증폭 임계값	early amplification threshold	erly_ampl_thrs
PDA	preproc_dataprocnum	전처리 데이터 처리 번호	preprocess data process number	전처리 RFU 데이터 처리 코드	preprocess rfu data process code pre-process rfu data process code preprocessed rfu data process code pre-processed rfu data process code	prpr_rfu_data_prcs_code pre_prcs_rfu_data_prcs_code prpr_rfu_data_process_code pre_prcs_rfu_data_prcs_code
LabIDE	epr_bpn	epr bpn	end point ratio bpn	BPN PGR Manager RAW 탭 기준선보정 저고온 RFU 비율? (X) bpn end point ratio	RAW tab baseline-subtracted low-high temperature RFU ratio (X) bpn end point ratio	raw_tab_bsln_sbtr_low_high_temp_rfu_ratio (X) bpn_end_pont_rati
LabIDE	roc_left	좌측 곡선 비율	ratio of curve left	좌측 곡선 비율 좌측 기울기	left curve ratio left slope	left_ratio_curve left_crve_rati left_slope
LabIDE	exist_label	label 존재 여부	exist_label	어떤? label 존재 여부	what label existence yn	what_labl_exst_yn
SG IDEA	pcr_tb_id	pcr 튜브 id	pcr tube id	pcr 튜브 코드	pcr tube code	pcr_tube_cd
SG IDEA	frst_rgdt	최초 등록 날짜	first registration date	최초 등록 일시	first registration datetime	frst_rgst_dttm frst_rgst_dt
SG IDEA	frst_rgst_usid	최초 등록 사용자 id	first registration user id	최초 등록 사용자 id	first registration user id	frst_rgst_user_id
SG IDEA	tbl_cd	테이블 코드	table code	테이블 코드	table code	tabl_cd
SG IDEA	prjct_id	프로젝트 id	project id	프로젝트 id	project id	prjc_id

9 표준 코드 테이블

9.1 기본 원칙

9.1.1 일관성 원칙

• 동일한 성격의 코드는 동일한 명명 규칙과 데이터 타입을 사용한다.
• 시스템 전체에서 일관된 코드 체계를 유지한다.

9.1.2 확장성 원칙

• 향후 코드 추가를 고려한 유연한 구조로 설계한다.
• 코드값 범위를 충분히 확보한다.

9.1.3 가독성 원칙

• 코드명과 코드 의미를 명확하게 구분하여 기술한다.
• 한국어와 영어를 병행하여 이해도를 향상시킨다.

9.1.4 호환성 원칙

• 기존 사용 중인 코드값을 개선하기 어렵거나 비지니스적으로 영향력이 커 변경이 어려운 경우 현업부서가 사용하는 코드 체계를 따른다.
• 새롭게 생성되어야 하는 코드만 표준 규칙을 적용한다.
• 시스템 안정성 및 업무 연속성을 보장한다.

9.2 코드 값 설계 규칙

9.2.1 상태 코드 규칙

• 표준 형식: 숫자형 (0, 1, 2, …)
• 데이터타입: tinyint 또는 bigint
• 권장 규칙:
  • 0: 기본/초기/비활성 상태 (예: inactive)
  • 1: 활성/완료/진행 상태 (예: active)
    
  • 2: 임시/대기/예외 상태 (예: temporary)
  • 음수(-1): 삭제/중단 상태 (필요시)

9.2.2 버전/타입 코드 규칙

• 표준 형식: “접두어+버전번호” 또는 “표준약어”
• 데이터타입: varchar(10) ~ varchar(45)
• 권장 규칙:
  • 버전: Major.Minor 형식 (예: DSP1.0, DSP2.0)
  • 접두어: 시스템/모듈명 약어
  • 특수코드: 의미있는 약어 조합

9.2.3 이진 클래스 코드 규칙

• 여부성 코드는 컬럼명 끝에 _yn을 붙여 명명하고 이진 클래스 코드로 정의한다.
• 표준 형식: y 또는 n
• 데이터타입: varchar(1)
• 권장 규칙:
  • y: 예
  • n: 아니오

9.2.4 다중 클래스 코드 규칙

• 표준 형식: 영문 약어 (2-4자리) 또는 의미있는 단어와 숫자를 조합하여 사용한다.
• 데이터타입: varchar(45)
• 권장 규칙:
  • 국제 표준 약어 우선 사용
  • 대문자 사용
  • 의미 유추 가능한 약어 선택
  • 한글 사용 금지 (신규 코드)

9.2.5 코드값 길이 규칙

• 단순 상태: 1자리 숫자 (0-9)
• 복합 상태: 2자리 숫자 (10-99)
• 약어형: 2-4자리 영문 (AA-AAAA)
• 버전형: 5-10자리 영숫자 (DSP1.0)
• 설명형: 10자리 이상 (신규 생성 지양)
• 코드값 길이 규칙: 코드값 길이는 최대 20자리로 제한한다.

9.2.6 코드 테이블 구조 규칙

9.2.6.1 코드 테이블 필수 구성 요소

• [시스템]
  • 코드가 속한 시스템명
  • 예: PDA
    
• [번호]
  • 코드 일련번호 (auto increment)
    
  • 예: 1,2,3, …
• [컬럼명]
  • 코드 컬럼명으로 반드시 표준 용어 사전에 정의된 용어를 사용한다.
  • 예: pstv_ngtv_intrp_cd
• [컬럼 설명]
  • 컬럼의 한국어 설명으로 반드시 표준 용어 사전에 정의된 용어를 사용한다.
  • 예: DSP의 양성/음성 결과 이유 설명 코드
• [코드값]
  • 코드 값을 의마하며 편의상 코드라고 부른다.
  • 예: 1, 0, -1
• [코드명]
  • 코드의 논리명으로 영문이나 한글로 표현한다.
  • 예: 1, 0, -1
• [코드 의미]
  • 코드의 의미를 나타내며 한국어와 영어로 표현한다.
  • 예: 1: MuDT 과정에서 음성, 0: 정상 양성, -1: 2단 꺾기 수정 후 양성
• [데이터타입]
  • 해당 컬럼의 데이터 타입으로 도메인 사전에 정의된 데이터 타입을 사용한다.
  • 예: int
• [담당부서]
  • 코드 관리 담당 부서
  • 예: Core개발팀

9.2.6.2 코드 테이블 선택 구성 요소

• 비고: 추가 설명이 필요한 경우
• 생성일시: 코드 생성 일시
• 수정일시: 코드 수정 일시
• 사용여부: 코드 활성화 상태 (Y/N)
• 정렬순서: 코드 표시 순서
• 표준여부: 표준 규칙 준수 여부 (Y/N)

9.2.7 기존 코드 관리 원칙

9.2.7.1 기존 코드 보호 규칙

• 절대 금지 사항:
  • 기존 코드값 변경
  • 기존 코드 삭제
  • 기존 코드의 의미 변경
  • 기존 데이터타입 변경
• 허용 사항:
  • 코드 관리 부서의 요청 수용을 1순위로 한다.
  • 코드 의미 보완 (명확성 향상)
  • 비고 추가
  • 새로운 코드 추가

9.2.7.2 신규 코드 적용 규칙

• 적용 대상:
  • 새로 생성되는 테이블의 코드
  • 새로 추가되는 컬럼의 코드
  • 기존 코드 그룹에 추가되는 새 코드값
• 표준 준수:
  • 신규 코드는 반드시 표준 규칙 적용
  • 기존 코드와 일관성 고려
  • 현업 담당자와 사전 협의

9.2.8 변경 관리 규칙

9.2.8.1 변경 금지 원칙

• 기존 운영 코드:
  • 코드값 수정 절대 금지
  • 의미 변경 절대 금지
    
  • 삭제 대신 비활성화 처리

9.2.8.2 추가/보완 허용 범위

• 허용 사항:
  • 새로운 코드값 추가
  • 코드 의미 명확화 (괄호 내 영문 추가 등)
  • 비고란 활용한 추가 설명
  • 정렬순서 조정

9.2.8.3 승인 절차

• 현업 담당자 승인
• 시스템 영향도 검토
• 테스트 환경 검증

9.2.8.4 문서화 규칙

• 필수 기록 사항:
  • 모든 코드 변경 이력
  • 변경 사유 및 승인자
  • 현업 요청 근거
  • 시스템 영향도 분석 결과

9.2.8.5 이력 관리

• 변경일시, 담당자 필수 기록
• 백업 및 복구 계획 수립
• 변경 전후 비교표 작성

10 표준 데이터 계층 구조

10.1 기본 설계 원칙

10.1.1 계층별 단일 책임 원칙 (Single Responsibility Principle)

• 각 계층은 명확하고 고유한 업무 영역과 목적을 가져야 함
• 한 계층에서 관리하는 데이터는 해당 계층의 책임 범위 내에서만 정의
• 계층 간 역할과 책임이 중복되지 않도록 설계

10.1.2 계층별 추상화 원칙 (Abstraction Principle)

• 상위 계층일수록 추상적이고 포괄적인 개념을 다룸
• 하위 계층일수록 구체적이고 세부적인 데이터를 관리
• 각 계층은 적절한 추상화 수준을 유지

10.1.3 계층 간 의존성 원칙 (Dependency Principle)

• 하위 계층은 상위 계층에 종속됨 (상향 의존성 금지)
• 계층 건너뛰기 의존성 금지 (인접 계층 간에만 관계 형성)
• 순환 의존성 절대 금지

10.1.4 계층 정의 원칙

10.1.4.1 계층 식별 기준

• 업무 프로세스의 자연스러운 단위
• 데이터 생명주기의 구분점
• 관리 주체 및 책임자의 차이
• 시간적 순서 및 진행 단계
• 물리적 구조 및 논리적 그룹

10.1.5 계층 번호 체계

• 1부터 시작하는 연속된 정수 사용
• 상위 계층일수록 작은 번호
• 중간 계층 삽입 시 기존 번호 변경 금지
• 긴급한 경우 소수점 사용 허용되만 권장하지 않음 (예: 2.5 계층 - 긴급 삽입 시)

10.1.6 계층명 명명 규칙

• 영문 소문자 사용 (단어 간 공백 허용)
• 명사형 단어 사용
• 해당 계층의 핵심 개념을 나타내는 용어
• 약어 사용 지양 (불가피한 경우 표준 약어만 사용)
• 15자 이내 권장

10.1.7 계층별 설계 규칙

10.1.7.1 상위 계층 (1-3계층) 설계 규칙

• 목적: 전략적 관점의 데이터 관리
• 특징:
  • 장기간 유지되는 안정적 데이터
  • 조직 및 프로젝트 레벨의 의사결정 지원
  • 높은 추상화 수준 (데이터 품질 관리 중심)
• 설계 고려사항:
  • 비즈니스 목표와 직결되는 속성 정의
  • 변경 빈도가 낮은 안정적 구조
  • 명확한 식별자 체계 필요

10.1.7.2 중간 계층 (4-5계층) 설계 규칙

• 목적: 운영적 관점의 데이터 관리
• 특징:
  • 업무 프로세스의 핵심 단위
  • 실행 계획 및 운영 관리
  • 중간 수준의 추상화
• 설계 고려사항:
  • 실행 가능한 단위로 구성
  • 진행 상태 추적 가능한 속성 포함
  • 유연한 확장성 고려

10.1.7.3 하위 계층 (6-7계층) 설계 규칙

• 목적: 실행적 관점의 데이터 관리
• 특징:
  • 물리적 실체가 있는 구체적 데이터
  • 측정 가능하고 관찰 가능한 단위
  • 낮은 추상화 수준
• 설계 고려사항:
  • 표준화된 명명 규칙 적용
  • 자동화 처리 가능한 구조
  • 세밀한 추적 및 모니터링 지원

10.1.8 계층 간 관계 원칙

10.1.8.1 부모-자식 관계 규칙

• 기본 관계: 1:N (부모 1개 : 자식 N개)
• 예외 허용: 1:1 관계 (특수한 경우만)
• 금지 관계: N:M (다대다 관계 절대 금지)
• 관계 표현:
  • 자식 계층에 부모 계층의 식별자 포함
  • 명확한 외래키 관계 설정
  • 계층별 고유 식별자 체계 유지

10.1.8.2 데이터 흐름 원칙

• 정방향 흐름: 상위 → 하위 (계획 → 실행)
• 역방향 집계: 하위 → 상위 (결과 → 보고)
• 수평 흐름 금지: 동일 계층 간 직접 참조 금지
• 데이터 전파:
  • 상위 계층 변경 시 하위 계층 영향도 분석
  • 하위 계층 데이터로 상위 계층 상태 업데이트
  • 계층 간 일관성 유지 메커니즘 구축

10.1.9 계층 구조 구성 요소

• [계층 번호]
  • 형식: 1부터 시작하는 연속된 정수
  • 규칙:
    • 상위 계층일수록 작은 번호 부여
    • 최대 7계층까지 허용
    • 중간 계층 삽입 시 소수점 사용 (예: 2.5)
  • 범위: 1 ~ 7
  • 예시: 1(project), 2(product), 3(panel set), 4(experiment group), 5(experiment), 6(plate), 7(well)
• [계층명]
  • 형식: 영문 소문자, 단어 간 공백 허용
  • 규칙:
    • 표준 용어 사전에 등재된 용어 사용
    • 명사형 단어로 구성
    • 해당 계층의 핵심 개념을 나타내는 용어
    • 15자 이내 권장
• [계층 설명]
  • 형식: 영문 소문자, 단어 간 공백 허용
  • 규칙:
    • 표준 용어 사전에 등재된 용어 사용
    • 명사형 단어로 구성
    • 해당 계층의 핵심 개념을 나타내는 용어
    • 15자 이내 권장
  • 명명 원칙: snake_case 형태의 단어 조합
  • 예시:
    • project: 프로젝트 단위
    • product: 제품 단위
      
    • panel set: 패널 세트 단위
    • experiment group: 실험 그룹 단위
    • experiment: 실험 단위
    • plate: 플레이트 단위
    • well: 웰 단위
• [계층 설명]
  • 형식: 한국어 문장, 50자 이내
  • 규칙:
    • 해당 계층의 업무적 의미와 범위를 명확히 기술
    • 구성: [정의] + [특징] + [관리 범위]
  • 예시:
    • project: 프로젝트 단위
    • product: 제품 단위
      
    • panel set: 패널 세트 단위
    • experiment group: 실험 그룹 단위
    • experiment: 실험 단위
    • plate: 플레이트 단위
    • well: 웰 단위

10.1.9.1 계층 코드

• 형식: 계층별 표준 코드 체계
• 구성: [계층레벨] [업무구분] [순번]
• 데이터타입: VARCHAR(20)
• 예시:
  • 1계층: L1_PRJ_001 (Level1_Project_001)
  • 2계층: L2_PRD_001 (Level2_Product_001)
    
  • 3계층: L3_PNL_001 (Level3_Panel_001)
  • 4계층: L4_EXG_001 (Level4_ExperimentGroup_001)
  • 5계층: L5_EXP_001 (Level5_Experiment_001)
  • 6계층: L6_PLT_001 (Level6_Plate_001)
  • 7계층: L7_WEL_A01 (Level7_Well_A01)

10.1.9.2 예시

• 1계층 project:
  • 코드: COVID19_DIAG_2024
  • 설명: “COVID19 진단 시약 개발 프로젝트”
  • 주요속성: target_pathogen, project_number, dev_team, project_manager
• 2계층 product:
  • 코드: CORONA_C_V1.0
    
  • 설명: “Corona-C 제품 버전 1.0”
  • 주요속성: product_number, product_name, product_version, panel_info
• 3계층 panel set:
  • 코드: PNL_CORONA_BASIC
  • 설명: “Corona 기본 패널 세트”
  • 주요속성: panel_id, MOM, enzyme, analyte, sample_type, equipment, consumables
• 4계층 experiment group:
  • 코드: EXG_MULTI_MOM_LOD
  • 설명: “Multi MOM performance LoD 실험 그룹”
  • 주요속성: experiment_type, performance_category, test_objective
• 5계층 experiment:
  • 코드: EXP_20241201_001
  • 설명: “2024년 12월 1일 첫 번째 실험”
    
  • 주요속성: experiment_date, experiment_condition, equipment_number
• 6계층 plate:
  • 코드: PLT_EXP001_P01
  • 설명: “실험 001의 첫 번째 플레이트”
  • 주요속성: plate_name, plate_type, equipment_id
• 7계층 well:
  • 코드: A01, B05, H12
  • 설명: “플레이트 내 개별 웰 위치”
  • 주요속성: well_name, well_number

10.2 운영 및 관리 원칙

• 표준 단어 사전은 지속적으로 업데이트되며, 변경 사항을 반영할 수 있는 승인 프로세스를 운영한다.
  
• 조직 내 데이터 거버넌스를 강화하고, 표준 용어 사용을 활성화하기 위한 교육 및 가이드라인을 제공한다.

11 데이터 품질 관리

11.1 품질 기준 (Data Quality Criteria)

11.1.1 일관성 (Consistency)

11.1.1.1 명명 규칙 준수 지표

• 명명법 일관성 비율 (Naming Consistency Ratio, NCR) - 세분화 할 것
  • 정의: 테이블 및 컬럼 이름이 명명 규칙을 얼마나 일관되게 따르는지를 평가
  • 수식: NCR = Number of Names Following Standards / Total Number of Names
  • 스네이크 케이스 (snake_case)
  • 테이블 이름은 복수형, 컬럼 이름은 단수형.
  • 약어 사용 통일 (예: ID 대신 Id, Desc 대신 Description).
  • 분석 예시:
    • 총 50개의 이름(테이블 10개, 컬럼 40개)이 정의되었고, 이 중 45개가 명명 규칙을 따름.
    • NCR = 45 / 50 = 0.90
    • 해석: 명명법 일관성이 90% 수준이며, 규칙 위반 사례가 일부 존재함. 특히 컬럼 이름에서 규칙이 일관되지 않음.
• 물리명 규칙 준수율 (Physical Naming Compliance)
  • 정의: 정의된 물리명 작성 규칙을 준수하는 정도
  • 수식: 물리명 규칙 준수율 = (규칙을 준수하는 객체 수 / 전체 객체 수) × 100
  • 분석 예시:
    • 테이블 물리명 규칙:
      • 소문자 사용
      • 단어 간 언더스코어
      • 복수형 사용
      • 검사 결과:
        • 전체 테이블: 20개
        • 규칙 준수 테이블: 17개
        • 테이블 물리명 준수율 = (17/20) × 100 = 85%
• 약어 사용 일관성 (Abbreviation Consistency)
  • 정의: 정의된 약어 규칙을 일관되게 사용하는 정도
  • 수식: 약어 일관성 = (표준 약어 사용 건수 / 전체 약어 사용 건수) × 100
  • 분석 예시:
    • 약어 사용 현황:
      • 전체 약어 사용: 40건
      • 표준 약어 사용: 35건
      • 약어 일관성 = (35/40) × 100 = 87.5%
    • 비일관성 예시:
      • number → num, nbr (비일관)
      • identifier → id (일관)
      • sequence → seq (일관)
        
• 명명 규칙 준수율 (Naming Convention Compliance)
  • 정의: 정의된 명명 규칙을 준수하는 정도
  • 수식: 명명 규칙 준수율 = (규칙 준수 객체 수 / 전체 객체 수) × 100
  • 분석 예시:
    • 전체 객체(테이블+컬럼): 100개
    • 규칙 준수 객체: 90개
    • 명명 규칙 준수율 = (90/100) × 100 = 90%

11.1.1.2 메타데이터 완결성 지표

• 논리명 완전성 (Logical Name Completeness)
  • 정의: 모든 테이블과 컬럼에 논리명이 정의된 정도
  • 수식: 논리명 완전성 = (논리명이 정의된 객체 수 / 전체 객체 수) × 100
  • 분석 예시
    • 전체 테이블: 20개
    • 논리명 있는 테이블: 18개
    • 테이블 논리명 완전성 = (18/20) × 100 = 90%
    • 전체 컬럼: 150개
    • 논리명 있는 컬럼: 135개
    • 컬럼 논리명 완전성 = (135/150) × 100 = 90%
• 설명 정의 비율 (Description Coverage Ratio, DCR)
  • 메타데이터 항목(테이블, 컬럼 등)에 대한 설명(Comment)이 얼마나 잘 정의되어 있는지를 측정
  • 수식: DCR = Number of Items with Comments / Total Number of Items
  • 분석 예시
    • 총 테이블: 20개
    • 설명 있는 테이블: 15개
    • 테이블 설명 완전성 = (15/20) × 100 = 75%
    • 해석: 75%의 테이블이 설명을 포함하고 있음. 나머지 25%는 설명이 없어 데이터 해석 시 어려움이 예상됨.
    • 총 40개의 컬럼 중 32개에 설명이 작성됨.
    • DCR = 32/40 = 0.80
    • 해석: 80%의 컬럼이 설명을 포함하고 있음. 나머지 20%는 설명이 없어 데이터 해석 시 어려움이 예상됨.
• 데이터 유형 일관성 비율 (Data Type Consistency Ratio, DTCR)
  • 동일한 데이터 속성(예: user_id, created_date)이 여러 테이블에 정의된 경우, 데이터 유형이 일관되게 유지되는지를 측정
  • 수식: DTCR = Number of Consistent Data Types for Attributes / Total Number of Shared Attributes
  • 분석 예시
    • user_id와 created_date는 총 10개의 테이블에서 사용됨.
      
    • user_id는 8개 테이블에서 VARCHAR(50)로, 2개에서 VARCHAR(100)로 정의됨.
      
    • created_date는 모든 테이블에서 DATETIME으로 정의됨.
      
    • 일관성 유지 속성 = 9개.
    • DTCR = 9 / 10 = 0.90
    • 해석: 90%의 데이터 속성이 일관된 데이터 유형을 유지하고 있으나, user_id에서 일부 불일치 발견.
• 유사 컬럼 타입 일관성 (Similar Column Type Consistency)
  • 정의: 유사한 성격의 컬럼들이 동일한 타입을 사용하는 정도
  • 수식: 타입 일관성 = (표준 타입 사용 컬럼 수 / 동일 성격 전체 컬럼 수) × 100
  • 분석 예시:
    • 날짜 타입 사용 현황:
      • 날짜 관련 전체 컬럼: 20개
      • 표준 타입(DATE) 사용: 18개
      • 타입 일관성 = (18/20) × 100 = 90%
  • 비일관성 예시:
    • created_dt: DATE (일관)
    • modified_dt: TIMESTAMP (비일관)
• 도메인 일관성 지표
  • 도메인 정의 완전성 (Domain Definition Completeness)
    • 정의: 컬럼에 도메인이 명확히 정의된 정도
    • 수식: 도메인 정의 완전성 = (도메인이 정의된 컬럼 수 / 전체 컬럼 수) × 100
    • 분석 예시:
      • 도메인 정의 현황:
        • 전체 컬럼: 150개
        • 도메인 정의됨: 130개
        • 도메인 정의 완전성 = (130/150) × 100 = 86.7%
      • 주요 도메인:
        • CODE: 코드값
        • NAME: 명칭
        • DATE: 날짜
        • AMOUNT: 금액
• 키 속성 정의 비율 (Key Definition Ratio, KDR)
  • 설명: 테이블별로 주요 키 속성(Primary Key, Foreign Key 등)이 정의되었는지 평가
  • 수식: KDR = Number of Tables with Defined Keys / Total Number of Tables
  • 분석 예시
    • 총 10개의 테이블 중 7개에 Primary Key가 정의되고, 6개에 Foreign Key가 정의됨.
    • Primary Key와 Foreign Key를 모두 갖춘 테이블은 5개.
    • KDR = 7 / 10 = 0.70
    • 해석: 70%의 테이블이 주요 키 속성을 포함. 데이터 무결성 강화를 위해 추가 작업 필요.
• 메타데이터 완결성 비율 (Metadata Completeness Ratio, MCR)
  • 메타데이터 항목(테이블, 컬럼 등)에 필요한 정보가 얼마나 완전하게 정의되었는지를 평가
  • 주요 메타데이터 속성: 이름, 데이터 유형, 길이, 기본 키 여부, 외래 키 여부, 설명(Comment) 등.
  • 수식: MCR = Number of Defined Metadata Attributes / Total Metadata Attributes Required
  • 분석 예시: 총 10개의 테이블에 대해 다음과 같은 메타데이터 정의가 필요하다고 가정:
    • 속성: 이름, 데이터 유형, 설명(Comment), 기본 키 여부 (총 4개 속성).
    • 메타데이터가 완전히 정의된 테이블: 8개.
    • 일부 정의가 누락된 테이블: 2개
    • MCR = (8x4 + 2x3) / (10x4) = 38/40 = 0.95
    • 해석: 95%의 메타데이터 속성이 정의되었음. 높은 수준의 완결성을 유지하고 있으나, 일부 속성 누락이 존재

11.1.1.3 구조 관련 지표 (TBD)

• 구조적 복잡도 지표
  • 테이블 응집도 (Table Cohesion Rate)
    • 정의: 테이블 내 컬럼들의 논리적 연관성 정도
    • 수식: 테이블 응집도 = (관련 컬럼 수 / 전체 컬럼 수) × 100
    • 예시) 실험(Experiment) 테이블:
      • 전체 컬럼: 10개
      • 실험 관련 컬럼: 8개
      • 테이블 응집도 = (8/10) × 100 = 80%
  • 관계 복잡도 (Relationship Complexity)
    • 정의: 테이블 당 평균 관계 수
    • 데이터 모델 내 테이블 간 관계의 복잡성을 의미
    • 높은 값은 관계의 복잡성을 줄여야 함을 의미
    • 수식: 관계 복잡도 = 전체 관계 수 / 전체 테이블 수
    • 분석
      • 적정 범위: 0.5~2.0.
      • 값이 높으면 테이블 간 관계가 과도하게 복잡함.
      • 값이 낮으면 데이터 모델이 충분히 연결되지 않았을 가능성.
    • 예시)
      • 전체 테이블: 10개
      • 전체 관계(FK): 15개
      • 관계 복잡도 = 15/10 = 1.5
  • 테이블-속성 비율 (Table-to-Attribute Ratio, TAR)
    • 테이블당 평균 속성 개수를 계산하여 데이터 모델이 과도하게 단순하거나 복잡한지 평가
    • 너무 낮으면 데이터가 지나치게 분산되었고, 너무 높으면 과도하게 복잡하다는 의미
    • 수식: TAR = Total Number of Attributes / Total Number of Tables
    • 분석
      • 적정 EAR 범위: 일반적으로 5~15 사이가 적정.
      • 낮으면 테이블가 과도하게 많거나 속성이 지나치게 분산됨.
      • 높으면 테이블에 과도한 속성이 포함되어 복잡성이 증가.
        
• 정규화 평가 지표
  • 정규화 수준 (Normalization Level)
    • 정의: 테이블별 정규화 형태(1NF, 2NF, 3NF 등)
    • 각 테이블의 정규화 수준(1NF, 2NF, 3NF)을 평가하여 데이터 중복 및 종속성을 점검.
    • 정규화 수준에 따라 점수를 부여:
      • 1NF: 1점, 2NF: 2점, 3NF 이상: 3점.
    • 분석
      • 값이 2.5 이상이면 높은 정규화 수준으로 간주.
      • 값이 1.5 미만이면 데이터 중복 가능성이 높음.
    • 수식1: 정규화 준수율 = (목표 정규화 달성 테이블 수 / 전체 테이블 수) × 100
    • 수식2: 정규화 수준 = (총 테이블의 정규화 수준들의 총합 / 전체 테이블 수)
    • 예시)
      • 전체 테이블: 10개
      • 1NF 달성 테이블: 4개
      • 2NF 달성 테이블: 4개
      • 3NF 달성 테이블: 2개
      • 3NF 정규화 준수율 = (2/10) × 100 = 20%
      • 정규화 수준 = (4x1+4x2+3x1)/10 = 1.5
  • 중복 데이터 가능성 (Data Redundancy Potential)
    • 정의: 동일 정보가 여러 테이블에 중복될 가능성
    • 수식: 중복 가능성 = (중복 가능 컬럼 수 / 전체 컬럼 수) × 100
    • 예시)
      • 전체 컬럼: 50개
      • 중복 가능 컬럼: 5개
        • 중복 가능성 = (5/50) × 100 = 10%
• 키 구조 평가 지표
  • 식별자 구조 적절성 (Identifier Structure Adequacy)
    • 정의: PK 구조의 적절성 평가
    • 수식: 단순 식별자 비율 = (단순 PK 테이블 수 / 전체 테이블 수) × 100
    • 예시)
      • 전체 테이블: 10개
      • 단순 PK 테이블: 7개
      • 단순 식별자 비율 = (7/10) × 100 = 70%
  • 외래키 의존도 (Foreign Key Dependency Rate)
    • 정의: 테이블 간 의존성 정도
    • 수식: FK 의존도 = 테이블의 FK 수 / 테이블의 전체 컬럼 수
    • 예시) 샘플(Sample) 테이블:
      • 전체 컬럼: 8개
      • FK 컬럼: 2개
      • FK 의존도 = 2/8 = 0.25
        
• 키 속성 일관성 비율 (Key Attribute Consistency Ratio, KACR)
  • 각 테이블에 정의된 키 속성의 비율을 평가하여 일관성을 측정.
  • 기본 키(Primary Key), 외래 키(Foreign Key) 등이 정의되지 않은 경우 낮은 값을 가짐.
  • 수식: KACR = Number of Entities with Proper Keys Defined / Total Number of Tables
  • 분석
    • 값이 1에 가까울수록 모든 테이블이 적절한 키를 정의하고 있음.
    • 값이 낮으면 스키마의 데이터 무결성이 낮을 가능성.
• 다중 관계 비율 (Multi-Relationship Ratio, MRR)
  • 설명
    • 단일 테이블가 여러 관계에 참여하는 정도를 측정.
    • 지나치게 높은 값은 관계의 복잡성과 데이터의 잠재적 무결성 문제를 시사.
    • 수식: MRR = Total Number of Relationships Involving an Entity / Total Number of Entities
  • 분석
    • 적정 범위: 1~3.
    • 값이 높으면 특정 테이블가 관계 과부하 상태.
• 외래 키 활용 비율 (Foreign Key Utilization Ratio, FKUR)
  • 데이터 무결성을 보장하기 위해 외래 키 사용 여부를 평가.
  • 외래 키가 정의된 테이블의 비율로 측정.
  • 수식: FKUR = Number of Tables with Foreign Keys / Total Number of Tables
  • 분석
    • 값이 1에 가까울수록 모든 테이블이 적절히 외래 키를 사용하고 있음.
    • 값이 낮으면 데이터 간 연계성이 부족할 가능성.
• 속성 데이터 유형 일관성 비율 (Attribute Data Type Consistency, ADTC)
  • 동일 속성 이름이 여러 테이블에 존재할 경우 데이터 유형의 일관성을 측정.
  • 수식: ADTC = Number of Consistent Attribute Types / Total Number of Attributes with Similar Names
  • 분석
    • 값이 1에 가까울수록 동일 속성이 일관된 데이터 유형을 가짐.
    • 낮으면 데이터 모델링의 일관성이 부족함.

11.1.2 완전성 (Completeness)

• 필수 데이터 누락 여부 (TBD-DB 접근 필요 및 phase1 범위 아님)

11.1.3 정확성 (Accuracy)

• 데이터값의 정확성 (TBD-DB 접근 필요 및 phase1 범위 아님)

11.1.4 유효성 (Validity)

• 데이터 형식/도메인 준수 (TBD-DB 접근 필요 및 phase1 범위 아님)

11.1.5 적시성 (Timeliness)

• 데이터 입력/갱신 시점 (TBD-DB 접근 필요 및 phase1 범위 아님)