Главная страница
Навигация по странице:

  • Таблица 2. Сравнение форматов хранения данных

  • Рисунок 2. Процесс загрузки данных в БД с использованием интерактивных SQL запросов

  • Автоматизация загрузки больших массивов данных предметной области в промышленную бд


    Скачать 0.74 Mb.
    НазваниеАвтоматизация загрузки больших массивов данных предметной области в промышленную бд
    Дата15.08.2022
    Размер0.74 Mb.
    Формат файлаpdf
    Имя файлаText_KoveshnikovMG.pdf
    ТипДокументы
    #646185
    страница2 из 5
    1   2   3   4   5
    2.
    Форматы хранения данных
    2.1
    XML
    XML – язык разметки, который определяет набор правил для представления данных в виде XML документа. При его разработке согласно [6] одними из целей, которые ставились перед создателями, являются следующие идеи:

    XML должен быть с легкостью используемым в сети Интернет;

    XML должно поддерживать большое число приложений;

    XML документы должны быть понятными человеку;

    Размер XML документов имеет наименьший приоритет.
    XML документы структурированы в виде леса так, что их можно читать без дополнительных приложений при понимании концепции вложенности тэгов. Схема XML помогает убедиться в целостности документа, проверить ограничения, налагаемые на данные, и задать возможные связи между сущностями. Также, так как все данные в XML документе имеют текстовый формат, то возможна коллективная работа над данными.
    Возможно использование утилит для сравнения текстовых файлов, проведения инспекций изменений между версиями одного файла.
    Существует много средств для работы с XML, таких как DOM- анализаторы, SAX- анализаторы, языков запросов XPath, XQuery. Анализаторы позволяют выполнить разбор
    XML документа, подтвердить корректность документа или выдать сообщение о неправильной структуре файла. Существует два вида анализаторов, которые отличаются по представлению считанных данных в памяти. Древовидные анализаторы, например
    DOM-анализаторы, полностью считывают документ и представляют его в виде дерева или леса, доступ к которому предоставляется разработчику. В то время как потоковые анализаторы, например SAX-анализаторы, считывают документ постепенно и генерируют события по мере того, как встречаются тэги XML. Для обеспечения проверки документа либо в него включается описание, либо создается его схема. Согласно [6] документы XML можно разделить на правильно построенные и корректные. Правильно построенные документы отвечают требованиям к синтаксису XML, а корректные удовлетворяют схеме или описанию документа.
    Технология XSLT применяется для преобразования XML в другие форматы. На вход XSLT процессору подаются XML документ и таблица стилей, которая определяет, как представлять те или иные данные из входного документа в результирующем файле.
    12

    Встроенные в СУБД Oracle функции для работы с XML документами позволяют форматировать данные в виде XML, агрегировать записи в виде XML дерева, конкатенировать значения.
    Благодаря широкому распространению языка XML во многих языках программирования существуют, как встроенные библиотеки для работы с XML документами, так и сторонние решения. Документы XML хорошо подходят для представления и передачи структурированной информации, что делает его удобным способом для хранения данных.
    2.2
    CSV
    Альтернативой XML для представления табличной информации может послужить
    CSV формат, который также является текстовым. Этот формат получил распространение за счёт широкой поддержки табличными редакторами. Основными функциями, которые работают с CSV форматом, являются импорт и экспорт, что позволяет удобно конвертировать файлы разных форматов. И как следствие он может использоваться для передачи данных между различными системами, как единый вид представления табличной информации.
    CSV формат хорошо подходит для хранения последовательностей записей с одинаковым числом полей. Однако он не приспособлен к хранению иерархической информации. Тем не менее, если необходимо, можно преобразовать иерархию в плоскую структуру. Этот формат хранит только данные и небольшое количество символов для поддержки структуры и экранирования служебных символов. Соответственно, в одном
    CSV файле могут храниться только записи одного типа, что ограничивает возможности по представлению данных в этом формате.
    Реляционная СУБД Oracle предоставляет возможность для импорта и экспорта данных в формат CSV. Для импорта данных предпочтительным способом является утилита SQL*Loader, которая позволяет гибко задавать формат файла. Также можно использовать технологию внешней таблицы для загрузки данных. В этом случае создаётся таблица, которая использует данные из плоского файла, затем происходит запроса вида
    INSERT INTO … SELECT, который выполняет загрузку в обычную таблицу. Для экспорта данных применяется спулинг, когда результат запроса выводится в файл, также можно производить выгрузку при помощи PL/SQL процедур. Для упрощения загрузки и выгрузки данных имеются заготовки в веб-форме.
    13

    Как и в случае с XML, для работы с данными в формате CSV существует множество библиотек для Java, которые реализуют основные функции такие, как чтение и запись (SuperCSV, OpenCSV, JavaCSV и т.д.).
    2.3
    XLS
    Другим форматом, подходящим для хранения данных, является формат XLS. В отличие от XML и CSV он является бинарным. Также существуют и другие форматы, которые хранят данные в бинарном виде, например, ODS, XLSX. Два последних формата являются сжатыми архивами, которые содержат описание документа и данные преимущественно в формате XML. XLS формат поддерживают многие табличные процессоры. Однако встроенными средствами СУБД чаще всего не удаётся осуществить загрузку и выгрузку, используя этот формат. Поэтому необходимо первоначально произвести промежуточные преобразования. Кроме того, в связи с тем, что этот формат является бинарным, файлы в этом формате необходимо блокировать в потенциально многопользовательском окружении перед работой.
    2.4
    Сравнение форматов
    Хранение информации в том или ином формате, даёт свои преимущества и для того, чтобы выбрать подходящий, необходимо привести сравнение по некоторым критериям.
    Одним из немаловажных качеств формата является размер документа. Так бинарные форматы, чаще всего применяют сжатие для того, чтобы размер файла был меньше, однако помимо данных в файлах хранятся и метаданные, которые определяют стили и прочие дополнительные свойства данных, что оказывает существенное влияние на размер файла. Текстовые форматы хранят данные в виде текста, что увеличивает размер файла относительно заархивированного формата. Тем не менее, такие форматы как CSV, которые не содержат метаданных, при средних и малых объемах данных занимают меньше дискового пространства, чем аналоги в форматах XLS или XML.
    Другим немаловажным фактором при использовании файлов с табличной структурой является возможность совместной работы. Для бинарных файлов по умолчанию такая возможность отсутствует, так как обычные средства сравнения файлов не могут определить эффективную разницу между ними. Тем не менее, существуют сторонние средства и дополнения к системам контроля версий для сравнения таблиц в одинаковом формате, например xdocdiff.
    Кроме того следует учесть особенности работы с файлами в форматах. Так, если речь идёт о бинарных файлах, то для работы с ними необходим табличный процессор и к тому же системы управления базами данных не предоставляют функций для обработки
    14
    таких форматов. Поэтому для загрузки данных в базу и автоматической обработки данных может потребовать различный объём усилий. К примеру, чтобы загрузить данные из сложного документа XML, может потребоваться произвести преобразование данных в
    SQL запросы.
    Формат
    CSV
    XML
    1
    XLS
    XLSX
    ODS
    Размер среднего файла
    2 2.1 Мбайт
    19.1 Мбайт
    6.5 Мбайт
    1.7 Мбайт
    1.3 Мбайт
    Размер небольшого файла
    3 49 Кбайт
    541 Кбайт
    103 Кбайта
    39 Кбайт
    70Кбайт
    Коллективная работа
    +
    +
    +
    4
    +4
    +4
    Зависимость от дополнительног о программного обеспечения нет нет
    Табличный процессор с поддержкой данного формата
    Табличный процессор с поддержкой данного формата
    Табличный процессор с поддержкой данного формата
    Использование для импорта данных
    +
    +
    5
    -
    6
    -6
    -6
    Использование для экспорта данных
    +
    +5
    -6
    -6
    -6
    Таблица 2. Сравнение форматов хранения данных
    В результате можно сказать, что использование формата CSV подходит для хранения и преобразования табличных данных, которые не имеют иерархической структуры, между различными системами. Если же необходимо структурировать данные в виде иерархии, то целесообразно использовать XML, так как этот формат поддерживает вложенность объектов.
    1
    Размеры XML документов в данной таблице представлены для формата «XML таблица», поддерживаемого
    Excel
    2
    Таблица из 360 тысяч уникальных значений, каждое размером от 1 до 6 символов, в 10 тысячах строках
    3
    Таблица из 10 тысяч уникальных значений, каждое размером от 1 до 5 символов, в 1 тысяче строк
    4
    При установке дополнения к системе контроля версий
    5
    Если XML файл имеет жестко заданную структуру, в противном случае необходимо использовать сторонние средства
    6
    Возможно только при использовании специализированных программ
    15

    3.
    Подходы к загрузке данных
    3.1
    SQL-запросы
    Один из простейших вариантов загрузки данных - это формулирование интерактивных SQL-запросов к базе данных с использованием INSERT и UPDATE выражений. Данный подход предполагает знание не только языка SQL, но и схемы базы данных. Поэтому чаще всего непосредственно формулированием запросов занимается разработчик, а оператор предоставляет данные. Таким образом, возникает существенная вероятность возникновения ошибки, так как контролировать передачу информации от источника к базе данных довольно трудно. Кроме того, учитывая, что схема базы данных в большинстве случаев нормализована, то запись в понимании оператора может быть представлена группой записей в нескольких таблицах, имеющих ссылки между собой для проверки целостности. При этом вставки должны быть совершены в определённом порядке: сначала записи, которые не содержат внешних ключей, затем те, которые ссылаются на уже вставленные данные, и так далее. При загрузке могут возникнуть проблемы с циклическими ссылками между записями таблиц, наличие таких связей чаще всего сигнализирует об ошибке при составлении схемы данных, но, тем не менее, возникновение такой ситуации вполне возможно. В этом случае необходимо выполнять загрузку с отключенными проверками целостности и включать их после выполнения вставок. Поэтому для того чтобы вставить в базу данных сущности, надо обладать компетенцией для работы с базой данных. Более того ситуация усугубляется тем, что формулированием запросов, сбором и обработкой данных занимаются люди, поэтому на качество загружаемых данных влияет и человеческий фактор. Причем чем больше происходит передач информации от человека к человеку, тем выше риск неправильной трактовки данных и возникновения ошибок. Данный процесс представлен на рисунке 2, где стрелка помечена красным цветом, если существует вероятность ошибки при выполнении указанного действия.
    Данный способ загрузки имеет низкую скорость, так как на каждый запрос тратятся ресурсы СУБД: выполняется синтаксический анализ, составляется плана запроса, и происходит его выполнение. Более того если таблица индексируется по одному или нескольким столбцам, то могут возникнуть накладные расходы на реорганизацию индекса. Поэтому целесообразно включать индексирование после загрузки данных, и хотя это займет, возможно, значительное время, но оно не превзойдет суммарные затраты на работу во время загрузки. Также на скорость загрузки могут влиять триггеры, которые выполняются при каждой вставке или, если задано условие, при некотором ограничении
    16
    на входные данные. При выполнении загрузки большого объёма данных следует сделать это условие максимально строгим, чтобы не вызывать ложных срабатываний триггеров.
    Однако при загрузке 5 тысяч записей с использованием триггера, у которого было указано
    WHEN условие срабатывания, не отличилось по скорости выполнения от триггера, где та же проверка была внутри тела.
    Использование запросов SQL для загрузки в базу данных переносимо между разными СУБД, так как синтаксис INSERT запросов, не использующих специфических функций, совпадает. Запросы удобно хранить в файлах для последующего использования.
    Эти текстовые файлы удобно хранить в системах контроля версий, так как все модификации сохраняются в виде истории и возможна одновременная работа нескольких пользователей над одним и тем же файлом. Различные изменения одно и того же текстового файла разными пользователями по умолчанию поддаются слиянию воедино.
    Хранение исполненных запросов для наполнения на жестком диске позволяет передавать на другие компьютеры для получения в точности такого же наполнения. Целесообразно логически разделять файл с запросами на последовательность файлов - обновлений базы данных. Такое разделение может пригодиться не только для более быстрого поиска синтаксических ошибок, но и для внесений дополнительных специфических данных для заказчика. Кроме того, обновление базы данных через запуск нескольких файлов с наполнением становится более надежным, так как при ошибке достаточно отменить изменения до последнего успешно установленного обновления. Способ внесения данных с помощью запросов удобен, когда необходимо либо внести небольшой объём данных в базу немедленно, либо когда необходимо сделать обновление некоторых данных в базе.
    Оба этих варианта использования базы могут диктоваться срочными требованиями заказчика к первичному наполнению или иными событиями, влекущими изменения общего первичного наполнения системы. Однако, по мере роста объёма данных для обновления, растёт и время, затрачиваемое на этот процесс. Также возрастает трудность поддержки и сопровождения, так как в случае ошибок приходится делать все новые и новые обновления. Причиной тому, что исправить ошибку наполнения проще, сделав новое обновление, является факт, что источник проблемы довольно трудно найти и могут существовать данные, которые уже зависят от этого наполнения. Данные обновления помимо всего прочего надо хранить и упорядочивать, чтобы процесс установки происходил в правильной последовательности. Для этого необходимы метаданные об обновлениях, позволяющие однозначно определить порядок их установки. При большом количестве таких обновлений и появлении ответвлений в дереве зависимостей возникает
    17
    необходимость в автоматическом разборе этих метаданных для упорядочивания обновлений для установки.
    Рисунок 2. Процесс загрузки данных в БД с использованием интерактивных SQL запросов
    Недостатки подхода:
    - необходимо знание схемы базы данных и языка запросов к БД (SQL);
    - легко допустить ошибку, как в самих данных, так и в генерации SQL-запроса, если процесс генерации не автоматизирован;
    - трудоёмкость использования и освоения;
    - для многократного использования необходимо сохранение SQL-запросов в файлах.
    Объём файлов растет по мере увеличения количества информации. Файл содержит операторы и конструкции языка запросов, что может негативно отразится на занимаемом объёме памяти;
    - необходимо упорядочивать исполнение запросов при наполнении из существующих файлов;
    - смена схемы базы данных влечёт исправление всех запросов, связанных с ней;
    - затруднительна обработка и модификация данных, которые сформулированы в виде
    SQL-запросов;
    - низкая скорость, обусловленная низкой скоростью генерации запросов и их выполнением с проверками целостности;
    Преимущества:
    - переносимость между СУБД;
    - ошибки сразу видны при выполнении одиночного запроса;
    - возможность дополнения базы данных в виде дополнительных SQL-запросов;
    18

    - различные версии текстового файла с запросами можно сравнивать стандартными средствами систем контроля версий и соответственно выполнять слияние;
    В итоге данный метод предполагает, что либо необходимо обучать операторов, которые осуществляют сбор данных языку SQL и посвящать в устройство баз данных, либо тратить время разработчиков или администратора на наполнение базы данных. Оба варианта приносят большие финансовые потери. Следует отметить, что использование построителей запросов частично решает проблемы данного метода, но как бы, то, ни было, этот метод является совершенно неприемлемым для больших массивов данных.
    Данное решение, тем не менее, является переносимым между разными СУБД и позволяет производить обновление данных в базе, что удобно для небольших обновлений.
    3.2
    Загрузка данных при помощи утилиты Import для СУБД Oracle
    Существуют и иные способы загрузки данных в базу, отличные от описанного выше метода. Они используют другие механизмы, которые позволяют производить загрузку данных быстрее, нежели вставка каждой записи в таблице в отдельном запросе.
    Тем не менее, за счет увеличения скорости загрузки появляются ограничения на формат и тип загружаемых данных, а для некоторых способов ещё и наличие дополнительных метаданных для разбора файла.
    Один из таких способов – загрузка данных в некотором бинарном формате. Данный способ использует заранее заготовленный файл – дамп. Этот файл генерируется утилитой
    Export и содержит данные в бинарном виде. В заголовок файла помещаются данные о сеансе выгрузки с помощью утилиты Export: имя пользователя совершившего выгрузку данных, время, версию СУБД, имя файла. Затем идут данные о схеме таблиц и типах, сопровождаемые дополнительной информацией, и перечисляются данные. Ближе к концу файла описываются ограничения. Таким образом, для загрузки в базу данных утилита
    Import обладает достаточным набором информации внесённой в дамп-файл.
    Из-за того что файл хранится в бинарном формате система контроля версий, если она используется, не может достоверно определить, какая порция данных изменилась при редактировании файла.
    Следует отметить, что версия утилиты Import должна быть не ниже версии утилиты
    Export, которая использовалась для создания файла - дампа.
    Использование утилиты Import предполагает, что дамп был сгенерирован утилитой
    Export, поэтому загрузка данных из файлов в бинарных форматах генерируемых другими
    СУБД не представляется возможной. Однако у многих СУБД есть свои утилиты или встроенные команды для экспорта базы данных в виде файла, который содержит схему
    19
    базы и имеющиеся в ней данные. В последствие при нарушении работы СУБД и потере текущей версии базы можно загрузить данные из этого файла, потеряв только изменения, которые произошли с момента его создания. Для СУБД MS SQL Server аналогами Import и Export являются команды BACKUP и RESTORE.
    Данный способ загрузки не подходит, если необходимо какое-либо вмешательство.
    Любые изменения могут повлечь нарушение формата и проблемы при восстановлении данных из файла. В связи с этим, хранение дампа в системах контроля версий для данного способа не приносит пользы, так как файл не подлежит одновременному изменению несколькими пользователям. Перед изменением один из них должен заблокировать файл в системе контроля версии, чтобы изменения не были утеряны. Загрузка из файла работает для конкретной СУБД, утилиты которой были использованы для генерации дампа, так как бинарные форматы таких файлов различных СУБД закрыты и не совместимы между собой. В связи с этим отсутствует переносимость между разными СУБД.
    Так как утилита Import загружает данные из дампа в определённом порядке, то этот процесс протекает довольно быстро. Загрузка происходит в том порядке, в котором данные и метаданные помещены в файл дампа. Так в самом начале последовательности создаются таблицы и типы, затем загружаются данные и индексы, потом импортируются триггеры и включаются ограничения целостности. Такая последовательность помогает избежать повторных срабатываний триггеров и проблем с ограничениями при загрузке внешних ключей. То есть, в ходе загрузки ограничения целостности и триггеры включаются только тогда, когда данные уже расположены по таблицам.
    Утилита Import позволяет загружать данные из дампа в уже созданные таблицы, однако при этом возникают дополнительные трудности: необходимо вручную отключать ограничения, наложенные на данную таблицу, таблицы должны иметь совместимые схемы. Кроме того можно вручную управлять процессом импорта, постепенно загружая данные из дампа. Также необходимо позаботиться о ручном создании системных триггеров, если таковые имелись в базе, из которой происходил экспорт, так как они не попадают в дамп.
    Утилита Import имеет четыре варианта работы:
    - полная загрузка;
    - загрузка пространства таблиц;
    - загрузка объектов определенного пользователя;
    - загрузка определенных таблиц и секций.
    Во время полной загрузки перемещаются все объекты базы данных, однако чтобы провести импорт в этом режиме необходимо обладать привилегией
    IMP_FULL_DATABASE
    20

    Режим пространства таблиц позволяет загрузить определённые группы таблиц. Также необходимо обладать привилегией указанной выше, чтобы осуществить данный вид загрузки. Режим загрузки объектов некоторого пользователя позволяет загрузить таблицы и другие объекты базы данных. Каждый пользователь может загружать все объекты, принадлежащие ему, однако для загрузки чужих объектов необходимо быть привилегированным пользователем. Режим загрузки таблиц загружает таблицы и секции текущего пользователя, привилегированный пользователь может загружать любые таблицы.
    1   2   3   4   5


    написать администратору сайта