프론트엔드 개발자로서 이해하면 좋은 데이터 베이스 지식

1. Database 정의

• 데이터베이스란 일반적으로 컴퓨터 시스템에 저장된 정보 또는 데이터의 집합을 의미합니다. 서로 연관성이 있는 자료(data)를 많이 모은 것(base)으로 많은 자료를 어떻게 잘 처리할 것인지가 데이터베이스의 주요 관심사입니다.

• 애플리케이션에서는 데이터가 메모리 상에서 존재합니다. 메모리에 존재하는 데이터는 보존이 되지 않기 때문에 애플리케이션이 종료하면 메모리에 있던 데이터들은 다시 읽어 들일 수 없습니다. 따라서, 데이터를 오랜 기간 저장 및 편집, 보존 하기 위해서 데이터 베이스를 사용하는 것입니다.

• 데이터베이스는 보통 데이터베이스 관리 시스템(DBMS)로 제어합니다. 데이터와 DBMS는 연관된 어플리케이션들과 함께 '데이터베이스 시스템'으로 일컬어지며, 더 짧게는 '데이터베이스'라고 통칭되기도 합니다 (Oracle).

• 일반적으로 database에는 크게 관계형 데이터베이스(RDBMS)와 "NoSQL"로 명칭되는 비관계형(Non-relational) database가 있습니다.

2. 관계형 데이터베이스

RDBMS, Relational DataBase Management System

이름 그대로, 관계형 데이터 모델 즉, 데이터 간 상호 연관성에 기초를 둔 데이터베이스 시스템을 말합니다. DB에 컬럼, 레코드, 테이블의 구조를 갖춰 데이터를 기록하는데, 이는 우리가 흔히 쓰는 스프레드시트 프로그램의 구조와 비슷합니다.

• ex) MySQL, Postgres, Oracle DB

관계형 데이터란 데이터를 서로 상호관련성을 가진 형태로 표현한 데이터를 말합니다.

• 모든 데이터들은 2차원 테이블(table)들로 표현할 수 있습니다. 이 테이블은 키(key)와 값(value)의 관계를 나타냅니다.
  

• 각각의 테이블은 컬럼(column)과 row(로우)로 구성되어 있습니다.
  

  • 컬럼은 유일한 이름을 가지고 있으며, 자신만의 타입을 가지고 있습니다. 이러한 열은 필드(field) 또는 속성(attribute)이라고도 불립니다.
  • 로우는 관계된 데이터의 묶음을 의미합니다. 한 테이블의 모든 행은 같은 수의 열을 가지고 있습니다. 이러한 행은 튜플(tuple) 또는 레코드(record)라고도 불립니다.
  • 각 로우는 저만의 고유키(Primary Key)가 있습니다. 주로 이 primary key를 통해서 해당 로우를 찾거나, 인용(reference)하게 됩니다. 한 테이블 안의 로우는 다른 테이블들의 로우로 연결이 가능한데, 이는 연결된 로우의 고유키를 위한 컬럼을 추가함(외래키)으로써 이루어집니다.

• 각각의 테이블들은 서로 상호연관성을 가지고 서로 연결될 수 있습니다.
  

  • one to one
    테이블 A의 로우와 테이블 B의 로우가 정확히 일대일 매칭이 되는 관계를 one to one 관계라고 합니다. 서로가 서로의 오로지 한 로우에만 연결되어야만 합니다.
    유저와 유저프로필의 관계
    
  • one to many
    테이블 A의 로우가 테이블 B의 여러 로우와 연결이 되는 관계를 one to many 관계라고 합니다.
    각 고객은 여러 제품을 구매할 수 있지만 구매된 제품의 주인은 오직 한 고객 뿐입니다
    로우 하나에 다른 테이블의 로우 여러개가 연결될 수 있습니다.
    주인과 애완동물의 관계
    
    
  • many to many
    테이블 A의 여러 로우가 테이블 B의 여러 로우와 연결이 되는 관계를 many to many 라고 합니다.
    책은 여러 작가에 의해 쓰일 수 있고 작가들은 여러 책을 쓸 수 있습니다.
    
    
    
    

어떻게 테이블과 테이블을 연결하는가?

• Foreign key(외부키)라는 개념을 사용하여 주로 연결합니다
• 앞서 본 one to one 예에서 user_profiles 테이블의 user_id 컬럼은 users 테이블에 걸려있는 외부 키라고 지정합니다.
• 즉 데이터베이스에게 user_id의 값은 users 테이블의 id 값이며 그러므로 users 테이블의 id 컬럼에 존재하는 값만 생성될 수 있습니다.
  • 만일 users 테이블에 없는 id 값이 user_id 에 지정되면 에러가 발생합니다.

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

• 왜 정보를 여러 테이블에 나누어서 저장하는가?
• 앞서 본 one to many의 예에 경우 그냥 하나의 테이블에 고객 정보와 구입한 제품 정보 모두를 저장 하면 안되는가?
• 하나의 테이블에 모든 정보를 다 넣으면 동일한 정보들이 불필요하게 중복되어 저장됩니다.
  • 더 많은 디스크를 사용하게 되고, 잘못된 데이터가 저장 될 가능성이 높아집니다.
• 예를 들어, 고객의 아이디는 동일한데 이름이 서로 다른 로우들이 있다면 어떻게 해야 할까요? 어떤 이름이 정확할까요?
• 여러 테이블에 나누어서 저장한후 필요한 테이블 끼리 연결 시키면 위의 두 문제가 사라집니다.
  • 중복된 데이터를 저장하지 않음으로 디스크를 더 효율적으로 쓰고,
  • 또한 서로 같은 데이터이지만 부분적으로만 내용이 다른 데이터가 생기는 문제가 없어집니다.
  • 이것을 normalization(정규화) 이라고 합니다.

3. 스타벅스 메뉴 ERD 모델링

웹사이트 구성방식에 집중에 집중하여 팀원분들과 함께 메뉴와 관련된 데이터베이스를 기반으로 개체-관계 다이어그램 모델링을 진행하였습니다. 스타벅스 코리아에 존재하는 음료부를 보면서 우선적으로 조원들과 분류하였던 건, 고유의 값을 가지는지, 혹은 중복의 값을 가지는지 구분하였습니다.

카테고리, 음료(제품), 영양정보, 알러지, 음료 이미지, 음료 설명, 신상 여부 중에서 고유의 값을 가지는 음료, 음료 이미지, 음료 설명을 우선적으로 나누고, 정보 분류에 있어서 중요도에 따라서 논의를 진행하였습니다. 가장 핵심적인 정보는 아무래도 제품이다 보니 제품과 매칭되는 걸 기본으로 생각하였습니다.

간략적으로 데이터를 나열하자면 위의 스프레드 시트처럼 모든 데이터는 나열될 수 있습니다. 가장 중요한 건 음료(제품)에 관련된 테이블을 중점으로 확장하여 1:1로 관계의 경우는 하나의 테이블로 진행하기로 하였습니다. 그리고 카테고리 1:M 관계에 대해서 연결하고 알러지에 대해서는 M:M 관계로 중간테이블로 진행하였습니다.

• 하나의 데이터베이스 테이블에 자료를 다 기록을 한다면 조회가 빠르지만, 새로운 자료 추가될 때 열이 추가되므로 시간, 비용 발생
• 별도의 데이터베이스 테이블에 자료를 기록을 한다면 별도로 관리가 유용하지만 추가적으로 고려해야 할 사항 발생

처음 진행할 때는 관계에 대하여 감이 잘 안잡혔지만 1:M 관계에 대해서 비유적으로 생각했을 때, row에서 구성되는 데이터의 모양을 상상하면 더 쉽게 와 닿았습니다. ERD에서 볼 땐 column만 생각하다 보니 혼동이 왔었던.. 그래서 데이터가 어떻게 구성되고 나누어 질 수 있는지 또한 정규화 관련 추가적인 학습을 한다면 데이터베이스 이해와 더불어 백엔드와 연결에서도 이런 부분을 이해하고 작업을 진행할 수 있을 거 같았습니다.

최적화를 통하여 필요한 데이터를 잘 찾을 수 있도록 구성하는 기본적인 시멘틱 웹을 작성을 하게 된다면 데이터 활용에 있어서도 보다 구체적인 측면으로 접근이 가능함을 다시 확인했습니다. 데이터베이스를 실제 수 많은 종류의 산업군, 서비스 유형 등에 따라 다른 방식으로 구축하기 때문에, 기획에 있어서 구체적이지 않다면 차후에 유지 보수가 어려워지는 걸 피부로 느꼈습니다.

개발자 도구에 네트워크 탭에서 확인할 수 있는 스타벅스 사이트의 JSON 형태의 데이터들을 보면서 많은 제품들을 효율적으로 관리하기 위한 가장 적절한 방법을 찾아내고 이를 구현하는데 있어서도 개발자의 고민을 엿볼 수 있었습니다. 또한, 과제를 이행하면서 실제 여러가지 필드(caffein_L,chabo_L,cholestrol_L 등)가 많이 있지만 이를 선별하여 구조화하는 방법을 모르면 그저 데이터를 받기만하지 않을까 싶더라구요. 따라서, 분류와 더불어 실제 자료가 확인이 가능한 것 중심으로 데이터 테이블을 구성하고 싶었습니다.

알러지

제품과 알러지 관계가 M:M 테이블의 관계를 가지며 이를 1:M으로 구현하기 위해 많은 논의를 거쳤습니다(알러지 유무로 나누어 생각을 해서 다시 알러지 유발 요소를 연결하는) 하지만, 가장 이상적인 방안은 역시 음료를 제외한 모든 메뉴로 이를 확대한다고 가정할 때, 관리에 용이성이 떨어지게 되므로 M:M의 방식으로 구성하는 것이 보다 최적화가 가능하게 되는 방법이었습니다.

영양소

간단하게 보면 1:1의 매칭으로 쉽게 넘길 수 있는 문제였습니다. 같은 테이블에 넣어서 구조화를 하게되면 한 번에 데이터를 받게 되고 관리 특면에서도 용이하게 되기에 우선은 전체로 묶어서 생각하였습니다. 하지만, 반대로 또 생각해보면 영양에 대한 중요점과 표기 방식이 시간이 지남에 따라 바뀔 수 있기에 수정이 용이하지 않다는 점도 마음에 걸렸고 분리하는 것도 방법이라는 생각을 들게 했습니다. 또한, 만약 음료나 1회 제공량에 대한 사이즈가 달라지게 될 경우 영양소 표기도 모두 달라지게 되므로 M:M 테이블 관계로 나누어 접근하는 방법도 가능해 보였습니다.

M : M

리뷰를 진행하면서 역시 M:M 테이블 관계에 대하여 심화하여 알 수 있었습니다. 다음의 경우 중간 테이블에서 양 방향으로 정보를 서로 연결하는 조합에 있어서, 중간 테이블을 통하여 관련된 정보를 관리하는 것은 무척이나 효율적인 방법이었습니다. 예를 들어 의류 상품과 사이즈, 그리고 제품 수량의 관계에 있어서 수량을 중간 테이블에 넣게 되면 두 가지 부가 데이터에 기인한 구체적인 데이터를 찾는 것이 가능하게 되는 점을 볼 때 구체성을 나누어 데이터를 관리하면 처리에 있어서도 이점이 있었습니다.

4. ACID(Atomicity, Consistency, Isolation, Durability)

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

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

5. 트랜잭션(Transaction)

• ACID를 제공함으로 따라서 트랜잭션(일련의 작업들을 한번에 하나의 unit으로 실행하는것) 기능을 제공합니다.
• 트랜잭션은 일련의 작업들이 마치 하나의 작업처럼 취급되어서 모두 다 성공하거나 아니면 모두 다 실패하는걸 이야기 합니다.

6. NoSQL 데이터베이스

• 비관계형 타입의 데이터를 저장할때 주로 사용되는 데이터베이스 시스템
• 관계형 데이터베이스와 다르게 비관계형 이기 때문에 데이터들을 저장하기 전에 정의 할 필요가 없다.
  • 관계형 데이터베이스는 데이터들을 저장하기 전에 어디에 어떻게 저장할것인지를 정의 해야한다.
  • 즉 테이블을 정의해야함 (테이블 이름, 테이블과 다른 테이블의 관계, 각 컬럼의 타입 등등)
• MongoDB, Redis, Cassandra 등이 가장 대표적인 NoSQL 데이터 베이스이다.

7. SQL(RDBMS) VS NoSQL

SQL

정형화된 데이터들 그리고 데이터의 완전성이 중요한 데이터들을 저장하는데 유리하다.

• 예) 전자상거래 정보. 은행 계좌 정보, 거래 정보 등등.

• 장점:
  • 관계형 데이터베이스는 데이터를 더 효율적으로 그리고 체계적으로 저장할 수 있고 관리 할 수 있다.
  • 미리 저장하는 데이터들의 구조(테이블 스키마)를 정의 함으로 데이터의 완전성이 보장할 수 있다.
  • 트랜잭션(transaction)

• 단점:
  • 테이블을 미리 정의해야 하므로 테이블 구조 변화 등에 덜 유연한다.
  • 확장성이 쉽지 않다.
    • 역시 테이블 구조가 미리 정의 되어 있다보니 단순히 서버를 늘리는것 만으로 확장하기가 쉽지 않고 서버의 성능 자체도 높여야 한다.
    • 서버를 늘려서 분산 저장 하는것도 쉽지 않다.
    • Scale up (서버의 성능을 높이는것)으로 확장성이 됨.

NoSQL

주로 비정형화 데이터 그리고 완전성이 상대적으로 덜 유리한 데이터를 저장하는데 유리하다.

• 예) 로그 데이타

• 장점:
  • 테이터 구조를 미리 정의하지 않아도 되므로 저장하는 데이터의 구조 변화에 유연하다.
  • 확장하기가 비교적 쉽다. 그냥 서버 수를 늘리면 됨(scale out)
  • 확장하기가 쉽고 테이터의 구조도 유연하다 보니 방대한 양의 데이터를 저장하는데 유리하다.

• 단점:
  • 데이터의 완전성이 덜 보장된다.
  • 트랜잭션이 안되거나 비교적 불안정하다.

정규화 관련 자료
정규화 관련 자료 2