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

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

귀하의 사양을 제대로 이해하지 못하도록 귀하의 질문을 읽고 다이어그램을 면밀히 검토 한 후 가정 한 비즈니스 규칙 목록을 정의했습니다. 이러한 목록을 정의한 후 외부 플랫폼 (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. 이것은 일대 다 (또는 다 대일) 계층 관계 의 사례이다 .}

---

답변