본문 바로가기

데이터 Story

데이터에 대한 개인적인 비전 오늘은 비전에 대한 글을 짧게 써보려고 합니다.저의 비전이니 데이터인들의 비전일 수 있다고 생각합니다. 차세대 등의 개발 프로젝트에서 소프트웨어를 분리 발주하듯이, 데이터 분야도 분리 발주해야 한다는 것이 제 생각입니다.발주사 입장에서 모델링, 표준화, 이행, 튜닝 등의 DA 영역은 별도로 계약하는 것입니다. 데이터 분리 발주를 주장하는 이유는 바로 아시겠죠?시스템의 토대가 되는 데이터 구조를 제대로 구축하기 위함이고, 사업의 근간이 되는 데이터를 제대로 관리하기 위함입니다. 현재는 수행사가 발주사와 전체 계약을 하고, 필요 시 데이터 분야에 대해서는 수행사가 데이터 전문 업체와 계약을 합니다. 이런 방식으로라도 데이터 전문 업체를 참여시키면 좋을 텐데 현실은 그렇지 않은 경우가 많습니다.수행사에는 코디.. 더보기
데이터 아키텍트 프레임웍 아래 그림은 데이터 아키텍트가 해야 할 일에 대한 프레임웍입니다. 프레임웍(Framework)이란 전체가 어떻게 구성됐는지를 보여주는 논리적인 틀입니다. 데이터 아키텍트가 해야 할 일은 크게 표준, 구조, 품질 영역으로 구분할 수 있습니다. 각 영역은 업무의 종류에 따라 원칙, 설계, 관리, 시스템으로 구분할 수 있습니다. 표준 영역은 데이터에 대한 표준화를 의미합니다. 표준 지침서가 있어야 하고, 표준 단어와 표준 용어와 같은 표준 컨텐츠가 있어야 합니다. 그리고 이런 컨텐츠를 관리하는 메타 시스템이 필요합니다. 구조 영역은 데이터 모델을 의미합니다. 마찬가지로 모델링 지침서가 있고, 데이터 주제 영역, 개념 모델, 논리 모델 등이 있습니다. 모델링은 표준 데이터를 이용해서 수행합니다. 모델은 저장소에.. 더보기
두 가지 종류의 표준 도메인 표준 단어와 표준 도메인, 표준 용어는 서로 엮어 있어 각자 별개의 것으로 설명하기 힘듭니다. 하지만 각자의 내용이 길고, 구분이 필요하기 때문에 별도의 장에서 설명하고 있습니다. 서로 밀접하게 연관되다 보니 중복 설명이 될 수 있습니다. 도메인의 의미는 다소 포괄적입니다. 데이터 모델링에서 도메인(domain)의 일반적인 의미는 ‘데이터 타입과 길이, 포멧 등이 같은 값의 집합’입니다. 이는 표준 도메인에도 유사하게 적용되는 의미입니다. 결국 의미가 같고, 데이터 타입과 자릿수가 같은 것을 표준 도메인이라고 합니다. 실제로 표준 도메인은 속성 명의 끝에 붙는 것으로 사용되고 있습니다. 분류어라는 용어로도 사용됩니다. 표준 도메인의 역할 표준 도메인의 사용 목적은 크게 세가지 정도가 있습니다. 하나는 데.. 더보기
복합어에 대한 정리 이번 글은 복합어에 대한 내용입니다. 이미 복합어에 대한 글을 게시한 적이 있지만, 이번 기회에 더 자세하게 설명하겠습니다. 먼저 표준 단어에 대한 이전 글을 읽어보시길 권합니다. http://dataprofessional.tistory.com/172 위 글에서 설명했지만 복합어는 표준 단어의 일종입니다. 즉, 표준 단어는 단일어와 복합어로 나눌 수 있습니다. 복합어가 필요한 이유를 간단히 설명한다면, 애매한 사용을 줄이고 컬럼 명을 줄이기 위해서라고 하겠습니다. 표준화지침서에 복합어의 사용을 지양하라는 지침이 많은데, 제 생각은 반대입니다. 애매한 사용을 줄이고 컬럼 명을 줄이기 위해서는 복합어가 많아야 한다고 생각하기 때문입니다. 복합어를 사용해야 하는 경우 그럼, 어떤 경우에 복합어를 만들면 될까요.. 더보기
표준 단어에 대해서 제가 최근에 표준화에 대한 글을 간혹 올리는데요. 잠깐 언급한 적도 있지만, 그동안 표준화에 대한 내용은 자세히 다루지 않았습니다. 여러 이유가 있었지만, 어쨌든 최근 생각은 제 경험을 공유하는 게 좋겠다고 생각해서 하나씩 공유하고 있습니다. 그동안 속성 명을 정한 게 10만 개는 훌쩍 넘는 거 같습니다. 모델링할 때 아직까지는 속성 명 정하는 게 재미있습니다. 재미 없으면 힘들 텐데, 재미 있으니 누가 뭐라 하든 열심히 정하고 있습니다. 다만 개수에 압도당할 뿐이죠. 모델링 자체로만 봤을 때 재미 없는 게 한 가지 있습니다. 양이 압도적으로 많고, 중요한 부분이지만 정성을 들이기 쉽지 않은 부분인데요. 눈치 채셨을 거 같은데, 속성 설명 적는 것입니다. 가끔 50자 이상 적으라는 식의 가이드가 있으면 .. 더보기
[worst practice 4] 요건은 아래와 같습니다. -부서명, 전화번호, 부서장 등의 부서에 대한 기본 정보를 관리한다.-전화번호, 부서장 등의 데이터는 변경될 수 있어 이력 관리한다. 위의 요건을 설계한 모델이 아래와 같습니다.잘못된 부분을 생각해 보세요. [그림 1] -- 이력 데이터를 어떻게 설계할지에 대한 문제입니다. 이력 데이터를 원천 엔터티에 통합해서 관리하면 좋을 때가 있고 그렇지 않을 때가 있습니다. [그림 1]은 그렇지 않을 때에 해당돼서 아래와 같이 관리하는 게 바람직합니다. [그림 2] 실체를 관리하는 엔터티나 기본 정보를 관리하는 엔터티, 기준 정보를 관리하는 엔터티는 이력 데이터를 원천 데이터와 같이 관리하지 않는 것이 좋습니다. 실체 데이터는 한 번 생기면 그대로 존재하는 것이어서, 특성(속성)이 바뀐다고.. 더보기
worst practice 이번 요건은 다소 까다롭습니다. -한 계좌에는 관리 사원, 실적 사원 등 여러 역할 사원이 존재한다.-한 사원은 여러 계좌의 관리 사원이 될 수 있고, 여러 계좌의 실적 사원이 될 수 있다.-동일 사원이 동일 계좌에 대해 여러 역할을 할 수는 없다.-계좌에 대한 역할 사원은 한 번 정해지면 바뀌지 않는다. 위 요건을 설계한 모델이 [그림 1]입니다.잘못된 부분을 생각해 보세요. [그림 1] 역할유형코드의 인스턴스는 관리사원, 실적사원입니다. -- 식별자밖에 없으니 식별자에 대한 문제죠. ㅎ 우선, 역할이 한 번 정해지면 바뀌지 않는다고 했습니다. 즉 한 번만 지정되는 것이니 역할지정일자 속성은 식별자가 아닙니다. 그리고 동일 사원이 동일 계좌에 대해 여러 역할을 할 수 없다고 했습니다. 이 요건 때문에 .. 더보기
속성 명 정하는 방법 엔터티 명은 상당히 중요합니다.제가 매우 강조하는 부분이에요.속성 명도 중요하긴 한데, 중요하게 취급하기에는 개수가 너무 많고 잘못됐을 때 치명적이지 않습니다. 그래도 잘못 정했을 때의 부작용이 없는 건 아닙니다.속성 명과 데이터가 전혀 다른 경우가 많습니다.변용해서 사용했거나 처음부터 잘못 사용한 경우죠. 제 책에서 속성 명에 대한 설명은 많지 않습니다.더욱이 방법을 소개하진 않았는데, 이 글에서 간단한 방법을 소개하겠습니다. 속성은 도메인 자체가 중요합니다.금액, 날짜, 내용, 명, 번호, 여부, 코드 등의 도메인이 속성의 성격을 바로 나타내죠.속성에서 관리하는 데이터의 성격을 구분하게 하는 게 도메인입니다.그래서 우선 도메인의 종류와 의미를 파악해야 합니다.도메인은 사이트마다 조금씩 다를 수 있습니.. 더보기
[worst practice 2] 요건이 아래와 같습니다. -고객이 발급 받아서 사용하는 보안카드를 관리한다.-폐기한 보안카드 데이터를 관리하는데, 일자별로 폐기된 보안카드를 조회할 수 있도록 관리한다. 이 요건을 아래와 같이 설계했습니다.잘못된 부분을 생각해 보세요. [그림 1] -- 고객보안카드페기 엔터티의 주 식별자가 잘못됐습니다.쉽게 찾으셨을 거 같아요. 하나의 보안카드가 여러 번 폐기될 때 [그림 1] 고객보안카드페기 엔터티와 같이 설계할 수 있습니다.발급된 보안카드는 한 번 폐기되면 끝이기 때문에 [그림 2]와 같이 설계해야 적절합니다. [그림 2] 일자별로 폐기된 보안카드를 조회한다는 이유 때문에 폐기일자 속성이 주 식별자에 포함된 사례로, 역시 슈퍼 식별자입니다.폐기일자+보안카드번호는 인덱스를 나타내죠. [그림 2] 정도도.. 더보기
모델러의 상처 자기 일에 애정을 가진 진지한 모델러일수록 상처받기 쉬운 법이다. 더보기

티스토리툴바