多值数据库(UniVerse) -- SM (MV) vs SM (VS)和ASSOC()

Question

我有一个问题来自IBM嵌套关系数据库白皮书的pg 16，我很困惑为什么在下面的CREATE命令中他们使用MV/MS/MS而不是MV/MV/MS，而ORDER_#和PART_#都是一对多的关系。我不明白在非1NF数据库设计中什么是值，vs子值是什么意思。我也想知道更多关于ASSOC ()条款的知识。

IBM嵌套关系数据库白皮书第16页(稍作空格修改)

    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语句来处理图5中的1NF表，以生成如图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

我将继续回答我自己的问题，在追求UniVerse对DBA的SQL管理时，我在pg 55上遇到了CREATE TABLE的代码。

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")
);

无论如何，我不能百分之百肯定我是对的，但我猜这个顺序并不重要，而且它们不是一个不可传递的关联，它们只是一个顺序不敏感的分组。

往前走！关于MS和MV的问题的第二部分，我一辈子都搞不清这语法是从哪里来的。我相信这是虚构的。我无法访问开发机器来测试它，但在旧的10.1或新的UniVerse 10.3 SQL引用中找不到它(术语MV)

对于那些不习惯UniVerse的人来说，5R和5L意味着5个字符的右或左对齐。这是在表元数据中内置的显示功能..。谷歌的UniVerse格式(或FMT)获得更多信息。

Answer 2

正如您所知，属性、多值和子-多值来自于它们构造数据的方式。

从本质上说，所有数据都存储在一棵排序树中。UniVerse是一个多值数据库。通常，它不像SQL work函数的Relational那样工作。

每个记录可以有多个属性。

每个属性可以有多个多值。

每个多值可以有多个子多值。

所以，如果我有一个叫弗雷德的记录

然后，FRED<1,2,3>表示第一个属性、2个多值位置和3个子值位置。

要阅读更多关于UniVerse的信息，您需要了解更多关于工作原理的知识。SQL部分只是它的一个侧面部分。我建议你阅读其他手册来理解你在做什么。

编辑

实际上，上面的代码告诉您：

每个客户可能有多个订单。它们存储在“表”中的MV级别上。

每个订单可能有多个部件。它们存储在“表”中的MS级别上。

每个订单可能有多个qtys。这些存储在MS级的“表”中。因为他们是在同一水平，虽然他们是1-n的订单，他们是1-1在部分。