高中信息技术：基于罗马尼亚度假系统的数据库建模与Web应用开发教案

高中信息技术：基于罗马尼亚度假系统的数据库建模与Web应用开发教案

一、教学背景分析

（一）课程定位与价值

本项目定位于高中信息技术选择性必修课程“数据管理与分析”与“信息系统与社会”模块的深度融合实践。以构建“罗马尼亚度假系统”为驱动性任务，将抽象的数据规范、数据库原理、软件工程思维置于真实、复杂且具有国际视野的情境中。课程不仅承载关系数据库核心知识体系，更致力于通过完整项目生命周期，实现从工具操作到学科思想方法的跃升。项目历时四课时，形成“需求—建模—实现—交互”的完整逻辑闭环，是高二年级信息技术学科大单元教学与跨学科项目式学习的标杆性载体。

（二）教材分析（项目载体分析）

本设计无既定教材章节对应，系依据《普通高中信息技术课程标准（2017年版2020年修订）》自主开发的原创教学项目。选择“罗马尼亚度假系统”作为认知锚点，基于三重考量：其一，数据复杂度适中，涵盖景点、酒店、交通、订单、用户、收藏、评论等七类核心实体，实体间联系包含1∶1、1∶N、M∶N全部类型，能完整训练E-R建模与范式理论；其二，业务规则丰富，存在早鸟折扣、儿童票价、多语言导览等真实约束条件，为SQL查询与数据完整性设计提供充足梯度；其三，文化承载力强，可自然融入吸血鬼城堡、多瑙河三角洲、盐矿疗养等地理历史元素，达成技术工具与人文底蕴的双重建构。本项目打破教材中数据库部分“重语法轻设计”的窠臼，将SQL语言降维至实现工具，而将思维重心置于数据建模与系统抽象。

（三）学情分析

【基础】知识储备：学生已完成必修模块“数据与计算”，掌握二进制、字符编码、算法流程图等基础知识，能够使用Excel进行排序、筛选与简单函数计算。但此前对数据库的接触多为工具性浏览（如访问学籍系统），从未以设计者视角审视后台数据组织。多数学生能复述“数据库是存储数据的仓库”，但对关系、元组、候选码等术语存在严重混淆，将“主键”等同于Excel中的序号列。

【重要】能力水平：逻辑思维能力分化显著。约30%学生具备清晰的分类思想，能快速从文本中提取实体；约50%学生处于“具象操作依赖期”，必须借助实物卡片或白板拖拽才能完成关系映射；20%学生面对多表关联时思维容易“断线”，表现为反复修改E-R图却无法形成稳定结构。编程基础参差不齐，约15%学生参加过校际创客竞赛，具有HTML/CSS或Python基础，其余学生仅在学校统一课程中接触过Scratch或Pythonturtle绘图，对Web应用前后端协作机制几近空白。

【非常重要】认知特征与痛点：高二学生正处于皮亚杰形式运算阶段的巩固期，对“看不见”的数据关系存在认知负荷。具体表现为：难以将“用户点击收藏按钮”这一行为抽象为在“收藏表”中插入一条记录；倾向于将业务规则（如“钻石会员免退改手续费”）直接写入界面提示语，而非设计为数据库字段约束或存储过程。此外，学生对罗马尼亚的地理陌生感可能引发畏难情绪，需通过沉浸式情境将其转化为探索动机。

（四）课标对应

本设计精确对标《普通高中信息技术课程标准》以下条目：

模块2“信息系统与社会”2.1：能结合具体案例描述信息系统的组成要素，理解信息系统对人们日常生活的影响。2.4：通过搭建或模拟简单信息系统，了解信息系统的工作过程。

模块3“数据管理与分析”3.2：掌握关系数据库的基本概念，能使用SQL进行数据定义、查询、更新。3.3：通过项目实践，体验小型数据管理系统的设计与开发过程，了解数据库优化的一般方法。

学科核心素养：计算思维（形式化描述、模型抽象、问题分解）；数字化学习与创新（选用适宜工具完成数字化作品）；信息意识（主动发现数据价值，敏感于数据安全与隐私）；信息社会责任（在跨国信息系统设计中尊重文化差异与法律规范）。

二、教学目标与核心素养

（一）知识技能目标

1.【基础】准确默述关系数据库核心术语：关系、元组、属性、域、主键、外键、候选键、参照完整性，并能从罗马尼亚度假系统案例中辨识对应实例。

2.【重要】独立绘制包含至少六个实体、三种联系类型的完整E-R图，并运用五条转换规则将E-R图转化为符合第三范式的关系模式，书写规范的数据字典。

3.【重要】运用MySQL语句完成数据库的创建、表的定义与修改，针对度假系统典型业务场景编写单表查询、连接查询、嵌套查询、分组统计与带存在性判定的查询。

4.【基础】使用原型设计工具创建系统界面低保真原型，准确理解B/S三层架构中表现层、业务逻辑层与数据层的职责划分，能够用JSON格式模拟前端与后端的交互报文。

（二）过程方法目标

1.经历“用户访谈纪要→需求列表→实体识别→逻辑建模→物理实现→界面呈现”的完整软件工程还原路径，在反复迭代中内化学科思想方法。

2.通过小组协同绘制E-R图、互审SQL脚本、结对调试原型故障，发展协作建构与批判性思维。

3.面对“数据冗余与更新异常”等真实问题情境，运用规范化理论提出改进方案，形成权衡设计与优化的工程决策意识。

（三）情感态度价值观目标

4.在罗马尼亚文化语境的项目实践中，养成尊重多元文化、遵守信息法规、保护用户隐私的职业伦理。

5.经历从凌乱需求到整洁数据模型的思维跃迁，获得“化繁为简”的智力愉悦，坚定技术向善的信念。

6.在分工协作中理解个体专长与集体智慧的关系，培育互助共进的团队精神。

（四）学科核心素养细化

信息意识：能敏锐捕捉需求文档中隐含的数据依赖（如“游客希望看到酒店周边兑换点”应映射为新增实体“外币兑换点”及外键关联）。

计算思维：抽象——将“早鸟价提前30天预订”文本规则形式化为订单表“预订日期”与入住日期间隔的算法判断；分解——将系统拆解为数据存储层、逻辑处理层与呈现层；建模——用E-R图实现问题域的结构化映射。

数字化学习与创新：灵活选用Draw.io、MySQLWorkbench、墨刀等数字工具，形成从建模到原型的多平台协同工作流；创新性整合外部开放数据（如罗马尼亚世界遗产名录API）作为系统特色功能。

信息社会责任：在设计用户表时引入隐私保护设计思想，如密码字段加密存储、用户权限分级；讨论欧洲通用数据保护条例对系统功能界面的影响，如必须包含“删除我的数据”按钮。

三、教学重难点

（一）【重要】【基础】重点

1.实体与属性的精准辨别：能够在景点介绍段落中正确区分“山脉名称”（属性值）与“山脉实体”（若需独立管理海拔、开放季节等信息时，应提升为实体）。

2.E-R图规范绘制：矩形、椭圆、菱形、连线及联系类型的标准标注，避免将联系直接连在属性上。

3.SQL核心语法：CREATETABLE（含数据类型与约束）、SELECT（FROM-WHERE-GROUPBY-HAVING-ORDERBY）标准结构，INNERJOIN与LEFTJOIN的语义差异。

4.原型界面与数据字段的一一对应：界面中的每个静态文本或动态占位符均能找到其所属表及字段。

（二）【非常重要】【难点】【高频考点】

5.M∶N联系的拆表处理与复合主键选择：例如“游客收藏景点”需创建独立收藏表，确定采用（游客ID，景点ID）作为复合主键还是增设自动编号代理主键，辨析两种设计对查询性能与数据冗余的影响。此为历年学业水平考试综合性大题的高频失分点。

6.第三范式的判别与分解：给定包含传递依赖的关系模式（如酒店表含城市名称、城市人口、城市等级），识别其中部分依赖与传递依赖，无损分解至3NF。

7.业务规则的形式化表达：将自然语言约束（“同一游客在同一景点每日仅可预订一张门票”）转化为唯一索引（UNIQUE约束）或触发器逻辑，突破“重查询、轻约束”的思维定式。

8.前后端分离思想的模拟理解：在不编写服务器代码前提下，理解HTTP请求如何携带参数，服务器如何返回JSON数据，原型工具中如何通过变量绑定模拟异步数据刷新。

四、教学方法与策略

本设计遵循建构主义与认知学徒制模型，实施“双主三阶”混合式教学策略。双主：教师主导项目骨架与关键节点，学生主体进行知识建构与创意生发。三阶：第一阶“扶”（教师提供高度结构化的半成品数据库与残缺原型，学生完成补全任务）；第二阶“放”（给定核心需求列表，小组协作完成完整E-R图与主要查询）；第三阶“创”（鼓励高水平小组引入罗马尼亚特色元素，如盐矿疗养预约、吸血鬼城堡夜间开放专场）。全课贯穿认知冲突策略，如故意提供包含更新异常的冗余表供学生批判；采用出声思维策略，教师边绘制E-R图边口述“为什么这里我选择用菱形而非直接在实体上加属性”，将内隐知识外显化。同时渗透跨学科整合：地理学科（罗马尼亚喀尔巴阡山脉地形对景点分布的影响）、历史学科（布朗城堡与德古拉传说的文化符号化）、经济学科（基于竞争环境的酒店动态定价模型），实现信息技术工具性与人文性的统一。

五、教学环境与资源准备

硬件环境：多媒体计算机网络教室，配备教师控制台与电子广播系统，学生机安装Windows10操作系统，每机均预置MySQL8.0社区版及图形化工具MySQLWorkbench8.0，确保TCP/IP本地连接畅通；服务器端预置已部分建表的空白数据库RomTravel_Starter，包含空的users表和spots表结构，用于第一课时快速演示。

软件工具：Draw.io（浏览器版，登录即用，支持实时协作光标）；墨刀（Web端，使用教育版账号创建团队项目）；VSCode（安装Prettier插件用于格式化JSON片段）；内网协作平台（仅用于小组提交作业链接，不涉及公网）。

学材资源：自制“罗马尼亚旅游局客户访谈纪要（模拟版）”PDF，内含五份典型游客画像及痛点描述；微课视频《六步法：从E-R图到完美SQL》置于教学局域网共享；错误集锦诊断卡（纸质活页），收录历届学生典型谬误如“将订单表的外键设为NOTNULL导致新订单必须关联已存在游客”等；罗马尼亚旅游宣传片节选（已剪辑为3分钟无版权争议片段）。

六、教学实施过程

（一）第1课时：系统认知与需求分析——从异域风情到数据抽象

创设情境，激活前备经验。教师播放罗马尼亚布拉索夫布朗城堡4K航拍视频，无人机镜头掠过锯齿状塔楼与浓密森林，画外音加入德古拉传说轻述。视频骤停，教师发问：倘若你是赴罗自由行的中国游客，最渴望通过一款度假App获得哪些服务？此问以情感冲击降低认知门槛，学生迅速迸发答案：中文导览、特色餐厅预订、防偷窃提示、吸血鬼城堡夜游购票。教师将答案实时键入思维导图根节点，故意不整理，形成“需求毛坯”。此环节设计意图在于唤醒生活经验，建立“技术服务于文化体验”的价值取向。【基础】

分组模拟调研，提炼需求。教师下发模拟版“客户访谈纪要”，文档虚构了五类游客：摄影发烧友（需求：日出日落时间、制高点机位）；亲子家庭（需求：儿童游乐设施、婴儿车租赁）；穷游背包客（需求：青旅比价、拼车信息）；奢华疗养客（需求：盐矿SPA预订、私人导览）；文化研究者（需求：教堂开放时间、宗教礼仪禁忌）。小组四人依据角色扮演，抽取身份卡，以第一人称补充至少三条个性化需求。教师巡堂观察到多数小组直接将访谈文本为需求列表，于是及时介入，引导转换句式：将“我想知道附近哪有中餐馆”转化为“系统需支持基于当前位置的半径500米内餐饮检索功能”。此环节是信息意识到计算思维的第一次摆渡，将用户愿望转化为系统功能，并将功能初步映射为可能的数据项（中餐馆→名称、地址、菜系、评分）。【重要】

抽象核心数据实体。教师提出经典问题：请从刚才整理出的所有需求句子中圈出所有名词。学生很快圈出“游客”“景点”“酒店”“订单”“评论”“收藏”“导游”“车辆”“支付”等。教师追问：这些名词是否都要成为数据库中的表？引出实体筛选原则——凡需要独立存储多条特征信息的名词倾向为实体，凡仅描述其他事物性质的名词倾向为属性。例如“票价”依附于景点，不必单独成表；但“票价历史记录”因需存储不同日期的价格变动，则应提升为实体。此处理解坡度较大，约半数学生面露困惑，教师补充实物类比：身份证是你的属性，但公安局里所有身份证信息汇总表就是实体。此环节结束时，全班形成公共实体清单：用户、景点、酒店、交通线路、订单、评论、收藏夹。【非常重要】

契约作业与预告。各组为本系统命名并撰写三句推介语，要求必须包含一个罗马尼亚专属文化符号。作业提交至局域网共享文件夹，下节课将从中抽取优秀案例作为E-R图建模素材。

（二）第2课时：数据建模——E-R图与关系模式的精工细作

温故知新与错误辨析。教师展示一幅故意绘错的E-R图草稿：将景点实体包含“所在城市”属性直接写作字符串，并另有一个“城市”实体孤悬图中，二者无连线。请学生诊断。很快有学生指出若城市需存储人口、面积、市长等信息，则必须作为实体并与景点建立“位于”联系。教师顺势强化核心原则：属性不可再分，实体必有联系。【高频考点】

核心讲授：E-R图三要素与绘制规范。教师以“景点—城市—所属国家”三级隶属为例，屏幕录屏实时绘制。强调矩形仅出现于独立存在对象，椭圆必须依附于某矩形或菱形（弱实体的椭圆用双线椭圆），菱形必须连接两个及以上矩形。特别警示：绝不允许将菱形符号置于联系线上方以外的位置，杜绝“悬浮菱形”。针对联系上的属性，如预订联系中的“下单时间”“预订状态”，必须挂接在菱形上，不可错挂在游客或酒店实体。此时下发Draw.io团队链接，每组获得一个共享白板，教师推送空白E-R画布，内置半成品实体框（用户、景点、酒店）作为脚手架。

分组绘制局部E-R图。此环节持续20分钟，是思维可视化高峰。第一组迅速确定了用户与订单的1∶N联系，但处理订单与景点关系时产生争执：一张订单可包含多个景点吗？教师介入引导阅读需求——系统支持打包购买“城堡联票”，因此订单与景点为M∶N，需拆出中间实体“订单明细”。第二组在绘制“酒店—设施”时陷入僵局：酒店拥有游泳池、健身房、停车场，是将设施作为酒店的多值属性还是独立实体？教师引导思考：是否需要查询“拥有室内恒温泳池的酒店”？如是，则设施应独立为实体。这一决策训练是数据建模的核心素养。教师记录典型问题，不直接给答案，而是反问各组的查询需求。【非常重要】

关系模式转换五条黄金法则。教师精炼讲解：1∶1联系可将任一方主键放入对方；1∶N将一方主键放入多方；M∶N新建关系表包含双方主键；多元联系转换为独立表；弱实体需携带依赖表主键。学生对照法则，将本组E-R图逐步文本化，形成关系模式草案。此时【难点】爆发：几乎所有小组在处理“用户收藏景点”这一M∶N联系时，自动生成收藏表（用户ID，景点ID），但对是否添加“收藏时间”字段意见不一。教师启发：收藏时间究竟是联系的属性还是收藏实体的属性？从业务视角，用户在乎收藏顺序，故应加入时间戳。同时抛出代理键问题：采用复合主键（用户ID，景点ID）虽能唯一标识，但若有第三方服务需引用此收藏记录（如推送降价通知），长复合主键不便，是否应增设自增ID作为主键？此问题暂不强行统一，留作课后辩论。

范式诊断与优化。教师呈现一段异常关系模式：酒店（酒店ID，酒店名，城市ID，城市名称，城市人口，城市等级）。引导学生发现城市人口依赖于城市ID，而非酒店ID，存在传递依赖，将导致城市人口修改时必须遍历所有该城市酒店。学生动手分解至3NF，形成酒店表与城市表。随后自查本组模式，找出违反范式之处。第六组发现其交通表同时存放了航空公司名称、总部所在地，而总部地址与航班号无直接依赖，迅速拆分。此环节使学生亲历“设计—发现问题—重构”的工程循环，对范式的理解从记忆条文升维为解决问题的工具。【重要】

（三）第3课时：数据库实现——从建模到物理部署

DDL建表实战。教师广播共享MySQLWorkbench界面，以公共实体清单中的“用户表”为例，逐行书写CREATETABLE语句。强调VARCHAR与CHAR的适用场景（用户名用VARCHAR(50)，固定编码如性别可用CHAR(1)）；数值型INT与DECIMAL的选择（货币用DECIMAL(10,2)避免浮点误差）；日期时间类型取舍（生日用DATE，订单生成用DATETIME）。约束定义环节密集设问：为什么手机号字段要用UNIQUE？（避免一个手机号注册多个账号）为什么用户ID设置AUTO_INCREMENT？（代理键简化引用）外键定义时ONDELETERESTRICT与CASCADE分别适用于何种业务？（重要订单禁止级删，收藏夹可级联删）学生实时在自己的MySQL中跟随创建，部分学生因大小写规范问题报错，教师借此强调SQL书写习惯——关键字大写、表字段小写蛇形。【基础】

测试数据植入。学生使用INSERT语句向各表填充5至10条模拟数据。为提升趣味，教师鼓励以罗马尼亚真实信息填充：景点名称写入“佩莱斯城堡”“萨利纳盐矿”，价格字段填入“45”“89”列伊。学生发现货币符号问题，引出字符集设置，教师补充CHARSET=utf8mb4以支持emoji及生僻地名。

【重要】查询任务群闯关。任务一（单表）：从景点表中筛选出票价低于50列伊且开放时间包含“夜间”的景点，按票价升序排列。任务二（连接）：查询预订了“吸血鬼城堡夜游”项目的游客姓名、联系电话及预订人数。任务三（分组）：按酒店所在城市统计平均房价，仅显示平均房价高于300列伊的城市，并按均价降序输出。任务四（子查询）：找出从未产生过投诉记录的酒店名称，需使用NOTEXISTS。此时课堂进入高度专注状态，教师通过MySQLWorkbench的客户端连接功能随机抽取学生屏幕分享，展示其SQL语句，集体评判优劣。一名学生使用IN替代EXISTS，虽结果正确但教师指出当子查询表极大时EXISTS性能更优，自然引入查询优化意识。【高频考点】

【难点】数据操作与完整性约束。模拟客诉场景：游客因行程变更要求取消三天后的订单。学生需书写DELETE语句删除订单主表。但多数小组立即遇到外键约束失败——订单明细表仍保留对订单ID的引用。教师引出级联删除：ALTERTABLE订单明细ADDCONSTRAINTfk_od_orderFOREIGNKEY(order_id)REFERENCES订单(order_id)ONDELETECASCADE。进而追问：所有删除都该级联吗？假设删除景点，是否自动删除该景点的所有历史订单？学生辩论后达成共识：订单是业务档案，不应物理删除，而应逻辑标记“已取消”。此环节使学生深刻体会数据库设计不仅是存储，更是对商业规则的预先规制。

拓展任务：索引体验。学有余力小组在订单表下单时间字段创建索引，并用EXPLAIN对比带WHERE条件查询的执行计划，观察possible_keys与rows的变化。尽管不要求完全理解B+树原理，但学生直观感受到索引对海量数据检索的意义。

（四）第4课时：Web界面与数据交互原型——让数据被看见

三层架构可视化演绎。教师播放自制交互动画：用户在浏览器输入网址敲击回车，DNS解析、TCP连接、HTTPGET请求、服务器查询数据库、拼装HTML、渲染页面。重点停顿于服务器从数据库取回记录集并转为JSON的瞬间。学生抽象出“数据一直在流动”的本质。教师声明本课不写后端代码，而是用原型工具模拟数据流动的形态与格式。

【非常重要】界面低保真原型设计。各小组基于前三课时确定的关系模式字段，在墨刀中设计三个核心页面：首页需展示罗马尼亚热门目的地轮播图、全局搜索入口；景点详情页需布局景点名称、高清大图、票价、开放季节、简要介绍、用户评分；订单填写页需包含日历控件、成人儿童人数选择、优惠码输入框、总价实时计算展示。教师重点巡查字段映射：是否界面上的“景点名称”文本确实来源于数据库sight_name字段？有无杜撰数据库根本不存在的字段（如“虚拟现实导览”）？发现一组在详情页设计“周边兑换点推荐”，但数据库尚无外币兑换点实体，教师引导其思考若此功能确属必要，应如何回退修改E-R图。这形成了宝贵的闭环修正意识。

数据交互模拟。教师分发模拟JSON数据文档：{“sight_id”:101,“sight_name”:“布朗城堡”,“price”:“75.00”,“avg_score”:4.7,“comment_count”:128}。学生任务：在墨刀原型中创建动态面板，将景点卡片图片下方文字设置为“绑定变量”，变量的样本值引用上述JSON字段。点击卡片时跳转详情页，详情页对应字段自动填充。此环节不涉及真实Ajax请求，而是通过原型工具内置的“中继器”或“全局变量”实现状态保持。学生第一次亲历“数据驱动界面更新”，许多学生发出“原来App是这样工作的”感叹。

【重要】系统联调与电梯演讲。各小组将E-R图最终版、关系模式数据字典、核心SQL脚本、墨刀原型查看链接汇总至一张在线协作卡片。每组推选发言人，在2分钟内面向全班介绍本组系统最独特的罗马尼亚元素与对应的数据建模创新点。第一组在订单表中增加“文化偏好”字段，可存储“素食”“无障碍通道”等特殊要求，并在原型中展示筛选结果；第三组利用M∶N自关联在景点表实现“周边推荐”功能。教师即时点评，聚焦于“数据如何支撑特色功能”，而非界面美观度。

结课仪式。教师总结四课时的思维进化路径：从杂乱无章的用户愿望→结构清晰的E-R图→严谨约束的SQL表→可交互的原型界面，这正是信息技术学科“化信息为知识，化知识为智能”的典型范式。布置延展作业：撰写个人反思日志，主题为“我在度假系统构建中遭遇的最大数据建模困境及其突破”。

七、教学评价设计

（一）过程性评价（60%）

1.E-R图迭代成长记录（15%）：以Draw.io历史版本记录为依据，评价初始草稿与终稿的差异，重点观察学生能否自主发现并修正“冗余属性”“悬空联系”“主键缺失”三类典型缺陷。【重要】

2.SQL脚本运行测试（20%）：教师搭建自动评判环境，导入各组SQL文件，运行预设的10个验收查询用例，统计通过率。同时人工抽检代码风格：关键字大写、缩