면접을 위한 CS 전공 지식 노트-[4.1 데이터베이스의 기본]

DB는 일정한 규칙/규약을 통해 구조화되어 저장되는 데이터의 모음이다. 데이터를 관리하는 통합 시스템을 DBMS라고 한다. DB에 있는 데이터들은 특정 DBMS마다 정의된 쿼리 언어(query language)를 통해, 삽입, 삭제, 수정, 조회 등을 수행할 수 있다. DB는 실시간 동시 공유도 가능하다. 

위 구조를 기반으로 데이터를 주고 받는다. ex) MySQL이라는 DBMS가 있고, 그 위에 응용 프로그램에 속하는 Node.js나 php에서 해당 데이터 안에 있는 데이터를 끄집어내는 관련 로직을 구축할 수 있다.  

 

4.1.1   엔터티

Entity: 사람, 장소, 물건 등 여러 개의 속성을 지닌 명사를 의미한다. 

위 그림처럼 학생이라는 entity가 있으면 학생은 학번, 이름, 학점 등의 속성을 가지게 된다. 더 다양한 속성이 존재하겠지만 서비스의 요구 사항에 따라 맞춰진다.(보통 서비스 요구사항과 무관한 속성을 사라진다) 

 

약한 엔터티와 강한 언터디 

약한 엔터티: A가 B에게 종속돼 있으면, A는 약한 언터티이고 B는 강한 언터티이다. 

 

4.4.2   릴레이션 (relation)

DB에서 정보를 구분하여 저장하는 기본 단위이다. 

엔터티에 관한 데이터를 DB는 릴레이션 하나에 담아서 관리한다. relation은 관계형 DB에선 "Table" 이라 불린다. NoSQL DB에선 collection이라고 불린다.

 

ex) 회원이란 relation이 있다면, 이름, 아이디 등 엔터티들이 묶여서 DB에 담겨서 관리된다.

 

Table & Collection

DB의 종류는 크게 관계형 DB와 NoSQL로 나눌 수 있다.

대표적인 관계형 DB: MySQL => 구조: record-table-DB

대표적인 NoSQL: MongoDB  => 구조: document-collection-DB

 

위 그림처럼 record들이 쌓여서 테이블이 되고 그게 쌓여서 DB가 된다.  

 

 

4.1.3  속성 (attribute)

relation에서 관리하는 구체적이며 고유한 이름을 갖는 정보이다. 예를 들어 차라는 엔터티의 속성을 보면, 차 넘버, 바퀴 수 등이 있을 것이다. 서비스 요구 사항을 기반으로 관리 해야 하는 속성들만 엔터티의 속성을 본다.

 

4.1.4  도메인 (Domain)

relation에 포함된 각각의 속성들이 가질 수 있는 값의 집합을 말한다. ex) 성별이란 속성이 있다면 이 속성을 가질 수 있는 값은 (남,여)라는 집합이 된다. 

위 그림에서 볼 수 있는 것처럼 학생이라는 relation에 학번, 이름, 학년, 신장, 학과란 속성이 있고 학년은 (1,2,3,4) 라는 도메인을 가지는 것을 알 수 있다. 

 

4.1.5  필드와 레코드

앞에 설명된 것을 기반으로 DB에서 필드와 레코드로 구성된 테이블을 만들 수 있다. 

 

고객이란 엔터티는 속성으로 이름, 전번, 주소, 고객 등급 등의 필드를 가진다. row(행) 단위의 테이터를 record라고 하며, 이를 튜플이라고도 한다.

 

ex) 책이란 엔터티를 정의하고 이를 기반으로 테이블을 만들어보자! 

 

속성: 이름, 저자의 아이디, 출판년도, 장르, 생성 일시, 업데이트 일시만 있다고 가정할 때 

 

MySQL를 기준으로 타입을 정의해보면 (MongoDB의 경우는 다르다)

• 책의 아이디: INT
• 책의 제목: VARCHAR(255)
• 책의 저자 아이디: INT
• 책의 출판년도: VARCHAR(255)
• 책의 장르: VARCHAR(255) 
• 생성 일시: DATEIME
• 업데이트 일시: DATEIME

위에 정의한 속성의 타입에 따라 테이블을 만들면

Book

id INT

title VARCHAR(255)

author_id INT

publishing_year VARCHAR(255)

genre VARCHAR(255)

created_at  DATEIME

updated_at  DATEIME

보통 이런 형태를 띤다

보통 책의 제목, 책의 출판년도처러 한글을 속성 이름으로 쓰지는 않는다.  title, author_id 등으로 영어 이름에 매핑해서 쓰고 앞서 설명한 속성과 타입들이 들어가게 된다. 

 

위 테이블을 MySQL로 만드려면 아래와 같이 작성한다.

CREATE TABLE book{
 id INT NOT NULL AUTO _INCREMENT,
 title VARCHAR(255)
 author_id INT
 publishing_year VARCHAR(255)
 genre VARCHAR(255)
 created_at  DATEIME
 updated_at  DATEIME
}

 

필드 타입

필드는 타입을 갖는다. 예를 들어 이름은 문자열이고 전화번호는 숫자일 것이다. 이런 타입들은 DBMS마다 다르며, 여기에서는 MySQL를 기준으로 설명하겠다. 여러 가지 타입이 있고 대표적인 타입인 숫자, 날짜, 문자 타입에 대해 알아보면 

 

숫자 타입

숫자 타입으로는 TINYINT, SMALLINT, MEDIUMINT,INT DIGINT 등이 있다.

 

날짜 타입

날짜 타입으로는 DATE, DATETIEM, TIMESTAMP 등이 있다. 

 

DATE

날짜 부분은 있지만 시간 부분은 없는 값에 사용된다. 지원되는 범위는 1000-01-01~9999-12-31이다. 3바이트 용량을 가진다. 

 

DATETIME

날짜 및 시간 부분을 모두 포함하는 값에 사용된다.  지원되는 범위는 1000-01-01 00:00:00에서  9999-12-31 23:59:59이다. 8 바이트 용량을 가진다. 

 

TIMESTAMP

날짜 및 시간 부분을 모두 포함하는 값에 사용된다. 

 

문자 타입 

문자 타입으로는 CHAR, VARCHAR,TEXT, BLOB, ENUM, SET 이 있다. 

 

CHAR와 VARCHAR

CHAR 또는 VARCHAR 모두 그 안에 수를 입력해서 몇자까지 입력할지 정한다. 예를 들어 CHAR(30)이라며 최대 30글자까지 입력할 수 있다. 

 

CHAR는 테이블을 생성할 때 선언한 길이로 고정되며 길이는 0 ~255 사이의 값을 가진다. 레코드를 저장할 때 무조건 선언한 길이 값으로 고정해서 저장한다. 

 

VARCHAR는 가변 길이 문자열이다. 길이는 0~65,535 사이의 값으로 지정할 수 있으며, 입력된 데이터에 따라 용량을 가변시켜 저장한다. ex) 10글자의 이메일을 저장할 경우 10글자에 해당하는 바이트 + 길이기록용 1바이트로 저장하게 된다. 

 

TEXT와 BLOB

 두 타입 모두 큰 데이터를 저장할 때 쓰는 타입이다. 

TEXT는 큰 문자열 저장에쓰인다. (주로 게시판의 본문을 저장) 

BLOB은 이미지, 동영상 등 데이터 저장에 쓰인다. 그러나 보통은 아마존의 이미지 호스팅 서비스인 S3를 이용하는 등 서버에 파일을 올리고 파일에 관한 경로를 VARCHAR로 저장한다. 

 

ENUM과 SET

ENUM과 SET 모두 문자열을 열거하  타입이다. 

 

ENUM: (x-small, small, medium, large,) 형태로 쓰인다. 단일 선택만이 가능하고, 없는 값을 삽입하면 빈 문자열이 대신 삽입된다. ENUM을 이용하면 x-small 등이 0,1 등으로 매핑되어 메모리를 적게 사용하는 이점을 얻을 수 있다.  ENUM은 최대 65,535개의 요소들을 넣을 수 있다.

 

SET: ENUM과 비슷하지만 여러 개의 데이터 선택이 가능하다. 비트 단위의 연산을 할 수 있다. 최대 64개의 요소를 집어넣을 수 있다는 점이 다르다.

 

둘 다 공간적인 절약을 할 수 있다는 장점이 있지만, ENUM이나 SET에서 정의한 목록을 수정해야 한다는 단점이 있다. 

 

4.1.6  관계

DB에 테이블은 여러 개가 있으며, 상호 관계가 정의돼 있다. 관계화살표를 통해 나타낸다.                                                                                                                                                

         1:1 관계 

ex) user 당 user의 이메일은 한 개씩 존재하기 때문에 1:1 관계가 성립된다. 

 

1:1 관계는 테이블을 두 개의 테이블로 나눠 테이블의 구조를 더 이해하기 쉽게 만들어 준다. 

 

1:N 관계

예를 들어 쇼핑몰을 운영한다고 할 때 한 user 당 여러 장바구니에 넣을 수 있을 것이다. 이 경우 1:N 관계가 된다. 물론 0도 포함되어야 한다. 

 

N:M 관계

학생과 강의의 관계를 정의하면, 학생이 여러 강의를 선택할 수 있고, 강의도 여러 학생을 포함할 수 있으니 N:M관계를 형성하게 된다.

위 사진을 보면 중간에 학생-수업 테이블이 하나 껴져 있는 상태이다. N:M테이블은 직접 연결이 아닌, 1:N, 1:M이라는 관계를 갖는 테이블 두 개로 나눠서 설정한다. 

4.1.7  키 

테이블 간의 관계를 조금 더 명확하게 하고 테이블 자체의 인덱스를 위해 설정된 장치로 기본키, 외래키, 후보키, 슈퍼키, 대체키가 있다. 

 

키들은 위의 그림과 같은 관계를 가진다. 후보키 중에 기본키로 선택되지 못한 키는 대체키가 된다. 유일성은 중복되는 값은 없으며, 최소성은 필드를 조합하지 않고 최소 필드만 써서 키를 형성할 수 있는 것을 말한다. 

 

기본키 (Primary Key) - 유일성 + 최소성 만족

테이블의 데이터 중 고유하게 존재하는 속성이다. 기본키에 해당하는 데이터는 =  ID처럼 중복되어서는 안 된다. 만약 중복이 된다면 해당 필드는 기본키가 되면 안 된다. 

 

학번은 기본키로 설정할 수 있을 것이다. 물론 복합키를(학번 + 주민번호) 설정할 수 있겠지만, 그렇게 되면 최소성을 만족하지 못하게 된다. 

기본키 는 자연키 또는 인조키 중 골라 설정하게 된다. 

 

자연키 

유저 테이블을 만든다고 가정했을 때  주민번호, 이름, 성별 등의 속성이 있다. 이 중 이름,성별 등은 중복된 값이 들어올 수 있기 때문에 부적절 => 남는 것은 주민번호이다. 이 방법처럼 중복된 값을 제외하고 중복되지 않은 것을 뽑다보면 나오는 키를 자연키라고 한다. (자연키는 언젠가 변하는 속성을 가진다) 

 

인조키

위 예시와 동일한 상황을 가정했을 때 인위적으로  유저 아이디를 부여하는 것이다. (고유 식별자가 생긴다). 

- 오라클: sequence

- MySQL: auto increment

인위적으로 생성한 키를 인조키라고 부른다. 자연키와는 대조적으로 변하지 않는다. (보통 기본키는 인조키로 설정한다) 

 

외래키(Foreign Key) 

FK라고 하며, 다른 테이블의 기본키를 그대로 참조하는 값으로 개체와의 관계를 식별하는 데 사용한다. 

 

외래키는 중복돼도 무방하다. 위 그림을 보면 외래키가 어떻게 사용되는지 확인할 수 있다.

 

후보키(candidate key) 

기본키가 될 수 있는 후보들이며 유일성과 최소성을 동시에 만족한다. 

 

대체키(alternate key) 

후보키가 두 개 이상일 경우 어느 하나를 기본키로 지정하고 남은 후보키들을 말한다. 

 

슈퍼키 (super key) 

각 레코드를 유일하게 식별할 수 있는 유일성을 갖춘 키이다.