[4] 엔터티의 분류
1. 유무형에 따른 분류
1) 유형엔터티(Tangible Entity)는 물리적인 형태가 있고 안정적이며 지속적으로 활용되는 엔터티이다.
ex. 사원, 물품, 강사
2) 개념엔터티(Conceptual Entity)는 물리적인 형태는 존재하지 않고 관리해야할 개념적 정보를 가지는 엔터티이다.
ex. 조직, 보험상품
3) 사건 엔터티(Event Entity)는 업무를 수행함에 따라 발생되는 비교적 발생량이 많고 각종 통계자료에 이용되는 엔터티이다.
ex. 주문, 청구, 미납
2. 발생시점에 따른 분류
1) 기본엔터티는 원래 업무에 존재하는 정보로써 다른 엔터티와 관계에 의해 생성되지 않으며 독립적으로 생성하고 자신은 타 엔터티의 부모 역할을 한다. 다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가진다.
ex. 사원, 부서, 고객, 상품, 자재
2) 중심엔터티는 기본엔터티로부터 발생되며 그 업무에 있어서 중심적인 역할을 한다. 데이터가 많이 발생되고 다른 엔터티와의 관계를 통해 많은 행위 엔터티를 생성한다.
ex. 계약, 사고, 예금원장, 청구, 주문, 매출
3) 행위엔터티는 두 개 이상의 부모엔터티로부터 발생되며 자주 내용이 바뀌거나 데이터가 증가한다. 분석초기 단계에서는 잘 나타나지 않으며 상세 설계단계나 프로세스와 상관모델링을 진행하면서 도출될 수 있다.
ex. 주문목록, 사원변경이력
3. 엔터티 분류 방법의 예
* 엔터티를 도출할 때 일정한 그룹에 의해 그룹화하면 도출작업에 효율적이다.
1) 유무형에 따라 분류
유형(사원, 물품), 사건(주문, 창구), 개념(조직, 장소)
2) 발생시점에 따라 분류
기본(사원, 부서), 중심(접수, 계약), 행위(주문내역, 계약진행)
[5] 엔터티의 명명
첫 번째. 가능한 현업업무에서 쓰는 용어를 사용한다.
두 번째. 가능한 약어를 사용하지 않는다.
세 번째. 단수명수를 사용한다.
네 번째. 모든 엔터티에서 유일한 이름이 부여되어야 한다.
다섯 번째. 엔터티 생성 의미대로 이름을 부여한다.
제3절 속성(Attribute)
[1] 속성(Attribute)의 개념
* 업무에서 필요로한다.
* 의미상 더 이상 분리되지 않는다.
* 엔터티를 설명하고 인스턴스의 구성요소가 된다.
업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위
더 이상 분리되지 않는 최소의 데이터 단위라는 것은 하나의 속성이 두 개의 의미를 가져서는 안 되는 것을 의미한다.
[2] 엔터티, 인스턴스와 속성, 속성값에 대한 내용과 표기법
업무에서는 엔터티와 인스턴스들이 어떤 특징과 성격의 데이터로 구성되는지를 파악하는 작업이 필요하다. 분석단계에서 엔터티 내에 존재하는 여러 개의 인스턴스가 가지는 동일한 성격이 무엇인지를 파악하고 이름을 부여하여 엔터티의 속성을 기술하는 작업이 필요하다.
1. 엔터티, 인스턴스, 속성, 속성값의 관계
* 한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 한다.
* 한 개의 엔터티는 두 개이상의 속성을 갖는다.
* 한 개 속성은 한 개의 속성값을 갖는다.
엔터티에는 두 개 이상의 인스턴스가 존재하고 각각의 엔터티에는 고유한 성격을 표현하는 속성정보가 두 개 이상 존재한다.
엔터티내에 있는 하나의 인스턴스는 각각의 속성들에 대해서 한 개의 속성값만을 가질 수 있다.
속성은 엔터티에 속한 엔터티에 대한 자세하고 구체적인 정보를 나타내며, 속성값은 각각의 엔터티가 가지는 속성들의 구체적인 내용이다.
ex. 홍길동이라는 사람(엔터티), 이름, 주소(속성), 홍길동, 서울시 강서구(속성값)
2. 속성의 표기법
속성의 표기법은 엔터티 내에 이름을 포함하여 표현하면 된다.
[3] 속성의 특징
첫 번째. 엔터티와 마찬가지로 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야한다.
두 번쨰. 정규화 이론에 근간하여 정해진 주식별자에 함수적 종속성을 가져야 한다.
세 번쨰. 하나의 속성에는 한 개의 값만 가진다. 하나의 속성에 여러 개의 값이 있는 다중값일 경우 별도의 엔터티를 이용하여 분리한다.
[4] 속성의 분류
1. 속성의 특성에 따른 분류
1) 기본속성(Basic Attribute) : 업무분석을 통해 바로 정의한 속성을 말한다. 엔터티에 가장 일반적이고 많은 속성을 차지한다.
2) 설계속성(Designed Attribute) : 원래 업무상 존재하지는 않지만 설계를 하면서 도출해내는 속성을 말한다. 업무를 규칙화하기 위해 정의한다.
ex. 코드성 속성
3) 파생속성(Derived Attribute) : 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성을 말한다. 파생속성은 가급적 적은 것이 좋다.
파생속성의 경우 계산된 로직을 속성의 정의서에 기록함으로써 속성값에 대한 검증시 활용하기도 하는데 이때, 계산방법이 어떤 엔터티의 어떤 속성에 영향을 받는지에 대한 정의가 포함되어야 한다. 또 데이터의 정합성이 유지되도록 하고 값을 생성, 수정, 삭제할 때 항상 고려해야 한다.
ex. 통계관련, 배치작업 엔터티에서 많이 이용
2. 엔터티 구성방식에 따른 분류
1) PK(Primary Key)속성 : 엔터티를 식별할 수 있는 속성을 말한다.
2) FK(Foreign Key)속성 : 다른 엔터티와의 관계에서 포함된 속성을 말한다.
3) 일반속성 : 엔터티에 포함되어 있고 PK, FK에는 포함되지 않은 속성을 말한다.
- 세부의미를 쪼갤 수 있는지에 따른 분류
복합 속성(Composite Attribute) : 주소 속성은 시, 구, 동, 번지 등과 같은 여러 세부 속성들로 구성될 수 있는 복합 속성이다.
단순 속성(Simple Attribute) : 나이, 성별 등의 속성은 더 이상 다른 속성들로 구성될 수 없는 단순 속성이다.
- 속성값의 개수에 따른 분류
단일값(Single Value) 속성 : 속성 하나에 한 개의 값을 가지는 속성을 말한다. ex. 주민등록번호
다중값(Multi Value) 속성 : 속성 하나에 여러 개의 값을 가지는 속성을 말한다. ex. 전화번호
[5] 도메인(Domain)
엔터티 내에서 속성에 대한 데이터 타입과 데이터의 크기(범위) 그리고 제약사항을 지정하는 것을 도메인이라고 한다.
[6] 속성의 명명(Naming)
용어사전 : 속성이름을 정확하게 부여하고 용어의 혼란을 없애기 위함
도메인정의 : 속성이 가지는 값의 종류와 범위를 명확하게 하기 위함
용어사전과 도메인정의를 사용하여 프로젝트를 진행하면 용어적 표준과 데이터타입의 일관성을 확보할 수 있다.
첫 번째. 해당업무에서 사용하는 이름을 부여한다.
두 번째. 서술식 속성명은 사용하지 않는다.
세 번째. 약어사용은 가급적 제한한다.
네 번째. 전체 데이터모델에서 유일성 확보하는 것이 좋다.
제4절 관계(Relationship)
[1] 관계의 개념
1. 관계의 정의
* 인스턴스 사이의 논리적인 연관성으로써 존재 또는 행위로써 서로에게 연관성이 부여된 상태
관계는 엔터티 간 연관성을 표현하기 때문에 엔터티의 정의나 속성 정의 및 관계 정의에 따라서 다양하게 변한다.
2. 관계의 페어링
* 어떤 엔터티 타입의 엔터티가 자기 자신 또는 다른 엔터티 타입의 엔터티와 업무적인 이유에 의해서 연결된 것을 페어링이라고 한다.
페어링의 집합은 관계로 표현하는데, 인스턴스가 각각 다른 종류의 관계를 가지고 있다면 두 엔터티 사이에 두 개 이상의 관계가 형성될 수 있다.
엔터티 내에 인스턴스와 인스턴스 사이에 관계가 설정되어 있는 것을 관계 페어링이라고 한다.
[2] 관계의 분류
관계는 어떤 목적으로 연결되었느냐에 따라 존재에 의한 관계와 행위에 의한 관계로 구분되어진다.
1. 존재에 의한 관계
ex. 사원이 부서에 항상 속해있다.
2. 행위에 의한 관계
ex. 주문은 고객이 주문을 할 때 발생된다.
- 연관관계(Association)와 의존관계(Dependency)
연관관계는 항상 이용하는 관계로 존재적 관계에 해당하고, 의존관계는 상대방 클래스의 행위에 의해 관계가 형성될 때 구분하여 표현한다.
연관관계는 실선으로 표현하며 소스코드에서 멤버변수로 선언하여 사용하고, 의존관계는 점선으로 표현하며 행위를 나타내는 코드인
Operation(Method)에서 파라미터 등으로 이용한다.
ERD(Entity Relationship Diagram)에서는 존재적 관계와 행위에 의한 관계를 단일화하여 구분하지 않지만,
Class Diagram에서는 이처럼 구분하여 연관관계와 의존관계로 표현한다.
[3] 관계의 표기법
1. 관계명(Membership) : 관계의 이름
엔터티가 관계에 참여하는 형태를 지칭한다. 각각의 관계는 두 개의 관계명을 가지고, 각각의 관계명에 의해 두 가지 관점으로 표현될 수 있다.
첫 번째. 관계시작점(The Beginning) : 관계가 시작되는 곳
두 번째. 관계끝점(The End) : 관계를 받는 곳
관계시작점과 관계끝점 모두 관계이름을 가져야 하며, 참여자의 관점에 따라 관계이름이 능동적(Active)이거나 수동적(Passive)으로 명명된다.
- 관계명의 명명규칙
1) 애매한 동사를 피한다. (구체적이지 않아서 어떠한 관계가 존재하는지 파악하기가 어렵다.)
2) 현재형으로 표현한다.
2. 관계차수(Cardinality) : 1:1, 1:M, M:N
두 개의 엔터티 간 관계에서 참여자 수를 표현한다. 한 개인지 두 개 이상인지 존재하는 관계의 개수를 파악하는 것이 중요하다.
까마기발 모델에서 한 개의 관계가 존재하는 경우는 실선을 그대로 유지하고 다수의 관계가 존재하는 경우(Many)는 까마귀발과 모양으로 그린다.
1) 1:1, 하나의 엔터티에 관계되는 엔터티의 관계가 하나인 경우
2) 1:M, 하나의 엔터티에 관계되는 엔터티의 관계가 여러 개인 경우 (반대 방향은 단지 하나만의 관계를 가진다.)
3) M:N, 여러 개의 엔터티에 관계되는 엔터티가 여러 개인 경우 (반대 방향도 동일하게 여러 개의 관계를 가진다.)
M:N 관계로 표현된 데이터 모델은 이후에 두 개의 주식별자를 상속받은 관계엔터티를 이용해서 3개의 엔터티로 구분하여 표현한다.
3. 관계선택사양(Optionality) : 필수참여관계, 선택참여관계
ex1. 반드시 지하철의 문이 닫혀야만 지하철은 출발한다. -> 지하철 출발과 지하철 문 닫힘은 필수적인(Mandatory) 연결 관계에 있다.
ex2. 지하철 방송 시점이 지연되어도 지하철 출발과는 연관되지 않는다. -> 지하철 출발과 지하철 방송은 선택적인(Optional) 관계에 있다.
필수 참여는 참여하는 모든 참여자가 반드시 관계를 가지는, 타 엔터티의 참여자와 연결이 되어야 하는 관계이다.
선택참여된 항목은 물리속성에서 외래 키(Foreign Key)로 연결될 경우 Null을 허용할 수 있는 항목이 된다.
ERD의 관계를 나타내는 선에서 필수참여는 아무런 표시를 하지 않고, 선택참여하는 엔터티 쪽을 원으로 표시한다.
만약 관계가 표시된 양쪽 엔터티 모두에 선택참여가 표시된다면 잘못되었을 확률이 크다.
[4] 관계의 정의 및 읽는 방법
1. 관계 체크사항
첫 번째. 두 개의 엔터티 사이에 관심있는 연관규칙이 존재하는가?
두 번째. 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
세 번째. 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
네 번째. 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?
2. 관계 읽기
첫 번째. 기준(Source) 엔터티를 한 개(One) 또는 각(Each)으로 읽는다.
두 번째. 대상(Target) 엔터티의 관계참여도 즉 개수(하나, 하나 이상)를 읽는다.
세 번째. 관계선택사양과 관계명을 읽는다.
관계를 정의한 사항에 대해서 뒷부분만 의문문으로 변경하면 바로 관계를 도출하기 위한 질문 문장으로 만들 수 있다.
이러한 질문 방법은 실제 프로젝트에서 엔터티 간 관계설정 뿐만 아니라 업무의 흐름 분석에도 도움이 된다.
제5절 식별자
[1] 식별자(Identifiers) 개념
여러 개의 집합체(인스턴스)를 담고 있는 하나의 통(집합)에서 각각을 구분할 수 있는 논리적인 이름이 필요한데 이를 식별자라고 한다.
식별자는 하나의 엔터티에 구성되어 있는 여러 개의 속성 중 엔터티를 대표할 수 있는 속성을 의미하며, 하나의 엔터티는 반드시 하나의 유일한 식별자가 존재해야 한다. 식별자는 논리 데이터 모델링 단계에서 사용하고 키는 물리 데이터 모델링 단계에서 사용하는 것으로 구분한다.
[2] 식별자의 특징
- 주식별자일 경우
첫 번째. 주식별자에 의해 엔터티내에 모든 인스턴스들을 유일하게 구분해야 한다. (유일성)
두 번째. 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다. (최소성)
세 번째. 지정된 주식별자의 값은 변하지 않는 것이어야 한다. ( 불변성)
네 번쨰. 주식별자가 지정이 되면 반드시 값이 들어와야 한다. (Null 안됨)
대체식별자는 주식별자의 특징과 일치하지만 외부식별자는 주식별자와 다르게 참조무결성 제약조건에 따른 특징을 가진다.
[3] 식별자 분류 및 표기법
1. 식별자 분류
- 엔터티 내에서 대표성을 가지는가에 따라 주식별자(Primary Identifier)와 보조식별자(Alternate Identifier)로 구분 (대표성 여부)
- 엔터티 내에서 스스로 생성되었는지에 따라 내부식별자(Internal Identifier)와 외부식별자(Foreign Identifier)로 구분 (스스로 생성 여부)
- 단일 속성으로 식별이 되는가에 따라 단일식별자(Single Identifier)와 복합식별자(Composit Identifier)로 구분 (단일 속성 여부)
- 업무적으로 의미가 있는 식별자 속성을 대체하여 일련번호처럼 새롭게 만든 식별자를 구분하기 위해 본질식별자와 인조식별자로 구분 (대체 여부)
2. 분류별 식별자의 설명
[4] 주식별자 도출기준
1. 해당 업무에서 자주 이용되는 속성을 주식별자로 지정한다.
- 직원이라는 엔터티에 식별가능한 유일한 속성으로 주민등록번호와 사원번호가 존재한다. 업무에서 사원번호가 흔히 사용되므로,
사원번호를 주식별자로 지정하고 주민등록번호를 보조식별자로 지정한다.
2. 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않는다.
- 부서이름을 주식별자로 지정했을 때, 부서이름을 WHERE 조건 절에 기재하게 되는데 조건 절에 정확한 부서이름을 기재하는 것이 쉽지 않다.
이러한 경우, 일련번호나 코드를 이용하여 새로운 식별자를 생성하도록 한다.
3. 복합으로 주식별자를 구성할 경우 너무 많은 속성이 포함되지 않도록 한다.
- 주식별자의 속성 개수가 많으면(일반적으로 7개 이상) 기본 키(Primary Key)가 7개 이상 생성될 것이고 하나의 데이터만 가져오려 해도 복잡한 SQL문장을 구사해야 한다. 이러한 경우, 새로운 인조식별자(Artificial Identifier)를 생성하여 데이터 모델을 구성하는 것이 데이터 모델을 한층 더
단순하게 만들고 애플리케이션을 개발할 때 조건 절을 단순하게 할 수 있다.
문장의 간편성 뿐만 아니라 복잡한 소스 구성을 피하기 위해 과도한 복합키는 배제한다.
[5] 식별자관계와 비식별자관계에 따른 식별자
1. 식별자관계와 비식별자 관계의 결정
* 엔터티 사이 관계유형은 업무특징, 자식엔터티의 주식별자 구성, SQL 전략에 의해 결정된다.
2. 식별자 관계
* 자식엔터티의 주식별자로 부모의 주식별자가 상속이 되는 경우를 식별자 관계(Identifying Rlationship)라고 한다.
부모로부터 받은 식별자를 자식엔터티의 주식별자로 이용하는 경우는 Null 값이 오면 안되므로 반드시 부모엔터티가 생성되어야 자기 자신의 엔터티가 생성되는 경우이다. 부모로부터 받은 속성을 자식엔터티가 모두 사용하고 그것만으로 주식별자로 사용한다면 부모엔터티와 자식엔터티의 관계는 1:1이 될 것이고 만약, 부모로부터 받은 속성을 포함하여 다른 부모엔터티에서 받은 속성을 포함하거나 스스로 가지고 있는 속성과 함께 주식별자로 구성되는 경우는 1:M이 된다.
3. 비식별자 관계
* 부모엔터티로부터 속성을 받았지만 자식엔터티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 경우를 비식별자 관계(Non-Identifying Relationship)라고 한다.
- 비식별자 관계에 의한 외부속성을 생성하는 경우
1) 자식엔터티에서 받은 속성이 반드시 필수가 아니어도 무방하기 때문에 부모 없는 자식이 생성될 수 있는 경우이다.
2) 엔터티별로 데이터의 생명주기(Life Cycle)를 다르게 관리할 경우이다.
ex. 부모엔터티에 인스턴스가 자식의 엔터티와 관계를 가지고 있었지만 자식만 남겨두고 먼저 소멸될 수 있는 경우가 해당된다.
이에 대한 방안으로 물리데이터베이스 생성 시 Foreign Key를 연결하지 않는 임시적인 방법을 사용하기도 하지만,
데이터모델 상에서 관계를 비식별자관계로 조정하는 것이 가장 좋은 방법이다.
3) 여러 개의 엔터티가 하나의 엔터티로 통합되어 표현되어있는데 각각의 엔터티가 별도의 관계를 가지는 경우이다.
4) 자식엔터티에 주식별자로 사용해도 되지만 자식엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단될 때 비식별자 관계에 의한 외부식별자로 표현한다.
4. 식별자 관계로만 설정할 경우의 문제점
* 부모에서 자식으로 식별자 관계가 연결됨으로 인해 주식별자의 속성 수가 많아지게 된다.
식별자 관계만으로 연결된 데이터 모델은 주식별자 속성이 지속적으로 증가할 수 밖에 없고, 이는 개발의 복잡성과 오류가능성의 유발로 이어진다.
[데이터 전문가 포럼] SQL 개발자 스터디 교재(2020.08.22.)
#SQLD