오늘은 데이터 모델링을 진행하면서, 읽었던 책에 관한 내용을 공유해보고자 합니다
책 구매링크: https://product.kyobobook.co.kr/detail/S000001057639
꽤 오래전에 읽었던 책인데, 데이터 모델링 할 때 마다 읽게 되는 책이라 챕터마다 나름 정리를 해봤다.
1. 데이터 모델링의 기본 (story1~story3)
개체=행
엔티티=집합=테이블
모델링은 업무의 이해 → 업무 데이터의 이해 → 데이터 구조 모델링 → DB 생성 순으로 이루어진다.
그렇다면 데이터를 이해한다는 것은 무엇인가?
- 데이터가 어떻게 흐르는지(프로세스), 데이터의 선행관계와 같은 종속성(N:M,1:N등등) 규칙을 찾는 것(규칙과 관계)
- 프로세스: ex) 누가, 언제, 어떤 상품을 구매한다.
- 규칙과 관계: ex)
- 규칙: 같은 상품을 여러번 구매 할 수 있는지, 한번에 여러개 상품을 구매할 수 있는지
- 관계: 구매를 요청한 부서를 알고 있어야 하는지→ 이럴 경우 부서와 구매행위 간의 관계가 필요하다.
단위: 테이블 한줄에 들어가는 정보 ( 회원정보 우선 이여서, 자동차 테이블을 별도로 분리했음을 생각)
행위엔티티 / 시간이란 개념과 행위
주문A와 주문B를 구분해주는 식별자는 고객과 시각이다.
누가와 언제라는 정보가 절대적으로 중요하다. 고객의 행위에 시간이라는 개념이 절대적으로 개입되게 된다.
이로서 행위 엔티티는 식별자에 시각속성이 존재 하는 것을 확인 할 수 있다.
화면단위로 데이터 모델링을 진행하는 것은 아니다.
예를 들어, 주문서 한장을 살펴보자. 주문서에는 주문정보(주문번호, 고객정보, 주문품목, 결제정보)를 담고 있는데 주문서 1개의 테이블이 아닌 주문정보 별 로 여러 테이블로 나누게 된다. 이렇게 하는 이유는 데이터 관리(저장, 수정, 조회 등)에 유리하기 때문이다.
데이터 모델링에 대한 이론 학습 2가지
- 하나의 집합체로 보이는 뷰에서 데이터 구조로서의 부분을 분리해야하는 이유 (데이터 관리) (story6)
- 부분으로서의 테이블을 분리하는 기준과 규칙등 방법론 (여러 테이블)(story7)
설문지를 통한 데이터 모델링 예시
데이터의 성격과 주제등의 유사함을 중심으로 구조화 하는 작업이 필요하다.
나는 설문지를 봤을 때, 연령대와 성별, 제품가격 품질 만족도 같은게 존재하길래 고객과 제품위주로 테이블이 필요하다고 생각을 했다.
그게 아니라 1) 질문, 2) 보기, 3) 설문지 이렇게 3가지 요소를 찾아야했다.
설문 제목은 설문을 기획하고 생성하는 입장에서의 메타 정보이다. 따라서 설문지라는 상위 개체 수준에서 관리 해야한다. → 설문지 제목과 개요의 경우 설문지에서 보이지 않는 텍스트여서 상위 개체 라는 소리이다.
ㄴ 메타 정보가 뭐지? 상관없는 규격화된 정보?
데이터 모델링을 위한 기본기 2가지를 살펴 봤다.
- 데이터의 근본 성격 파악 → 데이터 집합과 개체 식별
- 위에서 보듯 질문,보기, 설문지을 찾아 집합 구분을 했던 것들
- 데이터의 종속성 분석 → 데이터의 독립성 확인과 모델 골격 조망
- 설문 질문 – 설문 보기 1대N 관계에서 테이블 관계 구조를 바꾸어 질문과 보기를 각각 독립적으로 모듈화 시킬 수 있다. 모듈화를 시키는게 좋긴하나, 서로의 관계를 살펴보고 필요에 의해서 진행해야할 것 같다.
여기까지가 업무를 데이터 중심으로 바라 볼 수 있는 시선이고, 모델링을 위해 데이터를 이해한다라는 내용을 알 수 있었다.
업무를 데이터 중심으로 바라 본다는 것은 유사한 데이터 근본을 파악하고 그룹핑하는 것을 말한다.
데이터를 이해 한다는것은 비지니스 로직적으로 어떻게 사용 할 것인지를 알고 있기 때문에, 왜 이렇게 관계를 지었는지에 대한 것을 알고 있다는 것을 말한다. 위에서 말하는 1:N의 관계같은 것을 말할 수도 있고 관계가 필요없기에 모듈화 작업을 진행했던 것도 말할 수 있겠다. 즉, 왜 이렇게 모델링을 했는지를 알고있다는 것이다.
2. 데이터 모델링을 한다는것 (story4~story6)
이해를 돕기 위한 내용
- 디멘션: if문이라 생각하면 될듯하다.
- 팩트: 결과라 생각하면 될듯하다.
- 팩트라는건 맥락(여러 디멘션)을 걸쳐 나온 정보이다.
- 디멘션은 그룹핑 구조를 가질 수 있게 되어있다. if문안에 switch같은느낌이랄까.
story4에서 중요한건 디멘션을 뽑는 통찰력이다. 상품판매량 엑셀의 내용을 보고 지역, 년도, 상품 3가지 디멘션을 추출한 것이 가장 중요하다고 생각된다.
어떻게 보면 87이라는 판매량이 어떤 기준(디멘션)으로 뽑혔는지를 살펴보았을 때 역으로 추적한 것 같아 보이기도 한다.
데이터의 처리는 OLTP와 OLAP가 존재한다.
- CRUD를 사용하여 현재 데이터를 처리하는 것은 OLTP(OnLineTransaction Protocol)라고 한다.
- 분석 성격의 데이터 처리를 OLAP(OnLineAnalyticalProtocol)라고한다.
앱, 웹 개발자라면 OLTP성격의 데이터 처리 위주로 하게 된다. 데이터 분석가나 BI 쪽이라면 OLAP 형식의 데이터처리를 하게 될텐데 중요한 점은 처리 유형에 따라 모델링 방법이 다르다는 것이다.
즉, OLTP는 중복과 무결성을 중시하는 정규화를 사용하게 되고, OLAP 반정규화를 쓰게 될 것이라는 것이다.
범주화와 추상화를 통해 데이터 속성을 끄집어 내야한다.
범주화는 본질이 유사한 것끼리 묶는 작업을 말한다. 본질이라는 것은 대상의 가장 핵심적이고 필수적인 속성을 말한다.
- 사물의 속성자체에 주의를 기울이고
- 그 속성에 근거하여 범주화하고
- 그 범주들을 사용해서 규칙을 만들고
- 사물의 특성과 움직임을 그 규칙으로 설명한다.
개체간의 표면적인 유사성에 영향을 받지 말고 존재, 성질, 모습을 분석해야한다.
예를들면, 학사관리의 학생, 교수, 직원을 엔티티로 만들게 된다면 데이터의 관리가 복잡해짐을 볼 수 있다. 학생이 교수가 되거나, 조교가 되었을 때 학생쪽 엔티티에서 제거하고 교수 엔티티에 넣어야하거나, 새로운 조교 엔티티를 만들어야 할 수도 있다. 왜 이런 상황이 생길까?
학생, 교수, 직원은 각각 다른 속성이 아니라 모두 사람이며 직책을 나타내는 엔티티임을 파악해야했다.
위의 예시에서 본질은 사람으로서의 근본적인 정보(사람, 성명 )이며,
현상은 논리적 맥락이나 역할(학생, 교수, 은행원, 고객 등)임을 볼 수 있다
범주화와 추상화는 데이터 모델링이 무엇인지 훨씬 또렷하게 해주는 작업인데 더 살펴보자.
범주화와 추상화는 데이터 모델링을 더 뚜렷하게 해준다.
범주화는 본질 유사한 것끼리 묶는 것이고, 추상화는 핵심적인 적인 특성만 추리는 것이다.
아래 추상화의 설명은 서울대 교육학용어사전에서 발췌한 내용이다.
추상화는 구체적사물들의 공통된 특징, 즉 추상적 특징을 파악하여 인식의 대상으로 삼는 행위다. 추상화가 가능한 개체들은 그것들이 소유하고 있는 특성의 이름으로 하나의 집합을 이룬다. 그러므로 추상화한다는것은 여러 개체를 집합으로 파악하는 것과 동일하다.
즉, 추상화는 어떤 관점을 기준으로 관심없고 필요 없는 부분을 덜어내어 핵심만을 간추리는 행위이다. 그 과정에서 유사한 것들은 하나의 집합으로 파악하는 것이다.
두 작업 모두 모호하고 어려운 부분들이 존재한다.
어디까지를 한 범주화로 볼 것 인지, 어디까지 추상화 시킬 것 인지 굉장히 주관적인 모호함을 가지게 된다.
범주화는 유사한 속성’들’을 끼리 묶는 것인데 확장시킬 수록 범주화 범위가 더 넓어지게 된다. 예를들면, 원숭이와 사람으로 범주화를 묶으면 지적생명체, 직립보행 할 수 있는 생명체, 팔과 다리가 있는 동물로 범주화 시킬 수 있다. 원숭이,사람,강아지를 범주화를 묶으면 크게 동물이라는 범주화로 그룹을 크게 키울 수 있게된다. 그러므로 어디까지 범주화 할 것 인가? 에 대한 질문을 계속해서 던져 범주화 시키는 힘을 길러야한다.
세계를 가장 단순하게 추상화 한다면 시간, 공간으로 추상화 할 수 있다. 시간을 더 작게 추상화하면 봄,여름,가을,겨울 사계절로 표현 할 수 있다. 공간은 오양주 육대륙으로 나누어 표현 할 수 있다. 추상화는 현실의 복잡성을 단순하게 표현해줄수있는 역할도 하지만 그 과정속에서 잃어버리게 되는 구체성과 다양성을 인식하고 있어야한다.
따라서 모델링을 하면서 적절한 추상화와 범주화을 고민해야한다.
내부 스키마, 개념 스키마, 외부 스키마
스키마라는 것은 추상화 개념이라 보면 된다.
예를들면, 디스크 정리를 진행하면 ‘데이터를 블록단위’를 보게 되는데 이를 추상화 한것이 ‘폴더’이다. 파일을 삭제하기 위해 연관된 블록들을 사용자가 일일이 제거한다고 생각하면 굉장히 복잡할 것이다. 이러한 생각을 가지고 스키마를 살펴보자. 아래로 갈 수 록 더 추상화되는 것이다.
내부 스키마: DBMS에서 보여지는 테이블 →DBMS를 통해 실제 물리적 저장 구조로 저장하게된다.(위에서 설명한 블록단위라보면된다.), 여기선 테이블까지를 말하지만 보통 내부스키마는 OS 수준의 저장 구조까지 내부 스키마라고 하긴한다.
개념 스키마: 테이블보다 더 추상화 된 것이기에, DBMS랑 상관이 없다. 논리데이터 모델이 여기에 해당하는데 엔티티 간의 관계나 속성들을 정의한 것을 말한다. (컬럼(char,int)와 같은 속성은 없다. 한글로 보여지는 모델링이라 보면 될듯하다.)
외부 스키마: 개별 사용자들이 필요한 정보를 얻기위해 조인에서 만든 뷰 테이블
보통 모델링이라 시작하면 개념 스키마 부터 관심을 가지며 시작하게 될 것 같다.
또 중요한건 조인해서 만드는 테이블과 개념 스키마는 다른 영역이라는 것이다. 서로 독립적이야 함을 명확하게 알고 있어야한다.
데이터 모델을 보는 3가지 관점이 존재하는데 이를 더 살펴보자.
- 개념 모델: 식별자와 속성들을 정의하는 모델
- 논리 모델: 개념모델을 더 상세히 + 데이터 타입과 길이(업무의 영역)
- 물리 모델 : 실질적으로 저장된 테이블들
데이터베이스가 최상의 성능을 내는 구조로 그리고 싶으면 어떻게 해야할까
정규화를 쓰세요
- 중복을 제거하셈
- 외래키는 다른 테이블 기본키로만하셈
데이터 분석 우캐함?
유형, 종속관계, 계층구조를 살펴보셈
데이터 유형
데이터 유형은 글을 쓸 때의 육하원칙처럼 데이터 유형도 그런게 존재한다.
업무 요건을 어떻게 데이터 모델로 표현 할 것인가? 에 대한 질문에 명쾌한 해답을 줄 수 있다.
해답은 데이터 유형끼리 묶으면 된다.
성격이 같은 데이터는 하나의 유형으로 통합하는데, 주체는 주체 끼리,대상은 대상끼리, 업무 행위는 관련 개체들과의 관계로 표현하는 것이 핵심이다.
여기서 ‘업무 행위’는 관련 개체들과의 관계로 표현된다는게 무엇인지 알아보자.
대출과 대출상환으로 예를 들 수 있는데, 대출을 하지 않으면 절대 대출 상환을 할 수 없다. 그렇기에 대출은 부모성격을 띄게 되고, 이를 대출 상환에 관련된 개체라고 볼 수 있다.
즉, 관련된 개체(대출)들이 없으면 ‘업무 행위’(대출 상환)은 절대 존재 할 수 없다는 것을 의미한다. 그렇기에 관련 개체들과의 관계로 표현된다고 하는 것이다.
데이터를 읽는 것은 == 트랜잭션의 실질적인 주체와 대상에 해당하는 데이터를 정확히 보는 것이다.
최상위 부모 역할의 데이터 == 마스터 데이터 라고 하는데 이를 중요하고 일관되게 관리해야한다.
추천글: 라즈베리로 서버 구축하기
