A. 資料庫設計案例分析
加到200分吧，我幫你
B. 空間資料庫的空間資料庫的設計
資料庫因不同的應用要求會有各種各樣的組織形式。資料庫的設計就是根據不同的應用目的和用戶要求，在一個給定的應用環境中，確定最優的數據模型、處理模式、存貯結構、存取方法，建立能反映現實世界的地理實體間信息之間的聯系，滿足用戶要求，又能被一定的DBMS接受，同時能實現系統目標並有效地存取、管理數據的資料庫。簡言之，資料庫設計就是把現實世界中一定范圍內存在著的應用數據抽象成一個資料庫的具體結構的過程。
空間資料庫的設計是指在現在資料庫管理系統的基礎上建立空間資料庫的整個過程。主要包括需求分析、結構設計、和數據層設計三部分。
1、需求分析
需求分析是整個空間資料庫設計與建立的基礎，主要進行以下工作：
1）調查用戶需求：
了解用戶特點和要求，取得設計者與用戶對需求的一致看法。
2）需求數據的收集和分析：
包括信息需求(信息內容、特徵、需要存儲的數據)、信息加工處理要求(如響應時間)、完整性與安全性要求等。
3）編制用戶需求說明書：
包括需求分析的目標、任務、具體需求說明、系統功能與性能、運行環境等，是需求分析的最終成果。
需求分析是一項技術性很強的工作，應該由有經驗的專業技術人員完成，同時用戶的積極參與也是十分重要的。
在需求分析階段完成數據源的選擇和對各種數據集的評價
2、結構設計
指空間數據結構設計，結果是得到一個合理的空間數據模型，是空間資料庫設計的關鍵。空間數據模型越能反映現實世界，在此基礎上生成的應用系統就越能較好地滿足用戶對數據處理的要求。
空間資料庫設計的實質是將地理空間實體以一定的組織形式在資料庫系統中加以表達的過程，也就是地理信息系統中空間實體的模型化問題。
1）概念設計
概念設計是通過對錯綜復雜的現實世界的認識與抽象，最終形成空間資料庫系統及其應用系統所需的模型。
具體是對需求分析階段所收集的信息和數據進行分析、整理，確定地理實體、屬性及它們之間的聯系，將各用戶的局部視圖合並成一個總的全局視圖，形成獨立於計算機的反映用戶觀點的概念模式。概念模式與具體的DBMS無關，結構穩定，能較好地反映用戶的信息需求。
表示概念模型最有力的工具是E-R模型，即實體-聯系模型，包括實體、聯系和屬性三個基本成分。用它來描述現實地理世界，不必考慮信息的存儲結構、存取路徑及存取效率等與計算機有關的問題，比一般的數據模型更接近於現實地理世界，具有直觀、自然、語義較豐富等特點，在地理資料庫設計中得到了廣泛應用。
2）邏輯設計
在概念設計的基礎上，按照不同的轉換規則將概念模型轉換為具體DBMS支持的數據模型的過程，即導出具體DBMS可處理的地理資料庫的邏輯結構(或外模式)，包括確定數據項、記錄及記錄間的聯系、安全性、完整性和一致性約束等。導出的邏輯結構是否與概念模式一致，能否滿足用戶要求，還要對其功能和性能進行評價，並予以優化。
從E—R模型向關系模型轉換的主要過程為：
①確定各實體的主關鍵字；
②確定並寫出實體內部屬性之間的數據關系表達式，即某一數據項決定另外的數據項；
③把經過消冗處理的數據關系表達式中的實體作為相應的主關鍵字
④根據②、③形成新的關系。
⑤完成轉換後，進行分析、評價和優化。
3)物理設計
物理設計是指有效地將空間資料庫的邏輯結構在物理存儲器上實現，確定數據在介質上的物理存儲結構，其結果是導出地理資料庫的存儲模式(內模式)。主要內容包括確定記錄存儲格式，選擇文件存儲結構，決定存取路徑，分配存儲空間。
物理設計的好壞將對地理資料庫的性能影響很大，一個好的物理存儲結構必須滿足兩個條件：一是地理數據佔有較小的存儲空間；二是對資料庫的操作具有盡可能高的處理速度。在完成物理設計後，要進行性能分析和測試。
數據的物理表示分兩類：數值數據和字元數據。數值數據可用十進制或二進制形式表示。通常二進制形式所佔用的存貯空間較少。字元數據可以用字元串的方式表示，有時也可利用代碼值的存貯代替字元串的存儲。為了節約存貯空間，常常採用數據壓縮技術。
物理設計在很大程度上與選用的資料庫管理系統有關。設計中應根據需要，選用系統所提供的功能。
4)數據層設計
大多數GIS都將數據按邏輯類型分成不同的數據層進行組織。數據層是GIS中的一個重要概念。GIS的數據可以按照空間數據的邏輯關系或專業屬性分為各種邏輯數據層或專業數據層，原理上類似於圖片的疊置。例如，地形圖數據可分為地貌、水系、道路、植被、控制點、居民地等諸層分別存貯。將各層疊加起來就合成了地形圖的數據。在進行空間分析、數據處理、圖形顯示時，往往只需要若干相應圖層的數據。
數據層的設計一般是按照數據的專業內容和類型進行的。數據的專業內容的類型通常是數據分層的主要依據，同時也要考慮數據之間的關系。如需考慮兩類物體共享邊界(道路與行政邊界重合、河流與地塊邊界的重合)等，這些數據間的關系在數據分層設計時應體現出來。
不同類型的數據由於其應用功能相同，在分析和應用時往往會同時用到，因此在設計時應反映出這樣的需求，即可將這些數據作為一層。例如，多邊形的湖泊、水庫，線狀的河流、溝渠，點狀的井、泉等，在GIS的運用中往往同時用到，因此，可作為一個數據層。
5)數據字典設計
數據字典用於描述資料庫的整體結構、數據內容和定義等。 數據字典的內容包括： 1）資料庫的總體組織結構、 資料庫總體設計的框架 。 2）各數據層詳細內容的定義及結構、 數據命名的定義 。 3）元數據（有關數據的數據，是對一個數據集的內容、質量條件及操作過程等的描述） 。
C. 資料庫課程設計實例
資料庫課程設計
題目：小型超市管理系統
1、項目計劃
1.1系統開發目的
（1）大大提高超市的運作效率；
（2）通過全面的信息採集和處理，輔助提高超市的決策水平；
（3）使用本系統，可以迅速提升超市的管理水平，為降低經營成本， 提高效益，增強超市擴張力， 提供有效的技術保障。
1.2背景說明
21世紀，超市的競爭也進入到了一個全新的領域，競爭已不再是規模的競爭，而是技術的競爭、管理的競爭、人才的競爭。技術的提升和管理的升級是超市業的競爭核心。零售領域目前呈多元發展趨勢，多種業態：超市、倉儲店、便利店、特許加盟店、專賣店、貨倉等相互並存。如何在激烈的競爭中擴大銷售額、降低經營成本、擴大經營規模，成為超市營業者努力追求的目標。
1.3項目確立
針對超市的特點，為了幫助超市解決現在面臨的問題，提高小型超市的競爭力，我們將開發以下系統：前台POS銷售系統、後台管理系統，其中這兩個子系統又包含其它一些子功能。
1.4應用范圍
本系統適應於各種小型的超市。
1.5 定義
（1）商品條形碼：每種商品具有唯一的條形碼，對於某些價格一樣的商品，可以使用自定義條形碼。
（2）交易清單：包括交易的流水賬號、每類商品的商品名、數量、該類商品的總金額、交易的時間、負責本次收銀的員工號。
（3）商品積壓：在一定時期內，遠無法完成銷售計劃的商品會造成積壓。
（4）促銷：在一定時期內，某些商品會按低於原價的促銷價格銷售。
庫存告警提示：當商品的庫存數量低於庫存報警數量時發出提示。
（5）盤點：計算出庫存、銷售額、盈利等經營指標。
1.6 參考資料
《資料庫原理及設計》 陶宏才編 清華大學出版社
《SQL Server 2000 實用教程》范立南編 清華大學出版社
《SQL Server 2000 編程員指南》李香敏編 北京希望電子出版社
《輕松搞定 SQL Server 2000 程序設計》Rebecca M.Riordan編
《軟體工程規范》Watts S.Humphrey編 清華大學出版社
《軟體工程理論與實踐》 Shari Lawrence Pfleeger編 清華大學出版社
《軟體需求分析》 Swapna Kishore編 機械工業出版社
《軟體工程思想》 林銳編
2、邏輯分析與詳細分析
2.1系統功能
（1）、零售前台（POS）管理系統，本系統必須具有以下功能：
商品錄入：根據超巿業務特點制定相關功能，可以通過輸入唯一編號、掃描條形碼、商品名稱等來實現精確或模糊的商品掃描錄入。該掃描錄入方法可以充分保證各種電腦操作水平層次的人員均能准確快速地進行商品掃描錄入。
收銀業務：通過掃描條形碼或者直接輸入商品名稱（對於同類多件商品採用一次錄入加數量的方式）自動計算本次交易的總金額。在顧客付款後，自動計算找零，同時列印交易清單（包括交易的流水賬號、每類商品的商品名、數量、該類商品的總金額、交易的時間、負責本次收銀的員工號）。如果顧客是本店會員並持有本人會員卡，則在交易前先掃描會員卡，並對所購物品全部實行95折優惠，並將所購物品的總金額累計到該會員的總消費金額中。 會員卡的有效期限為一年，滿一年未續卡者，該會員卡將被注銷。
安全性：OS登陸、退出、換班與操作鎖定等許可權驗證保護；斷電自動保護最大限度防止意外及惡意非法操作。
獨立作業：有的斷網收銀即在網路伺服器斷開或網路不通的情況下，收銀機仍能正常作業
(2)、後台管理系統，本系統必須具備以下功能
進貨管理： 根據銷售情況及庫存情況，自動制定進貨計劃（亦可手工制定修改），可以避免盲目進貨造成商品積壓。 按計劃單有選擇性地進行自動入庫登記。 綜合查詢列印計劃進貨與入庫記錄及金額。
銷售管理： 商品正常銷售、促銷與限量、限期及禁止銷售控制。 綜合查詢各種銷售明細記錄、各地收銀員收銀記錄以及交結賬情況等。 按多種方式統計生成銷售排行榜，靈活察看和列印商品銷售日、月、年報表。
庫存管理： 綜合查詢庫存明細記錄。 庫存狀態自動告警提示。如庫存過剩、少貨、缺貨等。軟體為您預警，避免庫存商品積壓損失和缺貨。 庫存自動盤點計算。
人員管理： 員工、會員、供貨商、廠商等基本信息登記管理。 員工操作許可權管理。 客戶銷售許可權管理。
（3）系統結構
系統總體結構
模塊子系統結構
功能描述：商品錄入子系統要求能快速錄入商品，因此必須支持條形碼掃描。
功能描述：收銀業務子系統能計算交易總額，列印交易清單，並根據會員卡打折。
功能描述：進貨管理子系統可以根據庫存自動指定進貨計劃，進貨時自動等級，以及提供查詢和列印計劃進貨與入庫記錄的功能。
功能描述：銷售管理子系統可以控制某商品是否允許銷售，查詢每種商品的銷售情況並產生年、月、日報表，同時可以生成銷售排行榜。
功能描述：庫存管理子系統提供查詢庫存明細記錄的基本功能，並根據庫存的狀態報警，以及自動盤點計算。
功能描述：人員管理子系統提供基本信息登記管理，員工操作許可權管理，客戶銷售許可權管理的功能。
2.2、流程圖
前台管理系統
頂層DFD圖
第0層DFD圖
第1層DFD圖
2.3、戶類型與職能
（1）、員工（營業員）：
通過商品條形碼掃描輸入商品到購買清單
操作軟體計算交易總金額
操作軟體輸出交易清單
對會員進行會員卡掃描以便打折
（2）、：超市經理
操作軟體錄入商品，供貨商，廠商
操作軟體制定進貨計劃
查詢列印計劃進貨與入庫記錄
操作軟體控制商品銷售與否
查詢列印銷售情況
操作軟體生成銷售排行榜
查詢庫存明細記錄
根據軟體發出的庫存告警進行入貨
操作軟體進行盤點計算
（3）、總經理：
基本信息登記管理
員工操作許可權管理
客戶銷售許可權管理
2.4、統開發步驟
確定參與者和相關的用況
為每個用況設計過程
建立順序圖，確定每個腳本中對象的協作
創建類，確定腳本中的對象
設計, 編碼, 測試, 集成類
為過程編寫系統測試案例
運行測試案例，檢驗系統
2.5、系統環境需求
系統模式
本系統採用C/S模式作為開發模式
硬體環境
伺服器端：
高性能的計算機一台，
普通的雙絞線作為連接。
客戶端： 普通的計算機或者工作站，
普通的雙絞線作為連接。
軟體環境
伺服器端：安裝SQL Server 2000的伺服器版本，
安裝windows 2000伺服器版本，
配置了諾頓等必須的防毒軟體。
客戶端： 安裝SQL Server2000的伺服器版本，
安裝了VB等可視化開發工具軟體，
安裝windows2000伺服器版本。
2.6、系統安全問題
信息系統盡管功能強大，技術先進，但由於受到自身體系結構，設計思路以及運行機制等限制，也隱含許多不安全因素。常見因素有：數據的輸入，輸出，存取與備份，源程序以及應用軟體，資料庫，操作系統等漏洞或缺陷，硬體，通信部分的漏洞，企業內部人員的因素，病毒，「黑客」等因素。因此，為使本系統能夠真正安全，可靠，穩定地工作，必須考慮如下問題：為保證安全，不致使系統遭到意外事故的損害，系統因該能防止火，盜或其他形式的人為破壞。
系統要能重建
系統應該是可審查的
系統應能進行有效控制，抗干擾能力強
系統使用者的使用許可權是可識別的
3、基於UML的建模
3.1語義規則
用例模型（use cases view）（用例視圖）的基本組成部件是用例（use case）、角色(actor)和系統(system)。用例用於描述系統的功能，也就是從外部用戶的角度觀察，系統應支持哪些功能，幫助分析人員理解系統的行為，它是對系統功能的宏觀描述，一個完整的系統中通常包含若干個用例，每個用例具體說明應完成的功能，代表系統的所有基本功能（集）。角色是與系統進行交互的外部實體，它可以是系統用戶，也可以是其它系統或硬體設備，總之，凡是需要與系統交互的任何東西都可以稱作角色。系統的邊界線以內的區域（即用例的活動區域）則抽象表示系統能夠實現的所有基本功能。在一個基本功能（集）已經實現的系統中，系統運轉的大致過程是：外部角色先初始化用例，然後用例執行其所代表的功能，執行完後用例便給角色返回一些值，這個值可以是角色需要的來自系統中的任何東西。
UML：是一種標準的圖形化建模語言，它是面向對象分析與設計的一種標准表示；它不是一種可視化的程序設計語言而是一種可視化的建模語言；不是工具或知識庫的規格說明而是一種建模語言規格說明是一種表示的標准；不是過程也不是方法但允許任何一種過程和方法使用它。
用例（use case）：
參與者（actor）：
3.2、UML模型
3.21、系統UML模型
3.22、子系統UML模型
（1）零售前台（POS）管理系統用例視圖
（2）後台管理系統用例視圖
3.3、系統實現圖
4、超市銷售系統概念設計文檔
（1）、系統ER圖
（2）、系統ER圖說明
1) 商店中的所有用戶（員工）可以銷售多種商品，每種商品可由不同用戶（員工）銷售；
2) 每個顧客可以購買多種商品，不同商品可由不同顧客購買；
3) 每個供貨商可以供應多種不同商品，每種商品可由多個供應商供應。
（3）、視圖設計
1) 交易視圖(v_Dealing)——用於查詢交易情況的視圖；
2) 計劃進貨視圖(v_PlanStock)——用於查詢進貨計劃的視圖；
3) 銷售視圖(v_Sale)——用於查詢銷售明細記錄的視圖；
4) 入庫視圖(v_Stock)——用於查詢入庫情況的視圖。
5、邏輯設計文檔
（1）、系統關系模型
a) 商品信息表（商品編號，商品名稱，價格，條形碼，促銷價格，促銷起日期，促銷止日期，允許打折，庫存數量，庫存報警數量，計劃進貨數，允許銷售，廠商編號，供貨商編號）
b) 用戶表（用戶編號，用戶名稱，用戶密碼，用戶類型）
c) 會員表（會員編號，會員卡號，累積消費金額，注冊日期）
d) 銷售表（銷售編號，商品編號，銷售數量，銷售金額，銷售日期）
e) 交易表（交易編號，用戶名稱，交易金額，會員卡號，交易日期）
f) 進貨入庫表（入庫編號，入庫商品編號，入庫數量，單額，總額，入庫日期，計劃進貨日期，入庫狀態）
g) 供貨商表（供貨商編號，供貨商名稱，供貨商地址，供貨商電話）
h) 廠商表（廠商編號，廠商名稱，廠商地址，廠商電話）
（2）、系統資料庫表結構
資料庫表索引
表名 中文名
MerchInfo 商品信息表
User 用戶表
Menber 會員表
Sale 銷售表
Dealing 交易表
Stock 進貨入庫表
Provide 供貨商表
Factory 廠商表
商品信息表(MerchInfo)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
MerchID int 4 P Not null 商品編號
MerchName Varchar 50 Not null 商品名稱
MerchPrice Money 4 Not null 價格
MerchNum Int 4 Not null 庫存數量
CautionNum Int 4 Not null 庫存報警數量
PlanNum Int 4 null 計劃進貨數
BarCode Varchar 50 Not null 條形碼
SalesProPrice Money 4 促銷價格
SalesProDateS Datetime 8 促銷起日期
SalesProDateE Datetime 8 促銷止日期
AllowAbate Int 4 Not null 允許打折
AllowSale Int 4 Not null 允許銷售
FactoryID Varchar 10 F Not null 廠商編號
ProvideID Varchar 10 F Not null 供貨商編號
用戶表(User)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
UserID varchar 10 P Not null 用戶編號
UserName Varchar 25 Not null 用戶名稱
UserPW Varchar 50 Not null 用戶密碼
UserStyle Int 4 Not null 用戶類型
會員表(Menber)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
MemberID Varchar 10 P Not null 會員編號
MemberCard Varchar 20 Not null 會員卡號
TotalCost Money 4 Not null 累積消費金額
RegDate Datetime 8 Not null 注冊日期
銷售表(Sale)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
SaleID Varchar 10 P Not null 銷售編號
MerChID Varchar 10 F Not null 商品編號
SaleDate Datetime 8 Not null 銷售日期
SaleNum Int 4 Not null 銷售數量
SalePrice Money 4 Not null 銷售單額
交易表(Dealing)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
DealingID Varchar 10 P Not null 交易編號
DealingPrice Money 4 Not null 交易金額
DealingDate Money 4 Not null 交易日期
MemberID Varchar 10 會員卡號
UserName Varchar 10 F Not null 用戶名稱
入庫紀錄表(Stock)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
StockID Varchar 10 P Not null 入庫編號
MerchID Varchar 10 F Not null 入庫商品編號
MerchNum Int 4 Not null 入庫數量
MerchPrice Money 4 Not null 單額
TotalPrice Money 4 Not null 總額
StockDate Datetime 8 Datetime 入庫日期
PlanDate Datetime 8 Datetime 計劃進貨日期
StockState Int 4 Not null 入庫狀態
供貨商表(Provide)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
ProvideID varchar 10 P Not null 供貨商編號
ProvideName Varchar 50 Not null 供貨商名稱
ProvideAddress Varchar 250 供貨商地址
ProvidePhone Varchar 25 供貨商電話
廠商表(Provide)
欄位名 欄位類型 長度 主/外鍵 欄位值約束 對應中文名
FactoryID varchar 10 P Not null 廠商編號
FactoryName Varchar 50 Not null 廠商名稱
FactoryAddress Varchar 250 廠商地址
FactoryPhone Varchar 25 廠商電話
6、物理設計文檔
/*----------創建資料庫----------*/
create database SuperMarketdb
on primary
(
name=SuperMarketdb,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.mdf',
size=100MB,
maxsize=200MB,
filegrowth=20MB
)
log on
(
name=SuperMarketlog,
filename='C:\Program Files\Microsoft SQL Server\MSSQL\Data\SuperMarketdb.ldf',
size=60MB,
maxsize=200MB,
filegrowth=20MB
)
go
/*----------創建基本表----------*/
use [SuperMarketdb]
go
/*創建交易表*/
CREATE TABLE Dealing (
DealingID int identity(1,1) Primary key ,
DealingDate datetime NOT NULL ,
DealingPrice money NOT NULL ,
UserName varchar(25) NULL ,
MemberCard varchar(20) NULL
)
GO
/*創建廠商表*/
CREATE TABLE Factory (
FactoryID varchar(10) Primary key ,
FactoryName varchar(50) NOT NULL ,
FactoryAddress varchar(250) NULL ,
FactoryPhone varchar(50) NULL
)
GO
/*創建會員表*/
CREATE TABLE Member (
MemberID varchar(10) Primary key ,
MemberCard varchar(20) NOT NULL ,
TotalCost money NOT NULL ,
RegDate datetime NOT NULL
)
GO
/*創建商品信息表*/
CREATE TABLE MerchInfo (
MerchID int identity(1,1) Primary key ,
MerchName varchar(50) Unique NOT NULL ,
MerchPrice money NOT NULL ,
MerchNum int NOT NULL ,
CautionNum int NOT NULL ,
PlanNum int NOT NULL ,
BarCode varchar(20) Unique NOT NULL ,
SalesProPrice money NULL ,
SalesProDateS datetime NULL ,
SalesProDateE datetime NULL ,
AllowAbate int NOT NULL ,
AllowSale int NOT NULL ,
FactoryID int NOT NULL ,
ProvideID int NOT NULL
)
GO
/*創建供應商表*/
CREATE TABLE Provide (
ProvideID varchar(10) Primary key ,
ProvideName varchar(50) NOT NULL ,
ProvideAddress varchar(250) NULL ,
ProvidePhone varchar(25) NULL
)
GO
/*創建銷售表*/
CREATE TABLE Sale (
SaleID int identity(1,1) Primary key ,
MerChID int NOT NULL ,
SaleDate datetime NOT NULL ,
SaleNum int NOT NULL,
SalePrice money NOT NULL
)
GO
/*創建入庫表*/
CREATE TABLE Stock (
StockID int identity(1,1) Primary key ,
MerchID int NOT NULL ,
MerchNum int NOT NULL ,
MerchPrice money NULL ,
TotalPrice money NULL ,
PlanDate datetime NULL ,
StockDate datetime NULL,
StockState int NOT NULL
)
GO
/*創建用戶表*/
CREATE TABLE User (
UserID varchar(10) Primary key ,
UserName varchar(25) NOT NULL ,
UserPW varchar(50) NOT NULL ,
UserStyle int NOT NULL ,
)
GO
/*----------創建表間約束----------*/
/*商品信息表中廠商編號、供應商編號分別與廠商表、供應商表之間的外鍵約束*/
ALTER TABLE MerchInfo ADD
CONSTRAINT [FK_MerchInfo_Factory] FOREIGN KEY
(
[FactoryID]
) REFERENCES Factory (
[FactoryID]
),
CONSTRAINT [FK_MerchInfo_Provide] FOREIGN KEY
(
[ProvideID]
) REFERENCES Provide (
[ProvideID]
)
GO
/*銷售表中商品編號與商品信息表之間的外鍵約束*/
ALTER TABLE Sale ADD
CONSTRAINT [FK_Sale_MerchInfo] FOREIGN KEY
(
[MerChID]
) REFERENCES MerchInfo (
[MerchID]
) ON DELETE CASCADE
GO
/*入庫表中商品編號與商品信息表之間的外鍵約束*/
ALTER TABLE Stock ADD
CONSTRAINT [FK_Stock_MerchInfo] FOREIGN KEY
(
[MerchID]
) REFERENCES MerchInfo (
[MerchID]
) ON DELETE CASCADE
GO
/*----------創建索引----------*/
/*在交易表上建立一個以交易編號、交易日期為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Dealing ON Dealing(DealingID, DealingDate)
GO
/*在商品信息表上建立一個以商品編號為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_MerchInfo ON MerchInfo(MerchID)
GO
/*在銷售表上建立一個以銷售編號、銷售日期為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Sale ON Sale(SaleID, SaleDate)
GO
/*在入庫表上建立一個以入庫編號、入庫日期、商品編號為索引項的非聚集索引*/
CREATE nonclustered INDEX IX_Stock ON Stock(StockID, StockDate, MerchID)
GO
/*----------創建視圖----------*/
/*創建用於查詢交易情況的視圖*/
CREATE VIEW v_Dealing
AS
SELECT DealingDate as 交易日期,
UserName as 員工名稱,
MemberCard as 會員卡號,
DealingPrice as 交易金額
FROM Dealing
GO
/*創建用於查詢進貨計劃的視圖*/
CREATE VIEW v_PlanStock
AS
SELECT Stock.StockID as SID,
MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
Factory.FactoryName as 廠商,
Provide.ProvideName as 供貨商,
Stock.MerchNum as 計劃進貨數量,
Stock.PlanDate as 計劃進貨日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=0
GO
/*創建用於查詢銷售明細記錄的視圖*/
CREATE VIEW v_Sale
AS
SELECT MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
MerchInfo.MerchPrice as 商品價格,
Sale.SalePrice as 銷售價格,
Sale.SaleNum as 銷售數量,
Sale.SaleDate as 銷售日期
FROM Sale INNER JOIN
MerchInfo ON Sale.MerChID = MerchInfo.MerchID
GO
/*創建用於查詢入庫情況的視圖*/
CREATE VIEW v_Stock
AS
SELECT MerchInfo.MerchName as 商品名稱,
MerchInfo.BarCode as 條形碼,
Factory.FactoryName as 廠商,
Provide.ProvideName as 供貨商,
Stock.MerchPrice as 入庫價格,
Stock.MerchNum as 入庫數量,
Stock.TotalPrice as 入庫總額,
Stock.StockDate as 入庫日期
FROM Stock,MerchInfo,Provide,Factory
Where Stock.MerchID = MerchInfo.MerchID
and Provide.ProvideID=MerchInfo.ProvideID
and Factory.FactoryID=MerchInfo.FactoryID
and Stock.StockState=1
GO
7、小結
和傳統管理模式相比較，使用本系統，毫無疑問會大大提高超市的運作效率，輔助提高超市的決策水平，管理水平，為降低經營成本， 提高效益，減少差錯，節省人力，減少顧客購物時間，增加客流量，提高顧客滿意度，增強超市擴張能力， 提供有效的技術保障。
由於開發者能力有限，加上時間倉促，本系統難免會出現一些不足之處，例如：
本系統只適合小型超市使用，不能適合中大型超市使用；
超市管理系統涉及范圍寬，要解決的問題多，功能復雜，實現困難，但由於限於時間，本系統只能做出其中的一部分功能；
對於以上出現的問題，我們深表歉意，如發現還有其它問題，希望老師批評指正。
請採納。
D. 設計一個空間資料庫應該有哪些功能
通過設計和建立database空間資料庫，掌握空間資料庫設計和建設流程，學會利用所學GIS知識獨立分析和解決問題的能力，對所學建庫知識進行一個完整的串接。
3、需求分析
旅遊業是一個綜合性很強的信息依賴型產業，旅遊信息的獲取、加工、傳播和利用對旅遊業的發展起著舉足輕重的作用。從旅遊者和旅遊規劃管理部門的需求出發建立旅遊信息資料庫，不僅可以使旅遊者和旅遊規劃管理部門能夠快速、准確地查找和檢索自己所需要的旅遊信息，而且能夠促進旅遊信息規范化和標准化，促進旅遊信息的共享，打破對旅遊信息的封鎖；旅遊信息資料庫的建立有利於從整體上對旅遊業進行宏觀的調控和管理，有利於旅遊業協調、健康有序的發展。
四川省旅遊空間資料庫的建立以arcgis為平台，以database為載體，內涵四川主要景點的各種信息（屬性和空間），可以為使用者提供一定的信息服務。
4、功能分析與數據組織
4.1 數據組織
本實驗的數據組織為：矢量數據採用簡單數據格式shapefile存儲，具體文件如下表所示：
文件名稱
用途
主要景點
記錄四川省的主要旅遊景點信息，並進行分類
交通要道_國道
存儲四川省的交通要道國道的走向，便於分析路徑
交通要道_高速路
存儲四川省的交通要道高速路的走向，便於分析路徑
交通要道_鐵路
存儲四川省的交通要道鐵路的走向，便於分析路徑
主要城市
記錄四川省的主要城市信息，便於查詢信息
主要河流
記錄四川省的主要河流信息
4.2 功能分析
本資料庫主要的功能設計為：
1、可以通過地圖空間信息查詢到景點的屬性信息，如景點的類型、票價、主要的景點以及景點的具體位置信息等；
2、可以通過屬性的查詢方式找到具體景點的位置，並可以通過提供的信息找到到該景點的路徑。
5、資料庫建設流程
5.1 環境配置
5.1.1 硬體配置
計算機一台（windowxp 操作系統）
5.1.2 軟體配置
專業軟體：PCI8.2，ArcGIS9.2 desktop
其它軟體：Office Access 2003、抓圖軟體等
E. 資料庫具體應用的實例有哪些
資料庫的應用領域
1、多媒體資料庫： 這類資料庫主要存儲與多媒體相關的數據，如聲音、圖像和視頻等數據。多媒體數據最大的特點是數據連續，而且數據量比較大，存儲需要的空間較大。
2、移動資料庫： 該類資料庫是在移動計算機系統上發展起來的，如筆記本電腦、掌上計算機等。該資料庫最大的特點是通過無線數字通信網路傳輸的。移動資料庫可以隨時隨地地獲取和訪問數據，為一些商務應用和一些緊急情況帶來了很大的便利。
3、空間資料庫： 這類資料庫目前發展比較迅速。它主要包括地理信息資料庫（又稱為地理信息系統，即GIS）和計算機輔助設計（CAD）資料庫。其中地理信息資料庫一般存儲與地圖相關的信息數據；計算機輔助設計資料庫一般存儲設計信息的空間資料庫，如機械、集成電路以及電子設備設計圖等。
4、信息檢索系統： 信息檢索就是根據用戶輸入的信息，從資料庫中查找相關的文檔或信息，並把查找的信息反饋給用戶。信息檢索領域和資料庫是同步發展的，它是一種典型的聯機文檔管理系統或者聯機圖書目錄。
5、分布式信息檢索： 這類資料庫是隨著Internet的發展而產生的資料庫。它一般用於網際網路及遠距離計算機網路系統中。特別是隨著電子商務的發展，這類資料庫發展更加迅猛。
許多網路用戶（如個人、公司或企業等）在自己的計算機中存儲信息，同時希望通過網路使用發送電子郵件、文件傳輸、遠程登錄方式和別人共享這些信息。分布式信息檢索滿足了這一要求。
6、專家決策系統： 專家決策系統也是資料庫應用的一部分。由於越來越多的數據可以聯機獲取，特別是企業通過這些數據可以對企業的發展作出更好的決策，以使企業更好地運行。由於人工智慧的發展，使得專家決策系統的應用更加廣泛。
(5)空間資料庫設計案例擴展閱讀
對資料庫系統的基本要求是：
①能夠保證數據的獨立性。數據和程序相互獨立有利於加快軟體開發速度，節省開發費用。
②冗餘數據少，數據共享程度高。
③系統的用戶介面簡單，用戶容易掌握，使用方便。
④能夠確保系統運行可靠，出現故障時能迅速排除；能夠保護數據不受非受權者訪問或破壞；能夠防止錯誤數據的產生，一旦產生也能及時發現。
⑤有重新組織數據的能力，能改變數據的存儲結構或數據存儲位置，以適應用戶操作特性的變化，改善由於頻繁插入、刪除操作造成的數據組織零亂和時空性能變壞的狀況。
⑥具有可修改性和可擴充性。
⑦能夠充分描述數據間的內在聯系。
F. 空間資料庫的設計有哪些步驟和內容
資料庫應用系統的開發是一項軟體工程。一般可分為以下幾個階段：
1.規劃
2.需求分析
3.概念模型設計
4.
邏輯設計
5.物理設計
6.程序編制及調試
7.運行及維護。
G. 空間資料庫
（一）區域級潛力與適宜性空間資料庫
1.資料庫設計
區域級評價空間資料庫採用了MapGIS數據管理技術和Geodatabase技術，數據保存為MapGIS數據、ShipeFile、文件和Access資料庫，見表12-2。
數據比例尺為1∶500萬，採用投影坐標WGS84。
數據來源：全國1:500萬矢量數據、全國1∶100萬矢量數據、遙感影像數據、Dem數據、搜集的各婁圖件、數據標准化獲得的數據和區域級評價成果數據等；
數據格式：Shape File、Geodatabase、Raster(Grid、Tiff、Image）、MapGIS等；
數據處理步驟及方法：收集資料、劃分圖層、維護屬性表、配准並矢量化圖形、設置可視化參數、屬性關聯、投影變換；
數據容量：Geodatabase(Access、Shape File）共1G;Raste（r衛星影像、DEM）共計500G；處理後的數據共計約600G；
數據內容：共63個全國基礎地理矢量圖層；78個評價專題圖層；Dem數據；衛星影像數據。
資料庫主要成果圖層屬性欄位設置示例見表12-2。
表12-2 區域級評價主要成果圖層屬性欄位設置示例
續表
H. 空間資料庫的設計
空間資料庫主要存儲與各類圖形數據，包括行政區劃底圖、遙感影像圖、地質遺跡分布圖等。資料庫設計時，通過圖元、圖例、空間索引和圖類分層設計，建立空間資料庫(圖6-4)。
I. 資料庫系統及應用的圖書目錄
第1章 資料庫系統概論
1.1 資料庫的基本概念和相關術語
1.1.1 數據、數據管理與數據處理
1.1.2 資料庫基本概念
1.1.3 關系列表和關系資料庫
1.2 資料庫技術的產生與發展
1.2.1 數據管理的發展
1.2.2 數據和數據管理技術
1.2.3 數據管理技術的3個發展階段
1.3 資料庫系統的一般構成
1.3.1 資料庫系統的一般構成
1.3.2 資料庫系統的模式構成
1.3.3 資料庫系統的物理組成
1.3.4 資料庫管理系統的功能
第2章 關系數據模型
2.1 數據模型
2.1.1 概述
2.1.2 數據模型的基本要素
2.1.3 數據模型的發展
2.2 關系數據模型
2.2.1 基本概念
2.2.2 關系數據模型的數據結構
2.2.3 數據操作
2.2.4 數據約束
2.2.5 關系數據模型的優缺點
2.3 關系
2.3.1 域、笛卡兒積和關系
2.3.2 關系的性質
2.3.3 關系模式
2.3.4 關系完整性
2.4 關系代數
2.4.1 集合運算
2.4.2 關系演算
第3章 結構化查詢語言SQL基礎
3.1 SQL簡介
3.1.1 SQL的歷史
3.1.2 SQL的優點
3.2 資料庫的操作
3.2.1 資料庫的創建
3.2.2 資料庫的修改
3.2.3 資料庫的刪除
3.3 數據表的操作
3.3.1 數據類型
3.3.2 表的創建
3.3.3 表結構的修改
3.3.4 表的刪除
3.4 表中數據的操作
3.4.1 SQL語方的基本查詢
3.4.2 多表間的連接查詢
3.4.3 嵌套查詢
3.4.4 聯合查詢
3.4.5 數據插入
3.4.6 數據修改
3.4.7 數據刪除
3.5 視圖
3.5.1 視圖的基本概念
3.5.2 創建視圖
3.5.3 刪除視圖
3.5.4 更新視圖
3.6 索引
3.6.1 索引的概念
3.6.2 索引的分類
3.6.3 建立索引的原則
3.6.4 創建索引
3.6.5 刪除索引
第4章 資料庫完整性
4.1 資料庫完整性概述
4.2 完整性約束的分類
4.3 完整性約束的定義
4.3.1 Primary Key約束
4.3.2 UNIQUE 約束
4.3.3 NOT NULL 約束
……
第5章資料庫安全
第6章資料庫恢復技術
第7章並發控制
第8章資料庫設計理論
第9章資料庫應用設計方法
第10章 資料庫開技術
第11章 數據倉庫技術
第12章 數據挖掘技術
第13章 地理信息系統和空間資料庫
第14章 主流資料庫產品介紹
附錄A HIS案例
參才文獻
J. 預測模擬技術在空間資料庫優化開發中的應用——專家系統類比法滑坡災害制圖案例研究
本文譯自Environmental Geology,2002(41）∶765～775。
Alberto Pistocchi1Lucia Luzi2Paola Napolitano3著
朱汝烈4譯校
（1Studio di Ingegneria per I'Ambiente e il Territorio,Viale G.Carcci,15,47023 Cesena,Italy；2IRRS-CNR,MiLan,Italy；3ACTA Studio Associato,Naples,Italy；4中國地質調查局水文地質工程地質技術方法研究所，河北保定，071051）
【摘要】此案例研究，源於將不同概率的預測模型[貝葉斯（Bayesian）概率、模糊邏輯、「與」、「或」、「總和」、「產出」、「灰度（非線性）」運算以及必然性因素等]，用於編制義大利亞平寧山脈北部的丘陵和山嶽地區滑坡災害地圖。利用7個數據層來檢驗非常脆弱的區域：岩性、與地質構造線的距離、年降雨量數值、土地覆蓋類型、地形坡度和坡向，以及與水文網路段的距離。與用預測率指數預測的不同結果進行了對比和縝密的討論，以評價這種易於運用、適宜有效的資料庫在土地規劃中使用價值的可能性。
【關鍵詞】支持性函數整體化模擬滑坡災害空間資料庫
1導言及一般論點
近幾年來，全歐洲各地方及規劃部門在建立空間資料庫方面有了長足進展。然而，很多資料庫似乎對決策支持仍然不起作用，而且其使用的有效數據經常是純粹土化的。特別是，最終數據使用者和決策者對於有關地理信息系統（Geographic Information Systems——GIS）的模擬能力，近乎於毫不知曉的狀況。極少有地方政府機構在日常的決策中採用預測模型作為其有效支撐。
地理信息系統為詳細的空間特徵模擬帶來巨大的能力，並且許多地方政府現在已擁有GIS技術，為其使用提供了方便條件。人們在對自然界現象進行日常習慣性觀察時，這一重要信息有變成一種更有力的方法手段的潛在可能嗎？
出於參與規劃和目標共享的需要，地學家已經注意到確定的共享資源在用於規劃和決策支持中做出的評估具有何等重要性的有關闡述。一些人強調地球科學地圖在制定政策和土地使用規劃過程中的作用。據他們的觀點，災害地圖（hazard maps）的主要作用是，為決策者提供有關土地開發規章條例定義問題的正確觀點。
基於自然現象之間因果關系的預測模型，已被水文工作者、地球科學家、環境分析家和工程師廣泛地應用於自然風險評估、自然資源管理、污染防治與土壤改良及環境影響評估等領域。然而，就諸如滑坡這一自然災害場合而言，要建立一個能在區域規模內可靠適用的模式似乎相當困難。一些人探究產生這一困難的原因，認為主要是受模型和數據的限制。與其他風險管理的角度不同，很少有管理者探索過有關定量模型的應用問題。
滑坡災害制圖的傳統方法，依賴地質學家和地貌學家的經驗觀察、鑒定（通過對現場特性的直接觀察和遠距離的檢測報告）來解釋滑坡發生的特徵。這樣雖有相當可能判明既往事件，但是在撇開專家主觀性及定性判斷的情況下，幾乎不能支持任何預測。
近幾年來，已經提出了基於成帶現象的大地構造模型。然而，基於大地構造模型的計算方法，或者說實際上是基於指數疊加的方法，限於數據不足或數據質量的低下，盡管其自然基礎相當穩固，仍經常是不可靠的。
另一方面，通過「客觀」的可復制模型進行的預測，分析家對可能的、有限的隨機選擇感到興趣。特別是下列這些情況：
·當具有相當重要性的規劃設想涉及到社會沖突時；
·當現象不容易覺察時；
·當對覆蓋整個所關心區域的現象做詳細測圖所耗費用過於高昂，因而有必要對那些需更深一步了解的區域進行「篩選范圍」模擬的時候。
一般說來，模擬過程與決策很相似，而且其工作具協調性和基礎性。災害地圖之所以合理的一個理由，是通過專家的專門鑒別，可用模擬方法學的手段再現、復制，可以有助於認識的社會構成，亦即在管理者、社區公眾以及科學家之間分享正確的決策准則。
這一原因導致開展使用概率進行預測的可能性的調查研究。在這些探索過程中，充分運用有關滑坡事件的先驗性知識，通過合理地確定參數，用模糊的、或隨機的地圖套疊方法進行概率預測。
在最近幾年，對這種方法做了很多探索。所有這些方法已經比較廣泛地使用於敏感性分析或不同方法的性能對相同案例的研究。目前，在這些應用中存在的主要困難是不同的地圖的對比。
有人提出了一種解決問題的構想，以完善繪圖功能。在那些作者們的工作中，顯示了概率、模糊的范疇，並可用現象發生地區最支持性的探測功能——例如滑坡或者礦藏——來證明。這些技術通過推測、校核而發揮效用；對其他諸如神經和貝葉斯（Bayesian）網路等方法，其共通特徵與一般的數學模擬近似。以這種方法能輕易地找出一種稱之為預測比率的獨特標准，它主要用於比較不同預測地圖，堪稱使模型具有良好性能的有效措施。對其解釋如下：支持性函數的用途在於以產生至少包含科學家基於規章的判斷，即可從現場經驗獲得的、預測大部分正確的地圖為目標。當然，隨後由於專家對現象認識和理解的逐步深化在評估期間必然要求選擇多種模擬。同時，由於協調不當而產生變數的假定概率，以及數據缺乏和不可靠，也可引起謬誤的結果。不過，運用定量法可以使模型的校準和確認能夠支持預測的透明度和合理性。支持性函數模擬方法最近已在專門為其安排的某些案例研究中應用。
本文目的在於，探討支持性函數模擬對用現有的資料庫標准認定的滑坡事件，編制災害地圖的可應用性，並且檢查這種方法在現有的資料庫里信息的運用中如何改進，以與其他技術（例如，每個岩性單位的滑坡頻率編圖或者純粹的滑坡目錄清單似的繪圖）相比較。
支持性函數模擬也可用於構建資料庫的概念性設置：數據的收集嚴格依賴於在理論框架上對最佳可用信息的准確理解。
2理論背景
很多作者指出，數值技術的使用與那些對相關現象自身屬性的局部價值認為值得關注的事件相聯系。屬性被認為是事件的證據因素，「或然性」、「可能性」或者發現事件的「可能」程度，在一定意義上與每個相關屬性的存在非常符合。假定 A是已進行分析的定義域，而 F是被檢查的事件現象。若 r數據層為有效數據，則對於每一個屬性種類中的mk來說，設定k=1，…r，便可對每個數據層定義一個分配函數：
地質災害調查與監測技術方法論文集
它將 A的每個象素分配到k層序列中的一層中；可以為每層確定另一個函數：
地質災害調查與監測技術方法論文集
在這種情況下，地圖在每個層里出現一個數值下降的間隔[a,b]。在此，a和b取決於分析者（如稍後將指出的那樣）所做的進一步假定。這個數值代表支持性（favorability），即假定一旦遭遇某種特殊種類屬性現象出現時的可靠程度。
對作為每個數據層的函數成分 V和R被定義後，支持性函數可表示為：
地質災害調查與監測技術方法論文集
間隔極值 a,b必須由分析家據其「可靠性」的解釋而定，若認為可靠性與「可能性」相同，則 a=0,b=1。若令可靠性范圍等於確定性系數，則 a=-1,b=1。如果選擇不同的方法，則可能需要另外的數值。
支持性函數在本項目中的不同用法將在本報告中予以陳述。
若支持性假設為與特定現象 F相關，設定與事件的可能性一致的屬性種類為E1，…，E。，然後根據貝斯定理，按 E1，…，E。獨立條件假說，可寫為：
地質災害調查與監測技術方法論文集
在ppsI中，I=1，…，n，是發生必然屬性種類的優先概率，並且可用該屬性種類存在的總面積的百分比進行估算。pps1至n作為屬性種類的先期共同可能性考慮；這可以作為全部種類共同發生的總面積的百分比。ppaI,I=1，…，n是觀察到的F對於屬性種類Ei事件的可能性；這可以根據公式計算。ppaI=1－(1-(areaI)-1)nb(I），其中areaI是符合i系列條件的面積，而nb(i）是與F條件也符合的i系列的面積。psF是所有覆蓋整個區域的F的優先概率，並可用所有符合F條件面積的百分數算出。
按此法則，一張地圖可以由發生的屬性種類的每種組合的計算編制出。這可以通過常規交叉作業程序，在GIS的柵格內操作完成。
如果使用確定性系數，則運演算法則作如下相應變動：
（1）一種屬性種類的確定性系數可以定義為：
地質災害調查與監測技術方法論文集
式中：I=1，…，n;n是作為原因因數的主題數據種類的數量。
（2）對兩個數據種類來說，確定性系數根據下列法則計算：
當 CF1和CF2均為正號，那麼 CF1+2=CF1+CF2-(CF1×CF2）；
若 CF1和CF2符號相反，則 CF1+2=CF1+CF2/{1-min(|CF1｜,｜CF2|))；
若 CF1和CF2均為負號，則 CF1+2=CF1+CF2+(CF1×CF2）。
（3）程序通過首先計算 CF1+2=CF12，然後 CF13=CF12+3等等，按此重復操作可獲得更多的圖件。
作為最後的方法，採用模糊集合論通過計算「模糊總和」、「模糊產出」，「模糊與」、「模糊或」以及「模糊非線性函數」。所有這些函數都是在假設 F存在的可能性預測值等於給定的種類EI（即 ppaI）的條件下進行運算的。它們是：
·「模糊與」＝min(ppaI）,I=1，…n;
·「模糊或」＝max(ppaI）,I=1，…n；
·「模糊結果」＝Ⅱ（ppaI）,I=1，…n；
·「模糊總和」＝1－Ⅱ（1-ppaI），I=1，…n；
·「模糊非線性計算」＝（模糊總和）（模糊結果）1－γ，γ是0:1范圍的參數。
按此方法，可確定編制覆蓋層地圖的法則，以便分析家能評價覆蓋整個研究地區的不同事件屬性數據差別，並有助於進一步識別存在更多現象的場地。這些計算結果代表與被認為屬於有利性的現象相關指標的數目。必須注意到，除已描述之外，根據相應的資料證據分量、可信功能、線性回歸覆蓋概率以及其他諸多條件，可採用不同的技術。
必須指出，優先概率psF需要對確定性系數的估計測定而計算獲得，但將它用於絕對邊界條件是無意義的，因為要預知未來的滑坡事件的可能性實際上幾乎是不可能的。預測根據的理由必須在概括全部條件求得支持性指標後，方可確認，而不能以對災害的數字計算結果為依據。
3應用
用於本案例研究的地區在義大利（圖1）北部的薩維（Savio）河流域。區域地質概況基本上為泥灰岩和沙岩組成的一個沉積盆地。可更詳細分為以下3種主要的地質岩層：
圖1研究區位置圖
（1）托爾頓階（Tortonian N1）為灰色砂質和泥質濁流沉積岩，是主要地質岩層，並出露於這條主要溪流兩側。
（2）由微晶質石膏與泥質粘土和沙層互層組成，而其基底為含硫石灰岩地層。
（3）由泥質岩、砂質岩和礫岩3層構成，全部含有灰岩層。
此外，還有淤泥質泥灰岩層、晚始新世砂岩地層、上新世粘土以及混雜堆積的粘土層出露地表。
該地區被大量滑坡覆蓋，在不同的地質單元內，大多數情況下是以滑移型或泥石流型的運動形式發生。而且，有的地區有岩石崩落，並存在塊體平移運動，然而對它們均未做過分析。研究過程中使用的數據由埃米利亞·羅馬格納地區地質調查所（Regione Emilia Romagna Geological Survey）提供。
用於本案例研究的資料庫由若干主題層構成，它們涉及：
·線性構造（斷層，向斜和背斜），比例尺1:50000；
·岩性單元，比例尺1:50000；
·根據CORINE歐洲工程指南協議，從TM陸地衛星映像獲得的土地覆蓋情況，比例尺1∶50000：
·數字地形模型（DTM），根據從Regione Emilia Romagna地方當局的地圖資料庫中獲得的、通過計曲等高線內插、等高距為50m的等值線製成；
·整個地區的7個降雨計量站的降雨測量數據；
·數字化水文網，比例尺1:10000。
必須強調，資料庫的分辨度非常低劣，另外，數據在比例尺上很不均勻。有人會認為特別是當與平均滑坡面積進行對比時，地形信息明顯很不精確，因而成為非實際滑動的運動學的代表。這項研究的目的是評價現實世界資料庫的預測能力（前已闡述），必須意識到，重要的不是做出可靠的災害地圖，因為最好的信息雖已被應用殆盡，但不可能有任何更深遠范圍的調查和數據可供獲取。正如在以下內容所強調的那樣，與土地計劃的預測相比較，評估的結果將為資料庫的改進給予更多的輸入內容。
從DTM數字地形模型中形成了坡度和坡向地圖，並用固定的數值間隔對坡度做了分級。
對線性構造的距離做了計算，目的在於評價構造干擾對坡體穩定性的可能影響。以對柵格地圖和柵格化作為計算結果。
分析了降雨資料，以查明高程與年降雨量之間的關系。從這兩個變數的一個回歸方程發現：y=0.7086x+708.19(R2=0.66），x為海拔高程（m）,y是超過30年的長時間級數降雨量的總平均值（mm/a）。後來用該方程式做了一幅連續降雨地圖，結果明確顯示，DTM既像降雨特徵的指示劑，同時也猶如位能釋放的一個顯示器。
應當注意，過高的高程與降雨的相互關系相當微弱，而更進一步的分析則要求更好地描述該地區的實際降雨分布情況。然而，依據現有數據，僅能說明已經適當地查明了降雨分布的一般趨勢而已。
盡管概念上的差異特性可以在滑坡的現象情況與所需的因素之間梳理出來，然而，當其他所需要特徵都存在的情況下，恰恰只是「要素」觸發了滑坡。可以認為，所有這些數據層都可能具有優先意義。
至於存在滑坡可能性的數據，只能依賴地方當局的土地不穩定情況報表獲得。應著重指出，資料庫適用於構建GIS的長時間序列分析。而且，其數據的密度和分布，按統計學來看，屬具典型意義的現實滑坡分布。可以證明，事實上，當為貝葉斯程序培養的數據集不是足夠大（並且排列也不足夠隨機）——這關繫到對分區性隨機變數的獲得——的時候，按定量評價的觀點衡量概率綜合模擬，是毫無意義的。本案例中，滑坡發生的優先總和有利性條件（級別—特殊）的概率ppa1和psf，需由專家們判定。而且，選擇滑坡的類型和年齡以便培養數據系列是重要的，這樣的系列可照顧到同類滑坡。已有人進行了關於「泥石流」和「崩滑泥石流」類型滑坡的分析，認為通常發生在局部地區。在本研究項目中，僅在編制一些圖件時有效地應用。
地區土地不穩定性報表記錄也考慮了岩石崩落、塊體滑動以及潛在不穩定的地段，但是這些沒包括在分析過程中。圖2顯示了用於分析的數據層。
被考慮的全部主題的數據原則上有相互關聯的可能性。由於多餘的信息將可能導致無效結果，因而做一些嘗試性計算。為了分析的目的，已進行了一次對7個主題條件（即，降雨地圖、岩石學、土地覆蓋、坡度、坡向、與水文網的距離及與線性構造的距離）的聯合性試驗。7個主題條件分類列入獨立的圖例內，並作為促使滑坡體產生活動的條件在地圖上的識別標准。
對每一個地圖偶對做了4個指數的聯合計算：
·x平方（x2）指數；
·克拉默（Cramers）指數；
·意外事故指數；
·共同信息不確定性得分。
這里，第一個指數被確定為：
圖2用於預測的原因因素主題圖
地質災害調查與監測技術方法論文集
式中
地質災害調查與監測技術方法論文集
而 T＝象素的總數，Ti＝地圖1中 i類象素的數量，Tj＝地圖2中 j類象素的數量。指數 n和m分別是在地圖1和地圖2中的種類數目。
克拉默指數（V）和意外事故指數（C）確定如下：
地質災害調查與監測技術方法論文集
相同符號的含義相應同前，同時 M取（m-1,n-1）的最小值，而 n和m分別是兩幅圖中每一幅中的數據種類的數目。
圖幅偶對 A和B的共同信息不確定性得分取決於：
地質災害調查與監測技術方法論文集
其中
地質災害調查與監測技術方法論文集
n、m分別是在地圖A和地圖B里種類的數量，而Pij則是在地圖A和B的交會線上i和j種類的像素數量分別對像素總量的比率。Pj是地圖A中種類j的像素總數量，而 Pi表示種類i在地圖B中的總像素。
上述指標可判斷一個地圖偶對之間的協調性尺度。x平方指數給出協調性（無上邊界的）絕對尺度，而對其本身沒用；V和C表示區域內預防標準的尺度[0,1]，它們越是接近1，則兩張地圖之間的聯系越強。這3個指標結合使用，可提供關於聯系性的一個綜合尺度標准，並允許我們超越一套地圖從不同角度去比較像對的聯系性。通常，可能注意到3個指標呈現如所期望那樣非常相似的反應。不確定性共同信息記錄也可用於確定由前面的指標測定的聯系性模型，並假定在0（完全獨立的地圖）和1（完全聯系的地圖）之間改變。表1展示了如上所述的地圖計算的指標。
表1數據層之間的聯系性指標
盡管未使用計算的指標，在嚴格條件下，對於確定貝葉斯條件（比非聯系性質更強）的獨立性，這些由全部數據層推斷而得出的聯系性指標，可能應當是獨立的。
正如分析所指出的，必須被注意到，滑坡顯示出與岩石學的某種聯系（只有一個滑坡，岩石學主題由於共同信息的不確定性，具有非相關性），並與海拔高程/雨量以及地表覆蓋存在空間聯系趨勢。
應當指出，若從因果關系以外的因素看來，岩石學與海拔高程/雨量和土地覆蓋是相關的，而與坡度之間的聯系較弱，與其他主題的聯系則極少或無聯系。提供給研究項目的不甚適用的DTM似乎是造成這一現象的首要原因。除在坡度和降雨量/海拔高程之間的微弱的聯系外，其他聯系可能均未予考慮。
根據當地地質調查所的分析似乎也得出同樣的結論，岩性的因素僅僅用於編制滑坡災害圖以及擬定作為滑坡災害指標的每個岩性單位的滑坡頻率。
在每次運算期間，只有已知滑坡（通過隨意抽樣選擇）的一半用來生成預測地圖，然而剩下的東西，應當視為同樣有效的數據群。作為滑坡災害預測嘗試，最先使用潛在原因因素，而在第2次試驗過程中，只使用了3個最為相關的因素，這將在後面的章節中予以解釋。
4結果討論
支持性函數的計算如以下將予以描述的那樣，是在不同的模擬假定前提下進行的。每一幅由計算生成的良好地圖的預測能力，用曲線的預測比率進行測試。這種曲線，是通過研究地區的累積百分率標定分類，以支持性評定數值的遞減量（遵循上面提到的各種法則）作為橫坐標，以滑坡地區的累積百分率作為縱坐標而做成的。據說，當預測的滑坡百分比與區域最大值的20%相一致時，便是對模型預測能力的良好評估。更廣泛的觀念是，曲線越是有規則的接近縱軸，則預測越加吻合。相反，若更多的曲線靠近45°直線，則說明組合因素造成預測靠近支持性數值的隨機分布范圍，這種預測的有用價值極小。在因果因素中，已經認識到水文網路所起的作用較小，這是因為為其所擬定的細節，要比其他因素的精密度高得多。乍看起來河流切割「遍布」各地，因而不便於將滑坡分布與它和水文網路的距離加以聯系。因此，在因果因素中沒有包括河流水系。
在圖3中對已考慮的6個因果因素的預測比率，逐個予以顯示。本項目中，預測者估計的條件頻率ppaI,I=1，…n（發生滑坡事件的條件概率，給定的種類 i）適於每個主題內的每一個種類。
圖3原因因素預測的比率——使用整個滑坡封閉折線和條件頻率
第一步計算用作證據的數據，來自圖解滑坡活動的全部封閉折線。滑坡被分解成兩個隨機取樣組，其中一個用於標定，而另一個用於證實。計算作業使用了3個最相關的主題（岩性、土地覆蓋以及海拔高程/雨量），遵照先前描述的指標。預測比率曲線用圖4顯示。
進一步使用所有的6個指標進行了計算，其預測比率用圖5顯示。
我們注意到，由於整個滑坡體均被繪制，因而這可能會含有一些精確性的偏差；由於因果因素的集合，致使滑坡觸發點和滑坡前緣不相同。因此，在每個滑坡封閉折線內預測，只使用最高點；若從物質運動的運動學原理考慮，觸發點應當在最高位置。6個因果指標在此假定前提下計算的預測比率，如圖6所示。
圖47位預測者預測的比率——使用3個因果指標
（岩石學、降雨量和土地覆蓋）和整個滑坡封閉折線
圖57位預測者預測的比率——使用所有6個相關的原因指標和整個滑坡封閉折線
7位預測者使用3個和6個因果指標的預測比率，分別用圖7和圖8顯示。
就輸入數據的相關性而論，表明使用坡度、坡向和雨量分布（即更准確的DTM和雨量——由更區域化的降雨計量器獲得的數據）具有更好的代表性，將使結果得到改進。一旦得到新數據，分析者們便可重新評價其對預測的潛在影響。
從預測比率的比較中可以確定：
·當使用6種因果指標代替3種與滑坡關聯性更好的指標（岩石學、土地覆蓋以及雨量）時，似乎沒有明顯的改進；在兩種情況下的預測表現得非常近似，這恰似對種類群用了修整清除器，然而更多的指標是被應用了的。
·更進一步的清除效果可由只用觸發點，而無需考慮滑坡整體來作為證據。這不至於帶來地圖總體預測能力的惡化；但同時也須顧及到，過量的清除有可能會導致繪圖的可靠程度降低乃至消失。
圖6隻使用觸發點因果指標預測的比率
圖77個預測者只使用3個因果指標（岩石學、土地覆蓋和降雨量）和觸發點預測的比率
圖87個預測者使用6個相關因果指標和滑坡觸發點預測的比率
·岩石學在原因指標的預測比率圖解中，無論如何顯然具有更高的預測能力（如此則可理解，為何當地地質調查所單獨選擇了將這個主題層用於災害制圖），當然還包括土地覆蓋和降雨。然而並非其他全部主題都與預測相關。
·在本案例研究過程中，除貝葉斯可能性的情況外，7位預測者所用的預測表現得極其近似。然而數據的有效分布性是非常敏感的，當整個滑坡體被用作證據，並處於模糊「或」、「與」的某些場合時，則預測均近乎為隨機性的。通常，似乎確定性系數是預測者在這一具體案例的研究中最有用的手段，雖然在每種情況下，一些預測者以預測比率曲線和預測地圖所作出的預測實際上相同。
圖9顯示了在本案例中，進一步顯示了將3個因素與作為主題證據的觸發點共同配合使用時的7種預測。這是本案例研究過程中探討的情況之一，它具有更好的預測比率，並且可能對滑坡災害成帶性作出最佳的基礎性思考，顯現了當前的認識狀態。
圖9根據7種預測做出的預測地圖
5結論
本文討論的方法是使用數字模型（較少需要專家的主觀判斷），依據滑坡災害來劃分土地等級。這似乎表明，當客觀預測可從空間資料庫中提煉出來時，則可以說明其主題有一些「系統」增加的價值，即全部數據都共同使用比僅只使用某些主題的效果更好。
必須強調，這種方法從現有資料庫的開發入手，且保留對每個主題認識的開放、完善。在最好的預測者們各種各樣的測試（確定性系數、貝葉斯可能性、模糊的操作和其他可能的技術）中，僅能根據各種測試技術的預測能力做出選擇，最後則慎重地使用了預測比率曲線進行預測。
這些分析已經引發了現有的資料庫尚屬不健全的認識，當然，僅指為了生成預測模擬使用目的的地形數據不甚適當而言。這寄希望於未來投入進一步的調查研究並捕獲數據，以確定一種更佳的數字化地形模型。只要改進的原因因素地圖一旦產生，或者一個新的原因因素被確認與現象相關，便可能重新進行計算，從而可能產生新的預測圖。預測比率使用的有效性可按實際和有效改進進行檢查，也可用來對數據收集和岩土工程監測的進一步努力指明方向。例如，在本案例研究中，岩性、土地覆蓋以及降雨（如上所述，按高程描述）顯然是滑坡的最相關的因素，因而到目前為止，分析主要致力於這些因素的調查和編圖。更進一步說，准備並使用具有合適解讀能力的DTM顯得很有必要，其目的是為了更詳細地檢查地形數據的影響。分析也很重視其他主題條件，例如水體高程，對用於危險繪圖時，它可能就變得相當重要。