Форум программистов, компьютерный форум, киберфорум
Наши страницы
MS Access
Войти
Регистрация
Восстановить пароль
 
 
Рейтинг 4.89/28: Рейтинг темы: голосов - 28, средняя оценка - 4.89
ildwine
Супер-модератор
3013 / 1893 / 1229
Регистрация: 04.03.2013
Сообщений: 4,633
Записей в блоге: 1
1

База данных по учету ремонтов компьютерного оборудования: схема данных

09.10.2014, 08:43. Просмотров 5185. Ответов 59
Метки нет (Все метки)

Здравствуйте, форумчане!

Составил схему данных. Вроде бы на данный этап учел всё необходимое.
Вложение 440975

Вопрос, можно ли так делать: таблицы "Заказы" и "Выполнения заказов" соединены связью "один к одному". Исходил из того, что при создании нового заказа часть полей по ремонту не должна заполнятся, а эти поля хотелось бы сделать обязательными. Поэтому вынес в отдельную таблицу.

Также пока не придумал куда записывать информацию по выдаче оборудования из ремонта. На ум приходит еще одна таблица со связью "один к одному".

Сама база данных: Вложение 440974

В общем, хотелось бы конструктивной критики и советов. Заранее спасибо
0
Миниатюры
База данных по учету ремонтов компьютерного оборудования: схема данных  
Вложения
Тип файла: zip ildwine_db.zip (29.8 Кб, 99 просмотров)
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
09.10.2014, 08:43
Ответы с готовыми решениями:

База данных по учету ремонтов компьютерного оборудования: формы
Здравствуйте, форумчане! Начинаю делать формы к данной схеме данных ...

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

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

База данных по учету движения материала на складе
Входные документы:Приходный ордер, Лимитная карта, Требование,...

База данных по учету движения материала на производстве - MS Access
Всем привет как сделать базу данных по учету движения материала на...

59
ildwine
Супер-модератор
3013 / 1893 / 1229
Регистрация: 04.03.2013
Сообщений: 4,633
Записей в блоге: 1
09.10.2014, 08:53  [ТС] 2
Один ответ уже есть http://www.cyberforum.ru/post6697677.html от shanemac51
База данных по учету ремонтов компьютерного оборудования: схема данных
0
ltv_1953
Эксперт MS Access
12872 / 5842 / 1127
Регистрация: 21.06.2012
Сообщений: 10,524
09.10.2014, 08:55 3
Приветствую.
Исключительно по картинке.
1. Типы оборудования. Вряд ли у оборудования может изменяться тип. Зачем указывать тип оборудования в Заказах? Для статистики всегда можно по коду оборудования вытащить его тип.
2. Исполнение заказов. Может быть связь с Заказами не один к одному, а один ко многим. Ремонт может же состоять из нескольких замен комплектующих, ... и прочих работ. Ну и поля перераспределить, если будет такое изменение.
3. Заказчики и представители. А не возможен ли вариант, когда один представитель для нескольких заказчиков?
1
ildwine
Супер-модератор
3013 / 1893 / 1229
Регистрация: 04.03.2013
Сообщений: 4,633
Записей в блоге: 1
09.10.2014, 09:47  [ТС] 4
Цитата Сообщение от ltv_1953 Посмотреть сообщение
1. Типы оборудования. Вряд ли у оборудования может изменяться тип. Зачем указывать тип оборудования в Заказах? Для статистики всегда можно по коду оборудования вытащить его тип.
Согласен
Цитата Сообщение от ltv_1953 Посмотреть сообщение
2. Исполнение заказов. Может быть связь с Заказами не один к одному, а один ко многим.
Замены здесь только на уровне всего изделия, замену конкретных блоков/радиоэлементов/расходников учитывать не планируется. То есть если пришел БП, и починить не смогли, то выдается замена, если починили, то графы замены будут пустыми. Так что всё-таки - "один к одному"
Цитата Сообщение от ltv_1953 Посмотреть сообщение
Заказчики и представители. А не возможен ли вариант, когда один представитель для нескольких заказчиков?
Нет. У заказчика (то есть подразделения) есть люди ответственные за сдачу в ремонт, либо местные сисадмины, либо закрепленные за подразделением специалисты по снабжению.

Цитата Сообщение от shanemac51 Посмотреть сообщение
мне не нравятся круговые ссылки
На счет типов оборудования и наименований согласен, только что ltv_1953 на это указал. Уберу связь, да и вообще поле "Типы оборудования" в таблице "Заказы", а вот с представителями заказчиков и заказчиками - не совсем понятно. Если оставить только связь "Заказчики" - "Заказы", то невозможно будет зафиксировать факт "Какой представитель сдавал?", а вот если оставить связь "Представители" - "Заказы", то получится, что информация о подразделении-заказчике вообще не вводится, только через связь можно будет вытащить подразделение...

Добавлено через 2 минуты
Ну хотя при вводе данных через форму можно будет явно указать заказчика...
0
ltv_1953
Эксперт MS Access
12872 / 5842 / 1127
Регистрация: 21.06.2012
Сообщений: 10,524
09.10.2014, 09:55 5
Цитата Сообщение от ildwine Посмотреть сообщение
то получится, что информация о подразделении-заказчике вообще не вводится, только через связь можно будет вытащить подразделение...
В отличии от категории изделия изменение представителей подразделений наверняка будет, как и переход представителя из одного подразделения в другое. Если для статистики важно, какое подразделение сдавало в ремонт, то нужно прописывать текущее подразделение представителя в заказ (или вести историю подразделений представителей, чтобы по дате выяснять, чьим представителем был представитель на дату заказа).
0
ildwine
Супер-модератор
3013 / 1893 / 1229
Регистрация: 04.03.2013
Сообщений: 4,633
Записей в блоге: 1
09.10.2014, 10:01  [ТС] 6
ltv_1953, для статистики важен факт "Какое подразделение разместило заказ". Представитель в принципе нужен только на момент размещения заказа, а дальше без разницы, уволится он, или перейдет в другое подразделение. Главное, чтобы он в бумагах расписался, что сдал. А списки представителей думаю просто отдельно будут редактироваться и поддерживаться в актуальном состоянии.
0
mobile
Эксперт MS Access
23030 / 13076 / 2723
Регистрация: 28.04.2012
Сообщений: 14,319
09.10.2014, 10:19 7
Чего, как мне кажется, не хватает в схеме
1. Гарантия. И ответственность по гарантии. Не исключены возвраты по гарантии. И тогда исполнение заказов уже может быть не "один-к-одному". Либо вести гарантии отдельно. Что может быть не очень хорошо.
2. Дефекты. Есть огромная разница между описанием дефекта заказчиком (как правило набор невнятных слов, сводящихся к "не работает") и дефектовкой специалиста. Описание дефектов заказчиком вряд ли удастся свести к типизированным. Их надо просто записывать со слов заказчика. Дефектовка специалистом тоже немалая проблема, поскольку дефектов может быть множество разных. В том числе и в одном заказе. И обнаруженные дефекты необходимо выносить а отдельную таблицу для каждого предмета из заказа. Таблица дефектовки специалистом связывается как "многие-к-одному" с таблицей предметов заказа по коду предмета.
3. Наличие на складе замен неисправных деталей. А также какой-то учет пополнения складов. От этого зависит (может зависеть) срок исполнения заказа, стоимость заказа и даже гарантийные обязательства, поскольку вместо оригинальной детали на складе может быть заменитель с иной ценой и иным сроком гарантии.
4. Из структуры данных совершенно не видно какой срок может занимать работа. Дата выдачи в Исполнении заказов это видимо, дата фактической выдачи, а не планируемой, т.е. той, которая обещана заказчику.
5. Насколько я понимаю, в одном заказе может быть несколько, много предметов заказа. Или на каждую единицу составляется отдельный заказ? Если в заказе может много предметов (единиц заказа), то схема никак это не учитывает.
6.Заказчик может звонить и интересоваться как идет работа. Желательно ввести стадию ремонта. Типа «Ждем детали», «Готов», «Выдан»
7. Из структуры данных невозможно определить стоимость работы, деталей замены. Думаю, что это недостаток ТЗ. Обидно делать большую работу и не сделать к ней важный кусок, завершающий ее.
8. Несколько иной аспект. Если систему предполагается вести на нескольких ПК, в том числе и у каждого мастера, у девочки на приеме, у директора, то имеет смысл сделать распределение ролей. И в зависимости от роли, предоставляется разный интерфейс и набор данных. Т.е. например директор может видеть все, но не должен менять данные, введенные мастером. Девочка на приеме видит только связанное с заказчиком и распределение работ по мастерам, а также ежедневные отчеты. Ну и так далее.
1
ltv_1953
Эксперт MS Access
12872 / 5842 / 1127
Регистрация: 21.06.2012
Сообщений: 10,524
09.10.2014, 10:20 8
Тогда по этому актуальному состоянию при выборе представителя и нужно прописывать его подразделение в заказ.
Например, как во вложении
1
Вложения
Тип файла: 7z ildwine_db.7z (30.2 Кб, 24 просмотров)
ildwine
Супер-модератор
3013 / 1893 / 1229
Регистрация: 04.03.2013
Сообщений: 4,633
Записей в блоге: 1
09.10.2014, 12:42  [ТС] 9
Цитата Сообщение от mobile Посмотреть сообщение
1. Гарантия. И ответственность по гарантии. Не исключены возвраты по гарантии.
Ну это не особо принципиально, потому что все заказчики ведомственные подразделения. Денежный вопрос и ответственность не обсуждается. Если будет возврат, то будет новый факт приема в ремонт. Один и тот же экземпляр техники бывает в ремонте не один раз.
Цитата Сообщение от mobile Посмотреть сообщение
5. Насколько я понимаю, в одном заказе может быть несколько, много предметов заказа. Или на каждую единицу составляется отдельный заказ?
1 единица техники - 1 заказ
Цитата Сообщение от mobile Посмотреть сообщение
7. Из структуры данных невозможно определить стоимость работы, деталей замены.
Как уже писал выше, денежный вопрос вообще не важен. Для нашего конкретного отдела важен учет фактов ремонта, учет работ конкретных специалистов и документооборот, с возможностью выбора разнообразной статистики в отчетах.
Цитата Сообщение от mobile Посмотреть сообщение
2. Дефекты.
Дефекты, указанные заказчиком думаю брать из справочника "Неисправности", список наиболее типовых хранить там. Для указания специфики предусматриваю поле "Примечание заказчика" в таблице "Заказы". Неисправности после диагностики специалистом думаю записывать в поле "Характер неисправности после диагностики" таблицы "Исполнение заказов" в текстовом виде.
Цитата Сообщение от mobile Посмотреть сообщение
8. Несколько иной аспект. Если систему предполагается вести на нескольких ПК, в том числе и у каждого мастера, у девочки на приеме, у директора, то имеет смысл сделать распределение ролей.
База рассчитана на однопользовательское использование на локальной машине.
Цитата Сообщение от mobile Посмотреть сообщение
6.Заказчик может звонить и интересоваться как идет работа. Желательно ввести стадию ремонта. Типа «Ждем детали», «Готов», «Выдан»
Вот тут согласен полностью, ну да у меня этого еще и нет. Надо добавлять. Также должны быть несколько исходов "Отремонтирован", "Заменен", "Составлен акт о непригодности"... Это пока в схеме не отражено.

Добавлено через 16 минут
Еще кстати вопрос: обеспечение целостности данных я везде проставляю, а каскадное обновление и удаление нужно или нет?
0
mobile
Эксперт MS Access
23030 / 13076 / 2723
Регистрация: 28.04.2012
Сообщений: 14,319
09.10.2014, 13:31 10
Нашел у себя в закромах таблицы какой-то компьютерной фирмы. Таблица Неисправности - описание клиента, таблица Дефекты - дефектовка мастера. Не знаю поможет ли Вам хоть чем-то. Хотя бы хоть как-то классифицировать и упорядочить. Не говорю о жалобах клиента, там полный произвол. Дефектовка мастера важнее.
1
Вложения
Тип файла: rar Неисправности.rar (71.8 Кб, 63 просмотров)
ildwine
Супер-модератор
3013 / 1893 / 1229
Регистрация: 04.03.2013
Сообщений: 4,633
Записей в блоге: 1
09.10.2014, 13:43  [ТС] 11
mobile, спасибо. У нас, в принципе, база то и сейчас же ведется только на Excel+VBA, там список неисправностей есть.
0
ildwine
Супер-модератор
3013 / 1893 / 1229
Регистрация: 04.03.2013
Сообщений: 4,633
Записей в блоге: 1
09.10.2014, 14:45  [ТС] 12
Цитата Сообщение от ltv_1953 Посмотреть сообщение
Тогда по этому актуальному состоянию при выборе представителя и нужно прописывать его подразделение в заказ.
За пример подстановки в форму спасибо.
Но всё равно непонятно оставлять всё-таки связи обе связи (1 и 2)?
База данных по учету ремонтов компьютерного оборудования: схема данных

А если всё-таки представитель с одного подразделения перейдет в другое, то удалять его там нельзя. Иначе потеряется информация в заказах о том кто сдавал. Пришла в голову мысль добавить логическое поле в таблицу "Представители", мол "активен"/"неактивен", если уволился, помечать неактивным. Но если перешел в другое подразделение, то добавляя его туда, будет дубликат данных.
0
ltv_1953
Эксперт MS Access
12872 / 5842 / 1127
Регистрация: 21.06.2012
Сообщений: 10,524
09.10.2014, 15:06 13
Цитата Сообщение от ildwine Посмотреть сообщение
Но всё равно непонятно оставлять всё-таки связи обе связи (1 и 2)?
Оставлять. Как же без них поддерживать целостность данных. Не, ну можно макросы данных использовать (как в старых MS SQL использовались триггеры для поддержания целостности данных), но зачем эта головная боль.
Цитата Сообщение от ildwine Посмотреть сообщение
А если всё-таки представитель с одного подразделения перейдет в другое, то удалять его там нельзя.
Его нужно не удалять, а изменять подразделение, которое он теперь представляет. Ничего не пропадет, т.к. в заказе прописаны и представитель и то подразделение, которое он представлял на момент формирования заказа.
Цитата Сообщение от ildwine Посмотреть сообщение
Пришла в голову мысль добавить логическое поле в таблицу "Представители", мол "активен"/"неактивен", если уволился, помечать неактивным.
Это стандартное решение. Удалять его нельзя т.к. на него есть ссылки в заказах. А чтобы он не путался в списках представителей, там отображают только активных (при входе в поле представителя).
Цитата Сообщение от ildwine Посмотреть сообщение
обеспечение целостности данных я везде проставляю, а каскадное обновление и удаление нужно или нет?
Если связи только по основным полям-счетчикам, то каскадное обновление не нужно - изменить счетчик нельзя. Каскадное удаление не ставьте (в Вашей базе применения его не видно). Рискуете, поставив, удалить случайно вместе с заказчиком, например, все его заказы и представителей.
1
ildwine
Супер-модератор
3013 / 1893 / 1229
Регистрация: 04.03.2013
Сообщений: 4,633
Записей в блоге: 1
10.10.2014, 19:34  [ТС] 14
Схема с учетом исправлений на текущий момент:
База данных по учету ремонтов компьютерного оборудования: схема данных
0
ildwine
Супер-модератор
3013 / 1893 / 1229
Регистрация: 04.03.2013
Сообщений: 4,633
Записей в блоге: 1
13.10.2014, 12:36  [ТС] 15
Итак, добавил таблицы "Выдача заказов" и "Статус заказа".
"Выдача заказов" имеет связь "один к одному" с "Размещения заказов". Ну и связи с представителями и сотрудниками.
В данной таблице будут фиксироваться факты выдачи оборудования из ремонта: кто выдал, когда, кто принял от подразделения.

Что скажете?
Итоговый вариант БД: ildwine_db_13_10_14.zip
Схема данных:
База данных по учету ремонтов компьютерного оборудования: схема данных
0
ildwine
Супер-модератор
3013 / 1893 / 1229
Регистрация: 04.03.2013
Сообщений: 4,633
Записей в блоге: 1
13.10.2014, 21:52  [ТС] 16
Думаю приступать к формам... Вот хотел бы услышать вердикт...
0
ildwine
Супер-модератор
3013 / 1893 / 1229
Регистрация: 04.03.2013
Сообщений: 4,633
Записей в блоге: 1
16.10.2014, 11:28  [ТС] 17
Новые сложности...
При добавлении факта ремонта через форму Access выдает ошибку "Невозможно добавление или изменение записи. Для обеспечения целостности данных необходимо наличие связанной записи в таблице 'Исполнения заказов'.
База данных по учету ремонтов компьютерного оборудования: схема данных

Таблицы связаны отношением один к одному. Как с этим бороться? Получается такая схема неприемлема?
0
mobile
Эксперт MS Access
23030 / 13076 / 2723
Регистрация: 28.04.2012
Сообщений: 14,319
16.10.2014, 11:44 18
Я давно хотел предупредить о сложностях в связи таблиц "один-к-одному". Нужно постоянно следить за ними, добавляя ключи. Это аналогично тому как держать вычисляемое поле в таблице. Хотел написать, но забыл :-(

Лишь в редких случаях таблицы со связями "один-к-одному" желательно применять. Скажем, когда количество полей таково, что просто не вмещается в рамки спецификаций. Такое бывает достаточно часто в экологических проектах, химических и геофизических БД, в задачах испытания материалов. Но Ваша задача иная, количество параметров мало и совершенно не имеет смысла иметь таблицы "один-к-одному". Только дополнительные сложности. Соедините таблицы в одну, если конечно логика данных позволяет, и забудете об этих сложностях
2
ltv_1953
Эксперт MS Access
12872 / 5842 / 1127
Регистрация: 21.06.2012
Сообщений: 10,524
16.10.2014, 11:50 19
Измените связь этих таблиц. Насколько я помню, основная - Размещения_заказов (заполняется раньше, чем Исполнения_заказов), а по схеме наоборот. Нужно так, чтобы связанной (подчиненной) стала Исполнение_заказов. Связь удаляете и заново делаете - тяните мышью от Размещения к Исполнению.
1
Миниатюры
База данных по учету ремонтов компьютерного оборудования: схема данных  
ildwine
Супер-модератор
3013 / 1893 / 1229
Регистрация: 04.03.2013
Сообщений: 4,633
Записей в блоге: 1
16.10.2014, 15:17  [ТС] 20
Связи поменял. Вроде получилось.

Вопрос такой... ltv_1953, вот вы мне присылали пример подстановки в форму. Пытаюсь делать как у вас - не получается...
Я пытаюсь сделать форму для ввода представителей заказчиков такого вида:
База данных по учету ремонтов компьютерного оборудования: схема данных

В обведенном поле "Код заказчика" мне нужна подстановка значений запроса:
База данных по учету ремонтов компьютерного оборудования: схема данных
База данных по учету ремонтов компьютерного оборудования: схема данных

Однако, в выпадающем списке подставляется первый столбец запроса (цифры). Пробовал делать запрос без отображения столбца "код заказчика", тогда подставляется список подразделений, но после ввода возникает ошибка, мол, несоответствие типов данных в поле формы и поле таблицы, что логично, ибо пытаюсь подставить текст в числовое поле.
Изучал то, что у вас в конструкторе формы: вроде всё также. Смотрел код VBA, но там прописано обновление другого поля...
База данных по учету ремонтов компьютерного оборудования: схема данных

Подскажите, что я делаю не так? Вроде всё просто должно быть, а не получается.
БД на текущий момент: ildwine_db_16_10_14.zip
0
16.10.2014, 15:17
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
16.10.2014, 15:17

База данных оборудования
Доброго времени суток, уважаемые форумчане! В организации есть оборудование...

База данных для инвентаризации оборудования
Добрый день! Только вчера начал изучать Access, поэтому не очень уверен в...

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


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
20
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.
Рейтинг@Mail.ru