ERD설계와 정규화

 

ERD가 뭐죠?

ERD는 Entity Relationship Diagram의 약자로 요구 분석 사항에서 얻은 엔티티와 속성들의 관계를 그림으로 나타낸 개체-관계 모델이다.

프로젝트에서 사용하는 데이터베이스 구조를 한눈에 파악할 수 있고 서비스 구축 시 제일 먼저 신경써야 하는 부분이다.

 

 

ERD 구성요소와 표기법

 

기본 요소로 Entity, Attribute, Relationship등이 있고 구체적으로 weak Entity, Multivalued Attribute, Weak Realationship 이 있다.

 

먼저 엔티티에 대해서 보자면

 

엔티티(Entity)

정의 가능한 사물 또는 개념

사람도 될 수 있고 도서정보와 같은 무형의 정보도 데이터화가 가능하다.

데이터베이스의 테이블이 엔티티라고 생각하면 된다

예를들어 학생 Entity는 아래의 그림과 같이 표현된다.

 

엔티티 속성(Attribute)

각각의 엔티티에는 개체가 갖고있는 속성을 포함한다.

학생 엔티티라면 아래와 같은 속성이 있고 데이터베이스의 테이블의 각 필드(컬럼)들이 엔티티 속성이라고 생각하면 된다.

 

 

엔티티 도메인(Entity Domain)

도메인은 속성의 값, 타입, 제약사항 등에 대한 값의 범위를 표현하는 것이다.

사용자에 따라 속성 타입만 그릴수도 있고, 가독성을 위해 생략할 수도 있다.

데이터 타입을 명시할 때 데이터베이스가 지원하는 타입에 맞게 명시해야 한다. 

 

 

엔티티와 엔티티를 연결해주는 것을 관계(Relationship)이라 표현한다.

관계 표시 방법에는  식별자 관계와  비식별자 관계가 있다.

두 엔티티 관계에서 부모 키를 자식에서 PK로 사용하는지 일반 속성으로 사용하는지에 따라 다르게 표기한다.

 

• 식별자 관계
  • 엔티티 사이의 강한 연결관계를 표현
  • 자식 주 식별자의 구성에 포함된다.
  • 실선으로 표현한다.
  • 반드시 부모 엔티티에 종속되며 자식 주식별자 구성에 부모 주식별자를 포함한다.
  • 상속받은 주식별자 속성을 타 엔티티에 이전이 필요하다.

부모 테이블인 학생의 PK키인 학번을 자식 테이블인 학생별 취미의 FK로 참조하여 주식별자로 설정했다.

 

 

• 비식별자 관계
  • 엔티티 사이의 약한 연결관계를 표현
  • 자식 일반 속성에 포함된다.
  • 점선으로 표현한다.
  • 자식 주식별자 구성을 독립적으로 구성한다.
  • 자식 주식별자 구성에 부모 주식별자가 부분 필요하다.
  • 상속받은 주식별자 속성을 타 엔터티에 차단 필요
  • 부모쪽의 관계참여가 선택적이다.

 

부모 테이블인 부서정보의 PK키를 자식 테이블의 사원정보 테이블에서 일반 속성으로 사용한다.

 

 

관계의 카디널리티(Cadinality)

관계가 존재하는 두 entity사이에 한 entity에서 다른 entity 몇개의 개체와 대응되는지 제약조건을 표기하기 위해 선을 그어 표현한다.

 

대표적인 카디널리티는 아래와 같다

1. 1:1 (one to one)
2. 1:M (one to many)
3. N:1 (many to one) 
4. N:M (many to many) 

 

※Cardinality: 한 개체에서 발생할 수 있는 발생 횟수를 정의하며, 다른 개체에서 발생할 수 있는 발생 횟수와 연관된다.

 

 

관계의 참여도를 나타내는 표시가 있다 | 표시가 있다면 필수적으로 참여가 요구되는 개체 O표시가 있다면 없어도 되는 개체라고 정의한다.

 

 

 

One to One (1:1관계)

 

한명의 학생과 하나의 신체정보는 1:1로 매칭된다.

 

 

One to many(1:다 관계)

 

한명의 학생은 여러개의 취미를 가질 수 있으므로 1:M으로 매칭된다.

 

 

 

Many to Many(N:M 관계)

 

제품은 여러 제조업체를 가질 수 있고 제조업체는 여러 제품을 가질 수 있기 때문에 N:M(다 대 다) 관계이다.

 

그런데!!!

모델링 과정에서는 M:N 관계를 완성되지 않은 모델로 간주하여 두 엔티티 사이를 조정하는 관계 테이블을 두는 작업이 필요하다.

이처럼 제품과 제조업체 사이에 업체별 제품이라는 엔티티를 설정하고 두 테이블의 PK키를 FK키로 참조한다.

 

 

 

 

정규화란?

 

엔티티끼리의 관계를 다 설정했을 때 릴레이션 간 잘못된 종속 관계로 인해 데이터베이스 이상 현상이 발생하는 경우가 있다 이를 해결하고 중복요소를 찾아 제거해 나가는 과정을 정규화라 한다.

 

※이상현상(Anomaly)

• 삭제이상:불필요한 정보까지 삭제됨
• 삽입이상: 불필요한 정보가 필요함
• 수정이상: 불필요한 정보까지 갱신 필요

 

 

 

 

 

 

 

제 1정규형

릴레이션의 모든 도메인이 더는 분리할 수 없는 원자값 만으로 구성되도록 분리한다.

속성은 다중 값을 가지면 안된다.

 

연락처 속성이 여러개이므로 1정규화를 거치면

 

 

이처럼 정규화 할 수 있다.

 

제 2정규화

1정규형을 만족하고 모든 부분 함수 종속성을 제거한 상태 즉 완전 함수 종속

다시말해 기본키가 아닌 모든 속성이 기본키에 완전 함수 종속되는 상태를 제 2정규화라고 말한다.

 

부분 함수 종속 과 완전 함수 종속?

부분 함수 종속: 위 그림에서 에를 들어 (회원 아이디, 나이) 가 기본키일 때 회원 아이디에 따라 각 회원의 이름, 성별 등이 정해지는 상황이면 이름은 (회원 아이디, 나이)에 부분 함수 종속이라고 말한다.

 

완전 함수 종속: 동일하게 (회원 아이디, 나이)가 기본키일 때 회원 아이디와 나이 둘 모두에 따라 이름, 성별 등이 정해지는 상황이면 이름은 (회원 아이디, 나이)에 완전 함수 종속이라고 말한다.

 

이와같은 테이블이 있을 때 고객명과 고객등급은 고객아이디 하나에 부분 함수 종속한다.

 

 

이처럼 분리하면 주문일자는 고객아이디,주문번호에 완전 함수 종속하고 고객명과 고객등급은 고객아이디에 완전함수 종속한다고 할 수 있다. 

 

제 3 정규형

제 2 정규형을 만족하고 일반 속성들간에도 종속관계가 존재하지 않아야 한다.

일반 속성들간 종속 관계가 존재한다면 분리되어야 한다.

 

직업코드와 직업명은 고객아이디에 완전함수 종속하기 때문에 2정규형을 만족한다. 하지만 직업코드와 직업명 또한 종속관계가 존재하기 때문에 이를 분리 해주어야 한다.

 

 

BCNF 보이스/코드 정규화

제 3정규형이고, 결정자가 후보키가 아닌 함수 종속 관계를 제거하여 릴레이션의 함수 종속 관계에서 모든 결정자가 후보이킨 상태

 

 

※함수 종속 관계: 테이블의 특정 컬럼A를 알면 다른 컬럼B를 알 수 있을 때 함수적 종속성이 있다고 한다. 

※결정자: 주어진 릴레이션에서 다른 속성을 고유하게 결정하는 하나 이상의 속성 -> A컬럼

 

 

이처럼 정규화 과정이란 중복된 속성을 최소화 하고, 종속관계에 있는 속성을 제거하는 과정으로 정규화 과정을 다시 조인하면 데이터의 손실없이 이전 상태로 복구가 가능해야 한다.

 

정규화를 거쳤을 시 장점과 단점

 

장점

DB변경시 이상현상 제거

데이터 구조의 안정성 및 무결성 유지

데이터 삽입,삭제,수정 시 테이블의 재구성 필요성 감소

 

단점

릴레이션간의 JOIN연산 증가로 인해 응답 시간 저해

 

역정규화

join이 너무 많아지는 DB설계와 쿼리는 요청을 처리하는 시간을 증가시키는 문제가 있기 때문에 모든 주요 Entity를 분리하는 것이 좋은 것이 아니라 DB의 전반적인 성능을 향상시킬 수 있는 구조화 과정을 거치는 것이 필요하다.

역정규화는 중복을 허용하며 Entity를 다시 통합하거나 분리하는 등 구조를 재조정 하는 과정

 

왜 역정규화를 할까?

읽기 작업이 많이 필요한 테이블의 읽기 성능 향상을 위해서

 

 

위와같은 정규화된 테이블과 비정규화 테이블로 만드는 역정규화를 실행했을 때

정규화된 테이블에서 김찬강사의 수강료를 확인하고자 할 때 3개의 테이블을 JOIN한 뒤 데이터 값을 검색한다.

 

만약 테이블의 갯수가 많고 데이터가 많다면 JOIN시간이 훨씬 늘어나 데이터 읽기 효율성이 떨어진다

그래서 시간표 테이블같이 역정규화를 시키면 읽기 시간이 단축된다.

 

그러나 역정규화를 했을 때 생각해아할 점이 있다.

• 데이터의 무결성(정확성)이 떨어진다. -> 중복 데이터를 허용하기 때문
• 읽기(조회)속도는 빨라지지만 쓰기(삽입,수정,삭제)속도는 느려짐
• 저장공간의 효율이 떨어짐
• 유지보수가 어려움

 

 

 

 

 

 

Refereces

https://inpa.tistory.com/entry/DB-%F0%9F%93%9A-%EC%A0%9C-1-2-3-%EC%A0%95%EA%B7%9C%ED%99%94-%EC%97%AD%EC%A0%95%EA%B7%9C%ED%99%94

https://velog.io/@kjhxxxx/DataBase-ERD%EB%9E%80

https://velog.io/@oyunseong/ERD%EC%99%80-%EC%A0%95%EA%B7%9C%ED%99%94-%EA%B3%BC%EC%A0%95