관계형 데이터 모델링 노트 - 04 속성 이야기

• 속성에 대한 사설
  • 속성은 많은 개수 때문에 어려움을 겪음
  • 속성은 엔터티의 성격을 상세하게 기술하는 요소
  • 속성을 모두 도출하면 해당 엔터티가 관리하는 데이터가 무엇인지 알게 됨
  • 속성은 데이터를 저장하는 가장 작은, 독립된 저장 단위이자 더는 나눌 수 없는 원자 데이터임
  • 속성을 분석하는 시간이 많을수록 속성을 상세하게 분석할 수 있어 데이터 모델의 완성도가 높아짐
• 식별자 속성과 비식별자 속성
  • 식별자 속성이란 엔터티에 존재하는 인스턴스의 유일성을 보장해 주는 속성이나 속성 집합임
  • 인스턴스마다 서로 다른 값을 가지는 속성이 식별자 속성
  • 비식별자 속성은 일반 속성으로서, 식별자 속성에 따른 특성을 설명하는 속성
  • 식별자 속성은 결정자 속성을 의미하고 비식별자 속성은 종속자 속성을 의미함
  • 연관된 속성을 묶는 과정이 정규화인데 묶는 기준이 결정자임
  • 결정자 역할을 하는 속성과 종속자 역할을 하는 속성이 모이면 엔터티가 됨
  • 엔터티의 식별자가 정해지면 그 엔터티가 정의된 것이나 마찬가지여서 식별자는 데이터 모델링에서 중요한 역할
• 식별자 종류 - 후보 식별자
  • 후보 식별자는 주 식별자가 될 가능성이 있는 식별자를 의미함
  • 후보 식별자는 NULL을 허용함
  • 인스턴스 유일성을 보장해주기 위해 유니크 인덱스를 생성하는게 보통
  • 모든 후보 식별자를 찾긴 어려워도 주요 후보 식별자는 도출해야 하며, 최소한 업무 식별자는 도출해야함
• 식별자 종류 - 주 식별자
  • 주 식별자는 엔터티에 하나만 존재하는 대표 식별자
  • 주 식별자는 논리적으로 인스턴스를 식별하는 기준이고, PK는 테이블에 지정된 물리적인 제약을 의미하기 때문에 편의상 동일하게 사용하지만 주 식별자에 다른 속성을 추가해서 PK를 만들수 있기 때문에 완전히 일치하지는 않음
  • 하나 또는 여러 개의 후보 식별자 중에서 대표를 지정하거나 적당한 후보 식별자가 없다면 인조 식별자를 만들어 주 식별자로 사용함
  • 주 식별자는 NULL을 허용하지 않으며 하나만 존재해야 함
  • 정규화의 기준이 되는 속성이기도 하기 때문에 정규형이 맞는지를 검증할 때는 주 식별자가 명확한 기준이 됨
  • 엔터티의 성격을 대변할 수 있는 기초 속성이며 해당 엔터티만을 위해 사용되는 것이 아니라 하위 엔터티도 고려해서 선택해야함
• 주 식별자가 바뀌는 현상
  • 엔터티 정의가 불명확할 때
    • 정의가 분명하지 않으면 나중에 엔터티를 사용할 때 임의대로 사용할 수 있음
    • 개인에 따라 판단이 달라지기 때문에 결국 임의대로 사용함
    • 유연하게 정의한 것은 구체적으로 한정된 범위 내에서 정의한 것이지만 명확하지 않은 것은 한정된 범위가 없는 것임
    • 유연한 모델이 되기 위한 선결 조건은 엔터티를 명확하게 정의하는 것이며 식별자나 주 식별자를 명확하게 하는 것임
  • 데이터 분석이 미흡할 때
    • 데이터를 정확하게 분석하지 않거나, 예외 업무에 대한 고려가 미흡한 때도 주 식별자가 변경될 수 있음
  • 이력 데이터를 고려하지 않았을 때
    • 이력 등의 시간 개념을 고려하지 않아서 주 식별자가 변경되는 일도 빈번하게 발생함
    • 원천 데이터를 설계하면서 이력 데이터를 고려하지 않으면, 나중에 이력 엔터티를 설계할 때 기존에 설계한 원천 엔터티의 주 식별자가 변경될 수 있음
    • 주 식별자가 변경되지 않도록 원천 데이터를 설계할 때 이력 데이터를 고려해야함
    • 이력 데이터를 관리할지를 결정하는 것은 어려운 일이지만 모델러가 감지해야 하는 부분 중 하나임
    • 이력 데이터에 대한 요건의 변경이나 추가 때문에 주 식별자가 바뀌기도 함
  • 업무가 변경될 때
    • 업무가 바뀜으로 인해서 주 식별자가 변경되는 것은 방지 할 수 없음
    • 요구사항 분석 단계에서 업무 담당자와의 인터뷰나 주변 엔터티와의 관계 등으로 업무가 확장될 가능성이 조금이라도 감지되면 유연하게 설계해야 함
  • 엔터티를 유연하게 설계하는 방법 중 하나가 인조 식별자를 채택하는 것임
  • 주 식별자가 바뀔 수 있다고 생각되면 인조 식별자를 사용하여 영향을 최소화해야 함
• 어떤 속성을 주 식별자로 선택해야 하는가
  • 업무 식별자나 후보 식별자가 주 식별자가 될 수도 있고 둘 다 부적절하면 인조 식별자가 주 식별자가 됨
  • 주 식별자 속성의 값이 변경되지 않도록 선정
    • 주 식별자의 속성 값이 바뀌면 그 값을 사용한 다른 엔터티의 외래 식별자 속성 값도 바꿔야하기에 속성 값이 바뀌지 않도록 주 식별자를 선정해야함
    • 업무 식별자의 값은 인스턴스를 발생시키는 기준이기 때문에 속성 값이 변경되지 않음
    • 바뀔 수 있는 소속 지점은 주 식별자가 아닌 일반 속성으로 관리하는게 바람직함
    • 선분이력 방식을 사용한 이력 엔터티에서 종료일자가 주 식별자로 사용되는데 데이터가 변경된 특정이롤 업데이트 될 수 있는데 이런 경우는 성능 관점에서 도입된 개념이므로 변경이 발생해도 문제는 없지만 하위 엔터티가 없을 때만 가능함
    • 하위 엔터티가 없을 때 주 식별자 값이 바뀌는 것은 문제가 되지 않을 수도 있음
    • 이러한 관리적 예외 상황을 제외하고는 주 식별자가 변경되는 것은 피해야함
  • 일반 속성에 종속되지 않도록 선정
    • 일반 속성에 존재하는 속성이 주 식별자에 포함되면 안됨
    • 주 식별자(결정자) 속성이 일반 속성에 종속된 형태는 함수 종속을 위반했기 때문에 사용하면 안됨
    • 추출 속성을 주 식별자로 사용하면 값도 바뀔 수 있으며 일반 속성에 종속된 형태가 됨
    • 추출 속성은 일반 속성이라도 정합성을 맞추기 어려운 속성임
  • 인조 식별자에는 의미를 부여하지 않도록 선정
    • 인조 식별자 값에 부여된 의미는 대게 속성에도 존재하는데, 속성 값은 변경될수 있어 결과적으로 주 식별자 값이 바뀌게 됨
    • 업무적인 의미가 존재하면 속성으로 관리해야하며 아무 의미 없는 식별 기능만을 하는 순번으로 인조 식별자를 사용해야함
    • 여러 종류의 상품을 하나의 엔터티로 통합하여 상품번호 값에 상품종류코드 값을 포함시켜 인조 식별자에 의미가 포함되었지만 데이터의 유일성을 보장하려는 방법으로 사용하는 것이기 때문에 문제 없음
  • 주 식별자 속성에 논리적으로 널 값이 존재하지 않도록 선정
    • 주 식별자 속성 값에는 논리적인 널 데이터를 사용할 수 없음
    • 데이터 통합이나 데이터 관리 측면에서 주 식별자에 널 값이 필요할 수도 있어 널 대신에 기본 값을 사용함
    • 기본 값을 사용할 때는 한결같이 사용해야 하며 중간에 기본 값이 바뀌면 안되며 업무에서 사용되지 않을 값을 선택해야 함
• 최소한의 속성이 포함되도록 선정
  • 주 식별자가 여러 속성으로 구성돼 있고, 하위 엔터티가 많다면 주 식별자가 너무 많아져 모델이 복잡해짐
  • 주 식별자에 속한 속성이 많으면 모델의 가독성이 떨어지며 다른 엔터티와 관계를 표현할 때 관계선이 복잠해져서 관리가 어려워지며 조인 구문도 복잡해짐
• 업무적으로 활용도가 높은 속성으로 선정
  • 업무에서 사용된다는 말은 그 속성으로 조회가 자주 된다는 의미이므로 주 식별자를 활용해 조회하는 것이 좋음
  • 인조 식별자를 사용해 조회하면 필요없는 데이터를 찾아가는 한 번의 과정을 더 거치기에 업무 식별자보다 효율이 떨어짐
• 업무 식별자와 인조 식별자가 혼합되지 않도록 선정
  • '~순번' 과 같이 업무 식별자와 인조 식별자가 혼합된 속성을 부분 인조 식별자라고 함
  • 업무 식별자를 사용하든지 인조 식별자를 사용해야지 둘을 혼합해서 사용하는 것은 피하는 것이 좋음
• 슈퍼 식별자가 되지 않도록 선정
  • 인덱스와 주 식별자는 같은 개념이 아니기 때문에 인스턴스의 유일성을 보장하는 데 기여하지 않는 속성은 주 식별자에서 제외해야함
• 최소 길이가 되도록 선정
  • 주 식별자의 길이가 길면 많은 블록을 사용하고 인덱스의 깊이를 깊게 만들어 주 식별자를 활용한 조회시 효율이 떨어짐
  • 고객번호와 같은 자릿수는 무의식적으로 높게 잡지 않고 현실을 감안하여 정해야함
  • 10자리만 사용해도 약 100억의 고객을 저장할 수 있음
  • Varchar 타입보다는 Number 타입이 저장 공간이 절약됨
• 주 식별자 속성 값은 가능한 고정 길이가 되도록 선정
  • 배타 속성이 주 식별자에 사용되면 값의 길이가 달라질 수 있지만, 주 식별자 값의 길이는 가능하면 같아야함
  • 주 식별자의 값의 길이가 같아야 데이터 성격이 더욱 명확해질 수 있으며, 조회하는데 혼선이 생기지 않음
• 주 식별자 속성은 전사에서 한 번만 사용되도록 선정
  • 서브타입 엔터티나 엔터티를 수직 분할한 1:1 관계의 엔터티 등은 주 식별자가 같음
  • 근본적으로 같은 집합을 의미할 때를 제외하고 다소 엄격한 기준이지만 주 식별자가 같지 않도록 설계하는 것이 바람직함
  • 관계 속성과 시스템 속성을 제외하고 중복 속성 등이 전혀 사용되지 않도록 하는 것은 힘들지만 전체 모델에서 한 번만 사용되도록 원칙을 정함으로써 주 식별자 선정에 더욱 신중하게 정할 수 있음
•  암호화 대상 속성이 포함되지 않도록 선정
  
  • 가까운 미래에 암호화를 해야 할 가능성이 있는 속성이 주 식별자에 포함되면 안됨
  • 암호화 기술과 인덱스 기술이 아무리 발전해도 암호화 속성을 사용하는 것은 성능상 비효율적임
• 업무를 대표할 수 있는 속성으로 선정
  • 업무를 대표하는 속성을 엔터티의 주 식별자로 사용하면 엔터티를 더욱 직관적으로 이해할 수 있어 모델의 가독성이 좋아짐
• 주 식별자를 단순하게 설계해야 하는 이유
  • 다른 엔터티와 관계를 표현할 때 관계선이 복잡해져 가독성이 떨어지며 관계 자체도 관리하기 어려움
  • 조인 구문이 복잡해져 쿼리가 길어져 실수할 확률이 높아짐
  • 주 식별자 인덱스가 커져 성능에도 좋지 않음
  • 핵심적으로 사용되는 엔터티일수록 주 식별자 속성을 단순화 해야함
• 주 식별자 선정 절차
  • 업무 식별자 도출 > 후보 식별자 도출 > 업무 식별자를 주 식별자로 검토 및 선정 > 후보 식별자 중 주 식별자로 검토 및 선정 > 인조 식별자를 주 식별자로 선정
  • 엔터티를 정의하는 단계에서 업무 식별자를 도출하고 후보 식별자도 주 식별자가 될 수 있기에 가능한 모든 후보 식별자를 도출하여 주 식별자가 되지 않더라도 유니크 인덱스를 설정하기도 함
  • 후보 식별자를 모두 도출하고 나서 그 중에 업무에서 대표로 사용할 수 있는 더 좋은 후보 식별자를 업무 식별자로 선정하기도함
  • 업무 식별자는 비지니스 의미를 파악하기 쉬우며 업무에서 많이 사용되므로 조회 요건에 효율적임
  • 업무 식별자는 데이터를 발생시킨 주체이므로 보통 여러 속성으로 구성되는데 해당 엔터티가 주요 엔터티라서 하위 엔터티가 많다면 복잡한 업무 식별자를 주 식별자로 선택하는 것은 신중하게 고려해야함
  • 인조 식별자를 사용할 때는 업무 식별자와 후보 식별자는 대리 식별자가 되므로 반드시 유니스 인덱스를 생성해야 엔터티 성격을 파악하기 쉬우며 중복을 막아 데이터 발생에 혼선이 없어 데이터 품질이 높아짐
  • 상위 엔터티에서 시작해서 하위 엔터티로 차례로 주 식별자를 정함
• 복잡한 주 식별자
  • 기준 데이터를 관리할 때
    • 기준 엔터티는 업무의 기준이 되는 데이터를 관리하는 엔터티임
    • 기준 엔터티 중에는 기준이 복잡함에 따라 주 식별자가 복잡해지는 경우가 있음
    • 하지만 기준 엔터티는 보통 하위 엔터티(참조 무결성 제약으로 참조되는 엔터티)가 없기 때문에 문제가 없음
    • 기준 엔터티에 업무 식별자가 복잡하다는 이유로 인조 식별자를 사용하면 기준이 되는 속성(결정자)과 기준에 의한 결과를 저장하는 속성(종속자) 사이에 혼란만 생김
  • 집계 데이터를 관리할 때
    • 집계 엔터티는 집계되는 기준이 많을수록 주 식별자가 복잡해짐
    • 하지만 하위 엔터티가 없으며 인조 식별자를 사용할 이유도 없음
  • 인스턴스를 생성하는 기준이 복잡할 때
    • 데이터를 관리하려는 상세 수준에 따라서 주 식별자가 복잡해질 수 있음
    • 상세 수준이 높을수록 주 식별자가 늘어남
  • 교차 엔터티일 때
    • 교차 엔터티는 일반적으로 양쪽 엔터티의 주 식별자를 식별자로 상속받기 때문에 주 식별자가 복잡함
  • 슈퍼 식별자가 사용될 때
    • 주 식별자를 잘못 결정한 것이지만, 그 자체로 주 식별자 역할은 하기 때문에 구분이 쉽지 않음
    • 커버링 인텍스를 주 식별자로 사용하기 위해서 슈퍼 식별자를 주 식별자로 선택하지 말아야함
  • 주 식별자 상속이 지속적으로 이루어질 때
    • 존재 종속 원칙에 근거해 식별자로 상속했다면 주 식별자가 복잡해지는 것이 잘못된 것은 아님
    • 하지만 효율성을 고려해 상속/단절 전략을 새워야 할 때도 있음
  • 주 식별자가 복잡하다는 이유만으로 특정 숫자를 정해 그 이상의 속성으로 구성된 주 식별자를 사용하지 못하게 하는 것은 근거도 이유도 없음
  • 업무 식별자가 복잡하지만 하위 엔터티가 좋재 하지 않으면 주 식별자가 많더라도 문제가 없음
  • 반대로 업무 식별자가 확고하지 않고 업무 식별자가 바뀔 가능성이 존재하면 인조 식별자를 채택할 수 있음
• 복합 주 식별자의 속성 순서
  • 이 작업은 주 식별자가 결정된 후에 마지막으로 하게 됨
  • 조회 성능을 고려하여 속성을 순서를 결정함
  • 개발이 마무리 되고 테스트 단계에서 성능 문제 때문에 주 식별자의 속성 순서를 변경하는 일이 자주 발생함
  • 분석과 설계 단계에서 주요 요건을 위주로 직관적으로 판단하더라도 주 식별자의 속성 순서를 결정해야함
  • 조건절에 포함된 속성 중에서 분포도를 가장 줄일 수 있는 속성이 주 식별자의 맨 처음에 오는 것이 효율적임
  • 조건절에 포함된 속성이 관계 속성이라면 상위 엔터티의 값과 관계가 있는 하위 엔터티의 인스턴스 개수인 관계비를 의미하기 때문에 관계비가 적은 속성이 분포도가 좋은 것이기 때문에 이 속성이 주 식별자의 맨 앞에 존재해야함
  • 배치 업무는 주로 일자를 기준으로 조회하므로 일자 속성이 복합 주 식별자의 맨 앞에 위치하는 것이 좋음
• 교차 엔터티의 주 식별자
  • 양쪽 상위 엔터티의 주 식별자만으로 교체 엔터티의 주 식별자를 구성
    • BOM모델이나 양쪽 엔터티의 인스턴스 간 매핑을 관리하는 엔터티
    • 업무적으로 기준 성격이 강한 상위 엔터티의 주 식별자를 먼저 위치시킴
  • 양쪽 상위 엔터티의 주 식별자에 자체 업무 식별자가 추가된 구성
    • 상위 엔터티의 주 식별자만으로 교차 엔터티의 인스턴스를 식별할 수 없을 경우
  • 인조 식별자로 구성
    • 상위 엔터티의 주 식별자로 구성하기에는 업무 식별자가 복잡해지는 경우
  • 양쪽 상위 엔터티의 주 식별자 중에서 자주 사용하는 한쪽 부모 엔터티의 주 식별자만 상속하면서 순번 속성을 추가하는 구성
    • 업무 식별자 속성과 인조 식별자 속성을 같이 사용하는 것은 바람직하지는 않음
  • 상위 엔터티를 인조 식별자로 채택하면 교차 엔터티의 주 식별자는 단순해짐
• 사원 엔터티의 주 식별자와 사원의 정의에 대해서
  • 주 식별자인 사원번호에 입사연도를 사용하는 것은 입사 연도 노출도 문제지만 퇴사하고 재입사한다면 사원주민등록번호인 업무 식별자가 중복이 되며 사원에 대해 집계할 때는 어떤 식으로든 추가적인 연산이 필요함
  • 따라서 주 식별자인 값에는 어떤 체계도 없는 것이 바람직함
  • 사원 엔터티가 고객 엔터티에 통합되는 경우 많은 경우에 사원번호의 상징성 때문에 사원 엔터티에 사원번호를 주 식별자로하고 고객번호는 유니크 인덱스를 생성하여 중복되지 않도록함
• 식별자 종류 - 인조 식별자
  • 후보 식별자 중에서 주 식별자로 사용할 마땅한 후보가 없을 때, 순번 성격의 속성을 추가하여 식별자로 사용함
  • 보통 업무 식별자를 주 식별자로 사용해야 업무가 더욱 명확해지지만 소수의 실체 엔터티인 고객번호/계좌번호/부서번호/상품번호 등과 같이 인조 식별자를 사용하는 것이 업무를 더욱 명확하게 만들기도함
  • 행위 엔터티 등에서 인조 식별자를 사용하면 업무에 대한 가독성이 현저니 떨어지며 인조 식별자 만으로 업무를 파악하기 힘들고 새로운 인스턴스가 생성되는 기준을 알 수 없음
  • 인조 식별자는 업무와의 결합도를 감소시켜 모델의 확장성을 증가시키고 유연한 모델이 됨
  • 인조 식별자를 사용하면 업무 식별자에 유니크 인덱스를 생성하여 관리해야 함
  • 인조 식별자를 사용함에 있어서 무분별하게 요건에 맞지 않게 사용하거나 의미를 부여하지 않아야함
  • 인조 식별자 사용 순서
    • 후보 식별자 도출 > 후보 식별자 중에 주 식별자로 적당한 후보가 있는지 검토 > 적당한 후보가 없다면 인조 식별자 사용
• 인조 식별자를 사용해야 좋을 때
  • 주 식별자가 복잡하면서 하위 엔터티가 다수일 때
    • 주 식별자가 복잡한 건 문제가 되지 않지만, 주 식별자가 복잡하면서 하위 엔터티가 많을 경우 문제임
  • 업무를 직관적으로 만들어 주는 번호를 사용할 때
    • 주 식별자만 보고 업무를 알게 할 필요는 없지만 계좌번호/고객번호와 같이 일반화된 용어를 주 식별자로 사용하면 업무가 직관적으로 연상됨
    • 실체 엔터티나 자립 엔터티인 경우
  • 적당한 후보 식별자가 없을 때
  • 업무가 변경될 가능성이 있을 때
  • 업무가 확장될 가능성이 있을 때
  • 업무 식별자의 값이 변경될 가능성이 있을 때
  • 업무 식별자의 값에 NULL 값이 포함될 수 있을 때
  • 업무 식별자의 길이가 길 때
  • 업무 식별자의 값에 보안을 적용해야 할 때
• 업무 식별자와 인조 식별자의 혼합
  • 업무 식별자와 인조 식별자를 혼합해서 사용하면 바람직하지 않은 이유
    • 요건을 알기 어려워 가독성이 떨어짐
    • 엔터티 성격이 모호해짐
      • 발생순번/처리순번/등록순번과 같은 일반적인 속성을 사용하면 엔터티 성격이 모호해짐
      • 또한 주문순번 속성이 주문한 진짜 순서를 의미하여 사용한다면 업무 식별자에 가까움
    • 모델을 관리하기 복잡해짐
      • 모델의 가독성이 떨어지기 때문에 관리가 어려워지며, 비슷한 주 식별자의 남발로 인해 엔터티 간의 관계를 관리하기가 어려워짐
• 부분 인조 식별자를 사용할 수 있는 경우
  • 보통 쿼리의 성능을 최우선으로 고려해야 할때 사용함
    • 교차 엔터티인 경우 양쪽 엔터티에서 주 식별자를 상속받는데 한쪽  엔터티를 기준으로 대부분의 조회를 수행하게 되는 경우 한쪽 엔터티와 인조 식별자의 조합으로 식별자를 구성함
  • 엔터티 사이의 관계가 종속 관계이고 이때 하위 엔터티의 업무 식별자가 분명하지 않을 경우
    • 등록일시 등의 시간 속성이 업무 식별자에 포함되는 게 무의미해서 업무 식별자가 분명하지 않을 때 부분 인조 식별자인 순번을 사용하여 식별자를 구성함
  • 업무 식별자가 변경될 가능성이 있는 경우
  • 일자/일시 속성이 포함된 엔터티의 하위 엔터티가 많으며, 주요 업무 식별자를 자주 사용해야 할 때
    • 하위 엔터티를 직접 조회하거나 해당 데이터를 보면서 업무를 수행하는 것도 불편함
    • 이런 경우 일자/일시를 사용하기 보다 부분 인조 식별자인 순번을 사용
• 식별자 종류 - 대리 식별자
  • 주 식별자로 선정되지 않은 후보 식별자가 대리 식별자
  • 인조 식별자를 주 식별자로 사용하면 모든 후보 식별자가 대리 식별자가 됨
  • 인조 식별자를 사용하지 않으면 주 식별자와 대리 식별자를 합해야 후보 식별자가 됨
  • 인조 식별자를 주 식별자로 사용했을 경우 대리 식별자를 별도 관리해야함
• 식별자 종류 - 슈퍼 식별자
  • 주 식별자에 다른 속성을 추가해서 만든 식별자
  • 슈퍼 식별자를 주 식별자로 사용하는 잘못된 이유
    • 후보 식별자에 대해 이해가 부족
    • 커버링 인덱스 사용을 위해
    • 식별자를 제대로 분석하지 못함
  • 주 식별자는 인스턴스를 생성하는 기준과 인스턴스를 식별하는 역할만 해야하는데 슈퍼 식별자를 주 식별자로 사용하면 엔터티의 성격이 불분명해지며 엔티티 간 관계도 모호해지며 가독성도 떨어짐
  • 정규형은 식별자를 기준으로 종속성을 따지는 것인데 주 식별자가 모호하면 정확한 정규화가 불가능함
  • 슈퍼 식별자는 어떤 상황에서도 주 식별자로 사용하지 않은 것을 원칙으로 함
  • 주 식별자와 인덱스를 혼용해서 사용해서도 안됨
• 속성 종류 - 기초 속성
  • 엔터티의 본질을 설명하는 속성
  • 기초 속성을 보면 엔터티의 정의를 알 수 있음
    • 업무 식별자, 후보 식별자, 엔터티의 특성을 설명하는 속성 등이 포함됨
  • 엔터티가 어느 주제 영역에 속해야 하는지에 대한 오너십이 모델 오너십이며, 모델 오너십을 정하는 기준이 기초 속성임
  • 주로 사용자의 입력이라는 행위에 의해서 생성되며 논리 모델링 초반에 도출됨
    • 기초 > 관계 > 추출 > 시스템 순서로 도출
• 속성 종류 - 관계 속성
  • 관계 속성은 타 엔터티와의 관계를 알기 위해 사용하는 외래 식별자 속성
  • 참조되는 엔터티와 존재 종속 관계면 관계 속성은 엔터티의 본질을 의미하므로 기초 속성이기도 함
  • 단순히 참조만 하는 관계라면 기초 속성이 아님
• 속성 종류 - 추출 속성
  
  • 추출 속성은 기존에 존재하는 원본 속성의 값을 연산해서 생성할 수 있는 속성
  • 주로 공식에 의한 계산으로 값을 구함
  • 추출 속성은 원본 속성에 종속되어 있는데 이를 파생 종속이라 함
  • 같은 엔터티에 추출 속성과 원본 속성이 있는 것은 연산하는 대상 인스턴스가 주로 하나라는 것을 의미
  • 서로 다른 엔터티에 있다면 연산하는 대상 인스턴스가 보통 하나 이상임
  • 추출 속성은 여러 인스턴스에서 연산한 값을 관리하는 것이 기본 원칙임
    • 주문과 주문상품 엔터티가 있을 때 주문상품에는 주문단가, 주문수량 속성(원본 속성)이 존재하고 주문 엔터티에는 주문총금액 속성(추출 속성)이 있음
    • 성능 문제가 있을 경우에만 주문 엔터티에 주문총금액 속성을 넣기도 하지만 주문상품에 주문금액 속성은  사용하지 않는 것이 원침임
    • 고객의 최근 주문한 일자를 관리한다면 고객 엔터티에 최종주문일자 속성(추출 속성)을 만듬
  • 추출 속성을 사용하는 가장 큰 목적은 데이터 조회 시간을 단축하기 위함임
  • 추출 속성의 문제점
    • 정합성이 저하될 수 있다는 것
      • 계산된 값이기 때문에 식별이 거이 불가능하며 잘못된 값을 찾아내기는 더욱 어려움
    • 정합성을 실시간으로 맞춰야함
      • 원본 속성 값에 변화가 발생하면 연산을 다시 해서 새로운 값으로 추출 속성에 반영해야함
  • 성능 문제가 아니라면 추출 속성을 사용하지 않는 것이 원칙
    • 성능 문제로 사용해야 한다면 가능하면 DB에서 제공하는 각종 제약을 사용하여 강제적으로 맞추는것이 좋음
  • 추출 속성을 주 식별자로 사용해서는 안됨
    • 추출 속성은 다른 속성 값에서 추출된 속성으로 파생 종속 속성은 결정자가 될 수 없으며 원본 속성이 변경되지 않는다고 하더라도 바람직하지 않음
  • 추출 속성은 다른 속성 값에서 재현할 수 있는 속성인데, 만약 재현할 수 없다면 추출 속성이 아님
  • 추출 속성은 ERD에서 관리해야 하며 연산 규칙을 지정해 관리할 수 있도록 해야함
  • 추출 속성을 사용했다면 원본 속성의 관리가 더욱 중요함
    • 원본 속성이 관리가 안되거나 값에 이상이 생기면 추출 속성 값을 재생할 수 없음
• 속성 종류 - 시스템 속성
  • 시스템 속성은 데이터에 대한 추적/감시를 위해 사용하는 속성(생성일/생성자/수정일/수정자)
  • 시스템 속성에 업무적인 의미를 부여해 업무적으로 사용하지 않는 것이 좋음
  • 시스템 속성을 삭제하고도 업무에 지장을 주지 않도록 설계하는 것이 좋음
  • 데이터를 추적해야 할 상황은 자주 발생하지 않기 때문에 데이터 추적을 정밀하게 하려고 많은 속성을 사용해서는 안됨
  • 보통 모든 엔터티에 추가하는 것이 원칙이지만 성능에 매우 민감한 엔터티는 시스템 속성을 삭제하는 것만으로도 미세한 성능 향상을 기대할 수 있음
  • 시스템 속성을 ERD에 표현하는 시기는 DB에 테이블로 생성하기 바로 직전임
  • 시스템 속성 선정은 가능한 빨리 하는 것이 좋음
• 추출 속성의 종류 - 중복 속성
  • 중복 속성을 제거하는 것이 관계형 데이터 모델링의 중요한 목적 중 하나지만 간혹 긴요하게 사용할 때가 있음
  • 중복 속성은 주로 상위 엔터티에서 하위 엔터티에 복사해 놓아 조인을 피할때 사용함
    • 한두건의 조인은 크게 문제가 없지만 대량 조회일 경우 영향이 큼
  • 추출 속성은 때에 따라 효과적이어서 사용할 여기가 있는 반면, 중복 속성을 사용하면 얻는 것에 비해 잃는 것이 크기 때문에 점점 중복 속성 사용을 꺼려하는 추세
    • 정합성을 맞추기가 힘들기 때문임
• 시점 데이터가 중복 속성이다?
  • 그 당시의 데이터를 관리한다면 중복 속성이라고 볼 수 없다
    • 시점 데이터를 관리한다는 것은 그 당시 값을 알기 위해서이며 이력 관리와 동일함
  • OO이력에 있는 속성을 다른 엔터티에서 자주 조회한다면 추출 속성을 사용함
  • 이력 데이터를 관리하지 않고 시점 데이터만을 관리하는 것은 바람직하지 않음
  • 이력 데이터가 있다면 시점 데이터는 추출 속성이기 때문에 성능 문제까지 검토해서 채택 여부를 결정함
• 중복 속성을 사용할 수 있는 경우
  • 보통 중복 속성은 성능 문제를 해결하기 위해 사용함
  • 데이터 정합성 문제가 최소화되면 중복 속성을 사용할 수 있는데 값이 변하지 않는 속성을 사용하는 것이다
  • 원본 속성이 존재하는 상위 엔터티와 중복 속성이 존재하는 하위 엔터티의 관계비가 1:1에 가까울수록 중복 속성을 사용할 때의 부작용이 줄어듬
    • 관계비가 많다면 정합성도 맞추기 힘들지만 저장 공간 또한 증가하게 됨
  • 엔터티 간의 관계가 참조 관계일 때보다는 종속 관계일 때가 비교적 중복 속성을 채택하기 적당함
  • 가능한 짧으면 좋음
• 단일 값 속성과 다가 속성
  • 단일 값 속성은 한 시점에 하나의 값만을 가지는 속성
    • 데이터는 원자 값이어야 한다는 원칙을 지킨 정상적인 속성
  • 다가 속성은 유사한 성격의 값을 복수로 가지고 있는 속성
    • 한 속성에 유사한 종류의 값이 여러 개 존재하는 속성
    • 취미1, 취미2, 취미3
  • 복합 속성은 두 개 이상의 세부 속성으로 구성된 속성
    • 집 전화번호, 사무실 전화번호, 휴대폰번호
    • 이를 논리 다가 속성으로 구분할 수도 있으며 구체적이지 않은 속성 명과 관련있음
  • 다가 속성은 모델링하는 과정에서는 발생할 수는 있지만 최종 물리 모델에서 여러 개의 속성으로 분해하든지, 별도의 1정규형 엔터티로 분리해야함
• 단순 속성과 복합 속성
  • 단순 속성은 일반적인 원자 값으로 이루어져있는 속성
    • 원자 값은 논리적으로 의미가 있으면 되지 시/분/초를 나누는 것은 의미가 없음
    • 단순 속성 = 원자 속성
  • 복합 속성은 여러 의미를 가지는 속성
    • 두 개 이상의 의미 있는 단순 속성으로 분해할 수 있는 속성으로 1정규화와 관련된 속성
    • 나눠서 의미가 있으면 복합 속성
    • 전화번호나 주소와 같은 복합 속성
      • 시/구/동 등으로 나눌 수 있지만 업무에서 사용하지 않기에 분리하지 말아야함
    • 인조 식별자에 의미가 부여된 속성
    • 코드값/코드명이 한 종류를 의미하는 것이 아니라 두 종류가 혼합돼 있는 경우는 두 개의 코드 속성으로 분해해야함
    • 텍스트 속성도 넓은 의미의 복합 속성임
      • 단순 텍스트라고 하더라도 주제를 나눌 수  있는 내용이라면 개별 속성으로 분해하는 것이 좋음
      • 조회에 사용하지 않더라도 데이터는 도메인에 맞게 관리하는 것이 바람직함
  • 복합 속성은 이론적으로 잘못 설계된 속성임으로 여러 개의 개별 속성으로 나누는 것이 원칙
  • 만약 복합 속성 전체로 조회한다면 굳이 나누지 않고 하나의 속성으로 관리하는 것이 효율적임
  • 모델링하는 과정에서는 발생할 수는 있지만 최종 물리 모델에서 여러 개의 속성으로 분해하든지, 별도의 1정규형 엔터티로 분리해야함
• 필수 속성과 선택 속성
  •