Практические примеры использования ОМУО. Практическое применение ОМУО может быть широко и многообразно. Например, такая учетная задача, как «товары поставщиков». Поставщики поставляют разные товары, новые работники могут этого не знать и допускать большие ошибки. Да и старые работники могут не успевать за темпом изменений, ведь поставщики могут периодически расширять ассортимент, менять и увеличивать профиль деятельности и т.д. Если своевременно обновлять отношение «поставщик» («лицо-актив»), то любой работник, вместо того чтобы регулярно и мучительно всех расспрашивать, сможет освежить свои знания, просто используя базу данных. Также отпадает нужда в регулярных рассылках по почте с информированием об изменениях у поставщиков. Или, например, такая задача, как «потребности покупателей», во многом похожая на предыдущий пример. Аналогично, потребности покупателей могут меняться во времени, могут удовлетворяться за счет других поставщиков (наших конкурентов). Не зная ничего этого, работники и ЛПР (лица, принимающие решения) будут удовлетворять свои информационные потребности методами устных расспросов, запросами по почте, общением в магенте и прочими малоэффективными средствами. Или откройте любой интернет-каталог товаров. Многочисленные характеристики товаров, требующиеся для каталогов (обычных и электронных, интернет-магазинов и т.д.) – это все те же самые отношения. Просто они заполняются в других базах – торговых базах, или базах данных самих сайтов. В бухгалтерской базе мы этих отношений не видим. На основании, например, отношения «аксессуар», в сайтах осуществляется подбор дополнительных предложений для того товара, который ищет покупатель. Точно также в офисе, в бухгалтерской базе, будет возможно осуществлять подбор аксессуаров для покупателей, пришедших в офис – если вести учет отношения «аксессуар». Пока же это возможно только в торговой базе, да и то совсем по другой схеме – «категорий», не учитывающих отношения между одинаковыми («актив»-«актив», «лицо-лицо») или неодинаковыми («лицо»-«актив», «актив-лицо») объектами. Если для добавления каждого нового вида отношения – предположим, или «аксессуар», или «заменитель», или «дополнение» - нам нужно будет всякий раз перепрограммировать алгоритмы базы данных и/или изменять структуру полей базы данных с последующей трудоемкой реструктуризацией, то далеко с такой логикой создания новых отношений мы не уедем. Не в этом ли причина постоянных затруднений многих веб-сервисов? И последний пример – «состав актива», то есть из чего состоит товар (не путать с задачей спецификации готовой продукции). Ассортимент товаров может быть очень широким, содержимое коробки даже аналогичных похожих товаров может меняться очень широко. Например, раньше в комплекте любого принтера всегда обязательно присутствовал USB-кабель. Теперь же почти нигде он не идет в комплекте - но так бывает не всегда. Как это узнать, если пришел клиент с жалобой, и нужно срочно разобраться, был ли ему отпущен в составе этой модели USB-кабель, или же нет и т.д. Если же ведется учет отношения «входит в состав», то мы всегда сможем увидеть содержимое коробки товара, даже проданного давно (но, предположим, все еще находящегося на гарантии).
|