데이터 모델링의 3요소
| 복수/집합 type/class |
개별/단수 | |
| 업무가 관여하는 어떤 것 things | 엔터티 타입 entity type | 엔터티 entity |
| 엔터티 entity | 인스턴스 instance 어커런스 occurrence |
|
| 어떤 것 간의 관계 relationships | 관계 relationship | 패어링 pairing |
| 어떤 것이 가지는 성격 attributes | 속성 attribute | 속성값 attribute value |
엔터티 entity
엔터티는 저장이 되기 위한 어떤 것 things 으로, 명사에 해당한다.
엔터티는 인스턴스의 집합으로, 해당 업무에서 필요하고 관리하고자 하는 정보여야 한다. 고로 업무 프로세스는 반드시 해당 엔터티를 이용해야 한다. 인스턴스 각각을 구분하기 위한 유일한 식별자(PK)가 존재해야 하며 반드시 속성을 포함하고 있어야 한다. 다른 엔터티와 최소 한 개 이상의 관계가 존재해야 한다.
엔터티의 이름을 지을때는 가능하다면 약어의 사용을 지양하고 현업 업무에서 사용하는 용어를 사용해야 한다. 단수명사를 사용하되 모든 엔터티에서 유일하게 이름이 부여되어야 한다.
엔터티의 분류
엔터티는 유형/무형에 따른 분류와 발생시점에 따른 분류로 나눌 수 있다.
유형/무형에 따른 분류
- 유형 : 물리적인 형태가 있고 안정적이며 지속적으로 활용되는 엔터티로, 업무로부터 엔터티를 구분하기 가장 용이하다.
사원, 물품 등이 이에 속한다. - 개념 : 물리적인 형태는 존재하지 않고 관리해야 할 개념적인 정보로 구분이 되는 엔터티이다.
부서, 사업자 번호 등이 이에 속한다. - 사건 : 업무를 수행함에 따라 발생되는 엔터티로, 비교적 발생량이 많으며 각종 통계자료에 이용될 수 있다.
주문, 계약 등을 예로 들 수 있다.
발생시점에 따른 분류
- 기본(키) : 업무에 원래 존재하는 정보로서, 다른 엔터티와의 관계에 의해 생성되지 않고 독립적으로 생성이 가능하고 자신은 타 엔터티의 부모 역할을 하게 된다.
사원, 고객, 부서, 상품 등이 이에 속한다. - 중심(메인) : 기본 엔터티로부터 발생되는 엔터티로, 그 업무에 있어서 중심적인 역할을 한다.
계약, 청구, 주문, 매출 등이 이에 속한다. - 행위(액션) : 두 개 이상의 부모 엔터티로부터 발생되고 자주 내용이 바뀌거나 데이터량이 증가한다.
주문 목록 등을 예로 들 수 있다.
속성 attribute
속성은 인스턴스에서 더 이상 분리되지 않는 최소의 데이터 단위를 의미한다. 엔터티를 설명하고 인스턴스의 구성요소가 된다. 이름, 주소, 생년월일과 같은 각각의 값을 대표하는 이름들을 속성이라 하고 그 이름에 대한 구체적인 값을 속성값이라고 한다.
속성은 엔터티와 마찬가지로 해당 업무에서 필요하고 관리하고자 하는 정보여야 한다. 한 개의 엔터티는 두 개 이상의 인스턴스의 집합이다. 한 개의 엔터티는 두 개 이상의 속성을 갖고 한 개의 속성은 하나의 속성값을 갖는다.
속성의 표기할 때에는 속성명을 기재하고, 해당 속성이 식별자인지 아닌지 표시하고(#) 해당 속성이 필수값(*)인지 선택값(O)인지 표시한다.
각 속성은 가질 수 있는 값의 범위가 정해져있는데, 이를 그 속성의 도메인이라 한다. 예를 들어 학생이라는 엔터티가 있을 때, 학점이라는 속성의 도메인은 0.0부터 4.5 사이의 실수 값이다.
속성은 특성에 따른 분류와 엔터티 구성 방식에 따른 분류로 나눌 수 있다.
특성에 따른 분류
- 기본 속성 : 업무 분석을 통해 바로 정의한 속성
- 설계 속성 : 원래 업무 상 존재하지는 않지만, 설계를 하면서 도출해내는 속성
- 파생 속성 : 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성
엔터티 구성 방식에 따른 분류
- PK 속성 : primary key
- FK 속성 : foreign key
- 일반 속성
관계 relationship
관계는 인스턴스 사이의 존재의 형태나 행위에 의하여 서로에게 논리적인 연관성이 부여된 상태라고 할 수 있다. 인스턴스와 인스턴스 사이 간 관계가 설정되어 있는 어커런스를 관게 패어링 pairing 이라고 한다. 관계는 이 패어링의 집합을 의미한다.
관계명 membership
엔터티가 관계에 참여하는 형태를 지칭한다. 각각의 관계는 두 개의 관계명을 가지고 있으며, 각각의 관계명에 의해 두 가지의 관점으로 표현될 수 있다.
관계차수 cardinality
One to One, One to Many, Many to Many
관계선택사양 optionality
필수 참여 관계와 선택 참여 관계
예를 들어 고객과 주문 사이의 관계를 정의한다면, 고객은 주문에게 있어 필수적인 관계이지만 주문은 고객에게 있어 선택적인 관계가 된다. 필수적인 관계를 필수참여관계, 선택적인 관계를 선택참여관계 라고 한다.
관계를 읽을 때에는 기준 엔터티를 한 개 또는 각 each 으로 읽는다. 대상 엔터티는 관계 참여도의 개수를 읽는다. 그리고 관계선택사양과 관계 명을 읽는다. 위에 예로 든 고객과 주문 사이의 관계를 읽는다면, 각각의 고객은 여러개의 주문을 때때로 주문한다 / 각각의 주문은 하나의 고객을 반드시 가진다 라고 읽을 수 있다.
식별자
엔터티 내에서 각각의 인스턴스들을 구분할 수 있는 논리적인 이름이 필요하다. 이 구분자를 식별자라고 한다.
주식별자에 의해 엔터티내의 모든 인스턴스들이 유일하게 구분되어야 한다. 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다. 지정된 주식별자의 값은 자주 변하지 않는 것이어야 하며, 주식별자가 지정이 되면 반드시 값이 들어와야 한다. 이를 순서대로 유일성, 최소성, 불변성, 존재성이라고 한다. 불변성의 예로는 사원번호를 들면 된다. 사원번호 같은 경우는 값이 절대 변하지 않기 때문이다. (변하는 경우는 재입사...?ㅎ_ㅎ)
업무에서 자주 이용되는 속성을 주식별자로 지정하되 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않는다. 복합으로 주식별자를 구성할 경우 문장의 간편성 뿐만 아니라 복잡한 소스구성을 피하기 위해서라도 너무 많은 속성이 포함되지 않도록 주의한다.
식별자의 분류
| 분류 | 식별자 | 설명 |
| 대표성 여부 | 주식별자 | 타 엔터티와 참조관계를 연결할 수 있는 식별자 |
| 보조식별자 | 대표성을 가지지 못해 참조 관계 연결을 못하는 식별자 | |
| 스스로 생성 여부 | 내부식별자 | 엔터티 내부에서 스스로 만들어지는 식별자 |
| 외부식별자 FK | 타 엔터티와의 관계를 통해 타 엔터티에서 받아오는 식별자 | |
| 속성의 수 | 단일식별자 | 하나의 속성으로 구성된 식별자 |
| 복합식별자 | 둘 이상의 속성으로 구성된 식별자 | |
| 대체여부 | 본질식별자 | 업무에 의해 만들어지는 식별자 |
| 인조식별자 | 업무적으로 만들어지지는 않지만 원조식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만든 식별자 |
식별자의 관계
자식 엔터티의 주식별자로 부모 엔터티의 주식별자가 상속이 되는 경우를 식별자 관계, 부모 엔터티로부터 속성을 받았지만 주식별자로 사용하지 않고 부모와 연결이 되는 속성으로만 이용하게 되면 비식별자 관계라고 한다.
식별자 관계 만으로 연결된 데이터 모델은 주식별자 속성은 지속적으로 증가할 수 밖에 없는 구조로, 개발의 복잡성과 오류 가능성을 유발시킬 수 있다. 반면에 비식별자 관계로만 설정하면, 속성이 자식 엔터티로 상속되지 않아 자식 엔터티에서 데이터를 처리할 때 부모 엔터티를 참조해야 하므로 많은 join 이 발생하여 성능이 저하되는 문제가 발생할 수 있다. 따라서 실제로 프로젝트를 전개할 때에는 식별자 관계와 비식별자 관계를 취사 선택하여 연결하는 것이 높은 수준의 데이터 모델링 기술이라고 볼 수 있겠다.
어떤 관계를 선택해야 하는지에 대한 고려는 아래의 표와 이미지의 조건들을 따져 결정한다.
| 식별자 관계 | 비식별자 관계 | |
| 목적 | 강한 연결관계 표현 | 약한 연결관계 표현 |
| 자식 주식별자 영향 | 자식 주식별자의 구성에 포함됨 | 자식 일반 속성에 포함됨 |
| 연결 고려사항 | 반드시 부모 엔터티에 종속 상속받은 주식별자 속성을 타 엔터티에 이전할 필요가 있음 |
부모 쪽의 관계 참여가 선택관계일 수 있음 상속받은 주식별자 속성을 타 엔터티에 차단 |
