Powerful PowerDesigner

관계(Relationship)란 ?


 관계도 집합이다

 릴레이션십(Relationship)이란 엔터티와 엔터티 사이의 관계를 말한다. 즉, 우리가 관리하고자 하는 업무 영역 내의 특정한 두 개의 엔터티 사이에 존재하는 많은 관계 중 특별히 우리가 관리하고자 하는 직접적인 관계를 의미한다.
 관계는 두 엔터티 사이에 그 목적과 내용이 다른 여러 개의 관계가 동시에 존재할 수 있다. 마치 교통량이 너무 많거나 좀더 나은 이동을 위해 특수 목적을 가진 더 세분화된 교량을 추가할 수도 있고, 작은 교량을 없애고 커다란 교량으로 통합할 수도 있듯이 관계 또한 크게 묶을 수도 있고, 구체적으로 분할시킬 수도 있다.

 직접 관계를 관계라고 한다

데이터 모델링에서의 데이터 집합(엔터티) 간에는 무수한 관계가 존재한다. 하지만 이러한 모든 관계를 표현(설계)하는 것은 아니다. 많은 관계 중에서 직접 종속인 것만을 관계로 보고 모델링하는 것이다.

 두 엔터티 간에는 하나 이상의 관계가 존재할 수 있다

두 개의 엔터티 사이에는 서로 다른 업무 규칙을 가진 별개의 관계가 존재 할 수 있다.
보험계약과 고객과의 관계는  계약자 관계는 1:M이지만 피보험자 관계는 M:M이 될 수 있다. 물론 명의변경을 할 수도 있고 그 이력까지 관리하겠다고 한다면, 계약자 관계도 다시 M:M이 된다. 보험 종류에 따라 하나의 보험계약에 여러 명의 고객이 피보험자가 될 수 있으며, 고객 또한 하나 이상의 보험계약에 피보험자가 될 수 있으므로 이 관계는 당연히 M:M 릴레이션십을 가진다

 외래키로 정의

관계는 외래키(FK, Foreign Key)로 구현되어 참조무결성(RI, Referential Integrity)으로 데이터 정합성 유지의 역할을 하게 된다.

참조무결성 : 제3장-제3절-4항 참조무결성 규칙 정의 참조

 관계의 관점

• 항상 두 엔터티 간에 존재한다.
• 항상 두개의 관점을 가지고 있다.
• 데이터의 양방향 업무 규칙(Business Rule)을 표현
• 관계를 통하여 정보로서의 활용가치 상승
• 외래키로 구현되어 참조무결성으로 데이터의 정합성 유지
• 참조무결성

 출처 : DB 포탈 사이트 DBguide.net

개념 데이터 모델 정의

개념적 데이터 모델이란 건물로 말하면 철제빔으로 건물의 골격을 세워 놓은 형태와 유사하다. 건 물의 골격이 주요 골조 자재로 구성되어 있듯이 개념 데이터 모델도 주요 핵심 엔터티들로 구성된다. 핵심 엔터티란 행위의 주체나 목적물이 되는 개체 집합에 해당하는 엔터티를 의미한다. 이들은 부모가 존재하지 않는 창조된 집합이어서 다른 집합의 존재 유무에 상관없이 독립적으로 탄생할 수 있다. 핵심 엔터티는 대체적으로 여러 가지 하위의 행위 엔터티를 탄생시킨다.

개념 데이터 모델 의의

개념 데이터 모델은 단지 대상을 주요 핵심 엔터티로 한정한다는 것일 뿐이지 모델링 기법은 논리적 모델링과 특별히 다를 것이 없다. 만약 우리가 하향식으로 데이터아키텍처를 수립해 간다면 개념적 모델은 개괄적 모델을 좀더 상세화된 형태로 진화시키거나 중요 엔터티만 선정하여 모델링을 함으로써 탄생된다. 물론 이후에도 모델링의 상세화는 계속되어 갈 것이며, 필연적으로 개념적 모델도 따라서 약간씩 변화가 일어날 수 밖에 없다. 하지만, 개념 데이터 모델은 앞으로 아무리 상세한 모델링이 진행되더라도 전체적인 골격은 개념적 모델을 벗어나지 않는다는 것이다.

데이터아키텍처 프레임워크 상에서 개념 데이터 모델

엔터프라이즈아키텍처에서 개념 레이어는 최상위의 개괄 레이어와 하위의 논리 레이어 중간에 존재하는 레이어이다. 데이터아키텍처에서는 개괄 데이터 모델과 논리 데이터 모델 사이에 존재하는 모델이라고 할 수 있다. 여기에서 개괄 데이터 모델는 흔히 사용되어지는 주제영역 관계도와도 대응되는 부분이라고 할 수 있다. 개념 데이터 모델은 상위의 주제영역별로 핵심 엔터티와 핵심 속성, 또한 핵심 엔터티들 사이의 관계들로 이루어진 데이터 모델이라고 할 수 있다. 아키텍처의 개념을 종종 건축물에 비유하곤 한다. 개념 데이터 모델을 건축물에 비유해 보면 건물의 기둥들과 중요 벽체들로만 만들어진 건물 설계 도면에 비유할 수 있다. 이 단계에서 정의된 핵심 엔터티들과 관계들을 기반으로 논리 데이터 모델에서는 업무 요구사항에 기반한 세부 데이터 모델이 생성되게 된다.

출처 : DB 포탈 사이트 DBguide.net

서브타입

확장된 개체-관계 다이어그램은 서브타입의 개념을 도입했다. 서브타입은 정확한 의미로는 서브 타입 엔터티이며 그것의 전체집합인 슈퍼타입(Supertype)의 부분집합이다. 예를 들어 학생들은 학 부학생이나 대학원생으로 분류될 수 있다. 이 경우 학생이 슈퍼타입이고 학부학생과 대학원생은 서브타입이다.

[그림 3]은 바커 표기법에 따른 서브타입 표현으로, 슈퍼타입인 사원은 서브타입인 내근사 원, 설계사, 대리점을 가지고 있다. 슈퍼타입은 세 서브타입에 공통적인 모든 속성을 포함하고 있고 서브타입은 각 서브타입에 적절한 속성만을 포함하고 있다.

                                                                           [그림 4]

[그림 3]에서 속성‘사원구분’은 내근사원, 설계사, 대리점인지를 가리킨다. 어떤 서브타입 이 적합한지를 결정해 주는 속성을 구분자(Discriminator)라고 부른다. IE 표기법을 사용하는 툴을 사용하면 [그림 5]와 같이 구분자는 서브타입 부호 바로 옆에 나타난다. 모든 슈퍼타입이 구분 자를 가지고 있는 것은 아니다. 만일 구분자가 없다면 적합한 서브타입을 생성하기 위해 응용 코드가 작성되어야 한다. 서브타입은 배타적(Exclusive) 또는 포괄적(Inclusive)일 수 있다. 만약 배타적이 라면 슈퍼타입은 많아야 1개의 서브타입과 관련될 수 있다. 만약 포괄적이라면 슈퍼타입은 1개 또는 그 이상의 서브타입과 관련될 수 있다. [그림 5]는 서브타입 MANAGER와 DB_ADMIN을 가진EMPLOYEE 슈퍼타입을 보여주고 있다. 돔 안의 X는 서브타입이 배타적인 것을 의미한다. 따라서 사원은 MANAGER나 DB_ADMIN 중 하나가 될 수 는 있으나 둘 다 될 수는 없다. [그림 6] 은 이러한 동일한 서브타입을 포괄적으로 보여주고 있다. 여기서 사원은 MANAGER, DB_ADMIN, 또는 양쪽 모두 될 수도 있다. 슈퍼타입은 두 개 이상의 서브타입과 관련되므로, 포괄적 서브타입은 구분자를 가지고 있지 않다.

                                                             [그림 6]

출처 : DB 포탈 사이트 DBguide.net

카디날리티(Cardinality)

개체-관계 다이어그램은 데이터베이스가 지켜야 할 제약 조건들을 명시할 수 있다. 중요한 제약 조건 중의 하나로 연결(Connectivity)이라는 것이 있는데, 이는 한 개체가 관계를 통하여 다른 개체 와 관련된 개체들의 수를 나타낸다. 관계의 연결은 1:1, 1:M, M:M으로 분류된다. 개체-관계 다이어 그램에서는 관계의 연결을 1, M 을 사용하여 표현하며 [그림1]의 예와 같다. 표기법에 따라서 는 M:M을 M:N으로 표현하기도 하나 여기서는 M:M으로 나타내기로 한다.

                                                                      [그림 1]

• 일대일(One To One, 1:1) : X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속하는 한 개체도 X 에 속하는 한 개체에만 연결된다.
• 일대다(One To Many, 1:M) : X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속 하는 한 개체는 X에 속하는 여러 개체들과 연결된다.
• 다대다(Many To Many, M:M) : X에 속하는 한 개체는 Y에 속하는 여러 개체들과 연결될 수 있 으며, Y에 속하는 한 개체도 X에 속하는 여러 개체들과 연결될 수 있다.

또한 카디날리티(Cardinality)란 관계에 참여하는 하나의 개체에 대해 다른 엔터티에서 몇 개의 개체가 참여하는지를 나타낸다. 예를 들면 한 명의 학생이 1개 이상 6개 이하의 과목에 등록할 수 있 다면 카디날리티는 (1, 6)이다. 한 명의 교수는 최대 3개의 과목을 가르칠 수 있다면 카디날리티는(0, 3)이다. 카디날리티는 (Min, Max)의 한 쌍의 값으로 표현하는데 여기서 Min은 관계에 참여하는 개체의 최소 개수, Max는 관계에 참여하는 최대 개수를 각각 의미한다. 여기서 Max의 값이 M으로 표시되면 최대 개수에 제한이 없음을 의미한다. [그림 2]에서 PROFESSOR-COURSE의 관 계를 살펴보면 다음과 같이 해석할 수 있다.

                                                                       [그림 2]

1) PROFESSOR-COURSE는 1:M 관계이다.

2) PROFESSOR의 카디날리티는 (0, 3) 이다. 즉 각 교수는 3개 이하의 과목을 가르칠 수 있다.

3) COURSE의 카디날리티는 (1, 1)이다. 즉 각 과목을 가르치는 교수는 반드시 1명이어야 한다.

출처 : DB 포탈 사이트 DBguide.net

식별자

엔터티의 각 개체들은 인스턴스라고 하는데, 인스턴스는 그들을 지칭하거나 식별해 주는 속성인 식별자(Unique Identifier)를 가지고 있다. 예를 들어 직원 인스턴스는 직원번호, 주민번호, 직원명 으로 식별될 수 있다. 이들 중 직원명은 실세계에서는 직원 각각을 식별하는데 이용될 수 있으나 데 이터 측면에서는 동명이인의 문제 때문에 식별성이 미약한 편이다. 봉급이나 입사일 같은 속성으로 는 각각의 인스턴스를 유일하게 식별할 수 없다. 이와 마찬가지로 고객은 고객번호나 고객이름으로 식별될 수 있고, SALES-ORDER은 OrderNumber(주문번호)에 의해서 구별될 수 있다.

식별자는 하나 또는 그 이상의 속성으로 구성된다. 특별히 두 개나 그 이상의 속성으로 이루어진 식별자를 복합 식별자(Composite Identifier)라고 부른다. 그 예로는 (Area Code, Local Number), (Project Name, Task Name), (First Name, Last Name, Date Of Hire) 등이 있다.

식별자와 키는 구별하여 사용되어야 하며, 이 둘은 서로 일치할 수도 있고 그렇지 않을 수도 있다. 즉 식별자는 논리적인 관점에서 사용되고 키(Key)는 물리적인 관점에서 사용된 키를 가진다고 할 수 있다. 이러한 이유로서 식별자가 엔터티에 대해 하는 역할은 키가 테이블에 대해 하는 역할과 동일하다.

데이터 모델링의 초기 단계에서부터 모델을 지나치게 상세히 표현하면 개체-관계 다이어그램을 이해하고 다루기가 힘들어질 수도 있기 때문에  간단하게 식별자만 보이거나  직사각형 안에 개체 이름만 간결하게 보임으로써 많은 모델들 중에서 사용자가 필요한 것들을 손쉽게 사용되어질 수 있다.

관계(Relationship)

관계는 엔터티와 엔터티간 연관성을 표현하는 것으로, 엔터티의 정의에 따라 영향을 받기도 하고, 속성 정의 및 관계 정의에 따라서도 다양하게 변할 수 있다. 엔터티간에 논리적으로 존재할 수 있는 수 많은 관계들 중에서 정말로 의미가 있고 관리할 가치가 있는 관계를 식별해 낸다는 것이 쉬운일은 아니다. 최초의 개체-관계 다이어그램에서 관계는 속성을 가질 수 있었으나 현재에는 그렇지 않다.

관계의 표현에는 이항 관계(Binary Relationship), 삼항 관계(Ternary Relationship), n항 관계 가 존재할 수 있는데 실제에 있어서 삼항 관계 이상은 잘 사용되지 않는다. [그림 1] 참조 매핑 카디날리티(Mapping Cadinality)는 개체-관계 다이어그램에서 개체와 연결될 때 나타나는 대응(Mapping)되는 수로 대응수라고도 한다. 대응수는 최대 대응수(Maximum Cadinality)와 최 소 대응수(Minimum Cadinality)로 구분된다. 매핑 카디날리티가 포함된 개체-관계 다이어그램에 대하여 예제를 통해서 설명하고자 한다. [그림 1] 참조 다음과 같은 조건 하에서 교수 개체와 학생 개체 간에 성립하는 지도 관계의 매핑 카디날리티를 결 정하고, 개체-관계 다이어그램을 작성하면 [그림 5-1-13]과 같은 이항 관계 구조의 다이어그램을 완성할 수 있다.

• 조건 1 : 교수는 꼭 학생에 대한 지도를 해야 한다.
  
  Min-Card(교수, 지도) = 1
• 조건 2 : 교수는 여러 명의 학생을 지도할 수 있다.
  
  Max-Card(교수, 지도) = n
• 조건 3 : 학생은 꼭 교수에게 지도를 받아야 한다.
  
  Min-Card(교수, 지도) = 1
• 조건 4 : 학생은 여러 명의 교수에게 지도를 받을 수 없다.
  
  Max-Card(교수, 지도) = 1

                                                              [그림 1]

출처 : DB 포탈 사이트 DBguide.net

속성(Attribute)

속성은 엔터티에 저장되는 개체 집합의 특성을 설명하는 항목이라고 할 수 있다. 엔터티를 명확하 고 구체적으로 정의했다 하더라도 이것만으로는 개체 집합의 특성을 설명하기에는 부족함이 있다. 예를 '직원'은??. ‘직원’집합의 특성을 설명하기 위해 직원번호, 직원명, 주민등록번호, 연락전화번호, 거주지 주 소 등과 같은 속성을 정의했다면 이제 이러한 속성 구성을 통해 어떻게‘홍길동’이라는 개체를 특징 짓고 변별할 것인지를 분명하게 이해할 수 있고 집합의 의미 또한 좀더 명확해진다고 할 수 있다. [그 림 1]과 [그림 2]에서 엔터티의 속성을 표현하는 서로 다른 방법을 보여 주고 있다. [그림 1]은 엔터티에 연결되는 속성을 타원으로 보여 주고 있다. 이 스타일은 데이터 모델링 소프트웨 어 제품이 출현하기 이전에 원래의 개체-관계 모델에서 사용되었다. [그림 2]는 현재의 데이터 모델링 소프트웨어 제품에서 보편적으로 사용되고 있는 스타일을 보여 주고 있다.

[그림 1]의 개체-관계 다이어그램에서 속성은 개체 집합을 갖는다. 또한 각 속성은 가질 수 있는 값 의 범위가 있는데 이를 그 속성의 도메인(Domain)이라 한다. 예를 들면 학생이라는 엔터티가 있을 때 학점이라는 속성의 도메인은 0.0 에서 4.0 사이의 실수 값이며 주소라는 속성은 길이가 20자리 이내의 문자열로 정의할 수 있다. 여기서 물론 각 속성은 도메인 이외의 값을 갖지 못한다.

                                                                      [그림 1]

                                                                      [그림 2]

일반적으로 서로 다른 개체 집합에 정의된 속성은 같은 도메인을 공유할 수 있다. 예를 들면 학생 개체 집합에서 주소 속성에 해당하는 도메인과 교수 개체 집합에서의 주소 속성의 도메인은 같은 값 들의 범위를 가질 수 있다. 개체 집합 내에서 각각의 개체를 식별할 수 있도록 하나 또는 그 이상의 속성들로 이루어진 속성 집합을 식별자(Unique Identifier)라고 하는데 이 속성들이 개체 집합 내의 각 개체를 유일하게 지정한다. 예를 들면 학번, 성명, 주소, 생년월일, 학과 등의 속성들로 이루어진 학생 엔터티에서 학번 속성은 하나의 식별자가 될 수 있다.

[그림 3]은 자동차 개체 집합의 속성 구성을 나타낸 것이며‘ID_NUM’이라는 속성에 밑줄을 친 것은 식별자를 의미한다. [그림 2]과 같은 표현에서는‘#’표시가 붙은 속성이 식별자이다. 속성은 단순형 혹은 복합형으로 분류할 수 있다. 예를 들면 주소 속성은 시, 구, 동, 번지 등과 같은 여러 세부 속성들로 구성될 수 있는데 이를 복합 속성(Composite Attribute)이라 한다. 또한 나이, 성별 등의 속성은 더 이상 다른 속성들로 구성될 수 없는 단순한 속성이므로 단순 속성(Simple Attribute)이라 한다. 속성은 관리 목적이나 상세화 정도에 따라서 단일값(Single Value) 또는 다중 값(Multi Value)을 가질 수 있다. 주민등록번호와 같은 속성은 반드시 하나의 값만 존재하므로 이 속성은 단일치 속성(Single-Valued Attribute)이라 하고 어떤 사람의 전화번호와 같은 속성은 집, 휴대전화, 회사 전화번호와 같이 여러 개의 값을 가질 수 있다. 자동차의 색상 속성도 차 지붕, 차체, 외부의 색이 다를 수 있다. 이런 속성을 다중치 속성(Multi-Valued Attribute)이라 한다.

[그림 3]과 같은 표현에서 다중치 속성은 두 개의 실선으로 표시한다. 개체-관계 모델에서는 복합 속성, 다중치 속성을 정의할 수 있지만, 직접 구현은 불가능할 수도 있다. 이를 위해서는 M:M 관계나 다수의 속성 또는 1:M 관계의 추가 엔터티를 사용하여 수정해 주어야 한다. 만약 다중치 속 성이 존재하면 설계자는 아래의 방법 중 하나를 선택하여 해결할 수 있다.

                                                                           [그림 3]

                                                                          [그림 4] 


1) 엔터티 내에서 다중치 속성을 여러 개의 새로운 속성으로 나눈다. [그림 3]에서의‘COLOR’ 속성에 대해 [그림 4]와 같은 새로운 속성을 만들어 [그림 3]에서‘CAR’개체형의 속성 들로 부착시킨다.

2) 다중치 속성을 구성하는 속성들로 구성된 새로운 엔터티를 만든다. 이때 새로운 엔터티는 원래 엔 터티와 M:1 관계를 맺게 한다. [그림 4]의‘COLOR’속성을 떼어내어 새로운 엔터티로 만들 면 새로운 엔터티‘COLOR’는‘CAR’개체형과 M:1 관계가 될 것이다. 속성 중에는 유도 속성 (Derived Attribute)으로 분류될 수 있는 것도 있는데 이 속성은 다른 속성의 값으로부터 어떤 계산을 통해 새로운 값을 얻게 되므로 집합의 본질이나 특성을 규명하기 위한 속성을 고려할 때 제외할 수도 있다. 예를 들면 어떤 사람의 나이 속성은 현재 날짜로부터 생년월일 속성의 값을 뺌 으로써 나이의 값을 유도할 수 있다.

출처 : DB 포탈 사이트 DBguide.net

엔터티(Entity)

엔터티는 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서 그 대상들간에 동질성을 지닌 것으로 볼 수 있는 개체 집합이나 그들이 행하는 행위의 집합으로 정의할 수 있다. 동질성은 집 합을 어떻게 정의하느냐에 따라 달라질 수 있는데, 집합에 들어갈 개체들의 동일한 성질을 어디까지 로 한정할 것인지를 결정하는 것으로 동질성 유무를 판단할 수 있다. 예를 들면, ‘고객’이라는 집합 을‘우리 상품을 구매한 사람이나 법인’으로 정의했다면 아직 구매를 한 적이 없는 잠재고객이나 구 매상담자, 또 법인번호가 없는 단체나 개인사업자 등은 이들과 동질성을 갖지 못한다. 그러나 이들이 현재 어떠한 방법으로든 관리가 되고 있거나 앞으로 관심을 갖고자 하는 범주에 해당한다면 집합의 정의를 더 확장해야만 이들을 고객 집합 내에 끌어들일 수 있다. 집합에 대한 정의 문제는 엔터티의 구성 속성과 관계 정의에도 영향을 미치고 이것은 결과적으로 데이터 모델 전체의 구성에 영향을 미 치게 되므로 엔터티, 즉 집합에 대한 명확한 정의는 데이터 모델링에서 가장 핵심적인 사안이라 할 수 있다. 그러므로 엔터티를 정의할 때는 어떤 대상이 그 엔터티에 속하는지 여부를 명확하게 구분할 수 있도록 정의해야 한다.

엔터티는 그 집합에 속하는 개체들의 특성을 설명할 수 있는 속성(Attribute)을 갖는데, 예를 들어 ‘학생’이라는 개체 집합은 학번, 이름, 이수학점, 등록일자, 생일, 주소, 전화번호, 전공 등의 속성으 로 특징지어질 수 있다. 이러한 속성 가운데에는 개체 집합 전체가 공유할 수 있는 공통 속성도 있고, 개체 집합 중 일부에만 해당하는 개별 속성도 있을 수 있다.

개체-관계 다이어그램을 표기하는 방법은 여러 가지가 있는데, 그것들에 대해서는 뒤에서 설명하 기로 하고, 여기서는 그 중 한가지인 리차드 바커 표기법(Richard Barker Notation)에 따른 표현 을 예로 설명한다. 엔터티를 개체-관계 다이어그램으로 나타낼 때는 그림과 같은 모양으로 나타내고 이름을 부여할 수 있다.

출처 : DB 포탈 사이트 DBguide.net

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

개념 데이터 모델링은 조직, 사용자의 데이터 요구사항을 찾고 분석하는데서 시작한다. 이 과정은 어떠한 자료가 중요하며 또 어떠한 자료가 유지되어야 하는지를 결정하는 것도 포함한다. 이 단계에 있어서의 주요한 활동은 핵심 엔터티와 그들 간의 관계를 발견하고, 그것을 표현하기 위해서 개체-관계 다이어그램을 생성하는 것이다. 개체-관계 다이어그램은 조직과 다양한 데이터베이스 사용자에게 어떠한 데이터가 중요한지를 나타내기 위해서 사용된다. 데이터 모델링 과정이 전 조직에 걸쳐 이루어진다면, 그것은 전사적 데이터 모델(Enterprise Data Model)이라고 불린다. 개념 데이터 모델을 통해 조직의 데이터 요구를 공식화하는 것은 두 가지의 중요한 기능을 지원한다.

첫째, 개념 데이터 모델은 사용자와 시스템 개발자가 데이터?터 모델은 추상적이다. 그렇기 때문에 그 모델은 상위의 문제에 대한 구조화를 쉽게 하며, 사용자와 개발자가 시스템 기능에 대해서 논의할 수 있는 기반을 형성한다.

둘째, 개념 데이터 모델은 현 시스템이 어떻게 변형되어야 하는가를 이해하는데 유용하다. 일반적으로 매우 고립된(Stand Alone) 시스템도 간단하게 추상적 모델링을 통해서 좀더 쉽게 표현되고 설명된다.

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

논리 데이터 모델링은 데이터 모델링 프로세스의 Input으로써 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 기법 또는 과정이라 할 수 있다. 논리 데이터 모델링의 결과로 얻어지는 논리 데이터 모델은 데이터 모델링이 최종적으로 완료된 상태라고 정의할 수 있다. 즉 물리적인 스키마 설계를 하기 전 단계의‘데이터 모델’상태를 일컫는 말이다.

논리 데이터 모델링의 핵심은 어떻게 데이터에 액세스하고 누가 데이터에 액세스하며, 그러한 액세스는 전산화와는 독립적으로, 다시 말해서 누가(Who), 어떻게(How) 그리고 전산화는 별개로 비즈니스 데이터에 존재하는 사실들을 인식하여 기록하는 것이며 이것은 기법으로서의 의미를 넘어 하나의 철학이라고도 할 수 있다. 특히 데이터 모델링 과정에서 가장 핵심이 되는 부분이 논리 데이터 모델링이라고 할 수 있다.

데이터 모델링이란 모델링 과정을 통해어그램이라는 그림으로 그려내는 과정을 말하는 것이 아니다. 시스템 구축을 위해서 가장 먼저 시작할 기초적인 업무 조사를 하는 초기 단계부터 인간이 결정해야 할 대부분의 사항을 모두 정의하는 시스템 설계의 전 과정을 지원하는‘과정의 도구’라고 해야 할 것이다.

이 단계에서 수행하는 또 한가지 중요한 활동은 정규화이다. 정규화는 논리 데이터 모델 상세화 과 정의 대표적인 활동으로 논리 데이터 모델의 일관성을 확보하고 중복을 제거하여 속성들이 가장 적절한 엔터티에 배치되도록 함으로써 좀더 신뢰성있는 데이터 구조를 얻는데 목적이 있다.

논리 데이터 모델의 상세화는 식별자 확정, 정규화, M:M 관계 해소, 참조 무결성 규칙 정의 등을 들 수 있으며, 추가적으로 이력 관리에 대한 전략을 정의하여 이를 논리 데이터 모델에 반영함으로써 데이터 모델링을 완료하게 된다. 이에 대한 상세한 내용은 제3장 논리 데이터 모델링에서 다루게 될 것이다.

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

데이터 모델링 과정의 세 번째 단계인 물리 데이터 모델링은 논리 데이터 모델이 데이터 저장소로서 어떻게 컴퓨터 하드웨어에 표현될 것인가를 다룬다. 데이터가 물리적으로 컴퓨터에 어떻게 저장될 것인가에 대한 정의를 물리적 스키마라고 한다. 이 단계에서 결정되는 것은 테이블, 칼럼 등으로 표현되는 물리적인 저장 구조와 사용될 저장 장치, 자료를 추출하기 위해 사용될 접근 방법 등이 있다.

계층적 데이터베이스 관리 시스템 환경에서는 데이터베이스 관리자가 물리적 스키마를 설계하고 구현하기 위해서 보다 많은 시간을 투자하여야 한다. 계층적 데이터베이스 관리 시스템 환경에서의 물리적 스키마 설계의 예는 데이터의 디스크상의 위치, 색인화할 레코드, 다양한 최적화 문제 등이다.

이에 비해, 논리 데이터 모델은 매체에 물리적으로 구현되는 것과는 독립적으로 여겨진다. 현실적으로 물리 데이터 모델을 계층적 데이터베이스 관리 시스템에 구현하는 것은 그것이 구현될 하드웨 어와 밀접한 관계를 맺고 있다. 그러나 관계형 데이터베이스 관리 시스템의 출현으로 인해 그 초점이 개념 및 논리 데이터베이스 설계로 이동하고 있다. 그래서 관계형 데이터베이스 관리 시스템을 사용하는 조직에서는 데이터베이스 관리자가 잘 유지해야 하는 데이터 항목의 발견과 데이터 항목 간에 존재하는 논리 관계를 이해하는데 더 많은 시간을 할애한다. 관계형 데이터베이스 관리 시스템의 출현으로 인하여 물리적 데이터베이스 설계와 관련된 문제들은 많은 부분 관계형 데이터베이스 관리 시스템 소프트웨어에서 처리되고 있다.

출처 : DB 포탈 사이트 DBguide.net