- ERD (Entity Relationship Diagram)
흔히 E-R 다이어그램이라고 불리우며 ERD 라고 줄여 부르기도 한다.
영어 약자 그대로 '존재하고 있는 것(Entity)들의 관계(Relationship)을 나타낸 도표(Diagram)' 이다.
여기서 말하는 존재하고 있는 것이란 데이터를 뜻하니 데이터들의 관계를 나타낸 도표인 셈이다.
그럼 데이터의 관계를 어떻게 나타내는지 그림들을 참고해 이해해보자.
ERD 규칙 및 표기 방법
먼저 ERD의 규칙을 살펴보면 아래와 같다.
A는 부모, B는 자식의 관계를 가진 ERD이다. 여기서 '~B로 구성되어 있다'라는 말이 살짝 헷갈릴 수 있다.
이를 풀어 설명해주면 '~B를 포함하고 있다' 라고 이해하면 될 것 같다.
그리고 부모와 자식의 관계를 알아야 하는데 A 테이블의 기본키를 B 테이블이 가지고 있다면
A테이블이 부모 테이블, B테이블이 자식 테이블을 뜻한다.
또한 그림에는 없지만 점선과 실선으로 관계를 구분하는데
실선은 부모 테이블의 기본키를 자식 테이블이 가지고 있으며 이를 기본키로 사용하는 경우이고
점선은 부모 테이블의 기본키를 자식테이블이 가지고 있지만 이를 기본키로 사용하지 않을 때 사용한다.
예시
아래의 그림을 예로 들어 설명해 보겠다.
위의 학생 테이블과 수강내역 테이블과의 관계를 나타낸 ERD를 예로 들어보겠다.
먼저 부모 테이블과 자식 테이블이 누구인지 알아내야 하는데 수강내역 테이블이 학생 테이블의 기본키를 외래키로 가지고 있으니
수강내역 테이블이 자식 테이블, 학생 테이블이 부모 테이블임을 알 수 있다.
다음으로 테이블 간의 관계를 보면 학생 테이블 쪽의
는 1을 뜻하기 때문에 '하나의 학생',
는 0~N 을 뜻하기 때문에 '0~N 개의 수강내역'을 뜻한다.
이는 학생의 입장에서는 '하나의 학생은 0~N 개의 수강내역을 가진다',
수강내역의 입장에서는 '0~N 개의 수강내역은 하나의 학생에게 포함되어 진다'라는 해석이 가능하다.
그리고 수강내역 테이블에서 학생 테이블의 기본키를 자신도 기본키로 사용하기 때문에 실선으로 표현되어 있음을 알 수 있다.
이러한 모든걸 유추해 이 ERD를 해석해 보자면
-
자식 테이블은 수강내역 테이블이다.
-
부모 테이블의 PK를 자식 테이블에서 PK로 사용하고 있다.
-
학생 한 명은 0~N 개의 수강내역을 가진다.
-
수강내역은 하나의 학생을 가진다.
-
수강내역 테이블은 학생 테이블의 PK인 [ 학생ID ]를 FK로 가진다.
아래의 그림을 참고해 한 번 더 살펴보자.
부서 테이블과 사원 테이블을 예로 든 그림이다.
이전 예제와 달리 점선으로 관계를 표현한걸 보니 사원 테이블은
부서 테이블의 기본키를 가지고 있지만 이를 기본키로 사용하지는 않음을 알 수 있다.
이 ERD를 이전 예제와 똑같은 방법으로 해석하면 다음과 같다.
-
부모 테이블은 부서 테이블이다.
-
자식 테이블은 사원 테이블이다.
-
자식 테이블이 부모 테이블의 PK를 가지고 있지만 이를 PK로 사용하지는 않는다.
-
하나의 부서는 0~N 명의 사원을 가질 수 있다.
-
사원 테이블은 부서 테이블의 PK인 부서번호를 FK로 가진다.
예로 든 것들을 봐도 알 수 있듯이, 기본키를 누가 갖고 있는가? 누가 외래키를 갖고 있는가?
누가 어디에게 종속되고 누가 누구를 포함하고 있는가 등의 관계를 표현 해냈음을 알 수 있다.
이것이 ERD이며 데이터베이스를 다루는 업종이라면 필수적으로 이해해야할 부분이기도 하다.
- 선 모양 총 정리
- 두 개체의 관계 - 선 모양 총정리
- 구성 요소 표기법
엔티티
- Entity는 정의 가능한 사물 또는 개념을 의미한다.
- 사람이나, 객체 혹은 개념이나 이벤트 등을 Entity로 둘 수 있다.
- 객체에는 가구나 자동차를 예시로 들 수 있다.
- 개념은 프로필이나 자기소개서 등이 있을 수 있겠고, 이벤트에는 거래 등이 있을 수 있다.
- 데이터베이스를 설계할 때, '테이블'이 Entity로 정의될 수 있다.
- 각각의 Entity에는 속성(Attribute)을 포함하고 있다. 필드(컬럼)명을 쓰면 된다.
예를 들어 사람이라면 나이, 이름, 생년월일 등 속성들을 포함할 수 있다. - 여기서, 하나 더 필요한 건 데이터의 타입(Domain) 이다.
데이터 타입을 같이 명시해줘야 하며 이 때, RDBMS가 지원하는 타입에 맞게 해야한다.
- 엔터티(Entity) : 업무에 필요, 데이터를 저장 및 관리하는 테이블을 의미
- 속성(Attribute) : 엔터티의 한 부분으로써 업무에 필요한 최소값의 단위를 의미. 필드(컬럼)명이라고 이해하면 된다.
- 도메인(Domain) : 속성의 값, 타입, 제약사항 등에 대한 값의 범위를 표현.
엔티티도 저장하는 데이터 정보 주제에 따라 종류가 구분된다.
예를들어 고객 정보같은 실제로 물리적인 형태로 있는 정보와 구매 이력같은 무형적이고 개념적인 정보가 있다.
이 엔티티 분류 구분을 잘 해주어야 정규화 및 데이터베이스 설계에 있어 굉장히 도움이 된다.
- 최종 예시
- 회원 ↔ 대여
회원번호PK가 대여 테이블에서 FK로 일반속성으로 쓰이고 있다.
( 점선 )
회원은 대여를 여러개 할 수 있다. ( 1:N )
아예 대여하지 않은 회원이 있을 수 있다. ( 1:N(선택) )
대여를 할땐 반드시 회원 정보가 필수로 존재해야한다.
( 1[필수]:N[선택] )
- 도서 ↔ 대여
도서번호PK가 대여 테이블에서 FK로 일반속성으로 쓰이고 있다.
( 점선 )
도서가 과거에 여러번 대여된 기록이 있을 수 있으니. ( 1:N )
아예 대여하지 않은 도서가 있을 수 있다. ( 1:N[선택] )
대여를 할땐 반드시 도서 정보가 필수로 존재해야한다.
( 1[필수]:N[선택] )
- 회원 ↔ 예약
회원번호PK가 예약 테이블에서 FK이자 PK로 쓰이고 있다. ( 실선 )
회원은 예약을 여러개 할 수 있다. ( 1:N )
아예 예약하지 않은 회원이 있을 수 있다. ( 1:N[선택] )
예약을 할땐 반드시 회원 정보가 필수로 존재해야한다.
( 1[필수]:N[선택] )
분석
- 효율적인 모델링 작업하기
도서 Entity에 관해서 말하자면, 도서관에 같은 책(책 이름이 똑같은)이 있다는 가정하에 모델링을 했음에도 불구하고, 위 예시는 효율적으로 모델링을 하지 못한 표본이 되고 말았다.
왜냐하면 도서번호로 같은 책이 있더라도 번호를 달리해 구분은 가능할지 몰라도,
똑같은 자료를 중복하게되는 구조여서 결과적으로 데이터공간을 낭비하는 결과를 초래하기 때문이다.
다시 말하면 도서관의 실제도서를 나타내는 Entity와 실제도서의 속성을 정의하는 Entity를 구분해야된다는 말이다.
왜냐하면, 도서번호만 다른 똑같은 책인 속성 정보가 완전히 같기 때문에 아래 사진에서 볼수 있듯이 같은 도서의 속성들의 데이터가 중복으로 저장됨을 표로 볼 수 있다.
따라서 이 속성정보를 중복해서 한 테이블에 저장하는 것보다, 테이블을 따로 분리해서 속성을 따로 저장하는게 데이터공간을 절약할 수 있게 된다.
이러한 분담 행위를 정규화라고 한다.
예시 수정
도서 엔티티를 분리해, 도서와 도서정보로 쪼개고 이를 연결한다. 그리고 ISBN(국제표준도서번호)을 외래키로 설정해 관계를 구성한다.
그리고 추가적으로 예약 엔티티는 직관적이게, 대여에 연결하는게 아니라, 회원과 도서를 연결하는게 맞다. 따라서 도서 엔티티에 예약 엔티티를 연결해준다.
- 도서 정보 ↔ 도서
ISBN(국제표준도서번호) PK가 도서 테이블에서 FK로 일반속성으로 쓰이고 있다. ( 점선 )
같은 책이 여러개 있을 수 있다. 도서정보가 같은 도서가 여러개. ( 1:N )
유실된 책이 있을수 있다. 도서정보는 무형의 정보일 뿐이고, 도서 엔티티는 실제 물리적 엔티티이다. ( 1:N[선택] )
도서는 반드시 도서 정보가 필수로 존재해야한다. ( 1[필수]:N[선택] )
- 도서 ↔ 예약
도서번호 PK가 예약 테이블에서 FK이자 PK로 쓰이고 있다. ( 실선 )
하나의 도서에 여러개 예약이 걸려 있을수 있다. ( 1:N )
예약이 없는 도서가 있을 수 있다. ( 1:N[선택] )
예약 정보에는 반드시 도서 정보가 들어 있어야 한다. (1[필수]:N[선택] )
