어떡하집 프로젝트 구상

향후 내집마련에 관련된 인사이트를 얻기위해 프로젝트를 진행하려고 합니다.

정민호정민호

1. 프로젝트를 시작한 동기

저는 오래전부터 내집마련에 관심을 가지고 있지만 막상 이렇다할 행동을 취한것은 없었습니다. 그나마 해둔것이라곤 시드머니를 만들기 위해 돈을 아껴쓰고 모으는 행동 뿐이었습니다.

그러다 최근 부동산에 대한 관심도가 부쩍 늘어났습니다. 부동산관련 카페에서 다른사람이 작성한 글을 읽어보거나, 유튜브 등을 보고 있습니다.

그 중에 이 프로젝트를 해봐야겠다고 마음먹게한 유튜브 영상이 하나 있었습니다.

그 영상은 유튜버 렘군RemGoon이란 분이 업로드한 부동산 랜드마크를 활용한 투자법 1탄과 부동산 랜드마크를 활용한 투자법 2탄 이었습니다.

이 영상에서는 랜드마크 아파트. 즉, 해당 지역의 아파트 중 시세를 이끌어 가는 대장(랜드마크) 아파트와 저평가된 아파트를 찾는 방법을 알려주었습니다.

따라서 저는 이 방법을 시스템화하여 자동으로 랜드마크 아파트와 저평가된 아파트를 찾아주는 프로젝트를 구상하게 되었습니다.

2. 프로젝트 진행계획

프로젝트는 사전조사 → 설계 → 구현 단계로 진행하려고 합니다.

사전조사 단계에서는 부동산과 관련하여 유사 시스템을 분석 합니다. 유사 시스템을 분석함으로써 어떤 데이터들을 수집할 것인지 명확하게 정의할 수 있고 또, 제공하는 기능들을 통해 본 시스템에서 구현할 기능에 대한 인사이트를 얻을 수 있기 떄문입니다.

설계 단계에서는 데이터를 수집과 처리, 제공하는 과정들을 제공하기 위해 어떤 툴을 사용하고 어떻게 구현할 것인지 정의 합니다.

구현 단계에서는 시스템을 구현하기 위한 환경을 구축하고 기능을 개발합니다.

프로젝트를 진행함에 있어 각 단계는 반드시 순서에 맞춰 진행하지 않고 필요 또는 제가 생각하는 우선순위에 따라서 유동적으로 진행하려고 합니다.

그리고 제가 어떻게 조사하고 설계, 구현 했는지 포스팅 해보려고 합니다. 포스팅은 최소 한 주에 하나는 포스팅하려고 합니다.

3. 프로젝트 이슈사항

3.1. 데이터 수집 부분

현재 프로젝트를 진행함에 있어 수집되어야 할 정보는 아파트와 관련된 정보입니다. 아파트와 관련된 정보는 아파트의 좌표와 주소(도로명/지번), 관련기사, 매매가, 전세가, 세대수, 평수, 평면도 등이 있습니다.

이 정보들 중 관련기사 정보를 수집할 때 특정 사이트에서 어뷰징 행위로 간주될텐데 이를 어떻게 풀것이며, 수집하는 속도를 어떻게 높일 것 인지 고민됩니다.

3.2. 변경되는 주소정보

사실 저는 회사에서 프로젝트를 하기 전까지 주소는 바뀌지 않는 정보인 줄 알았습니다. 주소가 변경되는 정확한 이유는 모르겠지만 아마도 도로가 변경되거나, 도시가 생기거나 하는 등의 이유가 있지 않을까 생각됩니다.

변경되는 주소는 아마도 PNU 코드로 막연하게 해결할 수 있지 않을까 생각되는데, 문제는 주소정보를 어떻게 자동으로 최신화 할 것인지 고민됩니다.

3.3. 아파트 줄임말

아파트 명칭이 유일하면 좋겠지만 그렇지 않고, 여러 사람들이 특정 아파트를 하나의 명칭으로 표현하면 좋겠지만 이것도 그렇지 않습니다. 앞서 소개한 유튜브 동영상에서도 '래미안힐스테이트’를 지명인 고덕과 합쳐서 '고래힐’이라고 표현하고 있습니다.

데이터 수집할 때 여러 사이트에서 아파트 정보를 수집하려고 생각하는데, 하나의 아파트가 여러 명칭들로 표현되면 난감 할것 같습니다.

수작업으로 아파트 명칭의 메타정보를 관리하기엔 아파트의 수가 너무나 많은데 이를 어떻게 해결할지 고민됩니다.

4. 프로젝트를 하면서 기대하는 것

이 프로젝트를 진행하면서 부동산에 관한 지식과 데이터와 관련된 전공 지식 향상을 기대하고 있습니다.

그리고 언제가 될진 모르겠지만 향후 내집마련 시 이 시스템을 통해 인사이트를 얻을 수 있기를 기대하고 있습니다.

시스템에서는 저평가된 지역 및 아파트를 도출 해주고, 특정 지역의 호재/악재를 파악 할 수 있기를 기대하고 있습니다.

또 해외 부동산 정보를 수집하여 국내의 부동산과 비교함으로써 어떠한 상관관계가 있는지 파악할 수 있지 않을까 기대합니다.

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

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

정민호정민호

1. 엔터티 이야기

2. 정규화 이야기

3. 데이터 통합과 서브타입 이야기

4. 속성 이야기

5. 관계 이야기

6. 이력 데이터 이야기

요약

  1. 이력 데이터

    1. 이력 데이터 개요

      1. 이력 데이터(Alterd Data)란?

        • 지나간 데이터(Bygone Data). 즉 입력된 데이터가 변경(정정 아님)된 데이터를 이력데이터라고 함

        • 이력 데이터는 원천 데이터의 함수 종속이나 파생 종속과 연관됨

        • 이력 데이터를 관리하는 이유는 데이터의 과거 상태를 추적할 필요가 있기 때문

        • 모델링 시 주요 엔터티는 이력 데이터 요건이 없더라도 생길 것을 대비하는 것이 좋음

        • 주 식별자가 아닌 주 식별자에 종속된 속성 값이 바뀌면 이력 데이터가 생기게 됨

      2. 내역데이터란

        • 예전에 쌓인 데이터여도 변경되지 않았다면 이력 데이터가 아니라 내역 데이터

        • 과거 데이터라도 본질(원천) 데이터일 수 있음

        • 내역 데이터는 살아있는 데이터이며, 내역 성격의 엔터티는 이력 데이터를 같이 관리하지 않아야함

      3. 이력 엔터티 설계 시점

        • 1. 원천 엔터티와 동시에 이력 엔터티를 설계

          • 이력 엔터티만을 설계하는 특정 시점이 사실상 없다는 것을 의미

          • 따라서 본질(원천) 데이터를 먼저 확고히 해야한 다는 점만 주의하면, 주요 엔터티는 개념 모델링 단계에서 이력 엔터티를 고려(또는 논의)하는 것이 현실적으로 효율적

        • 2. 원천 엔터티의 설계가 끝난 시점인 논리 모델링이 끝난 후 또는 물리 모델링 시점에 설계

          • 이력 데이터를 논리 모델링이 끝난 물리 모델링 단계에서 설계하면 기존(원천) 엔터티가 영향을 받을 수 있음

        • 이력 엔터티 설계 시점은 종합적인 사고가 가능하다는 전제하에서는 한 번에 설계하는게 좋으며, 본질 데이터를 설계할 때 최소한 모델 구조에 대한 변경을 염두에 두고 이력 데이터를 고민해야함

          • 중요한 엔터티는 업무 식별자(또는 주 식별자)와 주요 핵심 속성, 이력 데이터 관리 방안, 심각한 성능 이슈 등을 한꺼번에 고민하고 종합적으로 분석 판단해야함

        • 그리고 이력 데이터를 설계할 때는 선분이력 방식으로 설계할지를 같이 결정해야하며, 선분이력 시 종료일자 속성이 주 식별자에 포함된다면 그 엔터티에는 하위(자식) 엔터티가 없어야 함

  2. 이력 엔터티 설계 방법

    1. 이력 엔터티 설계 방법 개요

      1. 엔터티 단위 이력

        • 스냅샷 방식으로 저장 공간의 낭비가 심하나, 특정 시점의 전체 속성 값을 조회하는 요건이 많을 때 사용하면 좋음

        • 데이터 관리하기가 수월하며, 하위(자식) 엔터티에 미치는 영향도 차단했기 대문에 모델이 안정적인 장점이 있으나, 거의 유사한 스키마의 엔터티를 동일하게 유지해야하는 부담이 존재

        • 실무에서 가장 많이 사용하는 방법이며, 원천 엔터티의 하위 엔터티 또는 서브타입이 존재한다면 이 방법을 사용해야 함

      2. 속성 단위 이력(변경된 속성)

        • 변경된 속성의 데이터만 별도로 관리하여 저장 공간이 가장 절약되지만, 과거 특정한 시점에 대해 변경된 속성 값과 변경되지 않은 속성 값을 같이 조회하기 어려움

        • 변경 데이터를 별도의 엔터티에서 관리하는 방법과 함께 관리하는 방법으로 나뉠 수 있음

      3. 속성 그룹 단위 이력(유사)

        • 속성 중 내용(도메인)이 유사하거나 같이 사용될 수 있는 속성을 묶어서 별도의 엔터티에서 이력 데이터를 관리하는 방법

        • 적절하게 사용할 시 엔터티 단위 이력과 속성 단위 이력의 장점만을 살릴 수 있음

    2. 엔터티 단위 이력 설계

      1. 이력 데이터를 별도의 엔터티에서 관리하는 방법

        1. 실체 엔터티

          • 실체 엔터티에서는 원천 데이터를 관리하는 엔터티를 변경없이 그대로 존재하며, 이력 데이터는 원천 엔터티와 별도로 이력 엔터티에서 관리함(이력 엔터티의 주식별자에 변경일자 속성 추가)

          • 하위(이력) 엔터티가 존재하기 때문에 원천 데이터와 이력 데이터를 한꺼번에 조회하는 요건이 많다면 비효율이 발생

          • 비효율을 개선하기 위해 비정규화의 일종인 중복데이터를 사용할 수 있으나, 데이터 중복이 심하게 발생하므로 원칙적으로 사용을 지양해야함

        2. 기준 엔터티

          • 기준 엔터티이면서 원천 엔터티인 엔터티는 기준일자 속성까지 포함하여 관리

          • 데이터는 과거에 입력됐지만 현재도 살아 있는 원천 데이터

          • 기준 데이터에 대한 이력(정정 아님) 데이터를 설계할 시 별도의 이력 엔터티 생성 후 관리(이력 엔터티의 주식별자에 변경일자 속성 추가)

          • 또는 기준 엔터티에는 현재의 데이터만 관리하고 별도의 이력 엔터티 생성 후 관리(이력 엔터티의 주식별자에 변경일자 속성 추가)

        3. 행위 엔터티

          • 행위 엔터티에서는 이력을 관리하고자 하는 대상의 엔터티들의 구조를 그대로 이력 엔터티를 생성하여 관리함

      2. 하나의 엔터티에 원천 데이터와 변경 데이터를 함께 관리하는 방법

        • 일반적으로 주요 실체, 행위, 엔터티에는 사용하지 않지만, 기준 엔터티는 하위 엔터티가 존재하지 않고 데이터양도 적어서 이 방법을 사용하기 적절

          1. 실체 엔터티

        • 이력 데이터를 설계할 때는 먼저 원천 데이터를 설계

        • 원천 데이터와 변경 데이터를 함께 관리하기 때문에 엔터티 명에 굳이 '~이력’을 붙이지 않음

        • 원천 엔터티에 변경일자 속성 또는 순번 등의 인조식별자를 추가하며, 변경일자 속성에는 변경되지 않았다는 것을 의미하는 값으로 '9999-12-31’을 사용함

          1. 기준 엔터티

        • 조회하는데 문제가 없다면 굳이 이력 데이터 개념으로 설계할 필요는 없음

          1. 행위 엔터티

        • 하위(자식) 엔터티가 존재할 때 원천 데이터와 변경 데이터를 함께 관리하는 것은 바람직하지 않음

        • (?) 이해가 잘 안됨

      3. 속성 단위로 이력 데이터를 설계하는 방법

        • 특정 속성에 대한 이력 엔터티를 생성 후 변경일자 및 변경값 관리

        • 중복 데이터가 없어 데이터 저장공간이 절약되지만, 변경되지 않은 속성까지 함께 조회하긴 어려움

        • 실무에서 많이 사용되지 않지만, 자주 사용하는 중요한 속성에 대해서는 이 방법의 사용을 고려해야 함

      4. 원천 데이터를 별도의 엔터티에서 관리하면서, 변경 데이터와 원천 데이터를 함께 관리하는 방법

        • 원천 엔터티의 이력을 관리하고자하는 특정 속성을 추출하여 별도의 엔터티에서 데이터를 관리

        • 변경 이력 데이터로 설계한 것인지, 발생내역 데이터로 설계한 것인지 구분해야 함

    3. 속성 단위 이력 설계

      • 역할을 관리하는 별도의 엔터티를 설계할 때 자주 사용됨

      • 별도의 엔터티에서 관리하는 이유는 역할은 보통 한 개가 아니라는 사실과 함께 이력 데이터까지 고려하기 때문

      • 성능 문제를 해결하기 위해 이력 데이터를 선분이력으로 관리하거나, 또는 비정규화(데이터 중복)하는 방법이 있음

    4. 속성 그룹 단위 이력 설계

      • 속성 단위 이력 설계하는 방법과 같으며, 다만 성경이 유사한 속성들을 그룹으로 묶어서 관리하는데 차이가 있음

      • 유사한 속성들을 그룹으로 묶어서 관리하는 이유는 같이 조회되는 요건을 처리하기 위함

      • 따라서 유사한 속성이 아니더라도 같이 사용되는 속성을 그룹으로 묶을 수도 있음

      • 적절하게 사용하면 효율적인 모델이 되지만, 명확한 기준 없이 속성을 묶으면 원천 엔터티나 이력 엔터티의 성격이 혼한스러워질 수 있음

    5. 종 테이블(Vertical Table)을 이용한 이력 설계

      • 변경된 속성을 종 테이블 형식의 별도 엔터티에서 통합 관리하는 것

      • 이 방법을 사용할 시 엔터티명과 속성명에 대한 관리 부담이 부가적으로 생기며, 관리할 속성이 명확하지 않고 특정 시점의 모든 속성 데이터를 조회하기 어려움

      • 하지만 모델을 형상 관리할 필요가 없다는게 큰 장점으로 실무에서 자주 사용되지만, 지나치게 유연해서 가능하면 사용을 자제하고 종 테이블로 관리할 시 심사숙고하여 결정할 것

      • 종 테이블은 유연한 만큼 이력 엔터티를 통합하는데 자유도가 높아 무분별하게 통합할 위험이 있음

      • 따라서 성격이 유사하거나, 같은 영역에 있는 몇개의 이력 엔터티를 통합하는게 바람직하고, 조인해서 사용하기 보다는 필요할 때 참고할 용도로 사용하면 효과적임

  3. 선분이력

    1. 선분이력 개요

      • 선분이력은 과거 특정 시점의 데이터를 조회하는 요건이 많을 때 사용하는 방법으로 조회성능을 고려한 기법으로, 선분이력이 필요한 경우는 그다지 많지 않으므로 남용 주의

      • 특정 데이터가 변경된 시작일자와 변경 전의 종료일자가 이어지도록 인위적으로 데이터를 관리하는 것이 핵심이므로 변경된 릴레이션의 시작과 종료 시점을 연결하면 하나의 선분이 되는 것이 중요

      • 넓은 범위의 조회가 있고 성능 문제를 해결해야 한다면 선분이력 방법을 사용해야 하며, 선분이력의 종료일자에 대한 기본 값은 '9999년 12월 31일’이 적당하며, Default 제약을 설정해 사용하는것이 좋음

      • 선분이력을 사용할 때 시작일자와 종료일자가 겹치지 않도록 주의

      • 선분이력의 종료일자는 추출 속성으로 성능향상을 위해 존재하는 속성이지 본질적인 속성이 아니며, 데이터 성격상 없어도 되는 속성이므로 도입시 성능상 커다란 이득이 있는지도 따져봐야함

      • 성능향상을 위해 사용된 만큼 주 식별자에 포함하여 관리하는것이 좋으며, 변경순번과 같이 인조식별자를 사용하는 것은 바람직하지 않음

  4. 이력 엔터티 설계 절차

    • 이력 엔터티를 설계하는 시작점은 이력 데이터를 관리하는 요건이 있느냐 인데, 이력 데이터를 쌓아두지 않더라도 이력 엔터티를 설계해 두는 것은 의미가 있음

    • 이력 엔터티는 총 5단계로 아래와 같이 분류 될 수 있음

      1. 변경 데이터를 관리해야 하는 요건이 있는지

      2. 이력 데이터를 어떤 방법으로 관리해야 가장 효율적인지 분석

      3. 선분이력 방법을 채택할지 결정

      4. 이력 엔터티의 주 식별자(PK) 확정

      5. 다른 엔터티와의 관계를 감안하여 최종적으로 확인

  5. 서브타입 이력 모델

    1. 슈퍼·서브타입 엔터티별로 이력 데이터를 관리하는 방법

      • 슈퍼타입 이력 엔터티와 서브타입 이력 엔터티간 참조 무결성 제약이 없기 떄문에 데이터 무결성을 장담할 수 없음

      • 특정 시점의 데이터를 조회하기 복잡

    2. 슈퍼·서브타입 엔터티와 동일한 구조의 엔터티로 이력 데이터를 관리하는 방법

      • 직관적이고 엔터티 간에 참조 무결성 제약이 존재해 데이터 정합성이 맞으며, 조회하기 쉬움

      • 성능에 문제가 있을시 선분이력 방법을 적용할 수 있음

    3. 속성 단위로 이력 데이터를 관리하는 방법

      • 특정 속성을 대상으로 이력을 관리할 때 사용

  6. 정정 데이터

    1. 정정 데이터란

      • 정정 데이터는 데이터가 잘못돼 수정한 데이터로써 데이터를 변경한 이력 데이터와는 다름

    2. 정정 데이터 관리 방법

      • 정정 데이터를 관리하는 방법은 정정이력을 관리하지 않고 데이터 업데이트하는 방법

      • 하나의 엔터티에서 변경이력 데이터를 관리하면서, 정정 데이터도 함께 관리하는 방법

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

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

정민호정민호

1. 엔터티 이야기

2. 정규화 이야기

3. 데이터 통합과 서브타입 이야기

4. 속성 이야기

5. 관계 이야기

6. 이력 데이터 이야기

7. 비정규화 이야기

요약

  1. 비정규화(Denormalization)

    1. 비정규화 개요

      • 비정규화는 정규화의 연장선에 있는 과정으로써 조회 성능만을 향상시키기 위해 데이터를 중복하거나 그룹핑 하며, 단순히 사용 편이를 위해 사용되어서는 안됨

      • 비정규화라는 용어보다 일반적으로 반정규화, 역정규화 등을 많이 사용되며, 정규화를 역으로 적용하는 것 이상의 의미가 내포됨

      • 중복 데이터는 원천데이터와 정합성을 맞춰야 함

      • 조회 성능은 향상되지만 데이터 정합성 문제, 데이터 품질 문제, 모델의 가독성 문제, 모델의 확장성 문제, DB 공간 문제, 쓰기 성능 문제 등 많은 단점이 존재하므로 비정규형은 매우 신중하게 선택적으로 사용해야 함

    2. 비정규화 방법

      • 정규화를 거꾸로 적용한 역정규화(Reverse-Normalization) 방법

      • 정규형 모델에 중복 속성을 채택하는 방법

    3. 비정규화 원칙

      • 최우선적으로 고려할 요소는 데이터 무결성

      • 정규형은 필수며, 성능 문제가 있을 떄만 비정규형을 채택

      • 중복 속성은 가능한 사용하지 않으며, 추출 속성은 일부 사용할 수 있음

    4. 비정규형의 단점 7가지

      1. 정합성 유지

        • 중복 속성은 항상 원본 속성의 값으로 맞춰야하지만, 중복된 데이터가 늘어 날 수록 데이터의 정합성이 저하되어 결과적으로 데이터의 품질이 떨어지게 됨

        • 중복된 데이터가 적더라도 정도의 차이가 있을 뿐 데이터 품질은 자연히 저하될 수 밖에 없음

        • 실무에서는 어떤 이유에서든 데이터 정합성이 꺠져 있는 경우가 빈번

      2. 쓰기 성능 저하

        • 비정규화의 목적은 오직 읽기(Read: Select) 성능을 향상시키는 것으로, 쓰기 성능을 포기할 만큼 읽기 성능 문제가 큰지 잘 따져봐야 함

        • 비정규화를 사용하더라도 트리거를 사용해서 부작용 없이 사용할 수 있을 정도가 기준이 되어야 함

      3. 불명확한 데이터 성격

        • 엔터티 내 많은 중복 속성 떄문에 엔터티의 성격이 흐려질 수 있고, 엔터티의 성격이 흐려지면 제 3자가 보았을 떄 이해하기 어려움

        • 이해하기 어려운 모델은 사용할수록 점점 더 복잡해져 결국 조잡한 모델이 되기 쉬움

      4. 모델 확장성 저하

        • 군더더기 없은 정규형에 비해 비정규형은 군더더기가 많으며 이를 수정하는 것은 어렵기 떄문에 확장성이 떨어짐

        • 비정규형 위주로 이루어진 모델은 어디를 수정해야 하는지 정확히 모르기 때문에 유지·보수가 어려워지며 제대로 하긴 더욱 어려워짐

      5. 개발 어려움

        • 비정규형을 채택하면 개발이 쉽다는 얘기는 원천 데이터와 정합성을 체크하지 않기 떄문이며, 이는 있어서는 안 되는 일임

        • 중복 속성을 남발하면 개발할 당시에는 조인이 없으므로 편할지 몰라도 막상 운영하다 보면 중복된 데이터를 완벽하게 일치시키기가 쉽지 않아 문제가 됨

      6. DB 저장공간 차지

        • 인스턴스가 적은 엔터티는 큰 문제가 안 될 수 있지만, 인스턴스가 수억 건이 되는 엔터티는 20bytes 문자만 중복돼도 수십 Gbytes의 공간이 필요함

        • DB 공간을 많이 차지하면 일반적으로 성능에 나쁜 영향을 미침

      7. 일부 조회 성능 저하

        • 데이터 중복 시 하나의 블록에 존재할 인스턴스가 두 개의 블록에 존재할 수 있음

        • 조회할 떄 여러 블록을 사용하면 속도가 늦어짐

        • 비정규화를 하는 것이 반드시 조회 성능을 좋게하는지는 요건에 따라 달라질 수 있어 심사숙고해야함

        • 실제 데이터로 벤치마크하지 않는 한 좋고 나쁨을 단언 할 수 없음

    5. 비정규화 과정 5단계

      1. 함수 종속을 적용해 정규화

      2. 성능 문제 발생 요건 도출

      3. 비정규화 외 다른 방안 검토

        • 뷰를 사용해서 조인 문제를 해결할 수 있는지 검토

        • 파티션으로 데이터를 나눠서 해결할 수 있는지 검토

        • 클러스터링이나 IOT(Index Oriented Table) 같은 특수 형태의 테이블을 사용해서 해결할 수 있는지 검토

        • 인덱스를 조정하거나 힌트(Hint) 등으로 해결할 수 있는지 검토

        • 그밖에 DBMS의 최신 기술을 적용해 해결할 수 있느니 검토

      4. 비정규화 수행

      5. 정합성 구현 방안 검토

  2. 비정규화 방법

    • 역정규화

    • 엔터티 합체

    • 엔터티 분해 - 수직

    • 엔터티 분해 - 수평

    • 요약 엔터티

    • 추출 속성

    • 반복 속성

    • 중복 데이터

    • 시스템 속성 삭제

    • 슈퍼타입 엔터티의 속성과 서브타입 엔터티 간 속성 이동

  3. 비정규화 방법 - 역정규화

    1. 롤다운 역정규화(Roll-Down Denormalization)

      • 하위(자식) 엔터티를 기준으로 역정규화하는 것

    2. 롤업 역정규화(Roll-Up Denormalization)

      • 상위(부모) 엔터티를 기준으로 역정규화 하는 것

  4. 비정규화 방법 - 엔터티 합체

    • 일대일(1:1) 관계의 엔터티가 주를 이루며, 간혹 일대다(1:M) 관계의 엔터티도 대상이 됨

    • 엔터티를 합칠 때 성격이 같은지, 추후에 관계비가 바뀔 수 있는지 검토

    • 일대다(1:M) 관계의 엔터티는 보통 하위(자식) 엔터티를 기준으로 상위(부모) 엔터티를 합치는데, 상위(부모) 에넡티의 속성 개수가 많으면 엔터티를 합체하는 것이 적당하지 않음

  5. 비정규화 방법 - 엔터티 분해

    1. 엔터티 분해 개요

      • 중복 데이터가 발생하지 않는 비정규화 방법

      • 로우 체이닝이나 로우 마이그레이션이 생기지 않는 방향으로 엔터티 설계

        • 로우 체이닝(Row Chaining) - 전체 속성 사이즈가 블록 사이즈를 넘으면 두 개의 블록에 저장될 때

        • 로우 마이그레이션(Row Migration) - 한 블록에 저장되더라도 속성이 업데이트될 때 데이터가 커지면 다른 블록에 저장할 때

    2. 수직 분해

      • 엔터티의 속성을 별도의 엔터티로 분해하는 것

      • 일대일(1:1) 관계로 분해하는 이유는 한 블록에 중요한 인스턴스를 많이 저장할 수 있기 떄문

    3. 수직분해 기준

      • 사용빈도

      • 특별한 데이터 타입

      • 널(Null)이 발생할 수 있는 속성

      • 속성의 중요도

      • 업무에서 사용되는 속성별(락(Lock) 발생 최소화)

      • 전체 속성 사이즈가 기본 블록 사이즈를 초과 할 때(로우 체이닝, 로우 마이그레이션 발생 방지)

    4. 수평 분해

      • 엔터티의 특정 인스턴스를 별도의 엔터티로 분해 하는것으로 파티셔닝(Partitioning)으로 구현됨

    5. 수평 분해 방법

      • 파티셔닝

        • 파티션된 조각은 하나의 논리적인 엔터티로 존재

      • 특정 기준에 따라 엔터티 인스턴스를 분리해서 다른 엔터티로 이동시키는 것

        • 엔터티를 아예 물리적으로 분리해서 관리

  6. 비정규화 방법 - 요약 엔터티

    1. 요약 엔터티 개요

      • 요약 엔터티는 원천 엔터티를 대상으로 합계나 집계 등 미리 계산한 데이터를 저장한 엔터티

      • 미리 계산한 데이터도 데이터를 중복해서 관리하는 방법이어서 데이터 정합성을 주의 해야함

      • 하지만 중복 데이터라고 보기 어려운 요약 엔터티도 있음

    2. 요약 엔터티의 정합성을 맞추는 방법

      • 실시간으로 요약 엔터티의 데이터를 수정하는 방법

      • 배치로 요약 엔터티의 데이터를 맞추는 방법

  7. 비정규화 방법 - 추출 속성

    1. 추출 속성 개요

      • 추출 속성을 사용하는 목적은 미리 추출(계산)해서 보관한 값을 필요한 시점에 사용하기 위한것으로 추출 속성과 중복 속성은 구별됨

      • 추출 속성은 주로 하위(자식) 에넡티에서 많은 데이터(인스턴스)를 읽어서 연산 한 후 값을 상위(부모) 엔터티의 속성으로 가져다 놓은 속성을 말함

      • 추출 속성은 성능에 많은 영향을 미치므로 채택 여부를 숙고해야함

    2. 추출 속성의 유형

      • 총 횟수

      • 처음 값

      • 최종 값

      • 더한 값

      • 현재 값

      • 이전 값

      • 다음 값

      • 추출 관계

      • 여부 값

        • 여부 속성은 생각보다 정합성을 맞추기 어려워서 가능하면 지양

      • 주 식별자 값의 체계와 동일한 의미의 값(체계가 있는 값)

  8. 이전 값을 관리하는 방법

    • 이력 엔터티에 현재 유효한 데이터를 중복으로 관리하는 방법

    • 원천 엔터티에 이전 값을 관리하는 방법

  9. 비정규화 방법 - 추출 엔터티

    • 추출 속성을 사용하는 방법과 유사함

    • 추출 엔터티는 추출 속성을 묶어서 사용하는 개념으로 현재 유효한 인스턴스와 속성만 추출해서 관리하는 엔터티

  10. 비정규화 방법 - 반복 속성

    1. 반복 속성 개요

      • 조회 화면이 [1-Row]이냐 [N-Row] 냐에 따라서 정규형 비정규형을 사용

      • 조회 화면이 다양한 형태로 여러 개 존재할 떄는 중요도와 빈도에 따라 전략적으로 선택

      • 화면과 관련된 성능 이슈는 화면 구성이나 조회 방법 등을 바꿀 수 있는지 먼저 검토

      • 반복되는 속성이 한정돼 있을 때 사용할 수 있으며, 여러개의 속성이 묶여서 반복될 경우 정규화를 하는것이 좋음

    2. 반복 속성 유형

      • 롤업 역정규화

      • 단순 비정규화

  11. 비정규화 방법 - 중복 데이터

    1. 중복 데이터 사용 방법

      1. 데이터 중복 관리

        • 조회 효율을 위해 현재 시점의 데이터와 이력 데이터가 동시에 존재

      2. 엔터티 및 데이터 중복 관리

        • 업무 처리를 위한 대상을 뽑기 위해

        • 복구 대비

        • 다른 서버의 DB에서 원격 조인을 피하기 위해

        • 조회 성능을 향상시키기 위해

  12. 비정규화 방법 - 시스템 속성 삭제

  13. 비정규화 방법 - 슈퍼타입 엔터티의 속성과 서브타입 엔터티 간 속성 이동