【文章內(nèi)容簡介】 char(9)旅客編號Not nullP00000001P99999999 外鍵來自旅客信息表lineNochar(9) 線路編號Not nullL00000001L99999999 外鍵來自線路信息表PNo char(9)方案編號Not nullP00000001P99999999 外鍵來自方案編號stardatedatetime出發(fā)時間Not nullorderdatedatetime預定時間Not null priceint單價null數(shù)據(jù)項數(shù)據(jù)類型別名是否為空約束取值含義traNochar(9)出行編號Not nullT00000001T99999999 主鍵T代表出行，后8位按順序編號PasNochar(9)旅客編號Not nullP00000001P99999999 外鍵 來自旅客信息表guideNochar(9)導游編號Not nullG00000001G99999999 外鍵來自導游信息表lineNochar(9)線路編號Not nullL00000001L99999999 外鍵來自線路信息表sceNochar(9)景點編號Not nullS00000001S99999999 外鍵來自景點信息表PNo char(9)方案編號Not nullP00000001P99999999 外鍵來自方案編號startdatedatetime出發(fā)時間 Not null trantimedatetime參觀景點時間Not null 數(shù)據(jù)項數(shù)據(jù)類型別名是否為空約束取值含義guideNochar(9)導游編號Not nullG00000001G99999999 外鍵來自導游信息表pasNochar(9)旅客編號Not nullP00000001P99999999 外鍵來自旅客信息表evaluateGscore Int評價分數(shù)null evaluateDatedatetime評價時間null 數(shù)據(jù)項數(shù)據(jù)類型別名是否為空約束取值含義sceNochar(9)景點編號Not nullG00000001G99999999 外鍵來自景點信息表pasNochar(9)旅客編號Not nullP00000001P99999999 外鍵來自旅客信息表evaluateSscore Int評論分數(shù)Not null evaluateDatedatetime評價時間Not null （1）旅客信息表 R1（旅客編號、旅客姓名、性別、家庭住址、電話、身份證號）∈3NF。（2）導游信息表 R2（導游編號、導游姓名、性別、家庭住址、電話、身份證號）∈3NF。（3）線路信息表R3（線路編號、出發(fā)時間、出發(fā)地、目的地）∈3NF。（4）景點信息表 R4（景點編號、景點名稱、營業(yè)時間、票價、優(yōu)惠措施、注意事項）∈3NF。（5）線路方案信息表 R5（方案編號、方案類型、價格、總票數(shù)、交通方式、線路編號）∈3NF。（6）預訂信息表 R6（預訂編號、旅客編號、線路編號、線路方案、出發(fā)時間、預定時間、單價）∈2NF。（7）出行信息表 R7（出行編號、旅客編號、導游編號、景點編號、線路編號、方案編號、出發(fā)時間、參觀景點時間 ）∈2NF。 （8）導游評價信息表 R8(旅客編號、導游編號、評價時間、 評價得分) ∈3NF。（9）景點評價信息表R9（旅客編號、景點編號、評價時間、 評價得分）∈3NF。，當有許多拼客參加同一預訂信息或出行信息時，由于 guideNo、lineNo、sceNo等許多信息重復，而僅僅是PasNo、price、 ordernum、num等屬性有所不同，所以會造成大量的冗余。因此可以把這兩個表的屬性分別再產(chǎn)生一張明細表，并且要在預訂主表和訂單主表中分別加上一個預訂編號和出行編號做主碼。（1）由order聯(lián)系集產(chǎn)生預訂主表（ordermaster）和預訂明細表（orderDetail）：Ordermaster（orderNo、lineNoPno、stardate、orderdate) orderDetail（ordeNo、pasNo 、price）可以驗證，關(guān)系模式ordermaster和orderDetail都滿足BCNF要求，且分解是無損連接。轉(zhuǎn)化成對應的表如下：數(shù)據(jù)項數(shù)據(jù)類型別名是否為空約束取值含義orderNochar(9)預訂編號Not nullO00000001O99999999 主鍵O代表預訂，后8位按順序編號lineNo1char(9) 線路編號Not nullL00000001L99999999 外鍵來自線路信息表Pnochar(3)方案編號Not null001 999主鍵按流水號生成stardatedatetime出發(fā)時間Not nullorderdatedatetime預定時間Not null 數(shù)據(jù)項數(shù)據(jù)類型別名是否為空約束取值含義orderNochar(9)預訂編號Not nullO00000001O99999999 主鍵O代表預訂，后8位按順序編號pasNochar(9)旅客編號Not nullP00000001P99999999 外鍵來自旅客信息表priceint單價Not null（2）由travel聯(lián)系集產(chǎn)生出行主表（travelmaster）和訂單明細表（travelDetail）：Travelmaster（traNo 、guideNo 、lineNopno、startdate ）travelDetail（traNo、pasNo 、sNo、trantime）可以驗證，關(guān)系模式travelmaster和travelDetail都滿足BCNF要求，且分解是無損連接。轉(zhuǎn)化成對應表如下：數(shù)據(jù)項數(shù)據(jù)類型別名是否為空約束取值含義traNochar(9)出行編號Not nullT00000001T99999999 主鍵T代表出行，后8位按順序編號guideNochar(9)導游編號Not nullG00000001G99999999 外鍵來自導游信息表lineNo1char(9)線路編號Not nullL00000001L99999999 外鍵來自線路信息表Pnochar(3)方案編號Not null001 999主鍵按流水號生成startdatedatetime出發(fā)時間 Not null 數(shù)據(jù)項數(shù)據(jù)類型別名是否為空約束取值含義traNochar(9)出行編號Not nullT00000001T99999999 主鍵T代表出行，后8位按順序編號PasNochar(9)旅客編號Not nullP00000001P99999999 外鍵 來自旅客信息表sceNochar(9)景點編號Not nullS00000001S99999999 外鍵來自景點信息表trantimedatetime參觀景點時間Not null所以模式求精后整個拼車系統(tǒng)所確定的關(guān)系表如下：1） 2） Guide3）4）5）6）7） orderdetail8) 9) 10)11)4 物理設計在邏輯設計的基礎(chǔ)上，對關(guān)系模式的存儲方式和數(shù)據(jù)庫的存取結(jié)構(gòu)進行了物理優(yōu)化。為提高數(shù)據(jù)庫數(shù)據(jù)的存取速度，而需要設置合適的存取方式，主要采用以下兩類存取方式。，主要采用B+ 樹索引方法（1）Passenger、Guide、Scenery 表數(shù)據(jù)量相當大，其中PasName（旅客姓名)、guideName（導游姓名） 、teletphone(電話號碼) 等屬性列，Line 表的start(出發(fā)地)和distination（目的地）等屬性列，以及LineProject表的Pname ( 方案類型名稱)等屬性經(jīng)常出現(xiàn)在查詢條件中，所以在以上幾個表中的這幾列中建立索引。（2）Passenger表的PasNo(旅客編號)，Guide 表的guideNo(導游編號)， Line表的lineNo1(線路編號)，Scenery 表的 SceNo(景點編號)，LineProject表的Pno （方案編號），order表的orderNo（預訂編號）， 等屬性列經(jīng)常出現(xiàn)在鏈接操作的鏈接條件中，在這些列上建立B+樹索引。（3）travelDetail表的price（單價）、 quantity（總票數(shù)）和LineProject表中的Pprice (票價)和等屬性列經(jīng)常被查詢，所以在這幾個表中建立索引。（1）除特殊說明的表外，在其余各表主鍵上默認地建立聚簇索引。（2）預訂明細表和訂單明細中的數(shù)量是經(jīng)常要查詢的數(shù)據(jù)，為加快查詢速度，所以在orderDetail表 quantity列上建立聚簇索引。為了提高系統(tǒng)整體性能，將數(shù)據(jù)庫中的數(shù)據(jù)組織分為多個文件，分開進行存儲。數(shù)據(jù)庫中的數(shù)據(jù)組織一個primary文件進行存儲，以下是對各表數(shù)據(jù)進行分析。（1）數(shù)據(jù)相對穩(wěn)定、數(shù)據(jù)量較大、經(jīng)常用于查詢的表存組，符合該條件的表為： ,（2） 將數(shù)據(jù)變動可能性較大，數(shù)量較大，查詢比較多的表，符合此條件的表： Guide orderdetail （1）在目前實驗條件下，根據(jù)實驗的需求，將各數(shù)據(jù)文件存儲在以下路徑中。create database travelDBon primary ( name=39。 travelDB 39。, filename=39。 C:\myWork\39。, size=1, maxsize=5, filegrowth= 1 )log on ( name=39。travellog39。, filename=39。C:\myWork\39。, size=1, maxsize=5, filegrowth=1)Go5 數(shù)據(jù)庫腳本set nocount on set dateformat ymdcreate database travelDB on primary (name=39。 travelDB 39。, filename=39。e:\myWork\39。, size=1, maxsize=5, filegrowth=1)log on (name=39。OrderLog39。, filename=39。e:\myWork\travelLog .ldf39。, size=1, maxsize=5, filegrowth=1)go/*data mydatabase*/use travelDB go/* add my user*/go/*旅客表*/CREATE TABLE passenger( pasNo char(9) not null /*旅客編號*/ check(pasNo like 39。[P][09][09][09][09][09][09][09][09]39。), pasName varchar(10) not null, /*旅客姓名*/ sex char(1) not null, /*旅客性別*/ address varchar(50) null, /*家庭住址*/ telephone varchar(20) null, /*旅客電話*/ IDNo Char(18) not null /*身份證號*/ constraint passengerPK primary key (pasNo))gogo/*（passenger ）數(shù)據(jù)：*/insert passenger values(39。P2011071039。,39。喻自強39。,39。M39。,39。南京市青海路18號39。,39。1381760500839。, 39。32891019820410123439。)insert passenger values(39。P2011072039。,39。張小梅39。,39。F39。,39。上海市北京路8號39。,39。1381770506839。, 39。42891019790523457839。)insert passenger values(39。P2011072139。,39。張小娟39。,39。F39。,39。上海市南京路66號39。,39。1370730502539。, 39。28605619920328367239。)insert passenger values(39。P2011072239。,39。張露39。, 39。F39。,39。南昌市八一大道130號39。,39。1590720513439。, 39。36103419900328478239。)insert passenger values(39。P20110723