DAsP - 데이터 모델링 이해 [데이터 모델링 기법 이해]

데이터 모델링 기법 이해

 

1.   데이터 모델 목적

-       데이터 모델은 데이터베이스 설계에 대한 계획 또는 청사진이다.

-       설계자와 개발자, 사용자 등 모든 관련자들은 데이터 모델을 통해 구축될 시스템의 데이터 구조에 대한 형상을 이해하고, 요구사항의 구현과 변경 등에 대해 원활한 의사소통을 도모하게 된다.

-       설계 단계에서 조기에 오류들이 발견되고 정정되도록 원활한 의사소통이 필요하게 되고, 이러한 목적을 달성하는 데 데이터 모델은 최적의 수단으로 활용될 수 있다.

 

2.   개체-관계 모델 기법(Entity-Relationship Modeling)

-       개체-관계 모델은 1976년 피터 첸(Peter Chen)에 의해서 최초로 제안되었으며, 그의 논문을 통해 이 모델의 기본적인 구성 요소가 정립되었다.

-       이 모델이 지니고 있는 단순성 때문에 현재 개념/논리 데이터 모델링에서 가장 일반적으로 사용되고 있다.

-       이 모델에 서브타입이 추가되면서 확정된 개체-관계 모델(Extended Entity-Relationship Model)이 만들어졌으며, 이제 일반적으로 개체-관계 모델이라고 하면 이 확장된 개체-관계 모델을 의미한다.

 

개체-관계 모델은 다음과 같은 목적으로 사용되고 있다.

n  데이터에 대해 관리자, 사용자 개발자들이 서로 다르게 인식하고 있는 뷰들을 하나로 통합할 수 있는 단일화된 설계안을 만들 수 있다.

n  서로 다른 뷰를 충족시킬 수 있는 데이터 처리와 제약 조건 등의 요구사항을 정의하기 위해서이다.

-       개체-관계 모델은 개체-관계 다이어그램(ERD, Entity Relationship Diagram)으로 표현된다.

 

3.   개체-관계 모델 구성 요소

-       개체-관계 데이터 모델링은 일반적으로 개발 방법론에 의하여 논리 모델링(논리 데이터 모델링)과 물리 모델링(물리 데이터 모델링)으로 나눌 수 있을 것이다.

-       논리 데이터 모델이란 각 기업에서 업무를 수행하기 위해 필요한 개체(엔티티)가 무엇이며, 개체의 유일성을 보장해주는 식별자(Unique identifier)가 무엇이며, 각 엔티티 간에는 어떤 상관관계가 있고 필요한 속성이 무엇인지를 설명해주는 그림이다.

-       즉, 업무 담당자와 IT 시스템 설계자 사이의 의사소통이라 할 수 있다.

-       외래키, 기본키, 액세스 성능, 분산 시스템 등의 물리적 시스템 환경은 고려하지 않는다.

-       논리적 모델의 특징은 초기에 엔티티와 엔티티의 관계에서 M:M관계, 순환 관계(Recursive), 슈퍼/서브 타입(Super/Sub Type), 배타적(Arc) 관계 등을 갖고 있는 개체(엔티티)가 많이 보인다는 점이다.

-       물리 데이터 모델링은 논리 데이터 모델링을 기초로 현재의 시스템 환경(네트워크, 하드웨어, 운영체제, 미들웨어, 데이터베이스, 디스크 용량, 분산 등)을 고려하여 최고의 성능 향상을 목적으로 한다.

 

논리 데이터 모델링에서 물리 데이터 모델링 단계로 넘어오면서 고려해야 하는 작업

n  Super/Sub 관계의 엔티티를 몇 개의 테이블로 만들 것인가?

n  배타적(Arc) 관계 엔티티의 외부키(Foreign Key)를 몇 개로 할 것인가?

n  성능 향상을 위해 테이블을 추가해야 할 것인가 혹은 통합해야 할 것인가?

n  통계 작업을 위해 합계(Summary) 테이블 같은 임시성 테이블을 몇 개로 할 것이며, 유일키를 무엇으로 할 것인가?

n  테이블의 칼럼을 다른 테이블에 중복할 것인가, 중복한다면 어떤 애플리케이션이 관련되어 있는가, 인덱스의 설정, 스냅샷(Snapshot) 또는 뷰(View) 등의 객체가 필요한가?

n  분산 환경에서 테이블을 중복할 것인가, 중앙에 필요한 테이블을 따로 가져갈 것인가?

n  데이터가 분산 환경에서 이동 시 문제를 어떻게 해결할 것인가?

 

가.  엔티티(Entity)

- 엔티티는 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서, 그 대상들 간에 동질성을 지닌 것으로 볼 수 있는 개체 집합이나 그들이 행하는 행위의 집합으로 정의할 수 있다.

- 엔티티는 동질성을 갖는 개별 개체나 행위를 지칭하며, 달리 엔티티 인스턴스(Entity Instance)라고도 한다. 그리고 이들의 집합을 엔티티 타입(Entity Type)이라고 부른다.

 

나.  속성(Attribute)

- 속성은 엔티티에 저장되는 개체 집합의 특성을 설명하는 항목이라고 할 수 있다.

- 개체-관계 다이어그램에서 속성은 개체 집합을 나타내는 직사각형에 실선으로 연결된 타원형으로 표현되며, 각 타원형은 고유의 속성 이름을 갖는다.

- 또한 각 속성은 가질 수 있는 값의 범위가 있는데, 이를 그 속성의 도메인(Domain)이라 한다.

- 개체 집합 내에서 각각의 개체를 식별할 수 있도록 하나 또는 그 이상의 속성들로 이루어진 속성 집합을 식별자(Unique Identifier)라고 하는데, 이 속성들이 개체 집합 내의 각 개체를 유일하게 지정한다.

- 복합 속성(Composite Attribute): 여러 세부 속성들로 구성된 속성

- 단순 속성(Simple Attribute): 더 이상 다른 속성들로 구성될 수 없는 단순한 속성

- 속성은 관리 목적이나 상세화 정도에 따라서 단일 값(Single Value) 또는 다중 값(Multi Value)을 가질 수 있다.

 

다.  식별자

- 엔티이의 각 개체들은 인스턴스라고 하는데, 인스턴스는 그들을 지칭하거나 식별해 주는 속성인 식별자(Unique Identifier)를 가지고 있다.

- 식별자는 하나 또는 그 이상의 속성으로 구성된다. 특히 두 개나 그 이상의 속성으로 이루어진 식별자를 복합 식별자(Composite Identifier)라 부른다

- 즉, 식별자는 논리적인 관점에서 사용되고 키(Key)는 물리적인 관점에서 사용된다.

 

라.  관계(Relationship)

- 관계는 엔티티와 엔티티 간 연관성을 표현하는 것으로, 엔티티의 정의에 따라 영향을 받기도 하고, 속성 정의 및 관계 정의에 따라서도 다양하게 변할 수 있다.

 

마.  카디날리티(Cardinality)

- 개체-관계 다이어그램은 데이터베이스가 지켜야 할 제약 조건들을 명시할 수 있다. 중요한 제약조건 중의 하나로 연결(Connectivity)이라는 것이 있는데, 이는한 개체가 관계를 통하여 다른 개체와 관련된 개체들의 수를 나타낸다.

- 카디날리티(Cardinality)란 관계에 참여하는 하나의 개체에 대해 다른 엔티티에서 몇 개의 개체가 참여하는지를 나타낸다.

 

바.  존재 종속

- 만약 한 엔티티의 존재가 다른 엔티티(들)의 존재에 영향을 받는다면 이를 존재 종속(Existence-Dependent)이라 한다.

 

사.  서브타입

- 확장된 개체-관계 다이어그램은 서브타입의 개념을 도입했다.

- 서브타입은 정확한 의미로는 서브타입 엔티티이며, 그것의 전체 집합인 슈퍼타입(Super Type)의 부분 집합이다.

- 어떤 서브타입이 적합한지를 결정해 주는 속성을 구분자(Discriminator)라고 부른다.

- 서브타입은 배타적(Exclusive) 또는 포괄적(Inclusive)일 수 있다.

- 배타적이라면 슈퍼타입은 많아야 1개의 서브타입과 관련될 수 있다.

- 포괄적이라면 슈퍼타입은 1개 또는 그 이상의 서브타입과 관련될 수 있다.

 

4.   객체지향 모델링(Object-Oriented Modeling)

-       객체지향 개발은 전체 시스템 개발 영역을 다루고 있다.

n  객체지향 방법론

n  객체지향 분석

n  객체지향 설계

n  객체지향 모델링

n  객체지향 프로그래밍

n  객체지향 DBMS

 

가.  객체지향 개념

- 객체지향 모델링은 객체지향 개발의 기본이다. 조직이나 시스템은 객체(Object)라는 것에 관련되어 있고 객체에 대한 정보를 저장한다. 객체는 대개 객체를 기술하는 데이터와 그 기술 데이터를 운영하는 메소드(Method)로 구성된다. 속성 유형과 메소드를 공유하는 객체가 그룹화 되어서 객체 클래스(또는 클래스)로 된다. 객체 인스턴스는 객체 클래스의 어커런스이다.

- 객체는 속성과 메소드로 구성된다. 속성은 객체 클래스의 성질이다. 속성 값이 바로 객체 인스턴스의 성질인 것이다. 메소드는 하나 이상의 속성을 접근, 조작, 수정, 삭제, 생성하는 프로세스이다.

- 객체는 연관(Association) 또는 상속(Inheritance)을 통해 다른 객체들에 연결된다. 연관은 객체 간의 자연적 관계이다. 비즈니스를 모델링할 때 그 연관은 비즈니스 관계이다. 연관은 카디날리티와 모달러티(선택적 그리고 의무적)를 가질 수 있고, 연관은 하나, 둘, 셋 이상 객체들 간에 존재할 수 있다(즉, 일항, 이항 그리고 다항).

- 한 객체는 다른 객체의 성질을 상속할 수 있다. 가장 위에 가장 일반적인 객체(상위 클래스)를 가지고 제일 아래에 좀 더 구체적인 객체(하위 클래스)를 가진 계층(Hierarchy) 조직을 생각해 보면 하위 클래스는 상위 클래스로부터 속성과 메소드를 상속한다.

- 객체들이 한 객체 내부에 일어나는 것은 그 객체 외부에서 일어나는 것과는 관계가 없다는 것과 같은 구체적 경계(Boundary)를 가지고 있다. 이것을 일명 캡슐화(Encapsulation)라고 한다.

- 객체 안의 속성이 속성 자신의 구조를 가질 수 있다면 그 객체는 자기 자신의 논리적 데이터 모델을 가질 수 있다.

- 대부분의 객체 메소드는 메소드를 기술하는 서술(Narrative)에 의해서 표현될 수 있다. 그러나 메소드가 복잡하다면, 데이터 흐름 다이어그램(DFD, Data Flow, Diagram)과 같은 다양한 프로세스 모델링 기법 중의 하나가 사용될 수 있다.

- 메시지는 메시지 이동의 방향을 나타내는 화살표와 점선에 의해 객체 모형에 표현된다.

 

나.  객체 모형

- 객체 모형을 생성시키기 위해서 아래와 같은 방법을 취한다.

1) 주제에 연관된 기본(Basic) 객체를 식별한다. 그 결과는 엔티티 목록과 같은 것이다.

2) 객체 간의 연관(Association)을 식별한다.

3) 많이 알려져 있는 객체 모델링의 규약을 이용해서 객체의 다이어그램을 그린다.

4) 객체 간의 메시지는 다이어그램에 추가될 수 있다.

- 객체 모형이 완료 되었을 때 각 객체 내부에 대해서 표시하면 된다. 즉, 객체의 속성과 메소드가 문서화될 필요가 있다.

 

다.  객체 모형 데이터

- 객체 내의 데이터를 문서화하는 것은 상대적으로 간단하다. 그 이유는 객체 sop서 발견된 속성들은 그 객체의 성질이거나 메시지 안에 전달된 다른 객체의 성질이기 때문이다.

- 대부분의 경우 한 객체 안의 데이터는 구조를 가지지 않는다. 구조상 데이터가 개체-관계 다이어그램에 있다면, 다양한 엔티티 내에 있을 수 있다는 것을 뜻한다. 즉, 데이터 구조가 없는 객체는 모든 객체의 속성이 개체-관계 다이어그램에서 하나의 엔티티 내에 있다는 것을 의미한다. 데이터 구조가 없을 때 객체의 데이터를 문서화하는 것은 객체의 정의와 도메인을 구체화시키는 것으로 제한된다. 그러나 객체의 데이터가 구조를 가진다면 그 구조는 개체-관계 다이어그램의 단편도(Fragment Diagram) 안에 모형화되어야 한다.

라.  객체 모형의 메소드

- 객체 메소드가 복잡하지 않다면 메소드는 간단한 설명부(Narrative) 또는 구조화된 기법으로 가장 잘 문서화된다.

- 복잡한 메소드는 좀 더 정교한 문서화 접근 방식이 필요하다.

- 이벤트 지향적인 프로세스는 상태 전이 모델링(State Transition Modeling)과 같은 동적(Dynamic) 프로세스 모델링 기법이 필요하다. 반면에 정적인 프로세스는 데이터 흐름 다이어그램이나 기능 분해(Functional Decomposition)와 같은 기법을 사용한다.

 

마.  불명료한 객체 접근 방식

- 첫 번째는 객체지향 개발의 가장 단순화된 표현이다. 이것은 객체지향 개발을 분명하게 이해하는 데 필요한 많은 객체지향 특징을 무시하는 것이다.

- 두 번째는 객체지향 모델링의 미성숙이다.

 

바.  객체지향 모델링과 논리 데이터 모델링 간의 관계

- 객체지향 모델링과 논리 데이터 모델링은 공통점이 많다. 객체지향 모델링 개념은 논리 데이터 모델링의 개념과 매우 유사하다. 그러나 많은 유사점에도 불구하고 차이점 또한 존재한다.

- 객체지향 모델링에서만 유일한 것은 데이터와 프로세스를 같은 엔티티로 결합시킨 것이다.

객체지향 모델링	논리 데이터 모델링	차이점
객체	엔티티	객체는 프로세스를 포함한다.
속성	속성	-
연결 (Link)	관계 (Relationship)	유사하다. • 연관은 동일하다. • 상속은 데이터 모델링이 메소드를 포함하지 않는다는 것만 제외한다면 서브타입/슈퍼타입과 동일하다.
캡슐화	-	대응하는 논리적 데이터 모델링의 개념은 없다
객체 클래스	엔티티 유형	없음
객체 인스턴스	엔티티 인스턴스	없음
메시지	-	메시지는 프로세스와 연관되어 있기 때문에 대응하는 개념은 없다.

 

사.  객체지향 모델링 장점

- 객체지향 모델링의 장점은 재사용 코드와 같은 개념이 실제로 가능한 환경을 제공한다는 것이다.

- 객체지향 모델링은 모든 비즈니스 규칙이 표현될 수 있는 유일한 환경을 제공한다.

- 객체지향 모델링은 또한 프로세스와 데이터 모델링을 함께 운영한다. 데이터와 프로세스가 객체의 성질인 반면 데이터와 프로세스 각각은 그들의 풍부함(Richness)을 달성하는 다른 접근 방식을 필요로 한다는 사실이 확신하게 한다.