АВИАКОМПАНИЯ:

Нафига в Авиакомпании страна и город? Аэрофлот к какому городу относится?

Рейс может быть беспосадочным или же с посадками.
Это "с посадками" или с "пересадками" ?

Что такое Рейс? Это рейс с точки зрения авиакомпании или с точки зрения пасажира (билет) ?

Сейчас у тебя рейс - полная шняга, т.к. противоречит пункту 4 ТЗ.

РЕЙСЫ

По нормальному я бы назвал Route (рейс) или Ticket (билет для пасажира) который состоит из Unit'ов (или Leg'ов).

Ticket (Билет для пасажира):

Выкинуть авиакомпании. Т.к. один билет может состоять из Unit'ов разных авиакомпаний (например авиакомпании).
Аэропорт отправления и прибытия - так же можно выкинуть, можно оставить (нарушая нормальную форму). Т.е. их можно взять так же из Unit'ов. Это будет отправление в первом юните и прибытие в последнем
Время в пути - так же можно (нужно выкинуть), так как это расчетная величина
Есть ли багаж - включен / не включен.
Id багажа - если он есть

TicketUnit:

Ссылка на Ticket
Номер по порядку
Авиакомпания
Код рейса авиакомпании
Что-то еще уникальное к коду рейса (дата?)
Аэропорт откуда, аэропорт куда -- возможно подтягивать из рейса, если есть таблица БД рейсов
Дата и время вылета, дата и время прилета -- возможно подтягивать из рейса, если есть БД рейсов

Время в пути - расчетное, так же как время в воздухе и время stop light, stop over в аэропортах пересадок.

Если рейс это с точки зрения авиакомпаний, то там все будет КРАЙНЕ сложно. Т.к. он AFAIK так же будет состоит из Unit'ов, на которые должны накладываться правила тарификации и соответственно Unit'ы могут быть Priceable (включаемые в один билет) или не прайсайблами (запрещено включать в один билет).

Ну и соответственно билет с точки зрения пассажира != возможным рейсам одной авиакомпании. Скорее всего.

БАГАЖ

Вообще не понял, нафига отдельные в п.5. багаж должен что-то включать. Багаж должен лететь вслед за клиентом и 100% дублировать информацию из Ticket'а. Т.е. нафига для него отдельная сущность? Просто поле "есть багаж", "нет" и возможно Id багажа в таблице Ticket.

Как-то так. AFAIK

P.S.
А вообще задача сложная с точки зрения предметной области. И ТЗ крайне не конкретное или автор его не все привел.

Если задача по программированию - нафига всякие сложности с огрызками из предметной области (типа "номера лояльности", дни недели на рейсе)

должны быть указаны дни недели, когда этот рейс выполняется
Вижу только два нормальных варианта:
1) Сделать 7 колонок: Day1, Day2 ... Day7
2) хранить в одном поле, разделенные через какой-то разделитель (например ","). Это нарушает правила нормализации, ну и пофиг.
3) Делать табличку "дни недели" + связка N:N - полный БРЕД
Оптимально вариант 1.

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

Интересно, как преподаватель планируется хранить информацию о коде-шаринге ))). Когда один самолет делится между разными авиа-компаниями и ему присвоено несколько разных кодов. (можно задать преподу, с целью ввести его в ступор)

Яstop light, stop over
Очепятка, читать как layover и stopover

Кот МатроскинLeonid Kudryavtsevпропущено...

Вижу только два нормальных варианта:
1) Сделать 7 колонок: Day1, Day2 ... Day7
2) хранить в одном поле, разделенные через какой-то разделитель (например ","). Это нарушает правила нормализации, ну и пофиг.
3) Делать табличку "дни недели" + связка N:N - полный БРЕД
Оптимально вариант 1.

Вы как-то можете это аргументировать?
Я бы сказал наоборот - разумен вариант 3 (если задача ставится ровно так, как описал ТС - т.е. расписание задается днями недели и только ими)
Например, Вы как индексировать будете Ваш вариант 1 (уж не говорю про 2), если понадобится?
Описание Т.С. - для меня не понятно. Какие-то выхваченные куски из задания + совершенно левая схема, никак с заданием не согласующаяся.

Ключевые слова, "если понадобится".

Индексировать вариант 1 - легко, 7 индексов.


Аргументировать - легко. Ровно так информация и представлена в международном справочнике рейсов. Т.ч. изобретать велосипед на равном месте - не стоит.

В справочнике полно и других полей, которые на N:N нарываются. Но внутренняя кухня авиакомпании - никому не интересна. IMHO & AFAIK. Так же, как и частота полетов - конечно интересна, но узкому кругу лиц и при решение узкого круга задач. Т.е. как хранить - глубоко пофиг в 99% процентов случаев.

Нафига обо всей это специфики указано в Т.З. автора - не очень понятно. И что конкретно имелось в виду.

Кот МатроскинLeonid KudryavtsevИндексировать вариант 1 - легко, 7 индексов.

И как эти индексы будут использоваться в поиске "Рейсы по понедельникам или средам"? Будете городить динамику с union-ами?
Скорее всего никак ))). Хотя это от базы зависит.

1) См. спойлер про кому это надо )))

2) Какой GUI. Как человек указывает "понедельник", "среда" ? Если на экране будет 7 checkbox'ов (пусть со значением null и 'Y'), то элементарно (возможно ошибся):

SELECT * FROM расписание WHERE from = :P_FROM AND to = :P_TO AND (достаточно сложная хрень отбора попадания по дате) AND ( :CB1 is null OR day1 = :CB1 ) and ( :CB2 is null OR day2 = :CB2 ) ....

Пользователь нашелкал чекбоксов - получил результат. На стороне клиента все элементарно. Один чекбокс на экране - одно поле в БД. Что для вывода на экран, что для поиска.

Но в реальной жизни, отбор пойдет по откуда - куда, дата (зима, весна, лето, осень - маршруты у АК скорее всего разные). День недели - уже не так критично. По дню недели селективность будет ниже плинтуса.

Я почему так возбудился, уже 1.5 месяца Route с Unit'ами и Leg'ами объединяю ))). А тут смотрю, умные слова "номера лояльности", "место" до которых я еще не скоро доберусь. )))