论文部分内容阅读
本文主要讲述SolidWorks EPDM的SQL数据库的内部结构。在此之前，没有一个EPDM的中文教程曾全面论述过这方面的内容。但由于EPDM在大中国区存在二次开发的需要，大中国区的的工程师必须对此有一个系统深入的了解。所以笔者根据自己的体会，写出这篇章。
□广州宇喜资讯科技有限公司EPDM工程师 岑青山
一、关于控制所有库的ConisioMasterDb库
在EPDM的SQL服务器中，有数据库ConisioMasterDb，是用于控制所有的EPDM数据库。在这个库中，有表FileVaults用于控制SQL数据库和文档库（Vault）的关联，即文档库（Vault）和SQL数据库的对应关系，所以我们可以据此找到两者是如何对应的。
二、基本库结构
（1）在每一个EPDM的SQL数据库中，都存在表“Users”。用于记录这个文档库中的用户信息。其中主要的字段说明如表1所示。
表1
字段名 说明
UserID 表的主键，是个用户名的唯一标识
Username 用户名
LogedIn 此用户是否正在登录
Fullname 用户全名
（2）关于表“Groups”，其中字段说明如表2所示。
表2
字段名 说明
GroupID 表的主键，是个组名的唯一标识
GroupName 用户名
（3）关于表“GroupMembers”，主要用于用户和组的关联，其中主要的字段说明如表3所示。
表3
字段名 说明
GroupID 组ID
UserID 用户ID
所以，可以发出如下SQL命令将用户和组关联，达到显示所有组和成员的目标：
Select * from Users as U， Groups as G， GroupMem-bers as GM
Where U.UserID=GM.UserID and GM.GroupID=G. GroupID
（4）关于表“Projects”，主要用于记录Vault文档库中目录存在的地方。其中主要的字段说明如表4所示。
表4
字段名 说明
ProjectID 目录的ID ，是个目录的唯一标识
Name 最后一段目录名称，即：最后一级的目录名
Path 目录路径，即：字段Name所在的路径
所以一个目录在Vault文档库中的路径应该是：Path+Name；在本地视图（local View）的绝对路径应该是：%RootFolderPath%+ Path+Name。
（5）关于表“GroupProjectRights”，主要记录Vault文档库中组所对应的目录权限的存放。其中字段说明如表5所示。
表5
字段名 说明
GroupID 组的 ID号，这是源引自 Groups表的 GroupID字段
ProjectID 目录的ID，这是源引自Projects表的ProjectID字段
Type 该目录的权限，权限一个有20种，都记录于此。这一个权限都有唯一是数据表示。这个问题将在以后专门撰文阐述
所以要知道一个目录在组中的权限，可以发出如下SQL命令：
Select P.Path+ P.Name as 目录， G. GroupName， GP.Type as 权限
from Groups as G ， Projects as P， GroupProjectRights as GP
where G.GroupID=GP.GroupID and P.ProjectID=GP. ProjectID
当使用脚本恢复文档库的备份时，目录的权限会丢失。其原因在于产生新库中的GroupID和ProjectID改变了，不是原来的ID。但知道这个表后，用户可以据此通过组名的比对和目录字符串的比对，在新的文档库中自动恢复其目录权限。
（6）关于表“UserProjectRights”，这表记录Vault文档库中用户所对应的目录权限的存放。其中字段说明如表6所示。
表6
字段名 说明
UserID 用户的 ID号，这是源引自 Users表的 UserID字段
ProjectID 目录的ID，这是源引自Projects表的ProjectID字段
Type 该目录的权限，权限一个有20种，都记录于此。这一个权限都有唯一是数据表示。这个问题将在以后专门撰文阐述
所以要知道一个目录在用户中的权限，可以发出如下SQL命令：
Select P.Path+ P.Name as 目录，U.Username，U_P.Type as 权限
from Users as U ， Projects as P， UserProjectRights as U_P
where U.UserID= U_P. UserID and P.ProjectID= U_P. ProjectID
同上，当使用脚本恢复文档库的备份时，目录的权限会丢失。其原因在于产生的新库中，UserID和ProjectID改变了，不是原来的ID。但利用该表，用户可以据此通过用户名的比对和目录字符串的比对，在新的文档库中自动恢复其目录权限。
（7）关于表“Documents”，主要用于记录Vault文档库中所有文件、零件、装配体和工程图的存放地点。其中主要的字段说明如表7所示。 表7
字段名 说明
DocumentID 文档的ID号 ，这是该文档的唯一标识
Filename 文件名，这个文件名是全名含后辍
UserID 用户ID，这是指该文档最后被何用户所使用
LockDomain 检出该文档的计算机，我们可以据此知道此文档是否被检出
LockPath 检出该文档的在本地视图中的路径，我们可以据此知道此文档是否被检出，我们可以据此知道此文档是否被检出
DocTypeID 该文档中Vault文档库中的文件类型。例：word文件、SW零件等
（8）关于表“Cards”。这表记录Vault文档库中所有卡的存放地点。其中主要的字段说明如表8所示。
表8
字段名 说明
CardID 卡的ID号 ，这是该文档的唯一标识
CardType 卡的类型，限此卡这是属于为文件卡、搜索卡、项目卡等
CardName 卡的名称
此表用于当运行一下插件时，以CardID为依据判断当前激活的卡是否为用户所希望的卡。
（9）表DocumentsInProjects主要记录所有文件和路径之间的关系。其中主要的字段说明如表9所示。
（10）表Projects主要用于记录所有路径的信息。其中主要的字段说明如表10所示。
表9
字段名 说明
ProjectID 表Projects的ProjectID号
DocumentID 表Documents的DocumentID号
Deteed 删除标志，0是没有删除；1是已删除
表10
字段名 说明
ProjectID 表Projects的ProjectID号
Name 最后的目录的名称。如：文件夹a＼b＼c，则这个 name=c
StartTime 文件夹是创建日期
Path 在存档服务器中的路径
Deteed 删除标志，0是没有删除；1是已删除
所以，用户可以发出如下SQL命令，查询PDM中文件和文件夹的关系：
select FileName，Path from Documents as D， Docu-mentsInProjects as DP， Projects as P
where D.DocumentID=DP.DocumentID
and P.ProjectID=DP.ProjectID
（11）表GroupRights主要用于记录路径的权限。其中主要的字段说明如表11所示。
（12）表Variable主要用于记录Vault文档库中所有变量名称。其中主要的字段说明如表12所示。
表11
字段名 说明
GroupID 表GroupID的GroupID号
ProjectID 表Projects的ProjectID号
Type 权限
表12
字段名 说明
VariableID 变量的ID号 ，这是该变量的唯一标识
VariableName 变量名称
VariableType 变量类型，这里使用和权限同似的表示方法，限每一个两进制位表示一个类型
IsDeleted 变量是否被删除， 0为正在被使用， 1为已被删除
（13）表VariableValue主要用于记录所有变量及其对应值的表，十分重要。PDM的BOM表据此产生，其中主要的字段说明如表13所示。
表13
字段名 说明
VariableID 变量的ID号 ，这是该变量的唯一标识
DocumentID 表Documents的DocumentID号
ProjectID 项目ID号，即文件路径，对应的表是Projects
RevisionNo 修定版本号
ConfigurationID 配置 ID号，即这个变量在何种配置中被使用。
ValueText 变量值
ValueInt 变量为整型
ValueFloat 变量为浮点型
ValueDate 变量为日期
ValueCache 变量在缓冲中的值
Islongtext 变量是长文本型
所以，我们可以结合前面学习到的Documents表结构，发出如下SQL命令，查询PDM中某一文件的所有变量值（即某一个文件（零件）的BOM表）：
select D. Filename， P. Path， V. VariableName，VV.Val-ueText
from VariableValue as VV， Variable as V， Documents as D， Projects as P
where VV.VariableID=V.VariableID
and VV.DocumentID=D.DocumentID
and VV.ProjectID=P.ProjectID
本文主要讲述SolidWorks EPDM的SQL数据库的内部结构。在此之前，没有一个EPDM的中文教程曾全面论述过这方面的内容。但由于EPDM在大中国区存在二次开发的需要，大中国区的的工程师必须对此有一个系统深入的了解。由于篇幅所限及EPDM的自身系统安全问题，在本文中未能详述“参考引用关系”、“权限”和“用户登录”等方面的问题。
□广州宇喜资讯科技有限公司EPDM工程师 岑青山
一、关于控制所有库的ConisioMasterDb库
在EPDM的SQL服务器中，有数据库ConisioMasterDb，是用于控制所有的EPDM数据库。在这个库中，有表FileVaults用于控制SQL数据库和文档库（Vault）的关联，即文档库（Vault）和SQL数据库的对应关系，所以我们可以据此找到两者是如何对应的。
二、基本库结构
（1）在每一个EPDM的SQL数据库中，都存在表“Users”。用于记录这个文档库中的用户信息。其中主要的字段说明如表1所示。
表1
字段名 说明
UserID 表的主键，是个用户名的唯一标识
Username 用户名
LogedIn 此用户是否正在登录
Fullname 用户全名
（2）关于表“Groups”，其中字段说明如表2所示。
表2
字段名 说明
GroupID 表的主键，是个组名的唯一标识
GroupName 用户名
（3）关于表“GroupMembers”，主要用于用户和组的关联，其中主要的字段说明如表3所示。
表3
字段名 说明
GroupID 组ID
UserID 用户ID
所以，可以发出如下SQL命令将用户和组关联，达到显示所有组和成员的目标：
Select * from Users as U， Groups as G， GroupMem-bers as GM
Where U.UserID=GM.UserID and GM.GroupID=G. GroupID
（4）关于表“Projects”，主要用于记录Vault文档库中目录存在的地方。其中主要的字段说明如表4所示。
表4
字段名 说明
ProjectID 目录的ID ，是个目录的唯一标识
Name 最后一段目录名称，即：最后一级的目录名
Path 目录路径，即：字段Name所在的路径
所以一个目录在Vault文档库中的路径应该是：Path+Name；在本地视图（local View）的绝对路径应该是：%RootFolderPath%+ Path+Name。
（5）关于表“GroupProjectRights”，主要记录Vault文档库中组所对应的目录权限的存放。其中字段说明如表5所示。
表5
字段名 说明
GroupID 组的 ID号，这是源引自 Groups表的 GroupID字段
ProjectID 目录的ID，这是源引自Projects表的ProjectID字段
Type 该目录的权限，权限一个有20种，都记录于此。这一个权限都有唯一是数据表示。这个问题将在以后专门撰文阐述
所以要知道一个目录在组中的权限，可以发出如下SQL命令：
Select P.Path+ P.Name as 目录， G. GroupName， GP.Type as 权限
from Groups as G ， Projects as P， GroupProjectRights as GP
where G.GroupID=GP.GroupID and P.ProjectID=GP. ProjectID
当使用脚本恢复文档库的备份时，目录的权限会丢失。其原因在于产生新库中的GroupID和ProjectID改变了，不是原来的ID。但知道这个表后，用户可以据此通过组名的比对和目录字符串的比对，在新的文档库中自动恢复其目录权限。
（6）关于表“UserProjectRights”，这表记录Vault文档库中用户所对应的目录权限的存放。其中字段说明如表6所示。
表6
字段名 说明
UserID 用户的 ID号，这是源引自 Users表的 UserID字段
ProjectID 目录的ID，这是源引自Projects表的ProjectID字段
Type 该目录的权限，权限一个有20种，都记录于此。这一个权限都有唯一是数据表示。这个问题将在以后专门撰文阐述
所以要知道一个目录在用户中的权限，可以发出如下SQL命令：
Select P.Path+ P.Name as 目录，U.Username，U_P.Type as 权限
from Users as U ， Projects as P， UserProjectRights as U_P
where U.UserID= U_P. UserID and P.ProjectID= U_P. ProjectID
同上，当使用脚本恢复文档库的备份时，目录的权限会丢失。其原因在于产生的新库中，UserID和ProjectID改变了，不是原来的ID。但利用该表，用户可以据此通过用户名的比对和目录字符串的比对，在新的文档库中自动恢复其目录权限。
（7）关于表“Documents”，主要用于记录Vault文档库中所有文件、零件、装配体和工程图的存放地点。其中主要的字段说明如表7所示。 表7
字段名 说明
DocumentID 文档的ID号 ，这是该文档的唯一标识
Filename 文件名，这个文件名是全名含后辍
UserID 用户ID，这是指该文档最后被何用户所使用
LockDomain 检出该文档的计算机，我们可以据此知道此文档是否被检出
LockPath 检出该文档的在本地视图中的路径，我们可以据此知道此文档是否被检出，我们可以据此知道此文档是否被检出
DocTypeID 该文档中Vault文档库中的文件类型。例：word文件、SW零件等
（8）关于表“Cards”。这表记录Vault文档库中所有卡的存放地点。其中主要的字段说明如表8所示。
表8
字段名 说明
CardID 卡的ID号 ，这是该文档的唯一标识
CardType 卡的类型，限此卡这是属于为文件卡、搜索卡、项目卡等
CardName 卡的名称
此表用于当运行一下插件时，以CardID为依据判断当前激活的卡是否为用户所希望的卡。
（9）表DocumentsInProjects主要记录所有文件和路径之间的关系。其中主要的字段说明如表9所示。
（10）表Projects主要用于记录所有路径的信息。其中主要的字段说明如表10所示。
表9
字段名 说明
ProjectID 表Projects的ProjectID号
DocumentID 表Documents的DocumentID号
Deteed 删除标志，0是没有删除；1是已删除
表10
字段名 说明
ProjectID 表Projects的ProjectID号
Name 最后的目录的名称。如：文件夹a＼b＼c，则这个 name=c
StartTime 文件夹是创建日期
Path 在存档服务器中的路径
Deteed 删除标志，0是没有删除；1是已删除
所以，用户可以发出如下SQL命令，查询PDM中文件和文件夹的关系：
select FileName，Path from Documents as D， Docu-mentsInProjects as DP， Projects as P
where D.DocumentID=DP.DocumentID
and P.ProjectID=DP.ProjectID
（11）表GroupRights主要用于记录路径的权限。其中主要的字段说明如表11所示。
（12）表Variable主要用于记录Vault文档库中所有变量名称。其中主要的字段说明如表12所示。
表11
字段名 说明
GroupID 表GroupID的GroupID号
ProjectID 表Projects的ProjectID号
Type 权限
表12
字段名 说明
VariableID 变量的ID号 ，这是该变量的唯一标识
VariableName 变量名称
VariableType 变量类型，这里使用和权限同似的表示方法，限每一个两进制位表示一个类型
IsDeleted 变量是否被删除， 0为正在被使用， 1为已被删除
（13）表VariableValue主要用于记录所有变量及其对应值的表，十分重要。PDM的BOM表据此产生，其中主要的字段说明如表13所示。
表13
字段名 说明
VariableID 变量的ID号 ，这是该变量的唯一标识
DocumentID 表Documents的DocumentID号
ProjectID 项目ID号，即文件路径，对应的表是Projects
RevisionNo 修定版本号
ConfigurationID 配置 ID号，即这个变量在何种配置中被使用。
ValueText 变量值
ValueInt 变量为整型
ValueFloat 变量为浮点型
ValueDate 变量为日期
ValueCache 变量在缓冲中的值
Islongtext 变量是长文本型
所以，我们可以结合前面学习到的Documents表结构，发出如下SQL命令，查询PDM中某一文件的所有变量值（即某一个文件（零件）的BOM表）：
select D. Filename， P. Path， V. VariableName，VV.Val-ueText
from VariableValue as VV， Variable as V， Documents as D， Projects as P
where VV.VariableID=V.VariableID
and VV.DocumentID=D.DocumentID
and VV.ProjectID=P.ProjectID
本文主要讲述SolidWorks EPDM的SQL数据库的内部结构。在此之前，没有一个EPDM的中文教程曾全面论述过这方面的内容。但由于EPDM在大中国区存在二次开发的需要，大中国区的的工程师必须对此有一个系统深入的了解。由于篇幅所限及EPDM的自身系统安全问题，在本文中未能详述“参考引用关系”、“权限”和“用户登录”等方面的问题。