简介这份资源是山东科技大学信息科学与工程学院计算机科学与技术专业《数据库系统概论》课程设计的实验报告面向正在学习数据库系统实现、需要完成课程设计或希望理解DBMS底层机制的高校学生。报告围绕“实现一个简单的DBMS——创建表和修改表”展开完整呈现了CREATE TABLE与ALTER TABLE语句的解析思路、表物理存储结构设计、命令行与图形化界面两种交互方式以及新建表、修改表、显示表信息、保存退出四个功能模块的实现过程并附有需求分析、设计思想与程序流程图说明。压缩包内为1个doc文档约408KB内容涵盖任务书、设计要求、参考资料与设计步骤结构完整可直接作为课程设计报告的写作范本与实现参考。目前已有934人学习下载适合需要借鉴选题思路、报告框架与表结构存储方案的读者参考使用。1. 手写一个 DBMS 的表结构管理为什么“建表”比“查表”更接近数据库的内核很多人第一次接触数据库注意力都在SELECT上觉得查询才是数据库的灵魂。可如果让你从零实现一个 DBMS最先卡住你的往往不是查询而是CREATE TABLE——一条建表语句背后藏着词法切分、类型系统、约束校验、元数据持久化四件事任何一件没想清楚后面ALTER TABLE就会连环翻车。这份课程设计资源做的事情很朴素用 C 语言实现一个能创建表、修改表、读取表、保存表的迷你 DBMS把 SQL 语句从字符串变成磁盘上可复现的结构描述。它值得搞懂的地方在于表结构管理是数据库的“元数据层”是系统目录system catalog的雏形理解了这一层你再看真实数据库里information_schema那些表就不会觉得是玄学。下面从它怎么解析语句、怎么存结构、怎么改结构三个层面拆开讲。2. SQL 语句解析为什么手写解析器要先做“关键词确认”再做“字段提取”2.1 从字符串到 token逐字符扫描的取舍这份实现没有用 lex/yacc也没有正则而是最原始的手写扫描跳过空格、按分隔符切词、用tolower统一大小写。看SQL_CREATE的开头几行就能明白它的思路——先把第一个词读出来和create比对对了再读第二个词和table比对两级确认都通过才进入表名提取。这种“逐段确认”的写法看起来笨但它把错误定位做到了语句级别用户把create拼错程序直接告诉你create有误而不是笼统报一个语法错误。for(i0; SQL[i] ; i); // 跳过前导空格 for(j0; SQL[i]! SQL[i]!;; i,j) { temp[j]tolower(SQL[i]); // 统一转小写避免大小写差异 } temp[j]\0; if(strcmp(temp,create)!0) // 第一级确认动词 { error0; printf(\n 你输入的create有误请重新创建!\n); }这里的关键设计是用状态推进代替一次性解析。每确认一个关键词指针i就往前推一段后面的逻辑只关心“当前位置之后是什么”不需要回头。常见的实现思路是维护一个游标加一个当前 token 缓冲区读到分隔符就结算一次。这种写法在字段数量少、语法固定的场景下足够用代价是每加一种语法就要多写一段扫描逻辑扩展性差——这也是为什么真实数据库最终都会走向表驱动的词法分析器。2.2 字段三元组的提取名字、类型、长度怎么拆进入字段列表后代码用一个do-while循环反复提取“字段名 类型 可选长度 可选约束”。字段名读到空格为止类型读到空格或逗号为止然后拿类型去和{char,int,float,double,date}这个白名单比对。注意它用了一个并行数组Type1 {C,I,F,B,D}存类型首字母比对成功后只记首字母这是典型的“用编码压缩存储”的做法——元数据里存一个字符比存整个类型字符串省空间读取时再映射回来。长度提取有个细节值得说只有char、float、double才要求读长度int和date直接跳过。代码里判断f_TypeC||f_TypeF||f_TypeB才进入长度解析并且逐字符检查必须是数字SQL[i]48||SQL[i]58就置flag0。这里其实埋了一个隐患长度是逐位累加f_lengthf_length*10(SQL[i]-48)但最后存进f_t_len时只写了f_t_len[number][num][1] f_length48也就是只保留了个位数。两位数的长度比如char(50)会被截断成单个字符。这是手写解析里很常见的翻车点——累加逻辑对了落盘逻辑没跟上。2.3 约束条件的识别primary key、unique、not null 的分支处理约束解析是这段代码里分支最多的地方。读到约束词后先看是不是primary是的话必须再读一个key才算完整是unique就直接记是not就必须跟一个null。三个分支各自带错误提示任何一个不匹配都置error0并break。这种“前缀词 后续词”的两段式校验本质上是在没有语法分析器的情况下手工模拟产生式规则。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[number][num] primary key; // 注意这里赋的是字符串字面量地址 else { error0; printf(\n 你输入的KEY有误...\n); break; } }这里有个 C 语言层面的坑fieldCondition声明为char fieldCondition[LEN][LEN][MAX]是三维字符数组但赋值时写的是fieldCondition[number][num] primary key把一个字符串字面量的地址赋给了一个char[LEN]类型的数组元素。这在严格编译器下会报类型不匹配在宽松编译器下能过但语义可疑。正确的做法应该是strcpy(fieldCondition[number][num], primary key)。这类问题在手写解析器里非常典型解析逻辑想清楚了但数据落位的类型没对齐。3. 元数据的物理存储为什么“先清空再重写”是一种可接受的懒策略3.1 三维数组当内存目录表、字段、属性的分层这份实现用四个三维数组撑起整个内存中的元数据tableName[LEN][MAX]存表名fieldName[LEN][LEN][MAX]存字段名fieldType存类型fieldCondition存约束。第一维是表序号第二维是字段序号第三维是字符内容。再配一个Pro_Num[LEN]记录每张表有几个字段。这套结构等价于一个极简的系统目录表级目录 列级目录只是全部摊在内存数组里没有页、没有 B 树、没有槽位。用三维数组的好处是索引直观fieldName[2][1]就是第 3 张表第 2 个字段的名字读取时两层for循环就能遍历。代价是维度上限写死LEN和MAX是编译期常量表一多就溢出而且所有表共享同一块静态内存没有按需分配。真实 DBMS 的目录通常是一组系统表每张系统表自己也是用页管理的这里相当于把系统表退化成了定长数组。3.2 持久化格式表名、字段数、字段三元组的顺序写保存逻辑的核心思路在报告里写得很直白先把表名写进去再写字段个数然后按字段顺序写“字段名 类型 长度 约束”。读取时完全对称先读表名再读字段数Pro_Num然后for循环读Pro_Num次字段信息。这种“自描述前缀 定长循环”的格式好处是读取端不需要知道总共有多少表靠eof判断结束坏处是没有任何校验和文件被截断或手工改坏读出来的就是错位的垃圾数据。ioFile tableName[number]; ioFile Pro_Num[number]; for(i0; i Pro_Num[number]; i) { ioFile fieldName[number][i]; ioFile fieldType[number][i]; // 类型是 char/float/double 时再读一个长度标记 if(strcmp(fieldType[number][i],char)0 || ...) { ioFile mark[i]; f_t_len[number][i][0] (; f_t_len[number][i][1] mark[i][1]; // 只取标记的第二个字符 f_t_len[number][i][2] ); } ioFile _condition1[i]; // 根据 primary/unique/not 再决定是否多读一个词 }读取端有个和写入端呼应的细节约束词读进来后如果是primary就补成primary key如果是not就再读一个词确认是null。这说明磁盘格式里存的是拆开的词而不是完整约束串读取时再做重组。这种“存拆、读合”的做法让写入端简单但把重组逻辑压到了读取端两边必须严格对称改一边不改另一边就会错位——这是所有自定义序列化格式的通病。3.3 全量重写的动机避免原地修改的偏移计算报告里对保存策略的解释很实在修改表之后如果原地更新文件需要计算原记录的位置和长度麻烦且容易错所以干脆每次保存前清空文件、全量重写。这是一个典型的用写放大换实现简单的取舍。对于课程设计这种表数量个位数、字段数十个位的场景全量重写的开销可以忽略换来的是不需要维护空闲空间链表、不需要处理记录变长导致的搬移。真实数据库不会这么干因为全量重写在数据量大时不可接受它们用页内空闲空间管理、记录头指针、甚至原地更新加日志来避免重写整表。但要注意即便是真实数据库系统目录的修改在很多实现里也是相对重的操作因为目录变更频率远低于数据变更用简单可靠的策略比用极致优化的策略更划算。这份实现把这个取舍推到了极端连数据都不存只存结构所以全量重写毫无压力。4. ALTER TABLE 的实现为什么“改结构”比“建结构”更容易出错4.1 表存在性检查先定位再改SQL_ALTER的第一步不是解析ADD/DROP/MODIFY而是先把表名抠出来然后在tableName数组里线性查找。找到就记下下标al_num找不到就报“表不存在”。这个顺序很重要如果先解析子句再查表用户写了一个不存在的表名加一个拼错的ADD你会先报ADD错误用户改完ADD才发现表名也错了体验很差。先做存在性检查等于把“对象是否存在”这个前置条件提前拦截。for(al_num 0; al_num number; al_num) { if(strcmp(tableName[al_num], alterName) 0) break; } if(al_num number) // 走到末尾还没 break说明没找到 { printf(\n 你输入的表%s 不存在...\n, t_name); error0; }线性查找在表数量少时没问题表一多就是 O(n)。真实数据库的目录查找走的是索引通常是 B 树或哈希因为系统目录本身也是被索引管理的。这里用数组线性扫本质上是把“目录即数据”的思想简化掉了。4.2 ADD 分支新字段追加到数组尾部ADD分支的逻辑是解析出新字段名、类型、长度、约束然后写到fieldName[al_num][Pro_Num[al_num]]这一组位置最后Pro_Num[al_num]。也就是说新字段永远追加在现有字段之后不涉及已有字段的搬移。这是ALTER TABLE ADD COLUMN最自然的实现因为追加不改变已有字段的偏移已有数据如果有的话不需要动。但这里有个隐含假设字段顺序就是存储顺序。真实数据库里ADD COLUMN通常也是追加到末尾但有些系统支持ADD COLUMN ... FIRST/AFTER那就需要重排字段顺序代价高得多。这份实现只支持追加算是抓住了最常见也最安全的子集。4.3 DROP 与 MODIFY数组内搬移与类型覆盖DROP分支需要把被删字段之后的所有字段前移一位然后Pro_Num--。这是数组删除的标准操作但要注意四个并行数组名字、类型、长度、约束必须同步搬移漏一个就会导致字段信息错位。MODIFY分支相对简单定位到字段后直接覆盖类型和长度但如果新类型和旧类型长度不同f_t_len的写入要重新处理。这两个分支的共同风险是下标越界和搬移遗漏。比如DROP时如果只搬了fieldName没搬fieldCondition删完字段后约束信息就整体错位一格后续读取全是乱的。这类 bug 在数组式元数据管理里非常隐蔽因为程序不会崩只是显示的信息对不上。常见的排查手段是每次修改后立刻把整张表的结构打印出来和预期逐字段比对。5. 避坑与排查手写 DBMS 元数据层最容易翻车的几个点5.1 现象建表成功但重启后表“消失”原因通常是保存路径写死成了绝对路径比如C:\\Users\\Administrator\\Desktop\\DBMS.txt换一台机器或换一个用户目录文件根本不在那儿读取时open失败但代码没检查返回值number保持 0界面上就显示无表可显示。解决方式是路径改成相对路径或从配置读并且open之后必须判断is_open()失败时给出明确提示而不是静默继续。5.2 现象字段长度超过 9 就存错前面提过长度累加用的是f_length*10...但落盘只写了f_length48也就是只保留个位。char(50)会被存成char(0)或char(2)之类的错误值。排查方法是建一张带两位长度字段的表保存后直接打开元数据文件看实际写进去的字符。解决方式是把长度按字符串写sprintf成50而不是按单字符写读取端也按字符串解析。5.3 现象ALTER 之后约束信息整体错位典型原因是DROP时只搬移了部分并行数组或者ADD时新字段的约束没初始化残留了上一个字段的值。排查手段是每次ALTER后遍历打印fieldName/fieldType/fieldCondition三个数组的同一行看是否一一对应。解决方式是把字段的四个属性封装成一个结构体搬移时整体赋值从根上避免漏搬。5.4 现象输入带多余空格或分号就解析失败手写扫描对分隔符很敏感create table两个空格如果跳过空格的循环写漏了第二个词就会读成空串。分号处理也一样有的分支判断SQL[i]!;有的没判断导致最后一个字段把分号吃进名字里。排查时用最小用例逐个加空格、加逗号、加结尾分号试。解决方式是把“跳过空白”和“读一个 token”抽成两个独立函数所有解析路径统一调用而不是每处手写循环。5.5 现象表名或字段名大小写不一致导致查不到写入时可能保留了原始大小写查找时用strcmp严格比对用户输入Students而存储的是students就找不到。SQL 标准里标识符通常不区分大小写除非加引号这份实现只在关键词上做了tolower标识符没统一。排查时故意用不同大小写建表和改表。解决方式是在存储和比较标识符时统一转小写或者比较时用忽略大小写的版本。6. 从课程设计到真实 DBMS元数据层的设计取舍与验证思路把这份实现和真实数据库的目录管理放在一起看能看清几个关键取舍。第一是存储介质这里用文本文件全量重写真实系统用系统表加分页管理前者实现成本低、可读性好后者支持并发、支持事务、支持大规模表数量。第二是数据结构这里用定长三维数组真实系统用变长记录加槽目录前者索引快但上限死后者灵活但要处理碎片。第三是修改策略这里ALTER直接改内存数组再全量落盘真实系统的 DDL 往往要拿锁、写日志、更新多个系统表因为要保证崩溃恢复和并发一致性。如果要在课程设计基础上做验证我一般会按这个顺序压测先建一张 1 个字段的表保存、退出、重进确认能读回再建一张 10 个字段、带各种约束的表确认约束词没串位然后对中间字段做DROP确认后面的字段整体前移且四个属性同步最后把元数据文件手工改坏一个字符看程序是报错还是读出垃圾——这一步最能暴露读取端有没有做边界检查。真实数据库会用校验和、页头 magic number 来防这类问题手写实现至少应该在文件头写一个版本号和表数量读取时先校验再解析。还有一个容易被忽略的点是错误恢复。这份实现在解析失败时只是打印提示然后返回内存里的数组可能已经被部分写入如果用户接着保存脏数据就落盘了。稳妥的做法是解析阶段先写到一个临时结构全部校验通过后再合并到主数组也就是“解析与提交分离”。这个思路和数据库里“先写日志再改页”是同一个道理任何修改在确认完整之前不应该影响已持久化的状态。从那以后我每次碰这种“字符串进、结构出”的解析器都会先把最小合法输入和最小非法输入各跑一遍确认失败路径不会污染已有状态再往上加语法。希望帮到你。本文还有配套的精品资源点击获取
