[DB] Data Modeling

목차
1. 개념적 데이터 모델링 (feat. ERD)
2. 논리적 데이터 모델링
3. 물리적 데이터 모델링
4. 효율적 데이터 모델링
5. 참고 자료

---

1. 개념적 데이터 모델링 (feat. ERD)

 

모델링 이전에 가장 중요한 건 내가 만들고자 하는 서비스가 무엇인지 파악하고

UI를 우선적으로 확인하는 과정이 선행되어야 함을 잊지말자.

데이터 모델링 절차

 

어떤 프로젝트를 시작하기에 앞서, 백엔드 자원을 활용하기로 결정했다면 어지간히 간단한 서비스가 아니고서야 개발 도입 단계에서 필수적으로 거쳐가야 하는 것이 모델링이 아닐까 싶다.

모델링을 명확히 해야 백엔드와 프론트 엔드가 서로 딴소리 하는 불상사를 미연에 방지할 수 있기도 하고.

 

개념적 데이터 모델링이라는 건 결국 내가 처리할 데이터 간의 관계를 구상하는 단계이다.

개체 간의 관계를 찾아내어 정의하고, 표현하기 위하여 ERD를 생성하게 된다.

💡 Entity Relationship Diagram (ERD)
개체-관계 모델을 정의한 다이어그램으로써, 프로젝트에서 사용되는 데이터 베이스의 구조를 한 눈에 파악하고 API를 효율적으로 활용할 수 있게 만드는 모델 구조이다.
단순하게 설명하자면 실전 DB를 만들기 전에 간단하게 도형으로 만들어보자는 것.

학생 등록 시스템을 위한 ERD 템플릿

직사각형, 다이아몬드, 타원형과 연결선과 같은 기존에 정의되어 있는 기호 집합을 사용하여 Entity, Relationships 등의 상호 연결성을 보여준다.

그렇게 만든 ERD를 토대로 위의 이미지처럼 데이터 베이스를 구축하게 된다.

 

기본 요소로써 위의 사진에 나와있는 것들이 있는데 3가지 정도만 알아볼 예정.

 

1. Entity

Entity는 개체를 의미하며 표현하고자 하는 중요한 개념이나 정보를 독립적 단위로 구성한다.

예를 들어, 유저는 이름, 닉네임, 아이디 등의 속성(attributes)으로 구성된 Entity이다.

어떤 시스템이냐에 따라 Entity는 사람, 장소, 이벤트, 오브젝트가 될 수도 있다.

ERD에서 직사각형으로 표시되고 단수 명사를 사용하여 이름을 저장하는 게 기본 원칙이다.

나중에 이 Entity가 하나의 테이블이 된다고 생각하면 쉽다.

 

2. Attribute

개체의 특징이나 상태를 표현한다.

Entity에서 언급한 유저의 이름, 닉네임, 아이디 등이 속성에 해당한다.

속성은 이후 테이블의 필드(컬럼)가 된다.

여기서 중요한 건 데이터 타입(Domain)을 명시해주어야 한다.

 

3. Multivalued Attribute

이 내용을 넘길까 하다가 실전에서 하나의 테이블로 분리해야하는 경우가 있어서 언급하고 넘어가자.

하나의 개체에 속성이 둘 이상의 값을 가질 수 있는 경우 다중 값 속성이라고 한다.

예를 들어서 교사는 여러 과목을 가르칠 수도 있는데 보통 이런 케이스는 DB에서 Subject 테이블을 분리해버린다.

 

4. Relationship

Entity 사이의 관계를 나타낸다.

예를들어 고객과 계좌라는 Entity 사이에는 예금주라는 관계가 정의될 수 있다.

 

5. Cadinality and Ordinality

숫자 컨텍스트를 배치하여 Entity 간의 관계를 추가 정의할 수 있다.

1:1, 1:N, N:N 관계를 보다 명료하게 정의하기 위해 쓰인다.

실전에선 이런 선을 이용해서 정의하기 때문에 미리 숙지해두는 것이 좋다.

• One : 일대일 혹은 일대다 관계. 하나의 외래키가 존재한다.
• Many : 다대다 관계. 중계 테이블을 통해 여러 가지 데이터를 참조할 때 사용
• One (and only one) : 일대일 관계이긴 한데, 하나의 row끼리만 연결되어 있는 데이터
• Zero or one : 필수 조건을 가지지 않은 일대일 혹은 일대다 관계
• One or many : 참조되는 row 값들이 불명확한 일대일 혹은 다대다 관계
• Zero or many : 참조하는 테이블 간의 관계가 불명확함. row 생성값이 불명확한 장바구니가 예시

이걸 이용해서 이제 One to one(1대1 대응), Many to many(다대다 대응)과 같은 관계를 정의할 수 있게 된다.

📌 중계 테이블
Many to many Cardinality(N:M 관계)는 직관적으로 이해도 잘 안 되는 내용이었는데,
이번에 공부하면서 알아보니 다대다 관계는 완성되지 않는 모델로 간주하여 1:N 관계로 전환시켜주는 작업을 필요로 한다고 한다.
예를 들어, 유저 엔티티와 그룹 엔티티의 관계를 정의하기 위해 그룹에 속한 유저를 판단하는 경우를 가정하자.
하나의 유저는 여러 그룹에 속해있을 수 있지만, 하나의 그룹 또한 여러 유저가 속해있을 수 있으므로 이는 N:M 관계라고 볼 수 있다.
따라서 두 개의 엔티티만으로 표현 불가능한 경우 멤버 테이블을 따로 분리하여 유저와 그룹의 관련성을 표현하기 위한 다른 엔티티를 필요로 하는데 이를 중계 테이블이라고 한다.
이렇게 되면 유저와 멤버 테이블은 1대다 관계이고, 그룹과 멤버 테이블 또한 1대다 관계가 성립하게 된다.

 

🔐 PK와 FK

PK(Primary Key, 기본키)와 FK(Foregin Key, 외래키)라고 불리는 이것들은 ERD 구성 요소 표기법에서 매우 중요한 내용이다.

우선 pk 값은 중복이 없고 Null이 허용되지 않는 유일한 값에 지정하는 키로써 기본적으로 백엔드 툴에선 자동으로 '테이블명_id'라는 이름의 pk를 생성한다.

fk도 key의 일종이긴 한데, 현재 테이블이 참조하고 있는 테이블의 pk값을 가져온다.

이름은 보통 어느 테이블을 참조하고 있는지 알기 위해 '(참조하고 있는)테이블명_id'라고 지어서 구분한다.

즉, pk와 fk로 현재 테이블이 참조하고 있는 모델을 필드에 추가함으로써 관계를 정의할 수 있게 되는 것이다!

✍🏻 점선과 실선
두 개체를 선으로 이을 때, 부모의 키를 PK로 받는지 단순히 일반 속성으로 참조하는지에 따라 구분한다.
만약 PK를 일반 속성으로 받는다면 비식별자 관계로써 점선으로 표시하고
부모 키를 PK로 포함한다면 식별자 관계로써 실선으로 표시한다.

 

---

2. 논리적 데이터 모델링

 

Entity 수준의 모델링이 완성되면 구체화를 시켜주어야 한다.

이 과정을 논리적 데이터 모델링이라고 하는데 말만 그럴싸하고 딱히 별 거 없다.

• Entity      →   Table
• Attribute  →   Column(Field)
• Relation  →   PK, FK
• Tuple      →   ROW

위에서 열심히 그린 ERD를 이용해서 Key, 속성, 관계 등을 구체화하고 표시한다.

ERD는 어디까지나 단순하게 구상해보는 단계이기 때문에 여기서 중복 제거 및 일관성 확보를 통하여

DB 모델의 신뢰성을 높이고 보다 효율적은 모델링으로 수정하는 작업을 거친다.

 

동아리 운영진 붙잡고 난생 처음 짜본 데이터 모델. 여러모로 오류가 많지만 뿌듯하다.

여기서 각 필드의 데이터 타입을 명시하고 관계를 명시해준다.

 

---

3. 물리적 데이터 모델링

 

물리적 데이터 모델링은 최종적으로 위에서 작성한 관계형 모델을 관리할 데이터 베이스를 선택하고,

선택한 데이터 베이스에 실제 테이블을 만드는 작업을 말한다.

 

create table user_tbl (
    user_id bigint primary key auto_increment,
    username varchar(45) not null,
    nickname varchar(45) unique not null,
    password varchar(45) not null,
    (...)
);

대충 여기까지 하면 완성 단계라고 보면 된다.

 

---

4. 효율적 데이터 모델링

 

나도 DataBase라고 해봐야 코딩을 처음 배울 때, MySQL을 조금 만지작 거린게 다였고

그나마 최근에 프로젝트를 수행하면서 한 번 직접 모델링을 해본 게 다라서 효율적인 모델이 무엇인지는

아직 잘 모르겠고, 여전히 DB는 어렵다고 느낀다.

오히려 데이터 공간을 낭비하지 않기 위해 너무 강박증을 느껴서 더 비효율적인 모델링을 한 것 같기도 하다.

내가 어떤 식으로 데이터를 관리할 것이냐에 따라서 천차만별로 다양한 관계가 정의될 수 있어서 참 어려운 것 같다.

 

사실 이 내용은 여기서 한 번에 다룰만한 내용은 아니고 이후에 데이터 베이스의 정규화에 대해 포스팅하게 되면 더 자세하게 정리할 것이다.

이번 포스팅에서는 딱 한 가지만 언급하고 끝내자.

 

중복된 데이터를 저장해서는 안 된다!

 

---

5. 참고 자료

 

 

Entity Relationship Diagram (ERD) | ER Diagram Tutorial