테이블 간의 관계 (1:1 / 1:M / N:M)

스키마(schema)란?

• 스키마란 데이터베이스를 구성하는 레코드의 크기, 키(key)의 정의, 레코드와 레코드의 관계, 검색 방법 등을 정의한 것을 말한다.
• 스키마란 데이터베이스에서 데이터가 구성되는 방식과 서로 다른 엔티티 간의 관계에 대한 설명을 말한다.
• 즉, 데이터베이스의 청사진과 같다.

 

엔티티(Entity)란?

• 엔티티란 실체, 객체라는 의미로 실무적으론 엔티티라고 부른다.
• 즉, 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것으로 설명할 수 있다.
• 예) 학생이라는 엔티티는 학번, 이름, 학점, 등록일자, 생일, 전공 등의 속성으로 특징지어질 수 있다.

 

관계형 데이터베이스 중요 키워드

데이터(data)

• 각 항목에 저장되는 값이다.

 테이블(table; 또는 relation)

• 사전에 정의된 열의 데이터 타입대로 작성된 데이터가 행으로 축적된다.

칼럼(column; 또는 field)

• 테이블의 한 열을 가리킨다.

레코드(record; 또는 tuple)

• 테이블의 한 행에 저장된 데이터이다.

 키(key)

• 테이블의 각 레코드를 구분할 수 있는 값이다.
• 각 레코드마다 고유한 값을 가진다.
• 기본키(primary key)와 외래키(foreign key) 등이 있다.

 

 

1 : N 관계

 

• 하나의 레코드가 다른 테이블의 레코드 한 개와 연결된 경우이다.
• 다음과 같이 Users 테이블과 Phonebook 테이블이 있다고 가정한다.
• Users 테이블은 ID, name, phone_id를 가지고 있다.
• 이 중 phone_id는 외래키(foreign key)로써, Phonebook 테이블의 ID 와 연결되어 있다.
• Phonebook 테이블은 ID와 phone_number를 가지고 있다.
• 각 전화번호가 단 한 명의 유저와 연결되어 있고, 그 반대도 동일하다면, Users 테이블과 Phonebook 테이블은 1:1 관계(One-to-one relationship)이다.
• 그러나 1:1 관계는 자주 사용하지 않는다.
• 1:1로 나타낼 수 있는 관계라면 Users 테이블에 phone_id를 대신해 phone_number를 직접 저장하는 게 나을 수 있다.

 

 

 

 

 

N : M 관계

• 여러 개의 레코드가 다른 테이블의 여러 개의 레코드와 관계가 있는 경우이다.
• N:M(다대다) 관계를 위해 스키마를 디자인할 때에는, Join 테이블을 만들어 관리한다.
• 1:N(일대다) 관계와 비슷하지만, 양방향에서 다수의 레코드를 가질 수 있다.
• 다음과 같이 여행 상품을 관리하는 테이블이 있다고 가정한다.

• 여러 개의 여행 상품이 있고, 여러 명의 고객이 있다.
• 고객 한 명은 여러 개의 여행 상품을 구매할 수 있고, 여행 상품 하나는 여러 명의 고객이 구매할 수 있다.
• 이렇게 Customer 테이블과 Package table이 따로 존재한다면, N:M(다대다) 관계를 어떻게 표현할 수 있을까?
• 다대다 관계는 두 개의 일대다 관계와 그 모양이 같다.
• 두 개의 테이블과 1:N(일대다) 관계를 형성하는 새로운 테이블로 N:M(다대다) 관계를 나타낼 수 있다.
• 이렇게 다대다 관계를 위한 테이블을 조인 테이블이라고 한다.
• N:M(다대다) 관계를 그림으로 나타내면 다음과 같다.

 

 

• customer_package 테이블에서는 고객 한 명이 여러 개의 여행 상품을 가질 수 있고, 여행 상품 하나가 여러 개의 고객을 가질 수 있다.
• customer_package 테이블은 customer_id와 package_id를 묶어주는 역할이다.
• 이 테이블을 통해 어떤 고객이 몇 개의 여행 상품을 구매했는지 또는, 어떤 여행 상품이 몇 명의 고객을 가지고 있는지 등을 확인할 수 있다.
• 이렇게 조인 테이블을 생성하더라도, 조인 테이블을 위한 기본키(여기서는 ID)는 반드시 있어야 한다.
• 만약 외래키를 리스트 형식으로 관리하는 필드가 있다면, 어떤 문제가 발생할 수 있을까? 즉, 조인 테이블 사용하지 않는다면 문제점.
  • 문제 1. 필드에 저장되는 데이터의 크기를 설정해야하는데 엄청 커지게 되고 데이터가 저장되지 못할 수 도 있다.
  • 문제 2. 데이터를 조회하는데 많은 비용이 발생하게 된다.
  • 문제 3. 데이터를 수정할 때 두 곳에 수정이 잘 되었는지 확인이 불편하다. (실수를 유발한다.)

 

 

자기참조 관계(Self Referencing Relationship)

• 때로는 테이블 내에서도 관계가 필요하다.
• 예를 들어 추천인이 누구인지 파악하기 위해 사용할 수 있다.
• 다음과 같이 유저 테이블이 있다.
• user_id는 기본 키(primary key), name은 사용자의 이름, 그리고 recommend_id는 추천인 아이디이다.
• User 테이블의 recommend_id는 User 테이블의 user_id와 연결되어 있다.
• 한 명의 유저(user_id)는 한 명의 추천인(recommend_id)를 가질 수 있다.
• 그러나 여러 명이 한 명의 유저를 추천인으로 등록할 수 있다.
• 이 관계는 1:N(일대다) 관계와 유사하다고 생각할 수 있다.
• 그러나 일반적으로 일대다 관계는 서로 다른 테이블의 관계를 나타낼 때 표현하는 방법이다.

 

 

 

 

참고

https://hanamon.kr/%EA%B4%80%EA%B3%84%ED%98%95-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%84%A4%EA%B3%84-%EA%B4%80%EA%B3%84-%EC%A2%85%EB%A5%98/

관계형 데이터베이스 설계 (관계 종류 1:1 / 1:M / N:M ) - 하나몬

 

https://inpa.tistory.com/entry/DB-%F0%9F%93%9A-%ED%82%A4KEY-%EC%A2%85%EB%A5%98-%F0%9F%95%B5%EF%B8%8F-%EC%A0%95%EB%A6%AC

[DB] 📚 데이터베이스 키(KEY) 종류 🕵️ 정리