大資料庫構架

『壹』 大數據系統架構包含內容涉及哪些

【導語】大數據的應用開發過於偏向底層，具有學習難度大，涉及技術面廣的問題，這制約了大數據的普及。大數據架構是大數據技術應用的一個非常常見的形式，那麼大數據系統架構包含內容涉及哪些?下面我們就來具體了解一下。

1、數據源

所有大數據架構都從源代碼開始。這可以包含來源於資料庫的數據、來自實時源(如物聯網設備)的數據，及其從應用程序(如Windows日誌)生成的靜態文件。

2、實時消息接收

假如有實時源，則需要在架構中構建一種機制來攝入數據。

3、數據存儲

公司需要存儲將通過大數據架構處理的數據。一般而言，數據將存儲在數據湖中，這是一個可以輕松擴展的大型非結構化資料庫。

4、批處理和實時處理的組合

公司需要同時處理實時數據和靜態數據，因而應在大數據架構中內置批量和實時處理的組合。這是由於能夠應用批處理有效地處理大批量數據，而實時數據需要立刻處理才能夠帶來價值。批處理涉及到長期運轉的作業，用於篩選、聚合和准備數據開展分析。

5、分析數據存儲

准備好要分析的數據後，需要將它們放到一個位置，便於對整個數據集開展分析。分析數據儲存的必要性在於，公司的全部數據都聚集在一個位置，因而其分析將是全面的，而且針對分析而非事務進行了優化。這可能採用基於雲計算的數據倉庫或關系資料庫的形式，具體取決於公司的需求。

6、分析或報告工具

在攝入和處理各類數據源之後，公司需要包含一個分析數據的工具。一般而言，公司將使用BI(商業智能)工具來完成這項工作，而且或者需要數據科學家來探索數據。

關於大數據系統架構包含內容涉及哪些，就給大家分享到這里了，希望對大家能有所幫助，作為新時代大學生，我們只有不算提升自我技能，充實自我，才是最為正確的選擇。

『貳』 從資料庫最終用戶角度看,資料庫系統的結構分為哪些

由軟體、資料庫和數據管理員組成。其軟體主要包括操作系統、各種宿主語言、實用程序以及資料庫管理系統。資料庫由資料庫管理系統統一管理，數據的插入、修改和檢索均要通過資料庫管理系統進行。數據管理員負責創建、監控和維護整個資料庫，使數據能被任何有權使用的人有效使用。

資料庫管理員一般是由業務水平較高、資歷較深的人員擔任。資料庫系統是為適應數據處理的需要而發展起來的一種較為理想的數據處理的核心機構。計算機的高速處理能力和大容量存儲器提供了實現數據管理自動化的條件。

(2)大資料庫構架擴展閱讀

資料庫研究跨越了計算機應用、系統軟體和理論三個領域，其中應用促進了新系統的發展，新系統帶來了新的理論研究，而理論研究在前兩個領域起著指導作用。資料庫系統的出現是計算機應用的一個里程碑，它使計算機應用有科學計算向數據處理轉變。

因此，計算機可以用於各行各業，甚至在家裡。在此之前，文件系統能夠處理持久數據，但它們不提供對數據任何部分的快速訪問，而這對於數據量不斷增加的應用程序至關重要。

『叄』 資料庫系統由哪幾個部分組成

資料庫系統一般由資料庫、硬體、軟體、人員4個部分組成：

1、資料庫是指長期存儲在計算機內的，有組織，可共享的數據的集合。資料庫中的數據按一定的數學模型組織、描述和存儲，具有較小的冗餘，較高的數據獨立性和易擴展性，並可為各種用戶共享。

2、硬體是構成計算機系統的各種物理設備，包括存儲所需的外部設備。硬體的配置應滿足整個資料庫系統的需要。

3、軟體包括操作系統、資料庫管理系統及應用程序。資料庫管理系統是資料庫系統的核心軟體，是在操作系統的支持下工作，解決如何科學地組織和存儲數據，如何高效獲取和維護數據的系統軟體。

4、人員主要有4類。系統分析員和資料庫設計人員，負責應用系統的需求分析和規范說明；應用程序員，負責編寫使用資料庫的應用程序。

(3)大資料庫構架擴展閱讀

對資料庫系統的基本要求是：

①能夠保證數據的獨立性。數據和程序相互獨立有利於加快軟體開發速度，節省開發費用。

②冗餘數據少，數據共享程度高。

③系統的用戶介面簡單，用戶容易掌握，使用方便。

④能夠確保系統運行可靠，出現故障時能迅速排除；能夠保護數據不受者訪問或破壞；能夠防止錯誤數據的產生，一旦產生也能及時發現。

性能

①能夠保證數據的獨立性。數據和程序相互獨立有利於加快軟體開發速度，節省開發費用。

②冗餘數據少，數據共享程度高。

③系統的用戶介面簡單，用戶容易掌握，使用方便。

④能夠確保系統運行可靠，出現故障時能迅速排除；能夠保護數據不受非受權者訪問或破壞；能夠防止錯誤數據的產生，一旦產生也能及時發現。

⑤有重新組織數據的能力，能改變數據的存儲結構或數據存儲位置，以適應用戶操作特性的變化，改善由於頻繁插入、刪除操作造成的數據組織零亂和時空性能變壞的狀況。

『肆』 資料庫架構是什麼

問題一：sql server中的架構是什麼意思? 通俗點說就是一個組，裡面可以存放表、視圖、存儲過程等
主要是用於許可權控制安全控制的

問題二：什麼是架構，SQL中的架構有哪些 架構(Schema)是形成單個命名空間的資料庫實體的 *** 。
命名空間是一個 *** ，其中每個元素的名稱都是唯一的。
可以將架構看成一個存放資料庫中對象的一個容器。
架構實際上在sqlserver2000中就已經存在，當我們使用查詢分析器去查詢一個表的時候，一個完整的表的名稱應該包括伺服器名.資料庫名.用戶名.對象名，而在sqlserver2005中一個表的完全限定名稱應該為伺服器名.資料庫名.架構名.對象名
在2000中，假如有一個賬戶tt在test資料庫中創建了一張表table1的時候，在伺服器上對查詢的語句應為select * from test.tt.table1,也就是說，在sqlserver 2000中一張表所屬的架構默認就是表的創建者的登錄名稱，用戶可以和修改他所創建的所有資料庫對象。

問題三：資料庫架構是什麼 參考有一個聲音再也不能的在耳邊響起，有一雙手再也握不住那手心的溫度與舒適。

問題四：數據架構是什麼 數據架構即資料庫架構

資料庫是相關數據的 *** ，一個資料庫含有各種成分，包括表、記錄、欄位、索引等。
1．資料庫(Database)
Visual Basic中使用的資料庫是關系型資料庫(Relational Database)。一個資料庫由一個或一組數據表組成。每個資料庫都以文件的形式存放在磁碟上，即對應於一個物理文件。不同的資料庫，與物理文件對應的方式也不一樣。對於dBASE,FoxPro和Paradox格式的資料庫來說，一個數據表就是一個單獨的資料庫文件，而對於Microsoft Access、Btrieve格式的資料庫來說，一個資料庫文件可以含有多個數據表。
2．數據表(Table)
簡稱表，由一組數據記錄組成，資料庫中的數據是以表為單位進行組織的。一個表是一組相關的按行排列的數據；每個表中都含有相同類型的信息。表實際上是一個二維表格，例如，一個班所有學生的考試成績，可以存放在一個表中，表中的每一行對應一個學生，這一行包括學生的學號，姓名及各門課程成績。
3．記錄(Record)
表中的每一行稱為一個記消蘆錄，它由若干個欄位組成。
4．欄位(Field)
也稱域。表中的每一列稱為一個欄位。每個欄位都有相應的描述信息，如數據類型、數據寬度等。
5．索引(Index)
為了提高訪問資料庫的效率，可以對資料庫使用索引。當資料庫較大時，為了查找指定的記錄，則使用索引和不使用索引的效困鬥率有很大差別。索引實際上是一種特殊類型的表，其中含有關鍵欄位的值(由用戶定義)和指向實際記錄位置的指針，這些值和指針按照特定的順序(也由用戶定義)存儲，從而可以以較快的速度查找到所需要的數據記錄。
6．查詢(Query)
一條SQL(結構化查詢語言)命令，用來從一個或多個表中獲取一組指定的記錄，或者對某個表執行指定的操作。當從資料庫中讀取數據時，往往希望讀出的數據符合某些條件，並且能按某個欄位排序。使用SQL，可以使這一操作容易實現而且更加有效。SQL是非過程化語言(有人稱為第四代語言)，在用它查找指定的記錄時，只需指出做什麼，不必說明汪橋磨如何做。每個語句可以看作是一個查詢(query)，根據這個查詢，可以得到需要的查詢結果。
7．過濾器(Filter)
過濾器是資料庫的一個組成部分，它把索引和排序結合起來，用來設置條件，然後根據給定的條件輸出所需要的數據。
8.視圖(view)
數據的視圖指的是查找到(或者處理)的記錄數和顯示(或者進行處理)這些記錄的順序。在一般情況下，視圖由過濾器和索引控制

問題五：資料庫中的文件組和架構有什麼不同？兩者之間的關系是什麼？ 文件組 是 管理 物理文件的. 多個物理文件, 放在一個組裡面
架構 不知道你指的是不是 Schema.
如果是的話。

架構 是 邏輯上面的, 一個資料庫， 可以劃分為多個 架構， 每個 架構 存儲其獨有的業務數據。
SQL Server 默認使用一個 名為 dbo 的 構架。

問題六：資料庫-架構和資料庫-管理指的是什麼 資料庫架構：
下面是基於SQLserver資料庫來談的。貳
SQLServer經過這些年的發展，其實已經有很多很好的技術可以使用，如Replication、SSB、Cluster、Mirroring等（可以參考我在SQLServer DBA 三十問和SQLServer 高可用、高性能和高保護延伸 中的一些技術方面的知識），而且這些技術在可靠性方面已經通過了市場的認可，有很多公司在為提高其程序的可靠性、安全性和高效性等方面或多或少的採用了其中的某些技術，以下就我接觸過的這些技術方面的應用，主要針對網站這種流量很大，讀多寫少的應用，就資料庫架構方面做些探討，希望對各位有所幫助，如有不對的地方，歡迎大家指正和交流。

資料庫架構需要考慮的問題：
數據可靠和一致性；
數據容災；
當數據量和訪問壓力變大時，方便擴充；
高度可用，出問題時能及時恢復，無單點故障；
不應因為某一台機器出現問題，導致整網性能的急劇下降；
方便維護。
資料庫管理：
資料庫管理(Database Manager)是有關建立、存儲、修改和存取資料庫中信息的技術，是指為保證資料庫系統的正常運行和服務質量，有關人員須進行的技術管理工作。負責這些技術管理工作的個人或集體稱為資料庫管理員(DBA)。資料庫管理的主要內容有：資料庫的調優、資料庫的重組、資料庫的重構、資料庫的安全管控、報錯問題的分析和匯總和處理、資料庫數據的日常備份. 資料庫的建立：資料庫的設計只是提供了數據的類型、邏輯結構、聯系、約束和存儲結構等有關數據的描述。這些描述稱為數據模式。

問題七：oracle資料庫的結構是什麼？ Oracle資料庫的體系結構包括四個方面：資料庫的物理結構、邏輯結構、內存結構及進程。

1. 物理結構

物理資料庫結構是由構成資料庫的操作系統文件所決定，Oracle資料庫文件包括：

數據文件（Data File）
數據文件用來存儲資料庫中的全部數據，例如資料庫表中的數據和索引數據.通常以為*.dbf格式，例如:userCIMS.dbf 。

日誌文件（Redo Log File）
日誌文件用於記錄資料庫所做的全部變更（如增加、刪除、修改）、以便在系統發生故障時，用它對資料庫進行恢復。名字通常為Log*.dbf格式，如：Log1CIMS.dbf,Log2CIMS.dbf 。

控制文件（Control File）
每個Oracle資料庫都有相應的控制文件，它們是較小的二進制文件，用於記錄資料庫的物理結構，如：資料庫名、資料庫的數據文件和日誌文件的名字和位置等信息。用於打開、存取資料庫。名字通常為Ctrl*ctl 格式，如Ctrl1CIMS.ctl。

配置文件
配置文件記錄Oracle資料庫運行時的一些重要參數，如：數據塊的大小，內存結構的配置等。名字通常為init*.ora 格式，如：initCIMS.ora 。

2 邏輯結構

Oracle資料庫的邏輯結構描述了資料庫從邏輯上如何來存儲資料庫中的數據。邏輯結構包括表空間、段、區、數據塊和模式對象。資料庫的邏輯結構將支配一個資料庫如何使用系統的物理空間.模式對象及其之間的聯系則描述了關系資料庫之間的設計.

一個資料庫從邏輯上說是由一個或多個表空間所組成，表空間是資料庫中物理編組的數據倉庫，每一個表空間是由段(segment)組成，一個段是由一組區(extent)所組成，一個區是由一組連續的資料庫塊(database block)組成，而一個資料庫塊對應硬碟上的一個或多個物理塊。一個表空間存放一個或多個資料庫的物理文件（即數據文件）.一個資料庫中的數據被邏輯地存儲在表空間上。

表空間（tablespace）
Oracle資料庫被劃分為一個或多個稱為表空間的邏輯結構，它包括兩類表空間，System表空間和非System表空間，其中，System表空間是安裝資料庫時自動建立的，它包含資料庫的全部數據字典，存儲過程、包、函數和觸發器的定義以及系統回滾段。除此之外，還能包含用戶數據。。

一個表空間包含許多段，每個段有一些可以不連續的區組成，每個區由一組連續的數據塊組成，數據塊是資料庫進行操作的最小單位。

每個表空間對應一個或多個數據文件，每個數據文件只能屬於一個表空間。

資料庫塊（database block）
資料庫塊也稱邏輯塊或ORACLE塊，它對應磁碟上一個或多個物理塊，它的大小由初始化參數db-block-size（在文件init.ora中）決定，典型的大小是2k。Pckfree 和pctused 兩個參數用來優化數據塊空間的使用。

區（extent）
區是由一組連續的數據塊所組成的資料庫存儲空間分配的邏輯單位。

段（segment）
段是一個或多個不連續的區的 *** ，它包括一個表空間內特定邏輯結構的所有數據，段不能跨表空間存放。Oracle資料庫包括數據段、索引段、臨時段、回滾段等。

模式對象（schema object）
Oracle資料庫的模式對象包括表、視圖、序列、同意詞、索引、觸發器、存......>>

問題八：sql server中架構是什麼意思 架構（Schema）是一組資料庫對象的 *** ，它被單個負責人（可以是用戶或角色）所擁有並構成唯一命名空間。你可以將架構看成是對象的容器。
在 SQL Server 2000 中，用戶（User）和架構是隱含關聯的，即每個用戶擁有與其同名的架構。因此要刪除一個用戶，必須先刪除或修改這個用戶所擁有的所有資料庫對象。
在 SQL Server 2005 中，架構和創建它的資料庫用戶不再關聯，完全限定名（fully-qualified name）現在包含4個部分：server.database.schema.object
1. 體系結構（Architecture）
體系結構亦可稱為架構，所謂軟體架構，根據Perry 和Wolfe之定義：Software Architecture = {Elements,Forms, Rationale / Constraint }，也就是軟體主架構 = {組件元素，元素互助合作之模式，基礎要求與限制}。Philippe Kruchten採用上面的定義，並說明主架構之設計就是：將各組件元素以某些理想的合作模式組織起來，以達成系統的基本功能和限制。體系結構又分為多種樣式，如Pipes and Filters等。
2. 框架(Framework)
框架亦可稱為應用架構，框架的一般定義就是：在特定領域基於體系結構的可重用的設計。也可以認為框架是體系結構在特定領域下的應用。框架比較出名的例子就是MVC。
3. 庫(Library)
庫應該是可重用的、相互協作的資源的 *** ，供開發人員進行重復調用。它與框架的主要區別在於運行時與程序的調用關系。庫是被程序調用，而框架則調用程序。比較好的庫有JDK。
4. 設計模式（Design Pattern）
設計模式大家應該很熟悉，尤其四人幫所寫的書更是家喻戶曉。「四人幫」將模式描述為「在一定的環境中解決某一問題的方案」。這三個事物 ― 問題、解決方案和環境 ― 是模式的基本要素。給模式一個名稱，考慮使用模式將產生的結果和提供一個或多個示例，對於說明模式也都是有用的。
5. 平台（PlatForm）
由多種系統構成，其中也可以包含硬體部分。
對於以上的概念有一個比較清楚的認識之後，就可以在軟體的開發過程中進行應用。理論和實踐是缺一不可的，相輔相成的。沒有理論的指導，實踐就缺乏基礎；沒有實踐的證明，理論就缺乏依據，因此我一直認為：對於當代的程序員，在有一定的實踐基礎後，必須學習更深的理論知識。無論你是從那方面先開始學習的。
在軟體的開發過浮中，從許多過程實踐和方法中，大致可以提煉出五大步驟：需求、分析、設計、編碼、測試。而體系結構是軟體的骨架，是最重要的基礎。體系結構是涉及到每一步驟中。一般在獲取需要的同時，就應該開始分析軟體的體系結構。體系結構現在一般是各個大的功能模塊組合成，然後描述各個部分的關系。
我一般認為框架是體系結構中每個模塊中更細小的結構。如需要表示web技術，就會用到MVC框架，而web功能只是整個軟體體系中的一個功能模塊。每個框架可以有許多個實例，如用java實現的MVC框架structs。
而在框架之下就是設計模式，設計模式一般是應用中框架之中的，也可以說是對框架的補充。因為框架只是提供了一個環境，需要我們我裡面填入更多的東西。無論是否應用了設計模式，你都可以實現軟體的功能，而正確應用了設計模式，是我們對前人軟體的設計或實現方法的一種繼承，從而讓你的軟體更軟。
體系結構是可以從不同視角來進......>>

問題九：oracle資料庫的架構是什麼？ oracle 資料庫架構本質上是C/S結構的。 伺服器與客戶端是分開的，即時伺服器和客戶端是在同一機器上，他們也是按照客戶端/伺服器模式運行的，他們之間的進程是分開的。 希望能幫助你。

問題十：資料庫中擁有的架構與成員身份有什麼區別？ 不同許可權組合或單獨就構成常角色。
不同用戶創建的資料庫對象不可能放在放在一起，因此就出現了容器就是所謂的架構，架構就是單個命名空間的數據實體的 ***

『伍』 五種大數據處理架構

五種大數據處理架構
大數據是收集、整理、處理大容量數據集，並從中獲得見解所需的非傳統戰略和技術的總稱。雖然處理數據所需的計算能力或存儲容量早已超過一台計算機的上限，但這種計算類型的普遍性、規模，以及價值在最近幾年才經歷了大規模擴展。
本文將介紹大數據系統一個最基本的組件：處理框架。處理框架負責對系統中的數據進行計算，例如處理從非易失存儲中讀取的數據，或處理剛剛攝入到系統中的數據。數據的計算則是指從大量單一數據點中提取信息和見解的過程。
下文將介紹這些框架：
· 僅批處理框架：
Apache Hadoop
· 僅流處理框架：
Apache Storm
Apache Samza
· 混合框架：
Apache Spark
Apache Flink
大數據處理框架是什麼？
處理框架和處理引擎負責對數據系統中的數據進行計算。雖然「引擎」和「框架」之間的區別沒有什麼權威的定義，但大部分時候可以將前者定義為實際負責處理數據操作的組件，後者則可定義為承擔類似作用的一系列組件。
例如Apache Hadoop可以看作一種以MapRece作為默認處理引擎的處理框架。引擎和框架通常可以相互替換或同時使用。例如另一個框架Apache Spark可以納入Hadoop並取代MapRece。組件之間的這種互操作性是大數據系統靈活性如此之高的原因之一。
雖然負責處理生命周期內這一階段數據的系統通常都很復雜，但從廣義層面來看它們的目標是非常一致的：通過對數據執行操作提高理解能力，揭示出數據蘊含的模式，並針對復雜互動獲得見解。
為了簡化這些組件的討論，我們會通過不同處理框架的設計意圖，按照所處理的數據狀態對其進行分類。一些系統可以用批處理方式處理數據，一些系統可以用流方式處理連續不斷流入系統的數據。此外還有一些系統可以同時處理這兩類數據。
在深入介紹不同實現的指標和結論之前，首先需要對不同處理類型的概念進行一個簡單的介紹。
批處理系統
批處理在大數據世界有著悠久的歷史。批處理主要操作大容量靜態數據集，並在計算過程完成後返回結果。
批處理模式中使用的數據集通常符合下列特徵…
· 有界：批處理數據集代表數據的有限集合
· 持久：數據通常始終存儲在某種類型的持久存儲位置中
· 大量：批處理操作通常是處理極為海量數據集的唯一方法
批處理非常適合需要訪問全套記錄才能完成的計算工作。例如在計算總數和平均數時，必須將數據集作為一個整體加以處理，而不能將其視作多條記錄的集合。這些操作要求在計算進行過程中數據維持自己的狀態。
需要處理大量數據的任務通常最適合用批處理操作進行處理。無論直接從持久存儲設備處理數據集，或首先將數據集載入內存，批處理系統在設計過程中就充分考慮了數據的量，可提供充足的處理資源。由於批處理在應對大量持久數據方面的表現極為出色，因此經常被用於對歷史數據進行分析。
大量數據的處理需要付出大量時間，因此批處理不適合對處理時間要求較高的場合。
Apache Hadoop
Apache Hadoop是一種專用於批處理的處理框架。Hadoop是首個在開源社區獲得極大關注的大數據框架。基於谷歌有關海量數據處理所發表的多篇論文與經驗的Hadoop重新實現了相關演算法和組件堆棧，讓大規模批處理技術變得更易用。
新版Hadoop包含多個組件，即多個層，通過配合使用可處理批數據：
· HDFS：HDFS是一種分布式文件系統層，可對集群節點間的存儲和復制進行協調。HDFS確保了無法避免的節點故障發生後數據依然可用，可將其用作數據來源，可用於存儲中間態的處理結果，並可存儲計算的最終結果。
· YARN：YARN是Yet Another Resource Negotiator（另一個資源管理器）的縮寫，可充當Hadoop堆棧的集群協調組件。該組件負責協調並管理底層資源和調度作業的運行。通過充當集群資源的介面，YARN使得用戶能在Hadoop集群中使用比以往的迭代方式運行更多類型的工作負載。
· MapRece：MapRece是Hadoop的原生批處理引擎。
批處理模式
Hadoop的處理功能來自MapRece引擎。MapRece的處理技術符合使用鍵值對的map、shuffle、rece演算法要求。基本處理過程包括：
· 從HDFS文件系統讀取數據集
· 將數據集拆分成小塊並分配給所有可用節點
· 針對每個節點上的數據子集進行計算（計算的中間態結果會重新寫入HDFS）
· 重新分配中間態結果並按照鍵進行分組
· 通過對每個節點計算的結果進行匯總和組合對每個鍵的值進行「Recing」
· 將計算而來的最終結果重新寫入 HDFS
優勢和局限
由於這種方法嚴重依賴持久存儲，每個任務需要多次執行讀取和寫入操作，因此速度相對較慢。但另一方面由於磁碟空間通常是伺服器上最豐富的資源，這意味著MapRece可以處理非常海量的數據集。同時也意味著相比其他類似技術，Hadoop的MapRece通常可以在廉價硬體上運行，因為該技術並不需要將一切都存儲在內存中。MapRece具備極高的縮放潛力，生產環境中曾經出現過包含數萬個節點的應用。
MapRece的學習曲線較為陡峭，雖然Hadoop生態系統的其他周邊技術可以大幅降低這一問題的影響，但通過Hadoop集群快速實現某些應用時依然需要注意這個問題。
圍繞Hadoop已經形成了遼闊的生態系統，Hadoop集群本身也經常被用作其他軟體的組成部件。很多其他處理框架和引擎通過與Hadoop集成也可以使用HDFS和YARN資源管理器。
總結
Apache Hadoop及其MapRece處理引擎提供了一套久經考驗的批處理模型，最適合處理對時間要求不高的非常大規模數據集。通過非常低成本的組件即可搭建完整功能的Hadoop集群，使得這一廉價且高效的處理技術可以靈活應用在很多案例中。與其他框架和引擎的兼容與集成能力使得Hadoop可以成為使用不同技術的多種工作負載處理平台的底層基礎。
流處理系統
流處理系統會對隨時進入系統的數據進行計算。相比批處理模式，這是一種截然不同的處理方式。流處理方式無需針對整個數據集執行操作，而是對通過系統傳輸的每個數據項執行操作。
· 流處理中的數據集是「無邊界」的，這就產生了幾個重要的影響：
· 完整數據集只能代表截至目前已經進入到系統中的數據總量。
· 工作數據集也許更相關，在特定時間只能代表某個單一數據項。
處理工作是基於事件的，除非明確停止否則沒有「盡頭」。處理結果立刻可用，並會隨著新數據的抵達繼續更新。
流處理系統可以處理幾乎無限量的數據，但同一時間只能處理一條（真正的流處理）或很少量（微批處理，Micro-batch Processing）數據，不同記錄間只維持最少量的狀態。雖然大部分系統提供了用於維持某些狀態的方法，但流處理主要針對副作用更少，更加功能性的處理（Functional processing）進行優化。
功能性操作主要側重於狀態或副作用有限的離散步驟。針對同一個數據執行同一個操作會或略其他因素產生相同的結果，此類處理非常適合流處理，因為不同項的狀態通常是某些困難、限制，以及某些情況下不需要的結果的結合體。因此雖然某些類型的狀態管理通常是可行的，但這些框架通常在不具備狀態管理機制時更簡單也更高效。
此類處理非常適合某些類型的工作負載。有近實時處理需求的任務很適合使用流處理模式。分析、伺服器或應用程序錯誤日誌，以及其他基於時間的衡量指標是最適合的類型，因為對這些領域的數據變化做出響應對於業務職能來說是極為關鍵的。流處理很適合用來處理必須對變動或峰值做出響應，並且關注一段時間內變化趨勢的數據。
Apache Storm
Apache Storm是一種側重於極低延遲的流處理框架，也許是要求近實時處理的工作負載的最佳選擇。該技術可處理非常大量的數據，通過比其他解決方案更低的延遲提供結果。
流處理模式
Storm的流處理可對框架中名為Topology（拓撲）的DAG（Directed Acyclic Graph，有向無環圖）進行編排。這些拓撲描述了當數據片段進入系統後，需要對每個傳入的片段執行的不同轉換或步驟。
拓撲包含：
· Stream：普通的數據流，這是一種會持續抵達系統的無邊界數據。
· Spout：位於拓撲邊緣的數據流來源，例如可以是API或查詢等，從這里可以產生待處理的數據。
· Bolt：Bolt代表需要消耗流數據，對其應用操作，並將結果以流的形式進行輸出的處理步驟。Bolt需要與每個Spout建立連接，隨後相互連接以組成所有必要的處理。在拓撲的尾部，可以使用最終的Bolt輸出作為相互連接的其他系統的輸入。
Storm背後的想法是使用上述組件定義大量小型的離散操作，隨後將多個組件組成所需拓撲。默認情況下Storm提供了「至少一次」的處理保證，這意味著可以確保每條消息至少可以被處理一次，但某些情況下如果遇到失敗可能會處理多次。Storm無法確保可以按照特定順序處理消息。
為了實現嚴格的一次處理，即有狀態處理，可以使用一種名為Trident的抽象。嚴格來說不使用Trident的Storm通常可稱之為Core Storm。Trident會對Storm的處理能力產生極大影響，會增加延遲，為處理提供狀態，使用微批模式代替逐項處理的純粹流處理模式。
為避免這些問題，通常建議Storm用戶盡可能使用Core Storm。然而也要注意，Trident對內容嚴格的一次處理保證在某些情況下也比較有用，例如系統無法智能地處理重復消息時。如果需要在項之間維持狀態，例如想要計算一個小時內有多少用戶點擊了某個鏈接，此時Trident將是你唯一的選擇。盡管不能充分發揮框架與生俱來的優勢，但Trident提高了Storm的靈活性。
Trident拓撲包含：
· 流批（Stream batch）：這是指流數據的微批，可通過分塊提供批處理語義。
· 操作（Operation）：是指可以對數據執行的批處理過程。
優勢和局限
目前來說Storm可能是近實時處理領域的最佳解決方案。該技術可以用極低延遲處理數據，可用於希望獲得最低延遲的工作負載。如果處理速度直接影響用戶體驗，例如需要將處理結果直接提供給訪客打開的網站頁面，此時Storm將會是一個很好的選擇。
Storm與Trident配合使得用戶可以用微批代替純粹的流處理。雖然藉此用戶可以獲得更大靈活性打造更符合要求的工具，但同時這種做法會削弱該技術相比其他解決方案最大的優勢。話雖如此，但多一種流處理方式總是好的。
Core Storm無法保證消息的處理順序。Core Storm為消息提供了「至少一次」的處理保證，這意味著可以保證每條消息都能被處理，但也可能發生重復。Trident提供了嚴格的一次處理保證，可以在不同批之間提供順序處理，但無法在一個批內部實現順序處理。
在互操作性方面，Storm可與Hadoop的YARN資源管理器進行集成，因此可以很方便地融入現有Hadoop部署。除了支持大部分處理框架，Storm還可支持多種語言，為用戶的拓撲定義提供了更多選擇。
總結
對於延遲需求很高的純粹的流處理工作負載，Storm可能是最適合的技術。該技術可以保證每條消息都被處理，可配合多種編程語言使用。由於Storm無法進行批處理，如果需要這些能力可能還需要使用其他軟體。如果對嚴格的一次處理保證有比較高的要求，此時可考慮使用Trident。不過這種情況下其他流處理框架也許更適合。
Apache Samza
Apache Samza是一種與Apache Kafka消息系統緊密綁定的流處理框架。雖然Kafka可用於很多流處理系統，但按照設計，Samza可以更好地發揮Kafka獨特的架構優勢和保障。該技術可通過Kafka提供容錯、緩沖，以及狀態存儲。
Samza可使用YARN作為資源管理器。這意味著默認情況下需要具備Hadoop集群（至少具備HDFS和YARN），但同時也意味著Samza可以直接使用YARN豐富的內建功能。
流處理模式
Samza依賴Kafka的語義定義流的處理方式。Kafka在處理數據時涉及下列概念：
· Topic（話題）：進入Kafka系統的每個數據流可稱之為一個話題。話題基本上是一種可供消耗方訂閱的，由相關信息組成的數據流。
· Partition（分區）：為了將一個話題分散至多個節點，Kafka會將傳入的消息劃分為多個分區。分區的劃分將基於鍵（Key）進行，這樣可以保證包含同一個鍵的每條消息可以劃分至同一個分區。分區的順序可獲得保證。
· Broker（代理）：組成Kafka集群的每個節點也叫做代理。
· Procer（生成方）：任何向Kafka話題寫入數據的組件可以叫做生成方。生成方可提供將話題劃分為分區所需的鍵。
· Consumer（消耗方）：任何從Kafka讀取話題的組件可叫做消耗方。消耗方需要負責維持有關自己分支的信息，這樣即可在失敗後知道哪些記錄已經被處理過了。
由於Kafka相當於永恆不變的日誌，Samza也需要處理永恆不變的數據流。這意味著任何轉換創建的新數據流都可被其他組件所使用，而不會對最初的數據流產生影響。
優勢和局限
乍看之下，Samza對Kafka類查詢系統的依賴似乎是一種限制，然而這也可以為系統提供一些獨特的保證和功能，這些內容也是其他流處理系統不具備的。
例如Kafka已經提供了可以通過低延遲方式訪問的數據存儲副本，此外還可以為每個數據分區提供非常易用且低成本的多訂閱者模型。所有輸出內容，包括中間態的結果都可寫入到Kafka，並可被下游步驟獨立使用。
這種對Kafka的緊密依賴在很多方面類似於MapRece引擎對HDFS的依賴。雖然在批處理的每個計算之間對HDFS的依賴導致了一些嚴重的性能問題，但也避免了流處理遇到的很多其他問題。
Samza與Kafka之間緊密的關系使得處理步驟本身可以非常鬆散地耦合在一起。無需事先協調，即可在輸出的任何步驟中增加任意數量的訂閱者，對於有多個團隊需要訪問類似數據的組織，這一特性非常有用。多個團隊可以全部訂閱進入系統的數據話題，或任意訂閱其他團隊對數據進行過某些處理後創建的話題。這一切並不會對資料庫等負載密集型基礎架構造成額外的壓力。
直接寫入Kafka還可避免回壓（Backpressure）問題。回壓是指當負載峰值導致數據流入速度超過組件實時處理能力的情況，這種情況可能導致處理工作停頓並可能丟失數據。按照設計，Kafka可以將數據保存很長時間，這意味著組件可以在方便的時候繼續進行處理，並可直接重啟動而無需擔心造成任何後果。
Samza可以使用以本地鍵值存儲方式實現的容錯檢查點系統存儲數據。這樣Samza即可獲得「至少一次」的交付保障，但面對由於數據可能多次交付造成的失敗，該技術無法對匯總後狀態（例如計數）提供精確恢復。
Samza提供的高級抽象使其在很多方面比Storm等系統提供的基元（Primitive）更易於配合使用。目前Samza只支持JVM語言，這意味著它在語言支持方面不如Storm靈活。
總結
對於已經具備或易於實現Hadoop和Kafka的環境，Apache Samza是流處理工作負載一個很好的選擇。Samza本身很適合有多個團隊需要使用（但相互之間並不一定緊密協調）不同處理階段的多個數據流的組織。Samza可大幅簡化很多流處理工作，可實現低延遲的性能。如果部署需求與當前系統不兼容，也許並不適合使用，但如果需要極低延遲的處理，或對嚴格的一次處理語義有較高需求，此時依然適合考慮。
混合處理系統：批處理和流處理
一些處理框架可同時處理批處理和流處理工作負載。這些框架可以用相同或相關的組件和API處理兩種類型的數據，藉此讓不同的處理需求得以簡化。
如你所見，這一特性主要是由Spark和Flink實現的，下文將介紹這兩種框架。實現這樣的功能重點在於兩種不同處理模式如何進行統一，以及要對固定和不固定數據集之間的關系進行何種假設。
雖然側重於某一種處理類型的項目會更好地滿足具體用例的要求，但混合框架意在提供一種數據處理的通用解決方案。這種框架不僅可以提供處理數據所需的方法，而且提供了自己的集成項、庫、工具，可勝任圖形分析、機器學習、互動式查詢等多種任務。
Apache Spark
Apache Spark是一種包含流處理能力的下一代批處理框架。與Hadoop的MapRece引擎基於各種相同原則開發而來的Spark主要側重於通過完善的內存計算和處理優化機制加快批處理工作負載的運行速度。
Spark可作為獨立集群部署（需要相應存儲層的配合），或可與Hadoop集成並取代MapRece引擎。
批處理模式
與MapRece不同，Spark的數據處理工作全部在內存中進行，只在一開始將數據讀入內存，以及將最終結果持久存儲時需要與存儲層交互。所有中間態的處理結果均存儲在內存中。
雖然內存中處理方式可大幅改善性能，Spark在處理與磁碟有關的任務時速度也有很大提升，因為通過提前對整個任務集進行分析可以實現更完善的整體式優化。為此Spark可創建代表所需執行的全部操作，需要操作的數據，以及操作和數據之間關系的Directed Acyclic Graph（有向無環圖），即DAG，藉此處理器可以對任務進行更智能的協調。
為了實現內存中批計算，Spark會使用一種名為Resilient Distributed Dataset（彈性分布式數據集），即RDD的模型來處理數據。這是一種代表數據集，只位於內存中，永恆不變的結構。針對RDD執行的操作可生成新的RDD。每個RDD可通過世系（Lineage）回溯至父級RDD，並最終回溯至磁碟上的數據。Spark可通過RDD在無需將每個操作的結果寫回磁碟的前提下實現容錯。
流處理模式
流處理能力是由Spark Streaming實現的。Spark本身在設計上主要面向批處理工作負載，為了彌補引擎設計和流處理工作負載特徵方面的差異，Spark實現了一種叫做微批（Micro-batch）*的概念。在具體策略方面該技術可以將數據流視作一系列非常小的「批」，藉此即可通過批處理引擎的原生語義進行處理。
Spark Streaming會以亞秒級增量對流進行緩沖，隨後這些緩沖會作為小規模的固定數據集進行批處理。這種方式的實際效果非常好，但相比真正的流處理框架在性能方面依然存在不足。
優勢和局限
使用Spark而非Hadoop MapRece的主要原因是速度。在內存計算策略和先進的DAG調度等機制的幫助下，Spark可以用更快速度處理相同的數據集。
Spark的另一個重要優勢在於多樣性。該產品可作為獨立集群部署，或與現有Hadoop集群集成。該產品可運行批處理和流處理，運行一個集群即可處理不同類型的任務。
除了引擎自身的能力外，圍繞Spark還建立了包含各種庫的生態系統，可為機器學習、互動式查詢等任務提供更好的支持。相比MapRece，Spark任務更是「眾所周知」地易於編寫，因此可大幅提高生產力。
為流處理系統採用批處理的方法，需要對進入系統的數據進行緩沖。緩沖機制使得該技術可以處理非常大量的傳入數據，提高整體吞吐率，但等待緩沖區清空也會導致延遲增高。這意味著Spark Streaming可能不適合處理對延遲有較高要求的工作負載。
由於內存通常比磁碟空間更貴，因此相比基於磁碟的系統，Spark成本更高。然而處理速度的提升意味著可以更快速完成任務，在需要按照小時數為資源付費的環境中，這一特性通常可以抵消增加的成本。
Spark內存計算這一設計的另一個後果是，如果部署在共享的集群中可能會遇到資源不足的問題。相比HadoopMapRece，Spark的資源消耗更大，可能會對需要在同一時間使用集群的其他任務產生影響。從本質來看，Spark更不適合與Hadoop堆棧的其他組件共存一處。
總結
Spark是多樣化工作負載處理任務的最佳選擇。Spark批處理能力以更高內存佔用為代價提供了無與倫比的速度優勢。對於重視吞吐率而非延遲的工作負載，則比較適合使用Spark Streaming作為流處理解決方案。
Apache Flink
Apache Flink是一種可以處理批處理任務的流處理框架。該技術可將批處理數據視作具備有限邊界的數據流，藉此將批處理任務作為流處理的子集加以處理。為所有處理任務採取流處理為先的方法會產生一系列有趣的副作用。
這種流處理為先的方法也叫做Kappa架構，與之相對的是更加被廣為人知的Lambda架構（該架構中使用批處理作為主要處理方法，使用流作為補充並提供早期未經提煉的結果）。Kappa架構中會對一切進行流處理，藉此對模型進行簡化，而這一切是在最近流處理引擎逐漸成熟後才可行的。
流處理模型
Flink的流處理模型在處理傳入數據時會將每一項視作真正的數據流。Flink提供的DataStream API可用於處理無盡的數據流。Flink可配合使用的基本組件包括：
· Stream（流）是指在系統中流轉的，永恆不變的無邊界數據集
· Operator（操作方）是指針對數據流執行操作以產生其他數據流的功能
· Source（源）是指數據流進入系統的入口點
· Sink（槽）是指數據流離開Flink系統後進入到的位置，槽可以是資料庫或到其他系統的連接器
為了在計算過程中遇到問題後能夠恢復，流處理任務會在預定時間點創建快照。為了實現狀態存儲，Flink可配合多種狀態後端系統使用，具體取決於所需實現的復雜度和持久性級別。
此外Flink的流處理能力還可以理解「事件時間」這一概念，這是指事件實際發生的時間，此外該功能還可以處理會話。這意味著可以通過某種有趣的方式確保執行順序和分組。
批處理模型
Flink的批處理模型在很大程度上僅僅是對流處理模型的擴展。此時模型不再從持續流中讀取數據，而是從持久存儲中以流的形式讀取有邊界的數據集。Flink會對這些處理模型使用完全相同的運行時。
Flink可以對批處理工作負載實現一定的優化。例如由於批處理操作可通過持久存儲加以支持，Flink可以不對批處理工作負載創建快照。數據依然可以恢復，但常規處理操作可以執行得更快。
另一個優化是對批處理任務進行分解，這樣即可在需要的時候調用不同階段和組件。藉此Flink可以與集群的其他用戶更好地共存。對任務提前進行分析使得Flink可以查看需要執行的所有操作、數據集的大小，以及下游需要執行的操作步驟，藉此實現進一步的優化。
優勢和局限
Flink目前是處理框架領域一個獨特的技術。雖然Spark也可以執行批處理和流處理，但Spark的流處理採取的微批架構使其無法適用於很多用例。Flink流處理為先的方法可提供低延遲，高吞吐率，近乎逐項處理的能力。
Flink的很多組件是自行管理的。雖然這種做法較為罕見，但出於性能方面的原因，該技術可自行管理內存，無需依賴原生的Java垃圾回收機制。與Spark不同，待處理數據的特徵發生變化後Flink無需手工優化和調整，並且該技術也可以自行處理數據分區和自動緩存等操作。
Flink會通過多種方式對工作進行分許進而優化任務。這種分析在部分程度上類似於SQL查詢規劃器對關系型資料庫所做的優化，可針對特定任務確定最高效的實現方法。該技術還支持多階段並行執行，同時可將受阻任務的數據集合在一起。對於迭代式任務，出於性能方面的考慮，Flink會嘗試在存儲數據的節點上執行相應的計算任務。此外還可進行「增量迭代」，或僅對數據中有改動的部分進行迭代。
在用戶工具方面，Flink提供了基於Web的調度視圖，藉此可輕松管理任務並查看系統狀態。用戶也可以查看已提交任務的優化方案，藉此了解任務最終是如何在集群中實現的。對於分析類任務，Flink提供了類似SQL的查詢，圖形化處理，以及機器學習庫，此外還支持內存計算。
Flink能很好地與其他組件配合使用。如果配合Hadoop 堆棧使用，該技術可以很好地融入整個環境，在任何時候都只佔用必要的資源。該技術可輕松地與YARN、HDFS和Kafka 集成。在兼容包的幫助下，Flink還可以運行為其他處理框架，例如Hadoop和Storm編寫的任務。
目前Flink最大的局限之一在於這依然是一個非常「年幼」的項目。現實環境中該項目的大規模部署尚不如其他處理框架那麼常見，對於Flink在縮放能力方面的局限目前也沒有較為深入的研究。隨著快速開發周期的推進和兼容包等功能的完善，當越來越多的組織開始嘗試時，可能會出現越來越多的Flink部署
總結
Flink提供了低延遲流處理，同時可支持傳統的批處理任務。Flink也許最適合有極高流處理需求，並有少量批處理任務的組織。該技術可兼容原生Storm和Hadoop程序，可在YARN管理的集群上運行，因此可以很方便地進行評估。快速進展的開發工作使其值得被大家關注。
結論
大數據系統可使用多種處理技術。
對於僅需要批處理的工作負載，如果對時間不敏感，比其他解決方案實現成本更低的Hadoop將會是一個好選擇。
對於僅需要流處理的工作負載，Storm可支持更廣泛的語言並實現極低延遲的處理，但默認配置可能產生重復結果並且無法保證順序。Samza與YARN和Kafka緊密集成可提供更大靈活性，更易用的多團隊使用，以及更簡單的復制和狀態管理。
對於混合型工作負載，Spark可提供高速批處理和微批處理模式的流處理。該技術的支持更完善，具備各種集成庫和工具，可實現靈活的集成。Flink提供了真正的流處理並具備批處理能力，通過深度優化可運行針對其他平台編寫的任務，提供低延遲的處理，但實際應用方面還為時過早。
最適合的解決方案主要取決於待處理數據的狀態，對處理所需時間的需求，以及希望得到的結果。具體是使用全功能解決方案或主要側重於某種項目的解決方案，這個問題需要慎重權衡。隨著逐漸成熟並被廣泛接受，在評估任何新出現的創新型解決方案時都需要考慮類似的問題。

『陸』 什麼是資料庫的概念結構

1. 資料庫定義:資料庫是長期儲存在計算機內、有組織的、可共享的大量數據的集合。資料庫中的數據按一定的數據模型組織、描述和儲存，具有較小的冗餘度、較高的數據獨立性和易擴展性，並可為各種用戶共享。2. 資料庫管理技術發展的三個階段：人工管理階段，文件系統階段，資料庫系統階段。3. DBMS（資料庫管理系統）是位於用戶與操作系統之間的一層數據管理軟體。主要功能：1，數據定義功能。2，數據組織、存儲和管理。3，數據操縱功能。4，資料庫的事務管理和運行管理。5，資料庫的建立和維護功能。6，其他功能。4. 什麼是數據模型及其要素? (設計題)： 數據模型是資料庫中用來對現實世界進行抽象的工具，是資料庫中用於提供信息表示和操作手段的形式構架。一般地講，數據模型是嚴格定義的概念的集合。這些概 念精確地描述系統的靜態特性、動態特性和完整性約束條件。因此數據模型通常由數據結構、數據操作和完整性約束三部分組成。 (1)數據結構：是所研究的對象類型的集合，是對系統的靜態特性的描述。 (2)數據操作：是指對資料庫中各種對象(型)的實例(值)允許進行的操作的集合，包括操作及有關的操作規則，是對系統動態特性的描述。 (3)數據的約束條件：是完整性規則的集合，完整性規則是給定的數據模型中數據及其聯系所具有的制約和依存規則，用以限定符合數據模型的資料庫狀態以及狀態的變化，以保證數據的正確、有效、相容。最常用的數據模型：層次模型，網狀模型，關系模型，面積對象模型，對象關系模型。5.常用的數據模型有哪些（邏輯模型是主要的），各有什麼特徵，數據結構是什麼樣的。答：數據模型可分為兩類：第一類是概念模型，也稱信息模型，它是按用戶的觀點來地數據和信息建模，主要用於資料庫設計。第二類是邏輯模型和物理模型。其中邏輯模型主要包括層次模型、層次模型、關系模型、面向對象模型和對象關系模型等。它是按計算機系統的觀點對數據建模，主要用於DBMS的實現。物理模型是對數據最低層的抽象，它描述數據在系統內部的表示方式和存取方法，在磁碟或磁帶上的存儲方式和存取方法，是面向計算機系統的。物理模型是具體實現是DBMS的任務，資料庫設計人員要了解和選擇物理醋，一般用戶則不必考慮物理級的細節。層次數據模型的數據結構特點：一是：有且只有一個結點沒有雙親結點，這個結點稱為根結點。二是：根 以外的其他結點有且只有一個雙親結點。優點是：1.層次 數據結構比較簡單清晰。2.層次資料庫的查詢效率高。3.層次數據模型提供了良好的完整性支持。缺點主要有：1.現實世界中很多聯系是非層次性的，如結點之間具有多對多聯系。2.一個結點具有多個雙親等 ，層次模型表示這類聯系的方法很笨拙，只能通過引入冗餘數據或創建非自然的數據結構來解決。對插入和刪除操作的限制比較多，因此應用程序的編寫比較復雜。3.查詢子女結點必須通過雙親結點。4.由於結構嚴密，層次命令趨於程序化。可見用層次模型對具有一對多的層次聯系的部門描述非常自然，直觀容易理解，這是層次資料庫的突出優點。網狀模型：特點：1.允許一個以上的結點無雙親2.一個結點可以有多於一個的雙親。網狀數據模型的優點主要有：1.能夠更為直接地描述現實世界，如一個結點可以有多個雙親。結點
之間可以有多種上聯第。2.具有良好的性能，存取效率較高。缺點主要有：1.結構比較復雜，而且隨著應用環境的擴大，資料庫的結構就變得越來越復雜，不利於最終 用戶掌握。2.網狀模型的DDL,DML復雜,並且要嵌入某一種高級語言中，用戶不容易掌握，不容易使用。關系數據模型具有下列優點：1.關系模型與非關系模型不同，它是建立在嚴格的數學概念的基礎上的。2.關系模型的概念單一。3.關系模型的存取路徑對用戶透明，從而具有更高的數據獨立性，更好的安全保密性，也簡化了程序員的工作和資料庫開發的建立 的工作。主要的缺點是：由於存取路徑房租明，查詢效率往往不如非關系數據模型。因此為了提高性能，DBMS必須對用戶的查詢請求進行優化。因此增加 了開發DBMS的難度，不過用戶不必考慮這些系統內部的優化技術細節。6.三級體系結構，外模式，模式 ，內模式定義是什麼？模式也稱邏輯模式，是資料庫中全體數據的邏輯結構和牲的描述，是所有用戶的公共數據視圖。 外模式也稱子模式或用戶模式，它是資料庫用戶能夠看見和使用的局部數據的邏輯結構和特徵的描述，是資料庫用戶的數據視圖是與某一應用有關的數據的邏輯表示。 內模式也稱存儲模式 ，是一個資料庫只有一個內模式。它是數據物理結構和存儲方式的描述，是數據在資料庫內部的表示方式。7.兩級映像和兩級獨立性，為什麼叫物理獨立性和邏輯獨立性。當模式改變時由資料庫管理員對各個外模式、模式的映像亻相應改變，可以使外模式保持不變。應用程序是依據數據的外模式編寫的，從而應用程序不必修改，保證了數據與程序的邏輯獨立生，簡稱數據的邏輯獨立性。當資料庫的存儲結構改變了，由資料庫管理員對模式、內模式映像作 相應改變，可以使模式保持不變，從而應用程序也不必改變。保證了數據與程序的物理獨立性，簡稱數據的物理獨立性。8.資料庫系統一般由資料庫、資料庫管理系統 （及其開發工具）、應用系統和資料庫管理員構成。9.關系的完整性（實體完整性、參照完整性、和用戶定義的完整性）三部分內容，其中前二者是系統自動支持的，DBMS完整性控制子系統的三個主要功能？：提供定義完整性約束條件的機制，提供完整性檢查的方法，違約處理。16.SQL的定義；即結構化查詢語言，是關系資料庫的標准語言，是一個通用的、功能極強的關系資料庫語言。分類（互動式和嵌入式）17.group by 和having子句的作用20.視圖的概念：視圖是從一個或幾個基本表導出的表。及相關操作：定義視圖，查詢視圖，更新視圖。視圖更新有什麼操作：插入，刪除，和修改。22.資料庫規范化的方法函數依賴的定義什麼叫1NF2NF3NF BCNF定義：關系資料庫中的關系是要滿足一定要求的，滿足不同程度要求的為不同範式。滿足最低要求的叫第一範式，簡稱1NF。在第一範式中滿足進一步要求的為第二範式，其餘以此類推。各種範式之間的聯系有：5NF（4NF（BCNF（3NF（2NF（1NF。25.資料庫設計的幾個階段，每個階段常用的方法和簡要的內容：六個階段：需求分析、概念結構設計、羅織結構設計、物理設計、資料庫實施、資料庫運行和維護。28.事務的概念？事務有哪些基本屬性commit roll back含義：事務：是用戶定義的一個資料庫操作序列，這些操作要麼全做，要麼全不做，是一個不可分割的單位。四個特性：原子性，一致性，隔離性，持續性。Commit（提交：提交事務的所有操作） rollback（回滾：在事務運行的過程中發生了某種故障，事務不能繼續執行，系統將事務中對資料庫的所有已完成的操作全部撤銷，回滾到事務開始時的狀態。 29.什麼叫資料庫系統的可恢復性？：資料庫管理系統具有把資料庫從錯誤狀態恢復到某一已知的正確狀態的功能，這就是資料庫系統的可恢復性。資料庫故障的種類：事務內部的故障，系統故障（軟故障），介質故障（硬故障），計算機病毒。30.不進行並發控制可能產生的問題？：多個事務對資料庫並發操作可能造成事務ACID特點遭到在破壞。如何解決（三個）：1，丟失修改 2，不可重復讀 3，讀「臟」數據。31.三級封鎖協議？能解決什麼問題？：一級封鎖協議：事務T在修改數據R之前必須先對其加X鎖，直到事務結束才釋放。事務結束包括正常結束（COMMIT）和非正常結束（ROLLBACK）。一級封鎖協議中，如果是讀數據不修改，是不需要加鎖的，可防止丟失修改。二級封鎖協議：在一級封鎖協議基礎上，加上事務T在讀數據R之前必須先對其加上S鎖，讀完後即可釋放S鎖。在二級封鎖協議中，由於讀完數據後即可釋放S鎖，所以它不能保證可重復讀。三級封鎖協議：一級封鎖協議加上事務T在讀取數據R之前必須先對其加S鎖，直到事務結束才釋放。三級封鎖協議除了防止了丟失修改和不讀「臟」數據外，還進一步防止了不可重復讀。上述三級協議的主要區別在於：什麼操作需要申請封鎖，以及何時釋放鎖。一般採取哪三種措施？插入呢？刪除呢？：1，拒絕執行（不允許該操作執行），2，級連操作（當刪除或修改被參照表的一個元組造成了與參照表的不一致，則刪除或修改參照表中的所有造成不一致的元組），3，設置為空值（當刪除或修改被參照表的一個元組時造成了不一致，則將參照表中的所有不造成不一致的元組的對應屬性設置為空值）。38.視圖對資料庫安全性的作用？：1，視圖能夠簡化用戶的操作，2，視力使用戶能以多種角度看待同一數據，3，視圖對重構資料庫提供了一定程度的邏輯獨立性，4，視圖能夠對機密數據提供安全保護，5，適當的利用視圖可以更清晰的表達查詢。資料庫：儲存在計算機內，永久存儲、有組織、有共享的大量數據的集合。數據管理技術的發展階段：1.人工管理階段：數據不保存，應用程序管理數據，數據不共享，數據不具有獨立性。2.文件系統階段：數據可以長期保存，由文件系統管理數據；數據共享性太差，冗餘度大，數據獨立性差。3.資料庫系統階段：出現資料庫管理系統。資料庫系統的特點：數據結構化（本質區別）；數據共享性高、冗餘度低、易擴充；數據獨立性高；數據有DBMS統一管理和控制。資料庫管理系統：1.定義：DBMS，是位於用戶與操作系統之間的一層數據管理軟體。2.功能：數據定義功能；數據組織、存儲和管理；數據操縱功能；資料庫的事務管理和運行管理；資料庫的建立和維護功能；通信功能、數據轉換功能、互訪和互操作功能。資料庫系統：1.概念：DBS，是指在計算機系統中引入資料庫後的系統。2.組成：一般由資料庫、資料庫管理系統、應用系統、資料庫管理員構成。3.分類：集中式，C/S式，並行式，分布式。數據模型：1.定義：現實世界數據特徵的抽象。2.組成，三要素：數據結構、數據操作、數據的完整性約束。兩類數據模型為1）概念模型2）邏輯模型和物理模型。數據結構：描述資料庫的組成對象以及對象之間的聯系，主要描述與對象的類型、內容、性質有關的對象和與數據之間聯系有關的對象。常用的數據模型：1.層次模型，用樹形結構表示各類實體以及實體間的聯系。2.網狀模型，允許一個以上的結點無雙親，允許一個結點可以有多於一個的雙親。3.關系模型，包含單一數據結構