Добрый день.
Проектирую базу для ПО по учету компьютеров и оборудования.
Вот что получается.
Может быть что-то нужно исправить? И хотел бы услышать мнение о нормализации) 2нф и 3нф :)
Какие могут быть проблемы? Что не учел?
Спасибо!

prgmr_1. Пароли в таблице хранить... странно.
можно и md5... ну не суть) я ж еще учусь))

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

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

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

она называется оборудование) все что красным - это я подписал для общего понимания назначения таблицы :)

prgmr_4. Ссылки должны быть числовыми, а не varchar. ID (ключ), ParentID (ссылка на ключ). К примеру "бренды производителей". Справочники обычно: {ID, Код, Наименование}
спасибо, невнимательность, поправил.

prgmr_li4nostв таблице статусов буду хранить только наименования самих статусов. т.е. "на складе", "выдано", "в ремонте"....
Ну если не критично, можно и так. Просто я думал, что надо будет знать когда на складе появилось, когда выдано и когда времонт попало. Тогда нужна история.
История статусов оборудования
==============
id, idОборудования, idСтатуса, дата начала, дата окончания

Текущий статус берется на дату, к примеру текущую, по запросу.

Но если такое не нужно, то можно хранить ссылку на последний статус

переделал
а по связям нет претензий?

постоянный мемберБросилось в глаза малое число текстовых полей и их экстремально малая длина - 20 симв.
на это не обращайте внимания. перед генерацией скрипта все подделаю.

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

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

постоянный мемберСамая большая беда в сабже - пересорт, т.е. учетная единица вроде есть, но неверно посчитана/выдана/получена/внесена/списана и пр.
Удобные механизмы позволяют быстро определять данные проблемы.


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

или считать именно единицы учета?
т.е. всего 50, выдано 30, в ремонте 21 - значит беда?

постоянный мемберзы: в вашем случае также будет иметь место перекомплектация оборудования (замена памяти/винтов/приводов), что тоже надо как-то учитывать.
да, важный момент упустил...
но сейчас сложности у меня... таблица замены оборудования "tb_Replace":
replaceNO
replaceDate
repplaceDESCR
а дальше конфуз... комплектующие и все оборудование хранятся в одной таблице - tb_Eqipment
следовательно мне нужно указываем в чем я менял что-либо - ссылка на таблицу tb_Eqipment
и на что я менял - опять на tb_Eqipment...


Проверьте, пожалуйста, правильно сделал?
в таблицу tb_Eqipment добавил replaceNO
а в tb_Replace буду хранить только то, на что менял.
но опять же, если у меня на учете стоит системник целиком, а меняю я только оперативную память? как быть?

подумал, подумал... )))

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

Так же решил сделать что-то вроде карточки компьютера - для каждого пк и ноутбука буду указывать основные части - оперативка, жесткий диск, проц и видео. Все это будет хранится в таблице tb_isPC.
И тут вопрос назрел: будет ли связь между tb_Eqipment и tb_isPC идентифицирующей. и внешний ключ будет являются PK для таблицы tb_isPC? или лучше не заморачиваться и сделать суррогатный?

всех с новым годом :)
Значит проблем с нормализацией пока нет?

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

готово, спасибо.

wamacoа в tb_Eqipment добавь вид оборудования (memory, hdd, video и т.д.)
т.е. добавь справочник "вид оборудования" и свяжи один-ко-многим с tb_Eqipment.
он есть. таблица tb_Types

wamacoв таблице tb_isPC должна быть одна ссылка на tb_Eqipment
она тоже есть. только на схеме отображена как часть составного PK
я вот думаю, что можно убрать суррогатный ключ из таблицы tb_isPC, оставить только внешний ключ.

wamacoтаблицу tb_isPC сделай мастер, а к ней подчиненную с перечнем комплектующих из tb_Eqipment
не понял, зачем?

zeon11Таблицы workers и contacts -
Я думаю, что всё-таки тут сомнительно - приобретаешь одну таблицу, но теряешь гибкость.
Представь, через некоторое время тебя просят для поставщиков занести в лист контактов несколько человек - и всё, приплыли, переделывать БД.
согласен, сделал таблицу менеджеров :) у каждого менеджера есть место работы и контакт)


zeon11Ремонт у тебя никак не связан с заменёнными деталями. Если тебя спросят, принтер ремонтировали в прошлом году три раза, какие детали заменили?
Что, будешь искать, у какой детали замена произошла в дату, когда принтер находился на ремонте между REP_START_DATE и REP_END_DATE?

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

zeon11Users является подмножеством Workers. Может стоит объединить в одну таблицу?
Добавить в Workers доп. поле логическое UserBD? Туда-же добавить поле, характеризующее статус(уволен, в отпуске, работающий). В БД пускать при наличии двух признаков - работает и пользователь.
не, мне так больше нравится)
в суровых буднях человек может что-то делать для организации, не находясь в штате...))
но добавил поле "состояния" сотрудника - работает/не работает


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

------------------------------------
так как я хочу хранить копии документов связанных с оборудованием (накладные, гарантийники и т.п.), добавил таблицы tb_Docs и tb_DocLisk. Первая хранит ссылку на документ. Вторая связывает их с оборудованием