티스토리 뷰
1. 식별자의 개념
▷ Identifiers ( 식별자 )
: 하나의 엔터티에 구성되어 있는 여러 개의 속성 중에, 엔터티를 대표할 수 있는 속성
반드시 하나의 엔터티는 하나의 유일한 식별자가 존재한다.
식별자는 업무적으로 구분이 되는 정보로, 논리 데이터 모델링 단계에서 사용한다.
엔터티 내에서 인스턴스들을 구분할 수 있는 구분자이다.
2. 식별자의 특징
식별자는 주식별자 / 대체식별자 / 외부식별자 로 본다.
※ 주식별자의 특징
: 유일성 / 최소성 / 불변성 / 존재성
◈ 주식별자에 의해 엔터티내에 모든 인스턴스들이 유일하게 구분되어야 한다.
◈ 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
◈ 지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다.
◈ 주식별자가 지정이 되면 반드시 값이 들어와야 한다.
※ 대체식별자의 특징
: 주식별자의 특징과 일치한다.
※ 외부식별자의 특징
: 주식별자 특징과 일치하지 않는다. 참조무결성 제약조건 (Referential Integrity) 에 따른 특징을 가진다.
3. 식별자 분류 및 표기법
① 식별자 분류
주식별자 - 보조식별자 / 내부식별자 - 외부식별자 / 단일식별자 - 복합식별자 / 본질식별자 - 인조식별자
( 대표성 ) ( 스스로 생성 ) ( 속성의 수 ) ( 대체 여부 )
(1) 주식별자 - 보조식별자
: 자신의 엔터티 내에서 대표성을 가지는가 여부
(2) 내부식별자 - 외부식별자
: 엔터티 내에서 스스로 생성되었는지 여부
(3) 단일식별자 - 복합식별자
: 단일 속성으로 식별이 되는지 여부
(4) 본질식별자 - 인조식별자
: 원래 업무적으로 의미가 있던 식별자 속성을 대체하여 새로운 식별자 (일련번호)로 구분의 여부
② 식별자 표기법
4. 주식별자 도출기준
주식별자 도출작업
: 데이터 모델링 작업에서 중요한 작업이다.
◈ 해당 업무에서 자주 이용되는 속성을 주식별자로 지정한다.
◈ 이름으로 기술되는 것은 주식별자로 지정하지 않는다.
◈ 복합으로 주식별자로 구성할 경우 너무 많은 속성이 포함되지 않도록 한다.
① 해당 업무에서 자주 이용되는 속성을 주식별자로 지정하도록 함
'직원' 엔터티에서 '사원번호' 와 '주민번호' 가 식별가능한 속성이다. 직원 관리에서 주민번호 보다는 '사원번호'를 더 자주 사용되므로 '사원번호'를 주식별자로 지정, '주민번호'를 보조식별자로 지정한다.
② 명칭, 내역 등과 같이 이름으로 기술되는 것은 피함
명칭, 내역과 같이 이름으로 기술되는 것은 주식별자로 지정하지 않는다.
'부서이름'을 주식별자로 지정하면 안된다. 물리데이터베이스로 테이블 생성 후 데이터를 읽을 때 항상 '부서이름'이 WHERE 조건절에 기술되는 현상이 발생된다.
명칭, 내역의 인스턴스들을 식별할 수 있는 다른 구분자가 존재하지 않을 경우 새로운 식별자를 생성한다. ( ex. 일련번호, 코드 )
※ 명칭, 내역의 식별자 2가지 방법
(1) 코드를 부여하여 코드엔터티에 등록. 코드로 주식별자를 지정하는 방법
(2) 일련번호를 주식별자로 하고 명칭은 보조식별자로 활용하는 방법
③ 속성의 수가 많아지지 않도록 함
주식별자 선정을 위한 속성의 수가 많지 않도록 한다.
계속 상속이 되는 속성 ( 자식엔터티 , 손자엔터티 , 증손자엔터티 ... ) 은 복잡한 데이터 모델이 구현되어 물리데이터베이스에서 조인으로 인한 성능저하가 발생하지만, 속성의 반정규화 측면에서 하나의 테이블에 많은 속성이 있는 것이 인정된다.
주식별자의 많은 속성 개수 ( 일반적으로 7~8개 이상 ) 는 새로운 인조식별자 생성 후 데이터 모델 구성을 해야 한다.
데이터 모델과 조건절을 더 단순하게 한다.
' 접수 ' 엔터티에 많은 주식별자 (복잡한 속성) 으로 많은 Primary Key 가 생성되고, 복잡한 SQL 문장을 구사해야 한다.
인조식별자로 대체하여 간단한 SQL 문장을 구사할 수 있다.
5. 식별자관계와 비식별자관계에 따른 식별자
① 식별자관계와 비식별자 관계의 결정
▷ 외부식별자 ( Foreign Identifier )
: 자기 자신의 엔터티에서 필요한 속성 X , 다른 엔터티와의 관계에서 자식 쪽 엔터티에 생성되는 속성이다.
데이터베이스 생성 시 Foreign Key 역할.
관계와 속성 정의 → 주식별자 정의 → 논리적인 관계에 의해 외부식별자 도출
엔터티에 주식별자 지정 → 엔터티간 관계 연결 → 부모쪽 주식별자를 자식엔터티의 속성으로 내려 보냄
※ 결정해야 할 점
자식엔터티에서 부모엔터티로부터 받은 외부식별자
1) 자신의 주식별자로 이용할지?
2) 부모와 연결이 되는 속성으로서만 이용할지?
② 식별자관계
▷ 식별자 관계 ( Identifying Relationship )
: 자식엔터티의 주식별자로 부모의 주식별자가 상속이 되는 경우
부모로부터 받은 식별자를 자식엔터티의 주식별자로 이용하는 경우, Null 값 X
반드시 부모엔터티가 생성 → 자기 자신의 엔터티가 생성되는 경우이다.
1) 1:1 관계 : 자식엔터티가 부모로부터 받은 속성을 모두 사용, 그것만으로 주식별자를 사용할 때
2) 1:M 관계 : 자식엔터티가 부모로부터 받은 속성을 포함하고 다른 부모엔터티에서 받은 속성이나 스스로 가지는 속성도 포함할 때
1:1 관계에서 주식별자가 동일하며 엔터티 통합의 대상이 될 수 있다.
③ 비식별자관계
▷ 비식별자 관계 ( Non - Identifying Relationship )
: 부모엔터티로부터 속성을 받았지만, 자식엔터티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 경우
※ 비식별자 관계에 의해 외부속성을 생성하는 경우
1) 자식엔터티에서 받은 속성이 반드시 필수가 아니어도 무방하다. 부모 없는 자식이 생성될 수 있는 경우.
2) 엔터티별로 데이터의 생명주기 (Life Cycle) 를 다르게 관리할 경우.
(ex. 부모엔터티에 인스턴스가 자식의 엔터티와 관계가 있지만, 자식만 남겨두고 먼저 소멸되는 경우)
3) 여러 개의 엔터티가 하나의 엔터티로 통합되었는데, 각각의 엔터티가 별도의 관계를 가질 경우.
4) 자식엔터티에 주식별자로 사용 가능하지만, 자식엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단되는 경우.
통합된 엔터티에 각각의 엔터티가 별도의 관계를 가지고 있고, 각각의 관계로부터 받은 주식별자를 원래 식별자관게가 주식별자로 사용할 수 없게 된다.
'계약번호' 만 '계약' 엔터티의 주식별자로 구성 가능하다. 주식별자를 하나만 사용하는 것이 더 효율적이므로 '계약번호'만 주식별자로 지정, '계약사원번호' 는 일반속성 외부식별자로 사용한다.
④ 식별자 관계로만 설정할 경우의 문제점
* 지속적으로 식별자 관계를 연결한 데이터 모델의 PK 속성의 수 : 증가
( 데이터 모델의 흐름이 길어질수록 증가할 수 밖에 없는 구조 )
(그림 속)
PLANT 엔터티 PK 속성의 수 : 1개 / 관계 : 1:M
자식엔터티 PK 속성의 수 : PLANT 엔터티 PK 속성의 수 + 1
...
N대 자식엔터티 PK 속성의 수 : 부모 엔터티 1개 + 2대 1개 + 3대 1개 + ... + N-1대 + 1
(그림 속)
세 개의 테이블 정보를 가져오는 SQL 문을 작성하면 WHERE절이 매우 길어진다.
조인에 참여하는 주식별자 속성의 수가 많을 경우 정확하게 조인관계를 설정하지 않고 누락하여 개발하게 된다.
식별자 관계만으로 연결된 데이터 모델의 특징은,
주식별자 속성이 지속적으로 증가할 수 밖에 없는 구조로서 개발자 복잡성과 오류가능성을 유발시킨다.
⑤ 비식별자 관계로만 설정할 경우의 문제점
엔터티 기준속성 : 부모엔터티에 있는 PK 속성으로부터 상속되어 자식엔터티에 존재
! 조심 !
데이터 모델링 전개에서, 각 엔터티 간의 관계를 비식별자 관계로 설정하면 이런 유형의 속성이 자식엔터티로 상속 되지 않아서
자식 엔터티에서 데이터 처리할 때 쓸데없이 부모엔터티까지 찾아가야 한다.
비식별자 관계로 연결되면, 속성이 관계를 타고 자식엔터티로 내려가는 것을 차단한다.
만약 위 모델이 하위 엔터티에서 속성을 보려고 하면 불필요한 조인이 다량으로 유발되면서 SQL 구문이 길어지고 성능이 저하된다.
※ SQL 구문 : 비식별자관계 vs 식별자관계
1) 비식별자관계
: SQL구문에 많은 조인이 걸리게 된다.
복잡성 증가, 성능 저하
2) 식별자관계
: 부모의 모든 주식별자 속성을 상속받음 → 맨 하위의 자식엔터티에서 바로 조회의 조건을 이요하여 정보 조회 가능.
성능과 개발의 용이성 측면에서 우위에 있음.
비식별자관계와 식별자관계, 2 가지 경우를 일정한 규칙을 가지고 데이터 모델링을 해야 한다.
⑥ 식별자관계와 비식별자관계 모델링
1) 비식별자관계 선택 프로세스
식별자관계에서 비식별자관계를 파악하는 기술 필요.
이런 흐름(Flow)에 따라 비식별자관계를 선정하면 합리적으로 관계를 설정할 수 있다.
식별자관계로 모든 관계가 연결되면서 조건을 고려하고, 비식별자관계로 조정한다.
자식엔터티의 독립된 주식별자 구성이 필요한지 분석하는 부분이 가장 중요한 요인이다.
'독립적으로 주식별자를 구성한다' = '업무적 필요성과 성능상 필요여부를 모두 포함한다'
2) 식별자와 비식별자관계 비교
식별자 (강한 관계) vs 비식별자 (약한 관계)
3) 식별자와 비식별자를 적용한 데이터 모델
적절하게 식별자와 비식별자 관계가 설정된 데이터 모델은 균형감을 갖춘 것이다.
'SQL > SQLD 1과목' 카테고리의 다른 글
SQLD - 과목1. (7) 정규화와 성능 (0) | 2021.03.18 |
---|---|
SQLD - 과목1. (6) 성능 데이터 모델링 (0) | 2021.03.18 |
SQLD - 과목1. (4) 관계 (0) | 2021.02.08 |
SQLD - 과목1. (3) 속성 (0) | 2021.02.07 |
SQLD - 과목1. (2) 엔터티 (0) | 2021.01.31 |
- Total
- Today
- Yesterday
- python별찍기
- 40회 SQLD
- 데이터 모델링
- 데이터베이스
- 파이썬
- f-string
- SQLD 1과목
- 백준파이썬
- SQLD1과목
- range함수
- 백준
- Unity GameObject 생성
- SUM함수
- 네이버클라우드플랫폼
- 백준별찍기
- 백준 별찍기
- 파이썬문법
- 파이썬 입출력
- SQLD 2과목
- 파이썬입출력
- Python
- python문법
- 별 찍기
- 파이썬for문
- 파이썬sum
- 알고리즘
- BAEKJOON
- NaverCloudPlatform
- SQLD40회
- SQLD
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |