简单数据库设计实例
- 格式:doc
- 大小:191.50 KB
- 文档页数:13
数据库表结构设计例子数据库表结构设计是数据库开发中的重要环节,它决定了数据的存储方式和数据之间的关系。
下面列举了10个不同领域的数据库表结构设计例子。
1. 学生信息表学生信息表包含学生的姓名、性别、出生日期、班级等字段,用于存储学生的基本信息。
此表的主键可以是学生的学号,用于唯一标识每个学生。
2. 课程信息表课程信息表用于存储课程的信息,包括课程名称、学分、教师等字段。
此表的主键可以是课程号,用于唯一标识每门课程。
3. 图书馆借阅记录表图书馆借阅记录表用于记录读者的借阅情况,包括书籍名称、借阅日期、归还日期等字段。
此表的主键可以是借阅记录的编号,用于唯一标识每条借阅记录。
4. 订单信息表订单信息表用于存储用户的订单信息,包括订单号、商品名称、购买数量、订单日期等字段。
此表的主键可以是订单号,用于唯一标识每个订单。
5. 电影评分表电影评分表用于存储用户对电影的评分信息,包括用户ID、电影ID、评分等字段。
此表的主键可以是用户ID和电影ID的组合,用于唯一标识每条评分记录。
6. 医院病人信息表医院病人信息表用于存储病人的基本信息,包括病人姓名、年龄、性别、病历号等字段。
此表的主键可以是病历号,用于唯一标识每个病人。
7. 酒店预订表酒店预订表用于记录用户的酒店预订信息,包括预订人姓名、入住日期、离店日期、房间类型等字段。
此表的主键可以是预订记录的编号,用于唯一标识每条预订记录。
8. 购物车表购物车表用于存储用户的购物车信息,包括商品名称、商品数量、商品价格等字段。
此表的主键可以是购物车项的编号,用于唯一标识每个购物车项。
9. 员工信息表员工信息表用于存储公司员工的信息,包括员工姓名、职位、入职日期等字段。
此表的主键可以是员工的工号,用于唯一标识每个员工。
10. 聊天记录表聊天记录表用于存储用户之间的聊天记录,包括发送者ID、接收者ID、发送时间、消息内容等字段。
此表的主键可以是聊天记录的编号,用于唯一标识每条聊天记录。
数据库表结构设计例子数据库表结构设计是构建数据库的基础工作之一,它决定了数据库中数据的组织方式和存储结构。
一个好的数据库表结构设计可以提高数据库的性能、可扩展性和数据的完整性。
下面以一个电商平台的数据库为例,列举10个数据库表结构设计的例子。
1. 用户表(User)- 字段:用户ID、用户名、密码、手机号、邮箱、注册时间等。
- 主键:用户ID。
- 约束:用户名、手机号、邮箱的唯一性约束。
2. 商品表(Product)- 字段:商品ID、商品名称、商品描述、价格、库存、创建时间等。
- 主键:商品ID。
3. 订单表(Order)- 字段:订单ID、用户ID、商品ID、数量、总金额、下单时间等。
- 主键:订单ID。
- 外键:用户ID、商品ID分别关联用户表和商品表。
4. 地址表(Address)- 字段:地址ID、用户ID、收货人姓名、手机号、省份、城市、区县、详细地址等。
- 主键:地址ID。
- 外键:用户ID关联用户表。
5. 购物车表(Cart)- 字段:购物车ID、用户ID、商品ID、数量、创建时间等。
- 主键:购物车ID。
- 外键:用户ID、商品ID分别关联用户表和商品表。
6. 支付表(Payment)- 字段:支付ID、订单ID、支付方式、支付金额、支付时间等。
- 主键:支付ID。
- 外键:订单ID关联订单表。
7. 评价表(Review)- 字段:评价ID、用户ID、商品ID、评分、评论内容、评价时间等。
- 主键:评价ID。
- 外键:用户ID、商品ID分别关联用户表和商品表。
8. 物流表(Logistics)- 字段:物流ID、订单ID、物流公司、物流单号、发货时间、收货时间等。
- 主键:物流ID。
- 外键:订单ID关联订单表。
9. 类别表(Category)- 字段:类别ID、类别名称、父类别ID、创建时间等。
- 主键:类别ID。
- 外键:父类别ID关联类别表自身。
10. 优惠券表(Coupon)- 字段:优惠券ID、优惠券名称、优惠金额、适用商品、有效期等。
数据库设计案例数据库设计案例是指在实际应用中,根据需求和业务流程,设计出符合规范的数据库结构和数据表。
下面列举了10个数据库设计案例,包括了不同领域和不同类型的应用。
1. 学生信息管理系统学生信息管理系统是一种常见的数据库设计案例,主要用于学校、教育机构等场合。
该系统包括学生基本信息、课程信息、成绩信息等数据表,可以方便地管理学生信息和课程成绩,提高教学效率。
2. 医院信息管理系统医院信息管理系统是一种专业的数据库设计案例,主要用于医院、诊所等场合。
该系统包括病人基本信息、医生信息、药品信息、病历信息等数据表,可以方便地管理医院的各项业务,提高医疗服务质量。
3. 酒店管理系统酒店管理系统是一种常见的数据库设计案例,主要用于酒店、旅游机构等场合。
该系统包括客房信息、客户信息、订单信息等数据表,可以方便地管理酒店的各项业务,提高服务质量和客户满意度。
4. 电商平台电商平台是一种常见的数据库设计案例,主要用于电商、在线购物等场合。
该系统包括商品信息、订单信息、用户信息等数据表,可以方便地管理电商平台的各项业务,提高用户购物体验和销售效率。
5. 人力资源管理系统人力资源管理系统是一种专业的数据库设计案例,主要用于企业、机构等场合。
该系统包括员工信息、招聘信息、薪资信息等数据表,可以方便地管理企业的人力资源,提高招聘效率和员工满意度。
6. 物流管理系统物流管理系统是一种专业的数据库设计案例,主要用于物流、运输等场合。
该系统包括货物信息、运输信息、仓储信息等数据表,可以方便地管理物流业务,提高运输效率和客户满意度。
7. 金融管理系统金融管理系统是一种专业的数据库设计案例,主要用于银行、证券等金融机构。
该系统包括客户信息、账户信息、交易信息等数据表,可以方便地管理金融业务,提高服务质量和客户满意度。
8. 游戏管理系统游戏管理系统是一种常见的数据库设计案例,主要用于游戏开发、运营等场合。
该系统包括游戏信息、用户信息、充值信息等数据表,可以方便地管理游戏业务,提高用户体验和收益效率。
实例1 人事管理系统通过前面管理信息系统基础和 PowerBuilder 基础学习,我们初步掌握了使用PowerBuilder 进行信息系统开发的基本知识。
下面将通过一个个实例来说明如何利用PowerBuilder 作为数据库前端开发工具,开发出具有使用价值的管理信息系统。
人事管理系统实例是本书的第一个例子。
因此对于实例开发过程中所涉及到的一些知识会有重点讲述。
随着计算机技术的飞速发展,计算机在企业管理中应用的普及,利用计算机实现企业人事档案的管理势在必行。
当前企业信息管理系统正在从C/S 结构向B/S 结构转移,但是由于安全性等方面的因素,C/S 结构的管理信息系统仍然占据企业管理信息系统的主流。
本书所讲述的实例都是C/S 结构的管理信息系统。
人事管理系统是现代企业管理工作不可缺少的一部分,是适应现代企业制度要求、推动企业劳动人事管理走向科学化、规范化的必要条件。
第一节系统设计一、系统目标设计人事管理系统可以用于支持企业完成劳动人事管理工作,有如下3 个方面的目标。
支持企业实现规范化的管理。
支持企业高效率完成劳动人事管理的日常业务,包括新员工加入时人事档案的建立,老员工转出、辞职、退休等。
支持企业进行劳动人事管理及其相关方面的科学决策,如企业领导根据现有的员工数目决定招聘的人数等。
二、开发设计思想本系统开发设计思想有以下几点。
尽量采用公司现有软硬件环境,及先进的管理系统开发方案,从而达到充分利用公司现有资源,提高系统开发水平和应用效果的目的。
系统应符合公司人事管理的规定,满足公司日常人事管理工作需要,并达到操作过程中的直观、方便、实用、安全等要求。
系统采用C/S 体系结构,Client(客户端)负责提供表达逻辑、显示用户界面信息、访问数据库服务器;Server(服务器端)则用于提供数据服务。
系统分析等前期工作应尽量详细完善,以便公司以后体系结构的改变,对于一些安全性要求不高的信息可以方便的采用Brower/Server 的方式进行访问。
简单数据库设计案例
下面是一个简单的数据库设计案例,该案例用于记录学生信息。
1.首先,我们需要设计一张学生表,该表用于存储学生基础信息,包
括学生姓名、性别、出生日期等,这些信息有助于我们更好地了解学生。
2.其次,我们需要设计一张成绩表,用于存储学生的考试成绩和其他
课程成绩,比如通过外语考试成绩、数学成绩等。
3.然后,我们需要设计一张学校表,用于存储学生的学校信息,包括
学校的名称、地址、类型等,这将有助于我们更好地定位学生的学校位置。
4.最后,我们需要设计一张老师表,用于存储老师的基本信息,以及
老师任教的学校和学科,这有助于我们了解老师及其任教情况。
总之,以上就是一个简单的数据库设计案例,利用这个数据库,我们
可以更好的了解学生、学校和老师之间的信息,从而方便查询和分析。
数据库表设计实例本文将介绍一个简单的数据库表设计实例。
该实例考虑了班级管理系统的需求,并根据需求设计了三张表:学生表、课程表、选课表。
1.学生表设计学生表用于存储学生的基本信息,包括学生编号、学生姓名、性别、年龄、所在班级等字段。
具体字段和数据类型如下:字段|数据类型|描述---|---|---student_id | int |学生编号,主键name | varchar(50) |学生姓名gender | char(1) |性别,M表示男性,F表示女性age | int |年龄class_id | int |所在班级编号,外键2.课程表设计课程表用于存储所有的课程信息,包括课程编号、课程名称、学分数、任课教师等字段。
具体字段和数据类型如下:字段|数据类型|描述---|---|---course_id | int |课程编号,主键name | varchar(50) |课程名称credit | decimal(3,1) |学分数,保留一位小数teacher | varchar(50) |任课教师姓名3.选课表设计选课表用于存储学生选修的课程信息,包括选课编号、学生编号、课程编号、选课时间等字段。
具体字段和数据类型如下:字段|数据类型|描述---|---|---enrollment_id | int |选课编号,主键student_id | int |学生编号,外键course_id | int |课程编号,外键enrollment_time | datetime |选课时间使用以上三张表,我们可以实现班级管理系统的基本功能。
例如,可以通过学生表和课程表查询某个学生选修了哪些课程,或者通过课程表和选课表查询哪些学生选修了某门课程。
以上仅是班级管理系统的一个简单例子,实际的数据库表设计需要根据具体业务需求进行调整。
在设计表结构时,需要考虑到数据的完整性、正确性、一致性、查询效率等多个方面。
同时,需根据实际业务情况选择合适的数据类型、主键和外键,以确保数据尽可能地准确和高效。
数据库课程设计实例100例全文共四篇示例,供读者参考第一篇示例:数据库课程设计是计算机科学与技术专业中非常重要的一门课程,通过设计实例来锻炼学生的数据库应用能力和实践能力。
在这篇文章中,我将为大家分享100个关于数据库课程设计实例的案例,希望能够对大家有所帮助。
1.学生信息管理系统这是一个简单的数据库设计案例,主要包括学生的基本信息管理,课程信息管理和成绩管理,可以帮助学生熟悉数据库的基本操作。
2.图书管理系统这个案例主要是针对图书馆的管理系统,包括图书信息管理,借阅还书管理和读者信息管理等功能,可以综合运用数据库的增删改查等操作。
4.电商平台这个案例主要是针对电商平台的数据库设计,包括商品信息管理,用户信息管理和订单管理等功能,可以让学生了解大规模数据库设计的思路。
8.网站访问日志分析系统这个案例主要是针对网站访问日志分析系统的数据库设计,包括网站访问信息管理,日志分析和用户行为分析等功能,可以帮助学生了解数据库在大数据处理中的应用。
58第二篇示例:数据库课程设计是计算机科学与技术专业中非常重要的一门课程,通过学习数据库课程设计,学生可以掌握数据库设计与管理的基本原理和方法,从而能够独立完成复杂的数据库设计与开发工作。
为了帮助学生更好地理解数据库课程设计的内容,本文将介绍100个数据库课程设计实例,希望能够对学生有所帮助。
1. 学生信息管理系统设计一个学生信息管理系统,包括学生基本信息、课程信息、成绩信息等模块,能够实现学生信息的录入、查询、修改和删除功能。
2. 图书管理系统设计一个图书管理系统,包括图书基本信息、借阅信息、录入图书、查询图书、借阅图书等功能。
3. 超市库存管理系统设计一个超市库存管理系统,包括商品信息、库存信息、进货信息、销售信息等功能,能够实现库存的实时管理。
10. 健身房会员管理系统设计一个健身房会员管理系统,包括会员信息、健身项目信息、健身计划信息、签到信息等功能,实现健身房会员的管理。
数据库设计实例100例1、在网上书店的数据库设计:系统需要包括5个表:书籍表(Book):存储书籍的基本信息,如ISBN编号、书名、作者、出版社、价格等。
用户表(User):存储用户的基本信息,如用户名、密码、电子信箱、收货地址等。
订单表(Order):存储用户购买书籍的数量、总价、下单时间、配送方式等信息。
购物车表(Shopping_cart):记录用户将书籍加入购物车的内容,存储有书籍ID、书籍价格、数量等信息。
评论表(Comment):存储用户对书籍的评论,有评论时间、用户ID、书籍ID、评论内容等信息。
2、在论坛的数据库设计:系统需要包括7个表:用户表(User):存储用户的基本信息,如用户名、密码、电子信箱、注册时间等。
帖子表(Post):存储发布的帖子的基本信息,如发布用户ID、文章标题、文章内容等。
回复表(Reply):存储帖子的回复,有回复时间、回复用户ID、帖子ID、回复内容等信息。
版块表(Board):存储板块的基本信息,如版块ID、板块名称等。
用户权限表(User_authority):存储用户对版块的权限,有用户ID、版块ID、发布权限、回复权限等。
收藏表(Favorite):存储用户收藏的帖子,有用户ID、收藏时间、帖子ID等。
标签表(Tag):存储帖子的标签,有帖子ID、标签名称等信息。
3、在餐馆的数据库设计:系统需要包括5个表:菜品表(Food):存储菜品的相关信息,如菜品名称、单价、口味等。
订单表(Order):存储客户下单的信息,如客户姓名、联系方式、下单时间等。
菜单表(Menu):记录客户点的菜单,有菜品ID、菜品价格、数量等信息。
支付表(Payment):存储客户的支付信息,有支付金额、支付方式、支付时间等。
地址表(Address):存储用户的配送地址,有地址名称、所在省份、详细地址等信息。
4、在银行的数据库设计:系统需要包括6个表:客户表(Customer):存储客户的基本信息,如客户姓名、身份证号、电话号码、开户时间等。
数据库设计典型实例
数据库设计是构建信息系统的基础,一个好的数据库设计可以大大提高信息系统的效率和可靠性。
本文将介绍一个数据库设计的典型实例,以便读者更好地了解如何进行数据库设计。
1. 数据库概述
该数据库主要用于一个医院的信息管理,包括了患者、医生、药品、病历等数据。
2. 数据库需求分析
本数据库需要存储的信息包括:患者、医生、药品、病历等数据,各数据之间需要建立关系。
同时,还需要对各个数据进行查询与分析,提示用户可能存在的问题或疏漏。
根据需求分析,我们设计了以下的数据库结构:
3.1 患者信息表
字段名 | 数据类型 | 备注
:-- | :-- | :--
ID | INTEGER | 主键,自增长
姓名 | VARCHAR(20) |
性别 | CHAR(1) |
电话 | VARCHAR(20) |
邮箱 | VARCHAR(30) |
地址 | VARCHAR(100) |
该数据库可以使用在医院信息管理系统中,可以对患者信息、医生信息、药品信息和病历信息进行管理和查询。
比如,当一位患者来就诊之后,医生可通过该系统查询患者的之前的就医记录,判断该患者的病情和治疗方案;当医生开药时,系统能够查询该药品的规格、单价等信息,并自动生成开药记录,方便医生和患者核对。
5. 总结
数据库设计是信息系统的基础,合理、规范地设计数据库结构,能够让信息管理更加高效,提高系统的可靠性和安全性。
该数据库的设计实例涉及到患者信息、医生信息、药品信息和病历信息,给读者提供了一种常见的数据库设计实例。
sql数据库设计实例设计一个SQL数据库涉及到多个步骤,包括需求分析、概念设计、逻辑设计、物理设计和维护。
下面我会提供一个简单的示例,该示例涉及一个在线书店,我们会创建几个表格以及如何将它们相互关联。
假设我们需要为一个在线书店设计一个数据库。
书店销售书籍、提供预订服务,并管理客户和员工。
1. **需求分析**:* 需要存储书籍的信息(标题、作者、页数等)。
* 需要存储客户信息(姓名、地址等)。
* 需要存储员工信息(姓名、职位等)。
* 需要存储订单信息(订单号、客户、日期、总金额等)。
2. **概念设计**:使用实体-关系模型,我们可以创建以下实体和关系:* 实体: 书籍、客户、员工* 关系: 订单(多对多关系,因为多个客户可以下多个订单,每个订单可以包含多本书)3. **逻辑设计**:基于ER图,转化为关系数据库表:**书籍表(Books):**```sqlCREATE TABLE Books (BookID INT PRIMARY KEY,Title VARCHAR(255),Author VARCHAR(255),Pages INT,ISBN VARCHAR(20) UNIQUE );```**客户表(Customers):**```sqlCREATE TABLE Customers (CustomerID INT PRIMARY KEY,Name VARCHAR(255),Address VARCHAR(255),Email VARCHAR(255) UNIQUE,Phone VARCHAR(20) UNIQUE );```**员工表(Employees):**```sqlCREATE TABLE Employees (EmployeeID INT PRIMARY KEY,Name VARCHAR(255),Position VARCHAR(255),Salary DECIMAL(10, 2));```**订单表(Orders):**注意: 这里我们使用了一个关联表`OrderDetails`来处理多对多的关系。
数据库系统设计案例一、图书馆管理系统图书馆管理系统是一个常见的数据库系统设计案例。
该系统包含以下几个主要的实体:图书、读者、借阅记录等。
图书实体包含图书编号、书名、作者、出版社等属性;读者实体包含读者编号、姓名、年龄、性别等属性;借阅记录实体包含借阅编号、读者编号、图书编号、借阅日期、归还日期等属性。
通过设计合适的数据表和关系,可以实现图书的借阅、归还、查询等功能。
二、酒店管理系统酒店管理系统是一个用于管理酒店客房、客户信息和预订记录的数据库系统。
该系统包含以下几个主要的实体:客房、客户、预订记录等。
客房实体包含客房号、类型、价格等属性;客户实体包含客户编号、姓名、联系方式等属性;预订记录实体包含预订编号、客房号、客户编号、入住日期、离店日期等属性。
通过设计合适的数据表和关系,可以实现客房的预订、入住、退房等功能。
三、电商平台订单管理系统电商平台订单管理系统是一个用于管理订单信息和商品信息的数据库系统。
该系统包含以下几个主要的实体:订单、商品、用户等。
订单实体包含订单编号、用户编号、商品编号、下单时间、订单状态等属性;商品实体包含商品编号、商品名称、价格等属性;用户实体包含用户编号、用户名、联系方式等属性。
通过设计合适的数据表和关系,可以实现订单的创建、支付、发货等功能。
四、学生信息管理系统学生信息管理系统是一个用于管理学生信息和课程信息的数据库系统。
该系统包含以下几个主要的实体:学生、课程、成绩等。
学生实体包含学号、姓名、年龄、性别等属性;课程实体包含课程编号、课程名称、教师姓名等属性;成绩实体包含学号、课程编号、成绩等属性。
通过设计合适的数据表和关系,可以实现学生信息的录入、查询、成绩统计等功能。
五、医院管理系统医院管理系统是一个用于管理患者信息、医生信息和就诊记录的数据库系统。
该系统包含以下几个主要的实体:患者、医生、就诊记录等。
患者实体包含患者编号、姓名、年龄、性别等属性;医生实体包含医生编号、姓名、科室等属性;就诊记录实体包含记录编号、患者编号、医生编号、就诊日期、诊断结果等属性。
引言概述:数据库设计是构建信息系统的重要环节,它关乎着系统的性能、可靠性和扩展性。
在实际应用中,根据不同的需求和场景,我们可以参考一些典型的数据库设计案例来优化我们的设计。
本文将介绍数据库设计的典型案例之二,通过详细的讲解实例,帮助读者理解数据库设计的一些基本原则和最佳实践。
正文内容:一.数据库设计的典型案例之一1.1业务需求分析1.1.1澳大利亚某电商平台的需求背景和目标1.1.2电商平台的功能需求和性能需求1.1.3数据库设计的关键要求和约束条件1.2数据建模1.2.1实体关系模型的设计1.2.2实体关系模型的规范化1.2.3实体关系模型的验证1.3数据库表设计1.3.1数据库表的结构设计1.3.2数据库表的命名规范和约束条件1.3.3数据库表的索引和分区设计1.4数据库查询优化1.4.1查询计划的优化1.4.2索引的设计和优化1.4.3数据库查询的性能调优1.5数据库容灾与备份1.5.1数据库容灾方案的设计1.5.2数据库备份和恢复策略的制定1.5.3数据库的故障监控和自动恢复机制二.数据库设计的典型案例之二2.1业务需求分析2.1.1某在线教育平台的需求背景和目标2.1.2在线教育平台的功能需求和性能需求2.1.3数据库设计的关键要求和约束条件2.2数据建模2.2.1实体关系模型的设计2.2.2实体关系模型的规范化2.2.3实体关系模型的验证2.3数据库表设计2.3.1数据库表的结构设计2.3.2数据库表的命名规范和约束条件2.3.3数据库表的索引和分区设计2.4数据库查询优化2.4.1查询计划的优化2.4.2索引的设计和优化2.4.3数据库查询的性能调优2.5数据库容灾与备份2.5.1数据库容灾方案的设计2.5.2数据库备份和恢复策略的制定2.5.3数据库的故障监控和自动恢复机制总结:数据库设计是信息系统开发中不可忽视的环节,本文通过详细介绍了数据库设计的典型案例之二。
从业务需求分析到数据建模,再到数据库表设计、查询优化以及容灾与备份等方面进行了全面的讲解。
一个典型的数据库设计实例在这个例子中,我们将考虑一个在线购物的商城,该商城销售各种商品,包括衣服、电子产品和家居用品。
首先,我们需要设计数据库的实体关系图(Entity-Relationship Diagram,简称ERD)以及相应的表结构。
2.商品模块:在这个模块中,我们将存储所有的商品信息,包括名称、价格、库存等。
3.订单模块:在这个模块中,我们将存储用户的订单信息,包括订单号、下单时间、收货地址等。
4.购物车模块:在这个模块中,我们将存储用户的购物车信息,包括商品ID、数量等。
5.支付模块:在这个模块中,我们将存储用户的支付信息,包括支付方式、支付金额等。
在设计这些模块时,我们需要考虑以下几个因素:1.实体之间的关系:用户可以下订单,订单可以包含多个商品,商品可以存在于购物车中。
2.数据的一致性:需要确保订单中的商品数量不超过库存数量,并且用户的支付金额要与订单金额一致。
3.数据的安全性:需要对用户的密码进行加密存储,并确保用户的支付信息不被泄露。
接下来,我们将详细说明每个模块的表结构和关系。
2.商品模块:包括商品表,其中包含以下字段:商品ID、名称、价格、库存。
商品ID是主键。
3.订单模块:包括订单表,其中包含以下字段:订单ID、用户ID、下单时间、收货地址。
订单ID是主键,用户ID是外键。
4.购物车模块:包括购物车表,其中包含以下字段:购物车ID、用户ID、商品ID、数量。
购物车ID是主键,用户ID和商品ID是外键。
5.支付模块:包括支付表,其中包含以下字段:支付ID、订单ID、支付方式、支付金额。
支付ID是主键,订单ID是外键。
在这个数据库设计示例中,我们考虑了用户、商品、订单、购物车和支付这五个模块,并设计了相应的表结构和关系。
通过这个数据库设计,可以实现用户的注册、登录、购物、下单和支付等功能。
当然,这只是一个简单的示例,实际的数据库设计可能更加复杂,需要根据实际业务需求进行调整和优化。
数据库课程设计题目16个经典实例-CAL-FENGHAI-(2020YEAR-YICAI)_JINGBIAN数据库课程设计题目16个经典实例1.机票预定信息系统系统功能的基本要求:航班基本信息的录入,包括航班的编号、飞机名称、机舱等级等。
机票信息,包括票价、折扣、当前预售状态及经手业务员等。
客户基本信息,包括姓名、联系方式、证件及号码、付款情况等。
按照一定条件查询、统计符合条件的航班、机票等;对结果打印输出。
2.长途汽车信息管理系统系统功能的基本要求:线路信息,包括出发地、目的地、出发时间、所需时间等。
汽车信息:包括汽车的种类及相应的票价、最大载客量等。
票价信息:包括售票情况、查询、打印相应的信息。
3.人事信息管理系统系统功能基本要求:员工各种信息:包括员工的基本信息,如编号、姓名、性别、学历、所属部门、毕业院校、健康情况、职称、职务、奖惩等;员工各种信息的修改;对转出、辞退、退休员工信息的删除;按照一定条件,查询、统计符合条件的员工信息;教师教学信息的录入:教师编号、姓名、课程编号、课程名称、课程时数、学分、课程性质等。
科研信息的录入:教师编号、研究方向、课题研究情况、专利、论文及着作发表情况等。
按条件查询、统计,结果打印输出。
4.超市会员管理系统系统功能的基本要求:加入会员的基本信息,包括:成为会员的基本条件、优惠政策、优惠时间等。
会员的基本信息,包括姓名、性别、年龄、工作单位、联系方式等。
会员购物信息:购买物品编号、物品名称、所属种类,数量,价格等。
会员返利信息,包括会员积分的情况,享受优惠的等级等。
对货物流量及消费人群进行统计输出。
5.客房管理系统系统功能的基本要求:客房各种信息,包括客房的类别、当前的状态、负责人等;客房信息的查询和修改,包括按房间号查询住宿情况、按客户信息查询房间状态等。
以及退房、订房、换房等信息的修改。
对查询、统计结果打印输出。
6.药品存销信息管理系统系统功能基本要求药品信息,包括药品编号、药品名称、生产厂家、生产日期、保质期、用途、价格、数量、经手人等;员工信息,包括员工编号、姓名、性别、年龄、学历、职务等;客户信息,包括客户编号、姓名、联系方式、购买时间、购买药品编号、名称、数量等。
数据库设计举例学习了数据库设计的理论之后,要能够在实际中进行应用。
下面介绍一个简化的商品配送中心信息管理系统的数据库设计过程。
一、需求分析以往商品配送中心的数据管理全部是手工操作,存在的比较突出的问题是:数据不一致、查询和统计不方便。
为此,决定用计算机来处理数据。
于是到有关部门进行需求调查。
1.企业的组织结构一个商品配送中心大体都由如下几个部门组成:·采购部负责与供应商谈判,议价购买商品,并负责与供应商联系退货;·销售部管理商品及顾客退货;·库存部进货管理,退货管理,对库存商品的盘点与保质;·人事部人员招聘,考核,出勤管理。
2.业务情况商品配送中心主要为商品管理和配送服务,系统处理的数据也集中在商品的进存销流程中,所以这里以商品流为主线,分析进存销过程中相关部门的业务活动。
其中包括采购部、销售部、库存部和人事部采购部、库存部、销售部3个部门负责商品的进、存、销的主要工作,人事部负责整个中心的人员安排和管理,以促进和监督商品销售。
(1)采购部:主要负责商品采购和退货采购时,收到库存部发出的“仓库缺货统计报表”,确定需采购的商品种类和数量;查询供货商档案,确定采购对象;进行市场调查,确定要采购商品的参考价格;与供应商谈判,议定商品单位价格,签订采购合同并记人采购历史记录。
货到时,通知库存部验货、收货。
退货时,收到库存部发出的退货通知,查询采购合同历史记录,找到相应购货合同;查询供货商档案,找到联系方式,与供应商联系,商定退货事宜,签订退货合同,记人退货历史记录;通知库存部退货出库。
(2)销售部:主要负责货架商品管理和客户退货管理根据客户所购商品,查询相应商品单价及折扣表,打印售货清单,进行交易结算,并记入销售记录;根据售货记录,更新货架商品记录;盘点货架商品,对低于最低限量的商品,向库存部发出商品上架通知;对商品销售情况进行定期统计,调整商品结构;统讨一个人销售业绩,作为人事管理部门管理资料。
v1.0 可编辑可修改数据库设计实例数据库设计是数据库应用系统设计的一个组成部分,其核心是针对于特定的应用环境,设计合理的数据模型,创建数据库及其应用系统,使之能够有效地存储和处理数据,以满足用户的应用需求。
从实用角度出发,数据库设计可分为如下几个步骤:第一步:创建概念数据模型确定实体和关系确定属性规范化数据第二步:生成物理数据模型第三步:验证设计为便于学习者理解和掌握,下面结合具体的实例来讲解和展示数据库设计的详细过程。
假定我们要开发一个小型的ERP系统,以管理公司内部资源,其应用业务场景描述如下:v512工作室由IT业界专业人士组成,在提供高端IT培训业务的同时,还自主制作并免费发布大量公益性学习资源,工作室以公司形式运营,目前共拥有18名员工,这些员工分属于4个部门,且员工之间存在上下级管理关系。
计划将来根据业务的发展设立更多的部门,聘用更多的员工。
为保证质量,工作室对其成员的各项专业技能进行了级别评定。
8.5.1 确定实体和关系1. 确定高级别的活动要确定本ERP系统数据库设计中的实体和实体间关系,首先应明确要基于该数据库执行的高级别活动,这里所谓的高级别活动是指从用户的视角出发,确定本数据库设计中系统所涉及到的业务活动。
比如,存储和维护员工的个人信息等。
在前述的应用业务场景中,v512工作室需要考虑的高级别活动包括:-聘用新员工-解雇现有员工-维护员工的个人信息-增设新部门-裁撤现有部门-维护部门信息-维护工作室业务相关的技能信息-维护各员工的业务技能掌握情况2. 确定实体接下来要确定的是,针对上述的高级别活动需要记录和维护有关哪些事物的信息,这些事物将被转换为实体。
其中,员工相关信息可抽象为“Employee”实体、部门相关信息可抽象为“Department”实体、技能相关信息抽象为“Skill”实体,为规范和方便起见,这些实体均采用英文命名,并尽量在名称中体现其含义。
3. 确定关系进一步对上述高级活动进行分析,以确定实体间存在何种关系。
具体包括:-Employee-Department实体之间存在隶属关系员工必须且只能隶属于某一个特定的部门,一个部门可以包含0~多名员工,此为一对多关系。
这种从两个方向上对同一个关系的细化描述被称为关系的角色,每个关系都对应两种角色。
-Employee-Department实体之间存在管理关系每一名员工可以管理0~1各部门,每个部门必须由一名员工负责管理(其管理者不必须隶属于本部门),此为一对一关系。
-Employee-Skill实体之间存在掌握关系每一名员工均应掌握1~多项业务技能,每项技能可能被0~多名员工掌握,此为多对多关系。
-Employee-Employee实体之间存在管理关系每位员工由0~1位上级员工负责管理,有的员工可能没有上司(比如公司经理),但有的话只能有一位直接上级。
上级员工可以管理0~多位为下级员工。
经分析而得的上述实体间关系如图8-14所示。
图8-14 数据库设计实例CDM之14. 将多对多关系更改为实体前文中已讲过,在多对多关系中,可能会出现有属性与关系相关联、而不是单纯的与实体相关联的情况,将这样的属性添加到任何一个实体中都是不合理的,此时应将该关系转换为、或者说定义为实体。
我们这里的Employee与Skill实体之间就存在这种情况——员工所掌握的技能项目及其评定等级信息就与两个实体之间的多对多关系相关联,因此将此多对多关系定义为“人力资源”(HR)实体,转换后的实体-关系如图8-15所示。
图8-15 数据库设计实例CDM之2在实际的数据库应用设计中,更简单而可行的处理原则是,将一切多对多关系均转换为实体,而不必逐个对其进行细化分析,这样可以很好地解决违背数据库规范化第二范式的问题。
5. 分解活动接下来,需要对前述的高级别业务活动做进一步分析,看是否可以将其中的部分或全部项目分解为相对低级别、或者说更细致的业务活动,比如,其中“维护工作室业务相关的技能信息”这一高级别的活动可继续分解为:-添加新的技能项目-删除不再使用的技能项目-维护/更新现有技能项目的详细详细最后一项高级活动“维护各员工的业务技能掌握情况”也可以进行类似的分解。
需要说明的是高级业务活动的确定以及这里的细化分解并没有一成不变的标准,这就好比实现某一预期功能的编程工作是没有标准答案的(有的只是参考实现),其目的都是为后续的确定业务规则和实体属性等步骤提供便利,如果业务逻辑不是很复杂的话也可以一步完成,具体由数据库设计者自行把握即可。
6. 确定业务规则接下来要做的是,对前述业务活动进行再次分析,确定其应遵守的具体规则。
比如,一名员工必须且只能隶属于某一个部门就是一个业务规则。
业务规则通常可以表示为一对一、一对多和多对多关系,或者相应的约束条件,这些规则将来会体现到数据库的结构之中。
本实例中相关的业务规则如下:-员工必须隶属于某一个部门-员工编号一经确定不得更改-员工的姓名、性别、职务、所属部门等其它个人信息可以更改-员工所掌握的技能项目及其评定等级可以更改-每个部门允许设置0~多部电话…和前述业务活动的确定及分解情况类似,业务规则的确定以满足实际业务需要为准,注意不要搞得过于繁琐而失去其实用价值,具体详略程度需设计者根据经验自行把握,也可以待后续环节暴露出问题后再追溯回来,进行迭代处理。
8.5.2 确定属性首先,根据前述分析的业务活动的需要确定所有要记录和维护的数据条目,然后再将这些数据条目做为属性关联到相应的实体或关系中,比如:-员工实体员工编号、员工姓名、性别、职务、上司工号、工资、出生日期、所属部门-部门实体部门编号、部门名称、部门经理、部门地址、电话号码-技能实体技能编号、技能名称-人力资源实体员工编号、技能编号、掌握程度设置属性后的实体-关系如图8-16所示。
图8-16 数据库设计实例CDM之3其中,带有下划线的属性为所在实体的标识符。
为实体或关系设置属性时,应尽量采用规范的命名规则——属性的名称应体现其含义、且应遵循统一的命名格式,以便于将来的使用和维护,比如,假定部门编号使用缩略名称dept_name,那么部门名称等相应的其它属性就不应该使用完整名称,如department_name,而应是其名称保持一致,如dept_name。
在本阶段,设计者只需根据自己的经验和判断进行设计即可,而不必强求数据(属性)与实体间的关联关系一定是正确或合理的,后续的环节还将对现有的数据模型进行规范化处理,以发现可能存在的问题并进行修正。
8.5.3 规范化数据前文中已经讲过,规范化数据的目的在于避免出现数据冗余和操作异常,进而节省存储空间并更好地确保数据的一致性,实际上就是对所设计的数据模型进行一系列的规范化测试(判断其是否满足指定的范式要求)、发现问题并进行整改的过程。
在进行数据的规范化测试之前,应先简单地罗列出各实体中的数据,并为每个实体确定一个唯一的标识符、以唯一地标识实体集中的每一个实体,标识符可以是一个属性、也可以由多个属性组合而成。
实际上这一工作我们已经完成了,参见图8-16,其中,使用下划线标记的即为标识符属性,HR实体(多对多关系转换而成的实体)的标识符由其所依赖的两个实体的标识符(emp_id和skill_id)组合而成。
1. 第一范式测试根据第一范式的要求,检查各实体的属性是否存在多值的情况,这里的“多值”指的是同一个属性在同一个实体上可以有几个不同的取值,如果有则应将这样的属性从其所属的实体中删除掉,并用这些删除掉的属性创建新的实体和关系。
在我们的设计实例中,假定一个部门可以有0~多个电话号码,则Department实体中的phone属性就存在多值的情况,解决办法是,将phone属性从Department实体中删除,并创建一个单独的Phone实体(严格来说是实体集)。
此时,Department实体和Phone实体间存在一对多的关联关系——每个部门可以有0~多个电话号码,每个电话号码必须也只能隶属于某一个特定的部门。
修正后的实体-关系如图8-17所示。
图8-17 数据库设计实例CDM之42. 第二范式测试第二范式要求各实体中所有非标识符属性都必须完全依赖于实体的标识符,如果存在非标识符属性部分依赖(而不是完全依赖)于该实体的标识符的情况,则应从当前实体中删除这些属性、并将之加入到适合的实体中,其相关原理分析及具体做法前文中已有详细讲解。
实际上,由于单个属性做为标识符的实体中不可能出现非标识符属性对标识符部分依赖的情况,我们只需检查那些由多个属性联合组成标识符的实体。
本设计实例中,只有HR实体中存在两个属性(emp_id 和skill_id)组合构成标识符的情况,而其skill_level属性的确完全依赖于这二者,故本设计已符合第二范式的要求。
3. 第三范式测试第二范式要求实体中的属性间不得存在传递依赖,即所有的非标识符属性必须完全依赖于标识符、且不得依赖于实体中的其它(非标识符)属性,如果存在传递性依赖的情况,则应从当前实体中将相关属性删除,有必要的话,也可以将这些属性添加到适合的其它实体中。
经逐个分析,前述各实体的属性之间均不存在传递性依赖,故本设计已符合第三范式的要求。
8.5.4 生成物理数据模型在确定概念数据模型并完成了数据库的规范化之后,数据库设计就基本完成了,接下来要做的是生成与前述概念数据模型相对应的物理数据模型。
这个过程也称作解析关系,因为其主要工作就是将模型中的实体转换为表、并将实体间关系转换为表间的外键关系。
具体原则如下:1. 将实体转换为表实体中的标识符转换为表的主键,实体中的属性转换为表中的字段,属性的数据类型转换/具体化为特定数据库管理系统所支持的数据类型。
2. 解析关系概念数据模型中实体间关系最终将被转换为物理数据模型中表的外键,具体可分为如下三种情况: 解析一对多关系在解析一对多关系时,“一”方表中的主键字段(由其对应实体中的标识符转换得来)将成为“多”方表中的外键字段。
例如,图8-18所示的CDM 中,Department 实体和Phone 实体间存在一对多关系——一个部门可以拥有0~多部电话,但一部电话必须也只能隶属于一个部门。
隶属于拥有Department dept_id dept_name addressPhone phone_code图8-18 一对多关系CDM在转换后的PDM 中,Department 表中的主键字段(dept_id )成为Phone 表中的外键字段,具体如图8-19所示。
图8-19 一对多关系PDM解析一对一关系在解析一对一关系时,可以在其中任意一方(表中)设置外键。
如果该一对一关系在一个方向是强制性的,而在另一方向是可选的,则应在可选的一方设置外键。