當前位置:首頁 » 數據倉庫 » 資料庫中的四大組件
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

資料庫中的四大組件

發布時間: 2022-12-30 18:36:49

A. android四大組件的作用是什麼

Android 開發的四大組件分別是:活動(activity),用於表現功能;服務(service),後台運行服務,不提供界面呈現;廣播接受者(Broadcast Receive),勇於接收廣播;內容提供者(Content Provider),支持多個應用中存儲和讀取數據,相當於資料庫

  1. 活動

Android中,activity是所有程序的根本,所有程序的流程都運行在activity之中,activity可以算是開發者遇到的最頻繁,也是android當中最基本的模塊之一。在android的程序中,activity一般代表手機屏幕的一屏。如果把手機比作一個瀏覽器,那麼activity就相當於一個網頁。在activity當中可以添加一些Button、Checkbox等控制項,可以看到activity概念和網頁的概念相當類似。

一般一個android應用是由多個activity組成的,這多個activity之間可以進行相互跳轉。例如,按下一個Button按鈕後,可能會跳轉到其他的activity,與網頁跳轉稍微有點不一樣的是,activity之間的跳轉有可能返回值。例如,從activity A跳轉到activity B,那麼當activity B運行結束時,有可能會給activity A一個返回值。這樣做在很多時候是相當方便的。

當打開一個新的屏幕時,之前一個屏幕會被置為暫停狀態,並且壓入歷史堆棧中。用戶可以通過回退操作返回到以前打開過的屏幕。可以選擇性的一處一些沒有必要保留的屏幕,因為Android會把每個應用的開始到當前的每個屏幕保存在堆棧中。

Android 開發的四大組件分別是:活動(activity),用於表現功能;服務(service),後台運行服務,不提供界面呈現;廣播接受者(Broadcast Receive),勇於接收廣播;內容提供者(Content Provider),支持多個應用中存儲和讀取數據,相當於資料庫。

2.服務

Service是android系統中的一種組件,跟activity的級別差不多,但是他不能自己運行,只能後台運行,並且可以和其他組件進行交互。Service是沒有界面長生命周期的代碼。Service是一種程序,可以運行很長時間的,但是卻沒有用戶界面。這么說有點枯燥,來看個例子。打開一個音樂播放器的程序,這時如果想上網,那麼打開Android瀏覽器,這時雖然已經進入瀏覽器這個程序,但是歌曲播放並沒有停止,而是在後台繼續一首接一首的播放,其實這個播放就是由播放音樂的Service進行控制。當然這個播放音樂的Service也可以停止。例如,當播放列表裡的歌曲都結束,或用戶按下了停止音樂播放的快捷鍵等。Service可以在很多場合的應用中使用,如播放多媒體時用戶啟動了其他Activity,這時程序要在後台繼續播放,比如檢測SD卡上文件的變化,或在後台記錄地理信息位置的改變等,而服務卻藏在後台。

開啟Service有兩種方式:

(1)Context.starService():Service會經歷onCreat ——>onStar(如果Service還沒有運行,則Android先調用onCreat(),然後調用onStar(),所以一個Service的onStar方能會重復調用多次);如果是調用者自己直接退出而沒有調用StopService,服務會一直在後台運行。該服務的調用者再啟動起來後可以通過stopService關閉服務。注意,多次調用Context.starService()不會被嵌套(即使會有相應的onStar()方法被調用),所以無論同一個服務被啟動多少次,一旦調用Context.stopService()或者StopSelf(),都會被停止。

說明:傳遞給starService()的Intent對象會傳遞給onStar()方法。調用順序為onCreat——onStar(可調用多次)——onDestroy.

(2)Context.bindService():服務會經歷onCreate()——onBind(),onBind將返回給客戶端一個IBind介面實例,IBind允許客戶端回調服務的方法,比如得到服務運行的狀態或其他操作。這個時候把調用者(Context,如Activity)會和服務綁定在一起,Context退出了,服務就會調用onUnbind——onDestroy相應退出,所謂綁定在一起就是「共存亡」了。

3.廣播接收器

在Android中,廣播是一種廣泛運用的在應用程序之間傳輸信息的機制。而廣播接收器是對發送出來的廣播進行過濾接受並響應的一類組件。可以使用廣播接收器來讓應用對一個外部時間做出響應。例如,當電話呼入這個外部事件到來時,可以利用廣播接收器進行處理。當下載一個程序成功完成時,仍然可以利用廣播接收器進行處理。廣播接收器不NotificationManager來通知用戶這些事情發生了。廣播接收器既可以在AndroidManifest.xml中注冊,也可以在運行時的代碼中使用Context.registerReceive()進行注冊。只要是注冊了,當事件來臨時,即使程序沒有啟動,系統也在需要的時候啟動程序。各種應用還可以通過使用Context.sendBroadcast()將它們自己的Intent廣播給其他應用程序。

4.內容提供者

內容提供者(Content Provider)是Android提供的第三方應用數據的訪問方案。

在Android中,對數據的保護是很嚴密的,除了放在SD卡中的數據,一個應用所持有的資料庫、文件等內容,都是不允許其他直接訪問的。Android當然不會真的把每一個應用都做成一座「孤島」,它為所有應用都准備可一扇窗,這就是Content Provider。應用想對外提供的數據,可以通過派生Content Provider類,封裝成一枚Content Provider。每個Content Provider都用一個uri作為獨立的標識,形如:content://com.xxxxx。所有應用看著像REST的樣子,但實際上它比REST更為靈活。和REST類似,uri也可以有兩種類型,一種是帶id的;另一種是列表的,但實現者不需要按照這個模式來做,給id的uri也可以返回列表類型的數據。

B. 四大開源資料庫是哪些

如果打算為項目選擇一款免費、開源的資料庫,那麼你可能會在MySQL與PostgreSQL之間猶豫不定。MySQL與PostgreSQL都是免
費、開源、強大、且功能豐富的資料庫。你主要的問題可能是:哪一個才是最好的開源資料庫,MySQL還是PostgreSQL呢?該選擇哪一個開源資料庫
呢?

在選擇資料庫時,你所做的是個長期的決策,因為後面如果再改變決定將是非常困難且代價高昂的。你希望一開始就選擇正確。兩個流行
的開源資料庫MySQL與PostgreSQL常常成為最後要選擇的產品。對這兩個開源資料庫的高層次概覽將會有助於你選擇最適合自己需要的。

MySQL

MySQL相對來說比較年輕,首度出現在1994年。它聲稱自己是最流行的開源資料庫。MySQL就是LAMP(用於Web開發的軟體包,包括
Linux、Apache及Perl/PHP/Python)中的M。構建在LAMP棧之上的大多數應用都會使用MySQL,包括那些知名的應用,如
WordPress、Drupal、Zend及phpBB等。

一開始,MySQL的設計目標是成為一個快速的Web伺服器後端,使用
快速的索引序列訪問方法(ISAM),不支持ACID。經過早期快速的發展之後,MySQL開始支持更多的存儲引擎,並通過InnoDB引擎實現了
ACID。MySQL還支持其他存儲引擎,提供了臨時表的功能(使用MEMORY存儲引擎),通過MyISAM引擎實現了高速讀的資料庫,此外還有其他的
核心存儲引擎與第三方引擎。

MySQL的文檔非常豐富,有很多質量不錯的免費參考手冊、圖書與在線文檔,還有來自於Oracle和第三方廠商的培訓與支持。

MySQL近幾年經歷了所有權的變更和一些頗具戲劇性的事件。它最初是由MySQL
AB開發的,然後在2008年以10億美金的價格賣給了Sun公司,Sun公司又在2010年被Oracle收購。Oracle支持MySQL的多個版
本:Standard、Enterprise、Classic、Cluster、Embedded與Community。其中有一些是免費下載的,另外一
些則是收費的。其核心代碼基於GPL許可,對於那些不想使用GPL許可的開發者與廠商來說還有商業許可可供使用。

現在,基於最初的
MySQL代碼還有更多的資料庫可供選擇,因為幾個核心的MySQL開發者已經發布了MySQL分支。最初的MySQL創建者之一Michael
"Monty"
Widenius貌似後悔將MySQL賣給了Sun公司,於是又開發了他自己的MySQL分支MariaDB,它是免費的,基於GPL許可。知名的
MySQL開發者Brian Aker所創建的分支Drizzle對其進行了大量的改寫,特別針對多CPU、雲、網路應用與高並發進行了優化。

PostgreSQL

PostgreSQL標榜自己是世界上最先進的開源資料庫。PostgreSQL的一些粉絲說它能與Oracle相媲美,而且沒有那麼昂貴的價格和傲慢的客服。它擁有很長的歷史,最初是1985年在加利福尼亞大學伯克利分校開發的,作為Ingres資料庫的後繼。

PostgreSQL是完全由社區驅動的開源項目,由全世界超過1000名貢獻者所維護。它提供了單個完整功能的版本,而不像MySQL那樣提供了多個
不同的社區版、商業版與企業版。PostgreSQL基於自由的BSD/MIT許可,組織可以使用、復制、修改和重新分發代碼,只需要提供一個版權聲明即
可。

可靠性是PostgreSQL的最高優先順序。它以堅如磐石的品質和良好的工程化而聞名,支持高事務、任務關鍵型應用。
PostgreSQL的文檔非常精良,提供了大量免費的在線手冊,還針對舊版本提供了歸檔的參考手冊。PostgreSQL的社區支持是非常棒的,還有來
自於獨立廠商的商業支持。

數據一致性與完整性也是PostgreSQL的高優先順序特性。PostgreSQL是完全支持ACID特性
的,它對於資料庫訪問提供了強大的安全性保證,充分利用了企業安全工具,如Kerberos與OpenSSL等。你可以定義自己的檢查,根據自己的業務規
則確保數據質量。在眾多的管理特性中,point-in-time
recovery(PITR)是非常棒的特性,這是個靈活的高可用特性,提供了諸如針對失敗恢復創建熱備份以及快照與恢復的能力。但這並不是
PostgreSQL的全部,項目還提供了幾個方法來管理PostgreSQL以實現高可用、負載均衡與復制等,這樣你就可以使用適合自己特定需求的功能
了。

C. 請問Android中4大組件有哪些他們的作用是什麼

Activity
官方解釋:Activity是Android程序與用戶交互的窗口,是Android構造塊中最基本的一種,它主要為保持各界面的狀態做很多持久化的事情,妥善管理生命周期以及一些跳轉邏輯。

解釋說明:我們也可以簡單的理解為當前的操作界面。

Service
官方解釋:Service後台服務於Activity,封裝有一個完整的功能邏輯實現,接受上層指令,完成相關的事務,定義好需要接受的Intent提供同步和非同步的介面。

解釋說明:例如當我們打開音樂播放器後我們想讓該音樂播放器至於後台運行。這時我們就可以啟動服務來實現。

ContentProvider
官方解釋:ContentProvider是Android中提供的第三方應用數據的訪問方案,可以派生ContentProvider類,對外提供數據,可以像資料庫一樣進行選擇排序,屏蔽內部存儲的存儲細節,向外提供統一的數據介面模型,大大簡化上層應用對數據的整合提供了更方便的途徑。
解釋說明:我們可以簡單的理解為在我們的應用程序中我們在一塊區域定製了一些規則來存儲應用程序的相關信息。如果第三方應用程序想要訪問到我們應用程序中的信息就需要滿足我們定製的規則來進行獲取。

BroadcastReceiver
官方解釋:BroadcastReceiver接受一種或者多種Intent作觸發事件,接受相關消息,做一些簡單處理,轉換成一條Notification,統一了Android的事件廣播機制。

解釋說明:這個機制可以理解為電視廣播,我們通過廣播發送一個節目。人們可以通過收音機調到對應的頻率來進行接受廣播而獲取相應的信息。我們的應用程序可以通過廣播發送信息,也可以通過一定的條件篩選來獲取到被人發送的廣播信息。而且廣播的作用范圍不局限於本應用程序內進行信息傳遞。
可以在秒秒學上看看Android的課程,講解的可以,希望對你有幫助。

D. 管理信息系統的基本結構可以概括為四大部件,即信息源、 、 、和 。

管理信息系統的基本結構概括為四大部件:
信息源
信息處理器
信息用戶
信息管理者

E. 請android四大組件是什麼android常見合布局有哪些

Android有四大組件:Activity、Service、Broadcast Receiver、Content Provider

在這些組件之間的通訊中,主要是由Intent協助完成的。
Intent負責對應用中一次操作的動作、動作涉及數據、附加數據進行描述,Android則根據此Intent的描述,負責找到對應的組件,將 Intent傳遞給調用的組件,並完成組件的調用。
因此,Intent在這里起著一個媒體中介的作用,專門提供組件互相調用的相關信息,實現調用者與被調用者之間的解耦。
例如,在一個聯系人維護的應用中,當我們在一個聯系人列表屏幕(假設對應的Activity為listActivity)上,點擊某個聯系人後,希望能夠跳出此聯系人的詳細信息屏幕(假設對應的Activity為detailActivity)
為了實現這個目的,listActivity需要構造一個 Intent,這個Intent用於告訴系統,我們要做「查看」動作,此動作對應的查看對象是「某聯系人」,然後調用startActivity (Intent intent),
將構造的Intent傳入,系統會根據此Intent中的描述,到ManiFest中找到滿足此Intent要求的Activity,系統會調用找到的 Activity,即為detailActivity,最終傳入Intent,detailActivity則會根據此Intent中的描述,執行相應的操作。

如果您認可我的答案,請點擊下面的「選為滿意回答」按鈕,謝謝!

F. android四大組件是什麼

Android四大組件有:活動、服務、內容、提供廣播接收器。活動應用程序是顯示層,每一個畫面對應於你的應用程序服務,服務應用程序中不可見的工人,而內容是指提供共享的數據儲存,用來管理和共享應用程序的資料庫,廣播接收器是指廣播

G. Android四大組件是什麼講講你對它們的理解

Android有四大組件:Activity、Service、Broadcast Receiver、Content Provider。

Activity

做一個完整的Android程序,不想用到Activity,真的是比較困難的一件事情,除非是想做綠葉想瘋了。因為Activity是Android程序與用戶交互的窗口,在我看來,從這個層面的視角來看,Android的Activity特像網站的頁面。

Activity,在四大組件中,無疑是最復雜的,這年頭,一樣東西和界面掛上了勾,都簡化不了,想一想,獨立做一個應用有多少時間淪落在了界面上,就能琢磨清楚了。從視覺效果來看,一個Activity占據當前的窗口,響應所有窗口事件,具備有控制項,菜單等界面元素。從內部邏輯來看,Activity需要為了保持各個界面狀態,需要做很多持久化的事情,還需要妥善管理生命周期,和一些轉跳邏輯。對於開發者而言,就需要派生一個Activity的子類,然後埋頭苦幹上述事情。對於Activity的更多細節,先可以參見:reference/android/app/Activity.html。後續,會獻上更為詳盡的剖析。

Service

服務,從最直白的視角來看,就是剝離了界面的Activity,它們在很多Android的概念方面比較接近,都是封裝有一個完整的功能邏輯實現,只不過Service不拋頭露臉,只是默默無聲的做堅實的後盾。

但其實,換個角度來看,Android中的服務,和我們通常說的Windows服務,Web的後台服務又有一些相近,它們通常都是後台長時間運行,接受上層指令,完成相關事務的模塊。用運行模式來看,Activity是跳,從一個跳到一個,呃...,這有點像模態對話框(或者還像web頁面好了...),給一個輸入(抑或沒有...),然後不管不顧的讓它運行,離開時返回輸出(同抑或沒有...)。

而Service不是,它是等,等著上層連接上它,然後產生一段持久而纏綿的通信,這就像一個用了Ajax頁面,看著沒啥變化,偷偷摸摸的和Service不知眉來眼去多少回了。

但和一般的Service還是有所不同,Android的Service和所有四大組件一樣,其進程模型都是可以配置的,調用方和發布方都可以有權利來選擇是把這個組件運行在同一個進程下,還是不同的進程下。這句話,可以拿把指甲刀刻進腦海中去,它凸顯了Android的運行特徵。如果一個 Service,是有期望運行在於調用方不同進程的時候,就需要利用Android提供的RPC機制,為其部署一套進程間通信的策略。

Android的RPC實現,如上圖所示(好吧,也是從SDK中拿來主義的...),無甚稀奇,基於代理模式的一個實現,在調用端和服務端都去生成一個代理類,做一些序列化和反序列化的事情,使得調用端和伺服器端都可以像調用一個本地介面一樣使用RPC介面。

Android中用來做數據序列化的類是Parcel,參見:/reference/android/os/Parcel.html,封裝了序列化的細節,向外提供了足夠對象化的訪問介面,Android號稱實現非常高效。

還有就是AIDL (Android Interface Definition Language) ,一種介面定義的語言,服務的RPC介面,可以用AIDL來描述,這樣,ADT就可以幫助你自動生成一整套的代理模式需要用到的類,都是想起來很乏力寫起來很苦力的那種。更多內容,可以再看看:guide/developing/tools/aidl.html,如果有興致,可以找些其他PRC實現的資料lou幾眼。

關於Service的實現,還強推參看API Demos這個Sample裡面的RemoteService實現。它完整的展示了實現一個Service需要做的事情:那就是定義好需要接受的Intent,提供同步或非同步的介面,在上層綁定了它後,通過這些介面(很多時候都是RPC的...)進行通信。在RPC介面中使用的數據、回調介面對象,如果不是標準的系統實現(系統可序列化的),則需要自定義aidl,所有一切,在這個Sample里都有表達,強薦。

Service從實現角度看,最特別的就是這些RPC的實現了,其他內容,都會接近於Activity的一些實現,也許不再會詳述了。

Broadcast Receiver

在實際應用中,我們常需要等,等待系統抑或其他應用發出一道指令,為自己的應用擦亮明燈指明方向。而這種等待,在很多的平台上,都會需要付出不小的代價。

比如,在Symbian中,你要等待一個來電消息,顯示歸屬地之類的,必須讓自己的應用忍辱負重偷偷摸摸的開機啟動,消隱圖標隱藏任務項,潛伏在後台,監控著相關事件,等待轉瞬即逝的出手機會。這是一件很發指的事情,不但白白耗費了系統資源,還留了個流氓軟體的罵名,這真是賣力不討好的正面典型。

在Android中,充分考慮了廣泛的這類需求,於是就有了Broadcast Receiver這樣的一個組件。每個Broadcast Receiver都可以接收一種或若干種Intent作為觸發事件(有不知道Intent的么,後面會知道了...),當發生這樣事件的時候,系統會負責喚醒或傳遞消息到該Broadcast Receiver,任其處置。在此之前和這以後,Broadcast Receiver是否在運行都變得不重要了,及其綠色環保。

這個實現機制,顯然是基於一種注冊方式的,Broadcast Receiver將其特徵描述並注冊在系統中,根據注冊時機,可以分為兩類,被我冠名為冷熱插拔。所謂冷插拔,就是Broadcast Receiver的相關信息寫在配置文件中(求配置文件詳情?稍安,後續奉上...),系統會負責在相關事件發生的時候及時通知到該Broadcast Receiver,這種模式適合於這樣的場景。某事件方式 -> 通知Broadcast -> 啟動相關處理應用。比如,監聽來電、郵件、簡訊之類的,都隸屬於這種模式。而熱插拔,顧名思義,插拔這樣的事情,都是由應用自己來處理的,通常是在 OnResume事件中通過registerReceiver進行注冊,在OnPause等事件中反注冊,通過這種方式使其能夠在運行期間保持對相關事件的關注。比如,一款優秀的詞典軟體(比如,有道詞典...),可能會有在運行期間關注網路狀況變化的需求,使其可以在有廉價網路的時候優先使用網路查詢詞彙,在其他情況下,首先通過本地詞庫來查詞,從而兼顧腰包和體驗,一舉兩得一石二鳥一箭雙雕(注,真實在有道詞典中有這樣的能力,但不是通過 Broadcast Receiver實現的,僅以為例...)。而這樣的監聽,只需要在其工作狀態下保持就好,不運行的時候,管你是天大的網路變化,與我何干。其模式可以歸結為:啟動應用 -> 監聽事件 -> 發生時進行處理。

除了接受消息的一方有多種模式,發送者也有很重要的選擇權。通常,發送這有兩類,一個就是系統本身,我們稱之為系統Broadcast消息,在reference/android/content/Intent.html 的Standard Broadcast Actions,可以求到相關消息的詳情。除了系統,自定義的應用可以放出Broadcast消息,通過的介面可以是 Context.sendBroadcast,抑或是Context.sendOrderedBroadcast。前者發出的稱為Normal broadcast,所有關注該消息的Receiver,都有機會獲得並進行處理;後者放出的稱作Ordered broadcasts,顧名思義,接受者需要按資排輩,排在後面的只能吃前面吃剩下的,前面的心情不好私吞了,後面的只能喝西北風了。

當Broadcast Receiver接收到相關的消息,它們通常做一些簡單的處理,然後轉化稱為一條Notification,一次振鈴,一次震動,抑或是啟動一個 Activity進行進一步的交互和處理。所以,雖然Broadcast整個邏輯不復雜,卻是足夠有用和好用,它統一了Android的事件廣播模型,讓很多平台都相形見絀了。更多Broadcast Receiver相關內容,參見:/reference/android/content/BroadcastReceiver.html。

Content Provider

Content Provider,聽著就和數據相關,沒錯,這就是Android提供的第三方應用數據的訪問方案。在Android中,對數據的保護是很嚴密的,除了放在SD卡中的數據,一個應用所持有的資料庫、文件、等等內容,都是不允許其他直接訪問的,但有時候,溝通是必要的,不僅對第三方很重要,對應用自己也很重要。

比如,一個聯系人管理的應用。如果不允許第三方的應用對其聯系人資料庫進行增刪該查,整個應用就失去了可擴展力,必將被其他應用拋棄,然後另立門戶,自個玩自個的去了。

Andorid當然不會真的把每個應用都做成一座孤島,它為所有應用都准備了一扇窗,這就是Content Provider。應用想對外提供的數據,可以通過派生ContentProvider類, 封裝成一枚Content Provider,每個Content Provider都用一個uri作為獨立的標識,形如:content://com.xxxxx。所有東西看著像REST的樣子,但實際上,它比REST 更為靈活。和REST類似,uri也可以有兩種類型,一種是帶id的,另一種是列

表的,但實現者不需要按照這個模式來做,給你id的uri你也可以返回列表類型的數據,只要調用者明白,就無妨,不用苛求所謂的REST。

另外,Content Provider不和REST一樣只有uri可用,還可以接受Projection,Selection,OrderBy等參數,這樣,就可以像資料庫那樣進行投影,選擇和排序。查詢到的結果,以Cursor(參見:reference/android/database/Cursor.html )的形式進行返回,調用者可以移動Cursor來訪問各列的數據。

Content Provider屏蔽了內部數據的存儲細節,向外提供了上述統一的介面模型,這樣的抽象層次,大大簡化了上層應用的書寫,也對數據的整合提供了更方便的途徑。Content Provider內部,常用資料庫來實現,Android提供了強大的Sqlite支持,但很多時候,你也可以封裝文件或其他混合的數據。

在Android中,ContentResolver是用來發起Content Provider的定位和訪問的。不過它僅提供了同步訪問的Content Provider的介面。但通常,Content Provider需要訪問的可能是資料庫等大數據源,效率上不足夠快,會導致調用線程的擁塞。因此Android提供了一個AsyncQueryHandler(參見:reference/android/content/AsyncQueryHandler.html),幫助進行非同步訪問Content Provider。

在各大組件中,Service和Content Provider都是那種需要持續訪問的。Service如果是一個耗時的場景,往往會提供非同步訪問的介面,而Content Provider不論效率如何,都提供的是約定的同步訪問介面。我想這遵循的就是場景導向設計的原則,因為Content Provider僅是提供數據訪問的,它不能確信具體的使用場景如何,會怎樣使用它的數據;而相比之下,Service包含的邏輯更復雜更完整,可以抉擇大部分時候使用某介面的場景,從而確定最貼切的介面是同步還是非同步,簡化了上層調用的邏輯。

H. 醫學信息管理的醫學信息管理系統組成部件:

醫學信息管理系統,包括多個用於存儲醫學信息於資料庫中的資料庫設備;用於整體地管理醫學信息的管理設備和用於操作至少一個資料庫設備和管理設備的操作終端,該資料庫設備具有用於從存儲的醫學信息中提取所需信息並發送所需信息至管理設備的自動傳輸部分。該管理設備包括用於接收從自動傳輸部分發送的醫學信息的接收部分;用於基於包括在醫學信息中的預定的信息整體地存儲接收部分接收的醫學信息的存儲部分;用於驗證是否操作終端的操作員事先注冊的個人的個人驗證部分;和用於判斷是否被指示由操作終端操作的醫學信息是能夠被操作的信息的數據存取鑒定部分。
信息管理系統由四大部件組成,即(信息源)、(信息處理器)、(信息用戶)和(信息管理者)。
醫學信息管理系統,包括:
1,多個資料庫設備,用於存儲醫學信息於資料庫中;
2,管理設備,用於整體地管理所述醫學信息;
3,操作終端,用於操作所述資料庫設備和管理設備中的至少一個,
4,自動傳輸部分,用於從存儲在所述資料庫中的醫學信息中提取所需的信息並將該所需的醫學信息發送至管理設備,
5,接收部分,用於接收從自動傳輸部分發送的醫學信息;
6,存儲部分,用於基於包括在所述醫學信息中的預定的信息整體地存儲由所述接收部分接收的醫學信息;
7,個人驗證部分,用於驗證是否操作終端的操作員是事先注冊的個人;
8,數據存取鑒定部分,用於判斷是否被指示由所述操作終端操作的醫學信息是能夠被操作的信息。

I. 什麼是android的四大組件

Android四大組件有Activity,Service服務,Content Provider內容提供,BroadcastReceiver廣播接收器。

Android應用程序由一些零散的有聯系的組件組成,通過一個工程manifest綁定在一起。在manifest中,描述了每一個組件以及組件的作用,其中有6個組件,它們是Android應用程序的基石

(9)資料庫中的四大組件擴展閱讀

Activities(活動)

應用程序的顯示層。每一個畫面對應於你的應用程序,將會是Activity類的擴展。Activity使用Views去構建UI來顯示信息和響應用戶的行為。就桌面開發而言,一個Activity相當於一張Form。

Services(服務)

Android應用程序中不可見的「工人」。 Service組件運行時不可見,但它負責更新的數據源和可見的Activity,以及觸發通知。它們常用來執行一些需要持續運行的處理,當你的 Activity已經不處於激活狀態或不可見。

Content(內容)

提供共享的數據存儲。Content Provider(內容提供器)用來管理和共享應用程序的資料庫。在應用程序間,Content Provider是共享數據的首選方式。

Broadcast Receivers(廣播接收器)

Intent廣播的「消費者」。通過創建和注冊一個Broadcast Receiver,應用程序可以監聽符合特定條件的廣播的Intent。Broadcast Receiver 會自動的啟動你的Android應用程序去響應新來的Intent。Broadcast Receiver是事件驅動程序的理想手段。

參考資料來源:網路-Android組件

J. Android為什麼要設計4大組件,他們之間的聯系,不設計行不行

二,view的刷新,之前說過 三,IPC及原理 四,Android多線程 五,Android為什麼要設計4大組件,他們之間的聯系,不設計行不行(主要是為了實現MVC模式,然而java中最難的模式也是這個,很少有產品能將這個模式做得很好【Technicolor的 面試官問的這個】)六,service的周期,activity的周期,談下你對Android內部應用的了解,比如他做電話,以及聯系人等等應用。框架層有很多東西還是多看看,熟悉Android怎麼做的,不管你做應用程開發還是應用框架層開發很有好處的。 在就是你項目經驗,突出你遇到什麼難點,然後是怎麼解決的!盡量將每個技術點凸顯出來,當然 面試官有時候會為了體現你是否真正做過,他會問你,你在這個應用中做那個模塊,用了多少個類之類的問題。 偶爾有的 面試官會問你,你用過Android自帶的單元測試了沒,怎麼用的? 當然我 面試過很多家單位,有的是做平板,手機,數字電視,有的是做出個erp之類的客戶端等等,出於前面的三個,基本上都是將Android的全部改掉,如果真正要做Android的話,大家要學的還很多。 總之,一句話,什麼樣的 面試官都有,去 面試的時候要做好一切心理准備,不管是技術還是基礎都得扎實。一個人的交談能力也很重要,總之不是非常標準的普通話,最起碼你說的得讓別人聽得懂,而且得把 面試官講得非常徹底,這樣你獲得offer的機會更大,談工資也有優勢~~當然曾經一家公司的 面試官跟我說過,技術是不惜錢的,只要你有能力,多少錢他都請。 確實,來北京求職期間,牛人真的很多,而且有的 面試官也非常好,給了很多忠肯的意見。並不是每個 面試官都特想為難你的~最主要的還是想知道你的技術,因為他們也是吃公司飯,得為這個負責。 1.View如何刷新? 2.DDMS與TraceView的區別? 3.activity被回收了怎麼辦? 4.在Java中如何引入C語言? 答案 1.View 可以調用invalidate()和postInvalidate()這兩個方法刷新 2.DDMS是一個程序執行查看器,在裡面你可以看見線程和堆棧等信息,TraceView是程序性能分析器 3.activity回收了,那就只有另起了 4.java調用C語言程序,可以用JNI介面來實現 上面答案僅作參考,畢竟我個人能力也有限嘛,難免會回答錯誤,呵呵..... 解答: 1.View受系統刷新(系統內部有個循環,監控事件、做業務處理、繪UI),可以用postInvalidate()促使系統刷新。 2.(還真不知道) 3.請參照Activity生命周期,如果被系統destroy了,也就是說的回收,只有從新start了 4.通過JNI調用。