스키마란?
스키마는 데이터베이스에서 서로 다른 엔티티(혹은 테이블로 이해) 간의 관계에 대하여 설명한 자료이다. RDBMS(관계형 데이터베이스)에서 데이터 간의 관계에 대한 설계도로 이해 할 수 있다.
스키마가 왜 필요할까?
SQL 데이터베이스, RDBMS 같은 경우 데이터의 일관성, 데이터의 무결성 제약 조건 등의 조건이 있다. 이는 데이터를 더욱 효율적으로 관리하고 처음부터 끝까지 탐색해야하는 SQL이기 때문에 조회의 속도를 높인다. 예를들어 우리가 수강신청에 대한 데이터베이스를 구축해야 한다고 생각했을 때 여러가지 중복될 수 밖에 없는 데이터들이 있다.
- 학생들이 수강하는 교과목 : 1명의 학생은 N개의 교과목을 수강한다. 만약 학생 수강 과목을 학생 데이터 테이블에 저장하여 관리한다면 리스트 형태로 관리해야하고 이는 저장 공간의 범위 지정 문제 뿐 아니라 나중에 많은 데이터가 쌓였을 때 검색 또한 굉장히 오래 걸린다.
- 교과목을 수강하는 학생들 : 1개의 교과목은 N명의 학생들이 수강한다. 또 이것을 교과목의 테이블 마다 학생들의 리스트를 넣어놓게 되면 데이터의 중복이 발생되고 교과목과 학생수가 많아 졌을 경우 굉장히 비대해진다.
< 예시. 학생 테이블>
student_id | name | gender | age | addrees | course_id |
1 | Alice | 여자 | 23 | 서울시 강남구 | 1,2,3,4,5... |
2 | Bob | 남자 | 25 | 서울시 종로구 | 1,2,3,4,5... |
<교과목 테이블>
course_id | name | professor | student_id |
1 | 데이터베이스 | 김교수 | 1,2,3,4,5... |
2 | 알고리즘 | 박교수 | 2,3,1,5... |
3 | 운영체제 | 이교수 | 1 |
위의 예시를 보면 N:N 관계를 효율적으로 활용하지 못한 데이터베이스 설계이다. 데이터의 리스트가 가변적으로 늘어나지도 않을 뿐더러 수강신청 변경이 일어날 때마다 학생테이블에서 course_id를 삭제 해야하고 교과목 테이블에서 이 학생을 찾아 다시 또 삭제해야한다. 이런 것을 해결하기 위해 JOIN 테이블을 만들어서 N:N 관계의 스키마 구조를 만들 수 있다.
<N:N 관계 -> Join 테이블>
학생 테이블(students)에 데이터 추가:
student_id | student_name | gender | age | address |
1 | Alice | 여자 | 23 | 서울시 강남구 |
2 | Bob | 남자 | 25 | 서울시 종로구 |
과목 테이블(courses)에 데이터 추가:
course_id | course_name | professor |
1 | 데이터베이스 | 김교수 |
2 | 알고리즘 | 박교수 |
3 | 운영체제 | 이교수 |
수강 테이블(enrollments)에 데이터 추가 (JOIN 테이블):
student_id | course_id |
1 | 1 |
1 | 3 |
2 | 2 |
2 | 3 |
SELECT * FROM enrollments WHERE student_id = 1;
위와 같이 수강 테이블에서 student_id = 1 인 학생이 수강하는 모든 과목을 찾을 때 아래와 같은 결과를 만들 수 있다.
"student_id"가 1인 학생이 수강한 과목을 검색하는 SQL 문 실행 결과:
student_id | course_id |
1 | 1 |
1 | 3 |
수강 테이블은 Join테이블로 학생과 과목 테이블의 관계인 N:N을 학생 과 수강테이블(1:N), 과목과 수강테이블(1:N)으로 서로의 Foreign Key(FK) 를 참조하여 빠른검색이 가능하도록 만든다. 이것을 활용하여 course_id = 1을 수강하는 학생들의 이름을 출력한다던지 혹은 모든 정보를 출력할 수도 있다.
스키마 설계 과제, 인스타 게시물 스키마 설계
이번 코드스테이츠에서 스키마 설계 과제로 인스타 게시물에 대한 스키마를 설계하는 것을 했다. 요구사항은 아래와 같다.
- 게시물에는 사진을 여러장 첨부 할 수 있다.
- 게시물에는 좋아요, 댓글 기능이 있다.
- 좋아요는 좋아요 갯수, 좋아요를 누른 사람들이 누구인지 알 수 있다.
- 댓글은 댓글 코멘트와 댓글 작성자가 누구인지 나와 있다.
- 사용자는 다른 사용자를 팔로잉 할 수 있으며 팔로워가 누군지 조회 할 수 있다.
- 게시물의 여러개의 해시태그를 남길 수 있고 해시태그만으로 이 해시태그가 포함된 여러 게시물을 조회 할 수 있다.
위와 같은 요구사항들을 고려해서 테이블간의 관계도를 설계한 스키마를 이번에는 파워포인트로 작성했다. 근데 다른 분들 보니까 스키마 설계 웹사이트 툴을 이용해서 깔끔하게 잘 만드시는 것 같아 다음에 나도 한번 도전해보려한다.
위와 같은 스키마 구조를 만들어서 제출 했다. 어떤 것들이 1:N 관계에 있는지 N:N 관계에 있는지 확인해서 작성했는데 아직 모범 답안 레퍼런스를 받지 못해 잘 설계했는지는 모르겠다. 이렇게 설계하고 실제로 생성하는 것까지 실습을 해봐야겠다.
결론
SQL 과 NoSQL의 차이에 대한 이해와 RDBMS를 설계할 때 구조를 처음부터 잘 잡아야 나중에 문제가 없는 것을 알게 되었다. 아직 이것을 실제로 구축하고 구축한 데이터베이스를 통해서 웹 서비스를 제공해보지 않아 사실 아직 정확히 감이 오지 않는다. 시간이 가능하다면 먼저 mongoDB 같은 NoSQL 서비스를 활용해서 간단히 만들어보고 운영해보고 또 가상의 RDBMS를 활용해서 스키마도 설계하고 목업 데이터를 만들어 둘의 차이와 활용도를 이해하면 좋을 것 같다.
'개발일지' 카테고리의 다른 글
[KPT] Section3를 마치며 돌아보는 KPT 회고 feat.코드스테이츠 (1) | 2023.05.09 |
---|---|
[TIL] Spring Framework 기본 개념 정리 (0) | 2023.03.31 |
[TIL] Section2, Unit6 SQL 학습 일지 (0) | 2023.03.29 |
[TIL] 웹 애플리케이션 작동원리 (0) | 2023.03.28 |
미 국방부가 왜 TCP/IP가 극심한 전시 상황에서도 신뢰성을 유지할 수 있다고 판단한 이유 (0) | 2023.03.24 |