Дизайн базы данных для комплексной музыкальной аналитики

Question

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

Паспорт

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

Затем я записываю двоичный отклик животного на мелодию (например, не нравится).

Я играю> 500 мелодий для животных каждый день, для> 300 дней. Я также объединяю данные от> 10 животных.

Мне также нужно хранить такие переменные, как пробный номер в каждый день (был ли он представлен 1-й мелодией? Последний? И т. Д.) И дату, чтобы я знал, какие данные указывают на исключение из-за внешних проблем (например, животные остановились отвечая после 100 испытаний или на весь день).

Анализ

Я пытаюсь раскрыть какие виды музыкальной структуры в этих сгенерированных случайным образом мелодии приведет к любит/не любит от животного. Я делаю это в основном исходя из гипотез, основанных на предыдущих исследованиях. Запросы, которые мне нужно выполнить в моем наборе данных, имеют форму: «Имеет ли большее количество заметок из той же октавы, что повышает удобство настройки?»

Я также выполняю анализ набора данных в течение года, когда данные накапливаются.

То, что я пытался

Я объединить данные из всех животных в один гигантский список, содержащий dicts. Каждый ДИКТ представляет одну пробу и связанное с ним:

• животных ID #
• идентификатор сеанса #
• суда ID #
• двоичного ответа (например,/не нравится)
• мелодия, которая определяется диктофон. Ключи - это просто воспроизводимые ноты, а значения обозначаются при воспроизведении ноты. Например. {'1A#':[30,100]} означает мелодию с одной нотой, A # с 1 октавы, от 30 мс до 100 мс.

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

Я искал реструктурировать свои данные в базу данных или формат Pandas DataFrame из-за скорости 1) сериализации данных и 2) запросов и 3) возможного более чистого кода вместо обращения к вложенным dicts. Первоначально я думал, что мои данные, естественно, хорошо поддаются какой-либо структуре таблиц из-за пробной структуры моего эксперимента. К сожалению, определение мелодий в таблице кажется сложным, так как мелодии на самом деле не имеют фиксированной структуры.

Какие могут быть альтернативы в структурировании моих данных?

Answer 1

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

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

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

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

Я надеюсь, что помогает

Answer 2

Я бы использовал реляционную базу данных, поддерживающую JSON, например postgresql. Таким образом, вы можете сохранить мелодию как объект JSON и не беспокоиться о структуре мелодии. Остальная часть вашей модели данных кажется реляционной. Я бы создал таблицу для животных, а затем стол для испытаний/сеансов. Так что ваша сессия таблица может выглядеть

SessionId (integer, primary key) | TrialId (integer) | AnimalId (integer, foreign key) | tune (json) | response (bool)