21.06.08/DB설계, REST API의 네이밍

앞으로 일하면서 느끼거나 공부했던 것들을 간단하게 적어보려고 한다.
예쁘게 보이려고 적는게 아니니까 시간을 뺏기지 않는 선에서 기록하는 것을 목표로 한다.

 

<<지금까지 공부한 내용>>
DB 설계
Rest API의 URI 네이밍 가이드

 

 

 

DB 설계

이부분은 저번에 공부했던 내용이지만 못적어서 오늘 적어본다.

우리는 지금 mysql을 쓰고 있고 규모가 그리 크지는 않지만 작지도 않은 플랫폼의 데이터베이스를 설계하려고 했다.

 

처음에 생각한 방향으로 설계를 했을 때 DB는 엉망진창이었다.

제일 잘못 생각했던 부분은 다음과 같다.

 

매장에서 운영하는 프로그램들이 있고,

하나의 프로그램이 여러 매장에서 운영중일 수 있을 때의 관계를

N:M이라고 봤는데 이 경우에 무작정 매장에 JSON 데이터 타입의 column을 만들어서

속한 프로그램의 아이디를 배열 형태로 넣어주는 식으로 설계를 했다.

테이블을 너무 많이 만들면 안된다는 강박관념에 이렇게 짰던 것 같다.

-- 이런식으로

CREATE TABLE `Store`(
program JSON NULL COMMENT '진행프로그램'
...
);

 

하지만 이렇게 설계를 하면 데이터베이스의 중복이 발생할 가능성이 있고 수정/삭제 해야한다는 불편함이 있다.

따라서 데이터베이스의 구조를 바꾸고, 테이블 개수가 많아지더라도 향후 관리에 좋은 방향으로 설계를 다시 하기로 마음먹었다.

 

데이터베이스의 기본적인 구조, 제약조건 등 개념은 학교에서 데이터베이스시스템 수업을 통해 배웠었다. 

정규화 관련해서는 정보처리기사 자격증 공부를 하면서 공부했었다.

수업 때 기본 설계 방법도 배웠으나 조금더 큰 구조의 데이터 베이스를 설계하고 실제로 사용해보려니 어려운 점도 많았어서 리마인드겸 DB설계에 적용한 내용을 간단하게 메모해 놓으려고 한다.

---

관계형 데이터베이스 설계하는 방법

1. E-R 모델과 릴레이션 변환 규칙을 이용한 설계

2. 정규화를 이용한 설계: 이상현상을 제거하며 중복을 최소화하고 더 좋은 작은 릴레이션으로 분해하는 작업

---

-> E-R 모델과 릴레이션 변환 규칙을 이용한 설계 (참고)

1. 데이터 요구사항에 대한 분석 -> 요구사항 명세서
2. 개념 스키마 설계 -> ERD
   1. 개체(entity)와 속성(attribute)을 추출한다. 예를들어 사용자, 매장, 프로그램 등을 추출한다.
   2. 개체간의 관계를 추출한다. 이때 (1:1, 1:N, N:M), (선택적인 관계, 필수적인 관계)로 분류된다.
   3. 위의 내용으로 ERD를 생성한다.
3. 논리 스키마 설계 -> 릴레이션 스키마의 테이블 명세서
   
   1. 규칙1: 모든 개체는 릴레이션으로 변환
   2. 규칙2: N:M 관계는 릴레이션으로 변환 (여기가 위에서 내가 놓친 내용이었다!!!)
   3. 규칙3: 1:N 관계는 외래키로 표현 (약간 개체가 참여하면 외래키로 포함해서 기본키로 지정)
   4. 규칙4: 1:1 관계는 외래키로 표현 (외래키를 서로 주고 받음. 모든 개체가 1:1 관계에 필수적으로 참여하면 릴레이션 병합)
   5. 규칙5: 다중 값 속성은 독립 릴레이션으로 변환
4. 내부 스키마 설계 -> DB 스키마 생성 SQL문
   1. sql문 생성은 aquery.com 사이트를 이용해서 뽑아내주었다.

---

-> 정규화를 이용한 설계 (참고)

 

정규화란 데이터의 중복을 줄이고 무결성을 향상 시키는 등 여러 목적을 달성하기 위해 관계형 데이터베이스를 정규화된 형태로 재디자인하는 것을 말한다. 정보처리기사 공부할 때 공부하긴 했지만 실제로 실습해보지는 않았기 때문에 새로웠다.

 

정규화는 1-6정규화까지 있지만 실무에서는 대체로 1-3정규화까지를 거친다고해서 1-3정규화까지 적용해서 프로젝트 DB를 설계해보았다. 아래는 1-3정규화 과정의 대략적 내용이다.

 

제 1정규화(First Normal Form, 1NF)

테이블(Relation)이 제 1정규형을 만족했다는 것은 아래 세 가지 조건를 만족했다는 것을 의미한다.

1. 어떤 Relation에 속한 모든 Domain이 원자값(atomic value)만으로 되어 있다.
2. 모든 attribute에 반복되는 그룹(repeating group)이 나타나지 않는다.
3. 기본 키를 사용하여 관련 데이터의 각 집합을 고유하게 식별할 수 있어야 한다.

 

제 2정규화(Second Normal Form, 2NF)

제 2정규화를 수행 했을 경우 테이블의 모든 컬럼이 완전 함수적 종속을 만족한다.(부분 함수적 종속을 모두 제거되었다.) 이를 이해하기 위해서는 부분 함수적 종속과 완전 함수적 종속이라는 용어를 알아야 한다.

• 함수적 종속: X의 값에 따라 Y값이 결정될 때 X -> Y로 표현하는데, 이를 Y는 X에 대해 함수적 종속 이라고 한다. 예를 들어 학번을 알면 이름을 알 수 있는데, 이 경우엔 학번이 X가 되고 이름이 Y가 된다. X를 결정자이라고 하고, Y는 종속자라고 한다. 다른 말로 X가 바뀌었을 경우 Y가 바뀌어야만 한다는 것을 의미한다.
• 함수적 종속에서 X의 값이 여러 요소일 경우, 즉, {X1, X2} -> Y일 경우, X1와 X2가 Y의 값을 결정할 때 이를 완전 함수적 종속 이라고 하고, X1, X2 중 하나만 Y의 값을 결정할 때 이를 부분 함수적 종속 이라고 한다.

 

제 3정규화(Third Normal Form, 3NF)

테이블(Relation)이 제 3정규형을 만족한다는 것은 아래 두 가지 조건을 만족하는 것을 의미한다.

1. Relation이 제 2정규화 되었다.(The relation is in second normal form)
2. 기본 키(primary key)가 아닌 속성(Attribute)들은 기본 키에만 의존해야 한다.

 

---

Rest API의 URI 네이밍 가이드 (참고)

 

무작정 백엔드 API 개발을 시작하고 프런트엔드와 협업을 하면서 올바른 rest api의 url 네이밍 패턴이 무언인지 궁금해졌다. 당장은 개발자 수도 적고 시작하는 단계라 큰 영향이 없더라도 우리 개발팀의 개발 문화를 정하고, 나중에 규모가 커졌을 때 불편해 하지 않으려면 필요하다는 생각이 들었다. 그래서 네이밍에 대해서 찾아보게 되었다.

 

우선 Rest란 무엇일까?

HTTP URI를 통해 자원을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다고 한다. 인터페이스(URI로 지정한 리소스에 대한 조작을 한정적인 인터페이스로 수행), 무상태성(작업을 위한 상태정보 저장 및 관리 안함), 자체표현구조(Rest API 메시지만 보고도 이해할 수 있는 구조), 캐시기능(HTTP의 캐시 기능 적용 가능)이라는 특징이 있다.

 

Rest API URI 네이밍 규칙

1. 소문자를 사용한다..
2. 언더바 대신 하이픈을 사용한다.
3. 마지막에 슬래시를 포함하지 않는다.
4. 행위는 포함하지 않는다.
   1. ex) POST api/user/delete-post/1 (x) DELETE api/user/post/1 (O)
   2. 처음에는 여기서 잘못 네이밍을 했다. 행위는 포함하지 말아야지!
5. 파일 확장자는 URI에 포함시키지 않는다. (accept header를 사용한다.)
6. 가급적 전달하고자하는 자원의 명사를 사용하되, 컨트롤 자원을 의미하는 경우 예외적으로 동사를 허용한다.