- 스키마 : DB에서 데이터가 구성되는 방식과 서로 다른 엔티티간의 관계에 대한 설명
- 데이터(data): 각 항목에 저장되는 값입니다.
- 테이블(table; 또는 relation) : 사전에 정의된 열의 데이터 타입대로 작성된 데이터가 행으로 축적됩니다.
- 칼럼(column; 또는 field) : 테이블의 한 열을 가리킵니다.
- 레코드(record; 또는 tuple) : 테이블의 한 행에 저장된 데이터입니다.
- 키(key) : 테이블의 각 레코드를 구분할 수 있는 값입니다. 각 레코드마다 고유한 값을 가집니다. 기본키(primary key)와 외래키(foreign key) 등이 있습니다.
관계 종류
- 1:1 관계
- 1:N 관계
- N:N 관계
1:1 관계 : 하나의 레코드가 다른 테이블의 레코드 한개와 연결된 경우
user 테이블은 user_id, name, phone_id를 가지고 있다.
phone_id는 외래키로써 Phonebook 테이블의 phone_id와 연결되어 있다.
각 전화번호가 단 한 명의 유저와 연결되어 있고, 그 반대도 동일하다면 1:1관계라고 할 수 있으나 잘 사용되지는 않는다.
1:N관계 : 하나의 레코드가 여러 개의 레코드와 연결 될 경우
-> 1:N 관계에서 어떤 접근 방법이 좋은가?
1) 교사가 담당하는 수업 목록에 대해 수업 이름을 나열하는 경우
문제점 : 수업 이름이 바뀌면 Teachers 테이블의 바뀐 수업 내용들로 행을 다 찾아서 수업 이름을 바꿔줘야 한다.
2) 다른 테이블에서 테이블의 기본 키(primary key - ClassID)를 입력시키는 경우
문제점 : 교사가 담당 수업을 얼마나 많을지 모른다. 그럼 자료구조의 크기를 정해줘야 하는데 수업이 많아지면 문제가 나타난다. 그리고 검색이 오래 걸리기에 복잡도가 올라간다.
이와 같은 문제로 하나의 열에 여러 값을 저장할 수는 없다.
그래서 소스는 한군대에 정의되어지는 것이 좋다.
TeacherID를 Classes 테이블에 저장하면 교사가 가르치는 모든 수업을 찾아낼 수 있기에 위 두 문제를 피할 수 있다.
N:N 관계 : 여러 개의 레코드가 다른 테이블의 여러개 레코드와 관계가 있는 경우
N:N의 관계는 잘 쓰이진 않는다.
하지만 다대다 관계가 있을 땐 Join 테이블을 사용하는 것이 좋은데
Classes, Students 테이블의 키를 Join 테이블의 외래키로 두면서 일대다 관계로 나타낼 수 있다.
Classes/Students 테이블에서는 수업 하나가 여러 명의 학생을 가질 수 있고, 학생 한명이 여러개의 수업을 들을 수 있다.
Classes/Students 테이블은 ClassesID와 StudentsID를 묶어주는 역할을 한다.
이 테이블로 인해 어떤 학생이 몇개의 수업을 듣는지, 어떤 수업에 몇 명의 학생이 듣고 있는지 확인할 수 있다.
또한 주의해야 할 점은 조인 테이블이더라도 해당 id는 필요하다. (CS_ID)
