주 식별자 썸네일형 리스트형 worst practice 이번 요건은 다소 까다롭습니다. -한 계좌에는 관리 사원, 실적 사원 등 여러 역할 사원이 존재한다.-한 사원은 여러 계좌의 관리 사원이 될 수 있고, 여러 계좌의 실적 사원이 될 수 있다.-동일 사원이 동일 계좌에 대해 여러 역할을 할 수는 없다.-계좌에 대한 역할 사원은 한 번 정해지면 바뀌지 않는다. 위 요건을 설계한 모델이 [그림 1]입니다.잘못된 부분을 생각해 보세요. [그림 1] 역할유형코드의 인스턴스는 관리사원, 실적사원입니다. -- 식별자밖에 없으니 식별자에 대한 문제죠. ㅎ 우선, 역할이 한 번 정해지면 바뀌지 않는다고 했습니다. 즉 한 번만 지정되는 것이니 역할지정일자 속성은 식별자가 아닙니다. 그리고 동일 사원이 동일 계좌에 대해 여러 역할을 할 수 없다고 했습니다. 이 요건 때문에 .. 더보기 [worst practice 1] 잘못 설계된 모델 잘못 설계한 사례 모델을 간혹 올릴 생각입니다.궁금하신 점이나 다른 아이디어 있으면 댓글로 남겨주세요. -- 요건은 아래와 같습니다. -회원은 주민등록번호 별로 한 번만 가입이 가능하다.-회원은 고유한 회원아이디가 있으며, 한 회원이 여러 개의 회원아이디를 가질 수 있다. [그림 1]은 위의 요건을 설계한 모델입니다. [그림 1] 어디가 잘못 설계됐는지 잠깐 생각해 보세요.그런데 모델이 너무 간단해서 잘못될 부분이 한 군데 밖에는 없네요. ㅎ 잘못된 부분은 답글에 올렸습니다.답글 보시기 전에 많이 생각해 보세요. -- 회원아이디 엔터티의 주 식별자가 잘못 설계됐습니다. 회원아이디 속성 값이 고유하기 때문에 회원아이디 엔터티의 주 식별자는 [그림 2]와 같이 회원아이디 단독 속성이어야 합니다. [그림 2].. 더보기 식별자 종류 – 주 식별자 주 식별자(Primary Identifier)는 엔터티에 하나만 존재하는 대표 식별자입니다. 업무 식별자나 후보 식별자와 달리 물리적인 개념이 강해 PK(Primary Key)라고 생각해도 될 거 같습니다. 주 식별자 역할은 두 가지 관점으로 생각할 수 있습니다. 하나는 자신의 엔터티를 바라보는 관점이고요. 다른 하나는 다른 엔터티에서 바라보는 관점입니다. 전자는 자신의 엔터티 내에서 인스턴스를 식별하는 PK 역할이고요. 후자는 다른 엔터티에서 바라볼 때 그 엔터티와의 관계를 식별하는 FK(Foreign Key) 역할입니다. 주 식별자는 물리적으로 인스턴스를 대표하는 역할을 하기 때문에 인스턴스를 조회할 때 사용하고요. 또한 다른 엔터티와 조인(Join)할 때도 주 식별자를 사용합니다. 주 식별자를 선정.. 더보기 이전 1 다음
