Mobile Service 資料分類及資料庫存放位置

Mobile Service 是利用 Drupal 所開發出來的平台，Mobile Service 提供後台讓各單位人員可以註冊以及登入至系統發佈新聞等訊息，並且將這些訊息在前台顯示出來，除此之外也提供了校園單位簡介地理位置等資訊。

既然平台是利用 Drupal 所開發，所以要拉取資料庫的資料前，必須先來看一下各個資料存放於哪些資料表中。基本上與之前介紹的位置相似，可參考關於Drupal新增content時的資料表變動、Map 功能用到的 Drupal 資料 此兩篇介紹。


首先來看一下我對於 Mobile Service 所作的資料分類，目前的資料分類是依照新聞發佈、行事曆 以及部分地圖功能所做規劃。( 這裡為什麼說是部分的地圖功能，原因在於這部分只是存放發佈訊息及活動的位置，完整的地圖功能將包含了各類型單位、公車資訊等 )。

Type	Field	功能說明
building (建築物)
	name	建物名稱
	Floor	建物樓層
	introduction	建物簡介
	latitude	緯度
	longitude	精度
units (單位或院所)
	atBuilding	所在建物
	name	單位名稱
	atFloor	所在樓層
	introduction	單位簡介
	number	單位室碼
	phone	單位電話
	fax	單位傳真
	web	單位網址
	type	單位類型(學術、行政)
	hasGroup	是否有組別
group (組別或系所)	atBuilding	所在建物
	name	組別名稱
	atFloor	所在樓層
	atUnits	所在組別
	introduction	組別簡介
	number	組別室碼
	phone	組別電話
	fax	組別傳真
	web	組別網址
member (成員)
	atUnits	所屬單位或組別
	name	成員姓名
	title	職稱
	phone	成員電話(分機)
news (新聞)
	pUnits	發佈單位或組別
	pMember	發佈成員
	title	新聞標題
	content	新聞內容
	date	發佈日期
	time	發佈時間
	mediaUrl	多媒體檔連結位置
	mSource	多媒體檔來源
	mediaType	多媒體檔類型
events (事件 – 行事曆用)
	pMember	發佈人員
	pUnits	發佈單位或組別
	title	事件標題
	content	事件內容
	pDate	發佈日期
	pTime	發佈時間
	aDate	活動日期
	aTime	活動時間
	aPlace	活動地點
	alatitude	活動地點座標緯度
	alongitude	活動地點座標精度
	mediaUrl	多媒體檔連結位置
	mSource	多媒體檔來源
	mediaType	多媒體檔類型

此表為目前規畫在 Drupal 上的資料分類 (請注意這並非資料庫中實際的資料表或欄位 )，目的是為了新聞發佈及行事曆兩項功能，基本的功能都已經在表上有描述，此處將不再敘述，接下來將記錄實際在 Drupal 上的資料庫位置。

目前 Mobile Service 上共有 130 個資料表，同樣的這些資料表大多數是 Drupal 所必須使用；而此處因為有特別為了可以直接拉取資料庫而做分類與設計，所以在位置上較不會分散在各處。

常用到的資料表有 node, node_revisions, node_type, users, users_roles, role, permission, content_type_* 。

users, users_roles, role, permission 這四個資料表可以讓我們取得註冊者與系統權限及 uid 等關聯，並且在資料分類中設計了 member 的類型後，更可以利用 content_type_member.nid 來將各單位的人員與系統帳號做綁定的動作，如此一來，雖然發佈新聞或是其他訊息時系統看的是 uid 以及 系統權限 rid ，但是在前台或是其他自行由資料庫抓取資料的平台時，可以清楚顯示發佈者是哪個單位的成員，並且利用綁定的動作來做行動裝置上的權限控管，方便未來行動裝置上發佈功能的開發。

至於上面表中的各個 type 對應到資料庫中的資料表分別為 content_type_building, content_type_units, content_type_group, content_type_member, content_type_news, content_type_events。而這邊的設計概念十分簡單，由大至小，大的包含數個小的。

建築物 > 單位院所 > 組別系所 > 成員 > 新聞、行事曆

我們不管取得哪個部份的資訊，都可以經由 at* 或是 pMember 這兩個 field 取得更上面層級的資料，經由此步驟就可以一路的追尋回去，取得所在位置、樓層或是相關簡介等，如此也可以在地圖上標示此訊息的發佈位置；當活動資訊內無活動地點的經緯度時，也可以利用活動地點 aPlace 這個 field 來向上追朔取得地標。


和之前所使用的生活資訊平台相比較，經由這樣簡單的設計可以減少建構資料時必須輸入大量重複的資料，也讓使用者也就是訊息發佈者可以減少輸入的資料量，同時也兼顧了部分的關聯問題，以減少需要特定資料時多餘的運算步驟。


至於要如何利用 Drupal 所建立的資料庫，要求特定的資料這邊就不再贅述了，可以參考關於Drupal新增content時的資料表變動、Map 功能用到的 Drupal 資料以及配合此表的介紹就可以編寫出需要的 SQL 指令。

Read more »

Map 功能用到的 Drupal 資料

Map 功能是最先開發的部分，所以資料庫的部分是沿用一開始明宗與漢卿他們所建立的生活資訊平台，目前此平台的資料表共有121個，但實際上在拉需求的資料時，會使用到的資料表並不多，而且位置有固定的模式，這個部分請參考 關於Drupal新增content時的資料表變動

node_revisions :

• nid : 應該是 node id ，值通常與 vid 相同，經過一段時間觀察，大部分所需擷取的資料都可以使用 nid 當成唯一鍵。(此部分為觀察結果後的判斷，並沒有細看 drupal 的原碼)
  
• uid :此部分為 Drupal 的使用者 id ，如果需要使用者資料與 uid 的關聯，可以參考 users 資料表，至於身份的部分可以參考 users_roles 以及 role 此兩個資料表；users_roles 負責 uid 與 rid 的對應，role 資料表可查詢到 rid 所對應到的使用者權限身份；而實際上每個使用者權限身份可以執行的動作則位於 permission 資料表。
  
• title : 每個 PO 文的標題。因為整個系統的開發過程與一般先規畫資料庫再寫 AP 這樣的過程稍微不同。雖然在規畫時同樣需要定義出需求哪些資料，但是這邊所規畫出來的資料，未來會放在資料庫的哪個位置或是如何命名則是由 drupal 所決定；這裡所規畫出來的資料就是直接呈現於畫面上的資料。或許這樣解釋不是很清楚，這邊舉個例子，假設在平台上顯示了【系所 : 資訊工程學系】，那這個資訊工程學系的字串資料就是存在於 title 這個欄位，而資訊工程學系的詳細介紹就會存放在 body 欄位。

node :

• type : 此處標示著每個發佈的文章是屬於哪種類型，類型可以是建築物、單位、餐廳等，而這些類型必須在規劃資料時盡量的分類清楚，因為 drupal 上的這些類型並無法向規劃資料庫一樣直接給它們關聯，所以一不小心可能會照成大量的資料重覆存在於資料庫中，或是需要利用非常大量的 sql 語法才能取出資料；雖然 drupal 利用了 nid 將每個資料給予唯一的值，但是重覆的資料過多會導致開發者從不個地方取得資料，也會產生難以維護的問題。至於每個類型內包含著哪些資料則是存放在另外的資料表中。

content_* : 以 content 開頭的資料表則是存放著不同類型資料的內容。

• content_type_unitsmap : 在這邊包含了學校內所有單位等相關資料。此處並不包含單位名稱，單位名稱須利用這裡的 nid 與 node.nid 做比對之後，再取 node.title 才是單位名稱。
  
  • field_um_seat_value : 單位位於哪棟大樓
  • field_um_phone_value : 電話
  • field_um_fax_value : 傳真
  • field_um_mail_value : e-mail
  • field_um_member_value : 包含成員及部分單位簡介也顯示於此
  • field_um_floor_value : 位於幾樓
  • field_um_room_value :單位房間號碼
  • field_um_link_url : 網頁網址
• content_type_sightseeing : 包含景點簡介等資訊，基本上與 content_type_unitsmap 類似。

• content_type_foodnews : 包含餐廳的資訊，基本上與 content_type_unitsmap 類似。

location : 地圖所需要的經緯度存放於此資料表中，所以當利用 content_type_unitsmap 取得單位資料時，也必須利用 nid 與此資料表的 nid 做比對，取出單位的經緯度。

Map 功能所用到的資料，大致上存放在上面介紹的資料表中，當然這個平台還提供了許多其他的資訊可以取用，不過目前只使用了這些資料。除此之外，這個平台當初規劃並非為了 UCampus做準備，所以有許多的分類顯得雜亂，如需要取得特定資訊必須額外再做判斷，這將使得運算資源白白浪費。所以之後規畫了另一個平台 Mobile Service，平台內資訊分類較為詳盡，除此之外也可以提供後台讓未來的各單位發佈新聞活動等訊息 (此部分由 漢卿 所建構，著實感謝)；而對於 Mobile Service 的資料分類將於另外一篇做記錄，以避免資訊混雜。

Read more »

關於Drupal新增content時的資料表變動

目前後台的部分是使用 Drupal 作開發，而行動裝置抓取資料必需直接向資料庫要求，所以對於 Drupal 新增 content 時相關的資料表做了一些觀察。

觀察的環境為 TWAMP 的安裝包，使用版本為 6.22 版，並且安裝了 CCK 及 Views 這兩個基本的模組，所以資料庫的結構上就是依照這樣的安裝所產生的，總共的資料表數量為61個，觀察的資料表為 content 以及 node 這兩個字串為開頭的資料表。

• 新增 content 類型

首先來看，新增一個 content 類型後，在 node_type 中會新增一筆資料，這筆資料代表的就是剛剛新增的 content 類型，並且此類型的相關設定都會存放在這。

• 新增 field

接著在此 content 類型中新增一個 field ，新增完這個 field 後，資料庫中會新增一個資料表，資料表的名稱為 content_type_"ContentType名稱" ，而裡面暫時不會有值，至於會有哪些欄位就視不同的 field type 而不同，最基本的欄位會有 nid 及 vid 。

譬如新增的 field type 是 Node reference 的話，那會多一個 field_"連結的node名稱"_nid 的欄位，記錄著連結到哪個 node，而有些 type 則會在未來新增內容時才做動作。

除此之外 content_node_field 及 content_node_field_instance 這兩個資料表，也會新增一筆與 field 設定相關的紀錄，而這兩個的差別在於 content_node_field 像是物件導向概念裡的類別，而 content_node_field_instance 則是經由類別創建出的實例，content_node_field 紀錄的是一般的設定，此設定可套用到其他的 content 類別，content_node_field_instance 則是與某個 content 類別綁住的獨有的設定。

• 新增 content 內容

接下來新增一個 content 內容，類型為剛剛所創建的 content 類型，在資料庫中會在 node 資料表中寫入一筆記錄，包含了創建的相關訊息，但不包括創建內容；node_comment_statistics 資料表中會有一筆統計紀錄；node_revisions 資料表會存放未來如果有變更的資訊。而實際內容會放在以 content 字串開頭的資料表中，像是前面提到的 Node reference 類型的 field 則會將內容資料放在 content_type_"ContentType名稱" 中，而如果是 text 類型的 field 則會 新增一個專門存放內容的資料表，資料表名稱像是 content_field_name。


以上是我對於新增 content 的流程所做的觀察，但這部分會因為不同的模組及設定而有所不同，不過如果只是要從 Drupal 所建立的資料庫中尋找到自己所需的資料來說，相信已經足夠，由上面可看出，實際內容存放的地方以 content 開頭的資料表為最主要，尤其是 content_type 和 content_field，接下來與建立內容相關的統計資料為 node_comment_statis 資料表，並且可以利用 nid 或是 vid 的值去比對出所需資料。

Read more »