데이터 모델
데이터를 사용하려는 목적에 맞게 정리하고 체계화 해놓은 모형
Entity (개체)
저장하고 싶은 데이터의 대상으로 실제 대상 하나하나(로우)를 의미하지만 우리가 흔히 테이블이라고 부르는 Entity Type을 일반화하여 Entity라고 부르기도 한다.
Attribute (속성)
Entity에 대해서 저장하려는 내용, 컬럼(필드)를 의미한다.
Relationship (관계)
entity들 사이 연결지점을 의미한다.
Constraint (제약조건)
각 데이터에 대한 일종의 규칙을 의미한다.
데이터 모델링의 목적
- 저장하고자 하는 데이터에서 Entity, Atrribute, Relationship, Constraint 파악
- 데이터베이스를 구축할 때 기반이 될 모델을 만들기 위함
Relational Model
Relation은 테이블을 의미하는 수학적 표현으로 Relational model은 테이블로 정리해서 표현한 모델을 의미한다.
각 테이블끼리 FOREIGN KEY 로 맺어지는 관계는 RELATIONSHIP 이라고 한다. 혼동하지 않도록 주의한다.
Relational Model 단점
- 로우만으로는 데이터의 구조를 알 수 없다.
- 테이블 간의 관계를 직관적으로 파악할 수 없다.
Entity Relationship Model(ERM)
테이블간의 관계를 보여주는 모델, 테이블 이름과 속성만 표시한 entity들을 선으로 연결해 각 관계를 직관적으로 보여주는 역할을 한다. 선의 모양에 따라 관계를 이해할 수 있다.
DBdiagram: ERM을 직접 그려볼 수 있는 사이트
데이터 모델의 3가지
- 개념 모델(Conceptual model) : 주요 Entity와 간단한 연결관계만을 나타낸다. attribute는 구체화하지 않고 대략적인 구조를 파악할 때 사용한다.
- 논리 모델(Logical model) : Entitiy(테이블 이름) 뿐만 아니라 Attribute도 표현하고 Primary Key, Foreign Key 까지 표시한다.
- 물리모델(Physical model) : 데이터를 구축할 수 있을 정도의 자세한 정보가 포함된 모델, 각 attribute의 데이터 타입 부터 변수 이름, 인덱스 등 세부 정보를 담고 있다.
좋은 데이터베이스 vs 나쁜 데이터베이스
| 좋은 데이터베이스 | 나쁜 데이터베이스 |
|---|---|
| 중복, 틀린 데이터가 없음 | 데이터 중복 저장, Null 이 많음 |
| 빠르고 정확하게 데이터를 다룰 수 있음 | 연산이 너무 오래 걸림 |
| 데이터가 늘어날 때마다 컬럼 구조가 변하지 않음 | 원하는 정보를 찾을 수 없음 |
| - | 틀린 데이터를 저장하고 있음 |
| - | 데이터가 늘어날때마다 컬럼 구조가 변함 |
데이터 모델링의 순서
1) Entity, attribute, relationship 파악부터 시작한다.
비즈니스 룰을 기반으로 정리한다. 비즈니스 룰이란 특정 조직이 운영되기 위해 따라야하는 정책, 절차, 원칙들에 대한 간단 명료한 설명을 의미한다. 쉽게 말해 웹사이트, 페이지에서 제공하는 모든 기능에 관한 규칙이다.
비즈니스 룰 예시
- 유저는 상품을 주문할 수 있다.
- 동일한 주문 내역은 한 번의 배달로, 3일 안에 유저가 지정한 배송지에 전달돼야 한다. 만약 그렇지 못할 시, 유저에게 최대한 빨리 알려줘야 한다.
- 유저는 상품에 대한 평가를 줄 수 있다. 평가는 두 종류의 데이터: 1~5 사이 자연수의 별점, 그리고 200자 이내 줄 글을 통해 할 수 있다.
비즈니스 룰을 기반으로 entity, attribute, relationship 찾는 법
- 모든 명사는 entity 후보다.
- 모든 동사는 realtionship 후보다.
- 하나의 값으로 표현할 수 있는 명사는 attribute 후보이다.
위의 예시에서 다시 살펴보자.
- 유저(명사) 는 상품(명사)을 주문(동사)할 수 있다.
위 비즈니스 룰에 따르면 유저라는 테이블과 상품이라는 테이블, 그리고 둘 사이에는 주문이라는 relationship이 있을 수 있다.
- 동일한 주문 내역(명사)은 한 번의 배달로, 3일 안에 유저(명사)가 지정한 배송지(하나의 값으로 표현할 수 있는 명사)에 전달돼야 한다. 만약 그렇지 못할 시, 유저(명사)에게 최대한 빨리 알려줘야 한다.
여기서 배송지는 주문이라는 테이블의 attribute가 될 수 있다. 이제 주문이라는 새로운 entity가 생겼으니 유저와 상품의 relationship이 바뀔 수 있다. 주문이라는 entity가 둘의 relationship을 대체해 유저는 주문과, 주문은 상품과 relationship을 갖는다.
- 유저(명사)는 상품(명사)에 대한 평가(명사)를 줄(동사) 수 있다. 평가(명사)는 두 종류의 데이터: 1~5 사이 자연수의 별점(속성), 그리고 200자 이내 줄 글(속성)을 통해 할 수 있다.
평가라는 entity가 있고 이는 별점과, 줄글 이라는 속성을 갖는다. 또한 평가는 유저와 상품과 relationship이 있다.
비즈니스룰이 구체적이지 않거나 누락된 것이 있으면 모델링을 할 때 문제가 생길 수 밖에 없다. 따라서 비즈니스 룰은 간단명료하면서도 필요한 내용을 모두 담고 있어야한다.
비즈니스 룰을 토대로 만들어진 ERM은 초안이 되지만 확정적인 모델이라고는 할 수 없다.
! '하나의 값으로 표현할 수 있는 명사는 attribute 후보이다.' 의 예외 규칙
- Entity안에 똑같은 종류의 여러 attrubute를 저장해야 할 때
유저(명사)는 여러개의 주소(속성)를 가질 수 있다.
한 유저가 여러개의 주소를 갖기 위해서는 address 컬럼이 계속 추가돼야 한다.
| name | address1 | addresss2 | address3 |
|---|---|---|---|
| 김코딩 | 서울시 | 수원시 | 제주도 |
| 김자바 | 인천시 | null | null |
| 박모모 | 서울시 | 과천시 | null |
이렇게 구성했을 때의 문제점
-
같은 종류의 컬럼이 여러개가 생기면 null이 많이 생성된다. 이렇게 구조적으로 null이 많이 생기는 경우는 최대한 피해야 한다.
-
컬럼을 몇개 만들어야 하는지 애매해진다. 이 경우 주소를 가장 많이 저장한 유저에 맞게 컬럼 개수를 추가해야한다.
-
조회가 복잡하다. 특정 주소를 가진 회원을 찾기 위해서는 address1,2,3을 모두 조회해야한다. 조회가 비효율적이게 된다.
이러한 이유로 이같은 경우는 address를 하나의 테이블로 분리해서 foreign key로 유저 테이블과 연결해주는 것이 좋다.
요약하면 하나의 값으로 표현할 수 있는 명사는 attribute후보 이지만 여러값을 가질 수 있다면 entity후보이다.
카디널리티(Cardinality)
Entity type A와 B 사이에서 A Entity 한 개와 B Entity 몇 개와 연결될 수 있고, B Entitiy 한 개와 A Entity 몇개와 연결될 수 있는지
1:1
EntityA에 대해서 EntityB 가 하나밖에 없고 EntityB에 대해서도 EntityA가 하나밖에 없는 관계
ex) 시민 - 주민등록증
1:N
하나의 A에 대해서 여러개의 B가 있을 수 있고 하나의 B에 대해서는 하나의 A만 존재한다.
ex) 유저 - 리뷰 : 한 명의 유저는 여러개의 리뷰를 작성할 수 있지만 각 리뷰의 작성자는 한 명 뿐이다.
M:N
하나의 A에 대해서 여러개의 B가 존재할 수 있고 하나의 B에 대해서 여러개의 A가 존재할 수 있다.
ex) 유저 - 찜하기 : 한 명의 유저는 여러개의 상품을 찜할 수 있다. 하나의 상품도 여러명의 유저에게 찜당할 수 있다.
카디널리티 또한 비즈니스 룰에 따라 파악할 수 있다. 예를 들어 페이스북의 경우 한명의 유저가 하나의 프로필을 가지기 때문에 유저와 프로필은 1:1관계이지만 넷플릭스의 경우 한명의 유저가 여러개의 프로필을 가지기 때문에 이때는 1:N관계이다.
카디널리티(Cardinality)로 ERM 나타내기
ERM에서 카디널리티는 두 테이블의 relationship을 나타내는 선의 모양으로 표시한다. 
세로 선과 여러갈래로 뻗은 선은 1과 N을 의미한다. 이는 한개의 Entity가 다른 Entity와 최대 몇개까지 연결될 수 있는지를 나타낸다.
원모양은 최소 몇개까지 연결될 수 있는지를 나타내는데 예를들어 유저와 리뷰관계를 나타낼 때 유저는 리뷰를 하나도 안남겨도 되지만 리뷰는 항상 한명의 작성자를 갖는다는 점에서 유저는 원, 리뷰에는 세로선이 사용된다.
다시 말해 하나도 없어도 되는 entity면 원을, 적어도 하나는 있어야 하면 세로선을 사용한다. 이를 최대 카디널리티와 함께 사용하면 아래와 같다. 최소카디널리티는 최대 카디널리티보다 안쪽에 표시한다.
1:1, 1:N, M:N 관계 모델링
1:1 관계 모델링
두 Entity중 하나, 혹은 양쪽 Entity모두에 Foreign Key를 부여할 수 있다. 예를들어 유저가 하나의 결제카드만 등록할 수 있다면 유저 엔티티의 아이디를 카드 엔티티의 foreign key로 참조할 수 있다. 한명의 유저가 반드시 카드를 등록해야하는 것이 아니면 유저에 foreign key설정을 피하는 것이 좋은데 이유는 null값이 생기기 때문이다. 만약 유저가 무조건 카드가 있어야만 할때는 유저테이블에 카드 아이디를 foreign key로 넣어도 된다.
1:N 관계 모델링
항상 다수쪽에 해당하는 entity에 foreign key를 설정한다. 만약 유저와 리뷰 테이블이 있다면 리뷰 테이블에 foreign key를 설정하면 된다. 만약 반대로 설정하면 한명의 유저는 여러개의 리뷰를 가질 수 있기 때문에 리뷰 컬럼이 작성할 때마다 늘어나야 한다. 이러한 상황은 최대한 피해야 한다. 이유는 여기 참조
M:N 관계 모델링
다대다 관계에 있는 두 Entity는 테이블 두개만으로 표현하기 어렵기 때문에 연결 테이블(Junction Table)을 만들어야 한다. 예를 들어 고객은 여러개의 여행상품을 살 수 있고 각 여행상품는 여러개의 고객에게 팔릴 수 있다. 그러면 고객과 패키지 아이디를 모두 참조하는 두개의 foreign key를 가진 연결 테이블 customer_package를 새로 생성한다. 이렇게 하면 두 엔티티 사이에 생성되는 모든 관계를 저장할 수 있다. 이처럼 다대다 관계에서는 구매하다(동사)도 entity 후보가 될 수 있다.
