Как обеспечить реляционную алгебру для данной схемы?

Question

СОТРУДНИК (PERSONNAME, УЛИЦА, ГОРОД)

WORKS (PERSONNAME, COMPANYNAME, ЗАРПЛАТА)

COMPANY (COMPANYNAME, CITY)

умудряется (PERSONNAME, MANAGERNAME)

Найти имена все сотрудники этой базы данных, которые не работают в First Bank Corporation (при условии, что все люди работают только для одной компании, а люди могут появляться в базе данных (например, у сотрудника), но не появляются в работах).

Здесь я не понимаю часть допущения. Что это значит?

Answer 1

Как @wildplasser отметил: Первая часть предположения

при условии, что все люди работают именно для одной компании ...

объявляет случай, что есть точные один Связь между сотрудниками и компаниями. Это будет означать, что не разрешено иметь записи данных, если сотрудник не связан с какой-либо компанией. То есть, где вторая часть предположений пинает в

... и люди могут появляться в базе данных (например, в сотруднике), но не появляются в работах

Так что это говорит нам о том, что даже возможно, чтобы сотрудники не были связаны с какой-либо компанией.

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

Answer 2

TL; DR: Может быть, вы имеете в виду, что вы «не понимаете допущение части» из запрашивая. Это прекрасно, потому что в запросах на допущения нет никакой части.

PS: Как указано в других ответах, утверждения кажутся противоречивыми. Они неясны, так же как и запрос. Я подозреваю, что «все люди работают только для одной компании» означает «люди в works работают только для одной компании»; в противном случае прямолинейно означает, что это противоречит предположению, что «людям разрешено появляться в [employee], но не отображаются в works» (следовательно, они будут безработными). И я подозреваю, что «имена всех сотрудников в этой базе данных» означают «люди в employee», за «в базе данных (например, в employee)».

---

Для запроса вам просто нужно понять, что строки состояния, когда он находится в и, когда он не в (результат базовой переменной или запроса) таблицы.Т.е., как знать таблицы означает ака предикат, заливка в-the (named-) гасит заявление, в котором столбцы являются параметры:

-- employee PERSONNAME lives on STREET in CITY 

Традиционно в технике и математике, чтобы использовать имя и параметры как стенографии:

-- EMPLOYEE(PERSONNAME,STREET,CITY) 

Каждая строка с колонком таблицы делает заявление аки предложение путем подачи аргументов за его значения столбцов:

(Frank, 1st Avenue, Mytown) proposition from EMPLOYEE predicate: 
    -- employee Frank lives on 1st Avenue in Mytown 
    -- EMPLOYEE(Frank, 1st Avenue, Mytown) 

Строки, которые делают истинное предложение пойти в таблицу и те, которые не не. Таким образом, каждая настоящая строка заявляет о своем предложении, и каждая отсутствующая строка не указывает ее. В таблице хранятся строки, которые превращают его предикат в истинное предложение.

операторов отношения сконструированы таким образом, что значение/предикат в результате определенное сочетание значение/предиката его вход (ы):

R -- holds rows where R(...) 
S -- holds rows where S(...) 
R JOIN S -- holds rows where R(...) AND S(...) 
R UNION S -- holds rows where R(...) OR S(...) 
R MINUS S -- holds rows where R(...) AND NOT S(...) 
R PROJECT columns to keep -- holds rows where FOR SOME columns to drop, R(...) 
R RESTRICT condition -- holds rows where R(...) AND condition 

(Re с помощью SQL, A (к сожалению, неверны & неудобно) гибрид из них, см this answer)

Ваше задание:.

СОТРУДНИК (PERSONNAME, УЛИЦА, ГОРОД)
WORKS (PERSONNAME, COMPANYNAME, ЗАРПЛАТА)
COMPANY (COMPANYNAME, CITY)
умудряется (PERSONNAME, MANAGERNAME)

Найти имена всех сотрудников в этом база данных, не работающая для First Bank Corporation

Мы хотим, чтобы таблица строк имела смысл/предикат true. Rephrase, чтобы получить тот, который мы хотим:

-- employee PERSONNAME does not work for FBC 

Мы должны сформулировать этот смысл/предикат в терминах значений/предикатов мы были даны: (я должен догадаться, что те, потому что вы не сделали дать им)

-- rough draft with only relevant columns 
-- ... [employee PERSONNAME ...] 
AND NOT ... [employee PERSONNAME works at COMPANY ... AND COMPANY = FBC] 

-- full base predicates but drop/keep columns appropriately 
-- FOR SOME STREET & CITY [employee PERSONNAME lives on STREET in CITY] 
AND NOT FOR SOME COMPANY & SALARY 
     [employee PERSONNAME works at COMPANY for $SALARY AND COMPANY = FBC] 

-- shorthand 
-- FOR SOME STREET & CITY [EMPLOYEE(PERSONNAME, STREET, CITY)] 
AND NOT FOR SOME COMPANY & SALARY 
     [WORKS(PERSONNAME,COMPANYNAME, SALARY) AND COMPANY = FBC] 

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

PROJECT PERSONNAME (EMPLOYEE) 
MINUS PROJECT PERSONNAME (RESTRICT COMPANY = FBC (WORKS)) 

(У вашего варианта реляционной алгебры могут быть разные операторы.)

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

Для запроса не требуются ограничения. Они всегда оценивают истинное утверждение, поэтому объединение (ANDing) с помощью запроса/предложения запроса не влияет на то, какие строки входят и не содержат базы. (Они подразумевают ограничения на выражения запросов в терминах их составных базовых таблиц, а также позволяют СУБД предотвращать невозможные значения базы данных, и они помогают пользователям проверить понимание значений/предикатов базовой таблицы.)

Лицо, которое дало вы, возможно, это не понимаете. Вы можете спросить их: если какое-либо из этих ограничений сделало не, тогда как бы получилось выражение query? (Ответ: Это было бы не так.)

Табличные значения/предикаты не были указаны. Возможно, утверждения являются попыткой объяснить, что означает «служащий» в запросе, с учетом (неопределенных) значений employee и works.