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个表
：学生表（学号，姓名，性别，年龄，院系）；学号是主键；课程表（课程号，课程名，学分，课时）；课程号是主键；选课表（学号，课程号，成绩，课程类型）；学号和课程号是主键；
创建完以后在给数据库备份，以免数据丢失。希望对你有帮助。