Преимущества систем «точно-в-срок»

«Точносрочные» системы имеют ряд важных преимуществ, которые привлекают внимание компаний с традиционным подходом к производству Основными преимуществами являются:

1. Пониженный уровень материальных запасов в процессе производства (незавершенного производства), закупок и готовых изделий.

2. Меньшие требования к размерам производственных площадей.

3. Повышение качества изделий, уменьшение брака и переделок.

4. Сокращение сроков производства.

5. Большая гибкость при изменении ассортимента изделий.

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

7. Повышенный уровень производительности и использования оборудования.

8. Участие рабочих в решении проблем.

9. Необходимость хороших отношений с поставщиками.

10. Меньше необходимости в непроизводственных работах, например, складировании и перемещении материалов.

27. Информационные системы MRP (ManufacturingResourcePlaning) – планирование материальных затрат.

MRP – это производственная система, в основном использующаяся на производствах дискретного типа, поэтому она редко используются для планирования материальных потребностей в сервисных, транспортных, торговых и других организациях непроизводственного профиля, хотя потенциально идеи MRPсистем могут быть с некоторыми допущениями применены и для непроизводственных предприятий, деятельность которых требует планирования материалов в относительно длительном интервале времени.

MRP системы базируются на планирование материалов для оптимальной организации производства и включают непосредственно функциональность MRP, функциональность по описанию и планированию загрузки производственных мощностей CRP (CapacityResources Planning) и имеют своей целью создание оптимальных условий для реализации производственного плана выпуска продукции.

МRР-системы вряд ли имеет смысл широко использовать тогда, когда спрос равномерен, партии материалов велики и изготавливаемые номенклатурные позиции многочисленны. С проблемами, возникающими в этом случае, неплохо справляются традиционные системы, например системы управления запасами по точке заказа. МRР-системы проявляют все свои свойства тогда, когда имеет место интенсивный поток изменений и высокая вариабельность размеров заказов и партий.

Таким образом, можно заключить, что МRР не применяется и не будет применяться абсолютно для всех производственных систем. Иногда она не нужна или же экономически неэффективна. Однако количество случаев внедрения МRP быстро растет. Следует только помнить, что в условиях слабого компьютерного обеспечения, неактуальной нормативной информации, неэффективного стиля менеджмента МRР чудес от системы, как и от любой другой методологии, ждать не приходится. Она просто будет генерировать больше недостоверной и бесполезной информации, чем было до ее применения. МRР наилучшим образом показывает себя при хорошо управляемой в целом производственной системе, позволяя расширить доступные горизонты управления.

Среди критериев оценки эффективности использования MRP были выдвинуты следующие:

1) использование временных единиц планирования не больших, чем неделя;

2) запуск процедуры планирования не реже раза в неделю;

3) отсутствие так называемого «проблемного списка»;

4) соблюдение условий поставки на уровне 95% или выше со стороны поставщиков, цехов и главного календарного плана в целом;

5) улучшение результатов работы по крайней мере по двум из следующих направлений:

• запасы;

• производительность;

• обслуживание клиентов.

Многочисленные исследования, проведенные в течение ряда лет, выявили несколько основных проблем внедрения МRPсистем:

1) только очень небольшой процент пользователей МRP полагают, что они успешно используют свои МRР-системы. Много систем установлено, но не внедрено, т. е. формальная система не используется на практике;

2) главное календарное планирование производства пользователями МRР не компьютеризировано, несмотря на удобство этого метода;

3) планирование потребностей в мощностях сравнительно редко применяется пользователями МRР;

4) компьютеризированное оперативное управление производством вводится относительно редко.

28. Информационные системы SCE (SupplyChainExecuting) — реализация управления цепочкой поставок.

SCE (SupplyChainExecution) — система исполнения цепочек поставок. Также такая система называется в зарубежных изданиях DRP (DistributionResources Planning). Является подсистемой, частью SCM-системы.

Функции SCE-систем

Планирование маршрутов поставок, необходимых операций и ресурсов.

Управление и надзор за всеми операциями и партиями товара. Настройка оповещений.

Поддержка выполнения складских операций (приемка и размещение на хранение, подготовка заказов и их отправка, отслеживание партий и сроков хранения).

Учет и оценка всех действий и перемещений, выработки ресурсов, потоков, себестоимости логистических процессов.

Аналитика и реорганизация процесса отбора и зоны отбора товара, использования и загрузки ресурсов.

Состав SCE-системы

В состав такой системы входит решение для прогнозирования продаж компании на текущий момент времени, решение для управления запасами и логистическое решение для менеджмента пополнения. SCE-системы представлены тремя видами программных продуктов.

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

Системы для управления перевозками (TransportationManagementSystems – TMS) позволяют сформировать оптимальный план транспортировки товаров и материалов (с учетом необходимых сроков поставок, возможных видов транспорта, графиков работы и т. д.), подготовить оптимальную схему загрузки транспортных средств, отслеживать грузы, находящиеся в пути.

Системы для управления заказами (OrderManagementSystems – OMS) прежде всего помогают покупателю сформировать заказ с учетом его индивидуальных требований. Помимо этого, OMS-системы позволяют оценить возможность выполнения заказа и могут предложить альтернативные варианты (используя данные о наличии продукции и запланированных поступлениях). В случае производственной необходимости OMS-система передает информацию о заказе в APS-систему для оценки возможности его выполнения. После того как заказ размещен, OMS-система позволяет его отслеживать на всех стадиях с помощью информации, полученной из WMS-, TMS- и MES-систем.

Примеры SCE-систем

WarehouseExpert

CorrChain

29. Информационные системы TMP (TradingPartnerManagement) – управление деловыми партнерами.

Trading Partner Management (TPM) - это централизованное решение, отвечающее потребностям в пространстве B2B EDI. Основными преимуществами SAP B2B TPM являются такие функции, как поддержка централизованной информации партнеров, создание соглашений между партнерами, определение переноса опроса и настройка функциональных профилей для пользовательских карт значений.

Пользовательский интерфейс разработан на основе требований, полученных от разных пользователей B2B, что отражает ожидания наших торговых партнеров. Он решает сложность взаимодействия B2B между торговыми партнерами.

Управление торговыми партнерами (TPM) - это приложение, которое помогает вам управлять деловыми отношениями EDI с несколькими торговыми партнерами. Он предназначен для решения сложной ситуации, возникающей при обмене данными между EDI между торговыми партнерами.

Для доступа к приложению B2B TPM выполните следующие действия:

1. Вам необходимо назначить роли пользователя для управления инструментом TPM. Если эти роли не будут добавлены к вашему пользователю, у вас не будет доступа к управлению торговыми партнерами. Для получения дополнительной информации о требуемых ролях TPM обратитесь к назначению ролей пользователей для управления приложением B2B в Руководстве по безопасности B2B .

2. Введите URL-адрес в виде http: <localhost: port> / b2bic в веб-браузере и войдите в приложение для интеграции в B2B-приложение.

3. Чтобы получить доступ к инструменту «Управление торговыми партнерами», выберите « Управление торговыми партнерами» .

TPM разделяется на следующие функциональные области, к которым можно получить доступ избиблиотеки управления торговыми партнерами :

· Управление торговым партнером Часть 2 - Шаблон

· Управление торговыми партнерами Часть 3 - Функциональный профиль

· Управление торговым партнером Часть 4 - Профиль торгового партнера

· Управление торговыми партнерами Часть 5 - Соглашение о торговых партнерах

· Управление торговыми партнерами Часть 6 - Доступ к Runtime Access TPM

· Управление торговыми партнерами Часть 7 - Настройки администрирования TPM

· Управление торговыми партнерами Часть 8 - Пользовательские функции (UDF)

30. Информационные системы VDW (Virtual Data Warehouse) – виртуальные хранилища данных.

Архитектура обеспечивает доступ к "живым" данным в режиме реального времени через программное обеспечение промежуточного слоя. В основе такого решения лежит репозиторий метаданных, который описывает источники данных, процедуры их предварительной обработки и форматы представления информации конечному пользователю. Недостатки такого решения — интенсивный сетевой трафик, снижение производительности несущей системы, угроза нарушения целостности данных в случае неудачных действий пользователей ХД.

Виртуальным хранилищем данных называется система, которая работает с разрозненными источниками данных и эмулирует работу обычного хранилища данных, извлекая, преобразуя и интегрируя данные непосредственно в процессе выполнения запроса.

Преимущества такого подхода очевидны.

· Появляется возможность анализа данных в OLTP-системе сразу после их поступления без ожидания загрузки в хранилище.

· Минимизируется объем требуемой дисковой и оперативной памяти, поскольку отсутствует необходимость хранения исторических данных и многочисленных агрегированных данных для различных уровней обобщения информации.

· Наличие в ВХД развитого семантического слоя позволяет аналитику полностью абстрагироваться от проблем, связанных с процессом извлечения данных из разнообразных источников, и сосредоточиться на решении задач анализа данных.

При работе с ВХД пользователь, можно сказать, имеет дело с «иллюзией» хранилища данных. Виртуальность предполагает, что ВХД существует только до тех пор, пока работает соответствующее приложение. Как только оно завершает работу, виртуальное хранилище прекращает существование.

Избыточность информации можно свести к нулю, используя виртуальное ХД. В такой системе данные из OLTP-системы не копируются в единое хранилище. Они извлекаются, преобразуются и интегрируются непосредственно при выполнении аналитических запросов в режиме реального времени. Фактически такие запросы напрямую передаются к OLTP-системе.

Достоинства виртуального ХД:

· минимизация объема хранимых данных;

· работа с текущими, актуальными данными.

Недостатки виртуального ХД:

· более высокое, по сравнению с физическим ХД время обработки запросов;

· необходимость постоянной доступности всех OLTP-источников;

· снижение быстродействия OLTP-систем;

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

31.   Информационные технологии для снижения трудоемкости процессов использования информационных ресурсов, повышение их надежности и оперативности.

Для снижения трудоемко­сти процессов использования информационных ресурсов, повыше­ния их надежности и оперативности используются современные информационные технологии— инфраструктура, обеспечи­вающая реализацию информационных процессов — процессов сбора, обработки, накопления, хранения, поиска и распространения ин­формации.

Технология — это комплекс научных и инженерных знаний, реализованных в приёмах труда, наборах материальных, технических, энергетических, трудовых факторов производства, способах их соединения для создания продукта или услуги, отвечающих определённым требованиям.

Информационные технологии (ИТ) — это комплекс методов пе­реработки разрозненных исходных данных в надежную и оператив­ную информацию для принятия решений с помощью аппаратных и программных средств с целью достижения оптимальных параметров объекта управления.

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

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

https://studfiles.net/preview/2238192/

32. Киоски данных.

Архитектура представляет собой облегченный вариант ХД тематической направленности. Бывают киоски данных, связанные с интегрированным ХД или несвязанные (автономные).

Киоск (витрина) данных – это небольшое ХД, обслуживающее одно из направлений бизнеса компании или одно ее структурное подразделение. Стоимость разработки киоска в десятки и сотни раз ниже стоимости корпоративного хранилища данных, а результат его внедрения окупается очень быстро.

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

Преимущества: простота и невысокая стоимость; экономия технических ресурсов; более высокий уровень безопасности данных; высокая производительность.

Недостатки: дублирование данных; необходимость синхронизации данных; трудоспособности расширения и объединения витрин данных; ограничение использования.

Витрины данных являются объектами хранения аналитической информации, нацеленными на поддержку конкретных бизнес-функций, конкретных подразделений компании. На уровне базы данных витрины обычно реализуются по схеме «звезда» или «снежинка» и содержат данные из области детальных данных (System of records). Также могут быть реализованы в виде многомерного OLAP-куба. Витрины данных являются основой, обеспечивающей возможность проведения многомерного анализа (OLAP) данных.

Киоск данных - это набор тематически связанных БД, содержащие информацию, относящуюся к отдельным аспектам деятельности организации. По сути дела, ВД - это облегченный вариант ХД, существенно меньше по объему, чем корпоративный ХД, и для его реализации не требуется особо мощная вычислительная техника. Концепция ВД была предложена Forrester Research в 1991 году. При этом главная идея заключалась в том, что ВД максимально приближены к конечному пользователю и содержат только тематические подмножества заранее агрегированных данных, по размерам гораздо меньшие, чем общекорпоративное ХД, и, следовательно, требующие менее производительной техники для поддержания. Концепция ВД ориентирована исключительно на хранение, а не на обработку корпоративных данных. Она не предопределяет архитектуру целевых аналитических систем, а только создает поле деятельности для их функционирования, концентрируясь на требованиях к данным. Таким образом, она оставляет свободу выбора во всем, что касается способов представления данных в целевом ХД (реляционный, многомерный) и режимов анализа данных хранилища. В большинстве случае ВД (витрина данных) - это аналитическая структура, которая обычно поддерживает область работы одного приложения, бизнес-процесса или отдела. Сотрудники отдела обобщают требования к информации и приспосабливают каждую витрину к своим нуждам. Затем они обеспечивают персонал, работающий с информацией, средствами интерактивной отчетности (например, инструментами OLAP, средствами формирования незапланированных запросов или параметризованных отчетов). Эти средства позволяют сотрудникам углубляться в данные и исследовать их пространственную структуру "вдоль и поперек", чтобы выявить тренды и получить более детальную картину событий, являющихся движущими силами тех процессов или задач, которыми эти сотрудники управляют.

33. Компоненты преобразования данных (ETL-tools, Staging Area, Near-line Storage).

Компоненты преобразования данных (ETL-tools, Staging Area, Near-line Storage) cлужат для перегрузки данных из одних программных компонентов в другие (с промежуточной очисткой и согласованием данных, получаемых из различных источников)/

ETL — extraction, transformation, loading, то есть извлечение, преобразование и загрузка, скрываются три основных процесса, используемые при переносе данных из одного приложения или системы в другие.

Извлечение данных На этой стадии отбираются и описываются данные внешних источников (начинают формироваться метаданные ХД), которые должны храниться в ХД (релевантные данные).

Преобразование данных На этой стадии релевантные данные преобразуются в формат представления данных в ХД, правила преобразования сохраняются в метаданных ХД, формируются ключевые поля таблиц физической структуры ХД, выполняется очистка данных.

Загрузка данных На этой стадии данные загружаются в ХД, выполняется построение агрегатов.

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

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

Цель любого ETL-приложения состоит в том, чтобы своевременно доставить данные из внешних систем в систему, с которой работают пользователи. Как правило, ETL-приложения используются при переносе данных внешних источников в ХД систем бизнес-аналитики. Поэтому организация процесса ETL является составной частью проекта разработки практически любого ХД.

Проектирование и разработка ETL-процесса является одной из самых важных задач проектировщика ХД. Для ХД процесс ETL имеет следующие свойства. Во-первых, объем данных, который выбирается из систем источников данных и помещается в ХД, как правило, бывает достаточно большим, до десятков Гб. Во-вторых, процесс ETL является необходимой составной частью эксплуатации ХД. В-третьих, на разных стадиях процесса ETL формируются метаданные ХД и обеспечивается качество данных. В-четвертых, во время процесса ETL может произойти потеря данных, поэтому необходимо обеспечивать контроль за поступлением данных в ХД. В-пятых, процесс ETL обладает свойством восстанавливаемости после сбоев без потери данных.

На рис. показано место процесса ETL в архитектуре системы бизнес-аналитики на основе ХД.

На процесс ETL возложена вся работа по подготовке данных для доставки их в ХД, формирование и обновление метаданных ХД, а также управление данными, извлеченными в результате Data mining.

Подсистема ETL в корпоративном хранилище данных работает в тесной взаимосвязи с подсистемой хранения данных (см. состав подсистем хранилища данных). ETL-процессы наполняют и используют область временного хранения данных (Staging Area). Область временного хранения, например, может состоять из следующих областей (схем) базы данных:

· область извлечения данных (Source Area);

· область преобразования данных (Transformation Area);

· область оперативного хранения данных (Operational Data Store).

Область временного хранения данных (Staging Area) – предназначена для временного хранения данных, извлеченных из систем-источников. ОВХ данных является промежуточным слоем между источниками данных и областью постоянного хранения. В данной области сохраняются извлеченные из операционных систем-источников данные, производится их очистка, трансформация, обогащение, подготовка к загрузке в область постоянного хранения. Зачастую очередной цикл обработки и загрузки данных в хранилище не может быть начат пока не будут извлечены все необходимые данные из различных систем-источников, а в силу ряда причин данные в источниках могут быть доступны в разные моменты по времени. Область временного хранения служит для сбора всех необходимых данных перед началом трансформации.

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

Ниже представлены основные принципы формирования области временного хранения.

1. В области временного хранения данных должно быть относительно небольшое количество сущностей - до 20, в которые сохраняются все необходимые данные, извлеченные из систем-источников.

2. Основой для проектирования состава сущностей области временного хранения должны являться предметные области (Subject Area) модели данных.

3. При извлечении данных из систем-источников сами данные и их типы не должны принципиально изменяться

Наполнение данными области постоянного хранения детальных данных, агрегатов и витрин данных также реализуется при помощи ETL-процессов загрузки данных и агрегации данных. Иногда данные процессы реализуют средствами базы данных, что не совсем правильно.

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

1. Процессы извлечения данных извлекают данные из систем источников.

2. Процессы извлечения данных сохраняют извлеченные данные в интерфейсные таблицы области Source Area.

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

4. После проведения преобразования данных данные загружаются в область оперативного хранения Operational Data Store.

5. Процессы загрузки данных производят чтение данных из области оперативного хранения.

6. Процессы загрузки данных проверяют ссылочную целостность данных и проводят их загрузку в область детальных данных (System of Records).

7. Процессы агрегации данных производят чтение детальных данных.

8. Процессы агрегации данных производят агрегацию и запись данных в Summary Area и Data Marts.

Near-line Storage используется для описания промежуточного типа хранилища данных, представляющего собой компромисс между онлайн-хранилищем (поддерживающий частой, очень быстрый доступ к данным) и автономное хранение / архивирование (используется для резервного копирования или длительного хранения, с редким доступом к данным). Хранилище с почти оперативным доступом (near-line), предназначенное для хранения данных, перенесенных на вторичный промежуточный носитель (сменный или постоянный). Это может быть вторичное устройство на магнитных дисках, накопитель на оптических дисках или даже устройство памяти, специфичное для данного приложения.

34. Корпоративное хранилище данных (Enterprise Data Warehouse).

Здесь накапливается детальная информация, необходимая для выполнения анализа. Данные перегружаются в корпоративное хранилище из оперативных элементов - унаследованных систем, автоматизированных банковских систем или оперативных складов данных. Как правило, обновление информации в EDW происходит с большой задержкой. Для разрешения этой проблемы используются ODS-элементы.

Корпоративное хранилище данных содержит информацию обо всех сторонах деятельности организации, интегрированную из множества оперативных источников данных и предназначенную для решения на ее базе задач консолидированного анализа данных. Корпоративное хранилище содержит наряду с детализированными данными, относящимися к каждому моменту времени, также и агрегированную информацию, а общий объем его данных варьируется от 50 Гбайт до более чем 1 Тбайт. Корпоративные хранилища данных могут потребовать больших затрат денег и времени на разработку и администрирование. Построение полноценного корпоративного хранилища данных обычно выполняется в трехуровневой архитектуре.

Корпоративное хранилище данных – это специальным образом организованный массив данных предприятия (организации), обрабатываемый и хранящийся в едином аппаратно-программном комплексе, который обеспечивает быстрый доступ к оперативной и исторической информации, многомерный анализ данных (KPI по различным измерениям), получение прогнозов и статистики в разрезах согласованной нормативно-справочной информации (НСИ).

Компоненты корпоративного хранилища данных предприятия

35. Место хранилища данных в виртуальном предприятии.

Виртуальные предприятия

Одной из перспективных областей применения систем складирования данных является разработка ХД как составной части виртуального предприятия. В этом случае ХД рассматривается как часть интегрированной информационной структуры организации, которая имеет типовую архитектуру.

https://www.intuit.ru/studies/courses/599/455/lecture/10158?page=3

36. Модель типового проекта создания хранилища данных.

Проект разработки ХД начинается после того, как выбраны инструменты разработки и сформирована команда проекта. В проектный цикл разработки ХД обычно включаются следующие типовые процессы (этапы):

· формулирование требований;

· создание вычислительной среды;

· моделирование данных;

· определение процедур извлечения преобразования и загрузки данных;

· проектирование аналитических отчетов;

· разработка приложений ХД;

· настройка производительности;

· проверка качества;

· передача системы складирования данных в эксплуатацию.

Укрупненная бизнес-модель (IDEF0) процесса разработки хранилища данных

https://www.intuit.ru/studies/courses/599/455/lecture/10159?page=3

37. Мультимедийные хранилища данных.

https://www.intuit.ru/studies/courses/599/455/lecture/10158?page=3

Очень перспективным в последнее время становится разработка ХД для цифровых (электронных) библиотек и мультимедиа. Современные СУБД имеют ряд встроенных возможностей для хранения и выборки мультимедийных данных (например, СУБД Pilot). Однако большинство решений по созданию мультимедийных баз данных реализуется на реляционных СУБД, обладающих возможностью работы с BLOB-данными и имеющими поддержку очень больших БД. Типичными представителями таких СУБД являются СУБД Oracle (имеет специальные средства выборки визуальной информации — VIR и интернет-систему обработки файлов iFS), DB2 и Informix (теперь IBM).

Примерами мультимедийных ХД являются разрабатываемые во всем мире электронные хранилища музейных данных (образы картин и других экспонатов).

Следует отметить следующие свойства медиаданных:

· неструктурированная форма с точки зрения теории реляционных баз данных;

· размер элемента медиаданных очень большой;

· данные не имеют фиксированного максимального размера;

· внутренний формат для представления таких данных не может быть выражен простым типом данных реляционных СУБД;

· поиск данных затруднен или просто невозможен стандартными средствами СУБД.

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

В этом отношении хранилище мультимедийных данных имеет типовую архитектуру, в которой медиаданные быстро извлекаются и визуализируются. Задачи сравнительного анализа медиаданных зависят от предметной ориентации ХД и требуют обычно специально разработанных процедур.

Преимущество

· Медиаданные классифицируются по иерархическим категориям и вводятся в ХД, что увеличивает скорость их выборки.