|
( ) | 1.下列何者是維度資料表(Dimension table)的基本結構 (1) 主鍵(Primary Keys) (2) 代理鍵(Surrogate Keys) (3) 自然鍵(Natural Keys) (4) 外來鍵(Foreign Keys)
(76) |
|
| (1) | I don't know |
|
| (2) | 123 |
|
| (3) | 234 |
|
| (4) | 134 |
|
| (5) | 124 |
|
( ) | 2.下列關於維度模型(Dimensional Model)之敘述何者有誤
(69) |
|
| (1) | 維度模型又稱為星狀綱要 |
|
| (2) | 維度之劃分建議以管理上的 3 個 H 以及 1 個 W 來進行劃分 |
|
| (3) | 維度模型工作必須辨別且擷取出可衡量的數值資料部分以及情境化的文字敘述資料部分 |
|
| (4) | I don't know |
|
| (5) | 維度模型的特點有容易瞭解、查詢快、均衡的維度資料表及可以容納非預期中的新資料 |
|
( ) | 3.資料立方體的基本組成元件中，包括下列哪一個 (1) 組成事實 (2) 組成維度 (3) 維度中的屬性之階層分析 (4) 資料立方體計算與儲存的方法與時機 (5) 匯流排架構 (6) 資料封包
(79) |
|
| (1) | 1234 |
|
| (2) | 246 |
|
| (3) | I don't know |
|
| (4) | 1345 |
|
| (5) | 346 |
|
( ) | 4.在維度模型中，有關維度資料表內的欄位描述何者錯誤
(63) |
|
| (1) | 如果欄位值有缺失，即便是填入虛值(Null Value)也不會造成該筆資料無法被查詢到 |
|
| (2) | I don't know |
|
| (3) | 欄位名稱具詳盡性(Verbose)，盡量不厭其煩的用全文命名 |
|
| (4) | 如果欄位值有缺失，建議以「未知的(Unknown)」或者「未符合(No Applicable, N/A)」當作填入值 |
|
| (5) | 完整的欄位名稱才能幫助大家了解報表的意涵，盡量要與所描述的事情內容一致 |
|
( ) | 5.關於變動緩慢的維度資料表記錄方式(Slowly Changing Dimensions, SCD)的處理方式，Kimball提出幾種對應的方法，在實務上哪一種方法最簡單，不需要特別撰寫程式來維護資料，查詢資料的程式也最簡單，但是會有造成資料錯誤的疑慮
(67) |
|
| (1) | I don't know |
|
| (2) | 新增加一筆維度資料 |
|
| (3) | 直接改寫維度屬性資料 |
|
| (4) | 新增加一個維度屬性 |
|
| (5) | 刪除並更新一筆維度資料 |
|
( ) | 6.在維度模型中，下列哪一個有關日期或時間資料的設計描述是錯誤的
(65) |
|
| (1) | 日期是每一個維度模型都絕對不會出現的維度資料表 |
|
| (2) | 如果有專案上的需求將日期與時間資料當作可以加總的數值資料處理，則日期與時間資料可以直接當作事實資料 |
|
| (3) | 如果將日期與時間資料放在同一張維度資料表中，會產生太多筆的資料，可以將日期與時間資料分別獨立儲存成日期維度資料表以及時間維度資料表，這兩個維度資料表皆直接與事實資料表連接 |
|
| (4) | 如果專案需求中必須提供工作或任務所花費的時間間隔(Time Interval)，則可以將時間資料轉換成相對應的數值資料並放入事實資料表中成為一個可計算的欄位，報表呈現時候再透過計算時間間隔的公式產生一個延伸性欄位供企業主參考 |
|
| (5) | I don't know |
|
( ) | 7.資料立方體的基本組成元件中，在組成維度方面，不包括下列哪一個
(78) |
|
| (1) | 維度表的組成屬性 |
|
| (2) | 維度對應關係 |
|
| (3) | 維度與事實的對應關係 |
|
| (4) | I don't know |
|
| (5) | 維度表 |
|
( ) | 8.下列有關變動快速龐大型維度資料表(Rapidly Changing Monster Dimension Tables)的描述何者正確 (1) 以新增加一筆維度資料技術來處理效率極高 (2) 解決方法就是分離(Break Off)原來維度資料表中經常改變維度屬性值的欄位 (3) 可以利用退化維度(Degenerate Dimensions, DD)技術處理(4) 可以採用半可加性(Semi-Additive)數值資料處理 (5) 將連續型數值欄位帶狀化(Banded)，使成為帶狀值後再儲存到迷你維度資料表中會讓分離技術更有效率 (6) 迷你維度資料表在使用上毫無缺陷是個完美的技術 (7) 被分離開且規模較小的維度資料表稱為迷你維度資料表(Mini-DimensionTables) (8) 當第一次分離出一個迷你維度資料表時，如果迷你維度資料表的資料量還是成長很快，則須要進行第二次分離，另外成立第二個迷你維度資料表(Second Mini-Dimension Table) (9) 利用直接改寫維度屬性資料技術可以增加效率
(68) |
|
| (1) | 2578 |
|
| (2) | 13469 |
|
| (3) | 278 |
|
| (4) | 13579 |
|
| (5) | I don't know |
|
( ) | 9.在實務上維度模型使用代理鍵有很多利益，包含下列哪些選項 (1) 查詢效率(Performance) (2)整合不同來源系統的自然鍵 (3) 提供穩定的鍵值 (4) 可以追蹤維度屬性值的變動 (5) 可以不用使用外來鍵 (6) 資料表可以不用進行正規化分析 (7) 資料表可以不用進行反正規化分析
(62) |
|
| (1) | 1256 |
|
| (2) | 34567 |
|
| (3) | I don't know |
|
| (4) | 1267 |
|
| (5) | 1234 |
|
( ) | 10.下列選項中有關商業智慧(BI)系統的建構方式何者錯誤
(64) |
|
| (1) | 使用資料倉儲系統的建構方式須使用資料倉儲匯流排架構(Data Warehouse Bus Architecture) |
|
| (2) | I don't know |
|
| (3) | 利用集中規劃觀點建構全公司的 BI 系統，將企業所需要的全部資料先蒐集與整合到一套系統上，再將資料分部門派送到較小的資料超市(Data Mart)供主管查詢，稱為資料倉儲(Data Warehouses)系統的建構方式 |
|
| (4) | 採用漸進式的方式分別完成，僅為公司內某單位先建構一個小的獨立的 BI 系統，稱為資料超市(Data Mart)系統的建構方式 |
|
| (5) | 資料超市(Data Mart)系統的建構方式因為工程浩大，很耗時間，以致於無法在短期內實現，因此企業容易失去熱忱，最後猶豫不決終告失敗 |
|
( ) | 11.下列有關星狀綱要模型之敘述哪些是錯誤 (1) 一個星狀綱要模型中可以有三個事實資料表存在 (2) 星狀綱要模型中顆粒度大小的設定不一致時，查詢過程比較有效率，正確性較高 (3) 一個星狀綱要模型中維度資料表只能有一個 (4) 星狀綱要模型中事實資料表中的自然鍵(Natural Keys,NK)欄位就是維度資料表中的外來鍵(FK)欄位的意思 (5) 迷你維度(Mini Demensions)是處理控制文件時而產生的 (6) 星狀綱要模型中事實資料表中的代理鍵(Surrogate Keys, SK)欄位與自然鍵(Natural Keys, NK)欄位意義不相同 (7) 星狀綱要模型中維度資料表的描述性欄位如果有蒐集不到資料的情形盡量都以虛值(Null Value)填入
(72) |
|
| (1) | 3467 |
|
| (2) | 1234567 |
|
| (3) | I don't know |
|
| (4) | 135 |
|
| (5) | 24 |
|
( ) | 12.在維度資料模型中有關維度資料表(Dimension Tables)代理鍵的描述下列何者正確
(61) |
|
| (1) | 代理鍵(Surrogate Keys, SK)編碼通常含有管理意涵 |
|
| (2) | 代理鍵(Surrogate Keys, SK)通常會有文字部份資料 |
|
| (3) | I don't know |
|
| (4) | 代理鍵(Surrogate Keys, SK)由系統給定 |
|
| (5) | 代理鍵(Surrogate Keys, SK)的欄位的意義與自然鍵(Natural Keys, NK)相同，所以可以直接以自然鍵當主鍵 |
|
( ) | 13.資料倉儲系統最常提供的三類資料呈現方法為 (1) 一般報表 (2) 線上即時報表分析 (3) 儀表板 (4) 討論版
(80) |
|
| (1) | 124 |
|
| (2) | 1234 |
|
| (3) | 234 |
|
| (4) | I don't know |
|
| (5) | 123 |
|
( ) | 14.下列有關退化維度(Degenerate Dimensions, DD)的描述何者錯誤
(66) |
|
| (1) | I don't know |
|
| (2) | 退化維度就等同迷你維度資料表(Mini-Dimension Tables) |
|
| (3) | 實務上常見的訂單(Order)、發票(Invoice)、提貨單(Bill of Lading)、機票(Airline Ticket)等文件上的單號或票號資料都會是退化維度資料來源 |
|
| (4) | 退化維度指的就是該維度資料表中除了交易控制文件的編號欄位之外別無其他欄位，例如訂單編號 |
|
| (5) | 分析過程中可以將退化維度資料表中的欄位直接納入事實資料表中，原來的退化維度資料表則不再需要 |
|
( ) | 15.下列關於事實資料表(Fact Table)之敘述何者錯誤
(74) |
|
| (1) | I don't know |
|
| (2) | 只用來儲存那些經常用來表現企業經營績效的數值 |
|
| (3) | 是一個擁有許多自然鍵的資料表 |
|
| (4) | 每筆事實資料表(Fact Table)會連到每張維度資料表中的一筆資料 |
|
| (5) | 事實資料絕大多數都是數值性資料 |
|
( ) | 16.下列關於交易控制文件(Transaction Control Document)之敘述何者有誤
(73) |
|
| (1) | I don't know |
|
| (2) | 交易控制文件的資料是來源系統或 ERP 系統主要處理的對象 |
|
| (3) | 文件結構屬於父子(Parent-Child)結構 |
|
| (4) | 文件上只有一筆交易文件的表頭記錄(Transaction Header Record) |
|
| (5) | 文件的主體(Transaction Body)只能填入一筆交易品項記錄 |
|
( ) | 17.下列累積快照事實資料表、交易事實資料表與週期快照事實資料表之比較敘述何者錯誤
(70) |
|
| (1) | 以顆粒(Grain)度設定為比較項目而言，累積快照事實資料表的顆粒度設定是以一個工作生命週期來記錄一筆事實資料，交易事實資料的顆粒度設定是以一個交易事件來記錄一筆事實資料，週期快照事實資料表的顆粒度設定是以一個固定時間的企業現況來記錄一筆事實資料 |
|
| (2) | I don't know |
|
| (3) | 以時間週期(Time Period)為比較項目而言，累積快照事實資料表的時間週期為不確定時間間距，交易事實資料表的時間週期為單時間點，週期快照事實資料表的時間週期為固定時間間距 |
|
| (4) | 以事實資料為比較項目而言，累積快照事實資料表的事實資料表示預設時間內的績效表現，交易事實資料表的事實資料表示交易活動內的績效表現，週期快照事實資料表事實資料表示生命週期內的績效表現 |
|
| (5) | 以設計日期維度資料表為比較項目而言，累積快照事實資料表在日期維度資料表時會以多日期欄位方式記錄里程碑，交易事實資料表在日期維度資料表會記錄著交易的日期，週期快照事實資料表在日期維度資料表會紀錄著週期結束的日期 |
|
( ) | 18.通常資料倉儲設計者，為了同時符合資料結構與呈現內容上的不同需求，需用同一主題的多維度模型資料去定義出
(77) |
|
| (1) | 多個資料報表 |
|
| (2) | 一個資料報表 |
|
| (3) | I don't know |
|
| (4) | 能給不同使用者用的資料立方體 |
|
| (5) | 匯流排矩陣表 |
|
( ) | 19.下列關於維度模型之特性敘述何者正確 (1) 可以減少大量的 Join 運作，可以節省查詢時間 (2)可以方便的組合出查詢報表(Ad-hoc Queries) (3) 可以容納非預期中的新資料 (4) 可以依據任務及資源的相依性決定關鍵路徑(Critical Path)
(75) |
|
| (1) | 134 |
|
| (2) | 124 |
|
| (3) | I don't know |
|
| (4) | 123 |
|
| (5) | 234 |
|
( ) | 20.通常維度資料表具有以下哪三種特性 (1) 欄位名稱具詳盡性(Verbose) (2) 欄位值具描述性(Descriptive) (3) 資料具完整性(Complete) (4) 資訊來源具未知性(Unknown)
(71) |
|
| (1) | 134 |
|
| (2) | I don't know |
|
| (3) | 123 |
|
| (4) | 234 |
|
| (5) | 124 |