110 高普考高考二級 資訊處理 系統分析與設計研究 考古題詳解

核心觀念

本題考查資料庫分析與設計，重點是把出差申請、行程地點、每日津貼及實支實付費用分開記錄，並以主鍵、外鍵串接。不同類型的資料分開存放，可避免同一趟出差有多個地點或多筆費用時，重複記錄申請人與出差基本資料。

題目未提供餐費津貼金額、住宿上限及出差日數計算規則，以下假設津貼金額及核銷規則由參數檔維護；交通費及住宿費依核准憑證實支核銷。

解題方法

先從原卷申請單擷取出差單號、姓名、工號、出差事由、說明、起始日期時間及結束日期時間，再依出差資料的關聯拆分資料表：

• 一位員工可提出多筆出差申請。
• 一筆出差申請可安排多個地點。
• 一筆出差申請可涵蓋多個出差日，每日分別計算餐費津貼及住宿情形。
• 一筆出差申請可有多筆交通、住宿等費用憑證。

以「出差單」作為主檔，其他資料以出差單號關聯。每日津貼與費用明細各自記錄，便於核算、查詢及追溯憑證。

（一）大致資料庫結構

1. 員工檔 EMPLOYEE

• **主鍵：**員工編號
• 欄位：員工編號、姓名、部門、職稱、在職狀態

姓名與工號雖出現在申請單上，正式系統以員工編號識別員工，姓名等資料由員工檔取得。

2. 出差申請主檔 TRIP

• **主鍵：**出差單號
• **外鍵：**員工編號
• 欄位：出差單號、員工編號、出差事由、說明、起始日期時間、結束日期時間、申請日期、申請狀態、核准人、核准時間

出差單號及申請單欄位依原卷圖示設計；核准相關欄位供系統流程管理使用。

3. 出差地點明細 TRIP_DESTINATION

• **主鍵：**出差單號＋地點順序
• **外鍵：**出差單號
• 欄位：出差單號、地點順序、地點名稱、到達日期時間、離開日期時間、拜訪目的

以「地點順序」記錄同一趟出差的多個地點，避免在出差主檔中以多個欄位固定存放地點。

4. 每日差勤津貼檔 TRIP_DAILY_ALLOWANCE

• **主鍵：**出差單號＋日期
• **外鍵：**出差單號
• 欄位：出差單號、日期、早餐津貼金額、午餐津貼金額、晚餐津貼金額、住宿夜數、住宿核銷金額、備註

逐日記錄津貼與住宿資訊，可依公司規則處理部分日、不同日期津貼及住宿核銷情形。

5. 實支費用明細 TRIP_EXPENSE

• **主鍵：**費用明細編號
• **外鍵：**出差單號
• 欄位：費用明細編號、出差單號、發生日、費用類別、起點、訖點、交通工具、金額、憑證號碼、憑證日期、核准金額、核銷狀態、備註

核心觀念

本題考的是 UML 類別圖：辨認類別、關聯、重數，以及類別中的屬性與方法。圖中的「業務經理、業務人員、銷售點、顧客、訂單、訂購品」是類別；連接類別的線表示類別之間的關聯。

每個類別方框分成名稱、屬性、方法三個部分。圖上以「屬性」與「方法」作為欄位標示，尚未列出實際內容。

解題方法與作答

（一）類別代表什麼？

這六個名稱代表銷售訂單系統中的六種物件類別，分別描述：

• 業務經理：負責管理業務人員或銷售點的人員。
• 業務人員：負責銷售業務、服務顧客的人員。
• 銷售點：公司進行銷售活動的據點。
• 顧客：向公司購買商品的對象。
• 訂單：顧客提出的購買紀錄。
• 訂購品：訂單中所包含的商品。

類別是同一類物件的共同描述；實際存在的某位經理、某筆訂單，則是該類別的個別物件。

（二）關聯與重數代表什麼？

圖中的關聯名稱表示類別之間的業務關係；線端的重數則表示：以關聯另一端的一個物件為基準，這一端可以對應幾個物件。

• 管理（業務經理—業務人員）：圖示重數為業務經理端 $1$、業務人員端 $0..*$。一位業務人員由一位業務經理管理；一位業務經理可管理零位或多位業務人員。
• 管理（業務經理—銷售點）：兩端皆為 $1$。每個銷售點對應一位業務經理，每位業務經理也對應一個銷售點。
• 分配到（銷售點—業務人員）：圖示重數為銷售點端 $1$、業務人員端 $0..*$。每位業務人員分配到一個銷售點；一個銷售點可分配零位或多位業務人員。

核心觀念

本題考查 ER Model（實體關係模型）的設計：先找出系統需要記錄的實體，再用關係與基數表示實體間的業務規則。重點是比較兩種流程的識別方式：

• 舊制以停車幣識別一次停車，消磁代表已完成折抵。
• 新制以車牌連結停車紀錄，並以發票或停車券 QR Code 核驗消費與折抵資格。

題目未指定發票能否拆分折抵、停車費如何付款，以下採用合理假設：一次停車可用多張發票折抵；一張發票只折抵一次；停車券可選擇性核發；系統記錄折抵與付款結果。

解題方法

先依流程辨認資料：

1. 進場時，系統建立一筆停車紀錄，並記下停車幣或車牌。
2. 購物後，顧客出示發票，系統檢查可折抵額並記錄折抵。
3. 離場時，系統結算停車費；舊制回收或消磁停車幣，新制依車牌找到停車紀錄並完成付款。

「一筆停車紀錄可搭配多張發票，一張發票至多用於一次折抵」屬多對多關係，因此以「折抵明細」實體記錄每次折抵額，避免把多張發票塞進同一個欄位。

（一）停車幣消磁方式的 ER Model

停車幣 1 ─── 0..* 停車紀錄 1 ─── 0..* 折抵明細 0..* ─── 1 發票

關係說明：

• 一枚停車幣可在不同時間重複使用，因此可對應多筆停車紀錄；每筆停車紀錄使用一枚停車幣。
• 一筆停車紀錄可有多筆折抵明細；每筆明細使用一張發票。
• 一張發票至多折抵一次；若業務規則允許拆分或重複核銷，基數須依規則調整。
• 消磁可視為停車幣狀態的變更；若需稽核服務中心的作業，可另加「服務人員」或「消磁紀錄」實體。

（二）新系統帶來的效益

1. 縮短離場與折抵時間： 顧客可自行選擇車號並掃描 QR Code，減少前往服務中心排隊。
2. 降低人力與營運成本： 減少人工核對發票、消磁停車幣及處理異常的工作量。
3. 減少實體停車幣管理： 降低停車幣製作、補發、回收、清點與設備維護成本。
4. 提高折抵正確性： 系統依發票資料計算可折抵額，並記錄核銷狀態，降低人工計算錯誤與重複折抵。
5. 改善顧客體驗： 免持停車幣、可自助完成折抵與繳費，流程更便利。

核心觀念

本題考查前台表單的資料驗證，以及「欄位格式正確」和「身分確實屬於輸入者」之間的差別。驗證可由淺入深分為：

• 欄位完整性：是否必填、是否漏填。
• 資料型態與格式：是否為規定的字元種類、格式或長度。
• 值域與內容檢查：數值是否在範圍內、代碼是否屬於允許清單。
• 欄位間一致性：多個欄位彼此是否相符。
• 檢查碼驗證：依公式檢查輸入值是否符合規則。
• 資料庫與業務規則驗證：資料是否存在、是否與權威紀錄相符，以及是否符合業務條件。

前台驗證能及早提示輸入錯誤；涉及身分或重要資料時，仍須由伺服器端再次驗證，並與可靠資料來源核對。

解題方法

先將題目要求拆成兩層：第一層確認身分證號的格式和檢查碼，排除常見輸入錯誤；第二層確認身分證號是否與健保卡卡號及後端資料相符。前者檢查資料本身，後者才是資料比對與身分辨識。

（一）一般前台欄位的資料驗證規則

常見規則如下：

1. 必填檢查：不可空白或只輸入空格。
2. 資料型態檢查：例如只能輸入數字、日期或英文字母。
3. 長度檢查：例如固定 10 碼，或介於最短與最長長度之間。
4. 格式檢查：以格式規則或正規表示式檢查，例如電子郵件格式、電話格式。
5. 值域檢查：數值須落在指定範圍內，例如年齡不得為負數。
6. 允許值檢查：輸入值須屬於指定清單，例如狀態代碼只能是特定選項。
7. 欄位間一致性檢查：例如確認密碼與確認密碼欄位相同。
8. 檢查碼驗證：依規定公式計算，確認代碼或編號具有合法的檢查碼。
9. 資料庫查核：檢查資料是否存在、是否重複，或是否與既有紀錄相符。
10. 業務規則檢查：確認輸入符合實際作業條件，例如使用者是否符合申辦資格。

（二）身分證號可使用的驗證規則

對一般國民身分證字號，可依序進行以下檢查：

1. 必填檢查：確認欄位有輸入內容。
2. 長度檢查：一般身分證字號為 10 碼。
3. 字元格式檢查：第一碼須為有效英文字母，其餘須為數字；