Базы данных и системы управления базами данных: понятия, общие сведения, использование в эис

Стратегии работы с внешней памятью

СУБД с непосредственной записью

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

СУБД с отложенной записью

В таких СУБД изменения аккумулируются в буферах внешней памяти до наступления любого из следующих событий:

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

Такая стратегия позволяет избежать частого обмена с внешней памятью и значительно увеличить эффективность работы СУБД.

Теперь про базы

Получается, что БД — это совокупность данных, представленных определённым образом (в нашем случае — таблицей), и набор инструментов для манипулирования ими.

Данные могут быть сгруппированы не только в таблицы, но и в коллекции. У каждой базы есть свой инструмент для создания таблиц/коллекций, добавления, удаления или изменения данных, а также для составления выборки. В статье мы рассмотрим базы, которые состоят из таблиц, а инструментом манипулирования данными будет язык SQL.

Таблицы между собой могут объединяться в схемы — в одной базе данных их может быть несколько, а может и не быть деления на схемы вообще. Это зависит от БД.

Вернёмся к определению из Википедии и вспомним про слово «реляционные». Реляционные (от англ. relation — отношения) — это базы данных, таблицы которых могут выстраиваться в различных отношениях. Возьмём предыдущий пример и добавим в него тех самых «отношений». Создадим таблицу «Производитель», а ту, что в примере, обозначим как «Каталог».

Таблица «Производитель»:

Теперь таблицу «Каталог» можно оформить в другом виде:

Получилось так, что у таблиц «Каталог» и «Прозводитель» появились отношения. Значения из столбца «Каталог» ссылаются на строки из таблицы «Производитель». Добавлением отношения мы решили нескольких проблем:

  1. Избавились от избыточных данных. Каталог стал занимать меньше места. Вместо хранения целой строки мы используем только номер строки из таблицы «Производитель». 
  2. Снизили вероятность ошибиться. При смене названия производителя нам достаточно отредактировать строку в таблице «Производитель», «Каталог» останется без изменений. 

Это не все проблемы, которые мы решили добавлением отношений. Для понимания других проблем необходимо углубиться в тему баз данных. Разделение данных на таблицы с отношениями — это процесс нормализации. Так можно достигать различных нормализованных форм данных. При достижении каждой из нормализованных форм мы избавляем данные от дополнительных проблем. 

Современная СУБД состоит из:

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

Так как через СУБД осуществляют все процессы, применимые к базам данных, следовательно, лучше будет выделить только её основные возможности.

Какие бывают NoSQL-СУБД: основные типы нереляционных баз данных

Все NoSQL решения принято делить на 4 типа:

  1. Ключ-значение (Key-value) – наиболее простой вариант хранилища данных, использующий ключ для доступа к значению в рамках большой хэш-таблицы . Такие СУБД применяются для хранения изображений, создания специализированных файловых систем, в качестве кэшей для объектов, а также в масштабируемых Big Data системах, включая игровые и рекламные приложения, а также проекты интернета вещей (Internet of Things, IoT), в т.ч. индустриального (Industrial IoT, IIoT). Наиболее известными представителями нереляционных СУБД типа key-value считаются Oracle NoSQL Database, Berkeley DB, MemcacheDB, Redis, Riak, Amazon DynamoDB, которые поддерживают высокую разделяемость, обеспечивая беспрецедентное горизонтальное масштабирование, недостижимое при использовании других типов БД .
  2. Документно-ориентированное хранилище, в котором данные, представленные парами ключ-значение, сжимаются в виде полуструктурированного документа из тегированных элементов, подобно JSON, XML, BSON и другим подобным форматам . Такая модель хорошо подходит для каталогов, пользовательские профилей и систем управления контентом, где каждый документ уникален и изменяется со временем .  Поэтому чаще всего документные NoSQL-СУБД используются в CMS-системах, издательском деле и документальном поиске. Самые яркие примеры документно-ориентированных нереляционных баз данных – это CouchDB, Couchbase, MongoDB, eXist, Berkeley DB XML .
  3. Колоночное хранилище, которое хранит информацию в виде разреженной матрицы, строки и столбцы которой используются как ключи. В мире Big Data к колоночным хранилищам относятся базы типа «семейство столбцов» (Column Family). В таких системах сами значения хранятся в столбцах (колонках), представленных в отдельных файлах. Благодаря такой модели данных можно хранить большое количество атрибутов в сжатом виде, что ускоряет выполнение запросов к базе, особенно операции поиска и агрегации данных . Наличие временных меток (timestamp) позволяет использовать такие СУБД для организации счётчиков, регистрации и обработки событий, связанных со временем: системы биржевой аналитики, IoT/IIoT-приложения, систему управления содержимым и т.д. Самой известной колоночной базой данных является Google Big Table, а также основанные на ней Apache HBase и Cassandra. Также к этому типу относятся менее популярные ScyllaDB, Apache Accumulo и Hypertable .
  4. Графовое хранилище представляют собой сетевую базу, которая использует узлы и рёбра для отображения и хранения данных . Поскольку рёбра графа являются хранимыми, его обход не требует дополнительных вычислений (как соединение в SQL). При этом для нахождения начальной вершины обхода необходимы индексы. Обычно графовые СУБД поддерживают ACID-требования и специализированные языки запросов (Gremlin, Cypher, SPARQL, GraphQL и т.д.) . Такие СУБД используются в задачах, ориентированных на связи: социальные сети, выявление мошенничества, маршруты общественного транспорта, дорожные карты, сетевые топологии . Примеры графовых баз: InfoGrid, Neo4j, Amazon Neptune, OrientDB, AllegroGraph, Blazegraph, InfiniteGraph, FlockDB, Titan, ArangoDB.

Виды NoSQL-СУБД

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

Стандарт
сетевой модели впервые был определен в 1975 году организацией CODASYL (Conference
of Data System Languages), которая определила базовые понятия модели и формальный
язык описания.

Базовыми
объектами модели являются:

  • элемент данных;
  • агрегат данных;
  • запись;
  • набор данных,


Элемент данных

то же, что и в иерархической модели, то есть минимальная информационная
единица, доступная пользователю с использованием СУБД.


Агрегат данных

соответствует следующему уровню обобщения в модели. В модели определены
агрегаты двух типов: агрегат типа вектор и агрегат типа повторяющаяся группа.

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

Адрес

Город

Улица

дом

квартира

Агрегат типа
повторяющаяся группа соответствует совокупности векторов данных. Например, агрегат
Зарплата соответствует типу повторяющаяся группа с числом повторений 12.

Зарплата

Месяц

Сумма

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

Следующим
базовым понятием в сетевой модели является понятие «Набор».


Набор

это двухуровневый граф, связывающий отношением «один-ко-многим» два типа записи.

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

Для любых
двух типов записей может быть задано любое количество наборов, которые их связывают.
Фактически наличие подобных возможностей позволяет промоделировать отношение
«многие-ко-многим» между двумя объектами реального мира, что выгодно
отличает сетевую модель от иерархической. В рамках набора возможен последовательный
просмотр экземпляров членов набора, связанных с одним экземпляром владельца
набора.

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

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

Преподаватель

Группа

День недели

№ пары

Аудитория

Дисциплина

Иванов

4306

Понедельник

1

22-13

КИД

Иванов

4307

Понедельник

2

22-13

КИД

Карпова

4307

Вторник

2

22-14

БЗ и ЭС

Карпова

4309

Вторник

4

22-14

БЗ и ЭС

Карпова

84305

Вторник

1

22-14

БД

Смирнов

4306

Вторник

3

23-07

ГВП

Смирнов

4309

Вторник

4

23-07

ГВП

Экземпляров
набора Ведет занятия будет 3 (по числу преподавателей), экземпляром набора Занимается
у будет 4 (по числу групп). На рис. 3.6 представлены взаимосвязи экземпляров
данных наборов.

Рис.
3.6.
Пример взаимосвязи экземпляров двух наборов

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

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

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

История разработки

Реляционная база данных СУБД была изобретена в начале 1970-х Э. Ф. Коддом, молодым ученым-программистом IBM. В специальной статье по РБД он предложил перейти от хранения данных в иерархических структурах к организации их в таблицах, имеющих строки и столбцы.

К 1960-м годам собралось огромное количество данных, хранящихся на новых мэйнфрейм-компьютерах мира, многие из которых были компьютерами IBM System 360. Это стало проблемой для дальнейшего развития цифровых технологий. Расчеты на мэйнфреймах были дорогими, часто стоили сотни долларов в минуту. Существенной частью этих затрат была сложность, связанная с управлением базой данных (БД).

В 1973 году лаборатория Сан-Хосе, ныне Almaden, начала разрабатывать программу под названием System R (реляционый) с целью применить теорию отношений с помощью так называемой промышленной реализации. Это качество стало определяющим, чтобы определить, какие СУБД называются реляционными. В результате реализации этого проекта было изобретена новая революционная система хранения, ставшая основой успеха IBM.

Дон Чемберлин и Рэй Бойс изобрели SQL для структурированных данных, который сегодня наиболее широко применяются. Патриция Селингер разработала оптимизатор на основе затрат, делающий работу с реляционными БД более рентабельной и эффективной. А Раймон Лори изобрел компилятор, сохраняющий процедуры запросов к БД для будущего использования.

В 1983 году IBM представила второе семейство реляционных СУБД DB2 с целью управления данными. Сегодня DB2 по-прежнему производят миллиарды транзакций каждый день, являясь самым успешным программным продуктом IBM. По словам Арвинда Кришны, генерального менеджера IBM Information Management, DB2 продолжает оставаться лидером в области инновационного ПО для реляционных баз данных (РБД).

Доктор Кодд, известный своим коллегам как Тед, был удостоен звания стипендиата IBM в 1976 году, а в 1981 году Ассоциация вычислительной техники вручила ему премию Тьюринга за вклад, внесенный в разработку РБД.

Данные

Вокруг нас все­гда мно­го раз­ных дан­ных, например:

  • теле­фон­ные номера;
  • дела на день;
  • запи­си на бумаж­ках, сти­ке­рах и в блокнотах;
  • опуб­ли­ко­ван­ные мыс­ли раз­ных людей;
  • фото­гра­фии в смартфоне;
  • и всё осталь­ное, что мож­но про­чи­тать, уви­деть или услышать.

Если это ком­пью­тер­ная игра, то дан­ны­ми будут типы и место­по­ло­же­ния вра­гов, их уро­вень здо­ро­вья, уро­вень здо­ро­вья героя, тип героя, его поло­же­ние, харак­те­ри­сти­ки карты.

Если это при­ло­же­ние для рабо­ты с кли­ен­том, то там будут хра­нить­ся имя кли­ен­та, его зака­зы, номер теле­фо­на, уро­вень в про­грам­ме лояльности.

Если это служ­ба сле­же­ния за граж­да­на­ми — фото­гра­фия, имя, посе­щён­ные стан­ции мет­ро и ули­цы, место работы.

Конфигурация SQL ServerSQL Server configuration

СтатьяArticle ОписаниеDescription
Настройка брандмауэра Windows (SQL Server)Configure Windows Firewall (SQL Server) Общие сведения о конфигурации брандмауэра и настройке брандмауэра Windows для предоставления доступа к SQL Server.Overview of firewall configuration and how to configure the Windows firewall to allow access to SQL Server.
Настройка брандмауэра Windows (SSAS)Configure the Windows Firewall (SSAS) Настройте порт и брандмауэр, чтобы разрешить доступ к Службы Analysis ServicesAnalysis Services или Power PivotPower Pivot для SharePoint.Configure both port and firewall settings to allow access to Службы Analysis ServicesAnalysis Services or Power PivotPower Pivot for SharePoint.
Настройка многосетевого компьютераConfigure a Multi-Homed Computer Настройте SQL ServerSQL Server и брандмауэр Windows в режиме повышенной безопасности для предоставления сетевого подключения экземпляру SQL ServerSQL Server в многосетевой среде.Configure SQL ServerSQL Server and Windows Firewall with Advanced Security to provide for network connections to an instance of SQL ServerSQL Server in a multi-homed environment.

В чём преимущества

Базы дан­ных и их систе­мы управ­ле­ния зато­че­ны на рабо­ту с боль­шим объ­ё­мом дан­ных и от лица боль­шо­го чис­ла поль­зо­ва­те­лей. Сей­час вы поймёте.

Ско­рость — ещё одно пре­иму­ще­ство базы дан­ных. База дан­ных устро­е­на так, что она лег­ко и быст­ро нахо­дит, запи­сы­ва­ет, пере­пи­сы­ва­ет и сно­ва нахо­дит дан­ные. Всё пото­му, что СУБД все­гда зна­ет, что где лежит и по како­му кри­те­рию искать. Там не будет слу­чай­ных дан­ных в слу­чай­ном месте.

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

Слож­ность. Базы дан­ных нуж­ны в чис­ле про­че­го для хра­не­ния слож­но струк­ту­ри­ро­ван­ных дан­ных. Мы при­вык­ли думать, что база дан­ных — это такая таб­ли­ца, где есть стро­ки и столб­цы. Но база дан­ных при пра­виль­ной орга­ни­за­ции может намно­го больше:

  • Свя­зы­вать одну еди­ни­цу дан­ных с мно­же­ством дру­гих. Напри­мер, если один чело­век совер­шил мно­го зака­зов со мно­же­ством това­ров внут­ри каж­до­го, база дан­ных спо­соб­на хра­нить и обра­ба­ты­вать такие связи.
  • База может хра­нить дере­во дан­ных — вро­де того, о кото­ром мы писа­ли недав­но. Попро­буй в реаль­ной жиз­ни похра­нить дерево!
  • В базах могут жить ссыл­ки на дру­гие фраг­мен­ты и отде­лы базы.

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

Сравнение SQL и NoSQL

  1. Если SQL-системы основаны исключительно на строгом представлении данных, то NoSQL-системы предоставляют свободу и способны работать с любым типом данных.
  2. SQL-системы стандартизированы, за счёт чего запросы формируются с использованием языка SQL. В то же время NoSQL-системы базируются на специфической для каждой из них технологии, что является недостатком.
  3. Масштабируемость. Обе СУБД способны обеспечить вертикальное масштабирование, то есть увеличить объём системных ресурсов на обработку данных. При этом NoSQL, будучи более новой разновидностью баз данных, позволяет применять простые методы горизонтального масштабирования.
  4. В плане надёжности SQL обладает уверенным лидерством.
  5. У SQL-баз есть качественная техническая поддержка за счёт их продолжительной истории, в то время как NoSQL-системы весьма молоды и и решить какую-либо проблему сложнее.
  6. Хранение данных и доступ к их структурам в рамках реляционных систем лучше всего происходит в SQL-системах.

Таким образом, хоть NoSQL и является стремительно развивающейся разновидностью систем управления базами данных, однако на данном этапе рекомендуется остановить свой выбор на SQL.

Надёжность SQL-систем, особенно MySQL, подтверждается временем и массовостью. Сегодня любой уважающий себя ресурс использует для хранения данных именно систему MySQL.

@ivashkevich

04.04.2018 в 19:25

31565

+178

Состав СУБД

Обычно современная СУБД содержит следующие компоненты:

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

PostgreSQL

Наиболее продвинутая система управления базами данных, которая ориентируется на расширяемость и полное соответствие SQL-стандартам ANSI/ISO. Отличается от других систем объектно-ориентированным функционалом и полной поддержкой концепта ACID.

Система данных основана на мощной технологии Postgres, поэтому она хорошо справляется с обработкой нескольких заданий одновременно. Поддержка конкурентности реализована посредством MVCC, что тоже обеспечивает совместимость с ACID.

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

Поддерживаемые типы данных:

bigint: знаковое 8-байтное целое;
— boolean: булевская величина;
— bigserial: инкрементируемое (автоматически) 8-битное целое;
— box: прямоугольник на плоскости;
— bit : битовая строка (имеет фиксированную длину);
— bit varying : тоже битовая строка, но уже переменной длины;
— circle: круг на плоскости;
— bytea: бинарные данные;
— date: календарная дата;
— character varying : строка символов, имеющая фиксированную длину;
— character : аналогично, но переменной длины;
— integer: знаковое 4-байтное целое;
— cidr: сетевой адрес IPv6 либо IPv4;
— inet: адрес хоста IPv6 либо IPv4;
— macaddr: MAC-адрес;
— polygon: многоугольник на плоскости;
— line: бесконечная прямая на плоскости;
— lseg: отрезок на плоскости;
— xml: XML-данные;
— path: геометрический путь;
— money: денежная величина и прочие типы.

Достоинства:

— полная SQL-совместимость;
— поддержка опытным профессиональным сообществом;
— поддержка сторонними организациями;
— расширяемость (систему управления базами данных можно программно расширить, используя хранимые процедуры);
— объектная ориентированность (СУБД PostgreSQL является не только реляционной, но и объектно-ориентированной).

Минусы:

— в простых операциях чтения эта СУБД иногда уступает конкурентам;
— система данных довольна сложна, поэтому не очень популярна;
— сложно найти подходящего провайдера.

В каких случаях желательно использовать эту СУБД:

— когда в приоритете целостность и надёжность данных;
— когда база данных должна выполнять сложные процедуры;
— если в будущем планируется перенести базу данных на другой сервер, другое решение.

Есть и «противопоказания» применения PostgreSQL:
— если всё, что вам нужно — быстрые операции чтения, однозначно не стоит брать эту СУБД;
— когда повышенная надёжность, ACID и т. д. вам не требуются, то данная СУБД — это стрельба из пушки по воробьям.

Статья является свободным переводом отсюда, поэтому можете почитать её в оригинале.

Чем хороши и плохи нереляционные базы данных: главные достоинства и недостатки

По сравнению с классическими SQL-базами, нереляционные СУБД обладают следующими преимуществами:

  • линейная масштабируемость – добавление новых узлов в кластер увеличивает общую производительность системы ;
  • гибкость, позволяющая оперировать полуструктирированные данные, реализуя, в. т.ч. полнотекстовый поиск по базе ;
  • возможность работать с разными представлениями информации, в т.ч. без задания схемы данных ;
  • высокая доступность за счет репликации данных и других механизмов отказоустойчивости, в частности, шаринга – автоматического разделения данных по разным узлам сети, когда каждый сервер кластера отвечает только за определенный набор информации, обрабатывая запросы на его чтение и запись. Это увеличивает скорость обработки данных и пропускную способность приложения .
  • производительность за счет оптимизации для конкретных видов моделей данных (документной, графовой, колоночной или «ключ‑значение») и шаблонов доступа ;
  • широкие функциональные возможности – собственные SQL-подобные языки запросов, RESTful-интерфейсы, API и сложные типы данных, например, map, list и struct, позволяющие обрабатывать сразу множество значений .

Обратной стороной вышеуказанных достоинств являются следующие недостатки:

  • ограниченная емкость встроенного языка запросов . Например, HBase предоставляет всего 4 функции работы с данными (Put, Get, Scan, Delete), в Cassandra отсутствуют операции Insert и Join, несмотря на наличие SQL-подобного языка запросов. Для решения этой проблемы используются сторонние средства трансляции классических SQL-выражений в исполнительный код для конкретной нереляционной базы. Например, Apache Phoenix для HBase или универсальный Drill.
  • сложности в поддержке всех ACID-требований к транзакциям (атомарность, консистентность, изоляция, долговечность) из-за того, что NoSQL-СУБД вместо CAP-модели (согласованность, доступность, устойчивость к разделению) скорее соответствуют модели BASE (базовая доступность, гибкое состояние и итоговая согласованность) . Впрочем, некоторые нереляционные СУБД пытаются обойти это ограничение с помощью настраиваемых уровней согласованности, о чем мы рассказывали на примере Cassandra. Аналогичным образом Riak позволяет настраивать требуемые характеристики доступности-согласованности даже для отдельных запросов за счет задания количества узлов, необходимых для подтверждения успешного завершения транзакции . Подробнее о CAP-и BASE-моделях мы расскажем в отдельной статье.
  • сильная привязка приложения к конкретной СУБД из-за специфики внутреннего языка запросов и гибкой модели данных, ориентированной на конкретный случай ;
  • недостаток специалистов по NoSQL-базам по сравнению с реляционными аналогами .

Подводя итог описанию основных аспектов нереляционных СУБД, стоит отметить некоторую некорректность запроса «NoSQL vs SQL» в связи с разными архитектурными подходами и прикладными задачами, на которые ориентированы эти ИТ-средства. Традиционные SQL-базы отлично справляются с обработкой строго типизированной информации не слишком большого объема. Например, локальная ERP-система или облачная CRM. Однако, в случае обработки большого объема полуструктурированных и неструктурированных данных, т.е. Big Data, в распределенной системе следует выбирать из множества NoSQL-хранилищ, учитывая специфику самой задачи. В частности, для самостоятельных решений интернета вещей (Internet of Things), в т.ч. промышленного, отлично подходит Cassandra, о чем мы рассказывали здесь

А в случае многоуровневой ИТ-инфраструктуры на базе Apache Hadoop стоит обратить внимание на HBase, которая позволяет оперативно, практически в режиме реального времени, работать с данными, хранящимися в HDFS

Нереляционные СУБД находят больше областей приложений, чем традиционные SQL-решения

Источники

  1. https://ru.wikipedia.org/wiki/NoSQL
  2. https://aws.amazon.com/ru/nosql/
  3. https://ru.bmstu.wiki/NoSQL
  4. https://tproger.ru/translations/types-of-nosql-db/
  5. https://habr.com/ru/sandbox/113232/

Встраиваемые

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

MyISAM

MyISAM – является родным типом таблиц для базы СУБД MySQL. База данных в MySQL организуется как каталог. Таблицы базы данных организуются как файлы данного каталога. Каждая MyISAM таблица хранится на диске в трех файлах, имена которых совпадают с названием таблицы, а расширение может принимать одно из следующих значений:

  • Frm – содержит структуру таблицы, в файле данного типа хранится информация об именах и типах столбцов и индексов.
  • Myd – файл, в котором содержатся данные таблицы.
  • Myi – файл, котором содержатся индексы таблицы.

Особенности типа таблиц MyISAM:

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

MEMORY (HEAP)

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

Ограничения MEMORY таблиц:

  • Индексы используются только в операциях сравнения совместимо с операторами = и <=>, с другими операторами, такими как > или < индексирование столбцов не имеет смысла
  • Возможно использование только неуникальных индексов.
  • Можно использовать записи фиксированной длины, поэтому в них не допустимы столбцы типов TEXT и BLOD.
  • В версиях, предшествующих MySQL 4.0.2, не поддерживается индексирование столбцов, содержащих NULL-значения.

Виды баз данных и их структура, примеры

Выделяют несколько видов баз данных. Основными из них являются:

  1. Фактографическая, с краткой информацией об объектах какой-то системы, формат которой строго фиксирован.
  2. Документальная, включает документы разного вида, в том числе текстовые, графические, звуковые, мультимедийные.
  3. Распределенная, является базой данных с разными частями, которые хранятся на различных компьютерах, объединенных в сеть.
  4. Централизованная, представляет собой базу данных, местом хранения которой является один компьютер.
  5. Реляционная, имеет табличную организацию данных.
  6. Неструктурированная (NoSQL), является базой данных, в которой делается попытка решить проблемы масштабируемости и доступности с помощью атомарности и согласованности данных без четкой структуры.

Базы данных разных систем обладают неодинаковой структурой. Для ПЭВМ характерно использование реляционных баз данных с файлами в виде таблиц, в которых столбцы являются полями, а строки – записями. В базе данных находятся данные определенного множества объектов. Для каждой записи характерна информация по одному объекту. Такую базу определяют:

  • имя файла;
  • список полей;
  • ширина полей.

В качестве примера можно привести школьную базу с данными «Ученик», «Класс», «Адрес». Также базой данных является расписание движения поездов или автобусов. В этом случае каждой строке соответствует запись с данными конкретного объекта. Возможные поля: номер рейса, маршрут, время отправления и прибытия. Классической базой данных является телефонный справочник.

Определение

Запрос к базе данных – предписание с указанием на данные, которые необходимы пользователю.

Примечание

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

Существует три звена для создания приложения, с помощью которого можно просматривать и редактировать базы данных:

  • набор данных;
  • источник информации;
  • визуальные компоненты управления.

В случае Access роль таких звеньев выполняют:

  1. Table.
  2. DataSource.
  3. DBGrid.

Приложения базы данных является нитью, которая связывает базу и пользователя:

БД => набор данных –=> источник данных => визуальные компоненты => пользователь

Набор данных:

  • Table, в виде таблицы, навигационного доступа;
  • Query, включая запрос, реляционный доступ.

Визуальными компонентами являются:

  1. Сетки DBGrid, DBCtrlGrid.
  2. Навигатор DBNavigator.
  3. Разные аналоги Lable, Edit.
  4. Компоненты подстановки.

Access характеризуется наличием следующих типов полей:

  • текстовый, в виде текстовой строки с максимальной длиной до 255, заданной параметром «размер»;
  • поле МЕМО, является текстом длиной до 65535 символов;
  • числовой, в параметре «Размер поля» можно задать поле: байт, целое, действительное и другие;
  • дата/время, необходимо для записи данных о времени;
  • денежный, является специальным форматом для решения финансовых задач;
  • счетчик, в виде автоинкрементного поля, который предназначен для ключевого поля, увеличивается на единицу после добавления новой записи и сохраняется в данное поле новой записи, что гарантирует разные значения для неодинаковых записей;
  • логический, в виде «да или нет», «правда или ложь», «включен или выключен»;
  • объект OLE, предназначен для хранения документов, картинок, звуков и другой информации, представляет собой частный случай BLOB, то есть полей (Binary Large Object), которые можно встретить в разных базах данных;
  • гиперссылка, необходима для хранения ссылок на ресурсы в Интернете, характерна не для всех форматов баз данных, например, отсутствует в dBase и Paradox;
  • подстановка.

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

Реляционная база данных

Под данным типом баз данных понимается их представление в рамках двумерной таблицы. Она имеет несколько столбцов, в которых устанавливаются такие параметры, как, например, тип вводимых данных (текст, число, дата и др.).

Таблица здесь является способом хранения введённых в неё данных и способна реагировать на любые обращения со стороны СУБД. Главная проблема в работе с реляционными базами данных состоит в их правильном проектировании.

Во время проектирования базы данных следует учесть следующие два фактора:

  1. база данных должна быть компактной и не содержать избыточных компонентов;
  2. обработка базы данных должны происходить просто.

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

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

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

Данные

В контексте баз данных под данными понимают набор значений, который собирается в строки и столбцы, тем самым представляя таблицу. Представим, что у нас есть каталог мебельного магазина. Нам нужно сохранить все данные из раздела «Шкафы» этого каталога в таблицу. Мы решили, что все шкафы отличаются друг от друга характеристиками:

  • название производителя;
  • название модели;
  • высота;
  • длина;
  • цвет;
  • количество дверей.

Составим таблицу и вобьём в неё выдуманные данные.

У нас есть таблица с данными. Столбцами мы показываем, как они будут храниться. В примере я указал, что мы будем хранить информацию в структуре: производитель, модель, высота, длина, цвет, количество дверей. Иными словами, я создал структуру таблицы.

Добавляя в таблицу строки, я вводил в неё данные, ориентируясь на структуру, заданную в столбцах. Чем больше строк, тем больше данных. Чем больше столбцов, тем подробнее будут эти данные.

Ещё есть такое понятие, как «значение» — это пересечение столбца и строки. Например, у последней строки в столбце «Цвет» написано «хаки». Здесь «хаки» — значение. Если мы начнём группировать таблицы и добавим возможность манипулирования ими, то получим базу данных.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector