아크관계4 FK를 어느쪽에 둘지 결정하기 모델링을 하다보면 어느쪽 테이블에 FK를 둘 지 하는 것이 고민이 될 때가 있습니다. 오늘은 그런 상황에 대해서 살펴보도록 할께요. 먼저 가장 단순하게, 다음과 같은 상황이라면 어떨까요? 1:M 관계 그림과 같이 1:M 관계라면 당연히 M쪽에서 FK를 가지게 됩니다. 아니 가져야 합니다. 1 쪽에서 M 개의 데이터를 수용할 수는 없으니까요. 팀장 쪽에서 팀원 이라는 속성을 팀원1~팀원100 정도로 가지고 있지 않는 한, 팀원의 정보를 가지는 것은 불가능합니다. 한 팀장 밑에 팀원은 여러명 일 테니까요. 데이터는 이렇게 들어가게 되겠지요. ( 아래그림처럼, 테이블에 들어갈 데이터를 예를들어 써보시면 확실하게 이해가 갑니다. 저도 평소에 뭔가 헷갈린다 싶을 때는 꼭 데이터를 예를 들어 적어보는데요, 생각이 .. 2013. 8. 29. 아크관계를 위해 키 조정하기 오늘은 통합이나, 아크(arc) 관계 설정을 위해서 키를 조정하는 상황에 대해서 살펴 보겠습니다. 예를들어 도서를 대출할 때 개인회원이나 법인 회원이 대출 가능한 경우 입니다. 개인회원은 주민등록번호를 사용하여 식별하구요, 법인회원은 법인번호로 식별하도록 합니다. 그런데, 법인은 해마다 일정금액을 기부해야만 법인 회원 자격이 유지되도록 하고 있기 때문에, 법인번호와 회원등록년도를 조합하여 식별하도록 키를 구성하겠습니다. 개인회원이나 법인회원 모두가 도서 대출을 할 수 있는 경우, 도서대출 테이블에 전달할 키 (Foreign Key)가 문제가 됩니다. 만약 아무 생각없이 개인이나 법인을 모두 연결한다면 컬럼이 이렇게 구성되겠지요. 그런데, 이때에는 개인이 대출한 경우는 주민번호 컬럼만 값이 들어있고 나머지.. 2013. 7. 11. 엔터티 통합하기 요사이는 테이블들을 합칠지 말지 하는 고민을 많이 하고 있습니다. 언뜻 보기에는 테이블의 데이터들이 유형만 다를 뿐 비슷해 보이기는 하는데, 속성을 하나하나 뜯어 보자니 좀 다른것 같기도 하고... 참 결정하기 힘든것 같습니다. 예를 들어 도서관에서 책을 구매하고자 하는 대상을 모아놓는 테이블이 아래와 같이 여러 종류가 있다고 해볼께요. 속성이 조금씩 다르기는 하지만 의미상으로는 같은 구매 대상이기 때문에 통합하고 싶습니다. 좋은 결정을 내리기 위해서는, 통합 했을때의 장단점을 하나하나 따져보는 수밖에 없을것 같아요. 일단 장점을 살펴보자면, 실제로 주문을해서 구매를 진행하게되는 이후 프로세스 처리 시 에는 다 같이 사용될 확률이 높은데, 통합하면 데이터 모델이 단순해집니다.예를들어 통합전에는 모든 구매.. 2013. 6. 13. 선택적(optional) 관계의 모든것 저답지 않게 오늘은 좀 선정적?인 제목을 달아봤습니다. 혼자서 글을 쓰고 있고, 부끄러워 주변에 알리지도 않으면서도, 방문자가 늘지않고 오히려 줄어드니 기운이 빠져서요. 제목을 이렇게 하면 방문자가 늘까요? :-) 오늘은 선택적 관계에 대해서 알아보겠습니다.optional 은 관계위에 동그라미로 표현하고, "~ 일 수도 있다" 라고 읽지요. 예를들면 이런겁니다. 그림1. 부서와 사원 사원은 늘 특정 부서에 속하지만, 부서중에는 사원이 하나도 없는 부서도 존재한다는 의미입니다. 반대의 경우도 물론 가능하겠죠.그림2. 부서와 사원 부서는 늘 사원을 가진다. 부서를 만듦과 동시에 팀원들을 발령한다는 의미죠. 하지만 사원은 부서에 속하기도 하고 속하지 않기도 한다 인데, 예를들어 신입사원이 입사했을때 한동안 팀.. 2013. 6. 6. 이전 1 다음
