รูปแบบการออกแบบฐานข้อมูลเชิงสัมพันธ์? [ปิด]

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

ตัวอย่างจะรวมถึงรูปแบบสำหรับการออกแบบตารางขั้นตอนการจัดเก็บทริกเกอร์ ฯลฯ ...

มีพื้นที่เก็บข้อมูลออนไลน์ของรูปแบบดังกล่าวคล้ายกับmartinfowler.comหรือไม่

ตัวอย่างของปัญหาที่รูปแบบสามารถแก้ไขได้:

• การจัดเก็บข้อมูลแบบลำดับขั้น (เช่นตารางเดี่ยวที่มีประเภท vs หลายตารางพร้อมกับรหัส 1: 1 และความแตกต่าง ... )
• การจัดเก็บข้อมูลด้วยโครงสร้างตัวแปร (เช่นคอลัมน์ทั่วไปเทียบกับ xml เทียบกับคอลัมน์ที่คั่นด้วย ... )
• ล้างข้อมูลให้เป็นปกติ (จะทำอย่างไรกับผลกระทบน้อยที่สุด ฯลฯ ... )

มีหนังสือมาร์ตินฟาวเลอร์ลายเซ็นต์ของซีรีส์ที่เรียกว่าเป็นRefactoring ฐานข้อมูล ที่ให้รายการของเทคนิคสำหรับการ refactoring ฐานข้อมูล ฉันไม่สามารถพูดได้ว่าฉันได้ยินรายการรูปแบบฐานข้อมูลมาก

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

นอกจากนี้สถานที่ที่ยอดเยี่ยมในการมองหาโมเดลฐานข้อมูลที่บรรจุกระป๋องไว้ล่วงหน้าคือชุดข้อมูลทรัพยากรหนังสือรุ่น1ของ Len Silverston ที่ประกอบด้วยโมเดลข้อมูลที่สามารถใช้งานได้ในระดับสากล (พนักงานบัญชีการขนส่งการจัดซื้อ ฯลฯ ) เล่ม 2ประกอบด้วยโมเดลข้อมูลเฉพาะอุตสาหกรรม การดูแลสุขภาพ ฯลฯ ) เล่ม 3จัดทำรูปแบบข้อมูล

ในที่สุดในขณะที่หนังสือเล่มนี้เกี่ยวกับ UML และการสร้างแบบจำลองวัตถุอย่างเห็นได้ชัดการสร้างแบบจำลองสีของ Peter Coad ด้วย UMLให้กระบวนการ "ต้นแบบ" ขับเคลื่อนของการสร้างแบบจำลองเอนทิตีเริ่มต้นจากสมมติฐานว่ามี 4 แกนหลักของโมเดลวัตถุ / ข้อมูล

รูปแบบการออกแบบไม่ใช่โซลูชันที่สามารถใช้ซ้ำได้

รูปแบบการออกแบบสามารถนำกลับมาใช้ใหม่ได้ตามคำจำกัดความ เป็นรูปแบบที่คุณตรวจพบในโซลูชันที่ดีอื่น ๆ

รูปแบบไม่สามารถใช้ซ้ำได้ คุณสามารถใช้การออกแบบลงของคุณตามรูปแบบ

patters การออกแบบเชิงสัมพันธ์รวมถึงสิ่งต่าง ๆ เช่น:

1. ความสัมพันธ์แบบหนึ่ง - ต่อ - หลายกลุ่ม (รายละเอียดหลักความสัมพันธ์แม่ - ลูก) โดยใช้คีย์ต่างประเทศ

2. ความสัมพันธ์แบบหลายต่อกลุ่มกับตารางบริดจ์

3. ตัวเลือกความสัมพันธ์แบบหนึ่งต่อหนึ่งถูกจัดการด้วย NULL ในคอลัมน์ FK

4. Star-Schema: Dimensions and Fact, การออกแบบ OLAP

5. การออกแบบ OLTP ที่ได้มาตรฐานอย่างสมบูรณ์

6. คอลัมน์ค้นหาหลายดัชนีในมิติข้อมูล

7. "ตารางการค้นหา" ที่มี PK คำอธิบายและค่ารหัสที่ใช้โดยแอปพลิเคชันอย่างน้อยหนึ่งรายการ ทำไมต้องมีรหัส ฉันไม่รู้ แต่เมื่อต้องใช้งานนี่เป็นวิธีจัดการรหัส

8. Uni-ตาราง [บางคนเรียกสิ่งนี้ว่า มันเป็นรูปแบบบางครั้งก็ไม่ดีบางครั้งก็ดี] นี่คือตารางที่มีสิ่งที่รวมไว้ล่วงหน้าจำนวนมากซึ่งละเมิดรูปแบบปกติที่สองและสาม

9. ตารางอาเรย์ นี่คือตารางที่ละเมิดรูปแบบปกติแรกโดยมีอาร์เรย์หรือลำดับของค่าในคอลัมน์

10. ฐานข้อมูลผสมใช้งาน นี่คือฐานข้อมูลที่ทำให้เป็นมาตรฐานสำหรับการประมวลผลธุรกรรม แต่มีดัชนีพิเศษมากมายสำหรับการรายงานและการวิเคราะห์ มันเป็นรูปแบบการต่อต้าน - อย่าทำอย่างนี้ คนทำมันต่อไปดังนั้นมันยังคงเป็นรูปแบบ

คนส่วนใหญ่ที่ออกแบบฐานข้อมูลสามารถสั่นสะเทือนครึ่งโหลได้อย่างง่ายดาย "มันเป็นอีกหนึ่งในนั้น"; นี่คือรูปแบบการออกแบบที่ใช้เป็นประจำ

และสิ่งนี้ไม่รวมถึงรูปแบบการจัดการและการดำเนินงานของการใช้งานและการจัดการ

AskTomน่าจะเป็นทรัพยากรที่มีประโยชน์ที่สุดเพียงหนึ่งเดียวในแนวทางปฏิบัติที่ดีที่สุดใน Oracle DB (ฉันมักจะพิมพ์ "asktom" เป็นคำแรกของข้อความค้นหา google ในหัวข้อเฉพาะ)

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

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

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

คำถาม:

• คุณต้องการใช้ DBMS อื่นในอนาคตหรือไม่ ถ้าใช่ไม่ใช้กับสิ่งพิเศษ SQL ของ DBMS ปัจจุบัน ลบตรรกะในแอปพลิเคชันของคุณ

ไม่ได้ใช้:

• ช่องว่างสีขาวในชื่อตารางและชื่อคอลัมน์
• อักขระที่ไม่ใช่ ASCII ในชื่อตารางและคอลัมน์
• ผูกพันกับตัวพิมพ์เล็กหรือตัวพิมพ์ใหญ่เฉพาะ และห้ามใช้ 2 ตารางหรือคอลัมน์ที่แตกต่างกันเฉพาะกับตัวเล็กและตัวใหญ่
• ไม่ใช้คำสำคัญ SQL สำหรับชื่อตารางหรือคอลัมน์เช่น "FROM", "BETWEEN", "DELETE" เป็นต้น

recomendations:

• ใช้ NVARCHAR หรือสิ่งที่เทียบเท่าสำหรับการสนับสนุน Unicode คุณจะไม่มีปัญหากับเพจรหัส
• ตั้งชื่อที่ไม่ซ้ำกันทุกคอลัมน์ ทำให้ง่ายต่อการเข้าร่วมเพื่อเลือกคอลัมน์ มันยากมากหากทุกตารางมีคอลัมน์ "ID" หรือ "ชื่อ" หรือ "คำอธิบาย" ใช้ XyzID และ AbcID
• ใช้บันเดิลของทรัพยากรหรือเท่ากับสำหรับนิพจน์ SQL ที่ซับซ้อน ทำให้ง่ายต่อการเปลี่ยนไปใช้ DBMS อื่น
• ไม่ส่งสัญญาณข้อมูลอย่างหนัก DBMS อื่นไม่สามารถมีชนิดข้อมูลนี้ สำหรับตัวอย่าง Oracle daes ไม่มี SMALLINT เพียงตัวเลข

ฉันหวังว่านี่เป็นจุดเริ่มต้นที่ดี

คำถามของคุณค่อนข้างคลุมเครือ แต่ฉันคิดว่าUPSERTอาจเป็นรูปแบบการออกแบบ สำหรับภาษาที่ไม่ใช้MERGE, จำนวนของทางเลือกในการแก้ปัญหา (ถ้าแถวที่เหมาะสมอยู่แล้วUPDATE; อื่นINSERT) ที่มีอยู่

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

หากคุณกำลังคิดที่จะเป็นโรงงานซิงเกิลตัน ... ไม่เลยคุณไม่ต้องการสิ่งเหล่านี้เพราะระดับการเขียนโปรแกรม DB ต่ำเกินไป

หากคุณคิดว่าการตั้งชื่อออบเจ็กต์ฐานข้อมูลอยู่ภายใต้หมวดหมู่ของอนุสัญญาไม่ใช่การออกแบบ

BTW, S.Lott ความสัมพันธ์แบบหนึ่งต่อหลายและหลายต่อหลายคนไม่ใช่ "รูปแบบ" พวกมันเป็นหน่วยการสร้างพื้นฐานของโมเดลเชิงสัมพันธ์