데이터 모델링 (1)

 

데이터 모델링(data modeling)이란 주어진 개념으로부터 논리적인 데이터 모델을 구성하는 작업을 말하며, 일반적으로 이를 물리적인 데이터베이스 모델로 환원하여 고객의 요구에 따라 특정 정보 시스템의 데이터베이스에 반영하는 작업을 포함한다. 후자의 의미로 흔히 데이터베이스 모델링으로 불리기도 한다.   -위키 백과-

 

위키에서 설명하는 데이터 모델링의 내용은 개념으로부터 논리적인 데이터 모델을 구성하며 이를 물리적인 데이터베이스 모델로 변환하여 요구에 따라 정보 시스템의 데이터베이스에 반영하는 작업이다.

 

그럼 데이터 모델링은 무엇을 모델링하는 것 일까?

 

데이터 모델링은 현실세계의 사물, 사건, 관점, 비지니스를 추상화시키고 단순화시켜 명확하게 모델링하는 것을 의미한다.

또한 위에서 말하는 정보 시스템을 구축하기 위해서는 데이터를 계획/분석/설계하는데 이때 업무를 분석하고 설계하며,

이후 구축/운영 단계에서는 변경과 관리 등의 목적을 가지고 이용할 수 있도록 구축해야 한다.

 

데이터 모델링은 3가지의 관점으로 본다.

what = 업무가 어떤 데이터와 관련이 있으며, 어떤 관계를 가지고 있는가?

how =  업무가 어떤 일인지, 무엇을 해야 하는지?

상관 = 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받는지?

 

사실 데이터 모델링을 실무에서 한다는 것은  기업 업무에 대한 종합적인 이해를 바탕으로 이루어져야만 한다.

 

비즈니스의 이해를 바탕으로 업무내용을 정확하게 분석하는 것을 통해 모델을 생성하고 모델을 가지고 개발 및 데이터 관리를 진행한다. 

 

 

데이터 모델링은 3가지 관점이 있기에 3가지 요소가 존재한다.

 

1. 업무가 사용하는 어떠한 것(Things)

2. Things가 가지는 성격(속성)

3. 업무가 관여하는 Things 간의 관계

 

실제로 이 세 가지가 엔티티, 속성, 관계로 변환된다.

 

데이터 모델링을 할 때 보통 3단계를 거쳐서 데이터를 모델링한다.

 

1. 개념적 데이터 모델링 (Conceptual Data Modeling)

 

 - 추상화 수준이 높은 상위 수준을 형상화 하기 위해서 개념적인 모델링을 한다고 할 수 있다.

조직, 사용자의 데이터의 요구사항을 찾고 분석으로 시작한다. 이때 실무에서는 인터뷰를 통해 개발자와 고객사의 실무자들을 만나 실제 업무에대한 요구사항에 대한 회의를 자주 한다.   인터뷰를 통해 핵심 엔티티를 찾고 그들간의 관계를 발견하여 ERD 다어이어 그램을 만든다. 

이 때 전 조직에 걸쳐 이루어진다면 전사적인 데이터 모델링이라 하며 보통 Enterprise Data Modeling 이라고도 한다.

 

2. 논리적 데이터 모델링 (Logical Data Modeling)

 

 - 가장 중요한 단계라고나는 생각한다.  Entity 중심의 상위 수준 모델이 완성되었다면, 업무에 구체적인 모습과 흐름에 따른 구체화된 업무 중심의 데이터 모델을 만든다. 이 단계에서는 비즈니스 데이터에 존재하는 사실들을 인식하여 기록한다. 이때 정규화 과정을 진행하는데, 주요 목적으로는 데이터의 중복을 제거하고 일관성을 확보하거나 무결성을 지키기 위한 노력이다. 

 

 

3. 물리적 데이터 모델링 (Physical Data Modeling)

 

 - 실제로 Table, Columns, FK, PK 등  데이터베이스의 구조를 잡고 실제 저장장치를 효율적으로 설치하는 과정이며

이때 DBA분들이 가장 많은 시간을 투자한다.

 

 

사실 DBA분들은 개념+논리적 데이터 모델링 부분에서 크게 관여하지 않는다. 도와주거나 조언을 주는 정도이지 직접 설계를 하지는 않는다. 다만 과정에는 참여를 하고 비즈니스적 이해를 하는 것을 바탕으로 하고 물리적으로 데이터를 모델링할 때 어떤 장치가 가장 효율적인지, SQL 문의 튜닝 등등 좀 더 교육적이고 전체적인 데이터베이스 관리자의 역할에 충실하고, 이러한 실제 설계 부분은 시스템 개발자가 도맡아서 한다.

 

실무에서는 이렇게 3단계를 거쳐서 모델링하지는 않는 것 같다. 개념과 논리를 묶어서 한 번에 진행하는 것을 많이 보았고 이후 물리까지도 DBA가 없다면 개발자가 전부 처리하기도 한다.

 

아까 ERD를 사용한다고 했는데 ERD가 무엇인지 알아보자.

 

사실 대학과정에서는 ER 설계를 알려주는 경우가 대다수인데 사실 실무처럼 몸집이 커지게 되면 ER설계는 한계점이 너무 도드라져서 아예 사용하지 않는다. 대신 ERD를 사용한다. 

 

ERD는 각 업무 분석에서 도출된 엔티티와 엔티티 간의 관계를 쉽게 이해하기 위해서 도식화시킨 것을 말한다. 

개발자가 클래스를 설계할 때 UML을 사용해 설계하는 것 과 같은 맥락이며 가장 중요하기도 하다.

 

ERD에 관한 설명은 하지 않겠지만 대략적인 작업 순서는 다음과 같다.

 

논리적인 모델링까지 진행했다는 전제하에 

 

주요 엔티티를 좌측 상단에 연관된 엔티티들을 주변에 배치한다. 그 이유는 사람의 눈은 왼쪽에서부터 오른쪽, 위에서 아래로 향한다. 그렇기 때문에 흐름적으로도 좌측 상단에 주요 엔티티를 배치하여 자연스러운 흐름이 되는 것이 좋다.

 

엔티티를 배치했다면 각 엔티티 간의 비즈니스 관계를 설정해준다. 예를 들어 고객은 주문을 한다. / 주문은 고객에게 주문을 받는다. 등 현재형으로 관계에 관한 이름을 적는다. 그 이후 각 엔티티의 인스턴스들이 관계에 얼마나 참여하는지 참여도를 정하고, 관계 참여의  필수 여부를 지정하면 된다.

 

이때는 IE/Crow's Foot 표기법을 가장 많이 사용한다.

 

 

이제 데이터 모델이 완성되었다고 했을 때 체크해보아야 할 요소가 있다.

 

1. 업무에서 필요로 하는 모든 데이터가 정의되었는가?

2. 동일한 사실은 반드시 한 번만 기록되는가? (의도적으로 중복을 허용했다면 성능적으로 이점이 있어야 한다.)

3. 잦은 변경사항이 있는 비즈니스 요구사항에서 데이터 모델이 유연하게 대응할 수 있는가?(가장 어렵다)

4. 많은 업무 규칙들을 정보 시스템을 사용하는 사용자/ 관리자들이 설계자가 정의한 업무 규칙들을 동일한 의미로 받아 드릴 수 있는가?

5. 동일한 데이터가 한 번만 정의되었다면 다른 곳에서 참고하거나, 활용할 수 있어야 한다.

 

용어에 대해서 말하자면 엔티티는 집합 개념으로 사용되고 단수를 인스턴스라고 부른다.

 

그렇다면 누가 데이터 모델링을 학습해야 할까?

 

대답은 데이터베이스를 구축하는 모든 사람이 학습해야 한다. 개발자는 특히 중요하며, DBA, 관리자 등 참여하는 모든 이가 알고 있어야 효율적으로 데이터베이스를 활용할 수 있다.

 

또 하나로 중요성이 대두되는 것은 데이터의 독립성이다. 

 

데이터 독립성을 표현하는 데 있어서 미국 표준협회 산하 X3위원회에서 정의한 three-schema-architecture를 통해 정의된 아키텍처를 예를 들 수 있다.  이 아키텍처는 구조, 독립성, 사상을 이해하면 많은 도움이 된다.

 

이 아키텍쳐는 각 데이터베이스의 단계를 인터페이스 계층을 두어 분리한 것인데 그로 인해 각 계층의 변화에 영향을 받지 않는 것이 목적이다. 각 계층은 가장 하부에서 물리적인 단계를 가지고 있는 내부적 단계가 존재하며, 물리적인 독립을 구현한다. 이때 사상(Mapping)은 다리 역할을 하며 이 사상을 통해 다음 단계인 개념적 단계랑 소통한다.

개념적 단계는 우리가 아는 논리적인 단계를 뜻한다. 최상위 외부 단계가 존재한다. 외부 단계는 데이터를 사용하는 사용자나 개발자들에게 가공된 데이터를 보여주는 VIEW라 할 수 있다.

 

이 부분에 대해서는 많은 자료가 존재하기 때문에 길게 설명하지 않는다.

 

사실 데이터 모델링을 한다는 것은 내부 단계부터 개념적 단계 외부 단계로 올라가면서 설계를 한다고 할 수도 있다.

 

다음에는 엔티티에 관하여 자세히 알아보겠다.