Нужен совет по пострению БД?

Question

[Myshka]

Привет :3
Нужно спроектировать базу данных бесконтактных карт метрополитена(RFID-меток) для этого есть четыре таблицы со следующими связями.
Таблица cards
id_card - номер карты
cash - текущее количество поездок
station - станция на которой последний раз ею пользовались
time - время последнего использования
status - рабочаю\не рабочая

Таблица station - перечисляются все станции метрополитена.
Таблица history_add - история пополнения карт
Таблица history - история передвижения носителей карт



Дайте, пожалуйста, совет как "нормализировать данные"(привести их к какой-то из НФ). И что б Вы ещё сюда добавили :3

Comments

[entermix]

cash - почему int? Что если баланс 22р50к? Или в копейках будете хранить?

cash - почему int? Что если пополнение 22р50к?

Имеется в виду количество поездок, а не остаток средств (денег)

[Myshka]

Кандрашкин Алексей:

cash - почему int? Что если баланс 22р50к?

entermix прав, в данном случае "cash" - не сумма денег, а кол-во поездок.

История пополнений? А где история списаний?

История списания - и есть история использования карты. Одно использование = "-1" в поле "cash".

Answer 1

[entermix]

cards
id (INT), status (BOOL), ...
stations
id (INT), name (VARCHAR), ...
operatioons
id (INT), station_id (INT), operation (INT) (+1/-1, etc), balance (INT), created (INT)...

station - станция на которой последний раз ею пользовались

time - время последнего использования

SELECT FROM `operatioons` WHERE `station_id` = {STATION_ID} ORDER_BY created DESC LIMIT 1

Выведет последнюю операцию с картой, отсюда можно взять ID станции и время, когда картой воспользовались (пополнили счет/прошли турникет)

Comments

[Myshka]

Т.е. теперь не четыре, а три таблицы?

[entermix]

Myshka: да, а зачем Вам 4?

[Myshka]

entermix: ну это типа на курсовую и сказали "Чем больше - тем лучше." :|

[entermix]

Myshka: ну не знаю, сомневаюсь, что "Чем больше - тем лучше." - действительно лучше, обычно наоборот, сейчас это 3НФ, этого вполне достаточно.

Можно еще так сделать:

cards
id (INT), status (BOOL), ...
stations
id (INT), name (VARCHAR), ...
operatioons
id (INT), type_id(INT) station_id (INT), sum(INT), balance (INT), created (INT)...
operatioon_types
id (INT), name (VARCHAR), ...

В таблице operatioon_types будет всего две записи

1, Платежи
2, Расходы

[Myshka]

entermix:

ну не знаю, сомневаюсь, что "Чем больше - тем лучше." - действительно лучше, обычно наоборот,

А можете глянуть на эту карту таблиц и сказать в какой она форме и нормально ли там всё вообще? Это из одной уже готовой курсовой.

[entermix]

Myshka: ну это уже совсем другой вопрос, вам нужно добавить новую тему, чтобы получить ответ.

[Myshka]

entermix: ок)

Answer 2

[Rsa97]

IMHO, полностью нормализованная форма будет содержать всего две таблицы:

stations (id, name);
events (card, event, station_id, sum, timestamp)

где event: ('активация', 'приход', 'расход', 'блокировка', 'возврат', 'списание')
Но здесь есть смысл в частичной денормализации и добавлении поля balance и, если возможны какие-то операции с заблокированной картой, то поля state.

Comments

[d-stream]

Все-таки три: еще атрибутика карт.
то бишь в events - card - это id
и плюс cards (card, card attributes...)

[Rsa97]

d-stream: В оригинальной базе атрибутов вроде не заложено. Но если они нужны, то таки да, нужна будет ещё таблица.

[Myshka]

d-stream: в смысле "атрибутика карты"?

[d-stream]

Myshka: ну например наличие логотипа на карте, некий уникальный номер (который может не совпадать с rfid id), всякие юбилейные серии и т.п.

Ну или как более понятное - большой ассортимент RFID идентификаторов в виде твердых, мягких карт, брелоков разного вида, наклеек и заготовок - знание что это (карта, брелок, кольцо) - может оказаться полезным

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

[Myshka]

d-stream: как по-мне, то наличие card_id, который может не совпадать с rfid id, не спасёт от копирования. Чтоб отслеживать оригинальная ли карта и записывается история проходов через турникет и история пополнения. Т.е. идея такая: если человек прошёл на одной станции, а через минут пять-десять он проходит на другой, которая стопятсот минут от него - значит карта краденая и её блокируют, а сам человек не пропускается. Так же при копировании можно менять сумму оплаченных проходов. Для этого и ведётся история пополнения и текущие кол-во поездок.
Если в число поездок в базе отличается от записанных на карте - карта тоже блокируется.

[d-stream]

Myshka: спасать и не надо. Надо просто уметь хранить множество карт у которых id совпадает

а типовых и практическо-типовых сценариев - 100500, например заблокированной может оказаться "правильная" карта - с последующим скандалом -)))

[Myshka]

d-stream:

а типовых и практическо-типовых сценариев - 100500, например заблокированной может оказаться "правильная" карта - с последующим скандалом -)))

это ж норма. В таком случае блокируются обе карты! И носитель оригинальной подходит к бабушке на льготном турникете и грит:"Что это за...?". А она такая:"Подойдите в кассу.". Товарищ идёт в кассу, где, естественно, после долгих разбирательств(без них никуда :D) получает новую карту с текущим кол-вом поездок :-)
И все радуются жизни, кроме чувака с поддельной картой :(

[d-stream]

Myshka: но это совершенно не мешает и не помогает в плане идеологии построения структуры БД

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

[Rsa97]

d-stream: А смысл? Если со считывателя вам пришла только rfid-метка, то сможете сказать какой из десяти дублирующих карт она принадлежит?

[Myshka]

d-stream: в Украине нету школьных карт, у школьников удостоверения картонные и их пропускаю бабушки на льготных турникетах, предварительно проверив актуальность даты.
Насчёт цвета, то он у всех одинаковый, зелёный.
У меня база для карт с накоплением поездок и она только на метро, а у студентов - безлимитный проездной.

[d-stream]

Myshka: то бишь студенческий безлимитный проездной - та самая точка монетизации для жуликов.
И да, это же курсовая -)

[Myshka]

d-stream:

И да, это же курсовая -)

Ну да, можно пофантазировать :D
Что ещё посоветуете придумать, чтоб увеличить кол-во таблиц?
Пы.Сы. если не сложно - загляните в коменты предыдущего ответа. Там карта таблиц с уже готовой курсовой. Можете сказать какая там НФ и есть ли она там вообще? :D

[Rsa97]

d-stream: Кстати, вот как раз тариф карты (стандарт, школьный, студенческий, пенсионный, депутатский) может храниться в её атрибутах. А цвет, вкус и запах хранить смысла не имеет.

[d-stream]

Myshka: Я курсовые не дарю, не продаю -)

Rsa97: Главное, что это должна быть как минимум одна отдельная таблица

[Myshka]

d-stream:

Я курсовые не дарю, не продаю -)

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

[d-stream]

Myshka: смотреть непонятно куда - лениво -)
А так - подвесить кассы по продаже карт (+1 таблица), кассиров (+1 таблица), журнал продаж карт (касса, кассир, карта) - еще +1

Потом можно реализовать не попоездочные варианты, когда на карте Х поездок и каждый проход -1 поездка, а суммовой - на карте XX денежек, а цена поездки зависит от времени суток и дня недели

Ну и всякие варианты типа "вторая поездка в течении часа - за полцены"

[Myshka]

d-stream: спасибо :)
Буду размышлять :D

[d-stream]

Myshka: че тут размышлять? срочно патентовать и продавать метрополитену -))

[Myshka]

d-stream: точно, у них же там к концу года переворот намечается :))
Хотят полностью от жетонов отказаться и перевести людей на пластиковые карты. А тут я налечу со "своими" идейками :D