решения для Python для управления графом зависимостей научных данных значениями спецификации

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

Проблема: Я имею дорогой (часы ко дням для вычисления) и атрибуты данных большого (ГБ), которые обычно создаются как преобразования одного или нескольких других атрибутов данных. Я должен отслеживать точно, как эти данные создаются так, я могу снова использовать их, как введено для другого преобразования, если они соответствуют проблеме (созданный с правильными значениями спецификации), или создайте новые данные по мере необходимости. Хотя это не должно иметь значения, я обычно я запускаю с несколько неоднородной информации о молекулярной биологии 'с добавленной стоимостью', например, геномов с генами и белками, аннотируемыми другими процессами другими исследователями. Я должен объединить и сравнить эти данные для создания моих собственных выводов. Много промежуточных шагов часто требуются, и они могут быть дорогими. Кроме того, конечные результаты могут стать входом для дополнительных преобразований. Все эти преобразования могут быть сделаны несколькими способами: ограничение с различными исходными данными (например, использование различных организмов), при помощи различных значений параметров в тех же выводах, или при помощи различных моделей вывода, и т.д. Исследования часто изменяются и основываются на других незапланированными способами. Я должен знать, какие данные я имею (какие параметры или спецификации полностью определяют их), оба так, что я могу снова использовать их при необходимости, а также для общей научной целостности.

Мои усилия в целом: Я разрабатываю свои классы Python с проблемой описания в памяти. Все атрибуты данных, созданные объектом класса, описаны единственным набором значений параметров. Я называю эти параметры определения или спецификации 'def_specs' и этими def_specs с их значениями 'форма' данных atts. Все глобальное состояние параметра для процесса могло бы быть довольно большим (например, сто параметров), но данные atts обеспеченный любым классом требуют только небольшого количества их по крайней мере непосредственно. Цель состоит в том, чтобы проверить, являются ли ранее созданные данные atts соответствующими путем тестирования, если их форма является подмножеством глобального состояния параметра.

В классе легко найти необходимые def_specs, которые определяют форму путем исследования кода. Протирание возникает, когда модулю нужно внимание данных от другого модуля. Эти данные atts будут иметь свою собственную форму, возможно, переданную как args вызывающим объектом, но чаще фильтровали от глобального состояния параметра. Класс вызова должен быть увеличен с формой его зависимостей для поддержания полного описания его данных atts. В теории это могло быть сделано вручную путем исследования графа зависимостей, но этот график может стать глубоким, и существует много модулей, которые я постоянно изменяю и добавляю, и... Я слишком ленив и небрежен, чтобы сделать это вручную.

Так, программа динамично обнаруживает полную форму данных atts путем отслеживания вызовов к другим атрибутам классов и продвижения их формы назад до вызывающей стороны (сторон) через управляемый стек __get__ вызовы. Поскольку я переписываю, я нахожу, что должен строго управлять доступом атрибута к своим классам разработчика, чтобы препятствовать тому, чтобы произвольная информация влияла на данные atts. К счастью, Python делает это легким с дескрипторами.

Я храню форму данных atts в дб так, чтобы я мог запросить, существуют ли соответствующие данные (т.е. его форма подмножество текущего состояния параметра) уже. В моем переписывать я перемещаюсь от mysql через большой SQLAlchemy к объектному дб (ZODB или couchdb?), поскольку таблица для каждого класса должна быть изменена, когда дополнительный def_specs, обнаружены, который является болью, и потому что некоторые def_specs являются списками Python или dicts, которые являются болью для перевода в sql.

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

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