Введение
1 История баз данных
1.1 Переход от данных к информации, к интеллекту и знаниям
1.2. Иерархическая и сетевая модель базы данных
1.3 Реляционная база данных
1.4 Ассоциативная модель базы данных
Заключение
Список источников
Введение
Специалисты в области информационных технологий, занимающиеся проектированием или архитектурой баз данных, вероятно, знакомы с моделью реляционной базы данных. В этой статье будет кратко обобщена реляционная и другие знакомые модели данных.
В оставшейся части этой статьи будет представлена и описана ассоциативная модель базы данных. Ассоциативная модель менее известна, поскольку она относительно новая и не имеет большой базы поставщиков программного обеспечения. Хотя он, по-видимому, предлагает ряд преимуществ по сравнению с другими структурами баз данных, ему еще предстоит добиться коммерческого успеха на основном рынке баз данных. Однако, учитывая рост все больших и больших баз данных и хранилищ данных, а также скорость и эффективность, обещанные ассоциативной моделью данных, эта модель данных, вероятно, станет важным новым дополнением к рынку баз данных.
В этой статье основное внимание будет уделено введению ассоциативной модели данных и сравнению с реляционной моделью данных – с ограниченными примерами эталонных данных или реальных приложений. Однако планируется серия последующих статей, в которых будут описаны достоинства этой новой модели данных и фактическое применение технологии. Примечание: для целей настоящего документа система управления базами данных (СУБД), модель данных и архитектура данных – хотя и не являются синонимами – используются несколько взаимозаменяемо.
История баз данных
Маклеод и Шелл отмечают, что, системы управления базами данных имеют относительно короткую историю, а первая СУБД была разработана GE в 1964 году. Как описано Саймоном, мэйнфреймы были источником ранних данных и приложений для обработки данных.
Поскольку мэйнфреймы начали заменяться миникомпьютерами, люди начали искать способы получить более прямой доступ к данным вместо того, чтобы делать запросы в отдел обработки данных каждый раз, когда требовались данные из файлов приложения или баз данных. Чтобы получить более прямой доступ, будут скопированы стандартные данные, полученные в результате запроса на ленту для передачи на миникомпьютер и использования на нем. Этот подход работал в некоторых случаях, в других случаях это было проблематично из-за временной задержки и необходимости запрашивать мэйнфрейм, если требовались какие-либо другие данные В 1980-х годах микрокомпьютеры и компьютерные приложения широко распространили распределенные вычисления. Хотя предполагались эффективные распределенные системы управления базами данных, “островки данных” были проблемой, которую создавали эти приложения на базе ПК.
С 1990 года по настоящее время развитие более мощного аппаратного обеспечения, программного обеспечения и сети технологии, включая появление Интернета и связанных с ним глобальных телекоммуникационных возможностей – результатом стало мощное программное обеспечение для баз данных, огромные хранилища данных и складские помещения, а также разнообразные модели и структуры для хранения данных. Основная цель всего этого роста и продвижения технологий заключалась не только в технологии ради технологии. Цель состояла в том, чтобы сделать данные доступными для людей – в правильной форме, своевременно и в правильном контексте – чтобы позволить им принимать соответствующие решения относительно данных , относящихся к их бизнесу или функции. Чтобы сделать это, данные должны иметь смысл, быть преобразованы в информацию и расширять или создавать знания для пользователя.
Переход от данных к информации, к интеллекту и знаниям
Данные — это отдельные биты информации, не имеющие никакого связанного контекста, придающего им смысл. Например, эта строка элементов данных – #PM764, 60, SN 1239876a, 814-555-1212 – каждый из них представляет что-то, но не имеет смысла без контекста или связи с другими данными. Данные не имеют смысла без взаимосвязи (например, 60). Если вы возьмете любой из этих элементов данных и объедините его с другой информацией или покажете взаимосвязь, вы получите информацию, то есть фрагменты данных с взаимосвязями.
Например, если вы укажете 60 сотрудников, идентификационную карточку сотрудника #PM764 и телефон наберете 814-555-1212, тогда каждая часть данных станет более значимой. Любая информация относительно бессмысленна без контекста. Например, если вы говорите, что Пэту Смиту 60 лет – 60 — это возраст, вес или IQ? Контекст придает информации актуальность. Для каждого контекста, в котором представлена информация, она может иметь уникальный набор взаимосвязей с другими частями информации. Существует столько же типов отношений, сколько и способов мышления о вещах.
Информация в любом контексте может иметь бесконечное число взаимосвязей с другой информацией элементы или наборы. Информация может быть собрана в бесконечном количестве наборов, и информационные элементы могут существовать одновременно в любом количестве различных информационных наборов. Информация растет за счет добавления перспективы и намерения. Чтобы вывести информацию на уровень интеллекта, ее необходимо дополнительно контекстуализировать. Как указывалось ранее, данные относятся к символам, цифрам или изображениям без контекста и сами по себе не имеют никакого значения. Данные становятся информацией, когда они обрабатываются в контексте.
Разведка — это целенаправленная информация. Использование данных и информации для предыдущий пример можно контекстуализировать следующим образом: Идентификационная карточка #PM764 принадлежит сотруднику по имени Пэт Смит, который вошел в здание 2 в 8:17 утра 17/01/2022. Продвигая эту концепцию еще на один шаг, вы можете преобразовать этот интеллект в знания, добавив перспективу, историю и более широкий глобальный контекст следующим образом: удостоверения личности сотрудников имеют встроенные коды, которые указывают на допуск владельца к безопасности, могут действовать как устройства слежения по периметру здания и могут препятствовать входу владельца в ограниченные базы данных выше их уровня допуска.
Знание находится за пределами возможностей сегодняшние вычислительные возможности, но могут быть включены путем предоставления соответствующих данных, информации и контекстуализированного интеллекта. Введение, история и объяснение перехода от данных к информации, к интеллекту и знаниям важны для понимания важности моделирования баз данных. Итак, как организовать, смоделировать и сохранить данные, чтобы они давали вам информацию, интеллект и знания? Для достижения этой цели был разработан ряд моделей баз данных. Четыре, которые будут описаны на следующих страницах, включают в себя: иерархический, сетевой, относительный и ассоциативный. Большая часть этой статьи будет посвящена последним двум.
Иерархическая и сетевая модель базы данных
Две из относительно хорошо известных моделей баз данных — это иерархическая и сетевая модели. Иерархические модели предполагают структуру данных, в которой элементы структуры имеют только отношения «один ко многим» друг с другом.
Реляционная модель базы данных
Одной из наиболее часто используемых структур базы данных является модель реляционной базы данных. Как следует из названия, модель реляционной базы данных имеет отношение в своей основе, но затем целый ряд правил, регулирующих ключи, отношения, объединения, функциональные зависимости, переходные зависимости, многозначные зависимости, Сравнение модели реляционной базы данных и ассоциативной модели базы данных.
Системы управления реляционными базами данных (СУБД) широко используются и имеют долгую историю. Признанный «отец» реляционной базы данных, E. F. Кодд, написал часто цитируемое введение к статье о реляционных база данных, пользователи больших банков данных должны быть защищены от необходимости знать, как данные организованы в машине (внутреннее представление). Учебники на заре истории баз данных рекламировали будущее СУБД. Кроенке отметил, что в то время как другие ранние модели баз данных имеют тенденцию усложнять, поскольку они заставляют пользователя формализовать свое представление о данных; реляционная модель имеет тенденцию к упрощению. Позже, когда использование СУБД стало более распространенным, сложность, связанная с проектированием СУБД, также была хорошо задокументирована. Джордан и Мачески идентифицируют два ключевые участники разработки базы данных, когда они заявляют, что системный аналитик все еще должен знать общие принципы проектирования баз данных, чтобы помочь администратору базы данных разработать высококачественную базу данных. Более поздние руководства по разработке баз данных с использованием конкретных пакетов баз данных содержат аналогичные предостережения и указания. Дьюсон подводит итог, говоря esign — это не та область, которую можно пропустить или отнестись к ней легкомысленно, и Рэнкинс и др. указывают, что esigning для повышения производительности требует компромиссов … для получения наилучшей производительности записи из база данных, вы должны пожертвовать производительностью чтения.
Нормализация является серьезной проблемой при проектировании СУБД. Кронке определяет нормализацию как процесс преобразования отношения, имеющего определенные проблемы, в два или более отношения, у которых этих проблем нет. Много написано о советах по нормализации базы данных, и многие авторы отмечают, что СУБД — это не лучший дизайн базы данных для всех типов данных. Даже в более поздних работах отца СУБД Кодда признается, что реляционная база данных лучше всего подходит для данных с довольно регулярным или однородная структура и что необходимы дополнительные исследования, чтобы определить, может ли СУБД в достаточной степени обрабатывать разнородные данные, такие как изображения, текст и разные факты. Возможно, другие модели баз данных больше подходят для таких разнородных данных.
Ассоциативная модель базы данных
Утверждается, что ассоциативная модель базы данных обладает преимуществами по сравнению с СУБД и другими моделями баз данных. В то время как СУБД и другие модели баз данных основаны на записях — данные хранятся в строках и столбцах в табличных представлениях – все данные в ассоциативной модели базы данных моделируются как дискретные независимые элементы данных. Отношения между элементами данных моделируются как ассоциации.
Гриффитс описывает эти две фундаментальные структуры данных как Элементы и набор ссылок, которые соединяют их вместе. Уильямс вводит ассоциативная модель базы данных как имеющая два типа структур данных, элементы, которые имеют уникальный идентификатор, имя и тип и ссылки, которые имеют уникальный идентификатор вместе с уникальными идентификаторами трех других объектов, которые представляют источник, глагол и цель факта, который записан источник в базе данных. Далее он отмечает, что каждая из трех вещей, идентифицируемых источником, глаголом и целью, может быть либо ссылкой, либо элементом. Вместо хранения или представления данных в табличной форме ассоциативные модели баз данных изображаются с Элементы данных в узлах со связями, представленными векторами или линиями со стрелками, соединяющими элементы. Ссылка содержит взаимосвязь или ассоциацию (также называемую векторами) между двумя связанными элементами.
Ассоциативные системы управления базами данных (СУБД) не очень хорошо известны и не имеют большой установленной базы пользователей. Однако за последние 12 лет два поставщика программного обеспечения предложили продукты СУБД. Компания Lazesoft, базирующаяся в Великобритании, предлагала продукт под названием Sentences™, пока компания не была закрыта в 2003 году. Relevance Canada, Inc. предлагает продукт под названием Relevance™, который, согласно литературе компании, успешно использовался в различных проектах.
В ряде неопубликованных статей кратко излагаются преимущества ассоциативной модели базы данных. Мьюир сравнивает две модели данных, отмечая, что структура базы данных, которая помогает СУБД превосходить СУБД на низком уровне, вредит ей на высоком уровне … ADBMS также более гибка для внесения изменений в приложение, СУБД на самом деле имеет больше смысла, независимо от размера приложения . Он также приводит следующее сравнение между реляционными и ассоциативными системами баз данных.
Айсола утверждает, что ADBMS является технологическим решением проблем, присущих хранению и управлению данными на основе таблиц. Отмечая, что ADBMS работает как мозг, Айсола указывает, что программное обеспечение, основанное на модели ADBMS, может хранить и находить все ассоциативно в основанной на концепции многомерной системе хранения информации и управления, которая может быть на 100% совместима с концептуальной моделью бизнеса, но работает независимо от пространства имен существующих наборов данных (имена, метки и значения являются атрибутами). Кроме того, он отмечает что ADBMS позволяет создавать хранилища данных без таблиц и что данные могут быть импортированы непосредственно из существующих баз данных в ассоциативную модель базы данных и исходный набор информации.
Как отмечалось ранее в этой статье, программное обеспечение, основанное на ассоциативной модели данных, не имело большого коммерческого успеха. Однако одним из аспектов ADBMS, который может сделать ее более привлекательной для будущих пользователей, являются присущие ей функции безопасности. Содержимое (данные) и индекс (ассоциации) могут храниться вместе или по отдельности в разных местах. Если бы хакер должен был получая доступ к тому или иному, Айсола отмечает, что не раскрывается ничего, кроме неограниченной символьной строки. В его статье утверждается, что для понимания того или иного вам нужен другой компонент плюс алгоритм, используемый для соединения двух. Отделение данных от ассоциаций с программным обеспечением в качестве третьего компонента создает ключ безопасности из трех частей, который обеспечивает высокий уровень безопасности.
Недавно крупная компания, занимающаяся базами данных, представила векторный продукт — по–видимому, основанный на ассоциативной модели данных. Кларк сообщает, что Ingres разработала способ для компаний быстрого поиска в базах данных, создав часть базы данных, обрабатывающую запросы, которая использует концепцию, известную как вектор запроса к базе данных были представлены следующим образом: Стандартная база данных Ingres: 16,5 секунды Вход по вектору: 0,206 секунды Написанное от руки программное обеспечение: 0,040 секунды.
В настоящее время разрабатывается еще один пример применения модели ADBMS с использованием данных, полученных от человека Проект «Геном». По словам Айсолы, огромный объем данных, собранных для генома человека Проект был импортирован в базу данных Relavance ™ и проходит анализ. Хотя подробности о проекте являются предварительными и не могут быть опубликованы, первоначальные результаты уже позволили получить представление о данных, которые не были выявлены при использовании традиционного программного обеспечения СУБД.
Заключение
Литература об ассоциативной модели базы данных ограничена. До недавнего анонса Ingres только два поставщика программного обеспечения предлагали коммерческие продукты для поддержки ADBMS. Мьюир и Айсола высоко оценивают достоинства ассоциативной модели данных и, в частности, продукта Relavance™. Предложения™ продукт больше не предлагается с тех пор, как Lazysoft распалась как компания. До распада Lazysoft Кинг и Rainwater написали исследовательскую работу, основанную в значительной степени на продукте Sentences™. Их оценка ADBMS не сильно отличается от оценки Muir и Айсола. Кинг и Рейнуотер приходят к выводу, что ассоциативная модель данных может быть реализована как многопользовательская веб-СУБД … и в то же время преодолевая несколько существенных ограничений реляционной модели. Наконец, эти авторы утверждают, что ассоциативная модель данных освобождает модель информационных технологий для непосредственного представления бизнес-процесса: разрыв между бизнес-моделью и реализацией базы данных был значительно сокращен. Представляется вероятным, что будущие потребности пользователей больших систем баз данных будут направьте их в сторону систем баз данных, основанных на ассоциативной модели данных. Последующие исследования и публикации должны быть сосредоточены на поддающихся количественной оценке достижениях и конкретных преимуществах, получаемых от использования программного обеспечения базы данных ADBMS.
Список источников
- Мосин С.В. Алгоритм использования кэша запросов к реляционной базе данных. Вестник СибГУТИ. 2017;(1):47-57.
- Тимофеева Н.Е., Дмитриева К.А. Сравнительный анализ реляционной и нереляционной модели хранения служебной информации централизованной распределенной базы данных // Вестник российского нового университета. Серия: сложные системы, модели, анализ и управление, 2019. № 1. C. 66-74.
- Королева Ю.А, Маслова В.О., Козлова В.К. Разработка концепции миграции данных между реляционными и нереляционными системами БД // Программные продукты и системы, 2019. № 1. C. 63-67.
- Hasan M. Performances analysis of NoSQL and relational databases for analyzing GeoJSON spatial data // Перспективы науки, 2019. № 7. C. 40-42.