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

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


Для любого разработчика структура данных - это один из больных вопросов. Потом взирая на то, что наваял, частенько как тем скульпторам хочется взять молот и разрушить некоторые скульптуры как уродство. Поэтому надо не подпускать разработчиков к софту после того, как софт признан годным.

Какой-то свой опыт и виденное говорят за то, что структуру данных при проектировании ИС предприятия надо строить ПО НАИБОЛЕЕ ОСТРЫМ ПРОБЛЕМАМ, СТОЯЩИМ НА ПРЕДПРИЯТИИ.
Так если ИС покупается для контроля за денежными потоками - одна структура и здесь уместна структура системы ОБРАБОТКИ ЗАКАЗОВ, если наиболее остры проблемы управления людьми на предприятии - другая структура (возможно управлять через денежное регулирование - но это опять же на предприятиях, где наиболее остры проблемы контроля денег), если главная проблема контроля каких-то товаров, предметов (прием и передача чего-либо), а не руководство людьми, которые осуществляют движение товаров, и не котроль денег, сопровождающих движение товаров, то третья структура.

Поэтому для одних контор лучше одна корпор. ИС, для других - другая, где разные акценты на обработку разной информации. Например - тот же 1С - вроде что-то универсальное, но это лишь какой-то каркас - и для каждого предприятия - много-много допрограммирования.
Конечно в идеале - хорошо бы и структуру данных под предприятие, но это франчайзеры 1С не в праве делать, да и не могут.

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

P.S. Известны эти тенденции в США всё основывать на деньгах. И люди быт так же основывают.
И вот - опа - финансовый кризис, и именно из США.