데이터 모델링 1

모델링 접근 전략
단순명료, 투명한 모델링->복잡하면 db에게 일을 많이 시킬 수 없기 때문

어떻게 단순 명료하게 설계할 것인가.

• 무엇을 어떻게 이용할지 파악
• 정보는 언제 바뀔지 모르기 때문에 단절되는 것을 막아야 한다
• 미래를 위한 융통성 확보 but 심플
• RDB에서는 효율적이지 못하면 속도가 현저히 느려짐

정보시스템의 전반적인 특징

• 다양한 기종
• 다양한 DBMS
• 분리된 데이터 모델
• 업무 흐름 중심
• 데이터 중복 & 일관성 문제
• 이력관리 부족
  => 프로그램의 문제는 금방 보완할 수 있지만, 데이터베이스의 문제는 재구축하기 전까지는 바뀔 수 없다.

데이터 모델 작성 방법

• 구체적 & 입체적 => 관계가 있다/없다 Attribute가 있다/없다 가 아니라 구체적인 관계 설정(반드시 있어야 한다 없어도 된다) 필요
• 공통/개별 관계, 공통/개별 속성을 구체적으로 명시해야 하는데, 이러한 조건을 만족한 ERD는 일견 복잡해 보이지만 설계자/관계자에게는 쉽고 명확하게 보임
• 어느 레벨?: 초가삼간을 지을 때는 간단한 설계도면 되지만, 거대한 건물을 지을 때는 복잡한 도면이 필요하다(설계자가 복잡한 도면을 보고 복잡하다고 하는 것은 지금까지 제대로 설계를 못했다는 방증)

잘못된 유형:

1. 형제형 - 먼저 자식 테이블부터 나타남. 그리고 거의 관계가 없는 부모 테이블을 만들어 자식 테이블들과 이어줌(=>할아버지도 단군의 자식, 아버지도 단군의 자식, 나도 단군의 자식 = 모두 형제(?)) = 명확한 릴레이션이 존재하지 않음
   -> 모델링은 반드시 1촌 관계만 표현!!!!!!!!!!!!!
2. 족보형 - 부계중심의 족보는 결국 단일 성씨만 나타남. 하지만 실제로는 다른 성씨도 내 혈통에 반드시 존재하는데 이것이 표현되지 않음
3. 네트워크형 - 네트워크의 선에서 단말이 하나씩 나타나듯, 중요한 entity가 드문드문 나타남. 눈앞에 보이는 많이 쓰이는 엔티티만 뽑아 역순으로 관계를 정의하려고 해서 생기는 현상

잘못된 모델링 방식

1. 혼자 책상에 앉아 모델링 - 관계자의 의견 청취 없이 혼자만의 생각으로 모델링하는 것은 초상화를 그려야 할 때 추상화를 그리는 것과 같다.
2. 관계자 혼자 떠들고 모델링 작성자는 듣기만 - 관계자는 자신의 일의 복잡성을 과장되게 이야기하는 경향이 있으므로 듣기만 해서는 모델링이 쓸데없이 복잡해짐
3. 사진 찍듯 있는 그대로의 모습만 반영 - 회사의 방침, 필요로 하는 데이터 등에 따라 모델링은 달라질 수 있기 때문에 재창조가 필요하다.

-> 잘 정돈된 저장장소가 있어야 유저가 어떤식으로 끄집어내더라도 심플하고 빠르게 전달해줄 수 있다.

수평적 사고

• 삼각형의 원리: 삼각형은 내가 하고자 하는 일의 크기. 일의 크기가 커지더라도 난이도는 달라지지 않게 하는 것이 수평적 사고. 위의 큰 삼각형도 결국 하나하나는 작은 동일한 크기의 삼각형으로 이루어져 있듯, 독립적인 하나의 삼각형을 해결할 수 있으면 다른 삼각형을 해결하는 것은 어렵지 않다.
  결국 중요한 것은 삼각형의 크기를 키우지 않는 것. 그 방법은 각 단위의 삼각형은 대칭을 이루어야 한다. 각 단계의 모델링을 대충 처리하면 삼각형의 크기는 커지고 서로 영향을 주는 데이터도 늘어나게 된다.

데이터 모델링을 대충하고 프로그램에서 처리하겠다는 생각은 버리기.
명확한 집합 정의.