7 лучших бесплатных программных решений с открытым исходным кодом для управления базами данных

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

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

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

Области применения

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

Области применения СУБД:

1. Банковское дело — для информации о клиентах, счетов и займов, а также банковских операций.
2. Авиакомпании — для бронирования и информации о расписании. Авиакомпании были одними из первых, кто использовал базы данных в географически распределенном порядке: терминалы, расположенные по всему миру, обращались к центральной системе баз данных через телефонные линии и другие сети передачи данных.
3. Университеты — для информации о студентах, регистрации курсов и оценок.
4. Операции с кредитными картами — для покупок по кредитным картам и формирования ежемесячных выписок.
5. Телекоммуникации — для ведения записей о совершенных вызовах, составления ежемесячных счетов, поддержания баланса на телефонных карточках с предоплатой и хранения информации о сетях связи.
6. Финансы — для хранения информации о запасах, продажах и покупках финансовых инструментов, таких, как акции и облигации.
7. Продажи — информация о клиенте, продукте и покупке.
8. Производство — для управления цепочкой поставок и для отслеживания производства товаров на фабриках, запасов товаров на складах, в магазинах и заказов на товары.
9. Человеческие ресурсы — для получения информации о сотрудниках, заработной плате, налогах на заработную плату и льготах, а также для получения зарплат.

Графически ориентированная DMS

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

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

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

Сегодня эта модель используется на больших компьютерах. В других областях по-прежнему полагаются на иерархическую модель или обращаются к реляционной модели, гораздо более гибкой и простой в использовании. Некоторые известные модели сетевых баз данных — это UDS Siemens и DMS Sperry Univac. Со временем оба производителя также разработали интересные смешанные формы между сетевой моделью и реляционной. Графически ориентированная база данных благодаря своей ретикулярной структуре считается современной эволюцией сетевой модели.

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

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

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

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

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

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

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

Реляционная модель данных

Основной информационной единицей реляционной БД является таблица. База данных может состоять из одной таблицы (однотабличная БД) или из множества взаимосвязанных таблиц (многотабличная БД).

Структурными составляющими таблицы являются записи и поля.

В одной таблице не должно быть повторяющихся записей.

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

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

Подчеркиваются поля, составляющие главный ключ.

В теории реляционных баз данных таблица называется отношением. Отношение по-английски — relation. Отсюда происходит название «реляционные базы данных». ИМЯ_ТАБЛИЦЫ в нашем примере — это имя отношения. Примеры отношений:

Каждое поле таблицы имеет определенный тип. С типом связаны два свойства поля:

1. множество значений, которые оно может принимать;

2. множество операций, которые над ним можно выполнять.

Поле имеет также формат (длину).

Существуют четыре основных типа для полей БД: символьный, числовой, логический и дата. Для полей таблиц БИБЛИОТЕКА и БОЛЬНИЦА могут быть установлены следующие типы:

В нашем случае поле ПЕРВИЧНЬШ показывает, поступил больной в больницу с данным диагнозом впервые или повторно. Те записи, где значение этого поля равно TRUE (ИСТИНА), относятся к первичным больным, значение FALSE (ЛОЖЬ) отмечает повторных больных. Таким образом, поле логического типа может принимать только два значения.

В таблице БОЛЬНИЦА используется составной ключ — состоящий из двух полей: ПАЛАТА и НОМЕР_МЕСТА. Только их сочетание не повторяется в разных записях (ведь фамилии пациентов могут совпадать).

Как хранится информация в БД

В основе всей структуры хранения лежат три понятия:

• База данных;
• Таблица;
• Запись.

База данных

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

Таблица

По отношению к базе данных таблица является вложенным объеком. То есть одна БД может содержать в себе множество таблиц.
Аналогией из реального мира может быть шкаф (база данных) внутри которого лежит множество коробок (таблиц).
Таблицы нужны для хранения данных одного типа, например, списка городов, пользователей сайта, или библиотечного каталога.
Таблицу можно представить как обычный лист в Excel-таблице, то есть совокупность строк и столбцов.
Наверняка каждый хоть раз имел дело с электронными таблицами (MS Excel).
Заполняя такую таблицу, пользователь определяет столбцы, у каждого из которых есть заголовок. В строках хранится информация.
В БД точно также: создавая новую таблицу, необходимо описать, из каких столбцов она состоит, и дать им имена.

Запись

Запись — это строка электронной таблицы.
Это неделимая сущность, которая хранится в таблице. Когда мы сохраняем данные веб-формы с сайта, то на самом деле добавляем новую запись в какую-то из таблиц базы данных. Запись состоит из полей (столбцов) и их значений. Но значения не могут быть какими угодно.
Определяя столбец, программист должен указать тип данных, который будет храниться в этом столбце: текстовый, числовой, логический, файловый и т.д. Это нужно для того, чтобы в будущем в базу не были записаны данные неверного типа.

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

1. Создадим для сайта новую БД и дадим ей название «weather_diary».
2. Создадим в БД новую таблицу с именем «weather_log» и определим там следующие столбцы:
   • Город (тип: текст);
   • День (тип: дата);
   • Температура (тип: число);
   • Облачность (тип: число; от 0 (нет облачности) до 4 (полная облачность));
   • Были ли осадки (тип: истина или ложь);
   • Комментарий (тип: текст).
3. При сохранении формы будем добавлять в таблицу weather_log новую запись, и заполнять в ней все поля информацией из полей формы.

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

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

Английское слово „relation“ можно перевести как связь, отношение.
А определение «реляционные базы данных» означает, что таблицы в этой БД могут вступать в отношения и находиться в связи между собой.
Что это за связи?
Например, одна таблица может ссылаться на другую таблицу. Это часто требуется, чтобы сократить объём и избежать дублирования информации.
В сценарии с дневником погоды пользователь вводит название своего города. Это название сохраняется вместе с погодными данными.
Но можно поступить иначе:

1. Создать новую таблицу с именем „cities“.
2. Все города в России известны, поэтому их все можно добавить в одну таблицу.
3. Переделать форму, изменив поле ввода города с текстового на поле типа «select», чтобы пользователь не вписывал город, а выбирал его из списка.
4. При сохранении погодной записи, в поле для города поставить ссылку на соответствующую запись из таблицы городов.

Так мы решим сразу две задачи:

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

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

Прогноз на 2020 год

По оценке экономистов, в 2020 году темпы роста ВВП в экономике России могут снизиться практически до нулевой отметки, динамика доходов населения также будет нулевой. В отношении инвестиционной активности будет наблюдаться умеренный рост. В центре внимания будут нефтегазовый сектор, технологии и инновации. Объем сделок будет расти в недвижимости, строительстве и потребительском сегменте. Рост инвестиций в основной капитал по официальному прогнозу ожидается в районе 5%, по оценкам экспертов – не более 2%.

Обнаружили ошибку? Выделите ее и нажмите Ctrl + Enter.

Базы данных 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:

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

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: если вы столкнетесь с этой сложностью, вы должны спросить себя, действительно ли это ваша сфера деятельности …

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

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

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

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

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

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

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

Мультимедиа данные

Определение 1

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

Реляционные системы могут только хранить мультимедиа-данные, а создавать и редактировать такие данные способны только специализированные программы.

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

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

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

Различные СУБД содержат разные механизмы поддержки мультимедиа-данных. Зачастую для их размещения и хранения используют BLOB-поля (Binary Large OBject – большие двоичные объекты). Т.к. мультимедиа-данные могут быть различных видов (графические, аудио-, видео- и т.д.), а каждый вид может иметь разные форматы (например, графическая информация хранится в файлах с расширениями gif, tif, bmp и др.), удобно привязывать их к средствам обработки с помощью механизма OLE.

Поэтому наиболее распространенным типом BLOB-полей являются поля OLE.

Пример 1

Например, MS Access поддерживает поле объекта OLE, система Paradox позволяет создавать кроме того поля типа binary и graphic.

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

Модель сетевой базы данных

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

Преимущества сетевой БД:

1. Концептуально проста и легка в разработке.
2. Доступ к данным проще и гибче по отношению к иерархической модели и не позволяет члену существовать без родителя.
3. Может обрабатывать сложные данные из-за своего отношения «многие ко многим». Это позволяет более естественное моделирование отношений между записями или объектами реляционной СУБД в отличие от иерархической.
4. Благодаря своей гибкости легче перемещается и находит информацию в сетевой БД.
5. Такая структура изолирует управляющие программы от сложных физических данных.

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

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

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