當前位置:首頁 » 數據倉庫 » 資料庫碼表設計
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

資料庫碼表設計

發布時間: 2022-11-15 06:04:08

『壹』 資料庫碼表是什麼意思

碼表就是代碼表,例如性別代碼表的值為男和女,類似於數據字典,一般是一對多的關系。
以性別代碼表為例:sex : id name
1 男
2 女
我想獲得一個性別為男的值只需要設置sex.id='1'就可以了。

『貳』 資料庫設計的步驟有哪些

資料庫的設計過程大致可分為以下六個階段:

1. 需求分析階段

需求收集和分析,結果得到數據字典描述的數據需求(和數據流圖描述的處理需求)。

2. 概念結構設計階段

通過對用戶需求進行綜合、歸納與抽象,形成一個獨立於具體DBMS的概念模型,可以用E-R圖表示。

3. 邏輯結構設計階段

將概念結構轉換為某個DBMS所支持的數據模型(例如關系模型),並對其進行優化。

4. 資料庫物理設計階段

為邏輯數據模型選取一個最適合應用環境的物理結構(包括存儲結構和存取方法)。

5. 資料庫實施階段

運用DBMS提供的數據語言(例如SQL)及其宿主語言(例如C),根據邏輯設計和物理設計的結果建立資料庫,編制與調試應用程序,組織數據入庫,並進行試運行。

6. 資料庫運行和維護階段

資料庫應用系統經過試運行後即可投入正式運行。在資料庫系統運行過程中必須不斷地對其進行評價、調整與修改。

『叄』 資料庫設計的設計技巧

(需求分析階段)
1) 理解客戶需求,詢問用戶如何看待未來需求變化。讓客戶解釋其需求,而且隨著開發的繼續,還要經常詢問客戶保證其需求仍然在開發的目的之中。
2) 了解企業業務可以在以後的開發階段節約大量的時間。
3) 重視輸入輸出。
在定義資料庫表和欄位需求(輸入)時,首先應檢查現有的或者已經設計出的報表、查詢和視圖(輸出)以決定為了支持這些輸出哪些是必要的表和欄位。
舉例:假如客戶需要一個報表按照郵政編碼排序、分段和求和,你要保證其中包括了單獨的郵政編碼欄位而不要把郵政編碼糅進地址欄位里。
4) 創建數據字典和ER 圖表
ER 圖表和數據字典可以讓任何了解資料庫的人都明確如何從資料庫中獲得數據。ER圖對表明表之間關系很有用,而數據字典則說明了每個欄位的用途以及任何可能存在的別名。對SQL表達式的文檔化來說這是完全必要的。
5) 定義標準的對象命名規范
資料庫各種對象的命名必須規范。 (資料庫邏輯設計)
表設計原則
1) 標准化和規范化
數據的標准化有助於消除資料庫中的數據冗餘。標准化有好幾種形式,但Third Normal Form(3NF)通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說,遵守3NF 標準的資料庫的表設計原則是:「One Fact in One Place」即某個表只包括其本身基本的屬性,當不是它們本身所具有的屬性時需進行分解。表之間的關系通過外鍵相連接。它具有以下特點:有一組表專門存放通過鍵連接起來的關聯數據。
舉例:某個存放客戶及其有關定單的3NF資料庫就可能有兩個表:Customer 和Order。Order 表不包含定單關聯客戶的任何信息,但表內會存放一個鍵值,該鍵指向Customer 表裡包含該客戶信息的那一行。
事實上,為了效率的緣故,對表不進行標准化有時也是必要的。
2) 數據驅動
採用數據驅動而非硬編碼的方式,許多策略變更和維護都會方便得多,大大增強系統的靈活性和擴展性。
舉例,假如用戶界面要訪問外部數據源(文件、XML 文檔、其他資料庫等),不妨把相應的連接和路徑信息存儲在用戶界面支持表裡。還有,如果用戶界面執行工作流之類的任務(發送郵件、列印信箋、修改記錄狀態等),那麼產生工作流的數據也可以存放在資料庫里。角色許可權管理也可以通過數據驅動來完成。事實上,如果過程是數據驅動的,你就可以把相當大的責任推給用戶,由用戶來維護自己的工作流過程。
3) 考慮各種變化
在設計資料庫的時候考慮到哪些數據欄位將來可能會發生變更。
舉例,姓氏就是如此(注意是西方人的姓氏,比如女性結婚後從夫姓等)。所以,在建立系統存儲客戶信息時,在單獨的一個數據表裡存儲姓氏欄位,而且還附加起始日和終止日等欄位,這樣就可以跟蹤這一數據條目的變化。
4) 每個表中都應該添加的3 個有用的欄位
dRecordCreationDate,在VB 下默認是Now(),而在SQL Server · 下默認為GETDATE()
sRecordCreator,在SQL Server 下默認為NOT NULL DEFAULT · USER
nRecordVersion,記錄的版本標記;有助於准確說明記錄中出現null 數據或者丟失數據的原因 ·
5) 對地址和電話採用多個欄位
描述街道地址就短短一行記錄是不夠的。 Address_Line1、Address_Line2 和Address_Line3 可以提供更大的靈活性。還有,電話號碼和郵件地址最好擁有自己的數據表,其間具有自身的類型和標記類別。
6) 使用角色實體定義屬於某類別的列
在需要對屬於特定類別或者具有特定角色的事物做定義時,可以用角色實體來創建特定的時間關聯關系,從而可以實現自我文檔化。
舉例:用PERSON 實體和PERSON_TYPE 實體來描述人員。比方說,當John Smith, Engineer 提升為John Smith, Director 乃至最後爬到John Smith, CIO 的高位,而所有你要做的不過是改變兩個表PERSON 和PERSON_TYPE 之間關系的鍵值,同時增加一個日期/時間欄位來知道變化是何時發生的。這樣,你的PERSON_TYPE 表就包含了所有PERSON 的可能類型,比如Associate、Engineer、Director、CIO 或者CEO 等。還有個替代辦法就是改變PERSON 記錄來反映新頭銜的變化,不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。
7) 選擇數字類型和文本類型盡量充足
在SQL 中使用smallint 和tinyint 類型要特別小心。比如,假如想看看月銷售總額,總額欄位類型是smallint,那麼,如果總額超過了$32,767 就不能進行計算操作了。
而ID 類型的文本欄位,比如客戶ID 或定單號等等都應該設置得比一般想像更大。假設客戶ID 為10 位數長。那你應該把資料庫表欄位的長度設為12 或者13 個字元長。但這額外占據的空間卻無需將來重構整個資料庫就可以實現資料庫規模的增長了。
8) 增加刪除標記欄位
在表中包含一個「刪除標記」欄位,這樣就可以把行標記為刪除。在關系資料庫里不要單獨刪除某一行;最好採用清除數據程序而且要仔細維護索引整體性。 (資料庫邏輯設計)
鍵選擇原則:
1) 鍵設計4 原則為
關聯欄位創建外鍵。
所有的鍵都必須唯一。
避免使用復合鍵。
外鍵總是關聯唯一的鍵欄位。
2) 使用系統生成的主鍵
設計資料庫的時候採用系統生成的鍵作為主鍵,那麼實際控制了資料庫的索引完整性。這樣,資料庫和非人工機制就有效地控制了對存儲數據中每一行的訪問。採用系統生成鍵作為主鍵還有一個優點:當擁有一致的鍵結構時,(不讓主鍵具有可更新性)
在確定採用什麼欄位作為表的鍵的時候,可一定要小心用戶將要編輯的欄位。通常的情況下不要選擇用戶可編輯的欄位作為鍵。
4) 可選鍵有時可做主鍵
把可選鍵進一步用做主鍵,可以擁有建立強大索引的能力。
索引使用原則:
索引是從資料庫中獲取數據的最高效方式之一。95%的資料庫性能問題都可以採用索引技術得到解決。
1) 邏輯主鍵使用唯一的成組索引,對系統鍵(作為存儲過程)採用唯一的非成組索引,對任何外鍵列採用非成組索引。考慮資料庫的空間有多大,表如何進行訪問,還有這些訪問是否主要用作讀寫。
2) 大多數資料庫都索引自動創建的主鍵欄位,但是可別忘了索引外鍵,它們也是經常使用的鍵,比如運行查詢顯示主表和所有關聯表的某條記錄就用得上。
3) 不要索引memo/note 欄位,不要索引大型欄位(有很多字元),這樣作會讓索引佔用太多的存儲空間。
4) 不要索引常用的小型表
不要為小型數據表設置任何鍵,假如它們經常有插入和刪除操作就更別這樣作了。對這些插入和刪除操作的索引維護可能比掃描表空間消耗更多的時間。 (資料庫邏輯設計)
1) 完整性實現機制:
實體完整性:主鍵
參照完整性:
父表中刪除數據:級聯刪除;受限刪除;置空值
父表中插入數據:受限插入;遞歸插入
父表中更新數據:級聯更新;受限更新;置空值
DBMS對參照完整性可以有兩種方法實現:外鍵實現機制(約束規則)和觸發器實現機制
用戶定義完整性:
NOT NULL;CHECK;觸發器
2) 用約束而非商務規則強制數據完整性
採用資料庫系統實現數據的完整性。這不但包括通過標准化實現的完整性而且還包括數據的功能性。在寫數據的時候還可以增加觸發器來保證數據的正確性。不要依賴於商務層保證數據完整性;它不能保證表之間(外鍵)的完整性所以不能強加於其他完整性規則之上。
3) 強制指示完整性
在有害數據進入資料庫之前將其剔除。激活資料庫系統的指示完整性特性。這樣可以保持數據的清潔而能迫使開發人員投入更多的時間處理錯誤條件。
4) 使用查找控制數據完整性
控制數據完整性的最佳方式就是限制用戶的選擇。只要有可能都應該提供給用戶一個清晰的價值列表供其選擇。這樣將減少鍵入代碼的錯誤和誤解同時提供數據的一致性。某些公共數據特別適合查找:國家代碼、狀態代碼等。
5) 採用視圖
為了在資料庫和應用程序代碼之間提供另一層抽象,可以為應用程序建立專門的視圖而不必非要應用程序直接訪問數據表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。 1) 避免使用觸發器
觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要採用觸發器,你最好集中對它文檔化。
2) 使用常用英語(或者其他任何語言)而不要使用編碼
在創建下拉菜單、列表、報表時最好按照英語名排序。假如需要編碼,可以在編碼旁附上用戶知道的英語。
3) 保存常用信息
讓一個表專門存放一般資料庫信息非常有用。在這個表裡存放資料庫當前版本、檢查/修復(對 Access)、關聯設計文檔的名稱、客戶等信息。這樣可以實現一種簡單機制跟蹤資料庫,當客戶抱怨他們的資料庫沒有達到希望的要求而與你聯系時,這樣做對非客戶機/伺服器環境特別有用。
4) 包含版本機制
在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長,用戶的需求總是會改變的。最終可能會要求修改資料庫結構。把版本信息直接存放到資料庫中更為方便。
5) 編制文檔
採用給表、列、觸發器等加註釋的資料庫工具。對開發、支持和跟蹤修改非常有用。
對資料庫文檔化,或者在資料庫自身的內部或者單獨建立文檔。這樣,當過了一年多時間後再回過頭來做第2 個版本,犯錯的機會將大大減少。
6) 測試、測試、反復測試
建立或者修訂資料庫之後,必須用用戶新輸入的數據測試數據欄位。最重要的是,讓用戶進行測試並且同用戶一道保證選擇的數據類型滿足商業要求。測試需要在把新資料庫投入實際服務之前完成。
7) 檢查設計
在開發期間檢查資料庫設計的常用技術是通過其所支持的應用程序原型檢查資料庫。換句話說,針對每一種最終表達數據的原型應用,保證你檢查了數據模型並且查看如何取出數據。

『肆』 資料庫設計的基本步驟

資料庫設計的基本步驟如下:

1、安裝並打開MySQL WorkBench軟體以後,在軟體的左側邊欄有三個選項,分別是對應「連接資料庫」、「設計資料庫」、「遷移資料庫」的功能。這類選擇第二項,設計資料庫,點擊右邊的「+」號,創建models。

『伍』 數據表設計考慮哪些問題

DB2資料庫的性能與穩定性直接跟資料庫對象的多少、大小有關。如果對象很少,不復雜,那麼就算不怎麼規劃,也能夠達到比較高的性能。如果對象數據比較多、比較大的話,那麼就需要在資料庫設計之前好好的規劃,否則會在很大程度上影響資料庫的性能與穩定性。

一、選擇合適的語言與資料庫字元集。

在企業中部署資料庫的時候,首先需要在操作系統上安裝資料庫。而在安裝資料庫的時候,需要選擇安裝的語言環境。即是以中文狀態下安裝資料庫還是以英文狀態安裝資料庫。如在啟動安裝程序的時,可以利用/i language選項來指定安裝過程中所採用的語言。到目前為止,DB2資料庫已經支持很多種語言。那麼資料庫在安裝過程中,該採用什麼語言呢?筆者建議,只要資料庫管理員有一點英語基礎,最好能夠採用英文語言環境來進行安裝。雖然說現在DB2資料庫的中文語言環境已經設計的比較完善,但是筆者仍然擔心其有一些不知名的漏洞。為此筆者在安裝DB2資料庫的時候,基本上都採用的是英文語言環境來進行安裝。即將語言設置為「EN」,表示英文。提高DB2數據備份與恢復的效率。

另外如果DB2 資料庫中要保存英文以外的數據,或者說用戶會使用不同的字元集訪問資料庫時,還需要在資料庫安裝過程中選擇特定的資料庫字元集。DB2資料庫中的所有字元數據,包括數據字典中的數據,都是存儲在資料庫字元集中的。如果用戶使用不同的字元集訪問資料庫時,資料庫管理員就需要選擇包含所有這些用戶的字元集的超集。只有如此,才能夠確保系統能夠很方便的使用替代字元完成字元的轉換,從而提高資料庫的性能。如果用戶選擇的字元集不對,有可能會出現一些莫名其妙的問題。如一次用戶在安裝資料庫過程中,沒有選擇合適的字元集。雖然在使用的過程中,其存儲中文字元沒有問題。但是當對資料庫採取還原操作時,卻發現還原後的資料庫中有些原來是中文字元的地方,盡然出現了亂碼。這主要就是沒有選擇合適的字元集惹的禍。有時候如果字元集選擇不當的話,從外部數據源(如Excel表格)導入數據的時候,中文數據也會無法順利導入。所以,資料庫管理員在安裝資料庫的時候,需要根據實際企業,來選擇合適的字元集。

二、評估資料庫對象的大小、數量。

DB2資料庫的性能與穩定性直接跟資料庫對象的多少、大小有關。如果對象很少,不復雜,那麼就算不怎麼規劃,也能夠達到比較高的性能。如果對象數據比較多、比較大的話,那麼就需要在資料庫設計之前好好的規劃,否則會在很大程度上影響資料庫的性能與穩定性。其實DB2 資料庫就好像一個倉庫,資料庫中的對象(如索引、數據表、表空間)等等就好像倉庫中的貨物。如果貨物比較少,那麼隨便放放,倉庫都顯得很空曠。貨物尋找起來也會很方便。但是如果貨物數量比較多、比較大,就必須要對其存儲空間進行合理規劃。只有如此才能夠讓倉庫的空間利用率達到最佳狀態。並且貨物的存放有序,在查找起來也特別的方便。筆者這里就以倉庫管理為例,說話該如何做好資料庫對象大小、數量等方便的評估,以及他們對於資料庫性能與穩定性的影響。

1、根據對象大小來規劃存儲空間。在倉庫貨物的擺放上,要根據貨物的大小來規劃存儲空間。或者說要首先防止大的貨物。只有如此空間的利用率才會最高。其實在規劃DB2對象的時候,也是如此。如某些表可能會包含的記錄比較多,屬於大表。此時資料庫管理員就需要考慮,是否將其放置在一個獨立的表空間或者硬碟空間上,以提高數據操作的性能。大表所對應的索引往往也是比較大的。為此在硬體條件允許的情況下,將索引表與數據表分別存放在不同的硬碟上,可以提高資料庫的性能。而對於一些比較小的對象(如數據表),可以將它們存放在一個表空間中。其實這個表空間就好像倉庫中的一個個紙盒子。將小的對象放入到這個「紙盒子」中,不但不佔空間,而且也容易管理。

2、根據對象的使用頻率來規劃存放空間。在倉庫中擺放物品的時候,往往會把近期就要用到的貨物或者頻繁需要用到的東西放在倉庫門口或者容易拿到的地方。如此在拿這些貨物時就會比較便捷,也不會對其他貨物產生影響。對於DB2資料庫中的對象來說,也是這么一回事。可以將那些訪問量比較大的對象,如索引、數據表,存放在性能比較好的硬碟上或者單獨的硬碟中。此時訪問這些數據,就不會與其它對象產生I/O沖突,操作起來速度就會比較快。而將不怎麼用到的對象,存放在一起。由於他們不怎麼被用到,所以即使存放在性能比較低的硬碟上,其對資料庫性能產生的負面影響也是非常有限的。 在DB2資料庫裡面如何更新執行計劃

3、根據類別來存放資料庫對象。在倉庫中存放貨物的時候,還會對其進行分類。然後根據類別來進行存放。這有利於貨物的管理與檢索。其實在資料庫對象存儲空間設計時,也需要考慮這個因素。如現在應用軟體在設計的時候,很多都是根據模塊來設計。那麼在資料庫對象設計時,也需要根據這個模塊來設計存儲的空間。如將同一個模塊的資料庫對象存放在同一個表空間內。不過這可能會跟上面的兩個建立相違背。此時最好是在對象的命名上做文章。如可以根據模塊的不同,分別給資料庫對象取一個相同的前綴或者後綴。如即使同一塊模塊要用到多個表空間,此時就可以給表空間一個相同的前綴。如此在管理資料庫對象的時候,根據表空間的前綴就可以判斷其所屬的模塊了。如果再加上一個後綴來表示其資料庫對象的分類,那麼就更合理了。為此在管理資料庫對象的時候,要執行分類管理。不僅要從技術上對其進行分類,如分為索引、數據表、關鍵字等等。還需要從功能上進行分類,如按應用程序的模塊來進行分類等等。

三、設計好資料庫備份與還原的方案。

在資料庫交付生產使用之後,往往需要進行大量的測試。但是在測試過程中往往又會產生很多的垃圾數據。可是交給企業應用的,肯定是一個干凈的資料庫系統。為此在資料庫設計的時候,就需要想好如果減少測試過程中的垃圾數據。或者採取什麼樣的方式來實現在交互時自動清除垃圾數據的機制。

一般來說,想要一個資料庫備份與還原的方案,減少資料庫測試所產生的垃圾數據。如現在在給企業部署資料庫的時候,往往是先安裝一個干凈的資料庫系統。當然字元集這些需要預先設置好。然後再利用資料庫還原功能將預先定義好的資料庫模型還原出來。

另外有些時候需要兩個方案互為補充。如在資料庫初始化的過程中,採用資料庫還原的方式來創建資料庫對象。但是在應用軟體升級的時候,由於此時已經有了用戶的數據,為此不能夠在使用資料庫還原的方法。而是通過應用程序來執行某些SQL代碼,來調整或者增加部分資料庫對象。無論採用哪一種方式,需要遵循的一個原則就是在給企業創建資料庫對象時要最大限度的減少測試。而要做到這一點,就是需要先在測試伺服器上創建對象並測試對象可用。然後直接將相關的SQL代碼在投入使用的資料庫伺服器上執行。

『陸』 資料庫設計的基本步驟

資料庫設計的基本步驟

1、需求分析階段

進行資料庫設計首先必須准確了解與分析用戶需求(包括數據與處理)。需求分析是整個設計過程的基礎,是最困難和最耗費時間的一步。作為「地基」的需求分析是否做得充分與准確,決定了在其上構建資料庫「大廈」的速度與質量。需求分析做的不好,可能會導致整個資料庫設計返工重做。

2、概念結構設計階段

概念結構設計階段是整個資料庫設計的關鍵,它通過對用戶需求進行綜合、歸納與抽象,形成一個獨立於具體資料庫管理系統的概念模型。

3、邏輯結構設計階段

邏輯結構設計是將概念結構轉換為某個資料庫管理系統所支持的數據模型,並對其進行優化。

4、物理設計階段

物理結構設計師為邏輯數據模型選取一個最適合應用環境的物理結構(包括存儲結構和存取方式)。

5、資料庫實施階段

在資料庫實施階段,設計人員運用資料庫管理系統提供資料庫語言及其宿主語言,根據邏輯設計和物理設計的結果建立資料庫,編寫與調試應用程序,組織數據入庫,並進行測試運行。

6、資料庫運行和維護階段

資料庫應用系統經過試運行後即可投入正式運行,在資料庫系統運行過程中必須不斷對其進行評估、調整與修改。

資料庫設計的基本原則

1、一致性原則:對數據來源進行統一、系統的分析與設計,協調好各種數據源,保證數據的一致性和有效性。

2、完整性原則:資料庫的完整性是指數據的正確性和相容性。要防止合法用戶使用資料庫時向資料庫加入不合語義的數據。對輸入到資料庫中的數據要有審核和約束機制。

3、安全性原則:資料庫的安全性是指保護數據,防止非法用戶使用資料庫或合法用戶非法使用資料庫造成數據泄露、更改或破壞。要有認證和授權機制。

4、可伸縮性與可擴展性原則:資料庫結構的設計應充分考慮發展的需要、移植的需要,具有良好的擴展性、伸縮性和適度冗餘。

5、規范化原則:資料庫的設計應遵循規范化理論。規范化的資料庫設計,可以減少資料庫插入、刪除、修改等操作時的異常和錯誤,降低數據冗餘度等。

『柒』 親愛的,資料庫的表怎麼設計呢

這個軟體不僅是資料庫表的設計問題,還包括你軟體的設計問題,其實資料庫部分並不復雜,復雜的是你的軟體部分。
首先,你的數據採集的來源是什麼?是從另一個庫中獲得,還是記錄在一個臨時表中?
一般應該是這樣:
一個表存儲物流的單號和相關的狀態;
表結構:物流彈(單號,當前狀態,更新時間,其他欄位)
另一個表以日誌的形式記錄每個單號的物流信息操作;
表結構:操作日誌(編號,單號,操作,時間,處理狀態)
最後為每個物流單的處理記錄一個日誌表,用於顯示整個訂單處理流程;
表結構:處理日誌(記錄號,單號,處理狀態,處理時間)

處理過程是先從操作日誌表根據處理狀態讀取未處理的物流單號,然後逐一處理,更新物流單號並記錄處理日誌,處理後修改操作日誌表中的處理狀態

『捌』 怎樣建立資料庫表格

我當年的筆記,都給你吧。

一、 建立資料庫
方法一:使用向導,調出方法⑴可採用「文件」菜單「新建」
⑵或採用「工具」菜單「向導」
方法二:使用資料庫設計器
1、 使用向導建立資料庫
特點:可以方便快捷地創建資料庫,但只適用於一般常用的資料庫。
2、 使用資料庫設計器建立資料庫
特點: 最大特點就是靈活性
操作步驟:⑴「文件」菜單「新建」,顯示新建對話框
⑵選擇「資料庫」和單擊「新建文件」鈕
⑶在創建對話框中輸入新資料庫的名稱和單擊「保存」鈕
效果:資料庫文件已經建立完成。
顯示出「資料庫設計器」窗口和「資料庫設計工具」
打開「資料庫設計器」工具方法:「顯示」菜單「工具欄」
選擇「資料庫設計器」
三、建立表
1、 資料庫與數據表
可以先建立自由表,然後再添加到資料庫中
建立新的資料庫表,系統會將其自動加入到資料庫中。
2、 建立自由表
注意:自由表獨立於任何資料庫,如需要課添加到資料庫中,但不能同時
將一個表添加到多個資料庫。
預備知識:建立表必須首先建立表的結構
即要描述各個欄位的欄位名、欄位類型、欄位寬度、如果是數
值型還有小數位數,以及索引、是否再欄位中允許空值(選擇NULL)

3、 建立資料庫表
有三種方法:
法一、「文件」菜單「新建」,顯示新建對話框
選擇「表」和單擊「新建文件」鈕
在創建對話框中輸入新數表名稱和單擊「保存」鈕
法二、再建立完資料庫後,不關閉「資料庫設計器」窗口,單擊滑鼠右鍵後
選擇快捷菜單種的「新表」,單擊「新表」鈕,再創建對話框輸入表 名
後「保存」
法三、使用資料庫設計器工具欄
(「顯示」菜單「工具欄」)
選擇「資料庫設計器」工具欄種的第一個鈕「新建表」

二、使用命令建立資料庫、資料庫表
1、 建立資料庫
CREATE DATABASE 資料庫名稱
2、 建立資料庫表
CREATE TABLE │DBF 表名 [FREE]
(欄位名1 欄位類型 [(欄位寬度 [,小數位數] )]
[(欄位名2……]

二、使用向導建立查詢
1、查詢形式分類:查詢向導:標准查詢
交叉表向導:以電子表格形式輸出查詢結果
圖形向導:以電子圖形形式輸出查詢結果
2、使用查詢向導建立查詢步驟:
[0]使用查詢向導前必須先打開用到的庫表或自由表
⑴欄位選取
⑵記錄篩選
⑶選擇排序方式
⑷查詢完成(選擇保存並運行)(瀏覽查詢)
⑸打開查詢設計器,修改查詢

『玖』 1,資料庫表結構如何設計,有哪些表,分別有什麼作用

一般可將資料庫結構設計分為四個階段,即需求分析、概念結構設計、邏輯結構設計和物理設計。
數據字典(Data Dictionary DD)用於記載系統定義的或中間生成的各種數據、數據元素,以及常量、變數、數組及其他數據單位,說明它們的名字、性質、意義及各類約束條件,是系統開發與維護中不可缺少的重要文件。數據與數據元素分別用數據表、數據元素表記載。其中,數據號是設計人員給定的順序編號,用於分類清查與整理,並且與數據元素代碼相關聯。數據名是原有表格或憑證的名稱。

『拾』 說明在設計資料庫表時你是如何考慮的

資料庫是整個軟體應用的根基,是軟體設計的起點,它起著決定性的質變作用,因此我們必須對資料庫設計高度重視起來,培養設計良好資料庫的習慣,是一個優秀的軟體設計師所必須具備的基本素質條件! 那麼我們要做到什麼程度才是對的呢?下面就說說資料庫設計的原則: (1)、資料庫設計最起碼要佔用整個項目開發的40%以上的時間

資料庫是需求的直觀反應和表現,因此設計時必須要切實符合用戶的需求,要多次與用戶溝通交流來細化需求,將需求中的要求和每一次的變化都要一一體現在資料庫的設計當中。如果需求不明確,就要分析不確定的因素,設計表時就要事先預留出可變通的欄位,正所謂「有備無患」。 (2)、資料庫設計不僅僅停留於頁面demo的表面 頁面內容所需要的欄位,在資料庫設計中只是一部分,還有系統運轉、模塊交互、中轉數據、表之間的聯系等等所需要的欄位,因此資料庫設計絕對不是簡單的基本數據存儲,還有邏輯數據存儲。 (3)、資料庫設計完成後,項目80%的設計開發在你腦海中就已經完成了 每個欄位的設計都是有他必要的意義的,你在設計每一個欄位的同時,就應該已經想清楚程序中如何去運用這些欄位,多張表的聯系在程序中是如何體現的。換句話說,你完成資料庫設計後,程序中所有的實現思路和實現方式在你的腦海中就已經考慮過了。如果達不到這種程度,那當進入編碼階段後,才發現要運用的技術或實現的方式資料庫無法支持,這時再改動資料庫就會很麻煩,會造成一系列不可預測的問題。 (4)、資料庫設計時就要考慮到效率和優化問題 一開始就要分析哪些表會存儲較多的數據量,對於數據量較大的表的設計往往是粗粒度的,也會冗餘一些必要的欄位,已達到盡量用最少的表、最弱的表關系去存儲海量的數據。並且在設計表時,一般都會對主鍵建立聚集索引,含有大數據量的表更是要建立索引以提供查詢性能。對於含有計算、數據交互、統計這類需求時,還要考慮是否有必要採用存儲過程。 (5)、添加必要的(冗餘)欄位 像「創建時間」、「修改時間」、「備注」、「操作用戶IP」和一些用於其他需求(如統計)的欄位等,在每張表中必須都要有,不是說只有系統中用到的數據才會存到資料庫中,一些冗餘欄位是為了便於日後維護、分析、拓展而添加的,這點是非常重要的,比如黑客攻擊,篡改了數據,我們便就可以根據修改時間和操作用戶IP來查找定位。 (6)、設計合理的表關聯 若多張表之間的關系復雜,建議採用第三張映射表來關聯維護兩張表之間的關系,以降低表之間的直接耦合度。若多張表涉及到大數據量的問題,表結構盡量簡單,關聯也要盡可能避免。 (7)、設計表時不加主外鍵等約束性關聯,系統編碼階段完成後再添加約束性關聯 這樣做的目的是有利於團隊並行開發,減少編碼時所遇到的問題,表之間的關系靠程序來控制。編碼完成後再加關聯並進行測試。不過也有一些公司的做法是乾脆就不加表關聯。 (8)、選擇合適的主鍵生成策略