МАГ2. Принципы построения
h2. Общие соображения

Основная задача нового МАГ - автоматическое формирование музыкального расписания.
Основное отличие от предыдущего МАГА - полноценная интеграция с системой редактирования расписания, использование стандартных _’Сеток’ или _’Шаблонов’, возможность формирования нескольких независимо ротирующихся папок расписаний в пределах одной МБД.
Соответственно, все параметры ротации должны храниться и настраиваться для каждой папки расписания.
В настоящий момент вводится следующее ограничение:

Одна категория МБД может находится в ротации только для одной папки расписания.

Это не исключает использование элементов, входящих одновременно в несколько категорий. Такие элементы в каждой из своих категорий ротируются независимо.
В новой программе нет ограничения на тип ротируемого материала Музыка, Джинглы, Передачи.

Идеология ротации
h3. Категории. Порядок расстановки.

Расписание формируется путем заполнения реальными фонограммами заранее определенных позиций в расписании - _’Ротируемых позиций_’ (Scheduled position).
В позиции подставляются реальные элементы из категорий, указанных в позиции.
В одной позиции не может быть указано более одной категории.
Позиции заполняются в порядке следования категорий в специальном списке, определяющем _’Порядок расстановки_‘( Plot numbers, Pass order).
Сначала заполняются позиции, принадлежащие категории, являющейся первой по порядку расстановки (_’Порядок расстановки=1_’), потом, все позиции категории с порядком=2 и т.д.
Позиции одной категории заполняются, начиная с более ранних по времени.
Элемент, выбираемый в позицию, тестируется относительно _’Правил’ (_’Rules’).

Правила.¶

Правило это, по сути, булева функция, предикат, возвращающая результат проверки _’Да-Нет_‘. У правила есть дополнительные настраиваемые параметры, влияющие на его проверку.
Множество проверяемых правил, вместе с параметрами их проверки, указывается для категории.
Т.е. все элементы, отбираемые в ротируемую позицию, проверяются одинаковым набором правил с одинаковыми параметрами их проверки, указанными для соответствующей категории.
Правила бывают _’Нарушаемые ’и _’Ненарушаемые’.
Правила указываются в виде списка, сначала ненарушаемые, потом нарушаемые, и проверяются в том же порядке, в каком они указаны.
Порядок указания важен только для нарушаемых правил, и вот почему:

• если элемент нарушает ненарушаемое правило, то он сразу отбрасывается.
• если элемент нарушает нарушаемое правило, то программа запоминает порядковый номер нарушенного правила, и переходит к проверке других кандидатов.
  по завершении проверки программа выбирает из всех проверенных тот элемент, который нарушил правило с большим номером.
  Т.е. чем ниже (ближе к концу) списка правило, тем оно менее важно.
  Если есть несколько элементов, нарушивших наименьшее правило, то из них выбирается первый по _’Порядку программирования_’.

_’Порядок программирования_’.¶

Как заполняется конкретная позиция?
Элементы категории при ротации перебираются по-очереди. Элемент, выбранный в ротируемую позицию, переносится в конец очереди.
Порядок следования элементов категории в данной очереди называется _’Порядком программирования_’ (Schedule order).
Выбор элемента в ротируемую позицию происходит в следующей последовательности:

1. Из указанной категории выбираем элемент с наименьшим порядком программирования
2. Данный элемент проверяется на соответствие Правилам.
   1. Если элемент не нарушает никаких правил, то он выбирается в данную позицию. При этом он получает новый порядок программирования, больший, чем максимальный порядок программирования элементов данной категории. Т.е. попадает в конец порядка программирования. _’Элемент найден_’.
   2. Если элемент нарушает ненарушаемое правило - он отбрасывается, сохраняя свой порядок программирования
      (опционально, элемент может быть сброшен в хвост порядка программирования специальной опцией, для сохранения очередности ротации)
3. Если элемент еще не найден, то выбирается следующий по порядку программирования элемент, пока не достигнута _’Глубина поиска_’ (Search depth).
   После чего переходим к шагу 2.
4. Глубина поиска достигнута, возможные варианты:
   1. Нет ни одного подходящего эл-та, все проверенные нарушают нарушаемые правила - _’позиция остается не запрограммированной_’.
   2. Есть элементы, нарушающие только нарушаемые правила - выбираем из них лучший, (см. выше). _’Элемент найден_’.

Глубина поиска¶

Это максимальное количество элементов, которое программа имеет право проверить для выбора эл-та в данную позицию.
Глубина поиска указывается для категории.
Глубина поиска может быть указана в процентах от количества эл-тов категории, тогда численное количество вычисляется перед проверкой первого эл-та категории. Глубина не может быть меньше 1.
Чем больше глубина, тем больше шансов найти элемент и тем менее предопределен порядок, в котором попадут в расписание эл-ты данной категории.
Глубина = 100% - анархия.

Методика формирования и редактирования расписания¶

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

Кроме этого, нужно уметь откатить сгенерированное расписание, вернув в исходное состояние порядок программирования для задействованных категорий.
При выполнении последовательности:

1. генерировать
2. откатить
3. генерировать

расписание, полученное на шаге 3 должно быть эквивалентно расписанию шага 1.

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

Предлагается реализовать следующее множество операций

Подбор элементов во все или в некоторые, заранее определенные позиции расписания, выполняется по команде _’Генерировать_’ (Schedule).
Для очистки части расписания используется команда обратная команда, _’Отменить генерацию_’ (Unschedule), применимая как к одному, так и ко множеству элементов расписания. При этом, вместо сгенерированных элементов в расписании восстанавливаются исходные Ротируемые позиции. А элементы, находящиеся в этих позициях, помещаются в начало порядка программирования (Kick?, а иногда удобно и в конец. Подумать, посмотреть ???).

Существует команда _’Удалить позицию’, которая выполняет сначала _’Отменить генерацию’ для данной позиции, если в ней есть элемент, а потом удаляет и саму ротируемую позицию.

Существует возможность подобрать вместо выбранного программой альтернативный элемент, для этого существует команда _’Альтернатива’. Для предыдущего элемента позиции выполняется _’Отменить генерацию’ (Kick ???).

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

_’Сформированное расписание параллельно редактируется с других рабочих мест, не имеющих функциональности МАГа_’, и вносящих изменения непосредственно в расписание, не затрагивая другие, специфичные для МАГа структуры данных (БД). Эта ситуация является штатной, ее нельзя избежать и она не должна приводить к выходу системы из строя.

Требования¶

1. На одной БД могут независимо ротироваться несколько Папок расписаний.
2. Одна категория МБД ротируется только в одной Папке расписания.
3. Одна фонограмма может входить в несколько категорий и независимо ротироваться в нескольких папках расписаний
4. При генерировании расписания заполняются заранее указанные в расписании ротируемые позиции. 1 позиция = 1 элемент
5. Позиции заполняются непосредственно в эфирном расписании - все изменения мгновенно становятся доступны всем. Этап Сохранить как эфирное отсутствует.
6. Расписание генерируется только полными сутками. Невозможно сгенерировать, например, 1 час
7. Расписание генерируется последовательно, возможны пропуски, но возврат во времени - невозможен
8. Генерирование расписания можно отменить только последовательно, начиная с самого позднего, при этом восстанавливается порядок программирования для всех элементов ротационных категорий, который был на момент начала генерирования отменяемых суток
9. Лог генерирования пишется только для автоматической генерации, и не пополняется при ручном изменении расписания.
10. Все правила проверяются по данным в БД.
    Перед проверкой правил программа должна убедиться, что в БД храниться актуальная информация, отражающая последние изменения, внесенные при редактировании расписания (изменения могут быть внесены с любого места).

Реализация
h3. Структура БД

Используются следующие таблицы БД

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

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

Основная проблема - расхождение информации, хранимой в таблице с реальной информацией решается следующим образом: приложение, желающее использовать таблицу, должно убедиться, что БД хранит актуальное содержимое.

Предлагаемый вариант быстрого контроля:
В БД создается спец. таблица, которая хранит записи о хеше содержимого расписания на соответствующую дату.
Этот хеш быстро вычисляется, например, по названиям и датам изменений блоков. При несоответствии хранимого в БД хеша и расчетного - содержимое БД обновляется и прописывается новый хеш.

Соответственно, перед использование таблицы PH_PLAY_PLAN приложение обязано обратиться к объекту-синхронизатору и убедиться, что копия соответствует реальности.

Таблица хешей - PH_PLAY_HASH

Таблица PH_PLAY_PLAN

.