今天看到一篇大資料gis的文章，文章中講到了資料驅動的空間分析和挖掘。
摘自李清泉，李德仁，2014《大資料gis》：
資料的極大豐富使人們可以逐漸擺脫對模型和假設的依賴。對於大資料時代，谷歌的研究主管peter norvig 有一句名言「all models are wrong, and increasingly you can succeed without them」。所以，大資料gis的特徵之二就是空間分析方法由模型驅動逐漸轉變為資料驅動。
那麼究竟什麼是資料驅動，什麼是模型驅動，今天看了一篇部落格，感覺對理解有幫助，分享一下：
資料驅動、模型驅動作為如今軟體設計中兩種不同的模型驅動方法，應該說各有各的優缺點以及適用的場合，不能就一概的去認為哪種必然就是更好的。
資料驅動採用的方式是根據對業務的分析建立資料模型來進行系統設計的一種方法，通過資料模型的建立來完成系統的實現，一般來說，在採取資料模型的系統中多採用的是前台直接和資料模型進行繫結的方式，這樣在實現起來相對來講會非常的快速。根據資料驅動的系統設計以及實現方式上來講，資料驅動適合於資料型的應用系統的建設，而現在大部分的中小型應用系統很多就停留在這個層面上，在這類系統中資料驅動會顯得特別的實用和好用，這類系統乙個非常突出的共同點就是系統基本屬於資訊的錄入、顯示以及查詢這樣的乙個過程，不存在複雜的資料業務邏輯處理。
模型驅動採用的方式根據對業務的分析建立業務物件模型來進行系統設計的一種方法，通過業務物件模型結合系統架構約束來進行系統的實現，一般來說，在採取模型驅動的系統中多採用n層的結構體系，前台顯示一般和業務顯示模型進行互動，而業務顯示模型則通過業務物件模型進行互動來完成業務邏輯的處理，業務物件模型通過與持久物件模型進行業務持久的處理，在這樣的情況下，勢必增加了系統的複雜度，模型驅動適合與業務型應用系統的建設，這個在行業化的業務應用上顯得比較突出，這類系統的共同點在於業務邏輯較為複雜而且多變，系統不僅僅是資訊的錄入、顯示以及查詢，更多的是對錄入或顯示的資訊進行業務邏輯的處理。
經過上面的簡單介紹後，我覺得對於資料驅動和模型驅動都會有個大概的概念，只能說資料驅動和模型驅動各有優勢，要結合系統需求來選擇相應的驅動方式。
對於模型驅動個人有些觀點，其實從模型驅動我們可以看出如果採用模型驅動面對乙個資料型的應用系統時，最後產生的業務物件模型即退化為了資料模型，只是由於模型驅動通常採用的n層架構此時反而約束了此模型的快速實現，是否應該在模型驅動的n層架構中去考慮一種退化的業務物件模型的支援呢？覺得這點是值得思考的，如果支援的話應該說對於模型驅動非常有利或者說是模型驅動的乙個補充，相當於對於模型驅動進行分類處理，有些時候架構不能太s，還是要根據系統建設的需求做出適當的調整。
根據這樣的觀點，其實資料驅動也是模型驅動，只是它採用的是一種退化的業務物件模型的驅動，並同時進行架構層次的調整以適應系統的快速建設，但資料驅動對於複雜多變的業務邏輯系統來說畢竟難去滿足了，主要是會在資料模型的建立以及業務邏輯的修改的方面。
綜合這樣的觀點，還是更為傾向模型驅動，同時也認為，模型驅動的架構應該考慮對於退化的業務物件模型的支援。
資料驅動 模型驅動 模型驅動的雲安全
存檔日期 2019年5月15日 首次發布 2011年2月8日 手動將安全策略轉換為技術實施非常困難，昂貴且容易出錯，尤其是在應用程式層實施時。為了在時間和金錢上的投資方面實現更多的成本節省，雲安全工具需要變得更加自動化。還需要這些工具的自動化，以使雲安全管理成為一項更輕鬆的任務，使雲管理員可以專注於...
屬性驅動與模型驅動的比較
a 屬性驅動靈活 準確 模型驅動不靈活，因為很多時候，頁面所提交過來的引數並不屬於模型中的屬性.也就是說頁面所提交過來的引數，與模型中的屬性 並不一致，這是很常見的情況。b 模型驅動更加符合物件導向的程式設計風格，使得我們獲得的是物件而不是乙個個離散的值。c 使用模型驅動時action方法需要實現m...
資料驅動和模型驅動的區別
自己的理解，不對望糾正。在以前的基於數學的時期時，因為不可能對大量的資料做處理，所以只能依靠在少量資料中例如數學中正態分佈等等的假定來做假定的數學模型，進行手工計算，並推導出一些由這些模型所得結果的性質，模型驅動就是讓資料去貼合某個模型，拿出一組資料來，對比更適合哪個模型。資料驅動是目前比較火的研究...