개발자 및 데이터베이스 디자이너, 안녕하세요!데이터베이스 스키마 디자인 관련 문제
내 프로젝트에 데이터베이스 스키마를 디자인합니다.
프로젝트에는 '생산자'와 '소비자'간의 관계가 포함됩니다. 그러나 '프로듀서'가 '사용자'와 '조직'모두 일 수있는 경우 '소비자'는 '사용자'일 수 있습니다 (단지 지금은). 프로젝트의 객체 모델을 고려한다면, 주로 '생산자'와 '소비자'라는 두 개의 기본 인터페이스로 구성됩니다. 관계는 'Organization'과 'User'라는 주 클래스의 인스턴스 사이에 있으며, 'Organization'클래스는 'Producer'인터페이스를 구현하고 'User'클래스는 'Producer'와 'Сonsumer'의 인터페이스를 구현합니다. 예를 들어, 내 응용 프로그램을 사용하는 특정 기간 동안 일부 사용자는 다른 사용자에게 항목을 판매 할 수 있어야하며 다른 사람에게 물건을 살 수 있어야합니다. 향후
위의 설명에 따라 ER 다이어그램을 디자인했지만 몇 가지 단점이 있습니다.
첫째, ER-설명 및 UML 설명 사이에 완전한 일치가 없다. 인터페이스에 대해 분리 된 테이블을 할당해야합니까? 나도 몰라. 사실,이 경우 ER 기술에 따르면 '생산자'와 '소비자'가 '조직'과 '사용자'의 수퍼 클래스라고 할 수 있습니다. 그러나 사실 그들은 단지 인터페이스 일뿐입니다.
둘째, 불필요한 'JOIN'없이 스토리지에 대한 액세스를 충분히 유연하게 제공하는 가장 간단한 설계가 필요합니다. 어쩌면 인터페이스 구현을 완전히 포기해야할까요? 그러나 나는 OOP 부를 사용하기위한 모든 것입니다. 데이터베이스 레벨에서 인터페이스 구현을 사용할 수 있습니까? 상속을 사용할 수 있다는 것을 알고 있습니다. 그러나 이러한 모든 트릭이 생산성에 어떻게 영향을 미치는지는 알지 못합니다. 이전의 모든 프로젝트에서 수퍼 클래스와 인터페이스를 사용할 필요가 없었기 때문입니다. PostgreSQL을 관계형 DBMS로 사용하겠습니다.
성공적인 데이터베이스 구성에 대한 경험과 구현을 알려주십시오.
UPDATE
나는 테이블 '생산자'와 '소비자'의 역할을 할당 할 경우, 내가 그들을 엔티티 '사용자'와 '조직'의 특성을 속성을 제공해야합니다. 한편, 역할의 수가 증가하면 속성의 수가 증가합니다. 이 경로는 테이블 속성의 혼잡을 수반합니다. 그리고 다른 역할에 대한 일부 속성은 NULL 값을 따릅니다. 반면에 하나의 역할에 대한 하나의 속성은 다른 역할에 대한 여러 속성을 따를 수 있습니다. 예를 들어 엔터티 'Organization'에 대한 'name'특성은 엔터티 'User'에 대한 'firstname', 'middlename', 'lastname'및 'username'특성을 따릅니다. 셋째, 여전히 '프로듀서', '조직', '사용자'및 '소비자'모델을 서로 분리하고 싶습니다.
당신이 고민하고 있다고 생각하는 것은 "역할"의 주제입니다. 매우 일반적인 문제입니다. 사람은 많은 역할을 할 수 있습니다. 그렇다고해서 항상 그럴 수밖에 없다는 것을 의미하기 때문에 사람을 일종의 역할로 만드는 것은 아닙니다. 롤 플레잉 관계를 만들면 문제를 해결할 수 있지만 문제를 신중하게 분석 할 시간이 없다는 것을 알 수 있습니다. 당신은 또한 실재물 (예 : 생산자로서의 사람)이 역사와 다른 사실들을 유지하는데 도움이된다는 것을 발견 할 수 있습니다. –
참으로 까다 롭습니다. 짐이 말하는 것은 옳다. 나는 저녁 늦게 이것을 들여다 보겠다. (짐이 좋은 대답을 제시하지 않는 한). –
나는 한 번에 너무 많은 질문을하고 있다고 생각합니다. 나는 4 가지 명시 적 질문과 몇 가지 더 암묵적인 질문을 세운다. 모든 것은 문제 영역에 존재하는 것의 부정확 한 모델에 기인합니다. 그 문제를 해결하는 것이 좋습니다. UML과 ER은 둘 다 쉽게 맞출 수 있습니다. 사실 하나의 UML 모델은 OOP와 DB의 기반을 제공 할 수 있습니다. –