Составить схему (сначала только схему) информационной системы железнодорожного вокзала

Доброго времени суток!!!
суть вот в чем: мне нужно составить схему(сначала только схему) информационной системы железнодорожного вокзала. Работаю в erwin'е, хотя тут не суть в чем, уже очень долгое время у меня не выходит, преподаватель не засчитывает, а мне очень нужно его сдать. Помогите пожалуйста.
условия: не менее 10-ти сущностей, 3-яя нормальной форма, неидентифицирующая связь.
если кого заинтересует, то прилагается скрин.

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

Миниатюры

 

0

количество вагонов в поезде может и не нужно указывать так как мы можем их вычислить используя комбинацию SELECT и COUNT из таблицы "вагоны"
разве что только придумать отдельную сущность для "ФИО" сотрудников и клиентов, так как есть маленькая вероятность что сотрудник будет клиентом.

да кстати у вагона должно быть поле "номер" так как номер вагона не равен id и в билете должен быть указан этот же номер.
У расчета наверно должно быть поле "id кассы", а не наоборот.
и немного смущает "id кассы" у сущности "сотрудники"

отпишитесь когда узнаете чего хочет препод, мне тож интересно.

1

XRuZzz, вчера был у него, после нескольких часов серфинга и изучения сайта ржд.ру, получился такой вариант. В принципе его он устроил, хоть и с небольшим недовольством. Только что поставил оракл, буду заполнять. Надеюсь, что все пройдет нормально. Так-то много работы, весомая база получится. А по поводу номера вагона я думал, хотел как раз так сделать, но когда сделал, появились непонятки с нормализацией, и неидентифицирующая связь терялась, пришлось "приравнять" id и номер. Что касается расчета, в самом первом варианте сущность расчет включала id кассы, но в этом случае опять же с нормализацией косяки были, пришлось переделать, и получилось так, что расчет имеет всего 2 id, 1-наличный, 2-безналичный(это кстати он мне и посоветовал, был первый и последний его совет). Id кассы у сотрудника его тоже смущает, но я себе представляю так, что каждый сотрудник работает на своей кассе, т.е. определенному сотруднику соответствует определенный id. Количество вагонов в "поезд" я включил только чтоб самому не запутаться, просто многое из этого я буквально "высасывал из пальца". Искал базы в инете(их не так много), думал возьму что-то, моему удивлению не было предела, когда я увидел, что там количество сущностей до 8-ми, в основном хватает 4, нормализацией там даже не пахнет. Эта работа намного подробней всех остальных, выложенных в инете, думаю выложу куда нибудь, чтоб если кому понадобится, не мучались как я)))

Удачи мне))) заполнение такой базы через cmd требует...терпения, усидчивости. Заполненную по-другому базу не примет, сказал((.

Миниатюры

 

0

Сообщение от goray92 А по поводу номера вагона я думал, хотел как раз так сделать, но когда сделал, появились непонятки с нормализацией, и неидентифицирующая связь терялась, пришлось "приравнять" id и номер.

у вас два поезда( сверху номера, снизу id, 0 - это ведущий вагон и он не нумеруется)
я лично не понимаю как пассажир найдёт свой вагон. то есть в жизни они по id не нумеруются

0

хм...и правда...а как это реализовать, не подскажете? чтоб в билет шел номер вагона, а не id? нужно так же, 3 нф, неидент связь. буду благодарен

0

Сообщение от goray92 хм...и правда...а как это реализовать, не подскажете? чтоб в билет шел номер вагона, а не id? нужно так же, 3 нф, неидент связь. буду благодарен

просто добавить поле номер к вагону, я не эксперт по нф но вроде 3 форме это не должно повредить )
а в билете отображать через программу которая будет делать запрос через таблицу "вагоны". то есть на уровне базы данных билет естественно не знает о номере вагона. билету достаточно знать id вагона. может и можно придумать что то поизъящнее, но вроде и такой вариант годиться.
или это уже будет идентифицирующая связь? тогда я не очень понимаю, что в ней плохого

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

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

Сообщение от goray92 Эта работа намного подробней всех остальных, выложенных в инете, думаю выложу куда нибудь, чтоб если кому понадобится, не мучались как я)))

собственно я поэтому и заинтересовался. самому интересно как правильно сущности связывать.

1

в принципе...повредить не должно, если таким образом реализовать, и думаю это будет верное решение, а уже через запросы группировать не по id а по номеру.
суть неидент связи в том, что(как он объяснял) не все бд поддерживают другие связи, а эту поддерживают все без исключений, другими словами он учил нас создавать универсальные бд. Выше 3ей нф тоже поддерживают не все, как-то так, утверждать не стану, так как не уверен в словах))
а про вагон и правда, как я сам не додумался, видимо потому что устал. Ну да ладно, как раз сейчас занимаюсь написанием, пробный вариант заполнения уже готов))) вроде должно получится все идеально. Еще несколько видоизменил общую схему, ну думаю это не страшно. Спасибо за наводку))

0

хм тут подумал, что можно добавить сущность Локомотивы.
Но это из за того, что ты не дал определения термину "поезд". То есть если смотреть в вики то поезд состоит из локомотива и вагонов.(Я советую почаще в вики заглядывать, чтоб разбираться в сущностях твоей предметной области)
Если ты понимаешь под поездом сам локомотив с вагонами, то тогда можно и не вводить сущность локомотивов.

Тока проблема в том, что локомотивов в поезде может быть больше чем один.

Добавлено через 3 минуты
Суть в том, что если судить по вики поезд это не одназначное понятие. Поэтому надо дать более точное определение.

0

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

1

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

Если поверхностно, то у меня получилось:

Таблица сотрудники:
id_user
name
lastname

Таблица кассы:
id_kassa
name_kassa

Таблица кассы и сотрудники:
id_users
id_kassa

Вокзалы:
id_vokzal
name
adress
phone

Таблица вокзалы и кассы:
id_vokzal
id_kassa

Что такое расчет не понял, пропускаю.

Таблица маршруты:
id_marshrut
data_marsrut
name



маршруты и вокзалы объезда по маршруту:
id_vokzal
id_marshrue



Далее, таблица поезда:

id_poezd
name

таблица маршруты и поезда:
id_marshrut
id_poezd

таблица вагоны:
id_vagon
name

таблица места:
id_mesto
status

таблица вагоны и места:
id_vagon
id_mesto

таблица вагоны и классы обслуживания
id_vagon
id_klass_obsl

таблица виды вагонов по классу обслуживания:
id_klass_obsl
xaracteristiti_description
stoimost_proezda_в этом_вагоне

таблица вагоны и поезда:
id_poezd
id_vagon

Приходит к нам значит юзер и говорит - мне нужно к вокзалу Х, дата такая - то , хочу на купе поехать.

Сотрудник делает запрос - дайте маршруты, идущие к вокзалу Х. Идем в таблицу маршруты и вокзалы. Вытаскиваем все маршруты, идущие туда. Далее дата проезда. Вытаскиваем все маршруты, удовлетворяющие дате проезда. Далее из оставшихся маршрутов, вытаскиваем все поезда из-за всех маршрутов. Из-за всех поездов вытаскиваем все вагоны, удовлетворяющие классу обслуживания - купе. Выдаем список свободных мест. Юзер выбираем место 1 в вагоне номер 12 поезда 134 маршрута 1834. Все, в базе данных статус места меняем на занято. Юзеру выдаем билет со всеми данными.

Добавлено через 9 минут
Если бы автор свою БД показал преподу, который у нас вел, тот бы его завалил без вопросов, ибо автор даже основы не понял, непонятно, что на парах делал, и судя по всему, ни одной книжки не прочитал.

1

Сообщение от kkk008009kkk Таблица кассы и сотрудники: id_users id_kassa

это уже неодназначная связь many-many от которой все отказываются в последнее время.

1

А, сорри, автор. Не заметил условие.

это уже неодназначная связь many-many от которой все отказываются в последнее время.

Кто все? Пару ссылок накидайте, если есть.

0

Сообщение от kkk008009kkk Кто все? Пару ссылок накидайте, если есть.

скажем докладчики с yiiconf
материалы по конференции
ключевые моменты из презентации "Вкусно готовим "Многие-ко-многим""
да и я пришёл к выводу, что если у вас налицо связь many-many то это уже отдельная сущность у которой есть свой собственный id.
логически не могут относиться множество сотрудником ко множеству касс.
то есть могут, но тогда теряется функция таких отношений, которые мы вводим. а именно избежать двусмысленности.

1

А вот с кассами и сотрудниками я ошибся, да. Наверное, там еще в дальнейшем могут быть ошибки.

А по ссылкам, информация локальна, я рассчитывал на какой-то глобальный отказ, какую-то альтернативу. Вообще никогда с базами данных не работал на практике, чисто курс прослушал 2 года назад.

0

я не знаю кто источник глобального отказа, но локальные отказы встречаются повсюду


то что товарищ называет "использовать 2 связи один -ко-многим" по ссылке, я называю "определить связь "многие-ко-многим" отдельной сущностью(со своим id)"

0

Сообщение от XRuZzz то есть могут, но тогда теряется функция таких отношений, которые мы вводим. а именно избежать двусмысленности.

Первичный ключ к кассам или сотрудникам, в зависимости от заданных условий.

0

Сообщение от kkk008009kkk Первичный ключ к кассам или сотрудникам, в зависимости от заданных условий.

Это сложно объяснить. Но в связи many-many нет "первого" и "второго" ключа. В этом и проблема - есть два ключа и кто из этих ключей главнее не ясно.
У вас то ли кассы включают сотрудников, то ли сотрудники включают кассы - то есть по таблице кассы-сотрудники это нельзя сказать.
Такая база допускает что у вас Иванов будет относиться сразу к двум кассам и в какой кассе он щас находиться и за какую отвечает не ясно.
К кассе 2 могут относиться сотрудники Иванов, Петров, Сидоров и потом не найти сотрудника, который отвечает за эту кассу.
А по Дэйту база данных это набор истинных утверждений.

Я раньше создавал связь many-many, разработчики yii в первой версии сделали поддержку many-many. И все обламались.

many-many это погоня за двумя зайцами.

1

XRuZzz, Да, все понял уже. Сейчас сел проектировать одну БД и походу дела напоролся на ту же ошибку. Вкратце, Имеется таблица юзеры. Имеется таблица расы. Я сделал еще одну таблицу - "расы и юзеры" с id_user id_rasa . Информация заносится один раз при регистрации. Я так понял, тоже ошибка?

yii

По личным ощущениям yii намного лучше codeigniter? В плане, стоит попробовать, как лучшую альтернативу? Как-то хотел установить, пару лет назад. Помню там командная строка была, не разобрался, ушел))

Добавлено через 18 минут
Перечитал о связи манитомани, все понял, да, походу, у меня там ошибка, исправил.

0

Мне проще на своём примере объяснить. Раньше я создавал базу в формате таблица "сущности", таблица "сущности -описания", таблица "описания".
Например таблицы "фоты" "фоты-описания" "описания". Идея была в том, что у фотографии может быть много описаний, и одно описание можно использовать для разных фотографий. Погнался за двумя зайцами.

например
фоты
1 photo1.jpeg
2 photo2.jpeg

описания
1 Фотография с отдыха
2 Фотография с рыбалки

фоты-описания
id_фоты id_описания
1 1
1 2
2 2

и тут мы понимаем что photo2.jpeg это не фотография с рыбалки, а это фотография с работы. Сколько действий нужно сделать, чтоб исправить ошибку? сколько информации мы потеряем безвозвратно?

Сообщение от kkk008009kkk Перечитал о связи манитомани, все понял, да, походу, у меня там ошибка, исправил.

надо читать Date - An Introduction to Database Systems чтоб меньше ошибок было

Я помню тоже задавал давно вопрос в форуме про свою структуру бд со связью many many. Сказали тока "со структурой надо что то делать", но не сказали про ошибки.

1

Сообщение от XRuZzz и тут мы понимаем что photo2.jpeg это не фотография с рыбалки, а это фотография с работы. Сколько действий нужно сделать, чтоб исправить ошибку? сколько информации мы потеряем безвозвратно?

Исправить ид_описания в таблице фото-описание? Ничего не потеряем))

П.С. Если ошибся, так и напишите - "короче, в общем, читайте Дейта".

Кстати, уже скачал, сейчас сяду читать.

Добавлено через 3 минуты
Я так подумал, нам нужно удалить запись с опсианием ид "фото с рыбалки", и вставить новую запись с идом описания уже фото с работы. И тут уже начинаются проблемы.

0