본문 바로가기

데이터 Story/데이터 상념(想念)

데이터에 대한 개인적인 비전 오늘은 비전에 대한 글을 짧게 써보려고 합니다.저의 비전이니 데이터인들의 비전일 수 있다고 생각합니다. 차세대 등의 개발 프로젝트에서 소프트웨어를 분리 발주하듯이, 데이터 분야도 분리 발주해야 한다는 것이 제 생각입니다.발주사 입장에서 모델링, 표준화, 이행, 튜닝 등의 DA 영역은 별도로 계약하는 것입니다. 데이터 분리 발주를 주장하는 이유는 바로 아시겠죠?시스템의 토대가 되는 데이터 구조를 제대로 구축하기 위함이고, 사업의 근간이 되는 데이터를 제대로 관리하기 위함입니다. 현재는 수행사가 발주사와 전체 계약을 하고, 필요 시 데이터 분야에 대해서는 수행사가 데이터 전문 업체와 계약을 합니다. 이런 방식으로라도 데이터 전문 업체를 참여시키면 좋을 텐데 현실은 그렇지 않은 경우가 많습니다.수행사에는 코디.. 더보기
데이터 아키텍트 프레임웍 아래 그림은 데이터 아키텍트가 해야 할 일에 대한 프레임웍입니다. 프레임웍(Framework)이란 전체가 어떻게 구성됐는지를 보여주는 논리적인 틀입니다. 데이터 아키텍트가 해야 할 일은 크게 표준, 구조, 품질 영역으로 구분할 수 있습니다. 각 영역은 업무의 종류에 따라 원칙, 설계, 관리, 시스템으로 구분할 수 있습니다. 표준 영역은 데이터에 대한 표준화를 의미합니다. 표준 지침서가 있어야 하고, 표준 단어와 표준 용어와 같은 표준 컨텐츠가 있어야 합니다. 그리고 이런 컨텐츠를 관리하는 메타 시스템이 필요합니다. 구조 영역은 데이터 모델을 의미합니다. 마찬가지로 모델링 지침서가 있고, 데이터 주제 영역, 개념 모델, 논리 모델 등이 있습니다. 모델링은 표준 데이터를 이용해서 수행합니다. 모델은 저장소에.. 더보기
[worst practice 4] 요건은 아래와 같습니다. -부서명, 전화번호, 부서장 등의 부서에 대한 기본 정보를 관리한다.-전화번호, 부서장 등의 데이터는 변경될 수 있어 이력 관리한다. 위의 요건을 설계한 모델이 아래와 같습니다.잘못된 부분을 생각해 보세요. [그림 1] -- 이력 데이터를 어떻게 설계할지에 대한 문제입니다. 이력 데이터를 원천 엔터티에 통합해서 관리하면 좋을 때가 있고 그렇지 않을 때가 있습니다. [그림 1]은 그렇지 않을 때에 해당돼서 아래와 같이 관리하는 게 바람직합니다. [그림 2] 실체를 관리하는 엔터티나 기본 정보를 관리하는 엔터티, 기준 정보를 관리하는 엔터티는 이력 데이터를 원천 데이터와 같이 관리하지 않는 것이 좋습니다. 실체 데이터는 한 번 생기면 그대로 존재하는 것이어서, 특성(속성)이 바뀐다고.. 더보기
worst practice 이번 요건은 다소 까다롭습니다. -한 계좌에는 관리 사원, 실적 사원 등 여러 역할 사원이 존재한다.-한 사원은 여러 계좌의 관리 사원이 될 수 있고, 여러 계좌의 실적 사원이 될 수 있다.-동일 사원이 동일 계좌에 대해 여러 역할을 할 수는 없다.-계좌에 대한 역할 사원은 한 번 정해지면 바뀌지 않는다. 위 요건을 설계한 모델이 [그림 1]입니다.잘못된 부분을 생각해 보세요. [그림 1] 역할유형코드의 인스턴스는 관리사원, 실적사원입니다. -- 식별자밖에 없으니 식별자에 대한 문제죠. ㅎ 우선, 역할이 한 번 정해지면 바뀌지 않는다고 했습니다. 즉 한 번만 지정되는 것이니 역할지정일자 속성은 식별자가 아닙니다. 그리고 동일 사원이 동일 계좌에 대해 여러 역할을 할 수 없다고 했습니다. 이 요건 때문에 .. 더보기
[worst practice 2] 요건이 아래와 같습니다. -고객이 발급 받아서 사용하는 보안카드를 관리한다.-폐기한 보안카드 데이터를 관리하는데, 일자별로 폐기된 보안카드를 조회할 수 있도록 관리한다. 이 요건을 아래와 같이 설계했습니다.잘못된 부분을 생각해 보세요. [그림 1] -- 고객보안카드페기 엔터티의 주 식별자가 잘못됐습니다.쉽게 찾으셨을 거 같아요. 하나의 보안카드가 여러 번 폐기될 때 [그림 1] 고객보안카드페기 엔터티와 같이 설계할 수 있습니다.발급된 보안카드는 한 번 폐기되면 끝이기 때문에 [그림 2]와 같이 설계해야 적절합니다. [그림 2] 일자별로 폐기된 보안카드를 조회한다는 이유 때문에 폐기일자 속성이 주 식별자에 포함된 사례로, 역시 슈퍼 식별자입니다.폐기일자+보안카드번호는 인덱스를 나타내죠. [그림 2] 정도도.. 더보기
모델러의 상처 자기 일에 애정을 가진 진지한 모델러일수록 상처받기 쉬운 법이다. 더보기
[worst practice 1] 잘못 설계된 모델 잘못 설계한 사례 모델을 간혹 올릴 생각입니다.궁금하신 점이나 다른 아이디어 있으면 댓글로 남겨주세요. -- 요건은 아래와 같습니다. -회원은 주민등록번호 별로 한 번만 가입이 가능하다.-회원은 고유한 회원아이디가 있으며, 한 회원이 여러 개의 회원아이디를 가질 수 있다. [그림 1]은 위의 요건을 설계한 모델입니다. [그림 1] 어디가 잘못 설계됐는지 잠깐 생각해 보세요.그런데 모델이 너무 간단해서 잘못될 부분이 한 군데 밖에는 없네요. ㅎ 잘못된 부분은 답글에 올렸습니다.답글 보시기 전에 많이 생각해 보세요. -- 회원아이디 엔터티의 주 식별자가 잘못 설계됐습니다. 회원아이디 속성 값이 고유하기 때문에 회원아이디 엔터티의 주 식별자는 [그림 2]와 같이 회원아이디 단독 속성이어야 합니다. [그림 2].. 더보기
DA 전망 지난 글에서 모델링을 모델러가 하지 못하는 현실에 대해 썼습니다. 나름 전문 모델러로서 슬픈 현실이 아닐 수 없습니다. 하지만 달라질 거라 확신합니다. 이유는 여러 가지가 있는데요. 우선 10년 전과 비교해 지금의 환경이 낫다고 생각하기 때문입니다. 모델러를 찾는 데가 없진 않습니다. 숫자를 헤아리기 힘든 공공에서 필수인 EA 프로젝트에서도 모델러가 필요하고요. 좋아지고 있는 추세로 판단하면 앞으로도 좋아질 거 같습니다. 시스템의 기반 환경도 좋아졌다고 생각합니다. SI 산업이 불황이라고 하지만 시스템 없이는 기업이 존재할 수 없는 상황이라 낙관적이라고 생각합니다. 지나친 긍정일 수 있지만 지금이 시스템 선진국으로 넘어가는 과도기라는 생각이 듭니다. 게다가 DB도 소위 기초 체력이 튼튼해졌다고 생각하고요.. 더보기
모델링을 수행하는 주체는? 실무에서 모델링을 수행하는 주체는 누구일까요? 당연한 질문인데 답변하기 망설여지는 게 안타깝습니다. 개발 프로젝트에서 데이터 모델링을 개발자가 수행하는 경우가 많습니다. 운영 단계는 제외하고 개발 단계만 따져도 개발자가 모델을 설계하는 경우가 60~70%는 되지 않을까 싶습니다. 개발 프로젝트에서 전문 모델러가 모델링을 수행한 지는 얼마 되지 않을 거 같습니다. 아마 15년 전부터 일부 대형 프로젝트에서 전문 모델러가 모델링을 수행하지 않았나 싶습니다. 그렇지 않으면 개발자 중에 모델링을 잘 하는 사람이 모델링을 수행하는 경우가 대부분이었습니다. 저도 15년 전에 그렇게 모델링을 했습니다. 개발도 했지만 프로그래밍 언어보다 MS 액세스를 먼저 다루었고, 정규화를 알고 있었기 때문이었죠. 하지만 그때도 일.. 더보기
업무를 모르면 모델링을 할 수 있을까요? 최근 컨텐츠에 대한 압박을 받고 있습니다. ㅎ카페 글도 그렇지만, 디비가이드넷에 컬럼을 연재하고 있어서 고민이 많습니다.그래서 다양한 생각을 하면서 글로 정리하고 있는데요.개인적인 생각일지라도 도움 받을 분이 있을 수 있어 카페에 하나씩 올릴 생각입니다.혹시 소재를 알려주시면 도움이 될 거 같습니다. 업무를 모르면 모델링을 할 수 있을까요? 정답은 ‘아니오’입니다. 업무에 의해서 데이터가 생기기 때문입니다.데이터는 업무에 종속돼 있죠.업무에서 필요한 데이터를 설계하는 게 모델링입니다. 그리고 결정적으로 데이터 사이의 종속성이 업무 요건에 의해서 결정됩니다.다른 말로 표현하면, 정규화가 업무 요건을 기준으로 수행된다는 점입니다. 업무를 수행하려면 이런저런 데이터가 필요하고, 이런저런 데이터를 제대로 사용하.. 더보기

티스토리툴바