Многозначная база данных (UniVerse) - SM (MV) против SM (VS) и ASSOC()

У меня вопрос, заданный на стр. 16 Белой книги IBM по вложенным реляционным базам данных, я запутался, почему в приведенном ниже CREATE Команда они используют MV/MS/MS, а не MV/MV/MS, когда оба ORDER_#, а также PART_# отношения один-ко-многим.. Я не понимаю, какое значение имеет значение против под-значения в дизайне базы данных, отличном от 1nf. Я также хотел бы знать, чтобы узнать больше о ASSOC () пункт.

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 указано, что атрибут является либо повторяющимся (многозначным -"MV"), либо повторяющейся группой (многозначным -"MS"). Предложение ASSOC связывает атрибуты во вложенной таблице. При желании вложенные реляционные базы данных 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
Источник

2 ответа

Решение

Я пойду дальше и отвечу на свой вопрос, продолжая администрирование IBM UniVerse SQL для администраторов баз данных, для которых я наткнулся на код CREATE TABLE на стр. 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 или новой версии SQL-справки UniVerse 10.3.

примечание для тех, кто не использовал UniVerse 5R а также 5L означают 5 символов справа или слева выровнены. Это верно, функция отображения, встроенная в метаданные таблицы... Google для UniVerse FORMAT (или FMT) для получения дополнительной информации.

Источник

Как вы знаете, атрибут, многозначность и субзначность происходит из того, как они структурируют свои данные.

По сути, все данные хранятся в виде дерева. UniVerse - это многозначная база данных. Как правило, он не работает, скажем, как реляционные БД функции SQL.

Каждая запись может иметь несколько атрибутов.

Каждый атрибут может иметь несколько многозначных значений.

Каждое многозначное значение может иметь несколько вложенных многозначных значений.

Итак, если у меня есть запись под названием FRED

Затем FRED<1,2,3> ссылается на 1-й атрибут, 2 многозначных позиции и 3 субзначных позиции.

Чтобы узнать больше об этом, вам нужно больше узнать о том, как работает UniVerse. Раздел SQL - это только его боковая часть. Я предлагаю вам прочитать другие руководства, чтобы понять, с чем вы работаете.

РЕДАКТИРОВАТЬ

По сути, приведенный выше код говорит вам, что:

Может быть несколько заказов на одного клиента. Они хранятся на уровне MV в "таблице"

Там может быть несколько частей на заказ. Они хранятся на уровне MS в "таблице"

Может быть несколько qtys на заказ. Они хранятся на уровне MS в "таблице". поскольку они находятся на одном уровне, хотя они 1-n для заказов, они 1-1 в отношении частей.

Источник
Другие вопросы по тегам