[DB] 요구사항 정의서 작성법

 안녕하세요 코북입니다. 추석 연휴의 파도에 휩쓸려 관성을 이겨내지 못하고 계속해서 쉬어버렸습니다. 너무 많이 쉬었다고 자책하기보다는 기왕 푹 쉬고 돌아왔으니 충전된 에너지로 더 열심히 공부해야겠다는 생각이 듭니다. 오늘은 프로젝트 시작 전 어떻게 데이터베이스를 구성해야 하는지 계획하는 요구사항 정의서 작성법에 대해서 기록하려고 합니다. 

 

▶ 개념적
▷ 요구사항 정의서 -> 테이블, 컬럼, *관계(1:1, 1:N, N:N) -> ERD로 표현

ex) 
1. 회원으로 가입하려면 아이디 비밀번호가 있어야 한다. 회원은 회원 아이디로 식별한다
 -> ERD에서 PK는 밑줄로 표시
2. 상품을 등록하려면 상품명과 상품아이디로 등록해야 한다
3. 한 명의 회원은 여러개의 상품을 주문할 수 있고,
하나의 상품은 여러명의 회원이 주문할 수 있다.
※ 기능은 적지 않는다

▷ 객체정의서 -> 테이블 명과 컬럼 명을 나열 
요구사항 정의서에서 이미 관계를 명시한 부분은 제외하고 작성한다
ex) 
1. 회원 : 아이디, 비밀번호
2. 상품 : 상품아이디, 상품명 
3. 게시글 : 게시글 번호, 게시글 제목, 게시글 내용
--> 이미 요구사항 정의서에서 관계를 정의했기 때문에 상품 컬럼명에 회원 아이디 같은 FK를 적을 필요가 없다

▶ 논리적 : 테이블 구조화 -> 테이블 이름, 컬럼 이름, PK(식별), data type, 길이, 제약조건, (관계 -> FK)

▷ 1:1 관계
FK가 어디에 존재하든 상관없다.
FK에 UK와 NOT NULL 제약조건을 추가해줘야한다. 
tip) 1:1관계는 실제로 거의 존재하지 않음

▷ 1:N 관계
FK가 N에 존재 -> 1의 PK가 N의 FK가 됨
ex) 
학생 테이블 교수테이블
학번 PK
교수번호 FK (N) 교수번호 PK (1)

▷ N:N 관계
두 테이블을 연결해줄 새로운 테이블이 필요! --> PK는 1개만 있어야 하기 때문에!
ex)
고객 테이블 연결테이블 상품테이블
고객ID PK (1) 고객ID FK (N)
상품ID FK  (N) 상품ID PK (1)

-> PK가 존재하는 테이블이 이상적인 테이블이므로 
연결테이블에도 PK를 설정해주는 것이 좋다

ex)
연결테이블
일련번호 PK
고객ID FK
상품ID FK
-> 고객테이블과 상품테이블의 정보를 둘 다 보여줄 때는 연결테이블을 사용한다

▶ 그 외 주의사항

▷ 테이블의 컬럼은 최소화하는 것이 좋다
ex) 
학생 테이블에는 학생의 정보만 들어가는 것이 좋다
FK는 테이블간의 관계를 연결하는 역할이라는 것을 인지하자
ex)
회원이 포인트를 가질 경우, 회원테이블과 포인트테이블을 따로 만들어서 관리하는 것이 좋다
포인트의 경우 가변적이고, 이력관리를 자주해줘야하기 때문이다
회원테이블에서 다 관리하면 복잡해지거나 중복이 발생할 수 있음

▷ 컬럼을 최소화하다 보면 테이블은 자연스럽게 쪼개진다 (쪼개지면 좋음)
테이블 수 가 적으면 데이터가 한 곳에 많이 누적되고 읽어 들일 때 성능의 문제가 발생할 수 있다

▷ 모든 테이블이 관계를 가질 필요는 없다. 관계가 없어서 더 좋은 효과가 생길 수도 있다
ex)
주 단위 매출

▷ 이력성 데이터의 관리 
소멸 데이터의 경우, 기존 테이블에 저장해 둘 필요가 없다
소멸 데이터 테이블을 만들어서 따로 관리하는 것이 낫다 -> 의미 없는 데이터들을 없애서 성능 up

 

 요구사항 정의서를 작성하는 것에 대해 배웠었지만, 따로 정리를 하지 않아 정보들이 머릿속에 복잡하게 얽혀있었습니다. 배웠던 부분을 정리하고 보니 확실히 이전보다 체계적으로 정리가 됐습니다. 특히 테이블의 관계 부분에 있어서 1:N 관계와 N:N 관계의 차이를 구분할 수 있게 됐습니다. 이력 관리 테이블의 경우 따로 테이블을 만들어서 관리하는 것이 보다 효율적이라는 것도 알 수 있었습니다.