我不得不把它作为一个酒店连锁的访问数据库。 我的困境是，当您进行图层处理时，任务需要多个步骤。
酒店共有19家酒店，楼层数不同 不同酒店的每个楼层都有不同的区域 然后，每个区域都包含其中的元素 最后，每个元素都有与之关联的项目。
您的想法是，您在表单上有多个组合框，您可以选择在下一个cb中给出适当楼层的酒店。选择一个楼层，并列出与给定酒店的楼层相关的区域，直到最后的cb给出项目。
我很挣扎，因为桌子看起来都需要很多才是很多关系，因此无法看到如何嵌套它们，或者这是否是最好的选择。
请帮助
答案 0 :(得分：0)
我根本没有看到你们有多少关系。酒店表涉及地板表涉及的区域表涉及元素表涉及的项目表。但是如果你想模拟许多关系，请使用链接表。
所以酒店桌上有hotelid作为PK，以及您对酒店一般需要的其他任何信息。地板与地板和其他任何楼层相关的信息。 HotelFloor表只包含hotelid和floorid。
但如果地板，区域等结构不是特定酒店的独特之处，那么你真的只需要这种结构。
答案 1 :(得分：0)
我想你可能会过度思考这个问题。对我来说，所有这些关系都是一对多的。
我认为你的一部分困惑在于，你只想根据其中一个属性，即关卡来考虑酒店楼层。因此，您认为A酒店位于1楼，B酒店位于1楼，因此楼层和酒店之间存在多对多的关系。如果地板的唯一属性是它的水平，那将是真实的。但正如您已经说过的，每个酒店的每个楼层都有自己的区域。因此，每个酒店的1楼不能用单个记录表示。
不要在层面上考虑底线，而应将每个楼层视为自己的实体。如果您这样做，您会发现酒店可能有许多楼层实体，但每个楼层实体可能只属于一家酒店。
一个真实世界的例子让这个结晶清晰：
如果多对多模型属实，那么当你离开电梯时，你和你的朋友会站在一起。显然事实并非如此，所以一对一到很多关系都很有道理。
出于同样的原因，您示例中的所有关系都是一对多关系。它们可以这样建模：
酒店 :( PK）HotelID等。
楼层 :( PK）FloorID，（FK）HotelID，Level等。
区域 :( PK）AreaID，（FK）FloorID等。
元素 :( PK）ElementID，（FK）AreaID等。
项目 :( PK）ItemID，（FK）ElementID等