어떻게 모델링 사용자 테이블을 존재하고 같은 다른 테이블이 많이 존재하는 사용자 managament 시스템, 주문, 에서 작동 데이터베이스 설계 또는 ERD 다이어그램 제품, 고객 등 노트, 의견, CREATED_BY이 (가) 작성한 (사용자 표를 가리키는을 가질 수 있습니다 그 다른 테이블의 각) 및 edited_by (또한 사용자 테이블을 가리키는) 속성ERD 다이어그램 - 하나 개의 테이블에 대한 연관의 많은
결국 ERD 다이어그램은 하나의 동일한 테이블 (사용자)에 많은 연관성을 가지고 있기 때문에 혼란 스럽습니다. 이 다이어그램은 한 곳에서 많이 연관되어 있기 때문에 읽을 수 없습니다.
또는 데이터베이스 디자인 문제입니까? - 아마, 각 테이블에 두 속성이 포함되어서는 안되지만 다른 방식으로 처리되어야합니다.
ER 모델에서 두 엔티티간에 둘 이상의 관계가있을 수 있습니다. 이것에 대한 사례를 설명했습니다. 이것은 주제 자체에 의해 주도되며 프로젝트의 분석 단계에서 발견됩니다. ERD의 라인은 이러한 발견 된 관계를 나타냅니다. 이것이 복잡하다면, 주제가 복잡하거나 분석가가 실수를했기 때문입니다.
데이터베이스 디자인 (최소한 관계형 디자인)에서 관계는 주어진 테이블의 주어진 행을 참조하는 외래 키로 구현됩니다. 아마, 디자인은 분석에 동의합니다. 많은 ERD는 설계가 완료된 후에 작성되며 애널리스트의 ER 모델이 아닌 디자이너의 관계형 모델을 반영합니다.
오늘날의 많은 개발자는 단순히 머리를 분석하고 직접 디자인을 진행합니다. 간단한 경우, 시간을 절약 할 수 있습니다. 복잡한 경우에 이것은 당신을 물기 위하여 돌아올 수있다. 분석에서의 오류는 디자인 계층에 묻힐 때까지 발견되지 않습니다.
짧은 대답은 아무 문제가 없다는 것입니다.
다른 디자인이 다른 이유로 존재한다는 사실을 기억해야합니다. 이 정보를 실제 모델 (예 : 의도 한 데이터베이스의 정확한 스키마를 보여주는 모델)에서 볼 수 있기를 기대하지만, 그러한 구현 세부 사항을 개념적으로 벗어나 읽기 쉽도록 논리적 모델에서 제외 할 수도 있습니다. 시스템 감사와 같은 일은 구현 세부 사항 일뿐입니다. 상위 수준 디자인에서는 정보가 유용하지 않을 것입니다.
기억할 것은 모델이 항상 하나의 다이어그램 일 필요는 없다는 것입니다. 그들은 종종 너무 커지고 혼란스러워 하나의 다이어그램을 볼 수 없으며 주문 영역에 대한 다이어그램, 고객에 관한 다이어그램 등을 주제 영역별로 나눠서 합리적으로 결정할 수 있습니다. 이것은 가독성을 높이는 데 실제로 도움이 될 수 있습니다.