Сетевая модель данных

История

Сетевая модель была одним из первых подходов, использовавшимся при создании баз данных в конце 50-х — начале 60-х годов. Активным пропагандистом этой модели был Чарльз Бахман. Идеи Бахмана послужили основой для разработки стандартной сетевой модели под эгидой организации CODASYL. После публикации отчетов рабочей группы этой организации в 1969, 1971 и 1973 годах многие компании привели свои сетевые базы данных более-менее в соответствие со стандартами CODASYL. До середины 70-х годов главным конкурентом сетевых баз данных была иерархическая модель данных, представленная ведущим продуктом компании IBM в области баз данных — IBM IMS.

В конце 60-х годов Эдгаром Коддом была предложена реляционная модель данных и после долгих и упорных споров с Бахманом реляционная модель приобрела большую популярность и теперь является доминирующей на рынке СУБД.

2018: Рост рынка на 18,4% до $46 млрд — Gartner

В 2018 году объём мирового рынка систем управления базами данных (СУБД) достиг $46 млрд, увеличившись на 18,4% относительно 2017-го во многом благодаря облачным проектам. Такие данные в конце июня 2019 года обнародовали в аналитической компании Gartner.

По оценкам экспертов, основной вклад (около 68%) в этот подъём внесли облачные решения, а среди производителей отличились компании Microsoft и Amazon Web Services (AWS), на которые пришлось 75,5% роста рынка.


Исследование показало усиливающуюся тенденцию перехода СУБД в облачную среду. Ожидается, что к 2022 году примерно 75% систем будут развёрнуты или перенесены на облачную платформу, и лишь 5% решений мигрируют в обратную сторону — из облака в локальную инфраструктуру.

Такой тренд специалисты связывают с увеличивающейся популярностью бизнес-модели SaaS (программное обеспечение как услуга), а также практической значимостью использования СУБД для аналитических задач. В Gartner говорят, что клиенты внедряют новые приложения и переводят существующие ресурсы в облако с экспоненциально растущей скоростью.

Компании всё чаще задействуют облачные сервисы для задач, связанных с аналитикой, машинным обучением, искусственным интеллектом, озером данных и хранением информацией.

По словам аналитиков, в некоторых случаях облачные сервисы могут оказаться дороже традиционного программного обеспечения, однако первые предоставляют следующие неоспоримые преимущества: устранение необходимости в управлении инфраструктурой и возможность более лёгкого масштабирования процессов. Кроме того, чаще всего облако безопаснее, добавляют в Gartner.

Хотя в 2018 году расходы на локальные СУБД от Oracle, Microsoft, IBM и других вендоров увеличивались, положительная динамика достигалась не за счёт новых внедрений, а благодаря принудительному обновлению софта. Компании вынуждены ставить новые версии и дополнения к продуктам во избежание рисков, отмечают исследователи.

Большинство новых СУБД-проектов запускаются в облаке. В этих условиях поставщики инфраструктуры для облачных сервисов и услуг, которые оказываются на её основе, становятся новой платформой для управления данными.

Аналитик Gartner Адам Ронталь (Adam Ronthal) говорит, что практически все инновации на рынке систем управления базами данных развиваются в облаке. Поэтому любой, кто хочет воспользоваться преимуществами последних разработок, должен присутствовать в этой среде.

Они появляются только в облаке или по крайней мере в первую очередь там. Все больше становится нововведений, которых никогда не будет в локальной среде, даже если у производителя есть локальные продукты, — считает Ронталь.

Поставщики облачных услуг формируют вокруг себя экосистемы, предлагая не только сами сервисы, но и возможности для организации взаимодействия между ними и с конкурирующими продуктами.

В категории локальных СУБД подход другой: здесь отдельные продукты зачастую выполняют несколько задач, но редко предлагают встроенные механизмы для интеграции с другим ПО в локальной среде.

Все это говорит о том, что гарантировано доминирующее положение инфраструктуры облачных провайдеров, их собственных предложений и сторонних решений, работающих на их основе, — подчеркнул вице-президент по исследованиям Gartner Дональд Фейнберг (Donald Feinberg).

В конце июня 2019 года Gartner обнародовала результаты опроса, которые показали, что 81% компаний, пользующихся публичными облачными сервисами, выбирают не менее одного поставщика.

Литература

  • А. Филимонов. Построение мультисервисных сетей Ethernet. — М.: BHV, 2007. ISBN 978-5-9775-0007-4.
  • Руководство по технологиям объединённых сетей. 4-е изд. — М.: Вильямс, 2005. ISBN 5-8459-0787-X.
  • Интернет ресурс: сервер :
    • Этот сервер, содержащий сведения по сетевым технологиям начал формироваться в 1997 году. Он частично создан на средства, выделенные по проектам РФФИ (99-07-90102 и 01-07-90069).
    • В основу материалов легли тексты книг:
      • «Протоколы и ресурсы Интернет» (Радио и связь, М. 1996),
      • «Сети Интернет. Архитектура и протоколы» (Сиринъ, М. 1998),
      • «Протоколы Интернет. Энциклопедия» («Горячая линия — Телеком», М. 2001, 1100 стр.),
      • «Протоколы Internet для электронной торговли» («Горячая линия — Телеком», М. 2003, 730 стр.),

которые базировались на двух курсах, читаемых студентам[значимость факта?] кафедр «Телекоммуникационные сети и системы» (факультет МФТИ ФРТК), «Интеграции и менеджмента» (факультет МФТИ ФОПФ) и «Информатики» (факультет НаноБиоИнфоКогни МФТИ) — «Каналы и сети передачи данных», «Протоколы Интернет».

Состав частей реляционной модели данных

Наиболее распространенная трактовка реляционной модели данных, принадлежит Дейту, который воспроизводит ее (с различными уточнениями) практически во всех своих книгах. Согласно Дейту реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части.

Структурная часть


Структурная часть (аспект), отвечает за принцип построения структуры реляционной базы данных на нормализированном наборе n-арных отношений, в форме таблиц

Важно что реляционная база данных, структурно может представляться только в виде отношений

Манипуляционная часть

В манипуляционной части модели утверждаются операторы манипулирования отношениями — реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями), а второй — на классическом логическом аппарате исчисления предикатов первого порядка. Основной функцией манипуляционной части реляционной модели является обеспечение меры реляционности любого конкретного языка реляционных БД: язык называется реляционным, если он обладает не меньшей выразительностью и мощностью, чем реляционная алгебра или реляционное исчисление.

Целостная часть

В целостной части реляционной модели данных фиксируются два базовых требования целостности, которые должны поддерживаться в любой реляционной СУБД. Первое требование называется требованием целостности сущностей. Объекту или сущности реального мира в реляционных БД соответствуют кортежи отношений. Конкретно требование состоит в том, что любой кортеж любого отношения отличим от любого другого кортежа этого отношения, т.е. другими словами, любое отношение должно обладать первичным ключом. Как мы видели в предыдущем разделе, это требование автоматически удовлетворяется, если в системе не нарушаются базовые свойства отношений.

Второе требование называется требованием целостности по ссылкам и является несколько более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений. Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении, на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать).

Преимущества

  1. Стандартизация. Появление стандарта CODASYL, который определил базовые понятия модели и формальный язык описания.
  2. Быстродействие. Быстродействие сетевых баз данных сравнимо с быстродействием иерархических баз данных.
  3. Гибкость. Множественные отношения предок/потомок позволяют сетевой базе данных хранить данные, структура которых была сложнее простой иерархии.
  4. Универсальность. Выразительные возможности сетевой модели данных являются наиболее обширными в сравнении с остальными моделями.
  5. Возможность доступа к данным через значения нескольких отношений (например, через любые основные отношения).

Основные элементы сетевой модели данных

  • Элемент данных – минимальная информационная единица доступная пользователю.
  • Агрегат данных – именованная совокупность элементов данных внутри записи или другого агрегата, которую можно рассматривать как единое целое. Имя агрегата используется для его идентификации в схеме структуры данного более высокого уровня. Агрегат данных может быть простым, если состоит только из элементов данных, и составным, если включает в свой состав другие агрегаты.
  • Запись — совокупность агрегатов или элементов данных, отражающих некоторую сущность предметной области. Иными словами, запись — это агрегат, который не входит в состав никакого другого агрегата и может иметь сложную иерархическую структуру, поскольку допускается многократное применение агрегации. Имя записи используется для идентификации типа записи в схемах типов структур более высокого уровня.
  • Тип записей – эта совокупность подобных записей. Тип записей представляет некоторый класс реального мира.
  • Набор — именованная двухуровневая иерархическая структура, которая содержит запись владельца и запись (или записи) членов. Наборы отражают связи «один ко многим» и «один к одному» между двумя типами записей.
Наборы бывают нескольких видов:
  • С одними и теми же типами записей, но разными типами наборов.
  • Наборы из трех записей и более, в том числе с обратной связью.
  • Сингулярный набор (только один экземпляр). У такого набора нет естественного владельца и в качестве него выступает система. В дальнейшем такие наборы могут приобрести запись — владельца.

Основные понятия используемые в сетевой модели данных

Элемент данных – минимальная информационная единица доступная пользователю.

Агрегат данных – это именованная совокупность данных внутри одной записи. Имя агрегата используется для его идентификации в схеме структуры данного более высокого уровня. Агрегат данных может быть простым, если состоит только из элементов данных, и составным, если включает в свой состав другие агрегаты.

Запись — это конечный уровень обобщения данных. Иными словами, запись — это агрегат, который не входит в состав никакого другого агрегата и может иметь сложную иерархическую структуру, поскольку допускается многократное применение агрегации. Имя записи используется для идентификации типа записи в схемах типов структур более высокого уровня.

Тип записей – это совокупность логически связанных экземпляров записей. Тип записей представляет некоторый класс реального мира.

Набор — именованная двухуровневая иерархическая структура, которая содержит запись владельца и запись (или записи) членов. Наборы отражают связи «один ко многим» и «один к одному» между двумя типами записей.

Общее определение термина пакет

Для описания фрагментов информации, передаваемых по сети, применяются термины: пакет, дейтаграмма, фрейм, сообщение и сегмент. Все они по сути имеют один и тот же смысл, но относятся к разным уровням модели OSI. Например, пакет можно рассматривать как конверт с письмом. Чтобы отправить этот конверт по почте, необходимо выполнить ряд требований (рис.1), которые перечислены ниже.

  • Подготовить почтовое вложение. Эта составляющая почтового отправления представляет собой письмо, например, с фотографией новорожденного сына, отправляемой дяде Джо.
  • Написать на конверте адрес отправителя. Эта составляющая служит в качестве обратного адреса, который должен быть написан на стандартном конверте. Адрес указывает, от которого поступило сообщение, и необходим даже просто на тот случай, если возникнут проблемы с доставкой письма.
  • Написать на конверте адрес получателя. Эта составляющая представляет собой адрес дяди Джо, без которого письмо невозможно доставить намеченному получателю.
  • Пройти через систему проверки. Эта составляющая представляет собой штемпель на почтовой марке. Он подтверждает, что письмо отправлено с соблюдением всех требований и соответствует стандартам почтовой службы.

Рис.1. Обязательные составляющие обычного письма.

Передача сетевого пакета фактически происходит по таким же принципам, как и отправка обычного письма. Рассмотрим в качестве примера сообщение электронной почты, которое показано на рис.2. Для его доставки адресату необходимо такая же информация, как и для обычного письма (а также некоторые другие компоненты, которые рассматриваются в данной главе). эта информация описана ниже.

  • Почтовое вложение. Этот компонент представляет собой передаваемые данные, допустим, электронное письмо дяде Джо с сообщением о рождении сына.
  • Адрес отправителя. Этот компонент служит в качестве обратного адреса для электронного письма. Он позволяет узнать от кого поступило сообщение, даже просто на тот случай, если возникнет проблема при доставке электронной почты.
  • Адрес получателя. Этот компонент представляет собой адрес электронной почты дяди Джо и необходим для правильной доставки электронной почты.
  • Информация для системы проверки. Если речь идет о пакете, то этот компонент представляет собой определенную информацию для системы контроля ошибок. В данном случае применяется контрольная последовательность фрейма (Frame Check Sequence — FCS). Такую последовательность можно рассматривать как результат вычислений, выполненных над содержимым пакета с помощью некоторой математической формулы. Если вычисления FCS в пункте назначения {на компьютере дяди Джо) дадут правильный результат, это будет означать, что данные в пакете являются действительными и должны быть приняты. А если результаты вычислений окажутся неправильными, сообщение будет отброшено.

Рис.2. Основные компоненты пакете.

Далее понятие пакета применяется для иллюстрации процесса прохождения данных сверху вниз по уровням модели OSI, затем по физическому кабелю, а после этого снизу вверх по уровням модели OSI. Пока они не поступят в виде нового сообщения во входной почтовый ящик дяди Джо.

Другие сетевые модели

Важное значение с точки зрения организации сетей имеет также модель DoD (Department of Defense — Министерство обороны США), так как в основе протоколов TCP/IP лежит не модель OSI, а именно эта модель. Поскольку модель DoD во многом совпадает с моделью OSI, тот факт, что она является фундаментом протоколов TCP/IP, может привести к некоторой путанице при изучении модели OSI

Верхние уровни модели DoD не совпадают с верхними уровнями модели OSI, поэтому в разных книгах можно встретить различные описания порядка расположения протоколов в модели OSI. Но здесь необходимо прежде всего учитывать, что фактически знание того, где должен быть указанный протокол модели OSI, необходимо в основном для успешной сдачи экзаменов; а на практике важнее всего понимание назначения каждого уровня модели.

Модели DoD и OSI

Модели OSI и DoD позволяют наглядно представить процесс сетевого взаимодействия, а компания Cisco применяет в своей работе иерархическую межсетевую модель, которая представляет собой многоуровневое отображение топологического проекта объединенной сети. Эта модель разработана в целях максимального повышения производительности; в то же время она обеспечивает оптимальную отказоустойчивость. Применение этой модели позволяет упростить конструкцию сети путем распределения функций по уровням сетевого проекта. Очевидным недостатком данной модели в сетях небольших и средних размеров является высокая стоимость проекта, но если задача состоит в создании высокопроизводительной, масштабируемой, резервируемой объединенной сети, то применение такого подхода является одним из наилучших способов реализации в проекте поставленных целей.

Иерархическая межсетевая модель Cisco состоит из трех уровней:

  1. Уровень ядра сети. Этот уровень объединенной сети соответствует опорной сети. Поскольку опорная сеть играет такую важную роль, любые серьезные нарушения в ее работе скорее всего будут заметны для всех, кто использует эту объединенную сеть. Кроме того, поскольку скорость здесь играет очень важную роль (в связи с огромным объемом трафика, который проходит по опорной сети), на этом уровне практически не должны быть реализованы функции, требующие значительных ресурсов маршрутизации или коммутации. Иными словами, маршрутизация, обработка списков доступа, сжатие, шифрование и все прочие функции, требующие больших затрат ресурсов, должны быть выполнены до того, как пакет поступит в ядро сети.
  2. Распределительный уровень. Этот уровень занимает промежуточное положение между уровнем ядра сети и уровнем доступа. Клиенты не взаимодействуют непосредственно с этим уровнем, но на нем выполняется основная часть функций обработки передаваемых ими пакетов. На этом уровне выполняется также основная часть вспомогательных функций. В частности, на нем функционируют службы маршрутизации, обеспечения качества обслуживания (Quality of Service — QоS), проверки списков доступа, шифрования, сжатия и трансляции сетевых адресов (Network Address Translation — NAT).
  3. Уровень доступа. На этом уровне пользователям предоставляется доступ к локальным сегментам. Характерной особенностью уровня доступа является применение соединений локальной сети, обычно в сетевой среде небольшого масштаба (такой как отдельное здание). Иными словами, именно на этом уровне происходит подключение клиентов к сети. Обычно на уровне доступа выполняется коммутация Ethernet и другие основные функции.

Пример практического применения этой модели приведен на рис.10.


Рис.10. Иерархическая межсетевая модель Cisco.

Использования сетевой модели

Сетевые модели также создавались для мало ресурсных ЭВМ. Это достаточно сложные структуры, состоящие из «наборов» – поименованных двухуровневых деревьев. «Наборы» соединяются с помощью «записей-связок», образуя цепочки и т.д. При разработке сетевых моделей было выдумано множество «маленьких хитростей», позволяющих увеличить производительность СУБД, но существенно усложнивших последние. Прикладной программист должен знать массу терминов, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п. Один из разработчиков операционной системы UNIX сказал «Сетевая база – это самый верный способ потерять данные».

СУБД, поддерживающие сетевую модель, широко использовались на вычислительных системах серии IBM 360/370 (ЕС ЭВМ). В качестве примеров таких систем можно указать IDMS, UNIBAD (БАНК), аналоги СЕДАН, СЕТОР. На персональных компьютерах сетевые СУБД не получили широкого распространения. Примером сетевой СУБД для персонального компьютера является db_VISTA III. Отметим, что система db_VISTA реализована на языке С и поэтому является переносимой. Система может эксплуатироваться на ПЭВМ типа IBM PC, SUN, Macintosh.


С этим читают