花卉批發市場交易作業流程斐氏圖

分析花卉批發市場交易作業流程的目的在於研究交易作業中的物流與資訊流的動 向，從 3.2 節的 IDEF0 流程圖中可看到五大流程的靜態細部內容，而完整的花卉批發市場 交易作業動態流程則可利用斐氏圖(Petri Net)[33]來表達。IDEF0 流程圖與斐氏圖之間的轉 換過程乃是以將 IDEF0 中的作業方格(Activity Box)視為斐氏圖中的轉移點(Transition)，代 表正在進行的動作；將 IDEF0 中的箭號(Arrow)視為斐氏圖中的暫存點，代表該物流或資 訊流的屬性狀態。當斐氏圖確定整個交易流程的物流與資訊流轉換流程沒有發生鎖死(Dead Lock)的情況[13]，爾後才設計整個交易資料庫的內容，以建置接下來要進行的花卉標準化 三階正規化資料庫。

本論文以 HPSim[30]軟體作為設計斐氏圖的工具，HPSim 是一套利用 C++語言撰寫而 成的斐氏圖設計軟體，並提供在網路上免費下載，它具備圖形化介面用來進行基本的斐氏 圖編輯與執行。以空心圓形圖示代表暫存點；長方形圖示代表轉移點；實心圓形代表實體 標記(Token)，根據第 3.2 節花卉批發市場交易流程 IDEF0 圖將作業方格與箭號轉換後，可 得到如圖 3.21 所示的斐氏圖；包含 25 個轉移點(Transition)及 58 個暫存點(Place)，其動態 行為乃由轉移點的激發來控制。

圖 3.21 花卉批發市場交易作業流程斐氏圖

本論文實驗以 300 批花卉作為初始值進行斐氏圖動態模擬，模擬花卉在完成進貨後於 批發市場交易流程中所花費的時間。在此設定理貨作業各轉移點所需時間共為 0.05 秒；拍 賣作業所需時間為 0.01 秒；分貨作業與領貨作業各為 0.01 秒。從圖 3.21 可發現：進貨作 業還有 170 批花卉尚未完成；理貨作業中共有 58 批花卉在等待 OP 作業處理；拍賣線甲與 拍賣線乙上各有 1 批與 5 批花卉完成拍賣等待條碼機辨認條碼，正在作業中的花卉共 6 批；

截至目前已經過 13 秒，共有 60 批交易完成的花卉，而交易流程中的 WIP 量有 70 批花卉。

實驗跑完 300 批花卉共需 60.3 秒。確定斐氏圖沒有發生鎖死(Dead Lock)後，其動態行為觀 察顯示其資料是有效的，接著著手設計整個交易資料庫的內容，以建置接下來要進行的花 卉標準化三階正規化資料庫。

第四章 花卉資料庫三階正規化分析與設計

本章的主要目的在對花卉批發市場進行關聯式資料庫三階正規化分析與設計，共分為 兩小節。第 4.1 節說明「設計階層(Design Layer)與花卉資料庫設計」，第 4.2 節說明「台灣 五大花卉批發市場資料庫三階正規化分析」。

4.1 設計階層與標準化花卉資料庫設計

設計階層(Design Layer)是用來為設計應用發展程序(Application Development Process) 目的而做的一個單一資料模型(Data Model)或一組資料模型[25]。階層可視為建構資料模型 時的階段性目標，例如建構一套 ERP 系統時，其中包含的生產管理模組、財務會計模組、

供應商管理模組等每個模組都是單一資料模型設計階層；包含兩個以上不同模組所構成的 設計階層則是一組資料模型。每一個設計階層皆為階層式架構模型的一部份，如圖 4.1[25]；第一階為邏輯模型，第二階為實體模型，第三階為特定資料庫實體模型。圖 4.2 為設計階層與花卉批發市場資料庫設計的關係對照圖。

圖 4.1 設計階層的架構示模型圖

1. 第一階層(邏輯模型)：此階層為概念性邏輯資料模型(Conceptual Logical Data Model)，

目的是要擷取公司在設計一套應用發展程序時的需求。以房屋設計為例，第一階層就 好比將顧客的需求畫成一張房屋設計藍圖，藍圖內容必須包含顧客對房屋的期待，如 浴室、客廳、臥室廚房等配置方式。對花卉批發市場建構交易作業資料庫系統而言，

第一階層必須討論花卉批發市場於資料庫系統最基本的需求為何？例如做資料庫設 計的目的是提高效率、降低成本等；對資訊方面的需求是資料內容包含承銷人資料、

供應人資料、花卉資料、拍賣資料等；對系統特性要求能分成多個應用系統包含帳務 系統、拍賣系統等；在邏輯模型中就是把公司這些需求建立實體關係模型(ER Model)，

並將資料間的關聯性與資料的屬性畫成實體關係圖(ER Diagram)。

2. 第二階層(實體模型)：此階層為一般通稱的實體模型(The Generic Physical Model)，目 的是要將邏輯模型中的公司需求轉換成資料庫可執行的規則。以房屋設計為例，完成 第一階層藍圖後必須將藍圖合理化並設計管線配置、水電設施、插座安排、樑柱規劃 等實體設計，這些步驟就是第二階層實體模型。對花卉批發市場建構交易作業資料庫 系統而言，第二階層必須把第一階層設計的實體關係模型轉成關聯式資料庫模式並建 立出三階正規化的關聯式資料庫模式。

3. 第三階層(特定資料庫實體模型模型)：此階層為特定資料庫實體模型(Database-specific Physical Models)，目的是將第二階層設計好的關聯式資料庫模型轉到不同的系統介面 上實際執行。以房屋設計為例，將藍圖合理化之後就從紙上談兵轉到實體用鋼筋水泥 蓋出房子，此為第三階層。對花卉批發市場建構交易作業資料庫系統而言，第三階層 的工作在於將第二階層已經建立好的三階正規化關聯式資料庫模式轉到 SQL Server、

Oracle、DB2 等資料庫系統介面，為配合花卉批發市場整體軟硬體系統介面，故選擇 SQL Server2000 系統作為特定資料庫實體模型。

圖 4.2 設計階層與花卉批發市場資料庫設計關係對照圖

若將上述的階層式架構模型從單一花卉批發市場規模擴展到整體花卉產業規模，那麼 花卉產業的交易資訊將會分為兩套子系統分別是：訂單輸入系統(Order Entry System)與銷 售追蹤系統(Sales Tracking System)，如圖 4.3[25]所示。對照國內花卉產業的五家花卉批發 市場，每家花卉批發市場的交易資訊都會建立一套訂單輸入系統階層式架構，那麼五家花 卉批發市場就有五套訂單輸入系統；進而再增加一套銷售追蹤系統後，可對整體花卉產業 進行銷售追蹤、分析與預測的管理，即國內目前花卉業務情報(Flower Business Intelligence, FBI)之花卉批發資訊分享熱線(Wholesale Information Sharing Hotline, WISH)的資料倉儲系

設計階層的階層式架構圖 花卉批發市場資料庫設計階層式架構圖

設計花卉資料需求之 實體關係模型(ER Model)

將實體關係模型轉為 三階正規化關聯式資料庫

將三階正規化關聯式資料庫轉到 SQL Server2000 系統介面執行

統[7]。

圖 4.3 花卉產業設計階層圖

一般而言，因為每個階層各代表不同時期的模型系統，換句話說，系統無法在同一個 模型中呈現設計程序(Design Process)內的各個階層(Layers)，取而代之的是必須強調階層內 容的ㄧ致性與同步性，使能夠在同一套系統中具備以下功能：

1. 建構不同階層間的關聯性並將之連結。

2. 在每個階段裡面,作不同的設計決策,並紀錄各階段的轉換過程(Transform)。

3. 進行維護工作,當不同階層內容有所改變時,能同步進行更動。

而 ERWIN 軟體能提供上述階層間環環相扣的關係連結、轉換與維護。故第五章將利用 ERWIN 軟體設計標準化花卉三階正規化資料庫系統。

4.2 台灣五大花卉批發市場資料庫三階正規化分析

花卉批發市場的交易資料庫的目的乃是儲存花卉批發市場作業流程的資訊檔案內 容，進而促進花卉批發市場資訊作業處理的電子化。然而目前國內五家花卉批發市場的資 料庫都沒有經過三階正規化，本節將根據第 4.1 節的設計階層理念，分成五小節對國內五 大花卉批發市場的資料庫作三階正規化分析。第 4.2.1 節說明「台北花市資料庫現況與三 階正規化分析」；第 4.2.2 節說介紹「彰化花市資料庫現況與三階正規化分析」；第 4.2.3 節介紹「台中花市資料庫現況三階正規化分析」；第 4.2.4 節說介紹「台南花市資料庫現 況與三階正規化分析」；第 4.2.5 節說介紹「高雄花市資料庫現況與三階正規化分析」。

五家花市各自的原始檔案儲存模式可視為設計階層中的邏輯模型，忠實呈現出各花市 在資料庫檔案規格上的需求。而根據各家花市的原始資料表格式，利用三階正規化方法中 的分解法(Decomposition)將傳統的檔案系統轉為三階正規化的關聯式資料庫，此步驟可視 為設計階層中的實體模型。

4.2.1 台北花市資料庫現況與三階正規化分析

台北花卉市場交易資料的處理狀況目前僅只於建立原始資料表格式，用以作為檔案儲 存的依據，然而各個資料表各自獨立，並無進行資料庫三階正規化設計。因此原始資料表 鎖儲存的資料量相當多且複雜，故使用起來雖然單純但是在搜尋或修改及其他加値運用的 效用上卻相當貧瘠。

台北花卉的原始資料表共五張[13]，分別是：表 4.1 台北花市承銷人資料表，目的在於 建立承銷人詳細資訊方便查詢承銷人資料，內容包括承銷人姓名、身分證字號、住址、電 話、商號、繳款狀況等；表 4.2 台北花市供應人資料表，紀錄供應人的姓名、地址、電話、

所屬供應團體等基本資料；表 4.3 台北花市日交易資料表，主要目的是紀錄每日的交易資 料，包括交易日期、承銷人代號、供應人代號、花卉代號、數量、單價等，這是每筆交易 最重要的資料內容；表 4.4 台北花市花卉資料表，紀錄台北花市供應人的供應花卉資料，

包括花卉代號、品名、類別等資料；表 4.5 台北花市日進貨資料表，此資料表主要目的是 在理貨作業時，登錄貨車司機繳交的進貨資料表內容，包括進貨日期、供應商代號、花卉 代號、等級、箱數、理貨員、台車等資料。

表 4.1 台北花市承銷人資料表

表 4.2 台北花市供應人資料表

欄位名稱 欄位說明

SU_NO 供應商代號 SU_GR_NO 供應團體代號 SU_GROUP 供應團體 SU_NAME 供應人名稱

SU_TT_ID 匯款(1.信 2.電 3.金 4.其他) SU_BANK 匯款銀行代號

SU_AC_KIND 帳戶種類 SU_AC_NAME 戶名 SU_ACC_NO 帳號

SU_ADDR1 供應人地址 1 SU_ADDR2 供應人地址 2 SU_TEL1 電話 1

SU_TEL2 電話 2 SU_FAX 傳真號碼 SU_IDNO 身分證字號 SU_REG_ID 登記碼(同語音碼)

SU_KIND 供應類別(1.農會合作社 2.供應團體所屬花農 3.個人 4.進口商 5.行口商 8.花

SU_KIND 供應類別(1.農會合作社 2.供應團體所屬花農 3.個人 4.進口商 5.行口商 8.花