나는 개념적 다이어그램을 작성하고있다 [예, 속성과 키를 포함하고 있다는 것을 알고 있습니다. 그러나 이것은 제가 배우는 동안하고있는 것을 통합하기위한 것입니다]-관계에 초점을 둔 개념적으로 취급하십시오 테이블이 아닌 다이어그램 방법)

내 마음의 장애물은 : 나는 프로필, 위치 및 조직 관계를 모델링하는 가장 좋은 방법을 확인하려고합니다.

우선, 규칙 :

• 하나 이상의 프로필 은 하나 이상의 조직 의 회원 / 친구 일 수 있습니다 . 그 반대.
• 하나 이상의 프로필 은 다른 프로필의 회원 / 친구 일 수 있습니다.
• 하나 이상의 조직 이 다른 조직의 구성원 / 친구 일 수 있습니다.

친구와 회원의 차이점은 친구는 읽기 전용과 같으며 [레벨에 따라] 회원은 모든 사항을 수정할 수있는 모든 권한이 있습니다.

더 복잡하게하기 위해, 위치 에는 고유의 "추가"수정 가능 규칙 세트가 있습니다. 예를 들어, 조직 은 두 개의 위치를 소유 하지만 위치 규칙에 따라 해당 조직 의 회원 [ 프로필 ]은 한 위치에서 완전히 액세스 할 수 있지만 다른. [죄송합니다 : 더 나은보기 크기를 위해 다른 창에서 이미지를 열어야 할 것입니다.]

보시다시피, 프로필과 조직의 개념은 친구와 회원의 개념으로 모델링 될뿐만 아니라 프로필과 조직의 개념은 거의 동일합니다. 레코드의 관리자 / 회원 / 친구 등]. 따라서 왜 다음 개념을 생각하고 있습니까?

위의 이미지에서 Option.2를 참조하십시오. 그러면 현재 Organization 및 Organization_Locations 테이블과 그 관계 가 제거 되어 Profile 과 다소 재귀적인 관계로 Option.2 Organization Table로 대체됩니다 .

문제의 요점은 내가 프로그래밍 방식으로 단순성과 유연성을 해치면서 다형성에 너무 신경을 쓰는지 아닌지, 프로세스 자체를 완전히 혼란스럽게하는지 여부입니다.)

사전에 귀하의 생각에 감사드립니다-M :).

수정 된 다이어그램 :

MDCCL의 질문에 대한 답변 :

1. 예, 프로필 은 한 사람으로 구성되어 있으며 동일한 근거를 가지고 있지만 이론적 근거가 향하는 곳은 본인이 맞습니다. 조직 과 개인 은 프로필의 하위 유형이 될 수 있습니다 . 따라서 프로필은 한 사람 또는 하나의 조직으로 구성됩니다.
2. 프로필 당 하나의 이메일 주소.
3. 예. 위와 같이, 조직에는 최소한 이메일 주소가 있어야합니다.
4. 하나의 고정 주소를 수정하십시오.
5. 가능성은 있지만, 비록 내가 배우고있는 것으로부터의 희귀 성은 미래 장수 등을 위해 모델링해야하고, 단지 확인하기 위해 위치는 둘 이상의 사람이 소유 할 수 있습니다.

6. 위치는 확실히 다른 대부분의 필수 요소입니다. 아마 그때 당신이 읽을 수 있도록 간결 여기에 무엇을 할 수 있는지 명확합니다하지만 희망이 질문에 도움이 추가 관련된 첫번째 [것입니다 내 다른 답변 한 후 마지막에 # 6 내 대답을 참조 ]) 재 : 역할 소유자. An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[따라서 이전에 추측 한대로; 간단히 말해서, Profile은 0 개 이상의 Location / s의 소유자가 될 수 있습니다.

7. 예, 위치 의 소유자 인 프로필 은 모든 역할 권한 [슈퍼 사용자]을 가정합니다 . 프로필 입니다 관리자 의 특정 세부 사항 수정할 수 있습니다 위치 /하지만 주로하는 데 도움이 다른 모든 통해 공급 세부 사항 / 데이터 편집 / 프로필이야 -이 주로에 의해 제공됩니다 '기본 회원 / s'를 상기 위치 / s의; 이는 잎 기본 회원 읽기 전용 관련된 모든 수, 위치 에 의해 scrutineered해야 세부 사항 및 공급 데이터 관리 / 소유자 . 이 외에도 모든 프로필[조직 / 사람] 훨씬처럼 기본 회원은 하자의 용어들을 A - '읽기 전용' 고객을 -하지만 위치는 다음과 같이 설정되어있는 경우에만 공개 [이 아닌 개인 ] 그들이 같이 입력을 제공하지 수 있지만, 기본 회원 수를 .

8. 옳은.
9. 직감이 놀랍습니다! 예, it is foreseen that a single Location could contain one to many LocationTypes-더 복잡하게하기 위해 개별 위치 유형에 '부모'위치와 관련된 프로필에 대한 다양한 권한이있을 수 있습니다. 이 중 권한은 위치에서 위치 유형 (OS 폴더 보안 권한과 유사)으로 필터링됩니다. 나는 다이어그램을 통해 설명으로 더 많은 유형을 언급 할 수 있다고 지적합니까?
10. 예.
11. 12 참조.
12. 맞습니다. Profile1 [Person or Organization]이 Profile2 [Person or Organization] 소유 위치에 대해 [정확한 권한을 가진 친구 / 회원 인 경우 ]에 대해 행동하는 것이 가장 중요합니다.
13. 매우 합리적입니다-a ) 동의합니다. b) 동의합니다. c) 예, 흠? ... 아마도 프로필 [person] ~ Profile [person] = Friends 와 거의 동일해야합니다 . 무엇이든 설명, 그것을 중심으로 돌고있는 것 위치 로, 조직 / s는 다른 따라 행동 할 것이다 기구 위치 / s의; 의미 상으로, 나는 어떤 조직이라도 ' 원인이 아무리 좋더라도'그 위치 조직의 '구성원'으로서 하위 조직으로 보이기를 원할 것 입니다.

[6]. 이것은 여전히 ​​나에게 희미한 회색이지만, 여기에 간다 ... 아마도 내 손해를 입히기 위해, 회원 / 친구 관계의 유사성은 너무 가깝기 때문에 그들을 결합하려고 생각했다. 다이어그램과 해석을 뒷받침하면, 그것들을 별도로 유지하는 것이 옳을 것 같습니다 [ 나는 enum 속성을 통해 단일 관계를 구별하려고했습니다 : Owner / Admin / Member / Friend ]. 예를 들어 다음과 같은 개념 : 조직이 소유 한 위치는 0 대에서 많은 프로필 [개인 또는 조직]이 수행하지만, 관계 ([멤버 또는 친구] ]는 역할을 통해 표시됩니다.So perhaps, the default relation between any Profile is Friend [much like Guest at Answer#7], enabling them to view the read-only Location data and msg/email the Location Owner/Admin - but not allow them to receive Location updates, news, etc., as a Member would.

개인적 경험을 통해 처리하는 데이터를 이해하고 분류하고 모델링하는 데 시간을내어 전체 개발 프로세스를보다 쉽고 유연하게 수행 할 수있게되어 기쁩니다. 그리고 나는 당신도 이미 이것을 알고 있다고 확신합니다.

예비 데이터 모델 및 가정 된 비즈니스 규칙

귀하의 사양을 제대로 이해하지 못하도록 귀하의 질문을 읽고 다이어그램을 면밀히 검토 한 후 가정 한 비즈니스 규칙 목록을 정의했습니다. 이러한 목록을 정의한 후 외부 플랫폼 (Dropbox)에서 .PDF 문서로 업로드하기로 결정한 IDEF1X ^[1] 데이터 모델을 도출 했습니다. 형식으로 인해이 데이터 모델은 포함 된 이미지에 적합하지 않기 때문입니다. 이 두 가지 도구는 앞으로 나아갈 수 있도록 해결해야 할 측면 섹션에서 아래 열거 한 몇 가지 중요한 사항에 대한 참조로 유용 합니다 .

먼저, 여기에…

• 조직 및 프로필 예비 데이터 모델 .

단지 예비 일 뿐이므로 원하는 최종 데이터 모델을 완성하는 데 도움이되는 수단으로 고려하십시오.

가정 된 비즈니스 규칙

이 예비 데이터 모델은 다음과 같이 열거 할 비즈니스 규칙 (귀하의 질문에서 추론) 모음에서 파생되었습니다.

조직 및 프로필

참고Profile 현재의 동의어로 이해된다 Person.

• 이 Organization의 친구입니다 일대 Profiles .
• 이 Organization의 친구입니다 일대 Organizations .
• 은 Organization의 구성원 인 일대 다 Organizations .
• A Profile는 일대 다 의 멤버입니다 Organizations.
• A Profile는 일대 다 친구입니다 Profiles.
• A Profile는 일대 다 의 멤버입니다 Profiles.

위치와 주소

• 은 Organization소유 일대를 Locations .
• A Location는 일대 다로 분류됩니다 LocationTypes( 주어진 시점에서 하나만 ).
• A를 Location가질 수 일대 Addresses ( 하나 Physical , 하나 를위한 Shipping, 하나 에 대한 Billing, 또는 하나의 모든 상기 용도로 사용, 또는 하나를 그 두 가지 목적을 결합 및 작용 다른 하나만 그들의 참조).

• 이 Address에 의해 유지 될 수 일대 다 Profiles 또는 다른 방법을 넣어, A는 Profile유지 일대 Addresses .

• 특정는 Address사용할 수있다 일대 Profiles (로서의 Physical대 하나 Profile 에 사용되는 Billing에 의해 다른 하나 등). 그래서,가 Address에 대해 유사한 방식으로 작동 Locations하고 Profiles.

  • 따라서, 개인은 Address, 수있다 동시에 타입, Physical, Shipping 및 Billing .

위치와 역할

• A는 일대Location 다를 엽니 다 . Roles
• A Role는 일대 다로 수행 될 수 있습니다 Locations.
• A는 Profile(가로 설정되고 나면 Member의 Organization) 수행 할 수있다 일대 하나 Roles 에, 일대 다 Locations (그러나 하나의 특정 Role각 Location특정 시점, 즉, 더 결코 두 개 또는 Roles 동시에 ).

앞으로 나아 가기 위해 해결해야 할 측면

데이터 모델의 해상도를 계속 발전시키기 위해 다음은 일단 해결 한 후에이 목표를 달성하는 데 도움이되는 관련 사항 목록입니다.

1. 나는 Profile당신의 맥락 에서 용어 가와 비슷한 (또는 같은) 의미를 가지고 있다고 가정 Person했지만 조금 다를 수 있습니다. 이런 식으로 시나리오에서 엔터티 Organization와 Person하위 유형이 Profile?

2. A는 수 Profile(또는 Person) 자신 일대는 EmailAddresses , 또는 A는 Profile(나 Person)는 고정 정확히 하나 EmailAddress ?

3. 당신은이에 대한 가능성을 제공 하시겠습니까 Organization통해 연락을 Telephone하고 Email, 또는 당신은 만 가능으로 제한하려는 Profile(또는 Person)?

4. 나는 a Location가 정확히 Address 유형 중 하나 에 고정되어 있다고 가정합니다. Physical맞습니까?

5. A는 것이 가능 Location하여 공유 할 수 일대 다른 Organizations 나 , 그렇지 않으면,이 Location소유 할 수 하나 Organization ?

6. 당신은 의견을 통해 a Member와 a 라는 사실 Friend이 동일 하다는 것을 언급했습니다 . 내가 제안한 예비 데이터 모델에서 볼 수 있듯이, 나는 당신에게 원래의 사양을 따랐으며 가능한 한 최선의 정의를위한 노력에 도움이 될 수 있다고 생각하기 때문에 다른 단체 들 사이의 Organization그리고 Profile(또는 Person) 멤버십과 우정의 가능한 모든 조합을 묘사 했습니다. 시나리오의 해당 부분에 대한 구조. 이런 의미에서:

   • 나는 그 진술 an Organization is a Member of another Organization이 a Profile (or Person) is a Member of an Organization이라는 엔터티에 관한 진술 과 다른 효과를 갖는다 고 가정한다 Location.
   • 당신은 데이터 모델에서 볼 수 있듯이, 나는 생각 Role의이 Owner에만 유효 Organization유효한, 나에게, 그리고 Roles에 대한 Profile(또는 Person), A는 내부에 Location있다 Admin하고 Member. 이 모든 것에 대해 어떻게 생각하십니까? 귀하는 귀하의 상황에 적용되는 비즈니스 규칙과 직접 접촉하기 때문에 본인의 가정이 올바른지 알려 주어야합니다.

7. Profile(또는 Person) Roles동일하게 다른 게임을 할 수 있습니까 Location? 즉, A는 수 Person같은 시간에, 수는 Admin또한과 Member같은의 Location? 이와 관련하여 규칙은 무엇입니까?

8. 나는 같은 Profile(또는 Person) 다른 방식 Roles으로 다르게 연주 할 수 있다고 생각합니다 Locations. 예를 들어, 특정 Profile(또는 Person)은 Location“1” 의“관리자” 이며 이와 동일한 Profile(또는 Person)은 “2” 의“ Member”입니다 Location. 내가 맞아?

9. 특정인 이 동시에 Location다른 것을 가질 수 있습니까? 아니면 LocationTypes개인이 Location정확히 하나를 유지하도록 고정되어 LocationType있습니까?

10. 속성이 Organization.Website"dba.stackexchange.com"과 같은 특정 조직의 웹 사이트 주소를 나타 냅니까?

11. 경우 Profile(것으로 이해 "1" Person)이다 Member(또는 Friend)의 Profile"2"는, 그것이 가능하다 Profile아웃 캐리 "1" Role(A)에 Location의해 소유 Profile"2"? 나는 그런 시나리오가 사이의 관계에 대해서만 유효하다는 것을 고려 Organization하고 Member Person당신이 어떻게 생각하십니까, 그래서?

12. 비슷한 방법으로, 경우에 Organization"1"는 것입니다 Member(나 Friend)의 Organization"2", 그것은 가능하다 Organization"1"밖으로 수행하기 위해 RoleA의 Location소유 Organization"2"? 다시 말하지만, 이런 종류의 시나리오는 Organization과 a 사이의 관계에만 유효하다고 생각합니다. Member Person맞습니까?

13. 이 점에서 나는이 질문 -를 쓰고 -while 나는 거기에 관련된 세 개의 다른 종류의 관계이다라고하는 것이 합리적이 될 것이라고 생각 Organizations하고 Persons, 우리가 정의 할 수 있습니다 :

    • (a) a Organization와 a 의 관계는 Person“ Membership”입니다.
    • (b) a Person와 다른 Person" Friendhip" 와의 관계 .
    • (c) 개인 과 다른 사람의 관계를 설명하기 위해 아직 의미있는 이름 을 찾지 못했습니다 .OrganizationOrganization
    • 따라서 (a), (b) 및 (c)에 대해 어떻게 생각하는지 알려주십시오.

14. 는 것이 가능 Organization수 Friend(또는 Member중) 일대 다를 Organizations동시에? 또는 하나의 독점적으로 다른 사람 Organization과 만 관계를 가질 수 있습니다.Organization?

첫 번째 발전을 묘사 한 연속적인 데이터 모델

위에 나열된 보류중인 측면에 대한 귀하의 답변과 해결에주의를 기울여 다음을 만들었습니다.

• 조직 및 프로필 예비 데이터 모델-첫 번째 사전 .

아직 익숙하지는 않지만이 새로운 데이터 모델은 다음과 같은 비즈니스 규칙을 나타냅니다.

• A는 Profile것입니다 중 하나 Organization 또는 을 Person. ^[2]
• A는 Profile의 제공 친구가 될 수 있습니다 일대 FriendProfiles 및이 Profile의 받아들이는 친구가 될 수 있습니다 일대 다 FriendProfiles . ^[삼]
• A는 Location구성 될 수 일대 다 Locations . ^[4]

후속 특정 의견에 대한 답변

관심사 분리 (예 : LocationAddress 및 ProfileAddress)를 메모 / 복합하는 것이 정말 흥미 롭습니다. 나는 분명한 관계없이 모든 사람들을 서두르고 유지하고 싶었습니다.

그렇습니다. 이 용어는 일반적으로 응용 프로그램 개발 단계와 관련이 있으며 현재는 응용 프로그램 개발 단계와 관련이 있기 때문에 관심사 분리 ( 응용 프로그램 프로그래밍 및 디자인 의 기본 원칙) 라고 부르지는 않지만 좋은 비교 입니다. 데이터를 이해하고 논리적 구조를 설계하는 단계.

개인적 경험에서 볼 때,이 단계는 중요한 것을 전체 맥락에 두는 것과 관련이 있으며, 관심있는 특정 시나리오에서 관련이있는 다른 엔티티간에 존재하는 연관성을 보는 것과 관련이 있습니다. 데이터 모델에서 이러한 것들을 묘사. 당신에 대해 주석되는 특정의 경우, Address기업이 할 수 있습니다 다른 엔티티, 하나와의 연결의 종류가 Profile와와 다른 일을 Location.

그렇습니다. 무언가가 옳거나 자연스럽지 않다면 적절한 데이터를 이해하기 위해 더 많은 노력을 기울여야한다는 신호일 수 있습니다. 이런 식으로, Address엔티티는 내가주의해야 할 것들 중 하나입니다. 왜냐하면 a Profile와 an 의 관계 는 엔티티를 통해 처리 Address 될 수 있다고 생각 Location하기 때문에 (모든 사람 Location은 적어도 하나의 물리적 요소를 가져야 한다는 사실 때문에) Address) 따라서 최신 모델에 묘사 된 연관 엔티티를 무시할 수ProfileAddress 있지만 이러한 점을 계속 분석하여 아이디어를 알려 주시기 바랍니다.

또한 IDEF1X에서 가독성을 높이기 위해 엔티티에서 PK / FK 표기법을 변경하는 것이 일반적입니까 (예 : ProfileId-LocationOwnerProfileId)?

IDEF1X는 사용 되는 엔터티에 따라 이러한 속성 의 의미 를 포착하기 위해 FOREIGN KEYS를 나타내는 역할 이름 을 사용할 것을 권장하기 때문에 그렇습니다 . 이것은 또한 기본 키 마이 그 레이션 개념과 밀접한 관련이 있습니다 . 실제로 역할 이름을 사용하는 것은 IDEF1X보다 우선합니다. 원래 1970 년 정본에서 EF Codd 박사가 발표했기 때문입니다. 이런 식으로 IDEF1X 표준이 관계형 모델을 향한 충실도를 명확하게 볼 수 있습니다 .

솔루션과 함께 / 솔루션에서 모델이 마음에 들지 않거나 느끼지 않는 점에 대해 흥미를 느끼고 싶습니까?

이미에 대해 설명한 사항 외에 Address기업, 안 확인이있는 경우입니다 Roles주어진에 의해 수행 Profile특정에이 Location에 대한 동등 Organization또는 Person. 내 관점에서, Person첫 번째는와 연결되어야하며 Organization, 그러면 특정에서 수행 Organization할 것을 지정 하지만 시나리오를 더 잘 알고 있으므로이 규칙은 불필요 할 수 있습니다. 이 점에서, 나는 나에게 상황 설명이나 알고하는 것이 매우 도움이 될 것이라는 사실을 주장하기 위하여려고하고 의미 로이 데이터 구조주고 미래의 사용자 것을 , 그리고PersonRoleLocationOrganizationProfileLocation하지만 기밀 정보로 간주 될 수 있음을 이해합니다. 따라서 이는 제한 사항입니다.

현재 구조를 사용하면 모든 사람 ( Organization또는 Person)이 다른 사람 ( Organization또는 Person)과 관련 될 수 있고 Role어디에서든 ( Location) 아무거나 ( ) 할 수있는 것처럼 보이지만 혹독한 것은 이것이 바로 여러분과 사용자가이 데이터베이스에서 기대하는 것입니다. 물론 잘 정의 된 제약 조건을 제공 할 것입니다. 이 경우 우리는 거의 최종 솔루션을 제공하고 있습니다. 당연히 당신의 의견은이 상황에서 결정적이므로, 당신은 또한이 아이디어들을 분석 한 다음 최종 단계를 취할 수 있도록 당신의 결론을 알려야합니다.

실현 가능한 2 차 전진

불행히도, 통신은 몇 주 전에 멈췄습니다. 당신이 반드시 충족시켜야 할 업무 약속 때문에 완전히 합리적인 것 같습니다. 보다 안정적이고 강력한 모델을 개발했다면 훨씬 더 만족 스러웠지만 이전의 상호 작용으로 인해 올바른 방향으로 당신을 가리킬 수 있다고 가정 할 수 있습니다.

이 질문과 답변 프로세스에서 이미 제시된 것 외에도 이전 데이터 모델에서 새로운 진행을 제공하는 것이 비슷한 문제를 가진 다른 구직자에게 도움이 될 수 있다고 생각합니다. 그래서 나는…

조직 및 프로필 예비 데이터 모델-2 차 사전

이러한 데이터 모델에서 볼 수 있듯이, 나는 제거한 대다 나는 사이의 이전 모델에 묘사 된 것을 관계 Profile와 Address주어진이 있기 때문에, Profile이미 관련이 일대 Addresses 의 소유를 통해를 Locations.

이 새로운 발전에서 보여지는 또 다른 변화는 이제 주어진 것을 일대 다Location 소유 할 수있는 가능성을 포함한다는 사실입니다 . 따라서, I는 변경 합니다 (닫아 PRIMARY KEY를 (연관 엔티티 첨가 한 다음 속성) 및 대다 관한) 과이 . ProfilesLocationLocationOwnerProfileIdProfileLocation

노트

_{1. IDEF1X 는 1993 년 12 월 미국 표준 기술 연구소 ( NIST ) 에서 표준 으로 정의한 권장 데이터 모델링 기술입니다 .}

_{이것은 (슈퍼) 타입 서브 타입 클러스터의 발생 이다. 관심이 있으시다면, 여기 에 이런 종류의 관계를보다 자세하게 다루는 대답 이 있습니다.}

_{3. 다 대다 계층 관계 의 예이며 , “부품 탐색 문제”에 대한 명확한 해결책을 제공 한 구조와 매우 유사합니다 . 물론 이러한 솔루션은 1970 년 에드거 프랭크 코드 (Edgar Frank Codd) 박사에 의해 “대규모 공유 데이터 뱅크를위한 데이터의 관계형 모델”이라는 엄청난 영향력있는 논문에서 소개되었습니다 .}

_{4. 이것은 일대 다 (또는 다 대일) 계층 관계 의 사례이다 .}

객체 모델링의 개념과 데이터 모델링의 개념을 문제에 대한 자신의 이해를 명확하게하는 데 도움이되지 않는 방식으로 혼합하려고한다고 생각합니다. 나는 너무 많은 짓 bling 지 않고 약간 혼란을 정리할 수 있기를 바랍니다.

관계형 모델은 상속을 지원하지 않으며 다형성을 신경 쓰지 않습니다. 이는 객체 모델에서 상속과 다형성으로 쉽게 처리되는 실제 상황을 모델링 할 때 다소 전문화 된 디자인 패턴을 사용해야 함을 의미합니다. 그 특별한 디자인 패턴에 대해서는 나중에 더 설명하겠습니다.

ER 모델이 처음 개발되었을 때 관계형 모델링에 대한 구현 불가지론 적 대안이되어야했습니다. 처음에는 상속과 같은 것도 없었습니다. 그러나 1980 년대 나 1990 년대에이 모델은 상속을받을 때와 동일한 표현 기능을 제공하도록 확장되었습니다. 이것은 "확장 된 ER 모델"로 알려져 있지만 모든 실제적인 목적을 위해 오늘날의 ER 모델에는 EER 기능이 포함되어 있습니다.

하나의 EER 기능은 "일반화 / 전문화"라는 이름으로 사용됩니다. 웹에서이 개념을 검색하고 읽을 수 있습니다. Gen-spec은 클래스와 서브 클래스가 객체 모델에서 제공하는 것과 거의 동일한 표현 기능을 제공합니다. 그러나 Gen-spec은 gen-spec 상황에 대한 관계형 테이블 디자인과 관련된 문제를 다루지 않습니다. 나중에 더 자세히.

ER 모델링에서 관계는 항상 동일한 엔티티를 포함합니다. 따라서 조직과 프로필 간의 친구 관계는 프로필과 다른 프로필 간의 친구 관계와 동일하지 않습니다. 두 관계에는 다른 이름이 필요합니다. 이 규칙을 따르지 않으면 자신을 매듭으로 묶을 수 있습니다.

그 중 하나이거나 조직, 프로필 및 위치가 모두 전문화되어있는 일반화 된 엔터티를 만들어야합니다. 귀하의 사례를 충분히 이해하지 못해 도움이 될 것입니다.

계속해서 관계형 모델과 ER 모델을 단일 모델로 결합하고 있음을 알았습니다. 가장 노련한 데이터베이스 설계자가이 작업을 수행합니다. 그러나 숙달 될 때까지 두 모델을 서로 분리하여 유지하는 것이 좋습니다.

마지막으로 gen-spec 상황을 나타내는 관계형 테이블을 어떻게 설계합니까? 이 두 가지 디자인 패턴 "클래스 테이블 상속"및 "단일 테이블 상속"을 찾아보십시오. Stackoverflow에는 두 개의 태그가 있습니다. 웹상에서 패턴에 대한 훌륭한 프레젠테이션도 있습니다. 나는 특히 Martin Fowler의 치료를 좋아합니다. 그는 객체 모델러가 어떻게 생각하는지 알고있는 것 같습니다. 도움이 되었기를 바랍니다.