Как связать сущности в SQL через таблицы SQL

Question

Я очень новичок в разработке БД, и мне нужно создать БД для проекта. Я могу объяснить, что я хочу сделать, с точки зрения объектно-ориентированного подхода, и, к счастью, эксперт по БД был бы достаточно любезен, чтобы объяснить мне, как я могу справиться с этим в аспекте БД.

Я хочу создать объект User (Id, Name), который будет иметь отношение к объекту Location (штат, город). Так что на языке программирования я хотел бы иметь следующее

class User {
String Name;
Int Id;
Location location; }

class Location {
String State;
String City; }

Может ли кто-нибудь объяснить мне, как я могу справиться с этим?

Answer 1

Это зависит от требований вашего проекта (проектирование)

Отношения могут быть следующими:

* У пользователя есть одно местоположение и местоположение, связанное с одним пользователем (отношение один к одному)

* У пользователя есть одно местоположение или несколько, и Местоположение связано с одним конкретным пользователем (Отношение Один ко Многим)

* У пользователя есть одно или несколько местоположений, а местоположение связано с более чем пользователем (отношения "многие ко многим")

Answer 2

Судя по комментариям, похоже, что вы хотите установить связь "многие к одному" между таблицей "Расположение" и таблицей "Пользователь". Это означает, что у пользователя будет одно и только одно местоположение, но одно местоположение может быть назначено нескольким пользователям. Итак, вы можете посмотреть, как это должно выглядеть, я включил следующий сценарий DDL или "Язык определения данных", который используется всеми администраторами баз данных:

Создайте таблицу User:

CREATE TABLE [dbo].[User](
    [UserId] [int] NOT NULL,
    [Name] [varchar](50) NOT NULL,
    [LocationId] [int] NOT NULL,
 CONSTRAINT [PK_User] PRIMARY KEY CLUSTERED 
(
    [UserId] ASC
) ON [PRIMARY]
) ON [PRIMARY]

Создайте таблицу Location:

CREATE TABLE [dbo].[Location](
    [LocationId] [int] NOT NULL,
    [City] [varbinary](50) NOT NULL,
    [State] [varchar](2) NOT NULL,
 CONSTRAINT [PK_Location] PRIMARY KEY CLUSTERED 
(
    [LocationId] ASC
) ON [PRIMARY]
) ON [PRIMARY]

Теперь создайте внешний ключ (FK) между 2. FK сообщает базе данных, что вы хотите связать данные между 2 таблицами. То есть вы не можете назначить пользователя на местоположение, которое не существует в таблице расположения. Это делается через поля Id.

ALTER TABLE [dbo].[User]  WITH CHECK ADD  CONSTRAINT [FK_User_Location] FOREIGN KEY([LocationId])
REFERENCES [dbo].[Location] ([LocationId])
GO
ALTER TABLE [dbo].[User] CHECK CONSTRAINT [FK_User_Location]
GO

В Интернете есть много хороших ресурсов для изучения дизайна баз данных. Один вопрос, на который вы захотите ответить раньше: "Насколько нормализована моя база данных?" Нормализация базы данных сильно повлияет на ваш дизайн.

Еще одна вещь: не позволяйте вашей объектной модели приложения определять, какой должна быть ваша модель базы данных. Другими словами, вам не нужно иметь взаимно-однозначное отношение между объектами приложения и таблицами базы данных. Это может быть так для очень маленьких баз данных, но, используя лучшие методы для проектирования БД, вы быстро увидите, что это практика, которая не является устойчивой.

Answer 3

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

table User on Name, Id, LocId
    // (longhand) "user identified by [Id] has name [Name] and is located in location [LocId]"
    // (shorthand) User(Name,Id,LocId)
table Location on LocId, State and City
    // (longhand) "location [LocId] is city [City] in state [State]"
    // (shorthand) "Location(LocId,State,City)

Строки, удовлетворяющие другим операторам, получают путем объединения операторов с использованием AND, OR, AND NOT, EXISTS, IMPLIES и т. Д. Соответствующие таблицы можно получить путем объединения таблиц с использованием JOIN, UNION, MINUS, PROJECT-OUT, <= (соответственно). СУБД может сделать это преобразование для нас.

User
    // rows satisfying User(Name,Id,LocId)
User JOIN Location
    // rows satisfying User(Name,Id,LocId) AND Location(LocId,State,City)
User PROJECT-OUT LocId
    // ie User PROJECT Name,Id
    // rows satisfying EXISTS LocId User(Name,Id)
User WHERE Name='Fred'
    // rows satisfying User(Name,Id,LocId) AND Name='Fred'

Вот как таблицы / операторы "связаны": именами параметров / столбцов и логическими / реляционными операторами.

Только вы можете решить, какие строки вы хотите в своих таблицах, то есть какие операторы вы хотите, чтобы ваши запросы были объединены.

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

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

Учитывая некоторые утверждения и ситуации, которые могут возникнуть, из этого следует, что база данных будет только в определенных состояниях. Мы сообщаем об этом СУБД через "ограничения", чтобы они могли предотвращать другие состояния, а также оптимизировать выполнение. Например, если это всегда так, EXISTS Name,Id User(Name,Id,LocId) ПОДРАЗУМЕВАЕТ СУЩЕСТВУЮЩИЙ State,City Location(LocId,State,City), т.е. что USER PROJECT LocId <= Местоположение PROJECT LocId, тогда мы говорим, что есть " ограничение включения "от LocId пользователя до местоположения. Если также {LocId} является ключом Location, то есть также FK от LocId пользователя до Location. Я повторяю, это не нужно для запроса; государства, нарушающие это, никогда не возникнут из-за использования утверждений, кроме как по ошибке.

Вы и другие комментаторы здесь страдаете от общих недоразумений, которые преподаются как неверное представление методов или, к сожалению, являются действительными частями методов. Например, вместо этого используются отношения, означающие определенные виды ограничений на таблицы / отношения в базе данных. Один из них смущенно говорит, что между пользователями и местоположениями существует отношение "много:1". На самом деле это означает, что таблица / отношение User PROJECT Id,LocId, т.е. EXISTS Name User(Name,Id,LocId) между пользователями (1:1 с идентификаторами) и местоположениями (1:1 с LocIds) имеет свойство многие:1, то есть, что многие пользователи могут находиться в одном и том же месте в некоторых состояниях базы данных. Затем это далее путают с наличием ограничения включения или FK от пользователей к местоположениям. Тогда люди смутно думают, что такие вещи "связывают" таблицы: но они ограничивают таблицы (то есть базу данных) и не имеют отношения к запросам.

Прочтите о NIAM или FCO-IM или объектно-ролевом моделировании, которое расскажет вам, как четко думать о дизайне. (В книгах Хэлпина рассказывается, как сопоставить ORM2 с ER и другими без искажений из-за распространенных заблуждений.)