본문 바로가기

Data Modeling21

엔터티 분류하기 요사이는 엔터티의 이름을 짓고 있는데요, 이러한 작업은 엔터티가 어떤 유형인지를 구분하는 것으로부터 시작됩니다. 엔터티 이름의 어미를 유형 구분으로 끝내는 것이 성격을 명확히하고 의사소통을 쉽게 하기위한 기본사항이거든요. 엔터티 이름의 어미에 사용하는 유형을 예로 들면 다음과 같습니다. ~ 코드 : 국가코드와 같이 데이터 건수가 적으면서 변경이 거의 없는 기준 정보 입니다.~ 기본 : 고객기본, 창고기본과 같이 업무 시작이 되는 주체에 대한 정보 입니다.~ 내역 : 주문내역, 재고내역과 같이 ~기본 정보에 의해 발생하는 이벤트나 상태를 다루는 정보입니다.~ 상세 : 고객연락처상세와 같이 ~ 기본 또는 ~ 상세의 성격중 일부 정보를 구체적으로 표현하기 위한 정보입니다. ~ 이력 : 고객기본변경이력과 같이 .. 2013. 6. 26.
ERD에서 올바른 관계(relationship) 맺어주기 요즘은 현재 운영중인 시스템의 ERD를 보면서 테이블들 간의 관계를 찾아주는 작업을 하고 있습니다. 초기 ERD는 운영 Database에서 reverse 해서 만들었는데, 테이블간의 관계는 전혀 없습니다. 이걸 들여다 보면서 나름 해독하고, 업무 설명 문서를 읽고, 그래도 모르겠는 내용은 물어가며, 이렇게 저렇게 상상의 나래까지 더해서 관계를 찾아가고 있는데요. 꽤 재미있네요. :-) 오늘은 이렇게 관계를 찾아나가던 중, 세 번이나 관계를 바꾸고 나서야 만족스러운 결과를 얻었던 사례를 말씀드리려고 해요. 우리 도서관에 연체한 회원의 목록을 타 도서관에 보내서, 그 쪽 도서관에도 연체한 사람인지 알아보려고 하는 업무라고 가정할께요. 다른 도서관은 우리 도서관의 타 지역 분원 일 수 있구요, 아니면 아예 다.. 2013. 6. 20.
엔터티 통합하기 요사이는 테이블들을 합칠지 말지 하는 고민을 많이 하고 있습니다. 언뜻 보기에는 테이블의 데이터들이 유형만 다를 뿐 비슷해 보이기는 하는데, 속성을 하나하나 뜯어 보자니 좀 다른것 같기도 하고... 참 결정하기 힘든것 같습니다. 예를 들어 도서관에서 책을 구매하고자 하는 대상을 모아놓는 테이블이 아래와 같이 여러 종류가 있다고 해볼께요. 속성이 조금씩 다르기는 하지만 의미상으로는 같은 구매 대상이기 때문에 통합하고 싶습니다. 좋은 결정을 내리기 위해서는, 통합 했을때의 장단점을 하나하나 따져보는 수밖에 없을것 같아요. 일단 장점을 살펴보자면, 실제로 주문을해서 구매를 진행하게되는 이후 프로세스 처리 시 에는 다 같이 사용될 확률이 높은데, 통합하면 데이터 모델이 단순해집니다.예를들어 통합전에는 모든 구매.. 2013. 6. 13.
선택적(optional) 관계의 모든것 저답지 않게 오늘은 좀 선정적?인 제목을 달아봤습니다. 혼자서 글을 쓰고 있고, 부끄러워 주변에 알리지도 않으면서도, 방문자가 늘지않고 오히려 줄어드니 기운이 빠져서요. 제목을 이렇게 하면 방문자가 늘까요? :-) 오늘은 선택적 관계에 대해서 알아보겠습니다.optional 은 관계위에 동그라미로 표현하고, "~ 일 수도 있다" 라고 읽지요. 예를들면 이런겁니다. 그림1. 부서와 사원 사원은 늘 특정 부서에 속하지만, 부서중에는 사원이 하나도 없는 부서도 존재한다는 의미입니다. 반대의 경우도 물론 가능하겠죠.그림2. 부서와 사원 부서는 늘 사원을 가진다. 부서를 만듦과 동시에 팀원들을 발령한다는 의미죠. 하지만 사원은 부서에 속하기도 하고 속하지 않기도 한다 인데, 예를들어 신입사원이 입사했을때 한동안 팀.. 2013. 6. 6.

티스토리툴바