본문 바로가기

전체 글74

관계 종류 결정하기 오늘은 관계의 종류를 결정하는 방법을 살펴보도록 할께요. 가장 일반적인 관계인 1:M 관계에는 식별자관계(identifying relationship)과 비식별자관계(non-identifying relationship)가 있습니다. 예를들어 회사의 사원들이 존재하는데, 이들은 입사할때 특정한 사번을 부여받고, 모든 사원들은 부서에 소속된다면 다음과 같이 표현합니다. 이것은 비식별자 관계라고 합니다. 각각의 식별자가 독립적으로 존재하기 때문에 붙여진 이름입니다. 그림1. 부서 사원 비식별자 관계 이 사원의 매일의 근무 시간 정보를 기록하는데, 각자 사번별로 일자를 기록하여 관리한다면 다음과 같이 표현하죠. 이것은 식별자 관계라고 합니다. 그림에서 보듯 근태정보는 사번과 일자의 조합으로 식별할 수 있기 때문.. 2013. 5. 18.
속성이냐 엔터티냐 모델링을 하다보면 기존 엔터티에 몇 개의 속성을 추가하면 그만일지, 별도의 엔터티를 만들어 주어야 할 지 고민이 될때가 자주 있습니다. 오늘은 그런 상황에 대해서 생각해 보도록 하겠습니다. 예를들어 다음과 같은 직원 엔터티가 있다고 하겠습니다. 아버지의 성명을 관리해야 한다면 속성하나의 추가로 가능합니다. 이것으로 그만이라면 현재의 모델은 이대로 완벽하지요. 그런데, 조금 시간이 지나니 직원 부모의 환갑 축하금을 드리기 위해 아버지의 생년월일도 관리해야 한다고 합니다. 그러다보니 아버지만 드리면 안된다고 어머니도 드려야 한다고 하지요. 몇년이 지나 복지가 확대되어 자녀 출산 축하금도 지급하고 초등학교 입학선물도 준다고 하면 아이들 정보도 관리해야 하겠지요. 어느정도 까지는 아래와 같이 속성을 추가해가면서.. 2013. 5. 10.
서브타입 해체하기 지난번에 서브타입에 대해 소개해 드린적이 있습니다. (서브타입 사용하기) 그때 서브타입은 Relational Database에서 구현할 수 없는 개념적인 것이니 언젠가는 없애야 한다고 했었지요. 오늘은 그 해체 작업을 어떻게 하는지 살펴보도록 하겠습니다. 최근에 모델을 보다가 조금 특이한 서브타입 구조를 발견했습니다. 신청처리는 신청 자체를 접수하는 것도 있고, 승인하는 것도 있는데, - 여기까지는 일반적인 서브타이핑이죠 - 그 승인이 신청에 의거하여 발생 하기도 하고, 또 가끔은 그냥 승인 처리만 일어나기도 하는 경우입니다. 약간 사족을 달아보자면, 양쪽이 optional 인 관계는 사용을 지양!해야하는 관계 유형 입니다. 왜냐하면 양쪽이 optional이라는 것은 매우 약한 관계이다보니 서로 관계없는.. 2013. 5. 1.
이력 데이터 관리하기 오늘은 이력관리에 대해서 이야기 해보려고 합니다. 데이터 모델링을 하다보면, 중요한 데이터에 대해서 변경이 일어날때, 이전의 모습이 어땠는지를 기록해 두어야 할 필요가 생기구요. 이때 변경에 대한 이력을 기록하기 위한 데이터 모델을 작성하게 되죠. 이러한 이력을 어떻게 모델링 할 수 있을까요? 일단 데이터의 건수가 많지 않으면서 변경도 그다지 자주 발생하지 않는 경우는 하나의 테이블 내에서 최종 데이터와 이력 데이터를 아래와 같이 간단하게 함께 관리할 수 있습니다. 이전키를 가지기 위해서 자기참조관계를 맺어주게 되구요. 이력을 빼고 최종만 조회하기 위해서 최종여부를 두는 것이 편리합니다. 그런데, 데이터 건수도 많고 변경도 자주 일어나는 경우라면 이력 테이블을 별도로 분리해야 하구요. 사실 이게 훨씬 더.. 2013. 4. 24.