排课项目小结
一、个人在小组中参与工作总览(简述)
小组项目需求阶段:
项目流程：
在共同确认了项目题目之后，我参考了老师课堂上介绍的上一届学生项目的流程将要实现的功能进行了拆分，并与小组成员分享了我对排课系统业务流程的想法。在课后积极参与项目需求分析和讨论工作，与组内成员一起确定了排课系统的业务流程的雏形，并后续的课堂讨论中对其进行了修改与完善。
小组项目数据库设计阶段
实体与ER图绘制：
积极参与讨论与小组成员按照项目流程共同确定了实体及其属性、主码，并绘制并逐步完善了ER图。 IDEFX图绘制：
在多次负责绘制IDEF1X图的过程中，我对部分实体之间的对应关系、部分实体的主键以及属性的合理性进行了深入思考。在这个过程中，我提出了自己的意见，并对图进行了修改以确保准确性和完整性。
文档修改与整理：
在项目的六次修改中，我参与了多次的文档整合工作，并在后期负责“专业负责人安排下学期必修课程和专业选修课程”、“专业负责人安排课程班级和教师，教务处老师安排课程时间和地点”两个步骤中的表结构设计，在此过程中我积极提出了自己对实体及其属性、样本的想法，并进行了相应的修改。
3、小组项目界面设计阶段：
负责“专业负责人安排下学期必修课程和专业选修课程”、“专业负责人安排课程班级和教师，教务处老师安排课程时间和地点”两个步骤中的两个页面设计，使用墨刀软件完成了页面的绘制与完善，并在讨论中对其他页面提出了修改意见。
4、项目全程中小组讨论与协作情况及自认的参与度：
在整个项目中，我展现了积极的参与度和协作能力。我积极参与讨论，深入思考并提出自己的意见。课后，我主动承担了包括绘制IDEF1X图和整理文档在内的组内任务工作。在项目的表结构设计阶段和界面设计阶段，我全权负责了前文所述的两个板块，并持续地根据老师和同学的意见对其进行修改与完善。
二、个人工作(问题难点及解决方法)
- 问题：在设计前期未能明确意识到“时间”与“地点”应作为实体；
难点：如何发现应该将属性抽离出作为实体；
解决方法：在按照需求抽象出实体之后，再按照约束深入思考原来的属性是否需要抽离出来作为实体以实现需求，也就是正向思考之后还需要逆向思考；如果不将“时间”与“地点”两个属性转化为实体排课时可能出现同一时间同一地点排多门课的情况，这显然对于排课系统而言是不能容忍的漏洞；此外，还可能造成用户输入的上课地点错误、上课时间格式不统一等问题而造成数据不一致；
- 问题：在只有时间表、地点表的情况下难以确保不会出现同一时间多门课或同一地点多门课的情况；
难点：如何修改设计，使得作品能够保证课程时间、地点之间相互不冲突；
解决办法：增加两个动态变化的冲突表分别记录所排课程的时间信息与地址信息。（这里存在一个疑惑，详见：三、个人项目感悟-存在的疑问-2）
- 问题：分步执行带来的同一对象在不同场景的不同抽象，导致这些属性难以进行统一约束，例如最初在设计时将专业负责人、教务老师均作为属性，仅将教师作为实体，但实际上前两者也属于教师；
难点：实体虽然有不同的抽取属性的方法，但仍然属于同一实体，应该如何统一；
解决方法：将专业负责人、教务老师、教师抽象为“职工”实体，统一约束。（这里存在一个疑惑，详见：三、个人项目感悟-存在的疑问-3）
- 问题：在最初设定主码时未考虑将工程主码与项目主码拆分，为避免过多外码组成主码而自定义了较多代码作为主码，使得用户需要输入代码，降低了可行度与界面友好程度；
难点：如何在用户不输入代码的同时确保主码的唯一，并且还要方便数据库查询；
解决方法：将自增ID作为工程主码，外码合成键作为项目主码，既能够方便数据库存储，主码自动生成也方便了用户操作，同时赋予了主码更多含义。
- 问题：学生课表单独存储将会造成大量冗余，占据大量空间；
难点：如何在不单独储存学生课表的情况下实现选课与课表展示；
解决方法：让学生选课班而不直接对表数据进行操作，并将学生课表作为凭据，通过查询实现展示。
- 问题：整个项目流程拆分过度。设计阶段由与操作人员不同，我们将：专业负责人安排课程班级和教师，教务处老师安排课程时间和地点两个步骤拆分为了两步进行，但实际上这两部分的界面高度一致，拆分为两步执行反而变得啰嗦；
难点：如何确保每个步骤都被考虑到的情况下，找到最简洁的实现路径；
解决方法：首先按照原来的思路（不同操作人员分为不同步骤）执行，确保每一步都能够单独实现，在后续页面设计阶段发现问题后返回修改。
- 问题：“讨论式合作”效率低下，造成项目进度缓慢；
难点：如何在每个人都需要发表自己思考的情况下提高讨论效率；
解决方法：先思考后交流，最好是想要分享观点的同学直接把自己的观点在ER图中表示出来，并说明理由后同学依次提问或发表意见。
三、个人项目感悟
项目收获
项目流程：
- 在确认项目流程之前必须先进行需求的分析与讨论，在实际中应该与项目相关的利益相关者（包括客户、用户、团队成员等）进行沟通和讨论，收集项目需求和期望。可以将这个步骤划分为：需求收集、需求整理和需求确认；
- 对于操作时间不同、涉及不同操作人员的步骤，应当将其划分为两个独立的步骤。后者能够体现出权限的差异和控制；
- 在IDEF1X图的设计中，无法直接体现项目流程中各步骤的先后顺序。这需要通过后期的编程来实现和控制；
- 当出现以下情况时，应当考虑增加“明细”实体：
ER图与IDEF1X图
u 实体具有多个属性：如果一个实体具有多个属性，并且这些属性可能有不同的特征或值域，可以考虑将其拆分为多个明细实体。这样可以更好地组织和管理数据，并提高数据库的灵活性和可扩展性。
u 实体具有多值属性：如果一个实体具有多个值的属性，而每个值之间又具有关联关系，可以将其拆分为多个明细实体。这样可以更好地表示属性值之间的关系，并避免重复数据的存储。
u 实体具有多对多关系：如果一个实体与其他实体之间存在多对多的关系，可以考虑创建一个明细实体来表示这种关系。这样可以将多对多关系转化为一对多关系，更好地管理和查询相关数据。
u 实体的属性具有不同的重要性或可选性：如果一个实体的属性在重要性或可选性上存在差异，可以将其拆分为多个明细实体。这样可以更好地控制属性的访问权限和数据完整性。
u 实体的属性有不同的频率或粒度：如果一个实体的属性在使用频率或粒度上存在差异，可以将其拆分为多个明细实体。这样可以更好地优化数据存储和查询性能，以及提高数据处理的效率。
但是过度拆分实体可能导致数据库结构复杂化，增加管理和查询的复杂性。
表结构设计
- 实体的命名需要规范，最好使用驼峰命名法；
- 多个外码组成的主码最好仅作为业务主码，这能够使其包含的信息更多，同时提高操作便捷性；
- 如果用外码组成的代码作为工程主码，将造成两个不良影响：
难以实现聚集索引需要代码按序排列的要求；
数据行的增加与删除将会引起叶子结点的分裂与合并，使得系统效率降低；
- 工程中需要设定种子字段作为主码。一个表的主码若由过多的外键组成，应仅仅将其作为业务主码，使用自增ID作为工程主码应以确保索引树的稳定性；（解决2中的影响①）
- 工程中须设定逻辑删除字段。只对库中数据进行插入、修改，对于需要删除的数据行只是修改标签使其在查询中不可见，以确保聚集索引树的稳定。（解决2中的影响②）。
- 数据库中冗余的不一致是通过编程中读表后再写新表来实现的；
- 将外码的功能交由程序或界面实现其制约关系，能够有效减少表连接并实现选择，同时提供了更大的灵活性、用户友好性和跨平台兼容性，从而使得数据关联的处理更加可控和可定制。
- 在表结构设计阶段要充分考虑系统的使用年份、用户量等信息，给予充足的存储空间，例如工号；
- 为了提高操作的简洁性，可以设置某些字段的默认值，例如在制作新的培养方案时，可以将其默认值设置为往届的信息，用户修改部分信息即可；
- 页面中显示的操作、实现的功能必须要与表结构相吻合，也就是说在页面设计的阶段中仍然需要改进ER图或表结构；
- 页面设计最重要的是用户友好性，这要求了登陆之后的身份自动识别、界面中使用更多的按钮、下拉选项、减少用户自己输入的情况；
- 为了提高界面的友好性，同时方便数据库中存储，可以通过数据库中的代码-字段映射或其他方法，在数据库中存代码，而在页面中显示相应的文字；
- 表结构设计中自动获取或自动生成的代码对用户是不可见的，仅用于内部查询，例如日期信息（自动获取）、考试批次号（自动生成）；
- 界面中必须有确认按钮，这个按钮相当于一个发起动作，按下后才表明选择已结束并进行了用户确认，可以将信息插入到数据库中或进行后续的操作；这样做的好处有：避免误操作、确保数据一致性；
- 认识到文档的重要性：想要文档内容清晰，不仅需要写作时思维清晰，更需要对整个项目流程十分熟悉，在编写文档的过程中既是对写作者小组作业中参与度、思考深度、项目可行度、完整度等的自我检验，也是发现思维漏洞或其他问题的有效途径；
- 重视需求：无论任何阶段、任何修改或完善都需要紧扣“需求”，这个“需求”既是项目需要实现的功能需求，也是包含友好性、可维护性等在内的项目需求；
- 互补技能与知识：小组合作使得不同成员能够共享各自的技能和知识。在团队合作中相互交流，能够更快地发现自己思维的漏洞以及不熟悉的知识点；
- 提高自我要求：在团队合作中不只是要把自己负责的部分做得出色，同时还要求任务完成的可读性要高、逻辑性要强，要方便与小组内成员沟通交流；
- 促进团队合作和沟通能力：在小组作业完成的过程中发生意见不统一是常有的事情，这要求我们学会有效地与其他成员合作、协商、解决冲突和共同制定决策，选取一个折中的办法、换取角度思考问题；
- 促进组内同学相互学习：当组内同学都为了同一个目标而努力时，在完成小组时会有比完成个人作业时更强的紧迫感、责任感，会要求自身更投入、为项目的完成做出更多的贡献；
- 如何理解“明细”实体？
页面设计
小组协作收获
项目能力
协作能力
存在的疑问
例如订单明细，既可以将其视为由于书籍信息与订单之间为多对多的关系，需要新造一张表来记录对应关系；也可以将订单与订单实体视为“主从关系”，也就是将订单视为父实体，订单明细视为子实体；还可以认为二者是不同场景下的不同单位：订单明细表是插入/删除/更新数据的单位，而订单是发布的单位。我认为为了实现对订单和订单明细之间的数据关联和查询是应该更倾向于第二种理解，这样理解正确吗？
- “冲突表”在设计阶段考虑的必要性是什么？
“冲突表”的使用寿命仅仅是在排课阶段，选课阶段与长期存储（不涉及更改课程时间的阶段）均不需要其存在，为什么不将其作为一个临时表，在检索到排课通道未关闭的情况下临时生成冲突表，检索到排课通道关闭后自动销毁呢？我认为在设计阶段考虑“冲突表”的主要意义是为其预留空间，这样的理解正确吗？
- “实体统一”的必要性是什么？
在前面将专业负责人、教务老师、教师抽象为“职工”实体的操作中实际上是为了保证数据一致性，避免键入错误，但这一操作也可以在界面中通过查询、选择两个操作完成，即在填写“专业负责人、教务老师”时直接从“教师”表中进行选择，那么在设计阶段把他们统一的必要性是什么呢？
- “学期”作为实体的必要性是什么？
“学期”只有学期号，学期名两个属性，在选课时也能通过查询属性实现筛选功能，将其作为实体是为了提高查询效率吗？
四、两种数据库技术的感悟
关系型数据库
特点在于：
- 以强存储模式实现，需预先定义表头，表头的设计好坏关系到系统使用的方便程度。
- 通过SQL实现表的增删改查，依赖于表之间做笛卡尔积，但最好不要超过三张表同时做表连接，这说明了冗余存在的必要性。
- 通过事务实现并发控制保证数据的准确性和完整性。
- 以集中式存储出发，最初的设计以单机版软件为主。
- 通过安全性、完整性、并发性、故障恢复等手段确保数据的一致性，数据库稳定、可靠。
优点在于：
关系型数据库最大的优点即能够保证数据一致性与安全性。
- 结构化查询语言（SQL）：使用SQL作为标准查询语言，具有广泛的支持和应用。SQL可以执行各种操作，如插入、更新、删除和查询数据。
- 数据一致性：使用ACID事务来保证数据一致性，即使系统发生异常或错误，也能保持数据的完整性和一致性。
- 数据安全性：提供丰富的访问控制和权限管理机制，可以对用户进行身份验证和授权，保障数据的安全性。
- 数据备份和恢复：具有可靠的备份和恢复机制，可以在系统崩溃或数据损坏时快速恢复数据。（日志实现）。
- 数据库设计简单：使用表格和键值之间的关系来组织数据，设计相对简单，易于理解和维护。
- 标准化：采用标准化的数据模型，并且支持多种标准化形式，这样数据库可以更好地与其他系统进行集成和互操作。
- 可扩展性：关系型数据库可以通过分区、复制和集群等技术来扩展容量和提高性能，以满足不断增长的数据需
弊端在于：
关系型数据库比较明显的弊端在于耗时长、并发度低，在海量数据、高并发情况的互联网状态下显然是不适用的。
- 限定数据类型：需要在设计时定义表格和列，必须明确指定每个列的数据类型，难以处理半结构化和非结构化数据。
- 处理海量数据复杂：当数据规模变得非常大时，传统的关系型数据库很难处理这些数据。通常采用分区、分片等技术来解决扩展性问题，但是这会使得数据库架构变得更加复杂。
- 并发度低：由于使用ACID事务保证数据一致性，关系型数据库并不能很好地处理高并发的情况。
- 不适合复杂查询：对于复杂的查询操作，关系型数据库的效率较低，需要进行多次JOIN或嵌套查询，增加了数据库的负担。
适用场景：
当涉及“高价值数据”、数据一致性、安全性要求较高时，或数据规模未达到“海量数据”级别时，或数据结构化时均适用关系型数据库。
非关系型数据库
特点在于：
- 每行数据之间相互割裂，无需预定义表头，但数据库无法发现插入错误，只能依靠程序员保证数据的一致性。
- 由于记录之间相互割裂（弱存储），支持分布式存储，因而在可扩展性与高并发性上表现良好，但显然无法支持表连接。
- 不支持SQL进行增删改查，市面上的非关系型数据库一般会提供自己的语法，暂未统一。
- 不使用表而是使用集合来存储数据，在形式上更加灵活。
优点在于：
非关系型数据库主要优点在于：强扩展性、支持海量数据、读写速度更快、存储容量更大、表结构可变化。
- 强扩展性：采用分布式存储方式，可以实现数据的横向扩展和分区存储。
- 海量据量处理能力：由于其支持分布式存储，非关系型数据库可实现海量数据的存储。
- 读写更高效：采用键值对和文档结构来存储数据，相比于关系型数据库，具有更高的读写性能和更低的延迟。
- 表结构灵活：非关系型数据库使用键值对作为基本数据单元，格式灵活可以存储复杂数据，适应非结构化的数据。
- 易于水平扩展：非关系型数据库采用了分片技术，可以根据数据量和性能需求，方便地进行水平扩展。
- 缺乏标准化：不同的非关系型数据库系统之间存在差异，缺乏统一的标准化和规范化，对于程序员的学习能力要求高。
- 数据一致性难以保证：非关系型数据库并不需要提前设定表头，使得其无法检查数据正确性。
- 不支持事务：这意味着无法保证数据的原子性、一致性、隔离性和持久性。
- 难以跨系统迁移：现有产品不够成熟，产品之间不能互通或移植，通用性差，在迁移和集成方面可能存在困难。
- 较低的查询性能：虽然非关系型数据库具有良好的读写性能和可扩展性，但是在某些复杂查询方面可能表现较差，例如需要多次JOIN或嵌套查询等操作。
- 缺少约束：数据之间相互独立难以实现约束。
弊端在于:
适用场景：
当涉及存储非结构化数据、“低价值数据”或需要水平扩展以支持大规模应用程序时，非关系型数据库是非常适用的。
二者相对比的感悟：
- 无论是关系型数据库或非关系型数据库都有自己的适用场景，根据需求选择合适的产品。
- 充分认识到当今社会中保持终生学习的重要性；当涉及到非关系型数据库时，不同的软件操作方式、语法也将会有差异，因而在学习中应重点掌握的是原理与设计的能力，不应拘泥于语法格式。