속성 (프로그래밍) 편집하기

'''속성'''(屬性, attribute)이란 개체가 가지고 있는 고유한 특성을 말한다. 예를 들어 '회원'이라는 개체는 "성명=홍길동", "성별=남자", "연령=30"이라는 속성을 가질 수 있다. [[데이터베이스]]에서 특정 [[레코드]](record)에 대한 속성값을 표시하기 위해 [[필드 (데이터베이스)|필드]](field)를 사용한다.

== 개요 ==
속성이란 사전적인 의미로는 사물(事物)의 성질, 특징 또는 본질적인 성질, 그것이 없다면 실체를 생각할 수 없는 것으로 정의할 수 있다. 본질적 속성이란 어떤 사물 또는 개념에 없어서는 안 될 징표(徵表)의 전부이다. 이 징표는 사물이나 개념이 어떤 것인지를 나타내고 그것을 다른 것과 구별하는 성질이라고 할 수 있다.
이런 사전적인 정의 이외에 데이터 모델링 관점에서 속성을 정의하자면, “업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위”로 정의할 수 있다. 업무상 관리하기 위한 최소의 의미 단위로 생각할 수 있고, 이것은 엔티티에서 한 분야를 담당하고 있다.<ref name="개요">〈[http://www.dbguide.net/db.db?cmd=view&boardUid=148180&boardConfigUid=9&categoryUid=216&boardIdx=132&boardStep=1 속성 (Attribute)의 개념]〉, 《데이터 전문가 지식포털》</ref>

속성은  엔티티에서 관리되는 구체적인 정보 항목으로 더 이상 분리될 수 없는 최소의 데이터 보관 단위이다. 예를 들어, 엔티티 사원에 속하는 모든 엔티티는 이름을 갖고 있다. 또한 모든 사원에는 입사 일자, 사원번호, 생년월일 등의 특성을 가지고 있다. 엔티티 사원에 속하는 모든 인스턴스들이 공통으로 가지는 이러한 특성을 속성(Attribute)이라고 한다. 각 엔티티들은 일련의 속성들에 의해 상세화될 수 있다.<ref name="dbguide">〈[http://www.dbguide.net/db.db?cmd=view&boardUid=12854&boardConfigUid=9&categoryUid=216&boardIdx=41&boardStep=1 속성 개념]〉, 《데이터 전문가 지식포털》 </ref>

== 유형 ==
속성 차원은 텍스트, 숫자, 부울 또는 날짜 데이터 유형을 가질 수 있어 데이터의 그룹화, 선택 또는 계산을 위한 여러 가지 함수를 사용할 수 있다. 속성 유형은 속성 차원의 레벨 0 맴버에만 적용된다.

* 텍스트 속성을 이용하여 기본 속성 맴버 선택 및 계산 시 속성 비교를 수행할 수 있다. 이러한 비교를 수행할 경우 문자가 비교된다. 예를 들어, 패키지 유형 Bottle은 다른 패키지 유형 Can보다 작다.

* 숫자 속성 차원은 레벨 0 맴버의 이름에 숫자 값을 사용한다. 계산 시 숫자 속성 차원 맴버의 이름(값)을 포함할 수 있다. 예를 들어, 각 제품에 대한 온스당 이익을 계산하기 위해 온스 속성에 지정된 온스 수를 사용할 수 있다. 또 예를 들어 시장 모집단 그룹별로 제품 판매를 분석하기 위해 기본 차원 값 범위와 숫사 속성을 연결할 수도 있다.

* 데이터베이스의 부울 속성 차원은 두 개의 맴버만 포함한다. 부울 속성 차원이 추가될 때 이 속성 차원에 대해 기본적으로 두 개의 속성 값(True 및 False)이 생성된다. 계정 또는 엔티티와 같은 기본 차원은 부울 데이터 유형을 가지는 하나의 속성 차원과 연결될 수 있다.

* 날짜 속성은 월-일-년 또는 일-월-년 형식으로 날짜 형식으로 지정하고 순서 정보를 적절하게 지정할 수 있다. 계산 시에 날짜 속성을 사용할 수 있다. 예를 들어, 특정 날짜 이후의 제품 판매 계산에서 날짜를 비교할 수 있다. 사용자는 [애플리케이션 설정] 환경설정에서 [속성 차원 날짜 형식]의 옵션을 선택하여 날짜 형식을 설정할 수 있다.<ref name="속성데이터유형">〈[https://docs.oracle.com/cloud/help/ko/financial-consol-cloud/AGFCC/understanding_attribute_data_types.htm#AGFCC-admin_dimensions_180 속성 데이터 유형 이해]〉, 《오라클》 </ref>

=== 명목 자료 ===
명목자료(nominal data)는 nominal(이름과 관련한)이란 수식어에서 알 수 있듯이 여러 카테고리들 중 하나의 이름에 데이터를 분류할 수 있을 때 사용된다. 명목 자료는 순서를 매길 수 없고 그냥 셀 수 있다. 평균을 계산하는 것이 의미 없고 퍼센트로는 표현할 수 있다. 특별히 명목 자료가 두 개의 범주 중 하나에 속하는 경우 이분 자료(categorical data)라고 불린다.

; 예시
사람 객체의 명목 속성 : 머리색, 혼인 상태, 직업 등<br>
- 머리색 : 검정, 갈색, 금색, 적색, 적갈색, 회색 등으로 구분 가능<br>
- 혼인 상태 : 독신, 혼인, 이혼, 미망인 등<br>
- 직업 : 교사, 치과, 개발자, 농부 등

; 명목 속성의 값
- 기호 또는 명칭 <br>
- 숫자로 표시 가능 <br>
- 숫자를 사용해도 명목 속성에서 수학적 연산은 의미가 없음<br>
- 유의미한 순서나 정량적인 값을 가지지 않음 <br>
- 평균 또는 중위수를 계산하는 것은 무의미한 일이지만 최빈수는 의미가 있음

=== 순서 자료 ===
데이터가 속하는 카테고리들에 순서가 있는 경우 순서 자료(ordinal data)라고 한다. 예를 들어 청팀이 이길 가능성에 대하여 조사하는 경우 그 답변을 “5. 매우 높다. 4. 높다. 3. 중립, 2. 낮다. 1. 매우 낮다."로 디자인할 수 있다. 명목 자료와 마찬가지로 숫자를 세고 퍼센트로 표현할 수 있다. 
평균에 대하서는 신중해야 한다. 명목 자료에 대해 평균을 계산해서는 안된다는 사람들이 있는데 이건 매우 높다에 5를, 높다에 4를 할당한 것처럼 그 각각의 숫자에 수학적/과학적 의미가 있는 것이 아니기 때문이다.

; 예시 <br>
(1) 패스트 푸드 식당에서 구매 가능한 음료의 크기에 해당하는 드링크 사이즈 속성 <br>
- 소형, 중형, 대형 3가지 값이 있으며 의미 있는 순서를 가진다.

(2) 직급 <br>
- 조교, 부교수, 정교수 <br>
- 이병, 일병, 상병, 병장

- 순서 속성은 객관적으로 측정할 수 없는 품질의 주관적인 평가를 등록하는 데 유용하다. <br>
ex) 설문조사(만족도 조사) : 0, 1, 2, 3, 4 순으로 매우 불만족, 약간 불만족, 중립, 만족, 매우 만족
- 순서 속성은 값의 범위를 유한 개수의 순서 범주로 구분하여 해당 값을 분할함으로써 얻을 수 있음<br>
- 중심 경향은 최빈수, 중위수로 표현할 수 있지만, 평균으로 나타낼 수 없음

; 정성적 속성
- 명목형, 이진형, 순서형 속성 <br>
- 실제 크기나 양 없이도 객체의 특징을 설명 <br>
- 정성적 속성의 값은 범주를 나타내는 단어를 이용 <br>

=== 구간 자료 ===
시간을 비율 자료(ratio data)라고 보는 사람이 있는데 기본적으로 하루 중 특정 시점을 나타내는 시간은 구간자료(interval data)다. 데이터의 연속된 측정 구간 사이의 간격이 동일한 경우 구간 자료라고 부른다. 구간 자료는 명목 자료를 가지므로 다양한 연산을 수행할 수 있다. 절대적 원점(zero point)이 없다. 예를 들면 00:00 이라는 자료의 값이 측정한 시간의 값이 없다는 것이 아닌 그냥 자정에 시간을 측정했다는 뜻이다.

; 간격 척도 속성
- 동일한 크기 단위로 측정함
- 속성의 값은 순서를 갖고 양수, 0 또는 음수를 가짐
- 값의 순서를 설정할 수 있고, 값 사이의 차이 정도 비교 가능
- 간격 척도 속성은 절대 영점이 존재하지 않음

=== 비율 자료 ===
현재 시각이 13:30 인데 시계를 보고 13:00 부터 계산하였을 때 30분을 기다린 것일 때 이 '30분'이 비율 자료(ratio data)다. 비율 자료의 경우 구간자료와 다르게 절대적 원점(meaningful zero point)이 존재하며 구간자료에서 00:00 이라는 값은 기다린 시간이 0초라는 뜻이다. 나이, 돈, 몸무게 이런 것들이 주로 비율 자료로 다루어 진다.

; 비율 척도 속성 
- 절대 영점을 갖고 있는 숫자 속성
- 어떤 값을 다른 값의 곱이나 비율로 표현할 수 있음
- 정렬할 수 있고, 값의 차이, 평균, 중위수, 최빈수를 계산할 수 있음

=== 이산형 vs 연속형 ===
구간형이나 비율형 자료는 이산형(discrete)이나 연속형(continuous) 둘 중의 하나의 속성을 갖게 된다. 측정값이 정수로 딱딱 떨어지는 경우 이산형이고 연속된 무수히 많은 값 중 하나를 가질 수 있는 경우 연속형이 된다. 연속형 데이터는 실제 표현될 때 적당히 반올림되어 표현된다. 현실에서 측정/이해하고자 하는 변수는 종종 하나 이상의 데이터 타입에 속하게 되며 데이터 타입은 어떤 측정 방법을 택하느냐에 따라 결정된다. 나이를 예로 들자면 나이는 비율 자료로 수집될 수 있지만, 순서 자료로 수집될 수 있다. 반면, 명목 자료나 순서 자료를 둘 다 카테고리 유형 데이터인 구간 자료나 비율 자료로 수집할 수 없다. 보다 보편적으로 이야기하자면 데이터 측정은 주어진 데이터의 본질적인 속성보다 더 높고/낮은 수준으로 내려갈 수는 있어도 더 정교한/높은 수준으로 올라갈 수는 없다.

; 이산형 <br>
- 유한 또는 셀 수 있는 무한 값의 집합 <br>
- 정수로 표현될 수 있거나 아닐 수도 있음 <br>

; 연속형 <br>
- 속성값이 이산형이 아닌 값 <br>
- 일반적으로 부동 소수점 변수로 표시 <ref name="기본적인 데이터 종류">〈[http://blog.heartcount.io/dd basic data type (기본적인 데이터 종류)]〉, 《하트카운트 블로그》, 2015-08-24 </ref>
<ref name="속성 유형">ggg1018, 〈[https://m.blog.naver.com/PostView.nhn?blogId=ggg1018&logNo=220874308104&proxyReferer=https:%2F%2Fwww.google.com%2F 데이터 객체와 속성 유형]〉, 《네이버 블로그》 </ref>

== 특징 ==
=== 표기법 ===
;  엔티티, 인스턴스, 속성, 속성값의 관계
엔티티에는 두 개 이상의 인스턴스가 존재하고 각각의 엔티티에는 고유의 성격을 표현하는 속성정보를 두 개 이상 갖는다. 업무에서는 엔티티를 구성하는 특징이 무엇인지 또한 각각의 인스턴스들은 어떤 성격의 데이터로 구성되는지를 파악하는 작업이 필요하다. 분석단계에서 엔티티 내에 존재하는 여러 개의 인스턴스가 가지는 동일한 성격은 무엇인지를 파악하고 이에 이름을 부여하여 엔티티의 속성으로 기술하는 작업이 필요하다. 예를 들면 사원은 이름, 주소, 전화번호, 직책 등을 가질 수 있다. 사원이라는 엔티티에 속한 인스턴스들의 성격을 구체적으로 나타내는 항목이 바로 속성이다. 각각의 인스턴스는 속성의 집합으로 설명될 수 있다. 하나의 속성은 하나의 인스턴스에만 존재할 수 있다. 속성은 관계로 기술될 수 없고 자신이 속성을 가질 수도 없다.

; 속성의 표기법
속성의 표기법은 엔티티 내에 이름을 포함하여 표현하면 된다.

=== 속성의 특성 ===
속성은 업무분석을 통해 바로 정의한 속성을 기본속성(Basic Attribute), 원래 업무상 존재하지는 않지만, 설계를 하면서 도출해내는 속성을 설계속성(Designed Attribute), 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성을 파생속성(Derived Attribute)이라고 한다.

; 기본속성
기본 속성은 업무로부터 추출한 모든 속성이 여기에 해당하며 엔티티에 가장 일반적이고 많은 속성을 차지한다. 코드성 데이터, 엔티티를 식별하기 위해 부여된 일련번호, 그리고 다른 속성을 계산하거나 영향을 받아 생성된 속성을 제외한 모든 속성은 기본속성이다. 주의해야 할 것은 업무로부터 분석한 속성이라도 이미 업무상 코드로 정의한 속성이 많다는 것이다. 이러한 경우도 속성의 값이 원래 속성을 나타내지 못하므로 기본속성이 되지 않는다.

; 설계속성
설계속성은 업무상 필요한 데이터 이외에 데이터 모델링을 위해, 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성이다. 대개 코드성 속성은 원래 속성을 업무상 필요에 의해 변형하여 만든 설계속성이고 일련번호와 같은 속성은 단일(Unique)한 식별자를 부여하기 위해 모델상에서 새로 정의하는 설계속성이다.

; 파생속성
파생속성은 다른 속성에 영향을 받아 발생하는 속성으로서 보통 계산된 값들이 이에 해당한다. 다른 속성에 영향을 받기 때문에 프로세스 설계 시 데이터 정합성을 유지하기 위해 유의해야 할 점이 많으며 가급적 파생속성을 적게 정의하는 것이 좋다.

이러한 분류 방식은 프로젝트에서 엄격하게 분류하여 속성 정의서에 나열하는 경우도 있다. 속성 정의서에 기록함으로써 향후 속성 값에 대한 검증 시 활용되기도 한다. 파생속성은 그 속성이 가지고 있는 계산방법에 대해서 반드시 어떤 엔티티에 어떤 속성에 의해 영향을 받는지 정의가 되어야 한다. 예를 들어 '이자'라는 속성이 존재한다고 하면 이자는 원금이 1,000원이고 예치 기간이 5개월이며 이자율이 5.0%에서 계산되는 속성 값이다. 그렇다면 이자는 원금이 1,000원에서 2,000원으로 변하여도 영향을 받고 예치기간이 5개월에서 7개월로 증가하여도 값이 변하며 이자율이 5.0%에서 6.0%로 되어도 이자 속성이 가지는 값은 변할 것이다. 한 번 값이 변해도 또 다시 영향을 미치는 속성의 조건이 변한다면 이자의 값은 지속적으로 변경될 것이다.
이와 같이 타 속성에 의해 지속적으로 영향을 받아 자신의 값이 변하는 성질을 가지고 있는 속성이 파생 속성이다. 파생 속성은 될 수 있으면 꼭 필요한 경우에만 정의하도록 하여 업무 로직이 속성 내부에 숨지 않도록 하는 것이 좋다. 파생 속성을 정의한 경우는 속성 정의서에 파생 속성이 가지는 업무로직을 기술하여 데이터의 정합성이 유지될 수 있도록 해야 하며 그 파생 속성에 원인이 되는 속성을 이용하는 모든 애플리케이션에서는 값을 생성하고, 수정하고 삭제할 때 파생 속성도 함께 고려해 주어야 한다. 파생 속성은 일반 엔티티에서는 많이 사용하지 않으며 통계관련 엔티티나 배치 작업이 수행되면서 발생되는 엔티티의 경우 많이 이용된다.<ref name="개요" />

; 기본키 속성
레코드를 식별하는 기본키(primary key)에 해당하는 속성

; 외래키 속성 
다른 테이블의 기본키를 참조하는 키 속성

; 일반 속성
기본키나 외래키를 제외한 속성

; 단일 속성
더 이상 쪼개질 수 없는 속성 

; 복합 속성 
속성값이 의미있는 값으로 쪼개질 수 있는 속성 

; 단일값 속성
하나의 원자값으로 구성된 속성 

; 다중값 속성 
동일 속성에 여러 개의 값으로 구성된 속성

=== 엔티티 구성방식 ===
; PK(Primary Key) 속성
엔티티를 유일하게 구분할 수 있는 속성을 PK 속성이라고 한다.

; FK(Foreign Key) 속성
다른 엔티티와의 관계에 있어서 포함된 속성을 FK 속성이라고 한다.<ref name="아지">아지^^*, 〈[http://blog.daum.net/s850322/25 개체와 속성 ]〉, 《다음 블로그》 </ref>

; 일반 속성
엔티티에 포함되어 있고, PK 또는 FK에 포함되지 않는 속성을 일반 속성이라고 한다.<ref name="doorbw">doorbw, 〈[https://doorbw.tistory.com/227 엔티티(ENTITY)와 속성(ATTRIBUTE)]〉, 《tistory》 </ref>

엔티티를 식별할 수 있는 속성을 PK(Primary Key)속성, 다른 엔티티와의 관계에서 포함된 속성을 FK(Foreign Key)속성, 엔티티에 포함되어 있고 PK, FK에 포함되지 않은 속성을 일반속성이라 한다. 또한 속성은 그 안에 세부 의미를 쪼갤 수 있는지에 따라 단순형 혹은 복합형으로 분류할 수 있다. 예를 들면 주소 속성은 시, 구, 동, 번지 등과 같은 여러 세부 속성들로 구성될 수 있는데 이를 복합 속성(Composite Attribute)이라 한다. 또한 나이, 성별 등의 속성은 더 이상 다른 속성들로 구성될 수 없는 단순한 속성이므로 단순 속성(Simple Attribute)이라 한다.
일반적으로 속성은 하나의 값을 가지고 있으나, 그 안에 동일한 성질의 여러 개의 값이 나타나는 경우가 있다. 이 때 속성 하나에 한 개의 값을 가지는 경우를 단일값(Single Value), 그리고 여러 개의 값을 가지는 경우를 다중값(Multi Value) 속성이라 한다. 주민등록번호와 같은 속성은 반드시 하나의 값만 존재하므로 이 속성은 단일값 속성(Single-Valued Attribute)이라 하고, 어떤 사람의 전화번호와 같은 속성은 집, 휴대전화, 회사 전화번호와 같이 여러 개의 값을 가질 수 있다. 자동차의 색상 속성도 차 지붕, 차체, 외부의 색이 다를 수 있다. 이런 속성을 다중값 속성(Multi-Valued Attribute)이라 한다. 다중값 속성의 경우 하나의 엔티티에 포함될 수 없으므로 1차 정규화를 하거나, 아니면 별도의 엔티티를 만들어 관계로 연결해야 한다.<ref name="개요" />

=== 특성 ===
; 1. 속성의 어원적 의미
속성이라는 의미에는 가공되지 않은 것이라는 의미도 포함되어 있다. 이 말은 곧 원천적인 것을 의미한다. 또한 고유한 성질이란 의미도 가지고 있는데 이 말은 남의 도움을 받지 않더라도 자기만이 가지고 있는 독자적인 성질이 반드시 있어야 함을 뜻한다. 혼자서도 독자적인 성질을 가지고 있느냐에 대한 문제는 절대적이 아니라 상대적이라는 것 때문에 판단이 쉽지 않다. 즉 어떤 시스템의, 어떤 엔티티에서, 어떤 목적으로 사용하려고 하느냐에 따라서 달라지기 때문에 사람의 종합적인 판단이 필요하다는 것이다. 이러한 속성의 어원적인 특징들은 속성 검증의 원칙으로도 사용된다.

; 2. 속성도 일종의 집합이다.
물리 데이터 모델링 단계에서 엔티티는 테이블이 되고, 속성은 칼럼이 된다. 결국 속성에는 데이터 값이 들어가게 되며, 그 값들은 여러 종류를 가지게 된다. 가령, 사원 정보 엔티티의 직책 속성에는 사원, 대리, 과장, 부장 … 등 여러 종류의 값들이 존재한다. 만약 이 값들의 종류 하나 하나를 개체 라고 한다면, 직책이란 속성은 결국 이들을 구성요소로 하는 집합이란 뜻이 된다.

; 3. 릴레이션십도 속성이다.
물리 데이터 모델링 단계에 가서 보면 릴레이션십 또한 결국은 일종의 속성이 될 수 밖에 없다.
물론, 원론적으로 본다면 이를 무조건 릴레이션십으로 표현하는 것이 옳다는 것에는 이견이 있을 수 없다. 왜냐하면 우리가 작성하는 논리적 데이터 모델이란 업무를 체계적으로 형상화하는 것이지 데이터베이스의 구조를 정의하는 것이 아니기 때문이다. 엄격히 말한다면 논리적 데이터 모델에는 데이터베이스나 컴퓨터와 같은 물리적 요소들은 전혀 감안하지 않은 상태에서 정의되어야 한다.

; 4. 속성들 간은 서로 독립적이다.
속성들은 반드시 식별자에 직접 종속되어야 한다. 이 말은 정규화의 제2정규형에 해당하는 말이 다. 만약 속성들 간에 종속성이 존재한다면 이들은 별도의 엔티티로 분리되어야 한다. 이것이 바로 제3정규형이다.<ref name="dbguide" />

== 도메인 ==
데이터 모델링 관점에 있어 도메인(Domain)은 데이터 표준화 측면에서 매우 중요한 요소다.
도메인이 체계화 및 표준화되지 않으면 물리 모델 구현 관점에서 속성과 엔티티의 이름이 표준화되지 않을 수 있고 데이터 타입의 정확성까지 잃을 수 있기 때문이다.
도메인은 동일한 테이블 타입을 가지는 속성을 분리하는 것을 의미한다. 이러한 도메인 분리 과정에는 일정한 규칙이 존재하는 데, 도메인은 크게 Unique identifier, 코드 속성, 일반 속성으로 분리할 수 있다.
대부분의 프로젝트에서는 굳이 도메인을 적용할 필요가 없다. 도메인 적용 여부에 따라 별다른 문제가 없기 때문이다.
그러나 도메인을 사용하면 동일하거나 유사한 속성에 동일한 데이터 타입을 할당할 수 있어 데이터의 일관성과 정합성을 유지할 수 있는 이점이 있다.
특히 데이터 모델링을 수행한 후 애플리케이션을 개발할 경우, 도메인 적용 유무가 때때로 큰 차이를 가져오곤 한다.<ref name="axiom" />

온라인 서점 시스템을 구현한다고 할 때, 소프트웨어로 해결하고자 하는 문제의 영역인 온라인 서점이 도메인이 된다
한 도메인은 다시 여러개의 하위 도메인으로 나뉠 수 있다. 
ex) 온라인 서점의 하위 도메인 : 상품, 회원, 주문, 정산, 배송 등등
모든 도메인마다 고정된 하위 도메인이 존재하는 것은 아니다. 상황에 따라 달라진다. 
대상이 기업인지, 사용자인지 등등
특정 도메인을 위한 소프트웨어라고 해서 도메인이 제공해야 할 모든 기능을 구현하는 것은 아니다.
외부 업체의 배송 시스템이나, 결제 시스템 같은것들을 이용한다.<ref name="joont92">joont92, 〈[https://joont92.github.io/ddd/%EB%8F%84%EB%A9%94%EC%9D%B8-%EB%AA%A8%EB%8D%B8/ 도메인 모델]〉, 《깃허브》, 2020-06-16 </ref>

=== 정의 방법 ===
1. 모든 속성을 엔티티별로 나열 <br>
2. 속성을 명사로 분리 (복합 명사인 경우 명사를 분리) <br>
3. 공통으로 발생하는 명사를 하나의 도메인으로 생성 (공통으로 발생하는 명사는 하나의 도메인으로 설정해 추후 동일한 데이터 타입을 할당) <br>
4. 각 도메인별로 데이터 타입과 길이를 지정 <br>
5. 각 엔티티의 속성에 도메인 할당 <br>

즉, 모든 속성을 나열하고 속성을 명사로 분리해야 한다. 이때, 보통 2〜3개의 명사로 속성을 나열하면 도메인 설정에 문제가 발생하지 않는다. 공통 도메인 사용 절차적으로 발생하는 명사를 하나의 도메인으로 생성해야 한다. 이 경우 최소 공배수를 구한 다음 해당 명사만으로 도메인을 구성하면 된다. 도메인은 크게 어렵지 않지만 표준화를 위해서는 이를 적용하는 것이 바람직하다. 이를 통해서만 실수를 줄이고 데이터의 정합성까지 유지할 수 있기 때문이다. <ref name="axiom">axiom, 〈[http://www.gurubee.net/lecture/2872 도메인의 개념을 이해하자]〉, 《구루비》, 2015-08-13 </ref>

=== 도메인 모델 ===
특정 도메인을 개념적으로 표현한 것이다. 이를 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고, 도메인 지식을 공유하는데 도움이 된다.

* 도메인을 이해하려면 도메인이 제공하는 기능과 주요 데이터 구성을 파악해야 한다.
* 보통은 기능과 데이터를 함꼐 보여주는 클래스 다이어그램이 적합하다.
* 꼭 UML만 사용해야 하는 것은 아니다. 도메인을 이해하는데 도움이 된다면 표현방식이 무엇인지는 중요하지 않다.
* 여러 하위 도메인을 하나의 다이어그램에 모델링하면 안된다.
* 각 하위 도메인마다 별도로 모델을 만들어야 한다.
* 모델의 각 구성요소는 특정 도메인을 한정할 때 비로소 의미가 완전해지기 때문이다.<ref name="joont92" />

=== 도메인 모델 패턴 ===
일반적인 어플리케이션의 아키텍쳐는 아래의 4계층으로 구성된다.

; Presentation(표현)
사용자의 요청을 처리하고 사용자에게 정보를 보여준다.
외부 시스템도 사용자가 될 수 있다.

; Application(응용)
사용자가 요청한 기능을 실행한다
업무 로직을 직접 구현하지 않으며 도메인 계층을 조합해서 기능을 실행한다.

; Domain(도메인)
시스템이 제공할 도메인의 규칙을 구현한다

; Intrastructure(인프라스트럭쳐)
외부 시스템과의 연동을 처리한다(DB, Messaging 등)

여기서 도메인 영역에 해당하는, 도메인의 규칙을 객체지향 기법으로 구현하는 패턴이 도메인 모델 패턴이다.

; 주의사항 
개념 모델을 만들때 처음부터 완벽하게 도메인을 표현하는 모델을 만드는 시도를 할 수 있지만 실제로 이는 불가능에 가깝다.
소프트웨어를 개발하는 동안 도메인을 점점 더 이해하게 되기 때문에, 시간이 지나감에 따라 모델을 수정하는 경우가 많기 때문이다.
그러므로 처음에는 개요 수준의 개념 모델을 작성하여 도메인에 대한 전체 윤곽을 이해하는데 집중하고, 구현하는 과정에서 개념 모델을 구현 모델로 점진적으로 발전시켜 나가야한다.<ref name="joont92" />

=== 도메인 모델 도출 ===
도메인을 모델링할 때 기본이 되는 작업은 모델을 구성하는 핵심 구성요소, 규칙, 기능을 찾는 것이다.
이는 모두 요구사항을 분석하면서 찾아낼 수 있다
* 요구사항을 통해 제공해야 하는 기능을 도출해낼 수 있다
출고 상태로 변경하기, 배송지 정보 변경하기 등
* 요구사항을 통해 특정 항목이 어떤 데이터로 구성되어야 하는지 알 수 있다
e.g. 한 상품을 한개 이상 주문할 수 있다
* 요구사항을 통해 각 항목간의 관계를 알 수 있다
e.g. 최소 한 종류 이상의 상품을 주문해야 한다
* 특정 조건이나 상태에 따라 제약이나 규칙이 달리 적용되는 경우도 많다
e.g. 출고를 하면 배송지 정보를 변경할 수 없다
* 요구사항을 이해하다 보면 설계가 바뀌는 경우가 종종 생긴다

; 문서화
코드는 상세한 모든 내용을 다루고 있기 때문에 코드를 이용해서 전체 소프트웨어를 분석하려면 많은 시간을 투자해야 한다.
전반적인 기능 목록이나 모듈 구조는 상위 수준에서 정리된 문서를 참조하는 것이 소프트웨어 전반을 빠르게 이해하는데 도움이 된다.
코드 자체도 문서화의 대상이 될 수 있다.
도메인 지식이 잘 묻어나고, 도메인을 잘 표현하도록 코드를 작성하면 코드의 가독성이 높아지면서 코드가 문서로서의 의미도 가지게 된다.<ref name="joont92" />

{{각주}}

==참고자료==
* 컴퓨터인터넷IT용어대사전, 〈[https://terms.naver.com/entry.nhn?docId=827902&cid=42344&categoryId=42344 로깅]〉, 《네이버 지식백과》, 2019-03-20
* 흠시 , 〈[https://dailyheumsi.tistory.com/162 [부스트코스 웹 프로그래밍] 로깅]〉, 《티스토리》, 2020-01-24
* doorbw, 〈[https://doorbw.tistory.com/227 엔터티(ENTITY)와 속성(ATTRIBUTE)]〉, 《tistory》

== 같이 보기 ==
* [[데이터베이스]]
* [[레코드]]
* [[필드 (데이터베이스)|필드]]

{{프로그래밍|검토 필요}}

[[분류:데이터베이스]]