[worst practice 4] 요건은 아래와 같습니다. -부서명, 전화번호, 부서장 등의 부서에 대한 기본 정보를 관리한다.-전화번호, 부서장 등의 데이터는 변경될 수 있어 이력 관리한다. 위의 요건을 설계한 모델이 아래와 같습니다.잘못된 부분을 생각해 보세요. [그림 1] -- 이력 데이터를 어떻게 설계할지에 대한 문제입니다. 이력 데이터를 원천 엔터티에 통합해서 관리하면 좋을 때가 있고 그렇지 않을 때가 있습니다. [그림 1]은 그렇지 않을 때에 해당돼서 아래와 같이 관리하는 게 바람직합니다. [그림 2] 실체를 관리하는 엔터티나 기본 정보를 관리하는 엔터티, 기준 정보를 관리하는 엔터티는 이력 데이터를 원천 데이터와 같이 관리하지 않는 것이 좋습니다. 실체 데이터는 한 번 생기면 그대로 존재하는 것이어서, 특성(속성)이 바뀐다고.. 더보기 worst practice 이번 요건은 다소 까다롭습니다. -한 계좌에는 관리 사원, 실적 사원 등 여러 역할 사원이 존재한다.-한 사원은 여러 계좌의 관리 사원이 될 수 있고, 여러 계좌의 실적 사원이 될 수 있다.-동일 사원이 동일 계좌에 대해 여러 역할을 할 수는 없다.-계좌에 대한 역할 사원은 한 번 정해지면 바뀌지 않는다. 위 요건을 설계한 모델이 [그림 1]입니다.잘못된 부분을 생각해 보세요. [그림 1] 역할유형코드의 인스턴스는 관리사원, 실적사원입니다. -- 식별자밖에 없으니 식별자에 대한 문제죠. ㅎ 우선, 역할이 한 번 정해지면 바뀌지 않는다고 했습니다. 즉 한 번만 지정되는 것이니 역할지정일자 속성은 식별자가 아닙니다. 그리고 동일 사원이 동일 계좌에 대해 여러 역할을 할 수 없다고 했습니다. 이 요건 때문에 .. 더보기 속성 명 정하는 방법 엔터티 명은 상당히 중요합니다.제가 매우 강조하는 부분이에요.속성 명도 중요하긴 한데, 중요하게 취급하기에는 개수가 너무 많고 잘못됐을 때 치명적이지 않습니다. 그래도 잘못 정했을 때의 부작용이 없는 건 아닙니다.속성 명과 데이터가 전혀 다른 경우가 많습니다.변용해서 사용했거나 처음부터 잘못 사용한 경우죠. 제 책에서 속성 명에 대한 설명은 많지 않습니다.더욱이 방법을 소개하진 않았는데, 이 글에서 간단한 방법을 소개하겠습니다. 속성은 도메인 자체가 중요합니다.금액, 날짜, 내용, 명, 번호, 여부, 코드 등의 도메인이 속성의 성격을 바로 나타내죠.속성에서 관리하는 데이터의 성격을 구분하게 하는 게 도메인입니다.그래서 우선 도메인의 종류와 의미를 파악해야 합니다.도메인은 사이트마다 조금씩 다를 수 있습니.. 더보기 이전 1 ··· 3 4 5 6 7 8 9 ··· 61 다음
