Лекции для студентов

Теория СУБД

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

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

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

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

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

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

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

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

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

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

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

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

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

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