数据库物理设计全解析
立即解锁
发布时间: 2025-08-23 00:29:20 阅读量: 2 订阅数: 6 

# 数据库物理设计全解析
## 1. 引言
数据库设计包含逻辑设计和物理设计两个关键部分。逻辑数据库设计是构建业务数据模型的过程,也就是为某个组织或其部分构建业务数据需求模型。而物理数据库设计则是基于逻辑设计的结果,结合应用的使用、性能和存储要求进行微调,并依据所选的数据库管理系统(DBMS)做出具体的实现决策。
随着关系数据模型的兴起,数据库设计领域的侧重点发生了变化。过去,数据库设计文本更侧重于物理数据库设计;如今,重点明显转向了逻辑数据库设计。这主要是因为逻辑设计在形式化方面取得了一定的成功,而物理设计相对缺乏形式化。逻辑数据库设计具有实现独立性,便于进行一般性分析并建立半形式化方法;物理数据库设计则依赖于具体实现,若要有效开展物理数据库设计,必须详细了解应用的工作方式、运行的硬件和操作系统,以及所选DBMS提供的功能。尽管如此,物理数据库设计对于数据库系统的设计者和用户来说仍然至关重要。
## 2. 大学短期课程案例
### 2.1 案例背景
某大学决定向工商业界提供一系列短期课程,尤其关注为期三到四天的信息技术课程。为此,学校成立了一个商业部门——大学短期课程(USC),负责课程的开发、营销和管理。
### 2.2 课程相关信息
- 每门短期课程由一名大学教师(课程经理)开发和维护,但根据课程的受欢迎程度,可能会有多名不同的讲师授课。
- USC在大学校园内的特定场地和商业、工业场地举办课程。前者称为预定课程,后者称为现场课程。
- 预定课程的学生可能来自多个不同的组织,而现场课程的学生显然来自同一个组织。许多公司将USC课程作为其内部培训计划的一部分。
### 2.3 数据库系统需求
USC希望构建一个数据库系统,以更高效地管理短期课程。除了常规的数据插入、更新和删除操作外,该系统还需执行以下功能:
- 当有人打电话注册特定课程时,USC工作人员需检查已注册的人数,注册人数不得超过课程限制。
- 在特定课程开课之前,USC工作人员可随时查询数据库,了解该课程的注册人数。
- 系统需定期通知USC工作人员哪些课程的注册学生少于四人(四人是课程成本的盈亏平衡点,若注册人数少于四人,课程将推迟到以后日期)。
- 在课程开课两周前,工作人员需致电每位学生确认出勤情况。
- 在课程开课一周前,工作人员需检查课程费用是否已支付,并打印每个课程的出勤名单。
- USC需跟踪哪些讲师有资格教授哪些课程,讲师必须至少提前六个月分配到预定课程。
- USC经理希望生成每门课程的平均学生人数统计数据,以了解每门课程的受欢迎程度,并确定课程在一年中的特定时间是否更畅销。
- USC希望维护一个最新的邮件列表,以便向潜在客户定期发送新的和更新的课程手册。
- 大学正在与欧洲、美国和远东的姐妹大学建立联系,USC希望在一两年内设计出分布式数据库功能。
## 3. 逻辑数据库设计
### 3.1 设计过程
逻辑数据库设计通常包括两个方面:一是引出和记录数据库应用的新需求,二是整合可能从现有信息通信技术(ICT)应用中收集到的一系列现有数据需求。在设计过程中,可以采用两种互补的方法:数据建模和规范化。数据分析师通常会进行大量的数据建模工作,对于应用的关键方面,还会进行规范化处理。这两种方法的结果可能需要进行协调,协调后的输出将是一个逻辑模式。
### 3.2 示例逻辑模式
以大学短期课程为例,从业务规则中得出的主要实体和关系可以用以下逻辑模式表示:
```plaintext
Courses(courseNo, courseName, courseManager, courseDuration)
Lecturers(lecturerCode, lecturerName, lHomeAddress, lWorkAddress, lHomeTelNo, lWorkTelNo)
Students(studentNo, studentName, studentAddress, studentTelNo)
Presentations(pNo, courseNo, pDate, pSite, lecturerCode)
Attendance(studentNo, pNo, feePaid)
Qualifications(lecturerCode, courseNo)
Domains
dates: julianDates
lecturerCodes: integer(3)
personNames: character(30)
studentNos: integer(6)
Addresses: character(50)
TelephoneNumbers: character(17) format <(99999) (99999999)>
courseNos: integer(3)
courseNames: character(30)
courseDuration: integer(1) {1,2,3,4}
sites: character(10) {university, hotel, on-site}
feePaids: character(1) {Y,N}
presentationNos: integer(5)
Relation Courses
Attributes
courseNo: courseNos
courseName: courseNames
courseManager: lecturerCodes
courseDuration: courseDurations
Primary Key courseNo
Foreign Key courseManager References Lecturers Not Null
Delete Restricted
Update Cascades
Relation Lecturers
Attributes
lecturerCode: lecturerCodes
lecturerName: personNames
lHomeAddress: addresses
lWorkAddress: addresses
lHomeTelNo: telephoneNumbers
lWorkTelNo: telephoneNumbers
Primary Key lecturerCode
Relation Students
Attributes
studentNo: studentNos
studentName: personNames
studentAddress: addresses
studentTelNo: telephoneNumbers
Primary Key studentNo
Relation Presentations
Attributes
presentationNo: presentationNos
pSite: sites
courseNo: courseNos
pDate: dates
lecturerCode: lecturerCodes
lHomeTelNo: telephoneNumbers
lWorkTelNo: telephoneN
```
0
0
复制全文
相关推荐









