ฉันกำลังสร้างไดอะแกรมเชิงแนวคิด [ใช่ฉันรู้ว่าฉันได้รวมคุณลักษณะและปุ่ม - แต่นี่เป็นเพียงสำหรับฉันที่จะรวมสิ่งที่ฉันทำในขณะที่เรียนรู้] - ดังนั้นโปรดรักษามันเป็นแนวคิดด้วยการมุ่งเน้นที่ความสัมพันธ์และ ตารางและไม่ใช่วิธีไดอะแกรม;)

สิ่งกีดขวางในใจของฉันคือ: ฉันพยายามที่จะหาวิธีที่ดีที่สุดในการสร้างแบบจำลองความสัมพันธ์ส่วนตัวที่ตั้งและองค์กร

ก่อนอื่นกฎ:

• หนึ่งหรือมากกว่าส่วนตัว 's สามารถเป็นสมาชิก / เพื่อนของหนึ่งหรือมากกว่าองค์กร ; และในทางกลับกัน.
• โปรไฟล์อย่างน้อยหนึ่งรายการสามารถเป็นสมาชิก / เพื่อนของโปรไฟล์อื่น ๆ
• องค์กรอย่างน้อยหนึ่งแห่งสามารถเป็นสมาชิก / เพื่อนขององค์กรอื่น ๆ ได้

เพื่อนและสมาชิกแตกต่างกันในการที่เพื่อนเป็นแบบอ่านอย่างเดียวและสมาชิก [ขึ้นอยู่กับระดับ] สามารถเข้าถึงสิ่งที่แก้ไขได้อย่างเต็มที่

เพื่อให้สิ่งต่าง ๆ ซับซ้อนขึ้นสถานที่ตั้งมีกฎการรีฟิล "เพิ่มเติม" ของตนเองเช่นองค์กรที่เป็นเจ้าของสองสถานที่แต่ขึ้นอยู่กับกฎที่ตั้งสมาชิก [ โปรไฟล์ ] ขององค์กรนั้นอาจเข้าถึงได้อย่างเต็มที่ในที่เดียว แต่ จำกัด การเข้าถึงที่ อื่น ๆ [ขออภัย: คุณมักจะต้องเปิดภาพในหน้าต่างอื่นเพื่อดูขนาดที่ดีขึ้น]

ดังนั้นอย่างที่คุณเห็นแนวคิดของโปรไฟล์และองค์กรนั้นเหมือนกันเช่นเดียวกับแนวคิดที่ยังไม่ได้เป็นแบบอย่างของเพื่อนและสมาชิก [... ซึ่งฉันคิดว่าจะได้รับการจัดการเหมือนตารางตัวกลางปัจจุบันที่มีการตั้งค่าเจ้าของ / ผู้ดูแลระบบ / สมาชิก / เพื่อน ฯลฯ ในบันทึก] ดังนั้นทำไมฉันจึงคิดถึงแนวคิดต่อไปนี้:

ดูOption.2 ในภาพด้านบน:ซึ่งจะลบปัจจุบันองค์การและOrganization_Locationsตารางและความสัมพันธ์ของพวกเขาแทนที่ด้วยตารางองค์การ Option.2 เป็นความสัมพันธ์ที่ค่อนข้างเรียกซ้ำกับข้อมูลส่วนตัว

ฉันคิดว่าปมของเรื่องคือหรือไม่ฉันกำลังใจเกินไปโดยทางโปรแกรมกับความแตกต่างเพื่อความเสียหายของความเรียบง่ายและความยืดหยุ่นทำให้สับสนตัวเองอย่างสิ้นเชิงในกระบวนการ;)

ขอบคุณสำหรับความคิดของคุณล่วงหน้าชื่นชมมาก - M :)

แผนภาพที่แก้ไข:

เพื่อตอบคำถามของ MDCCL:

1. ใช่โปรไฟล์ถูกสร้างขึ้นจากคนคนหนึ่งและมีความหมายเหมือนกัน - แต่ที่เหตุผลของคุณเป็นหัวหน้า - ผมเชื่อว่าคุณถูกต้องกำลัง: องค์กรและบุคคลที่อาจจะเป็นชนิดย่อยของรายละเอียด ; ดังนั้นโปรไฟล์ถูกสร้างขึ้นจากหนึ่งคนหรือหนึ่งองค์กร
2. ที่อยู่อีเมลหนึ่งรายการต่อหนึ่งโปรไฟล์
3. ใช่. ข้างต้นองค์กรอย่างน้อยควรมีที่อยู่อีเมล
4. ถูกต้องหนึ่งที่อยู่คงที่
5. มันเป็นไปได้ แต่เป็นสิ่งที่หายาก - แม้ว่าจากสิ่งที่ฉันเรียนรู้ - ดังนั้นเราควรเป็นแบบอย่างสำหรับการมีอายุยืนยาวในอนาคต ฯลฯ และเพื่อยืนยันสถานที่ตั้งจึงสามารถเป็นเจ้าของได้มากกว่าหนึ่งคน

6. สถานที่ตั้งนั้นเป็นเอนทิตีที่สำคัญระหว่างที่อื่น ๆ บางทีฉันอาจจะชี้แจงสิ่งที่สามารถทำได้อย่างกระชับที่นี่จากนั้นให้คุณอ่านแม้ว่าคำตอบอื่น ๆ ของฉันซึ่งหวังว่าจะได้รับการเพิ่มเติมที่เป็นประโยชน์ต่อคำถามนี้ก่อน [ จากนั้นดูคำตอบของฉันในตอนท้าย # 6 ];) Re: เจ้าของบทบาท An **Organization** can be an Owner of zero or more **Locations**. A Person can be an owner of zero of more Locations[ดังนั้นตามที่คุณคาดการณ์ไว้ก่อนหน้านี้; ใส่เพียงโปรไฟล์สามารถเป็นเจ้าของศูนย์หรือมากกว่านั้น

7. ใช่ข้อมูลส่วนตัวที่เป็นเจ้าของของสถานที่ตั้งถือว่าทุกบทบาทสิทธิ์ [ผู้ใช้ super]; ข้อมูลส่วนตัวที่เป็นผู้ดูแลระบบสามารถแก้ไขรายละเอียดบางอย่างของที่อยู่แต่ส่วนใหญ่จะช่วยให้ / แก้ไขรายละเอียด / ข้อมูลที่จัดทำผ่านทางอื่น ๆ ทั้งหมดโปรไฟล์ / s - นี้จะเป็นหลักที่จัดทำโดย'Basic สมาชิก / s'กล่าวว่าสถานที่ตั้ง / s; ซึ่งใบพื่นฐานสมาชิกที่สามารถอ่านได้อย่างเดียวที่เกี่ยวข้องทั้งหมดที่ตั้งรายละเอียดและข้อมูลของอุปทานที่จะต้องตรวจสภาพโดยผู้ดูแลระบบ / เจ้าของ นอกเหนือจากนี้โปรไฟล์ใด ๆ[องค์กร / คน] เป็นเหมือนสมาชิกพื้นฐาน 'อ่านอย่างเดียว' - ลองเรียกพวกเขาว่าแขก - แต่ถ้าตั้งเป็นสาธารณะ [และไม่ใช่ส่วนตัว ] แม้ว่าพวกเขาจะไม่สามารถป้อนข้อมูลเหมือนสมาชิกพื้นฐานสามารถ .

8. แก้ไข.
9. สัญชาตญาณของคุณยอดเยี่ยมมาก! ใช่it is foreseen that a single Location could contain one to many LocationTypes- เพื่อทำให้สิ่งต่าง ๆ มีความซับซ้อนยิ่งขึ้น - คาดว่า LocationTypes เหล่านั้นแต่ละรายการอาจมีการอนุญาตที่แตกต่างกันสำหรับ Profiles ที่เชื่อมโยงกับตำแหน่ง 'Parent' ซึ่งการอนุญาตจะกรองจาก Location ไปยัง LocationType / s [เหมือนกับสิทธิ์การรักษาความปลอดภัยโฟลเดอร์ OS] ฉันทราบผ่านแผนภาพของคุณคุณอาจจะหมายถึงพิมพ์คำอธิบายเพิ่มเติม?
10. ใช่.
11. ดู 12
12. ถูกต้องความสามารถสำหรับProfile1 [บุคคลหรือองค์กร] เพื่อดำเนินการตามProfile2 [บุคคลหรือองค์กร] เป็นเจ้าของสถานที่ [ถ้าเป็นเพื่อน / สมาชิกที่มีสิทธิ์ที่ถูกต้อง] เป็นสิ่งสำคัญยิ่ง
13. สมเหตุสมผลมาก - a)เห็นด้วย b)เห็นด้วย c)ใช่อืม ... บางทีมันควรจะเป็นมากเช่นเดียวกับรายละเอียด [คน] เพื่อข้อมูลส่วนตัว [คน] = เพื่อน ไม่ว่าคำอธิบายก็จะหมุนไปรอบ ๆสถานที่ตั้งเป็นองค์การ / s จะกระทำการอื่น ๆองค์การ สถานที่ตั้ง / s; แม้ว่าจะมีความหมายฉันสงสัยว่าองค์กรใดจะต้องการให้ปรากฏเป็น "สมาชิก" ขององค์กรที่อยู่ในตำแหน่งนั้นเพื่อให้สามารถทำได้'ไม่ว่าจะเป็นสาเหตุที่ดีเพียงใดก็ตาม'

[6] นี่ยังเป็นสีเทาสำหรับฉัน แต่ที่นี่ไป ... เพื่อความเสียหายของฉันความคล้ายคลึงระหว่างสมาชิก / เพื่อนสนิทนั้นใกล้เคียงกันมากจนฉันคิดว่าจะรวมมันเข้าด้วยกัน ในความเข้าใจย้อนหลังกับแผนภาพและการตีความของคุณดูเหมือนว่าคุณอาจมีสิทธิ์ที่จะแยกพวกเขา [ ฉันจะแยกความสัมพันธ์เดี่ยวผ่านคุณสมบัติ enum: เจ้าของ / ผู้ดูแลระบบ / สมาชิก / เพื่อน ] แนวคิดของคุณเช่น: สถานที่ที่เป็นขององค์กรจะมีการดำเนินการกับโปรไฟล์ [บุคคลหรือองค์กร] เป็นศูนย์แม้ว่าจะมีความแตกต่างที่ชัดเจนระหว่างวิธีที่โปรไฟล์ดำเนินการกับตำแหน่งผ่านความสัมพันธ์ [สมาชิกหรือเพื่อน ] เขียนแทนผ่านบทบาท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.

เป็นเรื่องที่ดีมากที่คุณสละเวลาในการทำความเข้าใจจัดประเภทและสร้างแบบจำลองข้อมูลที่คุณติดต่อด้วยนับตั้งแต่ประสบการณ์ส่วนตัวของฉันทั้งหมดนี้ทำให้กระบวนการพัฒนาทั้งหมดง่ายขึ้นและยืดหยุ่นมากสำหรับการเปลี่ยนแปลงในอนาคต และฉันค่อนข้างแน่ใจว่าคุณก็รู้เรื่องนี้อยู่แล้ว

แบบจำลองข้อมูลเบื้องต้นและกฎเกณฑ์ทางธุรกิจที่สมมติขึ้น

ฉันกำหนดรายการของกฎเกณฑ์ทางธุรกิจที่ฉันได้สันนิษฐานไว้หลังจากอ่านคำถามของคุณและตรวจสอบไดอะแกรมของคุณอย่างใกล้ชิดเพื่ออธิบายการทำความเข้าใจข้อกำหนดของคุณ หลังจากกำหนดรายการดังกล่าวฉันได้รับแบบจำลองข้อมูลIDEF1X ^[1]ที่ฉันตัดสินใจอัปโหลดเป็นเอกสาร. PDF ในแพลตฟอร์มภายนอก (Dropbox) เนื่องจากรูปแบบของรูปแบบข้อมูลนี้ไม่เหมาะกับภาพที่ฝังอยู่ สองคนนี้เป็นเครื่องมือที่จะไปเป็นประโยชน์เป็นข้อมูลอ้างอิงสำหรับจุดสำคัญบางอย่างที่ผมระบุด้านล่างในส่วนสิทธิด้านการแก้ปัญหาเพื่อให้ก้าวไปข้างหน้า

ก่อนอื่นนี่คือ ...

• องค์กรและโปรไฟล์เบื้องต้นรูปแบบข้อมูล

เนื่องจากเป็นเพียงแค่นั้นเบื้องต้นให้ถือว่าเป็นวิธีการที่ช่วยให้เราเข้าใจรูปแบบข้อมูลขั้นสุดท้ายที่ต้องการ

กฎเกณฑ์ทางธุรกิจที่สันนิษฐาน

แบบจำลองข้อมูลเบื้องต้นดังกล่าวมาจากการรวบรวมกฎเกณฑ์ทางธุรกิจ (อนุมานจากคำถามของคุณ) ที่ฉันจะแจกแจงดังนี้:

องค์กรและโปรไฟล์

หมายเหตุที่เป็นที่เข้าใจในปัจจุบันเป็นคำพ้องความหมายสำหรับProfilePerson

• Organizationคือเพื่อนของหนึ่งต่อหลายคน Profiles
• Organizationคือเพื่อนของหนึ่งต่อหลายคน Organizations
• Organizationเป็นสมาชิกของหนึ่งต่อหลายคน Organizations
• Profileเป็นสมาชิกของหนึ่งต่อหลายคนOrganizations
• Profileคือเพื่อนของหนึ่งต่อหลายคน Profiles
• Profileเป็นสมาชิกของหนึ่งต่อหลายคน Profiles

สถานที่และที่อยู่

• Organizationเป็นเจ้าของหนึ่งต่อหลายคน Locations
• A Locationถูกจัดประเภทโดยหนึ่งต่อหลาย LocationTypes ( หนึ่งจุด ณ เวลาที่กำหนด)
• Locationอาจจะมีหนึ่งต่อหลายคน Addresses ( หนึ่ง Physical , หนึ่งสำหรับShipping, หนึ่งสำหรับBilling, หรือหนึ่งที่ทำหน้าที่ทุกวัตถุประสงค์กล่าวหรือหนึ่งที่รวมสองวัตถุประสงค์และอื่นที่ทำหน้าที่เพียงคนเดียวของพวกเขา)

• Addressอาจถูกเก็บไว้โดยหนึ่งต่อหลายคน Profilesหรือใส่อีกวิธีหนึ่งที่Profileช่วยให้หนึ่งต่อหลายคน Addresses

• ที่เฉพาะเจาะจงAddressอาจถูกใช้โดยหนึ่งต่อหลายคน Profiles (ที่ทำหน้าที่เป็นPhysicalสำหรับหนึ่ง Profileถูกนำมาใช้สำหรับการBillingโดยที่แตกต่างกันอย่างใดอย่างหนึ่งฯลฯ ) ดังนั้นการAddressทำงานในลักษณะที่คล้ายกันสำหรับการและLocationsProfiles

  • ดังนั้นบุคคลที่Addressอาจจะเป็นในเวลาเดียวกัน , ประเภทPhysical, และShipping Billing

สถานที่และบทบาท

• Locationเปิดอย่างใดอย่างหนึ่งต่อหลายคน Roles
• Roleอาจจะดำเนินการในแบบหนึ่งต่อหลายคน Locations
• A Profile(เมื่อมีการตั้งค่าเป็นMemberของOrganization) อาจดำเนินการแบบหนึ่งต่อหลาย Rolesในหนึ่งต่อหลาย Locations (แต่เพียงหนึ่งเฉพาะRoleในแต่ละLocationจุด ณ เวลาหนึ่งกล่าวคือไม่เคยสองคนหรือมากกว่า Rolesในเวลาเดียวกัน )

ด้านการแก้ไขเพื่อให้ก้าวไปข้างหน้า

เพื่อที่จะก้าวต่อไปในการแก้ปัญหาของรูปแบบข้อมูลของคุณนี่คือรายการของจุดที่เกี่ยวข้องที่เมื่อเราทำงานออกมาจะช่วยให้เราบรรลุเป้าหมายนี้:

1. ฉันสันนิษฐานว่าคำProfileในบริบทของคุณมีความหมายคล้ายกัน (หรือเหมือนกัน) เหมือนกันPersonแต่อาจแตกต่างกันเล็กน้อย ด้วยวิธีนี้คุณจะบอกว่าในสถานการณ์สมมติของคุณเอนทิตีOrganizationและPersonเป็นชนิดย่อยของProfile?

2. ที่สามารถProfile(หรือPerson) ของตัวเองหนึ่งไปยังหลาย EmailAddresses , หรือเป็นProfile(หรือPerson) จับจ้องไปตรงหนึ่ง EmailAddress ?

3. คุณต้องการที่จะให้ความเป็นไปได้สำหรับการOrganizationได้รับการติดต่อผ่านทางTelephoneและEmail, หรือคุณต้องการ จำกัด ว่าจะเป็นไปได้เพียงProfile(หรือPerson)?

4. ฉันคิดว่า a Locationได้รับการแก้ไขให้เป็น Addressประเภทใดประเภทหนึ่งPhysicalถูกต้องหรือไม่

5. เป็นไปได้หรือไม่ที่ a Locationจะแบ่งปันโดยหนึ่งต่อหลายคนที่แตกต่างกันOrganizations หรือมิฉะนั้น a Locationสามารถเป็นของเพียงคนเดียวได้ Organizationหรือไม่?

6. คุณได้ระบุผ่านความคิดเห็นว่าข้อเท็จจริงของการเป็นMemberและFriendเป็นเหมือนกัน อย่างที่คุณเห็นในรูปแบบข้อมูลเบื้องต้นที่เสนอของฉันฉันทำตามข้อกำหนดดั้งเดิมและบรรยายถึงความเป็นไปได้ทั้งหมดของการเป็นสมาชิกและมิตรภาพระหว่างOrganizationและProfile(หรือPerson) ในหน่วยงานที่แตกต่างกันเนื่องจากฉันคิดว่ามันมีประโยชน์ในความพยายาม โครงสร้างของส่วนนั้นของคุณ ในแง่นี้

   • ผมคิดว่าคำสั่งan Organization is a Member of another Organizationมีผลแตกต่างจากคำสั่งที่นับถือนิติบุคคลที่เรียกว่าa Profile (or Person) is a Member of an OrganizationLocation
   • ที่คุณสามารถดูในรูปแบบข้อมูลที่ผมคิดว่าRoleของOwnerจะใช้ได้เฉพาะสำหรับOrganizationและให้ฉันถูกต้องRolesสำหรับProfile(หรือPerson) ภายในLocationมีและAdmin Memberคุณคิดยังไงกับเรื่องทั้งหมดนี้? เนื่องจากคุณอยู่ในการติดต่อโดยตรงกับกฎเกณฑ์ทางธุรกิจที่ใช้กับสถานการณ์ของคุณคุณต้องบอกฉันว่าสมมติฐานของฉันถูกต้องหรือไม่

7. สามารถProfile(หรือPerson) เล่นแตกต่างกันRolesภายในเดียวกันได้Locationหรือไม่ คือสามารถPersonในเวลาเดียวกันAdminและยังเป็นMemberของเดียวกันได้Locationหรือไม่ กฎอะไรในเรื่องนี้?

8. ผมคิดว่าเหมือนกันProfile(หรือPerson) สามารถเล่นที่แตกต่างกันในการที่แตกต่างกันRoles Locationsตัวอย่างเช่น: Profile(หรือPerson) เฉพาะคือ“ ผู้ดูแลระบบ” ในLocation“ 1” และที่เหมือนกันนี้Profile(หรือPerson) คือ“ Member” ในLocation“ 2” ในเวลาเดียวกัน ฉันถูกไหม?

9. มันเป็นไปได้สำหรับโดยเฉพาะอย่างยิ่งLocationที่จะมีที่แตกต่างกันLocationTypesในเวลาเดียวกันหรือบุคคลที่Locationได้รับการแก้ไขที่จะถือว่าหนึ่งLocationType?

10. คุณลักษณะนี้Organization.Websiteแสดงถึงที่อยู่เว็บไซต์ขององค์กรหนึ่ง ๆ เช่น“ dba.stackexchange.com” หรือไม่

11. หากProfile“ 1” (เข้าใจแล้วPerson) เป็นMember(หรือFriend) ของProfile“ 2” เป็นไปได้หรือไม่ที่Profile“ 1” จะสามารถดำเนินการRoleใน“ 2” ที่Locationเป็นเจ้าของได้Profileหรือไม่? ฉันคิดว่าสถานการณ์ดังกล่าวใช้ได้กับความสัมพันธ์ระหว่างOrganizationและMember Personคุณคิดว่าอย่างไร

12. ในทำนองเดียวกันหากOrganization“ 1” เป็นMember(หรือFriend) ของOrganization“ 2” เป็นไปได้หรือไม่ที่Organization“ 1” จะสามารถดำเนินการRoleใน“ 2” ที่Locationเป็นเจ้าของได้Organizationหรือไม่? อีกครั้งฉันคิดว่าสถานการณ์ประเภทนี้ใช้ได้เฉพาะกับความสัมพันธ์ระหว่างOrganizationa และ a Member Personเท่านั้นถูกต้องหรือไม่

13. ในเรื่องนี้ - ในขณะที่ฉันกำลังเขียนคำถามนี้ - ฉันคิดว่ามันสมเหตุสมผลที่จะพูดว่ามีความสัมพันธ์ที่แตกต่างกันสามประเภทที่เกี่ยวข้องOrganizationsและPersonsและเราสามารถกำหนด:

    • (a) ความสัมพันธ์ระหว่างOrganizationและPersonกับ " Membership"
    • (b) ความสัมพันธ์ระหว่าง a Personและอีกอย่างแตกต่างกันPersonเป็น“ Friendhip”
    • (ค) เรายังไม่พบว่ามีความหมายชื่อเพื่ออธิบายความสัมพันธ์ระหว่างบุคคลและที่แตกต่างกันอีกOrganizationOrganization
    • ดังนั้นให้ฉันรู้ว่าคุณคิดอย่างไรเกี่ยวกับ (a) (b) และ (c)

14. มันเป็นไปได้สำหรับOrganizationที่จะเป็นFriend(หรือMember) ของหนึ่งต่อหลายคนที่แตกต่างกันOrganizationsในเวลาเดียวกันได้หรือไม่ หรือเป็นไปได้เพียงที่Organizationจะมีความสัมพันธ์กับคนละคนเท่านั้นOrganization?

แบบจำลองข้อมูลต่อเนื่องแสดงให้เห็นถึงความก้าวหน้าครั้งแรก

ด้วยความใส่ใจในการตอบสนองและการแก้ปัญหาของคุณต่อประเด็นที่ค้างอยู่ที่ฉันได้กล่าวไว้ข้างต้นฉันได้สร้างสิ่งต่อไปนี้ ...

• องค์กรและโปรไฟล์เบื้องต้นข้อมูลรุ่นแรก - แอ็ดวานซ์

แม้ว่าฉันจะรู้สึกไม่สบายใจกับมัน แต่รูปแบบข้อมูลใหม่นี้แสดงกฎทางธุรกิจต่อไปนี้:

• Profileเป็นอย่างใดอย่างหนึ่งOrganization หรือ ^[2]Person
• Profileอาจจะเป็นเพื่อนที่เสนอขายแบบหนึ่งต่อหลายคน FriendProfilesและProfileอาจจะเป็นเพื่อนที่ยอมรับของหนึ่งต่อหลายคน ^[3]FriendProfiles
• Locationอาจประกอบด้วยหนึ่งต่อหลายคน ^[4]Locations

คำตอบสำหรับความคิดเห็นเฉพาะที่ตามมาของคุณ

มันน่าสนใจมากสำหรับฉันที่จะจดบันทึก / รวมการแยกข้อกังวล [เช่น LocationAddress และ ProfileAddress] - เพราะฉันต้องการเร่งรีบและจับพวกมันทั้งหมดโดยไม่มีความสัมพันธ์ที่ถูกต้อง [ตลกมันไม่รู้สึกผิดกับ ERD ดั้งเดิมของฉัน]

ใช่นั่นคือการเปรียบเทียบที่ดีแม้ว่าฉันจะไม่เรียกมันว่าเป็นการแยกข้อกังวล (ซึ่งก็คือหลักการพื้นฐานในการเขียนโปรแกรมและการออกแบบแอปพลิเคชัน) เนื่องจากคำนี้มักเกี่ยวข้องกับขั้นตอนการพัฒนาแอปพลิเคชัน ขั้นตอนของการทำความเข้าใจข้อมูลและออกแบบโครงสร้างเชิงตรรกะ

จากประสบการณ์ส่วนตัวของฉันฉันคิดว่าระยะนี้เกี่ยวข้องกับการใส่สิ่งสำคัญลงในบริบททั้งหมดของพวกเขามันเกี่ยวข้องกับการเห็นความสัมพันธ์ที่มีอยู่ระหว่างหน่วยงานต่าง ๆ ที่เกี่ยวข้องในสถานการณ์เฉพาะที่น่าสนใจแล้ว แสดงสิ่งเหล่านี้ในแบบจำลองข้อมูล ในกรณีที่เฉพาะเจาะจงที่คุณแสดงความคิดเห็นเกี่ยวกับการที่Addressนิติบุคคลที่อาจมีความแตกต่างกันของการเชื่อมต่อกับหน่วยงานอื่น ๆ หนึ่งด้วยและหนึ่งที่แตกต่างกันด้วยProfileLocation

และใช่เมื่อบางสิ่งไม่ถูกต้องหรือเป็นธรรมชาติมันอาจเป็นสัญญาณว่าเราจำเป็นต้องใช้ความพยายามมากขึ้นเพื่อที่จะเข้าใจข้อมูลที่เกี่ยวข้อง ในลักษณะนี้Addressกิจการเป็นหนึ่งในสิ่งที่ฉันพิจารณาว่าต้องการความสนใจมากขึ้นเนื่องจากฉันคิดว่าความสัมพันธ์ระหว่าง a Profileและa Address สามารถจัดการได้ด้วยวิธีของLocationกิจการ (เนื่องจากข้อเท็จจริงที่ว่าทุกคนLocationต้องมีอย่างน้อยหนึ่งร่างกายAddress) ดังนั้นเราสามารถยกเลิกการProfileAddressเชื่อมโยงเอนทิตีที่ปรากฎในรุ่นล่าสุด แต่คุณควรวิเคราะห์ประเด็นเหล่านี้และแจ้งให้เราทราบความคิดของคุณ

นอกจากนี้ยังเป็นเรื่องธรรมดาใน IDEF1X ที่จะเปลี่ยนการบอกเลิก PK / FK ในเอนทิตีเพื่อให้อ่านง่ายขึ้น [เช่น ProfileId - LocationOwnerProfileId]

ใช่นั่นเป็นคำพูดที่ฉลาดมากจากคุณเนื่องจาก IDEF1X แนะนำให้ใช้ชื่อบทบาทสำหรับการระบุคีย์ต่างประเทศเพื่อรวบรวมความหมายของแอตทริบิวต์ดังกล่าวตามเอนทิตีที่ใช้งานอยู่ นอกจากนี้ยังเป็นที่น่าสังเกตว่าเรื่องนี้ก็เป็นเรื่องที่เกี่ยวข้องอย่างยิ่งกับแนวคิดของการโยกย้ายคีย์หลัก ตามความเป็นจริงการใช้ชื่อบทบาทนำหน้า IDEF1X เนื่องจากเป็นการนำเสนอโดยดร. EF Codd ในข้อความน้ำเชื้อปี 1970 ของเขา ในลักษณะนี้อย่างใดอย่างหนึ่งสามารถเห็นได้ชัดเจนความจงรักภักดีที่มาตรฐาน IDEF1X ช่วยให้ต่อแบบเชิงสัมพันธ์

ฉันสนใจที่จะเรียนรู้สิ่งที่คุณไม่ชอบโดยเฉพาะ / รู้สึกว่าไม่ได้เป็นแบบอย่างด้วย / ในการแก้ปัญหา?

นอกจากนี้รายละเอียดที่อธิบายไว้แล้วข้างต้นเกี่ยวกับAddressนิติบุคคลผมไม่แน่ใจว่าถ้าRolesดำเนินการโดยได้รับProfileในโดยเฉพาะอย่างยิ่งLocationจะเทียบเท่าการหรือOrganization PersonจากมุมมองของฉันPersonต้องมีการเชื่อมโยงกับสิ่งOrganizationแรกสิ่งนี้Organizationจะบอกว่าPersonให้ทำRoleสิ่งใดสิ่งหนึ่งโดยเฉพาะLocationแต่คุณรู้สถานการณ์ดีขึ้นดังนั้นกฎนี้อาจไม่จำเป็น ในเรื่องนี้ผมจะยืนยันเกี่ยวกับความจริงที่ว่ามันจะเป็นประโยชน์มากสำหรับผมที่จะรู้ว่าคำอธิบายบริบทหรือความหมายว่าผู้ใช้ในอนาคตนี้ให้โครงสร้างข้อมูลOrganization, ProfileและLocationแต่ฉันเข้าใจว่านี่อาจเป็นข้อมูลที่เป็นความลับดังนั้นนี่จึงเป็นข้อ จำกัด

ด้วยโครงสร้างปัจจุบันดูเหมือนว่าทุกคน ( OrganizationหรือPerson) สามารถเชื่อมโยงกับทุกคน (อีกครั้งOrganizationหรือPerson) และสามารถ / ทำอะไรก็ได้ ( Role) ที่ใดก็ได้ ( Location) แต่สำหรับ perharps นี่เป็นสิ่งที่คุณและผู้ใช้คาดหวังจากฐานข้อมูลนี้ ซึ่งแน่นอนว่าคุณจะมีข้อ จำกัด ที่ชัดเจน หากเป็นกรณีนี้เราเกือบจะให้ทางออกสุดท้าย เนื่องจากโดยปกติแล้วความคิดเห็นของคุณจะแตกหักในสถานการณ์นี้คุณควรวิเคราะห์ความคิดนี้แล้วแจ้งให้เราทราบข้อสรุปของคุณเพื่อให้เราสามารถทำตามขั้นตอนสุดท้ายได้

ความก้าวหน้าที่สองเป็นไปได้

น่าเสียดายที่การหยุดสื่อสารไม่กี่สัปดาห์ที่ผ่านมาฉันเดาว่าเนื่องจากข้อผูกพันในงานที่คุณต้องปฏิบัติ ฉันจะได้รับเนื้อหามากขึ้นถ้าเราพัฒนาแบบจำลองที่มีเสถียรภาพและมีเสถียรภาพมากขึ้น แต่เนื่องจากการโต้ตอบก่อนหน้าของเราฉันสามารถสรุปได้ว่าฉันสามารถชี้คุณไปในทิศทางที่ถูกต้อง

นอกจากสิ่งที่นำเสนอในคำถามและคำตอบนี้แล้วฉันคิดว่าการให้ความก้าวหน้าใหม่จากตัวแบบข้อมูลก่อนหน้านี้อาจเป็นประโยชน์สำหรับผู้ค้นหารายอื่นที่มีปัญหาคล้ายกัน ดังนั้นฉันได้สร้าง ...

องค์กรและโปรไฟล์แบบจำลองข้อมูลเบื้องต้น - ขั้นสูงที่สอง

ดังที่เห็นได้ในตัวแบบข้อมูลดังกล่าวฉันได้ลบความสัมพันธ์แบบหลายต่อหลายอย่างที่ฉันได้อธิบายไว้ในตัวแบบก่อนหน้าระหว่างProfileและAddressเนื่องจากสิ่งที่ได้รับProfileนั้นสัมพันธ์กับแบบตัวต่อตัว Addressesผ่านเจ้าของLocationsแล้ว

การเปลี่ยนแปลงที่จะมีภาพประกอบล่วงหน้าใหม่นี้ก็คือความจริงที่ว่ามันในขณะนี้มีความเป็นไปได้ที่ที่กำหนดLocationสามารถเป็นเจ้าของโดยหนึ่งต่อหลายคน Profilesดังนั้นฉันได้เปลี่ยนLocationคีย์หลัก (โดยไล่LocationOwnerProfileIdแอตทริบิวต์) แล้วเพิ่มการเชื่อมโยงนิติบุคคล ( หลายต่อหลายคน ) ที่เกี่ยวข้องกับProfileLocation

หมายเหตุ

_{1. IDEF1Xเป็นเทคนิคการสร้างแบบจำลองข้อมูลที่ขอแนะนำอย่างยิ่งซึ่งถูกกำหนดให้เป็นมาตรฐานในเดือนธันวาคม 1993 โดยสถาบันมาตรฐานและเทคโนโลยีแห่งชาติของสหรัฐอเมริกา ( NIST )}

_{2. นี้เป็น ocurrence ของ(Super) คลัสเตอร์ประเภทย่อย ในกรณีที่คุณมีความสนใจนี่คือคำตอบที่ฉันจัดการอย่างละเอียดมากขึ้นกับความสัมพันธ์แบบนี้}

_{3. ตัวอย่างของความสัมพันธ์แบบลำดับชั้นหลายต่อหลายคนและเป็น simliar มากกับโครงสร้างที่ให้แก้แตกหักกับ“อะไหล่ Explotion ปัญหา” วิธีการแก้ปัญหาดังกล่าวเป็นของหลักสูตรที่นำโดยดร. เอ็ดการ์แฟรงก์ Coddในปี 1970 กระดาษที่มีอิทธิพลอย่างมากของเขา“เป็นความสัมพันธ์รูปแบบของข้อมูลขนาดใหญ่ที่ใช้ร่วมกันข้อมูลธนาคาร”}

_{4. ในฐานะที่เป็นเช่นนี้เป็นตัวอย่างของหนึ่งต่อหลายคน (หรือหลายต่อหนึ่ง) ความสัมพันธ์แบบลำดับชั้น}

ฉันคิดว่าคุณกำลังพยายามผสมผสานแนวคิดจากการสร้างแบบจำลองวัตถุและแนวคิดจากการสร้างแบบจำลองข้อมูลในลักษณะที่ไม่ได้ช่วยให้คุณเข้าใจปัญหาของคุณเองมากขึ้น ฉันหวังว่าฉันสามารถล้างความยุ่งเหยิงเพียงเล็กน้อยโดยไม่ต้องเดินเตร่มากเกินไป

โมเดลเชิงสัมพันธ์เช่นนี้ไม่สนับสนุนการสืบทอด นี่หมายความว่าจะต้องใช้รูปแบบการออกแบบที่ค่อนข้างพิเศษเมื่อสร้างแบบจำลองสถานการณ์ในชีวิตจริงที่จัดการได้ง่ายโดยการสืบทอดและความหลากหลายในรูปแบบวัตถุ เพิ่มเติมเกี่ยวกับรูปแบบการออกแบบพิเศษในภายหลัง

เมื่อแบบจำลอง ER ได้รับการพัฒนาเป็นครั้งแรกมันควรจะเป็นทางเลือกที่ไม่เชื่อเรื่องพระเจ้าในการนำไปใช้กับแบบจำลองเชิงสัมพันธ์ ในตอนแรกมันไม่ได้มีอะไรเหมือนมรดกเลย แต่บางครั้งในช่วงทศวรรษ 1980 หรือ 1990 โมเดลได้ขยายออกไปเพื่อให้ความสามารถในการแสดงออกที่เหมือนกันซึ่งคุณได้รับจากการสืบทอด สิ่งนี้เป็นที่รู้จักกันในนาม "รุ่นขยาย ER" แต่สำหรับวัตถุประสงค์ในทางปฏิบัติทั้งหมดรุ่น ER ในปัจจุบันมีคุณสมบัติของ EER

คุณลักษณะหนึ่งของ EER มีชื่อ "Generalization / Specialization" คุณสามารถค้นหาและอ่านแนวคิดนี้บนเว็บ Gen-spec ให้ความสามารถในการแสดงออกที่เหมือนกันมากที่คลาสและคลาสย่อยให้ในรูปแบบวัตถุ อย่างไรก็ตาม Gen-spec ไม่ได้จัดการกับปัญหารอบการออกแบบตารางเชิงสัมพันธ์สำหรับสถานการณ์ gen-spec เพิ่มเติมว่าภายหลัง

ในการสร้างแบบจำลอง ER ความสัมพันธ์เกี่ยวข้องกับเอนทิตีเดียวกันเสมอ ดังนั้นความสัมพันธ์เพื่อนระหว่างองค์กรและโปรไฟล์จึงไม่เหมือนกับความสัมพันธ์เพื่อนระหว่างโปรไฟล์และโปรไฟล์อื่น ความสัมพันธ์ทั้งสองต้องการชื่อต่างกัน คุณจะผูกตัวเองเป็นปมถ้าคุณไม่ปฏิบัติตามกฎนี้

ไม่ว่าจะเป็นหรือคุณจำเป็นต้องมีองค์กรทั่วไปที่องค์กรโปรไฟล์และสถานที่อาจเป็นผู้เชี่ยวชาญ ฉันไม่เข้าใจกรณีของคุณดีพอที่จะช่วยเหลือคุณ

ตอนนี้ฉันสังเกตเห็นว่าคุณกำลังรวมโมเดลเชิงสัมพันธ์และโมเดล ER ของคุณเข้าด้วยกันเป็นแบบจำลองเดียว สถาปนิกฐานข้อมูลที่มีประสบการณ์มากที่สุดทำเช่นนี้ แต่ฉันแนะนำให้คุณแยกทั้งสองรุ่นออกจากกัน (แม้ว่าจะกระทบกัน) จนกว่าคุณจะมีความชำนาญ

ในที่สุดวิธีหนึ่งออกแบบตารางเชิงสัมพันธ์ที่แสดงสถานการณ์ gen-spec ได้อย่างไร ลองค้นหาทั้งสองรูปแบบการออกแบบ "Class-table-inheritance" และ "Single-Table-Inheritance" มีสองแท็กสำหรับสิ่งเหล่านี้ในมากกว่าใน Stackoverflow นอกจากนี้ยังมีการนำเสนอลวดลายสวย ๆ บนเว็บ ฉันชอบการรักษาของ Martin Fowler เป็นพิเศษ ดูเหมือนว่าเขาจะรู้ว่าผู้สร้างวัตถุคิดอย่างไร หวังว่านี่จะช่วยได้