ЧТО ТАКОЕ СУБД И С ЧЕМ ЕЕ ЕДЯТ

Теория СУБД

Лекции на тему “Введение в теорию СУБД”

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

ЧТО ТАКОЕ СУБД И С ЧЕМ ЕЕ ЕДЯТ

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

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

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

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

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

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

ЗА ТАБЛИЦАМИ – НАШЕ БУДУЩЕЕ!

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

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

Это и есть основное свойство опи­сываемой модели.

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

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

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

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

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

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

СВЯЗЫВАЕМ ДАННЫЕ

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

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

1. Один-к-одному.Этот вид связи применяется в том случае, когда пер­вичный ключ одной таблицы ссылает­ся на ключ другой. Чтобы было понятнее, приведу пример: допустим, у нас имеется три таблицы хакерской БД. Первая – информация о хакере: дата рождения, пол (девушки тоже бывают взломщиками ;)) и ICQ. Вторая – хакер-ские течения (тип течения, его слож­ность и начальные капиталовложе­ния). Ну и третья – тип выхода в ин­тернет (технология, скорость доступа, оценка безопасности). Все эти табли­цы нельзя свести в одну, так как в ре­зультате отсутствия связи между дан­ными о доступе в интернет и о хакерс-ких течениях (и не только о них) мы получим путаницу. А при реализации связи в виде трех разных таблиц (с помощью первичного ключа - поряд­кового номера) обеспечивается и вы­сокая скорость обработки, и упорядо­ченность данных.

2. Один- ко- многим.Наиболее типичная связь. Реализуется при копировании первичного ключа одной таблицы в дру­гую. В этом случае во второй таблице этот ключик называется уже внешним. Непонятно? Тогда опять обращусь к примеру. Возьмем две таблицы – с ин­формацией о хакере (таблица "Хакеры") и об отношениях с характеристиками эксплойтов, которые он написал (табли­ца "Эксплойты"). По сути, они связаны механизмом один-ко-многим. Действи­тельно, каждый хакер может быть авто-

ром нескольких эксплойтов (так часто и бывает), но каждый эксплойт может быть написан одним и только одним ав­тором (даже при совместной работе в хак-группах определенным эксплойтом занимается один человек). Здесь в каче­стве внешнего ключа в таблице "Эксплойты" используется ник хакера, а в качестве первичного – название эксплойта. При этом внешний ключ "ник хакера" является первичным ключиком в таблице "Хакеры", а сюда введен наме­ренно для связи двух таблиц и организа­ции поиска нужной информации. Кстати, отношение "Эксплойты" совсем не обя­зательно будет состоять лишь из одного атрибута – можно добавить характерис­тики операционок, к которым применим эксплойт, количество целей, тип (локаль­ный или удаленный) и т.п.

3. Многие-ко-многим.Суть этого ти­па связи в том, что ключ в одной таб­лице связывается с ключом другой и наоборот. С этим типом в реляцион­ной модели дела обстоят очень плохо. Точнее, эту связь напрямую вообще никак не реализовать. Чтобы обойти этот недостаток, используется класси­ческое решение: добавляется проме­жуточное отношение, которое будет связано типом "один-ко-многим" как с первой, так и со второй таблицей. Опять наглядный пример. Имеем два отношения: информация о хакерах и данные о серверах, которые когда-то были взломаны. Если подумать, то мы владеем следующей структурой: од­ним злоумышленником могут быть хакнуты несколько серверов (так час­то и бывает в жизни), а на один сер-вак могут поселиться несколько хаке­ров (одновременно или последова­тельно), если админ вовремя не про-патчил баг. Чтобы реализовать по­добную схему в реляционной БД, мы добавим промежуточное отношение из двух полей: ник хакера и адрес сер­вера. Таким образом, эта вспомога­тельная таблица будет иметь связь "один-ко-многим" как с первым, так и со вторым отношением. Конечно, в этом случае повысится избыточность данных, поэтому эксперты рекоменду­ют избегать таких связей.

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

ОБЪЕКТНЫЙ РАЙ

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

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

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

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

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

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

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

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

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

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

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

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

Для нужд обычного человека (то есть тебя) вполне хватит реляцион­ных СУБД, которые применяются повсеместно. Это и всенародно люби­мый MySQL, и менее любимый Access, и MSSQL. Подобных систем управле­ния масса, определись и выбери ту, что тебе больше по сердцу. А сде­лать этот нелегкий выбор, как всегда, поможет этот уникальный СПЕЦвы­пуск ;).

Какие бывают базы данных? В большинстве случаев решения программистов ограничиваются двумя типами: локальная и клиент-серверная. В первом случае получается шампунь "все-в-одном". Во втором мы разделяем данные и клиентское приложение и получаем два уровня.

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