sql -> реляционная алгебра

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

Смотрите, в предложении SELECT нужно только три поля. Это projection.

Предложение FROM имеет три отношения. Это Cartesian product.

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

Я понятия не имею, какие обозначения вы используете в классе, но вы, вероятно, хотите что-то, имеющее общую форму

projection((things-you-want), selection((criteria), selection((criteria),
  selection((criteria), aXbXc))))

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

Обратите внимание: в зависимости от того, насколько разборчив ваш преподаватель, вам, возможно, придется переименовать поля. Поскольку и Show, и Seat имеют в качестве атрибута showNo, вам может быть запрещено использовать перекрестное произведение, прежде чем дать им уникальные имена (альтернативные правила, атрибуты однозначно идентифицируются неявным префиксом имени отношения).

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

В любом случае, неужели переход от sql к реляционной алгебре и дереву требует много дополнительной работы? Я не сомневаюсь, что с практикой вы сможете пропустить промежуточный шаг. Однако, поскольку вы задали вопрос в первую очередь, я бы предложил пройти через движения. Помните требование «покажи свою работу» от учителей математики младших классов для объединения простых терминов, которое исчезло в старшей школе? Здесь действует то же правило. Говорю это как бывший оценщик заданий по CS.

Результат этого SQL-запроса не является отношением, поэтому он не имеет точного эквивалента в RA. Вы можете попробовать создать версию RA того же SQL-запроса с добавлением DISTINCT.