canonical

    關系數(shù)據(jù)庫模型在理論上主要解決的是消除數(shù)據(jù)冗余的問題。關系模型的數(shù)學基礎是所謂的集合論，而集合的基本含義正是一組具有某種原子性的互不相同的元素。面向對象技術是對相關性進行局域化的一種手段（相關的數(shù)據(jù)和操作聚集到同一對象名義下），在這一局域化過程中，相同的元素被識別出來，成為獨立的對象。從某種意義上說，關系模型與對象模型是殊途同歸的過程，是從不同側面對同一事物的反映。關系模型中，我們關注的重點是元素組成的集合，允許的連接關系定義在集合之上。而在對象模型中，我們關注的首先是橫向關聯(lián)的實體，實體之間具有穩(wěn)定的聯(lián)系。在概念層面上，從對象模型映射到一種關系存儲模型只是一個分組問題。為了斷開實體之間的直接聯(lián)系，關系模型創(chuàng)造了一個id字段，而對象模型并不是需要顯式id的。在關系模型中，關聯(lián)并不是通過某種存在的結構來表達的（一個實體持有另一個實體的指針，擁有直接聯(lián)系），而是將直接關聯(lián)問題弱化為某種計算過程，我們必須檢查id的值（不是某種直接的存在性），通過某種運算過程才能重新發(fā)現(xiàn)數(shù)據(jù)之間的關聯(lián)。
   
    通過id（伴隨一個匹配計算過程）來進行間接關聯(lián)對于保證模型的一致性是非常關鍵的。在ORM中恢復了對象的強關聯(lián)其實會造成很多潛在的復雜性。例如為了維護對象層面結構的一致性，在更新父子關系的時候，我們需要同時調用 child.setParent(parent); parent.getChildren().remove(child); 當關聯(lián)結構更加復雜的時候，這里所需要的維護工作是隨之增加的。不過，在ORM中，對象的形態(tài)是暫時性的。在ORM的一次session的操作過程中，對于對象狀態(tài)的修改可以是不一致的。例如我們可以只調用child.setParent(parent); 而不需要同時  parent.getChilren().remove(child); 只要我們在此次session操作中，不需要同時用到parent.getChildren(). 這種關聯(lián)的暫時性對于很多ORM應用來說是必不可少的。
   
    對象模型中可以直接表達的結構關系比關系模型要豐富一些，例如繼承關系，many-to-many, one-to-list等。但是所有這些都不是真正本質性的差異。拋棄概念詮釋，基類與眾多派生類之間的關系基本上可以等價于一組one-to-one關系。而當關聯(lián)對象本身的重要性凸現(xiàn)出來的時候，當我們無法把它約化為對象上的一些附屬特性的時候（例如數(shù)組的下標），我們必然要建立相應的關聯(lián)對象，而這正對應于關系模型中的中間關聯(lián)表。中間關聯(lián)表上增加額外的字段是一個自然的擴展過程，而對象模型上做這樣的擴充往往表現(xiàn)為形態(tài)上的重大的不兼容的變化，例如從getManyToManyEntity() -> getToManyRelation(), 這實際上意味著這里的對象形式是偶然的，簡化的。
   
    在原始的關系數(shù)據(jù)庫模型中，所有的表之間的地位是平等的，所有字段之間的地位是平等的（主鍵和外鍵在參與數(shù)據(jù)關聯(lián)時和其他字段的處理方式一致）。這種概念上的均一性和普遍性往往被認為是理論的優(yōu)美之處。但是現(xiàn)實世界是復雜的，發(fā)展的方向就是逐步識別出不同之處，并找出自然的表達形式將這些不同表達出來。均勻的關系模型是對稱性最高的，最簡化的模型。在面對物理約束時，它隱含的假設是集合之間很少發(fā)生相互作用，單表（表單到數(shù)據(jù)表之間的映射）和主從表是最廣泛的情況。試著想象一下關系模型，在思維中一般我們只能看到兩個數(shù)據(jù)表，當考慮到多個表的時候，因為這些表之間沒有明確的可區(qū)分性，因此它們的意象是模糊的。只有明確意識到主鍵，外鍵，主表，從表，字典表，事實表，緯度表這些不同的概念的時候，當對稱性出現(xiàn)破缺的時候，我們思維中的模型才能夠豐富化起來。
   
    關系模型理論應用到數(shù)據(jù)庫具體應用中時，并不需要死守關系范式教條，它們只是描述了某種極端化的對唯一性的追求。面對具體應用的時候，理論本身也在不斷豐富化。我并不把現(xiàn)實應用中必然需要增加冗余字段看作是關系理論失效的結果。從關系完全分解，到關系完全不分解之間，我們可以建立大量的模型。建立冗余字段的時候，我們存在著大量可能的選擇，到底哪一種選擇是最優(yōu)的，理論方面仍然可以給我們以具體的指導。理論在各種不同純化程度的關系模型中都可以給我們以直觀的建議。數(shù)據(jù)倉庫理論中建立的snowflake模式和star模式，強調了針對主題域的允許部分冗余的關系分解。這里實際上是強調了表之間的不同性。不再是所有的表都處于同一地位。Fact Table和Dimension Table之間的區(qū)別被識別出來，并被明確處理。在我看來，這是原始關系模型的一種自然發(fā)展，它也是關系模型理論的一部分。理論不應該是單一的，而是提供一個模型級列，在不同的復雜性層次上，我們可以根據(jù)理論的指導選擇具體的實現(xiàn)模型。
   
    關于ORM http://canonical.javaeye.com/blog/111500
    關系模型中的所謂關系是在使用時刻才定義的，所有建立關系的方式在某種程度上都是等價的，也是外在的。而在ORM中主鍵與外鍵之間的關聯(lián)被獨立出來，成為模型內(nèi)置的部分。這在很多時候簡化了數(shù)據(jù)查詢的結構構造過程。
    在ORM中主鍵因為緩存的存在而顯出與其他字段的區(qū)別。ORM的使用使得數(shù)據(jù)存儲的分解策略得到擴充。并不是所有的表的更新頻度都是一致的，而且表中的數(shù)據(jù)量大小也不同。字典表一般較小，而且很少更新，可以安全的復制。在整個數(shù)據(jù)存儲框架中，ORM作為獨立的技術元素參與數(shù)據(jù)存儲過程，通過主鍵提供緩存服務，產(chǎn)生了新的數(shù)據(jù)分布模型，提供了新的性能優(yōu)化契機。