백엔드 개발자를 위한 DB 기초 개념부터 JPA 까지 - 1

데이터베이스 개념은 매우 딥하지만, 백엔드 개발을 막 시작하여 프로젝트에 투입되어야 하는데 DB에 대한 지식이 별로 없을때 도움이 될 수 있도록 작성한 글이다.

 

데이터베이스(DB)란?

• "많은 기능을 해주는 고성능의" 엑셀 이다.

데이터베이스는 말 그대로 데이터를 저장하는 공간을 말한다. 여러분들이 쇼핑몰을 운영한다고 가정해보자. 쇼핑몰에 회원이 가입했고, 회원정보 (이름, 나이)를 저장해야하는데 어디다 저장할 것인가? 메모장에 적어놔도 되지만, 보통 이럴땐 데이터베이스에 정보를 저장한다.

 

DBMS (Database Management System)

• 데이터베이스를 관리해주는 소프트웨어

우리가 흔히 말하는 DB는 이 DBMS를 말하는 것이다. DBMS는 사용자와 DB간의 소통의 창구 역할을 하는 중간 다리 소프트웨어 인터페이스다. 사용자는 DBMS에 "회원1 정보 내놔" 라고 하면 DBMS는 이를 해석해서 알맞는 회원 정보를 DB에서 가져와서 사용자에게 보여준다.

오픈 소스 RDBMS의 종류는 Oracle, MySQL, MSSQL, MariaDB, PostgreSQL 등이 있다.

 

RDBMS vs. NoSQL

RDBMS : 엑셀 형식처럼 틀이 잡혀진 DB

NoSQL : 틀이 없고 마구잡이로 데이터를 넣을 수 있는 DB

 

DBMS는 결국 프로그램이다. 이 프로그램을 사용할 수 있는 방법은 두 가지가 있는데, GUI방식과 CLI방식이다. 당연히 우리는 GUI가 편하다. 마우스로 아이콘을 클릭하고 그러는것이 커맨드를 입력하는 것보다 직관적이니까.

거의 모든 DBMS는 GUI, CLI 사용자 인터페이스를 둘 다 지원한다.

MySQL은 MySQL Workbench가 GUI를 지원한다.

 

DBMS를 로컬에 다운로드 받으면 백그라운드 프로세스로 상시 가동된다.

MySQL을 다운로드 받으면 MySQL Server라는 프로세스가 상시로 띄워져 있는 걸 확인할 수 있다. 이는 DBMS 프로그램 (서버)로 얘가 항상 켜져 있어야 인터페이스 (Workbench)로 이 프로그램에 접근을 할 수 있는 것이다. 당연히 DBMS 프로그램이 켜져있어야 데이터를 넣고, 수정, 삭제, 조회를 할 수 있다.

 

로컬에 구동중인 PostgreSQL Server 프로세스

 

여담으로  AWS RDS는 이 디비만 켜져있는 아주 소형의 가상 컴퓨터를 빌려주는 것이다. 그 컴퓨터는 24시간동안 가동되면서 DBMS 프로그램만 운영한다.

 

그럼 데이터들은 도대체 어디에 저장되는 걸까?

• DBMS가 다운로드 받아진 컴퓨터 어딘가에 저장된다.

저장 형태는 DBMS마다 다를 수 있지만, 파일형태로 저장된다. 만약 MySQL을 내 로컬에 다운로드 받고 Workbench를 통해서 로컬 MySQL 서버에 접속해서 데이터를 저장한다.

당연히 로컬 컴퓨터를 포맷하면 해당 데이터도 사라진다. 

 

스키마 vs. 인스턴스 vs. 테이블

스키마 : 데이터를 넣기 위한 틀

인스턴스 : 실제 데이터

테이블 : 스키마들을 모아 놓은 것

이는 말로 설명하면 꽤 어려우므로, 사진으로 이해하는 것이 훨씬 직관적이다.

*NoSQL DB들은 스키마가 없다. 그래서 아무 데이터나 막 때려박을 수 있다.

 

데이터베이스 설계

• 요구사항에 맞도록 스키마를 만들고, 이를 기반으로 테이블을 만드는 것

앞선 예시에서 회원과 주문을 관리해야한다면, 이를 저장할 테이블들을 미리 만드는 것을 말한다. DB 설계 툴도 다양하게 존재하는데, 필자는 ERD Cloud라는 웹 서비스를 자주 활용한다. (공유 기능이 있어서 편리하고 무료다.)

https://www.erdcloud.com/

ERDCloud

 

SQL (Structured Query Language)

• DBMS가 알아들을 수 있는 언어

DBMS에게 내리는 명령어를 SQL이라고 한다. 일종의 프로그래밍 언어라고 생각하면 된다.

만약 자바로 코드를 짜다가 DB 연동이 필요하면 SQL로 명령어를 입력하면 된다. SQL은 자바는 모른다. 그래서 문자열로 쌩으로 작성해야한다. 그 문자열을 DB에 전달해서 원하는 작업을 이어간다. 

이렇게 하면 조금 불편한게, 개발자는 자바 언어 말고도 SQL도 숙지를 해야한다.

그래서 어플리케이션 언어들 (자바, 파이썬 등)은 SQL을 좀 더 편리하게 쓸 수 있게끔 하는 기술들이 존재한다.

(SQL Mapper, ORM)

 

PK, FK (Primary key, Foreign key)

• PK는 테이블의 인스턴스(=레코드, 로우)를 구분 짓는 ID다. (DB에는 중복되는 인스턴스가 존재하면 안된다.)
• FK는 다른 테이블의 PK값이다. (혹은 NULL)

PK는 반드시 존재해야하며, 유니크(식별 가능)해야 한다. 회원의 경우 회원 ID (123123)이 PK가 될 수 있다.

FK의 개념이 모호할 수 있는데, DBMS에서 여러 테이블에 있는 정보를 조합하여 보고 싶을 때 사용하는 SQL이 JOIN인데, 이를 사용하기 위해서는 참조해야할 테이블(값)을 명시하는 무언가가 필요한데 그게 FK값이다.

 

예시로 회원이 여러개의 주문을 할 수 있다고 가정하자. 이 회원이 자신이 주문한 주문목록을 조회하기 위해선 주문들을 모두 끌어와서 보여줘야한다. 근데 DB에는 회원 테이블 따로 주문 테이블 따로 저장한다. 어떻게 특정 회원이 주문한 주문만 가져올까?

주문 테이블에 이 주문이 어떤 회원의 것인지를 나타내는 회원의 PK값을 칼럼으로 넣는다. 이 칼럼은 주문 입장에서 FK가 된다.

 

연관관계 매핑

앞선 예시에서 회원은 여러개의 주문과 연결되었다. 이렇게 다른 테이블들을 PK와 FK를 적절히 활용해서 연관관계를 지정할 수 있다.

거의 모든 테이블은 다른 테이블과 연관관계가 지정되고, 아무 연관관계도 없는 테이블(이런 테이블을 아일랜드 테이블 이라고 한다.)은 실제 프로젝트에서는 거의 없다. 

연관관계는 1:1, 1:다, 다:다 형태로 존재하고 위 예시는 회원(1) : 주문(다) 형태로 매핑된 상태다.

 

트랜잭션

• DB 작업의 최소 단위 (혹은 완전하게 진행되어야 하는 일련의 과정들을 묶은 것)

특정 회원이 특정 상품을 주문하여 결제까지 이루어지는 과정을 생각해보자.

1. 상품을 고름
2. 주문이 생성 됨
3. 결제를 진행함
4. 결제가 완료 됨

이때 만약 회원의 잔고가 부족해서 결제를 못했을 때를 생각해보자. DB입장에서 결제가 진행 안 되었는데 생성된 주문을 주문 테이블에 저장해야할까? 현실적으로 그러면 안 된다. 

따라서 해당 경우 1~4를 하나의 최소 작업 단위(트랜잭션)으로 생각해야 한다.

트랜잭션이 완료되면 commit을, 그렇지 않으면 rollback을 할 수 있다.