(Возврат на основную страницу)
Editorial
Дейт защищает реляционную модель
Сара Кашмен (Sarah Kashman)
Крис Дж. Дейт говорил это раньше и опять повторил в своем докладе на открытии международного симпозиума DAMA: «Давайте торжественно поклянемся никогда больше не произносить слов „плоские таблицы”!» Аудитория встретила овацией самого Дейта и его попытки «наставлять и развлекать» слушателей.
Дейт является автором двадцати двух основополагающих книг по управлению данными, включая «Введение в системы баз данных», которая выдержала уже восемь изданий. Его доклад был первым на открывшемся на этой неделе 16 ежегодном международном симпозиуме DAMA (Data Management Association).
Имея многолетнюю репутацию непреклонного поборника реляционной теории, Дейт заявляет профессионалам в области баз данных, что такие кажущиеся безобидными выражения, как плоские таблицы, добавили путаницы в представления, связанные с реляционной моделью.
Дейт начал свою презентацию с описания некой стены, окружающей пространство, которое друг Дейта и его коллега по реляционной теории Хью Дарвен называет реляционным миром.
«Большинство людей ищут реляционный мир, но наблюдают лишь стену, — объяснял Дейт. — Они видят проблемы и полагают их реляционными, однако проблемой является сама стена, которая служит барьером в общении».
Среди барьеров на пути к реляционной модели Дейт выделил и язык Structured Query Language (SQL).
«Самая большая проблема, связанная с SQL, — та, что он не реализует реляционную модель», — сказал Дейт. И в качестве любимой мозоли назвал NULL.
«NULL представляет собой слишком упрощенное решение сложной проблемы, — сказал он, расходясь во мнениях со своим наставником Теддом Коддом, изобретшим реляционную модель. — Кодд был единственным, кто понимал реляционную модель и считал NULL хорошей идеей».
Автор бестселлера Джо Селко, который заявляет, что он «сделал карьеру, возражая Крису Дейту», допускает, что в SQL возможны некоторые усовершенствования.
К примеру, Селко сказал, что
ему хотелось бы, чтобы символ джокера был бы без подчеркива
ния теперь, когда так широко распространены лазерные принтеры. Но в целом,
заметил он, SQL логичен, а что касается NULL, он не видит способа его обойти.
«Не стоит думать, что вы всегда все знаете», — сказал Селко.
Дейт приберег самую жесткую
критику для дискуссии, в частности для обсуждения объектноориентированных СУБД и
СУБД на основе XML. Назвав их «последней модой в компьютерном мире», Дейт
заявил, что он отвергает тот аргумент, что реляционные СУБД — вчерашний день. По
его мнению, поклонники объектноориентирован
ных баз данных «видят недостатки в реляционной модели просто потому, что не до
конца ее понимают».
Дейт также заметил, что энтузиазм поклонников XML заходит слишком далеко.
«XML изобрели, чтобы решить проблему обмена данными, но, решив ее, они теперь хотят владеть всем миром, — сказал он. — Похоже, что с XML мы забыли, что собирались делать, а вместо этого сосредоточились на том, как это выполнить».
Крег С. Маллинз, директор по
планированию технологии в компании BMC Software и эксперт в SearchDatabase.com,
разделяет мнение Дейта об XML. Он считает, что этот язык может быть стоящим до
тех пор, пока XML используется лишь в ка
честве метода получения данных и помещения их в СУБД.
Однако Маллинз предостерег, что данные XML, которые хранятся в реляционных СУБД в виде целых документов, окажутся бесполезными, если к ним надо будет обращаться с запросами. Он подчеркнул точку зрения Дейта, что XML не является настоящей моделью данных.
«XML вызывает чрезмерный энтузиазм. Его крикливо разрекламировали, и все полагают, что ему везде найдется место, — сказал Маллинз. — Но если он действительно проникнет везде, то тогда у нас везде будут проблемы».
Что касается объектноориентированных СУБД, то ни Маллинз, ни Дейт не видят в них угрозы реляционным СУБД.
Оба они отвергают известную аналогию, используемую сторонниками объектноориентированных СУБД. Она заключается в том, что при работе с реляционными СУБД каждый раз для обработки объекта его необходимо собирать, — это все равно, что для парковки каждый раз разбирать автомобиль, а если надо ехать — заново его собирать.
По словам Дейта, каждый, кто пользуется этой аналогией, демонстрирует «непонимание различий между логической и физической моделями». Он считает, что использование терминов «плоские» или «двумерные (2D)» таблицы для описания данных, хранящихся в реляционных базах данных, в корне неверно.
Когда его спросили, умело ли применяется реляционная модель в сегодняшних системах, Маллинз дал незамедлительный отрицательный ответ, но при этом он не считает ситуацию такой плохой, как ее рисует Дейт.
«Мы занимаемся производственной работой и создаем ценности, — утверждает Маллинз. — И разве все не ради этого?»
DB Design & Warehousing
Введение в структуры данных кластеризованных и некластеризованных индексов
Виджая Кумар (Vijaya Kumar)
Когда я был новичком в использовании SQL Server, меня сначала смущала разница между кластеризованными и некластеризованными индексами. Как разработчик и новоиспеченный администратор баз данных, я решил самостоятельно узнать все об этих типах индексов и о том, когда их следует использовать.<annot>
Эта статья является результатом моих исследований и опытов. Она объясняет различия между кластеризованными и некластеризованными индексами администраторам баз данных и тем разработчикам, которые только начинают работать с SQL Server.
Вы можете вырезать и вставить предложенный мной код, чтобы лучше понять различия между кластеризованными и некластеризованными индексами.
Планы выполнения
Виджая Кумар (Vijaya Kumar)
Когда я начал работать с SQL Server, то не использовал должным образом возможности Show Execution Plan для анализа запросов. Мне всегда казалось: когда я составляю запрос, он получается самым лучшим. Я никогда даже не задумывался о производительности обработки моего запроса и не считал нужным взглянуть на план его выполнения (Execution Plan).<ANNOT>
В ранние дни моей карьеры я был счастлив, извлекая данные и даже не зная, как они мне возвращались и какой тип Execution Plan применялся для выполнения запроса. Я полагал, что о производительности его обработки позаботится SQL Server. Мне кажется, в самой природе проектировщиков программного обеспечения заложено, что при начале работы или при освоении новой технологии они не считают нужным тратить время на освоение всего, что на самом-то деле необходимо знать, прежде чем приступать к написанию кода. Возможно, это происходит из-за конкуренции или из-за некоторой незрелости отрасли IT.
Дни летели за днями, а в файлах базы данных накапливалась информация. И в один прекрасный момент моего заказчика не устроила производительность, с которой обрабатывались запросы в приложении. Он пришел ко мне с несчастным лицом, утверждая, что ему пришлось тратить лишнее время на выполнение офисной работы из-за того, что запросы обрабатывались медленно. Сначала я посоветовал этому заказчику увеличить системные ресурсы, например нарастить жесткий диск компьютера в качестве временного решения. Хотя стоимость жесткого диска невелика, при деградации производительности обработки запросов это нельзя считать долговременным решением. Он согласился со мной отчасти, пообещав, со своей стороны, выполнить требуемое. А меня попросил заново проанализировать и лучше настроить запросы, и не полагать, что он будет и дальше продолжать увеличивать системные ресурсы. Мне пришлось считаться с его личным мнением, потому что в отрасли IT важно удовлетворять пожелания заказчиков. Я пообещал своему заказчику, что пересмотрю и точнее настрою запросы.
КАК?
В начале своей карьеры я знал основные вещи об MS-SQL Server. Честно говоря, когда я давал обещание заказчику, у меня в голове не было никаких идей. Но лично мне казалось, что с помощью GOOGLE и документации я что-нибудь сделаю, чтобы решить задачу.
Я читал книги по MS-SQL, искал подсказки в документации и в Интернете. Я услышал о концепции Show Execution Plan и нашел ее. Эту опцию можно включить, используя SQL Query Analyzer. Show Execution Plan представляет собой важное графическое средство, позволяющее разработчикам и администраторам баз данных анализировать, оптимизировать запросы и способствовать их выполнению, улучшая тем самым производительность их обработки.
В Show Execution Plan предусмотрены различные значки для выполнения разных задач. В этой статье меня особенно будут интересовать значки Table Scan, Index Scan, Index Seek, Clustered Index Scan, Clustered Index Seek.
По мере того как дни и годы летели, как болиды в Формуле-1, я решил, что настало время полностью разобраться в том, как работают эти значки.
Теперь я готов анализировать запросы и улучшать производительность их обработки. Перед тем как приступить к анализу запросов, я задал себе несколько вопросов:
Когда MS-SQL Server использует Table Scan?
Когда MS-SQL Server использует Index Scan?
Когда MS-SQL Server использует Index Seek?
Когда MS-SQL Server использует Clustered Index Scan?
Когда MS-SQL Server использует Clustered Index Seek?
Меня в основном интересовало, в каких базах MS-SQL Server будет применять одну из этих опций для анализа запроса. Эта информация будет полезна начинающим разработчикам и администраторам баз данных. Я решил написать данную статью, чтобы поделиться своими знаниями и помочь другим лучше понять эти методы.
Если хотите, можете просто читать эту статью, а можете запустить SQL Server и выполнять вместе со мной все упражнения.
Programming
Автоматическое шифрование хранимых процедур и преодоление ограничения 8 Кб
Джозеф Гама (Joseph Gama)
В своей статье Джозеф Гама предоставляет полезный сценарий, способный помочь любому администратору БД, стремящемуся автоматизировать шифрование хранимых процедур.
Шифрование единственной хранимой процедуры является простой задачей: все, что нужно сделать, — добавить WITH ENCRYPTION перед оператором AS. И если вы должны выполнять это действие только от случая к случаю, то просто не забывайте добавлять этот оператор каждый раз, когда набираете оператор CREATE PROCEDURE. Однако если вы сталкиваетесь с кучей хранимых процедур, требующих шифрования (скажем, перед передачей их команде тестеров) и, вероятно, этот процесс будет повторяющимся, тогда наилучшим решением будет использование автоматизации.
Существует три возможных подхода:
приобрести коммерческий инструмент;
написать приложение с помощью VB, Delphi или C++ (например) для выполнения этой работы;
написать сценарий.
Программист внутри вас, вероятно, предпочел бы второе решение, поскольку оно требует меньшей работы по написанию кода. Однако, администратор БД внутри вас, наверное, воскликнет: «Конечно, сценарий!». Почему? Потому что не существует «внешней» программы для решения подобной задачи. Кроме того, написание сценария дает вам дополнительный контроль.
Стоит сказать, что написание подобного сценария сталкивается с определенными сложностями. Наверное, вы знаете, что при удалении хранимой процедуры с помощью оператора DROP с последующим повторным ее созданием с использованием WITH ENCRYPTION, вы можете получить сообщение об ошибке, если размер хранимой процедуры превысит 8 Кб. Решение заключается в изменении хранимой процедуры с помощью оператора ALTER вместо ее удаления c последующим воссозданием.
Другой проблемой является то, что размещение операторов CREATE PROCEDURE и AS не является простым процессом. Лучшее решение должно работать с любым размером текста без использования временных файлов или какой-либо внешней помощи. Код, сопровождающий эту статью (находится на дискете) работает со всеми хранимыми процедурами и отобразит ошибку, идентифицирующую обнаруженную проблему. С этой проблемой легко справиться, внеся незначительные изменения в код хранимой процедуры, например, удаляя двойные пробелы между CREATE PROCEDURE.
Other
Системные таблицы
Труди Пельцер
Как появилось название этой статьи? У меня было искушение назвать ее «Ну, знаете, те самые штуковины, которые вам выдает ваша СУБД, когда вы спрашиваете, какие в ней есть таблицы, столбцы и ограничения». Или, возможно, «Что в SQL Server называется системными таблицами, в IBM — системным каталогом, а в Oracle — словарем данных».
Проблем с названием статьи было множество.
Если бы в названии говорилось «информационная схема», то те, кто никогда не слышал этот термин (а таких много), не поняли бы его.
Если бы в названии говорилось «каталог» или «системный каталог», некоторые могли бы подумать, что обсуждение коснется стандартной иерархии SQL «каталог-схема-таблица» (а для некоторых «каталог» означает «база данных»).
Если бы в названии говорилось «метаданные», кто-то решил бы, что это статья о хранилищах данных.
Но я решила, что «Системные таблицы» будет хорошим компромиссным названием для статьи, в которой обсуждается, как IBM DB2 v8, Microsoft SQL Server 2000 и Oracle9i обрабатывают данные, описывающие саму структуру БД. Я буду назвать это «метаданными».
Описание структуры базы данных
В стандартном SQL информация, описывающая базу данных, хранятся в схеме под названием INFORMATION_SCHEMA.
«Информационная схема является определением модели данных SQL, специфицированным как SQL-schema в терминах <SQL schema statement>, как определено в ISO/IEC 9075. <...> Представления Информационной схемы определяются как находящиеся в схеме под названием INFORMATION_SCHEMA, что позволяет получать доступ к ним так же, как к любым иным таблицам в какой-либо другой схеме. Право выполнять оператор SELECT в любом из этих представлений предоставлено учетной записи PUBLIC WITH GRANT OPTION, так что любой пользователь может обращаться к ним с запросами... Никакие другие полномочия для них не предусмотрены, так что их нельзя модифицировать. <...> Можно предполагать, что таблицы Информационной схемы представлены в Definition Schema в том же самом виде, как любые иные таблицы, и потому они сами себя описывают» (стандарт SQL).
Итак, если вы используете СУБД, совместимую со стандартом SQL, и вам хочется узнать что-то о структуре таблицы, к которой у вас есть доступ, то вы сможете воспользоваться обычным оператором SELECT для извлечения нужной вам информации из INFORMATION_SCHEMA.
А как обстоят дела с Большой Тройкой? Ниже приведено несколько цитат из документации каждого из производителей.
«Каждая база данных включает набор таблиц системного каталога, которые описывают логическую и физическую структуру данных. <...> Эти таблицы содержат информацию об определениях объектов баз данных, таких как пользовательские таблицы, представления и индексы, а также относящиеся к безопасности данных сведения о том, какие полномочиями обладают пользователи в отношении этих объектов. Они создаются при создании базы данных и обновляются в ходе нормальной работы. Их нельзя явным образом создать или удалить, но к ним можно обращаться с запросами и просматривать их содержимое, используя представления каталога. <...> По умолчанию полномочия на обращение с оператором SELECT к этим представлениям предоставлены учетной записи PUBLIC» (документация IBM DB2).
«Эти представления определены в специальной схеме под названием INFORMATION_SCHEMA, которая содержится в любой базе данных, но видеть ее можно лишь в базе данных master. Каждое представление INFORMATION_SCHEMA содержит метаданные обо всех объектах данных, хранящихся в этой конкретной базе данных» (документация Microsoft SQL Server).
«В F021, базовой информационной схеме (Basic information schema), у Oracle нет никаких представлений. Однако Oracle делает доступной ту же информацию в других представлениях метаданных... Эти таблицы и представления называются статичными, потому что они меняются только тогда, когда вносится изменение в словарь данных (к примеру, когда создается новая таблица, или когда пользователю предоставляются новые полномочия). К таблицам словаря данных нет прямого доступа, но можно получить доступ к хранящейся в них информации через представления словаря данных» (документация Oracle).
В каждом случае мы видим, что рассматриваемая СУБД предоставляет доступ к метаданным через набор системных представлений, к которым можно обращаться посредством оператора SELECT языка SQL. В SQL Server даже имеется надлежащая структура INFORMATION_SCHEMA, которая требуется стандартным БД SQL.
Но почему же разработчики стандарта — и Большая Тройка — решили, что необходима именно такая конструкция? Ну, они (как всегда) следовали правилам, установленным отцом теории реляционных СУБД.
(Возврат на основную страницу)