Post

데이터베이스 설계 - RDB 편

Posted
Preview Image
By bramilch 49 min read


2024/06/26: 초안 작성
2024/06/28: 상향식, 하향식 디자인, 디자인 절차 추가, 보완
2024/07/08: 정규화 절차, 방법과 유용한 팁들, DB 개발자, DB 사용자로서의 어려움 추가
2024/07/10: 하향식 RDB 설계 절차 추가, 보완
2024/07/11: 하향식 RDB 설계 절차, 예시 정리, 보완 2024/07/16: 정규화 보완, 상향식 RDB 설계 설명, 절차, 예시 추가

※ 내용에 오류가 있을 수 있습니다.
※ 내용을 계속 추가, 수정, 보완하고 있습니다.


목차


머리말


  • 이어드림 스쿨에서 미니 프로젝트로 진행한 DB 설계 프로젝트를 경험하면서, 관계형 데이터베이스 설계의 어려움을 다시금 실감함.

  • DB 설계 미니 프로젝트 회고는 별도 작성 예정

  • DB 설계는 신중한 계획, 많은 고려가 필요하고, 체계적인 절차와 프레임워크가 필요하다는 것을 절감

  • RDB 설계 시 어려웠던 부분 3가지

  1. 서비스의 구체적 데이터 중 DB에 넣을 것과 넣지 않을 것을 구분하는 것

  2. 서비스로서 확정된 것과 확장할 수 있는 것을 구분

  3. 운영, 성능 측면에서 무결성, 일관성, 정규화, 비정규화를 고려하여 스키마 설계

  • 여기선 RDB 설계 개념, 절차, 고려해야 할 요소들, 주의해야 할 점, 정규화을 잘할 수 있는 방법, 데이터베이스 관련 직무에 대해 다룸.


관계형 데이터베이스 설계 RDB Design


  • LLM이 대세이고, 비정형 데이터의 중요성은 높아졌지만, 여전히 RDB는 중요하고, 앞으로도 중요하다는 것은 누가 부인할까

  • 빅데이터 관점에서 현실상 RDB, Non-relational DB의 한계를 넘어서(?) 하둡을 적용하여 빅데이터를 다루는 회사는 대기업, 성장을 많이 한 회사이고, 그런 회사는 많지 않고 수요도 적음.

  • 빅데이터에서도 정형 데이터 처리가 중요하기 때문에 RDB 설계와 이해는 필수

  • DB 테이블 구조는 회사 기밀

  • 관계형 데이터베이스를 설계하려면 비즈니스 도메인에 대한 깊은 이해, 데이터 분석 기술, 데이터베이스 원칙에 대한 지식이 필요

  • 구조화된 데이터 저장 및 검색에 의존하는 애플리케이션을 개발하는 데 있어 매우 중요한 요소


관계형 데이터베이스 설계 RDB Design란?


  • 관계형 데이터베이스 설계는 테이블과 테이블 간의 관계를 사용하여 데이터베이스의 데이터를 정의하고 구성하는 프로세스

데이터를 효율적이고 효과적으로 저장하기 위한 논리적, 물리적 스키마를 만드는 작업

  • RDB 설계의 목표는 데이터베이스가 지원하는 비즈니스 프로세스의 데이터 요구사항을 정확하게 표현하여 데이터 무결성, 일관성 및 접근성을 보장하는 것


RDB 설계의 중요성


  • 잘 설계된 관계형 데이터베이스는 데이터베이스의 효율성과 확장성, 안정성을 보장

  • 데이터 무결성 및 일관성 보장

  • 데이터 검색 및 조작을 용이하게 함.

  • 복잡한 쿼리 및 트랜잭션 지원

  • 확장성 및 향후 성장 지원


RDB 설계 시 주요 개념


  • 테이블 Tables: RDB의 데이터는 테이블에 저장되며, 각 테이블은 엔티티 유형을 나타냄. 예를 들어, ‘고객’ 테이블에는 고객 정보가 저장되고 ‘주문’ 테이블에는 주문 세부 정보가 저장될 수 있음.

  • 열 Columns: 열은 엔티티의 속성을 정의. 예를 들면, “Customers” 테이블에는 “CustomerID”, “FirstName”, “LastName” 등의 열이 있을 수 있음.

  • 행 Rows: 행은 엔티티의 개별 인스턴스를 나타냄. “Customers” 테이블의 각 행은 단일 고객을 나타냄.

  • 기본 키 Primary Keys: 기본 키는 테이블의 각 레코드를 고유하게 식별함. 기본 키는 Null 값을 포함할 수 없으며 테이블의 모든 행에서 고유해야 함. 일반적으로 자동 증가 정수 또는 고유 식별자를 사용

  • 외래 키 Foreign Keys: 외래 키는 두 테이블을 서로 연결. 외래 키는 다른 테이블의 기본 키를 참조하여 테이블 간의 관계를 설정하므로 테이블 간의 상호 참조 역할을 함. 예를 들어, ‘Orders’ 테이블의 ‘OrderID’ 열은 ‘Customers’ 테이블의 ‘CustomerID’에 연결되는 외래 키 역할을 할 수 있음.

  • 관계 Relationships: 관계는 테이블이 서로 상호 작용하는 방식을 정의함. 일대일, 일대다, 다대다의 세 가지 주요 유형이 있음. 효과적인 데이터베이스 설계를 위해서는 이러한 관계를 이해하고 올바르게 구현하는 것이 중요

  • 정규화 Normalization: 관계형 데이터베이스의 열과 테이블을 정리하여 중복성과 종속성을 최소화하는 프로세스. 정규화는 큰 테이블을 작은 테이블로 나누고 그 사이의 관계를 정의함으로써 데이터 무결성을 유지하고 성능을 개선하는 데 도움이 됨.

  • 비정규화 Denormalization: 읽기 성능을 개선하기 위해 데이터베이스를 비정규화하기도 함. 비정규화에는 관련 테이블을 단일 테이블로 결합하여 데이터를 검색하는 데 필요한 조인 횟수를 줄이는 작업이 포함되지만, 저장 공간 증가와 잠재적인 데이터 중복이 발생할 수 있음.


RDB 설계 고려 요소


  • 사용성 Usability: 애플리케이션 요구사항에 부합하는지 확인. 개발자와 관리자가 데이터베이스를 쉽게 관리하고 이해할 수 있도록 설계.

  • 데이터 무결성 Data Integrity: 적절한 제약 조건, 정규화 기법을 통해 데이터 수명 주기 내내 무결성을 유지하는지 확인. 기본 키와 외래 키, 관계 등 데이터 정확성과 일관성 확인

  • 보안 Security: 민감한 정보를 보호하기 위한 액세스 제어, 사용자 권한, 암호화, 데이터의 안전한 전송 등 보안 고려

  • 성능 Performance: 쿼리 및 색인 전략 최적화. 쿼리 실행 계획 분석, 자주 쿼리하는 열을 색인화 indexing하고, 중복을 피하기 위해 데이터를 정규화하고, 데이터 유형과 크기를 신중하게 선택하여 성능을 최적화

  • 확장성 Scalability: 확장 가능한 데이터 구조 선택, 큰 테이블 분할, 일관성을 위한 설계, 데이터 양과 사용자 부하의 증가, 향후 요구 사항, 잠재적인 확장 고려

  • 유지 관리 가능성 Maintainability: 향후 변경 사항 고려, 설계 모듈화, 의미 있는 이름을 사용하고, 결정 사항을 문서화


RDB 설계 시 주의할 점


  • 과도한 정규화 Over-Normalization: 정규화는 중복성을 줄이지만, 지나친 정규화는 불필요하고 복잡한 쿼리, 성능 저하로 이어질 수 있음. 정규화와 비정규화의 균형 필요

  • 성능을 위한 비정규화 Denormalization for Performance: 경우에 따라 비정규화를 통해 읽기 성능을 향상시킬 수 있음. 하지만 데이터 이상 현상과 스토리지 비용 증가로 이어질 수 있으므로 주의

  • 복잡한 조인 Complex Joins: 성능을 저하시킬 수 있는 지나치게 복잡한 조인 작업 지양. 인덱스를 현명하게 사용하고 자주 액세스하는 데이터에 대해서는 비정규화

  • 비기능 요구 사항 무시 Ignoring Non-Functional Requirements: 보안, 가용성, 백업/복구 계획과 같은 비기능적 요구 사항 주의. 장기적인 관점에서 필요


정규화 절차, 방법과 유용한 팁들


  • 정규화는 데이터 중복, 삽입, 업데이트, 삭제 이상과 같은 바람직하지 않은 특성을 제거하기 위해 테이블을 분해하는 체계적인 접근 방식

  • 데이터를 정리하여 중복을 줄이고 데이터 무결성을 개선. 데이터베이스를 두 개 이상의 테이블로 나누고 테이블 간의 관계를 정의하는 작업을 포함

  • 정규화는 큰 테이블을 작은 테이블로 나누고 그 사이에 관계를 설정하여 데이터 무결성을 높이고 중복성을 줄이는 것

  • 정규화는 데이터베이스 설계를 개선하지만 신중한 고려와 계획이 필요

  • 효율성, 무결성, 변화하는 비즈니스 요구 사항에 대한 대응 사이에서 균형을 이루는 정규화된 데이터베이스를 얻는 것이 관건


정규화 절차


  • 테이블 식별: 전체 데이터베이스를 주제에 따라 테이블로 분류. 각 테이블은 하나의 주제 또는 개념을 나타내야 함.

  • 기본 키 식별: 각 테이블에 기본 키 결정. 기본 키는 테이블의 각 레코드를 고유하게 식별

  • 중복 제거: 중복 데이터를 찾아서 새 테이블로 옮김. 외래 키를 사용하여 원래 테이블과 새 테이블 사이에 관계를 만듦.

  • 정규화 규칙 적용: 원하는 수준의 정규화에 도달할 때까지 각 정규화 양식의 규칙을 체계적으로 적용


정규화 형식


  • 정규화는 일반적으로 정규화 단계를 따르며, 각 단계는 정규화의 형태에 해당.

  • 1NF First Normal Form: 동일한 테이블에서 중복 열을 제거하고, 관련 데이터의 각 그룹에 대해 별도의 테이블을 만들고, 각 행을 고유한 열 또는 열 집합(기본 키)으로 식별

  • 2NF Second Normal Form: 모든 비키 non-key 속성이 기본 키에 완전히 종속되도록 하기 위해 테이블을 별도의 테이블로 더 세분화

  • 3NF Third Normal Form: 기본 키에 종속되지 않는 열을 제거

  • BCNF Boyce-Codd Normal Form: 3NF의 일부 문제 중 특히 복합 키 composite keys와 관련된 문제를 해결

  • 4NF Fourth Normal Form: 다중 값 종속성을 처리

  • 5NF Fifth Normal Form: Project-Join Normal Form (PJ/NF)이라고도 함. 특정 유형의 프로젝션 projection 및 조인 작업에서 보존되지 않는 함수 종속성 문제를 해결


정규화 중 고려해야 할 요소


  • 데이터 종속성: 데이터 간의 종속성 고려. 모든 비키 non-key 속성은 기본 키에 종속되어야 함.

  • 성능: 정규화는 중복성을 줄이지만, 여러 조인이 필요하기 때문에 쿼리가 더 복잡해지고 성능이 느려질 수 있음. 정규화와 성능의 균형을 유지

  • 비즈니스 요구 사항: 3NF 이상의 정규화는 구체적인 비즈니스 요구 사항에 따라 이루어지는 것이 유리

  • 유지 관리 및 발전: 정규화하고, 비즈니스 요구 사항 변경에 따른 수용 가능성 고려


정규화를 잘 수행하기 위한 팁


  • 간단하게 시작: 1NF의 기본부터 시작하여 필요에 따라 점차적으로 더 높은 수준의 정규화 형태를 적용
  • 다이어그램 도구 사용: ERD 등 다이어그램 도구를 사용하여 데이터베이스 구조를 시각화, 정규화 프로세스 파악
  • 반복적 접근: 반복적으로 정규화, 각 단계가 끝난 후 데이터베이스를 테스트하여 비즈니스 요구 사항을 충족하는지 확인
  • 문서화: 각 정규화 단계에서 정규화 근거를 포함하는 것이 좋음. 데이터베이스 설계에 대한 문서화를 유지


상향식 DB 디자인(설계)와 하향식 DB 디자인(설계)


  • DB 설계 방법론은 상향식 접근 방식 top-down approach과 하향식 접근 방식 bottom-up approach의 두 가지 접근 방식이 있음. 각 접근 방식은 고유한 장점, 고려 사항, 이상적인 적용 시나리오가 있음.

  • DB 설계 시 자주 언급되는 데이터 모델링 3단계는 Top-Down (하향식) 접근방식임.

  • 역시나 상향식과 하향식을 비교하며 통합하는 것이 가장 바람직

  • 두 가지 접근 방식 모두 각자의 강점이 있으며, 단독으로 사용하기보다는 함께 사용하는 경우가 많음.

  • 하향식 접근 방식으로 시작하고, 프로젝트가 진행됨에 따라 물리적 구현을 심화, 성능 최적화, 기술 문제 해결 위해 상향식 접근 방식을 적용하는 것을 반복함으로써 지속적으로 개선

  • 실제로 하향식으로 전체 방향 설계 → 상향식으로 특정 기술 문제 해결 방식을 반복하여 문제를 해결하는 경우가 많음. 하향식, 상향식 DB 설계, 디자인 접근 방식을 통해 기능, 성능, 요구 사항을 모두 충족하는 균형 잡힌 디자인을 구현해가는 것이 중요


하향식 접근 방식 Top-Down Approach of DB Design


  • 하향식 접근 방식은 전체 시스템에 대한 거시적인 관점으로 시작한 다음, 점진적으로 구성 요소를 세분화함.

  • 개념적 모델링과 관련되며, 데이터베이스 설계의 초기 단계에서 특히 유용


주요 특징


  • 거시적 관점 High-Level Perspective: 시스템의 전반적인 목표와 요구 사항으로 시작하여 세부적인 사항을 살펴보기 전에 큰 그림에 집중

  • 개념적 모델링 Conceptual Modeling: 다이어그램과 모델을 사용하여 세부적으로 분석하기 전에 전체 시스템의 구조와 관계를 시각화함.

  • 반복적 개선 Iterative Refinement: 피드백 및 시스템 요구 사항에 대한 심층적인 인사이트를 바탕으로 모델을 개선하면서 반복을 통해 디자인을 발전시킴.

  • 이상적인 시나리오 Ideal Scenario: 전체 아키텍처와 구성 요소 간의 상호 작용이 중요한, 복잡한 시스템을 다룰 때 유용. 특히 프로젝트의 초기 단계에서 이해관계자들이 시스템의 방향과 목표를 조율하는 데 유용


하향식 설계 Top-Down DB Design 절차


  • 설계 절차를 통해 3가지 결과물을 도출하는 것이 바람직

Top-Down (하향식) 접근방식인 데이터 모델링 3단계

개념적 데이터 모델링(E-R 다이어그램(개념적 스키마 도출)) → 논리적 데이터 모델링(Relation 모델(논리적 스키마 도출)) → 몰리적 데이터 모델링(물리적인 SQL 코드(데이터베이스 스키마 도출))

  • 실제로 하향식 설계를 진행하다보니 설계, 구현에서 절차가 종료되는 것이 아니라 유지, 운영, 확장 관점까지 포함한 좀 더 구체적이고, 체계적인 절차 설명이 필요하다고 느낌.

  • 아래 절차는 여러 요소들의 선후 관계를 보고, 스스로 정리한 것.

1. 비즈니스 및 관리 데이터 요구 사항 분석 → 2. 개념적 설계(ERD, 엔티티와 속성 식별, 기본 키 정의, 엔티티 간 관계 설정) → 3. 논리적 설계(테이블, 열, 데이터 유형, 제약 조건들 구현, 정규화) → 4. 물리적 설계(물리 저장 공간 결정, 성능 최적화, 확장 계획, 보안 및 백업 계획, 설계 문서화) → 5. 구현 → 6. 테스트 및 유효성 검사(요구사항 충족 확인, 데이터, 관계 무결성 검증 등 유효성 검사, 샘플, 부하, 장애 등 각종 테스트) → 7. 유지 관리 및 최적화 (성능 모니터링, 최적화, 정기 백업, 요구사항에 따른 스키마 업데이트)


  1. 비즈니스 및 관리 데이터 요구 사항 분석


  1. 비즈니스 및 관리 데이터 요구 사항 분석: 설계를 시작하기 전에 비즈니스 요구사항과 관리해야 할 데이터를 이해하고, 엔티티와 그 속성, 엔티티 간의 관계를 파악. 애플리케이션의 데이터 요구 사항을 이해하고 문서화

  2. 개념적 설계 Conceptual Design: 엔티티-관계 다이어그램(ERD)을 만듦.

    2-1. 엔티티와 속성 식별: 데이터베이스의 주요 개체(엔티티)와 그 속성(속성)을 결정. 예를 들어 전자상거래 애플리케이션에서 엔티티에는 고객, 제품 및 주문이 포함될 수 있음.

    2-2. 기본 키 정의: 각 테이블의 기본 키를 선택하여 레코드를 고유하게 식별함. 기본 키는 테이블의 모든 행에서 변경할 수 없고 고유해야 함.

    2-3. 엔티티 간 관계 설정: 엔티티 간의 관계를 정의. 관계가 일대일인지, 일대다인지, 다대다인지 결정하고 그에 따라 외래 키를 설정.

  3. 논리적 설계 Logical Design: ERD를 논리적 스키마로 변환. 테이블, 열, 데이터 유형, 제약 조건(예: 기본 키, 외래 키)을 정의

    3-1. 제약 조건 구현: 데이터 무결성과 비즈니스 로직을 적용하려면 제약 조건(예: NOT NULL, UNIQUE, FOREIGN KEY)을 사용

    3-2. 정규화: 데이터베이스를 정규화하여 중복성을 제거하고 데이터 무결성을 보장 필요. 정규화 형식(1NF, 2NF, 3NF, BCNF 등)에 따라 데이터 정리, 중복 제거. 각 테이블에 하나의 엔티티에 대한 데이터, 관계가 올바르게 관리되는지 확인

  4. 물리적 설계 Physical Design: 데이터의 물리적 저장 공간을 결정. 성능을 위해 데이터베이스를 최적화(인덱싱 Indexing, 파티셔닝 Partitioning 등). 데이터 보안 및 백업 계획

    4-1. 성능 고려: 설계 단계 초기에 쿼리 성능을 고려. 전략적으로 열 Column을 색인화(인덱싱)하면 데이터 검색 속도를 크게 높일 수 있음.

    4-2. 확장성에 대한 계획: 확장성을 염두에 두고 데이터베이스를 설계. 적절한 데이터 유형 선택, 파티셔닝 전략, 필요한 경우 샤딩을 계획

    4-3. 설계 문서화: 테이블, 필드, 관계 및 설계 과정에서 이루어진 모든 가정을 포함한 데이터베이스 스키마를 문서화. 좋은 문서는 유지 관리와 향후 개발에 매우 중요

  5. 구현 Implementation: 데이터베이스 관리 시스템(DBMS)을 사용해 데이터베이스 스키마를 만듦. 초기 데이터로 데이터베이스를 채움.

  6. 테스트 및 유효성 검사 Testing and Validation: 샘플 데이터로 데이터베이스 테스트. 요구 사항 충족하는지 확인. 데이터와 관계의 무결성 검증, 예상되는 부하에서 정상 동작 확인.

  7. 유지 관리 및 최적화 Maintenance and Optimization: 데이터베이스 성능을 모니터링하고 필요한 최적화를 수행. 정기적으로 백업. 애플리케이션 요구 사항이 변화함에 따라 데이터베이스 스키마를 업데이트


하향식 RDB 설계 예시


호텔 예약 시스템 RDB를 설계 한다면


엔티티 및 관계

  • 엔티티 고객, 예약, 객실, 결제


관계

  • 고객은 여러 번 예약할 수 있음.

  • 하나의 예약은 하나의 객실에 대한 예약임.

  • 예약에는 여러 개의 결제가 있을 수 있음.


엔티티 관계 다이어그램(ERD)

  • 고객(고객ID, 이름, 이메일, 전화)

  • 객실(객실ID, 객실타입, 가격)

  • 예약(예약ID, 고객ID, 객실ID, 체크인 날짜, 체크아웃 날짜)

  • 결제 (결제ID, 예약ID, 금액, 결제일)


정규화

  • 모든 테이블이 3NF인지 확인

  • 각 테이블은 단일 엔티티를 나타내야 하며, 관계는 외래 키를 통해 관리


논리적 설계

  • 적절한 데이터 유형으로 테이블을 만들고 열을 정의

  • 기본 키와 외래 키를 정의


물리적 설계 및 구현

  • DBMS 사용하여 스키마 생성

  • 자주 쿼리하는 열(예: RoomID, CustomerID)에 대한 인덱스를 만들기


상향식 접근 방식 Bottom-Up Approach of DB Design


  • 상향식 접근 방식은 개별 테이블, 필드, 관계 등 시스템의 가장 작은 구성 요소를 취합하여 전체 시스템을 구성하는 방식

  • 데이터 모델링에서 하향식 데이터베이스 모델링처럼 ‘3단계’ 방법은 없지만, 세부적인 고려, 구현에 중점을 두는 것이 핵심


세부 설계 및 최적화


  • 엔티티-속성-값(EAV, Entity-Attribute-Value) 모델링: 많은 수의 속성으로 설명되지만 일부 속성만 값을 갖는 엔티티를 공간 효율적인 방식으로 인코딩하는 데이터 모델. 희소 데이터를 다루거나 각 엔티티의 정확한 속성 집합을 알 수 없거나 매우 가변적일 때 상향식 접근 방식에 특히 유용

  • 인덱싱 전략 Indexing Strategy: 최적의 인덱스 집합을 결정하는 것은 상향식 접근 방식에서 매우 중요한 부분

  • 파티셔닝 및 샤딩 Partitioning and Sharding: 대규모 데이터베이스는 종종 더 작고 관리하기 쉬운 조각으로 나누면 이점이 있음. 파티셔닝은 테이블을 더 작고 관리하기 쉬운 조각으로 나누고, 샤딩은 여러 서버에 데이터를 분산시킴. 두 가지 전략 모두 성능과 확장성에 중점을 둔 상향식 접근 방식의 일부


구현 및 테스트


  • 스키마 생성 및 마이그레이션: 데이터베이스 스키마를 생성하기 위해 실제 SQL 스크립트 또는 데이터베이스 관리 시스템(DBMS) 명령 생성. 테이블 생성, 관계 정의, 제약 조건 설정 등이 포함됩니다 또한 기존 데이터를 새로운 스키마 형식으로 변환하기 위해 마이그레이션 스크립트가 필요요

  • 성능 조정: 초기 구현 후에는 최적의 성능을 위해 데이터베이스를 튜닝하는 상향식 접근 방식이 강조됨. 쿼리 성능 분석, 인덱스 조정, 구성 최적화 등이 있음.

  • 백업 및 복구 계획: 백업 빈도, 백업 유형(전체, 차등 differential, 증분 incremental), 복구 절차 등 이러한 전략을 세부적으로 수립하는 것이 포함됨.


하향식 설계와 통합


  • 상향식 접근 방식은 하향식 접근 방식의 중요성을 부정하는 것이 아니라 오히려 이를 보완한다는 점이 중요

  • 전체적인 데이터베이스 설계 프로세스에는 개념 모델링(하향식)과 세부 설계 및 구현(상향식)의 반복인 경우가 많음.

  • 하향식 설계 모델은 프레임워크와 거시적인 구조를 제공, 상향식 접근 방식은 세부 사항, 성능 최적화, 구현을 구체화함.


주요 특징


  • 디테일 지향 Detail-Oriented: 가장 작은 구성 요소부터 시작하여 시스템 전체에 이르기까지 데이터 저장의 세부 사항에 중점을 둠.

  • 기술 구현 Technical Implementation: 설계 초기 단계부터 특정 기술, 데이터 유형, 인덱스 및 기타 기술 사양을 결정

  • 점진적 개발 Incremental Development: 설계는 점진적으로 진행하고, 다음 단계로 넘어가기 전에 각 구성 요소를 개발하고 테스트

  • 이상적인 시나리오 Ideal Scenario: 데이터와 데이터 구조에 대한 명확한 이해가 있고, 성능, 저장, 검색 메커니즘을 최적화하는 데 중점을 두는 경우에 유리. 데이터베이스가 상당한 양의 데이터를 처리할 것으로 예상되거나 특정 성능 특성이 중요한 경우에 특히 유용


상향식 설계 Bottom-Up DB Design 절차


  • 상향식 관계형 데이터베이스(RDB) 설계는 가장 낮은 수준의 데이터 조직에서 시작하여 보다 광범위한 시스템 아키텍처를 향해 상향식으로 작업하면서 데이터베이스 설계 및 구현의 세부적인 측면에 중점을 둠.

  • 복잡한 데이터 구조, 성능 최적화, 데이터베이스 스키마가 애플리케이션의 운영 요구 사항과 밀접하게 연관되어 있을 때 특히 유용함.


  1. 애플리케이션 요구 사항 분석: 애플리케이션이 처리할 데이터 유형, 데이터에 대해 수행할 작업, 기대 성능 등 애플리케이션의 기능적 요구 사항 분석
  1. 데이터 구조 파악: 애플리케이션 요구 사항에 따라 필요한 데이터 구조 파악. 엔티티, 엔티티의 속성, 엔티티 간의 관계를 결정
  1. 데이터 스토리지 최적화: 각 데이터 구조에 대해 데이터를 저장하는 가장 효율적인 방법을 결정. 데이터 유형 선택, 인덱싱 전략, 필요한 경우 파티셔닝 또는 샤딩을 계획
  1. 스키마 생성: SQL 스크립트를 개발하거나 데이터베이스 관리 시스템(DBMS) 도구를 사용해 데이터베이스 스키마 생성. 테이블 생성, 기본 키 및 외래 키 정의, 제약 조건 설정
  • 데이터 마이그레이션 구현: 기존 데이터베이스나 데이터 소스에서 마이그레이션하는 경우 데이터를 새 스키마 형식으로 변환하는 스크립트 개발
  1. 성능 최적화: 작업 성능 분석, 필요에 따라 스키마, 인덱스 및 구성을 조정하여 성능 목표 달성
  1. 테스트 및 검증: 실제 데이터와 워크로드로 데이터베이스를 테스트하여 애플리케이션의 요구 사항을 충족하는지 확인. 데이터베이스의 성능, 정확성 및 안정성을 검증
  1. 모니터링 및 조정: 배포 후에는 데이터베이스의 성능과 사용 패턴을 지속적으로 모니터링. 관찰된 성능과 변화하는 요구 사항에 따라 필요에 따라 스키마, 인덱스 또는 구성을 조정


상향식 설계 Bottom-Up DB Design 예시


전자상거래 제품 카탈로그


  • 제품 카탈로그를 관리하는 전자상거래 애플리케이션의 데이터베이스를 설계하고 있다고 가정

  • 갖고 있는 기능: 이름, 카테고리, 가격대별로 제품을 검색하고 자세한 제품 정보 표시

  • 세부적인 데이터 구조와 최적화부터 시스템 아키텍처로 나아가는 상향식 접근 방식

  • 핵심은 성능 테스트 및 검증을 기반으로 설계를 반복적으로 개선하여 데이터베이스가 애플리케이션의 요구 사항을 효율적이고 안정적으로 충족하는지 확인


데이터 구조

  • 제품: ID, 이름, 설명, 카테고리ID, 가격

  • 카테고리: ID, 이름

  • 데이터 저장소 최적화: 적절한 데이터 유형(ID의 경우 INT, 이름 및 설명의 경우 VARCHAR)을 사용합니다. 제품 이름으로 빠르게 검색하려면 제품 테이블에서 이름을 색인하세요. 쿼리 성능을 개선하려면 제품 테이블이 커지면 CategoryID를 기준으로 분할하는 것을 고려하세요.


스키마 생성 쿼리

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

CREATE TABLE Categories (
    ID INT PRIMARY KEY,
    Name VARCHAR(255)
);

CREATE TABLE Products (
    ID INT PRIMARY KEY,
    Name VARCHAR(255),
    Description TEXT,
    CategoryID INT,
    Price DECIMAL(10, 2),
    FOREIGN KEY (CategoryID) REFERENCES Categories(ID)
);


  • 데이터 마이그레이션 구현: CSV 파일에서 데이터를 가져오는 경우 CSV를 파싱하는 스크립트를 작성하여 데이터를 Products 및 Categories 테이블에 삽입합니다.

  • 성능 최적화: 검색 쿼리를 테스트하고 필요에 따라 인덱스를 조정합니다. 제품 테이블의 크기를 모니터링하고 예상 성능 임계값을 초과하는 경우 파티셔닝을 고려하세요.

  • 테스트 및 검증: 샘플 데이터로 데이터베이스를 채우고 테스트를 수행하여 검색 및 제품 표시가 예상대로 작동하는지 확인합니다. 데이터베이스가 동시 액세스와 업데이트를 원활하게 처리하는지 확인합니다.

  • 모니터링 및 조정: 배포 후에는 데이터베이스의 성능을 모니터링하고 실제 사용 패턴과 성능 메트릭을 기반으로 스키마 또는 인덱스를 조정합니다.


데이터베이스 관련 직군과 직무


데이터 관련 직무 총정리(DA, DE, DS, DBA, DA) 참고

  • 데이터베이스 엔지니어

  • 데이터베이스 관리자 (DBA)

  • 데이터베이스 아키텍트 (DA)

  • 데이터베이스 튜너


DB 개발자, DB 사용자로서의 어려움


관계형 데이터베이스(RDB)


  • 스키마 변경: RDB에서 데이터베이스 스키마를 크게 변경하는 것은 특히 대규모 애플리케이션에서 번거로울 수 있음. 테이블, 열 또는 관계를 추가, 수정하려면 신중한 계획이 필요하며 때로는 다운타임이 발생하기도 함.

  • 데이터 무결성: 데이터 무결성을 보장하고 제약 조건(외래 키 제약 조건 등)을 적용하는 것은 특히 테이블 간의 복잡한 관계를 다룰 때 까다로울 수 있음.

  • 성능: 특히 대규모 데이터 세트나 복잡한 쿼리를 처리할 때 RDB에서 성능 문제가 발생할 수 있습니다. 성능을 개선하려면 쿼리를 인덱싱하고 최적화해야 할 수도 있음.

  • 확장: 특히 기존 RDBMS가 대량의 데이터나 동시 사용자를 처리하는 데 어려움을 겪을 수 있는 분산 환경에서는 RDB를 확장하는 것이 어려울 수 있음.


NoSQL 데이터베이스


  • 트랜잭션 부족 Lack of Transactions: 많은 NoSQL 데이터베이스는 성능과 확장성을 위해 ACID(원자성, 일관성, 격리성, 내구성) 속성을 희생합니다. 이로 인해 특정 시나리오에서 데이터 일관성을 유지하기가 어려울 수 있습니다.

  • 데이터 모델링 Data Modeling: NoSQL 데이터베이스는 데이터 모델링에 있어 RDB와 다른 접근 방식이 필요한 경우가 많습니다. 효율적인 데이터 액세스를 위해서는 비정규화와 쿼리 패턴 이해가 중요합니다.

  • 툴링 및 성숙도 Tooling and Maturity: 일부 NoSQL 데이터베이스는 기존 RDBMS에 비해 툴링이 덜 성숙되어 있습니다. 이로 인해 모니터링, 백업, 관리와 같은 작업이 더 어려워질 수 있습니다.

  • 학습 곡선 Learning Curve: 관계형 개념에 익숙한 개발자는 RDB에서 NoSQL 데이터베이스로 전환하는 과정에서 학습 곡선을 겪을 수 있습니다. 다양한 NoSQL 데이터베이스와 해당 데이터 모델의 뉘앙스를 이해하는 데 시간이 걸릴 수 있습니다.



[참고자료]

DB 설계하는 법 (feat. 데이터 모델링) https://yeongunheo.tistory.com/entry/DB-%EC%84%A4%EA%B3%84%ED%95%98%EB%8A%94-%EB%B2%95-feat-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EB%AA%A8%EB%8D%B8%EB%A7%81

토이프로젝트 해방일지 - 2. 데이터베이스 설계하기 https://velog.io/@backfox/%ED%86%A0%EC%9D%B4%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-%ED%95%B4%EB%B0%A9%EC%9D%BC%EC%A7%80-2.-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%84%A4%EA%B3%84%ED%95%98%EA%B8%B0

DBA 입장에서 바라보는 데이터베이스 직군 이야기 https://rastalion.dev/dba-%EC%9E%85%EC%9E%A5%EC%97%90%EC%84%9C-%EB%B0%94%EB%9D%BC%EB%B3%B4%EB%8A%94-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%A7%81%EA%B5%B0-%EC%9D%B4%EC%95%BC%EA%B8%B0/

Backend, Data Engineering
Backend Data Engineering
This post is licensed under CC-BY-NC-ND-4.0 by the author.