数据库设计的案例分析
数据库设计案例
数据库设计案例在当今信息化时代，数据库已经成为了大多数企业和组织的核心数据管理工具。
良好的数据库设计可以极大地提高数据的存储效率和查询效率，对于企业的运营和决策都具有重要的意义。
本文将通过一个实际的数据库设计案例来介绍数据库设计的流程和方法。
案例背景。
某电商企业拥有大量的商品信息、用户信息、订单信息等数据，为了更好地管理和分析这些数据，决定进行数据库设计和优化。
需求分析。
首先，数据库设计的第一步是需求分析。
在这个案例中，我们需要考虑以下几个方面的需求：1. 商品信息管理，包括商品的名称、价格、库存等信息。
2. 用户信息管理，包括用户的账号、密码、姓名、联系方式等信息。
3. 订单信息管理，包括订单号、下单时间、商品信息、用户信息、订单状态等信息。
4. 数据查询和分析，需要支持对商品、用户、订单等数据的高效查询和分析。
数据库设计。
在需求分析的基础上，我们可以开始进行数据库设计。
数据库设计包括逻辑设计和物理设计两个阶段。
逻辑设计阶段。
在逻辑设计阶段，我们需要根据需求分析得到的数据实体和数据关系来设计数据库的逻辑结构。
在这个案例中，我们可以设计以下几个数据表：1. 商品表（Product），包括商品ID、名称、价格、库存等字段。
2. 用户表（User），包括用户ID、账号、密码、姓名、联系方式等字段。
3. 订单表（Order），包括订单号、下单时间、商品ID、用户ID、订单状态等字段。
物理设计阶段。
在物理设计阶段，我们需要根据逻辑设计得到的数据表结构来选择合适的数据库引擎、数据类型、索引等技术来实现数据库的物理存储。
在这个案例中，我们可以选择使用关系型数据库，并且根据具体的数据库引擎来选择合适的数据类型和索引策略。
数据库优化。
数据库设计完成后，我们还需要进行数据库的优化工作，以提高数据库的性能和可靠性。
数据库优化包括索引优化、查询优化、存储优化等方面。
在这个案例中，我们可以考虑以下几个优化方案：1. 索引优化，对于经常被查询的字段，可以添加索引来提高查询效率。
access数据库案例
access数据库案例Access数据库案例。
在现代社会，数据库已经成为了信息管理的重要工具，而Access作为一种轻量级的关系型数据库管理系统，被广泛应用于各个领域。
本文将通过一个实际案例，介绍如何使用Access数据库管理系统进行数据管理和分析。
案例背景。
假设我们是一家小型的零售企业，我们需要一个数据库来管理我们的产品信息、客户信息、订单信息以及库存信息。
我们希望能够通过这个数据库来实现产品销售情况的分析、客户消费行为的追踪以及库存管理的优化。
数据库设计。
首先，我们需要设计数据库的结构。
我们可以创建四张表，分别是产品信息表、客户信息表、订单信息表和库存信息表。
产品信息表包括产品编号、产品名称、价格等字段；客户信息表包括客户编号、姓名、联系方式等字段；订单信息表包括订单编号、客户编号、产品编号、数量、日期等字段；库存信息表包括产品编号、库存数量等字段。
数据录入。
在数据库设计完成后，我们需要将实际的数据录入到数据库中。
我们可以通过Access提供的表单功能，逐条录入产品信息、客户信息、订单信息和库存信息。
在录入数据的过程中，我们需要保证数据的准确性和完整性，避免出现错误或遗漏。
数据查询与分析。
当数据录入完成后，我们就可以利用Access提供的查询功能进行数据的查询和分析。
比如，我们可以通过查询功能快速找到某个产品的销售情况，或者找到某个客户的消费记录。
我们还可以利用报表功能生成销售报表、客户消费报表等，帮助我们更好地了解业务情况。
数据更新与维护。
随着业务的发展，我们的数据库中的数据也会不断发生变化。
我们需要定期对数据库进行更新和维护，保证数据的及时性和准确性。
同时，我们还需要对数据库进行备份，以防止数据丢失。
安全性管理。
最后，我们还需要关注数据库的安全性管理。
我们可以通过Access提供的权限设置功能，对不同用户设置不同的权限，保护数据库中的重要信息不被未授权的人员访问和修改。
总结。
通过这个案例，我们了解了如何使用Access数据库管理系统进行数据管理和分析。
access数据库开发经典案例解析
access数据库开发经典案例解析Access数据库是一种广泛应用于办公自动化和小型业务系统的数据库管理系统。
它的使用简单方便，适合于小型项目和初级开发人员。
本文将通过分析两个典型案例，来展示Access数据库的开发过程和应用场景。
Case 1:学生成绩管理系统学生成绩管理系统是一个常见的应用场景，用于管理学生的成绩信息。
该系统通常包含学生信息、课程信息和成绩信息等数据表格。
首先，我们需要创建一个学生信息表格，包含学生的学号、姓名、性别、年龄等字段。
然后，创建一个课程信息表格，包含课程的编号、名称、学分等字段。
最后，创建一个成绩信息表格，包含学生学号、课程编号、成绩等字段。
在Access数据库中，我们可以使用表格视图来创建和编辑数据表格，也可以使用SQL语句来创建表格和插入数据。
例如，可以使用以下SQL语句来创建学生信息表格：CREATE TABLE学生信息(学号INT PRIMARY KEY,姓名TEXT,性别TEXT,年龄INT);然后，可以使用INSERT INTO语句来插入学生信息数据：INSERT INTO学生信息(学号,姓名,性别,年龄)VALUES (1, '张三', '男', 18);类似地，我们可以创建其他表格和插入数据。
接下来，我们需要设计学生成绩查询功能。
可以通过创建查询来实现。
例如，可以创建一个简单的查询，查询某个学生的全部成绩：SELECT学生信息.学号,学生信息.姓名,成绩信息.课程编号,成绩信息.成绩FROM学生信息INNER JOIN成绩信息ON学生信息.学号=成绩信息.学号WHERE学生信息.学号= 1;这个查询将返回学号为1的学生的全部成绩信息。
除了查询功能，我们还可以设计数据输入和修改功能。
通过创建表单来实现。
例如，可以创建一个学生信息表单，包含学号、姓名、性别和年龄等输入框。
用户可以在表单中输入学生信息，并通过按钮点击来保存到数据库中。
用户动态数据库设计案例
用户动态数据库设计案例在设计用户动态数据库时，我们首先需要明确我们想要追踪和记录的用户动态数据。
以下是一个简单的用户动态数据库设计案例：数据库表设计1. 用户表 (Users)UserID (主键，自增)UsernamePassword (使用哈希存储)EmailRegistrationDate2. 动态表 (UserActivity)ActivityID (主键，自增)UserID (外键，关联Users表的UserID)ActivityType (例如：注册、登录、发表文章、点赞等)ActivityDateAdditionalData (例如：发表的文章内容、点赞的对象ID等)设计思路1. 用户表：存储用户的基本信息，如用户名、密码、邮箱和注册日期。
其中密码应使用哈希函数进行存储，以增加安全性。
2. 动态表：记录用户的所有动态活动，如注册、登录、发表文章、点赞等。
这个表通过UserID与用户表关联，可以追踪用户的所有活动。
每一条记录都包含活动类型、活动日期和其他相关的附加数据。
使用场景这种设计可以用于多种场景，例如：1. 用户行为分析：通过分析UserActivity表，可以了解用户的行为模式，如他们最常做什么，最喜欢在什么时候进行某些活动等。
2. 系统监控和安全审计：可以监控异常活动，如未授权的登录尝试、频繁的密码尝试等。
3. 内容推荐：基于用户的活动历史，可以为用户推荐他们可能感兴趣的内容或产品。
4. 用户反馈和调查：通过分析用户的活动历史，可以更好地理解他们的需求和反馈。
5. 营销策略：基于用户的活动历史，可以制定更有效的营销策略。
请注意，这只是一个简单的用户动态数据库设计案例。
在实际应用中，可能需要根据具体需求进行更复杂的设计和调整。
数据库案例分析课程设计
数据库案例分析课程设计一、课程目标知识目标：1. 学生能理解数据库的基本概念，掌握数据库设计的基本原理和方法。
2. 学生能通过案例分析，了解数据库在不同领域的应用场景，掌握数据库管理系统的基本操作。
3. 学生能运用所学知识，分析并解决实际问题，设计简单的数据库系统。
技能目标：1. 学生能运用数据库设计方法，完成数据库模型的设计与优化。
2. 学生能熟练使用数据库管理系统，进行数据查询、更新、删除等操作。
3. 学生能通过小组合作，共同完成数据库案例的分析与讨论，提高团队协作能力。
情感态度价值观目标：1. 学生培养对数据库技术的兴趣，激发学习动力，形成主动探究的学习习惯。
2. 学生通过数据库案例分析，认识到信息技术在现实生活中的重要作用，提高信息素养。
3. 学生在合作学习过程中，学会尊重他人意见，培养良好的沟通能力和团队精神。
课程性质：本课程为实践性较强的学科，旨在通过案例分析，使学生掌握数据库技术的基本原理和应用。
学生特点：学生具备一定的计算机操作基础，对数据库技术有一定了解，但实际应用能力有待提高。
教学要求：注重理论与实践相结合，以案例为主线，引导学生主动参与，培养实际操作能力。
将课程目标分解为具体的学习成果，以便于教学设计和评估。
二、教学内容1. 数据库基本概念：数据库的定义、功能、分类及发展历程。
2. 数据模型：实体-关系模型、关系模型、面向对象模型等。
3. 数据库设计：需求分析、概念结构设计、逻辑结构设计、物理结构设计及数据库实施。
4. 数据库管理系统：常见数据库管理系统介绍，如MySQL、Oracle、SQL Server等。
5. 数据库操作：SQL语言及其应用，包括数据查询、插入、更新、删除等操作。
6. 数据库案例分析：分析不同领域（如教育、医疗、金融等）的实际案例，了解数据库应用场景。
7. 数据库安全与维护：数据库安全策略、数据备份与恢复、性能优化等。
教学内容安排和进度：第一周：数据库基本概念及发展历程第二周：数据模型及数据库设计方法第三周：数据库管理系统介绍及安装配置第四周：SQL语言及数据库操作第五周：数据库案例分析（教育领域）第六周：数据库案例分析（医疗领域）第七周：数据库安全与维护策略教材章节关联：本教学内容与教材中以下章节相关：1. 第二章 数据库基本概念2. 第三章 数据模型与数据库设计3. 第四章 数据库管理系统4. 第五章 SQL语言5. 第六章 数据库安全与维护教学内容根据课程目标制定，注重科学性和系统性，旨在使学生掌握数据库技术的基本知识，并能够应用于实际案例。
数据库设计与使用案例分析
数据库设计与使用案例分析数据库是用来存储和管理数据的一种结构化信息系统，被广泛应用于各行各业。
本文将从数据库设计和使用案例分析两个方面进行阐述。
在数据库领域中，设计是一个关键的环节。
一个好的数据库设计能够提高数据的存储效率和查询效率，并且可以更好地满足用户需求。
在进行数据库设计时，需要考虑以下几个方面：首先，需求分析是数据库设计的第一步。
通过与用户沟通，了解和收集用户的需求，并进行需求分析，确保数据库设计满足用户的需求。
例如，如果是一个图书馆管理系统，需要明确图书馆管理员、读者、图书等实体之间的关系以及它们的属性。
其次，实体关系建模是数据库设计的关键步骤之一。
通过分析和抽象实际业务中的实体及实体之间的关系，可以确定实体的属性以及实体之间的联系。
例如，在图书馆管理系统中，图书、借阅、读者等实体之间存在借阅关系，需要建立相应的关系模型。
接下来，关系型数据库是当前最广泛使用的数据库技术之一，因此关系模型的设计是数据库设计的重要环节。
在关系模型中，关键是要确定实体的主键和外键，以及实体之间的关系。
通过合理地设计关系模型，可以提高数据存储和查询的效率，并且能够更好地支持数据的一致性和完整性。
此外，数据库的规范化也是数据库设计的重要一环。
规范化是指将数据库中的数据按照一定规则进行分解和组织，以减少数据冗余和提高数据的一致性。
规范化主要包括第一范式、第二范式和第三范式等概念，通过规范化可以减少数据冗余并提高数据库的性能和可靠性。
在数据库设计完成后，下一步就是对数据库进行使用案例分析。
通过对数据库的使用案例分析，我们可以更好地理解和评估数据库的设计是否满足实际需求，并对数据库进行优化和改进。
首先，对于数据库的读取操作，我们需要考虑如何高效地查询和检索数据。
通过对数据库建立合适的索引，可以提高查询的速度和准确性。
同时，还可以采用一些查询优化技巧，如分页查询、查询缓存等，从而提高数据库的查询效率。
其次，对于数据库的写入操作，我们需要考虑如何保证数据的一致性和完整性。
数据库设计案例网上购物系统
网上购物系统1.系统需求分析网上购物系统分前台功能和后台功能两大部分。
前台主要供用户浏览和购买商品，后台主要供管理员使用，管理员可以对商品信息、订单信息及网站的新闻、公告进行管理。
1.1前台功能分析网上购物系统前台的用户共分两类：一类是注册用户(正式用户)，这类用户有基本的信息，可以对自己的信息进行查看与修改，可以随时实现网上购物。
当用户在网站所购商品总金额达一定数量，可以根据所购商品总金额数量不同自动升级成为不同等级的VIP会员，并享受不同折扣优惠；另一类用户是游客（未注册用户），他们只能查看、浏览网站信息，可以把商品加入购物车或收藏夹，但不能实现购买。
游客：可以查看商品信息、浏览网站信息，可以把商品加入购物车或收藏夹，但不能实现购买。
经过注册可以成为注册用户。
注册用户：登录后对可以对个人信息进行查看和修改。
商品信息浏览、商品查找、商品评论和建议。
注册用户不仅可以对网站商品进行浏览和查找外，还可以对商品进行评论、向管理员发送消息提出自己的建议。
选购商品加入购物车或收藏夹、对购物车或收藏夹信息进行管理。
用户注册后，登陆到电子商务网站中，可以进入购物流程。
用户在浏览商品后，可将满意商品放入购物车或收藏夹，购物车内可以随意增加、删除商品，修改商品数量，并同时统计购物车内商品总额。
用户可对购物车的商品进行修改或删除，或对收藏夹中商品进行删除。
结帐、确认订单、订单状态查询、历史订单查询。
用户确认购物车内信息无误，即可生成订单。
在生成订单时，必须填写一张配送单。
配送单默认为用户注册时的基本信息，当然配送地址可由用户修改为合适的收货地址，支付方式也可根据提示由用户自定。
下单后，用户可以在前台页面查看订单状态，订单状态可以是“末处理”，“已发货”，“已付款”。
5、发表及回复留言。
为了加强注册用户之间的交流，网站还提供了论坛功能，注册用户可以在某一个论坛版块中发贴，也可以回复别人的贴子。
1.2后台功能分析网上购物系统后台主要是供管理员使用的，管理员可对商品的一级分类信息、二级分类信息、商品信息进行添加、删除、查询及修改；对用户订单进行处理；管理用户在论坛中发表的留言，删除不健康及不利于网站的留言；回复用户发送的消息；对网站的新闻、公告进行管理。
mysql数据库表设计案例
mysql数据库表设计案例一、引言1.数据库表设计的重要性在当今信息化时代，数据库已成为各类应用系统的基础。
数据库表设计作为数据库建设的核心环节，直接影响到系统的性能、可维护性和扩展性。
一个优秀的数据库表设计能够提高数据查询效率，降低系统资源消耗，为业务发展提供有力支持。
2.MySQL数据库简介MySQL是一款广泛应用于各类项目的开源关系型数据库管理系统。
它基于Structured Query Language（SQL）进行数据操作，支持多种存储引擎，具有高性能、易使用、成本低等优点。
在众多开源数据库中，MySQL凭借其强大的功能和广泛的应用场景，成为许多企业和开发者的首选。
二、MySQL数据库表设计案例分析1.案例一：用户信息表（1）表结构设计：用户信息表主要包括用户ID、用户名、密码、邮箱、手机号、注册时间等字段。
（2）字段类型与约束：用户ID采用整型（INT）存储，设置为主键；用户名采用字符串类型（VARCHAR）存储，长度限制为255；密码采用字符串类型（VARCHAR）存储，长度限制为255，添加加密约束；邮箱采用字符串类型（VARCHAR）存储，长度限制为255，添加唯一约束；手机号采用字符串类型（VARCHAR）存储，长度限制为20；注册时间采用日期时间类型（DATETIME）存储。
（3）索引与查询优化：创建用户名、邮箱和注册时间的索引，以提高查询效率。
2.案例二：商品信息表（1）表结构设计：商品信息表主要包括商品ID、商品名称、商品类别、价格、库存、发布时间等字段。
（2）字段类型与约束：商品ID采用整型（INT）存储，设置为主键；商品名称采用字符串类型（VARCHAR）存储，长度限制为255；商品类别采用整型（INT）存储，关联类别表；价格采用浮点型（FLOAT）存储；库存采用整型（INT）存储；发布时间采用日期时间类型（DATETIME）存储。
（3）索引与查询优化：创建商品名称、类别ID和价格的索引，以提高查询效率。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
图书销售建立某中小型书店图书销售管理信息系统的数据库。
1. 基本需求分析1）组织结构对组织结构的分析有助于分析业务范围与业务流程。
书店的组织结构如图三所示。
图三书店组织结构简图其中，书库是保存图书的地方；购书/服务部负责采购计划、读者服务、图书预订等业务；售书部负责图书的销售。
财务部负责资金管理；人事部负责员工管理与业务考核。
2）业务分析对于信息处理系统来说，划分系统边界很重要，即哪些功能由计算机来完成，哪些工作在计算机外完成。
这些要通过业务分析确定。
同时，业务流程中涉及的相关数据也通过业务分析得到归类和明确。
在业务分析的基础上，确定数据流图和数据字典。
本系统主要包含以下业务内容。
①进书业务。
事先采购员根据订书单采购图书。
然后将图书入库，同时登记相应的图书入库数据。
本项业务涉及的数据单据和表格有：进书单（包括进书单编号、日期、金额、经手人等）和进书单细目（一个进书单可能有若干种图书。
进书单的细目数据包括每种图书的信息、定价、进价或折扣，数量），以及书库账本（图书信息、库存数量、价格等）。
②售书业务。
售书员根据读者所购图书填写售书单（如图四所示）。
同时，修改库存信息。
本项业务涉及和产生的数据表格有：售书单（包括售书单编号、售书日期、金额、员工）、售书细目（一个售书单可能有若干种图书。
售书细目包括该次售书的书籍编号、售出数量、折扣、售出价格等），以及书库账本。
图四售书单样式③图书查询服务业务。
根据读者要求，提供本书店特定的图书及库存信息。
本项业务涉及的主要数据是书库账本。
④综合管理业务。
包括进书信息、销售信息、库存信息的查询、汇总和报表输出。
本项业务涉及所有的进书数据、销售数据和库存数据等。
3）处理的数据上面的分析将本系统的业务归纳为4项。
在业务分析的基础上，应该画出系统的数据流图。
整个系统的分层数据流图将揭示一个系统内全部的数据项、数据结构、数据存储以及对数据的加工处理功能。
在此基础上就可以建立系统的数据字典。
本书不讨论数据流图和完整的数据字典规范等内容，仅对最后建立数据库所需要的数据进行分析说明。
在上述4项业务中涉及到的业务数据包括：进书数据、库存数据、销售数据。
在这些数据中又涉及到图书数据、员工数据等，而图书数据与出版社有关，员工与部门有关。
因此，将所有数据进行归类分析，书店销售管理信息系统要处理的数据应该包括：企业部门信息（组成：部门编号、部门名、办公电话）；员工信息（组成：工号、姓名、性别、生日、职务、所属部门、薪金）；出版社信息（组成：出版社编号、出版社名称、地址、联系电话、联系人）；基本图书信息（组成：图书编号、ISBN、书名、作者、出版社、版次、出版日期、定价、图书类别、备注）；进书单及细目（组成：进书单号、日期、{进书细目}、金额、业务员）；售书单及细目（组成：售书单号、日期、{售书细目}、金额、业务员）；书库账本（组成：图书编号、库存数量、平均进价折扣、备注）。
这些就是书店销售管理信息系统要处理的各种对象，每一种对象由括号内的属性组合在一起来描述。
这些属性有的是基本数据项，有的是数据项集合（由“{、}”括起来），数据项集合要做进一步的说明。
例如，“{进书细目}”由“序号、{基本图书信息}、进价或折扣、数量”等属性组成；“{售书细目}”由“序号、图书编号、售价或折扣、数量”等属性组成。
当所有数据对象都归纳完毕，就可以编制数据字典了。
在数据字典中，要对所有这些数据项、数据项集合等的命名、取值方式和范围、作用等进行明确而无异义说明。
4）处理功能分析数据字典不仅记载所有数据的详情，也要详细记载所有对数据的处理功能。
①进书业务。
当进书业务发生时，将所进图书入书库，然后存储进书单及细目数据，同时根据进书单登记图书库存数据。
当登记图书库存数据时，可能有两种情况：新图书或已有图书入库。
对于新图书，本业务要将图书的完整信息记载下来，然后记载图书进价和数量；已有图书是指同一种书。
但同一种书可能有版本方面的区别。
为简单起见，规定：“ISBN号”与“版次”相同的就是同一种书，图书编号相同。
对于已有图书，将本次进书数加到该图书的库存数中即可，但本次的进价折扣与以前库存的该书的折扣可能存在差异。
为了便于计算成本和售书收益，入库已有图书时，这里采用的方法是：将已有图书占用的资金和本次入库的资金加在一起，然后重新计算一个平均价格折扣。
因此，书库中该图书的价格折扣是当前所有库存图书占用资金除以当前库存数量后计算的折扣。
②售书业务。
根据读者所购图书的售书单存储售书单及细目数据，这是售书的业务数据。
同时，修改图书的库存信息。
③图书查询服务业务。
查询服务的输入是读者所提要求，输出是相关图书的库存信息。
为方便读者，可以针对书名、ISBN、作者、版次、出版社提供单个或多条件组合查询。
④综合管理业务。
管理人员需要定期或不定期汇总统计或查询进书信息、销售信息、库存信息，并按照管理要求制作业务报表。
通过进书单及细目可以对进书业务进行查询、统计汇总和报表输出。
通过售书单及细目可以对售书业务进行查询、统计汇总和报表输出。
通过库存账本可以对图书库存情况进行查询、统计汇总和报表输出。
2. ER模型分析设计（1）基本实体和联系首先确定实体类别以及它们各自的属性构成，指出实体标识符，并尽量规范属性名，避免同名异义或异名同义。
确定实体后，就可以分析实体之间的联系。
可以很容易确定，部门、员工、出版社、图书、书库是不同的实体。
部门的属性：部门号、部门名、办公电话；员工的属性：工号、姓名、性别、生日；部门与员工发生聘用联系。
这里规定一个员工只能在一个部门任职，它们是1：n联系。
当联系发生时，产生职务、薪金属性。
出版社属性：出版社编号、名称、地址、联系电话、联系人；图书属性：图书编号、书名、作者；出版社与图书发生“出版”联系。
一本图书只能在一家出版社出版。
这是1：n 联系。
当联系发生时，产生ISBN、版次、出版日期、定价、图书类别、备注等属性。
由员工购进图书，所以进书业务是员工与图书发生联系的结果。
一名员工可以进多种图书，一种图书可由多个业务员购进，所以它们是m：n联系。
“进书”联系产生“进书单”属性，进书单本身又由“日期、图书细目、数量、金额”等多个属性构成，所以是多值的组合属性。
与进书业务类似，售书业务是员工将图书售给读者。
本系统不保存读者信息，所以售书是员工与图书发生联系，“售书单”是“售书”联系的属性。
当图书购进后，图书要入书库保存。
书库与图书发生“保存”联系。
这里假定图书是集中式保管，只有唯一一个书库，所以书库不需要标明属性。
书库与图书之间是1：n联系。
“保存”联系的属性有数量、存书的价格折扣、存放备注。
(2) 需要解决的问题—售书与进书以售书为例，当员工在书店售书时，员工就与图书发生“售书”联系。
由于一个员工可以售出多种图书，一种图书可以从多名员工那里售出，因此员工与图书的“售书”联系是m：n。
在实际售书时，由于一名读者可能购买多种图书，所有这些图书构成一张完整的售书单，所以“售书单”是售书联系的属性，ER图如图五所示，图中略去员工和图书的实体属性。
图五图书销售联系的ER图仔细分析“售书单”属性，可以发现，售书单不是一个单一的数据，它是由多项内容构成，如日期、图书种类和数量、金额等属性。
对于属性来说，无论是实体属性还是联系属性，根据属性结构特点可以分为原子属性或组合属性。
原子属性就是属性是一个不可分割的整体，例如员工的“性别”、“年龄”等。
但有些属性是由几个子属性组合起来的。
例如，对于员工“薪金”，如果要分解为“基本工资”、“岗位工资”、“业绩提成”等，则成为组合属性。
因此，有些属性到底是原子属性还是组合属性，要根据设计的规定。
象“姓名”，我国一般是作为一个整体，但西方则分为“First Name”和“Last Name”。
而这里的“售书单”属性，很明显只能是组合属性。
从属性的取值情况可以分为单值属性或多值属性。
单值属性就是属性只有一种取值，如员工性别、生日等；而多值属性就是该属性可能有多种取值。
例如，如果允许员工兼职，则他的职务可能就不只一个值。
另外，若在员工中增加“学位”属性，有的员工可能就有几个学位。
假设在员工实体中增加一个“社会关系”属性，它由“姓名、年龄、关系、地址”组成，所以是组合属性，同时，由于一个员工可能有多个社会关系，则对员工来说，该属性又是多值属性。
前述的“售书单”属性，由于一个售书单内部可包含多种图书，所以它也是多值属性。
当实体或联系存在多值、组合属性时，对ER图的表述带来了一定的困难。
因为ER图将来将转化为关系模型，而关系中属性必须是原子的，因此在ER图中必须有专门的处理。
对于单值的组合属性，一般将组合属性的子属性分解为独立属性。
如“薪金”，若要了解其构成，就可变成。
而对于多值属性，一般会将这个属性变成实体来对待。
这样，它与原实体的关系就变成实体间的联系。
例如，将图三中的“售书单”当作实体，该实体分别与“员工”和“图书”实体发生联系。
一名员工可负责多份售书单，而一份售书单只由一名员工负责，他们之间是1：n联系；一份售书单中可包含多种图书，一种图书可由不同的售书单售出，他们之间是m：n联系。
这样，图五所示的ER图就变成图六的样子。
图六售书单ER图在图四中，售书单的“金额”属性是本单中所有图书销售金额的合计，即：金额=∑（数量×定价×折扣）这样的属性称为“导出”属性，由于可以从其他属性导出，在数据库中一般可略去。
（3）完整的ER图将“进书单”提升为实体来看待，这样，“进书”联系就分解为员工与进书单、图书与进书单两种联系。
而其中的“金额”是导出属性，略去。
进书单的属性有：进书单号、日期。
员工与进书单发生“经手”联系。
一名员工可经手多张进书单，一张进书单只由一名员工负责，所以它们是1：n联系。
进书单与图书发生“购进”联系。
一张进书单可以包含多种图书，一种图书可以由不同的进书单购进。
进书单与图书是m：n联系。
“购进”联系属性：购进的每种图书数量、进价折扣。
将“售书单”提升为实体，“售书”联系分解为员工和售书单、图书和售书单两个联系。
略去“金额”属性。
售书单的属性有：售书单号、日期。
员工与售书单发生“负责”联系，一名员工可负责售出多张售书单，一张售书单只由一名员工负责，所以它们是1：n联系。
图书与售书单发生“售出”联系。
一张售书单可以售出多种图书，一种图书可以由不同的售书单售出。
图书与售书单的联系是m：n联系。
“售出”联系的属性有：售出的每种图书的数量、售价折扣。
这样，根据以上的分析，可以画出图书销售的ER图。
为了清晰起见，将实体及属性、实体联系分别画出。
如图七所示。
实体及其属性图七图书销售ER模型联系图3.关系模型首先，将每个实体型转化为一个关系模式，于是分别得到部门、出版社、员工、图书、进书单、售书单的关系模式，关系的属性就是实体图中的属性。