본문 바로가기

데이터 Story

모델링에 답이 어딨어? 얼마 전 어떤 분이 한 말이다.일부 개발자의 생각을 안타까워하면서 한 얘기다.악의는 전혀 없었다.눈치가 없었을 뿐이었다. 왜 유독 모델링에 답이 없다고 하는 것일까?“튜닝에 답이 어딨어?”라는 말은 들어보지 못했다. 최고로 튜닝할 수 있는 절대 시간은 알기 어렵다.최고수가 행한 결과가 기준이나 정답은 될 수 있겠지만, 특정한 정답은 없는 것이다.이전보다 좋은 결과가 나오고, 근거가 명확하면 튜닝은 끝난 것이고 사람들은 수긍한다. 다만 튜닝은 실행 시간이라는 정량적인 수치가 있다.정답은 아닐 수 있지만 숫자가 나오니 정답처럼 느끼는 것일지 모른다. 사실 “답이 어딨어?”라는 말은 어떤 분야에도 해당되는 말이다.개발도 마찬가지다.하지만 완벽하진 않지만 좋은 코딩은 있을 것이다. 답이 없으면 찾아야 한다.최선.. 더보기
코드 유형과 코드 인스턴스를 한 개의 엔터티로 설계 공통 코드 데이터를 통합 관리하는 엔터티를 설계할 때, 코드 유형과 코드 인스턴스를 같이 관리할 수 있도록 한 개의 엔터티로 설계한다. [그림 통합코드] 통합코드 엔터티는 코드 유형과 코드를 통합 관리할 수 있도록 설계한 엔터티다. [그림 통합코드] 유형통합코드 속성은 해당 코드에 대한 코드 유형이 무엇인지를 관리하는 속성이다. 통합코드 엔터티에 대한 릴레이션은 아래와 같다. [통합코드] 더보기
통합 코드 속성 명명법 개인적으로는 속성 명이 길어나는 건 반대입니다.하지만 통합 코드를 구분하는 게 의미가 있어 매뉴얼에 포함시켰습니다. -- 통합코드 엔터티에서 관리되는 코드를 사용하는 속성 명은 ‘~통합코드’로 정하며, 구분/종류/유형과 같은 구분자를 붙여서 정한다. 따라서 일반 코드 속성 명은 ‘~구분통합코드’, ‘~종류통합코드’, ‘~유형통합코드’와 같이 사용한다. 코드 속성은 비코드 속성과 성격이 다르기 때문에 속성 명을 구분해서 정하는 것이 좋다 속성 명을 구분하면 사용법이 자연스럽게 구분되기도 한다. 주 식별자 속성과 같은 비코드 속성은 하나의 인스턴스가 하나의 실체(개체)를 의미하므로 구분/유형/종류 등을 사용하는 것이 적절하지 않지만, 일반 코드는 하나의 개체를 의미하는 것이 아니라 범주를 의미하므로 구분/종.. 더보기
복합어에 대한 상념(想念) 복합어를 사용하는 이유는 크게 두 가지입니다. 첫째, 관용화된 용어를 사용하기 위해서입니다. 대상이 많지는 않지만 단어와 단어가 합쳐져서 뉘앙스가 달라지는 경우가 있습니다. 용어에 민감한 사람들은 이를 관리하고 싶어 합니다. 여기서, ‘용어’란 주로 영문 단어를 의미할 것입니다. 한글 단어 조합의 의미를 따지기도 하지만 주로 영문 조합의 의미를 따집니다. 예를 들어, 부가가치세는 ‘부가+가치+세’이지만 영문은 ‘VAT’로 쓰는 게 명확하다는 것이죠. 복합어를 사용하는 둘째 이유는 영문(컬럼 명)의 길이가 길어지는 것을 막기 위해서입니다. ‘부가가치세’를 복합어로 만들지 않으면 영문이 ‘VL_AD_TX’ 정도가 됩니다. 단어별로 두 자리의 약어를 사용해도 8자리가 되죠. 이를 복합어로 만들어 ‘VAT’로 .. 더보기
외부에서 받은 코드 값만 관리할 때 외부에서 받은 코드를 관리할 때, 코드 값에 대한 명(名)을 알 필요가 없다면 통합코드 엔터티에서 관리하지 않고 속성에서 값만 관리하며 속성 명은 ‘~코드값’으로 정한다. 외부에서 데이터를 받을 때, ‘01’ 등의 코드가 포함됐지만 해당 값이 무엇을 의미하는지, 즉 코드명을 알 필요가 없을 때가 있다. 이때는 해당 코드를 통합코드 엔터티에 등록하지 않는다. 코드 형태라고 모두 통합코드 엔터티에서 관리하는 것은 아니다. [그림1] 교육과정 엔터티는 외부에서 받은 교육 과정 정보를 관리하는 엔터티다. [그림1] 교육 기관을 의미하는 교육기관코드에 대해서 ‘01’ 등의 값을 받지만 해당 값이 무엇을 의미하는지, 즉 ‘A기관’인지 ‘B기관’인지 알 수가 없다. 이는 해당 코드명이 사용되지 않는다는 것이다. 이렇.. 더보기
외부 코드를 내부 코드에 통합하는 방법 외부 코드를 내부 코드와 통합 관리할 때, 외부에서 받은 코드 값을 그대로 사용하지 않아도 된다면 외부 코드 값을 내부 코드 표준에 맞게 관리한다. 외부 기관과 데이터를 주고받을 때, 외부 기관에서 정한 코드 값이 데이터에 포함되는 경우가 많다. 이때 외부 코드 값이 많이 사용되지 않고 간혹 사용된다면 외부 코드를 내부 코드 표준에 맞게 통합 관리할 수 있다. [그림1] 모델은 코드를 관리하는 일반적인 모델에, 외부 코드를 관리할 수 있도록 설계한 모델이다. [그림1] 외부에서 받은 코드 값은 ‘KOR’이지만 내부에서는 ‘01’ 등 내부 표준을 정해 관리한다면, 통합코드 엔터티의 외부코드값 속성에는 ‘KOR’ 값으로 관리하고, 통합코드번호 속성에는 내부 표준에 맞춰서 ‘01’로 관리한다. 외부에서 받은 .. 더보기
내부 코드 통합 엔터티 내부에서 생성하는 일반 코드는 코드별 개별 코드 엔터티로 설계하지 않고 하나의 통합 코드 엔터티를 설계해서 통합 관리한다. 예를 들어 관리하려는 데이터가 개인, 법인 등의 고객 유형을 나타내면 이는 코드 성격의 데이터다. 이 코드 인스턴스를 관리하기 위해 엔터티를 설계할 때, 고객유형만을 관리하는 엔터티를 설계하는 것이 아니라 [그림1] 모델처럼 다른 유형의 코드까지 관리하는 엔터티를 설계해서 모든 내부 코드를 통합 관리하도록 한다. [그림1] 코드 성격의 데이터는 해당하는 인스턴스를 별도의 시스템에서 관리하는 게 일반적이다. 코드를 통합 관리하는 시스템에서 코드 인스턴스를 등록하고, 등록된 코드 인스턴스를 업무 시스템에서 사용하는데, 업무 시스템에서 사용할 엔터티가 [그림1] 모델과 같다. 코드유형 엔.. 더보기
테이블 명을 정하는 방법 엔터티 명을 정하는 것은 사실 매우 어렵습니다. 상황에 맞는 수 많은 방법을 정해 놓고 따라야 해서 쉽지 않습니다. 그래서 논란이 많은 부분이기도 합니다. 엔터티 명만 정말 잘 정해도 좋은 모델러라고 할 수 있습니다. 반면에 테이블 명을 정하는 방법은 간단합니다. 대개 두 가지 방법 중에서 하나를 택해서 사용합니다. 방법을 결정하는 것은 대개 DBA가 합니다. 테이블 명은 DB 오브젝트에 포함되는데 전체 오브젝트를 감안해야 하기 때문에 DBA가 큰 틀을 정하는 것이죠. 차세대 프로젝트에서도 대개 DBA 쪽에서 테이블 명을 정하는 규칙을 정합니다. 이 과정에서 DA나 모델러에게 조언을 구하기도 하지만, 그렇지 않은 경우도 많죠. 테이블 명을 정하는 방법은 크게 두 가지입니다. 하나는 영역별 번호를 사용하는.. 더보기
개별 엔터티로 설계해야 하는 코드 엔터티의 하나의 인스턴스가 개별 개체를 의미하지 않고 개별 개체를 묶은 개념이더라도 명(名) 외의 다른 속성도 관리해야 한다면, 코드 속성으로 설계하지 않고 개별 엔터티로 설계한다. 즉 개별 개체를 묶은 개념이라도 고유 속성이 필요하다면 엔터티로 설계한다. 만약 종합카드/체크카드/신용카드/신탁통장 등 거래 매체의 유형을 관리한다면, 데이터가 개별 개체가 아니라 묶은 개념인 유형을 의미하므로 코드 속성으로 설계해야 한다. 하지만 재발급기간, 발급가능고객종류 등과 같이 매체 유형에 따라 관리해야 할 속성이 존재한다면 [그림 거래매체유형] 거래매체유형 엔터티처럼 별도의 엔터티로 설계한다. [그림 거래매체유형] 해당 매체 유형의 재발급 기간을 관리해야 한다면 속성이 필요한 것이어서 위와 같이 엔터티로 설계할 수.. 더보기
코드로 설계 or 엔터티로 설계 엔터티의 인스턴스가 개별 개체를 의미하면 코드 속성으로 설계하지 않고 엔터티로 설계한다. 개별 개체를 의미한다는 것은 묶이기 전, 변형되기 전의 순수 데이터를 의미한다. 예를 들어 국가 집합에 속한 인스턴스가 대한민국, 호주, 일본 등이라면 각각은 개별 개체를 의미하기 때문에 엔터티로 설계한다. 만약 외국인 고객을 관리하는 엔터티에서 해당 고객의 국적을 관리한다면 [그림1] 모델처럼 국가 엔터티를 별도로 설계하여 외국인고객 엔터티와 관계선을 표현한다. [그림1] 위와 같이 개별 개체를 의미하는 국가를 엔터티로 설계해서 관리하지 않고, [그림2] 모델과 유사하게 국가 엔터티 없이 통합 코드 엔터티나 별도의 시스템에서 관리하는 국가코드 속성으로 설계하는 것은 바람직하지 않다. [그림2] 국가 데이터는 데이터.. 더보기

티스토리툴바