1、數據倉庫建模方法論 數據倉庫概念 數據倉庫數據架構 邏輯數據模型 數據模型標準化工藝流程主題數據倉庫領域的兩位大師Bill Inmon數據倉庫之父，數據倉庫概念的創始人理論： Corporate Information Factory(CIF) 主要著作：數據倉庫、企業信息工廠主要著作：數據倉庫工具箱維度建模的完全指南、 數據倉庫生命周期工具箱 設計、開發和部署數據倉庫的專家方法Ralph Kimball數據倉庫方面的知名學者理論：Mutildimensional Architecture(MD) 企業數據倉庫EDW企業數據倉庫定義：詳細交易及相關業務數據的集合包含必要的內部與外部信息來自于多

2、個數據源/業務操作系統保存一定的時間周期按照企業內業務規則所決定的模型來存儲企業數據倉庫作用：基于數據/信息來回答相關的業務問題和提供決策支持，并確保：一致、集成的數據存儲任意的數據粒度在整個企業的業務范圍保持企業內一致的信息視圖企業內一致的信息視圖（Single Version of the Truth）集成的企業信息（Integrated corporate information）不針對特定應用（Application neutral）無冗余（Non redundant）用于報表和決策支持（Reporting and decision making）最詳細的數據和信息（Detailed

3、Data）任何時候，針對任意數據，提出任意業務問題（Ask any question, any data, any time）數據倉庫的特點企業信息工廠數據倉庫總線 企業總線總線架構矩陣多維體系結構與企業信息工廠體系結構比較方面多維體系結構企業信息工廠體系結構范圍優先考慮業務單位范圍優先考慮企業總體范圍角度關心業務部門的需求多維建模師以企業視角，建立一致性維度。從企業角度解決供應源數據的問題，但并不是整個企業的數據必須在項目第一個階段都處理。相反而是選擇企業所有數據的一個子集。數據流實施方法采用自底向上的：如何快速的獲取由用戶控制的業務部門專有的數據，并最小限度的考慮整個企業的使用快速需求收集

4、和實現過程使得為整個環境提供一致而可靠數據的任務變得復雜。實施方法是自頂向下的：企業數據利用業務需求將數據從數據源推至需要這些數據的地方，其核心問題是從最初的項目開始為任何數據集市的使用而集成企業數據。為了制定盡可能在整個企業范圍內一致的主題域和業務數據需要增加模型開銷，需要更多的時間和代價。但后續項目則需要較少時間和代價，尤其對于使用現有的、健全的主題域的業務單位更是如此。實現對存儲空間最小需求，非冗余方式防止了在多個位置存儲數據。這種特性使更新或刪除異常最小化或者消除。易失性聚集數據集市：當業務過程發生變化，為了消除或減少對事實表重建，需要增加新的維或改變維。原子數據集市：由于事實表可能包

5、含幾億甚至更多的數據，重建將會帶來嚴重后果數據倉庫模型是與過程無關的，它摒棄了由于處理過程影響而帶來的變化數據倉庫模型的設計依賴于企業的業務規則，而不依賴與在其上將運行什么查詢。如果一個已經建好的數據集市需要改變或加強，可以根據存儲在數據倉庫中的細節數據合理且快速地進行重建靈活性多維設計是很多業務過程聚集在一起的結果。當處理請求發生變化時，多維數據庫的設計未必能夠適度地變化。數據倉庫模型存放數據粒度級別為原子級別，原子級別可以任意組合。故可以支持將來未知需求。復雜性數據集市模型易于業務人員理解。可以很容易構建數據集市，然而，當一個一個地建立數據集市時，由于數據的企業視圖的復雜性，對于這種結構，

6、完成更新時相當復雜的。數據倉庫中的細節數據是與處理過程無關的，因此數據倉庫的數據模型使得數據不一致的風險最小。功能性為多維處理提供了理想環境，切片和切塊、上鉆和下鉆等查詢提供良好的性能支持數據挖掘、統計分析和即席查詢持續維護總體目標是防止由于環境的后續構建、調整和優化而產生的高昂的代價。一個良好的數據倉庫模型將為企業提供長久的服務，將提供如下回報：整個環境端到端一致性和集成性易于建立新的數據集市加強現有數據集市數據倉庫和有關數據集市的維護和可持續發展OLTP與OLAP 針對特定問題的聯機數據訪問和數據分析技術 滿足對數據進行多角度、快速、一致、交互、深入觀察 使用預定義的多維數據視圖對數據進行

7、分析處理，支持對數據的切片、切塊、鉆取。 多維數據庫是一種以多維數據存儲形式來組織數據的數據管理系統，在使用時需要將數據從關系數據庫中轉載到多維數據庫中方可訪問。 也稱為面向交易的處理系統，其基本特征是顧客的原始數據可以立即傳送到計算中心進行處理，并在很短的時間內給出處理結果。這樣做的最大優點是可以即時地處理輸入的數據，及時地回答。也稱為實時系統(Real time System)。衡量聯機事務處理系統的一個重要性能指標是系統性能，具體體現為實時響應時間(Response Time)，即用戶在終端上送入數據之后，到計算機對這個請求給出答復所需要的時間。OLTP 數據庫旨在使事務應用程序僅寫入所

8、需的數據，以便盡快處理單個事務。On-Line Analytical ProcessingOn-Line Transaction ProcessingOLTP與OLAPOLTPOLAP用戶操作人員,低層管理人員決策人員,高級管理人員功能日常操作處理分析決策DB 設計面向應用面向主題數據當前的, 最新的細節的, 二維的歷史的, 聚集的, 多維的集成的, 統一的存取讀/寫數十條記錄讀上百萬條記錄工作單位簡單的事務復雜的查詢用戶數上千個上百個DB 大小100MB-GB100GB-TBROLAP表示基于關系數據庫的OLAP實現（Relational OLAP）MOLAP表示基于多維數據組織的OLAP實

9、現（Multidimensional OLAP）ROLAPMOLAP沿用現有關系數據庫技術專用技術響應速度相對molap要慢性能好，響應速度快數據轉載計算速度快數據轉載速度慢存儲空間耗費小，維數沒有限制需要進行預計算，可能導致數據爆炸，維數有限，無法支持維的動態變化借助rdbms對數據存儲，無文件大小限制受操作系統平臺文件大小限制，難以達到tb級可以通過sql語句實現詳細數據和概要數據的存儲缺乏數據模型和數據訪問的標準不支持預計算的讀寫操作無法完成維之間的運算無法完成多行計算支持高性能的決策支持計算復雜的跨維計算多用戶讀寫操作行級計算ROLAP vs MOLAP 數據倉庫概念 數據倉庫數據架構

10、 邏輯數據模型 數據模型標準化工藝流程主題數據架構形態各數據架構比較源系統ODSEDW獨立數據集市Data Mart #1Data Mart #2Non-conformedDimensions and Facts從屬數據集市Data Mart #1Data Mart #2Conformed DimensionsandConformed FactsData Mart數據集市類型活期存款定期存款零售信貸公司信貸債券投資票據信息同業拆借儲蓄國債衍生品儲蓄國債參與者交易流水會計單元理財產品風險緩釋市場數據計量結果公共信息數據挖掘模型風險引擎數據接口星型模型報表模型多維分析模型風險計算引擎信用風險績效衡

11、量和資本分配合規性與披露市場風險操作風險流動性風險防欺詐和反洗錢Enterprise Date WarehouseODS風險計量結果返回ODS多維分析匯總層應用層監管報表風險數據集市數據架構風險數據集市建設目標 數據倉庫概念 數據倉庫模型 邏輯數據模型 數據模型標準化工藝流程主題為什么需要邏輯數據模型為復雜的數據倉庫系統實施提供了規范和基礎結構藍圖促進業務部門用戶和IT分析人員之間的有效溝通明確業務需求解決業務問題形成對重要業務定義和術語的統一認識具備跨部門，能夠表達所有的業務 技術緩沖層 ETL專用的純技術層完全與源系統結構一致近源模型層 基本依照源系統建模盡量保持業務系統原貌整合模型層 面

12、向整合主題設計提供規范和共享應用集市層面向應用按需定制多維建模匯總數據核心系統對公信貸票據系統儲蓄國債市場數據核心系統對公信貸票據系統儲蓄國債市場數據.復雜交易復雜交易數據挖掘模型風險引擎數據接口星型模型報表模型多維分析模型匯總層當事人財務產品資產事件內部機構協議計量結果市場數據LDM在數據倉庫系統中的地位ODSEDWData MartData Mining目標短期的，細節的，同源的數據存儲；直接提供基于源系統結構的簡單原貌訪問；為BI環境中適合的業務需求提供支持長期的，細節的，整合的數據存儲；為BI環境中適合的業務需求提供支持服務特定應用 長期歷史分析性指標匯總 為企業提供預測性、趨勢分析性

13、需求提供支持原則簡單處理，不考慮整合；關注保留策略；面向全局，數據整合中性設計，靈活擴展提供規范和共享面向具體應用按需設計針對業務目標、挖掘算法設計數據模型形式偏源系統模型；根據支持應用情況可以保留短期歷史面向主題設計；偏范式化；長期保留歷史形式各異，依具體應用不同； 一條記錄表示一個觀測 多條記錄表示一個觀測重點理解源結構主題定義框架設計整合策略實施方法整體性一致性 業務理解 數據理解 數據準備用途業務原貌查詢即時報表數據質量檢查靈活查詢整合規則檢查特定應用 特定業務專題設計思路比較EDW邏輯數據模型設計目標中性的，共享的：不針對某個特別的應用而設計；靈活的，可擴展的：存放最詳盡的歷史數據，

14、業務發生變化時易于擴展，適應復雜的實際業務情況；穩定的，經得起考驗的：能夠在很長時間內保持穩定性，回答不斷產生、不斷變化且無法預先定義的業務問題；規范的，易懂的：使用業務語言進行模型設計，易于讓業務人員理解和使用，有助于IT和業務部門人員的溝通邏輯視圖(第三級)細節(第三級)主題區域(第一級)概念(第二級)邏輯數據模型的不同級別25邏輯數據模型的主題域主題域模型案例-市場風險數據集市主題域模型案例-信用卡數據集市主題域模型優點 指導業務數據模型開發 有助于數據一致性，避免冗余。當確定一個新的實體時，基于定義可以確定實體的恰當地主題域。 根據主題域劃分工作量，可使重復工作量最小化，并有利于相互協

15、調 指導數據倉庫項目選擇 為基于數據的項目分組提供了一種高層次劃分方法。在確定項目開發順序時，應該同時考慮業務優先級、技術實現難度、 人員可用性等信息 指導數據倉庫開發 有助于確定哪些相關的業務專家主題域模型目標 提供廣泛的理解提供對每一個主題域的理解，包括各個主題域的名稱和定義，通過業務規則將這些主題域聯系起來，形象地表達這些主題之間依賴關系和規則。因為在主題域層次，所以，主題域模型更容易覆蓋廣泛的領域。業務規則使主題域模型增加更多的準確性和清晰性。 確定范圍通過形象地表達主題域和他們的業務規則，我們能夠更容易地識別出將要分析的模型的范圍。 指引方向主題域模型能夠提供全景視圖，可以幫助我們確

16、定：計劃中的應用程序和現有的應用程序將怎樣共存。下一步，企業將需要什么樣新功能。主題域模型提供方向和指南。 建立對業務的高層次理解，為邏輯數據分析和建模打下基礎主題域模型概念模型影響數據倉庫粒度級別的主要因素匯總數據匯總數據能夠改善數據交付處理性能，匯總數據不會節省存儲空間，因為創建匯總的細節可能會繼續被保留。匯總提供的好處主要包括： 在線存儲需求減少 分析的標準化以及數據交付性能的改善 合并實體通過減少連接操作的數量，提高了數據交付處理的性能，并且可以增強一致性。分離數據根據穩定性和用法來分離數據。穩定性分析根據各個數據屬性是否經常變化的特性將這些屬性進行分組。影響因素描述當前業務需求粒度級

17、別必須足以回答定位在該數據倉庫迭代范圍內的每一個業務問題。提供高的粒度級別增加了數據倉庫和項目的開發成本，如果業務不需要細節，則增加的成本就沒有商業價值。未來業務需求按照目前明確需求建立數據倉庫，但在建立并抽取數據時要適應考慮未來的需求數據挖掘需求數據挖掘算法需要細節級明細數據派生數據需求派生數據在計算時使用了其它的數據元素，除非在代價和開發時間方面有很大增長，否則所選的粒度級別應該適用于存儲所有用于派生其它數據元素的元素。操作系統粒度操作源系統中有效的細節級別，對于不同粒度的源系統需要決定是否在最低的公共級別上抽取數據，以使所有的數據很好的整合，或者從每一個系統中根據他的有效粒度來抽取數據。

18、存儲開銷粒度級別對存儲開銷有很大影響備份和恢復數據倉庫需要周期性地進行備份和恢復，細節越多，日常備份需要的時間也越多。數據倉庫粒度級別逆規范化指南問題類型解決方法關系類型層次關系：子對父通常有很強的依賴性。傾向于將把這些概念逆規范化到一個實體同等關系：在獨立的表中保存獨立的實體，可以保證設計與業務規則保持一致。一對一關系：如果當一個實體值僅與來自另一個實體的一個實體值相關，反之亦然。傾向于逆規范化。確定關系：父實體決定子實體的意義。通常為事務處理數據到引用數據的關系和關系實體，在多對多關系引入的關系表被認為是子，而參與多對多關系的兩個表被認為是父。在事務處理引用關系中，事務處理表是子，而引用表

19、是父。通常，子表很大且易變。父表通常穩定的多且小。所以傾向于把這兩個實體保存在各自的表中。參與率確定關系中每個實體的參與性。對于一個給定的父實體數值，大概會有幾個子實體數值。父子關系越接近一對一，將父實體逆規范化到子實體，將有最小數量的冗余。父實體中有多少數據元素如果將父實體逆規范化到子實體，保證子實體中具有存放父實體的數據元素額外空間。使用率兩個實體的耦合或相關程度如何。如果在許多用戶查詢和發布中，來自兩個實體的數據元素將一起出現，那么，如果這些信息在同一表中而不是分布于多個表之內，則信息獲取將會更快捷。父實體是否變化如果未來父實體不需要加入更多的數據元素或關系，那么新業務規則不會對父實體引

20、起完整性和強制性影響。進行逆規范化的可行性就較強。如果未來父實體需要加入更多的數據元素或關系，那么新父實體數據元素會引起額外的冗余和空間。為了避免將來的維護和冗余問題，需要保持兩個實體的獨立性。變動對比率在同一時間周期內，兩個實體的插入和更新頻率是否相近。主要考慮性能和數據同步問題。即數據穩定性。風險數據集市-匯總層風險數據集市-應用層 數據倉庫概念 數據倉庫數據架構 邏輯數據模型 數據模型標準化工藝流程主題步驟任務項目準備與策劃模型設計人員的主要職責是參與制定模型相關的項目實施策略，包括確定數據源范圍，明確最終提交物和項目日程等。此外，模型設計人員在進場前可參與提出客戶相關資料的具體需求，包

21、括一些參考模板，以保證后續工作的輸入。項目啟動模型設計人員參與模型相關的工作流程制定、標準文檔的客戶化，負責在整個項目組范圍內組織模型培訓，明確LDM在整個信息架構中的定位和作用，并就工作方法達成共識。 系統需求模型設計人員參與業務訪談、數據和功能的需求分析系統設計系統設計工作是模型組工作的主體，主要由模型小組主導。它包括：信息調研、構建概念模型、邏輯數據模型詳細設計，以及物理數據模型設計。系統開發與單元測試模型設計人員主要起到支持的作用，為開發人員解釋模型設計，協助驗證單元測試的結果等，并根據測試發現的問題進行相應修改和變更。數據模型標準工藝概述項目準備與策劃在項目準備與策劃階段，模型設計人

22、員的主要職責是參與制定模型相關的項目實施策略，包括確定數據源范圍，明確最終提交物和項目日程等。此外，模型設計人員在進場前可參與提出客戶相關資料的具體需求，包括一些參考模板，以保證后續工作的輸入。確定項目人員本階段將確定參與項目實施的所有人員名單，包括全職和兼職人員。其中，在確定模型人員時，需考慮對人員進行如下要求： 熟悉使用建模工具 擁有豐富模型設計經驗 熟悉銀行業務 較強的溝通表達能力 具備數據敏感性 收集資料資料名稱資料說明相關模板名稱系統數據結構相關系統完整的數據結構（含字段/代碼的取值說明和索引等信息）供分析用源系統數據字典模板.xls業務需求客戶提供的各種業務需求材料部門職能調查問卷

23、對目標訪問部門的職能/業務范圍進行調研訪談材料現狀介紹/業務調查問卷/數據調查問卷制定實施策略明確與模型相關的 數據源范圍 里程碑 提交物 工作日程項目啟動在項目啟動階段，模型設計人員參與模型相關的工作流程制定、標準文檔的客戶化，負責在整個項目組范圍內組織模型培訓，明確數據模型在整個信息架構中的定位和作用，并就工作方法達成共識。制定工作流程劃分不同小組的工作邊界 確定模型組人員的工作分工 確定項目組內部以及對外的工作模式 對公司標準項目實施流程進行客戶化進行模型培訓介紹源系統由客戶介紹源系統，內容包括： 系統架構/設計思想/系統定位 業務功能/重要流程 關鍵數據表以及關系 和其他系統的關系 培

24、訓內容相關模板名稱數據模型的基本概念、定位及常用的建模方法數據模型培訓模板.ppt模型設計規范邏輯數據模型設計規范模板.pdf數據模型設計工具模型產品培訓【可選，依是否使用模型產品而定】系統需求在系統需求階段，模型設計人員參與配合業務顧問（以業務顧問為主導），進行需求分析、業務訪談工作，對需求人員所編寫的業務需求說明書就模型相關部分進行確認。業務訪談業務訪談階段 訪談議程及內容設定：訪談目的/訪談方式/調查問卷 調查問卷填寫：填寫說明/雙方交流問卷反饋內容 訪談過程記錄：專人負責記錄/錄音 聯系人員確認：確定對口聯系人，跟進未盡事宜 模型設計人員參與業務訪談過程內容總結階段 模型設計人員參與文

25、檔整理：訪談紀要的整理發送/調查 問卷的收集整理/不明確問題的確認 業務調研總結報告 報告編寫、確認總結報告需求分析業務數據分析 涉及的指標 查詢條件 分析維度 統計口徑 計算公式 處理周期 功能分析 目的與用途 流程調研 報表格式、展現方式 權限分配、用戶管理 補錄數據 對業務需求說明書的模型相關內容要求報表類需求需包含：對報表需求分類，簡述報表的目的。報表的訪問頻度、使用部門、權限要求 報表數據項定義、查詢條件 報表樣式 分析類需求需包含：對分析類需求分類，簡述分析的目的 訪問頻度、使用部門、權限要求 分析維度定義 分析指標定義 信息調研 本階段工作由模型設計人員主導，在系統需求調研的基礎

26、上進行系統數據滿足度分析。模型設計人員解讀業務需求說明書中產生的問題，記入業務需求問題跟蹤單進行跟蹤確認.業務顧問需根據數據滿足度中的數據缺口，確認或變更相應業務需求說明書的內容。構建概念模型 本階段工作由模型設計人員主導進行，主要工作包括建立主題域，確認重要業務關系，生成概念模型。如果項目中有規范小組，則由規范小組主導“規范關鍵定義”的工作。 邏輯數據模型詳細設計 本階段工作由模型設計人員主導，進行邏輯數據模型設計。業務人員需對模型人員提出的重要規則及處理原則進行確認。 物理數據模型設計 本階段的工作由技術人員主導，將邏輯數據模型轉化成可具體實施的物理數據模型,邏輯模型設計人員提供支持。物理

27、數據模型與平臺緊密相關，在實際的數據庫平臺上談論物理數據模型具有更高的可操作性系統開發與單元測試在系統開發與單元測試階段，模型設計人員主要起到支持的作用，為開發人員解釋模型，支持開發人員的數據映射和關聯關系驗證等工作，協助驗證單元測試的結果，并根據測試發現的問題進行相應修改和變更。支持模塊開發對模型進行說明和解釋 支持數據映射 支持關聯關系驗證 協助模塊單元測試協助單元測試結果驗證協助進行錯誤原因分析 修改、完善設計 根據開發和測試中發現的問題 調整模型，進行模型變更完善優化邏輯數據模型健康性檢查邏輯數據模型健康性檢查是針對邏輯數據模型設計與維護中的關鍵項目定期進行評估與回顧的活動，及早發現可

28、能存在的問題與不足，提升人員認知，給出合理化改進建議，完善規范與流程，保持邏輯數據模型健康持續發展，從而為各項工作提供邏輯清晰、設計規范、架構合理、使用方便的邏輯數據模型，提升數據服務質量。架構層面健康性檢查整體架構檢查 檢查主題是否完整 檢查主題間關系是否完整、準確 檢查涵蓋的業務范圍是否合理 檢查支持和服務的應用領域是否合理 主題架構檢查 檢查各主題的核心分類是否符合現狀、是否具備擴展性 檢查核心實體的業務定義是否準確和清晰 檢查是否采用了父子結構和重要關聯關系表等技術 檢查業務規則的表達是否合理 檢查是否有細分的子主題，劃分的詳略程度是否合適管理流程健康性檢查版本檢查 檢查有沒有使用工具

29、進行版本控制 檢查不同版本的劃分是否具有標準 核實每次發生版本變化的主要原因是什么 檢查歷史版本如何管理、版本是否有簡要說明 維護檢查 檢查是否有源系統變更管理流程 檢查是否有分析需求變更管理流程 檢查是否有統計匯總加工規則變化管理流程 元數據檢查 檢查模型是否具備發布機制 檢查模型是否能夠與元數據保持同步 檢查業務人員是否能查詢到所需信息 業務層面健康性檢查易用性檢查 檢查用戶了解模型與數據的所有方式 檢查是否有幫助文檔 檢查是否有培訓體系 一致性檢查 檢查現有業務規則的處理是否為大家接受 檢查新的或者變化的業務規則的處理方法 了解使用中的主要問題有哪些方面 檢查業務規則在不同層次之間是否一

30、致 完整性檢查 檢查業務應用中是否發現缺失的業務信息 核實缺失業務信息的原因 檢查已采納的業務數據是否完整、是否一致 完善優化物理數據模型優化檢查進行物理數據模型優化的工作要點 檢查字段命名是否符合規范 參考物理模型設計階段制定的命名規則進行檢查； 對不符合規范的字段了解原因，并決定是否進行修改； 檢查字段數據類型是否符合規范 檢查字段的數據類型是否符合加工規則、加載需求及應用需求； 如果制訂了數據類型規范，則應對照數據類型規范進行檢查； 對數據量大小排在前二十名表 找出所有加載這二十張表的腳本； 找出所有使用這二十張表的腳本和查詢； 考察這些腳本和查詢中對這些大表的常見用法(比如如何下條件等

31、)以及其實際性能表現; 結合上述信息分析其所用數據庫物理特性是否合理(比如分區、索引等)，如不合理討論是否應該修改； 考察是否還有進一步加入其他物理特性的必要性(比如對大表是否需要進行拆分處理、對目前拆的過散的表是否需要進行合并處理等)； 在初步測試后給出修改建議； 對運行最慢的前二十個腳本，以及有代表性及重用性的一些較慢的隨機查詢 找出導致這些腳本及查詢運行較慢的關鍵表；分析導致其運行效率較差的原因，判斷是否有進一步物理優化的可能性； 在初步測試后給出修改建議；.設計規范健康性檢查建模工具檢查 業務規則檢查 技術標準檢查 外觀美學檢查物理數據模型優化檢查物理模型優化檢查是針對整個系統運行情況

32、評估和回顧的一部分，及時檢查并發現物理模型設計過程中的一些問題和不足，并及時加以改進和完善，使得整個系統運行更加穩定、高效。進行物理數據模型優化的時機 系統運行一段時間后，出現空間容量、執行效率、資源分配的問題時 數據庫版本升級后 5、世上最美好的事是：我已經長大，父母還未老;我有能力報答，父母仍然健康。6、沒什么可怕的，大家都一樣，在試探中不斷前行。7、時間就像一張網，你撒在哪里，你的收獲就在哪里。紐扣第一顆就扣錯了，可你扣到最后一顆才發現。有些事一開始就是錯的，可只有到最后才不得不承認。8、世上的事，只要肯用心去學，沒有一件是太晚的。要始終保持敬畏之心，對陽光，對美，對痛楚。9、別再去抱怨

33、身邊人善變，多懂一些道理，明白一些事理，畢竟每個人都是越活越現實。10、山有封頂，還有彼岸，慢慢長途，終有回轉，余味苦澀，終有回甘。11、人生就像是一個馬爾可夫鏈，你的未來取決于你當下正在做的事，而無關于過去做完的事。12、女人，要么有美貌，要么有智慧，如果兩者你都不占絕對優勢，那你就選擇善良。13、時間，抓住了就是黃金，虛度了就是流水。理想，努力了才叫夢想，放棄了那只是妄想。努力，雖然未必會收獲，但放棄，就一定一無所獲。14、一個人的知識，通過學習可以得到;一個人的成長，就必須通過磨練。若是自己沒有盡力，就沒有資格批評別人不用心。開口抱怨很容易，但是閉嘴努力的人更加值得尊敬。15、如果沒有人為你遮風擋雨，那就學會自己披荊斬棘，面對一切，用倔強的驕傲，活出無人能及的精彩。5、人生每天都要笑，生活的下一秒發生什么，我們誰也不知道。所以，放下心里的糾結，放下腦中的煩惱，放下生活的不愉快，活在當下。人生喜怒哀樂，百般形態，不如在心里全部淡然處之，輕輕一笑，讓心更自