قاعدة بيانات متعددة القيمة (الكون) - SM (MV) VS SM (مقابل) و Assoc ()

Question

لدي سؤال مأخوذ من PG 16 من IBM's متداخلة قاعدة بيانات بيضاء, ، أنا مرتبك لماذا في أدناه CREATE أمر يستخدمون MV / MS / MS بدلا من MV / MV / MS، عندما كلاهما ORDER_#, ، و PART_# نكون واحد لكثير العلاقات .. لا أفهم ما القيمة، ووسائل القيمة الفرعية في تصميم قاعدة البيانات غير 1NF. أود أيضا أن أعرف لمعرفة المزيد عن ASSOC () بند.

PG 16 من ورقة قاعدة بيانات IBM الخاصة بي وورقة بيضاء (تعديلات بيضاء طفيفة)

    CREATE TABLE NESTED_TABLE (
      CUST# CHAR (9) DISP ("Customer #),
      CUST_NAME CHAR (40) DISP ("Customer Name"),
      ORDER_# NUMBER (6) DISP ("Order #") SM ("MV") ASSOC ("ORDERS"),
      PART_# NUMBER (6) DISP (Part #") SM ("MS") ASSOC ("ORDERS"),
      QTY NUMBER (3) DISP ("Qty.") SM ("MS") ASSOC ("ORDERS")
    );

تنفذ قواعد البيانات العلائقية IBM المتداخلة جداول متداخلة كسمات متكررة ومجموعات تكرار السمات المرتبطة بها. تحدد جمل SM SMEST أن السمة إما تكرار (متعدد - "MV") أو مجموعة متكررة (متعددة غير قطرية - "MS"). ينزلق جملة الشريط السمات داخل جدول متداخل. إذا رغبت في ذلك، فيمكن أن تدعم قواعد البيانات العلائقية التقليدية IBM عدة جداول متداخلة داخل جدول أساسي. سيطلب من بيان SQL القياسي التالي معالجة جداول 1NF من الشكل 5 لإنتاج التقرير المعروض في الشكل 6:

    SELECT CUSTOMER_TABLE.CUST#, CUST_NAME, ORDER_TABLE.ORDER_#, PART_#, QTY
    FROM CUSTOMER_TABLE, ORDER_TABLE, ORDER_CUST
    WHERE CUSTOMER_TABLE.CUST_# = ORDER_CUST.CUST_# AND ORDER_CUST.ORDER_# =
    ORDER _TABLE.ORDER_#;

                                       Nested Table
                Customer #       Customer Name Order #        Part #   Qty.
                AA2340987        Zedco, Inc.      93-1123     037617   81
                                                              053135   36
                                                  93-1154     063364   32
                                                              087905   39
                GV1203948        Alphabravo       93-2321     006776   72
                                                              055622   81
                                                              067587   29
                MT1238979        Trisoar          93-2342     005449   33
                                                              036893   52
                                                              06525    29
                                                  93-4596     090643   33

Answer 1

سأذهب إلى الأمام وأجب عن سؤالي الخاص، أثناء متابعة إدارة SQL في الكون IBM ل DBAS جئت عبر رمز ل CREATE TABLE على PG 55.

ACT_NO INTEGER FORMAT '5R' PRIMARY KEY
BADGE_NO INTEGER FORMAT '5R' PRIMARY KEY
ANIMAL_ID INTEGER FORMAT '5L' PRIMARY KEY

(انظر تشتيت ملاحظة جانبية أدناه) هذا مسمالي في البداية، ولكن أساسا أعتقد أن هذا لتوجيه عمود هو نفس توجيه الجدول مثل PRIMARY ( ACT_NO, BADGE_NO, ANIMAL_ID )

في وقت لاحق في الصفحة 5-19، رأيت هذا

ALTER TABLE LIVESTOCK.T ADD ASSOC VAC_ASSOC (
    VAC_TYPE KEY, VAC_DATE, VAC_NEXT, VAC_CERT
);

مما يدفعني إلى الاعتقاد بأن التخلص من ASSOC (VAC_ASSOC) إلى عمود سيكون هو نفسه ... مثل هذا

CREATE TABLE LIVESTOCK.T (
    VAC_TYPE ... ASSOC ("VAC_ASSOC")
    VAC_DATE ... ASSOC ("VAC_ASSOC")
    VAC_NEXT ... ASSOC ("VAC_ASSOC")
    VAC_cERT ... ASSOC ("VAC_ASSOC")
);

على أي حال، أنا لست متأكدا 100٪ أنا على صواب، لكنني أظن أن النظام لا يهم، وهذا بدلا من أن تكون جمعية غير حساسة، إنها مجرد مجموعة غير حساسة للنظام.

فصاعدا! مع الجزء الثاني من السؤال يتعلق MS و MV, ، أنا من أجل الحياة مني لا يمكن معرفة مكان وجود الجحيم IBM هذا بناء الجملة من. أعتقد أن تكون وهمية. ليس لدي حق الوصول إلى آلة ديف يمكنني اللعب على اختبار ذلك، لكن لا يمكنني العثور عليه (المصطلح MV) في 10.1 القديم أو الجديد Universe 10.3 SQL المرجع

ملاحظة جانبية بالنسبة لأولئك الذين لا يعتادون على الكون 5R و 5L يعني 5 أحرف اليمين أو اليسار مبررة. هذا صحيح ميزة العرض المضمنة في بيانات META الجدول ... Google for Lealse Format (أو FMT) لمزيد من المعلومات.

Answer 2

فقط حتى تعرف، السمة، يأتي Multivalue و Sub-Multivalue من الطريقة التي يقومون بها بنية بياناتهم.

أساسا، يتم تخزين جميع البيانات في شجرة من أنواع. الكون هي قاعدة بيانات متعددة الوسائط. بشكل عام، لا يعمل في طريقة القول بأنها DBS العلائقية من وظيفة عمل SQL.

يمكن أن يكون لكل سجل سمات متعددة.

كل سمة يمكن أن يكون لها متعددة الشركات متعددة.

يمكن أن يكون لكل Multivalue متعددة متعددة متعددة.

لذلك، إذا كان لدي سجل يسمى فريد

بعد ذلك، يشير Fred <1،2،3> إلى السمة الأولى، وموضع 2 متعدد الوظائف و 3 موقف فرعي.

لقراءة المزيد عن ذلك، تحتاج إلى معرفة المزيد حول كيفية عمل الكون. قسم SQL هو مجرد جزء جانبي منه. أقترح عليك قراءة الأدلة الأخرى لفهم ما تعمل معه.

تعديل

في الأساس، فإن الكود أعلاه يخبرك بما يلي:

هناك مايو تكون أوامر متعددة لكل عميل. يتم تخزينها على مستوى MV في "الجدول"

هناك مايو أن تكون أجزاء متعددة لكل طلب. يتم تخزينها على مستوى MS في "الجدول"

هناك مايو أن تكون العديد من الكمية لكل طلب. يتم تخزينها على مستوى MS في "الجدول". نظرا لأنهم في نفس المستوى، على الرغم من أنهم 1- ن لأوامر، فهي 1-1 فيما يتعلق بأجزاء.