반응형

- 모델링의 정의

  복잡한 현실세계를 일정한 표기법(추상화, 단순화, 명확화) 에 의해 표현하는일

 

- 모델링의 특징

  1) 추상화 : 현실세계를 일정한 형식에 맞추어 표현하는 것

  2) 단순화 : 복잡한 현실세계를 약속된 규약에 의해 쉽게 이해할 수 있도록 표현하는 것

  3) 명확화 : 누구나 이해하기 쉽게 정확하게 표현하는 것

 

- 모델링의 3가지 관점 

  1) 데이터관점(Data, What) : 어떤데이터와 관련있는지 데이터간의 관계는 무엇인지 모델링

  2) 프로세스 관점(Process, How) : 업무가 실제하고 있는 일은 무엇인지 무엇을 해야하는지 모델링

  3) 상관관점(Data vs Process) : 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받는지 모델링

 

- 데이터 모델링의 정의

  정보시스템을 구축하기 위한 데이터관점의 업무분석

  현실세계의 데이터에 대해 약속된 표기법에 의해 표현하는 과정

  데이터베이스를 구축하기 위한 분석/설계의 과정

 

- 데이터 모델이 제공하는 기능

   · 시스템을 현재 원하는 모습으로 가시화하도록 도와준다.

   · 시스템의 구조와 행동을 명세화 할 수 있게 한다.

   · 시스템을 구축하는 구조화된 틀을 제공한다.

   · 시스템을 구축하는 과정에서 결정한 것을 문서화한다.

   · 다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 다양한 관점을 제공한다.

   · 특정 목표에 따라 구체화된 상세 수준의 표현방법을 제공한다.

 

- 데이터 모델링의 중요성 및 유의점

  1) 파급효과

   시스템 구축이 완성되어 가는 시점에서 데이터 모델의 변경이 불가피한 상황이 발생한다면

   데이터 구조의 변경으로 전체시스템 구축 프로젝트에서 큰 위험요소이므로 다른 어떤 설계 과정보다 데이터 설계가       더 중요하다고 볼 수 있다.

  2) 복잡한 정보 요구사항의 간결한 표현

  3) 데이터 품질

    중복 데이터의 미정의 - 중복 데이터 모델은 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다. 

    데이터 구조의 비즈니스 정의의 불충분 - 비유연성 데이터 모델은 유지보수의 어려움을 가중시킬 수 있다.

    동일한 성격의 데이터를 통합하지 않고 분리함으로써의 나타나는 데이터 불일치 - 데이터와 데이터 간 상호 연관관계에 대한 명확한 정의는 이러한 위험을 사전에 예방할 수 있다.

 

- 데이터 모델링의 3단계

 현실세계(개체) ->  개념적 데이터모델링 -> 논리적 데이터모델링 -> 물리적 데이터모델링 -> 저장 데이터베이스

1) 개념적 데이터 모델링

    추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링 진행, 전사적 데이터 모델링, EA수립시 많이 이용

2) 논리적 데이터 모델링

    시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현, 재사용성이 높음

    "논리 데이터 모델은 데이터 모델링이 최종적으로 완료된 상태라고 정의, 즉 물리적인 스키마 설계를 하기 전 단계의       '데이터 모델' 상태를 일컫는 말"

    "누가, 어떻게, 그리고 전산화와는 별개로 비즈니스 데이터에 존재하는 사실들은 인식하여 기록하는 것"

    " 데이터 모델링 과정에서 가장 핵심이 되는 부분, ERD라는 그림으로 그려내는 과정"

    " 이 단계에서 수행하는 중요한 활동은 정규화"

 

3) 물리적 데이터 모델링

    실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계

    "테이블, 칼럼 등으로 표현되는 물리적인 저장 구조와 사용될 저장 장치, 자료를 추출하기 우해 사용될 접근방법 등"

 

- 프로젝트 생명주기(Life Cycle)에서 데이터 모델링

  일반적으로는 계획 또는 분석단계에서 개념적 데이터 모델링, 분석단계에서 논리적 데이터 모델링, 설계단계에서

  물리적 데이터 모델링이 수행된다.

 

- 데이터 모델링에서 데이터독립성의이 이해

1) 데이터독립성의 필요성

   유지보수 비용 증가, 데이터 복잡도 증가, 데이터 중복성 증가, 요구사항 대응 저하

    -> 끊임없이 요구되는 사용자 요구사항에 대해 화면과 데이터베이스 간에 서로 독립성을 유지하기 위한 목적

 

2) 데이터베이스 3단계 구조

   외부 단계(외부스키마)          <->        개념적 단계(개념스키마)           <->           내부 단계(내부스키마) 

                                논리적 데이터독립성                           물리적 데이터독립성

    · 외부 단계 : 사용자 관점으로 접근하는 특성에 따른 스키마 구성

    · 개념적 단계 : 통합관점

    · 내부 단계 : 물리적 저장구조  

 

3) 데이터독립성 구성요소

  · 외부스키마(External Schema)

     - View 단계 여러개의 사용자 관점으로 구성, 즉, 개개 사용자 단계로서 개개 사용자가 보는 개인적 DB스키마 

     - DB의 개개 사용자나 응용프래머가 접근하는 DB정의

 

  · 개념스키마(Conceptual Schema) 

    - 개념단계 하나의 개념적 스키마로 구성 모든 사용자 관점을 통합한 조직 전체의 DB를 기술하는 것

    - 모든 응용시스템들이나 사용자들이 필요로 하는 데이터를 통합한 조직 전체의 DB를 기술한 것으로 DB에 저장되는        데이터와 그들관의 관계를 표현하는 스키마

 

  · 내부스키마(Internal Schema) 

    - 내부단계, 내부스키마로 구성, DB가 물리적으로 저장된 형식

    - 물리적 장치에서 데이터가 실제적으로 저장되는 방법을 표현하는 스키마

 

4) 두 영역의 데이터독립성

독립성 내용 특징
논리적 독립성 개념 스키마가 변경되어도 외부 스키마에는 영향을 미치지 않도록 지원하는 것
논리적 구조가 변경되어도 응용프로그램에 영향 없음
사용자 특성에 맞는 변경가능
통합구조 변경가능
물리적 독립성 내부스키마가 변경되어도 외부/개념 스키마는 영향을 받지 않도록 지원하는 것
저장장치의 구조변경은 응용프로그램과 개념스키마에 영향없음
물리적 구조 영향없이 개념구조 변경 가능
개념구조 영향 없이 물리적인 구조 변경가능

5) 사상(Mapping)

   · 외부적/개념적 사상(논리적 사상) : 외부적 뷰와 개념적 뷰의 상호 관련성을 정의

               즉, 외부 화면이나 사용자에게 인터페이스 하기 위한 스키마 구조는 전체가 통합된 개념적 스키마와 연결됨

   · 개념적/내부적 사상(물리적 사상) : 개념적 뷰와 저장된 데이터베이스의 상호관련성 정의 

                즉, 통합된 개념적 스키마 구조와 물리적으로 저장된 구조의 물리적인 테이블스페이스와 연결되는 구조

 

- 데이터 모델링의 중요한 세가지 개념

1) 데이터 모델링의 세가지 요소

   · 업무가 관여하는 어떤 것(Things) : 모든 사람,사물, 개념

   · 어떤 것이 가지는 성격(Attributes) 

   · 업무가 관여하는 어떤 것 간의 관계 (Relationships)

 

2) 단수와 집합(복수)의 명명

개념 복수/집합개념 개별/단수개념
어떤것(Things) 엔터티 타입(Entity Type) 엔터티(Entity)
엔터티(Entity) 인스턴스(Instance), 어커런스(Occurrence)
어떤 것간의 연관 관계(Relationship) 패어링(Pairing)
어떤것의 성격 속성(Attribute) 속성값(Attribute Value)

 

- 데이터 모델링의 이해관계자

  데이터 모델링 기술/이해에 있어서 프로젝트 개발자 (가장 중요함) , 현업업무전문가 (이해할 수 있는 수준) , DBA 등

 

-데이터 모델의 표기법인 ERD의 이해

1) 데이터 모델 표기법

 데이터 모델에 대한 표기법으로 1976년 피터첸이 Entity-relationship model(E-R Model)이라는 표기법을 만듦

 [Chen 표기법] 엔터티는 사각형, 관계는 마름모, 속성은 타원형

  [IE표기법]

  [Barker 표기법]

&amp;amp;amp;amp;amp;nbsp;&amp;amp;amp;amp;amp;nbsp;

2) ERD(Entity Relationship Diagram) 표기법을 이용하여 모델링하는 방법

 - ERD 작업 순서

   1. 엔터티를 그린다.

   2. 엔터티를 적절하게 배치한다.

   3. 엔터티간 관계를 설정한다.

   4. 관계명을 기술한다. 

   5 관계의 참여도를 기술한다.

   6. 관계의 필수여부를 기술한다.

 

- 엔터티 배치

   1. 가장중요한 엔터티를 왼쪽상단에 배치하고 이것을 중심으로 다른 엔터티를 나열하면서 전개.

      해당 업무에서 가장 중요한 엔터티는 왼쪽 상단에서 조금 아래쪽 중앙에 배치하여 전체 엔터티와 어울릴 수 있도록

      하면 향후 관계를 연결할떄 선이 꼬이지 않고 효과적으로 배치 가능 ex) 고객, 주문

   2. 업무흐름에 중심이 되는 엔터티는 타 엔터티와 많은 관게를 가지고 있으므로 중앙에 배치

      ex) 주문, 출고, 주문목록, 출고목록

   3. 업무를 진행하는 중심이 되는 엔터티와 관계를 갖는 엔터티들은 중심에 배치된 엔터티들 주위에 배치. 

      ex) 창고,고객, 사원,재고

 

- ERD 관계의 연결

  엔터티 배치가 되면 서로 관련있는 엔터티간에 관계를 설정, 초기에는 모두 Primary Key로 속성이 상속되는 식별자 계를 설정하고 중복되는 관계가 발생하지 않도록 함

 

- ERD 관계명 표시

  관계설정이 완료되면 관계이름을 부여하고 이름은 현재형을 사용, 지나치게 포괄적인 용어는 사용하지 않도록 한다.

  ex) 주문하다, 접수하다, 포함하다, 포함된다

 

- ERD 관계 관계차수와 선택상 표시

  관계이름 지정 후 얼마나 관계에 참여하는지를 나타내는 관계차수(Cardinality) 를 표현

  IE표기법으로는 하나(1,One)의 관계는 실선으로 표기, Barker표기법으로는 점선과 실선을 혼합하여 표기

  다수참여의 관계는 까마귀발과같은 모양으로 그려줌.

  필수/선택 표시는 관계선에 원을 표현

 

-좋은 데이터 모델의 요소

1)  완전성(Completeness) : 업무에서 필요로 하는 모든 데이턱 데이터 모델에 정의 되어 있어야 한다. 

2) 중복배제(Non-Redundancy) : 하나의 데이터베이스 내에 동일한 사실은 반드시 한번만 기록하여야 한다.

3) 업무규칙(Business Rules) : 데이터모델에서 중요한 요소 중 하나가 데이터 모델링 과정에서 도출되고 규명되는 수많은 업무규칙을 데이터 모델에 표현하고 이를 해당 데이터 모델을 사용하는 모든 사용자가 공유할 수 있도록 제공하는 것

4) 데이터 재사용(Data Reusablity) : 데이터의 재사용성을 향상시키고자 한다면 데이터의 동합성과 독립성에 대해서 충분히 고려해야함, 통합모델이여야만 데이터 재사용성을 향상 시킬 수 있음, 데이터가 애플리케이션에 대해 독립적으로 설계되어야만 재사용을 향상시킬 수 있음.

5) 의사소통(Communication) : 많은 업무 규칙들을 해당 정보시스템을 운용, 관리하는 많은 관련자들이 설계자가 정의한 업무 규칙들을 동일한 의미로 받아들이는 역할 을 하면 진정한 의사소통의 역할 

6) 통합성(Integration) : 가장 바람직한 데이터 구조의 형태는 동일한 데이터는 조직의 전체에서 한번만 정의되고 이를 다른 영역에서 참조, 활용하는 것

 

-엔터티의 개념

 엔터티 : 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것(Thing) 또는 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서 그 대상들 간에 동질성을 지닌 인스턴스 들이나 그들이 행하는 행위의 집합

(인스턴스 : 엔터티의 하나의 값 -> 엔터티는 인스턴스의 집합 ex) 인스턴스 : 수학,과학,영어,국어 /  엔티티 : 과목 )

  · 사람, 장소, 물건, 사건, 개념등의 명사에 해당 (눈에  보이지 않는 개념 등도 해당)

  · 업무상 관리가 필요한 관심사에 해당

  · 저장이 되기위한 어떤것

ex) 과목, 강사, 사건....

 

- 엔터티와 인스턴스에 대한 내용과 표기법

  대부분 사각형으로 표현

- 엔터티의 특징

  1) 업무에서 필요로 하는 정보

  2) 식별이 가능해야 함( 유일한 식별자 : 그 엔터티의 인스턴스만의 고유한 이름

                                 ex) 이름은 동명이인이 되므로 유일하게 식별불가능, 사원번호는 식별자 )

  3) 영속적으로 존재하는 인스턴스의 집합('한 개' 가 아니라 '두개 이상')

      : 하나의 엔터티는 여러개의 인스턴스를 포함 ex) 인스턴스가 한개밖에 없으면 집합이 아니므로 엔터티 성립x

  4) 업무프로세스에 의해 이용

  5) 속성을 포함( 반드시 속성이 있어야 함) 

     예외적으로 관계엔터티의 경우는 주식별자 속성만 가지고 있어도 엔터티로 인정

  6) 관계의 존재 (다른 엔터티와 최소 한개 이상의 관계가 있어야 함)

 

- 엔터티의 분류

  1) 유무형에 따른 분류

    · 유형엔터티 : 물리적 형태 ex) 사원, 물품, 강사 등

    · 개념엔터티 : 물리적인 형태는 존재하지 않고 관리해야 할 개념적 정보 ex) 조직, 보험상품 등

    · 사건엔터티 : 업무를 수행함에 따라 발생하는 엔터티  ex) 주문, 청구, 미납 등

  2) 발생시점에 따른 분류

     · 기본/키엔터티(Fundamental Entity, Key Entity) : 기본엔터티란 그 업무에 원래 존재하는 정보로서 다른 엔터티와 관계에 의해 생성되지 않고 독립적으로 생성이 가능하고 자신은 타 엔터티의 부모역할을 함, 자신의 고유한 주식별자를 가짐 ex) 사원, 부서, 고객, 상품, 자재 등

     · 중심엔터티(Main Entity) :  기본 엔터티로부터 발생되고 그 업무에 있어서 중심 역할을 함, 데이터의 양이 많이 발생되고 다른 엔터티와의 관계를 통해 많은 행위엔터티를 생성 ex) 계약, 사고, 예금원장, 청구, 주문 매출 등

     · 행위엔터티(Active Entity) : 두개 이상의 부모엔터티로부터 발생되고 자주내용이 바뀌거나 데이터량이 증가 ex) 주문목록, 사원변경이력

 

  3) 엔터티 분류 방법의 예

    유무형에 따라... 유형, 사건, 개념

    발생시점에 따라... 기본/키 , 중심, 행위

 

- 엔터티의 명명

  첫 번째, 가능하면 현업업무에서 사용하는 용어를 사용한다.

  두 번째, 가능하면 약어를 사용하지 않는다.

  세 번째, 단수명사를 사용한다.

  네 번째, 모든 엔터티에서 유일하게 이름이 부여되어야 한다.

  다섯 번째,  엔터티 생성의미대로 이름을 부여한다.

 

 - 속성의 개념

    업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소한의 데이터 단위

     ex) 이름, 주소, 생년월일, 계약일자, 전문분야

     · 업무에서 필요로 한다.

     · 의미상 더 이상 분리되지 않는다.

     · 엔터티를 설명하고 인스턴스의 구성요소가 된다

 

- 엔터티, 인스턴스와 속성, 속성값에 대한 내용과 표기법

  1) 엔터티, 인스턴스, 속성, 속성값의 관계

    ·  한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 한다

    ·  한개의 엔터티는 두개 이상의 속성을 갖는다.

    ·  한 개의 속성은 한 개의 속성값을 갖는다.

  2) 속성의 표기법

  엔터티 내에 이름을 포함하여 표현

  ex) 엔터티 - 과목      / 강사       / 사건

       속성 - 과목이름  / 강사이름  /사건이름

 

- 속성의 특징

  · 엔터티와 마찬가지로 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야한다. ex) 강사의 교재이름

  · 정규화 이론에 근간하여 정해진 주식별자에 함수적 종속성을 가져야한다.

  ·  하나의 속성에는 한개의 값만 가진다. 하나의 속성에 여러 개의 값이 있는 다중 값을 경우 별도의 엔터티틑 이용하여 분리한다.

  

- 속성의 분류

  1) 속성의 특성에 따른 분류

    · 기본속성(Basic Attribute) : 업무분석을 통해 바로 정의 한 속성, 업무로부터 추출한 모든 속성이 해당 ex) 제품이름

    · 설계속성(Designed Attribute) : 원래 업무상 존재하지는 않지만 설계를 하면서 도출해내는 속성, 데이터 모델링을 위해 또는 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성 ex) 일련번호

   · 파생속성(Derived Attribute) : 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성 ex) 계산된 값

     데이터 정합성을 유지하기 위해 유의해야 할 점이 많으며 가급적 파생속성을 적게 정의하는 것이 좋다.

 

  2) 엔터티 구성방식에 따른 분류

   · PK(Primary Key) 속성 : 엔터티를 식별할 수 있는 속성

   · FK(Foreign Key) 속성 : 다른 엔터티와의 관계에서 포함된 속성

   · 일반속성 : PK,FK에 포함되어 있지 않은 속성

   

   · 복합 속성(Composite Attribute) : 여러 세부속성들로 구성되는 속성   ex) 주소 속성(시,구,동,번지)

   · 단순 속성(Simple Attribute) : 더 이상 다른 속성들로 구성될 수 없는 속성   ex) 나이, 성별

 

 

- 도메인 : 각 속성이 가질 수 있는 값의 범위

             엔터티 내에서 속성에 대한 데이터 타입과 크기 그리고 제약사항을 지정하는 것

  ex) 학생이라는 엔터티가 있을 때 학점이라는 속성의 도메인은 0.0 에서 4.0 사이의 실수 값이며

       주소라는 속성은 길이가 20자리 이내인 문자열로 정의 

 

- 속성의 명명

첫 번째, 해당업무에서 사용하는 이름을 부여한다.

두 번째, 서술식 속성명은 사용하지 않는다.

세 번째, 약어사용은 가급적 제한한다.

네 번째, 전체 데이터모델에서 유일성 확보하는 것이 좋다.

 

- 관계의 개념

  1) 관계의 정의 : 인스턴스 사이의 논리적인 연관성으로서 존재 또는 행위로서 서로에게 연관성이 부여된 상태

                       관계는 엔터티와 엔터티 간 연관성이므로 엔터티의 정의에 따라 영향을 받기도 함

  2) 관계의 패어링 : 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것

       각각의 엔터티의 인스턴스들은 자신이 관련된 인스턴스들과 관계의 어커런스로 참여하는 형태를 관계 패어링

       (Relationship Paring)이라 한다.

 

- 관계의 분류

  연관관계(Association)와 의존관계(Dependeny)

  : 연관관계는 항상 이용하는 관계로 표현방법은 실선,

   의존관계는 상대방클래스의 행위에 의해 관계가 형성될 때 구분하여 표현, 표현방법은 점선

 

- 관계의 표기법

  1) 관계명(Membership) : 관계의 이름

      관계가 시작되는 편 - 관계시작점 , 관계를 받는 편 - 관계끝점

      관계의 시작점과 끝점 모두 관계이름을 가져야 하며 참여자의 관점에 따라 관계이름이 능동적이거나 수동적으로

      명명된다. 

     · 애매한 동사 피하기 ex) 관계된다, 관련이 있다 등은 구체적이지 않음

     · 현재현으로 표현하기 ex) 수강을 신청했다, 강의를 할 것이다. 표현 x -> 수강 신청한다. 

  2) 관계차수(Cardinality) : 1:1 , 1:M , M:M

  3) 관계선택사양(Optionality) : 참여하는 엔터티가 항상 참여하는지 아니면 참여할 수도 있는지를 나타내는 방법으로                                             필수(Mandatory)관계와 선택(Optional)관계이다 ex) 주문서와 주문목록 - 필수참여

                                                                                                            목록과 주문목록 - 선택참여 

      관계선택사양은 관계를 통한 상대방과의 업무적인 제약조건을 표현하는 것으로서 간단하면서 아주 중요한 표기법

 

- 관계의 정의 및 읽는 방법

   · 관계 체크사항  

    두 개의 엔터티 사이에 관심있는 연관규칙이 존재하는가?

    두 개의 엔터티 사이에 정보의 조합이 발생되는가?

    업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?

    업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?

 

   · 관계 읽기

     1. 기준(Source) 엔터티를 한 개(One) 또는 각(Each)으로 읽는다.

     2. 대상(Target) 엔터티의 관계참여도 즉 개수(하나, 하나 이상)를 읽는다

     3. 관계선택사양과 관계명을 읽는다

 

- 식별자의 개념 

  하나의 엔터티에 구성되어 있는 여러개의 속성 중에 엔터티를 대표 할 수 있는 속성

  ( 엔터티내에서 인스턴스들을 구분할 수 있는 구분자)

  반드시 하나의 유일한 식별자가 존재해야함 

 

- 식별자의 특징

  주식별자의 특징

  1) 주식별자에 의해 엔터티내에 모든 인스턴스들이 유일하게 구분되어야 한다  - 유일성

  2) 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다. - 최소성

  3) 지정된 주식별자의 값은 자주 변하지 않는 것이여야 한다. - 불변성

  4) 주식별자가 지정이 되면 반드시 값이 들어와야 한다. - 존재정 

 

 외부식별자의 특징 : 주식별자 특징과 일치하지 않으며 참조무결성 제약조건에 따른 특징을 가짐

 

- 식별자 분류 및 표기법

  1) 식별자 분류

  대표성 여부 - 주식별자, 보조식별자

  스스로 생성 여부 - 내부식별자(엔터티내부 스스로 만들어지는 식별자), 외부식별자(타 엔터티로부터 받아오는 식별자)

  속성의 수 - 단일 식별자, 복합식별자

  대체여부 - 본질식별자(업무에 의해 만들어지는 식별자), 인조식별자 ( 예를들어 주문번호= 사번+주문일자+순번)

   [ 식별자의 분류체계] 

분류 식별자 설명
대표성 여부 주식별자 엔터티내에서 각 어커런스를 구분 할 수 있는 국분자이며, 타 엔터티와 참조관계를 연결 할 수 있는 식별자
보조식별자 엔터티 내에서 각 어커런스를 구분할 수 있는 구분자이나 대표성을 가지지 못해 참조고관계 연결을 못함
스스로의 생성여부 내부식별자 엔터티 내부에서 스스로 만들어지는 식별자
외부식별자 타 엔터티와의관계를 통해 타 엔터티로부터 받아오는 식별자
속성의 수 단일식별자 하나의 속성으로 구성된 식별자
복합식별자 둘 이상의 속성으로 구성된 식별자
대체여부 본질식별자 업무에 의해 만들어지는 식별자
인조식별자 업무적으로 만들어지지는 않지만 원조식별자가 복잡한 구성을 가지고 있기 때문에 인위적으로 만든 식별자

 

  2) 식별자 표기법

- 주식별자 도출기준

  해당 업무에서 자주 이용되는 속성을 주식별자로 지정, 명칭이나 내역 등과 같이 이름으로 기술되는 것들은 가능하면    주식별자로 지정하지 않음, 복합으로 주식별자로 구성할 경우 너무 많은 속성이 포함되지 않도록 함

 

- 식별자 관계와 비식별자관계에 따른 식별자

  1) 식별자관계와 비식별자 관계의 결정

     외부식별자(Foreign Identifier) : 자기 자신의 엔터티에서 필요한 속성이 아니라 다른 엔터티와의 관계를 통해 자식                                                  쪽에 엔터티에 생성되는 속성 - FK역할

     이때 자식엔터티에서 부모엔터티로부터 받은 외부식별자를 자신의 주식별자로 이용할 것인지 또는 부모와 연결되         는 속성으로 사용할 것인지를 결정

  2) 식별자 관계

     자식엔터티의 주식별자로 부모의 주식별자가 상속이 되는 경우

  3) 비식별자 관계

      부모엔터티로부터 속성을 받았지만 자식엔터티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 경우

      비식별자 관계에 의한 외부식별자 생성

      · 자식엔터티에서 받은 속성이 반드시 필수가 아니어도 무방하기 때문에 부모없는 자식이 생성될수 있는 경우 

      ·  엔터티별로 데이터의 생명주기(Life Cycle)을 다르게 관리할 경우, 자식만 남겨두고 먼저 소멸될 수 있는 경우

      ·  여러개의 엔터티가 하나의 엔터티로 통합되어 표현되었는데 각각의 엔터티가 별도의 관계를 가질때

      ·  자식 엔터티에서 별도의 주식별자를 생성하는 것이 더 유리하다고 판단 될때 표현

  4) 식별자 관계로만 설정할 경우의 문제점

                                                                   식별자 관계 

      식별자 관계로 인해 증가된 PK 속성의 수 : 식별자 관계만으로 연결된 데이 터 모델의 특징은 주식별자 속성이

      지속적으로 증가할 수 밖에 없는 구조로서 개발자 복잡성과 오 류가능성을 유발시킬 수 있는 요인이 될 수 있다

      (SQL 구문의 WHERE 절이 매우 길어짐)

  5) 비식별자 관계로만 설정할 경우의 문제점

    자식엔터티에서 데이터를 처리할 때 쓸데없이 부모엔터티까지 찾아가야 하는 경우가 발생됨

    ex) 단순하게 걸리는 하나의 조회조건도 비식별자 관계로만 데이터 모델링을 전개하면 SQL구문에 많은 조인이 걸리게 되는데 주식별자 속성을 상속받음으로 인해 자식엔터티에서 바로 조회의 조건을 이용하여 원하는 정보 가져올 수 있음, 성능과 개발의 용이성 측면에서는 식별자 관계가 우위에 있음

  6) 식별자 관계와 비식별자관계 모델링

항목 식별자 관계 비식별자 관계
목적 강한 연결관계 표현 약한 연결관계 표현
자식 주식별자 영향 자식 주식별자의 구성에 포함됨 자식 일반 속성에 포함됨
표기법 실선표현 점선 표현
연결 고려사항 - 반드시 부모엔터티 종속
- 자식 주식별자 구성에 부모 주식별자 포함 필요
- 상속받은 주식별자속성을 타 엔터티에 이전 필요
- 약한 종속관계
- 자식 주식별자구성을 독립적으로 구성
- 자식 주식별자구성에 부모 주식별자 부분 필요
- 상속받은 주식별자 속성을 타 데이터에 차단 필요
- 부모쪽의 관계참여가 선택관계 

 

 

 

 

+ Recent posts