엔티티(Entity)
엔티티의 사전적인 의미는 '독립체'이다. 데이티베이스에서의 엔티티는 식별이 가능한 객체라는 의미를 가지고 있다.
즉, 업무에 필요하고 유용한 정보를 용도별로 분류한 그룹이라고 할 수 있다.
엔티티의 특징
- 반드시 해당 업무에서 쓰이는 정보여야 한다.
- 유니크함(유일한 식별자)을 보장할 수 있어야 한다.
- 2개 이상의 인스턴스를 가지고 있어야 한다.
- 반드시 속성을 가지고 있어야 한다.
- 다른 엔티티와 1개 이상의 관계를 가지고 있어야 한다.
업무에서 쓰이는 정보여여 한다.
실질적으로 업무에서 쓰이는 정보여야 엔티티로 도출하는 의미가 있다. 업무에서 필요로 하고 관리하고 하는 정보이며 업무 프로세서에 의해 이용되어어야 한다.
유니크함을 보장할 수 있어야 한다.
Unique Identifier에 의해 식별이 가능해야 한다. 식별자는 고유해야 하며 중복이 발생해서는 안된다. 부여된 식별자를 통해 엔티티의 인스턴스가 한 개씩 식별되는지 검증되어야 한다.
2개 이상의 인스턴스를 가지고 있어야 한다.
엔티티의 값이 1개로 쭉 이어진다면 이 값은 굳이 엔티티로 만들 필요가 없다. 엔티티의 인스턴스는 최소한 두 개 이상의 집합이어야 한다.
반드시 속성을 가지고 있어야 한다.
속성이 없는 엔티티는 깡통 휴대폰과 같다. 엔티티는 반드시 자신을 상세하게 나타낼 수 있는 속성을 가지고 있어야 한다.
다른 엔티티와 1개 이상의 관계를 가지고 있어야 한다.
각각의 엔티티는 다른 엔티티와의 연관성을 가지고 있어야 한다. 예를 들면 회원 엔티티는 주문 엔티티와 관계가 있고 주문 엔티티는 상품 엔티티와 관련이 있다.
엔티티의 분류
유무형에 따른 분류
- 유형 엔티티
물리적인 형태로 존재, 안정적 및 지속적으로 활용되는 엔티티이다.
업무로부터 엔티티를 구분하기가 가장 용이하다.
예) 상품, 회원 - 개념 엔티티
물리적인 형태가 없고 관리해야 할 개념적 정보로 구분이 되는 엔티티
예) 부서, 학과 - 사건 엔티티
행위를 함으로써 발생되는 엔티티
비교적 발생량이 많으며 각종 통계자료에 이용될 수 있다.
예) 주문, 청구, 미납
발생시점에 따른 분류
- 기본 엔티티
해당 업무에 원래 존재하는 정보
다른 엔티티와의 관계에 의해 생성되지 않고 독립적으로 생성이 가능하다.
업부로부터 엔티티를 구분하기가 가장 용이하다.
예) 사원, 물품, 강사 - 중심엔티티
기본 엔티티로부터 발생한다.
해당 업무에 있어 중심적인 역할을 한다.
데이터양이 많이 발생하고, 다른 엔티티와의 관계를 통해 많은 행위 엔티티를 생성한다.
예) 계약, 사고, 예금원장, 청구, 주문, 매출 - 행위 엔티티
두 개 이상의 부모 엔티티로부터 발생한다.
자주 내용이 바뀌거나 데이터량이 증가한다.
분석 초기에는 잘 나타나지 않으며, 상세 설계단계나 프로세스와 상관 모델링을 진행하면서 도출된다.
예) 주문목록, 사원변경이력
명명규칙
- 업무에서 쓰이는 용어 사용
- 헌글은 약어를 사용하지 않고 영문은 대문자로 표기
- 단수 명사를 사용
- 모든 엔티티에서 유일하게 부여되는 이름이어야 한다.
- 엔티티 생성 의미대로 이름을 부여한다. (해당 엔티티가 갖고 있는 데이터가 무엇인지 명확하게 표현)
속성(Attribute)
속성은 의미상 더 이상 쪼개지지 않는 레벨이어야 하고 프로세스에 필요한 항목이어야 한다.
- 사물의 성질, 특징 또는 본질적인 성질
- 업무상 관리하기 위한 최소의 의미 단위
- 업무에서 필요로 한다.
- 의미상 더 이상 분리되지 않는다.
- 엔터티를 설명하고 인스턴스의 구성요소가 된다.
예를 들어, 아티스트에게는 이름, 생년월일, 소속사, 데뷔 연도 등의 수식어가 붙는데 이와같이 사물이나 개념의 특징을 설명해줄 수 있는 항목을 속성이라 부른다.
속성값
각각의 속성은 속성값을 가지며 속성값은 엔티팉에 속한 하나의 인스턴스를 구체적으로 나태내주는 데이터라고 볼 수 있다.
하나의 속성은 한 개의 속성값을 가지고 있다. 만약 하나의 속성의 여러 값이 들어간다면 별도의 엔티티로 분리하는 것이 바람직하다.
엔티티, 인스턴스, 속성, 속성값의 관계
- 한 개의 인스턴스는 두 개 이상의 인스턴스를 갖는다.
- 한 개의 인스턴스는 두 개 이상의 속성을 갖는다.
- 한 개의 속성은 하나의 속성값을 갖는다.
분류
특성에 따른 분류
- 기본속성(Basic Attribute) : 업무 프로세스 분석을 통해 바로 정의가 가능한 속성
- 설계속성(Designed Attribute) : 업무에 존재하지는 않지만 설계하다 보니 필요하다고 판단되어 도출해낸 속성
- 파생속성(Derived Attribute) : 다른 속성의 속성값을 계산하거나 특정한 규칙으로 변형하여 생성한 속성
기본속성
엔티티 중에 가장 일반적인 속성으로 업무 프로세스 분석을 통해 바로 정의가 가능한 속성들이다. 엔티티에서 가장 많은 퍼센티지를 차지하는 속성이며, 일부 설계속성이나 파생속성을 제외한 모든 속성이 기본속성에 해당한다고 보면 된다.
설계속성
업무에는 존재하지 않지만 설계 과정에서 합리적인 모델링을 위해 만들어진 속성이다. 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성이다.
학번, 코드성 속성, 일련번호 등이 있다.
파생속성
다른 속성에 영향을 받아 발생하는 속성이다. 보통 계산된 값이나 가공된 값이 이에 속한다. 특정 엔티티의 값들을 계산함으로 정합성을 유지해야한다. 그러므로 무분별하게 사용하기 보단 꼭 필요한 부분에 사용해야한다.(가급적 적게 정의)
주로 주문값에 값 합산이나 통계 관련에 사용된다.
구성 방식에 따른 분류
엔티티를 식별에 따른 분류
- PK 속성 : 엔티티를 식별할 수 있는 속성
- FK 속성 : 다른 엔티티와의 관계에서 포함된 속성(다른 엔티티의 속성에서 가져온 속성)
- 일반 속성 : 엔티티에 포함되어 있고, PK, FK를 제외한 나머지 속성
PK 속성
엔티티에 속한 각 인스턴스에 유니크함을 부여한 속성이다. 상품 엔티티의 상품 코드, 학생 엔티티의 학번, 직원 엔티티의 사번 등이 이에 속한다.
FK 속성
다른 엔티티와 관계를 맺게 해주는 매개체 역할을 하는 속성이다. 직원 엔티티의 부서코드, 학생 엔티티의 학과코드, 회원엔티티의 회원등급코드 등이 이에 속한다.
일반속성
PK, FK를 제외한 나머지 속성을 일반속성이라고 부른다. 상품 엔티티의 상품명, 가격, 학생엔티티의 이름, 생년월일 등이 이에 속한다.
도메인(Domain)
각 속성이 가질 수 있는 값의 범위이다. 속성들은 도메인 이외의 값은 가지지 못한다. 엔터티 내에서 속성에 대한 데이터 타입과 크기, 그리고 제약사항을 지정하는 것이다.
속성의 명명
- 속성명은 곧 사용자 인터페이스에 나타나기 때문에 업무와 직결되는 항목이다.
- 속성 이름을 정확하게 부여하고 용어의 혼란을 없애기 위해 용어사전 이라는 업무 사전을 프로젝트에 사용하게 된다.
- 각 속성이 가지는 값의 종류와 범위를 명화하게 하기 위해 도메인 정의를 미리 한다.
- 용어사전과 도메인 정의를 사용하면 데이터 타입의 일관성을 확보할 수 있게 된다.
속성명 부여 원칙
- 해당 업무에서 사용하는 이름을 부여 한다.
- 서술식 속성명은 사용하지 않는다.
- 약어 사용은 가급적 제한한다.
- 전체 데이터 모델에서 유일성 확보하는 것이 좋다.
- 반정규화를 적용할 때 속성명의 충동을 해결하여 안정적으로 반정규화를 적용할 수 있게 된다.
관계(Relationship)
엔티티와 엔티티와의 관계를 의미하며, 어떠한 연관성이 있는지 타입을 분류하여 존재 관계와 행위 관계로 나눌 수 있다.
- 상호 연관성이 있는 상태
- 엔터티와 엔터티 간 연관성을 표현하기 때문에 엔터티의 정의에 따라 영향을 받기도 하고,
- 속성 정의 및 관계 정의에 따라서도 다양하게 변할 수 있다.
존재관계
엄마와 아기처럼 존재 자체로 연관성이 있는 관계를 의미한다. 예를 들어 직원과 부서, 학생과 학과 엔티티가 이에 속한다.
행위 관계
특정한 행위를 함으로써 연관성이 생기는 관계이다. 예를 들어 회원과 주문, 학생과 출석부 엔티티가 이에 속한다.
표기법
- 관계명 (Membership)
- 관계의 이름
- 관계 차수 (Cardinality)
관계가 참여하는 수
- 1 : 1
- 1 : M
- M : N
- 관계 선택 사양 (Optionality)
- 필수 관계
- 선택 관계
관계명
엔티티와 엔티티가 어떠한 관계를 맺고 있는지를 나타내주는 문장이다. 모든 관계는 두 개의 관계명을 가지고 있는데 이유는 각 엔티티의 관점에서 관계명을 하나씩 가지기 때문이다.
관계명은 반드시 명확한 문장으로 표현해야 하며 현재형이어야 한다.
바람직하지 않은 관계명 | 바람직한 관계명 |
연관성이 있다. 관계가 있다. 출석을 했다. |
주문한다. 소속된다. 출석을 한다. |
관계차수
각 엔티티에서 관계에 참여하는 수를 의미하며 일반적으로 1:1, 1:M, M:N 형식으로 구분할 수 있다.
관계선택사양
필수적관계 | 참여자가 반드시 존재해야 하는 관계 |
선택적관계 | 참여자가 없을 수도 있는 관계 |
관계선택사양은 이 관계가 필수요소인지 선택사항인지를 나타내는 말이다. 예를들어 주문은 반드시 하나 이상의 주문상품이 있어야한다. 이러면 주문과 주문상품은 필수적관계이다. 하지만 학생과 출석부관계에서는 학생의 출석여부를 학생의 선택사항이므로 선택적관계라고 볼 수 있다.
필수적 관계는 위처럼 1~N개이며 선택적관계에서는 0~N개로 표현된다.
식별자(Identifiers)
모든 엔티티는 인스턴스를 가지고 있고 인스턴스는 속성으로 자신의 특성을 나타낸다. 식별자가는 이러한 속성 중에 각각의 인스턴스를 구분 가능하게 만들어주는 대표 속성이다.
주식별자
주식별자는 기본키, PK에 해당하는 속성이다. 하나의 속성이 주식별자가 될 수 있고, 여러 개의 속성이 주 식별자가 될 수도 있다.
- 유일성 : 각 인스턴스에 유니크함을 부여하여 식별이 가능하도록 한다.
- 희소성 : 유일성을 보장하는 최소 개수의 속성이어야 한다.
- 불변셩 : 속성값이 되도록 변하지 않아야 한다.
- 존재성 : 속성값이 NULL 일 수 있다.
분류
- 대표성여부
- 스스로 생성되었는지 여부
- 단일 속성의 여부
- 대체 여부
대표성여부
주식별자 | - 유일성, 희소성, 불변성, 존재성을 가진 대표 식별자 - 다른 엔티티와 참조 관계로 연결 |
보조식별자 | - 인스턴스를 식별할 수는 있지만 대표 식별자는 아니다. - 다른 엔티티와 참조 관계로 사용하지 않는다. |
스스로 생성되었는지 여부
내부식별자 | 엔티티 내부에서 스스로 생성된 식별자 |
외부식별자 | 다른 엔티티에서 온 식별자, 다른 엔티티와의 연결고리 역할 |
단일 속성의 여부
단일식별자 | 하나의 속성으로 구성된 식별자 |
복합식별자 | 두 개 이상의 속성으로 구성된 식별자 |
대체여부
원조식별자 | 업무 프로세스에 존재하는 식별자, 가공되지 않은 원래의 식별자 |
대리식별자 | 주식별자의 속성이 두 개이상인 경우, 그 속성들을 하나로 묶어서 사용하는 식별자 |
식별자 관계 vs 비식별자 관계
식별자관계
부모엔티티의 식별자가 자식 엔티티의 주식별자가 되는 관계이다. 그렇기때문에 주식별자(부모엔티티)가 반드시 존재하여야하며 단일식별자인지 복합식별자인지에 따라 1:1 또는 1:M이 된다.
비식별자관계
부모엔티티의 식별자가 자식 엔티티의 주식별자가 아닌 일반 속성으로 들어가는 관계이다. 그렇기때문에 자식엔티티에서 주식별자 값이 존재하지 않아도되며(NULL), 부모 엔티티가 없는 자식엔티티도 생성이 가능하다. 자식엔티티가 존재한 상태에서 부모엔티티 삭제도 가능하다.
'DB' 카테고리의 다른 글
[DB/SQLD] 데이터 모델링의 이해 (1) (0) | 2023.11.10 |
---|---|
[DB] 커넥션 풀의 이해 (0) | 2023.11.02 |