數據庫三個範式
Why one grouping of attributes into a relation schema may be better than another
two levels we can discuss the goodness of relation schemas.
logical(conceptual) level - how users interpret the relation schemas and the meaning of their attributes.
implementation (physical storage) level - how the tuples in a base relation are stored and updated.
Top-down design approach and as such is more appropriate when performing design of database by analysis and decomposition of sets of attributes
Relational database design ultimately produces a set of relations. The implicit goals of the design activity are information preservation and minimum redundancy.
Minimizing redundancy = minimize redundant storage of same information + reduce the need for multiple updates to maintain consistency across multiple copies of the same information.
functional dependency: a formal constraint among attributes that is the main tool for formally measuring the appropriateness of attribute groupings into relation schemas.
normalization 與 functional dependency的關系:
the process of normalization using functional dependencies.
1NF: 列的原子性，即列不能夠再分成其他幾列 聯系電話包括: 家庭電話 和 公司電話， 需要拆分為兩列在表裏進行儲存
2NF: 完全依賴主鍵 OrderID 和 ProductID 也就是說, 2NF在1NF的基礎之上，消除了非主屬性對於碼的部分函數依賴。
3NF: 任何非主屬性不依賴於其它非主屬性。第三範式（3NF）是第二範式（2NF）的一個子集，即滿足第三範式（3NF）必須滿足第二範式（2NF）。
Update Anomaly(更新異常): 修改一個列會 影響到其它的列 主要包括 insertion anomalies, deletion anomalies, and modification anomalies
EMP_PROJ(Emp#, Proj#, Ename, Pname, No_hours) Update Anomaly: change the name of project number P1 from "Billing" to "Customer-Accounting" may cause this update to be made for all 100 employees working on project P1
Insert Anomaly(插入異常): Can not insert a project unless an employee is assigned to it. 混在一起, 必須要處理不同的信息
Delete Anomaly(刪除異常): When a project is deleted, it will result in deleting all the employees who work on the project 會有多個行存一條Project信息
改變Entity 的狀態: 不應該受到影響
Modification Anomaly(修改異常):
Guidelines:
非異常的情況: Design a schema that does not suffer from the insertion, deletion and update anomalies
Relations should be designed such that their tuples will have as few NULL values as possible
The relations should be designed to satisfy the losslee join condition:
Candidate Key: 表中的一個屬性或屬性組，若除K之外的所有屬性都完全依賴於K
- 如何判斷一個Relation 是否符合2NF？
- 數據表中所有的candidate key
- 根據candidate key, 找出主屬性
- 找到所有的非主屬性
- 查看是否存在非主屬性對碼的部分函數依賴
完全函數依賴: 在一張表中,如果有X -> Y, 那麽對於X的任何一個真子集, X‘ -> Y都不成立, 則Y對於X完全函數依賴。 也就是說X當中少了任何一個attribute都不能夠唯一確定Y
部分函數依賴: 是完全函數依賴的取反, X當中的部分的屬性就可以確定Y
傳遞函數依賴: Z函數依賴於Y, 且Y函數依賴於X，那麽我們就稱Z傳遞函數依賴於X
NULL值用在什麽地方?
- not applicable or invalid
- Attribute value unknown
- Value known to exist, but unavailable
Closure of Attributes
Given a relation, FD, a set of attributes A, find all B such that A -> B
數據庫三個範式