Всем привет!

Только начинаю постигать азы БД.

Не могу понять, каким образом правильнее делать:

Имеем, например, БД Аэропорт (вокзал, транспортная окмпания и т.п.).
В ней имеем сущность РЕЙС: №рейса, дата_вылета_ ГОРОД_вылета, дата_прибытия, ГОРОД_прибытия.

Нужно ввести справочник-классификатор ГОРОДА. И связать его с сущностью РЕЙС.

Связь ведь получается М:М. Так? Т.е. осуществляют через доп.таблицу. Здесь с помощью двух таблиц нужно - "рейсы_города_вылета" и "рейсы_города_прилета" со связями 1:М ?

Но если добавить, например, сущность ГРУЗ: №груза, ГОРОД_сдачи, ГОРОД_доставки (Т.е. сдают клиенты груз, а затем уже подбирается для них соответствующий рейс). То, получается, добавляется ЕЩЕ 2 таблицы? Это разве правильно?

Каким способом организовывают БД, в одной из таблиц которой есть столбцы с одинаковыми наборами значений?

Буду признателен за любую помощь, ибо для меня важно понять и разобраться. а не получить итоговый результат.

ГхостикПочему это M:M ? Во-первых, лучше не город, а аэропорт (в той же Москве их несколько), а во-вторых, получается две связи 1:m - аэропорт вылета и аэропорт посадки.

М:М по определению из нашей универской методички.
Т.е. каждый рейс, хотя по смыслу будет больше подходить ПОЛЕТ, т.к. фиксированного расписания нет, выполняется в несколько аэропортов, и в каждый (из каждого) аэропорт(а) может быть совершено множество рейсов.
Получается, что есть две таблицы:

Полет: №полета; АЭРОПОРТ_вылета; АЭРОПОРТ_прилета;
Аэропорты: №Аэропорта; Наименование;

Т.е. можно это осуществить через две связи с внешним ключом "№Аэропорта" между этими таблицами?

Кот МатроскинС точки зрения описанной постановки задачи - правильно, но разумнее делать все-таки M:M, потому что рейсы могут случиться с промежуточными посадками.
У меня сейчас этап теоретический, никаких СУБД и в помине нет. И в учебном пособии четко указано "от связей м:м избавляться путем внедрения доп. таблиц". Думаю ,что будет однозначный "незачет" мне за это.

ГхостикЯ бы оставил два поля, и только при явной необходимости уже добавлял таблицу "маршрут", и в ней начальные и конечные пункты тоже бы были - первой и последней записью. Избыточно и ненормализовано - да, но учтен важный частный случай для производительности и удобства написания запросов.
Не примут у меня так работу(.

Кот МатроскинВы еще не забудьте такую вещь, как один аэропорт может обслуживать несколько городов, а не только тот к которому привязан номинально. И да как правильно сказали в одном городе может быть несколько аэропортов.
Поэтому лучше держать данные как о городах, так и об аэропортах.
Но тогда вы путаетесь несколько сущностей в одной объединить.
Пример:
груз перемещается их Одинцово (МО) в Тольятти - это некоторый маршрут поставки
а рейсов будет больше: Одинцово - Москва (Шереметьево), Москва (Шереметьево) - Самара (Курумоч), Самара (Курумоч) - Тольятти

если я конечно правильно понял что вы хотите сделать
Да, вы абсолютно правильно поняли. Для отслеживания перемещений груза у меня введена сущность (к нашему примеру) "посадка" , которая состоит из множества операций по погрузке\разгрузке с определенными грузами.


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

Всем спасибо за ответы.

Вот что набросал (в такой форме в отчет КР надо вставлять):



Есть справочник кораблей(суден) - Sheep, Грузов - Cargo, Арендаторов - Renter.

Договор - Contract - может быть трех видов - ContractType: Рейс, Аренда, Ремонт.

Во время рейса судно совершает заходы - DockIn. Во время каждого захода происходит погрузка или разгрузка - DockOp - определенных грузов, которые сданы клиентами - Cargo.

И так, необходимо добавить справочник портов - Hаrbor, связав его с Contract, DockIn

Своими примерами про аэропорт, вокзал и транспортную больше неразберихи внес. Извиняюсь.

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

Спасибо.

mad_nazgulПрежде чем начать проектировать БД нужно спроектировать модель предметной области.
1) Узнать какие сущности/объекты входят в модель. Возможно для вашей модели будет достаточно сущностей рейс, город, груз. А возможно и нет.
2) Какие связи м/у ними (город - рейс, рейс - груз и т.д.)

Когда вы это опишите, только тогда сможете спроектировать БД.

С опытом, для простых моделей предметной области, вы сможете сразу проектировать БД.
А пока так. В начале описываете модель, потом по ней проектируете БД.

Это понятно, спасибо! Само-собой, предметная область проанализирована. Выявлены сущности. Для нее и составлена ЕР-модель вышеуказанная.
Т.е. задание я выполни, в целом (просто вариантов моделей то много - у каждого свой. мой вариант преподавателя устроил).

Поступило уточнение - добавить справочник ПОРТов и связать его с действующими сущностями.
И тут я уперся в то, что у сущности Contract есть два атрибута - harbor_begin и harbor_end, которые могут принимтаь значания из одного справочника. Преподаватель на вопросы не отвечает, в учебном пособии про это нет ничего, кроме того, что от связей м:м уходить нужно через таблицу. Вот я и хочу понять, как это осуществляется правильно, профессионально.