A. 如何查看資料庫里表的欄位分別代表什麼意思
進入表的設計視圖，欄位位置顯示的是編程用到的代碼，標題位置顯示的是給用戶看到的名稱。你到表的設計視圖研究一下就明白了。
B. 這資料庫關系圖怎麼解讀（詳細解讀）
一共七張表，每張表均以ID欄位作為主鍵，應該是一個簡單的聊天系統後台資料庫，各個表大概應該為：
1.Users，用戶表，應該是主體表，用於記錄用戶的登錄信息，名稱之類，年齡，性別。
2.BloodType，血型表，應該是用於記錄血型，與users表的Bloodtypeid存在外鍵關聯。
3.Star，星座表，用於記錄星座，與users表的starid存在外鍵關聯。
4.Friends，應該用於記錄用戶對應的好友信息，其中與users表存在兩個外鍵關聯。
5.friendshippolicy，這個表搞不清楚實際內容。
6.messages，應該用於記錄用戶與好友間的信息對話，存在三個外鍵關聯，其中一個是與messagetype表存在，另兩個是與users存在外鍵關聯。
7.messagetype，用於記錄信息的類型，與messages表的messagetypeid存在外鍵關聯。
C. mysql資料庫表之間是怎麼關聯的請詳解
left join
join
主外鍵是兩種對表的約束。
例如：
學生表student（學號（id）,姓名（name）,性別（sex））
表內有：1，aa,女
課程表subject（課程編號（id）,課程名（name））
表內有：1,語文
成績表grade（成績編號（id）,學號（stu_id）,課程號（sub_id）,成績（grade））
表內有：1,1,1,90
成績表的學號就是學生表的學號相對應，並且為學生表的主鍵，這樣就稱成績表中的學號是學生表的外鍵，同理，成績表中的課程號是課程表的外鍵。
select * from student as s inner join subject as su on su.stu_id=s.id inner join grade as g on g.sub_id=su.id where 1.
(3)如何讀懂資料庫表欄位之間關系擴展閱讀：
注意事項
SQL 連接（JOIN） 子句用於把來自兩個或多個表的行結合起來，基於這些表之間的共同欄位。連接的結果可以在邏輯上看作是由SELECT語句指定的列組成的新表。
左連接與右連接的左右指的是以兩張表中的哪一張為基準，它們都是外連接。外連接就好像是為非基準表添加了一行全為空值的萬能行，用來與基準表中找不到匹配的行進行匹配。
假設兩個沒有空值的表進行左連接，左表是基準表，左表的所有行都出現在結果中，右表則可能因為無法與基準表匹配而出現是空值的欄位。
不同的 SQL JOIN可以使用的不同的 SQL JOIN 類型：
INNER JOIN：如果表中有至少一個匹配，則返回行
LEFT JOIN：即使右表中沒有匹配，也從左表返回所有的行
RIGHT JOIN：即使左表中沒有匹配，也從右表返回所有的行
FULL JOIN：只要其中一個表中存在匹配，則返回行（MySQL不支持FULL JOIN）
例如：
mysql> select * from access_log;
+-----+---------+-------+------------+
| aid | site_id | count | date |
+-----+---------+-------+------------+
| 1 | 1 | 45 | 2016-05-10 |
| 2 | 3 | 100 | 2016-05-13 |
| 3 | 1 | 230 | 2016-05-14 |
| 4 | 2 | 10 | 2016-05-14 |
| 5 | 5 | 205 | 2016-05-14 |
| 6 | 4 | 13 | 2016-05-15 |
| 7 | 3 | 220 | 2016-05-15 |
| 8 | 5 | 545 | 2016-05-16 |
| 9 | 3 | 201 | 2016-05-17 |
+-----+---------+-------+------------+
9 rows in set
D. 如何定義資料庫表之間的關系
唯一需要注意的是，外鍵欄位的數據類型必須和主鍵的數據類型相同。但是有些系統可以允許這條規則有一個例外，它允許在數字和自動編號（autonumbering）欄位（例如在SQL伺服器系統中訪問Identity和AutoNumber）之間建立關系。此外，外鍵的值可以是空（Null），盡管強烈建議在沒有特別原因的情況下，不要讓外鍵為空。你有可能永遠都不會有機會來使用需要這項功能的資料庫。 現在回到我們的示例關系表，並開始輸入合適的外鍵。（請繼續在紙上打草稿——在你的資料庫系統中創建真正的數據表還為時過早。要知道在紙上糾正錯誤要容易得多。）要記住，你正在把主鍵的值添加到關系表裡。只要調用實體之間的關系就行了，而其他的就簡單了： 書籍和分類是有關系的。 書籍和出版社是有關系的。 書籍和作者是有關系的。 作者和郵政編碼（ZIP）是有關系的。 郵政編碼和城市是有關系的。 城市和州是有關系的。 這一步並不是一成不變的，你可能會發現在規范化的過程中加入外鍵會更容易一些。在把欄位移動到一個新的數據表時，你可能要把這個新數據表的主鍵添加到原來的數據表裡，將其作為外鍵。但是，在你繼續規范化剩餘數據的時候，外鍵常常會發生改變。你會發現在所有這些數據表被全部規范化之後，一次添加所有的外鍵，這樣效率會更高。 操作數據表 現在讓我們一次操作一個數據表，就從Books數據表開始，它在這個時候只有三個欄位。很明顯，Authors、Categories和Publishers數據表的主鍵會被添加到Books里。當你完成的時候，Books數據表就有了七個欄位： Books Title (PK) ISBN (PK) Price FirstNameFK (FK) Authors.FirstName many-to-many LastNameFK (FK) Authors.LastName many-to-many CategoryFK (FK) Categories.Category many-to-many PublisherFK (FK) Publishers.Publisher one-to-many 要記住，Authors數據表裡的主鍵是一個基於姓和名兩個欄位的復合關鍵字。所以你必須要把這個兩個欄位都添加到Books數據表裡。要注意，外鍵欄位名的結尾包含有FK這個後綴。加入這個後綴有助於提高可讀性和自我歸檔。通過名稱這種方式來區別外鍵會使得追蹤它們更簡單。如果主鍵和外鍵的名稱不同，這沒有關系。 這里出現了三種關系：Books和Authors、Books和Categories，以及Books和Publishers。這三種關系中所存在的兩種問題可能沒有那麼明顯： Books和Authors之間的關系：一本書可以有多個作者。 Books和Categories之間的關系：一本書可以被歸入多個類。 這兩者的關系是多對多的關系。先前我告訴過你，數據表不能直接實現這樣的關系，而需要第三個聯系表來實現。（Books和Publishers的關系是一對多的關系，就像現在所說的，這樣是沒有問題的。） 這兩個新發現的多對多關系將需要一個聯系表來包含來自每個數據表的主鍵，並將其作為外鍵。新的聯系表是：BooksAuthorsmmlink TitleFK (FK) Books.Title one-to-many ISBNFK (FK) Books.ISBN one-to-many FirstNameFK (FK) Authors.FirstName one-to-many LastNameFK (FK) Authors.LastName one-to-many BooksCategoriesmmlink TitleFK (FK) Books.Title one-to-many ISBNFK (FK) Books.ISBN one-to-many CategoryFK (FK) Categories.Category one-to-many 沒有必要更改Categories、Authors或者Publishers數據表。但是，你必須把FirstNameFK、LastNameFK和CategoryFK這三個外鍵從Books里移走： Books Title (PK) ISBN (PK) Price PublisherFK (FK) Publishers.Publisher one-to-many 現在，讓我們轉到Authors數據表上來，它現在有兩個欄位。每個作者都和ZIPCodes數據表中的郵政編碼的值相關。但是，每個郵政編碼會和多個作者相關。要實現這種一對多的關系，就要把ZIPCodes數據表中的主鍵添加進Authors數據表作為外鍵： Authors FirstName (PK) LastName (PK) ZIPCodeFK (FK) ZIPCodes.ZIPCode one-to-many 至此，你已經准備好了處理剩下的地址部分了。看到它們被分在不同的數據表裡是很讓人奇怪的，但是這是遵照BCNF正確規范化數據的結果。每個郵政編碼的值只會有一個對應的城市值和州值。每個城市和州的值只會被輸入進其對應的數據表裡一次。ZIPCodes和Cities數據表需要外鍵欄位來實現這些關系： ZIPCodes ZIPCode (PK) CityFK (FK) Cities.City one-to-many Cities City (PK) StateFK (FK) States.State one-to-many States State (PK) 從一個到九個 最後，你有了九個數據表：Books、Authors、Categories、Publishers、ZIPCodes、Cities、States、BooksAuthorsmmlink和BooksCategoriesmmlink。圖A是這個示例數據表的資料庫最終的圖形形式。很難想像一個簡單的數據表會被分成九個數據表。 圖A 最初的一個數據表現在需要九個數據表了 由於這個示例資料庫很簡單，你可能會問這些關系有什麼作用。看起來仍在保存冗餘的數據，只不過形式不同罷了——通過外鍵來實現。這是因為我們的數據表現在只有很少幾個欄位。試想一下有十幾個欄位的數據表，會是什麼樣的一個情形。需要承認的是，你仍然需要把數據表的主鍵作為外鍵保存進關系表裡，但是至多可能最多增加一到兩個欄位。比較一下為這個數據表裡的每一條記錄都添加十幾個條目的情形吧。
E. 舉例說明關系型資料庫中數據表、欄位、記錄分別指什麼，它們有什麼關系
關系型資料庫個人感覺應該這樣解釋：一是關系型資料庫在表現出來的時候就是一張表格，不過這張表格有一些要求，一定是不可分的表格，就是基本單元是二元的沒有表中表。這個也就是你說的數據表；
表是有橫列有豎列的。欄位就是相當於其中豎列上寫的內容，記錄就是其中橫列上的內容，有幾條記錄即使表中有幾行內容。
借用上面那位仁兄的例子：
id name score
1 ss 12
2 aa 23
3 dd 34
這相當於一個建好的關系資料庫的表，其中的id，name，score就是該數據表的欄位，1 ss 12 就是一條記錄，該表現在有三條記錄。
希望我的回答可以幫到你。
F. 資料庫管理系統，資料庫，表，欄位的關系是什麼
你是要做一個系統，還是只要寫個資料庫就行了，做系統的話分前台後台比較麻煩，只創建個資料庫的話步驟如下：首先要創建資料庫，creat
database
CJGL,然後在伺服器上設置資料庫的相關內容；然後向資料庫中插入表
use
CJGL
括弧里是表的屬性，也就是列。
creat
table
(.....)這個系統需要3個表
：學生表（學號，姓名，性別，年齡，院系）；學號是主鍵；課程表（課程號，課程名，學分，課時）；課程號是主鍵；選課表（學號，課程號，成績，課程類型）；學號和課程號是主鍵；
創建完以後在給資料庫備份，以免數據丟失。希望對你有幫助。