Как хранить матричную информацию в MySQL?
Я работаю над приложением, которое анализирует сходство музыки. Для этого я обрабатываю аудиоданные и сохраняю результаты в txt файлах. Для каждого аудиофайла я создаю 2 файла, 1 содержит и 16 значений (каждое значение может быть следующим: 2.7000023942731723), а другой файл содержит 16 строк, каждая строка содержит 16 значений, как показано ранее.
Я хотел бы сохранить содержимое этих двух файлов в таблице моей базы данных MySQL.
Моя таблица выглядит так:
чтобы добавить содержимое этих двух файлов, я думаю, мне нужно использовать тип данных BLOB:
Мой вопрос в том, как хранить эту информацию в базе данных? Я работаю с Java, где у меня есть двойной массив, содержащий 16 значений (для файла1) и матрицу, содержащую информацию file2. Должен ли я обрабатывать значения как строки и добавлять их в столбцы в моей базе данных?
4 ответа
Надеюсь, что я не получаю отрицательный ответ, забвенный этим сумасшедшим ответом, но я стараюсь думать нестандартно. Мой первый вопрос: как вы обрабатываете эти данные после потенциального запроса? Если бы я делал что-то подобное, я бы, скорее всего, использовал нечто вроде matlab или октавы, которые имеют определенную нотацию для представления матриц. Это в основном куча текста с запятой и точкой с запятой с квадратными скобками в правильных местах. Я бы сохранил только строку, которую мое математическое программное обеспечение или модуль может анализировать изначально. В конце концов, это не похоже на то, что вы хотите сделать какой-то запрос на основе точки данных.
Я думаю, вам нужно нормализовать схему, подобную этой, если вы намерены сохранить ее в реляционной базе данных.
Похоже, у вас есть таблица матриц, которая имеет отношения «один ко многим» со своими файлами.
Если вы настаиваете на одной денормализованной таблице, один из способов сделать это — сохранить имя файла, его автора, имя его матрицы и его позицию в строке и столбце в названной матрице, которая ее владеет.
Просьба пояснить одно: это матрица в смысле линейной алгебры? Математическая сущность?
Если да, и вы используете только матрицу целиком, то, возможно, вы можете сохранить ее в одном столбце как blob. Это по-прежнему заставляет вас сериализовать и десериализовать строку или blob каждый раз, когда она входит и выходит из базы данных.
Я думаю, что проблема, с которой сталкивается dedalo, заключается в том, что он работает с массивами (я предполагаю, что один из них зубчатый, один — многоразмерный), и он хочет сериализовать их для blob.
Но массивы не являются непосредственно сериализуемыми, поэтому он спрашивает, как это сделать.
Самый простой способ сделать это — перебрать массив и построить строку, как предложил Дейв и сохранить строку. Это позволит вам просматривать содержимое из значения в базе данных, а не десериализовать данные всякий раз, когда вам нужно их заблокировать, как указывает duffymo.
Если вы хотите знать, как сериализовать массив в BLOB. (это просто кажется излишним)
Что касается того, какой тип данных хранит его, как в MySQL, есть только четыре типа blob для выбора из:
The four BLOB types are TINYBLOB, BLOB, MEDIUMBLOB, and LONGBLOB
Выбор лучшего зависит от размера сериализованного объекта. Я бы предположил, что BLOB будет достаточно хорошим.
Взгляд на математические вычисления средствами баз данных на примере умножения и транспонирования матриц Текст научной статьи по специальности «Математика»
Аннотация научной статьи по математике, автор научной работы — Маркеев Вадим Юрьевич, Крючков Алексей Александрович
Рассмотрена вертикальная структура представления матриц внутри базы данных . Показана реализация операций транспонирования и умножения матриц средствами баз данных .
Похожие темы научных работ по математике , автор научной работы — Маркеев Вадим Юрьевич, Крючков Алексей Александрович
VIEW ON MATHEMATICAL COMPUTATIONS BY MEANS OF DATABASES ON EXAMPLE OF MULTIPLICATION AND TRANSPOSE OF MATRICES
The representation of matrices in columnar databases is considered. Realization of the transpose and matrix multiplication by means of databases is shown.
Текст научной работы на тему «Взгляд на математические вычисления средствами баз данных на примере умножения и транспонирования матриц»
ВЗГЛЯД НА МАТЕМАТИЧЕСКИЕ ВЫЧИСЛЕНИЯ СРЕДСТВАМИ БАЗ ДАННЫХ НА ПРИМЕРЕ УМНОЖЕНИЯ И ТРАНСПОНИРОВАНИЯ МАТРИЦ
© В.Ю. Маркеев, А.А. Крючков
Ключевые слова: математические вычисления; умножение матриц; транспонирование матриц; базы данных; хранимые процедуры.
Рассмотрена вертикальная структура представления матриц внутри базы данных. Показана реализация операций транспонирования и умножения матриц средствами баз данных.
В [1] было показано, что вопреки распространенному мнению о применимости баз данных не более чем для длительного хранения информации средствами баз данных можно вполне успешно производить математические вычисления. Данное утверждение было проиллюстрировано на примере алгоритма Дейкстры, применяемого для нахождения кратчайшего пути между вершинами взвешенного графа. Экспериментально было установлено, что реализация алгоритма Дейкстры средствами СУБД MySQL для графов большой размерности (десятки тысяч вершин и выше) по скорости выполнения превосходит классическую матричную реализацию данного алгоритма средствами языка C++.
Что представляется немаловажным для авторов данной статьи, возможности реляционной модели организации данных при проектировании схемы БД позволяют выразить особенности сущностей и отношений между ними на языке предметной области, что при последующем использовании языка SQL, посредством которого производятся запросы к базе данных, придает алгоритмической реализации наглядность и изящество. А именно, программный код SQL-запросов и хранимых процедур при применении «говорящих» названий таблиц, полей внутри таблиц и переменных становится настолько самодокументируемым, что текст запроса практически дословно отражает его описание на языке предметной области.
Рассмотрим реализацию операций транспонирования и умножения действительных матриц, в т. ч. разреженных, средствами базы данных MySQL. Схему данных для матричных вычислений средствами БД
представляется удобным организовать следующим образом (рис. 1).
Каждая запись таблицы matrix соответствует конкретной матрице, для которой в данной реализации достаточно знать непосредственно только ее размерность, которая выражена в полях height и width.
Определенный элемент Aj некоторой матрицы A соответствует записи таблицы matrix_element, первичный ключ которой состоит из трех характеристик: номера (id) матрицы matrix, к которой относится данный элемент, номера строки i и номера столбца j, отражающих положение элемента внутри данной матрицы. Значением элемента матрицы выступает поле value соответствующей записи таблицы matrix_element.
Данный подход в теории проектирования баз данных принято называть вертикальной организацией БД. Горизонтальная же организация данных в данном случае матриц выглядела бы как двумерный массив. Если в языках и средах, подобных C++, представление матрицы в виде двумерного массива есть общепринятая практика, то попытки применения подобного подхода в БД, мягко говоря, неудобны и нецелесообразны.
В нашем случае вертикальная структура представления данных о матрицах легко допускает возможность хранения разреженных матриц по определению: т. е. если некоторые элементы матрицы равны нулю, то можно их не хранить в таблице matrix_element, и обратно, если для некоторых элементов матрицы нет записей в таблице matrix_element, то их следует считать равными нулю.
Рис. 1. Схема представления разреженных матриц в БД
Стоит отметить таблицу sequence, состоящую из единственного поля id, записи которой представляют ряд натуральных чисел. Количество записей в таблице sequence должно быть не меньше, чем наибольшее из измерений (height и width), участвующих в вычислениях матриц. Назначением таблицы sequence является имитация целочисленных осей координат, которые потребуются при вычислениях. Отметим, что для увеличения производительности на поля таблиц, по которым будет осуществляться связывание (внешние ключи), были установлены индексы.
Для вывода вертикального представления матрицы будет использован следующий SQL-запрос:
select h.id i , w.id j
, ifnull(a.value, 0) value from matrix
join sequence h on h.id <= matrix.height join sequence w on w.id <= matrix.width left join matrix_element a on a.matrix = matrix.id and a.i = h.id and a.j = w.id where matrix.id = _a order by h.id, w.id;
Изначально подключаем интересующую нас матрицу равную параметру _a, затем с учетом ее размерности строится двумерное пространство независимыми осями h и w. На данном этапе при независимом соединении таблиц — «координатных осей» мы получили декартово произведение векторов h и w, что даст нам ровно matrix.height * matrix.width элементов в выборке независимо от того, сколько элементов матрицы присутствует в таблице matrix_element. Далее, для каждого элемента пространства присоединяем соответствующую запись таблицы matrix_element посредством LEFT JOIN, что в случае отсутствия искомой записи сохранит целостность результирующей выборки, причем в качестве значения элемента, как, впрочем, и всех полей строки matrix_element, будет выступать значение null. Для удобства ряд значений упорядочивается по строкам, а внутри них — по столбцам. В результирующую выборку включаются номера строк и столбцов матрицы, а также значения находящихся на их пересечении элементов. Для обработки отсутствующих (нулевых) элементов применяется встроенная функция IFNULL(), которая вместо отсутствующих null-значений подставит нуль.
Для обеспечения привычного табличного представления матрицы, SQL-запрос несколько изменится:
group_concat(ifnull(a.value, 0) order by w.id separator '\t') matrix
join sequence h on h.id <= matrix.height join sequence w on w.id <= matrix.width left join matrix_element a on a.matrix = matrix.id and a.i = h.id and a.j = w.id where matrix.id = _a group by h.id;
В данном случае выборка элементов разобьется на классы эквивалентности по признаку принадлежности
элементов к одноименным строкам, после чего для каждого класса эквивалентности будет отображено по одной записи, внутри которой элементы данного класса (принадлежащие данной строке) будут выведены в горизонтальный ряд, разделяясь символом табуляции. Таким образом, вертикальное представление матрицы будет сведено к классической форме.
Задача транспонирования заданной матрицы стандартным образом решается путем двух вложенных циклов, которые, пробегая одну из половин двумерного массива, полученных разбиением матрицы по главной диагонали, меняют местами симметричные элементы. Также возникает проблема переопределения размерности массива при неравных количествах строк и столбцов матрицы. Что касается средств баз данных, то задача транспонирования решается аналогично выводу, за тем лишь исключением, что индексы строк и столбцов в результирующей выборке меняются местами. Транспонирование основано на следующем SQL-запросе:
select w.id i , h.id j
, ifnull(a.value, 0) value from matrix
join sequence h on h.id <= matrix.height join sequence w on w.id <= matrix.width left join matrix_element a on a.matrix = matrix.id and a.i = h.id and a.j = w.id where matrix.id = _a order by w.id, h.id;
Особенно изящно средствами баз данных выполняется операция умножения матриц посредством единственного SQL-запроса, в то время как классический подход подразумевает три вложенных цикла. Напомним, что элементом результирующей матрицы с, будет сумма попарных произведений элементов i-й строки матрицы A и j-го столбца матрицы B, т. е.
скі = . Далее приведен полный текст храни-
мой процедуры, производящей умножение матриц _а и _b, номера которых переданы в качестве входных параметров:
CREATE PROCEDURE math.mult(in _a INT, in _b int)
SQL SECURITY INVOKER BEGIN
declare ah, aw, bh, bw, m INT; select
matrix.height , matrix.width into ah, aw from matrix where matrix.id = _a;
matrix.height , matrix.width into bh, bw from matrix where matrix.id = _b;
# Позаботиться, чтобы в последовательности хватило чисел
call sequence(GREATEST(ah, aw, bw));
insert into matrix set height = ah, width = bw; set m = LAST_INSERT_ID();
insert into matrix_element select null , m , h.id , w.id
, sum(ifnull(a.value, 0)*ifnull(b.value, 0)) value from sequence h join sequence w on w.id <= bw join sequence k on k.id <= aw left join matrix_element a on a.matrix = _a and a.i = h.id and a.j = k.id left join matrix_element b on b.matrix = _b and b.i = k.id and b.j = w.id where h.id <= ah group by h.id, w.id having value != 0; else
select 'incorrect length' error; end if;
Особенно примечателен запрос на выборку элементов для их добавления в новую матрицу — результат умножения. Здесь к двумерному пространству новой матрицы добавляется третье (промежуточное) измерение, элементами которого будут произведения соответствующих элементов, которые затем при группировке сожмутся обратно в двумерное пространство путем суммирования элементов-значений внутри классов
эквивалентности. Классами эквивалентности в данном случае выступают элементы новой (результирующей) матрицы. Блок «having value! = 0» исключит из результирующей выборки нулевые значения, которые нет необходимости сохранять в связи с вышеописанными договоренностями хранения разреженных матриц.
Математические вычисления средствами баз данных представляют значительный интерес авторов по ряду причин. Во-первых, это впечатляющие результаты устойчивости и производительности при решении задач огромных размерностей. Во-вторых, из эстетических соображений, т. к., по нашему мнению, это красиво и удобно. И наконец, данная область мало исследована, по крайней мере, ранее нам не доводилось встречать научных (и вообще каких-либо) работ на стыке математических вычислений и баз данных, что придает еще больший интерес дальнейшим исследованиям в данной области.
1. Маркеев В.Ю., Крючков А.А. Использование средств баз данных для математических вычислений на примере алгоритма Дейкстры // Вестник Тамбовского университета. Серия Естественные и технические науки. Тамбов, 2012. Т. 17. Вып. 4. С. 1234-1238.
2. Беллман Р. Введение в теорию матриц. М.: Наука. 1969.
3. Гантмахер Ф.Р. Теория матриц. М.: Физматлит, 2010. 560 с.
Поступила в редакцию 23 ноября 2012 г.
Markeev V.Yu., Kryuchkov A.A. VIEW ON MATHEMATICAL COMPUTATIONS BY MEANS OF DATABASES ON EXAMPLE OF MULTIPLICATION AND TRANSPOSE OF MATRICES
The representation of matrices in columnar databases is considered. Realization of the transpose and matrix multiplication by means of databases is shown.
Key words: mathematical computations; matrix multiplication; transposition of matrices; databases; stored routines.
Хранение матриц в БД и их выборка, реально?
В БД не очень хорошо разбираюсь, есть в какой ни будь БД поле с типом данных Матрица?
Допустим у меня есть 2 очень похожих матрицы с минимальной разницей
5 5 5
5 5 5
5 5 5
и
5 5 6
5 5 5
5 5 5
Есть какой-то алгоритм что бы быстро найти похожие матрицы, или найти максимально похожую матрицу на эту и т.п.?
- Вопрос задан более трёх лет назад
- 845 просмотров
- Вконтакте
- Вконтакте
DrunkMaster: Да в любой, наверно.
Обработка, разумеется, будет зависеть от выбранной СУБД и способа хранения.
Если РСУБД — заведите в таблице столько столбцов, сколько надо для размещения матрицы. Для обработки или процедуру пишите или переложите на ЯП, какой используете. Варианты разные есть: например, обрабатывать сами данные в R.
Хранение матриц в реляционной базе данных
Я работаю над проектом для клиента и прохожу первоначальный дизайн базы данных. Проект будет простым веб-приложением для отслеживания процессов и их результатов в матричной диаграмме, я ищу хороший способ сохранить их в реляционных таблицах.
Прямо сейчас я думаю, что у меня есть общая таблица для подпрограмм, координаты x и y также будут отображены и, возможно, отличаться от этой таблицы поиска, содержащей идентификатор координат, в которых записано «попадание». У кого-нибудь есть способы сделать это лучше?
Это только начало проекта, поэтому у меня пока мало деталей, но моя основная причина использования нескольких таблиц заключается в том, что матрицы будут полностью динамическими по размеру и универсальными, так что каждая из них может быть разной, и они будут привязаны к Пользователь
Я также забыл упомянуть, что порядок значений x / y важен, что дополнительно подтверждает мои рассуждения о наличии нескольких таблиц для xy и значений, из этого я твердо предполагаю, что важно знать каждую отдельную ячейку
Основной пример (хотя и абстрактный) этого — процесс, связанный с рестораном. Действия, такие как сесть, заказать еду, просмотреть меню, заказать напитки, поесть, заплатить и т. Д., Результатом будет принятие заказа, доставка напитков, доставка еды, сдача. Несмотря на кажущуюся простоту, это становится сложным, если принять во внимание, что в каждом случае все происходит по-разному, в том числе в случае еды на вынос или фуршета. порядок действий и результатов становится неотъемлемой частью видения различий между ситуациями