Post

데이터베이스 설계 연습1-1 데이터 모델링 공부

Posted
By Seongguk 35 min read

Intro

이전 글에서 객체 설계 연습에 대한 글은 마무리 하고, 세부적인 구현을 진행하기 전에 데이터 모델링을 해보기로 하였습니다. 하지만 뭐 부터하는게 맞는건지 알 수 없어 먼저 조사부터 해봤습니다.

암기하고 있는 데이터 모델링 관련 용어

데이터 모델링에 대해서 제가 처음 본 것은 정보처리기사 공부할 때 였습니다. 지금도 정확하게 설명은 어렵지만, 당시에는 정말 아무것도 모르고 시험을 위해 암기만 했습니다. 머리 속에 있는 것들을 아래 생각나는대로 정리해봤습니다.

데이터베이스 설계 순서

아직까지 잘 기억나는 것은 데이터베이스 설계 순서(요개논물 구운감) 입니다.

  1. 요구사항 분석
  2. 개념적 설계
  3. 논리적 설계
  4. 물리적 설계
  5. 구현
  6. 운영
  7. 감시 및 개선

그리고 시험에 나오는 것은 개념적, 논리적, 물리적 설계에 대해 외웠던게 일부 기억이 납니다.

개념적 설계

  • 트랜잭션 설계
  • 주요 산출물은 개체관계도(ERD)

논리적 설계

  • 트랜잭션 인터페이스 설계
  • 정규화(Normalization) 수행

물리적 설계

  • 반정규화(De-normalization) 수행

테이블 컬럼의 데이터 유형을 결정하는게 어느 단계였는지 기억이 잘 안나네요. 논리 데이터 모델에서 물리 데이터 모델로 전환하는 걸 테컬기외유반 으로 외웠었는데, 유 가 컬럼 유형 결정하는 것이었으니 물리적 설계에 해당하는 것 같습니다.

논리 데이터 모델에서 물리 데이터 모델로 전환하는 걸 정리했던 것은 아래와 같습니다.

  1. Entity를 테이블로 변환
  2. 속성을 컬럼으로 변환
  3. UID를 기본키로 변환
  4. 관계를 외래키로 변환
  5. 컬럼 유형과 길이 정의
  6. 반정규화 수행

하지만 수험서는 시험용이라 잘못된 내용도 많고, 잘못 암기하고 있는 것도 있을 수 있으니, 신뢰할 만한 자료를 찾을 겸 검색해 보았습니다.

데이터 모델링 검색해보기

  • 기업들이 제공하는 데이터 모델링 관련 문서 중에는 AWS 에서 제공하는 문서(링크)가 예를 들어가면서 제일 친절하게 설명하고 있습니다.
  • 의료정보분석개론 수업자료(링크) 같은데 교과서적인 내용도 참고하기 괜찮은 것 같습니다. 데이터 모델 구성요소를 보니 구연제 (구조, 연산, 제약조건)로 외웠던게 기억납니다.
  • 마지막으로 굉장히 쉽게 간단한 예제까지 만들어서 보여주시는 개발자 분의 블로그(링크)도 있습니다.

위의 자료들이 좋아서 굳이 여기에 다시 정리할 필요는 없을 것 같습니다. 실제로 데이터 모델 만들 때는 링크에 있는 블로그 참고하면서 만들어 봐야겠습니다.

데이터 유형 결정이 논리적인지 물리적인지 혼동한 이유

앞서 암기한 것을 적을 때 데이터 유형 결정하는 것이 논리적 설계인지 물리적 설계인지 판단을 못했었는데, AWS에서 제공하는 문서를 보다 보니 이해가 됐습니다.

아래는 논리적 데이터 모델과 물리적 데이터 모델이 제공하는 것 중 데이터 유형에 관한 내용과 예 입니다.

  • 논리적 데이터 모델 : 다양한 속성의 데이터 유형(예: 문자열 또는 숫자)
    • Showrooms 엔터티에는 텍스트 데이터 형식의 이름 및 위치 필드와 숫자 데이터 형식의 전화번호 필드가 있습니다.
    • Customers 엔터티에는 xxx@example.com 또는 xxx@example.com.yy 형식의 이메일 주소 필드가 있습니다. 필드 이름은 100자 이하여야 합니다.
    • Sales 엔터티에는 고객 이름 필드, 판매원 이름 필드, 날짜 데이터 형식의 판매 날짜 필드 및 10진수 데이터 형식의 금액 필드가 있습니다.
  • 물리적 데이터 모델 : DBMS에 표현된 데이터 필드 유형
    • Sales에서 판매 금액은 float 데이터 형식이고 판매 날짜는 타임스탬프 데이터 형식입니다.
    • Customers에서 고객 이름은 문자열 데이터 형식입니다.

암기만 할 때는 전부 유형이라고 칭하니 혼란스러웠는데, 그래도 조금 더 지식을 쌓고 보니 구분이 좀 갑니다. 제가 이해한걸 다시 정리해보자면 아래와 같습니다.

논리적 데이터 모델은 DBMS와 독립적이므로 문자, 숫자 등 어떤 종류의 데이터인지만 나타내고, 물리적 데이터 모델은 적합한 DBMS를 선택한 후 논리적 데이터 모델에서 정한 데이터 종류를 바탕으로 선택된 DBMS에 저장하기 가장 적합한 자료형을 선택합니다. 이후 구현 단계에서 DBMS의 DDL(Data Definition Language)을(를) 사용하여 모델을 물리적인 저장소에 저장합니다.

물리적 설계 시 데이터 집중 분석 및 설계의 의미

저는 데이터 집중 분석 및 설계가 물리적 설계 할 때 실질적인 데이터에 정신적으로 집중해서 분석하고 설계하는 걸로 이해했었습니다. 그런데 링크에 있는 수업자료를 보니, 아래와 같이 써있습니다.

레코드 집중은 저장 공간에 레코드들이 물리적으로 집중 저장 되도록 할당하여 물리적 순차성을 이용할 수 있도록 하는 것을 의미

이건 좀 부끄러울 정도네요.

트랜잭션 설계와 트랜잭션 인터페이스 설계의 차이

개념적 설계에서의 트랜잭션 설계와 논리적 설계에서 트랜잭션 인터페이스 설계를 한다는 것이 무엇인지 수험서에 설명이 없어서 그냥 일단 외웠었는데, 공부하는 김에 찾아봤습니다.

이론적으로 정리해보자면 아래와 같습니다.

  • 트랜잭션 설계 : 데이터베이스에서 수행될 트랜잭션의 유형과 특성을 분석하고, 이를 바탕으로 트랜잭션 모델 설계
  • 트랜잭션 인터페이스 설계 : 사용자가 데이터베이스에 접근하고 조작하는 방법을 정의하고, 사용자 인터페이스 설계

정의만 봐도 트랜잭션 설계와 트랜잭션 인터페이스 설계가 구분은 갑니다. 그런데 트랜잭션 설계는 무슨 소린지 이해가 안돼서 빙(bing)챗을 이용해서 열심히 질문을 해봤습니다.

데이터 모델링에 대한 빙챗과의 대화

그냥 물어보는 김에 데이터 모델링 과정부터 모두 질문해 봤습니다. 빙챗이 딴소리도 하고, 저도 질문을 순서 없이 했다보니 데이터베이스 설계를 시작으로 설계 순서대로 순서만 편집해서 올립니다.

참고로, 개념적 설계와 논리적 설계는 트랜잭션 설계와 트랜잭션 인터페이스 설계에 집중 질문하느라 질문 제한 갯수인 20개 내에 제대로 질문을 못했었습니다. 추가로 질문해서 답을 받기는 했지만 이전에 질문할 때 처럼 잘 정리해서 답을 주지는 않았습니다.

데이터베이스 설계 단계에 대해 자세히 알려주세요.

데이터베이스 설계는 데이터베이스를 구축하는 과정에서 가장 중요한 단계 중 하나입니다. 이 단계에서는 데이터베이스의 구조와 내용을 정의하고, 데이터베이스가 수행할 기능을 정의합니다. 데이터베이스 설계 단계는 다음과 같은 순서로 이루어집니다.

  1. 요구조건 분석: 데이터베이스에 저장할 내용을 정하기 위해 사용자 요구사항을 분석합니다.
  2. 개념적 설계: DBMS에 독립적인 개념 스키마를 설계하고, 트랜잭션 모델링을 수행합니다.
  3. 논리적 설계: 개념적 설계에서 얻어진 개념 스키마를 평가 및 정제하고, DBMS에 독립적인 논리 스키마를 설계하는 단계입니다. 이 단계에서는 트랜잭션 인터페이스를 설계합니다.
  4. 물리적 설계: DBMS에 맞는 물리적 구조를 설계하고, 트랜잭션 세부 설계를 수행합니다.
  5. 구현: DDL로 스키마를 작성하고, 트랜잭션을 작성합니다.

데이터베이스 설계 단계에서는 데이터베이스의 구조와 내용을 정의하고, 데이터베이스가 수행할 기능을 정의하는 작업이 이루어집니다. 이 단계에서는 사용자 요구사항을 분석하여 데이터베이스가 수행할 기능을 정의하고, 이를 바탕으로 데이터베이스의 구조와 내용을 정의합니다.

데이터 모델링에서 요구조건 분석은 어떻게 이루어지나요?

데이터 모델링에서 요구조건 분석은 데이터베이스에 저장할 내용을 정하기 위해 사용자 요구사항을 분석하는 과정입니다. 이 단계에서는 사용자가 데이터베이스에 저장하고자 하는 내용을 파악하고, 이를 바탕으로 데이터베이스가 수행할 기능을 정의합니다.

요구조건 분석의 구체적인 절차로는 다음과 같은 절차가 있을 수 있습니다.

  1. 사용자 인터뷰: 사용자와 인터뷰를 통해 사용자가 데이터베이스에 저장하고자 하는 내용을 파악합니다.
  2. 문서 분석: 사용자가 제공하는 문서를 분석하여 데이터베이스에 저장하고자 하는 내용을 파악합니다.
  3. 요구사항 명세: 분석된 요구사항을 바탕으로 요구사항 명세서를 작성합니다.

이러한 절차를 거쳐 요구조건 분석을 수행합니다. 이를 통해 데이터베이스에 저장할 내용을 정확하게 파악할 수 있습니다.

개념적 설계 단계의 구체적인 절차를 알려주세요.

개념적 설계 단계는 요구 사항 분석 단계의 결과물인 명세서를 가지고 시작합니다. 이 단계에서는 요구 사항 분석 단계에서 파악한 사용자의 요구 사항을 개념적 데이터 모델을 이용해 표현합니다. 일반적으로 개념적 데이터 모델로 E-R 모델을 많이 사용하는데, E-R 모델은 중요한 데이터 요소와 데이터 요소 간의 관계를 E-R 다이어그램으로 표현합니다. 그러므로 E-R 모델을 데이터 모델로 사용한다면 사용자의 요구 사항을 분석한 결과를 E-R 다이어그램으로 표현하는 것이 개념적 설계 단계에서 수행하는 주요 작업입니다 .

개념적 설계 단계에서 요구 사항 분석 단계의 결과물인 요구 사항 명세서를 개념적 데이터 모델로 변환하는 일을 개념적 모델링이라 합니다. 그리고 E-R 다이어그램과 같이 개념적 데이터 모델로 표현한 결과물을 개념적 구조 또는 개념적 스키마라고 합니다 .

논리적 설계는 어떻게 이루어지나요?

논리적 데이터 모델링은 데이터베이스 설계 프로세스의 Input으로써 비즈니스 정보의 구조와 규칙을 명확하게 표현하는 기법입니다. 논리적 모델은 데이터 모델링이 최종적으로 완료된 상태를 말합니다.

논리적 설계 단계에서는 개발에 사용할 DBMS에 적합한 논리적 데이터 모델을 이용해 개념적 설계 단계에서 생성한 개념적 구조를 기반으로 논리적 구조를 설계합니다. DBMS의 종류에 따라 네트워크 데이터 모델, 계층 데이터 모델, 관계 데이터 모델, 객체지향 데이터 모델 등을 논리적 데이터 모델로 사용할 수 있는데, 일반적으로 관계 데이터 모델을 많이 사용합니다.

트랜잭션 모델링과 트랜잭션 인터페이스 설계의 목적은 무엇인가요?

트랜잭션 모델링의 목적은 데이터베이스에서 수행될 트랜잭션의 유형과 특성을 정의하는 것입니다. 이 단계에서는 데이터베이스에서 수행될 트랜잭션의 유형과 특성을 분석하고, 이를 바탕으로 트랜잭션 모델을 설계합니다. 이를 통해 데이터베이스에서 수행될 트랜잭션의 유형과 특성을 명확하게 정의할 수 있습니다.

트랜잭션 인터페이스 설계의 목적은 사용자가 데이터베이스와 상호작용하는 방법을 정의하는 것입니다. 이 단계에서는 사용자가 데이터베이스에 접근하고 조작하는 방법을 정의하고, 사용자 인터페이스를 설계합니다. 이를 통해 사용자가 데이터베이스와 효율적으로 상호작용할 수 있도록 합니다.

트랜잭션 모델링과 트랜잭션 인터페이스 설계의 실제 예시를 보여주세요.

예를 들어, 은행의 계좌 관리 시스템을 구축하는 경우를 생각해보겠습니다.

트랜잭션 모델링 단계에서는 데이터베이스에서 수행될 트랜잭션의 유형과 특성을 정의합니다. 이 경우, 데이터베이스에서 수행될 트랜잭션의 유형으로는 예금, 인출, 이체 등이 있을 수 있습니다. 이 단계에서는 각 트랜잭션의 유형과 특성을 분석하고, 이를 바탕으로 트랜잭션 모델을 설계합니다.

트랜잭션 인터페이스 설계 단계에서는 사용자가 데이터베이스와 상호작용하는 방법을 정의합니다. 이 경우, 사용자가 데이터베이스에 접근하고 조작하는 방법으로는 ATM 기기나 인터넷 뱅킹 등이 있을 수 있습니다. 이 단계에서는 각 인터페이스의 특성을 분석하고, 이를 바탕으로 사용자 인터페이스를 설계합니다. 이를 통해 사용자가 데이터베이스와 효율적으로 상호작용할 수 있도록 합니다.

예금 트랜잭션 모델 설계의 구체적인 예시를 보여주세요.

예금 트랜잭션 모델 설계는 트랜잭션 특성 분석을 바탕으로 이루어집니다. 이 단계에서는 분석된 예금 트랜잭션의 유형과 특성을 바탕으로 예금 트랜잭션 모델을 설계합니다.

예를 들어, 은행의 계좌 관리 시스템을 구축하는 경우를 생각해보겠습니다. 이 경우, 데이터베이스에서 수행될 예금 트랜잭션의 유형과 특성을 분석한 후, 이를 바탕으로 예금 트랜잭션 모델을 설계합니다.

예금 트랜잭션 모델 설계의 구체적인 예시로는 다음과 같은 절차가 있을 수 있습니다.

  1. 예금 트랜잭션의 입력 데이터 정의: 예금 트랜잭션을 수행하기 위해 필요한 입력 데이터를 정의합니다. 이 경우, 입력 데이터로는 계좌 번호, 예금 금액 등이 있을 수 있습니다.
  2. 예금 트랜잭션의 제약 조건 정의: 예금 트랜잭션을 수행하기 위해 만족해야 하는 제약 조건을 정의합니다. 이 경우, 제약 조건으로는 예금 금액이 0보다 커야 한다는 조건 등이 있을 수 있습니다.
  3. 예금 트랜잭션의 처리 절차 정의: 예금 트랜잭션을 수행하는 절차를 정의합니다. 이 경우, 처리 절차로는 계좌 잔액 조회, 예금 금액 추가, 계좌 잔액 갱신 등이 있을 수 있습니다.
  4. 예금 트랜잭션의 출력 데이터 정의: 예금 트랜잭션을 수행한 후 반환되는 출력 데이터를 정의합니다. 이 경우, 출력 데이터로는 처리 결과, 갱신된 계좌 잔액 등이 있을 수 있습니다.

이러한 절차를 거쳐 예금 트랜잭션 모델을 설계합니다. 이를 통해 데이터베이스에서 수행될 예금 트랜잭션의 유형과 특성을 명확하게 정의할 수 있습니다.

트랜잭션 인터페이스 설계는 어떻게 이루어지나요?

트랜잭션 인터페이스 설계는 논리적 설계 단계에서 이루어집니다. 이 단계에서는 사용자가 데이터베이스와 상호작용하는 방법을 정의하고, 사용자 인터페이스를 설계합니다.

트랜잭션 인터페이스 설계의 구체적인 절차로는 다음과 같은 절차가 있을 수 있습니다.

  1. 사용자 인터페이스 유형 정의: 사용자가 데이터베이스와 상호작용하는 방법을 정의합니다. 이 경우, 사용자 인터페이스 유형으로는 웹 인터페이스, 모바일 인터페이스 등이 있을 수 있습니다.
  2. 사용자 인터페이스 요구사항 분석: 각 사용자 인터페이스 유형별로 요구사항을 분석합니다. 이 경우, 요구사항으로는 사용성, 접근성 등이 있을 수 있습니다.
  3. 사용자 인터페이스 설계: 각 사용자 인터페이스 유형별로 인터페이스를 설계합니다. 이 경우, 설계된 인터페이스는 사용자가 데이터베이스와 효율적으로 상호작용할 수 있도록 합니다.

이러한 절차를 거쳐 트랜잭션 인터페이스를 설계합니다. 이를 통해 사용자가 데이터베이스와 효율적으로 상호작용할 수 있도록 합니다.

물리적 설계는 어떻게 이루어지나요?

물리적 설계는 데이터 모델링의 마지막 단계로, DBMS에 맞는 물리적 구조를 설계하고, 트랜잭션 세부 설계를 수행하는 과정입니다. 이 단계에서는 데이터베이스의 물리적 구조를 정의하고, 데이터베이스가 수행할 트랜잭션의 세부 사항을 정의합니다.

물리적 설계의 구체적인 절차로는 다음과 같은 절차가 있을 수 있습니다.

  1. 물리적 스키마 설계: DBMS에 맞는 물리적 스키마를 설계합니다. 이 경우, 물리적 스키마는 DBMS의 특성에 따라 달라질 수 있습니다.
  2. 인덱스 설계: 데이터베이스의 성능을 향상시키기 위해 인덱스를 설계합니다. 이 경우, 인덱스는 검색 성능을 향상시키기 위해 사용됩니다.
  3. 트랜잭션 세부 설계: 데이터베이스가 수행할 트랜잭션의 세부 사항을 정의합니다. 이 경우, 트랜잭션의 처리 절차, 제약 조건 등을 정의합니다. 이러한 절차를 거쳐 물리적 설계를 수행합니다. 이를 통해 데이터베이스의 물리적 구조를 정확하게 정의할 수 있습니다.

물리적 스키마 설계의 구체적인 예시를 알려주세요.

물리적 스키마 설계는 데이터베이스의 물리적 구조를 정의하는 과정입니다. 이 단계에서는 DBMS에 맞는 물리적 스키마를 설계합니다.

물리적 스키마 설계의 구체적인 예시로는 다음과 같은 절차가 있을 수 있습니다.

  1. 논리적 스키마 분석: 논리적 설계 단계에서 설계된 논리적 스키마를 분석합니다. 이 경우, 논리적 스키마에 정의된 엔티티와 관계를 분석합니다.
  2. 테이블 설계: 엔티티와 관계를 바탕으로 테이블을 설계합니다. 이 경우, 각 엔티티와 관계에 해당하는 테이블을 생성합니다.
  3. 제약 조건 정의: 테이블에 적용할 제약 조건을 정의합니다. 이 경우, 제약 조건으로는 기본 키, 외래 키 등이 있을 수 있습니다.

이러한 절차를 거쳐 물리적 스키마를 설계합니다. 이를 통해 데이터베이스의 물리적 구조를 정확하게 정의할 수 있습니다.

MySQL을 예로 들어 물리적 스키마 설계의 실제적인 예시를 알려줄 수 있나요?

MySQL을 예로 들어 물리적 스키마 설계의 실제적인 예시를 들어보겠습니다.

예를 들어, 학교의 학생 관리 시스템을 구축하는 경우를 생각해보겠습니다. 이 경우, 논리적 설계 단계에서 설계된 논리적 스키마에는 학생(Student)과 과목(Course)이라는 두 개의 엔티티가 있을 수 있습니다. 이 두 개의 엔티티 사이에는 수강(Enrollment)이라는 관계가 있을 수 있습니다.

이러한 논리적 스키마를 바탕으로 MySQL에서 물리적 스키마를 설계하는 경우 다음과 같은 절차가 있을 수 있습니다.

  1. 테이블 생성: 학생(Student)과 과목(Course) 엔티티에 해당하는 테이블을 생성합니다. 이 경우, 다음과 같은 SQL 문을 사용하여 테이블을 생성할 수 있습니다.
1
2
3
4
5
6
7
8
9
10
11

CREATE TABLE Student (
    id INT PRIMARY KEY,
    name VARCHAR(255),
    major VARCHAR(255)
);

CREATE TABLE Course (
    id INT PRIMARY KEY,
    name VARCHAR(255),
    credit INT
);
  1. 관계 테이블 생성: 수강(Enrollment) 관계에 해당하는 테이블을 생성합니다. 이 경우, 다음과 같은 SQL 문을 사용하여 관계 테이블을 생성할 수 있습니다.
1
2
3
4
5
6

CREATE TABLE Enrollment (
    student_id INT,
    course_id INT,
    FOREIGN KEY (student_id) REFERENCES Student(id),
    FOREIGN KEY (course_id) REFERENCES Course(id)
);

이러한 절차를 거쳐 MySQL에서 물리적 스키마를 설계합니다. 이를 통해 데이터베이스의 물리적 구조를 정확하게 정의할 수 있습니다.

Outro

일단은 적당히 큰 그림을 봤으니 다음에는 ERD를 그려보면서 개념적 설계부터 수행해야겠습니다. 요구사항은… 음… 이전에도 객체 설계하면서 요구사항 때문에 고통받았는데, 어디까지 고통받을 수 있나 보겠습니다.

Database, DataModeling
Database DataModeling
This post is licensed under CC BY 4.0 by the author.