Какие бывают базы данных

Как автономные технологии улучшают управление базами данных

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

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

3.2. Системы информационных баз

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

Структура информационных баз

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

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

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

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

По архитектурному принципу база данных делится на четыре зоны:

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

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

Формализация отношений

Различают следующие виды связей.

1 тип – «один к одному» (1:1)
Это модель функциональных зависимостей:

2 тип – «один ко многим» (1:М)
Это модель порожденных зависимостей (односторонних):       

3 тип – «много ко многим» (М:М)
Это модель порожденных записей (двусторонних):

                                                      

Используется составной ключ – Ui+ki, j+lj:

4 тип – «условная»
Модель одиночной связи

Используется для связи корневых объектов.

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

Основные нормальные формы:1НФ – существуют только функциональные зависимости;2НФ – существуют функциональные зависимости неключевых атрибутов от составного ключа;3НФ – неключевые атрибуты не имеют транзитивной связи с первичным ключом (первый атрибут связан с ключом, а второй атрибут связан с первым атрибутом). 

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

Каноническая процедура проектирования информационной базы

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

Каноническая процедура проектирования:

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

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

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

СУБД

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

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

Неструктурированные базы данных (NoSQL) создают структуру по ходу и убирают необходимость в создании жёстко определённых связей между данными. Здесь можно экспериментировать с разными способами доступа к тем или иным видам данных.

К реляционным базам данных относятся:

• SQLite;
• MySQL;
• PostgreSQL.

Из них наиболее распространённой является база данных MySQL, но остальные тоже имеют популярность и с ними можно столкнуться.

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

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

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

База данных сайта — нормализация отношений

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

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

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

1. Первая нормальная форма

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

Если бы в ней были записи типа «Ferrari => Красный, Жёлтый, Малиновый» — это было бы нарушением ввиду того, что атрибуты не являются простыми. В таком случае её нормализация заключалась бы в разбиении этой записи на 3: «Ferrari => Красный», «Ferrari => Жёлтый», «Ferrari => Малиновый».

2. Вторая нормальная форма

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

Если бы в нашей таблице помимо полей «Фирма» и «Цвет» было бы поле «Скидка», она не была бы нормализованной, т.к. скидка зависит от цвета, но не зависит от фирмы машины. Нормализация заключалась бы в разбиении её на 2 таблицы: «Фирма» и «id цвета» были бы в одной. А «id цвета», «Цвет» и «Скидка» были бы в другой.

3. Третья нормальная форма

По смыслу она очень похожа на 2НФ. Обе они предусматривают зависимость НЕ ключевых атрибутов от первичного ключа. Отношение находится в 3НФ, если оно находится во 2НФ и его НЕ ключевые атрибуты зависят от ПФ.

Единственное отличие в том, что во 2НФ зависимость неприводимая, а в 3НФ она нетранзитивная. Страшное слово «нетранзитивная» на самом деле подразумевает вынесение всех НЕ ключевых полей, которые могут относиться к нескольким записям таблицы, в отдельную таблицу.

Если бы в нашей таблице помимо полей «Фирма» и «Цвет» было бы поле «Возраст фирмы», она не была бы нормализованной, т.к. возраст фирмы не зависит от модели машины. Нормализация заключалась бы в разбиении её на 2 таблицы: «Цвет» и «id фирмы» были бы в одной, а в другой были бы «id фирмы», «Название фирмы», «Возраст фирмы».

Частным случаем 3НФ является нормальная форма Бойса-Клодда, которая дополнительно учитывает наличие в таблице нескольких потенциальных ключевых полей, которые являются составными и пересекаются (имеют хотя бы один атрибут).

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

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

4НФ, 5НФ, 6НФ и их частные формы представляют скорее академический интерес, т.е. они могут быть интересны только узкому кругу учёных, которые защищают диссертации и проводят свои исследования, пытаясь открыть что-либо новое.

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

O(1) vs O(n2)

В настоящее время многие разработчики не заботятся о временной сложности алгоритмов … и они правы!

Но когда вы имеете дело с большим количеством данных (я не говорю о тысячах) или если вы боретесь за миллисекунды, становится критически важным понять эту концепцию. И как вы понимаете, базы данных должны иметь дело с обеими ситуациями! Я не заставлю вас потратить больше времени, чем необходимо чтобы ухватить суть. Это поможет нам позже понять концепцию оптимизации на основе затрат (cost based optimization).

Концепция

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

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

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

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

• O(1) или постоянная сложность остаются постоянными (иначе это не будет называться постоянной сложностью).
• O(log(n)) остается низкой даже с миллиардами данных.
• Наихудшая сложность — O(n2), где количество операций быстро растет.
• Две другие сложности так же быстро увеличиваются.

Примеры

При небольшом количестве данных разница между O(1) и O(n2) незначительна. Например, предположим, что у вас есть алгоритм, который должен обрабатывать 2000 элементов.

• Алгоритм O (1) обойдется вам в 1 операцию
• Алгоритм O (log (n)) обойдется вам в 7 операций
• Алгоритм O (n) обойдется вам в 2 000 операций
• Алгоритм O (n * log (n)) обойдется вам в 14 000 операций
• Алгоритм O (n2) обойдется вам в 4 000 000 операций

Как я уже сказал, по-прежнему важно знать эту концепцию при работе с огромным количеством данных. Если на этот раз алгоритм должен обработать 1 000 000 элементов (что не так уж много для базы данных):

• Алгоритм O (1) обойдется вам в 1 операцию
• Алгоритм O (log (n)) обойдется вам в 14 операций
• Алгоритм O (n) обойдется вам в 1 000 000 операций
• Алгоритм O (n * log (n)) обойдется вам в 14 000 000 операций
• Алгоритм O (n2) обойдется вам в 1 000 000 000 000 операций

Я не делал расчетов, но я бы сказал, что с помощью алгоритма O (n2) у вас есть время выпить кофе (даже два!). Если вы добавите еще 0 к объему данных, у вас будет время, чтобы вздремнуть.

Идем глубже

Для справки:

• Поиск в хорошей хеш-таблице находит элемент за O (1).
• Поиск в хорошо сбалансированном дереве дает результат за O (log (n)).
• Поиск в массиве дает результат за O (n).
• Лучшие алгоритмы сортировки имеют сложность O (n * log (n)).
• Плохой алгоритм сортировки имеет сложность O (n2).

Примечание: в следующих частях мы увидим эти алгоритмы и структуры данных.

Есть несколько типов временной сложности алгоритма:

• сценарий среднего случая
• лучший вариант развития событий
• и худший сценарий

Временная сложность часто является наихудшим сценарием.

Я говорил только о временной сложности алгоритма, но сложность также применима для:

• потребления памяти алгоритмом
• потребления дискового ввода / вывода алгоритмом

Конечно, есть сложности хуже, чем n2, например:

• n4: это ужасно! Некоторые из упомянутых алгоритмов имеют такую сложность.
• 3n: это еще хуже! Один из алгоритмов, которые мы увидим в середине этой статьи, имеет эту сложность (и он действительно используется во многих базах данных).
• факториал n: вы никогда не получите свои результаты даже с небольшим количеством данных.
• nn: если вы столкнетесь с этой сложностью, вы должны спросить себя, действительно ли это ваша сфера деятельности …

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

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

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

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

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

База данных и СУБД

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

Есть поня­тие систе­мы управ­ле­ния базой дан­ных (СУБД) — это когда семья села за стол и само­го млад­ше­го отправ­ля­ют в кла­дов­ку за огур­ца­ми, он при­но­сит её и не раз­би­ва­ет по доро­ге. То есть СУБД — это какое-то сред­ство для мани­пу­ля­ции дан­ны­ми в базе, напри­мер программа.

Объектно-реляционные субд

Разница между объектно-реляционными и объектными СУБД: первые являют собой надстройку над реляционной схемой, вторые же изначально объектно-ориентированы. Главная особенность и отличие объектно-реляционных, как и объектных, СУБД от реляционных заключается в том, что О(Р)СУБД интегрированы с Объектно-Ориентированным (OO) языком программирования, внутренним или внешним как C++, Java. Характерные свойства OРСУБД:

• комплексные данные,
• наследование типа,
• объектное поведение.

Комплексные данные могут быть реализованы через постоянно-хранимые объекты (persistent objects). Создание комплексных данных в большинстве существующих ОРСУБД основано на предварительном определении схемы через определяемый пользователем тип (UDT — user-defined type). Используются также встроенные конструкторы составных типов, например массив (ARRAY).

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

Объектное поведение закладывается через описание программных объектов. Такие объекты должны быть сохраняемыми и переносимыми для обработки в базе данных, поэтому они называются обычно как постоянные (или долговременные) объекты. Внутри базы данных все отношения с постоянным программным объектом есть отношения с его объектным идентификатором (OID).

Объектно-реляционными СУБД являются, к примеру, широко известные Oracle Database, Microsoft SQL Server 2005, PostgreSQL, а также Sav Zigzag, IBM Cloudscape,

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

Практически общепринято определять три направления, типа и существенных отличия.

Это:

1. Иерархическая база данных.
2. Сетевая (распределенная) база данных.
3. Реляционная база данных.

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

Достаточно давно в иерархических базах в деревьях отношений была замечена динамика: что поначалу было обозначено вершиной — стало основанием, а иная ветка обрела статус вершины.

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

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

Как именовать конкретные реляционные отношения — не суть важно

Какие реляционные БД популярны в веб-разработке

MySQL

Это открытая СУБД, купленная Oracle в придачу к Sun Microsystems. С ней работают более половины (55,6%) всех разработчиков (по  опроса, который в 2020 году провёл сайт StackOverflow.com среди 65 тысяч респондентов).

Главные её преимущества — бесплатность и высокая скорость работы с данными. MySQL создавалась для обработки огромных массивов информации в промышленных масштабах, но благодаря доступности и быстродействию оккупировала Всемирную паутину, заслужив звание «СУБД всея интернета». И сегодня MySQL всё ещё самая удобная СУБД для работы с интернет-страницами и веб-приложениями.

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

SQLite

Эта СУБД использует большую часть стандартного языка SQL.

Главное преимущество SQlight — встраиваемость. Это объясняется тем, что SQlight не приложение типа «клиент-сервер» (в отличие от других реляционных СУБД), а библиотека, которую подключают непосредственно к программе.

И она тоже весьма популярна: достаточно сказать, что SQLite есть в каждом смартфоне. Например, в смартфонах на Android там хранятся контакты и медиа, а в iOS её используют многие приложения.

PostgreSQL

Её можно назвать самой продвинутой. Это не просто реляционная, а объектно-реляционная свободная СУБД.

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

История

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

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

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

Оперативные сетевые базы данных появились в середине 1960-х. Операции над оперативными базами данных обрабатывались в интерактивном режиме с помощью терминалов. Простые индексно-последовательные организации записей быстро развились к более мощной модели записей, ориентированной на наборы. За руководство работой Data Base Task Group (DBTG), разработавшей стандартный язык описания данных и манипулирования данными, Чарльз Бахман получил Тьюринговскую премию.

В это же время в сообществе баз данных Кобол была проработана концепция схем баз данных и концепция независимости данных.

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

Сам термин база данных (англ. database) появился в начале 1960-х годов, и был введён в употребление на симпозиумах, организованных компанией SDC в и 1965 годах, хотя понимался сначала в довольно узком смысле, в контексте систем искусственного интеллекта. В широкое употребление в современном понимании термин вошёл лишь в 1970-е годы.

Организация информации и данных

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

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

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

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

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

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

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

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

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

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

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

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

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

Использование баз данных для повышения эффективности бизнеса и принятия решений

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

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

Динамика организации данных

Жесткая модель данных существует до того момента, пока не изменились внешние обстоятельства. В начале 90-х никто не думал, что две цифры в поле даты, отведенные под год — достаточны. Сколько паники и проблем вызвал барьер 640 Кб памяти на заре компьютеростроения.

Насколько ужасно выглядит сегодня способ доступа к данным в dBase, Clarion, FoxPro, в то время как в начале 90-х всех все устраивало. Довольны были и разработчики, и пользователи. Но тогда информации было мало, да и алгоритмы были примитивные.

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

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

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

От прошлого к настоящему

Нет смысла охватывать историю баз данных, цепляясь за любое сходство, поэтому моментом появления баз данных будет не античное время, а 60-е годы 20 века. Именно тогда компьютеры стали эффективным инструментом для коммерческих компаний, а организация COBASYL (COnference on DAta SYstems Language), создавшая в 1959 году язык COBOL и впоследствии наделив его возможностями для управления БД, помогла им управлять резко возросшими потоками информации.

К концу 60-х появилась первая сетевая модель данных, возникло понятие СУБД, а в 1974 году компания IBM стала работать над языком для System R.  Так на свет появился SEQUEL (Structured English QUEry Language). Однако позже, когда стало известно, что такое название используется британской авиастроительной компанией, было решено немного сократить до привычного SQL.

С увеличением доступности компьютеров стали появляться ориентированные на простых пользователей БД (Paradox, RBASE 5000, RIM, Dbase III), API (ODBC, Excel, Access) и средства разработки (VB, Oracle Developer, PowerBuilder). Само-собой, тенденция охватила и интернет, на сегодняшний день эффективное взаимодействие с БД – негласное требование к любому ресурсу с более-менее динамической информацией.

Если говорить о компаниях, то на рынке установилось троевластие: практически вся власть в области баз данных распределена между IBM, Microsoft и Oracle.

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

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

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