Супер вложенные таблицы

Question

Мне нужно собрать в качестве базы данных доступ к сети отелей. Моя дилемма заключается в том, что эта задача требует нескольких шагов вниз по мере прохождения слоев.

В отеле 19 отелей с разным количеством этажей. Каждый этаж в разных отелях имеет разные площади Каждая из этих областей имеет элементы внутри Наконец, с каждым элементом связаны элементы.

Идея в том, что у вас есть несколько полей со списком в форме, где вы выбираете отель, который дает соответствующие этажи в следующем куб. Выбирается этаж, и перечисляются области, связанные с этим этажом для данного отеля, и так до тех пор, пока в финальном кубическом балле не будут указаны предметы.

Я изо всех сил, так как кажется, что таблиц должно быть много, так как многие отношения мудры, и поэтому не могу понять, как их вложить, или это даже лучший вариант.

Помогите пожалуйста

Answer 1

Я думаю, что вы, возможно, думаете об этом.Для меня все эти отношения один ко многим.

Я думаю, что часть вашего заблуждения заключается в том, что вы думаете о этаже отеля только с точки зрения одного из его свойств, а именно уровня.Таким образом, вы думаете, что в отеле A есть этаж 1-го уровня, а в отеле B - этаж 1-го уровня, поэтому между этажами и отелями существует отношение многих ко многим.Это было бы верно, если бы единственным свойством, которое имел этаж, был его уровень.Но, как вы уже сказали, каждый этаж каждого отеля имеет свой набор зон.Таким образом, этаж 1 уровня каждой гостиницы не может быть представлен одной записью.

Вместо того, чтобы думать о этаже с точки зрения его уровня, думайте о каждом этаже как о своей собственной сущности.Если вы сделаете это, вы поймете, что в отеле может быть много этажных объектов, но каждый этажный объект может принадлежать только одному отелю.

Реальный пример проясняет это:

• Вы входите в лифт в отеле A и нажимаете 3.
• Ваш друг входит в лифт в отеле B и нажимает 3.

Если многократномногие модели были верны, вы и ваш друг стояли бы бок о бок, когда вы выходите из лифта. Очевидно, что это не так, поэтому отношение один ко многим имеет смысл.

ДляПо той же причине, все отношения в вашем примере один-ко-многим.Они могут быть смоделированы следующим образом:

Отели : (PK) HotelID и т. Д.
Этажи : (PK) FloorID, (FK) HotelID, Levelи т. д.
Области : (PK) AreaID, (FK) FloorID и т. д.
Элементы : (PK) ElementID, (FK) AreaID и т. д.
Items : (PK) ItemID, (FK) ElementID и т. Д.

Answer 2

Я не вижу, где у вас много-много отношений вообще.Таблица отелей относится к полу. Таблица относится к областям. Таблица относится к элементам. Таблица относится к элементам таблицы.Но если вы хотите смоделировать множество связей, используйте таблицу связей.

Так что стол отеля с отелем, как PK, и всем остальным, что вам нужно в целом об отеле.Стол с полом и прочей информацией, связанной с полом.Таблица HotelFloor, которая содержит только hotelid и floorid.

Но вам действительно нужна эта структура, только если структура пола, площади и т. Д. Не будет уникальной для конкретного отеля.