SQL Server之T-SQL學習理論背景

理論背景

SQL 即 Structured Query Language ,它是爲查詢和管理關係型數據庫管理系統(RDBMS)中的數據而專門設計的一種標準語言。RDBMS 是一種基於關係模型的數據庫管理系統,而關係模型則是一種用於表示數據的語義模型。Microsoft 提供的 T-SQL 是標準 SQL 的一種方言(dialect)或擴展,在它的 RDBMS(Microsoft SQL Server)上負責處理數據。程序員

關係模型是獨立於語言的,也就是說,除了 SQL 之外,還能夠用其它語言來實現關係模型,如 C# 中的 類模型。數據庫

SQL

SQL 是基於關係模型的 ANSI 和 ISO 標準語言,專門設計用於查詢和管理 RDBMS 中的數據。編程

早在 20 世紀 70 年代,IBM 就爲其 RDBMS 產品(System R)開發了一種名爲 SEQUEL(Structured English Query Language)的語言。後來由於商標糾紛,就把這種語言的名字從 SEQUEL 修改爲了 SQL。SQL 最初與 1986 年成爲一項 ANSI 標準,以後又於 1987 年成爲了一項 ISO 標準。從 1986 年開始,ANSI 和 ISO 每隔幾年就會發布對 SQL 標準的修訂,到目前爲止,總共發佈過如下一系列標準:SQL-86(1986)、SQL-89(1989)、SQL-92(1992)、SQL:1999(1999)、SQL:2003(2003)、SQL:2006(2006)以及 SQL:2008(2008)。數據庫設計

有趣的是,SQL 與英語有些相像,也很講究邏輯性。與許多其它編程語言不一樣的是,SQL 只需告訴它你想要獲得什麼,而沒必要告訴它如何獲得這些東西。RDBMS 的任務就是計算出如何處理這一請求的物理實現機制。編程語言

SQL 有幾種不一樣類型的語句,包括數據定義語言(DDL,Data Definition Language)、數據處理語言(DML,Data Manipulation Language)以及數據控制語言(DCL,Data Control Language)。函數

DDL 用於處理數據對象的定義,包括的語句有 CREATE、ALTER 以及 DROP。DML 用於查詢和修改數據,包括的語句有SELECT、INSERT、UPDATE、DELETE 以及 MERGE。人們一般誤覺得 DML 只包括數據修改語句,但實際上它其實也包含 SELECT 語句在內。DCL 用於處理權限管理,包括的語句有 GRANT 和 REVOKE。atom

T-SQL 以標準 SQL 做爲基礎,同時也提供了一些非標準的(或專有的)擴展。在後續文章中第一次說起某個語言元素時,一般都會介紹它是不是一個標準元素。spa

DQL(數據查詢語言):在某些地方可能會看到 DQL 這個字眼,實質上它是將 DML 的 SELECT 語句單獨抽離出來做爲 DQL。設計

集合論

集合論的創始人是數據家格奧·康託(Georg Cantor),關係模型就創建在這一數學分支的基礎之上。康託對集合的定義以下:orm

所謂「集合」是把咱們直觀或思惟中肯定的、相互間有明確區別的那些對象 m 視爲一個總體 M,這一總體 M 就稱爲集合(稱 m 爲集合 M 的元素)。

                                      ——Joseph W.Dauben, Georg Cantor(Princeton University Press,1990)

這個定義中的每一個詞都有必定的深度和重要內涵。可是這些晦澀的術語不免讓人感到茫然,咱們再來看看另外一個非正式的定義:所謂集合就是把咱們直觀或思惟肯定的、不一樣的那些對象做爲一個總體來考慮的結果,這些對象就是集合的元素或成員。

咱們先考慮康託的集合定義中的一個詞「總體」。應該將集合視爲一個總體,重點關注的應該是一組對象,而不是組成集合的單獨對象。

「不一樣的」這個詞是指集合中的每個元素必須是惟一的。在一個表中,能夠經過定義鍵(key)約束條件來強制要求表中每行數據的惟一性。沒有鍵,就不能惟一標識一行數據,數據表也就不能知足集合的要求。相反,這樣的數據表將成爲多集(multiset)包(bag)

「咱們直觀或思惟中」表示集合的定義具備必定的主觀性。設想在一個教室中,一我的可能認爲看到的是一羣人,而另外一我的則可能認爲看到的是一羣學生和一羣老師。所以在集合的定義上尚有很大的自由空間。當爲數據庫設計數據模型時,在設計過程當中應該仔細考慮應用程序的主觀須要,以便爲涉及的實體定義合適的集合。

還有一些康託的集合定義中沒有提到的內容一樣很重要。康託的集合定義中沒有說起集合元素之間的順序關係,集合元素的排列順序關係並不重要,用於列舉集合元素的正式表示方法是用一對大括號如 {a,b,c} 來表示。由於元祖之間的順序可有可無,因此 {a,b,c} 和 {a,c,b} 是同一個集合的兩種表現形式。不少程序員短期內都很難接受查詢數據表時,返回的集合元素之間沒有必定順序的事實。換句話說,對數據表的查詢能夠返回按任何順序排列的數據行,除非你明確要求按照必定的表示目的對它們進行排序。

謂詞邏輯(Predicate Logic)

謂詞邏輯的起源最先能夠追溯到古希臘,它也是關係模型基於的另外一個數學分支。Dr.Edgar F.Codd 當初在建立關係模型時,就已經洞悉到了謂詞邏輯與數據的管理和查詢的關聯。不嚴格地說,謂詞就是用來刻畫事務是否具備某種性質或知足某種表達式條件的一個詞項,換句話說,也就是 true 或 false。在關係模型中,謂詞用於維護數據的邏輯完整性和定義它的結構。用謂詞來實施完整性的一個例子,能夠在 Employees 表中定義一個約束(constraint),只有薪資大於 0 的僱員數據才能夠保存到表中。這裏使用的謂詞就是「薪資(salary)大於 0」(T-SQL 表達式就是:salary > 0)。

謂詞也能夠用於對數據進行過濾以定義其子集等多種場合。例如,若是要查詢 Employees 表,並且只要返回來自銷售部門的僱員信息,就能夠在查詢過濾條件中使用謂詞:「部門(department)爲銷售(sales)」(T-SQL 表達式就是:department = 'sales')。

在集合論中,能夠用謂詞來定義集合。這是有用的,由於不可能經過列舉集合的所有元素來定義一個集合(例如無限集合)。有時爲了簡練,以集合元素的某個屬性爲基礎來定義集合則更爲方便。一個用謂詞來定義無限集合的例子,可使用如下謂詞來定義全部質數的集合:「x 是一個大於 1 的正整數,並且只能被 1 和它自己整除」。對於給定的任意一個值,該謂詞要麼爲 true,要麼爲 false。而全部質數的集合就是讓這個謂詞爲 true 的全部元素的集合。做爲一個用謂詞來定義的有限集合的例子,集合 {0,1,2,3,4,5,6,7,8,9} 能夠定義爲讓一下謂詞爲 true 的全部元素的集合:「x 是一個大於或等於 0 且小於或等於 9 的整數」。

關係模型(Relational Model)

關係模型是一個用於表示數據的語義模型,其理論基礎是集合論和謂詞邏輯。前面已經提到,關係模型最初是由 Dr.Edgar F.Codd 建立的,後來 Chris Date、Hugh Darwen 等人對這一模型進行了進一步的解釋和演化。

關係模型的目標是要用最少的或徹底無冗餘的描述來表示一個持久化的完整數據,並且還要將數據完整性(強制的數據一致性)定義爲模型的一部分。RDBMS 則能夠實現這樣的關係模型,並提供存儲、管理、實施強制的數據完整性以及查詢數據的手段。關係模型有着堅實的數學理論基礎這一事實,能夠保證對於給定的某個數據模型實例(之後將據今生成物理的數據庫)可以明確地判斷出其設計是否存在瑕疵,而不是僅靠直覺經驗來得出結論。

命題、謂詞和關係

人們一般認爲「關係(型)(relational)」這一術語源於數據表之間的關係,可是這種觀點是不正確的。「關係(型)」這一術語其實與數學術語「關係(relation)」有關。在集合論中,關係是集合的一種表示。在關係模型中,關係時相關信息的一個集合,在數據庫的實現就是數據表。關係模型的一個關鍵要點就是:一個關係表明一個集合(例如:Customers)。頗有意思的是,對關係進行操做的結果,獲得的仍是一個關係(例如兩個關係之間的聯接(join)運算)。

爲數據庫設計數據模型時,全部數據都是用關係(數據表)來表示的。首先要肯定一個命題(proposition),用於表示數據庫中要保存的信息。命題就是必須爲真(true)或假(false)的一個斷言或語句。例如:「員工 Jack 出生於 1971 年 2 月 12 日,隸屬於 IT 部門」就是一個命題。若是這個命題爲真,就表示它是 Employees 表中的一行;若是這個命題爲假,就表示它不是 Employees 表中的一行。

接下來就對命題進行形式化(formalize)處理,也就是從命題中分析出具體的數據(關係自己),並定義其結構(關係的標題/列名)。例如,根據命題來建立它的謂詞。而關係的標題則組成了屬性(列)的集合(set)。在這裏注意一下「集合」這一術語的使用。在關係模型中,屬性是沒有順序的。屬性(列)是沒有順序的。屬性是由一個屬性名稱和一個域(或類型)名稱來標識的。例如,Employees 關係的標題多是由如下屬性組成的(用屬性名稱和相應的類型名稱對來表示):employeeod 整型、firstname 字符串型、lastname 字符串型、birthday 日期型、departmentid 整型。域或類型是最基礎的關係型構建模塊之一。一個域就是一個屬性可能的(或有效的)一組取值的集合。例如,INT 域的範圍就是在 -2147483648 到 2147483647 之間的全部證書。域是一種數據庫中最簡單形式的謂詞,由於它用於限制屬性容許的值。例如,數據庫不會接受「員工的生日是 1971 年 2 月 31 日」這樣的一個命題(更不用說生日是「abc」這樣的命題了)。注意,域並不僅限於整型或字符串這樣的基本類型,例如,它能夠是可能取值的枚舉類型(enumeration),好比表明可能的工做職位的枚舉值。獲取,域的最佳處理方式就是把它看作一個類——封裝了數據和支持它的行爲。

缺乏的值

關係模型中有一個方面一直引發不少爭議——命題是否應該只限於使用二隻謂詞邏輯。當使用二值謂詞邏輯時,一個命題要麼爲 true,要麼就爲 false;若是一個命題不是真的,那麼它必定是假的。然而,若是考慮到現實中的一些不肯定的狀況,有人會說,還應該存在三值謂詞邏輯(或者甚至是四值)。例如,以 Employees 關係的 cellphone(手機)屬性爲例。假設缺乏某位員工的手機號,這時應該怎麼在數據庫中表示這個事實呢?若是用三值謂詞邏輯來實現這個域,就能夠爲 cellphone 屬性賦予一個表示缺乏值這種狀態的特殊值(如 NULL)。

約束(Constraint)

關係模型最大的優勢就是將數據完整性定義爲模型的一部分。完整性是經過規則(或約束)來實施的,它們在數據模型中定義,並由 RDBMS 實施。實施完整性最簡單的方法就是設置屬性的類型和是否容許控制(便是否支持 NULL),這也就是實施所謂的域完整性(Domain Integrity)。也能夠經過模型自己來實施約束:例如,關係 Orders(orderid,orderdate,duedate,shipdate)容許每一個訂單具備三個不一樣的日期;而關係 Employees(empid)和 EmployeeChildren(empid,childname)則容許每一個員工能夠有零個到可數的無限多個孩子。

約束的其它例子還包括提供實體完整性(entity integrity)的候選鍵,以及提供引用完整性(reference integrity)的外鍵。候選鍵(candidate key)是指在關係中可以防止同一元組(數據行)屢次出現的屬性集(一個或多個屬性)。基於候選鍵的謂詞可以惟一地標識一行數據(例如一個員工)。在關係中能夠定義多個候選鍵,例如,在 Employees 關係中,能夠在 employeeid,ssn(social security number,社會保險號),以及其它屬性上定義的候選鍵。能夠任意選擇一個候選鍵做爲主鍵(primary key),以此做爲標識一行的首選方法,而其它候選鍵則成爲備用關鍵字(alternate key)。

外鍵(foreign key)用於實施引用完整性。外鍵是在關係(稱爲引用關係,referencing relation)中的一個或多個屬性上定義的,經過它來引用另外一個(也多是同一個)關係中的候選鍵。這種約束要求引用關係中外鍵的屬性值要與被引用關係(referenced relation)的候選鍵屬性值相一致。例如,假設 Employees 關係具備一個定義在 departmentid 屬性上的外鍵,引用了 Departments 關係的主鍵屬性 departmentid,那麼,這就意味着 Employees.departmentid 屬性只能取 Departments。departmentid 屬性中出現過的那些值。

規範化(Normalization)

關係模型同時也定義了規範化規則(也成爲範式)。規範化是一種形式化的數學處理過程,以確保每一個實體只由一個關係來表示。在規範化的數據庫中,應該避免對數據的異常修改,並且在不犧牲完整性的前提下,將數據冗餘下降到最小。若是嚴格遵循實體關係建模(ERM,Entity Relationship Modeling)方法來構造關係模型,而且表示出每一個實體及其屬性,可能就無須規範化;不然,應該用規範化原則來增強和保證模型的正確性。

第一範式    第一範式要求表中的行必須是惟一的,屬性應該是原子的(atomic)。這個範式對關係的定義來講是冗餘的,換句話說,若是一個表真能夠表示一個關係,那麼它必定符合第一範式。

第二範式    第二範式包括兩條規則,首先數據必須知足第一範式,其次要求非鍵屬性(nonkey attribute)和候選鍵屬性之間必須知足必定的條件。對於每一個候選鍵,每一個非鍵屬性都必須徹底函數依賴於整個候選鍵。換句話說,一個非鍵屬性不能只徹底函數依賴於候選鍵的一部分。非正式的說,若是不要得到任何非鍵屬性值,就必須提供同一行中某個候選鍵的全部屬性值,若是知道了一個候選鍵的全部屬性值,就可以找到任意行的任意屬性值。

第三範式    第三範式也有兩條規則。首先,數據必須知足第二範式。其次,因此非鍵屬性必須非傳遞依賴於候選鍵。通俗地說,這條規則意味着全部非鍵屬性都必須互相獨立。換句話說,一個非鍵屬性不能依賴於其它非鍵屬性。

函數依賴指的是存在組合候選鍵字中的某些字段決定非關鍵字段的狀況。

相關文章
相關標籤/搜索