러닝MySQL 2장 데이터베이스 모델링과 설계

데이터베이스 스터디로 러닝MySQL을 읽고 있다. 

공부한 내용을 정리해보겠다!

 

2.3 관계형 엔티티 모델

 

데이터베이스는

객체인 엔티티와

엔티티간의 연결정보인 관계를 저장한다.

 

예) 엔티티는 제품과 고객, 둘의 관계가 판매

 

관계형 엔티티 entity relationship ER모델은

개념적 설계의 일반적인 접근 방식으로 요구사항을 디비의 관계와 엔티티의 형식적인 설명으로 변환할 때 도움이 된다.

 

 

2.3.1 엔티티 표현 방식

설계를 시각화하기 위해 ER모델링에는 ER다이어그램을 그리는 과정이 포함된다.

일반적으로 엔티티의 특징이나 속성을 저장하기 위헤 데이터베이스를 사용한다.

 

엔티티에 속한 속성은 해당 엔티티를 설명한다.

속성을 더 세분화해서 구성할 수 있다.

속성이 더 작은 단위로 구성된 경우 : 복합 속성

그렇지 않은 경우 : 단순 속성으로 분류

 

 

속성은 값이 동일한 엔티티를 구별하는데 도움이 된다. 고객을 구별하기 위해 각자 고유한 특성이 필요한데

이런 고유한 키 값을 기본 키라고 부른다.

기본 키 설정에는 신중해야한다.

예) 이메일을 기본키로 하면 , 이메일이 여러 개인 고객은? 이메일이 없는 고객은?

 

대체키로 사용할 수 있는 또 다른 속성을 보자면, 두 명의 고개개이 전화번호가 동일할 수 있으나 (전화번호는 기본키로 사용할 수 없음) 번호가 같아도 고객 이름이 같지 않기 때문에 전화번호와 이름을 복합 키로 사용할 수 있다.

엔티티로 식별할 때 사용할 수 있는 키가 여러 개일 수 있다.

대안 중 하나를 선택하거나 후보키 를 기본 키로 선택한다.

출처: https://jerryjerryjerry.tistory.com/49
키: 무언가를 식별하는 고유한 식별자 키의 종류로 기본키 , 슈퍼키, 대체키, 외래키 등이 있다.

슈퍼키 super key: 각 행을 유일하게 식별할 수 있는 하나 또는 그 이상의 속성들의 집합이다. 즉 유일성(고유한 데이터 속성)만 만족하면 슈퍼키가 될 수 있다. ex. 주민번호, 이름+나이, 학번

후보키 candidate key: 각 행을 유일하게 식별할 수 있는 최소한의 속성들의 집합 후보키는 기본키가 될 수 있는 후보들이며 유일성과 최소성을 동시에 만족해야한다. ex. 주민전호, 학번, (이름+ 나이 는 2개의 속성으로 되어있어서 후보키가 될 수 없다. )

기본키(primary key: 후보키들 중에서 하나를 선택한 키로 최소성과 유일성을 만족하는 속성이다. 테이블에서 기본키는 오직 1개만 지정할 수 있다. null값을 절대 가질 수 없고, 중복된 값을 가질 수 없다.

대체키 alternate key:후보키가 두개 이상일 경우 그중에서 어느 하나를 기본키로 지정하고 남은 후보키들을 대체키라고 한다. 기본키로 선정되지 않은 후보키이다.

외래키 Foreign key: 테이블이 다른 테이블의 데이터를 참조하여 테이블 간의 관계를 연결하는 것. 다른 테이블의 데이터를 참조할 때 없는 값을 참조할 수 없도록 제약을 준다.

부모 테이블 먼저 삭제될 수 없다. 왜냐하면 부모테이블을 참조하는데 부모테이블이 삭제되면 자식테이블은 참조하는 것이 없어지기 때문에 외래키 오류가 생긴다. 외래키 관계에서 부모테이블을 삭제하려면 자식테이블 먼저 삭제한 후 부모테이블을 삭제해야한다. 

 

2.3.2 관계 표현

엔티티는 다른 엔티티와 관계를 가질 수 있다.

에) 고객은 제품을 살 수 있고, 학생은 수업을 수강할 수 있고, 직원은 주소를 가질 수 있다.

엔티티와 마찬가지로 관계 또한 속성을 가질 수 있다.

예) 판매를 고객 엔티티(고유한 이메일 주소로 식별됨) 와 특정 날짜 및 시간(타임스탬프)에 존재하는 몇 가지 제품 엔티티(고유한 제품ID값으로 식별됨) 사이의 관계로 정의할 수 있다. 관계의 양족에서 엔티티 수가 다를 수도 있다.

• 다대다 
  • 고객이 원하는 수의 제품을 구입할 수 있고, 제품이 원하는 수의 고객에게 구입될 수 있다.
  • M:N
• 일대다
  • 한 사람이 신용카드 여러개는 되지만 각 신용카드는 한 사람에게만 속함
  • 다대일 N:1
  • 여러개의 신용카드가 한사람에게 속해짐
• 일대일 1:1
  • 자동차 엔진의 일련번호, 엔진에는 단 하나의 일련번호만 부여된다.
  • 일련번호는 하나의 자동차 엔진에만 속한다.

관계의 양쪽에 있는 엔티티의 수 (관계의 카디널리티cardinality)는

관계의 주요 제약 조건constraints을 정의한다.

관계의 카디널리티에 대해 신중히 생각할 것.

처음에는 일대일처럼 보이지만 나중에 복잡해즌 관계들이 많다.

예) 사람들이 때때로 이름을 바꿈, 경찰 디비에서는 더욱 그런 데이터가 있을 수 있다. 사람엔티티와 이름 엔티티를 다대다 관계로 모델링

 

중복된 값이 적을수록 좋다

주민번호를 조회하는 것처럼 중복 수치가 낮으면 빨리 데이터를 찾을 수 있기 때문

중복도가 낮을수록 카디널리티가 높다

중복도가 높으면 카디널리티가 낮다

 

카디널리티란?
테이블의 총 행 수에 대한 관계형 테이블 열의 고유 값 수

 

2.3.3 부분 참여와 전체 참여

엔티티 관계는 선택사항이거나 필수 사항이다.

선택사항 - 고객 엔티티는 구매 관계에 완전히 참여함

모든 고객이 제품을 구매했고 제품을 구매하지 않은 고객은 있을 수 없다.

부분적으로 참여 -고객이 제품을 구입할 수 있다.

 

즉 

부분참여가 비식별관계

전체참여가 식별관계

와도 같다고 한다. 

 

즉 부분적으로만 참여를 하여 값이 있어도 되고 없어도 되지만

ex. 회원가입시 유저의 주소 적어도 되고 안적어도 된다. 

전체참여는 식별을 할 수 있도록 필수적으로 있어야한다. 

ex. 회원가입시 유저의 주소가 필수적이다. 

 

 

요즘 추세는 식별/비식별관계를 잘 쓰지 않는다고 한다. 

외래키로 다른 테이블과 식별/비식별관계(Null일 수 있음)인 경우 

상위객체(소유엔티티)가 존재할 때 하위객체가 존재해야하기 때문에 

외래키 데이터를 삭제할 때 "참조 무결성 제약 조건 위반"이  발생할 수 있다. 

 

그래서 식별/비식별 대신

관계를 맺지 않고 키값을 갖는다고 한다. 그리고 인덱스를 걸어서 처리.

(인덱스를 건다는 것은 데이터베이스에서 특정 값을 빠르게 찾을 수 있게 기존 데이터를 정렬해놓아 검색할 수 있도록 하는 것)

 

 

 

2.3.4 엔티티 또는 속성

항목이 그 자체로 속성인지 아니면 엔티티인지 구분하기 어려운 경우가 있다

예) 속성이라 생각했던 이메일 주소는 그 자체로 엔티티가 될 수 있다.

이럴 경우 규칙을 사용해보기

• 데이터베이스와 직접적인 관련이 있는가?
  • 직접적인 관계의 객체는 엔티티
  • 엔티티를 설명하는 정보는 속성에 저장되어야한다.
  • 예) 재고 및 판매 데이터베이스에서 이메일 주소 보다 고객이 중요하므로 이메일 주소는 엔티티보다는 고객의 속성이 되는 것이 좋다.
• 항목 자체를 구성하는 요소가 있는가?
  • 만약 그렇다면 이런 구성요소를 나타낼 방법을 찾아야 한다.
  • 별도의 엔티티를 만드는 게 좋은 해결책이 될 수 있다.
  • 예) 학생성적 디비에서 학생 엔티티로 학생이 수강하는 수업, 연도 학기 저장, 수업 엔티티 별도로 생성.
• 객체가 여러 개의 데이터를 가질 수 있는가?
  • 만약 그렇다면 여러 개의 데이터를 저장할 방법을 찾아야한다.
  • 가장 확실한 방법은 객체를 별도의 엔티티로 나타내는 것이다.
  • 예) 고객에게 이메일 주소가 하나이상 있다면 이메일 주소를 별도의 엔티티로 모델링한다.
• 객체가 존재하지 않거나 알 수 없는 경우가 많은가?
  • 만약 그렇다면 이 객체는 사실상 일부 엔티티의 속성일 뿐이므로 별도의 엔티티로 만드는 편이 더 좋다.
  • 예) 학생 수업 성적을 저장하기 위해 모든 수업에 대한 성적 속성을 학생 엔티티가 취할 수 있다. 그러나 대부분 학생들이 일부 수업에 대해서만 성적을 받으므로 성적을 속성값으로 관리하지 않고 성적 엔티티로 별도 엔티티 집합으로 나타내는 것이 좋다.

2.3.5 엔티티 또는 관계

객체를 엔티티로 할지 관계로 할지 결정하는 쉬운 방법은

요구사항 명사를 엔티티

동사를 관계로 바꾸는 것!

예) 학위 프로그램은 하나 이상의 과정으로 구성된다 - 문장에

프로그램, 과정 - 엔티티 | 구성됨 - 관계

예) 학생이 프로그램에 등록합니다. 라는 문장에서는

학생, 프로그램 - 엔티티 | 등록 - 관계

설계를 단순하게 유지하고 가능하면 소소한 엔티티를 도입하지 말라

 

2.3.6 중간엔티티

 

다대다 관계를 새로운 중간 엔티티(연관엔티티)로 대체하고

원래 엔티티를 일대다 관계와 다대일 관계로 연결해

다대다 관계를 개념적으로 단순화할 수 있다.

 

예) 승객이 항공편을 예약합니다

승객, 항공편 - 엔티티 → 다대다 관계

 

한 승객이 예약 여러 번 할 수 있음

하지만 자리는 오직 한 승객에게 주어짐

이 관계(예약)의 카디널리티(관계의 양쪽에 있는 엔티티의 수)는 1:N

 

이와 마찬가지로

하나의 항공편에 많이 예약할 수 있지만

각 자리는 오직 한 항공편에서만 가능하므로

이 관계(배치)의 카디널리티 1:N

 

자리가 특정 승객과 특정 항공편과 연결되어야 하므로

자리 엔티티는 모든 엔티티와의 관계에 완전하게 참여한다. (자리가 필수로 있어야함!)

 

2.3.7 약한 엔티티와 강한 엔티티

약한 엔티티는 다른 엔티티에 종속되어 독립적으로 존재할 수 없으며,

식별 관계에 완전하게 참여한다. 반면 강한 엔티티는 자체적으로 고유하게 식별될 수 있는 엔티티이다.

출처: https://studyandwrite.tistory.com/427
강한 엔티티 타입은 자신의 키 속성만 이용해서 고유하게 엔티티들을 식별할 수 있는 타입
약한 엔티티 타입은 자신의 키 속성만으로 엔티티를 고유하게 식별할 수 없는 타입!

 

 

식별 관계에서 약한 엔티티는 부모 엔티티의 일부분이 되어 해당 엔티티를 식별한다. 그리고 약한 엔티티의 전체 키는 자신의 부분 키와 소유한 엔티티의 키를 조합한 값이 된다.

 

맥락을 바탕으로 적은 양의 정보로도 작업이 가능하다.

디비 설계에서는 다른 엔티티에 종속된 엔티티에 대한 주요 정보를 몇 개 생략할 수 있다.

예) 고객의 자녀 이름 저장하는 경우, 자녀 엔티티 만들고 부모를 잘 구분해주는 주요 정보만 저장할 수 있다.

이 경우 자녀 엔티티가 약한 엔티티이며

자녀엔티티와 고객 엔티티의 관계를 식별관계 라고 한다.

약한 엔티티는 데이터베이스에서 소유 엔티티와 독립적으로 존재할 수 없기 때문에 식별 관계에 완전하게 참여한다.

 

약한 엔티티는

해당 엔티티를 소유한 즉 강한 엔티티의 맥락 안에서

고유하게 구분되므로

약한 엔티티의 전체 키는

자신의 키(부분)와 소유한 엔티티의 키를 조합한 값이다

 

 

2.4 데이터베이스 정규화

데이터베이스 정규화는 관계형 디비의 구조를 설계할 때 중요한 개념이다

정규형의 목적 : 데이터의 중복을 줄이고 무결성을 향상하는 것

또한 정규화는 데이터베이스 구조를 재설계하거나 확장하는 프로세스를 효율화한다.

 

세 가지 정규형의 목표를 살펴본다

제 1정규형 1NF : 정규형(Normalization Form)

• 개별 테이블에서 반복되는 그룹을 제거한다
• 관련 데이터 집합에 대해 별도의 테이블을 만든다
• 기본 키로 각 관련 데이터 집합을 식별한다.

만약 관계에 복합 또는 다중 속성이 포함된다면 제 1정규형을 위반한 것이다.

반대로 복합 또는 다중 속성이 포함되지 않는다면 제1정규형을 만족한다.

따라서 해당 관계의 모든 속성값이 단일 타입인 경우 이를 제 1정규형이라고 한다.

제 2정규형 2NF

• 여러 행에 적용되는 값들의 집합은 별도의 테이블로 만든다
• 이런 테이블들은 외래키 foreign key로 연결된다.

해당 레코드는 테이블의 기본키 (필요한 경우 복합키)가 아닌 다른 것에 종속해서는 안된다

제 3정규형 3NF

• 키에 의존하지 않는 필드를 제거한다

해당 레코드 키의 일부가 아닌 값이 테이블에 없어야한다. 일반적으로 필드 그룹의 내용이 단일 레코드 이상에 적용될 수 있는 경우 해당 필드를 별도의 테이블에 배치하는 방법을 고려해야한다.

비정규형 UNF unnormalized form :

데이터 베이스 정규형 조건을 충족하지 않는 데이터베이스 모델을 말한다.