在线课程资源平台数据库设计及实现

罗尹奇，汤伟，许毅

（电子科技大学 图书馆，四川 成都 611730）

0 引言

在“新冠疫情”常态化的背景下，线上教育逐渐成为重要的教学手段并得到广泛应用[1-2]。高校同样也存在建设在线课程资源平台的内在需求。

一方面，高校图书馆数字资源一般由各数字资源厂商提供，存在扁平化、分散化的特点，数字资源与课程设置无关联，用户需通过特定的检索系统查询，才能得到该课程的教材教参信息。因此在线课程资源平台需实现基于课程信息的资源导航功能，以满足用户端的易用性需求。

另一方面，虽然通过EXCEL列表可有效的表示课程与其教材教参之间的关系[3]，但在平台的运维上，不同的学期具有不同的课程，同一门课程可能拥有不同的教材教参，而同一本教材教参又有可能分属于不同的课程。因此在线课程资源平台需能灵活的对课程与数字资源分别维护，同时也能对两者之间的关联关系进行调整，以满足管理员端的可维护性需求。

本文以电子科技大学在线课程资源平台二期系统为例，分析了其底层数据库设计方案，论证了该方案能够同时满足用户的使用需求与管理员的维护需求，并最后给出了基于Hibernate框架的对象关系映射的关键代码实现。

1 实体-关系模型建模

实体-关系模型（Entity-Relationship Model）是一种面向用户的数据建模方法，是概念数据模型的高层描述所使用的抽象表示或模式图，其本身与具体的数据库管理软件无关，在数据库设计中被广泛用作数据建模的工具[4-5]。

实体-关系模型基于应用场景，主要由实体、属性和关系组成。其中实体是系统中客观存在的事物，具有相同性质（或属性）的实体集合构成了实体集。属性是实体集中每个成员所拥有的描述性性质。关系则是用于描述多个实体之间的关联方式。实体-关系模型建模的目的在于从抽象概念层面上，构建在线课程资源平台的数据模型，其建模的基本步骤如下：

（1）识别并提取有效的实体。实体必须是客观存在并可以区分的，在在线课程资源平台应用场景中，有效的实体包括了学院、课程、数字资源。由于平台是开放式的，对于用户的类型并不做严格的区分，因此诸如授课教师、学生等实体在该场景中属于无效实体。

（2）提取实体的关键属性。实体本身的属性可能是非常多的，需提取符合应用场景要求的关键属性，而忽略非必要的次要属性。例如课程名称是课程实体的关键属性，而选课人数则属于次要属性。

（3）分析实体与实体之间的关系。实体之间的关系分3种类型：一对一的关系、一对多的关系、多对多的关系。学院与课程之间属于一对多的关系，即一个学院会开设多门课程；课程与数字资源之间属于多对多的关系，即一门课程会拥有多本教材教参，而同一本教材教参又有可能被多门课程使用。

根据上述的建模步骤，得到实体-关系模型的图形表示，其中实体用矩形表示，关系用菱形表示，属性用椭圆表示，如图1所示：

2 数据库实现

2.1 数据库模型

根据图1实体-关系模型，现将其转化为对应的数据库模型。在转化过程中实体（实体集）多数情况下会采用数据库表来表示；而属性则一般会转化为数据库表中的字段，其类型由实际应用场景决定。特别需要注意的是，实体-关系模型中的关系在转化时，依照关系类型的不同，决定了其在数据库中的表现形式：

（1）一对一的关系：当实体-关系模型中存在一对一关系时，其在数据库中会表示为两表之间的主键约束，即A表的主键是B表的主键，同时也是B表的外键，如图2所示：

图2 一对一的关系

（2）一对多的关系：当实体-关系模型中存在一对多的关系时，其在数据库中会表示为两表之间的外键约束，即A表的主键是B表的外键，如图3所示：

图3 一对多的关系

（3）多对多的关系：当实体-关系模型中存在多对多的关系时，此时在数据库中关系会作为单独的一张表建立，其作用在于通过复合主键的形式来描述多对多的关系。由于复合主键是通过多个主键的排列组合来保证唯一性，因此复合主键的排列组合过程实现了多对多关系，而唯一性则保证了这种关系是确定的，如图4所示：

图4 多对多的关系

（4）带属性的多对多的关系：作为特殊的多对多的关系，其关系中存在其他属性，此时该表的结构与一般的关系表结构所有差异，该表主键只是自增键或随机字符串，而关联实体的主键会作为该表的外键，同时该表中还包含了其他属性字段，如图5所示：

图5 带属性的多对多的关系

基于上述实体-关系模型到数据库表的转化规则，现将图1转化为数据库表，得到的结果如图6所示：

图6 数据库模型

2.2 数据词典

根据图6的数据库模型，现将各表数据词典列出，如表1至表4所示：

表1 学院t_institute表

表2 课程t_course表

表3 数字资源t_resource表

需要注意的是，在表4中link_type字段描述了课程-资源关系类型。一门课程中可能有多本教材以及参考资料，而数字资源本身是无法区分其是否为教材还是参考资料的，也就是同一个数字资源可能在这一门课程里是作为教材，而在另外的课程中则可能是参考资料，因此通过在课程-资源关系表中加入link_type字段来加以区分。

2.3 合理性分析

从用户角度来看，数据库设计方案满足了用户的一般使用行为。由于该平台用户多为在校师生，其关注的往往是本学院所开设的课程及相关数字资源，因此用户可以根据学院表进行导航。课程表中的学院序号字段则提供了查询条件，平台显示对应学院下所开设的所有课程，这样有助于用户找到本学期或以往的课程。利用课程编号以及课程-资源关系表，可以进一步查询出该课程下所关联的数字资源以及该资源是否为教材或参考资料。整个访问过程将课程与对应的数字资源以树状结构展示出来，满足了用户数据上钻下探的需求。

从管理员角度来看，数据库设计方案满足了简化运维的需求。课程与数字资源是相对独立的两张表，在运维过程中可以分开管理，课程可以与学校教务系统保持一致，数字资源则可以与第三方厂商保持一致，两者信息更新可以是异步的，相互之间不会发生干扰。管理员仅需维护课程-资源关系表，即在平台上选择相关资源并关联（或解除关联）到对应的课程上。整个运维过程简化为对课程-资源关联关系的运维，而课程与数字资源本身的信息则可以与其他系统自动化同步。

3 对象关系映射

对象关系映射（Object Relational Mapping，ORM）是一种程序设计技术，用于将面向对象编程语言里的对象，与关系型数据库中的数据进行转换[6]。由于面向对象是从软件工程的基础上发展起来的，而关系数据库则是从数学理论发展而来的[7]，两套理论存在显著的区别，存在范式不匹配的现象，因此ORM技术主要实现了在关系型数据库和程序对象之间作数据映射，以屏蔽底层复杂的SQL操作。

Hibernate框架是一种基于Java语言的ORM技术实例，通过Hibernate框架可以实现Java对象与数据库表间数据相互转化。本文采用的Hibernate版本为4.1.7，开发模式为基于XML配置文件。

3.1 学院表映射

由于学院表主要做导航功能，因此对于学院表仅做最基本的映射，直接将其Java代码与数据库字段进行对应。结果如表5与表6所示：

表5 学院对象关键代码

表6 学院表映射关键代码

3.2 课程表映射

在实际应用场景中，由于课程对象一方面需要能够实现上钻，获取其所开设的学院；另一方面又要能实现下探，得到该课程下的教材与参考资料。因此课程对象中需要同时包含对学院和数字资源的引用。但事实上需要注意的是，由于课程-资源关系表中附带了区分教材教参的字段，若课程对象直接对数字资源引用则无法在程序逻辑上实现区分教材教参，故此时的课程对象不直接对数字资源引用，而是转化为对课程-资源关系的引用，进而完成间接引用数字资源。其结果如表7与表8所示：

表7 课程对象关键代码

表8 课程表映射关键代码

3.3 资源表映射

与课程表的映射过程类似，资源对象同样不直接引用课程，而是对课程-资源关系表引用，这样才能区分该资源在课程中的类型是否为教材。映射结果如表9与表10所示：

表9 资源对象关键代码

表10 资源表映射关键代码

需要注意的是，资源的ID采用了UUID生成策略，这是因为一方面，数字资源的来源可能是多家第三方厂商，平台需要进行统一编号；另一方面，资源名、ISBN编号等信息不足以对资源加以区分，特别是针对同一本书籍可能有多个第三方厂商提供网址访问，故而使用UUID来作为资源的特定编号。

3.4 课程-资源关系表映射

在实际应用场景下，由于需要统计平台的教材与教参数量，因此需要对课程-资源关系表进行映射，结果如表11与表12所示：

表11 课程-资源关系对象关键代码

表12 课程-资源关系表映射关键代码

4 结论

综上所述，本文以电子科技大学在线课程资源平台二期系统为例，分析了基于实体-关系模型的数据建模技术，构建了平台的实体-关系模型；然后提出了将实体-关系模型转化为数据库表的方法，基于该方法建立了数据库模型并描述了其数据词典；最后本文基于Java编程语言中的Hibernate框架，提供了数据库表与程序对象映射的关键代码。

基于上述方法，本文展示了数据建模到数据库建立，再到程序代码映射的一般开发过程，特别是将实体-关系模型转化为数据库表的方法对于其他资源平台的建设具有一定的借鉴意义。