ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • SQLD 1장 - 데이터 모델의 이해
    독서 및 기타 활동 2020. 5. 11. 17:33

    데이터 모델의 유의사항

     

    중복(Duplication)

     

    - 데이터 모델은 같은 데이터를 사용하는 사람, 시간, 그리고 장소를 파악하는데 도움을 준다.

    ex) 데이터베이스가 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다.

     

    비유연성(Inflexibility)

     

    - 데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무변화에도 데이터 모델이 수시로 변경됨으로써 유지보수의 어려움을 가중시킬 수 있다.

    - 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.

     

    비일관성(Inconsistency)

     

    - 데이터의 중복이 없더라도 비일관성은 발생할 수 있는데, 예를 들면 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보를 갱신하는 경우이다. 개발자가 서로 연관된 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수 있기 때문에 이와 같은 문제가 발생할 수 있다.

    - 데이터 모델링을 할 때 데이터와 데이터 간의 상호 연관 관계에 대해 명확하게 정의한다면 이러한 위험을 사전에 예방하는데 도움을 줄 수 있다.

     

     

     

    데이터 모델링의 3단계 진행

     

    개념적 데이터 모델링

     

    - 추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링 진행

    - 전사적 데이터 모델링, EA수립시 많이 이용

     

    논리적 데이터 모델링

     

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

    - 재사용성이 높음

     

    물리적 데이터 모델링

     

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

     

     

     

    엔터티의 분류

    유무형에 따른 분류

     

    유형엔터티(Tangible Entity)

     

    - 물리적인 형태가 있고 안정적이며 지속적으로 활용되는 엔터티로 업무로부터 엔터티를 구분하기가 가장 용이

    - ex) 사원, 물품, 강사 등

     

    개념엔터티(Conceptual Entity)

     

    - 물리적인 형태는 존재하지 않고 관리해야 할 개념적 정보로 구분이 되는 엔터티

    - ex) 조직, 보험상품 등

     

    사건엔터티(Event Entity)

    - 업무를 수행함에 따라 발생되는 엔터티로서 비교적 발생량이 많으며 각종 통계자료에 이용될 수 있음

    - ex) 주문, 청구, 미납 등

     

     

    발생시점에 따른 분류

     

    기본엔터티

     

    - 그 업무에 원래 존재하는 정보로서 다른 엔터티와 관계에 의해 생성되지 않고 독립적으로 생성이 가능하고 자신은 타 엔터티의 부모의 역할을 하게 된다.

    - 다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가지게 된다.

    - ex) 사원, 부서, 고객, 상품, 자재 등

     

    중심엔터티

     

    - 기본엔터티로부터 발생되고 그 업무에 있어서 중심적인 역할을 한다.

    - 데이터의 양이 많이 발생되고 다른 엔터티와의 관계를 통해 많은 행위엔터티를 생성한다.

    - ex) 계약, 사고, 예금원장, 청구, 주문, 매출 등

     

    행위엔터티

     

    - 두 개 이상의 부모엔터티로부터 발생되고 자주 내용이 바뀌거나 데이터량이 증가된다.

    - 분석초기 단계에서는 잘 나타나지 않으며 상세 설계단계나 프로세스와 상관모델링을 진행하면서 도출될 수 있다.

    - ex) 주문목록, 사원 변경이력 등

     

     

     

    엔터티의 명명 규칙

     

    - 가능하면 현업업무에서 사용하는 용어를 사용

    - 가능하면 약어를 사용하지 않는다.

    - 단수명사를 사용

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

    - 엔터티 생성의미대로 이름을 부여한다.

     

     

     

    관계의 분류

     

    존재에 의한 관계

     

    - ex) 사원은 부서에 항상 속해있다.

    - UML 클래스다이어그램의 연관관계(Association)에 해당(실선으로 표현, 멤버변수)

     

    행위에 의한 관계

     

    - ex) 주문은 고객이 주문을 할 때 발생된다.(행위에 의해 관계가 형성됨)

    - UML 클래스다이어그램의 의존관계(Dependency)에 해당(점선으로 표현, 파라미터)

     

     

     

    관계의 표기법

     

    관계명(Membership)

     

    - 관계의 이름

    - 엔터티가 관계에 참여하는 형태

    - 각각의 관계는 두 개의 관계명을 가지고 있다.(관계시작점과 관계끝점 모두 있어야함)

    - 관계명 명명규칙

    • 애매한 동사를 피한다 ex) 관계된다, 관련이 있다 등 X
    • 현재형으로 표현한다 ex) 수강을 신청했다, 강의를 할 것이다 등 X

     

    관계차수(Cardinality)

     

    - 두 개의 엔터티간 관계에서 참여자의 수를 표현하는 것

    - 1:1, 1:M, M:N

     

    관계선택사양(Optionality)

     

    - 필수참여관계(Mandatory) : ex) 지하철문닫힘 - 지하철출발 

    - 선택참여관계(Optional) : ex) 지하철 안내방송 - 지하철출발

    - 필수참여 잘못 지정하면 데이터가 발생할때 반드시 한 개의 트랜잭션으로 제어해야 하는 제약사항이 발생

    - ERD에서 관계를 나타내는 선에서 선택참여하는 엔터티 쪽을 원으로 표시, 필수 참여는 아무런 표시를 하지 않는다.

     

     

     

    식별자 분류

     

     

     

     

    성능 데이터 모델링의 정의

     

    성능데이터모델링

     

    - 데이터베이스 성능 향상을 목적으로 설계단계의 데이터 모델링 때부터 성능과 관련된 사항이 데이터 모델링에 반영될 수 있도록 하는 것

    - 일반적으로 성능이라고 하면 데이터조회의 성능을 의미(입력, 수정, 삭제는 일시적이고 빈번하지 않고 단건 처리가 많은 반면 데이터조회의 경우는 반복적이고 빈번하며 여러 건을 처리하는 경우가 많기 때문)

    - 아무리 좋은 차라도 길이 굽이굽이 굽어져있으면 그 길을 빠르게 지나갈 수 없음!

     

    성능 저하 경우

     

    - 데이터 모델 구조에 의한 성능 저하

    - 데이터가 대용량이 됨으로 인해 불가피한 성능 저하

    - 인덱스 특성을 충분히 고려하지 않고 인덱스를 생성함으로 인한 성능 저하

     

    성능데이터 모델링 종류

     

    - 반정규화 또는 정규화

    - 인덱스의 특징을 고려한 컬럼의 순서 변형

    - 테이블 수직 또는 수평분할

    - 데이터 처리 성격에 따라 변환

     

     

     

    성능 데이터 모델링 순서

     

    1. 데이터 모델링을 할 때 정규화를 정확하게 수행한다.
    2. 데이터베이스 용량산정을 수행한다.
    3. 데이터베이스에 발생되는 트랜잭션의 유형을 파악한다.
    4. 용량과 트랜잭션의 유형에 따라 반정규화를 수행한다.
    5. 이력모델의 조정, PK/FK조정, 슈퍼타입/서브타입 조정 등을 수행한다.
    6. 성능관점에서 데이터 모델을 검증한다.

     

     

     

    반정규화 기법

     

    테이블 반정규화

     

    칼럼 반정규화

    댓글

Designed by Tistory.