Про перевод database: какие бывают, что с ними делают и с чем их едят

Системы управления базами данных

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

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

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

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

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

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

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

Вас заинтересует / Intresting for you:

База данных как объект правово… 535 просмотров Денис Wed, 27 Mar 2019, 03:16:24

Перенос корпоративных баз данн… 837 просмотров Дэн Fri, 27 Sep 2019, 07:52:18

Что такое SQL? Плюсы и минусы … 3586 просмотров Андрей Васенин Tue, 21 Nov 2017, 13:17:28

База данных и СУБД: основные п… 8169 просмотров Дэйзи ак-Макарова Fri, 24 Nov 2017, 05:30:03

Author: Светлана

Другие статьи автора:

2.2.3 Многоярусные базы данных

Это новый и многообещающий путь обработки данных в сети. Иногда этот способ организации баз данных называется multi-tier — многонитевые. В этом термине под нитью понимается один из множества потоков данных, обменивающихся одновременно с базой данных.

Наиболее распространен трехярусный вариант:

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

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

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

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

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

Многоярусная организация — наиболее сложный, гибкий и эффективный способ работы с базами данных. При этом надо отметить, что на нижнем уровне — на компьютерах пользователя не требуется установки Borland Database Engine (BDE). В этом заключается одно из преимуществ многоярусных распределенных баз данных.

Ключи в БД

Первичный ключ (РК, primary key) — столбец, значения которого различны во всех строках. РК бывают логические (естественные) и суррогатные (искусственные).

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

Вносим первичные ключи в наши таблицы:

Заметьте, что каждая запись в таблице уникальна. Осталось лишь установить соответствие между сообщениями и темами, используя первичные ключи. Добавляем в таблицу с сообщениями ещё одно поле:

Теперь становится ясно, что сообщение id=2 относится к теме «О рыбалке» (id=4), которая создана Васей, а остальные принадлежат теме «О рыбалке», созданной Кириллом (id=1). Такое поле будет называться внешний ключ (FK, foreign key). При этом каждое значение данного поля сопоставляется с каким-либо первичным ключом из таблицы «Темы». В результате устанавливается однозначное соответствие между темами и сообщениями.

Ещё момент: допустим, добавляется новый пользователь по имени Вася.

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

Итак, наша база данных фактически готова. Схематично она выглядит так:

В этой небольшой базе данных лишь 3 таблицы. А что делать, если их 10 либо 200? Ясно, что всё не так просто. Именно поэтому любое проектирование реляционных баз данных начинается с разработки концептуальной модели данных.

Системы распределенной обработки информации

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

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

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

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

Для чего нужны

Вот основ­ные зада­чи БД на при­ме­ре гардеробной:

• Сохра­нить наши дан­ные по запро­су — что­бы вы мог­ли открыть дверь, пове­сить курт­ку, закрыть дверь и боль­ше не думать ни о курт­ке, ни о гардеробной.
• Изме­нить наши дан­ные по запро­су — что­бы мож­но было лег­ко извлечь из гар­де­роб­ной все дыря­вые нос­ки и поло­жить на их место целые.
• Най­ти эти дан­ные по запро­су — что­бы быст­ро най­ти при­лич­ный пиджак или пар­ный носок.
• Не дать про­чи­тать эти дан­ные тем, кому не сле­ду­ет, а кому надо — дать. Напри­мер, млад­ший брат может смот­реть на ваши крос­сов­ки, но не может их брать. А девуш­ка (или парень) может поло­жить свои вещи, но толь­ко на опре­де­лён­ную полку.
• Под­дер­жи­вать поря­док и не дать захла­мить­ся — если вам было лень и вы про­сто кину­ли тол­стов­ку куда попа­ло, что­бы гар­де­роб­ная либо сама нашла, куда эту тол­стов­ку пра­виль­но поло­жить, либо ска­за­ла: «Э БРАТ ЗАЧЕМ ЗАХЛАМЛЯЕШЬ ПОЛОЖИ НОРМАЛЬНО ДАВАЙ»
• Мас­шта­би­ро­вать­ся — что­бы вы мог­ли про­сто вешать в гар­де­роб­ную вещи и не думать об объ­ё­ме полок.
• Не поте­рять дан­ные — если квар­ти­ра будет гореть, при­лич­ная гар­де­роб­ная не долж­на даже нагреть­ся. Или, если она всё-таки горит, что­бы где-то в защи­щён­ном под­зем­ном гара­же была точ­ная копия этой гар­де­роб­ной со все­ми акту­аль­ны­ми вещами.

Понятие БД и классификация БД

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

Безопасность данных также приобретает все большее значение, в электронных БД хранятся и шифруются пароли, личные данные и даже электронные валюты.

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

В зависимости от изменчивости базы данных ее тип относят по классификации БД к статическому или динамическому.

Функции статических БД:

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

Функции динамических БД:

1. Они обладают понятием самоуправления.
2. Могут быть связаны с динамическими сетями.
3. Эта структурная ассоциация позволяет хранить и обновлять информацию базы данных.
4. Использует HTML в качестве языка связи между сетью и динамической БД.
5. Наиболее используемые языки для создания динамических сетей, связанных с BBDD: Perl, CGI, PHP, JSP и ASP.

Основными СУБД, которые работают с динамическими веб-страницами, являются PostgresQL, MySQL, Oracle и Microsoft SQL.

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

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

Функциональные возможности библиографических БД:

1. Связаны со старыми записями, которые содержат информацию о местонахождении книги или документа.
2. Не содержат полный текст, только ссылку.
3. Благодаря таким форматам, как PDF, позволяет получать доступ к оригинальным статьям, на которые есть ссылки.
4. С развитием технологий включаются ссылки из других СМИ.

Особенности специализированных БД:

1. Содержат точную информацию и ориентированы на конкретную тему.
2. Используются в академической и научной среде.
3. Для некоторых случаев не рассматриваются как правильные BBDD: например, телефонный справочник, список контактов компании или международной компании.

Классификация СУБД

По модели данных

По типу управляемой базы данных СУБД разделяются на:

§  Иерархические (система FAT, Серверы каталогов)

§  Сетевые (интернет)

§  Реляционные (MS Access)

§  Объектно-реляционные ( Oracle Database, Microsoft SQL Server 2005, PostgreSQL)

По архитектуре организации хранения данных

§  локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

§  распределенные СУБД (части СУБД могут размещаться на двух и более компьютерах)

По способу доступа к БД

§  Файл-серверные

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

На данный момент файл-серверные СУБД считаются устаревшими.

Примеры: Microsoft Access (Microsoft Access — реляционная СУБД корпорации Microsoft. Имеет широкий спектр функций, включая связанные запросы, сортировку по разным полям, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных. Основные компоненты MS Access:просмотр таблиц; построитель экранных форм; построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI); построитель отчётов, выводимых на печать.), Borland Paradox.

§  Клиент-серверные

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

Примеры: Firebird, Interbase, MS SQL Server, Sybase, Oracle, PostgreSQL, MySQL, ЛИНТЕР.

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

Примеры: OpenEdge, SQLite, BerkeleyDB, один из вариантов Firebird, один из вариантов MySQL, Sav Zigzag, Microsoft SQL Server Compact, ЛИНТЕР.

6. Виды нормализации (1-3-нормальная форма).

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

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

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

Всего в реляционной теории насчитывается 6 НФ:

1.  1-я НФ (обычно обозначается также 1НФ).

2.  2НФ.

3.  3НФ.

4.  НФ Бойса-Кодда (НФБК).

5.  4НФ.

6.  5НФ.

1НФ

Таблица находится в первой нормальной форме, если каждый её атрибут атомарен. Под выражением «атрибут атомарен» понимается, что атрибут может содержать только одно значение. Таким образом, не существует 1NF таблицы, в полях которых могут храниться списки значений. Для приведения таблицы к 1NF обычно требуется разбить таблицу на несколько отдельных таблиц.

Замечание: в реляционной модели отношение всегда находится в 1 (или более высокой) нормальной форме в том смысле, что иные отношения не рассматриваются в реляционной модели. То есть само определение понятия отношение заведомо подразумевает наличие 1NF.

Проектирование баз данных

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

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

Реляционная структура данных

В конце 60-х годов появились работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э. Кодда (Codd E.F., A Relational Model ofData for LargeShared Data Banks. CACM 13:6, June 1970), где, вероятно, впервые был применен термин «реляционная модель данных».

Будучи математиком по образованию, Э. Кодд предложил использовать для обработкиданных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике какотношение – relation (англ.).

Наименьшая единица данных реляционной модели – это отдельное атомарное (неразложимое) для данной модели значение данных. Так, в одной предметной области фамилия, имя и отчество могут рассматриваться как единое значение, а в другой – как три различных значения.

Доменом называется множество атомарных значений одного и того же типа. Отношение на доменах D1, D2, …, Dn (не обязательно, чтобы все они были различны) состоит из заголовка и тела. На рис. 2.6 приведен пример отношения для расписания движения самолетов.

Заголовок (интерпретация) состоит из такого фиксированного множества атрибутов A1, A2, …, An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,…,n).

Рис. 2.6. Отношение с математической точки зрения (Ai — атрибуты, Vi — значения атрибутов)

Тело состоит из меняющегося во времени множества кортежей, где каждый кор теж со стоит в свою очер едь из множества пар атрибут-значение (Ai:Vi), (i=1,2,…,n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.

Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, …, а степени n – n-арным.

Кардинальное число или мощность отношения – это число его кортежей. Кардинальное число отношения изменяется во времени в отличие от его степени.

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

Мир объектов, систем и решений

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

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

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

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

Основные типы данных СУБД

Изначально применение СУБД ограничивалось преимущественно решением финансово-экономических задач.

Независимо от модели представления, базы данных обрабатывали такие основные типы данных:

• числовые – наиболее используемыми являются целочисленные, вещественные и денежные (финансовые);
• символьные, например, значения данных «четверг», «столбец», «менеджер»;
• логические, которые принимают значения «истина» или «ложь»;
• даты, которые задаются с помощью типа «Дата» или в виде обычных символьных данных.

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

К таким типам данных относились:

• время и дата/время, которые были предназначены для хранения информации о времени и/или дате;
• символьные переменной длины, которые хранили текстовую информацию большой длины (например, документ);
• двоичные для хранения графических, аудио- и видеообъектов, хронологической, пространственной и другой специальной информации. Такие данные часто называются мультимедиа-данными. Например, в MS Access тип данных «Поле объекта OLE» позволяет хранить в базе данных графические данные в формате BMP и отображать их автоматически при работе с базой;
• гиперссылки, которые предназначены для хранения ссылок на разные ресурсы (документы, файлы, узлы и т. д.), не принадлежащие базе данных, например, находящиеся в сети Интернет, корпоративной сети Интранет или на жестком диске персонального компьютера;
• данные в формате XML.

Разные базы — разные правила

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

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

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

Базы данных NoSQL

Класс NoSQL (нереляционных) баз данных достаточно широк. Их объединяет отсутствие необходимости структурировать данные в виде таблиц, но варианты реализации этой задачи используются разные.

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

Типы NoSQL баз данных.

Базы данных NoSQL можно разделить на несколько категорий. При этом некоторые из них подпадают более чем под одну категорию.

1. БД типа ключ-значение (Redis, Amazon DynamoDB). В них значения хранятся в связи с уникальным ключом, с помощью которого запись можно легко запросить и извлечь. Такой подход существенно облегчает разворачивание таких баз данных и управление ими. Кроме того, архитектура «ключ-значение» способствует скорости высокой работы приложений.
2. Концепция «широких колонок» (примеры реализации — Cassandra, Scylla, HBase) представляет собой способ хранения, сходный с РБД (имеются таблицы, колонки), но без строгой типизации. Каждая запись в такой базе может представлять собой многомерный массив. Это позволяет хранить объемы информации, измеряющиеся в
   петабайтах (тысячах терабайт) и при этом обеспечивать приемлемую скорость доступа к записям, что затруднительно или недостижимо для обычных РДБ. Для баз данных с «широкими колонками» разработан язык запросов, аналогичный SQL (CQL).
3. Документоориентированные БД (MongoDB, Couchbase) хранят данные в формате JSON, который разработан для описания объектов. К этой же категории можно отнести СУБД Elasticsearch, Splunk и Solr, которые дополнительно оснащены эффективными механизмами поиска.
4. Графообразные БД (Neo4J, Datastax Enterprise Graph) представляют данные в форме сетей, где узлы могут быть связаны между собой. Такие базы данных удобны для хранения объектов, которые должны быть представлены и визуализированы как математические графы. На формат данных, хранящихся в узлах графов, не накладывается ограничений, за ними лишь закреплены метки. Такой подход делает графообразные ДБ удобным инструментом для анализа гетерогенных сред. Например, они используются для предотвращения мошенничеств в сети Facebook.

Рисунок 3. Востребованность NoSQL баз данных. Автор24 — интернет-биржа студенческих работ

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

• отсутствие жестких схем данных, характерных для РДБ;
• легкость масштабирования (расширения объемов хранимой информации);
• возможность быстрой синхронизации между узлами при работе в составе кластера.

Недостатки NoSQL:

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

Преимущества и недостатки

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

Модель базы данных	Год создания	Преимущества	Недостатки
Иерархическая	1960-й	Очень быстрый доступ для чтения, четкая структура, технически простой.	Исправлена ​​структура в дереве, которая не допускает связи между деревьями.
Сетевая	Начало 1970-х	Поддерживает несколько способов доступа к записи, без строгой иерархии.	Плохой обзор с большими базами данных.
Реляционная	1970-й	Простое, гибкое создание и редактирование, легко расширяемое, быстрый ввод в эксплуатацию, простое расширение, быстрый запуск, очень динамичный контекст.	Неуправляемый с большими объемами данных, плохой сегментацией, атрибутами искусственного ключа, внешним интерфейсом программирования, плохо отражает свойства и поведение объектов.
Ориентирована на объекты	Конец 1980-х	Лучшая поддержка объектноориентированных языков программирования, хранение мультимедийного контента. Поддерживает объектноориентированные языки программирования, позволяет хранить мультимедийный контент.	Более низкая производительность с большими объемами данных, мало совместимых интерфейсов.
Ориентирована на документы	1980-е	Соответствующие данные хранятся централизованно в независимых документах, свободной структуре, концепции мультимедиа, относится к классификации сущностей БД.	Организационная работа относительно высока, часто требует навыков программирования.

Модели электронной обработки

Для того чтобы подробно изучить вопрос, какие существуют варианты классификации БД, нельзя обойти тему моделей. Иерархические базы данных были первыми, разработанными в 60-х годах в трудах Холлерита, они зависели от типа хранения информации 1N/ NN в форме перевернутого дерева.

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

Модель базы данных в сети, предложенная CODASYL, является его первой системой управления (IMS), появилась она в 1968 году для программы НАСА «Аполлон». Она решала некоторые проблемы предыдущей иерархической модели, которые уже практически не используются в современном IT-процессе.

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

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

Особенности транзакционных баз данных:

1. Единственная цель — отправка и получение данных с высокой скоростью.
2. Они нацелены на качественный анализ и производственные данные.
3. Уникальным назначением является сбор и восстановление данных с максимально возможной скоростью, поэтому избыточность и дублирование информации не является проблемой, как с другими БД.
4. Позволяют соединение с реляционными БД.
5. Операции являются атомарными, в этом типе возможно только то, что они выполняются полностью (целостность) или не выполняются вообще.

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

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

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

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

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

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

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

Справочная информация

ДокументыЗаконыИзвещенияУтверждения документовДоговораЗапросы предложенийТехнические заданияПланы развитияДокументоведениеАналитикаМероприятияКонкурсыИтогиАдминистрации городовПриказыКонтрактыВыполнение работПротоколы рассмотрения заявокАукционыПроектыПротоколыБюджетные организацииМуниципалитетыРайоныОбразованияПрограммыОтчетыпо упоминаниямДокументная базаЦенные бумагиПоложенияФинансовые документыПостановленияРубрикатор по темамФинансыгорода Российской Федерациирегионыпо точным датамРегламентыТерминыНаучная терминологияФинансоваяЭкономическаяВремяДаты2015 год2016 годДокументы в финансовой сферев инвестиционной