| 導購 | 订阅 | 在线投稿
分享
 
 
 

第三講 數據庫應用程序實例設計(上)

來源:互聯網網民  2006-12-16 17:27:51  評論

從本講開始,我們設計、編寫一個應用程序,在程序的編寫過程中穿插講解數據庫有關知識,這種寫講座的方式是一種嘗試,完整的程序需要很多講之後才能完成,對編寫數據庫程序不熟悉的讀者只要緊跟講座,邊學邊練定會有所收獲。下面就跟著心鈴來開始設計程序吧。

編寫程序設計方案

這裏心鈴就按照第一講中提到編寫數據庫程序的方法來進行。在設計應用程序之前我們先要明白程序的基本要求。心鈴在這裏要帶領大家編寫的程序名稱是「勞保用品發放管理系統」,這是應我們公司生産計劃部編寫的一個實用程序。

程序應該具備哪些主要功能呢?在企業工作的讀者可能都知道,勞動保護用品是國家明文規定必須要給員工發放的,基本要求是:對不同的工種要發放不同的勞保用品以適應從事工種的安全、工作及其他需要。只知道這些對編寫應用程序來說是遠遠不夠的,你必須了解更多的內容才能編寫程序,正如編寫行業商品軟件那樣,你首先要了解行業的運作模式才能寫出符合用戶需求的軟件,所以,要進一步了解企業勞保用品的發放辦法。根據自己掌握的情況並向部門分管人員了解,得知勞保用品發放方法是:按不同的工種發放不同的勞保用品;不同的勞保用品發放周期不同,如棉衣60個月發放一次,工作帽24個月發放一次等;工種變化後勞保用品也隨之變化;不同的工種相同的勞保用品發放周期也不同,比如科室人員的棉衣60個月發放一次,而車間人員的棉衣是48個月發放一次。

知道了勞保用品的發放辦法後,就要詢問用戶的需求了。用戶提出程序應該具備的功能是:員工可以添加和刪除;按單位(部門)每半年下達一次發放計劃給各下屬單位和供應部門,由各單位根據下達的計劃向供應部門提出勞保用品的名稱、規格、數量等,供應部門負責采購,發放計劃中包括單位每個員工應領取的各種勞保用品的名稱、數量、規格及整個單位各種勞保用品的名稱、數量和規格彙總數據。到這裏,讀者可先不往下閱讀講座內容,根據上面提供的發放辦法和用戶的需求,考慮一下程序應該怎麽編寫,應該寫哪些功能,還應該增加哪些用戶沒有提出的功能和輔助功能。

我們應該知道,軟件用戶特別是應用類軟件的用戶一般都不是電腦高手,他們提出定制的軟件功能一般都是最主要的功能,但軟件的編寫人員不能只完成用戶提出的功能。作爲程序編寫人員來說,無論是寫通用軟件還是爲個別客戶定制軟件,都首先要具有盡最大努力讓用戶使用方便、爲用戶著想的思想,所以編程者必須充分考慮用戶可能用到的各種功能和其他一些程序自身需要的功能,就這些用戶沒有提出的功能和用戶溝通,最後確定程序應具備的各種主要和輔助功能。下面就是心鈴最終爲「勞保用品管理系統」確定的各種功能,有些給出了解釋。

(一)本程序應具備的功能:

1 員工基本情況錄入。此功能除了錄入員工姓名、性別等基本信息外,部門、工種、有規格要求的勞保用品的規格等關鍵信息是不可少的。後面會解釋有規格要求的勞保用品是怎麽回事。

2 新員工勞保用品初次發放時間設定。這是一個比較重要的功能,用戶沒提出來。爲什麽要有此功能呢?由于老員工都已經有了發放記錄,每種勞保用品上次的發放時間都記錄下來了,這樣根據發放周期和上次發放時間就可以計算下次下達發放計劃時是否應該發放及發放數量,對新員工來說,由于沒有發放記錄(勞保用品上次發放時間),就無法計算下次什麽時候該發放,所以必須特意制造出一個初始發放時間記錄。根據公司規定,新員工到崗位後就應該在半年之內將所需的所有勞保用品發一套,這樣用戶就可以將新員工的初始發放時間記錄按發放周期向前推一個周期作爲上次發放時間,下次程序統計時就一定能爲此新員工發放勞保用品了。

3 按單位(部門)統計本次發放給各員工、此單位彙總及所有單位彙總的勞保用品名稱、規格、數量,此功能應該是最核心的一個功能了,沒有好解釋的。

4 員工工種改變。這個功能也是很重要的一個功能,員工一般不會在一個崗位上幹一輩子,工種改變是不可避免的,更改了工種,勞保用品種類及發放周期都應重新設定。

5 發放記錄查詢。查詢功能應該是必備的,雖然用戶沒提出來,但應編寫查詢單個員工的所有勞保用品上次發放時間記錄的功能。

6 員工信息修改及刪除員工。這是應該具備的較重要的功能吧。

下面是心鈴認爲的各種輔助功能,雖然劃爲輔助功能,但有些也是比較重要的:

7 某工種勞保用品發放周期修改。企業有時根據實際情況調整某些工種勞保用品的發放周期,必須及時修改,這關系到所有此工種的人員。

8 某工種增加勞保用品。這事也常有,及時增加可使此工種的員工下次發放時都能領到。

9 某工種刪除勞保用品。

10 刪除工種。

12 增加新工種。不要忘記給此新工種添加對應的勞保用品和發放周期。

13 工種改名。

14 勞保用品改名。

15 增加新部門

16 刪除部門

17 部門名稱修改

18 部門合並

19 員工部門改變

20 按部門查詢員工基本信息、查詢所有員工和單個員工信息

以下是心鈴劃出來的其他一些功能:

21 數據庫管理。包括數據庫整理、壓縮、備份、還原等,還是比較重要的。

22 幫助信息。總得給用戶提供幫助文檔吧。

23 打印功能。此功能放在這裏主要是因爲隨著公司辦公自動化的發展,各種計劃直接以電子文檔方式傳送,可以不用打印功能了。

24 關于本系統。現在的軟件都應該有吧,提供版本信息、版權信息、求助聯系方式等。

讀到這裏,大家感覺如何,別看用戶提出的功能很少,但站在用戶角度,本著爲用戶著想的思想,心鈴給程序列出了二十幾項功能,雖然重要性、使用頻率不一樣,但幾乎都是必不可少的。至此,我們完成第一步方案的一半任務,下一半的任務是根據所需功能來構造數據庫結構,包括用幾個數據表、每個表中的字段及屬性設定。

(二) 構造數據庫結構

上面我們已經分析了程序的功能,那麽我們根據上面需要完成的功能來構造需要的數據庫。

我們首先要做的是選擇使用什麽類型的數據庫。選擇什麽樣的數據庫要考慮數據量的多少及要求什麽樣的性能,對我們的這個程序來說,由于是給企業用的,數據量不是太大,就我們公司而言,約八千員工,每人平均勞保用品爲八種,這樣發放記錄大概有6~7萬條;從性能要求來說,每半年集中發放一次,平時就是用來做維護員工在企業內部崗位更換、工種變化、新增員工等一些工作,要求也不高。從這些方面來說,目前的各種類型的數據庫都可以滿足要求,但我們還應該再考慮一下使用方便及數據庫流行的程度。從目前來說,使用DBF數據庫的比較少,由于Delphi是將Paradox作爲自己的標准數據庫的,所以使用Paradox數據庫的也不少,而使用大型數據庫比較複雜也根本沒必要,使用ACCESS97或ACCESS2000類型的數據庫比較多,因此我們可以根據自己的喜好選用Paradox或ACCESS數據庫就可以了。心鈴最終選擇使用的是ACCESS97數據庫,能滿足要求,由于大部分電腦中都安裝有office,所以隨時可以方便地在ACCESS中打開,在中文ACCESS97下建庫也非常方便,加之它只有一個數據庫文件,安裝目錄下只有很少的二三個文件,而不象Paradox數據庫那樣每個數據表是一個文件,還有許多索引文件,看起來讓人煩。

選好了數據庫類型,我們就要來考慮需要幾個數據表了。最基本的我們首先應該想到有員工信息和發放記錄兩個表,再考慮一下工種和對應的勞保用品,我們還應該有一個工種勞保對應信息數據表。由于在錄入數據時應該有部門名稱和工種名稱供選擇,所以必須有部門名稱及代碼、工種及代碼兩個數據表。在未深入編程之前,是否還要用到一些臨時數據表還不能確定,所以這裏我們就把需要的基本數據表構建出來就可以,其他的根據編程需要再構建。我們先來爲數據庫選一個名字吧:LKLB,那麽數據庫文件的全名就是LKLB.MDB。下面我們就來構建LKLB中的這幾個數據表。

1 員工基本信息(取個名字LKYG)

員工信息這個數據庫表中都應該有什麽字段呢?部門名稱、員工姓名、性別、工種名稱是最基本的吧。我們想一下,部門名稱和工種的內容都是漢字,在程序中使用時不是太方便,所以我們最好給每個部門和工種都分配一個對應的數字編號。是否想過員工有重名的現象?這是很常見的,特別象我們八千人的大企業。因此我們必須有一個唯一能區分員工的字段,用數字編號是最常用的,所以給每個員工分配一個唯一編號,不允許重複。另外從程序中的員工勞保用品查詢功能考慮,由于不太可能記住每位員工的編號,所以需要使用姓名來查詢,查詢時輸入員工的姓名漢字是比較麻煩的,常采用的是用姓名的每個漢字的第一個拼音字母來輸入,這樣我們需要增加一個姓名拼音字段。下面該考慮員工的勞保用品的問題了。

關于勞保用品種類問題,按常規只要知道了員工的工種就可以在工種勞保對應信息表中查到該員工所有的勞保用品。如果勞保用品都沒有規格之分就好辦了,如毛巾、香皂每位員工發放的都一樣,但勞保用品中有一些是有規格的,比如棉衣、工作鞋等,每個員工的各不相同,心鈴只能把這些有規格之分的勞保用品放在員工信息表中,當然再爲每位員工建一個有規格的勞保用品數據表也是可以的。還要考慮一個問題,如果我們設計時只設計員工當前的工種對應的有規格的勞保用品是不行的,因爲作爲一個字段來說,應該都是同一類的,那麽我們就必須將所有帶規格的勞保用品都設定一個字段,在錄入時即使員工所屬的工種沒有這種勞保用品也錄入。這樣做有一個好處,正常情況下根據工種對應的勞保發放,如果碰到有規格的勞保用品就到員工信息表中來查詢規格,當然有些是用不到的。如果員工工種變化了,有了和以前不同的有規格的勞保用品,那麽就不用再修改員工信息表了,因爲事先都已經錄入了,這樣可以做到無論員工的工種怎麽變化,員工信息表都無需再改變。至此,我們的員工基本信息數據表的字段就可以確定了。下面是LKYG數據表中的字段、字段類型、長度等彙總表。

||||||LKYG數據表字段信息列表

字段名稱

含義

類型

長度

備注

bmbh

部門編號

文本

3

索引有重複

xm

姓名

文本

8

xmdm

姓名拼音

文本

4

ygbh

員工編號

文本

6

索引無重複

xb

性別

文本

2

gzbh

工種編號

文本

3

gzfgg

工作服規格

文本

3

mygg

棉衣規格

文本

3

cygg

襯衣規格

文本

3

bwx

白網鞋規格

文本

4

bjx

布膠鞋規格

文本

4

jx

膠靴規格

文本

4

jyx

絕緣鞋規格

文本

4

xz

文化衫規格

文本

4

由于考慮到都是按部門來發放,所以建立部門編號索引可以提高程序的執行效率;員工應有一個不允許重複的員工編號索引。

2 發放記錄數據表(FFJL)

發放記錄數據表結構如下:

字段名稱

含義

類型

長度

備注

bmbh

部門編號

文本

3

索引有重複

ygbh

員工編號

文本

6

gzbh

工種編號

文本

3

lbmc

勞保名稱

文本

12

ffrq

發放日期(上次)

日期

ffzq

發放周期(月)

整型

按部門索引主要是爲了提高統計速度。爲什麽在這裏要加上發放周期呢?心鈴是這麽考慮的,只要平時員工工種變動等能及時在程序中更改,那麽每次發放時,就根據這個發放記錄中的發放日期和發放周期直接計算是否應該發、該發多少數量,就沒有必要對每個員工再通過其工種去查其勞保用品的發放周期了,這裏雖然使得數據庫有點冗余,但寫程序比較方便。由于人員較多,不可能每次發放都做流水記錄,否則每次要增加幾萬條記錄。所以心鈴采用的是只保存最近的發放記錄,也就說發放後發放日期將更新爲最近的一次的發放日期,這樣保證不影響以後的發放,而數據庫也不會迅速膨脹。

3 工種勞保對應數據表(GZLB)

結構如下:

字段名稱

含義

類型

長度

備注

gzbh

工種編號

文本

3

索引有重複

lbmc

勞保名稱

文本

12

ffzq

發放周期

整型

4 部門數據表(BM)

結構如下:

字段名稱

含義

類型

長度

備注

bmbh

部門編號

文本

3

索引無重複

bmmc

部門名稱

文本

24

索引無重複

5 工種數據表(GZ)

結構如下:

字段名稱

含義

類型

長度

備注

gzbh

工種編號

文本

3

索引無重複

gzmc

工種名稱

文本

24

索引無重複

到這裏,我們已經把數據庫結構構造出來了,請讀者建立LKLB數據庫並在數據庫中建立上述五個數據表吧,並利用第二講中講到的建立數據庫別名的方法爲數據庫建立別名lklb。下一講將繼續按照心鈴在第一講提到的幾個步驟進行資料准備、編寫程序流程等工作。

 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
從本講開始,我們設計、編寫一個應用程序,在程序的編寫過程中穿插講解數據庫有關知識,這種寫講座的方式是一種嘗試,完整的程序需要很多講之後才能完成,對編寫數據庫程序不熟悉的讀者只要緊跟講座,邊學邊練定會有所收獲。下面就跟著心鈴來開始設計程序吧。 編寫程序設計方案 這裏心鈴就按照第一講中提到編寫數據庫程序的方法來進行。在設計應用程序之前我們先要明白程序的基本要求。心鈴在這裏要帶領大家編寫的程序名稱是「勞保用品發放管理系統」,這是應我們公司生産計劃部編寫的一個實用程序。 程序應該具備哪些主要功能呢?在企業工作的讀者可能都知道,勞動保護用品是國家明文規定必須要給員工發放的,基本要求是:對不同的工種要發放不同的勞保用品以適應從事工種的安全、工作及其他需要。只知道這些對編寫應用程序來說是遠遠不夠的,你必須了解更多的內容才能編寫程序,正如編寫行業商品軟件那樣,你首先要了解行業的運作模式才能寫出符合用戶需求的軟件,所以,要進一步了解企業勞保用品的發放辦法。根據自己掌握的情況並向部門分管人員了解,得知勞保用品發放方法是:按不同的工種發放不同的勞保用品;不同的勞保用品發放周期不同,如棉衣60個月發放一次,工作帽24個月發放一次等;工種變化後勞保用品也隨之變化;不同的工種相同的勞保用品發放周期也不同,比如科室人員的棉衣60個月發放一次,而車間人員的棉衣是48個月發放一次。 知道了勞保用品的發放辦法後,就要詢問用戶的需求了。用戶提出程序應該具備的功能是:員工可以添加和刪除;按單位(部門)每半年下達一次發放計劃給各下屬單位和供應部門,由各單位根據下達的計劃向供應部門提出勞保用品的名稱、規格、數量等,供應部門負責采購,發放計劃中包括單位每個員工應領取的各種勞保用品的名稱、數量、規格及整個單位各種勞保用品的名稱、數量和規格彙總數據。到這裏,讀者可先不往下閱讀講座內容,根據上面提供的發放辦法和用戶的需求,考慮一下程序應該怎麽編寫,應該寫哪些功能,還應該增加哪些用戶沒有提出的功能和輔助功能。 我們應該知道,軟件用戶特別是應用類軟件的用戶一般都不是電腦高手,他們提出定制的軟件功能一般都是最主要的功能,但軟件的編寫人員不能只完成用戶提出的功能。作爲程序編寫人員來說,無論是寫通用軟件還是爲個別客戶定制軟件,都首先要具有盡最大努力讓用戶使用方便、爲用戶著想的思想,所以編程者必須充分考慮用戶可能用到的各種功能和其他一些程序自身需要的功能,就這些用戶沒有提出的功能和用戶溝通,最後確定程序應具備的各種主要和輔助功能。下面就是心鈴最終爲「勞保用品管理系統」確定的各種功能,有些給出了解釋。 (一)本程序應具備的功能: 1 員工基本情況錄入。此功能除了錄入員工姓名、性別等基本信息外,部門、工種、有規格要求的勞保用品的規格等關鍵信息是不可少的。後面會解釋有規格要求的勞保用品是怎麽回事。 2 新員工勞保用品初次發放時間設定。這是一個比較重要的功能,用戶沒提出來。爲什麽要有此功能呢?由于老員工都已經有了發放記錄,每種勞保用品上次的發放時間都記錄下來了,這樣根據發放周期和上次發放時間就可以計算下次下達發放計劃時是否應該發放及發放數量,對新員工來說,由于沒有發放記錄(勞保用品上次發放時間),就無法計算下次什麽時候該發放,所以必須特意制造出一個初始發放時間記錄。根據公司規定,新員工到崗位後就應該在半年之內將所需的所有勞保用品發一套,這樣用戶就可以將新員工的初始發放時間記錄按發放周期向前推一個周期作爲上次發放時間,下次程序統計時就一定能爲此新員工發放勞保用品了。 3 按單位(部門)統計本次發放給各員工、此單位彙總及所有單位彙總的勞保用品名稱、規格、數量,此功能應該是最核心的一個功能了,沒有好解釋的。 4 員工工種改變。這個功能也是很重要的一個功能,員工一般不會在一個崗位上幹一輩子,工種改變是不可避免的,更改了工種,勞保用品種類及發放周期都應重新設定。 5 發放記錄查詢。查詢功能應該是必備的,雖然用戶沒提出來,但應編寫查詢單個員工的所有勞保用品上次發放時間記錄的功能。 6 員工信息修改及刪除員工。這是應該具備的較重要的功能吧。 下面是心鈴認爲的各種輔助功能,雖然劃爲輔助功能,但有些也是比較重要的: 7 某工種勞保用品發放周期修改。企業有時根據實際情況調整某些工種勞保用品的發放周期,必須及時修改,這關系到所有此工種的人員。 8 某工種增加勞保用品。這事也常有,及時增加可使此工種的員工下次發放時都能領到。 9 某工種刪除勞保用品。 10 刪除工種。 12 增加新工種。不要忘記給此新工種添加對應的勞保用品和發放周期。 13 工種改名。 14 勞保用品改名。 15 增加新部門 16 刪除部門 17 部門名稱修改 18 部門合並 19 員工部門改變 20 按部門查詢員工基本信息、查詢所有員工和單個員工信息 以下是心鈴劃出來的其他一些功能: 21 數據庫管理。包括數據庫整理、壓縮、備份、還原等,還是比較重要的。 22 幫助信息。總得給用戶提供幫助文檔吧。 23 打印功能。此功能放在這裏主要是因爲隨著公司辦公自動化的發展,各種計劃直接以電子文檔方式傳送,可以不用打印功能了。 24 關于本系統。現在的軟件都應該有吧,提供版本信息、版權信息、求助聯系方式等。 讀到這裏,大家感覺如何,別看用戶提出的功能很少,但站在用戶角度,本著爲用戶著想的思想,心鈴給程序列出了二十幾項功能,雖然重要性、使用頻率不一樣,但幾乎都是必不可少的。至此,我們完成第一步方案的一半任務,下一半的任務是根據所需功能來構造數據庫結構,包括用幾個數據表、每個表中的字段及屬性設定。 (二) 構造數據庫結構 上面我們已經分析了程序的功能,那麽我們根據上面需要完成的功能來構造需要的數據庫。 我們首先要做的是選擇使用什麽類型的數據庫。選擇什麽樣的數據庫要考慮數據量的多少及要求什麽樣的性能,對我們的這個程序來說,由于是給企業用的,數據量不是太大,就我們公司而言,約八千員工,每人平均勞保用品爲八種,這樣發放記錄大概有6~7萬條;從性能要求來說,每半年集中發放一次,平時就是用來做維護員工在企業內部崗位更換、工種變化、新增員工等一些工作,要求也不高。從這些方面來說,目前的各種類型的數據庫都可以滿足要求,但我們還應該再考慮一下使用方便及數據庫流行的程度。從目前來說,使用DBF數據庫的比較少,由于Delphi是將Paradox作爲自己的標准數據庫的,所以使用Paradox數據庫的也不少,而使用大型數據庫比較複雜也根本沒必要,使用ACCESS97或ACCESS2000類型的數據庫比較多,因此我們可以根據自己的喜好選用Paradox或ACCESS數據庫就可以了。心鈴最終選擇使用的是ACCESS97數據庫,能滿足要求,由于大部分電腦中都安裝有office,所以隨時可以方便地在ACCESS中打開,在中文ACCESS97下建庫也非常方便,加之它只有一個數據庫文件,安裝目錄下只有很少的二三個文件,而不象Paradox數據庫那樣每個數據表是一個文件,還有許多索引文件,看起來讓人煩。 選好了數據庫類型,我們就要來考慮需要幾個數據表了。最基本的我們首先應該想到有員工信息和發放記錄兩個表,再考慮一下工種和對應的勞保用品,我們還應該有一個工種勞保對應信息數據表。由于在錄入數據時應該有部門名稱和工種名稱供選擇,所以必須有部門名稱及代碼、工種及代碼兩個數據表。在未深入編程之前,是否還要用到一些臨時數據表還不能確定,所以這裏我們就把需要的基本數據表構建出來就可以,其他的根據編程需要再構建。我們先來爲數據庫選一個名字吧:LKLB,那麽數據庫文件的全名就是LKLB.MDB。下面我們就來構建LKLB中的這幾個數據表。 1 員工基本信息(取個名字LKYG) 員工信息這個數據庫表中都應該有什麽字段呢?部門名稱、員工姓名、性別、工種名稱是最基本的吧。我們想一下,部門名稱和工種的內容都是漢字,在程序中使用時不是太方便,所以我們最好給每個部門和工種都分配一個對應的數字編號。是否想過員工有重名的現象?這是很常見的,特別象我們八千人的大企業。因此我們必須有一個唯一能區分員工的字段,用數字編號是最常用的,所以給每個員工分配一個唯一編號,不允許重複。另外從程序中的員工勞保用品查詢功能考慮,由于不太可能記住每位員工的編號,所以需要使用姓名來查詢,查詢時輸入員工的姓名漢字是比較麻煩的,常采用的是用姓名的每個漢字的第一個拼音字母來輸入,這樣我們需要增加一個姓名拼音字段。下面該考慮員工的勞保用品的問題了。 關于勞保用品種類問題,按常規只要知道了員工的工種就可以在工種勞保對應信息表中查到該員工所有的勞保用品。如果勞保用品都沒有規格之分就好辦了,如毛巾、香皂每位員工發放的都一樣,但勞保用品中有一些是有規格的,比如棉衣、工作鞋等,每個員工的各不相同,心鈴只能把這些有規格之分的勞保用品放在員工信息表中,當然再爲每位員工建一個有規格的勞保用品數據表也是可以的。還要考慮一個問題,如果我們設計時只設計員工當前的工種對應的有規格的勞保用品是不行的,因爲作爲一個字段來說,應該都是同一類的,那麽我們就必須將所有帶規格的勞保用品都設定一個字段,在錄入時即使員工所屬的工種沒有這種勞保用品也錄入。這樣做有一個好處,正常情況下根據工種對應的勞保發放,如果碰到有規格的勞保用品就到員工信息表中來查詢規格,當然有些是用不到的。如果員工工種變化了,有了和以前不同的有規格的勞保用品,那麽就不用再修改員工信息表了,因爲事先都已經錄入了,這樣可以做到無論員工的工種怎麽變化,員工信息表都無需再改變。至此,我們的員工基本信息數據表的字段就可以確定了。下面是LKYG數據表中的字段、字段類型、長度等彙總表。 ||||||LKYG數據表字段信息列表 字段名稱 含義 類型 長度 備注 bmbh 部門編號 文本 3 索引有重複 xm 姓名 文本 8 xmdm 姓名拼音 文本 4 ygbh 員工編號 文本 6 索引無重複 xb 性別 文本 2 gzbh 工種編號 文本 3 gzfgg 工作服規格 文本 3 mygg 棉衣規格 文本 3 cygg 襯衣規格 文本 3 bwx 白網鞋規格 文本 4 bjx 布膠鞋規格 文本 4 jx 膠靴規格 文本 4 jyx 絕緣鞋規格 文本 4 xz 文化衫規格 文本 4 由于考慮到都是按部門來發放,所以建立部門編號索引可以提高程序的執行效率;員工應有一個不允許重複的員工編號索引。 2 發放記錄數據表(FFJL) 發放記錄數據表結構如下: 字段名稱 含義 類型 長度 備注 bmbh 部門編號 文本 3 索引有重複 ygbh 員工編號 文本 6 gzbh 工種編號 文本 3 lbmc 勞保名稱 文本 12 ffrq 發放日期(上次) 日期 ffzq 發放周期(月) 整型 按部門索引主要是爲了提高統計速度。爲什麽在這裏要加上發放周期呢?心鈴是這麽考慮的,只要平時員工工種變動等能及時在程序中更改,那麽每次發放時,就根據這個發放記錄中的發放日期和發放周期直接計算是否應該發、該發多少數量,就沒有必要對每個員工再通過其工種去查其勞保用品的發放周期了,這裏雖然使得數據庫有點冗余,但寫程序比較方便。由于人員較多,不可能每次發放都做流水記錄,否則每次要增加幾萬條記錄。所以心鈴采用的是只保存最近的發放記錄,也就說發放後發放日期將更新爲最近的一次的發放日期,這樣保證不影響以後的發放,而數據庫也不會迅速膨脹。 3 工種勞保對應數據表(GZLB) 結構如下: 字段名稱 含義 類型 長度 備注 gzbh 工種編號 文本 3 索引有重複 lbmc 勞保名稱 文本 12 ffzq 發放周期 整型 4 部門數據表(BM) 結構如下: 字段名稱 含義 類型 長度 備注 bmbh 部門編號 文本 3 索引無重複 bmmc 部門名稱 文本 24 索引無重複 5 工種數據表(GZ) 結構如下: 字段名稱 含義 類型 長度 備注 gzbh 工種編號 文本 3 索引無重複 gzmc 工種名稱 文本 24 索引無重複 到這裏,我們已經把數據庫結構構造出來了,請讀者建立LKLB數據庫並在數據庫中建立上述五個數據表吧,並利用第二講中講到的建立數據庫別名的方法爲數據庫建立別名lklb。下一講將繼續按照心鈴在第一講提到的幾個步驟進行資料准備、編寫程序流程等工作。
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 
 熱帖排行
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有