지난 장에서는 개념 데이터 모델링의 이론적 개념에 대해서 알아보았다. 이번에는 개념 데이터 모델링 이후의 논리 데이터 모델링 과정에 대해서 알아보도록 하자.
들어가기에 앞서 이전 내용에서 “때로는 개념과 논리 데이터 모델링 과정을 합쳐서 논리 데이터 모델링 단계 하나만으로 정의하기도 한다”고 말했던 것을 기억하는가? 이 말의 뜻은 논리 데이터 모델링의 일부 과정이 개념 데이터 모델링 과정과 유사하거나 동일함을 의미하며, 각 모델링 단계를 명확하게 구분하진 않는다는 것을 의미한다. 이 부분을 다시 한번 상기하며 이번 장의 내용을 시작해보도록 하자.
[Part1. 논리 데이터 모델링]
개념 데이터 모델링을 통해 추상적으로 릴레이션 구조로 표현했다고 생각해보자. 과연 이 구조가 완벽한 데이터 모델이라고 할 수 있을까?
답은 ‘No’이다. 추상적으로 만들다보니 불필요한 속성이나 관계들도 존재할 것이고, 이러한 것들을 정리하는 과정이 필요해질 것이다. 이때, 쉽게 생각하면 이러한 정리 과정을 통해 데이터베이스에 저장할 최종 형상을 만드는 것이 논리 데이터 모델링이라고 이해하면 된다.
1-1. 논리 데이터 모델링이란?
- 개념 데이터 모델링 과정에서 정의한 엔터티와 관계에서 식별자와 속성을 확정하는 단계이다.
- 일반적으로 정규화 작업을 통해 기존에 찾지 못했던 새로운 엔터티를 도출하거나 다대다(n:m) 관계를 해소하게 된다.
- 성공적인 논리 데이터 모델링을 위해서는 업무 프로세스를 이해하고 있는 현업 사용자의 참여가 필수적이며, 함께 모델링을 진행해야 한다.
- 논리 모델링 단계에서는 DBMS 시스템 유형은 고려하지 않으며, 일반적으로 제 3정규화 과정까지만 진행하게 된다. (⇒ 이 부분은 뒤에서 추가 설명)
1-2. 논리 데이터 모델링의 기능
- 전사적 통합 데이터 체계를 구축하여 비즈니스에 대한 이해를 도와준다.
- 데이터의 일관성 및 정확성을 유지하기 위한 규칙을 도출해낸다.
- 사용자와의 명확한 의사소통 수단으로 활용된다.
- 안정적인 데이터베이스 설계의 토대를 마련한다.
1-3. 정규화 과정
- 정규화란?
- 엔터티(=릴레이션, 테이블) 에 데이터 입력, 수정, 삭제 연산 시 발생하는 이상 현상을 제거하는 과정이다.
- 간단히 말하면 엔터티와 관련없는 속성을 제거하거나 분리하는 과정이다.
- 정규화 과정을 통해서 데이터의 정확성, 일관성, 안정성 등을 만족하게 된다.
- 이상 현상이란?
- 입력 이상 현상
- 데이터 입력시 불필요한 데이터도 함께 입력해야 하는 현상
- A 테이블의 데이터를 입력하려면 B 테이블의 데이터도 함께 입력해야 하는 경우
- 수정 이상 현상
- 일부 속성 값을 수정하면서 데이터의 정확성과 일관성을 보장하지 못하는 현상
- A 속성값을 수정하기 위해서 관련된 모든 데이터를 함께 수정해야 하는 경우
- 삭제 이상 현상
- 일부 정보를 지움으로써 관련된 정보가 연쇄적으로 함께 삭제되는 현상
- A 속성에 대한 정보를 지워야 하는데 관련된 행 전체가 삭제되면서 필요 정보가 누락되는 경우
- 입력 이상 현상
- 정규화 과정의 목적
- 관계형 데이터베이스(RDBMS)에서 데이터의 중복성을 줄이고 보존성을 높이게 된다.
- 데이터 중복성을 줄임으로써 저장공간을 최소화한다.
- 복잡한 관계를 단순화시킴으로써 데이터 조회속도 능력을 향상시키게 된다.
- 정규화의 장점
- 데이터의 중복값과 null 값이 줄어들게 된다.
- 정규화를 통해 새로운 엔터티를 도출하면서 요구사항의 발견 과정을 돕게 된다.
- 데이터 구조의 안정성을 높이게 되고 향후 모델 변화에 유연하게 대처할 수 있다.
정규화 과정은 제1정규형부터 제5정규형까지 이루어져 있다. 일반적으로 논리 데이터 모델 구축 시에는 제 3정규형까지 작업이 이뤄지기 때문에, 제3정규형까지만 자세히 알아보도록 하자.
[Part2. 논리 데이터 모델링 - 정규화 과정]
정규형의 예시는 이론적인 내용보다 실제 예시를 보면서 이해하는 편이 좋을 것이다. 각 정규형별로 예시를 들어두었으니 참고해서 이해해보도록 하자.
2-1. 제1정규형
- 모든 속성은 반드시 하나의 원자 값만으로 되어있어야 한다.
- 각 속성은 유일한 이름을 가지며, 속성 내의 값들은 모두 동일한 형식(=도메인)이어야 한다.
- 행(=row)들은 서로 식별 가능해야 한다.
2-2. 제2정규형
- 식별자가 아닌 모든 속성은 식별자 전체 속성에 완전 종속되어야 한다.
- 쉽게 말해, 주 키(=primary key, pk)가 아닌 모든 칼럼은 주 키(pk)에 종속되어야 한다.
2-3. 제3정규형
- 제2정규형을 만족하면서 식별자를 제외한 나머지 속성들 간에 종속이 존재하지 않는다.(=식별자를 제외한 속성들은 서로 독립적인 상태)
이후 논리 데이터 모델링 과정에서는 속성과 엔터티의 식별자를 확정하게 되는데, 이 부분에 대해서는 앞장의 내용 (📗 [DAsP 한 권으로 끝내기] Chapter4.데이터 모델링 - (2))을 참고하도록 하자.
[Part3. 논리 데이터 모델링 - 참조 무결성 규칙 정의]
일반적으로 부모-자식 간의 관계를 가진 엔터티에 대해 데이터를 입력하고 삭제할 때의 규칙을 정의하는 것이다.
자식 엔터티에 데이터를 입력할때 관련된 부모 엔터티의 처리는 어떻게 할지? 혹은 부모 엔터티의 데이터를 삭제할 때 관련된 자식 엔터티의 처리는 어떻게 할지? 에 대해서 규칙을 정의하게 된다. 각 모델링 상황에 맞게 규칙을 정의하게 되며, 자세한 규칙에 대해서는 아래 참고내용을 읽어보면 된다.
1. 입력규칙
- Dependent - 부모 엔터티에 인스턴스가 있는 경우에만 자식 엔터티의 입력을 허용
- Automatic - (자식 엔터티 인스턴스 입력을 항상 허용하고) 대응되는 부모 인스턴스가 없는 경우 자동 생성
- Nullify - (자식 엔터티 인스턴스 입력을 항상 허용하고) 대응되는 부모 인스턴스가 없는 경우 자식 참조키를 Null값으로 처리
- Default - (자식 엔터티 인스턴스 입력을 항상 허용하고) 대응되는 부모 인스턴스가 없는 경우 자식의 참조키를 기본값으로 처리
- Customized - 특정 검증 조건을 만족하는 경우에만 자식 엔터티의 입력 허용
- No Effect - 아무런 조건 없이 항상 자식 엔터티의 인스턴스 입력 허용
2. 삭제 규칙
- Restrict - 자식 엔터티에 인스턴스가 없는 경우에만 부모 엔터티의 삭제 허용
- Cascade - (부모 엔터티 인스턴스의 삭제를 항상 허용하고) 대응되는 자식 인스턴스를 자동 삭제
- Nullify - (부모 엔터티 인스턴스의 삭제를 항상 허용하고) 대응되는 자식 인스턴스의 참조키를 Null값으로 처리
- Default - (부모 엔터티 인스턴스의 삭제를 항상 허용하고) 대응되는 자식 인스턴스의 참조키를 기본값으로 처리
- Customized - 특정 검증 조건을 만족하는 경우에만 부모 엔터티의 삭제 허용
- No Effect - 아무런 조건 없이 항상 부모 엔터티의 인스턴스 삭제 허용
[Part4. 논리 데이터 모델링 - 이력 관리 정의]
4-1. 이력 관리란?
- 데이터의 발생 이력 시점에 대한 정보를 관리하는 것을 의미한다.
- 과거와 현재 시점의 데이터를 비교해야하는 중요 대상에 대해서만 이력 관리를 진행하게 된다.
4-2. 이력 관리의 종류
(1) 발생 이력 데이터
- 데이터가 발생할 때마다 해당 시점의 이력 정보를 남기는 경우
- 이벤트가 발생할 때마다 남길 수도 있고, 특정 기간 기준으로 계속 데이터를 남길 수도 있다.
- ex) 고객의 웹사이트 접속 기록(이벤트 발생시 마다 생성 or 일별로 생성)
(2) 변경 이력 데이터
- 데이터의 내용이 변경될 때마다 이력 정보를 남기는 경우
- ex) 고객의 주문 정보가 변경된 상황
(3) 진행 이력 데이터
- 업무의 진행 과정에 따라 이력 정보를 남기는 경우
- ex) 주문 업무 처리 내역(구매 신청 → 입금 완료 → 배송 준비 중 → 배송 중 → 배송 완료)
4-3. 이력 관리 형태에 따른 쿼리 예시
- 이력 관리는 시점/선분 이력으로 구분될 수 있다.
- 시점 이력 → 데이터의 변경이 발생한 시간(=시점) 관리
- 선분 이력 → 데이터 변경이 시작된 시점부터 종료된 시점까지 관리
- ※ (참고) 선분 이력 조회시 쿼리 수행 속도를 위해서는 종료시점이 없더라도 최대치를 부여하는 것이 좋다.(ex.9999/12/31)
/* 시점 이력 예시 */
SELECT 환율
FROM 환율 변동 이력
WHERE 발생시간 = (SELECT MAX(발생시간)
FROM 환율 변동 이력
WHERE 발생시간 <= 20230524 AND 통화_ID = 'KOR') AND 통화_ID = 'KOR'
/* 선분 이력 예시*/
SELECT 환율
FROM 환율 변동 이력
WHERE 발생시간 BETWEEN '2023-05-24 00:00:00'
AND '2023-05-25 00:00:00' AND 통화_ID = 'KOR'
모든 데이터 모델링 설계가 완료되면 모든 이해관계자들은 모델 리뷰를 통해 데이터 모델의 품질을 검토해야 한다. (⇒ 개념/물리 데이터 모델도 동일) 논리 데이터 모델링의 품질을 검토할 때에 완벽한 모델인지를 평가하는 것이 아니라, 조직의 상황과 여건에 적합한 모델인지에 대한 관점으로 검토하는 것이 중요하다.
논리 데이터 모델의 품질을 검토하는 기준은 [데이터아키텍처 전문가 가이드 p.449~453] 내용을 가볍게 읽어보면 되겠다.
다음장에는 마지막 단계인 물리 데이터 모델링 과정에 대해 알아볼 예정이다.
📘참고 서적: [데이터아키텍처 전문가 가이드]
한국데이터산업진흥원 지음
'[자격증] > DAsP(데이터아키텍처 준전문가)' 카테고리의 다른 글
[DAsP 한 권으로 끝내기] Chapter4.데이터 모델링 - (4) (0) | 2023.06.03 |
---|---|
[DAsP 한 권으로 끝내기] Chapter4.데이터 모델링 - (2) (0) | 2023.06.03 |
[DAsP 한 권으로 끝내기] Chapter4.데이터 모델링 - (1) (0) | 2023.06.03 |
[DAsP 한 권으로 끝내기] Chapter3.데이터 표준화 - (2) (0) | 2023.06.03 |
[DAsP 한 권으로 끝내기] Chapter3.데이터 표준화 - (1) (0) | 2023.06.03 |