worst practice 썸네일형 리스트형 worst practice 이번 요건은 다소 까다롭습니다. -한 계좌에는 관리 사원, 실적 사원 등 여러 역할 사원이 존재한다.-한 사원은 여러 계좌의 관리 사원이 될 수 있고, 여러 계좌의 실적 사원이 될 수 있다.-동일 사원이 동일 계좌에 대해 여러 역할을 할 수는 없다.-계좌에 대한 역할 사원은 한 번 정해지면 바뀌지 않는다. 위 요건을 설계한 모델이 [그림 1]입니다.잘못된 부분을 생각해 보세요. [그림 1] 역할유형코드의 인스턴스는 관리사원, 실적사원입니다. -- 식별자밖에 없으니 식별자에 대한 문제죠. ㅎ 우선, 역할이 한 번 정해지면 바뀌지 않는다고 했습니다. 즉 한 번만 지정되는 것이니 역할지정일자 속성은 식별자가 아닙니다. 그리고 동일 사원이 동일 계좌에 대해 여러 역할을 할 수 없다고 했습니다. 이 요건 때문에 .. 더보기 [worst practice 2] 요건이 아래와 같습니다. -고객이 발급 받아서 사용하는 보안카드를 관리한다.-폐기한 보안카드 데이터를 관리하는데, 일자별로 폐기된 보안카드를 조회할 수 있도록 관리한다. 이 요건을 아래와 같이 설계했습니다.잘못된 부분을 생각해 보세요. [그림 1] -- 고객보안카드페기 엔터티의 주 식별자가 잘못됐습니다.쉽게 찾으셨을 거 같아요. 하나의 보안카드가 여러 번 폐기될 때 [그림 1] 고객보안카드페기 엔터티와 같이 설계할 수 있습니다.발급된 보안카드는 한 번 폐기되면 끝이기 때문에 [그림 2]와 같이 설계해야 적절합니다. [그림 2] 일자별로 폐기된 보안카드를 조회한다는 이유 때문에 폐기일자 속성이 주 식별자에 포함된 사례로, 역시 슈퍼 식별자입니다.폐기일자+보안카드번호는 인덱스를 나타내죠. [그림 2] 정도도.. 더보기 이전 1 다음
