[실전]미니 프로젝트 - channel과 user ERD를 생각해보자

지금까지 미니프로젝트에서 data를 database Schema를 만드는 게 아니라 Map 객체를 이용해서 사용을 했었는데요. 본격적으로 시작하기 앞서서 database를 만들 때 참고할 ERD를 짜보려고 합니다.

 

테이블은 두 가지로 만들 건데요. 첫 번째로 user 테이블, 두 번째로 channel 테이블을 만들어볼 예정입니다.

 

1) USER TABLE

필요 데이터 : 회원번호, 회원아이디, 회원비밀번호, 회원이름

이때 회원번호는 고유번호로 PK, 회원아이디도 단 하나의 아이디여야 하기 때문에 UQ, 로 설정을 하려 합니다.

회원번호(PK)	아이디(UQ)	비밀번호	이름
1	testId1	1234	테스터1
2	testId2	9876	테스터2

 

2) CHANNEL TABLE

필요데이터 : 채널번호, 채널주인( = 회원아이디), 채널명, 채널설명, 구독자수, 영상수

채널번호는 고유 번호로 PK, 채널명은 중복을 허용하지 않기 위해 UQ, 채널을 운영하는 사람을 채널주인이라 하여 사용자를 받아올 수 있게 FK로 설정을 하였습니다.

채널번호 (PK)	채널주인 (FK)	채널명(UQ)	채널설명	구독자 수	영상 수
1	testId1	채널1	채널 1번 설명글	10	1
2	testId1	채널2	채널 2번 설명글	100	20
3	testId2	채널3	채널 3번 설명글	1000	300
4	testId1	채널4	채널 4번 설명글	10000	4000
5	testId2	채널5	채널 5번 설명글	100000	50000

이렇게 데이터를 해보면 채널이 유저 테이블에 접근을 하고 있는 걸 알 수 있습니다.

그렇다면 이 user 테이블과 channel 테이블과의 관계는 어떻게 정의할 수 있을까요?

User Table - Channel Table의 관계

사용자 한명당 채널이 하나만 존재한다면 테이블 과의 관계는 1:1이 됩니다.

하지만 설계할 당시에 사용자 한 명당 채널 백개를 사용한다 정의했는데요. 그렇기 때문에  1:N의 관계를 가지게 됩니다.

 

위 테이블을 기준으로 기존에 작성한 API를 수정을 진행하면 될 것 같습니다.

중복데이터를 허용하지 않는 이유
⭐ 비용 및 공간활용 : 테이블의 데이터가 늘어날수록 용량도 커지기 때문에 유료 DB 같은 경우에는 그만큼의 비용을 지불하게 됩니다. 그리고 중복데이터를 최대한 없애면 자료저장 공간을 최소화할 수 있습니다.
⭐ 이상발생 : 정규화를 거치지 못한 테이블의 경우에는 불필요한 중복이 존재하는데 이때 테이블 조작 시에 곤란한 현상이 발생하는데 이를 이상(Anomaly)이라 하며 대게 삽입이상, 삭제이상, 갱신이상이라고도 합니다. 때문에 중복데이터 허용하지 않는 것은 이상발생을 방지하는 것을 말합니다.