우리는 반드시 집합의 개념으로 사고해야 한다.

1

이쪽 분야에선 엔코아시스템의 ‘이화식’님의 교재를 주로 보는 것 같았다. 확신할 순 없고, 나의 선배들이 그러했다. 그때나 지금이나 ‘그’ 책은 뭔가 다가갈 수 없는 영역이었다. 당시에는 도메인에 대한 개념정의가 확실하지 않았기 때문일 수 있다고 생각하지만 여전히 데이터 모델링 영역은 껄끄럽다.

2

반면에, 이 책은 껄끄러운 영역의 기본적인 내용이 잘 담겨있다. 그래서 ‘그’ 책을 읽을 용기가 생겼다.

1. […] 나는 모델링이 잘 되지 않는 상황은 크게 세 가지라고 보는데 첫 번째는 […] 업무를 이해하지 못했거나 업무 요건이 명확하지 않을 때, 두 번째는 […] 모델링 이론을 정확히 숙지하지 못한 경우, […] 세 번째 이유는 이 두 상황이 혼재된 이유다.

2. 거래 처리 영역과 분석 정보 영역은 본질적으로 다른 목적을 가진다. 거래 처리 영역은 비즈니스 활동 자체를 지원한다. 반면 분석 정보 영역은 비즈니스 활동에 대한 측정, 평가, 분석, 예측, 개선 등을 지원한다.

3. […] 따라서 OLAP의 데이터 모델은 OLTP 데이터 모델보다 정규화가 덜 된 형태일 수 있으니, BI 초보 설계자는 OLAP의 반정규화된 모델을 정규화하고 싶은 유혹을 뿌리쳐야 한다.

4. […] 데이터 모델링은 업무 데이터를 읽고 이해하여 이를 조직화하고 구조화하는 과정이다. 따라서 데이터 모델링에는 업무 데이터를 충분히 이해하는 것이 선행되어야 한다.

5. 고대 그리스 철학자들이 세상을 이해하는 방식 1) 사물의 속성 자체에 주의를 기울이고, 2) 그 속성에 근거하여 범주화하고, 3) 그 범주들을 사용해서 규칙을 만들고, 4) 사물의 특성과 움직임을 그 규칙으로 설명한다.

6. 지원, 고객, 공급자의 정보를 별도의 엔티티로 관리한다면 직원 엔티티의 B와 공급자 엔티티의 B는 완전히 다른 객체로 취급된다. […] 이는 바로 고객관계관리(CRM)의 고객 통합 영역에서 항상 언급되는 통일인 인식 문제에 해당한다.

7. 따라서 우리는 추상화 수준을 항상 고심하게 되며, 적절한 절충점을 결정하는 것 역시 모델러의 필수 역량이다.

8. 데이터모델링은 2차원 표에 데이터를 어떻게 담는 것이 최적인지 그 구조를 고민하는 과정이다. 또한 데이토 모델은 단순히 도식화된 모형이 아닌 데이터베이스가 최고의 성능을 낼 수 있는 구조여야 한다. 정규화는 이에 대한 궁극의 기반 이론이다.

9. 정규화하면 테이블이 분리되어 조인이 늘어난 성능이 저하된다는 말은 상황에 따라 사실일 수도 있고 아닐 수도 있다. OLTP에서 조인에 의한 성능 저하가 극심한 경우라면 조인 방법이 잘못 되었을 가능성이 크다

10. […] 모델링 서적에서 자주 언급되는 몇 가지 화두에 대해 곰곰이 생각해보자. 1) 데이터는 업무 프로세스와 무관해야 한다. 즉, 프로세스에 종속적이지않 아야 한다. 2) 업무 활동과 절차가 변한다고 데이터 모델이 쉽게 바뀌어서는 안된다. 3) 데이터 모델은 업무를 명확히 표현해야 한다.

11. 엔티티 모델링 어려운 이유를 세분화하면 크게 다섯 가지 정도로 정리할 수 있다. 1) 데이터 집합을 정의하기가 쉬빚 않다. 2) 데이터 본질을 볼 줄 알아야 엔티티를 정확하게 정의할 수 있다. 그런데 어떠한 대상에서 비즈니스 관점을 제거하는 게 그리 쉬운 일은 아니다. 3) 엔티티 추상화 수준을 결정하는 것은 대단히 어렵다. 4) 하위의 트랜잭션 데이터만을 보고 부모 역할을 하는 상위의 논리적인 집합을 발견하는 것은 어렵다. 5) 업무의 방대함과 복잡도에 압도되기 슆다.

12. 모델러는 최종 트랜잭션 데이터가 아니라, 트랜잭션의 실질적인 주체와 대상에 해당하는 데이터를 정확히 볼 줄 알아야 한다.

13. […] 즉, Account는 업무 행위의 최상위 주체로, 관련 업무 처리들을 동일한 성격으로 관리하는 단위다. […] 수많은 행위 데이터들을 동일한 성격으로 묶을 수 있는 단위 객체이다.

14. 소프트웨어의 복잡성을 분할 정복으로 해결할 수 없는 이유는 소프트웨어를 모듈화한다고 해서 로직도 모듈화되는 것은 아니기 떄문이다. 결국 분할은 소프트웨어의 복잡도를 제거하는 것이 아니라 복잡도의 숲에서 길을 잃지 않고, 업무 영역을 시스템으로 옮기는 데 지치거나 압도되지 않도록 도와 줄 뿐이다.

15. 배타적이란 말은 동일 차원에서 분할했을 때 분할된 상호 간에 중복이 발생하지 않는 상태를 의미한다.

16. […] 논리 모델은 정규화 이론에 기반하여 데이터 무결성을 극한까지 보장해준다. 반면 물리 모델은 무결성과 정합성을 깨는 것을 최소화하면서 성능 위주로 최적화하는 데 목표가 있다. 둘의 목적과 뷰는 유사한 듯 다르다.

17. 관계와 관련된 몇가지 이슈 1) 관계에는 EQUAL, NOT EQUAL, LIKE, BETWEEN 등 다양한 패턴이 있다. 2) EQUL 이외 관계는 DBMS의 참조무결성 제약으로 구혀이 불가능하며, 애플리케이션에서 로직으로 처리해야 한다. 3) EQUAL, 외의 관계를 표현할 수 있는 모델링 툴은 많지 않다. 4) 데이터 규칙을 최대한 표현하다는 관점에서 툴에서 지원하지 않는 관계는 설명 상자등으로 기술하는 것이 적극적인 대응이라 생각한다. 5) 따라서 관계의 개념을 확장해보면 이 절의 처음에 나온 정의는 잘못된 것이라고 할 수 있다. 이 정의 관계의 현실적 정의 정도로 이해하면 좋을 것이다.

18. 유연한게 설계된 모델은 다음과 같은 약점도 갖게 되기 떄문이다. 1) 추상화 수준이 높아 직관적이지 않고, 경우에 따라 이해하기 어렵다 2) SQL이 복잡해서 개발과 유지보수 비용이 늘어난다. 3) 유연하지 않는 구체적인 모델과 비교하여 성능상의 제약과 한계가 있다. 4) 성능 외에도 RDB의 기본 사상과 다른 차원의 모델로 인해 DBMS가 제공하는 기본 기능 활용에 제약이 있을 수 있다.