데이터 Story/모델링 매뉴얼 썸네일형 리스트형 속성의 묶음이 반복된다면 정규화가 원칙 엔터티에 반복되는 속성은 정규화를 하는 것이 원칙이며, 특히 속성이 묶음으로 반복된다면 정규화를 한다. 단독 속성이 반복되면, 추가되지 않고 고정적인지를 고려해서 정규화를 하지 않을 수 있지만 묶음 속성이 반복되면 정규화를 하는 것이 원칙이다. [그림 1] 모델은 주문상품에 대한 속성(상품번호/상품가격/상품수량)이 반복된 비정규형 모델이다. [그림 1] 주문상품에 대한 속성인 상품번호, 상품가격, 상품수량 속성이 묶여서 세 번 반복됐기 때문에 비정규형 모델이다. 이 모델은 세 개의 속성이 묶여서 반복됐기 때문에 정규화를 해야 한다. [그림 2] 모델이 [그림 1] 모델에 대한 정규형 모델이다. [그림 주문정규화] 정규화를 한 주문상품 엔터티는 주문과는 다른 의미를 나타내는 별도의 엔터티다. 즉 엔터티의 .. 더보기 코드 유형과 코드 인스턴스를 한 개의 엔터티로 설계 공통 코드 데이터를 통합 관리하는 엔터티를 설계할 때, 코드 유형과 코드 인스턴스를 같이 관리할 수 있도록 한 개의 엔터티로 설계한다. [그림 통합코드] 통합코드 엔터티는 코드 유형과 코드를 통합 관리할 수 있도록 설계한 엔터티다. [그림 통합코드] 유형통합코드 속성은 해당 코드에 대한 코드 유형이 무엇인지를 관리하는 속성이다. 통합코드 엔터티에 대한 릴레이션은 아래와 같다. [통합코드] 더보기 통합 코드 속성 명명법 개인적으로는 속성 명이 길어나는 건 반대입니다.하지만 통합 코드를 구분하는 게 의미가 있어 매뉴얼에 포함시켰습니다. -- 통합코드 엔터티에서 관리되는 코드를 사용하는 속성 명은 ‘~통합코드’로 정하며, 구분/종류/유형과 같은 구분자를 붙여서 정한다. 따라서 일반 코드 속성 명은 ‘~구분통합코드’, ‘~종류통합코드’, ‘~유형통합코드’와 같이 사용한다. 코드 속성은 비코드 속성과 성격이 다르기 때문에 속성 명을 구분해서 정하는 것이 좋다 속성 명을 구분하면 사용법이 자연스럽게 구분되기도 한다. 주 식별자 속성과 같은 비코드 속성은 하나의 인스턴스가 하나의 실체(개체)를 의미하므로 구분/유형/종류 등을 사용하는 것이 적절하지 않지만, 일반 코드는 하나의 개체를 의미하는 것이 아니라 범주를 의미하므로 구분/종.. 더보기 외부에서 받은 코드 값만 관리할 때 외부에서 받은 코드를 관리할 때, 코드 값에 대한 명(名)을 알 필요가 없다면 통합코드 엔터티에서 관리하지 않고 속성에서 값만 관리하며 속성 명은 ‘~코드값’으로 정한다. 외부에서 데이터를 받을 때, ‘01’ 등의 코드가 포함됐지만 해당 값이 무엇을 의미하는지, 즉 코드명을 알 필요가 없을 때가 있다. 이때는 해당 코드를 통합코드 엔터티에 등록하지 않는다. 코드 형태라고 모두 통합코드 엔터티에서 관리하는 것은 아니다. [그림1] 교육과정 엔터티는 외부에서 받은 교육 과정 정보를 관리하는 엔터티다. [그림1] 교육 기관을 의미하는 교육기관코드에 대해서 ‘01’ 등의 값을 받지만 해당 값이 무엇을 의미하는지, 즉 ‘A기관’인지 ‘B기관’인지 알 수가 없다. 이는 해당 코드명이 사용되지 않는다는 것이다. 이렇.. 더보기 외부 코드를 내부 코드에 통합하는 방법 외부 코드를 내부 코드와 통합 관리할 때, 외부에서 받은 코드 값을 그대로 사용하지 않아도 된다면 외부 코드 값을 내부 코드 표준에 맞게 관리한다. 외부 기관과 데이터를 주고받을 때, 외부 기관에서 정한 코드 값이 데이터에 포함되는 경우가 많다. 이때 외부 코드 값이 많이 사용되지 않고 간혹 사용된다면 외부 코드를 내부 코드 표준에 맞게 통합 관리할 수 있다. [그림1] 모델은 코드를 관리하는 일반적인 모델에, 외부 코드를 관리할 수 있도록 설계한 모델이다. [그림1] 외부에서 받은 코드 값은 ‘KOR’이지만 내부에서는 ‘01’ 등 내부 표준을 정해 관리한다면, 통합코드 엔터티의 외부코드값 속성에는 ‘KOR’ 값으로 관리하고, 통합코드번호 속성에는 내부 표준에 맞춰서 ‘01’로 관리한다. 외부에서 받은 .. 더보기 내부 코드 통합 엔터티 내부에서 생성하는 일반 코드는 코드별 개별 코드 엔터티로 설계하지 않고 하나의 통합 코드 엔터티를 설계해서 통합 관리한다. 예를 들어 관리하려는 데이터가 개인, 법인 등의 고객 유형을 나타내면 이는 코드 성격의 데이터다. 이 코드 인스턴스를 관리하기 위해 엔터티를 설계할 때, 고객유형만을 관리하는 엔터티를 설계하는 것이 아니라 [그림1] 모델처럼 다른 유형의 코드까지 관리하는 엔터티를 설계해서 모든 내부 코드를 통합 관리하도록 한다. [그림1] 코드 성격의 데이터는 해당하는 인스턴스를 별도의 시스템에서 관리하는 게 일반적이다. 코드를 통합 관리하는 시스템에서 코드 인스턴스를 등록하고, 등록된 코드 인스턴스를 업무 시스템에서 사용하는데, 업무 시스템에서 사용할 엔터티가 [그림1] 모델과 같다. 코드유형 엔.. 더보기 개별 엔터티로 설계해야 하는 코드 엔터티의 하나의 인스턴스가 개별 개체를 의미하지 않고 개별 개체를 묶은 개념이더라도 명(名) 외의 다른 속성도 관리해야 한다면, 코드 속성으로 설계하지 않고 개별 엔터티로 설계한다. 즉 개별 개체를 묶은 개념이라도 고유 속성이 필요하다면 엔터티로 설계한다. 만약 종합카드/체크카드/신용카드/신탁통장 등 거래 매체의 유형을 관리한다면, 데이터가 개별 개체가 아니라 묶은 개념인 유형을 의미하므로 코드 속성으로 설계해야 한다. 하지만 재발급기간, 발급가능고객종류 등과 같이 매체 유형에 따라 관리해야 할 속성이 존재한다면 [그림 거래매체유형] 거래매체유형 엔터티처럼 별도의 엔터티로 설계한다. [그림 거래매체유형] 해당 매체 유형의 재발급 기간을 관리해야 한다면 속성이 필요한 것이어서 위와 같이 엔터티로 설계할 수.. 더보기 코드로 설계 or 엔터티로 설계 엔터티의 인스턴스가 개별 개체를 의미하면 코드 속성으로 설계하지 않고 엔터티로 설계한다. 개별 개체를 의미한다는 것은 묶이기 전, 변형되기 전의 순수 데이터를 의미한다. 예를 들어 국가 집합에 속한 인스턴스가 대한민국, 호주, 일본 등이라면 각각은 개별 개체를 의미하기 때문에 엔터티로 설계한다. 만약 외국인 고객을 관리하는 엔터티에서 해당 고객의 국적을 관리한다면 [그림1] 모델처럼 국가 엔터티를 별도로 설계하여 외국인고객 엔터티와 관계선을 표현한다. [그림1] 위와 같이 개별 개체를 의미하는 국가를 엔터티로 설계해서 관리하지 않고, [그림2] 모델과 유사하게 국가 엔터티 없이 통합 코드 엔터티나 별도의 시스템에서 관리하는 국가코드 속성으로 설계하는 것은 바람직하지 않다. [그림2] 국가 데이터는 데이터.. 더보기 실체 엔터티의 변경이력 엔터티 설계 원천 엔터티가 실체 엔터티일 때는 변경이력 데이터를 별도의 엔터티에서 관리하도록 설계한다. [그림1] 고객실체 엔터티는 실체인 고객 데이터를 관리하는 실체 엔터티다. [그림1] 만약 고객명 속성이나 전화번호 속성의 변경이력 데이터를 관리할 때, 고객은 실체이기 때문에 아래 모델처럼 별도의 엔터티에서 변경이력 데이터를 관리하도록 설계한다. [그림2] 고객실체 엔터티의 속성 중에서 하나라도 변경되면, 그 시점의 고객실체 엔터티 인스턴스는 고객실체이력 엔터티로 이동한다. 고객실체이력 엔터티는 변경된 과거 데이터이므로 주로 사용되지 않으며, 필요 시에만 참고 용도로 사용하기 위해 보관하는 역할을 한다. 실체 엔터티는 실체에 대한 개별 인스턴스를 관리하는 엔터티다. 실체 엔터티에서 실체의 변경된 데이터까지 관리한.. 더보기 관계 엔터티 설계 엔터티 간의 관계에서 생기는 관계 속성은 한 엔터티에 여러 개가 있을 수 있으며, 그 관계 속성 중에는 유사한 성격의 속성이 있을 수 있다. 이때 유사한 관계 속성이 두 개 이상이며, 추가될 가능성이 조금이라고 있다면 별도의 관계 엔터티로 설계한다. [그림1] 보험계약 엔터티에는 세 개의 관계 속성이 존재한다. [그림1] 보험을 계약한 고객과 보험의 피보험자 고객, 보험의 연대보증 고객이 누구인지를 관리하는 속성이 관계 속성이다. 따라서 계약고객번호/피보험고객번호/연대보증고객번호 속성은 관계 속성이며, 관계선이 세 개이므로 관계 속성과 마찬가지로 관계 명에도 역할(Role) 이름을 사용한 모델이다. 이미 세 개의 관계 속성이 존재하지만 연대 보증인의 경우에는 여러 명을 관리할 수도 있어서 관계 속성이 더.. 더보기 이전 1 2 3 다음
