不管你是
開發簡單的資料庫系統，還是複雜的系統甚至是作資料倉儲，選用或oracle，乃至簡單的用或foxpro，只要是關係型資料庫都難免為了那一張張表頗費心思。起初寫**的時候並不用考慮這些事情，因為前期的設計工作已經有人做了，看起來也就那麼回事，不就是第二正規化或第三正規化嗎。後來才發現，整理出那幾張表確實不容易，弄的不好的話資料結構一變動，所有的**都得變，這恐怕是我們做過資料庫系統的人都經歷過的。經過幾次經驗教訓，摸索出自己的一套發現資料的方法，拿出來和大家切磋切磋。（以圖書館為例，爛的不能再爛的例子了）。
第一步，找物。資料庫管理的就是公司或部門運作需要的資料，和業務相關，必然也和物相關，唯物論嘛。你說人事系統中沒有物，其實人事系統中的檔案就是資料的原始形態，沒有計算機前還不是檔案在起作用，是管理的物件。在圖書管理系統中的物就是圖書了。相應的也就有圖書號、作者、出版社、出版年月、庫存量，庫存位置等資料項了。這些資料往往是資料一致性和完整性考慮的重點所在。
第二步，找人。以人為本嘛，圍繞相應的物必然存在和它們有關係的人。在圖書管理系統中，自然就有圖書管理員和讀者了。資料庫管理系統本身是為了方便人管理資料的，可它往往也喜歡把管理資料的人的情況記錄下來，防止出現職責不明，也是資料管理中的一條主線。習慣把圖書管理員稱為員工，讀者稱為客戶，相應的有id號，姓名，性別，**，住址，身份等等。
第三步，找單據。在具體的業務中往往存在大量的單據，如入庫單，借書單，還書單等等需要和客戶或相應業務部門作信用記錄或記賬用的單據，往往和人和物都有關係，這時你就發現前面已經找好的人和物在這裡就用上了。如果分析作的好的話，這裡需要的資料項前面基本上都有了，只要引用就可以了。因為這些單據是經常使用的，所以主要索引的建立往往也在此就可以確定了。
第四步，找匯報和總結。統計和報表是每個資料庫系統不可缺少的功能，它的**往往是實際業務工作的需要，有的有現成的報表參考還好，沒有的話，你就要想到，不能便於使用人員向上級部門作業績匯報和對下級進行總結的系統，是得不到使用人員尤其的管理人員的認可的，你就等著返工吧。這時候，充分的溝通就會進一步完善前三步設計的資料項。在圖書管理系統中，我們不僅設計了常用的館藏統計、借閱統計、更新統計等和日常業務相關的報表，還作了各類圖書利用率統計、破損（遺失）統計、借閱量統計等等便於決策的報表，這些設計是從管理人員的例行報告中偶爾看到的，極大滿足了系統的實際使用效果，也是很多書上沒有提到過的。
至此，應該是發現了大多數的資料項了。另外的資料項就是常規的業務流程分析了，從物到物或從物到帳，找出新的業務關係資料，這些資料也將是快速模型法變化較多的地方。沒辦法，管理方法的更新必然帶來業務流程的微微變化，但基本上述四項資料是沒有多大變化的。
然後就可以考慮用第z正規化來整理得到的資料物件，確定保障資料完整性、一致性和併發性策略和機制。根據業務流程和具體
開發使用的資料庫系統來設計一套的許可權控制策略，製作精美的人機互動介面。
發現資料庫物件的依賴關係
sql server management studio中有乙個很有意思的工具，可以檢視某個物件的依賴和被依賴關係。如下圖所示 假設，我們自己的程式也要實現這樣的功能，那麼該怎麼做呢？1.首先，建立乙個專案，新增以下三個引用 2.用如下 測試 using system using system.co...
拉伸關鍵維度，發現設計中的不足
應用程的設計輪廓，最初是基於特定的業務需求，所選擇的技術或現在的技術 效能要求 預期的資料量，以及構建 部署和運營上可用的財務資源。無論採用什麼樣的解決方案，都要求能夠滿足或超越當前環境下的要求，成功執行起來，否則這就不稱其為解決方案了。現在來拉伸解決方案中的關鍵維度，看看哪些方面會遭到破壞。使用這...
Mutex物件使用時發現的問題
mutex物件等待互斥物件的方法有 mutex.waitall waitone mutex.waitany 使用mutex物件經常出現的異常現象有 異常一 由於出現被放棄的mutex,等待過程結束 原因 獲取互斥物件後沒有顯式的釋放對應的互斥物件就結束了對應的執行緒 解決辦法 每呼叫乙個等待方法，在...