제6장 데이터 모델링

1. 기본 개념 데이터모델링

데이터 모델이 제공하는 것

• 시스템을 현재 또는 원하는 모습으로 가시화하도록 도와준다.
• 시스템의 구조와 행동을 명세화 할 수 있게 한다.
• 시스템을 구축하는 틀을 재공한다.
• 우리가 결정한 것을 문서화한다.
• 다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 다양한 관점을 제공한다.
• 특정 목표에 따라 다양한 상세 수준을 제공한다.

데이터 모델링 필요성

데이터 모델링시 주의점

중복(Duplication)

데이터 모델은 같은 데이터를 사용하는 사람, 시간, 그리고 장소를 파악하는데 도움을 준다. 이러한 지식 응용은 데이터베이스의 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다.

비유연성(Inflexibility)

데이터 모델을 어떻게 설계했는냐에 따라 사소한 업무 변화에도 데이터 모델이 수시로 변경됨으로써 유집보수의 어려움을 가중시킬 수 있다. 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.

비일관성(Inconsistency)

데이터의 중복이 없더라도 비일관성은 발생한다. 예를 들어 신용 상태에 대한 갱신 없이 고객의 납무 이력 정보를 갱신하는 것이다. 개발자가 다른 데이터와 모순된다는 고려 없이 데이터를 수저알 수 있기 때문이다. 데이터 모델링시 데이터와 데이터간 상호연관 관계에 대한 명확한 정의는 이러한 위험을 사전에 예방할 수 있도록 해준다.

데이터 모델링 단계

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

개념 데이터 모델링은 조직, 사용자의 데이터 요구사항을 찾고 분석하는데서 시작한다. 이 과정은 어떠한 자료가 중요하며 또 어떠한 자료가 유지되어야 하는지를 결정하는 것도 포함한다. 이 단계에 있어서의 주요한 활동은 핵심 엔티티와 그들 간의 관계를 발견하고, 그것을 표현하기 위해서 개체-관계 다이어그램을 생성하는 것이다. 개체-관계 다이어그램은 조직과 다양한 데이터베이스 사용자에게 어떠한 데이터가 중요한지를 나타내기 위해서 사용된다. 데이터 모델링 과정이 전 조직에 걸쳐 이루어진다면, 그것은 전사적 데이터 모델(Enterprise Data Model)이라고 불린다.
개념 데이터 모델을 통해 조직의 데이터 요구를 공식화하는 것은 두 가지의 중요한 기능을 지원한다. 첫째, 개념 데이터 모델은 사용자와 시스템 개발자가 데이터 요구 사항을 발견하는 것을 지원한다. 개념 데이터 모델은 추상적이다. 그렇게 때문에 그 모델은 상위의 문제에 대한 구조화를 쉽게 하며, 사용자와 개발자가 시스템 기능에 대해서 논의할 수 있는 기반을 형성한다. 둘째, 개념 데이터 모델은 현 시스템이 어떻게 변형되어야 하느가를 이해하는데 유용하다. 일반적으로 매우 고립된(Stand Alone) 시스템도 간단하게 추상적 모델링을 통해서 좀더 쉽게 표현되고 설명한다.

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

논리 데이터 모델링은 데이터 모델링 프로세스의 Input으로써 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 기법 또는 과정이라 할 수 있다. 논리 데이터 모델링의 결과로 얻어지는 논리 데이터 모델은 데이터 모델링이 최종적으로 완료된 상태라고 정의할 수 있다. 즉 물리적인 스키마 설계를 하지 전 단계의 '데이터 모델' 상태를 일컫는 말이다. 논리 데이터 모델링의 핵심은 어떨게 데이터에 엑세스하고 누가 데이터에 엑세스하며, 그러한 엑세스는 전산화와는 독립적으로, 다시 말해서 누가(Who), 어떻게(How) 그리고 전산화는 별개로 비즈니스 데이터에 존재하는 사실들을 인식하여 기록하는 것이며 이것은 기번으로서의 의미를 넘어 하나의 철학이라고도 할 수 있다.
특히 데이터 모델링 과정에서 가장 핵심이 되는 부분이 논리 데이터 모델링이라고 할 수 있다. 데이터 모델링이란 모델링 과정을 과정을 통해서 조사하고 결정한 사실을 단지 객체-관계 다이어그램이라는 그림으로 그려내는 과정을 말하는 것이 아니다. 시스템 구축을 위해서 가장 먼저 시작할 기초적인 업무 조사를 하는 초기 단계부터 인간이 결정해야 할 대부분의 사항을 모두 정의하는 시스템 설계의 전 과정을 지원하는 '과정의 도구'라고 해야 할 것이다.
이 단계에서 수행하는 또 한가지 중요한 활동은 정규화이다. 정규화는 논리 데이터 모델 상세화 과정의 대표적인 활동으로 논리 데이터 모델의 일관성을 확보하고 중복을 제거하여 속성들이 가장 적절한 엔티티에 배치되도록 함으로써 좀더 신뢰성있는 데이터 구조를 얻는데 목적이 있다. 논리 데이터 모델의 상세화는 식별자 확정, 정규화, M:M 관계 해소, 참조 무결성 규칙 정의 등을 들 수 있으며, 추가적으로 이력 관리에 대한 전략을 정의하여 이를 논리 데이터 모델에 반영함으로써 데이터 모델링을 완료하게 된다.

물리 데이터 모델링(Phsical Data Modeling)

데이터 모델링 과정의 세 번째 단계인 물리 데이터 모델링은 논리 데이터 모델이 데이터 저장소로서 어떻게 컴퓨터 하드웨어에 표현될 것인가를 다룬다. 데이터 물리적으로 컴퓨터에 어떻게 저장될 것인가에 대한 정의를 물리적 스키마라고 한다. 이 단계에서 결정되는 것은 테이블, 컬럼 등으로 표현되는 물리적인 저장 구조와 사용될 저장 장치, 자표를 추출하기 위해 사용될 접근 방법 등이 있다.
계층적 데이터베이스 관리 시스템 환경에서는 데이터베이스 관리자가 물리적 스키마를 설계하고 구현하기 위해서 보다 많은 시간을 투자하여야 한다. 계층적 데이터베이스 관리 시스템 환경에서의 물리적 스키마 설계의 예는 데이터의 디스크상에서의 위치, 색인화할 레코드, 다양한 최적화 문제 등이다.
이에 비해, 논리 데이터 모델은 매체에 물리적으로 구현되는 것과는 독립적으로 여겨진다. 현실적으로 물리 데이터 모델을 계층적 데이터베이스 관리 시스템에 구현하는 것은 그것이 구현될 하드웨어와 밀접한 관계를 맺고 있다. 그러나 관계형 데이터베이스 관리 시스템늬 츌현으로 인해 그 초점이 개념 및 논리 데이터베이스 설계로 이동하고 있다. 그래서 관계형 데이터베이스 관리 시스템을 사용하는 조직에서는 데이터베이스 관리작가 잘 유지해야 하는 데이터 항목의 발견과 데이터 항목 간에 존재하는 논리 관계를 이해하는데 더 많은 시간을 할애한다. 관계형 데이터베이스 관리 시스템의 출현으로 인하여 물리적 데이터베이스 설계와 관련된 문제들은 많은 부분 관계형 데이터베이스 관리 시스템 소프트웨어에서 처리되고 있다.

1.1 엔티티(Entity)

정보가 저장될 수 있는 사람, 장소, 물건, 사전 그리고 개념을 정의할 수 있는 것으로 정보 시스템을 구현할때 데이터베이스 테이블에 해당되는 데이터 모델링에서 가장 중요한 표기법이다.

1.1.1 엔터티의 특징

• ENTITY NAME은 단수형이고 유일하게부여
• 이름만으로도 의미 전달이 되도록 고심하여 명명
• 보충 설명이 필요한 경우나 지금까지 통상 사용하던 단어가 있다면 동의어를 ()사용하여 추가
• ENTITY 명을 ATTRIBUTE 명과 같게 사용하지 말 것
• 모든 ENTITY는 다수의 사용형태(INSTANCE)를 가져야 함
• 모든 ENTITY의 사용형태는 ATTRIBUTE에 특정한 값을 가져야 함
• INSTANCE는 가끔 ENTITY로 잘못 판단되는 경우가 있음
• 모든 INSTANCE는 같은 ENTITY 내에서 반드시 다른 INSTANCE와 구별가능한 식별자(UID)를 가져야 함
• 식별자는 현존하지 않더라도 개념적으로는 존재해야 함
• 만약, 유일한 식별자가 없다면 ENTITY가 아님
• ENTITY NAME은 대문자, 크게 표시
• ATTRIBUTE NAME은 소문자, 작게 표시
• ENTITY의 UID가 되는 ATTRIBUTE에는 #*을 표시
  

1.2 관계(Relationship)

관계는 엔티티와 엔티티간 연관성을 표현한 것이다. 현재 관계나 장래 유용한 관계만 한정적으로 표현한다. 각 방향의 관계에는 관계의 명칭, 선택사항, 그리고 관계형태를 표시하여 준다.

가. M:1 관계

• A 엔티티에 존재하는 데이터 1개와 관계되는 B 엔티티에 존재하는 데이터의 개수가 여러 개인 엔티티 간의 관계를 M:1 관계라고 한다.
  
  • 각 사원은 단 하나씩의 부서에 반드시 소속되어야 한다.
  • 각 부서는 하나 이상의 사원을 배치받을 수 있다.

나. M:M 관계

• A 엔티티에 존재하는 데이터 1개와 관계되는 B 엔티티에 존재하는 데이터의 개수가 여러 개이며, B 엔티티에 존재한 데이터 1개와 관계되는 A 엔티티에 존재하는 데이터의 개수도 여러 개인 엔티티 간의 관계를 M:M 관계라고 한다.
  
  • 각 학생은 하나 이상의 교육과정에 등록되어 질 수도 있다.
  • 각 교육과정은 하나 이상의 학생을 접수 받을 수도 있다.

다. 1:1 관계

• A 엔티티에 존재하는 데이터 1개와 관계되는 B 엔티티에 존재하는 데이터의 개수가 1개인 엔티티 간의 관계를 1:1 관계라고 한다.
  
  • 각 PC는 단 하나씩의 마더보드에 반드시 HOST가 되어야 한다.
  • 각 마더보드는 단 하나씩의 PC에게 조립되어 질 수도 있다.

라. 관계형 메트릭스

각 ENTITY 간의 초기 단계의 관계를 정의하기 위한 보조자료로 활용되고 있으며,

• Key Entity와 Main Entity를 가로, 세로로 배열하고,
• 일단 제3자 입장에서 관계 유무만 판단하여 표시한다.
• 또한 1차 표시된 것들에 대해 구체적인 관계명칭을 찾으면서 관계 유무를 최종 판단하고,
• 상관관계가 없으면 DASH를 표시한다.
• 세로에 있는 ENTITY가 주어가 된다
• 순환(recursive) 관계는 대각선 BOX 에 기술되고,
• RELATIONSHIP MATRIX의 내용을 이용해 E-R을 그린다.
  

1.3 속성(Attribute)

속성은 엔티티에 저장되는 개체 집합의 특징을 설명하는 항목이라고 할 수 있다. 속성의 명칭은 의미가 명확하고, 내용을 함축성있게 부여하여야 하며, 집합개념(분자단위)의 속성은 단순개념(원자단위)으로 분할하여 가능한한 최소 단위까지 분할한 후, 괸리 필요에 따라 통합한다.또한 관계형 데이터베이스에서는 이러한 속성의 통합 및 분할이 수행속도에 미치는 영향이 크므로, 기존 현상조사에 국한하지 않고 적극적이고 개선적인 사고를 가지고 사용자에게 많은 질문을 하고 확인하여 속성을 결정한다.

1.4 식별자(Unique Identifier)

식별자란 하나의 엔티티에 구성되어 있는 여러 개의 속성 중에 엔티티를 대표할 수 있는 속성을 의미하며 하나의 엔티티는 반드시 하나의 식별자가 존재해야 한다. 보통 식별자와 키(Key)를 동일시 생각하고 있는 경우가 있는데 식별자는 논리 데이터 모델링 단계에서 사용하고 키는 물리 데이터 모델링 단계에서 사용한다.

• 식별자의 유형
  • 본질 식별자 : 속성들 중에서 집합의 본질을 명확하게 설명할 수 있는 의미상의 주어를 본질 식별자라한다.
  • 후보 식별자 : 각 인스턴스를 유일하게 식별할 수 있는 속성 또는 속성들의 조합이며, 후보 식별자로 속성 집합을 선택하는 경우에는 개념적으로 유일해야 한다.
  • 대체(보조) 식별자 : 보조 식별자란 원래의 식별자를 대신할 수 있는 또 다른 속성들이나 릴레이션쉽을 말한다. 가령 사원 엔티티에 공식적으로 부여된 식별자(실질 식별자)는 사원번호이지만, 만약 주민등록번호 속성이 유일한 값을 가진다면 필수적(Mandatory)으로 정의되었다면 비록 공식적인 식별자는 아니지만 식별자로서의 역활을 할 자격을 충분히 갖추고 있다. 특히 보조 식별자는 여러 참조 엔티티 중에서 원래의 식별자보다 보조 식별자로 연결을 맺는 것이 자신에게는 휠씬 유리한 경우에 의미가 있게 된다.
  • 인조 식별자 : 식별자 확정시 기존의 본질 식별자를 그대로 실질 식별자로 인정할 수 없는 여러 가지 상황이 발생했을 때, 전부 혹은 일부를 임의의 값을 가진 속성들로 대체하여 새롭게 구성한 실별자를 말한다.
  • 실질 식별자 : 인스턴스를 식별하기 위해 공식적으로 부여된 식별자를 말한다. 본질 식별자나 인조 식별자 모두가 실질 식별자가 될 수 있다.
• 작성 방법
  • 식별자 앞에는 # 기호를 표시하고 여러 개의 속성이 하나의 식별자라면 각각의 속성 앞에 # 기호를 반복적으로 표시한다.
    

2. 상세 개념 데이터모델

2.1 정규화(Normalization)

정규화의 의미

• 잘 만들어진 데이터 모델이라고 해고 엔티티에 데이터를 삽입, 수정, 삭제할 때 오류가 발생할 개연성을 가지고 있다. 이러한 것들을 통칭해서 변경 이상(Modification Anomaly)이라고 한다. 여기에는 구체적으로 삽입 이상(Insertion Anomaly), 수정 이상(Update Anomaly), 삭제 이상(Delete Anomaly)등이 있다.
• 변경 이상이 발생하는 엔티티를 그대로 운용하게 되면 데이터가 신뢰할 수 없는 값들로 채워질 가능성이 있다. 즉, 데이터의 일관성, 무결성을 해틸 가능성이 있는 것이다.
• 정규화 과정을 통해서 변경 이상의 엔티티를 정규화된 엔티티로 변환하게 된다.
  
  • 입력 이상 : 별도의 사실이 발생하기 전까지 원하는 데이터를 삽입할 수 없다. 어떤 데이터를 삽입하려고 할 때 불필요하게 원하지 않는 데이터도 함께 삽입되게 된다.
  • 삭제 이상 : 일부 정보를 삭제함으로써 유지되어야 할 정보까지도 삭제되는 연대 삭제가 발생한다.
  • 갱신 이상 : 일부 속성 값을 갱신 함으로써 원하지 않는 정보의 이상 현상(무결성 파괴, 정보의 모순성)이 발생한다.

정규화의 장점

• 중복값이 줄어든다.
  • 궁극적으로 컬럼 간, 레코드 간, 테이블 간에 중복되는 데이터들을 최소화할 수 있다. 이것이 정규화의 최대 성과라고 할 수 있다. 사실은 모든 장점이 이것에서 시작된다.
• NULL 값이 줄어든다.
  • 전체적으로 NULL 값의 사용이 줄어들게 된다.
• 복잡한 코드로 데이터 모델을 보완할 필요가 없다.
  • 데이터에 중복된 값이 적고, 그 부모가 누구인지가 항상 명시되어 있는 상황에서 데이터의 무결성을 지키기 위한 복잡한 코드를 사용할 필요가 없어진다. 데이터베이스 코드를 작성하는데 복잡한 변환 과정과 조인 질의, NULL 값 처리들이 필요하다는 것은 그 데이터베이스 설계가 문제가 있다는 말이기도 하다.
• 새로운 요구 사항의 발견 과정을 돕는다.
  • 실제 정규화 과정에서 많은 엔티티 혹은 속성들이 태어나게 된다. 또한 많은 결정 과정에서 업무 담당자와의 협의를 통해서 현재 뿐만 아니라 미래까지도 고려한 요구 사항의 발견 과정이기도 하다.
• 업무 규칙의 정밀한 포착을 보증한다.
  • 정규화 과정을 통하여 많은 복잡한 업무 규칙들이 체계화되고, 규칙의 Value화에도 도움을 주게 된다.
• 데이터 구조의 안정성을 최대화한다.
  • 중복된 값이 최소화되고 모든 정보들이 자기가 있어야 할 자리에 존재하게 되기 때문에 향후 발생하게 될 모델 변화에도 유연하게 대처할 수 있다.

가. 1차 정규화(1NF, First Normal Form)

• 정의
  • 모든 속성은 반드시 하나의 값을 가져야 한다. 즉, 반복 형태가 있어서는 안된다.
  • 각 속성의 모든 값은 동일한 형식이어야 한다.
  • 각 속성들은 유일한 이름을 가져야 한다.
  • 레코드들은 서로 간에 식별 가능해야 한다.
• 정규화 과정
  • 아래 그림과 같이 고객 엔티티의 계약일 속성의 값이 여러 건이 된다면 1차 정규형을 위배하는 것이 된다.
    
  • 어떤 속성이 다수의 값을 가지고 있다면 m:1 관계의 새로운 엔티티를 추가한다.
  • 관계형 모델에서는 관계(Relation) 정의상 한 속성이 하나의 값만을 가져야 한다. 그러므로 비정규형 관계는 엄밀히 말하면 관계로 간주할 수 없다.
  • 비정규형 관계가 관계로서의 모습을 갖추기 위해선 여러 개의 복합적인 의미를 가지고 있는 속성이 분해되어 하나의 의미만을 표현하는 속성들로 분해되어야 한다. 즉 속성수가 늘어나야 한다.
  • 비정규형 관계가 관계로서의 모습을 갖추기 위해선 하나의 속성이 하나의 값을 가질수 있어야 하며, 이 조건을 만족시키기 위해선 튜플이 늘어나야 한다. 또는 다른 관계로 분리되어야 한다.
  • 분석 또는 모델링 진행 과정에서 발생하며, 최종적인 모델링 완성 단계에서는 나올 수 없다. 그러나 분석(모델링) 초기 단계에는 상세히 분해된 속성보다는 위와 같은 레벨의 속성 추출이 복잡도를 줄일 수 있으므로 실전에서는 효율적이고 유리하게 이용될 수도 있다.

나. 2차 정규화(2NF, Second Normal Form)

• 정의
  • 식별자가 아닌 모든 속성들은 식별자 전체 속성에 완전 종속되어야 한다.
  • 이것을 물리 데이터 모델의 테이블로 말하면 기본키가 아닌 모든 컬럼들이 기본키에 종속적이어야 2차 정규형을 만족할 수 있다는 것이다.
• 정규화 작업
  • 아래 그림과 같이 식별자가 학번 + 코스 코드로 이루어진 학과 등록 엔티티에서 학번속성에 평가코드, 평가내역 속성들이 종속적이다. 그렇기 때문에 이것은 2차 정규형을 위반하고 있는 것이다.
  • 아래 그림과 같이 식별자가 학번 + 코스 코드로 이루어진 학과 등록 엔티티에서 코스 코드 속성에 코스명, 기간 속성들이 종속적이다. 그렇기 때문에 이 또한 2차 정규형을 위반하고 있는 것이다.
  • 의미상의 주어 즉, 본질 식별자를 알아야 식별자 부분 종속인지를 구분할 수 있다.
    
  • 속성의 의미가 명확하게 종속성을 비교할 수 있다.
  • 어떤 속성 식별자 전체에 종속되어 있지 않으면 잘못된 위치이며 새로운 엔티티 즉, 상위 부모 엔티티를 생성하고 UID BAR를 상속받게 된다.

다. 3차 정규화(3NF, Third Normal Form)

• 정의
  • 2차 정규형을 만족하고 식별자를 제외한 나머지 속성들 간의 종속이 존재하면 안된다. 이것이 3차 정규형을 만족하는 것이다.
    
• 정규화 작업
  • 위의 그림에서 학과등록 엔티티에서 평가코드, 평가내역 속성들이 서로 간에 종속적이다. 즉, 평가내역 속성은 평가코드 속성에 종속적이다. 그렇게 때문에 이것은 3차 정규형을 위반하고 있는 것이다.
  • 3차 정규형을 위반하고 있을 시에는 위의 그림에서의 평가항목 엔티티처럼 부모 엔티티가 생성되고 그 부모 엔티티로부터 UID Bar가 없는 관계를 상속받게 된다.

2.2 M:M 관계의 해소

M:M 관계는 블특정 관계로도 알려져 있으며, 데이터 구조에 있어서 어떠한 실제적 방법으로도 구현이 불가능하다. 이것이 이 관계를 해결하는데 충분한 이유이지만, 데이터 모델 구축 작업 초기에 그렇게 하는 데에는 또 다른 동기가 있다.

• M:M 릴레이션쉽은 새로운 릴레이션 엔티티를 추가하여 M:1 관계로 변경한다.
• 연관 관계(associative, relational) 엔티티는 M:M 관계 미결시 간관해 버렸을 추가 업무 규칙 또는 업무 논리를 내포할 수 있다. 특히 업무 규칙이 정밀하게 정의됨에 따라 하위유형(subtype) 계층 구조가 연관 실체로부터 나타나기 쉽다는 점, 분석 초기에 M:M 관계가 해결되지 않은 모델에서 이들이 간과된다는 점이다.
• M:M 관계는 데이터 종속성에 대한 결정을 어렵게 하여, 모델의 논리적 완성과 부분집합 식별 능력을 제한한다.
• M:M 관계 해결시까지 모델은 불안정 상태에 머물 것이다. 모델은 정규화되지 못하고, 모델에 대한 문서화 작업도 완비되지 못할 것이다.
  

2.3 엔티티의 재구성

정규화 작업을 하고, M:N 관계를 해소 작업을 거치게 되면, 새로운 엔터티들이 추가된다. 이런 엔터티들은 사안에 따라 다양한 방법으로 재구성되어야 한다. 동일한 속성을 가진 엔터티들을 하나로 통합하거나, 계층형 관계를 가진 엔터티들은 순환관계 모델로 통합하거나, 얼마간의 공통 속성과 별도의 개별 속성을 가지고 있는 엔터티들은 서브타입(Sub-Type) 형태로 모으며, 전혀 통합할 수 없으나 그들의 합집합과 다른 엔터티가 관계를 가지는 경우를 위한 아크(Arc) 관계등을 검토하여 재구성 하야 한다.

가. 역활의 통합

처음에 엔터티를 분류할 때는 서로 다른 개념으로 간주하여 독립적으로 모델링을 하였으나, 관련된 모든 속성들을 서로 비교했을때, 동일한 속성을 가진다면, 하나의 엔터티로 통합할수 있다.

나. 계층형 데이터 모델

큰 단위 밑에 여러개의 작은 단위로 구성되는 계층형 구조를 가지게 된다.
동일한 속성들을 가지고 있는 엔티티들을 하나의 엔티티로 통합한다. 그러나 구조변경시에 반드시 적절한 대안이 필요하며 이러한 경우는 다음에 설명될 순환관계를 활용해야 한다.

다. 순환관계(Recursive Relationship) 데이터 모델

하나의 엔티티가 다른 엔티티가 아닌 자기 자신과 관계를 맺는 관계를 순환 관계(Recursive Relationship)라고 한다. 이와 같은 순환 관계를 표현한 모델을 순환 구조 또는 순환 모델이라고 하며 아래 그림의 좌측에 표현된 조직 구조와 같은 계층 구조를 표현하는데 유용하다.

• 순환관계는 다음과 같은 특징을 가지고 있다.
  • 하나의 순환 엔티티는 각 엔티티의 모든 속성을 포함해야 한다.
  • 각 계층에 있는 속성은 동일하게 하는 것이 가장 좋다.
  • 순환 모델은 필수(직선) 관계로 취듭될 수 없고(무한 LOOP 발생), 반드시 선택사항 관계이다.
  • 순환 모델의 특징은 조직의 변경(추가/삭제)에 쉽게 대응할 수 있다는 것이다.

라. BOM(Bill Of Material) 데이터 모델

BOM 관계의 모델을 네트워크 구조(전철 노선이나 하이퍼링크를 갖는 웹 다큐먼트 같은)라 한다. 이러한 네트워크 구조를 제조업에서 아래 그림과 같이 부품의 소요량 파악 등의 모델에 유용하게 이용하게 되면서, M:M 순환 구조는 BOM(Bill Of Material)모델이라고 알려지게 되었다.

BOM 모델은 M:M 순환 관계라 하며, 상세 모델일 과정에서 새로운 관계 엔티티(Relation Entity, Intersection Entity)를 추가하여 두 개의 일대다(1:M) 관계로 구성된 모델로 구체화한다.

마. 서브타입 데이터 모델

모델링 작업을 진행하다 보면, 공통적으로 적용되는 속성들을 가지는 엔터티들이 있다.
이 속성들을 포함하는 상위개념의 엔터티를 생성하면 하나의 엔터티로 결합할 수 있다.
중복속성을 가진 여러개의 엔터티를 하나의 엔터티로 결합했을때, 그 구성 엔터티들을 서브타입(Sub-type)이라 한다.
수퍼타입(Super-type)이란 두개 이상의 서브타입을 가지는 엔터티를 말한다.

• 서브타입은 다음과 같은 특성을 가진다.
  • SUPER-TYPE의 모든 INSTANCE는 SUB-TYPE중 단 하나와 반드시 연결되어야 한다.
  • SUB-TYPE은 서로 중첩되지 않아야 하며, 그 전체집합은 SUPER-TYPE과 1:1 관계를 가져야 한다.
  • SUPER-TYPE과 SUB-TYPE은 결코 부모:자식 관계가 아니다.
  • SUB-TYPE은 자신의 ATTRIBUTE 나 독립적인 RELATIONSHIP을 가진다.
  • SUB-TYPE을 그릴때는 반드시 수퍼타입내에 위치시키며, 타엔터티와의 관계를 맺을 때, 특정 서브타입과 맺을 것인지 수퍼타입과 맺을 것인지를 확실히 해야 한다.

바. 아크(Mutually Exclusive)관계 데이터 모델

어떤 엔티티가 두개 이상의 다른 엔티티의 합집합과 릴레이션쉽을 가지는 것을 배타적(Exclusive) 관계 혹은 아크(Arc)관계라고 한다. 이러한 아크 관계는 동일한 관계가 서로 다른 하나 이상의 엔티티와 배타적으로 관계를 갖고 있을 때 이를 하나로 통합함으로써 발생하게 된다.

*이러한 관계의 특징은 다음과 같다.

• • 아크 내에 있는 릴레이션은 보통 동일하다.
  • 아크 내에 있는 릴레이션쉽은 항상 필수적이거나 선택사양이어야 한다.
  • 아크는 반드시 하나의 엔티티에만 속해야 한다. (하나의 아크가 여러 엔티티를 가질 수 없다.)
  • 어떤 엔티티는 다수의 아크를 가질 수 없다. 그러나 지정된 릴레이션쉽은 단 하나의 아크에만 사용되어야 한다.

사. 시계열 데이터 모델

데이터 이력을 관리하기 위해서 엔터티와 관계를 추가하는 경우가 있다. 이런 모델을 시계열 데이터 모델이라고 한다.

• 시계열 데이터 모델의 특징은 다음과 같다.
  • 프로젝트가 전산 시스템 개발이라면, 참가 사원은 이 프로젝트의 계획단계가 시작할때 투입되어 계획단계가 종료될때 투입 종료될 수 있다.
  • 그리고 이 사원은 분석단계에 참여하지 않고, 설계 단계에 재투입 될 수 있다.
  • 그렇다면, 종료일까지 식별자로 지정해야 할 것이다.
  • 업무요구 사항에 대한 분석결과에 따라서 식별자의 구성이 변경될 수도 있다.
  • 이와같이 복수의 값을 갖는 속성을 새로운 엔터티로 생성하여 관리하고자 할때 이용된다.
  • 또한 M:1 관계에서 이력을 남기고자 한다면 M:N관계를 해소하는 교차엔터티를 생성하여 해결한다.

아. 복잡한 데이터 모델

• 이 모델링 과정에서 한가지 공통적인 특징은 생성된 중간 엔터티 3개는 모두 이력관리를 위해서라는 것이다.
• 즉, 이 교차 엔터티들의 일반속성과 식별자만 통일해 준다면 3개의 엔터티를 생성할 필요없이 단하나의 엔터티를 추가하여 해결할 수 있다.
• 이렇게 생성된 엔터티 쪽의 관계의 선택 사양은 항상 필수(Mandatory) 관계로 정의되어져야 한다.
• 내용을 분석하여 Relationship 과 Attribute 결정한다.

3. 데이터베이스 설계

3.1 엔티티를 테이블로

• 일반적으로 TABLE 명칭과 ENTITY 명칭은 같게 하는 것이 좋다.
• 필요에 따라 ENTITY 명칭은 한글로하고 동의어를 영문으로 표시 (가능한 TABLE 명칭과 같게)
• SUPER-TYPE 이나 SUB-TYPE은 나중에 결정

3.2 속성을 컬럼으로

• 컬럼의 명칭은 속성의 명칭과 반드시 일치할 필요는 없으나 프로그래머와 사용자의 혼동을 피하기 위해 가능한 표준화된 약어를 사용한다.
• SQL의 예약어(reserved word)의 사용을 피한다.
• 가능한 컬럼 명칭은 짧은 것이 좋으며 짧은 명칭은 SQL 해독시간을 감소시킨다.
• 필수입력 속성은 Nulls/Unique 란에 NN을 표시한다.
• 견본 데이터를 입력시킨다.

3.3 식별자를 기본키로

• 1 단계
  • 키형태란에 ENTITY의 UID에 속하는 모든 속성들에 PK를 표시
  • PK로 표시된 모든 컬럼들은 Nulls/Unique 란에 반드시 NN,U 로 표시 되어야 한다.
  • 여러개의 컬럼으로 UID가 구성되어 있는 경우는 각각의 컬럼에 NN,U1을 표시
  • 또 다른 Unique Key가 있다면 NN,U2로 표시
    

• 2 단계
  • 테이블에 외부키 컬럼을 포함시킨다.
  • PK의 일부분으로 표시
  • Nulls/Unique 란에 각각 NN,U1을 표시
  • 키형태란에 PK,FK를 표시
  • 여러 컬럼으로 구성된 경우 PK,FK1을 각각에 표시
  • 추가된 FK 컬럼에 표본 데이터를 추가
    

3.4 관계를 외부키로

가. M:1 관계

• 반드시 1(one) 에 있는 PK를 M(many) 의 FK로 지정해야 한다.
  • FK 의 명칭을 결정하고
  • 키형태란에 FK 표시한다.
  • Nulls/Unique 란에 NN 표시(must be 관계시) 한다.
• 추가한 컬럼의 견본 데이터 작성한다.
  

나. 1:1 관계

어느 한쪽이 필수, 또는 모두가 선택으로 지정된 경우에 따라 참조하는 방법이 달라진다.

• Mandatoy
  • Mandatory 반대쪽에 있는 테이블의 PK를 Mandatory 쪽 테이블의 FK로 하며, NN 표시한다.
    

• Optional
  • 어느 한쪽의 PK를 다른 쪽의 FK로
  • 보다 빈번하게 사용되는 테이블이 FK를 가지는 것이 유리하며, FK에 U 표시한다.
    

다. 순환관계

• M:1 순환관계
  • 해당 테이블 내에 FK 컬럼 추가
  • 이 FK 는 같은 테이블 내의 다른 로우의 PK 컬럼을 참조하게 된다.
  • FK 컬럼명칭은 가능한 관계명칭을 반영
  • 이FK는 결코 NN 이 될 수 없다.
    

• 1:1 순환관계
  • 해당 테이블 내에 UNIQUE 한 FK 컬럼 추가
  • 이 FK 는 같은 테이블 내의 다른 로우의 PK 컬럼을 참조하게 된다.
  • FK 컬럼명칭은 가능한 관계명칭을 반영
  • 이 FK는 결코 NN 이 될 수 없다.

3.5 아크(Arc) 관계의 처리

아크 관계로 지정된 관계를 외부키로 전환하는 방법은 크게 두가지가 있다.

위의 은행계좌 테이블이 개인, 단체, 법인 에서 참조하는 외부키를 지정하는 방법은 아래와 같다.

1. 외부키 분리

• 각각의 컬럼을 별도로 분리하는 방법으로, 각각의 외부키는 별도의 컬럼으로 지정되며,어느 한 컬럼에 값이 입력될 때,
  다른 외부키는 항상 NULL값을 가진다.
  
  • 데이터모델을 살펴보면 아크 관계에 연결된 부분은 틀림없이 필수이다.
  • 그러나 위의 표를 보면, NULLs/Unique 란에는 NN을 표시하지 않았다.
  • 그것은 세개의 외부키 중 어느 하나는 항상 존재하지만 각각의 외부키는 반드시 NULL값을 가질 수 있기 때문이다.
  • 이 방법은 대개의 경우, 인덱스의 수를 중가시키게 되며, 조인을 할때도 불리하다.
  • 각각의 사항에 독립적으로 엑세스가 수행되는 경우에 사용하는 것이 좋으며,
  • 특별한 경우가 아니라면 사용하지 않는 것이 바람직하다.

2. 외부키 통합

• 각각의 컬럼을 별도로 분리하는 방법으로, 각각의 외부키는 별도의 컬럼으로 지정되며,어느 한 컬럼에 값이 입력될 때,
  다른 외부키는 항상 NULL값을 가진다.
  
  • 데이터모델을 살펴보면 아크 관계에 연결된 부분은 틀림없이 필수이다.
  • 그러나 위의 표를 보면, NULLs/Unique 란에는 NN을 표시하지 않았다.
  • 그것은 세개의 외부키 중 어느 하나는 항상 존재하지만 각각의 외부키는 반드시 NULL값을 가질 수 있기 때문이다.
  • 이 방법은 대개의 경우, 인덱스의 수를 중가시키게 되며, 조인을 할때도 불리하다.
  • 각각의 사항에 독립적으로 엑세스가 수행되는 경우에 사용하는 것이 좋으며,
  • 특별한 경우가 아니라면 사용하지 않는 것이 바람직하다.

3.6 서브타입의 처리

서브타입 데이터 모델은 그야말로 관련된 엔터티를 논리적인 잡합관계로 묶어놓은 것이다.
이러한 논리적 집합은 상황에 따라 여러 형태의 테이블로 전환하게 된다. 사용의 용이성뿐만 아니라 수행속도에 미치는 영향은 엄청난 차이를 가져오므로 신중하게 판단한다.

서브타입을 적절한 형태의 테이블로 전환하기 위한 서브타입 모델은 다음과 같다.

서브타입으로 지정된 모델을 테이블로 전환하는 방법에는 세가지가 있다.

가. 하나의 테이블로 통합

• SUB-TYPE을 SUPER-TYPE 에 통합하여 하나의 테이블로 만든다.
• 이 통합된 테이블에는 모든 SUB-TYPE의 데이터를 포함해야 한다.
• 주로 SUB-TYPE에 적은 량의 속성이나 관계를 가진 경우에 적용된다.

전환절차

1. SUPER-TYPE으로 테이블 명칭 부여
2. SUB-TYPE을 구분할 수 있도록 컬럼 추가
3. SUPER-TYPE의 속성을 컬럼명으로
4. SUB-TYPE의 속성을 컬럼명으로
5. SUPER-TYPE의 관계를 FK로
6. SUB-TYPE의 관계를 FK로
   

• 장점
  • 데이터 엑세스가 보다 간편
  • VIEW를 활용하여 각 SUB-TYPE 만을 엑세스하거나 수정 가능
  • 수행속도가 좋아지는 경우가 많다
  • SUB-TYPE 구분없는 임의 집합의 가공이 용이
  • 다수의 SUB-TYPE을 통합한 경우 조인(JOIN) 감소효과가 크다.
  • 복잡한 처리를 하나의 SQL로 통합하기가 용이

• 단점
  • 특정 SUB-TYPE의 NOT NULL 제한 불가
  • 테이블의 컬럼수가 증가
  • 테이블의 블럭수가 증가
  • 처리시 마다 SUB-TYPE의 구분(TYPE) 이 필요해 지는 경우가 많다.
  • 인덱스(INDEX) 크기가 증가

나. 서브 타입별로 분리

• 각각의 SUB-TYPE 마다 하나의 테이블로 만든다.
• 분할된 테이블에는 해당 SUB-TYPE의 데이터만 포함해야 한다.
• 주로 SUB-TYPE에 많은 량의 속성이나 관계를 가진 경우에 적용된다.
  전환절차

1. SUB-TYPE마다 테이블 명칭 부여
2. SUB-TYPE의 속성을 컬럼명으로
3. 테이블마다 SUPER-TYPE의 속성을 컬럼으로
4. SUB-TYPE마다 해당되는 관계들을 FK로
5. 테이블마다 SUPER-TYPE의 관계를 FK로
   

• 장점
  • 각 SUB-TYPE 속성들의 선택사양 명확
  • 처리시마다 SUB-TYPE 유형구분이 불필요
  • 전체 테이블 스캔시 유리
  • 단위 테이블의 크기가 감소

• 단점
  • 전체적인, 혹은 SUB-TYPE 구분없이 데이터를 처리하는 경우 UNION 이 발생
  • 처리속도가 감소하는 경우가 많다.
  • 트랜젝션 처리시 여러 테이블을 처리하는 경우가 빈번해 진다.
  • 복잡한 처리의 SQL 통합이 어려워 진다.
  • 부분범위 처리가 불가능해 질 수 있다.
  • 여러 테이블을 합친 VIEW는 조회만 가능하다.
  • UID 유지관리가 어렵다.

다. 아크 관게로 분리

• SUPER-TYPE 과 SUB-TYPE 을 각각 테이블로 전환시키는 방법
• SUPER-TYPE 과 SUB-TYPE 테이블간에는 아크(ARC) 관계를 가지며,

• 다음의 여러 가지 경우를 만족할 때 사용
  • 전체 테이터 처리가 빈번하거나
  • SUB-TYPE의 처리는 주로 독립적으로 발생하고
  • 테이블을 통합했을 때 컬럼의 수가 너무 많아지는 경우
  • SUB-TYPE의 컬럼 수가 많은 경우
  • 트랜잭션이 주로 공통부분(super-type)에서 발생하며
  • SUPER-TYPE 의 처리범위가 넓고 빈번하여 단일 테이블 클러스터링을 해야 할 때

전환절차

1. 각각의 엔터티 명칭을 기준으로 테이블 명칭 부여
2. 기본키 지정 (이러한 사항은 항상 수퍼 타입에 존재하고 있으며, 모든 테이블의 기본키는 동일하다.)
3. 각각의 엔터티 내에 있는 속성을 컬럼으로 지정
4. 수퍼타입에 연결된 관계를 각 테이블에 동일하게 외부키로 지정
5. 해당 서브타입에만 연결된 관계들에서 추가적인 외부키를 지정
6. 사례표에 견본 데이터를 작성

3.7 테이블 정규화 작업

• 제 1 정규화
  • 테이블은 반드시 무순서
  • 2차원 형식의 집합
  • 반복되는 그룹을 가질 수 없다

• 제 2 정규화
  • 반드시 제1정규형을 만족할 것
  • 키가 아닌 모든 컬럼은 PK에 종속적이어야 한다

• 제 3 정규화
  • 반드시 제2정규형을 만족할 것
  • 키가아닌 모든 컬럼은 다른 키가아닌 컬럼에 독립적이어야 한다

• 정규화 이유?
  • 정규화는 데이터의 중복을 최소화
  • 데이터의 중복은 데이터의 일관성을 해친다
  • 트랜젝션이 여러 테이블을 불필요하게 처리한다
  • 정규화 작업은 ENTITY 나 RELATIONSHIP, 테이블의 누락을 방지하는데 도움을 준다

3.8 추가적인 작업

• 참조 무결성의 CONSTRAINT 정의
• 인덱스(INDEX) 설계
• 클러스터링(CLUSTERING) 설계
• 해쉬 클러스터(HASH CLUSTER) 설계
• 뷰(VIEW) 설계
• 데이터베이스 설계의 반 정규화(denormalize)
• 저장공간 사용량 계획