这个简单网上订书系统的数据库怎么设计？
简单网上订书系统，涉及如下信息：
客户：客户号，姓名，地址，联系电话
图书：书号，书名，出版社，单价
订单：订单号，日期，付款方式，总金额
其中，一份订单可以订购多种图书，每种图书可以订购多本；一位客户可有多份订单，一份订单仅对应一位客户。

怎么设计关系较合适呢？
------解决方案--------------------
订单：订单号，日期，付款方式，总金额

这个可以分成2个表，一个是订单表：

订单：订单号，客户号，日期，付款方式，总金额

一个是订单明细表：

订单明细表：订单号,书号,数量，单价
------解决方案--------------------
其实，主要的业务就是订购：

一个客户有N个订单，

一个订单对应多本图书。


------解决方案--------------------

引用:

Quote: 引用:

订单：订单号，日期，付款方式，总金额

这个可以分成2个表，一个是订单表：

订单：订单号，客户号，日期，付款方式，总金额

一个是订单明细表：

订单明细表：订单号,书号,数量，单价

【订单】的主键为（订单号），【订单明细表】的主键为（订单号，书号）吗？

对的，可以这样设置的
------解决方案--------------------
不过我觉得，单独设置一个自增列也可以，就是：

订单明细表：id，订单号，书号，数量，价格

订单号和书号，都是外键
------解决方案--------------------

引用:

Quote: 引用:

其实，主要的业务就是订购：

一个客户有N个订单，

一个订单对应多本图书。

这样E-R图对吗？

关系模型怎么写？是
表名：（属性1，属性2，。。属性n）吗？主键怎么表示？

对，就是这个
------解决方案--------------------

引用:

Quote: 引用:

对，就是这个

关系模型怎么写呢？

表名：（属性1，属性2，。。属性n）吗？主键只要在下面加个下划线。
------解决方案--------------------

引用:

百度了一下，关系模型应该是类似于UML图的模型。

也不是，一般数据库教科书里的关系模型，就是你自己写的那种。

而你看到的那种类似于uml 的，逻辑模型把，就是有表，有字段，而且应该在power designer中的：


------解决方案--------------------

引用:

Quote: 引用:

Quote: 引用:

百度了一下，关系模型应该是类似于UML图的模型。

也不是，一般数据库教科书里的关系模型，就是你自己写的那种。

而你看到的那种类似于uml 的，逻辑模型把，就是有表，有字段，而且应该在power designer中的：

是这样
另外，【图书】里有（单价），【订单明细表】里就不用（价格）吧？

不是，订单明细表中必须有单价，因为价格是会变化的，比如你的定价是100，但是打折的时候只卖，75，那么其实订单明细表中的价格是，当时订购的价格，也就是历史上的价格，和当前的价格会有差别
------解决方案--------------------

引用:

Quote: 引用:

或者把价格改成实际购买价格

当时销售价格

对的，书一般会有定价，然后会有销售价格，还会有实际订单成交的价格
------解决方案--------------------
加多最少两个表，实现多对多的逻辑，单表要实现多对多有点痛苦
------解决方案--------------------
看了下你的表设计还存在一些问题，红色部分是需要加上的
客户：客户号，姓名，地址，联系电话
图书：书号，书名，出版社，单价
订单：订单号，客户号，日期，付款方式，总金额
订单明细：订单号，书号