데이터베이스(DB, DataBase): 일정한 규칙, 혹은 규약을 통해 구조화되어 저장되는 데이터의 모음
해당 데이터베이스를 제어, 관리하는 통합 시스템을 DBMS(DataBase Management System)라고 하며, 데이터베이스 안에 있는 데이터들은 특정 DBMS마다 정의된 쿼리 언어(query language)를 통해 삽입(Insert), 삭제(Delete), 수정(Update), 조회(Select) 등을 수행할 수 있다.
또한 데이터베이스는 실시간 접근과 동시 공유가 가능하다.
데이터베이스와 DBMS
위의 사진 구조를 기반으로 데이터를 주고 받는다.
예) MySQL이라는 DBMS가 있고 그 위에 응용 프로그램에속하는 Node.js나 php에서 해당 데이터베이스 안에 있는 데이터를 끄집어내 해당 데이터 관련 로직을 구축할 수 있음
1-1. 엔터티(Entity)
사람, 장소, 물건, 시간, 개념 등 여러 개의 속성을 지닌 명사(Things)로 업무에서 관리해야 하는 데이터 집합
ex) 회원이라는 엔터티가 있다면 회원은 이름, 아이디, 주소, 전화번호의 속성을 갖는다.
하지만 주소라는 속성이 서비스의 요구 사항과 무관한 속성이라면 주소라는 속성은 사라지게 된다.
엔터티는 유일한 식별자(PK)가 있어야 한다.
2개 이상의 인스턴스 집합이어야 한다.
반드시 속성을 가지고 있다.
다른 엔터티와 최소한 한 개 이상 관계가 있어야 한다.
반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 한다.
업무 프로세스에 의해 이용되어야 한다.
엔터티, 속성, 인스턴스
속성(Attribute): 엔터티가 가지는 항목으로 더 이상 분리되지 않는 단위, 인스턴스의 구성요소(릴레이션에서 관리하는 구체적이며 고유한 이름을 갖는 정보) 인스턴스: 데이터베이스에 저장된 데이터 내용의 전체 집합
약한 엔터티와 강한 엔터티
A가 혼자서는 존재하지 못하고 B의 존재 여부에 따라 종속적이라면 A는 약한 엔터티, B는 강한 엔터티가 된다.
ex) 방은 건물 안에만 존재하기 때문에 방은 약한 엔터티, 건물은 강한 엔터티
1-2. 릴레이션(relation)
데이터베이스에서 정보를 구분해 저장하는 기본 단위로 엔터티에 관한 데이터를 데이터베이스는 릴레이션 하나에 담아서 관리한다.
릴레이션 = 테이블 = (스키마 + 인스턴스)
관계형 데이터베이스에서는 '테이블'이라고 하며 NoSQL 데이터베이스에서는 '컬렉션'이라고 한다.
테이블과 컬렉션
데이터베이스의 종류: 관계형 데이터베이스와 NoSQL 데이터베이스로 나눌 수 있다.
관계형 데이터베이스(MySQL)
NoSQL(MongoDB)
레코드 - 테이블 - 데이터베이스
도큐먼트 - 컬렉션 - 데이터베이스
1-3. 도메인(domain)
릴레이션에 포함된 각각의 속성들이 가질 수 있는 값의 집합
ex) 성별이라는 속성이 있다면 이 속성이 가질 수 있는 값은 [남, 여]이다.
1-4. 필드(field)와 레코드(record)
회원이란 엔터티는 라는 테이블로 속성인 이름, 아이디 등을 가지고 있고 name, ID, address 등의 필드를 가진다.
이 테이블에 쌓이는 행(row) 단위의 데이터를 레코드(튜플)라고 한다.
필드(Field)
레코드(Records) == 튜플(Tuple)
엔터티의 속성을 표현하는 가장 작은 단위의 데이터
논리적으로 연관된 필드의 집합이며 행 row(튜플이라고도 함)
여러 필드가 모여 한 레코드를 이룬다.
위의 표에서 각 열은 고객의 정보(ID, NAME, AGE, CLASS)를 나타내고, 첫 번째 행에서 'Lee'라는 값은 NAME의 속성을 표현
위의 표에서 고객의 ID, NAME, AGE, CLASS 데이터가 모여 하나의 레코드를 구성하며, 한 고객의 레코드는 4개의 필드(ID, NAME, AGE, CLASS)로 이루어졌다고 할 수 있다.
레코드가 쌓여서 테이블(서로 연관된 레코드의 집합)이 되고 테이블이 쌓여서 데이터베이스(관련된 테이블의 집합체)가 된다!
엔터티를 데이터베이스에 넣어 테이블로 만들기 위해서 속성에 맞는 타입 정의
책의 아이디: INT
책의 제목: VARCHAR(255)
책의 저자 아이디: INT
책의 출판년도: VARCHAR(255)
책의 장르: VARCHAR(255)
생성일시: DATETIME
업테이드 일시: DATETIME
각 속성에 맞는 타입을 정하고 이를 테이블로 만들기!
book 테이블
필드 타입
1) 숫자 타입
TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT 등
타입
용량(바이트)
최솟값(부호 있음)
최솟값(부호 없음)
최댓값(부호 없음)
최댓값(부호 있음)
TINYINT
1(8비트)
-128
0
127
255
SMALLINT
2(16비트)
-32768
0
32767
65535
MEDIUMINT
3(24비트)
-8388608
0
8388607
16777215
INT
4(32비트)
-2147483648
0
2147483647
4294967295
BIGINT
8(64비트)
-263
0
263-1
264-1
2) 날짜 타입
DATE, DATETIME, TIMESTAMP 등
DATE
DATETIME
TIMESTAMP
날짜 부분은 있지만 시간 부분은 없는 값에 사용
날짜 및 시간 부분을 모두 포함하는 값에 사용
지원되는 범위는 1000-01-01 ~ 9999-12-31
지원되는 범위는 1000-01-01 00:00:00에서 9999-12-31 23:59:59
지원되는 범위는 1970-01-01 00:00:11에서 2038-01-19 03:14:07
3바이트의 용량을 가진다.
8바이트의 용량을 가진다.
4바이트의 용량을 가진다.
TIMESTAMP보다 허용되는 값의 범위가 훨씬 큼
DATETIME보다 저장 공간을 절반만 사용하고, 서버측 시간대를 사용, 자동 업데이트
3) 문자 타입
CHAR, VARCHAR, TEXT, BLOB, ENUM, SET
CHAR
VARCHAR(가변 길이 문자열)
TEXT
BLOB
그 안에 수를 입력해서 몇 자까지 입력할지 정한다.
큰 데이터를 저장할 때 쓰는 타입
태이블을 생성할 때 선언한 길이로 고정되며 길이는 0에서 255 사이의 값을 가진다.
입력된 데이터에 따라 용량을 가변시켜 저장할 수 있다.
큰 문자열 저장에 사용한다.
이미지, 동영상 등 큰 데이터 저장에 사용한다.
레코드를 저장할 때 무조건 선언한 길이 값으로 '고정'해서 저장된다.
길이는 0에서 65,535 사이의 값으로 지정할 수 있다.
주로 게시판의 본문을 저장할 때 사용한다.
보통은 아마존의 이미지 호스팅 서비스인 S3을 이용한는 등 서버에 파일을 올리고 파일에 관한 경로를 VARCHAR로 저장한다.
지정된 형태에 따라 저장된 CHAR의 경우 검색에 유리
검색을 별로 하지 않고 유동적인 길이를 가진 데이터를 저장할 때 유리
ENUM
SET
문자열을 열거한 타입
ENUM('x-small', 'small', 'medium', 'large', 'x-large' 형태로 이중에서 하나만 선택하는 단일 선택만 가능 (ex: 라디오타입)
ENUM과 비슷하지만 여러 개의 데이터를 선택할 수 있고 비트 단위의 연산 가능, 문자열을 정수값으로 매핑(ex: 체크박스 타입)
ENUM 리스트에 없는 잘못된 값을 삽입하면 빈 문자열이 대신 삽입
ENUM이나 SET을 사용할 경우 공간적으로 이점을 볼 수 있지만 애플리케이션의 수정에 따라 데이터베이스의 ENUM이나 SET에서 정의한 목록을 수정해야 한다는 단점이 있다.
ENUM을 이용하면 x-small 등이 0, 1 등으로 매핑되어 메모리를 적게 사용하는 이점을 얻는다.
ENUM의 크나큰 단점 1) 문자열 목록 고정, 문자열을 추가하거나 지우려면 ALTER TABLE 사용 2) MySQL에선 ENUM 컬럼의 값을 정수로 저장, 값을 가져올 때는 이를 문자열 표현으로 변환해서 추가 비용 듬
CREATE TABLE enumTest(
color ENUM('red','green','blue') /*레코드 안 red, green, blue가 아닌 것이 들어올 수 xx*/
);
INSERT INTO enumTest (color) VALUES ('green');
INSERT INTO enumTest (color) VALUES ('blue');
/*INSERT INTO enumTest (color) VALUES ('gray'); 오류!! gray는 ENUM에 xx*/
/*INSERT INTO enumTest (color) VALUES ('red','blue); 오류!! 단일 선택만 가능!!*/
ENUM
CREATE TABLE setTest(
writing SET('bold','italic','underline') /*레코드 안 bold,italic,underline이 아닌 것이 들어올 수 xx*/
);
INSERT INTO setTest (writing) VALUES ('bold');
/*INSERT INTO setTest (writing) VALUES ('light'); 오류!! lighty는 setM에 없음! */
INSERT INTO setTest VALUES ('italic');
INSERT INTO setTest VALUES ('bold,italic,underline'); /*다중 선택 가능*/
SET
최적의 데이터 타입 고르기
MySQL은 다양한 타입을 지원하기 때문에 데이터를 저장하는 데 적합한 데이터 타입을 고르는 것이 좋은 성능을 얻는데 필수적!
대체로 작을수록 좋다.
단순한게 최고: 날짜&시간은 문자열 xx MySQL의 내장 형식에 저장해야 하고 IP주소는 정수를 이용해 저장!!
가능하면 NULL 사용 자제: NULL 허용 컬럼으로 인해서 인덱스, 인덱스 통계, 값 비교 등이 더 복잡해지고 NULL 허용 컬럼은 저장 공간도 많이 사용한다. 대신에!! NULL 대신 0이나 특수한 어떤 값, 빈 문자열 등을 사용하는 것을 고려하기!
컬럼에 어떤 데이터 타입을 쓸지 결정할 때는 숫자, 문자열, 시간 같은 큰 범위의 타입부터 결정한 뒤 구체적인 타입 정하기! (ex, DATETIME이나 TIMESTAMP의 차이같은 것
1-5. 관계
데이터베이스에는 여러 개의 테이블이 있고, 이러한 테이블은 서로의 관계가 정의되어 있다. 이러한 관계를 관계화살표로 나타낸다.
'~B로 구성되어 있다.' => '~B를 포함하고 있다.'
관계화살표
1:1 관계
1:1 관계는 테이블을 두 개의 테이블로 나눠 테이블의 구조를 더 이해하기 쉽게 만들어 줌
ex) 유저당 유저 이메일은 한 개씩 있기 때문에 1:1관계
1:1 관계
1:N 관계
한 개체가 다른 많은 개체를 포함하는 개체
ex) 쇼핑몰을 운영한다고 가정했을 때 한 유저당 여러 개의 상품을 장바구니에 넣을 수 있다. 이 때 1:N 관계가 되는데, 하나도 넣지 않는 0개의 경우도 있기 때문에 0도 포함되는 화살표를 통해 표현한다.
1:N 관계
N:M 관계
테이블 두 개를 직접적으로 연결해서 구축하지는 않고 1:N, 1:M이라는 관계를 갖는 테이블 두개로 나눠서 설정한다. (ex. 학생_강의)
ex) 학생도 강의를 많이 들을 수 있고, 강의도 여러명의 학생을 포함할 수 있다. 이경우 N:M 관계가 된다.
N:M관계
1-6. 키
테이블 간의 관계를 조금 더 명확히 하고 테이블 자체의 인덱스를 위해 설정된 장치
기본키(Primary Key), 외래키(Foreign Key), 후보키, 슈퍼키, 대체키
슈퍼키는 유일성이 있고 그 안에 포함된 후보키는 최소성까지 갖춘 키
후보키 중에서 기본키로 선택되지 못한 키는 대체키가 된다.
유일성
최소성
중복되는 값이 없다.
필드를 조합하지 않고 최소 필드만 써서 키를 형성할 수 있다.
하나의 키 값으로 하나의 튜플만을 유일하게 식별할 수 있는 성질
모든 튜플들을 유일하게 식별하는데 꼭 필요한 속성으로만 구성되는 성질
키(key)의 구조
슈퍼키(Super Key)
각 레코드를 유일하게 식별할 수 있는 유일성을 갖춘 키
한 릴레이션 내에 있는 속성들의 집합으로 구성된 키(key)
수퍼키는 2개 이상의 속성들을 묶어 새로운 속성을 만들어내는 유일성은 만족하지만 최소성을 만족하지 못한다.
수퍼키 예제1
속성 중 '이름'을 기본키로 사용했을 때 동명이인이 있을 수 있기 때문에 유일성 만족하지 않음
이름과 다른 속성들을 묶어서 수퍼키를 만들고(이름 + 주민번호), 이를 기본키(PK)로 사용 가능
그림과 같이 주민번호로 묶었을 때, 주민번호는 사람마다 다르게 부여되는 숫자이여서 1개로도 유일성을 만족해서 기본키로 사용할 수 있지만, 이름 속성과 같이 사용되었을 땐 최소성은 만족하지 못함
수퍼키 예제2
속성 중 '학과'를 기본키로 사용했을 때 같은 학과가 있을 수 있어서 유일성을 만족하지 않음
학과와 다른 속성들을 묶어서 수퍼키를 만들고(학과+학번), 이를 기본키(PK)로 사용 가능
학번은 유일성을 만족해서 기본키로 사용할 수 있지만, 학과 속성과 같이 사용된다면 최소성은 만족하지 못함
후보키(Candidate Key)
기본키가 될 수 있는 후보들이며 유일성과 최소성을 동시에 만족하는 키
수퍼키 중에서 최소성을 만족하는 것이 후보키가 된다.
예) 학번 속성과 이름, 학년 속성이 있다면 학번 속성은 단독으로 학생 튜플을 유일하게 구별할 수 있기에 후보키 가능! BUT! 이름, 학년은 후보키 될 수 없다. 이름 속성이 없어도 학번 속성만으로 유일성을 만족할 수 있기 때문
후보키
위 테이블에 사람은 3명이 있고, 이 3명을 구분하는 수퍼키들이 모여있는데, 수퍼키들 중에서 속성은 최소한의 갯수로 3명을 구분할 수 있어야 후보키가 될 수 있다.
학번과 주민번호 수퍼키는 속성들이 각 1개씩 이루어져 있다.
이름 + 나이 수퍼키는 2개의 속성으로 되어있다. 즉 이름 + 나이 수퍼키는 2개이기에 최소성을 만족하지 못해서 후보키가 될 수 없다.
대체키(Alternate Key)
후보키가 두 개 이상일 때, 그 중에서 어느 하나를 기본키로 지정하고 남은 후보키
보조키라고도 불린다.
대체키
유일성과 최소성을 만족하는 후보키가 '학번'과 '주민번호'
후보키가 2개 이상이기 때문에 둘 중 하나인 주민번호 속성을 기본키로 선정
후보키 중 나머지인 학번 속성이 대체키로 선정
반대로 학번을 기본키로 선정한다면, 후보키 중 나머지인 주민번호 속성이 대체키로 선정
기본키(Primary Key)
유일성과 최소성을 만족하는 키(=후보키)로 테이블의 데이터 중 고유하게 존재하는 속성
기본키에 해당하는 데이터는 ID처럼 중복되어서는 안된다. => 유일성
튜플을 식별하기 위해 반드시 필요한 키(한 릴레이션에서 특정 튜플을 유일하게 구별할 수 있다.)
복합 기본키는 피하는 게 좋고, 널 값을 가질 수 있는 속성이 포함된 후보키는 기본키로 부적합하다.
PK
{ID, NAME}이라는 복합키를 기본키로 설정할 수 있지만 그렇게 되면 최소성을 만족하지 않기 때문에 기본키는 자연키 또는 인조키 중에 골라 설정한다.
자연키
인조키
중복된 값을 제외하며 중복되지 않는 것을 '자연스레' 뽑다가 나오는 키
인위적으로 생성한 키, 자연키와는 대조적으로 변하지 않는다. 그래서 보통 기본키는 인조키로 설정한다.
예) 유저 테이블을 만든다고 가정하면 주민번호, 이름, 성별 등의 속성이 있다. 이 중 이름, 성별은 중복된 값이 있을 수 있기에 주민번호가 자연스럽게 기본키가 된다.
예) 회원 테이블을 만든다고 가정하면 주민번호, 이름, 성별 등의 속성이 있다. 여기에 인위적으로 유저 아이디를 부여한다. 이를 통해 고유 식별자가 생겨난다.
오라클은 sequence, MySQL은 auto increment 등으로 설정
외래키(Foreign Key)
다른 테이블의 기본키를 그대로 참조하는 값으로 개체와의 관계를 식별하는 데 사용한다.
데이터의 참조 무결성(Referential integrity)를 확인하기 위해 사용되는 키
한 릴레이션을 다른 릴레이션과 연결해주는 역할을 함. 즉 외래키는 하나의 릴레이션을 다른 릴레이션에 의존하게 만든다.
설정하는 방법: 1) 릴레이션을 생성할 때 설정 2) 이미 생성된 릴레이션에 ALTER 명령어를 이용해 설정
설정할 때 참조되는(기본키가 있는 릴레이션) 릴레이션의 필드는 반드시 UNIQUE나 PK 제약 조건이 설정되어 있어야 한다.!!!! 아니면 오류~
