Составной первичный ключ с редактируемой частью

Question

(отредактировано 6/4)

Я проектирую базу данных, которая содержит следующие таблицы об отелях и их расположении (в контексте этого вопроса, скажем, названия отелей уникальны):

[Hotel]    
HotelId PK
HotelName AK

[HotelLocation]
HotelId FK
HotelLocationName

(HotelId, HotelLocationName) - это ПК в HotelLocation. Не может существовать два HotelLocations в одном и том же Hotel с одним и тем же HotelLocationName.

Некоторые примеры данных могут быть:

| Hotelid | HotelName      |         | HotelId | HotelLocationName |
----------------------------         -------------------------------
| 1       | Holiday Inn(1) |         | 1       | Reception         |
| 2       | Four Seasons   |         | 1       | Pool              |
| 3       | Holiday Inn(2) |         | 2       | Reception         |
                                     | 2       | Dinning room      |
                                     | 3       | Room 100          |
                                     | 3       | Room 101          |

Требуется, чтобы оба HotelName и HotelLocationName доступны для редактирования.

По этой причине в случае таблицы Hotel я использую сгенерированный неизменяемый HotelId и сохраняю HotelName в качестве альтернативного ключа (AK) с уникальным ограничением.

Я мог бы сделать то же самое для таблицы HotelLocation и изменить ее следующим образом:

[HotelLocation]
HotelLocationId PK
HotelId
HotelLocationName 

, где (HotelId, HotelLocationName) - АК. Проблема в том, что у меня намного больше таблиц, связанных с ним, где FK-подобие (HotelId, HotelLocationName) дает мне прямое отношение к Hotel, которое я не хочу терять.

Я знаю, что все еще могу использовать FK, похожий на HotelLocation AK, но проблема с каскадными обновлениями остается.

Я думаю о генерации HotelLocationId способом, которым я могу иметь (HotelId, HotelLocationId) PK, например, принимая MAX(HotelLocationId) + 1 для спецификаций c HotelId для каждой новой записи, но я бы предпочел альтернативное решение, если оно есть.

Есть ли какой-нибудь общий способ справиться с такой ситуацией?

Answer 1

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

Hotel
-----
Hotel ID
Hotel Name
...

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

У вас также есть таблица расположения отелей.

Hotel Location
--------------
Hotel Location ID
Hotel Location
...

Идентификатор расположения отеля - еще один слепой первичный key.

Вы создаете таблицу ассоциации для t ie этих таблиц вместе. Я предполагаю, что у Holiday Inn может быть много местоположений, поэтому между таблицей Hotel и таблицей Location Hotel существует отношение один ко многим.

Hotel Association
-----------------
Hotel ID
Hotel Location ID
Date location established
...

Первичный ключ - это и идентификатор отеля, и гостиница. ID местоположения. Это таблица, которая устанавливает взаимосвязь между двумя таблицами.

У вас также должен быть уникальный индекс по идентификатору местоположения отеля, идентификатору отеля, чтобы вы могли найти отель по расположению.

Как вы можете видеть, есть некоторые характеристики, которые имеют отношение к ассоциации, такие как дата создания, дата обновления и, возможно, другие характеристики.

Таблицы ассоциации или соединительные таблицы предоставляют связи между таблицами.