专题研究简报.pptVIP

專題研究簡報 周敬淳 高敏淞 吳鴻鑫 Q1作出轉換公式所需的INPUT? 有關領藥號的問題討論至今，目前的方向決定設計公式，讓AP Server可以直接轉換系統內碼成為領藥號 為了找出作出公式所需的INPUT，首先分析公式的運作模式 公式的運作模式 基本上 公式的運作應該是 內碼 - 公式 - 領藥號與藥台 而藥台與領藥窗口的對應資料10分鐘UPDATE一次。 然後重新製造出公式 由此可猜測作出公式所需的基本INPUT 作出公式的基本INPUT 目前內碼號碼 下張藥單的預定藥台 藥台與窗口的對應資料表(目前暫定沒有工作為0) 窗口與各窗口的目前最大領藥號資料表 INPUT的審視 目前內碼號碼 應可由取號機制那設計額外ROUTINE來取得 下張藥單的預定藥台 這個並非是系統的現成資訊，不過可以利用之前的的公式和目前內碼號碼+1得到 INPUT的審視 藥台與窗口的對應資料表(目前暫定沒有工作為0) 窗口與各窗口的目前最大領藥號 這個應該算是一個潛在的問題….. 因為系統目前設計的理念中，並沒有在領藥號後更新的機制，所以並沒有現成的資料表 這應該只好能用算的，並在每次UPDATE公式後，順便UPDATE 領藥號UPDATE 在每次要重新製造公式時，用前一次製造公式時的資料表和當時的最大內碼及目前的最大內碼，可以算出目前每個窗口的最大領藥號。 並把這次算出的數值UPDATE到資料表中，以留待下次使用。 修改後的INPUT 內碼號碼(前次和目前) 下張藥單的預定藥台 藥台與窗口的對應資料表(前次和今次) 窗口與各窗口的領藥號資料表(前次紀錄) 公式製作細部探討 令base =目前最大內碼 令t0 = 下一個預定藥台 C[]為目前工作藥台與數字轉換 M[]為記載藥台窗口對應的結構(新) Ex. Mn[A]代表A藥台所對應的窗口 W[]是記載窗口目前最大領藥號 Ex. W[1]代表1號窗口目前最大領藥號 N[]是紀錄窗口工作的藥台數 Ex.N[1]代表一號窗口工作的藥台數 F[]是紀錄前面有幾個藥台工作於同一窗口 Mnum是這次工作的藥台總數 公式製作細部探討 temp = base mod 5 If ( temp != 0) base = base + (5-temp); If ( index base) SwitchW(index) Else return( t0, Wo[t0]+5-(base-index)) 公式製作細部探討 Switch(Index){ Temp1 = index – base Temp2 = Temp1 mod 5 Temp1 = Temp1 / 5 Temp3 = Temp1 mod Mnum Temp4 = W[M[C[Temp3]]]+ N[M[C[Temp3]]]*Temp1*5+ F[M[C[Temp3]]]*5+Temp2 Return (M[C[Temp3]], Temp4 ) ] 公式的進化? 基本上目前公式的是以十分鐘更新而設計 但以實際狀況考量 更新的機率其實不高 大部分的排班都是在事前早已決定的 所以兼顧實用層面來講 亦可設計一個公式的 ”外掛” 公式成為組件 公式所需的INPUT中影響最大 應該是有關藥台與窗口的對應 亦即可設計一個公式的上級組件 按照需要供給所需的對應 例如: 一天有五個上班時段 上級組件可以按照時間來判斷 自動給予不同的對應資料表 按照此邏輯來推斷 亦可排出每月的上班表 Q2:資料的更新與傳輸 在目前AP cluster的架構下，選出適合的傳輸方式，同時必須考慮資料的存放與更新的問題。 Centralized 傳輸 Distributed 傳輸 資料的傳輸與更新(1) 重要的資料： 目前的內碼 藥臺─窗口的對照表 窗口的最大領藥號 內碼 – 統一由DB server的給號機來發送 對照表 窗口領藥號有處理方式的問題 Centralized VS. Distributed(1) Centralized 統一由一臺AP負責儲存資料 其他的AP的資料皆從該AP取得資料 資料的修改必須是對主要AP修改才生效 Distributed 每臺都有各自的資料 要注意資料的一致性 Centralized VS. Distributed(2) 完全Distributed幾乎不可行 會造成大量的信息 無法處理AP之間資料的時間差 只做部分的Distributed： 內圈的做好synchronization傳到外圈 外圈要修改時也扔到內圈做synchronization，之後才再扔到外圈 一台的修改方式 從AP Server的地方讀取目前排班的資料表 修改後 再傳輸回