Что является базой

База данных: назначение, понятие, классификация

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

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

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

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

Ключ сущности

Сущности имеют свойства, которые называются атрибутами (attribute).

Например, атрибуты:

  • сущности ФАКУЛЬТЕТ:
  • сущности ГРУППА:
  • сущности СТУДЕНТ:
    • фамилия;
    • имя;
    • отчество;
    • номер студенческого билета;
    • номер паспорта;
    • год рождения;
    • месяц рождения;
    • день рождения.

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

Например:

  • домен атрибута «год создания»: целые положительные числа;
  • домен атрибута «имя»: строка, не содержащая пробелов;
  • домен атрибута «год рождения»: целые положительные числа;
  • домен атрибута «месяц рождения»: январь, февраль, март … декабрь;
  • домен атрибута «день рождения»: целые числа от 1 до 31.

Ключ сущности (entity key), первичный ключ– это атрибут (или множество атрибутов) уникальным образом идентифицирующих экземпляр сущности (объект).

Например: ключ сущности СТУДЕНТ – номер студенческого билета, ключ ФАКУЛЬТЕТА – название. Если ключ состоит из одного атрибута, его называют простым ключом. Если ключ сущности состоит из нескольких атрибутов, его называют составным ключом.

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

Иерархическая база данных, структура иерархических данных

Когда речь идёт о хранении иерархических данных, каждый объект хранит информацию в виде определенной сущности, и у каждой сущности могут быть родительские и дочерние элементы, а у дочерних, в свою очередь, тоже могут быть дочерние элементы. Таким образом, можно сказать, что это данные, которые подлежат строгой иерархии (представьте себе своеобразное дерево).

Простой пример иерархических данных — документ в формате XML либо файловая система компьютера.

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

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

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

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

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

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

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

Главная особенность — все объекты хранятся в виде набора 2-мерных таблиц. Каждая таблица включает в себя набор столбцов, где указываются следующие параметры:
— название;
— тип данных (число, строка и т. д.).

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

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

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

Основные функции СУБД

  • управление данными во внешней памяти;
  • управление буферами оперативной памяти;
  • управление транзакциями;

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

  • журнализация и восстановление БД после сбоев;
  • поддержание языков БД.

Технология клиент-сервер является основой большинства реализаций современных программных систем. Речь идёт не только о паре «Приложение конечного пользователя — СУБД». Каждое звено многозвенной системы с длинными цепочками прохождения сообщений от пользовательского интерфейса через службы и серверы приложений к СУБД также работает в режиме «клиент-сервер». Отличительные признаки технологии следующие:

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

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

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

Рис. 1. Взаимодействие приложения с СУБД в системах с разным числом звеньев

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

  1. Простота разработки приложений. Программисту не требуется установка и настройка СУБД на своём рабочем месте. Программа имеет полный контроль над логикой работы с БД.
  2. Простота развёртывания приложений. В большинстве случаев достаточно скопировать файлы динамически подгружаемых библиотек в директорий приложения, при этом пользователю даже не нужно иметь права администратора на своём компьютере или другом устройстве, например, на планшете.
  3. Простота обслуживания локальной базы данных. Как правило, приложение со встроенной СУБД эксплуатируется в однопользовательском режиме, а размер базы данных относительно невелик, поэтому необходимость в дополнительной настройке прав доступа и оптимизации быстродействия практически отсутствует. Регулярные операции обслуживания базы данных (резервное копирование, индексация, очистка, дефрагментация и т. п.) могут быть автоматизированы и реализованы непосредственно приложением, например, при его запуске.
  4. Возможность работы в однозадачной операционной системе. Хотя времена господства MS DOS на персональных компьютерах давно прошли, разработчики встраиваемых систем для различных устройств и оборудования смогут по достоинству оценить эту возможность.
  5. Как правило, более высокое быстродействие на операциях вставки, удаления и считывания одиночных записей. Это связано не только с однопользовательским режимом работы, но и с отсутствием затрат на упаковку данных приложением с последующей их передачей по сети СУБД-серверу. По сути, приложение напрямую работает с локально расположенными файлами через слой программных интерфейсов (API) встроенной СУБД.

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

Сюда относятся такие продукты, как dBase, Paradox, FoxPro или Clipper (современная открытая кросс-платформенная реализация Clipper называется Harbour). Тем не менее, как минимум одна популярная встраиваемая СУБД до сих пор нередко используется в таком качестве, это Microsoft Access и его «мотор» MS Jet, являющийся компонентом операционной системы Windows.

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

  1. Более высокий риск потерь и повреждения данных. Как мы помним, встроенная СУБД находится в том же процессе операционной системы, что и приложение. Соответственно, аварийное завершение работы приложения в момент записи данных может повредить их. Транзакции также контролируются непосредственно приложением, поэтому при аварийном останове некому будет откатить незавершённые модификации базы данных и она останется в несогласованном состоянии.
  2. Ориентация на автономные однопользовательские клиентские и многопоточные серверные приложения. Хотя с помощью разделения файлов в сети можно организовать доступ к одной БД из нескольких приложений, находящихся на разных устройствах, такое решение будет ограничено небольшим числом пользователей и малыми размерами базы данных. Не касаясь серьёзных проблем обслуживания и обеспечения безопасности такой БД, на практике в сети передачи данных 100 мегабит/сек проблемы быстродействия начинаются уже при десятке пользователей, работающих с файлами размером нескольких сотен мегабайт данных.
  3. Невозможность распределения вычислительной нагрузки. Встроенная СУБД работает на одном устройстве, а вычисления производит непосредственно приложение. Клиент-серверная СУБД может быть развёрнута в кластере из многих устройств, при этом она способна сама производить вычисления, возвращая приложению- клиенту результат.
  4. Низкий уровень безопасности. Файлы базы данных должны быть целиком доступны пользователю как минимум на чтение. Таким образом, невозможно предотвратить копирование этих файлов злоумышленниками.
  5. Как правило, функционал встроенной СУБД урезан по сравнению с клиент-серверной версией того же продукта. Например, встроенная версия Microsoft SQL Server Compact несовместима с клиент­серверными версиями и сравнима с Microsoft Access.

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

На практике иногда я встречал отношение к вопросам выбора СУБД на уровне высказывания: «Не будем ломать голову, возьмём Oracle: он, как танк, везде пройдёт и нам уж всяко подойдёт». Действительно, если вы не хотите поднапрячь голову сейчас, но согласны, что спустя некоторое время, возможно, придётся на этой же голове рвать волосы, то можно, не напрягаясь, попросить сделать за вас работу продавцов-консультантов продуктов «Большой тройки»[3].

Из ряда многочисленных встроенных СУБД, опробованных непосредственно на практике или в тестовом режиме, таких как xBase, Microsoft, Access, Microsoft SQL Server Compact, SQLite, Oracle Lite) наиболее интересным современным решением мне представляется Firebird по следующим причинам.

  1. Кросс-платформенная СУБД, доступны версии для Windows, Linux и Mac.
  2. Свободно распространяемая СУБД с открытым исходным кодом, допускающая использование в закрытых коммерческих продуктах.
  3. Всего один основной DLL-файл для развёртывания (могут также понадобиться файлы ресурсов), одновременно работающий и как встроенная СУБД, и как клиентская библиотека для связи с СУБД- сервером Firebird. Соответствующий режим выбирается указанием или пропуском имени сервера в строке соединения.
  4. Практически полностью поддержана функциональность своей клиент-серверной версии, включая поддержку встроенных типов данных, видов, триггеров, хранимых процедур и системы безопасности. Это значит, что разработанное программистом приложение будет иметь минимум специфики при работе со встроенной или клиент-серверной версией СУБД с возможностью переключения изменением всего одного параметра соединения.
  5. Версионность данных, благодаря которой читающие транзакции не блокируют пишущие транзакции и наоборот. Разработчики отчётов оперативного контура информационных систем оценят эту возможность, когда требуется выдача согласованной информации на текущий момент времени.

Базы данных. Виды и типы баз данных. Структура реляционных баз данных. Проектирование баз данных. Сетевые и иерархические базы данных.

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

Firebird достаточно лёгок в администрировании: для относительно небольших

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

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

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

Виды моделей данных

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

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

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

  • иерархическая;
  • сетевая;
  • реляционная.

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

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

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

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

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

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

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

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

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

Оцените статью
Помощь юриста
Добавить комментарий

Adblock detector