• 沒有找到結果。

第三章 系統分析與設計

3.6 子系統模型

3.6.10 管理子系統

功能:

新增使用者帳號,管理系統設定選項,查閱最新消息並可加 以刪除管理。

架構:

取消 Strategy 模式。

圖 3-37 管理子系統類別圖 表 3-33 管理子系統事件規格表

類別名稱 事件 說明

Page_Load 當網頁下載時自動觸發,顯示系統設 定資料。

Updata_Click 當按下更新按鍵時觸發,更新系統設 定。

AddUser_Click

當按下新增使用者按鍵時觸發,上載 新增資料檔,以新增資料檔資料新增 使用用帳號。

SystemSetting

DeleteNews_Click 當按下新增使用者按鍵時觸發,刪除 所選擇的最新消息。

表 3-34 管理子系統方法規格表

類別名稱 方法 說明

GetSystemData():SystemData 取得系統設定資 料。

UpdataSystemData(SystemData) 更新系統設定資 料。

AddUser(HttpPostedFile)

接收新增資料 檔,以新增資料 檔資料新增使用 用帳號。。

NewsCount():int 取得最新消息的 總筆數。

SetNews(int index) 設定目前讀取的 最新消息。

GetNewsTitle():string 取得目前最新消 息的標題。

GetNewsContext():string 取得目前最新消 息的內容。

GetNewsDep():string 取得目前最新消 息的發佈單位。

GetNewsPostTime() 取得目前最新消 息的發佈時間。

GetNewsBeginTime() 取得目前最新消 息的開始時間。

GetNewsEndTime() 取得目前最新消 息的結束時間。

SystemSettingGroup

DeleteNews(int index) 刪除第 index 筆 的訊息。

3.6.11 其他

登入:

取消 Strategy 模式。

圖 3-38 登入類別類別圖

表 3-35 登入事件規格表

類別名稱 事件 說明

Login Submit_ServerClick 當使用者送出時觸發,檢查帳號和 密碼是否正確。

表 3-36 登入方法規格表

類別名稱 方法 說明

CheckUser():bool 檢查帳號和密碼是否正確,若正確,

回傳 true。

LoginGroup

SaveLogin(string ip):int

儲存使用者登入資料(IP,時間,登入次 數),並回傳登入次數。

3.7 資料庫設計

(1) 需求的收集與分析 (Requirements collection and analysis)

在這一階段中,我們主要是詳細分析資料庫使用者與預期資料 庫使用者的期望,並將其作條列式的描述,即為此系統的「資料需 求」。這一部份,我們將在 3.7.1 節中介紹。

(2) 概念資料庫設計 (Conceptual database design)

這一階段中,是將上一階段的「資料需求」轉化成「高階概念 資料模型」,我們選擇「實體關係模型」- ER Model (Entity

Relationship Model)作為高階概念資料模型。此一部份,將在 3.7.2 節中再作介紹。

(3) 邏輯資料庫設計 (Logical database design)

這一階段是將「高階概念資料模型」轉化成「概念綱要」。由 於,我們先前已決定要使用 SQL 2000 作為資料庫設計管理的工 具,而 SQL 2000 的「象徵實作資料模型」為「關聯式」,因此,在 此階段中,我們便將之前的 ER Model 轉化成「關聯式資料庫綱 要」。這一部份,我們將在 3.7.3 節中介紹。

(4) 實體資料庫設計 (Physical database design)

此一階段,是將「關聯式資料庫綱要」轉化成「內部綱要」,

即為「低階實體資料模型」。在此我們定義了各資料行的資料型別、

長度、是否允許 Null,以及預設值。我們將在 3.7.4 節中,作這一 部份的介紹。

(5) 資料庫系統實作 (Database system implementation)

在這一階段中,我們將「內部綱要」,即「低階實體資料模型」, 藉由 SQL 2000 建立了「線上學生課務資訊系統資料庫」,並且輸入 資料至資料庫中。至此,資料庫建置完成,資料庫系統即可開始運 作。而這一部份的實體資料表關聯,我們將在第四章系統建置時再 作介紹。

接著,我們以圖 3-38 來表示「線上學生課務資訊系統」資料庫的 設計過程。圖中的五個長方形框框,分別代表資料庫設計的五個主要 階段,框框箭頭下的文字,為各階段完成後的產物。

圖 3-39「線上學生課務資訊系統」的資料庫設計階段

3.7.1 資料需求

h. 每位學生都有自己所屬的班級,及序號,此部分由註冊組負責,

目前,已有很多「高階概念資料模型」被提出來,如:

實體關係模型(Entity-Relationship Model,簡稱:ER Model)、

加強型實體關係模型(Enhanced-ER,簡稱:EER Model)、

函數資料模型(Functional data model,簡稱:FDM)、

巢狀關聯資料模型(Nested Relational Model)、

結構資料模型(Structure Data Model)、

語意資料模型(Semantic Data Model,簡稱:SDM)...等等。

在此,我們選擇最熟悉亦普遍被使用的 ER Model,來作概念資料庫 設計。

ER Model 包含了實體型態、關係型態、屬性、鍵值、和結構限 制,下面我們就簡單介紹 ER Model 各元件,及其圖示。

實體(Entity):在真實世界中獨立存在的一個「事物」。如:職員、

房子、車、公司、工作、大學課程...等等。實體的代表圖示為單實 線矩形方塊,實體名稱標在矩形方塊中央,如圖 3-40。

圖 3-40 實體(Entity)

屬性(Attribute):用來描述實體的特殊性質。例如,一個實體為 職員的屬性有姓名、年齡、地址、薪水和職務等。而每個屬性都有值 (Value),是儲存在資料庫的主要部份,例如,屬性為“姓名”、“年 齡”者,其值分別為“沈小玉”、“20”或“吳大弘”、“45”。屬 性的代表圖示為單實線橢圓形,屬性名稱標在橢圓形中央,如圖 3-41。

圖 3-41 屬性(Attribute) 此外,屬性又可分為下列幾種型態:

簡單屬性(Simple Attribute):為不可分割的屬性,例如:年齡。

複合屬性(Composite Attribute):為簡單屬性的組合,例如,“上 課時間”是一個複合屬性,它可以拆成兩個簡單屬性,分別為“星 期”、“節次”。複合屬性的代表圖示為單實線橢圓形,複合屬性 名稱標在橢圓形中央,並以直線連結組合成複合屬性的各個簡單屬 性,如圖 3-42。

圖 3-42 複合屬性(Composite Attribute)

單值屬性(Single-valued Attribute):屬性只有一個單一的值。例 如:年齡。

多值屬性(Multi-valued Attribute):屬性有一個以上的值。例 如,一個人可能有一個 E-mail,也有可能沒有,也有可能有兩個以 上,因此,“E-mail”這個屬性就是屬於多值屬性。多值屬性的代 表圖示為雙實線橢圓形,多值屬性名稱標在橢圓形中央,如圖 3-43。

圖 3-43 多值屬性(Multi-valued Attribute)

儲存屬性(Stored Attribute):屬性的值不能由其他屬性的值導 出。如:出生日期。

導出屬性(Derived Attribute):屬性的值可以從儲存屬性的值導 出。例如,年齡屬性的值可以從出生日期屬性的值導出,因此,年 齡即為導出屬性,出生日期就是儲存屬性。導出屬性的代表圖示為 單虛線橢圓形,導出屬性名稱標在橢圓形中央,如圖 3-44。

圖 3-44 導出屬性(Derived Attribute)

鍵值屬性(Key Attribute):屬性的每一個值在其實體中均是唯一 的,分別代表實體中的每一個個別成員。有時符合此定義的屬性並 不只一個,我們必須從中挑選一個來當作鍵值屬性。例如,“學生”

實體的屬性“學號”與“身分證字號”,均符合鍵值屬性的定義,

但我們只能選擇其中一個,作為“學生”實體的鍵值屬性,通常,

我們都會以“學號”當作“學生”實體的鍵值屬性。鍵值屬性的代 表圖示為單實線橢圓形,鍵值屬性名稱加上實線底線後,標在橢圓 形中央,如圖 3-45。

圖 3-45 鍵值屬性(Key Attribute)

關係(Relationship):兩個實體間有關聯時,就產生了關係。例 如,“教師”跟“科目”兩個實體間有關聯,便產生了“授課”關

係。關係的代表圖示為單實線菱形方塊,關係名稱標在菱形方塊中 央,如圖 3-46。

圖 3-46 關係(Relationship)

角色名稱(Role Name):每個實體名稱均可當作角色名稱,此 時就不用特別標出來。但某些情況下,角色名稱會與實體名稱不一 樣,此時,就要在實體與關係之間的直線附近,標名角色名稱,如 圖 xxx。例如,在“教師”“管理”“班級”這個關係中,“教師”

所扮演的角色名稱為“導師”。

圖 3-47 角色名稱(Role Name)

基數率(Cardinality Ratio):以 1:1、1:N、M:N 表示兩個實體在 此關係中所暫的比例。例如,在“職員”“管理”“部門”的關係

員”實體與“管理”關係的直線附近標上“M”,在“部門”實體 與“管理”關係的直線附近標上“N”,來表示此種狀態,如圖 3-47。

E1:E2 = 1 : 1

圖 3-48 基數率(Cardinality Ratio)之一

E1:E2 = 1 : N

圖 3-49 基數率(Cardinality Ratio)之二

E1:E2 = M : N

圖 3-50 基數率(Cardinality Ratio)之三

參與限制(Participation Constraint):以“全部參與”及“部份 參與”來表示實體中的個別成員參與關係的程度。例如,在“教 師”“管理”“班級”的關係中,若每位教師都要擔任導師管理班 級的話,那麼對“教師”這個實體而言,就是“全部參與”此關 係,在 ER Model 圖示中,我們便以“雙實線”連接“教師”實體 與“管理”關係;若並非每位教師都要擔任導師管理班級的話,那 麼對“教師”這個實體而言,就是“部份參與”此關係,在 ER Model 圖示中,我們便以“單實線”連接“教師”實體與“管理”

關係,如圖 3-51。

E1 全部參與 E2 部份參與

圖 3-51 參與限制(Participation Constraint)

弱勢實體(Weak Entity):沒有任何鍵值屬性的實體。弱勢實體 必須透過關係與另一個實體結合,才能分辨弱勢實體中的每一個個 別成員。而上述的「另一個實體」便稱為「辨認擁有者」(Identifying Owner)。例如,弱勢實體「親屬」必須與辨認擁有者「學生」產生 關聯,才有意義。弱勢實體的代表圖示為雙實線矩形方塊,弱勢實 體名稱標在矩形方塊中央,如圖 3-52。

圖 3-52 弱勢實體(Weak Entity)

辨認關係(Identifying Relationship):弱勢實體與辨認擁有者所 產生的關係。由於,弱勢實體必須與辨認擁有者產生關聯,才有意 義,因此,弱勢實體必“全部參與”其所對應的辨認關係。例如,

“學生”“有”“親屬”的關聯中,“有”即為其“辨認關係”,

而“親屬”必全部參與“有”這個辨認關係。辨認關係的代表圖示 為雙實線菱形方塊,辨認關係名稱標在方塊中央,如圖 3-53。

圖 3-53 辨認關係(Identifying Relationship)

部份鍵值屬性(Partial Key Attribute):為弱勢實體所擁有。當辨 認擁者成員為同一個時,我們可藉由部份鍵值來分辨不同的弱勢實 體成員。例如:若同一學生的親屬間,不會有相同名字時,則弱勢 實體“親屬”的“姓名”屬性即為部份鍵值屬性。部份鍵值屬性的 代表圖示為單實線橢圓形,部份鍵值屬性名稱加上虛線底線後,標 在橢圓形中央,如圖 3-54。

圖 3-54 部份鍵值屬性(Partial Key Attribute)

最後,將我們根據上一節的資料需求,所繪出的「線上學生課務 資訊系統」資料庫的 ER Model 附上。

課程資料庫:

?

?

?

?

?

?

? ?

圖 3-56 課程資料庫-課程 ER Model 之二

圖 3-57 課程資料庫-課程 ER Model 之三

圖 3-58 課程資料庫-課程 ER Model 之四

圖 3-59 課程資料庫-課程 ER Model 之五

?

? ?

? ? ? ?

? ?

?

? ?

? ? ?

?

?

?

?

?

圖 3-60 課程資料庫-課程 ER Model 之六

圖 3-61 課程資料庫-課程 ER Model-學生實體圖

圖 3-62 課程資料庫-課程 ER Model-教師實體圖

? ? ? ?

圖 3-64 課程資料庫-課程 ER Model-班級實體圖

圖 3-65 課程資料庫-課程 ER Model-班別實體圖

圖 3-66 課程資料庫-課程 ER Model-系所實體圖

圖 3-67 課程資料庫-課程 ER Model-學院實體圖

圖 3-68 課程資料庫-課程 ER Model-書籍實體圖

圖 3-69 課程資料庫-課程 ER Model-課程實體圖

圖 3-70 課程資料庫-課程 ER Model-課程別實體圖

圖 3-72 課程資料庫-課程 ER Model-教室別實體圖

圖 3-73 課程資料庫-課程 ER Model-大樓實體圖

圖 3-74 課程資料庫-預選科目 ER Model 之一

圖 3-75 課程資料庫-預選科目 ER Model 之二

? ? ? ?

“課程資料庫-預選科目 ER Model”的其餘實體圖均同“課程 資料庫-課程 ER Model”的實體圖。

“課程資料庫-預選科目 ER Model”的其餘實體圖均同“課程 資料庫-課程 ER Model”的實體圖。

相關文件