1

IBMのNestedRelationalDatabaseホワイトペーパーの16ページから質問があります。以下のCREATEコマンドで、MV / MV/MSではなくMV/MS / MSを使用し、両方ORDER_#がPART_#1対多である理由がわかりません。関係..非1nfデータベース設計での値とサブ値の意味がわかりません。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句は、属性が繰り返し（multivalued--"MV"）または繰り返しグループ（multi-subvalued--"MS"）のいずれかであることを指定します。ASSOC句は、ネストされたテーブル内の属性を関連付けます。必要に応じて、IBMのネストされたリレーショナル・データベースは、ベース表内のいくつかの入れ子になった表をサポートできます。図5の1NFテーブルを処理して、図6に示すレポートを作成するには、次の標準SQLステートメントが必要です。

    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
4

2 に答える 2

1

ご存知のように、属性、複数値、およびサブ複数値は、データの構造に由来します。

基本的に、すべてのデータはソート ツリーに格納されます。UniVerse は多値データベースです。一般に、SQL のリレーショナル DB が機能するように機能するわけではありません。

各レコードは複数の属性を持つことができます。

各属性は、複数の複数値を持つことができます。

各多値は、複数のサブ多値を持つことができます。

FREDというレコードがある場合

次に、FRED<1,2,3> は、1 番目の属性、2 つの複数値の位置、3 つのサブ値の位置を参照します。

詳細を読むには、UniVerse の仕組みについて詳しく知る必要があります。SQL セクションはほんの一部です。何を扱っているかを理解するために、他のマニュアルを読むことをお勧めします。

編集

基本的に、上記のコードは次のことを示しています。

1 クライアントにつき複数の注文がある場合があります。これらは MV レベルで「テーブル」に保存されます

注文ごとに複数のパーツが存在する場合があります。これらは、MS レベルで「テーブル」に保存されます。

注文ごとに複数の数量がある場合があります。これらは「テーブル」に MS レベルで保存されます。同レベルなので、受注は1対1ですが、部品に関しては1対1です。

于 2010-01-14T22:59:22.323 に答える
1

pg 55でコードに出くわした DBA 向けの IBM の UniVerse SQL Administrationを追求しながら、私自身の質問に答えます。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")
);

とにかく、私が正しいと 100% 確信しているわけではありませんが、順序は問題ではないと推測しています。これらは自動詞的な関連付けではなく、順序に依存しないグループ化にすぎません。

進め！MSおよびに関する質問の 2 番目の部分では、MVIBM がこの構文をどこから取得したのか、一生わかりません。私はそれが想像上のものであると信じています。これをテストするためにプレイできる開発マシンにアクセスできませんが、古い 10.1 または新しいUniVerse 10.3 SQL リファレンスでそれ (MV という用語) を見つけることができません。

UniVerse に慣れていない方への補足として、右寄せまたは左寄せの 5 文字5Rを意味します。5Lこれは、テーブルのメタデータに組み込まれた表示機能です...詳細については、Google for UniVerse FORMAT (または FMT) を参照してください。

于 2010-01-07T23:19:03.523 に答える