BEB Section 2 - 관계형 데이터베이스

 

 사실 나의 학부 시절엔 데이터베이스를 그렇게 중요하게 여기진 않았다. 근데 필자는 좀 재밌게 들었던 경험이 있는데 직접적으로 컴퓨터를 통해 연결해서 여부를 확인한다거나 하는 일이 없었기 때문에 새로 시작한다는 마음으로 시작했다.

 

안 힘들어요. 안 힘들다고요.

 

 

 일단 먼저 관계형 데이터베이스가 필요한 이유에 대해 알아야할 것 같다.

 

• In-memory : 끄면 데이터가 사라진다.

 클라이언트-서버로 2티어 아키텍쳐로 되어있으면 서로 정보를 주고받는데 있어서는 문제가 없는데 이걸 종료해버리면 주고받던 데이터가 사라져 나중엔 볼 수 없다. 이럴 때 데이터베이스가 저장해주는 역할을 한다. .xlsx 파일이나 .csv 파일이 제일 큰 예시이다. 만약 2티어 아키텍쳐로 계속 유지보수를 하게 된다면 데이터를 보호할 수 없고, 원하는 시간에 데이터를 받아올 수 없으며, 데이터 수명이 프로그램의 수명에 의존하게 된다.

• File I/O : 파일 읽는 방식으로 작동

 원하는 데이터만 가지고 오는 게 불가능하기 때문에 모든 데이터를 가져와 서버에서 거칠 필요가 있다. 데이터가 필요할 때마다 전체 파일을 매번 읽어야하는데 파일의 크기가 커질수록 작업은 버겁고, 비효율적이라 이 방식은 큰 단점이 될 수 있다.

 

관계형 데이터베이스는 하나의 csv 파일이나 xlsx 파일을 한 개의 테이블로 저장 가능하고 데이터를 불러오기 수월하다.

 

SQL : Structured Query Language

 데이터베이스 언어로, 관계형 데이터베이스에서 사용된다. MySQL, Oracle, PostgreSQL, MariaDB 등 여러 곳에서 SQL 구문을 사용할 수 있다. 데이터베이스에 쿼리를 보내 원하는 데이터를 가져오거나 삽입할 수 있다. 여기서 말하는 쿼리는 검색어 라고 생각하면 쉬울 것 같다. SQL을 사용할 수 있는 데이터베이스와 달리, 데이터의 구조가 정해져 있지 않은 데이터베이스를 NoSQL이라고 한다. MongoDB가 그에 대한 대표적인 예시이다. 결국 SQL을 사용하기 위해 데이터의 구조가 고정되어있어야 한다.

 

#How_To_DB

 

 데이터베이스를 생성해서 살펴보고 테이블을 살펴보는 일은 매우 쉬웠다.

 

CREATE DATABASE DATABASE_NAME;

 

 사실 이건 아직도 작성할 때마다 세미콜론을 빼먹어서 큰일이긴한데, 무조건 붙여줘야 마무리된다는 것을 안다. 대문자로 적을 필요도 없고 소문자로 적어도 잘 돌아가긴 한다. 이렇게 데이터베이스를 생성하면

 

USE DATABASE_NAME;

 

 데이터베이스를 사용할 수 있고, 해당되는 데이터베이스의 테이블들을 볼 수 있는 권한을 가지게 된다.

 

CREATE TABLE table_name (
  id int PRIMARY KEY AUTO_INCREMENT,
  name varchar(255),
  email varchar(255)
);

 

 해당되는 데이터베이스에 테이블을 생성하고 싶다면 위 코드블럭처럼 작성하면 된다. 예시로는 지금 id, name, email 만 들어가있지만 더 추가하고 싶은 내용이 있다면 해달되는 필드와 유형을 넣어주면 된다. 테이블 정보를 확인하기 위해 DESCRIBE를 사용한다고 하지만,

 

DESC table_name;

 

 로도 테이블의 해당되는 정보를 알 수 있다.

 

 

SQL 명령어

• SELECT : 데이터셋에 포함될 특성을 특정한다.
• FROM : 테이블과 관련된 작업할 경우 반드시 입력해야한다. 특성은 여려 개를 적어서 내도 되는 거고, *(와일드 카드)를 써서 전체를 선택할 수 있다.

SELECT OBJ_1 FROM TABLE_NAME;
SELECT OBJ_1, OBJ_2 FROM TABLE_NAME;
SELECT * FROM TABLE_NAME;

• WHERE : 필터 역할 쿼리문. 선택적으로 사용 가능하다.

SELECT OBJ_1, OBJ_2 FROM TABLE_NAME WHERE OBJ_1 = "value1"; // 특정 값과 동일한 데이터 찾기
SELECT OBJ_1, OBJ_2 FROM TABLE_NAME WHERE OBJ_2 <> "value2"; // 특정 값 제외한 값 찾기
SELECT OBJ_1, OBJ_2 FROM TABLE_NAME WHERE OBJ_2 IN ("value1", "value2"); // 소괄호에 있는 값들과 일치하는 데이터를 필터할 때

• ORDER BY
• LIMIT
• DISTINCT
• INNER/OUTER JOIN

 

ACID

 ACID를 알기 전에 트랜잭션이 무엇인지 알아야한다.

 

 트랜잭션은 여러 개의 작업을 하나로 묶은 실행 유닛을 말한다. 각 트랜잭션은 하나의 특정 작업을 시작으로 해 모든 작업들을 다 완료해야 정상적인 종료를 한다. 하나의 작업이라도 실패하면, 모든 작업을 실패한 것으로 판단한다. 결국 미완료된 작업없이 모든 작업을 성공해야한다. 트랜잭션에는 ACID 특성을 가지고 있다.

 

• A, Atomicity : 원자성
  • 하나의 트랜잭션 내 모든 작업이 성공하거나 모두 실패해야 한다.
• C, Consistency : 일관성
  • 하나의 트랜잭션 전후에 데이터베이스의 일관된 상태가 유지되어야한다. 즉, 이전과 같이 데이터베이스의 상태는 유효해야한다. 이름이 없는 새로운 것을 추가하거나, 기존에 있던 정보를 삭제하는 쿼리는 C에 대해 위반한다.
• I, Isolation : 고립성
  • 모든 트랜잭션은 다른 트랜잭션으로부터 독립되어야하다. 실제로 동시에 여러 트랜잭션들이 수행될 때, 각 트랜잭션은 고립되어있어 연속으로 실행한 것과 동일한 결과를 나타낸다. 결국 동시에 실행되어도, 연속적으로 실행되어도 데이터베이스의 상태는 이전과 동일해야한다.
• D, Durability : 지속성
  • 트랜잭션이 성공적으로 수행되어 로그가 남아있어야하고, 아무리 런타임 오류나 시스템 에러가 발생해도 그 기록은 영구적으로 남아있어야 한다. 

 

SQL vs. NoSQL

 데이터베이스는 관계형과 비관계형으로 나눠진다. 앞서 설명한 SQL와 NoSQL을 의미한다.

 

• 관계형 데이터베이스는 행과 열로 구성된 테이블에 데이터를 저장한다. 특정한 형식을 지키기 때문에 데이터만 잘 입력했다면 사용하는 데는 매우 수월하다. 원하는 정보를 언제든지 쿼리할 수 있기 때문에 스키마가 뚜렷하게 보인다. 그래서 테이블 간의 관계를 직관적으로 파악할 수 있다.
• 비관계형 데이터베이스는 데이터가 고정되어있지 않지만, 스키마가 없진 않다. 비관계형 데이터베이스는 데이터를 읽어올 때 스키마에 따라 데이터를 읽어오고, 데이터를 입력하는 방식에 따라 읽는 방식도 영향을 미친다.
  • 속성을 Key-Value 의 배열 형태로 값을 저장한다. Key는 속성 이름을 뜻하고, Value는 연결된 데이터의 값을 의미한다.
  • 문서형 데이터베이스이기 때문에 JSON과 유사한 형식의 데이터를 문서화하여 저장한다.
  • 열에 대해 데이터를 집중적으로 관리한다. 열에는 Key-Value 형식으로 데이터가 저장된다. 큰 데이터 분석에 주로 사용되는 데이터베이스 형식이다.
  • 자료구조와 비슷한 형식으로 node와 entity, 그리고 edge으로 그래프 형식으로 데이터를 저장한다.

이에 대한 차이점은 물론 존재한다.

• 데이터 저장 방식
• 스키마의 필요성
• 쿼리의 중요성
• 확장성

 

어느 것으로 사용해야하냐고 묻는다면 비관계형 데이터베이스가 확장성과 속도에서 매우 뛰어난다. 하지만 관계형 데이터베이스가 더 좋은 성능을 보여주는 경우도 있으니 개발자가 편한 것을 쓰는 것이 제일 알맞다고 본다. 그래도 사용하는 케이스를 나눈다면 이렇게 나눌 수 있다.

 

• 관계형 데이터베이스
  • 데이터베이스의 ACID 성질을 준수해야하는 겨웅
  • 소프트웨어에 사용되는 데이터가 구조적이고 일관적일 경우
• 비관계형 데이터베이스
  • 데이터의 구조가 거의 없는 대용량의 데이터를 저장하는 경우
  • 클라우드 컴퓨팅 및 저장공간을 최대한 활용하는 경우
  • 데이트 구조를 자주 업데이트하는 경우

 

 

스키마

스키마는 데이터베이스에서 데이터가 구성되는 방식과 서로 다른 entity 간의 관계에 대한 설명을 말한다. 여기서 말하는 entity는 고유한 정보의 단위이다.

 

 

관계의 종류

• 1:1 관계

 하나의 레코드가 다른 테이블의 레코드 하나와 연결된 경우이다. User 테이블엔 user_id, name, phone_id를 가지고 있고, 이건 Phonebook 테이블에 있는 phone_id와 연결되어있기 때문에 1:1 관계로 볼 수 있다. 하지만 이 관계를 자주 사용하진 않는다.

 

• 1:N 관계

 하나의 레코드가 서로 다른 여러 개의 레코드와 연결된 경우이다. 위 그림과 같은 관계라고 나타냈을 때, 한 명의 유저가 여러 전화번호를 가질 수는 있지만 여러 명의 유저가 하나의 전화번호를 가질 순 없다. 관계형 데이터베이스에서 가장 많이 사용된다.

 

• N:N 관계

 여러 개의 레코드가 서로 다른 여러 개의 레코드와 연결된 경우이다. 이럴 때 관계형 데이터베이스에서 JOIN 을 사용한다. 위에서 표현한 1:N 관계와 비슷할 수도 있지만, 양방향을 통해 다수의 레코드를 가질 수 있다. Customer 테이블과 Package 테이블이 따로 존재해 이 관계를 표현해주기 위해선 매개체 역할을 해주는 테이블이 하나 필요하다. 이것을 우리는 조인 테이블이라고 한다.