서버 4주차 정리 - DB에 관하여 - (1)

[서버의 작동 원리]

• 클라이언트가 요청을 보내면 제일 먼저 서버 프로그램 요청
• 서버 프로그램  → BL(Backend language)에 요청
• BL(Backend language)에서 데이터를 조회하기 위해서 DB에 요청

---

각 서버별로 DB 하나를 갖는게 좋을까? 서버 전체가 DB 하나를 공유하는게 편할까? 

• 하나의 서버만 있다면 각종 트래픽이 있을거다.
• 하나의 서버별로 DB 하나를 가지는게 편할까? → 서버가 터지면 해당 DB도 문제, 해커가 공격 가능성
• DB 관점에서 서버 전체가 DB 하나를 공유하는게 편하다!

 

<구글의 예시>

ID, PW → 구글 드라이브, GMAIL, Youtube 접근 → Google DB 통합

(하지만 속도가 좀 느리다는게 단점)

 

• AWS에서 제공하는 DB(RDS, DynamoDB, AWS ElasticCache)
• RDS: 관계형 데이터베이스(mssql, oracle, mysql)
• → 서비스를 사용자가 관리하지 않고 아마존에서 제공하는 DB 사용

---

SQL 이란?

SQL (structed query languauge):

데이터베이스를 조작하기 위한 언어

 

SQL, NO SQL로 구분

• SQL : mysql, mariaDB(sql에서 파생된)
• 관계형 데이터로 변경이 많이 사용되면 → SQL

 

• 변경이 안되고 사용자에게 중요한 스키마 → NOSQL(SQL 사용하지 않는 데이터베이스 : MongoDB)
• : 정확한 데이터 알 수 없고, 읽기는 자주하거나 변경 하지 않는경우, 데이터베이스를 수평적으로 확장하는 경우에 NOSQL

---

RDBMS: 관계형 데이터베이스

 

관계형 데이터: 우리가 데이터가 자주 바뀌기 때문에 RDBMS를 사용한다.

 

만약 교수님 → 출석부(이름, 학번, 학과, 연락처), 성적부(이름, 학번, 학과, 연락처, 성적)

정보가 겹친다거나 불필요한 부분이 생김

(이름, 학번, 학과, 연락처가 겹침)

불필요한 정보를 삭제하는게 DB에서 중요함

 

관계형 DB: 테이블을 정의해서 상호관계를 나타냄

 

사용자의 관점에 따라 외부 스키마, 개념스키마, 내부스키마로 나뉜다.

 

Table: 행과 열만 있으면 DB, 하지만 관계형 DB에서는 특별한 제약 추가

[관계형 DB의 특별한 제약]

1. 모든 값은 유일한 값을 가진다
2. 하나의 테이블에서 중복되는 행이 존재하면 안된다
3. 관계형 db 행: 튜블,레코드
4. 컬럼: 속성(atrribute)

 

---

<DB 설계>

수강신청 하는 경우를 예시

 

학생 정보 테이블

칼럼: 이름,학번,학과,연락처

과목 정보 테이블

칼럼: 과목코드,과목명,시간,학점

 

학생의 정보 중복되지 않음(불필요한 정보가 줄여져있음)

칼럼들에는 데이터 형태(char, int, text, timestamp...)가 존재

학번(int), 학과(문자열), 연락처(문자열)

 

---

키의 종류와 개념

 

튜플: ROW와 같은 개념

• 많은 고객들의 튜플이 존재(중복되는 값이 있을 수 있음)
• 튜플에 중복되는 값이 존재(구분이 되는 속성을 키라고 불림)

 

<키 성질>

유일성: 하나의 키값으로 각각의 튜플을 식별할수 있는 속성

튜플이 여러개 존재할때 각자의 튜플을 구별해야 함

 

최소성: 키를 구성하는 속성들 중 꼭 필요한 최소한의 속성으로 키를 구별

(굳이 없어도 되는 속성은 넣지 말자)

 

• 주민번호, 이름, 나이 → 튜플 구별가능
• 하지만 주민번호로 각 튜플을 유일하게 식별 가능
• 주민번호 하나만으로 주민번호 최소성 가능