CC BY
12
МАТЕМАТИЧЕСКОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВЫЧИСЛИТЕЛЬНЫХ МАШИН, КОМПЛЕКСОВ И КОМПЬЮТЕРНЫХ СЕТЕЙ
УДК 004.652
DOI: 10.24412/2071-6168-2022-6-197-207
МОДЕЛИ ХРАНЕНИЯ ДАННЫХ ДЛЯ ПОИСКА АССОЦИАТИВНЫХ ПРАВИЛ
Е.О. Храмшина
Рассмотрены способы хранения данных для последующей обработки их с помощью алгоритмов поиска ассоциативных правил. Разработаны две базы данных для анализа покупательского спроса с разной структурой, основанные на разных моделях хранения данных: модели фактографического представления данных и модели Entity-Attribute-Value. Произведено заполнение одинаковыми данными. Составлены запросы на выборку данных и проанализирована скорость их выполнения. Проведенный эксперимент показал, что скорость выполнения запросов на выборку в базе данных с фактографическим представлением данных выше, чем в базе данных, основанной на модели данных Entity-Attribute-Value (до 81 раза при тестируемых наборах данных). Трудозатраты по поддержке баз данных оценены с помощью метрики Lines of code (LOC), которая показала, что запрос для базы данных первого типа содержит 7 строк, а запрос для базы данных второго типа - 71, а значит, требует большего времени для написания. Полученные результаты показывают, что для поставленной задачи - анализа данных с помощью ассоциативных правил больших объемов данных - более подходящей по анализируемым характеристикам является база данных с фактографическим представлением данных.
Ключевые слова: модель Entity-Attribute-Value, фактографическое представление данных, базы данных, поиск ассоциативных правил, покупательская корзина.
Современное развитие технических средств позволяет хранить большое количество информации на различных носителях и в различном виде. Наиболее удобный для оперативной обработки и анализа этих данных вид - структурированный. Один из вариантов структурированного хранения данных - базы данных. База данных - это организованная структура, предназначенная для хранения, изменения и обработки взаимосвязанной информации, преимущественно больших объемов [1]. В настоящее время существуют различные виды баз данных, поэтому для конкретного программного продукта следует отталкиваться от предметной области для его выбора - это важный этап разработки. В основе структуры базы данных положена модель хранения информации - способ представления информации в памяти ЭВМ (иерархическая, сетевая, реляционная). По типу хранимой информации базы данных делятся на документальные, лексикографические и фактографические базы данных [2]. Для каждой конкретной задачи из многообразия выбирается определенная, наиболее подходящая модель данных.
197
Цель данной работы - подобрать такую модель хранения данных большого объема, при которой их обработка с помощью алгоритмов поиска ассоциативных правил будет выполняться с наилучшими характеристиками (меньшее время выполнения и требуемый объем памяти). Под данными большого объема понимается такое количество данных, которое не получается обрабатывать обычными методами обработки данных за требуемое время. Выбранная модель будет использоваться при разработке алгоритма распределенного поиска ассоциативных правил [3].
Для выполнения поставленной цели необходимо решить следующие задачи:
1) спроектировать две базы данных с различной структурой;
2) заполнить их одинаковыми данными;
3) разработать запросы к базам данных;
4) оценить временные характеристики выполнения запросов при различных моделях хранения данных для выбранной предметной области;
5) оценить трудозатраты на реализацию баз данных.
В данной работе проведена оценка характеристик для двух моделей хранения данных - ЕПйу-АйпЬШ;е^а1ие модель и модель с фактографическим представлением данных, как наиболее часто используемых. В качестве предметной области рассмотрена область так называемой «покупательской корзины», которая наиболее часто используется для поиска ассоциативных правил.
Обе модели основаны на реляционной структуре базы данных [4]. В ее основе лежат отношения - двумерные таблицы со множеством строк (кортежей) и столбцов (полей или атрибутов). Одна такая таблица представляет собой определенный рассматриваемый объект предметной области. Поля таблицы описывают его свойства, а строки - экземпляры объекта. В каждом отношении является обязательным наличие первичного ключа - атрибута или набора атрибутов, однозначно определяющих единственный кортеж. Связи между объектами осуществляются с использованием внешних ключей.
Достоинством реляционной базы данных является ее простота и логическая замкнутость, а одним из недостатков - сложность системы описания различных связей между таблицами.
Модель Entity-Attribute-Value. Суть модели Епй1у-АйпЬШ;е^а1ие (EAV) заключена в создании нефиксированного набора полей таблицы, а хранение в таблице ключей, которые, в свою очередь, ссылаются на другие таблицы с данными [5]. Такая база данных состоит всего из трех таблиц: сущности (объекты предметной области), атрибуты (свойства и характеристики этих объектов) и таблица значений этих свойств. Атрибут — свойство некоторой сущности, часто ассоциируется с полем таблицы. Среди достоинств такого представления выделяют: гибкость и универсальность структуры данных; простоту добавления нового объекта; отсутствие избыточности данных. Однако выделяют и недостатки данной модели: большое количество запросов для вставки новых данных;
долгое выполнение выборки данных (из-за сложности реализации индексации); возможные проблемы с целостностью данных; неполное понимание модели у многих разработчиков.
Фактографическая база данных. Фактографическая база данных - это база данных, которая накапливает и хранит данные в виде множества экземпляров одного или нескольких типов информационных объектов [6]. Такое название база данных получила, потому что каждый экземпляр информационного объекта содержит ключевые данные по какому-либо факту, событию, вычлененному от остальных сведений и фактов [7].
Фактографические базы данных оперируют формализованными записями данных. Фактографическими базами данных могут быть базы, хранящие данные о складах, покупках и т.д. Предназначение таких баз - поиск однозначного ответа на запрос пользователя и решение конкретной сформулированной пользователем задачи.
По результатам вышеизложенного анализа моделей можно сделать вывод о необходимости применения фактографических баз данных во многих областях жизни человека. Это создает возможность хранить информацию в соответствии с определенными критериями по ее отбору и проводить соответствующее структурирование.
Экспериментальные исследования. Наиболее часто поиск ассоциаций используется для анализа «покупательской корзины», то есть для нахождения зависимостей между совместно покупаемыми товарами. Но стоит отметить, что данный вид анализа данных также может быть применен к медицинским данным или к данным о посещаемости интернет-ресурсов [8]. Процесс разработки баз данных отличается лишь физическим уровнем разработки базы данных (рис. 1), логический уровень и реализация совпадают.
Логический уровень ЕК-диаграмыа
ЦП
Физический уровень ЕК-модель данных
Логический уровень ЕК.-диаграмма
Физический уровень ЕАУ-модель данных
Рис. 1. Процесс разработки базы данных
Первый этап разработки программного продукта - анализ предметной области. Для хранения данных о покупках посетителей для дальнейшего анализа покупательского спроса в простейшем случае достаточно хранить в базе данных транзакцию, дату ее проведения, информацию о товарах - штрих-код, название, купленное количество и цену.
В соответствии с описанием модели EAV разработана первая база (рис. 2, а). В ней будет всего три таблицы: сущности, атрибуты и значения.
Поскольку для фактографической базы данных главной целью является ответ на запросы пользователя - данные в такой базе, зачастую, хранятся в ненормализованном виде, что позволяет сэкономить время на выборку данных. Структура второй базы также состоит из трех таблиц, представляющих собой сущности предметной области (рис. 2, б).
После того как скрипты создания баз данных выполнены, необходимо произвести заполнение баз одинаковыми данными. Системы автоматического проектирования баз данных позволяют выполнить это действие автоматически. Но поскольку существует условие одинаковости данных, полностью автоматизировать этот процесс поможет вспомогательная программа. Сгенерируем скрипт для заполнения данными фактографической базы данных и преобразуем его в скрипт заполнения базы данных, построенной на модели EAV с помощью разработанного алгоритма (рис. 3). На одну строку добавления данных в базу данных, основанную на фактографической модели, приходится до четырех новых строк добавления в базу данных, основанную на модели EAV (одна строка добавления в сущности и несколько строк в атрибуты, в зависимости от количества характеристик сущности).
Листинг метода преобразования скрипта тестовых данных для фактографической модели в скрипт для EAV-модели представлен ниже (листинг 1). В результате получены две совершенно различные базы данных на основе модели фактографического представления данных и EAV-модели с одинаковыми тестовыми данными, что позволит получать одинаковые выборки.
Сравним скорость выполнения запросов на выборку командой «SELECT» языка SQL [9, 10] к этим базам. В выбранной предметной области часто будет необходима выборка данных о покупках в следующем формате: товар и его параметры, транзакция, дата, количество, сумма транзакции. Поскольку структура баз данных различна, то и запросы на данную выборку будут разными. В базе, основанной на фактографической модели данных, необходимо выполнить запрос из листинга 2.
Рис. 2. Структуры баз данных: а) построенной на модели БАУ; б) построенной на модели фактографического представления данных
Листинг 1
Метод преобразования скрипта тестовых данных для фактографической модели
в скрипт для EAV-модели
1 private static void convertScriptToEAV(BufferedReader reader, String file-
name)
2 throws IOException {
3 String fileEAV = filename.substring(0, filename.length() - 4) + "EAVl.sql";
4 int count = 0;
5 Int number = 1;
6 String line = reader.readLine();
7 FileWriter writer = new FileWriter(fileEAV, false);
8 deleteTables(writer);
9 insertToTableAttributes(writer);
10 boolean delete = false;
11 boolean insert = false;
12 while (line != null) {
13 if (count > 70000) {
14 writer.close();
15 count = 0;
16 number += 1;
17 fileEAV = filename.substring(0, filename.length() - 4) + "EAV" + number +
".sql";
18 writer = new FileWriter(fileEAV, false);
19 } else {
20 count += 1;
21 clearStrings();
22 if (delete) {
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
Окончание листинга 1
delete = false;
line = reader.readLine();
continue;
} else {
if (insert) {
insert = false; }
}
words = line.split("\\s"); if ("insert".equals(words[0])) { insert = true;
if ("transaction".equals(words[2])) { convertTransactionInsert(); } else {
if ("product".equals(words[2]) {
convertProductlnsert(line);
} else if ("containment".equals(words[2])) {
convertContainmentInsert();
}
}
writeToFileStrings(writer); writeConsole(line); } else {
if ("delete".equals(words[0])) {
delete = true;
line = reader.readLine();
continue;
}
}
line = reader.readLine();
}
}
writer.close();
}
Листинг 2
Запрос к базе данных, основанной на ER-модели
SELECT
product.idprod, product.name as ProductName,product.cost, [transaction].idtran, [transaction].date as transactionDate, containment.count, product.cost* containment.count as "sum"
FROM containment left JOIN product ON containment.idprod = product.idprod left JOIN [transaction] ON containment.idtran = [transaction].idtran ORDER BY [transaction].date
А в базе, основанной на модели EAV, выполнить запрос из листинга 3.
Листинг 3
Запрос к базе данных, основанной на EAV-модели
SELECT
Tl.valuetext AS IDProd, productData.name AS ProductName, product-Data.cost,
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
Продолжение листинга 3 T2.valuetext AS Idtran, tranData.transactionDate, T3.valueint AS count, productData.cost * T3.valueint AS sum FROM (SELECT
attribute.id_attribute, attribute.name, value.id_entity, value.valuetext, enti-ty.name AS ent FROM attribute LEFT JOIN value ON attribute.id_attribute = value.id_attribute LEFT JOIN entity ON value.id_entity = entity.id_entity WHERE (attribute.id_attribute = 2)) AS T1 LEFT JOIN (SELECT
attribute_7.id_attribute, attribute_7.name, value_7.id_entity, val-ue_7.valuetext, entity_7.name AS ent FROM attribute AS attribute_7 LEFT JOIN
value AS value_7 ON attribute_7.id_attribute = value_7.id_attribute LEFT JOIN
entity AS entity_7 ON value_7.id_entity = entity_7.id_entity
WHERE (attribute_7.id_attribute = 6)) AS T2 ON T1.id_entity = T2.id_entity
LEFT JOIN
(SELECT
attribute_6.id_attribute, attribute_6.name, value_6.id_entity, value_6.valueint, entity_6.name AS ent
FROM attribute AS attribute_6 LEFT JOIN
value AS value_6 ON attribute_6.id_attribute = value_6.id_attribute LEFT JOIN
entity AS entity_6 ON value_6.id_entity = entity_6.id_entity
WHERE (attribute_6.id_attribute = 3)) AS T3 ON T1.id_entity = T3.id_entity
LEFT JOIN
(SELECT
value_5.id_entity, entity_5.name, tablenumbertran.valuetext AS transaction-Number,
value_5.valuedate AS transactionDate FROM attribute AS attribute_5 LEFT JOIN
value AS value_5 ON attribute_5.id_attribute = value_5.id_attribute LEFT JOIN
entity AS entity_5 ON value_5.id_entity = entity_5.id_entity LEFT JOIN (SELECT
attribute_4.id_attribute, attribute_4.name, value_4.id_entity, value_4.valuetext FROM attribute AS attribute_4 INNER JOIN
value AS value_4 ON attribute_4.id_attribute = value_4.id_attribute LEFT JOIN
entity AS entity_4 ON value_4.id_entity = entity_4.id_entity
WHERE (attribute_4.id_attribute = 7)) AS tablenumbertran ON
tablenumbertran.id_entity = value_5.id_entity
WHERE (attribute_5.id_attribute = 1)) AS tranData ON
tranData.transactionNumber = T2.valuetext
LEFT JOIN
(SELECT
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61 62
63
64
65
66
67
68
69
70
71
Окончание листинга 3 t1_1.name AS ent, t1_1.id_entity, t1_1.valuetext AS name, t2_1.valuemoney AS cost,
t3_1.valuetext AS productCode
FROM
(SELECT
attribute_3.id_attribute, attribute_3.name, value_3.id_entity, value_3.valuetext, entity_3.name AS ent
FROM attribute AS attribute_3 LEFT JOIN
value AS value_3 ON attribute_3.id_attribute = value_3.id_attribute LEFT JOIN
entity AS entity_3 ON value_3.id_entity = entity_3.id_entity WHERE (attribute_3.id_attribute = 4)) AS t1_1 INNER JOIN (SELECT
attribute_2.id_attribute, attribute_2.name, value_2.id_entity, val-ue_2.valuemoney
FROM attribute AS attribute_2 LEFT JOIN
value AS value_2 ON attribute_2.id_attribute = value_2.id_attribute LEFT JOIN
entity AS entity_2 ON value_2.id_entity = entity_2.id_entity
WHERE (attribute_2.id_attribute = 5)) AS t2_1 ON t1_1.id_entity =
t2_1.id_entity
LEFT JOIN
(SELECT
attribute_1.id_attribute, attribute_1.name, value_1.id_entity, value_1.valuetext FROM attribute AS attribute_1 LEFT JOIN
value AS value_1 ON attribute_1.id_attribute = value_1.id_attribute LEFT JOIN
entity AS entity_1 ON value_1.id_entity = entity_1.id_entity WHERE (attribute_1.id_attribute = 8)) AS t3_1 ON t1_1.id_entity = t3_1id_entity) AS
productData ON productData.productCode = T1.valuetext ORDER BY tranData.transactionDate
Результаты выполнения запросов для случая с 1000 транзакциями представлены ниже (рис. 3, 4). Результаты запросов одинаковые из чего можно сделать вывод, что данные заполнены верно и запросы составлены верно. Теперь оценим время выполнения запросов для разного количества данных.
IDPrad PiudLictNarme cost Idtran transaction Date count sum
1 ; 660 | 32ygflmsx tuv6sc0 jlpq 3kuy Ijkkqite 1 g9q vujlmy Dquxr5889... 327.00 902 2021-01-01 OD:DD:OO.DM) 162 133974,00
2 974 palxhvv8kwwan3bvj<ni\r5671 uy 1 Ely 15di 3yqnt 3ksmf 3nlpvt... 560.00 246 2021-01-01 02:39:01. DD0 650 364000,00
3 Ж 8v7sup1sw5f4wdv3gtdu3o8w4ac17rtyl3t32psh5 3t1mo5f... 606.00 867 2021-01-01 07:1D:05.DM) 740 44844D.00
4 658 8symfktyakuwve2 gy124snqw1p8a v3 qan5ooq8q0wlted... 5D4.00 631 2021-01-01 07 19 09 000 302 152208,00
5 397 uksgv5kj9fwr6rddh5«isvshkf39qvAyqf0ykl nnped1pdph531... 302.00 731 2021-D1-D1 11:D6:05.D90 799 640798,00
G 6Э0 86Gevp4kcqgxmy4r54wnj 5ce 73balmn2ifawa56vh6 ipcGSd... 70Э.00 465 2021-D1-D1 12:39:20.DD0 472 334648,00
7 872 vbe3ogdn_ijb 59ysgl3mwlnnq3aclrtil 3iw2ypj 3gego7oaf axho 1... 139.00 871 2021-01-02 06:15:15.D[H) 717 99663.00
В 336 5vbvDh1pdd4rav7™ nhofhcd52dcbyogt66lxd 6mvia56i8q... 676.00 26 2021-D1-02 08:D6:31 D90 63 42538.00
Э 235 isSfl 7ceeme5d 7mSy4hEso1dBjanrilir1&DIGoi1wh67igy&<wy... 660.00 436 2021-D1-02 08:D9:23.DD0 16S 11 [1Ш,00
10 910 0vtq0qn2fc5ih31 (rpisbfs33qn6vasl D7ex Ituml 9wd26nkst 9 q... 439.00 544 2021-01-03 0D:22:17.DW) 658 288362,00
Рис. 3. Результаты выборки из базы данных, построенной на модели EAV
idpnod PioductNarne cost idtran transaction Date count sum
1 | 660 | 32vgfImss tuv6sc0jlpq3kuy 1 jkkqEKs 1 gSq vujlmy0quxr5££S... S27 902 2021-01-01 00:00:00.000 162 133974
2 Э74 palxhvvSkwwan 3bv;<niv5671 uy 19y 15di Byqnt 3ksmf Snip vt... 560 246 2021-01-01 02:39:01.000 650 3640DD
3 886 3v7sup1sw5f4wdv3gtdu3oSw4ac17rtyl3t32psh5 3t1mo5f... 606 367 2021-01-01 07:1 D: 05.000 740 44£440
А ess ikymf ktyakuwve2 gy 124*nqw 1 pSa v3 qanSooq Sq [Med... 504 631 2021-01-01 07:19:09.000 302 152203
5 397 uk*gv 5kj ИwrGrddh Ewisvxhkf39qvxyqf Uykl mped 1 pdph 561... 302 731 2021-01-01 11:06:05.000 799 640793
6 690 365evp4kcqgxmy4r54wnj 5ce 73balmn2ifawa56vh6 ipc65d... 709 465 2021-01-01 12:39:20.000 472 334643
7 372 vbe 3ogdnjjb 55ysg Umwlmq Saclrtil 3iw2ypj 3gego7oaf axho 1... 139 371 2021-01-02 06:15:15.000 717 99663
о ззб 5vbv3h1pdd4rav7vj< nhofhcd52dcbyogt661xd EniviabSBq... 676 26 2021 -01 -02 06:06:31.000 63 42533
9 235 isSfl 7ceeme5d 7mBy4h5so1dSjannhr160(Eoi1wh67igy[><wy... 660 436 202141141206:09:23.000 163 110330
10 910 Ovtg Dgn2£sih31 vpjsbfx 33qn6vaxl07ex ItLirnl 5lwd26nkst 9 q... 439 544 2021411413 00:22:17.000 653 233362
Рис. 4. Результаты выборки из базы данных, построенной на модели фактографического представления данных
Вычислим необходимое количество экспериментов по формуле, выведенной из неравенства Чебышева [11]:
с
п =-
(1-у)е2'
где С - верхняя граница дисперсии, БХ < С.
Эта формула гарантирует, что при числе испытаний п с вероятностью, не меньшей у, можно быть уверенным в том, что абсолютная погрешность приближенного равенства МХ « X не превысит е.
Поскольку порядок измерений различен для разного количества транзакций, единую погрешность измерения выбирать некорректно, значение дисперсии тоже будем находить для каждого количества транзакций отдельно, у = 0,9. Примем погрешности £, равные приведенным в табл. 1, достаточными для эксперимента.
Таблица 1
Количество экспериментов в зависимости от погрешности_
Количество транзакций в базе данных, шт. С Погрешность е Количество экспериментов
1000 220,1 5 89
10000 1 443,8 15 65
100000 16 542,7 50 67
1000000 64 675,1 100 65
Усредненные временные характеристики выполнения запросов представлены ниже (табл. 2). Для сбора статистики запросы выполнялись для разного количества транзакций в базах данных. Эксперимент проводился на ЭВМ со следующими параметрами: процессор AMD Ryzen 7 3700X 8-Core Processor 3.60 GHz; оперативная память 8 ГБ; жесткий диск 250 ГБ SSD M.2 накопитель WD Blue; система Windows 10 Pro 64-разрядная.
Таблица 2
Время выполнения запросов на выборку данных _
Количество транзакций в базе данных, шт. Время выполнения запроса на выборку данных для анализа, мс Отношение, раз
Модель Entity-Attribute-Value Фактографическое представление данных
1000 85,3 43,3 1,9
10000 2 199,6 107,3 20,5
100000 43 422,0 539,1 80,5
1000000 410 438,5 5 058,4 81,1
Оценку трудозатрат по реализации баз данных будем оценивать размерно-ориентированной метрикой оценки кода - LOC-метрикой (Lines Of Code). Данная метрика позволяет оценить текущие и будущие трудозатраты на написание кода, не учитывая при этом опыт и умения программистов. Объем программы измеряется в строках исходного кода. Выделяют два основных показателя LOC:
количество «физических» строк кода - определяется как общее число строк исходного кода, включая комментарии и пустые строки (при измерении показателя на количество пустых строк, как правило, вводится ограничение - при подсчете учитывается число пустых строк, которое не превышает 25% общего числа строк в измеряемом блоке кода);
количество «логических» строк кода - определяется как количество команд и зависит от используемого языка программирования. В том случае, если язык не допускает размещение нескольких команд на одной строке, то количество «логических» LOC будет соответствовать числу «физических», за исключением числа пустых строк и строк комментариев. В том случае, если язык программирования поддерживает размещение нескольких команд на одной строке, то одна физическая строка должна быть учтена как несколько логических, если она содержит более одной команды языка.
Оценку показателя будем производить по тексту запроса (табл. 3).
Таблица 3
Данные для расчета показателя LOC_
Запрос к базе данных, основанной на фактографическом представлении данных Запрос к базе данных, основанной на модели Entity-Attribute-Value
Количество физических строк кода Количество логических строк кода Количество физических строк кода Количество логических строк кода
7 3 71 28
На основании полученных значений можно сделать вывод, что более трудоза-тратной является работа с базой данных, основанной на модели EAV.
Выводы. Проведенное исследование показало, что для обработки данных с помощью поиска ассоциативных правил при работе с большими наборами данных наиболее предпочтительно фактографическое представление данных. При небольших наборах данных разница во времени выполнения запросов на выборку незначительна, однако, при увеличении количества транзакций в базах данных, растет и время выполнения запросов. Благодаря фактографическому представлению данных, запросы на выборку выполняются до 81 раза быстрее (при используемых наборах данных), что позволяет сэкономить время на выгрузке данных для анализа. Кроме того, при таком способе хранения данных значительно сокращается время на разработку запросов к базе данных. Поскольку большее время из всего проведения эксперимента было затрачено именно на заполнение базы данных, написание запроса для модели EAV и его отладку, что подтвердили значения метрики LOC. В дальнейшем выбранная структура хранения данных будет использована в программном обеспечении для распределенного алгоритма поиска ассоциативных правил для больших объемов данных.
Список литературы
1. Коломейченко А.С., Польшакова Н.В., Чеха О.В. Информационные технологии: учеб. пособие. СПб.: Издательство «Лань», 2018. 228 с.
2. Ponniah P. Data Modeling Fundamentals: A Practical Guide for IT Professionals. Wiley, 2007. 464 p.
3. Khramshina E.O., Prutzkow A.V. Association Rules Mining with Three-Dimensional Data Structure. In International Journal of Open Information Technologies, 2020, Vol. 8, No. 8. P. 8-12.
4. Thalheim B. Entity-Relationship Modeling: Foundations of Database Technology. Springer, 2013. 628 p.
5. Sinard J. Practical Pathology Informatics: Demystifying Informatics for the Practicing Anatomic Pathologist. Springer, 2006. 393 p.
6. Медведкова И.Е. Базы данных: учеб. пособие. Воронеж. гос. ун-т инж. тех-нол. Воронеж: ВГУИТ, 2014. 108 с.
7. Martz N., Warren J. Big Data: Principles and Best Practices of Scalable Realtime Data Systems. Manning Publications Co, 2015. 28 p.
8. Collen M.F. Computer Medical Databases: The First Six Decades (1950-2010). Springer, 2012. 309 p.
9. Шнырев С Л. Базы данных: учеб. пособие. М.: НИЯУ МИФИ, 2015. 224 с.
10. Фиайли К. SQL: руководство по изучению языка: [пер. с англ.]. М.: ДМК Пресс, 2022. 456 с.
11.Калинина В.Н., Панкин В.Ф. Математическая статистика. М.: Высшая школа, 1998. 336 с.
Храмшина Евгения Олеговна, аспирант, ассистент,
evgenia.khramshina@smail.com, orcid 0000-0002-4490-8403, Россия, Рязань, Рязанский государственный радиотехнический университет имени В. Ф. Уткина
DATA STORAGE MODELS FOR ASSOCIATION RULES MINING
E.O. Khramshina
Methods of storing data for processing with association rules mining algorithms are considered. Two databases have been developed for the analysis of consumer demand with different structures, based on different data storage models: the factual data representation model and the Entity-Attribute-Value model. They filled with the same data. Requests for data sampling are made and the speed of their execution is analyzed. The experiment showed that the speed of query execution in a database with factual representation of data is higher than in a database based on the Entity-Attribute-Value data model (up to 81 times for the tested data sets). The database support effort was estimated using the Lines of code (LOC) metric, which showed that the query for the first type database contains 7 lines, and the query for the second type database contains 71, which means that it takes more time to write. The results obtained show that for the task at hand - data analysis with association rules mining for large data volumes - a database with a factual presentation of data is more suitable in terms of the analyzed characteristics.
Key words: association rules mining, entity-attribute-value model, factual representation of data, databases, shopping cart.
Khramshina Evgeniya Olegovna, postgraduate, lecturer assistant, evgenia.khramshina@gmail.com, orcid 0000-0002-4490-8403, Russia, Ryazan, Ryazan State Radio Engineering University named after V.F. Utkin
