DB схема - работа, оферта, състояние на работа

Проектирам база данни (в MS Access 2010, но мисля, че за този въпрос това няма значение), за да съхранявам информация за оферти и поръчки за дограма.

Това е първият ми голям проект за база данни и макар да чувствам, че съм схванал концепциите за нормализиране, имам сериозни проблеми да се ориентирам как да структурирам частта за обработка на офертата и работата.

Ключови точки:

  • Когато клиент направи запитване, се изготвя оферта или няколко оферти.
  • Създадените цитати може да включват вариации на едно и също нещо. Например една оферта може да бъде за 10 прозореца, боядисани в бяло, а друга оферта може да бъде за същите прозорци, боядисани в зелено (ние таксуваме допълнително за небели цветове). Може да има и отделни цитати, напр. един за прозорците на къща и един за някои врати.
  • Това е за дограма, изработка на прозорци, врати и т.н. - това означава, че се изготвят оферти, но те не се отнасят до таблица "продукти", тъй като всичко е еднократно. Лицето, което съставя офертата, просто ще напише нещо като "Двоен прозорец 1200x1000 - Спалня 1" и цена в отделно поле и този ред ще бъде добавен към офертата.
  • Всяка оферта ще има набор от подробности, прикачени към нея, които се считат за основни подробности за цялата оферта. Има около 120 полета, някои от които са за текст, а други са булеви, които съхраняват информация за работата. Това са неща като „Тип стъклена рамка“ (текст) и „Задачата включва плъзгащи се врати“ (булева). Те са важни, тъй като в тези полета се записва точно какво е цитирано и нашите дизайнери ще се позовават на тях по-късно. Те също ще формират основата на документ за одобрение, който изпращаме на клиента за подписване, преди да произведем нещо. Мисля, че това трябва да бъде настроено по този начин, защото обикновено се получава така, че ако правим да речем 10 прозореца за оферта, те споделят почти всички детайли като цвят на боята и тип стъкло. Ще има и поле за раздел/бележка за специални бележки относно неща, които се отклоняват от нашите стандартни спецификации и т.н.
  • Офертите могат да имат статус „На живо“, „Мъртъв“ или „Прогресира към поръчка“.
  • Един или няколко котировки могат да се превърнат в една „задача“, която да бъде обработена заедно и произведена наведнъж. Например можем да предложим някои прозорци и някои врати поотделно, клиентът решава, че иска да поръча и двете от нас едновременно, така че ние ги обработваме заедно. По подобен начин клиент може да има няколко „фази“ към една и съща поръчка, напр. те може да имат 10 прозореца от нас един месец и 10 прозореца от нас 3 месеца по-късно, когато друга част от къщата им е готова, въпреки че може да са били котирани по същото време.
  • Офертите често трябва да бъдат преразглеждани, тъй като клиентите променят мнението си за това, което искат.
  • Също така искам всяка „Работа“ (която може да се състои от няколко котировки) да има набор от JobDetails, който е обобщен списък за цялата поръчка.

Ето какво имам в момента: Диаграма на връзката на базата данни

Но наистина не съм сигурен дали го правя по най-добрия начин, тъй като нямам опит с подобни неща.

Таблицата Job също се свързва с таблица Accounts, която съдържа клиенти и т.н., но не съм показал това, тъй като не е напълно подходящо за разглеждания проблем.

Мисля, че "ревизираните" котировки всъщност трябва да създадат нов запис, копирайки данни от друг цитат и променяйки ги, така че да се създаде одитна пътека, и същото с JobDetails - ако JobDetails на работа се променят и/или са различен от JobDetails на Quote, тогава това трябва да бъде маркирано (тъй като клиентът може да трябва да плати повече).

Някой има ли препоръки за най-добрия начин да се справите с това?


person WhatEvil    schedule 10.07.2014    source източник


Отговори (1)


Следното би било много по-изчистен дизайн - имате твърде много свързани таблици, които не е необходимо да бъдат свързвани, ако релациите са зададени правилно:

EER


Пропуснах таблиците за плащане във вашия пример, те трябва да бъдат включени, както ги имате по-горе, връзките са правилни в тях.
Освен това таблицата JobDetails може да бъде обединена с действителната таблица за работа, тъй като от описанието ви по-горе те имат връзка едно към едно - можете, ако желаете, да я имате в отделна таблица, тогава просто ще трябва да препраща към работата само таблица, а не таблици с котировки и т.н

person kbbucks    schedule 10.07.2014
comment
Вероятно трябваше да го направя по-ясно - искам да имам одитна пътека за JobDetails. Ако работата е била цитирана като боядисана в бяло и един от дизайнерите я е променил на боядисана в зелено, тогава трябва това да бъде отбелязано в отчетите по време на фактуриране на клиента (те ще трябва да платят повече!) . Също така JobDetails трябва да се прилага както за работни места, така и за оферти. - person WhatEvil; 10.07.2014
comment
относно подробностите за работата: искам също всяка работа (която може да се състои от няколко котировки) да има набор от JobDetails, който е обобщен списък за цялата поръчка. Трябва да обобщите подробностите във вашия софтуер/процедура за отчитане, а не в друга таблица – т.е. като използвате оператор Select. - person kbbucks; 11.07.2014
comment
също по отношение на одитната пътека, все още трябва да можете да се справите с това в таблицата QuoteLine, като използвате различни състояния, след това можете да използвате superceded_QuoteLineID, за да се свържете с QuoteLine с актуализираните подробности - всички те така или иначе ще бъдат свързани обратно към заданието чрез съответния JobID - по отношение на следването на одитната пътека, която ще зависи от начина, по който докладвате за нея. - person kbbucks; 11.07.2014