[기획자의 SQL] RDMBS 관계형 데이터베이스를 알아보자

이전글 보기

[기획자의 SQL] 서버와 클라이언트 그리고 데이터베이스

 

 

SQL은 RDBMS에 있는 데이터를 원하는 목적에 맞게 정의하거나 조작하거나, 제어하는 언어라고 했다.

그리고 DBMS는 관계형 데이터베이스 시스템인데, 여기서 관계(Relation)는 매우 중요한 개념이지만, 기본 개념을 이해하고 차차 알아가도록 하자.

 

 

 

RDBMS 개요

갑을병정 주식회사에는 인사시스템이 있다.

1명의 사원은 사원번호, 사원 이름, 소속 부서, 연락처, 이메일, 연봉, 직급, 계약 구분 등등 다양한 정보를 포함하고 있다. 

 

만약 회사 직원의 정보를 하나의 표로 관리할 수 있을까? 할 수는 있겠지만, 너무 비효율적이다. 

 

지금은 인사/영업/개발/기획/디자인/재무라는 기능 조직 단위로 되어 있지만, PO 단위로 조직 개편을 한다면? 모든 인사 정보를 수정해야 하는 불편함이 생긴다. 또, A 직원은 1월 31일에 업데이트된 표를 보고 있고, B 직원은 10월 1일에 업데이트된 표를 보고 있다면, 1월 31일과 10월 1일 사이에 변동된 데이터에 대해서 A 직원은 모를 것이다. 

 

 

그래서 관계형 데이터베이스는 정규화(normalization)을 통해 이상(anomaly) 현상과 데이터의 중복을 제거하고, 동시성 관리 및 병렬 제어를 통해 많은 사용자들이 동시에 데이터를 공유하고 조작할 수 있도록 한다. 정규화는 하나의 표가 아닌 여러 개의 표(테이블)로 쪼개는 작업이 포함된다. 

 

 

 

라면은 면과 스프로 이루어져 있다.

모든 라면은 면과 스프로 이루어져 있듯이, 모든 RDBMS는 테이블의 집합이며, 각각의 테이블은 열(column, 속성)과 행(row, 레코드, 튜플)로 이루어져있다. 

https://hongong.hanbit.co.kr/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-databasedb-dbms-sql%EC%9D%98-%EA%B0%9C%EB%85%90/

column엔  데이터의 유형을 저장하고, row는 데이터 값을 포함한다. 이미 우리가 매우 많이 알고 있는 형태가 테이블이기에 SQL은 참 접근하기가 쉽다.

 

 

 

 

 

 

그래서 관계가 뭔데

이상 현상 방지를 위해 하나의 테이블을 2개 이상의 테이블로 쪼개게 되는 정규화를 수행하게 되더라도, 이 테이블을 하나로 볼 수 있도록 해야 하지 않겠나

https://cloud.google.com/learn/what-is-a-relational-database?hl=ko

그러면 공통된 정보를 통해 서로 연결을 시켜주는데 이걸 관계라고 한다. 그리고 관계형 데이터베이스는 여러 테이블이 서로 관계를 맺고 있다.

 

그러면 위 이미지처럼 CustomerID가 추가된다면, Customer Table과 Order Table에 각각 추가해줘야 하는가? 답은 아니오. 각각의 테이블은 그 데이터를 대표할 수 있는, 고유하게 식별할 수 있는 속성이 있는데 그걸 기본 키(Primary Key)라고 하고 다른 테이블에의 기본 키를 가져와서 참조하는 속성을 바로 외래 키(Foreign Key)라고 한다. 이 Key를 통해서 관계를 만드는데 사용한다. 위에 이미지 처럼, CustomerID는 Customer Table에서 기본 키에 해당하고 Order Table에선 외래 키에 해당해서 CustomerID가 추가된다면, Customer Table에만 추가하면 된다.  

 

 

 

ERD

RDBMS에는 여러 개의 테이블과 관계를 표시한 그림이 바로 ERD(Entity Relation Diagram)이다. ERD의 구성 요소는 엔터티(Entity), 관계(Relationship), 속성(Attribute) 3가지이기 때문에 ERD만 봐도 테이블은 뭐가 있는지, 기본 키/외래 키인지  테이블간은 어떤 관계인지 알 수 있다.

 

 

실제 프로젝트 또는 서비스를 구축할 때는 테이블이 무수히 많아서 ERD를 크게 인쇄해서 벽에 붙여놓고 하기도 했었다. 기획자도 ERD를 대략적으로 볼 수 있으면 좋은게 현재 시스템에서 어떤 데이터를 어느 테이블에 저장하고 있는지 알 수도 있고, 어떤 데이터를 참조해서 다른 테이블의 데이터를 가져올 수도 있는지 파악할 수 있다. 만약 원하는 정보가 없다면 그 컬럼을 추가해달라고도 요청할 수 있다. 

 

 

옛날엔 테이블 수정하면 ERD도 수정해야 하고 그래서 진짜 힘들었다는데 요즘은 ERD 그려주는 tool도 많고, DBMS인지 SQL 에디터에서 자체적으로 그려주기도 한다고 카더라(정확하지 않음). ERD 자체가 없는 소규모 프로젝트가 있기도 하고 ERD 자체가 시스템을 파악할 수 있는 귀중한 자료다 보니 공개되지 않아 볼 수 없을 수도 있다.

 

 

---

드디어 RDBMS에 관한 기본적인 설명인 끝이 났다.

 

회사 교육 자료 만들 때는 진짜 심플하게 했는데, 블로그는 상세하게 예시를 적을 수 있으니 뭔가 찾고 찾고 찾느라고 작성하는데 시간이 꽤 걸리는 것 같다.