본문 바로가기
JAVA

관계형 데이터베이스 설계(Schema / Entity , 1:1 / 1:M / N:M)

by code:J 2023. 7. 23.
반응형
SMALL

 

스키마(Schma) & 엔티티(Entity)

스키마(Schema)

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

즉, 데이터베이스를 어떻게 설계할 것인지에 대한 계획, 구조의 제약조건을 정하는 것입니다.

 

스키마는 아래와 같이 여러 테이블의 구조를 설계한 것입니다.

출처:https://drawsql.app/templates

스키마의 특징

  • 데이터 사전에 저장됩니다.
  • 시간이 지나도 변하지 않습니다.
  • 현실 세계의 특정한 부분을 모델로 만들어집니다.
  • 데이터 구조의 특성을 의미하며, 인스턴스에 의해 규정됩니다.

스키마의 3단 구조

스키마는 구조를 바라보는 입장에 따라 3단계의 스키마가 존재합니다.
  • 외부 스키마(서브 스키마)
  • 개념 스키마
  • 내부 스키마

1. 외부 스키마 (서브 스키마)

외부(사용자)에서 바라보는 스키마를 의미합니다.

 

사용자들이 사용할 데이터들을 보여주는 것이기 때문에 추상화가 되어있고, 여러 사용자가 바라보는 관점에 따라 여러 스키마가 존재할 수 있습니다.

 

예를 들어 티스토리라는 데이터베이스는 스토리 스키마, 스킨 스키마, 피드 스키마, 포럼 등으로 이루어져 있을 것입니다.

 

또한 사용자는 데이터베이스에서 데이터를 사용하는 사람이므로 응용 프로그래머라고 볼 수 있습니다.

 

사용자는 어떤 데이터가 필요한지를 결정하기 때문에 쿼리를 이용해서 데이터를 조작할 수 있습니다.

 

즉, 응용 프로그래머는 외부 스키마를 통해 구조를 확인하고 DML를 사용하여 데이터를 이용합니다.

데이터 조작어 : (DML :  Data Manipulation Language)

  • Insert
  • Select
  • Update
  • Delete

 

2. 개념 스키마

전체적인 개념을 정의하는 것을 의미합니다.

전체 데이터베이스가 어떤 구조로 되어있는지 구체적으로 어떠한 데이터가 있고, 그 데이터들은 어떤 테이블이 존재하고, 각 테이블마다 어떤 관계가 존재하는지를 정의합니다.

 

데이터베이스의 전체적인 구조를 확인하기 때문에 개념 스키마를 확인하는 사람은 데이터베이스 관리자 DBA입니다.

 

즉, DBA는 개념 스키마를 통해서 전체적인 구조의 개념을 확인하고 DDLDCL을 사용해서 구조를 설계합니다.

데이터 정의어(DDL : Data Definition Language)

  • Create
  • Alter
  • Drop
  • Rename
  • Truncate

데이터 제어어(DCL : Data Control Language) 

  • Grant
  • Revoke

 

3. 내부 스키마

실제 데이터의 내부를 정의하는 것을 의미합니다.

데이터의 내부 즉, 데이터의 필드 이름이 무엇이고, 해당 필드는 몇 Byte이며 인덱스가 있는지 등을 정의합니다.

 

이것은 곧 데이터를 물리적으로 어떻게 저장할지에 대해 정의한 것이므로 저장 스키마라고도 부릅니다.

 

물리적 저장장치의 입장으로 바라보기 때문에 내부 스키마를 확인하는 사람은 시스템 프로그래머입니다.

즉, 시스템 프로그래머는 내부 스키마를 통해서 데이터의 내부 구조를 확인하고 물리적인 데이터 구조를 설계합니다.

시스템 프로그래머란 내부 스키마를 통해서 데이터의 내부 구조를 확인하고 물리적인 데이터 구조를 설계합니다.

엔티티(Entity)

엔티티는 JPA를 사용해 보신 분은 익숙하겠지만, 그렇지 않다면 와닿지 않는 용어입니다.
엔티티는 실체, 객체라는 의미로 실무적으로는 엔티티라고 부릅니다.
즉, 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것으로 설명할 수  있습니다.

예시 ) 사원이라는 엔티티는 사번, 이름, 부서번호, 입사날짜, 연봉, 생년원일, 직위 등의 속성으로 특징지어질 수 있습니다.

 


관계형 데이터베이스

구조화된 데이터는 하나의 테이블로 표현할 수 있습니다.
사전에 정의된 테이블을 Relation이라고 부르기 때문에, 테이블을 사용하는 데이터베이스를 관계형 데이터베이스 RDB(Relational DataBase)라고 부릅니다.

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

데이터(Data)

: 각 항목에 저장되는 값

 

테이블 (Table or Relation)

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

 

칼럼(Column or Field or Attribute)

: 테이블의 한 열의 데이터를 의미합니다.

 

레코드(Record or Tuple or Row)

: 테이블의 한 행에 저장된 데이터를 의미합니다.

 

키(Key)

: 테이블의 각 레코드를 구분할 수 있는 값입니다.

: 각 레코드마다 고유한 값을 가집니다.

: 기본키(PK)와 외래키(FK) 등이 있습니다.

 


테이블과 테이블 사이의 관계 종류

1:1 관계

하나의 레코드가 다른 테이블의 레코드 한 개와 연결된 경우입니다.

User 테이블과 UserPrivacy라는 테이블이 있다고 가정해 봅니다.

  • User 테이블은 id, name, phone_id을 가지고 있습니다.
  • UserPhone 테이블은 id, phone_number를 가지고 있습니다.
  • 이중 User 테이블의 phone_id는 외래키(FK)로써, UserPhone 테이블의 id와 연결되어 있습니다.
  • 각 휴대폰 번호가 단 한 명의 유저와 연결되어 있고, 그 반대도 동일하다면, User 테이블과 UserPhone 테이블은 1:1 관계 (Ont to One Relationship)이라고 합니다.

그러나 1:1 관계는 자주 사용하지는 않습니다.

  • 만약 1:1로 나타낼 수 있는 관계라면 User 테이블에 phone_id 가 아닌 phone_number를 직접 저장하는 것이 좋을 수도 있습니다.

1:N 관계

하나의 레코드가 서로 다른 여러 개의 레코드와 연결된 경우입니다.

User 테이블과 UserPrivacy라는 테이블이 존재한다고 가정해 봅니다.

  • User 테이블은 id, name, userprivacy_id를 가지고 있습니다.
  • UserPrivacy 테이블은 id, phone_number, address, email를 가지고 있습니다.
  • 이 구조에서는 한 명의 User가 여러 정보를 가질 수 있습니다.
  • 그러나 여러 명의 User 가 하나의 개인정보를 뜻하는 UserPrivacy 테이블의 phone_number를 가질 수는 없습니다.
  • 이런 1 : N (일대다) 관계는 관계형 데이터베이스에서 가장 많이 사용합니다.

N : M 관계

여러 개의 레코드가 다른 테이블의 여러 개의 레코드와 관계가 있는 경우입니다.
N : M (다대다) 관계를 위해 스키마를 위해 스키마를 디자인할 때는, Joiin테이블 즉 중간테이블을 만들어 관리합니다.
위의 1 : N (일대다) 와의 관계가 비슷해 보이지만, 양방향에서 다수의 레코드를 가질 수 있습니다.

Feed라는 게시글, Like라는 좋아요 테이블 이 있다고 가정해 봅니다.

  • Feed (게시글) 하나는 여러 개의 좋아요를 받을 수 있고, Like (좋아요) 하나는 여러 게시글에 누를 수 있습니다.
  • 이렇게 Feed 테이블과 Like 테이블이 따로 존재한다면 N : M (다대다) 관계를 어떻게 표현해야 할지 궁금합니다.
  • N : M (다대다) 관계는 2 개의 1 : N (일대다) 관계와 모양이 같습니다.
  • 두 개의 1 : N 관계를 형성하는 새로운 테이블로 N : M 관계를 나타낼 수 있습니다.
  • 다대다 관계를 위한 테이블을 Join(중간) 테이블이라고도 합니다.
  • 이 중간테이블의 이름을 Feed_Like 테이블이라고 만들어줍니다.
  • Feed_Like테이블은 feed_id와 like_id를 묶어주는 역할을 합니다.
  • 이렇게 중간 테이블을 생성하더라도, 중간 테이블을 위한 기본키는 반드시 있어야 합니다.

만약 외래키를 리스트 형식으로 관리하는 필드가 있다면? 

즉, 조인 테이블을 사용하지 않는다면 어떤 문제가 있을까?

  1. 필드에 저장되는 데이터의 크기를 설정해야 하는데, 크기가 커지게 되며, 크기가 넘어간다면 데이터가 저장되지 않을 수도 있습니다.
  2. 한개의 데이터를 조회할 뿐인데 많은 비용이 발생하게 됩니다.
  3. 데이터를 수정할 때, 두 곳에 수정이 잘 되었는지 확인이 어렵고 실수를 유발 할 수 있습니다.
반응형
LIST