1

У меня есть две таблицы, которые имеют внешние ключи к первичному ключу друг друга. Эта БД находится на французском языке. Я переведу две таблицы, которые я хочу вам понять.Какая связь между этими таблицами?

  • Atelier кухня ==> Кухня
  • Cuisinier ==> Cooking Chef

Так что в этой картине мы видим, что в Kitchen таблице у нас есть ПК, на который ссылается FK из Cooking chef таблицы ; в таблице Cooking chef у нас есть PK, на который ссылается FK из таблицы Kitchen. Поэтому я смущен. Я не понимаю таких отношений между этими таблицами.

И я надеюсь, чтобы проверить мой запрос, который я сделал, чтобы создать эти две таблицы, если его правильно

CREATE TABLE [ATELIER CUISINE] ( 

NumCuisine INT NOT NULL PRIMARY KEY, 
TelCuisine VARCHAR(50) NOT NULL 
) 

CREATE TABLE CUISINIER (

NumCuisinier INT NOT NULL PRIMARY KEY, 
NomCuis VARCHAR(50) NOT NULL, 
DateEmb DATE NOT NULL, 
NumCuisine INT NOT NULL CONSTRAINT FK_CUISINIER_NumCuisine FOREIGN KEY REFERENCES [ATELIER CUISINE](NumCuisine) 

Смотрите изображение здесь:
Relationship model of the restaurant database

видеть изображение здесь:
Example records for some tables

+0

Возможно, этому FK разрешено значение NULL. Таким образом, вы можете сначала создать одну запись, и они свяжут их. Но это все еще не имеет никакого смысла. – MarceloBarbosa

+0

1. Что означает «вид отношений между таблицами»? Вы уже знаете о ПК и FK. 2. Ваши комментарии задают запрос. Измените это на свой вопрос. Но, * запрос для чего *? (И что вы пробовали?) – philipxy

+0

1. Опять же, пожалуйста, используйте вырезать и вставить текст в свои изображения в свой вопрос. Используйте формат кода для таблиц. Мы не можем вырезать и вставлять изображения. Если вы не можете, используйте онлайн-OCR, затем вырежьте и вставьте. 2. Какой запрос? В вашем вопросе или описании запроса по-прежнему нет запроса. Вы имеете в виду * табличные определения * ?? Измените свой вопрос, чтобы быть понятным. Пожалуйста, отредактируйте свой вопрос, чтобы вы задали один вопрос *. Прямо сейчас ваш заголовок * один * (* неясный *) вопрос, и тело сообщения говорит, что вы * надеетесь *, но не задает вопрос *, и если бы он * сделал *, это было бы * second * вопрос. – philipxy

ответ

0

Что вы видите здесь, скорее всего, очень важно ребенок рисунок.

Я бы предположил, что нам нужно начать с стандартного отношения родитель-ребенок «один kitchen использует один или более chef s». Таким образом, у нас будет внешний ключ в таблице cuisinier/chef, который содержит идентификатор atelier_cuisine/kitchen, где работает cuisinier.

Но по какой-то причине кухня должна быть в состоянии указать на самого важного повара/шеф-повара, работающего там. Только то, что numCuisinier или chefID/cookID - плохое имя этого столбца внешнего ключа, поскольку оно вводит в заблуждение, так же, как оно вводит нас в заблуждение в вашем примере. Если вы дали ему имя, например, numCuisinierChef или «chef/cook in Chief ID», имя столбца было бы само собой разумеющимся.

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

Без документации или комментариев в модели данных, вы жареные, на самом деле ...

Надеется, что это помогает, а не смущает - как модель данных и называние делает ...

Может быть один ключ. MarceloBarbosa действительно вдохновил меня, что: Если в atelier_cuisine, numCuisinier нуль-состоянии, и, в cuisinier, numCuisine является NOT NULL, то atelier_cuisine является родителем, и cuisinier является ребенок, и наоборот.

Марко здравомыслящий

+0

Большое вам спасибо за ваш комментарий. Вы правы в документации, что они не поместили комментарии для объяснения модели данных, но мне нужен запрос реализации, как я могу написать запрос этих двух таблиц в sql-сервере? –

+0

@mohammedaamoum Что значит «запрос этих двух таблиц»? Нет ни одного запроса. Записанный вами запрос зависит от того, что означают таблицы и что означает запрос. Что вы хотите знать о приложении, и что таблицы рассказывают вам о приложении? Как и почему вы могли бы написать запрос, не зная об этом? PS Базовая таблица содержит строки значений, связанных каким-то образом, т. Е. Участвующих в некоторой взаимосвязи. Так делает запрос. Связь запроса определяется SQL и наоборот, с точки зрения отношений и значений базовой таблицы. FK не имеют значения. – philipxy

0

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

Из (более ранней версии) this answer:

Для каждой базовой таблицы, АБД дает предиката --a естественного языка принудительной в- (named-) Заготовку шаблон заявления параметризованный именами столбцов.

-- chef with id NUMCUISINIER has name NOMCUIS and ... 
CUISINIER(NumCuisinier, NomCuis, ...) 

Базовая таблица содержит строки, которые, используя значения ее столбцы для заполнения (названные) пробелы, сделать истинное утверждение ака предложения.

CUISINIER 
NumCuisinier | NomCuis | ... 
---------------------------- 
1   | DURAND | ... -- chef with id 1 has name 'DURAND' and ... 
... 

-- AND for every absent row (NUMCUISINIER, NOMCUIS, ...), 
    NOT (chef with id NUMCUISINIER has name NOMCUIS and ...) 

Каждое выражение SQL/раздел преобразует старое значение таблицы на новое значение, удерживающей строки, которые делают истинное утверждение от какого-то нового предиката, которое может быть выражено в терминах оригинала предиката.

Предикат R JOIN S есть предикат RAND ред с предикатом S. Предикат R ON/WHEREcondition является предикатом RAND ред с condition.

/* rows where 
    chef with id c.NUMCUISINIER has name c.NOMCUIS and ... 
AND kitchen with id a.NUMCUISINE ... 
AND c.NUMCUISINE = a.NUMCUISINE 
*/ 
CUISINIER c join ATELIER_CUISINE a on c.NumCuisine = a.NumCuisine 

Так мы делаем запрос, написав выражение SQL, присоединенное предикат характеризует отношения приложения (ака ассоциации), строки которой мы хотим.

FKs (внешние ключи) не являются отношениями.

Ограничения FK: отношения некоторых людей, но это не так. Это факты.

A FK таблицы представляет собой набор столбцов. «FK» также используется для обозначения связанного ограничения, которое мы имеем, когда у нас есть FK. Который, как и любое ограничение, является истинным утверждением в каждом состоянии базы данных. (Эквивалентно, каждая ситуация приложения.) Ограничение FK говорит, что значения для определенных столбцов в определенной таблице также являются значениями для определенных столбцов в некоторой другой таблице, где они образуют CK (ключ кандидата). (Эквивалентно, он говорит, что если некоторые значения/сущности удовлетворяют определенным отношениям приложений, то некоторые из них плюс некоторые другие значения/сущности удовлетворяют некоторому другому отношению приложения, где значения/сущности образуют CK.) PK (первичные ключи) - это просто некоторые CK, которые вы решили назвать PK.)

Ограничение FK связано с определенным отношением приложений, но это не значит, что для «FK (constraint)» используется «отношение»). («ФК» также используется для обозначения значения subrow для столбцов FK, или значения в строке для столбца одного столбца FK а.)

Вы должны знать , что каждое средство стола.

Предикаты должны поставляться дизайнером вместе со схемой. Вам нужно узнать, что означают таблицы. Затем выражайте свой предикат запроса в терминах них. Затем конвертируйте в SQL.

Иногда мы имеем угадываем в предикатах более или менее успешно через здравый смысл и именование. FKs и другие ограничения могут помочь с угадыванием. (? Подчеркнуты)

здравого смысла, имена, PKS и FKS (? "#") Предполагают, табличные значения для вас, как:

-- chef with id NUMCUISINIER has name NOMCUIS and start date DATEEMB and works in kitchen with id NUMCUISINE 
CUISINIER(NumCuisinier, NomCuis, NateEmb, NumCuisine) 
-- kitchen with id NUMCUISINE has phone number TELCUISINE and chef with id NUMCUISINIER as head chef 
ATELIER_CUISINE(NumCuisine, TelCuisine, NumCuisinier) 

ФКС не нужны для запроса

В SQL-запрос над строками, которые делают предикат в истинное предложение, всегда возвращенные строки. Не имеет значения, сколько строк на NumCuisiner или NumCuisine значение (т. Е. Являются ли они PK) или должно ли значение отображаться в другой таблице (то есть, являются ли они FK). Или какие-либо другие ограничения.

Нам нужно знать предикаты для запроса. Когда мы знаем их , нам не нужно знать никаких ограничений. Нам не нужно знать FK.

FKs, CKs, PKs, альтернативные ключи и уникальные наборы колонок (суперкниги) не имеют отношения к запросу, за исключением того, что если вы знаете, что что-то является суперключом из-за одного, тогда вы можете писать запросы, связанные с извлечением значения из результата с одной строкой , Но вы могли бы выразить тот же результат без экстракций.

0

ИМХО, этот «обмен ключами» явно неправильный; из выборочных данных мы можем предположить (но не обязательно!), что отношения между [ATELIER CUISINE] и [CUISINER] являются «один ко многим» (таблица CUISINIER), и в этом случае [ATELIER CUSINE] НЕ должен иметь NumCuisinier колонке, или иначе NumCuisine не является Первичным ключом (который, согласно модели данных, есть)! Таким образом, модель данных, вероятно, неверна.

Мой лучший выбор для вашего запроса будет

SELECT B.*, A.TelCuisine 
FROM [ATELIER CUISINE] A INNER JOIN CUISINIER B ON A.NumCuisine = B.NumCuisine 

Если конечно NumCuisinier в [ATELIER Cuisinier] таблица НЕ FK, а @marcothesane предполагает и имеет совершенно иной смысл, в этом случае его должен содержаться в результирующем наборе (но с другим псевдонимом):

SELECT B.*, A.TelCuisine, A.NumCuisinier as [HeadChef] 
FROM [ATELIER CUISINE] A INNER JOIN CUISINIER B ON A.NumCuisine = B.NumCuisine 
0

Итак, вы хотите знать, как запросить это.

Как многие говорили, это зависит от того, что необходимо.

И - philipxy - Я не могу рассматривать внешний ключ как факт; вы не можете рассчитать сумму или среднее или стандартное отклонение значений внешнего ключа. И для Кимбалляна, как и я, факты - это факты, потому что вы можете делать с ними все это.

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

Сказав, что:

Если вам нужны все кухни номера телефонов и названия их головы повара:

SELECT 
    telCuisine 
, nomCuisinier 
FROM atelier_cuisine 
JOIN cuisinier USING(numCuisinier) 
; 

Если вам нужны все повара (независимо от того, шеф-повар или кто-либо еще), что вам может достигнуть с одним номером телефона на одной кухне, вы идете:

SELECT 
    nomCuisinier 
FROM atelier_cuisine 
JOIN cuisinier USING(numCuisine) 
WHERE telCuisine = '+39 6 23 25 22 13'; 

Если вы хотите знать, все номера телефонов кухни, где работает Гастон, вы идете:

SELECT 
     telCuisine 
    FROM cuisinier 
    JOIN atelier_cuisine USING(numCuisine) 
    WHERE numCuisinier='Gaston' 
; 

Я знаю, есть возможность использовать положение ON для соединения, но я ленивый и предпочитаю USING() пункт ...

Кроме того, я бы не стал знаете, каков ваш вопрос, действительно ...

+0

Это становится интересным - но это не очень укладывается в этот конкретный вопрос. Для меня первичный ключ и «значение» внешнего ключа - это способ отображения указателя в реляционной базе данных, периоде. Обычно это целое число, но SUM() или AVG() на нем, хотя это возможно, не имеет смысла. Факты - это меры в хранилище данных, для меня. А таблицы фактов содержат внешние ключи («указатели» на записи таблицы размеров) и меры - например, sales_amount, количество и т. Д. Факт, как вы его описываете, является смысловой ценностью. Лучший первичный ключ не имеет смысловой ценности и является суррогатным ключом. – marcothesane

+0

Тем не менее предикаты таблицы * необходимы и достаточны для запроса хранилища или базы данных. Просто попробуйте обосновать, что какой-то запрос, который вы написали, возвращает правильные строки.Или попробуйте написать свой комментарий * четко *. («Нет» и «FK» (вы имеете в виду значение или подземелье в столбцах FK), «факт» («Нет», «Мне», «изобразить», «период», «обычно» или «и т. '&' measure '(вы подразумеваете значение), «не имеет смысла» и «есть» или имеет «семантическое значение».) * Вам нужно использовать фреймворк, объясненный моим ответом *. Это только математика/рассуждение за реляционной моделью. И ваши (неопределенные) встречные требования исчезают. – philipxy

+0

«Факты все имеют точки зрения Факты не делают то, что я хочу, чтобы они были» [Говорящие головы - Кроссированные и Безболезненные (Остаются в свете - 1980)] (https://www.youtube.com/watch?v= WaffRW3hgUY) – philipxy