假设我们有这样的ER设计问题：
一家制药公司在全国各地销售其产品。为了便于销售，整个国家分为几个区域。地区有销售人员。该公司有各种类型的产品，分类。每个类别都有特定的佣金率。地区有储存设施。销售人员从存储设施中取出产品并将其运送到商店。保留每日销售记录。销售人员根据月度销售业绩收取佣金，根据半年销售业绩收取奖金，并根据年度业绩获得促销。
这是我的逐步解决方案：
第1步：常规实体类型映射。
区域{ 号码 ，名称}
ProductCategory { CategoryName ，CommissionRate}
产品{ ID ，名称}
员工{ ID ，姓名}
EmployeeType {的 类型名 }
销售{ 收据编号 ，日期，数量}
第2步：映射弱实体类型。
区域{ 号码 ，名称}
ProductCategory { CategoryName ，CommissionRate}
产品{ ID ，名称}
存储{数量，面积编号} ????什么是部分密钥和主密钥？
员工{ ID ，姓名}
EmployeeType {的 类型名 }
销售{ 收据编号 ，日期，数量}
Performance {CommissionAmount，BonusAmount，EmployeeID} ???什么是部分密钥和主密钥？
第3步：映射二进制1：1关系。
区域{ 号码 ，名称}
ProductCategory {CategoryName，CommissionRate}
产品{ ID ，名称，ProductCategoryName}
存储{数量，面积编号} ????
员工{ ID ，姓名}
EmployeeType {的 类型名 }
销售{ 收据编号 ，日期，数量}
Performance {CommissionAmount，BonusAmount} ????
第4步：映射二进制1：N关系。
区域{ 号码 ，名称}
ProductCategory { CategoryName ，CommissionRate}
产品{ ID ，名称，ProductCategoryName，存储空间} ????
存储{数量，面积编号} ????
员工{ ID ，姓名，AreaNumber，EmployeeTypeName}
EmployeeType {的 类型名 }
销售{ 收据编号 ，日期，数量，员工ID}
Performance {CommissionAmount，BonusAmount，EmployeeID，NewEmployeeType} ????
第4步：映射二进制M：N关系。
区域{ 号码 ，名称}
ProductCategory { CategoryName ，CommissionRate}
产品{ ID ，名称，ProductCategoryName，存储空间} ????
存储{数量，面积编号} ????
员工{ ID ，姓名，AreaNumber，EmployeeTypeName}
EmployeeType {的 类型名 }
销售{ 收据编号 ，日期，数量，员工ID}
Performance {CommissionAmount，BonusAmount，EmployeeID，NewEmployeeType} ????
ProductSales {ProductID，ReceiptNumber} ????是产品和销售之间的关系，M：N ????
如何解决现有问题以及如何改进解决方案？
答案 0 :(得分：0)
你需要这些表;区域，产品，库存（存储），类别，员工，销售。
您的描述未提及员工类型的任何需求，并且从销售中提取绩效。您的示例错过了将库存连接到项目，因此您可以按项目和区域进行搜索。从这些可以满足您的所有要求。
答案 1 :(得分：0)
您的问题和其他一些问题：
ProductCategory {CategoryName，CommissionRate}
问题陈述说每个类别都有接纳率（复数）。我们必须假设它是M：N。
EmployeeType {类型名}
可能没必要;问题在于销售人员。
销售{ReceiptNumber，Date，Qty}
收货总量通常是其产品数量和价格以及其他因素的函数。您可以通过单独的数量来计算其他内容，或者将其他内容视为理所当然，并从收据的明细行中获取总数量（下方）。
存储{数量，面积编号}
????什么是部分密钥和主密钥？
存储设施可能是一个常规实体; PK ID加属性名称，N：1，带有一个区域，因此添加FK属性Area。作为弱实体，每个区域添加一个存储设施号; PK是（StorageNumber，AreaNumber）。 AreaNumber是部分键（FK）。
存储设施的数量是每个产品，我们称之为库存。这是存储设施和产品的M：N关系或两者的弱实体。所以关系Stock与StorageID或（StorageNumber，AreaNumber）（FK）加上ProductID（FK），一起形成PK。
Performance {CommissionAmount，BonusAmount，EmployeeID}
???什么是部分密钥和主密钥？
性能{CommissionAmount，BonusAmount} ????
关于给予员工和日期的表现的一切都由其他实体决定。关系。所以我们不需要显示/重新表达它们。但如果是这样，最好是一个弱实体。 PK（EmployeeID，日期）。 EmployeeID是部分密钥（FK）。
Performance {CommissionAmount，BonusAmount，EmployeeID，NewEmployeeType} ????
员工显然具有可以晋升的级别/职位。这将是Employee的一个属性。虽然和以前一样，这是由销售决定的，所以并非绝对必要。
产品{ID，名称，ProductCategoryName，存储} ????
产品到产品类别是M：N，而存储是M：N但这些是两个独立的M：N关系，每个关系都有自己的表，不应相互混合或非关键产品属性。 （据推测，此表包含行，其中“名称为ProductCategoryName的产品类别中名称为Name的产品ID存储在设施存储中”。因此，对于存储产品的每个设施，每个（产品，产品类别）对都有一行。 ）
ProductSales {ProductID，ReceiptNumber}
????是产品和销售之间的关系，M：N ????
给定产品和收据确定该产品的总数量和/或价格，但这通常不是利益关系，也不是其他任何关系。我们想知道“收据ReceiptNumber上的行ItemNumber是否具有数量价格的产品ProductID”。我们可以认为一条线是其收据和产品的弱实体。所以项目{ItemNumber，ReceiptNumber，ProductID，Qty，Price}与（ItemNumber，ReciptNumber，ProductID）作为PK，具有属性Qty和Price。 （ItemNumber，ReceiptNumber）和ProductID是部分键（FK）。
销售人员从存储设施中取出产品并将其运送到商店。
存储设施和出口的对称性表明后者应该以类似于存储的方式建模，每个都有一个库存。然后我们可以调整StorageStock，OutletStock和Sales。