e-r model, more precisely, entity-relationship model， 這個模型從概念上來說有兩個功能，1，將該庫裡面的實體用各種方式分別出來（identify）（這裡的實體據老師來說就是一堆屬性的集合，即通過構成乙個實體的屬性來區別其本身的獨一性），2， 將這些實體以一定的關係來描述。
overview of the design progress:
設計資料庫大體看來的三個方面：
1.資料庫的關係結構設定（data schema）
2.可以訪問和更新的程式
3.乙個安全結構控制訪問的內容。
除此以外，由於資料庫設計的極大的使用者核心性，一些附加的額外要求將極大的影響資料庫的物理層面，邏輯層面和可視層面。
從乙個小資料庫來說的話，設計是乙個很簡單的事情，因為設計者通常都是使用者，但是在真實的世界中，往往使用者和設計者不是同乙個人，所以說設計者需要和使用者交流，然後出乙個在高階層面上對於使用者友善的程式，是的差不多就是win系統那樣的東西，gui介面使得傻瓜式操作變為可能。然後把這些需求在底層實現並優化。
因為使用者和設計者的交流，乙個高層資料模型被生成。這個資料模型對於設計者來說，會提供：
乙個系統概念框架，這個系統框架能系統的描述使用者的需求，以及為了實現需求所需要的資料結構。
（這個時候想想我們對於乙個教務系統的schema的需求和這個schema的實現，就很好理解了）
程式設計的階段：
1.對於潛在使用者需求的分析，在這個階段要和目標領域的專家進行交易 交流，出乙份資料輸入輸出的詳細規程，即甲方要求。
2.選擇資料模型，然後將要求用資料模型實現，我們上文提到的er模型就是乙個很好的模型，一般來說，這個階段的設計應該給出乙個圖形化的資料schema。設計者在這個階段應該檢查schema是否滿足使用者的要求而且要求之間不應該產生衝突。同時應該試著去掉冗餘的冗餘措施。
2.1：乙個概念化的schema還應該包含一些功能性要求（就是一些封裝好的函式？）例如增刪改查恢復什麼的。這一步也應該被檢查。
3.實現。
因為實現物理儲存的改變相對於邏輯層面較為容易，所以在設計邏輯資料庫的時候最好take with care.
設計時要避免的東西：
1.redundancy: 資料冗餘，即是多餘的資料拷貝，比如說我對於一節課程，同時給他標上課程名稱和課程序號這兩個字段，那這就是多餘的，因為乙個課程名稱必然唯一符合與乙個課程序號的。
資料冗餘不僅可能造成多餘的空間浪費，也可能會帶來更新資料的不變，因為如果我要對於乙個資料進行更新的話，如果不遍歷其所有出現的位置，那麼在呼叫的時候就可能會出現錯誤。
總結的來說，乙個實體的資料只應該出現在乙個位置。
2.incompleteness:個人覺得這個翻譯成資料的獨立性比較恰當，就是說如果資料不夠細分的話，會影響以後實體的建立，比如說，假設我們把每一節課都賦予它的課程名和id，而不是單獨儲存的話，那麼我們想新加一門課，但是現在這門課沒有乙個對應的實體（啊這個可以理解，比如說編譯原理這種課程是一直存在著的，但是能教的老師屈指可數而且老師還嫌學生太傻所以不願意教），那麼我們就不可能單單加上這門課的概念而不加上對應的實體，這就給教務處的人造成了麻煩。
壞的設計大概就以上兩種，但是好的設計可能很多，拿乙個顧客買了物品來做個例子，是物品這個實體和顧客產生關係，還是顧客和物品產生的關係，還是這一筆交易使得物品和顧客產生了關係？所以需要資料庫系統需要好好設計。
SQL SERVER學習筆記 1 資料庫概論
第一部分 資料庫概論 單詞記憶 dba 資料庫管理員 dbms 資料庫管理系統 sql 結構化查詢語言 dql 資料查詢語言 dml 資料操作語言 dcl 資料控制語言 ddl 資料定義語言 一 計算機資料庫的優點 1 降低儲存資料的冗餘度，也就是減少重複的資料。2 更高的資料一致性。3 儲存的資料...
資料庫 一 之資料庫概論
資料庫系統 database system,dbs 資料庫系統是由乙個互相關聯的資料集合和一組用以訪問這些資料的應用程式組成 資料庫 database，db 資料庫系統的資料集合 一 資料檢視 給使用者提供資料的抽象檢視，即系統隱藏關於資料儲存和維護的某些細節 資料抽象 a.物理層 最低層次的抽象，...
資料庫系統概論 資料庫設計需求分析
需求分析是設計資料庫的起點 獲取 匯出資訊 處理功能 處理效能 處理方式 處理週期等 使用者可能缺乏計算機知識，設計人員可能缺乏使用者的專業知識，故使用者需要不斷深入地與使用者進行交流 資料字典指的是關於資料庫中資料的描述，是進行詳細的資料收集和分析所獲得的主要結果，稱為元資料，它不是資料本身，而是...