DB_RDBMS - 6. 식별관계와 비식별관계, 논리적 설계.

몽구's·2022년 5월 6일
0

DB_RDBMS 모델링

목록 보기
7/8

개념적 설계에서 논리적 설계로 넘어가기 위해 기본키(Primary Key)와
외래키(Foreign Key)를 이해하고, 이를 식별관계, 비식별 관계로 연결지어 보자.

1. 식별자 분류

1) 식별자 분류
식별자의 종류는 자신의 개체(Entity) 내에서 대표성을 가지는가에 따라
주식별자(Primary Identifier)와 보조식별자(Alternate Identifier)로 구분하고 엔터티 내에서 스스로 생성되었는지 여부에 따라 내부식별자와 외부식별자(Foreign Identifier)로 구분할 수 있다.

또한 단일 속성으로 식별이 되는가에 따라 단일식별자(Single Identifier)와 복합식별자(Composit Identifier)로 구분할 수 있다. 원래 업무적으로 의미가 있던 식별자 속성을 대체하여 일련번호와 같이 새롭게 만든 식별자를 구분하기 위해 본질식별자와 인조식별자로도 구분할 수 있다.

예시) 엔티티 내 다양한 식별자 도출

2) 주 식별자 도출기준
데이터 모델링 작업에서 중요한 작업 중의 하나가 주식별자 도출작업이다. 주식별자를 도출하기 위한 기준을 정리하면 다음과 같다.

  • 해당 업무에서 자주 이용되는 속성을 주식별자로 지정한다.
  • 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않는다.
  • 복합으로 주식별자로 구성할 경우 너무 많은 속성이 포함되지 않도록 한다.

2-1) 해당 업무에서 자주 이용되는 속성을 주식별자로 지정하도록 한다.
예를 들면, 직원이라는 엔티티가 있을 때 유일하게 식별가능한 속성으로는 주민등록번호와 사원번호가 존재할 수 있다. 사원번호가 그 회사에서 직원을 관리할 때 흔히 사용되므로 사원번호를 주식별자로 지정하고 주민등록번호는 보조식별자로 사용할 수 있다.

  • 사원번호, 회원번호, 게시글번호, 결제번호, 프로그램번호 등 엔티티 내 유일하게 식별가능한 속성을 주식별자로 선택한다.

2-2) 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않도록 한다. 예를 들어, 한 회사에 부서이름이 100개가 있다고 할 때, 각각의 부서이름은 유일하게 구별될 수 있다고 하여 부서이름을 주식별자로 지정하지 않도록 해야 한다. 만약 부서이름을 주식별자로 선정하면 물리데이터베이스로 테이블을 생성하여 데이터를 읽을 때 항상 부서이름이 WHERE 조건절에 기술되는 현상이 발생된다. 부서이름은 많은 경우 20자 이상이 될 수 있으므로 조건절에 정확한 부서이름을 기술하기는 쉬운 일이 아니다.
이와 같이 명칭이나 내역이 있고 인스턴스들을 식별할 수 있는 다른 구분자가 존재하지 않을 경우는 새로운 식별자를 생성하도록 한다. 보통 일련번호와 코드를 많이 사용한다.

  • 부서명을 부서번호로, 프로그램명을 프로그램번호를 새로운 식별자로 만들어 주식별자로 사용한다.

2-3) 주식별자로 선정하기 위한 속성이 복합으로 구성되어 주식별자가 될 수 있을 때 가능하면 주식별자 선정하기 위한 속성의 수가 많지 않도록 해야 한다. 그러나 만약 주식별자로 선정된 속성들이 자신이 가지고 있는 자식엔터티로부터 손자엔터티, 그리고 증손자엔터티까지 계속해서 상속이 되는 속성이고 복잡한 데이터 모델이 구현되어 물리데이터베이스에서 조인으로 인한 성능저하가 예상되는 모습을 가지고 있다면 속성의 반정규화 측면에서 하나의 테이블에 많은 속성이 있는 것이 인정될 수도 있다. 하지만 일반적으로 주식별자의 속성의 개수가 많다는 것(일반적으로 7~8개 이상)은 새로운 인조식별자(Artificial Identifier)를 생성하여 데이터 모델을 구성하는 것이 데이터 모델을 한층 더 단순하게 하고 애플리케이션을 개발할 때 조건절을 단순하게 할 수 있는 방법이 될 수 있다.

  • "접수" 엔티티의 접수일자, 관할부서, 입력자사번, 접수방법, 신청인, 신청인 연락처 등 주식별자가 넘쳐난다면, "접수 번호"의 인조식별자를 통해 주식별자 속성을 단순화 한다.

2. 식별자관계와 비식별자 관계

외부식별자(Foreign Identifier)는 자기 자신의 엔터티에서 필요한 속성이 아니라 다른 엔터티와의 관계를 통해 자식 쪽에 엔터티에 생성되는 속성을 외부식별자라 하며 데이터베이스 생성 시에 Foreign Key 역할을 한다.

관계와 속성을 정의하고 주식별자를 정의하면 논리적인 관계에 의해 자연스럽게 외부식별자가 도출되지만 중요하게 고려해야 할 사항이 있다.

엔터티에 주식별자가 지정되고 엔터티간 관계를 연결하면 부모쪽의 주식별자를 자식엔터티의 속성으로 내려 보낸다. 이 때 자식엔터티에서 부모엔터티로부터 받은 외부식별자를 자신의 주식별자로 이용할 것인지 또는 부모와 연결이 되는 속성으로서만 이용할 것인지를 결정해야 한다.

1) 식별자 관계

부모로부터 받은 식별자를 자식엔터티의 주식별자로 이용하는 경우는 Null값이 오면 안되므로 반드시 부모엔터티가 생성되어야 자기 자신의 엔터티가 생성되는 경우이다.
부모로부터 받은 속성을 자식엔터티가 모두 사용하고 그것만으로 주식별자로 사용한다면 부모엔터티와 자식엔터티의 관계는 1:1의 관계가 될 것이고,
만약 부모로부터 받은 속성을 포함하여 다른 부모엔터티에서 받은 속성을 포함하거나 스스로 가지고 있는 속성과 함께 주식별자로 구성되는 경우는 1:M 관계가 된다.

2) 비식별자 관계

부모엔터티로부터 속성을 받았지만 자식엔터티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 경우가 있다. 이과 같은 경우를 비식별자 관계(Non-Identifying Relationship)라고 하며 다음의 네 가지 경우에 비식별자 관계에 의한 외부속성을 생성한다.
1) 자식엔터티에서 받은 속성이 반드시 필수가 아니어도 무방하기 때문에 부모 없는 자식이 생성될 수 있는 경우이다.
2) 엔터티별로 데이터의 생명주기(Life Cycle)를 다르게 관리할 경우이다. 예를 들어 부모엔터티에 인스턴스가 자식의 엔터티와 관계를 가지고 있었지만 자식만 남겨두고 먼저 소멸될 수 있는 경우가 이에 해당된다. 이에 대한 방안으로 물리데이터베이스 생성 시 Foreign Key를 연결하지 않는 임시적인 방법을 사용하기도 하지만 데이터 모델상에서 관계를 비식별자관계로 조정하는 것이 가장 좋은 방법이다.
3) 여러 개의 엔터티가 하나의 엔터티로 통합되어 표현되었는데 각각의 엔터티가 별도의 관계를 가질 때이며 이에 해당된다.

3. 개념적 설계를 바탕으로 식별, 비식별관계 만들기.

(1:1) 관계: 부모는 하나의 자식이 있다.
(1:N) 관계: 부모는 하나 이상의 자식 있다.
(N:M) 관계: 하나 이상의 부모와 하나 이상의 자식이 있다.
(1:1O) 관계: 부모는 하나의 자식이 있을수도, 없을수도 있다.
(1:NO) 관계: 부모는 여러개의 자식이 있을수도, 없을수도 있다.

식별자 관계

  • 부모의 주식별자가 자식의 주식별자가 되는 경우를 "식별자 관계"라고 한다.
  • 부모 테이블의 기본키(PK)가 자식 테이블의 외래키(FK)이면서, 기본키(PK)로 사용되는 관계.

Ex) 카드결제는 카드가 있어야 생기는 엔터티이다. 이런경우를 부모관계라고 표현한다.
여기서, 카드 엔터티의 카드번호 주식별자(기본 키)를 결제 엔터티의 주식별자(기본 키)로 지정했다.
FK는 Foreign Key로 외래키라는 뜻이다. 다른 엔터티의 기본 키를 참조한 키라고 해석하면된다. 이런경우를 식별자 관계라고 한다.

비식별자 관계

  • 부모의 주식별자가 자식의 주식별자가 되지 않고 그냥 속성으로 사용하는 경우
    비식별자 관계라고 한다.
  • 자식테이블에서 참조된 외래키(FK)가 기본키가 아닌 일반 컬럼으로 참조되는 관계
    -> 부모 테이블의 기본키(PK)가 자식 테이블의 외래키(FK)로만 사용되는 관계
  • 자식 테이블의 행(row)를 추가할 때 부모 테이블의 참조행(row)가 없어도,
    자식 테이블의 행(row)를 추가할 수 있다.
    -> 부모 테이블에 데이터가 없어도, 자식 테이블에 데이터를 추가 할 수 있다.

Ex) 카드AS는 카드가 있어야 생기는 엔터티이다. 하지만 식별관계처럼 카드번호를 기본키로 사용하지 않고, 카드AS번호를 기본 키로 사용한다.
부모 엔터티 주식별자(카드번호)를 그냥 속성으로만 사용하였다.
이런 경우를 비식별자 관계라고 한다.

4. 주의점

  • 테이블 설계 시 "비식별 관계로 테이블을 설계하는 것"을 권장한다.
  • 식별 관계를 사용할 경우 데이터의 정합성을 보장하지만 비즈니스 로직이 변경되면 테이블 관리가 힘들어진다.
    정합성 : 데이터 들의 값이 서로 일치함
  • 비식별관계를 이용할 경우 정합성을 유지하기 위해 별도의 비즈니스 로직이 필요하다.
  • 비식별 관계는 데이터 무결성을 보장하지 않는다.
    무결성 : 데이터 값이 정확한 상태

출처:
https://dataonair.or.kr/db-tech-reference/d-guide/sql/?pageid=5&mod=document&uid=329

https://inpa.tistory.com/entry/DB-%F0%9F%93%9A-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81-1N-%EA%B4%80%EA%B3%84-%F0%9F%93%88-ERD-%EB%8B%A4%EC%9D%B4%EC%96%B4%EA%B7%B8%EB%9E%A8

profile
"성공"하면 실력이고, "실패"해도 경험인걸요.

0개의 댓글