Что такое СУБД

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

Внесение объекта в базу — только полдела. Его еще нужно как-то характеризовать, связать с ним определенное значение. И тут нужно ввести понятие «данное». Данное — это определенный показатель, характеризующий объект и наделяющий его определенным значением. Причем не обязательно, чтобы объект был определен одним данным — их может быть много. Представим, что мы имеем дело с хакерской структурой. Хакерство — это объект. А вот данные — это уже хакерские течения, стаж незаконной деятельности, количество написанных эксплойтов и взломанных машин и т. п. Другими словами, данные — это характеристики определенного объекта. Именно это больше всего интересует клиента, обратившегося к пока еще будущей БД.

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

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

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

За таблицами — наше будущее!

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

Начнем с реляционной модели. В далеком 1969 году американский математик доктор Э. Ф. Кодд (Е.F. Codd) проанализировал сложившуюся к тому времени ситуацию по базам данных и пришел к выводу, что дело плохо. Во всех имевшихся в то время моделях были существенные недостатки: избыточность данных, сложность обработки и отсутствие безопасности хранения информации и т. п. После тягостных раздумий Кодд решил создать свою модель — реляционную. Для тех, кто злостно прогуливал английский, напоминаем, что relation переводится как «отношение» или просто «таблица». Гениальный доктор просто реализовал хранение данных в табличной форме, то есть организовал такие «хранилища» в виде логических структур (физические методы хранения могут быть любыми). Тем самым Кодд сумел добиться наглядности представления информации и удобства ее обработки. Благодаря достижению этого гения для формирования таблицы данных стало достаточно выполнить определенный логический запрос, подчиняющийся законам булевой алгебры. Среди операторов манипуляции данными существуют минимум три операции: извлечение строк (SELECT), извлечение столбцов (PROJECT) и объединение таблиц (JOIN). В результате этих действий мы получаем таблицу. И простой вывод из всего этого: результатом любой операции в реляционной модели является объект того же рода, что и объект, над которым осуществлялось действие. Это и есть основное свойство описываемой модели.

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

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

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

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

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

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

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

В теории СУБД выделяется три вида связей: один-к-одному, один-ко-многим и многие-ко-многим. Расскажем подробно о каждом виде.

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

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

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

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

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

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

Языки управления БД Для каждой модели БД существует свой язык управления. Для реляционной модели таким языком является SQL (Structured Query Language, или структурированный язык запросов). Создатели этого языка стремились максимально приблизить свое детище к человеческому (английскому) языку и при этом наполнить его логическим смыслом.

Язык SQL существенно облегчает работу тем, кто постоянно имеет дело с реляционными СУБД. Строго говоря, без этого структурированного языка многим несчастным пришлось бы писать программу, например, на С. Представьте: чтобы полноценно работать с таблицей, сначала необходимо создать этот объект, потом запрограммировать процедуры обращения к ней (извлечение и добавление строк). Для избавления от подобного геморроя разработчики СУБД позаботились о создании языка SQL.

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

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

Основные языки обращений к БД все же основываются на простом SQL-синтаксисе и имеют своего рода расширение, применимое к объектам. Примерами таких языков служат ORION, Iris и O2 Reloop.

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

Для нужд обычного человека вполне хватит реляционных СУБД, которые применяются повсеместно. Это и всенародно любимый MySQL, и менее любимый Access, и MSSQL. Подобных систем управления масса.