團隊專案——資料庫設計心得
一、專案簡介
該系統旨在設計一款基於聯邦型RDF資料庫的能充分理解使用者輸入關鍵詞語義的關鍵詞檢索引擎，通過構建索引以支援線上階段的關鍵詞檢索，理解使用者語義，讓使用者能自由表達自己的查詢需求，提供精準符合要求的答案，以精簡友好的介面、方便的操作為使用者提供一種資訊搜尋的快速定位的功能，特別是為區域網使用者提供更有針對性的、更方便的資源，從而提高資源的共享目標，讓使用者可以高效，快捷的獲得想要的資訊，區別於普通搜尋引擎，效果更加友好，方便快捷。
二、系統的功能描述
要想設計好資料庫，首先，我們應明確專案的需求，明確功能需求。
上圖為根據需求畫出的大致流程圖。
三、確定實體
通過對搜尋引擎各方面的分析，我們可以知道搜尋引擎中的實體包括：使用者，使用者組，模組，關鍵詞，結果。各實體包含的資料項分別如下：
（1）使用者：使用者id、使用者名稱、密碼、手機號、狀態、加入時間、上次登入 時間、上次登入地點、使用者組。
（2）使用者組：使用者組id、使用者組名稱。
（3）模組：模組id、模組名稱。
（4）關鍵詞：關鍵詞id、使用者id、關鍵詞、搜尋時間。
（5）結果：結果id、關鍵詞id、結果url、是否點選、點選時間。
另外，為了後期演算法方便，我們還將我們用到的資料集中的uri進行了編號，因為uri太長，如果不用編號的話，可能會很費時。
四、確定聯絡
通過以上分析，我們作如下規定：
（1）一個使用者可以屬於一個使用者組，一個使用者組可以包含多個使用者；
（2）一個使用者組可以繫結多個模組，一個模組可以被多個使用者組繫結；
（3）一個關鍵詞可以搜尋到多個結果，一個結果對應一個關鍵詞；
（4）一個使用者可以輸入多個關鍵詞，一個關鍵詞對應一個使用者；
實體之間的聯絡有：
（1）使用者與使用者組之間（M：1）
（2）使用者組與模組之間（M：N）
（3）關鍵詞與結果之間（1：M）
（4）使用者與關鍵詞之間（1：M）
五、最終設計結果
（1） 關鍵詞表（key_info表）
| 屬性名 |
資料型別 |
是否為空 |
含義 |
是否為主鍵 |
| Key_id |
int |
not null |
關鍵詞id |
primary key |
| User_id |
int |
not null |
使用者id |
Foreign key |
| Keyword |
varchar(100) |
not null |
使用者輸入的關鍵詞 |
|
| Search_t |
Datetime |
Not null |
搜尋時間 |
|
（2）圖結構表（schema_dir表）
| 屬性名 |
資料型別 |
是否為空 |
含義 |
是否為主鍵 |
| Start |
Int |
not null |
起點 |
primary key |
| End |
Int |
not null |
終點 |
Primary key |
| Path |
Int |
not null |
路徑條數 |
|
（3）屬性表（pre_info表）
| 屬性名 |
資料型別 |
是否為空 |
含義 |
是否為主鍵 |
| pre_id |
Int |
not null |
屬性編號 |
primary key |
| pre_uri |
varchar(20) |
not null |
屬性uri |
|
（4）許可權表（power_info表）
| 屬性名 |
資料型別 |
是否為空 |
含義 |
是否為主鍵 |
| User_id |
char(6) |
not null |
使用者編號 |
primary key |
| privilege |
char(15) |
not null |
許可權名 |
primary key |
| modifier |
Varchar(5) |
Not null |
修改人 |
|
| modi_time |
datetime |
Not null |
修改時間 |
primary key |
（5）模組資訊表（module_info表）
| 屬性名 |
資料型別 |
是否為空 |
含義 |
是否為主鍵 |
| module_id |
Int |
not null |
模組編號 |
primary key |
| Module_name |
varchar(20) |
not null |
模組名 |
|
（6）使用者組與模組關係表（group_module_r表）
| 屬性名 |
資料型別 |
是否為空 |
含義 |
是否為主鍵 |
| rela_id |
int |
not null |
關係編號 |
primary key |
| group_id |
int |
not null |
使用者組id |
foreign key |
| module_id |
int |
not null |
模組id |
foreign key |
（7）使用者組表（group_info表）
| 屬性名 |
資料型別 |
是否為空 |
含義 |
是否為主鍵 |
| group_id |
int |
not null |
使用者組id |
primary key |
| group_name |
varchar(10) |
not null |
使用者組名稱 |
|
（8）使用者表（usr_info表）
| 屬性名 |
資料型別 |
是否為空 |
含義 |
是否為主鍵 |
| user_id |
varchar(5) |
not null |
使用者id編號 |
primary key |
| user_name |
varchar(20) |
not null |
使用者賬號 |
|
| password |
varchar(20) |
not null |
密碼 |
|
| phone |
varchar(11) |
|
電話號碼 |
|
| state |
bool |
not null |
登陸狀態 |
|
| last_login_t |
datetime |
not null |
上次登陸時間 |
|
| last_login_loc |
varchar(20) |
not null |
上次登陸地點 |
|
| signup_t |
date |
not null |
註冊時間 |
|
| group_id |
int |
|
使用者組id |
foreign key |
(9)結果表（result_info表）
| 屬性名 |
資料型別 |
是否為空 |
含義 |
是否為主鍵 |
| res_id |
int |
not null |
結果id |
primary key |
| keyword_id |
int |
not null |
關鍵詞id |
foreign key |
| res_url |
varchar(300) |
not null |
搜尋結果url |
|
| clickon |
bool |
not null |
是否被點選 |
|
| clicktime |
datetime |
not null |
點選時間 |
|
（10）結點表（class_info表）
| 屬性名 |
資料型別 |
是否為空 |
含義 |
是否為主鍵 |
| node_id |
int |
not null |
結點編號 |
primary key |
| node_url |
varchar(255) |
not null |
結點url |
|
| out_deg |
int |
not null |
結點出度 |
|
| in_deg |
int |
not null |
結點入讀 |
|
| node_rank |
int |
not null |
結點排序 |
|
六、心得
這次的資料庫設計，小組同學內部積極討論，積極提出意見，改進資料庫。在資料庫設計中，我們要考慮全面，先設計概念模型，然後生成物理模型。
在設計過程中要注意：
若兩個實體之間存在多對多的關係，則應消除這種關係。消除的辦法是，在兩者之間增加第三個實體。這樣，原來一個多對多的關係，現在變為兩個一對多的關係。要將原來兩個實體的屬性合理地分配到三個實體中去。這裡的第三個實體，實質上是一個較複雜的關係，它對應一張基本表。一般來講，資料庫設計工具不能識別多對多的關係，但能處理多對多的關係。