SQL指令:找出TABLE內是否存在(欄位相同)重複的資料

一般:

select * from table where name in (select name from

table group by name having count(*)>1)

SQL指令:找出TABLE內是否存在(欄位相同)重複的資料

一般:

select * from table where name in (select name from

table group by name having count(*)>1)

【健康新知】多喝水不如多喝茶

西方人往往以為喝茶會造成脫水，但《歐洲臨床營養學報》刊登的一份研究報告說，喝茶和喝水一樣能補充人體水分，而且對人體健康還有額外的好處，包括預防心臟病和某些癌症等。因此就效益來說，喝茶比喝水更健康。

這項研究由英國倫敦大學「國王學院」的公衛營養專家拉克思頓女士主持，她與同事深入探討之後斷言，茶能促進健康的關鍵成份是類黃酮（flavonoids），這是一種有助於防止細胞受損的多酚抗氧化物，存在於許多植物之中，包括茶葉。

【健康新知】夏天猛喝茶、咖啡要小心！　累積過多草酸鹽易致泌尿結石

【健康新知】多喝水不如多喝茶

西方人往往以為喝茶會造成脫水，但《歐洲臨床營養學報》刊登的一份研究報告說，喝茶和喝水一樣能補充人體水分，而且對人體健康還有額外的好處，包括預防心臟病和某些癌症等。因此就效益來說，喝茶比喝水更健康。

這項研究由英國倫敦大學「國王學院」的公衛營養專家拉克思頓女士主持，她與同事深入探討之後斷言，茶能促進健康的關鍵成份是類黃酮（flavonoids），這是一種有助於防止細胞受損的多酚抗氧化物，存在於許多植物之中，包括茶葉。

【健康新知】夏天猛喝茶、咖啡要小心！　累積過多草酸鹽易致泌尿結石

	1.H1N1新型流感危險徵狀為何? 大部分感染H1N1新型流感者，症狀多為輕微，且一週內會痊癒，即使不需特殊特殊治療亦可康復，故大多數人可以在家裡休養。 惟仍有極少數人感染後病情迅速轉為重症，所以臨床醫生、病患及家庭照護者應對病情轉換之危險徵兆提高警覺，以及早就醫積極治療，避免轉為重症。危險徵兆如下：呼吸急促、呼吸困難、嘴唇發紫或變藍、血痰、胸痛、意識不清、高燒3天、低血壓。 兒童危險徵兆包括呼吸急促或困難、嗜睡、精神不濟及玩耍意願降低等，亦應特別注意。

即日起提供流感快速篩檢服務之公費流感抗病毒藥劑配置點

製表日期：98/8/7

流水號 縣市 機構名稱

	1.H1N1新型流感危險徵狀為何? 大部分感染H1N1新型流感者，症狀多為輕微，且一週內會痊癒，即使不需特殊特殊治療亦可康復，故大多數人可以在家裡休養。 惟仍有極少數人感染後病情迅速轉為重症，所以臨床醫生、病患及家庭照護者應對病情轉換之危險徵兆提高警覺，以及早就醫積極治療，避免轉為重症。危險徵兆如下：呼吸急促、呼吸困難、嘴唇發紫或變藍、血痰、胸痛、意識不清、高燒3天、低血壓。 兒童危險徵兆包括呼吸急促或困難、嗜睡、精神不濟及玩耍意願降低等，亦應特別注意。

即日起提供流感快速篩檢服務之公費流感抗病毒藥劑配置點

製表日期：98/8/7

流水號 縣市 機構名稱

:::

CMMI的效益

CMMI的產業競爭意義 1. CMMI的效益 (1) 依據SEI的分析報告，導入CMMI廠商的平均效益為 A. 生產力提高35% B. 產品上市時間縮短19% C. 產品發行後缺失率減少39% D. 節省成本對投入軟體流程改善成本比例為5：1 (2) 以大陸摩托羅拉北京研發中心為例，自1993年開始經過7年的軟體工程探索與實踐，通過了CMM 5級評鑑。1997年到2000年的3年間： A. 每人平均生產力提高6倍

目前在所有產業中，除了軟體公司已著手導入CMMI外，其實也有許多硬體OEM、ODM 業者也紛紛導入，大部分的原因是因為客戶的要求，希望能夠確保產品的發展過程，是被有效率的管理，因此已陸續導入。

整體來說，導入CMMI有以下幾點益處：

1.提高生產率 2.降低錯誤率 3.縮短開發時間 4.提高對專案的控管能力，且適用於各種有軟體或系統開發維護作業的組織

這也是國際間許多重要的非委包專案單位，如微軟、花旗銀行等單位都積極投入流程改善的原因，所以CMMI並非只適用於標案或軟體代工的公司。

根據SEI在成熟度報告對於產業類型的分類，主要為下列三種，並各自包含數種服務類型：

服務類：商業服務、工程與管理服務、醫療業與其它服務。 製造類：工業機械與設備、運輸設備、電子與其它電力設備、器械與相關產品。 其它類：零售、批發、公共行政(含國防)、財務、保險與地產業、運輸、通訊、電力、瓦斯與衛生。

這三種產業類型在SEI成熟度報告中的分析，以服務類為最多，共有98家（62%），其次是製造類，共有31家（20%），最後則是其它類，共有29家（18%）。進一步分析，服務類中是以工程與管理服務及商業服務為最多，製造類則是以器械與相關產品為最多，其它類是以公共行政（含國防）為最多。

何謂CMMI

1. CMMI技術概要 (1) CMM (Capability Maturity Model for software，軟體能力成熟度模式) 是美國國防部在1984年因當時該機構軟體標案委外承作時，無法評估軟體公司對軟體標案之承接及執行能力，故委託美國卡內基美隆大學 (Carnegie Mellon University) 的軟體工程學院 (Software Engineering Institute, SEI) 所進行的一項研究成果，試圖於軟體產業建立一套工程制度，使個人及組織在軟體發展上能有持續改善的依據，其目的是用來評估及改善軟體發展公司之軟體開發過程及軟體開發能力，並且協助軟體開發者持續改善軟體流程成熟架構及軟體品質，進而提昇軟體開發專案及軟體發展公司之軟體開發管理能力，達成軟體發展之功能正確、縮短開發時程、降低成本及確保品質等目標。 　　CMM目前已成為許多大型軟體業者於改善組織內部軟體工程所採行的軟體評估標準，CMM亦陸續應用系統工程及軟體採購方面，成為國際間認同且廣泛通用的一種軟體生產程序標準。其認證共分為五級(第一級：初始(Initial)、第二級：可重覆(Repeatable)、第三級：已定義(Defined)、第四級：已管理(Managed)、第五級：最佳化(Optimizing))。 　　由於CMM應用日漸廣泛，陸續發展出不同之CMM模式，包括：軟體能力成熟度 (Software Capability Maturity Model, SW-CMM) 、系統工程能力成熟度模式 (Systems Engineering Capability Maturity Model, SE-CMM) 、整合產品發展能力成熟度模式 (Integrated Product Development Capability Maturity Model, IPD-CMM) 、人力資源管理能力成熟度模式 (People Capability Maturity Model, P-CMM) 等應用模式；且SEI於2000年12月公佈能力成熟度整合模式 (Capability Maturity Model - Integrated, CMMI)，更進一步將能力成熟度模式整合，逐漸取代現行之CMM標準。   (2) CMMI (Capability Maturity Model - Integrated, CMMI) 是SEI繼CMM成功發展後的新修訂版本，目的在發展一個共通性之整合架構，以支援整合不同專業領域之特定能力成熟度模式及相關產品，並致力提供系統工程及軟體工程之指導原則，期許在任何架構下的組織，皆能促進其流程改善，CMMI不僅提高每一級別成熟度要求之門檻，亦同時擴充能力成熟度評鑑適用範圍，使得軟體工程、系統工程之專業領域及整合性產品與流程發展之環境，皆能運用CMMI為軟體開發流程提供持續改善的指引，對軟體生產力與品質的提升亦有顯著的實質效益，並確保所有發展的產品，能與國際標準組織／國際電技協會 (ISO／IEC) 15504軟體流程評鑑技術報告相容並一致。 　　其認證共分為五級 (以分段式表述而言)為第一級：初始(Initial)、第二級：已管理(Managed)、第三級：已定義(Defined)、第四級：數量化管理(Quantitatively Managed)、第五級：最佳化(Optimizing)。

2. 模式架構

流程是組織持續改善的掌控點。CMMI的目的是提供指導原則，產品(或服務)之發展、採購及維護改善組織的流程及改善管理的能力。CMMI將已認可的執行方法放在一個架構下，以幫助組織評鑑它的組織成熟度或流程領域能力，藉此建立改善的優先順序以落實改善。

組織可用CMMI模式，來設定流程改善的目標、優先順序、改善流程，並提供指導原則以確保穩定、適任及成熟的流程。CMMI能當作組織自我改善的指引。

在CMMI模式的兩種表述中，包含有流程領域、特定目標、特定執行方法、一般目標、一般執行方法、典型的工作產品、細部執行方法、註解、專業領域強化、一般執行方法詳細說明與參考資料。

(1) Maturity Levels 成熟度 　　組織成熟度提供在某些特定的專業領域下，預測組織未來績效表現的方法。經驗顯示，在組織改善的過程中，流程領域的複雜性會不斷增加，若組織能專注於一組可掌握的流程領域，將會有最佳的績效表現。 　　成熟度是經過定義的進階式流程改善的指標。每一成熟度是穩定組織流程的重要部分。每達成一級成熟度，即代表組織流程能力的增進。 　　共有由一到五個成熟度階段，每一階段成熟度都是下一階段流程改善的基礎： A. 成熟度第二級的流程領域 　包含如下： (A) 需求管理(Requirements Management)管理專案產品與產品組件之需求，並且界定專案計畫、工作產品與需求這兩者之間，是否有不一致的情形。 (B) 專案規劃(Project Planning)建立並維護定義專案活動的計畫。 (C) 專案監控(Project Monitoring and Control)提供對專案進度的瞭解，使得當專案績效明顯偏離原先計劃時，能採取適當的矯正措施。 (D) 供應商協議管理(Supplier Agreement Management)管理和專案有正式協議的供應商之產品與服務的採購。 (E) 度量與分析(Measurement and Analysis)發展並維護支援管理資訊所需的度量能力。

為什麼需要CMMI

自2003年SEI(Software Engineering Institute/SEI, Carnegie Mellon University/CMU)發表CMMI開始，全球每年導入家數幾乎以倍數成長，顯示CMMI確為國際證實有助於流程改善的模式，甚至認為CMMI已經為軟體的品質保證及國際合作的基本要求。 　　台灣軟體業者規模多屬中小型，CMMI以嚴謹、科學的方法有效提升流程管理能力，可以協助業者面對系統日趨複雜化、大型化的多元需求下，有效管理開發流程，並可藉CMMI認證與國際接軌。以印度通過CMMI認證廠商數與軟體出口成長率的正關聯性，預估台灣推動CMMI將有助於軟體業產值的提升。同時，以台灣優異的硬體設計與製造能力，加上對應的軟體在質與量上的提升，可提高產品附加價值，創造產業的新價值。 　　而導入CMMI有助於提昇流程改善與品質管控的能力，從環境建立、技術輔導、人才培訓、推廣宣導等分項計畫的實施，健全國內環境達到強化業者的體質；同時，透過已達一定數量的CMMI認證廠商數目發揮群聚效應，建立品質品牌，將使國際買主對台灣資訊服務業的技術與服務更具信心，打開產業的國際知名度。配合國內業者於特定領域的專業技術，結合產業上中下游的供應鏈，達到產業垂直分工與水平整合的綜效，提供全方位產品服務。國際化有賴於群策群力，整合國內業者行銷資源以拓展國際專案，有效將我國資訊服務業推向世界的舞台。

2008年是「雲端運算年」，經過一連串的洗禮與轟炸，大家現在對雲端運算（cloud computing）都有初步認識，但，你確定昨天聽到的「雲端運算」，和前天聽到的「雲端運算」，是在講同一件事情嗎？ ComputerWorld這周特地引用了知名分析公司Gartner提出的最新見解，Gartner認為，「雲端運算」這個字在當下被「熱情引用」得相當嚴重。報導還引用VMWare的技術長的話，指出「雲端運算可說是繼Virtualization以來，最被濫用的字眼！」 我覺得「濫用」是不至於，而是被太廣泛的用，哪裡都用，什麼都可以用，造成了「糊用」。當我們大家突然間都在談「雲端運算」(cloud computing)，企業爭著要把自己歸類成「雲端」，提供的服務是「雲端」，要客戶學「雲端」，Web 3.0也是「雲端」，大家都在雲端的時候，實情就愈來愈像高空空氣一樣的飄渺虛無。「糊用」沒關係，這樣一來反而讓一般的民眾，更能將此字琅琅上口，促使大家更快的作系統更換，更去使用網路上的資源，不也很棒？不過，若是對於真正想用「雲端運算」來做點事的企業IT部門，或是真正在為「雲端運算」在奮力研究的研究人員來說，如果大家口中講「雲端運算」，卻是在講完完全全不同的技術，那就變成雞同鴨講、牛頭不對馬嘴、青黃不接、是非不明、上氣不接下氣了。 所謂「雲端」這個字最初的正確起源，來自資工系學生畫網路示意圖，一定是拿一朵「雲」來簡而代表「Internet」這個裡面不知道有幾台電腦幾台路由器的複雜網路，化繁為簡。所以，所謂的「雲端運算」就是透過「互聯網」(Internet)來作運算，而它隱藏的另一涵意不是「天空」，而是「模糊化」，有一點點「丟給互聯網這個黑盒子，它就會不知怎麼動用好多電腦傳送加計算然後幫你準備好答案」的意思在。於是，許多IT很熟的人又常把雲端運算搞成是「Grid Computing」，這樣就太窄義了，看維基百科對雲端運算的定義，只要是「透過互聯網來計算」的都可以算是雲端運算，換句話說，最近大家流行談的「雲端運算」的話題，其實就是Distributed computing、SaaS、Web-based software、Data Center、Virtualization、甚至Web services等等的概念（與技術）的一個「概括詞」。我認為，它在行銷的意義上，遠大於技術上的意義；並不是說它不需要技術，而是這個字本身定義太廣，並不是在形容任何一個必要的技術。 由於目前對「雲端計算」的定義，涵蓋太多雜七雜八的技術，大家都搶著當「雲端」，所以，Gartner特別舉出「兩大陣營」，指出它們根本不應該被「一同視為雲端運算」，認為應該重新取名，分開視為完全不同的東西： 第一種雲端運算，叫「雲端服務」(cloud computing services)：有些網路服務，透過一個瀏覽器，透過互聯網來存取、來操作、來服務，譬如Salesforce.com的CRM工具，或是Amazon EC2的空間服務，這一類的「雲端運算」可視為Grid computing、SaaS的自然延伸，使用者完全不必去擔心成長的問題，遠端自然會幫你將該需要的伺服器或資料庫都準備好，使用者只要放心的把東西丟到網路上、丟往遠端的服務商即可。也充份善用了互聯網的便利性，讓使用者可以安全的將所有資料都存在遠端的一或多個伺服機裡，到哪裡都可以使用，服務商也可隨時作升級或更動，同時又巧妙的將龐大運算的問題丟給「雲端」解決，於是讓一隻單薄的手機或一個沒有運算能力的GPS也都可以上網幹很多奇奇怪怪的事，這一種雲端運算，主要是在形容一種新的「服務」方式。 第二種雲端運算，叫「雲端技術」(cloud computing technologies)：有些提到雲端運算的，其實是「data center」的下一代產品，內部系統採用多台電腦一同運算、儲存、相互備援，譬如可以將基因圖譜定序、DNA解碼等拆成好多來演算，又譬如Skype與BitTorrent以點對點(P2P)來共同組成單一系統，這個陣營其實才是正宗的distributed computing的「分身」，它技術牽扯到「雲端」的部份，遠比第一種雲端運算還要多，這種雲端運算主要是在形容一種新的「技術」。 Gartner說，不要吵、不要吵，以上兩者都是「雲端運算」，但是，幾乎是完全不同的「用意」。Gartner的建議是，在講「雲端運算」前，可能要先問自己，你所要講的這個「雲端運算」，可以說是某一個穿過密密麻麻幾億台電腦連線讓你使用的「服務」嗎？還是在講該服務後面的一個特殊的製作法，而這製作法是透過雲端內密密麻麻幾億台電腦內所構成的網路？ 像，CRM這種SaaS，假如它要說它是雲端運算，那它，顯然是在第一陣營，也就是「雲端服務」。 像Skype這種點對點的，假如它哪天也硬要說它是雲端運算，那它是在第二陣營，也就是「雲端技術」。 但是，像Google呢？ 目前它是「雲端運算」最新最熱情的擁護者，因為它有第一陣營與第二陣營的特質。Google透過MapReduce架構來將資料拆成小塊丟出去運算後再重組回來，以及BigTable完全跳脫一般資料庫資料以row設計儲存又完全的配合Google自己的GFS (Google File System)，幫助它穿過雲端的所有從request到response的所有環節，全部都是最佳化了，但，由於這一切的目的還是為了強化該公司所有的網站產品，讓使用者透過瀏覽器所使用的速度與感覺能變成最好，達到此點後，它就「夠用」了。所以，雖然也有許多、或許有扯到第二陣營的部份，但Google仍是偏向第一陣營。 換句話說，下次看到李開復博士再次提到雲端運算可以拿來算基因，或許可以以Gartner來建議他：「不要再講到那裡去了。」 從這邊開始，慢慢的不要當雲端運算只是一個空渺的字眼，或許可以，從「雲端」慢慢降落到「地面」，然後分頭依我們的需求，一一的探索雲端中的秘密。

技術論壇

淺談雲端運算 (Cloud Computing) 作者：黃重憲 / 臺灣大學電機資訊學院資訊工程系 「雲端運算」=「網路」=「網路運算」。「雲端運算」不是「新技術」或「技術」。「雲端運算」是一種概念，代表的是利用網路使電腦能夠彼此合作或使服務更無遠弗屆。在實現「概念」的過程中，產生出相應的「技術」。 隨著Google在去年初宣布於台灣啟動「「雲端運算」學術計畫」，「「雲端運算」」這個聽來帶點浪漫色彩的科技名詞立時席捲各大媒體版面。眾多網路公司以及「網格運算」服務都搶搭順風車，聲稱他們的服務也屬於「「雲端運算」」。但是，只怕很少人能夠聽明白他們口中的這朵「雲」代表著什麼玄機，以及它究竟要做什麼「運算」。 所謂「雲端」其實就是泛指「網路」，名稱來自工程師在繪製示意圖時，常以一朵雲來代表「網路」。因此，「「雲端運算」」用白話文講就是「網路運算」。舉凡運用網路溝通多台電腦的運算工作，或是透過網路連線取得由遠端主機提供的服務等，都可以算是一種「「雲端運算」」。 所以說，「雲端運算」其實不是新技術，更嚴格的說，甚至不能算是「技術」。「雲端運算」是一種概念，代表的是利用網路使電腦能夠彼此合作或使服務更無遠弗屆。而在實現「概念」的過程中，才會產生出相應的「技術」。 「雲端運算」的概念事實上也不算新，其本質大抵承襲自「分散式運算」(Distributed Computing)以及「「網格運算」」(Grid Computing)這兩位老前輩。在進一步窺探雲中的奧秘之前，先讓我們來認識其源頭。