Содержание к диссертации
Введение
Глава 1. Анализ моделей баз данных и ограничений для работы с большими объемами слабоструктурированных данных в сапр приборостроения 12
1.1. Анализ моделей данных для хранения большого объема слабоструктурированных данных 12
1.1.1. Анализ реляционной модели данных для представления слабоформализуемых данных 13
1.1.2. Анализ объектно-ориентированной модели данных для представления слабоструктурированных данных 17
1.2. Классификация ограничений целостности баз данных 20
1.3. Отражение ограничения ссылочной целостности в моделях данных 25
1.3.1. Ссылочная целостность в реляционной модели данных 28
1.3.2. Ссылочная целостность в объектно-ориентированной модели 31
1.4. Нереляционная модель данных для хранения слабоструктурированных данных 32
1.4.1. Анализ нереляционных моделей данных для хранения слабоструктурированных данных 32
1.4.2. Принципы масштабирования баз данных 39
1.4.3. Расширение документо-ориентированной модели данных для поддержки ссылочной целостности 42
Выводы по 1 главе 43
Глава 2. Семантическое расширение документо ориенированной базы данных для поддержки ограничений целостности в больших объемах данных 44
2.1. Семантическое расширение документо-ориентированной модели для поддержки ограничений целостности данных 44
2.1.1. Представление слабоструктурированных данных на инфологическом уровне 47
2.1.2. Представление слабоструктурированных данных на концептуальном уровне проектирования 50
2.2. Логическое представление ограничений целостности для слабоструктурированных данных 55
2.2.1. Семантически значимые отражения для представления ограничений ссылочной целостности 55
2.2.2. Преставление знаний об ограничениях целостности предметной области в модели данных 58
2.3. Расширенная документо-ориентированная модель данных с поддержкой ограничений целостности для система автоматизированного проектирования 60
Выводы по 2 главе 64
Глава 3. Методы поддержки ограничений целостности данных в распределенной документо-ориентированной базе данных сапр приборостроения 66
3.1. Требования к документо-ориентированной базе данных системы автоматизации проектирования 66
3.2. Стратегия распределения нагрузки в распределенной базе данных.
3.2.1. Увеличение производительности базы данных при работе с большим объёмом данных посредствам шардинга 72
3.2.2. Репликация данных в распределенной базе данных 75
3.3. Представление семантической информации для поддержки ограничений целостности в распределенной базе данных САПР приборостроения 3.4. Методы поддержки ограничений целостности в распределенной документо-ориентированной базе данных 81
3.4.1. Метод поддержки ограничений ссылочной целостности при обработке больших объемов информации 84
3.4.2. Метод поддержки ограничений предметной области при обработке больших объемов информации 86
Выводы по 3 главе 87
Глава 4. Программная реализация модуля поддержки ограничений целостности для сапр изделий приборостроения .89
4.1. Организация модуля поддержки ограничений целостности в документо-ориентированных базах данных 89
4.1.1. Описание программного обеспечения 89
4.1.2. Структура программного обеспечения 90
4.2. Описание основных семантических конструкций языка взаимодействия с базой данных 93
4.3. Протокол сообщений клиент-серверного взаимодействия 98
4.4. Обоснование эффективности разработанных методов и алгоритмов 102
Выводы по 4 главе 106
Заключение .107
Список литературы .1
- Анализ объектно-ориентированной модели данных для представления слабоструктурированных данных
- Представление слабоструктурированных данных на инфологическом уровне
- Увеличение производительности базы данных при работе с большим объёмом данных посредствам шардинга
- Описание основных семантических конструкций языка взаимодействия с базой данных
Анализ объектно-ориентированной модели данных для представления слабоструктурированных данных
Фундаментальные свойства отношений и процесс нормализации представления данных определяют строгую структуры базы данных и приводят к виду, обеспечивающему минимальную логическую избыточность. Плоские нормализованные отношения, лежащие в основе реляционной модели, универсальны и теоретически достаточны для представления данных любой предметной области. Однако порой в приложениях в БД появляются сотни, а бывает и тысячи таблиц, над которыми выполняют трудоёмкие операции соединения, предназначенные для восстановления сложных структур данных предметной области [28]. Для увеличения производительности представляют данные в денормализованном виде, что уменьшает количество таблиц для соединения, но увеличивает объем обрабатываемых данных при операциях обновления и удаления.
В каждой связи реляционной модели одно отношение выступает как основное, а другое отношение выступает в роли подчиненного. На основании этого делается вывод, что один кортеж основного отношения связан с одним или несколькими кортежами подчиненного отношения. Связи между отношениями поддерживаются неявным образом. Для поддержки данных связей отношения содержат наборы атрибутов, по которым они связаны. В основном отношении это первичный ключ отношения – уникальное значение, которое однозначно определяет кортеж основного отношения. В подчиненном отношении для установки связи присутствует набор атрибутов, соответствующий первичному ключу основного отношения. Однако, в подчиненном отношении данный набор атрибутов уже является вторичным ключом, то есть он определяет множество кортежей подчиненного отношения, которые связаны с единственным кортежем основного отношения. Данный набор атрибутов в подчиненном отношении принято называть внешним ключом. Поддержка целостности отношений и связей между ними предотвращает ввод несогласованных данных пользователями или приложениями, поддерживая данные в непротиворечивом состоянии.
Физическое представление отношений и путей доступа описывается независимо от описания логической схемы отношений, что позволяет избежать избыточности метаинформации при хранении данных, в отличии от объектно-ориентированной или документо-ориентированной модели данных.
В результате исследования [28] реляционная модель накладывает ряд ограничений при проектировании, которые описаны в следующих аспектах:
Модель не обеспечивает достаточных средств для представления смысла данных, в то время как семантика предметной области представляется в голове проектировщика модели данных независимой. Примером может служить представления ограничений целостности, выходящих за пределы ограничений первичного и внешнего ключа;
Во многих прикладных областях возникают сложности при моделировании предметной области на основе плоских таблиц. Иногда, имеет место на самой начальной стадии проектирования дизайнеру необходимо описать предметную область в виде одной, возможно, даже ненормализованной таблицы;
Однородная структура данных. Реляционная модель предполагает горизонтальную и вертикальную однородность данных. Под горизонтальной однородностью данных понимается тот факт, что каждая строка отношения состоит из того же набора атрибутов. Под вертикальной однородностью понимают тот факт, что значения в каком-либо столбце отношения принадлежат к одному и тому же домену. Более того, на пересечении строки и столбца должно находиться элементарное значение. Таким образом, представление слабоструктурированных данных не позволяет размещать их в одной таблице. Решением является денормализация данных или разбиение на несколько таблиц. В обоих случаях операция селекции будет осложнена, а операция объединения может быть не доступна при вынесении данных в другую, объединяющую таблицу;
Весь процесс проектирования происходит на основе учета зависимостей, реляционная модель не предоставляет какие-либо формализованные средства для представления этих зависимостей;
Семантическая перегрузка. Реляционная модель позволяет отражать только одной конструкцией представление данных и взаимосвязей между этими данными — отношением. Например, для представления связи "многие ко многим" ( : ) между двумя сущностями А и В необходимо создать три отношения: два для представления сущностей А и В, а третье — для представления связи;
Не обращая внимания на тот факт, что процесс проектирования начинается с определения некоторых существенных для приложения объектов предметной области и выявления связей между этими сущностями, реляционная модель данных не предлагает какого-либо механизма для разделения сущностей и связей.
Таким образом в реляционной модели выделяются три компоненты -структурная, аспект целостности и аспект манипулирования [9]. Низкая семантика реляционной модели не позволяет гибко описывать и реализовать механизмы поддержки целостности данных. Для поддержки ограничений ссылочной целостности в реляционных СУБД применяются внешние ключи, а также могут применяться триггеры в случае отсутствия поддержки внешних ключей.
Представление слабоструктурированных данных на инфологическом уровне
Типом документа называется разновидность типов данных, характеризуемая информационной структурой.
Экземпляром документа данного типа называется некоторое подмножество множества данных предметной области, выделенное по типу. Каждый экземпляр документа имеет уникальный ключом, который идентифицирует документ среди документов того же типа, что обеспечивает существование каждого из них как целостного объекта.
Каждый экземпляр документа обладает свойством, позволяющим однозначно идентифицировать его, без учета отношений, в которых данный документ состоит. Введено понятие уникального идентификатора документа, значение которого однозначно определяет объект.
Каждый документ можно разбить на части. Каждая часть документа, детализирует информацию о понятии сущности предметной области, то есть происходит группировка свойств документа по семантике, назначению, принадлежности и т.д. Понятие части документа основано на возможности формирования структуры конкретного экземпляра документа в любой момент времени, в то же время понятие части имеет формальное толкование, под которым понимается математическое определение понятия отношение. Значение атрибутов документа и его структура может меняться в течении жизненного цикла, что будет означать определенные изменения или появления новой информации о предметной области. Именно за счет изменения структуры понятие документа и его структуры отличается от понятия отношения, реляционных баз данных. Поэтому введены понятия статическая и динамическая модель документа.
Статическая модель документа – множество упорядоченных частей, которое присутствует в любом документе от момента его порождении и до конца времени существования в системе.
Динамическая модель документа – множество частей присутствующих в конкретном документе в данный момент времени. Динамическая модель может быть уникальной для каждого экземпляра любого типа документа также, как и может отсутствовать вовсе. Сущность предметной области, описанная в рамках концептуальной модели документо-ориентированной базы данных, состоит как минимум из одного документа, описывающего все ее свойства. При описании сущности несколькими документами устанавливается семантическая связь между ее частями, описываемая с помощью уникальных идентификаторов.
Концептуальная модель предметной области Таким образом предметную область, описанную в терминах концептуальной модели документо-ориентированной базы данных, можно представить в виде ориентированного мультиграфа. Вершинами которого являются документы или части документов, обозначаемые oi и принадлежащему типу объектов O. Ребра отображают семантические связи, выделенные в инфологической модели из множества связей R = {r}. Поскольку все связи r R являются ориентированными, то уместно говорить об окрестности любого узла oi О. Например, окрестностью 0-го порядка относительно oi (i(0)) будем называть сам узел oi.
Для примера, рассмотрим фрагмент предметной области «Изделие конструкторского бюро» на концептуальном уровне. Концептуальная модель, изображенная на рис. 2.2, отображает структуру изделия и ее компонентов. Документ «Изделие» имеет изменяемую структуру, поскольку каждый компонент имеет свои характеристики, следовательно, не все компоненты подчиняются общей схеме данных. Данный рисунок является примером для понимания модели предметной области на концептуальном уровне в документо-ориентированной системе.
Оборот “с изменяемой структурой” необходимо воспринимать, как возможность преобразования количества вершин графа, а также направленность связывающих их дуг. То есть каждый экземпляр одного и того же типа объекта может иметь отличную структуру.
Различают разные виды частей документа по их роли в структурно-функциональной модели: основные, внешние и внутренние. Основная часть документа описывает объект инфологической модели и представляет окрестность 0-го порядка данного объекта. Часть документа является внутренней, если она имеет физическое значение только внутри рассматриваемого документа, а также не может быть самостоятельным понятием, так как не имеет прямого отражения в предметной области. Часть является внешней, если представляет некоторую сущность предметной области и является самостоятельным документом. Основная ее цель – детальное описание частей документа. Так как внешняя часть является самостоятельной, то при ее изменении происходит изменение других документов, где эта часть используется.
Увеличение производительности базы данных при работе с большим объёмом данных посредствам шардинга
Все данные в программных комплексах – PDM-системах, предназначенных для поддержки информационного пространства на всех этапах жизненного цикла изделий, разделяют на два вида: Изделия – информация описывающая составные части конкретного изделия, внешний вид, его характеристики и правила эксплуатации. Справочники – наборы данных, применимые при проектируемые любых изделий, являющиеся своего рода словарями, описывающие сущности, используемые в нескольких местах.
Изделие описывается составными частями, а именно: детали, сборочные единицы, комплекты и комплексы. Деталями являются как стандартные изделия, электрорадиоэлементы (ЭРИ) и материалы, так и не стандартные, необходимые для сборки изделия.
Сборочные единицы представляются как сборками, спроектированными для конкретных изделий, так и сборками, которые имеют отношения к нескольким, независимым изделиям. При этом сборками являются электронные узлы, модули, приборы и само изделие.
Комплекты и комплексы – это те составные части изделия, которые разрабатываются в контексте заданного изделия.
На рисунке 3.1. представлена схематичная структура абстрактного изделия. Также каждая сборочная единица изделия обладает рядом атрибутов. Атрибут – элемент данных выражающий характеристику и выраженный в виде названия и значения свойства. Другими словами, атрибут используется для детального описания свойств объекта, которые позволяют представить необходимую информацию об изделии и информацию о составных частях. Атрибуты разделены на два вида: обязательные, необязательные и атрибуты, описывающие индивидуальные характеристики объекта. Рис. 3.1. Схематичная структура изделия
В рамках документо-ориентированной базы данных изделие представляется документом, без определения схемы данных. Характеристики изделия описываются посредством атрибутов, а справочники и изделия представляются различными типами документов.
Таким образом сформулированы требования к представлению и хранению данных, которым должна соответствовать предложенное расширение документо-ориентированной базы данных.
Актуальность.
Проектировщик при использовании среды для проектирования должен иметь доступ к последней версии данных. При работе с распределенными базами данных данное требование можно трактовать как завершением транзакции изменения данных является изменения данных на всех серверах, образующих распределенную базу данных.
Целостность.
Проверка на наличие "висящих" связей между объектами должна осуществляться как при удалении любых данных, так и при добавлении новых объектов в БД. Должно быть подтверждено существование всех объектов участвующих в отношении, только в этом случае операция над данными является возможной. Данное требование является ссылочной целостностью, которую в рамках предложенной диссертационной работы предложено объявляться на уровне БД и поддерживать на уровне СУБД.
Уникальность.
Данное понятие аналогично понятию нормализации данных в реляционных базах данных. Детальное описание объектов в системе должно вводиться не более одного раза, а при необходимости использования информации конкретного объекта устанавливается отношение основной-зависимый объект. Также необходимо отметить, что объекты любых видов, которые используются для формирования структуры изделия, должны иметь ряд атрибутов, с помощью одного или нескольких из них должна быть возможность обозначить объект. Обозначение объектов одного вида должно быть уникальным, но объекты различных видов могут иметь одинаковое обозначение, на основании того, что они описывают в PDM-системе разные составные единицы.
Требования по эксплуатации. При эксплуатации средств системы автоматизации необходимо учитывать требования к БД. Надежность. Под надёжностью базы данных понимают свойство сохранять работоспособность при выходе из строя сервера или серверов базы данных. Говоря о работоспособности, необходимо определить критерий отказа системы. Отказ – это событие при возникновения которого, система утрачивает способность выполнять свое предназначение. Данные понятия выражают смысл друг друга одно через другое: отказ – это потеря работоспособности, в то время как под надежностью понимается свойство, включающее безотказность и готовность к работе в любой момент времени. При работе с документо-ориентированными базами данных поддержка работоспособности и сохранности данных поддерживается за счет репликации и шардирования данных на нескольких вычислительных машин.
Минимизация времени отклика.
Под временем отклика системы понимается временной промежуток от момента времени начала действия до момента времени, когда пользователь системы видит результат выполнения своего запроса. Данный промежуток времени суммируется из нескольких составляющих: время на обработку запроса, время на формирование результата (получение данных и формирование их в объектах программного обеспечении) и время на визуализации (подготовка результатов к удобному для восприятия человеком вида и отображение данных). Обработка больших объемов данных требует большего времени на выполнения запросов. Имеется необходимость использования структур данных позволяющих сократить время на принятия решения.
Описание основных семантических конструкций языка взаимодействия с базой данных
Для однозначной идентификации объектов базы данных введен и используется обязательный атрибут идентификатор. Идентификатор предназначен для обозначения объектов в базе данных. Определим символы, которые могут использоваться в задаваемых пользователем идентификаторах или генерируемых системой, в случае его отсутствия в запросе. На формат идентификатора накладываются следующие ограничения: для однозначной интерпретации идентификатор должен начинаться с буквы; идентификатор не может содержать пробелы и представляет последовательность не нулевых символов.
Таким образом можно определить правило [57], описывающее идентификатор сущности в базе данных. Создание ссылки на документ подразумевает описание в теле зависимого документа идентификатора, название коллекции и название базы данных. Обязательным условием создания ссылки на объект базы данных является существование объекта, на который делается ссылка. Рассмотрим примеры указания ссылок в запросах к базе данных.
Для установки ссылки на документ используется оператор Insert - при создании нового документа, или оператор Update - при изменении объекта базы данных. Оператор Insert и Update принимают в качестве параметра JSON документ, который описывает документ в формате ключ-значение. {
На рисунке 4.3 представлено описание изделия, состоящего из двух видов компонентов. Каждый компонент описывается необходимым количеством изделий и ссылкой на описание компонента. Введен формат описания ссылок, который позволяет однозначно интерпретировать ссылку в теле JSON документа:
Чтобы обозначить атрибут документа, как указания ссылки или ссылок необходимо использовать название атрибута refs;
Атрибут документа refs является массивом ссылок, который может принимать не зависимое количество объектов, описывающих ссылку на документ. На одном уровне документа может находиться всего один атрибут refs, поэтому допускается возможность описания ссылок на разные коллекции. Таким образом refs не является привязкой к конкретному типу, но не рекомендуется использовать данный массив для разных типов, так как это осложняет восприятие и понимание пользователем БД; Объект в массиве refs имеет определенный формат и описывает идентификатор, название коллекции и название базы данных. На рисунке 4.4 представлен пример ссылки в котором ключ JSON документа id является уникальным идентификатором документа, на который устанавливается ссылка, ключ collection является названием коллекции, в которой хранится документ, на который устанавливается ссылка и ключ db, который описывает название базы данных в которой находится документ, на который ставится ссылка. Ключ db является обязательным, так как один экземпляр СУБД может обрабатывать несколько баз данных.
Рассмотрим примеры запросов к базе данных, которые включают работу с ссылками на документы БД. В качестве язык запросов используется JavaScript и JSON-структуры. Выбор данного языка запроса объясняется тем, что эта документ-ориентированная СУБД использует JSON-формат для представления документов и вывода результатов. Физически JSON-структуры хранятся в бинарном BSON-формате.
Вставка нового документа содержащего ссылки Внутри текущей базы данных создаются коллекции, вставка нового документа в коллекцию при помощи метода insert приводит к её автоматическому созданию. В качестве аргумента, метод insert принимает JSON-объект, который служит телом документа. На рисунке 4.5 представлен пример добавления в базу данных изделия, состоящего из двух компонентов. Каждый компонент содержит ссылку на документ, раскрывающий детали используемого компонента для реализации изделия. db.product.insert({ components: [ {
Для обновления используется метод update, первый аргумент которого определяет список обновляемых документов, второй — как отобранные документы модифицируются. Если обновлению подвергается только одно поле, следует обязательно использовать оператор $set. Если его опустить, вместо обновления поля, будет обновлен весь документ. Для удаления дополнительного поля вместо оператора $set, следует подставить $unset. Для того, чтобы добавить ссылку следует воспользоваться оператором $addToSet.
Для поддержки ограничений предметной области задаются ограничения на коллекцию базы данных в виде функции логического вывода. Функция принимает один аргумент - документ который будет проверяться на корректность заданному ограничению. Для написания функции используется язык JavaScript с поддержкой языка запросов JSONPath, предназначенный для организации доступа к частям документа.