曾記得。第一次編寫機房收費系統的文件模板，整整有12個文件須要編寫，只花了兩三天的時間就讓師傅驗收，完結專案。就這樣囫圇吞棗的文件編寫完畢了。
要知道：欠下的賬，終究是要還的。如今到了機房收費系統個人版重構階段，
（1）進行資料抽象，設計區域性概念模型；
（2）將區域性概念模型綜合成全域性概念模型
（3）就能夠按要求繪製機房收費系統資料庫概念設計模型——er關係圖。
能夠說，之前的資料庫的概念設計給我奠定了一丟丟的設計基礎。外加《資料庫系統原理》中的三正規化定理，本著求知好學、虛心請教的理念，於是乎發表這篇部落格，希望大家多多指正。
在資料庫設計中，理清er關係圖是尤為重要的。但往往是。我們根本理不清，有一種剪不斷，理還亂的感覺有木有……有木有。
先睹為快：
1、第一正規化1nf
定義：資料庫表中的字段都是單一屬性的。不可再分。
通俗簡單的說，每個屬性都是原子項，不可切割。
如：位址這個屬性就必須拆分為 省、區、街、鄉、道這幾個單值屬性。
2、第二正規化2nf
定義：假設關係模式r是1nf，且每乙個非主屬性全然函式依賴於候選鍵。
通俗簡單的說，在滿足第一正規化的前提下，當某張表中的非主鍵資訊不是由整個主鍵函式來決定時，即存在依賴於該表中不是主鍵的部分或者依賴於主鍵一部分的部分時，這就不滿足2nf的關係模式
如：原版的機房收費系統學生表，能夠拆成 學生資訊表 和 卡表。這樣就滿足了第二正規化。
3、第三正規化3nf
定義：假設關係模式r是1nf，且每乙個非主屬性都不傳遞依賴於r的候選鍵。
通俗簡單的說，消除沒有直接依賴於第一正規化和第二正規化形成的表的主鍵的屬性。為沒有與表的主鍵關聯的全部資訊建立了一張新錶。
每張新錶儲存了來自原表的資訊和它們所依賴的主鍵。
如：管理員的級別【level】由username稱【userid】決定。而【userid 】由上網的學生的【studentno】和【cardno】來推斷，由此產生了傳遞依賴，第三正規化往往就是消除傳遞的依賴的作用。
實踐是檢驗真理的唯一標準。這話說的真沒錯。自己冥思苦想半天。不如動手一畫來得快，畫著著畫著，之間的關係就越來越明白了。
再次看一下張機房收費系統——er 圖吧（申明：本人的圖必有瑕疵……小的望大爺大神們多多海涵。小的真在努力學習ing）
從我的er圖中能夠清晰的觀察到各個實體間的關係和實體的屬性。以及實體間的聯絡。從而能夠轉換成關係模型。
個別房重建工作才剛剛開始……這是道路的起點似幾乎有點過於強硬
，改革並提出了自己的罪，殘破的牙齒只能夠往肚子裡咽，走一步看一步。你能行的。
房間計費系統改造 三
房間的改造基本完成。在中三比重建，被推翻後。七然後重建 外觀和工廠 再重構，來來回回用了乙個月.重構機房從繪圖畫到一半就廢棄了。由於對三層不熟。之後。做完了，才敢又一次拾起來畫。繪圖先從包圖開始。巨集觀上有個了解 先前畫包圖的時候，跟師傅交流。結果被乙個師姐給笑話了，由於我覺得 它們各個層之間都是雙...
許可權系統 資料庫設計
字段型別 長度釋義 索引約束 menu id int5主鍵 唯一menu code varchar 20選單編碼 唯一 menu name varchar 20選單名稱 menu url varchar 30選單位址 唯一 menu css varchar 30選單圖示 非空 level int1 ...
系統的資料庫設計
一般的系統，如果不涉及複雜的頁面展示或是演算法實現，其實就是簡單的增刪改查，那麼資料庫設計就很基礎和重要了。剛看了一本關於用powerdesigner做資料庫設計的書，簡單分享下大致的步驟。一，資料流圖dfd data flow diagram 資料流圖包含使用者，業務和資料。不同的使用者有不同的業...