Объектный рай

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЛОКАЛЬНАЯ БАЗА

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

Яркими и наиболее распространен­ными представителями такого рода баз являются Dbase (файлы с расши­рением .dbf), Paradox (расширение .db) и Access (расширение .mdb). Форматы Dbase и Paradox - это даже не базы данных, а таблицы, потому что в одном файле может храниться только одна таблица данных. Индек­сы, ускоряющие поиск и осуществля­ющие сортировку, находятся в от­дельных файлах. Таким образом, од­на база данных может состоять из множества файлов, и это иногда при­водит к определенным проблемам при поставке приложения конечному пользователю.

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

Самый главный недостаток локаль­ных баз данных, как говорит юморист М. Задорнов, – "они тупые". Да-да. Качество и скорость доступа напря­мую зависит от драйвера. В больши­нстве из них не было оптимизаторов SQL-запросов и какого-либо кеширо-вания. Возможности железа исполь­зовались минимально, поэтому на больших базах запросы выполняют­ся крайне медленно.

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

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