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

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

1 голос
/ 07 января 2010

У меня вопрос, заданный на стр. 16 из Технического документа IBM Nested Relational Database , я запутался, почему в приведенной ниже команде 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 ]

1 голос
/ 15 января 2010

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

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

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

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

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

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

Тогда FRED <1,2,3> относится к 1-му атрибуту, 2 многозначным позициям и 3 субзначным позициям.

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

EDIT

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

Там может быть несколько заказов на клиента. Они хранятся на уровне MV в «таблице»

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

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

1 голос
/ 08 января 2010

Я продолжу и отвечу на свой вопрос, продолжая Администрирование UniVerse SQL IBM для администраторов баз данных Я обнаружил код для 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%, что я прав, но я предполагаю, что порядок не имеет значения, и что вместо того, чтобы быть непереходной ассоциацией, это просто нечувствительная к порядку группировка.

Onward! Со второй частью вопроса, относящейся к MS и MV, я на всю жизнь не могу понять, откуда, черт возьми, IBM получила этот синтаксис. Я считаю, что это воображаемо. У меня нет доступа к машине разработчика, на которой я могу сыграть, чтобы проверить это, но я не могу найти ее (термин MV) в старой версии 10.1 или новой UniVerse 10.3 SQL Reference

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

...