스키마가 무엇인가.
스키마(Schema)는 데이터베이스에서 데이터가 구성되는 방식과 서로 다른 엔티티 간의 관계에 대한 설명이다.
즉 " 데이터베이스의 청사진 " 과 같다.
수강신청기능을 구현할때 데이터베이스 구조를 생각해보면
| Teachers |
|---|
| Name |
| Department |
| Classes |
| Classes |
|---|
| Name |
| Room Number |
| Teacher |
| Students |
| Students |
|---|
| Name |
| Classes |
이런 구조들이 있고 각각 테이블들을
entities 라고 한다.
엔티티는 고유한 정보의 단위이고, 테이블로 표시할 수 있다.
여기서 Name ,Department Classes 등 하나의 열들이 필드 라고하고
한줄로 표현되는것
선생님에
Cynthia = music = music Theory, Brass Methods 이런게 하나의 레코즈 이다. Records
Teachers : Classes
선생님과 수업과의 관계
"선생님이 수업을 합니다"
"여러명의 교수님이 한개의 수업을 합니다" ? 이상하다.
"한명의 교수님이 여러 강의를 가르친다" OK
1:n 일대다 의 관계라고 얘기한다.
| ID | Name | Department | Classes |
|---|---|---|---|
| 1 | Morgan | PSY | PSY 101, PSY 201 |
| 2 | Sebastian | CS | CS 101, CS 102 |
| 3 | Kelly | CS | CS 151, CS 245 , CS 330 |
만약 한교수님들이 가르치는 강의목록을 이런식으로 배열 처럼 관리한다면 ? (가능함 Array기능있음 SQL에)
강의이름이 바뀐다던가 그런 문제에서
많이 골치아파진다 모든 테이블을 조사해서 싹다 바꿔줘야하니까.
비효율적이다.
보통은 Classes에 ID를 적는다. 고유한값 (Primary Key) 보통 자동증가
| ID | Name | Department | Classes |
|---|---|---|---|
| 1 | Morgan | PSY | 6,7 |
| 2 | Sebastian | CS | 1,2 |
| 3 | Kelly | CS | 3,4,5 |
Classes테이블의 ID를 참조할수있다.
1번째 이유
하지만 Maximum을 모른다.
클래스 ID들이 몇자나 들어갈지 모른다.
2번째 이유 검색이 오래걸린다.
그렇다면 이렇게쓰는건 어떨까
| ID | Name | Department | Classes |
|---|---|---|---|
| 1 | Morgan | PSY | 6 |
| 1 | Morgan | PSY | 7 |
| 2 | Sebastian | CS | 1 |
| 2 | Sebastian | CS | 2 |
| 3 | Kelly | CS | 3 |
| 3 | Kelly | CS | 4 |
| 3 | Kelly | CS | 5 |
이렇게 쓰는방법이 있겠다.
문제점은..
Kelly라는 교수님이 이름을 개명하셧다.
Kelly라는 이름을 다 Selly로 바꿔줘야하는데
만약 안바뀌거나 문제가 많아지면 ..?
Kelly가 누구야? Selly가 누구야?
이것이 정합성 이 깨진다고 얘기한다.
마지막 방법
| ID | Name | Room Num. | TeacherID |
|---|---|---|---|
| 1 | CS 101 | 114 | 2 |
| 2 | CS 102 | 114 | 2 |
| 3 | CS 151 | 222 | 3 |
| 4 | CS 245 | 118 | 3 |
| 5 | CS 330 | 220 | 3 |
| 6 | PSY 101 | 318 | 1 |
| 7 | PSY 201 | 318 | 1 |
이런식으로 Class가 TeacherID를 참조하면 쉽게 해결된다.
1:N 관계에서 N(다)인쪽에 Foreign Key가 들어가면 되겠구나! 생각하면 될꺼같다.
일대다 일때는 이방식이 베스트 프렉티스 , 이방식이 제일 합리적이다.
Class : Students
- 한개의 수업을 하나의 학생이듣는다. 음 ..?
- 여러개의 수업을 하나의 학생이 듣는다. 되는거같기도?
- 하나의 수업을 여러명의 학생이 듣는다. 맞는거같기도?
- 여러개의 수업을 여러명의 학생이 듣는다. OK
위에서 선생님 관계를 해봤을때
class의 하나의 레코즈가 student를 여러개 쓰는것도 비효율적
student의 하나의 레코즈가 class를 여러개 쓰는것도 비효율적
그럼 어쩌지?
1:n테이블 그리고 n:1 테이블 처럼해서
class와 student를 하나로 뭉쳐주는 테이블이 있다면 좋겠다
그게바로
JOIN 테이블 이라고한다.
조인테이블에는 classID / StudentID 라는속성을 가지고
예를들면
1번 클래스 / 2번 학생
1번 클래스 / 3번 학생
2번 클래스 / 1번 학생
2번 클래스 / 4번 학생
...
이런개 정해진 테이블이다.
가운데에 껴서 Foreign Key로 class,student 둘다 가지고있다.
마지막으로 자기참조 관계
유저테이블이 있고
추천인 ID가 테이블 내에 누군가를 참조하고있다.
이런식도 가능하다.
아마 대댓글 기능? 같은거 생각해보면
Parent 개념으로 생각해서 내가 참조하고있는 댓글 테이블에 또다른것이 있냐 없냐로
depth를 정의해서
댓글이냐
어떤 댓글에 대댓글이냐
어떤 댓글의 대댓글의 대대댓글이냐
를 어느정도 감이 잡힌다
parent, depth 등 생각해보자.! (null을 허용하고 null이면 그냥 댓글이겠다. 참조하는 parent 가없으니)
