標籤:機房收費系統 建立資料庫 三範式 e-r圖 sql資料類型
進行過了基礎三層思想的熏陶,馬上就進入了個人機房重構的階段,感覺自己這隻菜鳥中的菜鳥,任重而道遠。要想建造高樓大廈,必須有水泥、磚瓦。資料庫是管理資料資源的容器,下面是我自己建表的過程,如果有不妥的地方,還請大家指正!
一、“三範式”瞭然於胸
好處:關聯式資料庫的規範,為了減少資料冗餘。滿足三範式,說明資料庫比較健全,資料冗餘少,後期維護方便。
詳細內容:
第一範式(1NF):資料庫表中的欄位都是單一屬性,不可再分,確保了每列的原子性。
例如:住址 就要拆成 省份 城市,直到不能拆了為止。
第二範式(2NF):第一範式的升級版~目標是確保表中的每列都和主鍵相關。
例如:比如要設計一個學生考試成績表(表1),聯合主鍵是學號和課程。學號作為主鍵,學分僅僅跟課程相關。這樣就違背了第二範式的設計原則。
所以,遇到這樣的情況,我們就應該把這個表進行拆分,把學生資訊分離到一個表(表2.0),課程資訊分離到另一個表(2.2).
如果不拆分,會出現什麼問題?
資料冗餘:如果1個同學選修n門課程,那麼學生資訊就會被重複n-1次(表3的1區是資料冗餘的地方),n個同學選修1門課程,課程和學分也會被重複n-1次。
更新異常:如果需要更新一門課程的學分,表中所有的學分都要更新,否則會出現同課不同學分的情況。
如果增加課程,暫時沒有學生選修,沒有主鍵:學號,就不能再資料庫中存入課程資訊。
刪除異常:如果一批學生畢業,要刪除成績記錄,課程名稱、學分都會被刪除,難不成還要等開學了,進來一批新的學生再填進去???
第三範式(3NF) :在第二範式的基礎上更進一層。確保每列都和主鍵列直接相關,而不是間接相關。
例如:一個學生資訊的表(表4),存在決定關係:學號——>姓名、年齡、性別,還存在下面的決定關係
學號——>卡號——>餘額、狀態,存著餘額、狀態對學號的傳遞依賴,是間接相關的。違反了第三範式的原則。
因此把它拆分成表5和表6就很完美啦!
當然第三範式也會出現資料冗餘、更新異常、刪除異常,詳情與第二範式的類似。
二、“E-R圖”分析利器
E-R(Enitity Relationship diagram) :提供了表示實體、聯絡、屬性的方法,用來描述宏觀世界的概念性模型。
這是我畫的E-R圖。畫圖的過程是理清思路的過程。當初對充值、退卡等表只是會用,知道確定一個表裡面有卡號、操作者的ID等資訊。當時還覺得ID挺多餘的,不過現在發現它和卡號組成了聯合主鍵,起的作用還不小~
三、”SQL建表“落到實處 個人感覺,這個地方的建表,建表語句並沒有什麼難的地方,重點要注意以下幾點:
1.命名為什麼要規範?沒有規矩不成方圓。命名是專業素質的一種體現,同時規範的命名也便於我們後期的修改、維護。
2.資料類型是char 還是 varchar?char是定長的,當輸入的字元小於指定的數目,char(8),輸入的字元小於8,它會在後面補空值。如果大於8,會截取超出的字元。varchar是長度為n個位元組的可變長度且非Unicode的字元資料。n是介於1-8000之間的數值。相對節省儲存空間。因為char固定長度,所以在處理速度上要比varchar快很多,但是相對比較費儲存空間,所以對儲存不大,但在速度上有要求的可以使用char類型,反之可以用varchar.
其他欄位的資料類型也要選擇合適的,不能全部寫成char類型了。
3.建表完成後不允許修改欄位怎麼辦?在SQL SERVER2008中,建立的表無法修改欄位名和增加欄位名。可以選擇菜單裡面 工具——選項——Designers——資料表設計工具和資料庫設計器,去掉勾即可。
四、總結 每次到最後都要扯上一點點自己的感受,以此記錄我獻身於電腦事業的心路曆程(此處應該有掌聲O(∩_∩)O~)。建表給我最大的感觸是:1.不怕不知道,就怕不知道。三範式,E-R圖開始並沒有好好的鑽研過,只是知道它對建表有很大用處。雖不知,但是用的時候知道,就馬上能學,節省了很多走彎路的時間。2.寫東西是自己的看的,大不了噁心了別人~別人說的再好,自己照別人的操作一遍,也不如自己寫一遍部落格印象深刻。3.時間管理真是救苦救難的活菩薩啊!自從被老師逼著,認真的學了幾天時間管理,發現頭不疼了,眼不花了,幹事有重點了,每天活的都很有成就感,很快樂。還沒幾天,自我感覺就不錯了,堅持下去,小菜鳥有一天一定會成大鳥的,吼吼~