简介本资源是山东科技大学计算机科学与技术专业《数据库系统概论》课程设计的完整实验报告面向数据库初学者、本科课程设计实践者及DBMS原理学习者聚焦数据库表级操作的核心实现能力培养。报告详述了基于C语言开发简易DBMS的过程重点实现CREATE TABLE与ALTER TABLE语句解析、表结构内存建模、磁盘持久化存储table.txt、命令行与图形界面双交互模式以及程序流程图与物理存储结构设计。资源为1个408KB的Word文档.doc内容涵盖任务书、需求分析、设计思想、数组式表元数据管理方案、SQL语句关键词识别逻辑、表信息保存/加载机制及完整代码实现思路结构完整、步骤清晰、理论结合实践。已有934人学习下载适合理解关系型数据库底层建表与改表机制、夯实数据库系统实现基础的本科生与自学者。1. CREATE TABLE 不是语法糖它在内存里建了一座“表结构档案馆”而 ALTER TABLE 是在给这座馆做动态装修你敲下CREATE TABLE students (id INT PRIMARY KEY, name CHAR(20))终端回显“建表成功”——但真相是没有磁盘文件被创建没有页表被分配甚至没有一行真正的数据被写入你只是往一个三维字符数组里塞了 6 个字符串外加一个整型计数器加了 1。这份来自山东科技大学 2012 年的课程设计报告用不到 2000 行 C 代码把数据库最核心的 DDL数据定义语言机制拆解成可触摸、可调试、可打断点的内存操作。它不模拟 B 树不实现 WAL 日志不处理并发锁但它精准复现了 DBMS 启动时加载元数据、解析 SQL 语句、校验语法合法性、映射字段到内存结构、持久化为文本快照这一整条「元数据生命周期」。为什么值得搞懂因为所有工业级数据库——从 SQLite 到 PostgreSQL——在pg_class或sqlite_master表里存的本质上就是这份tableName[number][MAX]、fieldName[number][i][MAX]的升级版而你每次ALTER TABLE ADD COLUMN时后台真正发生的不过是把新字段 append 到那个二维字段数组末尾再重写一次table.txt。这不是玩具这是数据库的「元数据内核」在裸机上的最小可行实现。2. 表结构不是抽象概念它是被硬编码进三维数组的物理布局且每个维度都有明确语义边界2.1 三维数组即元数据模型tableName[LEN][MAX]定义了“库”的容量上限设计者用char tableName[LEN][MAX]存储所有表名其中LEN是预设常量报告中未给出具体值但从上下文推断应为 10–20MAX是单个表名最大长度如 32。这不是随意选的——它直接对应数据库系统中catalog 表的行数上限。当number当前表总数达到LEN时SQL_CREATE()中的number就会越界导致后续tableName[number]写入非法内存。这暴露了一个关键事实该设计将“数据库实例”等同于一个固定大小的表容器而非可动态扩容的哈希表或链表。工业级系统如 MySQL 的information_schema.TABLES使用 B 树索引支持百万级表而这里用数组意味着它只服务于教学场景下的「小规模元数据管理」其价值恰恰在于让你看清当系统说“支持 N 张表”时底层可能就是一块malloc(sizeof(table_meta) * N)的连续内存。// 源码节选表名存储结构声明隐含在报告第 2 页 char tableName[LEN][MAX]; // LEN: 最大表数量MAX: 单表名最大字节数 char fieldName[LEN][LEN][MAX]; // 第一维表索引第二维字段序号第三维字段名字符串 char fieldType[LEN][LEN][MAX]; // 同上存 int、char 等类型名 char fieldCondition[LEN][LEN][MAX]; // 存 primary key、not null 等约束字符串提示fieldName[LEN][LEN][MAX]的第二维LEN实际是「单表最大字段数」与第一维LEN最大表数共用同一常量这是典型的学生项目权衡——用空间换逻辑简洁。真实 DBMS 会为每张表单独分配字段数组避免跨表内存浪费。2.2 字段类型解析tolower() 字符串比对是 SQL 类型系统最原始的“模式匹配”SQL_CREATE()函数中对字段类型的识别完全依赖strcmp(temp, type[j]) 0其中type[5] {char,int,float,double,date}。注意两个细节temp是通过tolower(SQL[i])逐字符转小写后拼接的这意味着输入CHAR(10)、Char(10)、cHaR(10)均能被识别——它实现了 SQL 标准中“关键字不区分大小写”的语义但仅限于这 5 个硬编码类型类型后紧跟的(10)被单独提取并存入f_t_len[number][num]格式为(10)字符串而非整型10。这说明长度信息未参与类型校验仅作字符串标记。当你输入char(abc)程序会因abc非数字而报错见第 8 页源码但不会检查char(1000)是否超出MAX限制——因为f_t_len只是用于显示不参与后续存储或查询逻辑。2.3 约束条件的“状态机式”解析primary key被拆成两步校验暴露语法树构建雏形约束解析逻辑藏在SQL_CREATE()的嵌套if-else中先读取condition[j]字符串如primary若匹配primary则继续向前读取下一个 tokenkey并二次比对仅当两者连续出现才将fieldCondition[number][num]设为primary key。这本质上是在手动模拟LL(1) 语法分析器的前瞻符号lookahead行为。真实数据库使用 Yacc/Bison 生成语法树而这里用for(; SQL[i] ; i);移动指针 strcmp()判断完成了最简化的“token 流遍历”。更关键的是fieldCondition数组只存字符串不建立约束与字段的关联索引。例如PRIMARY KEY (id, name)这种联合主键无法表达因为代码中fieldCondition是按字段顺序一对一存储的没有“指向其他字段的指针”或“约束作用域列表”。2.4 物理存储结构table.txt不是数据库文件而是元数据快照的纯文本序列化协议报告第 3 页明确说明“在对表进行所有的操作之后将表信息存储到table.txt中前首先将表中数据清除再重新存储”。这意味着table.txt不支持增量更新每次保存都是全量覆盖文件格式是扁平化、无分隔符的空格分隔序列见Read()函数中ioFiletableName[number]的连续读取没有版本号、时间戳、校验和无法检测文件损坏或并发写入冲突。这种设计直指教学本质让学生理解「持久化 把内存状态转成可读文本」。当你看到table.txt内容类似students 2 id int primary key name char(20) not null courses 3 cid int unique cname char(50) NULL credits int NULL你就该意识到这正是 PostgreSQL 的pg_attribute表在文本层面的镜像——只是少了attrelid,attnum,atttypid等系统列多了人工可读的约束描述。3. SQL 解析不是黑匣子手写词法分析器如何用指针偏移和状态标志应对语法歧义3.1 空格跳过与 token 边界判定for(; SQL[i] ; i);是最朴素的词法扫描整个解析器没有使用正则表达式或状态机而是靠for循环手动移动字符指针i。例如for(i0; SQL[i] ; i);跳过开头空格for(j0; SQL[i]! SQL[i]!;; i,j)提取连续非空格/非分号字符为 tokenfor(; SQL[i] ||SQL[i],; i);跳过逗号和空格。这种写法看似低效却完美暴露了SQL 词法单元token的物理边界定义以空格、逗号、分号为分隔符。当你输入CREATE TABLE students(id INT)多空格它仍能正确切分因为SQL[i]! 条件确保了 token 提取的鲁棒性。但隐患也在此若用户输入CREATE-TABLE连字符-会被当作table的一部分导致strcmp(temp,table)!0报错——这正是词法分析需处理的“非法字符”问题而本设计选择忽略交由用户保证输入规范。3.2 类型长度校验(10)中的数字被转为 ASCII 码存储埋下类型安全漏洞看这段关键代码第 9 页if(SQL[i]48||SQL[i]58) { flag0; break; } // 检查是否为数字字符 else { f_lengthf_length*10(SQL[i]-48); } // 将字符0-9转为整数 ... f_t_len[number][num][1] f_length48; // 再转回ASCII字符f_length是整型变量用于计算(10)中的10但最终存入f_t_len的却是f_length48即1的 ASCII 码。这意味着若f_length10f_t_len[...][1]存的是字符1ASCII 49而非数字10当后续需要显示字段长度时直接printf(%s, f_t_len[...])即可输出(10)但若未来要基于长度做内存分配如malloc(f_length)必须重新解析f_t_len字符串——这违背了“数据与表示分离”原则是典型的学生项目技术债。3.3 主键校验的“两阶段确认”为何PRIMARY KEY必须拆成primarykeySQL_CREATE()中对主键的处理if(strcmp(condition,primary)0) { for(; SQL[i] ; i); for(j0; SQL[i]! SQL[i]!,; i,j) temp[j]tolower(SQL[i]); temp[j]\0; if(strcmp(temp,key)0) fieldCondition[...]primary key; }这并非冗余设计。试想输入CREATE TABLE t(a int primary, b char(10));—— 若不校验keyprimary会被误判为主键而实际它是字段a的别名虽 SQL 不允许但解析器需防错。这种“关键词连续性检查”是防止语法歧义的最低成本方案。工业级解析器会构建 AST抽象语法树将PRIMARY KEY作为单一 token而这里用两次strcmp是以可读性换健壮性让你一眼看懂PRIMARY KEY在内存里就是两个相邻字符串。3.4 ALTER TABLE 的“表存在性检查”线性搜索tableName[]揭示 O(n) 元数据查找代价SQL_ALTER()中查找目标表的代码第 12 页for( al_num 0; al_num number; al_num) { if(strcmp(tableName[al_num],alterName) 0 ) break; } if(al_num number) { /* 表不存在 */ }number是当前表总数al_num是循环变量。这意味着查找第 1 张表耗时 O(1)查找第 N 张表耗时 O(N)没有哈希索引没有二叉搜索树纯靠暴力遍历当number1000时平均查找成本 500 次strcmp而每次strcmp最坏 O(32) 字符比较。这解释了为何真实数据库的information_schema表必须建索引——pg_class.relname有 B-tree 索引确保SELECT * FROM pg_class WHERE relnamet是 O(log n)。而这份设计故意保留 O(n) 复杂度迫使你思考当元数据规模增长时什么数据结构能替代数组4. 常见问题排查5 个真实踩坑现场每个都对应一个数据库原理知识点4.1 现象输入CREATE TABLE t(id INT, name CHAR(20) NOT NULL);报错 “约束条件NOT NULL有误”原因解析器将NOT NULL视为两个独立 token但代码中condition[j]只读取第一个单词NOT随后strcmp(condition,not)0成立进入not null分支但此时SQL[i]指针已停在空格后temp读取NULL时因SQL[i] 导致j0temp[0]\0strcmp(temp,null)0永远为假。解决修改NOT NULL解析逻辑在strcmp(condition,not)0后强制跳过空格并读取下一个 token且要求其严格等于null注意小写。4.2 现象创建表t(id int primary key)成功但SELECT * FROM t报错“表不存在”原因SQL_CREATE()将primary key存入fieldCondition但Read()函数在从table.txt加载时对primary的处理是fieldCondition[number][i] primary key第 5 页而fieldCondition是char数组primary key是字符串字面量赋值时只存首地址导致后续printf输出乱码或崩溃。解决Read()中必须用strcpy(fieldCondition[number][i], primary key)替代直接赋值确保字符串完整拷贝。4.3 现象多次运行程序后table.txt文件末尾出现乱码或重复表信息原因Read()函数用while(!ioFile.eof())循环读取但eof()只在尝试读取失败后置位。当文件最后一行无换行符时ioFiletableName[number]成功读取后eof()仍为 false循环再次执行ioFilePro_Num[number]失败但number已自增导致后续数组访问越界。解决改用if (ioFile tableName[number])作为循环条件确保每次读取成功才处理。4.4 现象输入ALTER TABLE t ADD age INT NOT NULL新字段age的约束显示为NULL原因SQL_ALTER()的ADD分支中约束解析逻辑缺失。源码只实现了ADD字段名和类型但未处理NOT NULL等约束第 13 页代码截断处。fieldCondition数组未被赋值保持初始化值可能是空字符串或垃圾值。解决在ADD分支内复制SQL_CREATE()中的约束解析逻辑提取NOT NULL并存入fieldCondition[al_num][Pro_Num[al_num]]。4.5 现象表名含空格如my table创建时报错“表名有误”原因SQL_CREATE()提取表名时用for(j0; SQL[i]! SQL[i]!;; i,j)遇到空格立即终止my被当作表名table被当作下一个 token 导致语法错误。SQL 标准允许反引号或双引号包裹含空格标识符如my table但本设计未实现。解决增加引号检测逻辑——若SQL[i]或SQL[i]则向后查找匹配引号并将中间内容作为表名跳过内部空格。5. 内存布局即架构从char tableName[LEN][MAX]到现代数据库元数据服务的设计取舍这份课程设计最震撼我的地方是它用最直白的 C 数组把数据库的「元数据平面」metadata plane具象成了可触摸的物理存在。tableName[LEN][MAX]不是抽象类而是sizeof(char) * LEN * MAX字节的连续内存块fieldType[LEN][LEN][MAX]的三个维度分别对应「实例-表-字段」三级命名空间。这种设计强迫你面对一个根本问题当系统需要管理 10 万张表、每张表 200 个字段时这个三维数组会吃掉多少内存粗略计算LEN100000,MAX64,sizeof(char)1→tableName单独占用 6.4MB而fieldName需100000 * 200 * 64 1.28GB——这已经超出多数嵌入式设备内存更别说fieldCondition的额外开销。于是你立刻明白PostgreSQL 为何要把pg_class表元数据和pg_attribute字段元数据拆成两张独立系统表用 OID 关联而非嵌套数组SQLite 为何用sqlite_master表的sql字段存储建表语句原文而非解析后的结构体——它们都在用空间换时间用磁盘换内存用关系模型换数组索引。更值得玩味的是持久化策略。table.txt的“全量覆盖写入”看似简陋实则暗合现代云数据库的「不可变基础设施」思想。AWS Aurora 不直接修改页而是写入新的日志记录Snowflake 将元数据存于 S3每次变更生成新版本对象。区别只在于学生用fopen(table.txt, w)覆盖文件工业级系统用PUT s3://bucket/metadata/v2.json上传新对象。底层逻辑一致元数据变更 生成新快照而非原地修改。这让我想起某次线上事故DBA 手动编辑pg_class系统表导致集群崩溃。事后复盘发现他忘了pg_class的修改必须通过UPDATE语句触发 WAL 日志和缓存失效而直接UPDATE pg_class SET relnamenew WHERE oid123绕过了事务层——这和table.txt缺少校验和、无法回滚的本质相同当元数据失去原子性和一致性保障整个数据库就变成一座纸牌屋。从那以后我每次设计元数据模块都强制走一遍「三问」这个结构在内存里占多少字节用sizeof()和pahole验证它的序列化格式能否被人类读懂如 JSON/YAML而非 Protobuf 二进制如果进程崩溃在写入一半时元数据是否处于可恢复的一致状态用rename()原子替换或 WAL 预写日志这份 2012 年的课程设计没有用任何高深算法却用最笨的指针操作和数组索引把数据库最坚硬的内核——元数据管理——剥得一丝不挂。它不教你如何造轮子而是逼你亲手拆解轮子的每一颗螺丝。希望帮到你。本文还有配套的精品资源点击获取