【正文】 允許數(shù)據(jù)進入數(shù)據(jù)庫，編寫程序?qū)崿F(xiàn)業(yè)務規(guī)則，如，只有在某些數(shù)據(jù)項都不為空，且匹配正確后才能執(zhí)行業(yè)務流程的下一個事件。（3） 對業(yè)務流程的分析① 確定業(yè)務流程中的有關事件，用準確概述事件特征的描述符描述事件（如，銷售商品、裝運商品給顧客等） ，確定事件何時發(fā)生（事件發(fā)生的絕對時間）及在業(yè)務流程中發(fā)生的順序（事件發(fā)生的相對時間） ；② 確認與每一事件有關的資源、參與者、地點 14等實體；③ 識別事件、資源、參與者等的相關屬性，對事件、資源、參與者等的控制要求；④ 確定實體與實體間的聯(lián)系，實體與實體間的聯(lián)系分為：a. 1 對 1（1:1）：兩個實體集中，對于實體集 A 中的一個實例，實體集B 中至多有一個實例與之一一聯(lián)系，反之亦然，如，現(xiàn)金銷售中，一次銷售對應一次現(xiàn)金收款；b. 1 對多（1:n）：兩個實體集中，對于實體集 A 中的每一個實例，實體集 B 中有 n（ n≥0）個實例與之聯(lián)系，反之，對于實體集 B 中的每一個實例，實體集 A 中至多只有一個實例與之聯(lián)系，如，一個客戶對應多筆銷售，反過來，一筆銷售至多對應一個客戶；c. 多對多（m:n）：兩個實體集中，對于實體集 A 中的每一個實例，實體集 B 中的 n（n≥0）個實例與之聯(lián)系，對實體集 B 中的每一個實例，實體集A 中的 m（m≥0）個實例與之聯(lián)系，如，一個供應商對應多種存貨，一種存貨也會對應多個供應商。3．2．2 基于關系模型建模REA 模型是將關于數(shù)據(jù)庫的概念模型 ER 圖用于數(shù)據(jù)建模的基礎上發(fā)展得到14 多數(shù)情況下，地點可以從資源、參與者所在地判斷出來，因此，只有在必要的時候，才將地點單獨反映。24 / 51的會計信息系統(tǒng)的數(shù)據(jù)概念模型，因此 REA 模型要求基于關系模型建模。（1） 關系模型的約束性條件在第 2 章中介紹了關系模型的特點，由于關系模型具有約束性限制的優(yōu)點，保證了基于關系模型的數(shù)據(jù)庫管理系統(tǒng)（Data Base Management System, DBMS）簡單易用，提高了數(shù)據(jù)管理的效率和效果。因此，在基于關系模型建立數(shù)據(jù)模型的過程中，應充分利用由數(shù)據(jù)庫管理系統(tǒng)自動支持的約束性限制，它們是：① 主鍵（即主關鍵字）必須唯一：主鍵是用來唯一標識數(shù)據(jù)表中的每一行的單個屬性或?qū)傩缘慕M合。為保證主鍵的唯一，主鍵不能為空。該原則被稱為實體完整性規(guī)則。② 每一個外鍵必須為空或等于另一數(shù)據(jù)表中主鍵的值：外鍵是與另一關系中的主關鍵字相對應的屬性列。該原則被稱為參照完整性規(guī)則，保證兩張數(shù)據(jù)表中的數(shù)據(jù)一致。另外，用戶還可以定義針對某一應用環(huán)境的完整性約束條件，由系統(tǒng)提供定義和檢驗這類完整性規(guī)則的機制，由系統(tǒng)用統(tǒng)一的方式來處理這些自定義的完整性約束，而不是由具體的應用程序來完成這項工作，如值域控制。這也在一定程度上保證了系統(tǒng)的安全性和易維護性（只需維護自定義完整性約束，而無需顧慮對具體的應用程序的影響） 。（2） 建立關系數(shù)據(jù)模型從面向業(yè)務流程建立的模型（REA 模型）出發(fā)，為業(yè)務流程中有關事件、資源、參與者等實體及這些實體間多對多的聯(lián)系建立數(shù)據(jù)表。① 為業(yè)務流程中的每個實體建立一個實體數(shù)據(jù)表a. 名稱：該數(shù)據(jù)表的名稱就是實體的名稱；b. 主鍵：為便于操作和控制，常常對實體數(shù)據(jù)表中的每一個記錄（即每一行）生成一個數(shù)字代碼，以該數(shù)字代碼作為主鍵，如，訂單號、發(fā)票號、存貨代碼、供應商代碼等；c. 非鍵屬性：非鍵屬性包括這樣幾類：?。I(yè)務發(fā)生后自然生成的屬性，即事件涉及的時間、地點等，與事件相關的資源數(shù)量、金額，參與者（授權(quán)人、執(zhí)行人、審核人等）的名稱等；ⅱ）為了保證數(shù)據(jù)處理的正確執(zhí)行，人為設置的屬性，主要是一些控制業(yè)務流程進行的邏輯型字段。② 為實體之間的多對多聯(lián)系建立數(shù)據(jù)表當實體集 A 與實體集 B 的聯(lián)系是 m:n，要為這種聯(lián)系建立一個聯(lián)系數(shù)據(jù)表（簡稱表 C） ，將實體集 A 與實體集 B 的 m:n 聯(lián)系轉(zhuǎn)化成：實體集 A 與表 C的 1：m 聯(lián)系和實體集 B 與表 C 的 1：n 聯(lián)系。反映 m:n 聯(lián)系的關系數(shù)據(jù)表的要素：a. 名稱：將產(chǎn)生 m:n 聯(lián)系的兩個實體的名字相連，作為關系數(shù)據(jù)表的名25 / 51稱；b. 主鍵：兩個實體集的主鍵的組合作為該關系數(shù)據(jù)表的主鍵，這一類型的主鍵又稱為連接鍵；c. 非鍵屬性：使兩個實體集產(chǎn)生聯(lián)系的屬性 15。例如，產(chǎn)品實體與零件實體之間為 m:n 的聯(lián)系，可得到如下三個數(shù)據(jù)表（數(shù)據(jù)表表示方式：數(shù)據(jù)表名稱（主鍵、[外鍵]、非鍵屬性…） ）：a. 實體數(shù)據(jù)表：產(chǎn)品（產(chǎn)品號、產(chǎn)品名、規(guī)格） 、零件（零件號、零件名、庫存量）b. m:n 聯(lián)系數(shù)據(jù)表：產(chǎn)品零件構(gòu)成（[產(chǎn)品號]、[零件號]、數(shù)量） ，其中，構(gòu)成產(chǎn)品的零件數(shù)量是使產(chǎn)品和零件產(chǎn)生 m:n 聯(lián)系的屬性。③ 實現(xiàn) 1:1 聯(lián)系利用外鍵實現(xiàn) 1:1 聯(lián)系，即將實體集 A 的主鍵設置為實體集 B 的外鍵，反之亦可。特別注意的是如果是兩個事件之間存在 1:1 關系，則應選擇先發(fā)生的事件中的主鍵作為后發(fā)生的事件的外鍵，以此來反映事件發(fā)生的順序。④ 實現(xiàn) 1:n 聯(lián)系同樣利用外鍵，選擇父方（1 方）的主鍵作為子方（多方）的外鍵。在③和④中如果發(fā)生關系的實體是事件與資源或事件與參與者，一般將資源數(shù)據(jù)表、參與者數(shù)據(jù)表中的主鍵作為事件數(shù)據(jù)表的外鍵。如，銷售事件表中，放入存貨代碼、顧客代碼、銷售人員代碼等。由以上數(shù)據(jù)表可以生成與事件有關的原始憑證及信息用戶所需的其他視圖。3． 基于企業(yè)語義建模由于企業(yè)是一個價值鏈，所有業(yè)務流程必須銜接良好才能保證價值鏈的正常動作，因此，數(shù)據(jù)模型不只是對單一業(yè)務流程的抽象，而是要將所有業(yè)務流程集成起來，建立基于企業(yè)語義的模型。基于企業(yè)語義建模首先要根據(jù)業(yè)務流程之間的聯(lián)系，消除各業(yè)務流程的數(shù)據(jù)模型之間的沖突，實現(xiàn)業(yè)務流程的集成，其中要解決的沖突有：① 屬性沖突：即統(tǒng)一各業(yè)務流程中相同事件、資源、參與者的屬性值的類型，屬性取值單位（如米與分米相統(tǒng)一）和取值范圍；② 命名沖突：對同一事件、資源、參與者，應統(tǒng)一它們在各個業(yè)務流程的模型中的命名，同時要找出不同業(yè)務流程中命名相同但性質(zhì)不同的屬性，更改這些命名；③ 結(jié)構(gòu)沖突：同一實體在不同業(yè)務流程中屬性組成不同，一般用各業(yè)務流程中同一實體屬性的并（即包含同一實體在不同業(yè)務流程中出現(xiàn)過的所有屬15 實體集之間產(chǎn)生多對多聯(lián)系的原因并無量化指標時，可以沒有非鍵屬性。26 / 51性）解決沖突；④ 確定觸發(fā)機制：業(yè)務流程之間的連接關系最終要轉(zhuǎn)換成一定的觸發(fā)機制，即將使業(yè)務流程產(chǎn)生連接關系的實體為觸發(fā)器，當上游業(yè)務流程中該實體的相關屬性值發(fā)生一定的變化時，觸發(fā)相連業(yè)務流程中的相應事件。在解決沖突后，綜合企業(yè)業(yè)務流程的模型才能成為被各方面用戶理解和接受的統(tǒng)一的模型，而且能夠部分解決數(shù)據(jù)倉庫的數(shù)據(jù)源不一致問題 16。其次，要消除不必要的冗余，即冗余的數(shù)據(jù)（如那些可以由數(shù)據(jù)表中已有數(shù)據(jù)計算得出的數(shù)據(jù)，如存貨入庫金額、收到客戶訂單到產(chǎn)品裝運的時間等）或?qū)嶓w間冗余的聯(lián)系。不過，有時為了提高查詢的效率，會保留一些冗余數(shù)據(jù)（存貨入庫金額就是一例） ，根據(jù)應用需求應保留這些數(shù)據(jù)，但應定義相應的完整性約束條件，以保證更新數(shù)據(jù)表時，自動觸發(fā)完整性檢查例程，修改存在于另一數(shù)據(jù)表的冗余數(shù)據(jù)。3． 面向?qū)ο蠼EA 模型與面向?qū)ο蠓椒ㄓ邢嗤闹笇枷耄琑EA 模型應用構(gòu)成業(yè)務流程的事件、資源、參與者及它們之間的聯(lián)系來實現(xiàn)對業(yè)務流程的模擬，面向?qū)ο蠓椒▌t是通過構(gòu)成客觀世界的對象以及對象之間的聯(lián)系和作用來實現(xiàn)對客觀世界的模擬。事件、資源、參與者的屬性實際上就是對象中的數(shù)據(jù)。另外，REA 模型中的事件需要一個記錄過程來收集描述事件和記錄事件的數(shù)據(jù)，而每個資源、參與者和地點則需要一個維護過程來添加、刪除和更新各自的數(shù)據(jù)，應用面向?qū)ο蠓椒蓪⑹录?、資源、參與者的屬性及其記錄或維護過程封裝起來。由此可見，將REA 模型與面向?qū)ο蠓椒ㄏ嘟Y(jié)合，有助于靈活地為企業(yè)的復雜數(shù)據(jù)結(jié)構(gòu)建立數(shù)據(jù)模型，也有利于發(fā)揮面向?qū)ο蠓椒ǖ膬?yōu)點。同時，REA 的基于結(jié)構(gòu)化的特點使 REA 的層次可以與面向?qū)ο笾蓄惖膶哟蜗嘟Y(jié)合。也就是說，由于 REA 模型既可以表示具體的業(yè)務流程中的事件、資源、參與者，又可以將事件、資源、參與者概念化，從企業(yè)層面反映業(yè)務流程，可將REA 的這一特點與面向?qū)ο蠓椒ㄏ嘟Y(jié)合，將概念化程度最高的業(yè)務流程中的事件、資源、參與者視為概括度最高的父類，最高層次的 REA 模型逐層向下分解，這些父類就可以向下創(chuàng)建其子類，對子類的某些屬性及操作進行修改，就可以建立下層業(yè)務流程的相應對象。如，將存貨作為父類，向下可以創(chuàng)建原材料子類、半成品子類、產(chǎn)成品子類等，由原材料子類又可以創(chuàng)建其子類，如按存貨 ABC 法將存貨分類創(chuàng)建 A 類存貨、B 類存貨、C 類存貨。對這些子類分別修改其屬性和操作，如原材料的代碼、原材料數(shù)據(jù)的維護，A、B、C 類存貨的管理規(guī)則等。3．2．5 面向電子商務的發(fā)展建模 1716 下文將進一步介紹。17 電子商務實際上是采用大量的信息技術實現(xiàn)業(yè)務流程，面向業(yè)務流程建模已涵蓋了采用電子商務的業(yè)務流程，但鑒于電子商務在現(xiàn)階段及今后很長一段時期的重要性，本節(jié)集中討論面向電子商務建模的問題。27 / 51電子商務的發(fā)展要求供應鏈中企業(yè)間的最優(yōu)協(xié)調(diào)，以及對最終顧客的快速響應和優(yōu)質(zhì)服務，因此與供應鏈中其他企業(yè)及與顧客有關的數(shù)據(jù)也需要在數(shù)據(jù)模型中得到反映。由于其他企業(yè)、顧客的相關數(shù)據(jù)相對本企業(yè)而言是外部數(shù)據(jù)，要實現(xiàn)外部數(shù)據(jù)與企業(yè)內(nèi)部數(shù)據(jù)的雙向流動，就必須建立一定的接口數(shù)據(jù)模型，具體來說：（1）面向 B2B 電子商務建模① 支持信息交換的數(shù)據(jù)轉(zhuǎn)換模型信息交換技術是 B2B 電子商務的基礎，信息交換技術中已規(guī)定了標準的業(yè)務數(shù)據(jù)格式，要解決的問題是：如何將業(yè)務數(shù)據(jù)庫中的數(shù)據(jù)轉(zhuǎn)換為標準數(shù)據(jù)格式，及如何將標準數(shù)據(jù)格式中的數(shù)據(jù)轉(zhuǎn)換為業(yè)務數(shù)據(jù)庫中的數(shù)據(jù)，因此，要建立支持信息交換的數(shù)據(jù)轉(zhuǎn)換模型。B2B 電子商務信息交換的主流技術是 EDI 技術，EDI 的核心本質(zhì)是：被處理業(yè)務采用數(shù)據(jù)格式的國際統(tǒng)一標準。EDI 中標準的數(shù)據(jù)格式包含三個要素：數(shù)據(jù)元、數(shù)據(jù)段、標準報文格式。以聯(lián)合國標準化組織的 UN/EDIFACT 為例，這三個要素的定義為：? 數(shù)據(jù)元（data element）：在確定的上下文中被認為不可再細分的數(shù)據(jù)單元；? 數(shù)據(jù)段（data segment）：功能相關的數(shù)據(jù)元值的預定義和標識的集合。段以段標記開始，以段終止符結(jié)束，可以是為電子傳送提供信息服務的服務段，也可以是反映單證（一般固定不變，可由人或機器閱讀的記錄數(shù)據(jù)的數(shù)據(jù)載體）中具有一定功能的項的用戶數(shù)據(jù)段；? 標準報文（standard message）：用于傳送信息的有序字符列，一張標準報文規(guī)定了一組特定含義的項的集合，它可以與業(yè)務單證對應起來。該三要素意味著相關原始憑證與票據(jù)的電子化，這種電子化的單證通過 EDI軟件可以直接進入企業(yè)業(yè)務數(shù)據(jù)庫或由企業(yè)業(yè)務數(shù)據(jù)庫中的數(shù)據(jù)生成。EDI 軟件結(jié)構(gòu)包括：用戶接口模塊、內(nèi)部接口模塊、報文生成及處理模塊、格式轉(zhuǎn)換模塊、通信模塊。用戶接口模塊、內(nèi)部接口模塊和報文生成及處理模塊的基礎數(shù)據(jù)模型就是支持 B2B 電子商務建模的關鍵。該模型中要包括兩類數(shù)據(jù)表，一類數(shù)據(jù)表反映來自用戶接口模塊和內(nèi)部接口模塊的命令和信息中的屬性（字段） ，以及所需生成的 EDI 報文中的數(shù)據(jù)元；另一類數(shù)據(jù)表則反映這些命令和信息與 EDI 報文數(shù)據(jù)元的映射關系。隨著 Inter 安全性及網(wǎng)絡法律規(guī)范的完善，Inter 將成為企業(yè)信息交換的理想平臺，在 Inter 上運行 EDI 主要有以下幾種技術，要在了解這些技術的基礎上，建立與這些技術相容的用戶接口模塊、內(nèi)部接口模塊和信息生成和處理模塊。28 / 51a. XML/EDI：以可擴展的標記語言 XML 為基礎。XML 表示數(shù)據(jù)的內(nèi)容和邏輯關系，包含一組基本法則，用于描述諸如購物定單中產(chǎn)品規(guī)格、價格、件數(shù)、送貨方式等。XML 支持結(jié)構(gòu)化的數(shù)據(jù)，可以詳細定義某個數(shù)據(jù)對象的數(shù)據(jù)結(jié)構(gòu)，具有統(tǒng)一的數(shù)據(jù)格式，允許不同格式的數(shù)據(jù)互相交換。另外，XML/EDI 引進模板概念，解決數(shù)據(jù)的轉(zhuǎn)換問題，模板描述了數(shù)據(jù)對象的數(shù)據(jù)結(jié)構(gòu)及對數(shù)據(jù)的解釋，利用軟件代理自動完成數(shù)據(jù)轉(zhuǎn)換。b. OBI：是互聯(lián)網(wǎng)開放式購物標準，技術路線沿襲了美國標準 ANSIX12 與聯(lián)合國/歐洲經(jīng)濟委員會 EDIFACT 系列，將原先封閉的各項 EDI 標準經(jīng)修改、擴充、集成后移植到互聯(lián)網(wǎng)上，按規(guī)定流程在企業(yè)間傳輸數(shù)據(jù)；OBI 報文的單元化、層次化結(jié)構(gòu)體系：數(shù)據(jù)元——數(shù)據(jù)段——功能組——業(yè)務集，以底層的數(shù)據(jù)元為基本標準單元，每一層均以下一層為單元，按規(guī)定的位置和序列拼裝而成。OBI 數(shù)據(jù)轉(zhuǎn)換要運用程序語言、動態(tài)網(wǎng)和有關的 WEB 數(shù)據(jù)庫連接技術，編寫靈活的轉(zhuǎn)換程序來解決。② 電子票據(jù)的相關數(shù)據(jù)電子票據(jù)是互聯(lián)網(wǎng)和電子商務環(huán)境下重要的信息載體，要以相應數(shù)據(jù)及數(shù)據(jù)結(jié)構(gòu)支持對電子票據(jù)的管理要求：a. 可鑒別：加蓋數(shù)字時間戳和數(shù)字簽名 18，以辨別真?zhèn)?；b. 可傳輸：把來自各個數(shù)據(jù)源的不同格式的電子票據(jù)按標準化的數(shù)據(jù)結(jié)構(gòu)格式化，并封裝、加密后進行傳輸；c. 可存儲：以標準化的結(jié)構(gòu)格式妥善保存；d. 操作控制：設立數(shù)據(jù)源描述，操作日志保證來源不同的電子票據(jù)數(shù)據(jù)的原始性；e. 授權(quán)處理：電子票據(jù)中預留權(quán)限字段，只有相應的權(quán)限才能對電子票據(jù)進行相關處理，如，輸出，由電子票據(jù)產(chǎn)生相應的電子發(fā)票。③ 網(wǎng)上支付的數(shù)據(jù)驗證網(wǎng)上支付要驗證參與各方的身份，同時要保證每一筆網(wǎng)上支付業(yè)務經(jīng)授權(quán)方可進行，企業(yè)內(nèi)部數(shù)據(jù)與支付參與方的