TIL.45 Database

Database

일반적으로 컴퓨터 시스템에 저장된 정보 또는 데이터의 집합을 의미한다

데이터베이스는 데이터베이스 관리 시스템(DBMS)로 제어하며,

데이터와 DBMS를 통틀어 데이터베이스 시스템 또는 데이터베이스라 통칭하기도 한다.

 

---

데이터베이스를 사용하는 이유

우리가 흔히 사용하는 Applications 의 데이터는 메모리상에 존재하게 되는데, 메모리에 존재하는 데이터는 보존이 되지않는 특징이 있다.

따라서 데이터를 저장 및 보존하기 위해 데이터 베이스를 사용한다.

---

데이터베이스의 종류

관계형 데이터베이스

(RDBMS, Relational DataBase Management System) 와

NoSQL"로 명칭되는 비관계형(Non-relational) database 가 있다.

---

관계형 데이터베이스 (RDBMS, Relational DataBase Management System)

(MySQL, Oracle DB 등)

말 그대로 관계형 데이터 모델에 기초를 둔 데이터베이스 시스템으로 서로 상호관련성을 가진 형태로 표현한 데이터를 활용한다.

(관계형 데이터 : 데이터를 서로 상호관련성을 가진 형태로 표현한 데이터를 말함)

 

모든 데이터는 2차원 테이블(table)로 표현하며

각각의 테이블은 컬럼 (column)과 로우(row)로 구성된다.

각 로우는 저만의 고유 키 (Primary Key)를 통해 해당 로우를 찾거나 인용(refernce)하게 된다.

---

테이블 연결의 종류

 

one to one

테이블과 테이블 사이의 관계에 따라 원투원 이라 부른다.

(너 하나 면 나도 하나)

모든 테이블의 연결 관계를 생각하기 위해선 각 테이블의 서로가 서로에 대한 이해관계(?)를 생각해야한다.

유저 라는 테이블과  유저 프로필의 테이블로 생각해보자

먼저, 하나의 유저당 하나의 유저 프로필만 가질 수 있다.

하나의 사용자가 두개의 프로필을 가질 수 없기때문인데, 

유저와 유저프로필은 one to one관계를 가지게 된다.

여기서, 유저 프로필에 저장된 정보만 보고는 "그래서 이 정보가 누구의 정보인지?" 알 수 없기에

유저 테이블의 고유 키(PK) => 유저 테이블의 외래키 (FK) 로 사용함으로써 테이블의 관계를 지정해준다.

이렇게 관계?를 지정해주므로써 

유저 프로필 테이블의 정보가 "어떤 유저의 정보인지" 를 FK로 이어진 화살표방향(유저테이블)을 따라가다 보면

원하는 "어떤 유저인지" 정보를 확인할 수 있다.

유저 프로필 테이블은 유저 테이블의 외래키(FK)를 가지고 있다 라는 뜻은

== > 유저 프로필 테이블이 유저 테이블을 참조한다고 이야기 한다.

 

유저 프로필 테이블의 입장에서 User.id 는 외부키가 된다.(중요하지만 고유키보다는 덜 중요한)

외부키를 이용해 어떤 테이블에 종속되어있는지 알 수있다

 

여기서 화살표의 의미는 이 값을 알고싶으면 화살표 끝의 테이블로 가서 봐라 라고 이해하면 좋다

---

one to many

여기서도 관계를 이해하기 위해선 각 테이블간의 이해관계에 대해 생각해봐야한다.

고객의 정보를 저장하는 고객 테이블과

구매한 정보를 저장하는 오더 테이블이 있다.

각 고객은 여러 제품을 구매할 수 있지만, 구매된 제품의 주인은 오직 한 고객 뿐이다.

 

이때 고객 테이블과 오더 테이블은 one to many 관계를 갖는다.

오더 테이블에는 각 고객이 구매한 정보가 저장되어있는데

여기서도 오더 테이블만 보고서는 "어떤 고객이 구매한 건지" 알 수 없다.

따라서 고객 테이블의 PK를 오더 테이블의 FK로 사용하여 테이블과 테이블을 연결시켜 주어야 하며

오더 테이블은 고객 테이블의 외래키(FK)를 가지고 있다 라는 뜻은

오더 테이블이 고객 테이블을 참조한다 라고 할 수 있다.

 

---

many to many

여기서도 관계를 이해하기 위해선 각 테이블간의 이해관계에 대해 생각해봐야한다.

아래에서는 

작가 : 은진/ 허승/ 혁준 3명의 작가가 등장하며

허승 작가는 책 2번 3번 책을 출판하는 작가이고

혁준 작가는 책 2번을 허승 작가와 같이 출판하였다.

책 과 작가의 관계를 생각해보자, 책은 여러 작가에 의해서 쓰일 수 있으며 작가들은 여러 책을 쓸 수 있다.

작가 테이블과 책 테이블 두가지 테이블만 존재한다고 생각해보자

작가 테이블

id	name
1	은진
2	허승
3	혁준



책 테이블

id	title	price
1	너,들,이	25,000
2	나,들,코	30,000
3	m,b	25,000

 

너,들,이 는 누가 썻고,

나,들,코 는 누가 썻는지 책 테이블만을 보면 작가가 누구인지 알 수 없다.

그렇다면, 작가 테이블의 PK를 가져와 FK로 넣어보자

id	title	price	FK
1	너,들,이	25,000	1
2	나,들,코	30,000	2, 3
3	m,b	25,000	2

FK 자리에 2, 3 과 같이 값이 2개가 들어가는 경우가 생기는데

이는

정규화 규칙에서 벗어나며

각 열에서 값은 "오로지 하나" 만들어갈 수 있는 규칙에 어긋나기 때문에 성립되지 않는다.

따라서 작가와 책 테이블의 중간(피벗테이블)을 만들어 각 테이블의 PK를

중간 테이블의 FK로 각각 가져와

아래와 같이 정규화 규칙을 벗어나지 않도록 테이블을 구성해 줄 수 있으며

이는 후에 데이터 편집 및 유지 보수에 굉장히 효율적이다.

(이는 관계형 데이터베이스의 특징이기도 하다)

---

NoSQL 데이터베이스 비관계형 타입 데이터베이스 

NoSQL은 테이블로 관리하지 않고 

{

"~~~" : "~~~"

} 

와 같이 하나의 딕셔너리 처럼, 하나의 객체처럼 

비관계형 타입의 데이터를 저장할때 주로 사용되는 데이터베이스 시스템

관계형 데이터베이스와 다르게 비관계형 이기 때문에 데이터들을 저장하기 전에 정의 할 필요가 없다

관계형 데이터베이스는 데이터들을 저장하기 전에 어디에 어떻게 저장할것인지를 정의 해야한다.

즉 테이블을 정의해야함 (테이블 이름, 테이블과 다른 테이블의 관계, 각 컬럼의 타입 등등)

MongoDB, Redis, Cassandra 등이 가장 대표적인 NoSQL 데이터 베이스이다.

---

왜 테이블들을 연결해야 하는가?

앞서본 one to one 의 경우 사실 테이블을 나누지 않고 한 테이블에 모두 입력하면 더 적은 시간을 소모하여 데이터베이스에 접근 할 수 있다고 한다.

하지만 하나의 테이블에 모든 정보를 다 넣게 되면, 분명히 동일한 정보들이 불필요하게 반복 될것이고

이에 따라 더 많은 디스크를 사용하고 데이터의 신뢰성이 떨어질 가능성이 높아진다.

 

그래서 테이블을 나누어 저장한 후 필요한 테이블 끼리 연겨시키면 위의 문제를 해결 할 수 있다.

- 중복된 데이터를 저장하지 않아 디스크를 효율적으로 사용할 수 있고

- 서로 같은 데이터이지만 부분적으로만 내용이 다른 데이터가 생기는 문제가 사라진다.

이를 normalization(정규화) 라 부른다

 

---

ACID(Atomicity, Consistency, Isolation, Durability)

원자성, 일관성, 고립성, 지속성

• 원자성(Atomicity)은 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력입니다. 예를 들어, 자금 이체는 성공할 수도 실패할 수도 있지만 보내는 쪽에서 돈을 빼 오는 작업만 성공하고 받는 쪽에 돈을 넣는 작업을 실패해서는 안됩니다. 원자성은 이와 같이 중간 단계까지 실행되고 실패하는 일이 없도록 하는 것입니다.
• 일관성(Consistency)은 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것을 의미합니다. 무결성 제약이 모든 계좌는 잔고가 있어야 한다면 이를 위반하는 트랜잭션은 중단됩니다.
• 고립성(Isolation)은 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것을 의미합니다. 이것은 트랜잭션 밖에 있는 어떤 연산도 중간 단계의 데이터를 볼 수 없음을 의미합니다. 은행 관리자는 이체 작업을 하는 도중에 쿼리를 실행하더라도 특정 계좌간 이체하는 양 쪽을 볼 수 없습니다. 공식적으로 고립성은 트랜잭션 실행내역은 연속적이어야 함을 의미합니다. 성능관련 이유로 인해 이 특성은 가장 유연성 있는 제약 조건입니다. 자세한 내용은 관련 문서를 참조해야 합니다.
• 지속성(Durability)은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함을 의미합니다. 시스템 문제, DB 일관성 체크 등을 하더라도 유지되어야 함을 의미합니다. 전형적으로 모든 트랜잭션은 로그로 남고 시스템 장애 발생 전 상태로 되돌릴 수 있습니다. 트랜잭션은 로그에 모든 것이 저장된 후에만 commit 상태로 간주될 수 있습니다.

ACID 의 경우 이런게 있다는것만 읽고, 추후 데이터를 더 자세히 다룰 때 그때 이해하는게 더 도움이 된다고 한다.

 

트랜잭션(Transaction)

• ACID를 제공함으로 따라서 트랜잭션(일련의 작업들을 한번에 하나의 unit으로 실행하는것) 기능을 제공합니다.

  • 트랜잭션은 일련의 작업들이 마치 하나의 작업처럼 취급되어서 모두 다 성공하거나 아니면 모두 다 실패하는걸 이야기 한다.

  (만약 한 계좌에서 출금하여 송금을 하였는데, 출금한 내역만 존재하고 송금받은 내역이 존재하지 않으면 안된다. 

  따라서 트랜잭션 기능으로 이처럼 원활하지 못한 오류가 발생하였을때 테이블을 그 이전 상태로 전부 불러와 다시 사용할 수 있다)

---

 

SQL(RDBMS) VS NoSQL 정리

SQL의 장단점

장점

- 관계형 데이터베이스는 데이터를 더 효율적으로 더 체계적으로 저장 하고 관리 할 수 있다.

- 미리 저장하는 데이터들의 구조(테이블 스키마)를 정의함으로 데이터의 완전성이 보장 될 수 있다.

- 트랜잭션 기능을 사용할 수 있다. 

- 정형화된 데이터들 그리고 데이터의 완전성이 중요한 데이터들을 저장하는데 유리하다.(은행 계좌, 거래 정보 등등)

단점

- 테이블을 미리 정의해야 하므로 테이블 구조 변화에 덜 유연하다  (유동성이 작다)

- 확장성이 쉽지 않다.

(테이블 구조가 미리 정의되어 있다보니 단순히 서버를 늘리는 것만으로 확장이 어려우며 서버의 성능자체도 높여야한다)

(서버를 늘려서 분산저장하는 것도 쉽지 않다)

(Scale Up(서버의 성능을 높이는 것)으로 확장성을 증가시킬수는 있다.

 

NoSQL 장단점

장점

- 데이터 구조를 미리 정의하지 않아도 되므로 데이터의 구조 변화에 유연하다 (유동성이 크다)

- 확장하기가 비교적 수월하다 , just 서버 수를 늘리면 된다 (Scale out)

- 확장성도 좋고, 데이터의 구조도 유연하다 보니, 방대한 양의 데이터를 저장하는데 유리하다.

- 주로 비정형화 된 데이터 , 완전성이 상대적으로 덜 중요한 데이터를 저장하는데 유리하다.

(로그 데이타)

단점

- 데이터의 완전성이 덜 보장된다.

- 트랜잭션이 안되거나, 비교적 불안정하다.