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

OFF

Тема очень интересная - мне пондравилось... начал примерять "под себя" как можно полежать - и так :|- и так .\= и так `/\/....

И заказа нет.... Хм.. Есть пасспорт, место, описание - масса всего ... а где деньги, Зин?

Ой нет - он вреде бы есть... Главный ... но его как бы и нет.

В Этом раскладе коллега - у Вас смешалось в кучу кони люди. Я не смею Вас критиковать - не поймите меня превратно.. Смотрите - заказ надо выдавать заказчику. У Заказчика есть свои атрибуты (которых я не нашёл - вот что меня смутило) В Заказе будут какие то товары и услуги. Линии заказов. Со своими атрибутами. Которые Вам любезно раскрыли наши коллеги. Потом это всё сложится и распечатается "к оплате" А что у Вас будет?

Ваша Табличка ЧЕЛОВЕК напоминает мне сокраментальную фразу: "А БЕЗ Покойника?" © (по трёшке хоть это и унизит наше достоинство)

Cat2
Деньги - это самое главное! Ведь все это создается ради учета денег.




Отлично!!!

> Avtoru

Никогда не забывайте об ЭТОМ

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

Мне нравится Ваш энтузиазм Кириллко - коллега. Но Мне правильно намекнули - у ВАС диплом, а я Вас сбиваю... На всякие там мелочи. Давайте бросим всё и полежим в наших гробах (которые находятся на складе о котором Вы ТОЖЕ не упомянули). Эта часть процесса называется ИНВЕНТАРИЗАЦИЕЙ. Зачем нам (а особенно мне) вся эта дребедень??? (Извините за Сарказм...)

Кириллкоя понял... большое спасибо за уделенное время

Коллега, не обижайтесь прошу Вас... просто Вы попросили совета, а внять полученным советам не сочли нужным. Отдохните - приходите утром Мы ещё раз рассмотрим Ваш проект. И обязательно поможем.

Извините Коллега, Кириллко. Давайте посмотрим на ошибки - чувсвую себя нехорошо - человек старался а мы.... Итак:

Кириллкосуть в том что у нас есть проход, на протяжении которого составляется заказ... с клиента спрашиваются все данные,


Итак ПРОХОД - это опросник - Правильно я понял? Кроме него есть какойто журнальчик с примерами УСЛУГ и ТОВАРОВ.

Кириллко
предлагаются варианты, и в итоге в бд заноситься информация по:
данные клиента
данные объекта(трупика)


Но у Вас же нет ни тех данных ни других. Аттрибуты ЗАКАЗЧИКА: Адрес, Телефон, ФИО, Е-Меил, е т.д. А аттрибуты ОБЪЕКТА - ДеньРождения, ДеньСмерти, ФИО, Пол, ну и что там ещё - со временем - Место на кладбище...

Кириллко
что делаем(кремирование, похороны)
что выбираем(гроб урна памятник кладбище)


Тут у нас начался салат оливье: Можно разнести на две таблички - а можно всё и в одну - с кодом ТОВАР / УСЛУГА

Кириллко
что делаем(панихида отпевание питание вывоз трупа)


Вот здесь у нас начинается повтрорение - ЧТО ДЕЛАЕМ уже было - см Выше. В Реальной жизни может и так (де-нормализовано) было бы - по коду ИСПОЛНИТЕЛЬ УСЛУГИ - Ваш же бизнес агентский - а он не обязательно является производителем ВСЕХ услуг...

Кириллко
собственно каждый этот проход должен храниться в бд.....

Так то оно так, но а откуда взялись таблички МЕСТО, ОПИСАНИЕ, ТИП и так далее? Позвольте поинтересоваться ЧТО с ними делать?

Кириллко.... у меня есть уже готовая программа на диплом, со сделанной бд. но вот уважаемому ГАКу врядли подойдет моя бд. обязательно нужно третья НФ. собственно вот....

Думаю что ГАКу не 3NF надо а Ваше понимание процесса построения системы. Вы можете оспорить (как это делалось не раз) необходимость существования 3NF - И поверьте мне - если Ваши доводы будут аргументированы - Вы пройдёте на ура. Если такая система существует и работает - я бы поддверг ее и ее создателей беспощадной критике на так называемом Code Review. И если бы они сумели защититься с приведением метрологических показателей - я бы запросто признал свою несостоятельность. Но боюсь что это вряд ли бы удалось. я не буду забивать Вам голову, ув Коллега, что бы посоветовал в ВАШЕМ случае (у Вас ведь всё есть) - сначала НОРМАЛИЗУЙТЕ ВСЁ, покажите схемку полностью нормализованной структуры такой как ее описАл наш ув Коллега Cat2. А потом частично де-нормализуйте ее в то что у Вас получилось с объяснением что таков более удобный в плане организации кода способ ведения учёта. Но не забудьте про денюшку... очень Вас прошу. Вот и всё.

Кириллкопроход это интернет сайт в виде "мастера"..... я в итоге разбил на две таблицы Процесс и Предмет.

То что Вы описАли здесь - простой Order Entry Process. Ничем не отличающийся от классического заказа велосипедов или пиццы через интернет. Данные таким образом Вы может и внесёте а вот когда наступит время отчётов.... И надо будет эти данные выводить.....Ойййй ...

Кириллко
таблица действие содержит в себе названия возможных действий: вывоз, панихида, отпевание....
Таблица процесс непросредственно хранит в себе инфо о каждом действии и его параметров, ибо для вывоза, панихиды и тд эти параметры разные....


Вот смотрите даже в языке повторение ДЕЙСТВИЕ на мой взгляд это тот же ПРОЦЕСС
Вы так я думаю имели ввиду ДЕЙСТВИЕ как ЧАСТЬ процесса, но тогда Ваше ПИТАНИЕ - это тот же процесс. Посмотрите на структуру - ОНИ ИДЕНТИЧНЫ за маленьким исключением значения Действия_ID в Табличке Питание. Если их объединить то ПИТАНИЕ станет ПРОЦЕССОМ в котором нет действий. Ведь так?

Кириллко
Таблица тип содержит в себе: гроб, памятник, урна.
Состав соответственно:дерево, железо, пластилин и так далее.
ПРедмет: соответсвенно нашу вещь и подробное ее описание...

Теперь о Типе и Составе. Смотрите - все эти компоненты - денежно зависимые. От изменения состава - изменится цена у самого типа. То есть Вы попытались развести неразводимые атрибуты и проблемы начнутся когда их надо будет свести обратно - а их надо свести обратно потому как ГРОБ из дуба в цене <> ГРОБУ из пластика.

Кириллконо как быть с атрибутом количества человек? как его использовать? что касается типа... =( не знаю что и делать...

Коллега, а теперь давайте повнимательнее рассмотрим советы мудрейших по организации Вашей Базы. Давайте посмотрим на Заказ (информация о Клиенте) и Количество - как каждую часть Заказа (информация о Товаре Услуге) . Они связаны с Атрибутами - Реально предлагаемыми наборами СЕРВИСА - каждый атрибут - а один из них питание (на единицу измерения РОТ) имеет ценовую характеристику. То есть будет

ЗАКАЗ #12345 | 14 Ноября | Вася Пупкин {Данные Васи}
На {услугу} ПОХОРОНЫ Пети Пупкина {данные Пети}

#12345 | Линия 1 | Атрибут Услуга 1 (Похороны) | 1 (шт) | { 123 Рб} | {на кладбище}
#12345 | Линия 2 | Атрибут Услуга 2 (Вынос Тела) | 1 (шт) | {555 Рб} | {из дома}
#12345 | Линия 3 | Атрибут Услуга 3 (катафалк) | 2 (машины) | 2 х {222 Рб} | {У Дома}
#12345 | Линия 4 | Атрибут Товар 1 (Гроб Дубовый) | 1 (шт) | {444 Рб} | {На Складе}
************
#12345 |Линия 30 | Атрибут 88 Услуга (Поминки) | 120 (ртов) | 120 х {300 Рб} = 3600 Рб| {в кабаке}




:
Заказы
{
КодЗаказа
Номер документа
Дата документа
Заказчик
}

Количество
{
КодЗаказа
КодВидыТоваровУслуг
КодАтрибута
Количество
}

Атрибуты
{
КодТипыТоваровУслуг
КодАтрибута
Название атрибута
Значение атрибута
КодЕдиницаИзмерения
ЦенаЗаЕдиницу
КодМестоПредоставления
}

MестоПредоставления
{
КодМестоПредоставления
Название
}

ТипыТоваровУслуг
{
КодТипыТоваровУслуг
Признак
Название
}
ВидыТоваровУслуг

{
КодТипыТоваровУслуг
КодВидыТоваровУслуг
Название
}

К сожалению не могу согласиться с Ув. Коллегой AlexandrPlus Сейчас объясню почему. Помните начало сокраментальной фразы? "Сколько стоит похоронить? ©" трупы (прости Господи) совсем не платёжноспособны. Так же как и автомобили и музыкальные инструменты (если мы о ремонте пианинов) ну и так далее. Не вводите в заблуждение молодёжь, Коллега. ВСЕ системы подобны в сути своей. Это проходят ( у нас ) в колледже по предмету Management Information Systems У Вас "внутри бугра" они величаются (ну или величались когда то) Автоматизированными Системами Управления. В данном аспекте налицо Система Обработки Заказов. Предмет заказа Ритуальные Услуги. (Поменяйте предмет на Музыкальные Услуги и Система почти не изменится изменятся ее атрибуты). В перечень [расходных] товаров входят (здесь Гробы, Венки, памятники, Траурные Ленты, оградки, цветы, место на кладбище, - так называемые Tangible Items - те которые можно потрогать) Такими в Автомастерской будут карбюраторы, фильтры, колёса, ремни ... тд.
В Перечень УСЛУГ входят (здесь Вынос тела, омовение, отпевание, украшение (косметика) тела, оркестр, перевозка в последний путь, предание земле, Захоронение Или кремирование, поминки, - так называемые Intangible Items - те которые потрогать нельзя) . В Автомастерской будут замена масла, шиномонтаж, замена свечей, установка задержки зажигания, натяжка ремней, Развал Схождение, корпусные работы (опять же косметика) и так далее.

А Вот Заказ - объединяет всё - кстати по Вашей схеме , автор - Кириллка - У вас в заказе можно похоронить ТОЛЬКО одно лицо, а как быть например с футбольной командой? Помните случай с гибелью ВСЕЙ команды ТОПРЕДО... в авиакотострофе? С точки зрения Системы - субъектом услуги может быть одно или несколько лиц - может быть и НИ ОДНОГО лица как в случае с Памятником Неизвестному Матросу. Или героям лодки КУРСК. А вот платить кому то надо всё равно. Кстати и заказчик может быть один ИЛИ несколько, но как минимум ОДИН должен быть.

Кириллко
Что означает признак в этой таблице?

Почитайте повнимательнее этот пост, Коллега

OFF

У нашего автора материалов к размышлению как минимум на диссертацию пожалуй... Остапа понесло..©

Отличная подсказка Коллега! Благодарю. Ценный материал. Вот эта пожалуй будет наиболее близка к решению :

В предложенную модель я бы добавил подсказку от Ув. Cat2 о разделении продукта и сервиса по поставщикам Кстати обратите внимание что собственно Funeral Home линк отсутствует...

Но зато Барри предложил УНИВЕРСАЛЬНУЮ МОДЕЛЬ - Или Модель Всех Моделек :.

Коллеги, Ничего не напоминает?