design ok
This commit is contained in:
ridethepig
parent
53c8d1b339
commit
f92ad68d32
3
.gitignore
vendored
3
.gitignore
vendored
@ -1,3 +1,6 @@
|
||||
*.bkp
|
||||
*.swap
|
||||
*.o
|
||||
*.dtmp
|
||||
*.tmp
|
||||
$*
|
||||
File diff suppressed because one or more lines are too long
97
设计文档.md
97
设计文档.md
@ -4,7 +4,8 @@
|
||||
|
||||
主要面向对象：我自己
|
||||
|
||||
数据需求：
|
||||
> 数据需求：
|
||||
>
|
||||
|
||||
- 图书信息
|
||||
- 统计信息
|
||||
@ -171,7 +172,7 @@
|
||||
|
||||
编号：D3
|
||||
|
||||
组成：对应图书的编号，副本编号，资源URL，大小，日期
|
||||
组成：副本编号，资源URL，大小，日期
|
||||
|
||||
数据量：800条左右
|
||||
|
||||
@ -185,7 +186,7 @@
|
||||
|
||||
编号：D4
|
||||
|
||||
组成：图书编号，用户编号，日期，内容
|
||||
组成：编号，日期，内容
|
||||
|
||||
数据量：1600条左右
|
||||
|
||||
@ -233,7 +234,7 @@
|
||||
|
||||
存取频度：每天100次
|
||||
|
||||
存取方式：随机CRUS
|
||||
存取方式：随机CRUD
|
||||
|
||||
## 概念结构设计
|
||||
|
||||
@ -251,5 +252,93 @@
|
||||
|
||||
### E-R图
|
||||
|
||||
占位符
|
||||
|
||||
## 逻辑结构设计
|
||||
|
||||
### 转换关系
|
||||
|
||||
实体转换：
|
||||
- 管理员：admin(密码)
|
||||
- 系统中只有一个管理员，密码只能通过直接操作数据库修改，这仅作为一个存储项，也不需要主键之类的东西。
|
||||
- 用户：user(<u>用户ID</u>, 用户名, 用户邮箱, 用户密码, 用户配额, 注册日期)
|
||||
|
||||
- 图书：book(<u>图书ID</u>，ISBN，出版社，日期，语言，标题)
|
||||
|
||||
- 文件：document(<u>文件ID</u>，资源URL，大小，日期，类型，副本名)
|
||||
|
||||
- 笔记：note(<u>笔记ID</u>，日期，内容，标题)
|
||||
|
||||
- 类型：type(<u>类型ID</u>, 类型名称)
|
||||
|
||||
- 作者：author(<u>作者ID</u>, 作者姓名)
|
||||
|
||||
联系转换：
|
||||
|
||||
- 管理：管理不直接通过数据表体现，因此不需要添加任何的关系。
|
||||
- 拥有：一对多关系，因此在图书里面添加外键用户ID，修改图书关系为book(<u>图书ID</u>，用户ID(**FK ref user**)，ISBN，出版社，日期，语言， 标题)
|
||||
- 存取：一对多关系，但是由于该联系有自己的属性，所有单独新建一个关系 record(<u>记录ID</u>，时间，操作类型，用户ID，文件URL)。由于这里可能涉及到删除操作，因此使用外键，仅保留存取记录。
|
||||
- 对应：一对多关系，直接在文件里面添加外键图书ID，修改文件关系为document(<u>文件ID</u>，图书ID(**FK ref book**)，资源URL，大小，日期)
|
||||
- 图书-笔记：一对多关系，直接在笔记关系中增加外键，修改关系为note(<u>笔记ID</u>，图书ID(**FK ref book**)，日期，内容)
|
||||
- 图书-作者：多对多关系，单独建立一个关系book_author(<u>图书ID(**FK ref book**)，作者ID(**FK ref author**)</u>)
|
||||
- 图书-类型：多对多关系，单独建立一个关系book_type(<u>图书ID(**FK ref book**)，类型ID(**FK ref type**)</u>)
|
||||
|
||||
### 关系模式优化
|
||||
|
||||
#### 函数依赖集和范式
|
||||
|
||||
book_author、book_type两个为全码，无非主属性，必然满足BCNF
|
||||
|
||||
其余关系的函数依赖集如下：
|
||||
|
||||
- type：`{类型ID->类型名称}`
|
||||
- author：`{作者ID->作者姓名}`
|
||||
- user：`{用户ID->用户名, 用户ID->用户邮箱, 用户ID->用户密码, 用户ID->用户配额, 用户ID->注册日期}`
|
||||
- book：`{图书ID->用户ID, 图书ID->ISBN, 图书ID->出版社, 图书ID->日期, 图书ID->语言, 图书ID->标题}`
|
||||
- document：`{文件ID->图书ID, 文件ID->资源URL, 文件ID->大小, 文件ID->日期}`
|
||||
- note：`{笔记ID->图书ID, 笔记ID->日期, 笔记ID->内容, 笔记ID->标题}`
|
||||
- record：`{记录ID->用户ID, 记录ID->操作类型, 记录ID->时间, 记录ID->文件URL}`
|
||||
|
||||
可以看出，他们均为非主属性对码的完全函数依赖，满足BCNF。
|
||||
|
||||
#### 其他优化
|
||||
|
||||
冗余设计：
|
||||
|
||||
- 因为用户可能会经常需要看自己发布的笔记，虽然可以通过先查book表再查note，但是这样会降低查询效率，因此在note关系中添加用户ID。对于document也需要做同样的冗余属性列的添加，以提高某些情况下的查询效率。
|
||||
- 建立一个用户的统计数据表，里面存放了用户占用的存储空间、创建的图书数量、种类等信息，可以减少查询时的数据库压力。
|
||||
|
||||
简化属性：
|
||||
|
||||
- 由于时间戳是唯一的，因此在record这种不需要更新的表中，可以用时间戳来代替ID作为主键。
|
||||
|
||||
安全性设计：
|
||||
|
||||
- 数据加密：用户的密码通过加盐md5的方式存储在数据库中
|
||||
- SQL注入预防，交给框架来完成
|
||||
|
||||
完整性约束：
|
||||
|
||||
- 实体完整性：各个关系的主键
|
||||
- 参照完整性：。。。表中的外键
|
||||
- 自定义完整性：用户占用的存储空间不能超过配额，也就是用户的文件关系中，文件大小属性之和不能大于用户的配额。
|
||||
|
||||
触发器：
|
||||
|
||||
- book_author和book_type这两个联系由数据库自动更新，当插入一本图书的时候，通过触发器来插入表记录，同时维护author表和type表。
|
||||
- 对于book表、document表、author表和type表，在更改时自动更新统计信息表
|
||||
|
||||
## 物理结构设计
|
||||
|
||||
### 存储结构
|
||||
|
||||
- 存放位置为本地
|
||||
- 存储结构为单机关系型数据库
|
||||
|
||||
### 数据存取
|
||||
|
||||
- 对于type、author、user这三个表而言，一般只需要通过ID查询，因此无需建立额外的索引优化，直接用主键索引即可。book_author、book_type这两个全码表更是如此。
|
||||
- 对于book、document、note、record有对于非主属性的联合和范围查询的需求，主要是对日期的范围查询，对于类型、作者等属性的联合查询。其中，对于范围较小的属性，如图书的语言、出版社、类型等属性，可以不建立索引。对于标题、日期等范围较大的索引，根据启发式规则建立相应的索引。
|
||||
|
||||
## 最终的表设计
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user