데이터 모델링(Data modeling)이란

데이터 모델링(data modeling)이란 데이터베이스 설계 시 클라이언트의 요구를 분석, 논리 모델을 구성하고 물리 모델을 사용해 데이터베이스에 반영하는 작업을 말한다. [1] 데이터 모델링을 해 나갈 때는, 사람들은 데이터를 구조화하고 조직화한다. 뒤이어 이러한 데이터 구조는 데이터베이스 매니지먼트 시스템 상에서 구현된다. 데이터를 정의하고 조직화하는 것 외에도, 데이터 모델링은 (명시적으로나 비명시적으로) 구조 안에 들어갈 데이터의 제약 조건이나 범위를 규정해 나가게 된다.

구조화되었거나 구조화 안 되었거나 거대한 양의 데이터를 관리하는 것이 정보 시스템의 주요 기능이다. 하지만, 관계형 데이터베이스와 같은 데이터 관리 시스템 상의 저장소에 담을 구조적인 데이터를 기술하는 것이 데이터 모델이다. 데이터 모델은 구조화되지 않은 것들, 예를 들어 문서 편집기로 작성한 문서, 이메일 메시지 등은 보통 기술하지 않는다.



데이터 모델링 ( 영어 : data modeling )은 컴퓨터 과학 의 맥락에서 어떤 데이터 모델링 방법론을 적용하여 데이터 모델 의 인스턴스 를 만드는 과정이다. 데이터 모델링 방법론은 데이터 모델링을 형식적으로 적용한다. 현재까지 고안된 데이터 모델의 종류로는 다음과 같은 것이있다.

데이터 모델링을 할 때 데이터를 구조화 조직화한다. 이렇게 만들어진 데이터 구조는 다음에 데이터베이스 관리 시스템 (DBMS)를 사용하여 구현되는 경우가 많다.데이터 모델링 과정에서 데이터를 정의하고 조직화 할뿐만 아니라 구조화 된 데이터에 대해 (암시 적 혹은 명시 적으로) 제약 조건의 집합을 식별한다.

대용량의 구조화 데이터 및 대용량의 비정형 데이터를 관리하는 것은 정보 시스템 의 주요 기능이다. 데이터 모델은 관계형 데이터베이스 관리 시스템 (RDBMS)과 같은 데이터 관리 시스템에서 저장 장치 에 유지 되는 구조화 된 데이터를 기술한다. 데이터 모델은 비정형 데이터 - 워드 프로세서 로 작성하는 문서 나 전자 메일메시지, 이미지, 디지털 음악, 디지털 동영상 등 -에 대해서는 설명하지 경우가 많다.

데이터 모델링의 예는 다음을 참조.

목차

  [ 숨기기 ] 

데이터 모델의 종류 편집 ]

데이터 모델의 인스턴스 는 ANSI 에 따르면 다음의 3 종류가있다.

개념 스키마
개념 스키마 (데이터 모델)은 모델링의 대상이되는 영역의 의미적인 측면을 기술한다. 예를 들어, 어떤 조직이나 업계의 한 측면 모델을 개념 스키마로 기술 할 것이다. 개념 스키마는 엔티티 클래스와 관련 모임으로 구성된다. 실체 클래스는 대상 영역에서 중요한 개념을 표현한다. 관련은 두 엔티티 클래스 사이의 관계이다. 개념 스키마는 모델을 사용하여 표현 할 수있는 사물 등을 확인한다. 일반적으로 적용 할 수있는 모델은 # 범용 데이터 모델 절에서 설명.
논리 스키마
논리 스키마 (데이터 모델)은 모델링의 대상이되는 영역의 의미적인 측면을, 데이터를 처리하기 위해 어떤 기술을 사용하여 표현한 것이다. 논리 스키마는 관계 모델 의 관계 (  테이블)와 속성 (열)과 객체 지향 의 클래스 , XML 요소 (태그)와 속성 등으로 구성된다.
물리적 스키마
물리적 스키마 (데이터 모델)은 데이터가 유지 되는 물리적 인 방법을 적용한다. 물리적 스키마는 파티션 이나 CPU 테이블 스페이스 등 관련.

이러한 ANSI 의한 방법으로 중요한 것은, 앞서 언급 한 3 가지 관점의 각각의 모델이 서로 어느 정도 독립적이다. 논리 스키마의 관계 (표)와 속성 (열)은 개념적 모델에 반드시 영향을주지 않고 변경할 수있다. 사실, 당연히 스키마 구조는 다른 스키마에 대해 일관성을 가지고있을 필요가있다. 논리 스키마의 관계 (표)와 속성 (열)은 개념적 모델에서의 개체 클래스와 속성을 직접적으로 변환 한 결과는 다를 수있다. 그러나 논리 스키마는 궁극적으로 개념적 모델의 실체 클래스 구조의 목표를 ​​만족시킬 필요가있다. 많은 소프트웨어 개발 프로젝트의 초기 개발 과정 에서 개념 데이터 모델 의 설계가 중요하다. 계속 공정에서 개념 데이터 모델은 논리적 데이터 모델 의 형태로 구체화 할 수있다. 그 과정에서 때로는 논리적 데이터 모델은 물리적 데이터 모델 로 변환된다. 그러나 경우에 따라서는 개념 모델을 직접 구현할 수도있다.

개별 사례에서 세부 사항은 다를 수 있어도, 모델 인스턴스의 구조는 다른 모델 인스턴스와 일치하고있을 필요가있다. 논리 데이터 모델의 관계 (표 테이블)와 속성 (열) 구조는 개념 데이터 모델의 실체 클래스와 관련과 특성을 직접적으로 변환 한 것으로는 다르다 수있다. 그러나 논리 데이터 모델은 궁극적으로는 문맥 수준의 데이터 모델에서의 개체 클래스의 구조와 개념 데이터 모델의 관련 구조, 각각의 목표를 ​​만족시킬 필요가있다. 논리 데이터 모델이 생성 된 후 공정에서 데이터를 저장하는 플랫폼 이 결정되면 논리 데이터 모델은 물리적 데이터 모델로 변환 할 수있다. 그리고 물리적 데이터 모델을 기반으로하여 데이터의 정의가 만들어진다. 데이터베이스에 실제로 데이터가 저장되어 운영되면 데이터베이스에 대한 데이터 조작 (조회, 갱신 등)을 할 수있다.

데이터 구조 편집 ]

데이터 모델은 대상 영역의 데이터 구조를 설명하고, 또 결과적으로 그 영역 자체의 기본 구조를 설명한다. 이것은 데이터 모델은 대상 영역을위한 전용 인공 언어의 문법을 실제로 규정하고 있다는 것을 의미한다.

데이터 모델은 엔티티 클래스 (사물의 종류)의 집합을 표현한다. 대상이되는 조직은 실체 클래스의 집합에 대한 정보와 정보의 속성과 실체 사이의 관계와 속성 간의 관계를 유지하고 관리하려고 생각한다. 데이터 모델은 데이터를 컴퓨터 시스템에 표시하는 방법과는별로 관계없는 형태로 데이터를 조직화하고 기술한다. 데이터 모델에 의해 표현되는 실체는 명백한 물의 실체 일 수있다. 그러나 이러한 구상적인 실체 클래스를 포함하는 데이터 모델은 시간이 지난 경우 모델이 변경되는 경향이있다. 강력한 데이터 모델은 그러한 실체의 추상 을 발견하는 경우가 많다. 예를 들어, 데이터 모델은 "사람"이라는 실체 클래스를 포함 할지도 모른다. 데이터 모델의 "인물"의 실체는, 조직과 상호 작용하는 모든 인물을 표현한다. 이러한 추상적 인 실체 클래스는 종종 "판매자"와 "직원"이라는 구상적인 실체 클래스에 비해 적합하다. 또한 여기서 "판매자"와 "직원"의 실체 클래스는 그러한 사람들에 의해 발생하는 특정 역할을 확인하고있다.

어떤 사람들은 데이터 모델을 설계하는 것은 트랜잭션 데이터 참조 용 데이터를 구분하는 데 도움이, 생각하고있다. 여기서 트랜잭션 데이터는 하나 또는 그 이상의 참조 용 데이터를 참조하는 데이터를 말한다.

제대로 설계된 개념 데이터 모델은 대상 영역의 의미적인 측면을 기술한다. 개념 데이터 모델은 하나 또는 그 이상의 조직에 의해 사용되는 정보의 성격에 관하여, 진술의 집합이다. 잘 디자인 된 개체 클래스의 집합은 이해하기 어려운 기술적 인 용어가 아니라 자연 언어의 단어를 사용하여 이름을 붙일 수있다. 마찬가지로, 잘 디자인 된 관련 집합은 대상 영역에 대한 구체적인 진술을 생성한다.

관련 몇 가지 종류가있다. 예를 들어, "-로 구성된"(is composed of)라는 관련, "주문"실체 클래스 "주문 내역"실체 클래스가 다음과 같은 표현을 생성하기 위해 정의된다. 즉, 각각의 "주문"은 하나 또는 그 이상의 "주문 내역" "로 구성된" 영어를 사용하는 경우,보다 엄격한 방법은 전치사 또는 동명사 또는 분사를 "-해야한다"(must be) 또는 "- 가능성이있다"(may be)라는 동사를 수반하는 형태로 모든 관련 이름을 붙이는 것이다. 이렇게하면, 실체 클래스의 인스턴스 개수 (농도)과 속성의 수 (차수)을 모두 의미 적으로 처리 할 수​​있다. 이것은 이러한 관련을 한 방향으로 읽을 수있는 것을 의미한다. 예를 들면 다음과 같다.

  • 각각의 "주문"은 하나 또는 그 이상의 "주문 내역" "로 구성된" "가능성이있다".
  • 각각의 "주문"은 하나 또는 그 이상의 "주문 내역" "로 구성되어" "해야한다".

범용 데이터 모델 편집 ]

범용 데이터 모델은 기존의 데이터 모델 을 일반화 한 것이다. 범용 데이터 모델은 표준화 된 관계 (  테이블)의 형식 및 그러한 관계 유형에 관련하는 것에 대해 정의하고있다. 범용 데이터 모델을 정의하는 것은 자연적인 언어를 정의하는 것과 유사합니다. 예를 들어있는 범용 데이터 모델은 "분류 관계"나 "전체 - 부분 관계"와 같은 관계 유형을 정의하고 있을지도 모른다. "분류 관계 '는 한 사물과 사물의 종류 (클래스) 사이의 이항 관계 이다. "전체 - 부분 관계"는 부분의 역할을 사물과 전체의 역할을 사물 사이의 이항 관계이다. 직업 군의 확장 가능한 목록이 있으면, 어떤 사물도 분류 할 수 있으며, 어떤 개체에 대해 전체 - 부분 관계를 지정할 수있다.관계 유형에 대한 확장 가능한 목록을 표준화함으로써, 범용 데이터 모델에서 무수한 사물의 종류를 표현 할 수 자연 언어 표현 능력의 수준에 접근 할 수있다. 한편, 기존의 데이터 모델은 대상 영역의 범위는 고정으로 한정되어있다. 왜냐하면 기존의 데이터 모델을 인스턴스화 (적용)하여 수는 모델에서 사전 정의 된 사물을 표현할 수있을뿐이기 때문이다.

범용 데이터 모델은 기존의 데이터 모델의 단점을 해결하기위한 방법으로 개발된다. 예를 들어, 같은 지역에 기존의 데이터 모델에 의한 모델링을 여러 사람들이 할 경우 서로 다른 데이터 모델을 만들어 버리는 경우가 많다. 따라서 여러 사람이 공동으로 모델을 만드는 경우 어려움에 부딪친 다. 이러한 상황은 데이터 교환 및 데이터 통합​​하는 관점에서 장애이다. 그리고 같은 영역에 데이터 모델이 다르다는 항상 모델의 추상화 수준이 다를 수와 (모델의 의미 적 표현 능력에 따라) 인스턴스화 할 수있는 사물의 종류 다름이 원인이되고있다. 이러한 차이를 줄이기 위해 모델링을하는 사람들은 의사 소통을보다 구체적으로 표현 할 수 있도록 몇 가지 요소에 대해 합의를 할 필요가있다.

뛰어난 데이터 모델을 만드는 데 도움이되는 일반적인 몇 가지 패턴이있다. 이러한 패턴은 파티 (인물과 조직의 상위 개념 ), 제품 유형, 제품 인스턴스 , 활동 유형, 활동 인스턴스, 계약, 지역 사이트 등이 포함된다. 이러한 패턴에 포함 된 실체를 명시 적으로 포함 된 모델은 비교적 견고한 쉽게 이해할 것이다.

일반적인 도구를 만들 때 추상적 인 모델이 적합하다. 이 추상적 인 모델은 "사물"(THING)와 "사물 유형"(THING TYPE)의 변형 버전의 집합으로 구성된다. 이 추상적 인 모델은 모든 실제 데이터는 "사물"혹은 "사물 유형"의 인스턴스로 기술된다. 한편, 이러한 추상적 인 모델은 취급하기 어려운 측면도있다. 왜냐하면 실제 사물을 너무 잘 표현되어 있지 않기 때문이다. 그러나 한편, 이러한 추상적 인 모델에 특히 표준화 된 사전 (사전)가 존재하는 경우에 적용 가능성이 매우 높다. 구상적이고 특화된 데이터 모델은 범위와 환경이 변경된 때 모델을 변경해야한다는 우려가있다.

범용 데이터 모델이 데이터 모델링 방법에는 다음과 같은 특징이있다.

  • 범용 데이터 모델은 일반적인 실체의 집합으로 구성된다. 범용적인 실체로는 "사물 인스턴스 "," 클래스 ","관련 "등이 있으며, 또한 아마 이러한 실체에 많은 서브 타입이 존재하는 것이다.
  • 모든 사물 인스턴스는 "사물 인스턴스"라는 범용적인 실체의 인스턴스이거나 하위 유형의 인스턴스이다.
  • 모든 사물 인스턴스는 사물의 종류 ( "클래스")에 의해 명시 적 분류 관련을 사용하면 명시 적으로 분류된다.
  • 분류를 위해 사용되는 실체는 다른 종류의 실체와는 별도로 "클래스"이라는 실체 또는 그 하위 유형의 실체 표준 인스턴스로 정의된다. "클래스"의 하위 유형으로는 "관련 클래스"등이있다. 이러한 표준 직업 군은 "참조 데이터"라고하는 경우가 많다. 즉, 영역에 고유의 지식은 이러한 표준 직업 군의 인스턴스로 표현하는 것이 가능하다는 것이다. 예를 들어, 자동차, 바퀴, 건물, 배, 온도, 길이 등의 개념은 표준 인스턴스이다. 또한, "-로 구성된"나 "- 참여"와 같은 표준 관련 실체 또한 표준 인스턴스이다.

이러한 범용 데이터 모델이 데이터 모델링의 방법을 채택함으로써 표준 엔티티와 표준 관계형을 인스턴스로 추가 할 수있게된다. 그리고 데이터 모델에 유연성을 갖게하고, 응용 프로그램 소프트웨어 의 범위 변경된 경우에도 데이터 모델의 변경을 억제 할 수 있습니다.

범용 데이터 모델은 다음과 같은 규칙을 따른다.

  • 특성은 다른 실체에 관련을 표현하는 것으로 간주된다.
  • 실체가 발견되면 그 사물의 본질적인 특성에 따라 명명된다. 특정 맥락에서 역할에 따라 명명되는 것이 아니다.
  • 실체는 데이터베이스 나 데이터 교환을위한 파일 안에 국소적인 식별자 를 가진다. 이러한 식별자는 인공적인 것이며, 고유되도록 관리된다. 관련은 국소적인 식별자의 일부로 사용되는 것은 아니다.
  • 활동 관련 이벤트에 의한 영향은 실체로 표현되는 (속성으로 표현되지 않음).
  • 실체는 모델의 보편적 인 문맥을 정의하기 위해, 실체의 서브 타입 / 수퍼 유형 계층의 일부를 구성한다. 관련도 실체이기 때문에 다양한 관련 실체는 관련 서브 타입 / 수퍼 유형 계층의 일부를 구성한다.
  • 관련 높은 (일반) 수준에서 정의된다. 관련 그것이 타당 수준 중 가장 높은 수준으로 정의된다. 예를 들어, 컴포지션 관련 ( "-로 구성된다"고 표현되는)는 "사물 인스턴스"다른 "사물 인스턴스"간의 관계로 정의된다 (예를 들어, 단순히 "주문"과 "주문 내역 "사이의 관련은 정의되지 않는다). 이 일반적인 수준에서 관련은 원칙적으로 어떠한 사물 인스턴스와 그것과는 다른 어떤 사물 인스턴스에 적용 할 수 있다는 것을 의미하고있다. "참조 데이터"에서는 데이터에 대한 제약 그룹이 정의된다. 제약은 실체 간의 표준 인스턴스이다.

범용 데이터 모델의 예를 다음에 나타낸다.

데이터의 조직화 편집 ]

범용 데이터 모델과는 다른 종류의 데이터 모델은 데이터베이스 관리 시스템 (DBMS) 또는 다른 데이터 관리 기술을 사용하여 데이터를 구성하는 방법을 설명한다.이러한 데이터 모델은 예를 들어, 관계 모델 에서는 관계 (표 테이블) 군과 속성들을, 객체 지향 모델링 에서는 클래스 군과 특성들을 기술한다. 이론적으로, 이러한 데이터 모델은 전술 한보다 개념적 데이터 모델에서 파생된다. 그러나 이러한 데이터 모델은 시스템의 처리 용량이나 사용 패턴을 고려하여 개념적 데이터 모델과는 다르다 수있다.

"데이터 분석"은 데이터 모델링에서 일반적으로 사용하는 용어이다. 그러나 데이터 분석 해보는 작업은 " 분석 "(분석, 일반적인 개념에서 그 구성 요소가되고있는 개념들을 발견하는 것)보다" 종합 "(별도의 인스턴스를 하나의 일반적인 개념에 조립)으로, 이론과 방법론에서 공통되는 부분이 많다 (참고 : " 시스템 분석가 "라는 용어는 사용하고 있지만,"시스템 종합 자 '라는 용어는 사용하지 않는다). 데이터 모델링은 불필요한 데이터의 중복을 제거하는 것과 관련이되어있는 데이터 구조 군을 "관련"에 연결하여 개념에 가까운 데이터 구조들을 바탕으로하여 하나의 포괄적 인 개념에 조립하는 것을 목표로한다.

데이터 모델링의 다른 방법론으로는 자율적으로 데이터의 암시 적 모델을 생성하는 인공 신경망 과 같은 적응 형 시스템을 사용 방법론이있다.

데이터 모델링 기법 편집 ]

데이터 모델링 기법 (방법론)가 지금까지 일부 개발되어오고있다. 이러한 데이터 모델링 기법은 데이터 모델링을하는 사람들이 작업을 할 때 인도의 손이다. 그러나 두 사람이 같은 데이터 모델링 기법을 채용하고도 매우 다른 데이터 모델을 고안하는 결과가 될 수 종종있다. 데이터 모델링에 사용되는 유명한 기법을 다음.

실체 관련도 (ER 그림) 데이터 모델링의 예 편집 ]

위키 시스템을 실체 관련도 (ER 그림)에서 설명하는 예 ( MediaWiki 의 데이터베이스 스키마 의 일부)

통합 모델링 언어 (UML) 클래스 다이어그램의 데이터 모델링의 예 편집 ]

위키 시스템을 통합 모델링 언어 (UML)의 클래스 다이어그램 에서 설명하는 예 (MediaWiki의 데이터베이스 스키마의 일부)

문헌 소개 편집 ]

범용 데이터 모델의 데이터 모델링 문학

관련 항목 편집 ]

외부 링크 편집 ]








데이터 모델링 순서

출처 - 데이터베이스 설계 및 구축(개정2판)


식별자

- 주식별자는 주민번호와 같이 자연적인 속성도 후보( candidate)가 될 수 있으나, 필자ID나 책 ID 처럼 인위적인 것도 좋은 후보라 할 수 있다(인위적인 주식별자를 물리적모델에서IDENTITY 속성 등과 연계하면 좀 더 효율적으로 테이블을 관리 할 수 있다) . 주식별자가 될 수 있는 각후보들을 후보식별자(candidate identifier)라 하며, 이 중에서 주 식별자로 지정 하지 않은 것을 부식별자(alternate identifier)라 한다 (부식별자는 여러벌이 있을 수 있다). 부식별자는 물리적모델링에서 유일성(UNIQUE) 인덱스를 설정하는 경우가 많다.


- 인위적인 주식별자의 생성은 관리를 간단하게 하는 장점도 있지만 원하지 않게 중복 정보가 저장 될 수 있으므로 사용에 신중해야 한다. 또한 인위적 주식별자를 사용하는 경우는 데이터의 중복을 관리할 수 있는 대안을 미리 마련하여야 한다.


식별관계

- 식별(identifying) 관계란 부모 실체의 주 식별자가 자식 실체의 외래 식별자이자 동시에 주 식별자가 되는 관계이다. 

식별관계는 장점도 많지만, 단점도 많이 있다(이것은 학자들 간에도 논란의 여지가 많은 분야이다). 한 예로, [그림4-5]에서 필자와 책, 그리고 책과 판매실체 사이에모두식별관계를맺은것을볼수있는데(초보자들은흔히이렇게모델링한다), 이경우주식별자영역이점점비대해 지며(식별 관계는 부모 실체의 주식별자를자식실체의주 식별자로 계속해서 전파시키는특성이 있기 때문에), 결과적으로무의미한 외래 식별자들이 주 식별자 영역에 들어가는 경우도 많이 있다([그림4-5]의예에서, 판매실체의주식별자로필자ID는필요치않다) . 

외래식별자는앞에서설명한대로참조무결성을강화하는목적으로도사용되지만, 최종적인 데이터베이스에서부모테이블과자식테이블을조인(JOIN)하는데도많이사용된다. 조인할 때 대부분 부모 테이블의 주 식별자와 자식 테이블의 외래 식별자를 조인 조건에서 사용하는 데, 이때조인조건식이복잡해지고결과적으로성능이저하되는것도식별관계의또 다른 단점이라고 볼수 있다. 왜냐하면식별관계를 많이 사용할 경우, 복합주 식별자가만들어질 가능성이높아지기때문이다.

필자의 견해로는, 불가피한 경우를 제외 하고는 비식별관계를 맺는 것이 좋다고 생각한다. ‘ 불가피한경우’의예는[그림4-6]에나타내었다. 이것은하위형식관계s(ubtype relationship)라 불리는 것인데, [그림4-6]에서 필자를 전임 필자와 프리랜서 필자로 세분화하고, 필자실체의속성을하위형식실체들(전임필자및 프리랜서필자)이 공유하는개념이다(객체지향의상속개념과유사하다). 이경우, 이들사이의관계는반드시식별관계여야한다.


식별관계냐 비식별관계냐는 erd를 작성하는 사람의 판단에 따른다고 생각합니다. 

자식테이블의 pk를 구성하는 칼럼이 부모로부터 받는 거라면 식별이고 
그렇지 않고 단순한 데이타 저장용 칼럼이라면 비식별 관계가 되겠지요. 

이때 부모로 부터 받은 칼럼을 일반 칼럼으로 잡을 수도 있지만 pk로도 잡을 수 있는 애매한 상황등이 존재하는데 pk칼럼을 구성하는 원칙중 최소한의 원칙이란 것이 있습니다. 
즉 자식테이블의 pk를 구성하는 칼럼이 col1,col2,col3,col4 4개가 있고 col4는 부모로부터 받은 칼럼입니다. 그런데 자식테이블 로우의 유일성을 구분할 수 있는 것이 col1,col2,col3만으로도 충분하다면 col4는 pk 구성에서 빠져야 합니다. 그렇다면 처음에는 식별관계였다가 이후 비식별관계가 되겠지요.

출처 - http://www.okjsp.pe.kr/seq/96724


비식별 관계

부모 실체의 주 식별자가 자식 실체의 비식별자 영역의 외래 식별자가 되는 관계를 비식별관계(non-identifying)라고 한다. 비식별관계선은[그림4-1]처럼 점선으로 표시된다. 대부분의 경우, 비식별관계를 적용하는 것이 적절한 경우가 많다(또한이것은필자가선호하는것이기도하다). 비식별관계는 다시 강제적(mandatory) 비식별관계와 선택적(optional) 비식별관계로 구분된다.

■ 강제적 비식별 관계

강제적(mandatory) 비식별관계란 외래식별자에 NULL을 허용하지 않는 관계다(NULL이란 값을가지지않는상태를가리킨다). 이것은 자식실체가 존재하기 위해 부모실체가 반드시 먼저 존재 해야 함을 의미한다.

■ 선택적 비식별 관계

선택적(optional) 비식별 관계란 외래식별자에 NULL을 허용하는 관계다. 이것은 부모실체가 없이도 자식실체가 존재할 수 있음을 의미 하는데, [그림4-7]에서 필자 없는 책이 존재 할 수도 있다는 것을 나타낸다. 선택적 비식별관계는 관계 자체를 약화시킨다고 볼 수도 있으나, 상황에 따라 필요한 경우가 많다. 여기서 유의 할 사항은, 외래식별자가 NULL이 아닌 경우에는 참조 무결성 제약을 반드시 지켜야 한다는 것이다(즉, 외래식별자는 자기가참조하는 부모실체의 주식별자가가지고있는값만가질수있다) .


정규화

정규화(normalization)를 한 마디로 축약하면, ‘데이터 중복을 막고 무결성을 강화시키기 위해 하나의 실체를 둘 이상의 실체로 분리하는 작업’이라고 할수있다. 정규화된모델을정규형(normal form)이라한다. 정규형에는다음과같은것들이있다.

❶ 제 1 정규형(First Normal Form; 1NF)

❷ 제 2 정규형(Second Normal Form; 2NF)

❸ 제 3 정규형(Third Normal Form; 3NF)

❹ Boyce-Codd 정규형(BCNF)

❺ 제4 정규형(Fourth Normal Form; 4NF)

❻ 제 5 정규형(Fifth Normal Form; 5NF)

실무에서는제 3 정규형으로도충분하다고알려져 있으며, 제4 정규형이나 제 5 정규형은 다가종속성(multi-valued dependancy)까지분석하는것인데, 이것은오히려모델링에나쁜영향을미치는것으로판명되었다. 또한, Boyce-Codd 정규형은제3 정규형의대안이될수있지만, 종합적으로판단할때제 3 정규형이최선책이라고알려져있다.

함수적 종속성

함수적 종속성(functional dependency)이란 속성들 사이(실체들 사이가 아님!)의 종속 관계를나타내는것이다. 예를들어, 주문실체내에주문번호, 고객ID, 영업사원ID라는속성이있고, 주문번호는고객ID를결정짓고, 주문번호는영업사원ID를결정지으며, 고객ID는영업사원 ID를결정짓는다고할때, 이들의함수적종속관계를 아래 처럼나타낼수있다(화살표방향은결정짓는쪽에서종속되는쪽으로향하는것에유의할것).

주문번호 -> 고객 ID,  주문번호 -> 영업사원ID,  고객ID -> 영업사원ID 

여기서‘주문 번호가 고객 ID를 결정짓는다’라는 말의 뜻은 주문 번호 하나에 대해서 오직하나의고객ID를가질수있으며, 주문번호와고객ID는(다른실체로) 서로분리될수없다는 것을의미한다(별도의고객실체에 주식별자인고객 ID가있고, 이것이외래식별자로넘어온경우를상정할것). 이것은 '고객ID는 주문번호에 함수적으로 종속된다’ 라는 말과동의어다. 함수적종속성은제2∼5 정규형을규명하기위해반드시알아야하는개념이다.


제 1 정규형

제1 정규형이란 실체 내에 반복되는속성이나 속성그룹이 없는 형태를 말한다. 예를들어,[그림 4-12] (a)는 자식 1∼7까지의 속성이 반복되고 있으므로, 비1차 정규형(non-firstnormal form; NFNF 또는NF2)에해당된다. 반복되는속성(그룹)은정보손실과저장공간낭비라는심각한문제점을안고있으므로반드시제거해야한다.

[그림4-12] (a)에서 그 이유를 알아보자. 교수의자식이 평균적으로3명 정도라고 볼 때(이때, 평균적으로자식3까지에만유효한값이들어가게된다), 대부분의인스턴스에서저장공간이낭비될것이다([그림4-12] (a) 참고). 더심각한문제는자식이10명인교수가부임했을때발생한다. 이때만약자식10명중 7명만골라서등록하기를강요한다면정보를손실하게된다. 강력히반발하는교수때문에어쩔수없이자식 8, 자식 9, 자식10이라는속성을추가한다면, ERD와데이터베이스스키마는물론이고, 프로그램(저장프로시저, 트리거또는응용프로그램)까지수정해야 하는문제가발생할가능성이매우크다. 그리고 수정했다하더라도 또다시자식이15명인교수가부임할수도있다.

문제를해결하려면[그림4-12] (b)처럼반복되는속성(그룹)을별도의실체로분리하면된다. 그러면이제까지교수실체내에반복되는속성으로들어가던자식정보가자식실체의서로다른인스턴스로들어가게된다([표4-6] (b), (c) 참고). 이로서정보손실, 저장공간낭비및프로그램수정문제들이모두해결된것을알수있다. 이것이제1 정규형(First Normal Form - 1 N F)이다.


제 2 정규형

제 2 정규형이란하나의실체가제1 정규형이면서, 모든 비식별자 속성들이 주식별자에 함수적으로 완전히 종속되는 형태이다. 복합주식별자의 경우, 주 식별자의일부 속성에만함수적으로종속되는비식별자속성이있어서는 안된다.

예를들어, [그림4-14]의기술실체에서기술이름과기술난이도는기술자체에관한속성이고, 기술배운곳은 강아지별기술에관한속성으로, 그성격이엄연히구별된다. 이경우,주식별자인기술ID가실제로는기술ID와강아지별기술ID로구성되는복합주식별자와유사한 포괄적인 것이라고 해석될 수 있다. 따라서 이것은 제 2 정규형을 위반하고 있으며,속성들이 주 식별자에 함수적으로 완전히 종속되도록실체를 분리하면 [그림4-15]와 같은 제 2 정규형이만들어진다.


1정규화를 했을 때의 결과물에서 Single Primary Key로 되어진 테이블에는 제2정규화는 할 필요가 없다. 하지만 제1정규화를 했을 때의 결과물에서 Composite Primary Key로 되어진 테이블에는 반드시 제2정규화를 해야 한다.

식별자가 아닌 칼럼은 식별자 전체 칼럼에 대해 의존적이어야 하며 식별자 일부 칼럼에 대해 의존적이라면 그 칼럼은 의존적인 식별자 일부 칼럼과 함께 분리되어 새로운 개체(테이블)을 만든다.


제 3 정규형

제 3 정규형이란 하나의 실체가 제 2 정규형이면서, 어떠한 비식별자 속성들도 다른 비식별자속성에 함수적으로 종속되지 않는 형태이다.

예를들어, [그림4-15]의강아지실체에서개집이름과개집위치는개집 ID에함수적으로종속되므로, 이것은제3 정규형을위반하고있다. 따라서이속성들을별도의실체로분리하면[그림4-16]과같은제 3 정규형이만들어진다.



물리적 모델링

물리적모델링이란논리적모델링에대응되는모델링기법으로, 특정DBMS에의존하는데이터형식, 각종제약조건, 뷰, 인덱스등을설정하는작업이다. 물리적모델링의수행절차는 대략다음과같다.

❶ 이름영문화: 논리적모델에서는대부분한글이름을부여하는데, 물리적모델에서는이것을영

문이름으로바꿔야한다.

❷ 데이터형지정

❸ NULL, NOT NULL 및 IDENTITY 지정

❹ 제약기본값과개체기본값정의

❺ 체크와규칙정의

❻ 도메인정의및적용

❼ 인덱스설정

❽ 테이블별코멘트작성

❾ 뷰정의



Posted by linuxism
,


톰켓에서의 Connector 은 보통 2가지로 나뉜다.
HTTP Connector 와 JK Connector 

HTTP Connector 은 톰캣 혼자서(아파치 같은거 없이) 구동되어서 하나의 웹서버로서 활용 되기 위한 용도의 Connector 이다.

JK Connector 는 보통 AJP/1.3 프로토콜을 이용한 webserver 와 tomcat 의 연동을 위한 Connector 이다.

그럼 JK Connector 는 도대체 먼가 궁금 할것이다.

1. JK Connector

 JK Connector는 다양한 플랫폼을 지원하고, 아파치 웹서버 뿐만 아니라 Netscape/iPlanet, IIS 등도 지원하며, 뿐만 아니라 SSL을 지원하여 HTTP와 HTTPS 모두 사용 가능하다.

  웹서버와 연계하기 위한 모듈은 다음과 같다.

 - mod_jk : 아파치 웹서버 1.3 및 2.0과 연결하기 위한 모듈

- isapi   : IIS와 연결하기 위한 추가 모듈

- nsapi  : 넷스케이프/iPlanet과 연결하기 위한 추가 모듈

- dsapi : Domino와 연결하기 위한 추가 모듈. 하지만 이 모듈은 그리 좋은 성능을 제공하지는 못하다

 2. JK2  Connector

 JK2 Connector는 JK Connector를 재구성(Refactoring)해서 만든 Connector이다. 그러한 이유로 JK Connector와 매우 유사한 모습과 기능을 가지고 있지만 실질적으로 환경 구성에서는 약간의 차이를 보인다. 

JK2 Connector의 가장 큰 장점은 다양한 연결 방식을 제공한다는 점으로 매우 고성능의 유닉스 소켓과 함께 JDK 1.4에서 새로이 소개하고 있는 New I/O를 적용해서 사용할 수 있는 관계로 속도상의 향상을 도모할 수 있다.

이 Connector를 사용할 때에는 비록 JK2가 Apache 1.3을 지원하고 있긴 하지만 Apache 2.0을 대상으로 설계 되어졌다는 점이다.

 멀티 쓰레드 형태로 동작하는 IIS와 Netscape/iPlanet 그리고 아파치 2.0과의 연동시에는 JK Connector 보다 훨씬 좋은 성능을 제공한다.  

Apache 웹 서버는 멀티 쓰레드 기반의 웹서버가 아니다.

Apache 2.0만 멀티 쓰레드 기반으로 되어 있다. 이러한 이유로 단순 성능 비교시 유닉스에서 수행되는 Apache 웹 서버가 윈도우에서 돌아가는 IIS에 비해서 속도가 떨어진다.

또한 자바의 시스템 관리 기술인 JMX를 이용하여 웹서버와 톰캣의 연동 상황을 웹으로 보여줄 수 있는 상태 모듈이 포함되어 있다.

참고 : http://blog.naver.com/PostView.nhn?blogId=sj99yang&logNo=140002804249&redirect=Dlog&widgetTypeCall=true

자 그럼 Connector source 를 한번 볼까?

public class Connector implements Lifecycle, MBeanRegistration
다행이다ㅋ. 이놈은 interface 가 아니다. Likfecycle 과 MbeanRegistration 만 implements 한다. Mbean.... 나중에 책보고 한번더 정리가 필요 할것 같다. 아직도 JMX 기술에 대한 명확한 이해가 부족한것 같다.

API를 보면 너무나도 많은 Filed 가 있다. 하지만 이 모든것을 정리하기에는 시간적 여유가 너무나도 부족하다. 걍  슬쩍 훓어 보겠다.

- public Connector(String protocol)
Conntecor의 생성자 이다. 

Class clazz = Class.forName(protocolHandlerClassName);
this.protocolHandler = (ProtocolHandler) clazz.newInstance();

위 소스에서 보면 protocolHandlerClassName 이놈이 보인다.
따라가 보변 org.apache.coyote.http11.Http11Protocol 이놈이다.
다시 말해서 protocolHandler 로 Http11Protocol 클래스의 instance를 가지도록 한다는 의미가 된다. Http11Protocol  의 분석은 다음 글에 ....;;;

암튼 이놈은 default 로 setting 되어 있다.
하지만 method 중에서 setProtocol 이 있다.

if ("HTTP/1.1".equals(protocol)) {
              setProtocolHandlerClassName
                    ("org.apache.coyote.http11.Http11Protocol");
            } else if ("AJP/1.3".equals(protocol)) {
                setProtocolHandlerClassName
                    ("org.apache.jk.server.JkCoyoteHandler");
.....

이런 source 가 보인다.

즉 기본적으로는 http 프로토콜을 쓰지만 AJP/1.3 으로 JK connector 을 쓸수 있다.
그리고 이놈은 Server.xml 에서 정의 되어 있다.

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

앞서 적은 Digestor에서 이놈의 setting을 처리 하는 것이겠지? ㅋㅋㅋ
난중에 Digestor 도 한번더 보자.ㅋ


HTTP 1.1 의 특징(톰캣 최종 분석 참고)
 - 지속연결
   브라우저가 페이지 하나를 요청 하더라고 그 페이지 에서 참조하는 다른 자원도 함께 다운로드 해야 한다. 만약 참조하는 다른 자원에 대해서 각각 연결해서 다운하면 속도가 느려질수 밖에 없다. 따라서 HTTP 1.1 에서는 지속 연결(Persistent Connections)를 지원한다. 

 - 청크 인코딩
 HTTP 1.1. 에서는 transfer-encoding 이라는 특별한 해더가 추가됐는데, 이 해더는 바이트 스트림이 청크(chunk)단위로 전송 될것임을 가리킨다. 모든 청크에서는 실제 데이터가 전송되기 전에 16진수로 된 길이 값과 케리지 리턴/개행문자가 먼저 전송된다. 청크의 길이가 0 이면 하나의 트랜잭션이 종료 된다.

 - 100(Continue) 상태 코드 사용
Expect : 100 -continue 헤더를 전송해 요청 본체를 전송하기 앞서 서버측의 승인을 기다리는 것이다. 이 방법은 클라이언트가 전송하고자 하는 요청 본체의 양이 많을 경우 서버가 이를 받아들일수 있는지를 먼저 확인하고자 할때 사용된다.

출처 - http://interwater.tistory.com/31


===================================================================================























Posted by linuxism
,


안녕하세요..

 

오늘 살펴볼 주제는 Tomcat 의 log 관련설정법입니다.

 

많은 개발자들이 개발환경으로 Tomcat 을 많이 사용하고 있습니다. 그리고 log 처리는 log4j를 사용합니다.

그러나 JDK에서 기본으로 제공하는 Logging 클래스도 꽤 쓸만한 기능을 제공하고 있습니다.


java.util.logging 추상 클래스가 바로 그것인데요, 이 클래스를 상속받아 구현한 클래스를 줄여서 JULI 라고 부릅니다.

 

운영시에야 효율을 위해 최소한의 로그를 남기는것이 좋겠지만, 반대로 개발시에는 최대한의 많은 로그를 남기는것이 디버깅에 효과적입니다.

 

1. logging.properties의 위치

 a) 기본적인 Global 설정은 tomcat 디렉토리의 conf 입니다.

  - 이곳에 파일을 두고 설정하면 해당 컨테이너에 등록되는 모든 Application설정을 한방에 할수 있습니다.

 b) Application 별로 설정하고 싶다면, /WEB-INF/classes/ 밑에 logging.properties 를 두면 됩니다.

 

2. 설정방법

- 기본적으로 제공하는 핸들러는 java.util.logging.FileHandler 와 java.util.logging.ConsoleHandler 가 있습니다.

- java.util.logging.ConsoleHandler 는 기본출력 (catalina.out)으로 출력하는 핸들러이고,

- java.util.logging.FileHandler 는 날짜별로 롤링되는 특정파일에 출력하는 핸들러입니다.

- level 은 다음과 같이 ALL, FINEST, FINER, FINE, CONFIG, INFO, WARNING, SEVERE를 지원하며

- 오늘쪽으로 갈수록 로그량이 적습니다.

 

3. 설정예제

- org.apache.tomcat.util.net.TcpWorkerThread 클래스에 대해서 로그를 추가하고 싶을때

ex)
org.apache.tomcat.util.net.TcpWorkerThread.level = ALL
org.apache.tomcat.util.net.TcpWorkerThread.handler = java.util.logging.ConsoleHandler

 

- org.apache.tomcat.util.net 하위 클래스에 대해서 로그를 추가하고 싶을때

ex)
org.apache.tomcat.util.net.level = ALL
org.apache.tomcat.util.net.handler = java.util.logging.ConsoleHandler

 

이런식으로 로깅하고 싶은 클래스 또는 패키지를 지정해서 .level = XXX , .handler = java.util.logging.ConsoleHandler 를 달아주기만 하면 됩니다.

 

참 쉽죠~?


출처 - http://cafe.naver.com/hermeneus.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=98&


===================================================================================



tomcat 로그 저장 위치 변경 하기


tomcat logs 디렉토리(${catalina.base}/logs)에 저장되는 로그는 아래와 같은 곳에서 설정이 가능합니다.


- catalina.out 

  ${catalina.base}/bin/catalina.sh


- host-manager, localhost, manager

  ${catalina.base}/conf/logging.properties


- localhost_access_log

  ${catalina.base}/conf/server.xml



로그 저장 위치를 원하는 곳으로 변경 하는 방법은 두가지로 생각해 볼 수 있습니다.


첫번째는 logging.properies, catalina.sh, server.xml 등에서 디렉토리를 변경하는 방법이고

두번째는 ${catalina.base}/logs 디렉토리를 원하는 디렉토리로 soft link 시키는 방법입니다.



1. 각 설정에서 logging 디렉토리 변경

# vi /usr/local/tomcat/conf/logging.properties


변경 전

1catalina.org.apache.juli.FileHandler.level = FINE

1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs

1catalina.org.apache.juli.FileHandler.prefix = catalina.


변경 후

1catalina.org.apache.juli.FileHandler.level = FINE

1catalina.org.apache.juli.FileHandler.directory = /var/log/tomcat

1catalina.org.apache.juli.FileHandler.prefix = catalina.


# vi /user/local/tomcat/bin/catalina.sh


변경 전

if [ -z "$CATALINA_OUT" ] ; then

  CATALINA_OUT="$CATALINA_BASE"/logs/catalina.out

fi

변경 후

if [ -z "$CATALINA_OUT" ] ; then

  CATALINA_OUT=/var/log/tomcat/catalina.out

fi


# vi /user/local/tomcat/conf/server.xml


변경 전

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt"

pattern="%h %l %u %t &quot;%r&quot; %s %b" />

변경 후

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="/var/log/tomcat" prefix="localhost_access_log." suffix=".txt"

pattern="%h %l %u %t &quot;%r&quot; %s %b" />




2. ${catalina.base}/logs 디렉토리를 원하는 디렉토리로 soft link 

# ln -s /var/log/tomcat /usr/local/tomcat/logs






'Web > WAS' 카테고리의 다른 글

톰캣 앞에 아파치 웹 서버(Httpd)를 두어야 할까?  (0) 2012.05.08
톰캣(tomcat) Connector 설정  (0) 2012.04.05
tomcat - root가 아닌 tomcat 계정으로 실행  (0) 2012.04.04
was - web.xml 설명  (0) 2012.02.12
mod_jk 사용법  (0) 2012.02.10
Posted by linuxism
,