关于数据表设计遇到一个设计难题,我有多少分全给
我和几个同学最近在用J2EE做"图书馆管理系统",本来以为这个系统还很好做的.
我们的数据库设计思想是这样的(我只说关键的):
订单表---->订单详细表(因为一个订单也有可能采购了多种图书)
图书信息表(图书主键号,图书名,图书作者,图书入库的量,图书现存量等等,不重要的我就不写上来了)
读者信息表,图书借阅表,图书还书表,等等之类的,这些表通过图书主键和读者信息表的主键联系起来,
这样就感觉这个系统差不多了.

可是在于图书馆的工作人员交流的时候才现在不是那么一回事.他们居然要求每一本图书都得有一个有流水号(就是每一本书上的条形码,使

用系统时通过此条形码就

可以得到这本书在图书馆中的详细信息)
哎,现在问题来了,因为图书馆采购图书的时候不可能是每本书只进一本回来是吧,它是每本书都进一些回来,那难道现在的关于图书信息表应该这样设计?(图书主键号

也就是条形码,图书库存量,图书现存量,等等字段,)这样设计的话,感觉数据重复性好大啊,如果一本书有100本,那么关于此图书在数据库中的记录就

会有100条,而只是

他们的条形码不同而已.感觉很不好啊.

我想到了一种办法,那就是在最先我设计的图书信息表中加入这样的两个字段,"起始条形码","末尾条形码",这样在使用系统的时候也可以根

据条形码查到此图书的详

细信息,但是感觉这样非常不好,因为馆中的图书在使用过程中也有可能丢失,报损之类 的,这条形码是一个范围的话,重新贴条形码的话就有些不好控制了.总之就是感

觉这样做,限制性很大,很不利于系统的操作和控制.

现面我感觉的问题就出来,是分析每种书呢(就会有数量属性),还是分析每一本书(就会有状态属性:在架上,外借了,而没有库存量属性)我这样说,可能是使用java习惯了

,总是喜欢使用面向对象来分析现实问题.

我也在考虑怎么样把这图书信息表拆分成多张表,可是一点思想也没有.

你们听明白我的话没有啊?应该怎么样设计好关于图书信息表这一块啊?


------解决方案--------------------
1，你先把每个实体分配好，
2，把业务之间的关系，可以做成关联表。
这两点一班来说就够 用了。
------解决方案--------------------
可以先将图书分类，做标记，然后增加贴条形码！
------解决方案--------------------
就怕你没有多少分给我，就这问题还做那么大篇文章，你时间很多吗？
一开始你的想法就有问题了。既然只有流水号不同，那么你为什么不把索书号当主键呢？
"起始条形码","末尾条形码"这想法就不怎么样。
你记住是先贴流水号和索书号才把数据录入的，所以录入的时候直接对着书本的数据录入就是了，当然条形码也是录入"起始条形码","末尾条形码",不过，条形码用另一个以索书号为外键的表来储存。丢失,报损之类的情况就在第二个表的图书状态中标明就是了。

谢谢 谢谢经理的分哦。呵呵
------解决方案--------------------
你如果要用hibernate做的话 我建议你就应该坚持面向对象的思想来思考
你先设计Entity类 再通过hibernate映射来帮你自动创建表
------解决方案--------------------
每本书是一个实体book，每种书是一个大类type,
条形码是唯一的，关系book N：1 type，
就是建两个表解决问题，type是每种书，
book是每本书,book就两列，一个条形码为主键，一个为外键引用type，问题是否解决了？
------解决方案--------------------
我觉得killer89792说得不错，你这是数据的结构问题，好像跟JAVA没什么很大关系，现说不要死套对象。