UMC Server 4주차 세미나 (10/12)

 

 

 

 

 

 

 

 

해피 서버의 유저는 드림 서버의 유저가 될 수 없었는데 -> 서버 통합이 이루어진다면?

DB를 통합하는데, 동일한 ID가 겹친다면?

 

 

수강신청을 위해 필요한 정보들을 적는 과정 -> DB 설계

 

정규화, 중복 제거, 최적화 (~ 이런거 지워주세요, 중복 제거해주세요 등등)

 

필요한 데이터만 이 테이블에 저장 및 조회, 삭제, 업데이트하자 -> 정규화 과정

 

정규화

- 학생의 핸드폰번호와 집주소는 개인 정보로 따로 빼자

- 학번: 유일 값 (학생별 중복이 없이 부여되는 값), 단일값, 기본키 : PK (primary key)

: 테이블 당 기본키는 하나씩 갖고 있는 것이 좋다. 

- 외래키 (학번을 통해 개인정보를 찾는다. 학생과 정보를 매칭함) : FK

+ 성적의 과목코드 == FK

 

- auto increasing : 데이터 먹일 때 마다 하나씩 늘어남 (학번 부여할 때)

: 학생 당 학번을 생성할 때, 1씩 증가하도록 부여하는 과정

+ 게임 업계에서 많이 발생하는 이슈

 

 

 

 

식별: PK 없는 경우 (FK로 식별하는 경우)

비식별: PK가 있는 경우 (기본키를 갖는 경우가 편리하다)

PK가 있으면, PK만 보고서 처리할 수 있다.

PK가 없으면, 여러 단계를 거쳐야 단일값을 가져올 수 있다. 

(학번이 100번인 학생의 모든 과목의 과목 코드를 갖고온다 등등)

== PK가 있는 것이 조금 더 편리할 수 있다.

 

 

정규화 완료! :) 교수님 개인정보도 따로 뺐다.

 

 

 

연결 시키기!

 

+ 구분 값 (학생/교수) -> 주석이라고 한다 

 

 

 

wow,, 헷갈린다...!

 

DB간의 관계는 

1:1 (일대일 대응)

1:N (하나 당 여러개)

N:M (댓글 같은 경우, 대댓글 등등)

-> N:M은 어렵다 -> 1:N 관계로 변형하는 것을 권장

 

위의 사진 다시 가져왔다! (대응관계 다시 이해해보면 좋을 것 같다!)

 

- 교수는 하나의 과목을 갖는데, 과목은 여러 교수를 가질 수 있어서 N:1?

- 성적은 N:N 테이블 ==> 연계 테이블 이라고도 한다.