관계형 데이터 모델링 노트 1장

'데이터모델링 도서인 `관계형 데이터 모델링 노트 개정판` 책의 `1장 엔터티 이야기` 요약 및 정리

정민호정민호

1. 엔터티 이야기

요약

  1. 데이터 모델링이란

    • 업무 요건을 데이터로 설계하는 작업으로 모델링 하는 대상(What)은 업무 요건이며, 모델링하는 방법(How)은 모델링 설계 원칙임

    • 데이터의 성격을 정확히 분석해 엔터티를 명확하게 하는것이 모델링의 시발점

  2. 엔터티란 무엇인지

    • 엔터티란 업무를 수행하는데 필요한 데이터를 특성이 유사한 것끼리 모아 놓은 집합

    • 명확한 조건이 기준이 돼어 서로 명확하게 구별돼어야함

  3. 엔터티를 만드는 이유

    • 필요에 의해 업무에서 관리하고자 하는 데이터(속성)들을 잘 관리하기 위해

  4. 엔터티를 정의하는 방법

    • CASE 툴 등에 엔터티 정의 항목에 엔터티에 대한 설명을 작성

      • 엔터티가 본질적으로 어떤 집합으로 이루어져 있는지를 명백하게 기술

      • 식별자가 무엇이고 서브타입이 무엇인지 기술

  5. 엔서티를 정의하는 방법 상세

    • '만질 수 있느냐 없느냐’로 간단히 성격을 파악하고, '데이터가 자립했는지 아닌지’를 심도있게 분석하면 엔터티를 정의하기 수월해짐

      1. 실체가 있는지

    • 집합의 기준

      • 보이는 것(실체로 존재)

        • 보이는 실체이기 때문에 인식하기도 쉬워 가능하면 도출

        • 다른 여러 행위의 주체가 되기 때문에 더욱 중요

        • 엔터티를 분석이나 설계 할 때, 보이는 것을 관리하는지부터 따져볼 것

      • 보이지 않는 것(개념으로 존재)

        • 연상이 되는 것

          • 예) 주문, 강의 등

        • 연상이 안되는 것

          • 예) 환율, 분류 등

            1. 자립하여 스스로 존재하는지

    • 자립 엔터티(Independent Entity 또는 Strong Entity, Dominant Entity) 란

      • 어떤 엔터티에도 존재 종속(Existence Dependency)되지 않는 엔터티

      • 다른 엔터티에 존재 종속되지 않고 참조 관계만 존재

      • 참조 관계는 주 식별자로 상속하지 않고 일반 속성으로 상속

    • 존재 종속 엔터티(Dependent Entity 또는 Weak Entity, Subordinate Entity) 란

      • 자립 엔터티의 상대적인 개념으로 상위(부모) 엔터티가 존재하지 않으면 존재할 수 없는 엔터티

      • 존재 종속 관계는 주 식별자로 상속

      • 부모 엔터티의 인스턴스가 삭제되면 종속 엔터티의 인스턴스도 삭제돼야함

  6. 엔터티 유형

    1. 데이터 본질에 따른 핵심 엔터티 유형

      1. 실체 엔터티

        • 실체 물체(보이는 실상)에 대한 본질적인 데이터를 관리하는 엔터티

      2. 행위 엔터티

        • 행위나 활동으로 발생한 원천 데이터를 관리하는 엔터티

      3. 가공 엔터티

        • 원천 데이터를 추출·집계한 데이터를 관리하는 엔터티

      4. 기준 엔터티

        • 실체나 행위 데이터의 기준(업무 기준)이 되는 데이터를 관리하는 엔터티

    2. 기타 엔터티 유형

      1. 기본 엔터티

        • 실체 엔터티와 동일

        • 실제 물체(보이는 실상)를 관리

      2. 내역 엔터티

        • 행위 엔터티와 유사

        • 활동이나 행위에 의해 발생한 데이터를 관리

      3. 상세 엔터티

        • 한 개의 엔터티를 일대일(1:1) 관계의 두 개의 엔터티로 분해할 때의 하위 엔터티를 의미

        • 중요 속성이 아닌 속성을 관리

          • 단순히 중요하지 않은 속성만을 모아놓은 엔터티는 데이터 성격을 하나로 정의할 수 없기 때문에 '~상세' 엔터티가 됨

      4. 이력 엔터티

        • 이력은 '주문’과 같은 하나의 의미를 나타내는 용어

      5. 코드 엔터티

        • 코드 명과 코드 값을 관리하는 엔터티로써 그 외의 속성을 관리하면 코드 엔터티가 아님

      6. 관계 엔터티

        • 교차 엔터티의 일종

      7. 집계 엔터티

        • 어떤 값을 집계한 속성이 그 엔터티의 주요 속성이면 집계 엔터티로 정의

      8. 백업 엔터티

        • 원천 데이터의 데이터를 백업한 엔터티이므로, 백업 엔터티와 원천 엔터티를 합쳐야 전체 데이터가 됨

      9. 임시 엔터티

        • 범위가 모호하여 기준을 명확히 정할 필요가 있음

        • 사용한 후 삭제하는 엔터티 또는 트랜젝션이 끝날 때 삭제하는 엔터티, 매일 초기화되는 엔터티 등

  7. 엔터티 설계 방법

    1. 데이터 정체성

      • 엔터티만 명확하게 정의하면 모델링의 많은 문제는 해결

      • 여러 데이터가 혼합된 형태의 엔터티는 엔터티가 아니라 뷰로 사용

    2. 엔터티 무결성

      • 주 식별자가 존재하도록 엔터티 설계

    3. 엔터티 유일성

      • 같은 성격의 데이터는 전사적으로 유일하게

    4. 데이터 혼용 배제

      • 하나의 엔터티에 서로 다른 성격의 데이터를 혼용해서는 안됨

    5. 타 엔터티와 관계 존재

      • 엔터티는 보통 다른 엔터티와 관계가 존재하는 것이 일반적이므로 관계가 존재하지 않으면 그 엔터티의 성격을 다시 확인

        • 가공·기준 엔터티 등은 관계가 존재하지 않을 수 있음

    6. 프로세스 도출 지양

      • 프로세스에 따라 변하는 상태를 엔터티로 설계하거나, 특정 프로세스를 처리하기 위한 화면에 따라 엔터티를 설계하면 안됨

      • 엔터티와 프로세스는 별개

    7. 화면 도출 지양

      • 하나의 화면에 하나의 엔터티를 매핑해서 설계하는 것은 지양할 것

    8. 데이터 관리 요건

      • 데이터베이스에서 관리하려는 데이터를 엔터티로 설계하며, 설계 했더라도 사용하지 않는다면 삭제

  8. 엔터티 검증 방법

    • 단기간에 데이터 모델을 검증하는 방법은 사실상 없음

    • 엔터티를 하나씩 상세하게 들여다 보면서 평가 필요

    • 논리 모델이 완료된 시점에 검증하는 것이 좋으며, 리더가 일관되게 검증

    • 업무에서 필요한 데이터를 사용하기 좋게 설계한 것이 모델이므로, 모델에 누락된 데이터가 있는지, 불필요한 데이터가 있는지 검증

    • 엔터티가 잘못 설계됐을 경우 주 식별자나 관계, 속성, 변경 이력 데이터 등을 제대로 설계 하는 것이 무의미하기 때문에 엔터티 검증은 가장 우선으로 해야함

  9. 데이터 무결성 확보 방법

    • 데이터 무결성은 데이터 값이 완전하고 정확한 상태를 의미하며, 데이터가 정확하지 않다면 신뢰하기 힘들어 활용에 한계가 생김

    • DBMS 차원의 제약은 데이터 무결성을 호가보하기 위해서 중욯나 요소이므로 사용을 적극적으로 고려

      1. 엔터티 무결성(Entity Integrity)

        • 엔터티에 존재하는 모든 인스턴스는 고유해야 하며, 널 값을 가지면 안 된다는 것이 엔터티 무결성

        • 한 엔터티에는 동일한 주 식별자 값이 존재할 수 없으며, 주 식별자 속성은 모르는 값인 널 값을 허용할 수 없음

        • 엔터티 무결성을 만족하기 위해선 주 식별자에 PK(Primary Key)를 생성하고, 업무 식별자에 유니크 인덱스(Unique Index)를 생성

      2. 참조 무결성(Referential Integrity)

        • 연관된 인스턴스 간의 일관성을 유지하기 위한 제약

        • 엔터티의 외래 식별자 속성 값은 참조되는 엔터티의 주 식별자 값과 일치하거나 널 값이어야 한다는 것

        • 참조 무결성은 FK(Foreign Key) 제약으로 지켜짐

      3. 도메인 무결성(Domain Integrity)

        • 도메인 무결성은 속성과 관련된 제약

        • 도메인 무결성은 데이터 타입(Data Type)과 기본 값(Default) 제약, 널(Null) 제약, 체크(Check) 제약 등을 지킬 수 있음

      4. 업무 무결성(Business Integrity)

        • 업무 무결성은 기업에서 업무를 수행하는 방법이나 데이터를 처리하는 규칙을 의미

        • 업무 무결성을 지키기 위해 지침을 제시하여 논리적으로 지키게 하는 방법이 있고, 데이터베이스 제약을 사용하여 강제적으로 지키게 하는 방법이 있음

1.1. 집합과 엔터티

  • 집합 및 엔터티는 어떤 조건에 의해 그 대상을 분명히 알 수 있는것의 모임이며, 명확한 조건이 기준이 돼어 서로 명확하게 구별돼어야함

  • 직관이나 사고로 확정지을 수 있는 대상에 보이지 않는 것을 포함하고 있으며, 누가 생각해도 대상(원소)이 같을 수 있도록 정의하는 것이 중요

  • 릴레이션의 속성이 집합의 원소라고 생각하기 쉬우나, 집합의 원소는 릴레이션의 인스턴스를 의미

  • 테이블의 표에 비유하면, 가로는 릴레이션(속성)을 의미하고, 세로는 집합(인스턴스)을 의미

1.2. 엔터티에 대한 서설

  • 엔터티란 업무를 수행하는데 필요한 데이터를 특성이 유사한 것끼리 모아 놓은 집합

  • 엔터티

    • 필요 때문에 관리하고자 하는 데이터의 집합

    • 특성이 유사한 데이터끼리 모아 놓은 집합

      • 특성이 유사한것끼리 모아 놓았다는 것은 함수 종속(Functional Dependency)을 의미

    • 업무에서 관리하고자 하는 데이터(속성)를 함수 종속으로 도출한 결과 집합

  • 엔터티 설계시 유의 사항

    • 가능한 많은 데이터를 데이터베이스에 저장하도록 유도하는것이 좋으며, 관리할 필요성은 현업이 판단

    • 엔터티와 주 식별자는 한몸이라고 생각해야하며, 주식별자를 모르고 엔터티를 설계(정의) 할 수 없음

    • 속성이나 광계와 혼동해서는 안됨

1.3. 엔터티 정의가 왜 중요한가?

  • 엔터티를 잘못 정의하면 그 이후의 단계(관계 및 속성 정의 등)는 의미가 없어짐

  • 엔터티 정의(Definition)란

    • 엔터티의 설명을 적는것

      • CASE 툴 등에 엔터티 정의 항목에 엔터티에 대한 설명을 적는것

    • 엔터티가 본질적으로 어떤 집합으로 이루어져 있는지를 명백하게 하는 것

      • 식별자가 무엇이고 서브타입이 무엇인지를 밝히는 것

1.4. 엔터티 분류법

  • 데이터의 성격을 정확히 분석해 엔터티를 명확하게 하는것이 모델링의 시발점

  • 엔터티를 분류하는 이유

    • 대상을 범주로 구분하면 그 대상의 특성이 더 잘 이해기 떄문

    • 데이터와 엔터티를 보다 명확하게 이해하기 위함

  • 엔터티 분류 방법

    • 만질 수 있는 것과 만질 수 없는 것

      • 사람/사물과 같이 실제로 존재하는 물건인지, 만져서 느낄 수 있는지

    • 자립 엔터티와 종속 엔터티

      • 엔터티가 스스로 존재할 수 있는 자립 엔터티인지

      • 다른 엔터티엔가 존재 종속(Existence Dependency)된 종속 엔터티인지

    • 원천 데이터와 가공 데이터

    • 실체·행위·가공·기준 엔터티

      • 실체·행위·가공·기준 엔터티 중 어디에 속하는지

    • 내부 생성 데이터와 외부 생성 데이터

    • 엔터티 유형에 의한 기본·내역·상세 등의 엔터티

1.5. 엔터티 정의 방법 - 보이는 것인가?

  • 보이는 것을 관리하는 데이터는 실체 엔터티이며, 의미하는 데이터는 핵심 데이터일 가능성이 높음

  • 실체 데이터와 개념으로 존재하는 데이터를 명확히 구분하는게 엔터티를 설계하는 시발점

  • 집합의 기준

    • 보이는 것(실체로 존재)

      • 보이는 실체이기 때문에 인식하기도 쉬워 가능하면 도출

      • 다른 여러 행위의 주체가 되기 때문에 더욱 중요

      • 엔터티를 분석이나 설계 할 때, 보이는 것을 관리하는지부터 따져볼 것

    • 보이지 않는 것(개념으로 존재)

      • 연상이 되는 것

        • 예) 주문, 강의 등

      • 연상이 안되는 것

        • 예) 환율, 분류 등

1.6. 엔터티 정의 방법 - 스스로 존재하는가?

  • 관리하는 데이터의 범위에 따라 자립 엔터티가 종속 엔터티가 될 수 있고, 종속 엔터티가 자립 엔터티가 될 수 있음

  • 데이터의 성격만을 판단해 엔터티를 명확히 정의하는 것이 모델링의 시발점

  • 자립 엔터티(Independent Entity 또는 Strong Entity, Dominant Entity) 란

    • 어떤 엔터티에도 존재 종속(Existence Dependency)되지 않는 엔터티

    • 다른 엔터티에 존재 종속되지 않고 참조 관계만 존재

    • 참조 관계는 주 식별자로 상속하지 않고 일반 속성으로 상속

  • 존재 종속 엔터티(Dependent Entity 또는 Weak Entity, Subordinate Entity) 란

    • 자립 엔터티의 상대적인 개념으로 상위(부모) 엔터티가 존재하지 않으면 존재할 수 없는 엔터티

    • 존재 종속 관계는 주 식별자로 상속

    • 부모 엔터티의 인스턴스가 삭제되면 종속 엔터티의 인스턴스도 삭제돼야함

Tip
 '만질 수 있느냐 없느냐’로 간단히 성격을 파악하고, '데이터가 자립했는지 아닌지’를 심도있게 분석하면 엔터티를 정의하기 수월해짐

1.7. 종속 엔터티의 종류

  • 종속 엔터티는 참조 엔터티에 비하면 그다지 많지 않지만, 다양한 경우에서 발생

  • 종속 엔터티의 유형

    • 부모 엔터티의 부가 데이터를 관리하는 엔터티

      • 일부 데이터를 더욱 상세하게 관리하는 엔터티

    • 1정규화에 의해서 발생한 엔터티

      • 부모 엔터티 없이는 존재할 수 없는 종속 엔터티

    • 이력 데이터를 관리하는 엔터티

      • 원천 엔터티의 변경 데이터를 관리하기 위한 엔터티

    • 다대다(M:M) 관계에서 발생한 교차 엔터티

      • 다대다(M:M) 관계는 보통 두 개의 일다다(1:M) 관계로 표현되면서 종속 엔터티가 생기는데 이를 교차 엔터티(Association Entity 또는 Relationship Entity, Intersection Entity)라고 함

    • 슈퍼타입에 대한 서브타입 엔터티

      • 서브타입 엔터티는 슈퍼타입에 종속된 엔터티

    • 엔터티 분해에 의한 일대일 관계의 엔터티

      • 성능이나 관리상의 이유로 속성을 수직 분할로 나눠서 관리하는 엔터티

1.8. 모델(ERD)과 메타 시스템의 속성 설명

  • 표준은 기준을 의미하기도 하고 토대가 되기도 하지만, 메타 시스템의 속성 설명보다는 ERD의 속성 설명이 더욱 의미가 있다는 것을 간과하면 안됨

  • 메타 시스템이란

    • 엔터티와 속성 등의 정보를 관리하는 시스템

    • 엔터티를 관리하는 엔터티와 속성을 관리하는 엔터티 필요할 것

  • 메타 시스템에서 속성 관리 방안

    1. 엔터티의 엔터티의 주 식별자를 상속받아 엔터티의 속성을 관리

    2. 엔터티의 엔터티와 속성 엔터티를 별도로 두어 M:M 관계로 교차(관계) 엔터티를 통해 엔터티에 속한 속성을 관리

  • 속성 설명 종류

    • 일반화된 표준 설명

      • 메타 시스템에서는 대표적인 의미의 속성 설명

    • 개별적으로 특화된 설명

      • ERD에서는 엔터티의 개별적인 의미의 속성 설명

1.9. 엔터티 정의 방법 - 원천 데이터인가?

  • 엔터티에서 관리하는 데이터가 원천 데이터인지, 가공 데이터인지를 분류하는 것은 엔터티를 이해하는데 도움을 줌

  • 보이는 것을 설계한 데이터인지, 스스로 존재하는 것을 설계한 데이터인지에 이어 원천과 가공 데이터를 구분하는 것은 매우 유용한 데이터 분석법

  • 원천 데이터(Row Data)란

    • 스스로 존재하는 최초의 데이터

    • 고객이나 사용자가 화면에서 직접 입력(Key-In)함으로써 생성

    • 원천 엔터티는 데이터 성격 자체로 판단한 식별자가 사용

    • 외부에서 제공 받은 데이터

  • 가공 데이터(Processing Data)란

    • 원천 데이터나 또 다른 가공 데이터를 통해 만들어진 데이터

    • 프로그램에 의해 생성된 데이터(집계, 요약, 임시, 작업용 데이터)

    • 스스로 업데이트가 발생하지 않고 원천 데이터가 바뀌면 따라서 업데이트됨

    • 원천 데이터와는 연관성만 있을 뿐 참조 무결성 관계는 없음

    • 집계 기준과 같은 목적에 의해 주 식별자 결정됨으로써 식별자가 복잡해 질 수 있음

  • 백업 데이터(Backup Data)란

    • 원천 데이터일 수도 있고, 가공 데이터일 수도 있는 데이터

      • 기존 데이터를 두고 백업하면, 데이터 중복이 발생함으로 가공데이터

      • 기존 데이터에서 삭제하고 백업한다면 중복된 데이터가 아니므로 원천 데이터

  • 원천 데이터와 가공 데이터의 정합성을 맞추는 방법

    • 원천 데이터가 수정되는 시점에 가공 데이터를 실시간으로 수정하는 방법

    • 특정 시간을 정해 배치로 가공 데이터를 원천 데이터와 맞추는 방법

    • 가공 데이터는 원천 데이터가 어떤 엔터티에 존재하는지 기술

      • 어떤 방식으로 생성 했는지, 데이터 정합성을 어떻게 구현할 수 있는지 등 또한 기술

1.10. 데이터 본질에 따른 엔터티 분류법 - 실체·행위·가공·기준

  • 엔터티를 분류할 때의 기준은 데이터의 성격

  • 엔터티를 분류하는 이유

    • 다양하게 분류해 보면 엔터티의 성격을 이해하는데 많은 도움

    • 모델링 작업 순서를 정하는데 도움

  • 엔터티 분류 핵심 유형

    • 실체 엔터티

      • 실체 물체(보이는 실상)에 대한 본질적인 데이터를 관리하는 엔터티

    • 행위 엔터티

      • 행위나 활동으로 발생한 원천 데이터를 관리하는 엔터티

    • 가공 엔터티

      • 원천 데이터를 추출·집계한 데이터를 관리하는 엔터티

    • 기준 엔터티

      • 실체나 행위 데이터의 기준(업무 기준)이 되는 데이터를 관리하는 엔터티

  • 엔터티 분류 기준

    • 엔터티의 용도

    • 엔터티의 중요도

    • 엔터티 생성 순서

  • 엔터티 분류 순서

    1. 기준·실체 엔터티

    2. 행위 엔터티

    3. 가공 엔터티

1.11. 실체 엔터티란?

  • 실체 엔터티는 도출이 수비지만 잘못 설계하면 업무 전체적으로 심각한 영향을 끼침

  • 실체 엔터티를 제대로 설계해야 전체 모델이 안정됨

  • 실체 엔터티는 단순하게 설계

  • 실체 엔터티란

    • 간단히 만질 수 있는 것(Tangible) 중 본질적인 데이터를 관리하는 엔터티

  • 실체 엔터티 특징

    • 실체 엔터티의 주 식별자는 단순하게

      • 인조 식별자가 오히려 집합의 성격을 더 직관적이고 명확하게 해줌

      • 행위 엔터티나 가공 엔터티에 인조 식별자를 사용하면 이해하기 어렵고 오용되는 경향이 있으니 주의

    • 다른 엔터티 유형에 비해 과감한 통합 필요

      • 실체 엔터티가 통합되면 전체 모델 구조가 단순해지며, 단순한 모델이 좋은 모델이 될 가능성이 높음

    • 실체가 소멸되지 않는 한 지속해서 하나의 인스턴스로 관리

      • 실체 엔터티의 이력 데이터를 실체 데이터에 포함시키지 않도록 주의

    • 실체의 특정 속성이나 상태가 바뀔 수 있음

      • 일부 특성이 변하는 것으로 일부 속성에 대해 이력 데이터로 관리

1.12. 행위 엔터티란?

  • 행위 엔터티와 행위 엔터티를 관리하는 속성이 대부분 많기 때문에 모델링시 가장 많은 시간이 소요됨

  • 행위 엔터티의 통합은 실체 엔터티보다 어렵지만, 업무 식별자를 명확히 하여 최대한 통합하는 것이 좋음

  • 행위 엔터티란

    • 어떤 실체 의 업무 행위나 활동에 의해서 생긴 원천 데이터를 관리하는 엔터티

  • 행위 엔터티 특징

    • 엔터티 발생 순서가 존재할 수 있음

    • 복잡한 주 식별자와 관계

      • 주 식별자는 업무 식별자를 우선적으로 사용하며, 가공 엔터티와 관계가 발생하면 잘못된 모델일 가능성이 높음

  • 행위 엔터티의 업무 식별자 도출 방법

    • 누가, 무엇을, 언제, 어떻게, 어디에서 했는지 분석

      • 이 중 전부가 모여야 인스턴스를 유일하게 식별할 수 있고, 2~3개가 인스턴스를 발생시킨 주체일 수도 있음

1.13. 가공 엔터티란?

  • 원천 엔터티가 깔끔해도 가공 엔터티가 무분별하면 시스템 전반적으로 문제가 발생하기 때문에 가공 엔터티도 신경 써서 분석

  • 원천 데이터를 바로 집계해도 크게 불편하지 않다면 굳이 집계 엔터티를 사용할 이유는 없음

  • 가공 엔터티는 데이터 정합성이 문제를 최소화하기 위해 최대한 통합

  • 가공 엔터티란

    • 원천 데이터가 아닌 데이터를 관리하는 엔터티

    • 원천 데이터의 실체, 행위, 기준 엔터티의 데이터를 가공한 데이터를 관리하는 엔터티

      • 주로 집계, 요약, 임시 데이터를 관리

    • 보통 집계 기준(Dimension) 역할을 하는 엔터티 이외의 엔터티와는 관계가 존재하지 않음

    • 주 식별자는 집계하려는 기준을 의미

    • 작업의 편의성을 위해 데이터를 중복으로 관리하기도 함

1.14. 기준 엔터티란?

  • 기준 데이터는 소량의 데이터지만 행위 엔터티 등에서 사용되므로 시스템 전반적으로 영향을 미침

  • 기준 엔터티란

    • 업무의 기준이 되는 엔터티

      • 업무를 수행할 때 참조가 되기 때문에 참조(Reference) 엔터티라고도 함

    • 개념적인 데이터를 관리하는게 다를뿐 실체 엔터티의 특징을 그대로 따름

  • 기준 엔터티 구분

    • 기준 정보 성격의 데이터를 관리하는 엔터티

    • 기본 정보 성격의 데이터를 관리

  • 기준 엔터티 통합

    • 데이터의 중복을 방지하기 위해 통합

    • 업무의 기준이 되는 속성들을 모아 구조 통합

1.15. 엔터티 정의 방법 - 데이터 생성에 따른 분류법

  • 데이터는 어디에서 생성했는지에 따라 내부 데이터와 외부 데이터로 구분

  • 어떻게 생성했는지에 따라 화면 입력 데이터와 배치 데이터로 구분되며 모두 정규화 대상

  • 내부 데이터(Internal Data)란

    • 내부에서 생성할 수 있는 데이터로써, 그 값이 맞고 틀린지 결정할 수 있음

    • 중복 데이터를 배제하고, 완전 정규화된 관계형 데이터 모델에 저장

  • 외부 데이터(External Data)란

    • 외부에서 받은 데이터로써, 그 값이 맞고 틀린지 결정할 수 없음

    • 받은 그대로 저장하거나, 관계형 데이터 모델로 재설계하여 저장

  • 내/외부 데이터 기준

    • 내/외부 데이터의 기준은 주로 회사이지만, 기준 자체가 중요한 게 아니라 기준을 정한 후 일관되게 생각하는것이 중요

  • 데이터 생성 유형

    • 화면 입력(Key-In)

      • 외부 고객(Customer)이나 내부 사용자(User)가 주체

      • 화면을 선택하고 값을 입력한 후 저장하는 절차에 의해 데이터 생성

    • 배치(Batch)

      • 대량 배치

      • 개별 배치

        • 트리거

1.16. 엔터티 정의 방법 - 엔터티 유형에 따른 분류법

  • 기준이 명확하지 않으므로, 실무에 사용할 시 어떤 식으로든 기준을 정의해야함

  • 엔터티 유형을 접미어로 사용하는것은 바람직 하지 않으나, 표준을 정해 방향을 제시한다는 측면에서 접미어를 붙이는 것이 시스템에 유용할 수 있음

  • 접미어를 붙이기 위해 엔터티 분류법을 사용하는 것이 아니라, 데이터 성격을 파악하기 위해 분류법을 사용할 것

  • 엔터티 유형

    • 기본 엔터티

      • 실체 엔터티와 동일

      • 실제 물체(보이는 실상)를 관리

    • 내역 엔터티

      • 행위 엔터티와 유사

      • 활동이나 행위에 의해 발생한 데이터를 관리

    • 상세 엔터티

      • 한 개의 엔터티를 일대일(1:1) 관계의 두 개의 엔터티로 분해할 때의 하위 엔터티를 의미

      • 중요 속성이 아닌 속성을 관리

        • 단순히 중요하지 않은 속성만을 모아놓은 엔터티는 데이터 성격을 하나로 정의할 수 없기 때문에 '~상세' 엔터티가 됨

    • 이력 엔터티

      • 이력은 '주문’과 같은 하나의 의미를 나타내는 용어

    • 코드 엔터티

      • 코드 명과 코드 값을 관리하는 엔터티로써 그 외의 속성을 관리하면 코드 엔터티가 아님

    • 관계 엔터티

      • 교차 엔터티의 일종

    • 집계 엔터티

      • 어떤 값을 집계한 속성이 그 엔터티의 주요 속성이면 집계 엔터티로 정의

    • 백업 엔터티

      • 원천 데이터의 데이터를 백업한 엔터티이므로, 백업 엔터티와 원천 엔터티를 합쳐야 전체 데이터가 됨

    • 임시 엔터티

      • 범위가 모호하여 기준을 명확히 정할 필요가 있음

      • 사용한 후 삭제하는 엔터티 또는 트랜젝션이 끝날 때 삭제하는 엔터티, 매일 초기화되는 엔터티 등

1.17. 교차 엔터티란?

  • 교차 엔터티로 설계하는 것은 가능한 빠른 단계에서 하는것이 바람직

  • 엔터티 작도시 양쪽 부모 엔터티 사이에 위치 시키는 것이 좋음

  • 교차 엔터티란

    • 다대다(M:M) 관계에서 발생한 엔터티로써 물리 모델에서는 구현될 수 없으므로, 가능한 빠른 단계에서 교차 엔터티로 설계

    • 재귀 관계에서 발생하는 BOM(Bill Of Materials) 엔터티도 교차 엔터티

      • 다대다(M:M) 재귀 관계는 역할(Role)을 관ㄹ히나는 모델에서 주로 발생

  • 교차 엔터티 특징

    • 다대다(M:M) 관계는 논리적으로 많이 발생

    • 관리되는 속성이 많지 않음

    • 3개체 관계(Ternary Relationships)에서도 발생

    • 다대다(M:M) 관계를 해소하더라도 또다른 다대다(M:M) 관계가 생길 수 있음

  • 교차 엔터티 명명법

    • 관계의 명명법과 연관

    • 양쪽 무모 엔터티와의 연관성을 표현

1.18. 엔터티 설계 원칙

  • 성격·본질·주제에 따른 정체성이 분명한 엔터티로 설계

1.18.1. 데이터 정체성

  • 엔터티만 명확하게 정의하면 모델링의 많은 문제는 해결

  • 여러 데이터가 혼합된 형태의 엔터티는 엔터티가 아니라 뷰로 사용

1.18.2. 엔터티 무결성

  • 주 식별자가 존재하도록 엔터티 설계

1.18.3. 엔터티 유일성

  • 같은 성격의 데이터는 전사적으로 유일하게

1.18.4. 데이터 혼용 배제

  • 하나의 엔터티에 서로 다른 성격의 데이터를 혼용해서는 안됨

1.18.5. 타 엔터티와 관계 존재

  • 엔터티는 보통 다른 엔터티와 관계가 존재하는 것이 일반적이므로 관계가 존재하지 않으면 그 엔터티의 성격을 다시 확인

    • 가공·기준 엔터티 등은 관계가 존재하지 않을 수 있음

1.18.6. 프로세스 도출 지양

  • 프로세스에 따라 변하는 상태를 엔터티로 설계하거나, 특정 프로세스를 처리하기 위한 화면에 따라 엔터티를 설계하면 안됨

  • 엔터티와 프로세스는 별개

1.18.7. 화면 도출 지양

  • 하나의 화면에 하나의 엔터티를 매핑해서 설계하는 것은 지양할 것

1.18.8. 데이터 관리 요건

  • 데이터베이스에서 관리하려는 데이터를 엔터티로 설계하며, 설계 했더라도 사용하지 않는다면 삭제

1.19. 엔터티 명은 어떻게 정하는가?

  • 엔터티 명은 자신의 데이터 집합에 대한 이름이기도 하지만, 다른 엔터티가 바라보는 이름이기도 하므로 타 엔터티와 연관 관계에서 중요한 역할을 함

  • 부적절한 엔터티 명은 엔터티의 정확한 사용을 어렵게하여 엔터티를 오용하게 함

  • 엔터티 정의와 엔터티 명, 업무 식별자만 제대로 설계하면 엔터티는 온전해지며 더욱 견고해짐

1.19.1. 데이터 성격을 파악하기 쉽게 명명

엔터티 명을 보고 어떤 데이터를 관리하는지 알 수 있도록 적절하고 구체적으로 표현

1.19.2. 일관성 있게 명명

  • 일정한 약속을 정해 준수할 것

1.19.3. 구체적으로 명명

  • 구체적(Specific)

    • 엔터티를 구성하는 집합의 성격이 고정적일 때

    • 모호한 단어를 사용하지 않고 수식어를 적절히 사용하는것이며, 데이터의 성격을 표현하도록 붙이는 것

1.19.4. 확장성을 고려하여 명명

  • 일반적(General)

    • 추후에 추가(통합)될 집합이 존재할 가능성이 있을 대

    • 넓은 개념을 포함할 수 있도록 유연하게 정의

1.19.5. 필요한 단어로만 명명

  • 생략해도 의미가 통하는 단어는 생략

    • '~시', '~용', '~별' 등

  • 중복 의미를 나타내는 단어가 사용되지 않도록 주의

1.19.6. 프로세스를 표현하지 않도록 명명

  • 엔터티 명에 '~등록', '~처리' 등과 같이 프로세스(업무)를 표현하는 것은 바람직하지 않음

1.19.7. 명사형으로 명명

  • 엔터티 명은 명사형으로 사용하는 것이 일반적

  • 형용사형을 사용하여 설명하는 식의 엔터티명은 함축적이지 않으며 직관적이지 않음

1.19.8. 가능하면 짧게 명명

  • 엔터티 명은 가독성에 문제가 되지 않고 성격을 파악할 수 있는 정도 내에서 띄어쓰기를 하지 않고 명명

1.19.9. 테이블 명이 엔터티 명에 종속되지 않도록 명명

  • 속성 명을 컬럼 명으로 자동 전환하는 것과 달리 엔터티 명은 테이블 명으로 자동 전환하지 않아야 함

  • 엔터티 정의가 바뀌는 것은 바람직 하지 않지만, 엔터티 명은 생각보다 자주 바뀜

  • 엔터티 명은 빈번하게 변경되지만, 테이블 명은 변경할 이유가 없다는 점을 염두에 두고 원칙을 정의

1.19.10. 동일한 엔터티 명이 없도록 명명

  • 테이블 명과 마찬가지로 엔터티 명은 전 영역에서 중복돼서는 안됨

  • 엔터티 명에 특수 문자는 사용하지 않는 것이 원칙이지만 '_', '/', '( )', '[ ]' 등은 사용가능

1.20. 다양한 엔터티에 대한 명명법

  • 엔터티에서 관리하는 데이터를 가장 잘 표현한 명을 사용

1.20.1. 실체 엔터티 명명법

  • 실체 엔터티에 대한 명명법의 핵심은 엔터티 명이 명사로 끝나는 것

1.20.2. 행위 엔터티 명명법

  • 명사로 끝나도록 정하는 것은 적합하지 않음

  • 엔터티 명에 '~했음’이나 '~한 데이터’를 붙여보았을 때 자연스러운 문장이 되면 행위 엔터티에 대한 명명으로 적합

1.20.3. 교차 엔터티 명명법

  • 교차 엔터티의 명명법은 관계의 명명법과 연관됨

  • 다대다(M:M) 관계의 관계 명은 교차 엔터티 명과 유사

1.20.4. 집계 엔터티 명명법

  • 집계 기준은 앞쪽에, 대상(무엇을 집계했는지)은 뒤쪽에 위치하는 것이 좋음

    • '(사원, 부서, 월, 매채)별(거래, 매출, 주문)집계' 와 같은 형식의 엔터티 명

1.20.5. 외부 엔터티 명명법

  • 구체화 할것인지 일반화 할것인지 판단

    • 구체화 할 시 기관명을 엔터티 명에 붙이는 것이 좋고, 일반화 할 시 통합을 대비해 기관명을 생략

1.20.6. 서브타입 엔터티 명명법

  • 서브타입 엔터티 명은 슈퍼타입 엔터티에 수식어를 붙이는 형식으로 사용

1.20.7. 일대일 관계 엔터티 명명법

  • 유사한 속성을 분리할 때

    • 데이터의 성격에 맞게 명명

  • 덜 사용되는 속성을 분리할 때

    • 사용빈도에 따라 속성을 나눌경우 '~상세’로 명명

  • 프로세스를 표현한 결과를 나타낼 때

    • '~요청', '~승인’과 같이 데이터 성격에 맞는 엔터티 명으로 작성

1.21. 엔터티 설명은 어떻게 기술하는가?

  • 길고 장황한 설명은 전달을 흐리게 해 혼란스러울 수 있음

  • 간결한 설명이 좋은 설명이므로, 단순 명료하게 설명해야함

  • 엔터티 설명(Explanation)이란

    • 엔터티를 정의하는 것과 다르게, 단지 엔터티에 관해서 기술하는 것

    • 엔터티가 어떤 데이터를 관리하는지 알게 하기 위해 생략하지 않고 반드시 기술

  • 엔터티 설명 시 내용

    • 본질적인 설명

      • 엔터티를 구성하는 데이터의 본질, 성격, 주제 등에 대해서 설명

      • 원천 데이터가 어떤 엔터티인지, 외부에서 받은 데이터라면 어디에서 받은 데이터인지 기술

    • 부가 설명

      • 업무에 대한 설명, 프로세스에 대한 설명 등 참고로 기술하면 좋은 설명

1.22. 개념 모델에 포함하는 주요 엔터티란?

  • 주요 엔터티는 사용 중인 전체 엔터티 중 10 ~ 30% 정도로 정의

  • 주요 엔터티를 선정하는 것은 여의치 않을 때 생략할 수도 있으며, 모델링 중에 재선정할 수도 있음

  • 주요(핵심) 엔터티란

    • 주요 엔터티에 대한 정의는 명확하지 않지만, 중요하고(Important) 주된(Main) 엔터티

  • 주요 엔터티를 찾는 방법

    • 행위의 주체가 되는 엔터티

    • 하위 엔터티가 많은 엔터티

    • 핵심 업무 파악

    • 업무에서 자주 사용되는 엔터티

  • 주요 엔터티를 찾는 목적

    • 개념 모델링을 하기 위해서

  • 주요 엔터티를 선정하는 방법

    • 리스트를 대상으로 주요 엔터티 선정을 요청하는 방법

    • 인터뷰를 통해 주요 엔터티를 정하는 방법

    • 개략적으로 분석하고 실체, 행위, 가공 엔터티로 분류하면서 주요 엔터티를 선정하는 방법

1.23. 엔터티 정의의 또 다른 이름 - 업무 식별자

  • 업무 식별자는 엔터티를 설계하는 자체이기 때문에 업무 식별자까지 도출해야 제대로 엔터티를 설계한 것

  • 엔터티 정의와 직접 연결 되므로, 엔터티를 정의하는 시점에 업무 식별자 도출

  • 업무 식별자란

    • 업무적으로 인스턴스를 구분하게 하는 식별자

    • 데이터를 쌓는 기준이 되는 것으로 인스턴스의 발생 기준

      • 인조 식별자(사원번호 등)는 인스턴스를 물리적으로 구분하는 역할을 하지만, 업무 식별자는 인스턴스를 업무적으로 구분하는 역할

1.24. 업무 식별자 도출 방법

  • 인스턴스를 발생시키는 기준 속성을 찾고, 시각 속성과 순번 속성은 우선 제외하고 따져 봄

  • 업무 식별자를 도출할 때의 기본 원칙은 최소한의 속성이 되도록 해야함

  • 업무 식별자 찾는 방법

    • 데이터가 생성되는 기준 찾기

    • 정규화를 수행하는 기준 찾기

  • 업무 식별자 유형

    • 실체 엔터티는 보통 식별 번호가 업무 식별자가 됨

    • 행위 엔터티는 육하원칙에 의해 정해짐

    • 집계 엔터티는 집계 기준(Dimension)이 업무 식별자가 됨

    • 이력 엔터티는 업무 식별자에 시간 개념이 포함됨

1.25. 업무 식별자 표현 방법

  • 업무 식별자는 중요한 요소이기 떄문에 어떠한 방법으로든 관리해야 함

  • 업무 식별자 관리 방안

    • 업무 식별자에 유니크 인덱스 생성

  • 업무 식별자 표현 방안

    • 대리 식별자(Alternate Identifier) 사용

1.26. 데이터 모델을 검증할 수 있는가?

  • 단기간에 데이터 모델을 검증하는 방법은 사실상 없음

  • 데이터 모델을 기계적으로 평가하는 방법은 몇 가지가 있지만, 평가 했다고 하기엔 많이 부족함

  • 업무 요건에 따라 모델을 설계하기 때문에 어떤 식으로든 사람의 개입이 필연적

  • 객관화하기 위해서는 정량화하여 수치로 평가할 수 있어야함

1.27. 엔터티 검증

  • 업무에서 필요한 데이터를 사용하기 좋게 설계한 것이 모델이므로, 모델에 누락된 데이터가 있는지, 불필요한 데이터가 있는지 검증

  • 엔터티가 잘못 설계됐을 경우 주 식별자나 관계, 속성, 변경 이력 데이터 등을 제대로 설계 하는 것이 무의미하기 때문에 엔터티 검증은 가장 우선으로 해야함

1.27.1. 엔터티 검증 시기

  • 논리 모델이 완료된 시점에 검증하는 것이 좋으며, 리더가 일관되게 검증

1.27.2. 엔터티 존재 여부 검증 방법

  • 모델에 표현된 불필요한 엔터티가 있는지?

  • 모델에 표현되지 않은 엔터티가 있는지?

    • 애플리케이션 화면, 엔터티 매트릭스 비교

      • 화면은 있는데 엔터티가 없는 경우

      • 엔터티만 존재하고 화면이 없는 경우

      • 엔터티에도 없고 화면에도 없는 경우

    • TOBE 엔터티 존재 여부 검증

      • ASIS 엔터티가 TOBE 모델에 없는 경우

        • ASIS ㅇ네터티에 해당 업무가 TOBE에 삭제됐는지 검토

      • TOBE 모델에 있는 엔터티가 ASIS 모델에 없는 경우

        • 신규 업무로 인해 TOBE 모델에 추가됐는지 검토

1.27.3. 속성으로 설계해야 하는 것은 아닌지?

  • 엔터티를 설계할 때 간혹 속성으로 설계해야 하는데, 엔터티로 설계하는 경우가 있으니 주의

1.27.4. 하나의 엔터티는 하나의 주제로 구성되었는가?

  • 한 엔터티에 여러 성격의 데이터가 혼재돼서는 안되며, 엔터티는 동일한 성격의 집합으로 구성되어야 함

1.27.5. 유사한 성격의 데이터인데 개별적인 엔터티에서 관리하고 있지 않은지?

  • 유사한 데이터가 여러 엔터티에 존재하는 것은 특별한 이득이 없으므로 엔터티 통합을 기본 원칙으로 검증

  • 유사한 구조가 반복된다면 좀 더 일반화하여 통합

1.27.6. 필요한 단어만을 사용해서 엔터티 명을 구체적으로 붙였는지?

  • 필요한 단어만을 사용해서 구체적으로 붙여야함

  • 엔터티 명을 보고 어떤 데이터를 관리하는 엔터티인지를 알 수 있도록 가능한 구체적이어야 함

  • 반대로 확장할 수 있는 집합인데도 불구하고 구체적으로 붙이는 것은 바람직하지 않음

  • 엔터티 명에 필요 없는 단어는 생략

  • 서브타입 엔터티 명은 슈퍼타입 엔터티 명을 차용해야 함

1.27.7. 엔터티 명이 주 식별자와 한 쌍이 되도록 붙였는지?

  • 엔터티 명은 주 식별자와 한 쌍처럼 잘 어울려야 함

  • 어울리지 않을 경우 단순히 가독성 측면에서만 문제가 되는 것이 아니라 간혹 둘 중의 하나를 잘못 설계했을 수도 있음

1.27.8. 엔터티 설명이 존재하며 간결하고 명확한가?

  • 엔터티 설명은 반드시 기술하는 것이 원칙

  • 설명이 누락된 엔터티를 뽑아서 설명을 채워야함

  • 모델러는 엔터티 명과 설명만을 보고도 해당 엔터티를 충분히 설명할 수 있어야함

1.27.9. 업무 식별자가 존재하는가?

  • 모든 엔터티에 업무 식별자가 존재하는지를 검토

  • 업무 식별자는 CASE 툴에서 관리하지 않기 때문에 표준 형식을 정해서 관리

1.27.10. 이력 데이터를 관리하는 엔터티가 맞는지?

  • 엔터티 명이 '~이력’으로 끝나는지 검토

  • 하위(자식) 엔터티가 많다면 종료일자 속성을 주 식별자에 포함하지 말 것

1.27.11. 일대일 관계의 두 엔터티를 합체할 수 없는가?

  • 일대일(1:1) 관계만을 뽑아서 두 엔터티의 성격이 같은지 확인

  • 성능, 관리 상의 문제가 없다면 합체할 것을 고려

1.27.12. 종속 관계 엔터티의 주 식별자 상속이 적절한가?

  • 종속 관계인 엔터티는 동일한 주제 영역에 존재해야함

  • 종속 엔터티는 일반적으로 주 식별자를 식별자로서 상속

1.27.13. 데이터 인스턴스가 하나뿐인 특수 엔터티가 있는가?

  • 인스턴스가 하나뿐인 엔터티는 흔치 않으므로, 반드시 잘못된 것은 아니지만 재차 확인해볼 필요가 있음

1.27.14. 주 식별자가 존재하지 않은 엔터티가 있는가?

  • 주 식별자가 없다고 반드시 잘못된 엔터티는 아니지만, 주 식별자가 없는 엔터티를 뽑아서 다시 검토해야함

1.27.15. 주 식별자가 동일한 엔터티가 있는가?

  • 일대일(1:1) 관계나 슈퍼타입, 서브타입 관계 등을 제외하고, 엔터티의 주 식별자가 같은 엔터티는 주 식별자를 검토해 볼 필요가 있음

1.27.16. 엔터티의 의미를 쉽게 설명할 수 있는가?

  • 모델러는 스스로 설계한 엔터티와 속성을 쉽게 설명할 수 있어야함

1.27.17. 외부·복제 엔터티의 엔터티 명과 주 식별자가 원천 엔터티와 같은가?

  • 외부 엔터티나 복제 엔터티는 원천 엔터티와 엔터티 명과 주 식별자가 동일해야함

1.28. 데이터 모델 설계 원칙

  • 업무 요건을 데이터로 설계하는 작업으로 모델링 하는 대상(What)은 업무 요건이며, 모델링하는 방법(How)은 모델링 설계 원칙임

  • 모델 설계시 우선순위

    1. 데이터 무결성

    2. 데이터 성능

    3. 관리 효율성

    4. 사용 편의성

  • 모델 설계 원칙

1.28.1. 정체성

  • 데이터 성격에 맞는 정체성이 뚜렷한 엔터티를 설계하는 것은 데이터 모델 설계의 중요한 원칙

1.28.2. 통합성

  • 유사한 성격의 데이터는 통합하는 것이 데이터 모델링의 주요 원칙

1.28.3. 유연성

  • 확장하기 수월한 모델으로 데이터를 통합할수록 모델은 유연해짐

1.28.4. 무결성

  • 데이터에 결점이 없는 상태

    • 무결성을 지키기위해 중복된 데이터를 배제하고 참조 무결성(Referential Itegrity), 도메인 규칙을 정의

1.28.5. 가독성

  • 가독성이 좋도록 모델을 설계

    • 관계선이 겹치지 않도록하거나 서브타입을 표현하는 것, 재귀 관계나 배타 관계를 표현하는 것

1.28.6. 업무 연관성

  • 업무 요건에 맞는 모델을 설계하는 것

  • 업무 식별자를 제대로 도출하여 엔터티를 분명히 설계

  • 업무 프로세스에 맞게 관계선을 표현

1.28.7. 성능 효율성

  • 성능이 좋도록 모델을 설계하는 것

1.28.8. 관리 효율성

  • ERD가 제대로 관리될 수 있도록 설계하는 것

1.28.9. 표준화

  • 표준화 원칙을 따라 동일한 용어를 사용하도록 설계하는 것

1.28.10. 데이터 보안 대비

  • 향후에 사용되지 않을 수도 있다는 것을 고려해서 설계하며, 주믄등록번호 같은 암호화 대상 속성을 주 식별자로 사용하면 안됨

1.29. 무결성에 대해서

  • 데이터 무결성은 데이터 값이 완전하고 정확한 상태를 의미하며, 데이터가 정확하지 않다면 신뢰하기 힘들어 활용에 한계가 생김

  • DBMS 차원의 제약은 데이터 무결성을 호가보하기 위해서 중욯나 요소이므로 사용을 적극적으로 고려

1.29.1. 엔터티 무결성(Entity Integrity)

  • 엔터티에 존재하는 모든 인스턴스는 고유해야 하며, 널 값을 가지면 안 된다는 것이 엔터티 무결성

  • 한 엔터티에는 동일한 주 식별자 값이 존재할 수 없으며, 주 식별자 속성은 모르는 값인 널 값을 허용할 수 없음

  • 엔터티 무결성을 만족하기 위해선 주 식별자에 PK(Primary Key)를 생성하고, 업무 식별자에 유니크 인덱스(Unique Index)를 생성

1.29.2. 참조 무결성(Referential Integrity)

  • 연관된 인스턴스 간의 일관성을 유지하기 위한 제약

  • 엔터티의 외래 식별자 속성 값은 참조되는 엔터티의 주 식별자 값과 일치하거나 널 값이어야 한다는 것

  • 참조 무결성은 FK(Foreign Key) 제약으로 지켜짐

1.29.3. 도메인 무결성(Domain Integrity)

  • 도메인 무결성은 속성과 관련된 제약

  • 도메인 무결성은 데이터 타입(Data Type)과 기본 값(Default) 제약, 널(Null) 제약, 체크(Check) 제약 등을 지킬 수 있음

1.29.4. 업무 무결성(Business Integrity)

  • 업무 무결성은 기업에서 업무를 수행하는 방법이나 데이터를 처리하는 규칙을 의미

  • 업무 무결성을 지키기 위해 지침을 제시하여 논리적으로 지키게 하는 방법이 있고, 데이터베이스 제약을 사용하여 강제적으로 지키게 하는 방법이 있음

1.30. 성능에 대해서

  • 정규화를 할수록 엔터티가 분해되기 때문에 많은 조인이 생겨 조회 성능이 나빠지는 반면에, 중복 데이터를 사용하면 많은 인서트·업데이트가 생겨 쓰기 성능이 나빠짐

  • 성능 문제는 개념, 논리, 물리 모델링 각 단계에서 검토

  • 성능을 위해 정규화라는 관계형 모델링 우너칙을 깨고 비정규형을 사용하는 것이 데이터 무결성을 지키는 것만큼의 가치가 있는지에 대한 검토 또한 필요

  • 성능의 종류

    • 조회(Select) 성능

      • 소수 데이터 조회

        • 인덱스로 해결

      • 다량의 데이터 조회

        • 스캔 방법과 조인 방법을 사용해 해결

    • 쓰기(Insert/Update/Delete) 성능

      • 많은 트랜잭션을 동시에 최대한 빨리 입력 또는 수정 처리하는 것을 의미함

      • 한꺼번에 다량 발생하므로 경합을 줄여주는 방향으로 문제 해결 유도