MUMPS Globals：極端なデータベースプログラミング。 パート3

パート1 、 パート2を参照してください。



二次インデックス



リレーショナルデータベースでは、通常、テーブルの定義時、またはALTER TABLEの使用後にセカンダリインデックスが指定されます。 インデックスが定義されている場合、インデックスは自動的に作成され、データが変更されたときにデータベースによって維持および再計算されます。



MUMPSでは、テーブル更新機能などで、プログラマがインデックスを明示的に提供します。



MUMPSストアの階層的性質により、プライマリインデックスを持つフィールドがキーとして使用されます。



たとえば、新しい行をORDERに追加するMUMPS関数を考えます。

setOrder(orderNo,data) ; new rec,itemNo,ok if orderNo="" Quit 0 ;     set data("totalValue")=0 set itemNo="" for set itemNo=$Order(^ITEM(orderNo,itemNo)) Quit:itemNo="" do . set ok=$$getItem(orderNo,itemNo,.itemData) . Set data("totalValue")=data("totalValue")+itemData("price") set rec=data("custNo")_"~"_data("orderDate")_"~"_data("invoiceDate") set rec=rec_"~"_data("totalValue") set ^ORDER(orderNo)=rec Quit 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードに注意して、注文の合計費用を計算します。 特定の注文番号orderNoについてITEMからすべてのエントリを調べ、$$ getItem（）関数を使用して各アイテムの値を取得します。 $$ getItem（）関数のコードは次のとおりです。

 getItem(orderNo,itemNo,itemData) kill itemData s itemData("price")=0 if orderNo="" Quit 0 if itemNo="" Quit 0 if '$data(^ITEM(orderNo,itemNo)) Quit 0 set itemData("price")=^ITEM(orderNo,itemNo) Quit 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

特定の注文番号とアイテム番号についてグローバルのアイテムの存在をチェックする期限を見てください。 MUMPS関数の$ dataと否定演算子のシングルクォート `を使用します。



各顧客の購入にすばやくアクセスするためのインデックスを追加しましょう。



インデックスを保存するには、新しいグローバル^ ORDERX1を作成します。 顧客番号（custNo）と注文番号（orderNo）の2つのキーをグローバルに保存します。



インデックス（custNo、orderNo）を機能させるには、setOrder関数を次のように展開します。

 setOrder(orderNo,data) ; new rec,itemNo,ok if orderNo="" Quit 0 ;    set data("totalValue")=0 set itemNo="" for set itemNo=$Order(^ITEM(orderNo,itemNo)) Quit:itemNo="" do . set ok=$$getItem(orderNo,itemNo,.itemData) . Set data("totalValue")=data("totalValue")+itemData("price") set rec=data("custNo")_"~"_data("orderDate")_"~"_data("invoiceDate") set rec=rec_"~"_data("totalValue") set ^ORDER(orderNo)=rec if data("custNo")`="" set ^ORDERX1(data("custNo"),orderNo)="" Quit 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

注文を作成するには、この関数を次のように使用します。

 set orderNo=21 kill data set data("custNo")=101 set data("orderDate")="4/5/2003" set data("invoiceDate")="4/7/2003" set ok=$$setOrder(orderNo,.data)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

参照整合性



参照整合性を維持することは、データベース内のすべての参照アクションの中で最も有名なことのようです。

参照アクションには、他のテーブルが変更されたという事実のために、1つのテーブルで実行する必要があるすべてのアクションが含まれます。



参照整合性を維持するプロセスは、関連するテーブル間のセマンティック（元のセマンティック）整合性を維持する責任があります。 特に、これはNATURAL JOIN（異なるテーブルにはテーブル間の関係を構築するのと同じタイプの値を格納する列があります）またはプライマリ/外部キーに基づいたテーブル間の関係の維持によるものです。



たとえば、顧客番号CUSTOMER.custNoが変更または削除された場合、顧客テーブルと注文テーブルの間の意味的整合性を維持するために、ORDER.custNoフィールドを適切に変更する必要があります。



同様に、注文番号ORDER.orderNoが変更（または削除）された場合、注文のあるテーブルと（注文が行われた）物のテーブルの間のセマンティック整合性を維持するために、対応する変更はITEM.orderNoフィールドで行われる必要があります。



リレーショナルデータベース（RDBMS）では、主キーと外部キーを使用してテーブルを作成するときに整合性ルールが指定されます。 MUMPSでは、これらのルールを関数内に実装できます。



顧客テーブルと注文の関係に留意して、CUSTOMER更新操作は次のようになります。



SQL

 UPDATE CUSTOMER A SET custNo = :newCustNo WHERE A.custNo = :oldCustNo
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

データベース構造の定義時に対応する外部キーが正しく設定されていれば、リクエストの結果、ORDERテーブルの対応するエントリが更新されます（CUSTOMER.custNo = ORDER.custNoリンクにより）。



おたふく風邪

 updateCustomer(oldCustNo,newCustNo,newData) ; new result,orderData,orderNo if (oldCustNo="")!(newCustNo="") Quit 0 set orderNo="" for set orderNo=$order(^ORDERX1(oldCustNo,orderNo)) Quit:orderNo="" do . set result=$$getOrder(orderNo,.orderData) . set orderData("custNo")=newCustNo . set ok=$$setOrder(orderNo,.orderData) set ok=$$setCustomer(newCustNo,.newData) if newCustNo`=oldCustNo set ok=$$deleteCustomer(oldCustNo) Quit 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードの大部分は、CUSTOMERテーブルとORDERテーブルを提供するために既に作成した関数で構成されていることに注意してください。 MUMPSでは、コードを再利用するだけです。



次に、$$ getOrder関数を作成します。

 getOrder(orderNo,orderData) ; new record if (orderNo="") Quit 0 set record=$g(^ORDER(orderNo)) set orderData("custNo")=$piece(record,"~",1) set orderData("orderDate")=$piece(record,"~",2) set orderData("invoiceDate")=$piece(record,"~",3) set orderData("totalValue")=$piece(record,"~",4) Quit 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、元の単純な関数$$ deleteCustomer（）を拡張する必要があります。 クライアントテーブルからの行の削除にも同様の考慮事項が適用されます。



MでのSQLクエリとそれに相当するものを以下に示します。



SQL

 DELETE FROM CUSTOMER A WHERE A.custNo = :custNo
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この要求の結果、対応する注文レコードがORDERテーブルから削除されます（関係CUSTOMER.custNo = ORDER.custNoおよびデータベーススキーマの作成時に定義された整合性ルールに従って）。 整合性ルールは、たとえば外部キーを使用して設定できます。



おたふく風邪

 deleteCustomer(custNo) ; new orderNo if custNo="" Quit 0 set orderNo="" for set orderNo=$order(^ORDERX1(custNo,orderNo)) Quit:orderNo="" do . set result=$$deleteOrder(custNo,orderNo) kill ^CUSTOMER(custNo) Quit 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記のコードには、$$ deleteOrder（）関数が必要です。 ここにあります：

 deleteOrder(custNo,orderNo) ; kill ^ITEM(orderNo) ;       kill ^ORDER(orderNo) ;   kill ^ORDERX1(custNo,orderNo) ;       ,     Quit 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

特定の注文に含まれるすべてのものに関するレコードは、注文番号のインデックスに対して1つのKILLコマンドを使用して削除されることに注意してください。 これは、顧客とテーブル（SQLの用語で）を持つテーブル間に連鎖関係があるためです。



クライアントを削除するときに、注文に関する情報を保存し、クライアントと注文間の接続を切断する必要がある場合、deleteCustomer関数は次の形式を取ります。

 deleteCustomer(custNo) ; new orderNo,result,orderData if custNo="" Quit 0 set orderNo="" for set orderNo=$order(^ORDERX1(custNo,orderNo)) Quit:orderNo="" do . set result=$$getOrder(orderNo,.orderData) . set orderData("custNo")="" . set result=$$setOrder(orderNo,.orderData) kill ^CUSTOMER(custNo) Quit 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ORDERテーブルの注文番号ORDER.orderNoが変更または削除された場合、同様のロジックをITEMテーブルに保存されたデータに適用する必要があります。



トリガー



トリガーは、データベース内で特定の条件が満たされたときに事前定義されたコードを呼び出す簡単な方法です。 通常、トリガーは、データベース内の一部の情報が変更されるとトリガーされます。



リレーショナルデータベースでは、トリガーはデータベーススキーマレベルで定義されます。 MUMPSでは、データベースを提供する関数にトリガーコードを配置できます。



たとえば、特定の顧客の注文数CUSTOMER.totalOrdersを考えます。 ORDERテーブルで注文を追加または削除するときに、このフィールドを自動的に更新するトリガーを定義する必要があります。



SQL



CUSTOMER.totalOrdersの値が正しいことを確認するには、このSQL式をORDERテーブルのトリガーコードに含める必要があります。

 SELECT COUNT(A.orderNo) FROM A.ORDER WHERE A.custNo = :custNo
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このクエリは、ORDERテーブルの行の挿入および削除操作でトリガーされます（関係CUSTOMER.custNo = ORDER.custNoによる）



おたふく風邪



ORDERテーブルの行挿入関数に次の（トリガー）コードを追加するだけです。

 setOrder(orderNo,data) ; new rec,itemNo,ok if orderNo="" Quit 0 ;       set data("totalValue")=0 set itemNo="" for set itemNo=$Order(^ITEM(orderNo,itemNo)) Quit:itemNo="" do . set ok=$$getItem(orderNo,itemNo,.itemData) . Set data("totalValue")=data("totalValue")+itemData("price") set rec=data("custNo")_"~"_data("orderDate")_"~"_data("invoiceDate") set rec=rec_"~"_data("totalValue") set ^ORDER(orderNo)=rec ;       if data("custNo")`="" set ^ORDERX1(data("custNo"),orderNo)="" ; ;    CUSTOMER.totalOrders new custData Set ok=$$getCustomer(data("custNo"),.custData) ;       CUSTOMER.totalOrders. .   setCustomer     Set ok=$$setCustomer(data("CustNo"),.custData) ; Quit 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ORDERテーブルから行を削除する場合も、同じ考慮事項が適用されます。 同様のスキームを使用して、注文に物事を追加するときに注文値ORDER.totalValueを自動的に更新できます。



SQL



新しい注文値ORDER.Valueを計算するには、ITEMテーブルのトリガー内に次のSQLコードを配置する必要があります。

 SELECT SUM(A.price) FROM A.ITEM WHERE A.orderNo = :orderNo
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ITEMテーブルに対するすべての挿入および削除操作に対して、要求がトリガーされます（関係ORDER.orderNo = ITEM.orderNoに従って）。



おたふく風邪



ITEMテーブルを使用して、次の（トリガー）コードを行挿入関数に追加します。

 setItem(orderNo,itemNo,data) ; new ok if (orderNo="")!(itemNo="") Quit 0 set ^ITEM(orderNo,itemNo)=data("price") set^ORDERX1(custNo,orderNo)="" ;    ORDER.totalValue set ok=$$getOrder(orderNo,.orderData) ;     ORDER.totalValue   set ok=$$setOrder(orderNo,.orderData) Quit 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ITEMテーブルから行を削除する操作にも同じ考慮事項が適用されます。

データベースでトリガーを使用する次の例は、クライアントの作成日がORDER.invoiceDateフィールドに保存されるとすぐにクライアントの請求書を自動生成することです。 この機能は、ORDERテーブルの更新手順に非常に簡単に追加できます。

 setOrder(orderNo,data) ; new rec,itemNo,ok if orderNo="" Quit 0 ;    set data("totalValue")=0 set itemNo="" for set itemNo=$Order(^ITEM(orderNo,itemNo)) Quit:itemNo="" do . set ok=$$getItem(orderNo,itemNo,.itemData) . Set data("totalValue")=data("totalValue")+itemData("price") set rec=data("custNo")_"~"_data("orderDate")_"~"_data("invoiceDate") set rec=rec_"~"_data("totalValue") set ^ORDER(orderNo)=rec if data("custNo")`="" set ^ORDERX1(data("custNo"),orderNo)="" ; ;   CUSTOMER.totalOrders new custData Set ok=$$getCustomer(data("custNo"),.custData) Set ok=$$setCustomer(data("CustNo"),.custData) ; ;  -,     if Data("invoiceDate")`="" Set Result=$$invoiceOrder(orderNo) ; Quit 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、請求書を生成するために必要なすべての手順を実行するには、$$ invoiceOrder（）関数を記述する必要があります。



取引



データベースの完全な更新は、多くの場合、多くのテーブルに対する多数の更新で構成されます。 これらすべての関連する更新は、メインの更新（またはトランザクション）が完了したと見なされる前に完了することを保証する必要があります。



原則として、トランザクションはリレーショナルデータベースでデフォルトで有効になっています。 つまり、データベースへの変更は、変更プロセスがCOMMITコマンドを発行するまで記録されません。その後、すべての変更が確認され、新しいトランザクションが開始されます。



MUMPSはこの点で非常に似ていますが、トランザクションを明示的に含める必要がある点が異なります。 プログラムは、TCOMMITによって完了を確認するだけでなく、必ずトランザクションTSTARTを開始するコマンドを実行する必要があります。



SQL



現在のトランザクションを確認し、（暗黙的に）新しいトランザクションを開始します。

 COMMIT
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おたふく風邪



新しいトランザクションを開始します。

 TSTART
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

取引の確認：

 TCOMMIT
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

MUMPSシステムでトランザクション管理が明示的に有効になっていない場合、すべての更新が現在のリポジトリにすぐに適用されます。 つまり、グローバルまたはその要素に対するSETコマンドまたはKILLコマンドは、完了したトランザクションと見なすことができます。



結論



MUMPSを従来のリレーショナルデータベースよりも使用することには、多くの重要な利点があります。

• コードの再利用とメンテナンスの容易さ。 慎重なプログラミングにより、非常に高いレベルのコードの再利用を実現できます。 上記の例は、各テーブルのセット、取得および削除機能内のデータベースを使用してすべてのアクションをカプセル化する方法を示しています。 これらの関数を一度作成してから、必要に応じて使用します。
• 移植性。 データ構造定義は、それらと連携する関数内に含まれています。 データの定義とその実装に違いはありません。
• 柔軟性。 データを更新するコードは、システム内の任意のアクションまたはイベントでトリガーするように変更できます。
• パフォーマンスと最適化。 MUMPSの経験豊富なアナリストは、データベースを操作するために使用する機能を最適化する機会を見つけるでしょう。 これは、データの定義とそれらに対する操作の実装が特定の機能内に一緒に含まれているため可能です。 SQLを使用するアナリストは、トリガー、参照整合性アクション、およびトランザクションの処理方法を正確に制御できません。
• データ定義レイヤーを既存のMUMPSテーブル（グローバル）に透過的に重ね合わせることができるため、SQLを使用してデータを処理または取得する利点（特別なユーティリティを使用できます）は失われません。 これは後で行うことができます。 たとえば、 CachéSQLおよびサードパーティのユーティリティKB_SQLは、MUMPSグローバル上に本格的なSQL環境を実装します。