شيء مثل الميراث في تصميم قاعدة البيانات

Question

افترض أنك قمت بإعداد قاعدة بيانات لتخزين بيانات اختبار التعطل من المركبات المختلفة. تريد تخزين بيانات اختبارات الأعطال لقوارب السرعة والسيارات والذهاب.

يمكنك إنشاء ثلاثة طاولات منفصلة: BreeBoattests، المنافسة، و gokarttests. ولكن الكثير من أعمدةك ستكون هي نفسها في كل جدول (على سبيل المثال، معرف الموظف للشخص الذي أجرى الاختبار، اتجاه التصادم (الأمامي، الجانب، الخلفي)، إلخ). ومع ذلك، فإن الكثير من الأعمدة ستكون مختلفة، لذلك لا ترغب في وضع جميع بيانات الاختبار فقط في جدول واحد لأنك سيكون لديك عدد قليل جدا من الأعمدة التي ستكون دائما خالية من الزوارق السريعة، وبعضها سيكون دائما كن فارغا للسيارات، وبعضها البعض سيكون دائما فارغا للذهاب.

دعنا نقول أنك تريد أيضا تخزين بعض المعلومات التي لا تتعلق مباشرة بالاختبارات (مثل معرف الموظف للمصمم الذي يتم اختباره). لا يبدو أن هذه الأعمدة صحيحة في وضع جدول "اختبارات" على الإطلاق، خاصة لأنها ستكررها لجميع الاختبارات على نفس السيارة.

اسمحوا لي أن أوضح ترتيب واحد ممكن للجداول، حتى تتمكن من رؤية الأسئلة المعنية.

معرف سرعة السرعة |. col_about_speedboats_but_not_tests1 | COL_ABOUT_SPEDBOATS_BUT_NOT_TESTS2 معرف سيارات | col_about_cars_but_not_tests1 | COL_ABOUT_CARS_BUT_NOT_TESTS2 Gokarts ID | col_about_gokarts_but_not_tests1 |. COL_ABOUT_GOKARTS_BUT_NOT_TESTS2 اختبارات معرف | النوع |. ID_IN_TYPE |. col_about_all_tests1 | COL_ABOUT_ALL_TESTS2 (ID_IN_TYPE سيشير إلى عمود المعرف لأحد الجداول الثلاثة التالية، اعتمادا على قيمة نوع النوع) SpeedBoat_id |. col_about_speedboat_tests1 | COL_ABOUT_SPEEDBOAT_TESTS2 معرف كارتيز | car_id |. col_about_car_tests1 | COL_ABOUT_CAR_TESTS2 HOKARTTSTS ID | gokart_id | col_about_gokart_tests1 | col_about_gokart_tests2.

ما هو جيد / سيء حول هذا الهيكل وما هي الطريقة المفضلة لتنفيذ شيء مثل هذا؟

ماذا لو كانت هناك أيضا بعض المعلومات التي تنطبق على جميع المركبات التي تفضل الحصول عليها في جدول المركبات؟ سوف الجدول قفزات ثم تبدو مثل ...

معرف |. مركبة |. ... مع طاولة مركبات مثل هذا: ID | النوع |. ID_IN_TYPE (مع ID_IN_TYPE يشير إلى معرف إما القارب السريع أو السيارة أو الذهاب-Kart)

هذا هو مجرد الحصول على فوضى ملكية يبدو. كيف يجب إعداد شيء من هذا القبيل؟

Answer 1

ال type و id_in_type التصميم يسمى الجمعيات متعددة الأشكال. وبعد هذا التصميم يكسر قواعد التطبيع بطرق متعددة. إذا لم يكن هناك شيء آخر، يجب أن يكون علامة حمراء لا أعلن قيود مفتاح أجنبي حقيقي، لأن id_in_type قد يشير إلى أي من الجداول العديدة.

إليك طريقة أفضل لتحديد الجداول الخاصة بك:

• جعل الجدول مجردة Vehicles لتوفير نقطة مرجعية مجردة لجميع أنواع المركبات واختبارات المركبات.
• يحتوي كل نوع من النوع الفرعي على مفتاح أساسي لا يزيد تلقائيا، ولكن بدلا من ذلك المراجع Vehicles.
• يحتوي كل نوع من النوع الفرعي على مفتاح أساسي لا يزيد تلقائيا، ولكن بدلا من ذلك المراجع Tests.
• يحتوي كل نوع من النوع الفرعي أيضا على مفتاح أجنبي من النوع الفرعي للسيارة المقابلة.

إليك عينة DDL:

CREATE TABLE Vehicles (
 vehicle_id INT AUTO_INCREMENT PRIMARY KEY
);

CREATE TABLE Speedboats (
 vehicle_id INT PRIMARY KEY,
 col_about_speedboats_but_not_tests1 INT,
 col_about_speedboats_but_not_tests2 INT,
 FOREIGN KEY(vehicle_id) REFERENCES Vehicles(vehicle_id)
);

CREATE TABLE Cars (
 vehicle_id INT PRIMARY KEY,
 col_about_cars_but_not_tests1 INT,
 col_about_cars_but_not_tests2 INT,
 FOREIGN KEY(vehicle_id) REFERENCES Vehicles(vehicle_id)
);

CREATE TABLE Gokarts (
 vehicle_id INT PRIMARY KEY,
 col_about_gokarts_but_not_tests1 INT,
 col_about_gokarts_but_not_tests2 INT,
 FOREIGN KEY(vehicle_id) REFERENCES Vehicles(vehicle_id)
);

CREATE TABLE Tests (
 test_id INT AUTO_INCREMENT PRIMARY KEY,
 col_about_all_tests1 INT,
 col_about_all_tests2 INT
);

CREATE TABLE SpeedboatTests (
 test_id INT PRIMARY KEY,
 vehicle_id INT NOT NULL,
 col_about_speedboat_tests1 INT,
 col_about_speedboat_tests2 INT,
 FOREIGN KEY(test_id) REFERENCES Tests(test_id),
 FOREIGN KEY(vehicle_id) REFERENCES Speedboats(vehicle_id)
);

CREATE TABLE CarTests (
 test_id INT PRIMARY KEY,
 vehicle_id INT NOT NULL,
 col_about_car_tests1 INT,
 col_about_car_tests2 INT,
 FOREIGN KEY(test_id) REFERENCES Tests(test_id),
 FOREIGN KEY(vehicle_id) REFERENCES Cars(vehicle_id)
);

CREATE TABLE GokartTests (
 test_id INT PRIMARY KEY,
 vehicle_id INT NOT NULL,
 col_about_gokart_tests1 INT,
 col_about_gokart_tests2 INT,
 FOREIGN KEY(test_id) REFERENCES Tests(test_id),
 FOREIGN KEY(vehicle_id) REFERENCES Gokarts(vehicle_id)
);

هل يمكن أن تعلن بدلا من ذلك Tests.vehicle_id التي المراجع Vehicles.vehicle_id والتخلص من مفاتيح السيارة الخارجية في كل جدول اختبار من النوع الفرعي، ولكن من شأنه أن يسمح الشاذة، مثل اختبار القارب السريع الذي يشير إلى معرف Gokart.

Answer 2

بالنسبة لرسم الخرائط التسلسلات الهرمية للمدرر إلى جداول قاعدة البيانات، وأعتقد أن مارتن فاولر يضع البدائل جيدا إلى حد ما في أنماط كتابه من بنية تطبيق المؤسسات.

http://martinfowler.com/eaacatalog/singletableinheritance.html.

http://martinfowler.com/eaacatalog/classtableinheritance.html.

http://martinfowler.com/eaacatalog/concretetretableinheritance.html.

إذا كان عدد الحقول / الأعمدة الإضافية الصغيرة بالنسبة للفئات الفئة الفئة الفرعية، فإن ميراث جدول واحد عادة ما يكون أبسط التعامل معها.

إذا كنت تستخدم postgresql لقاعدة البيانات الخاصة بك، فأنت على استعداد لربط نفسك بميزة خاصة بقاعدة البيانات، فإنه يدعم ميراث الجدول مباشرة:

http://www.postgresql.org/docs/8.3/static/ddl-inherit.html.

Answer 3

وأود أن كسرها إلى جداول مختلفة، مثل المركبات (معرف، النوع، وما إلى ذلك) vehicleattributes () المركبة، attrabidid، القيمة)، crashtestInfo (المركبة، crashtestid، تاريخ إلخ.)

أو بدلا من السمات، جداول منفصلة لكل مجموعة من التفاصيل المماثلة التي يجب تسجيلها.

Answer 4

إذا كنت تستخدم sqlalchemy., ، كائن متعدد العلال القطار لبيتثون، يمكنك تكوين كيفية تعيين التسلسلات الهرمية للبورثة إلى جداول قاعدة البيانات. وبعد الخياطين العلائقية للكائنات جيدة لترويض SQL غير مملة خلاف ذلك.

مشكلتك قد تكون مناسبة جيدة للجداول العمودي. بدلا من تخزين كل شيء في المخطط، قم بتخزين نوع الكائن والمفتاح الأساسي في طاولة واحدة و Tumples المفتاح / القيمة لكل كائن في جدول آخر. إذا كنت تقوم بالفعل بتخزين اختبارات السيارات، فإن هذا الإعداد سيجعله أسهل بكثير لإضافة أنواع جديدة من النتائج.

Answer 5

قم بإجراء بحث Google على "النمذجة العلائقية المواصفات العامة". ستجد مقالات حول كيفية إعداد الجداول التي تخزن سمات الكيان المعمم (ما قد يسمي مبرمجات OO SuperClass)، وجداول منفصلة لكل من الكيانات المتخصصة (الفئات الفرعية)، وكيفية استخدام المفاتيح الأجنبية لربطها جميعا.

أفضل المقالات، المنظمة البحرية الدولية، ناقش المواصفات العامة من حيث النمذجة إيه. إذا كنت تعرف كيفية ترجمة نموذج ER إلى نموذج علائقية، ومن ثم إلى جداول SQL، فستعرف ما يجب القيام به بمجرد أن يظهر لك كيفية طراز Gen-Special في ER.

إذا قمت فقط بوجود جوجل على "Gen-spec"، فإن معظم ما ستراه هو موجه نحو الكائنات، وليس العلائقية الموجهة. قد تكون هذه الأشياء مفيدة أيضا، طالما تعرف كيفية التغلب على عدم تطابق المعاوقة العلائقية للكائنات.

Answer 6

التصميم الخاص بك معقول ويتبع قواعد التطبيع الصحيحة. قد تكون في عداد المفقودين طاولة مركبة مع معرف مركبة ونوع (أي الوالد "للسرعة السريعة والسيارات والجوكارت ... حيث تحتفظ بالأشياء مثل" SommetyByuserid "). بين طاولة السيارة وطاولة الزوارق السريعة هي علاقة واحدة إلى واحدة، وبين المركبات والسرعة السريعة / السيارات / غوكارت هناك علاقة واحدة فقط - 1 (أي يمكن أن يكون للمركبة فقط سجل واحد فقط لقارب سريع، السيارات أو الذهاب كارتس) ... على الرغم من أن معظم DB لا تقدم آلية إنفاذ سهلة لهذا الغرض.

قاعدة تطبيع واحدة تساعد في تحديد هذه الأنواع من الأشياء هي أن الحقل يجب أن يعتمد فقط على المفتاح الأساسي للجدول. في جدول موحد حيث يتم تخزين نتائج اختبار القارب السريع والسيارات و Gokart معا ثم تعتمد الحقول ذات الصلة بالسيارات على تاريخ الاختبار فحسب، بل في تاريخ الاختبار ولكن أيضا على معرف Vechicle ونوع السيارة. المفتاح الأساسي لجدول نتائج الاختبار هو تاريخ الاختبار + معرف السيارة، ونوع السيارة ليس ما يجعل صف بيانات الاختبار فريد من نوعه (أي على أي حال لإجراء اختبار في 01/01/200912: 30 مساء على مركبة واحدة محددة هذا هو القارب السريع والسيارة ... كلا ... لا يمكن القيام به).

أنا لا أشرح القاعدة التطبيع بشكل خاص بشكل جيد ... لكن قواعد أشكال الأشكال العادية / الرابعة / الرابعة / الرابعة / الخامسة دائما تخلت عني عندما قرأت الأوصاف الرسمية. يتناول أحد الأشخاص (الثالث / الرابع / الخامس) الحقول اعتمادا على المفتاح الأساسي والمفتاح الأساسي فقط. تتيح القاعدة الافتراض بأن المفتاح الأساسي قد تم تحديده بشكل صحيح (DECTIONH بشكل غير صحيح، المفتاح الأساسي سهل الاستخدام).