Ⅰ 如何合理和有效的進行資料庫設計
通常情況下，可以從兩個方面來判斷資料庫設計的是否規范:
1)一是看看是否擁有大量的窄表
窄表往往對於OLTP比較合適，符合範式設計原則
2)寬表的數量是否足夠的少。
所謂的寬表就是欄位比較多的表，包含的維度層次比較多，造成冗餘也比較多，毀範式設計，但是利於取數統計
若符合這兩個條件，我們可以說資料庫設計的比較好.
當然這是兩個泛泛而談的指標。為了達到資料庫設計規范化的要求，一般來說，需要符合以下五個要求。
要求一：表中應該避免可為空的列。
雖然表中允許空列，但是，空欄位是一種比較特殊的數據類型。資料庫在處理的時候，需要進行特殊的處理。如此的話，就會增加資料庫處理記錄的復雜性。當表中有比較多的空欄位時，在同等條件下，資料庫處理的性能會降低許多。
所以，雖然在資料庫表設計的時候，允許表中具有空欄位，但是，我們應該盡量避免。若確實需要的話，我們可以通過一些折中的方式，來處理這些空欄位，讓其對資料庫性能的影響降低到最少。
要求二：表不應該有重復的值或者列。
如現在有一個進銷存管理系統，這個系統中有一張產品基本信息表中。這個產品開發有時候可以是一個人完成，而有時候又需要多個人合作才能夠完成。所以，在產品基本信息表產品開發者這個欄位中，有時候可能需要填入多個開發者的名字。
如進銷存管理中，還需要對客戶的聯系人進行管理。有時候，企業可能只知道客戶一個采購員的姓名。但是在必要的情況下，企業需要對客戶的采購代表、倉庫人員、財務人員共同進行管理。因為在訂單上，可能需要填入采購代表的名字;可是在出貨單上，則需要填入倉庫管理人員的名字等等。
為了解決這個問題，有多種實現方式。但是，若設計不合理的話在，則會導致重復的值或者列。如我們也可以這么設計，把客戶信息、聯系人都放入同一張表中。為了解決多個聯系人的問題，可以設置第一聯系人、第一聯系人電話、第二聯系人、第二聯系人電話等等。若還有第三聯系人、第四聯系人等等，則往往還需要加入更多的欄位。
所以，我們在資料庫設計的時候要盡量避免這種重復的值或者列的產生。筆者建議，若資料庫管理員遇到這種情況，可以改變一下策略。如把客戶聯系人另外設置一張表。然後通過客戶ID把供應商信息表跟客戶聯系人信息表連接起來。也就是說，盡量將重復的值放置到一張獨立的表中進行管理。然後通過視圖或者其他手段把這些獨立的表聯系起來。
要求三：表中記錄應該有一個唯一的標識符。
在資料庫表設計的時候，資料庫管理員應該養成一個好習慣，用一個ID號來唯一的標識行記錄，而不要通過名字、編號等欄位來對紀錄進行區分。每個表都應該有一個ID列，任何兩個記錄都不可以共享同一個ID值。另外，這個ID值最好有資料庫來進行自動管理，而不要把這個任務給前台應用程序。否則的話，很容易產生ID值不統一的情況。
另外，在資料庫設計的時候，最好還能夠加入行號。如在銷售訂單管理中，ID號是用戶不能夠維護的。但是，行號用戶就可以維護。如在銷售訂單的行中，用戶可以通過調整行號的大小來對訂單行進行排序。通常情況下，ID列是以1為單位遞進的。但是，行號就要以10為單位累進。如此，正常情況下，行號就以10、20、30依次擴展下去。若此時用戶需要把行號為30的紀錄調到第一行顯示。此時，用戶在不能夠更改ID列的情況下，可以更改行號來實現。如可以把行號改為1，在排序時就可以按行號來進行排序。如此的話，原來行號為30的紀錄現在行號變為了1，就可以在第一行中顯示。這是在實際應用程序設計中對ID列的一個有效補充。這個內容在教科書上是沒有的。需要在實際應用程序設計中，才會掌握到這個技巧。
要求四：資料庫對象要有統一的前綴名。
一個比較復雜的應用系統，其對應的資料庫表往往以千計。若讓資料庫管理員看到對象名就了解這個資料庫對象所起的作用，恐怕會比較困難。而且在資料庫對象引用的時候，資料庫管理員也會為不能迅速找到所需要的資料庫對象而頭疼。
其次，表、視圖、函數等最好也有統一的前綴。如視圖可以用V為前綴，而函數則可以利用F為前綴。如此資料庫管理員無論是在日常管理還是對象引用的時候，都能夠在最短的時間內找到自己所需要的對象。
要求五：盡量只存儲單一實體類型的數據。
這里將的實體類型跟數據類型不是一回事，要注意區分。這里講的實體類型是指所需要描述對象的本身。筆者舉一個例子，估計大家就可以明白其中的內容了。如現在有一個圖書館里系統，有圖書基本信息、作者信息兩個實體對象。若用戶要把這兩個實體對象信息放在同一張表中也是可以的。如可以把表設計成圖書名字、圖書作者等等。可是如此設計的話，會給後續的維護帶來不少的麻煩。
如當後續有圖書出版時，則需要為每次出版的圖書增加作者信息，這無疑會增加額外的存儲空間，也會增加記錄的長度。而且若作者的情況有所改變，如住址改變了以後，則還需要去更改每本書的記錄。同時，若這個作者的圖書從資料庫中全部刪除之後，這個作者的信息也就盪然無存了。很明顯，這不符合資料庫設計規范化的需求。
遇到這種情況時，筆者建議可以把上面這張表分解成三種獨立的表，分別為圖書基本信息表、作者基本信息表、圖書與作者對應表等等。如此設計以後，以上遇到的所有問題就都引刃而解了。
Ⅱ 《資料庫》設計某企業計劃開發一個進銷存管理信息系統，替換原來的人工系統。
這個工程量大哦·
以上功能速達已經有現成的了，而且非常成熟了……
Ⅲ 商品管理系統資料庫設計
一個完整的銷售管理系統
我給你
Ⅳ 請問怎樣建立公司采購資料庫，資料庫需要那些內容
簡單點可建個Excel文件，如果公司有IT部門可由IT部門自行編個采購的程序或者根據需要買套軟體，資料庫中一般應有購買周期，批量，單價，供方等，我想建立此類資料庫的目的主要是一方面防止出現供貨不足或供貨量大造成庫存大，另一方面實現以較少的價錢買到合適的物料。
Ⅳ 如何建立自己個人的資料庫，我是外貿采購的，需要管理成百上千的供應商數據資料。
我用過浙大恩特的外貿管理軟體，他們的有供應商管理，用的還行工作效率是提高不少，具體是不是符合你的需要，你自己上網搜搜，打電話問問他們吧，每個人的要求是不一的。但願對你有用
Ⅵ 資料庫sql 的課程設計怎麼做，要借哪些書看，求大神指教
IT行業，資料庫確實是一門相當重要的課程。但是在大學裡面，對待資料庫原理及應用這么課程以及其課程設計的重視程度就相差很大了，各個學校要求也不一樣。如果是要學好，那確實要下工夫；如果只是完成課程設計，交差了事，其實相當簡單。
既然是課程設計，也算是個小小的項目，既然是項目，也就離不開需求分析、資料庫設計、部署實現等環節。當然，這個小小的項目只需要前面的部分：需求和資料庫設計，資料庫設計是重點。
需求分析就不用多說，和所有其他項目一樣，無非就是用戶需求，功能需求，系統需求等，找任何一本關於需求分析的書都是可以，除了那些個空話之外，更多的是要根據設計需要進行分析。
資料庫設計就比較復雜一點，首先得把資料庫原理搞清楚，比如：符合什麼樣的範式，怎麼畫ER圖，如何理解用例圖。在設計資料庫之前，有一系列的分析要做：面向對象分析，用例分析，類和對象分析等等。分析到位是資料庫設計成功的重要保障。分析完成之後才是設計，比如：邏輯結構設計，關系模式設計，存取方法設計，存儲結構設計，數據完整性設計，參考完整性設計，Check約束，Default約束，觸發器設計，視圖設計，存儲過程設計，許可權設計等。這些都完成了，最後一步才是寫SQL代碼實現這些設計，創建資料庫及相關的數據表，關聯，視圖，觸發器，存儲過程等一些列的看得見的資料庫參數。
上面說的比較理論，也比較籠統。我想我可以用一個簡單例子告訴你我要表達的意思。例子很簡單，其中很多地方都不是太好，不過或許可以給你一個直觀的思路。
資料庫應用課程設計報告書
網上超市管理系統
成 績：
學 號：
姓 名：
指導教師：
20 年 月 日
目錄
任務書......................................... (3)
1. 需求調查、分析................................. (4)
1.1.企業介紹.................................... (4)
1.2.需求調查及分析.............................. (5)
2. 面向對象分析和設計............................. (7)
2.1. 用例分析 (7)
2.2.類和對象設計 (12)
3. 邏輯結構設計.................................. (15)
3.1. 類和對象向關系模式轉換............................................ (15)
3.2. 關系模式優化 (16)
4. 資料庫物理結構設計............................ (16)
4.1. 存取方法設計 (16)
4.2. 存儲結構設計 (17)
5. 資料庫完整性設計.............................. (17)
5.1. 主鍵及唯一性索引 (17)
5.2. 參照完整性設計 (18)
5.3. Check約束 (18)
5.4. Default約束 (18)
5.5. 觸發器設計 (19)
6. 資料庫視圖設計................................ (19)
7. 資料庫存儲過程設計............................ (20)
8. 許可權設計...................................... (20)
9. 總結.......................................... (21)