Текст книги "Основы AS/400"

Автор книги: Фрэнк Солтис

сообщить о нарушении

Текущая страница: 16 (всего у книги 41 страниц)

Управление хранилищем данных

Метаданные – это данные о данных. Они используются для управления хранилищем данных. Существуют две формы метаданных – технические и бизнес-данные. Первые содержат описания оперативной базы данных и хранилища данных, что позволяет перемещать данные из оперативной базы в хранилище.

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

Теперь, после рассмотрения способов использования новых технологий баз данных AS/400, мы можем перейти к фундаментальным концепциям DB2/400. Сначала рассмотрим историю этой замечательной базы данных.

Эволюция реляционной базы данных

Первая коммерческая база данных с реляционными возможностями появилась в System/38. Эта уникальная технология опережала другие реляционные базы примерно на три года, что позволило System/38 выйти на передовые позиции на рынке.

Разработчики System/38 искали более эффективный способ обработки записей, по сравнению с System/3. Первая System/3 была разработана как машина единичных записей. Она поддерживала только пакетную обработку, то есть приложение должно было обработать все записи в файле одну за другой. Первые записи размещались на перфокартах, колода перфокарт составляла файл. Позднее, появилась возможность хранения файлов на диске, хотя обрабатывались они по-прежнему с помощью перфокарт.

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

Позднее в System/3 была добавлена интерактивная обработка. Применение дисков позволило обращаться к записям в произвольном порядке. Поиск нужной записи осуществлялся с помощью индекса – небольшого файла, в котором каждой записи основного файла соответствуют лишь два поля. Первое содержит значение ключа, а второе – дисковый адрес записи с совпадающим значением. Для сортировки записей индекса по значениям ключа использовалась особая программа. Затем индекс сохранялся на диске вместе с основным файлом.

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

System/34 была первой моделью семейства System/3, предназначенной для работы в интерактивном, а не в пакетном режиме. Размеры памяти в System/34 были также невелики, так что IBM решила ускорить поиск нужной записи в индексе, а для этого – устранить необходимость считывать индекс с диска.

Часть дорожек диска была зарезервирована для индекса, для контроллера диска была разработана специальная аппаратура. Желаемое значение ключа процессор передавал дисковому контроллеру. Затем контроллер начинал считывать информацию дорожки, отыскивая значение ключа. Обнаружив искомое, аппаратура контроллера считывала следующее поле адреса и возвращала его процессору. Процессор использовал полученный адрес для считывания целой записи из некоторой другой части диска.

Эта операция была названа сканированием. Функция сканирования значительно повысила эффективность интерактивной обработки, благодаря полному устранению этапа обращения к диску для считывания индекса. Но при этом потребовалось встроить в памяти еще один небольшой индекс. Индекс в памяти указывал, на какой индексной дорожке диска следует выполнять поиск. Позднее аналогичная операция сканирования была реализована в System/36 для обработки файлов.

Для System/38 также была важна очень высокая эффективность интерактивной обработки. Недостатком описанной процедуры сканирования была ее слишком тесная привязка к аппаратуре. Были также и другие ограничения: максимально возможное число индексов, ограничение способов их обработки и др. Так как System/38 должна была иметь одноуровневую память, разработчики решили поместить все файлы и индексы в эту большую память.

Если вернуться назад к только что описанной файловой структуре, то мы увидим двумерную таблицу, где строки —это записи, а столбцы – поля записей. Разработчики посчитали, что наиболее эффективным будет организовать файл System/38 просто как двумерную таблицу в памяти. Они также полагали, что производительность обработки повысится, если таблицу обрабатывать «на месте» без сортировки записей. Чтобы добиться этого, они встроили индекс в таблицу так, что сортировка просто не требуется (подробнее об этом – далее, в разделе «Машинные индексы»). По сути, предполагалось, что в System/38 никогда не будет программы сортировки.

Однако, такая программа была и есть. Ее написал Дик Бэйнс, назвав «Conversion Reformat Utility», вероятно, чтобы скрыть ее сущность и предотвратить использование прикладными программистами в новых проектах[ 50 ]50
  Бессмыслица, что-то вроде «утилита переформатирования преобразования». – Прим. консультанта.


[Закрыть]. Эта программа, тем не менее, была – а, может быть, есть и по сей день – самым быстрым способом сортировки и выборки записей из больших файлов. Джим Слоан (Jim Sloan), бывший разработчик и проектировщик, участвовавший в создании компилятора CL, разработал в составе своего набора QUSRTOOL утилиту для пользователей, интерфейс которой к этой программе сортировки позволял использовать внешние имена полей.

В процессе разработки базы данных Перри Тейлор (Perry Taylor) случайно наткнулся на технический отчет Е. Ф. Кодда (E. F. Codd). Кодд, который считается создателем реляционной базы данных, работал над проектом System/R (R – реляционная) в исследовательском центре IBM в Калифорнии. Базой в определении Кодда была двумерная таблица, над которой можно было выполнять четыре элементарных операции. Первая операция – упорядочение (order) – позволяла обрабатывать строки или столбцы в определенном порядке по ключевому полю; вторая – выборка (selection) – выбирать записи по значению ключевого поля; третья – проекция (projection) – осуществлять выборку из таблицы заданных полей; и наконец, четвертая – соединение (join) —рассматривать несколько таблиц как одну большую. Таким образом, реляционная база данных представляла собой просто двумерную таблицу с операциями упорядочения, выборки, проекции и соединения.

Перри сразу же понял, что разработчики System/38 строят очень похожую базу данных, за исключением того, что в ней нет соединения. Он позвонил Кодду, чтобы сообщить о работах в Рочестере и предложить свою поддержку. Но Кодд ответил, что, по его мнению, реляционные базы данных предназначены только для больших систем; а малым нужны только функции сортировки и слияния. По словам Перри, разговор не был сердечным. Тон Кодда он сравнил с тоном полицейских во время перекрестного допроса их защитниками на процессе О. Дж. Симпсона (O. J. Simpson) – вежливый, но холодный. Кодд и Тейлор больше никогда не разговаривали.

Через три года после объявления System/38 база данных System/R была объявлена как DB2 и признана в качестве первой реляционной базы данных[ 51 ]51
  После ухода из Рочестера Том Фьюри стал генеральным менеджером группы разработки DB2. В то время DB2 собиралась отмечать свою десятую годовщину, пресс-релизы с гордостью называли ее первой реляционной базой данных. Тому пришлось напомнить, что первой была база данных System/38.


[Закрыть]. Так как первоначально System/38 не поддерживала операции соединения, то она считается первой коммерческой базой данных с реляционными возможностями.

Двуликая база данных

Говоря о базе данных, мы имеем в виду не просто некоторое место для размещения данных. Мы говорим о системе управления базой данных. СУБД – среда для хранения и выборки данных, включающая определения данных, правила обеспечения их целостности и механизмы поддержания, а также операции сохранения и выборки данных. СУБД должна иметь интерфейс, чтобы пользователи могли работать с ней. В этом разделе мы представим два интерфейса СУБД AS/400: DDS (Data Description Specifications) и SQL (Structured Query Language), в следующих разделах – детально рассмотрим саму СУБД.

Когда IBM начинала проект System/38, стандартных интерфейсов к реляционной базе данных не существовало. Поэтому проектировщикам пришлось разработать собственный уникальный интерфейс для этой системы. Не удивительно, что этот интерфейс DDS очень похож на файловую систему, которую должен был заменить. Создатели интерфейса ограничились несколькими системными командами и функциями управления базой данных, а также ввели в MI команды для таких операций как чтение, запись, обновление и удаление. Программисты могли непосредственно использовать эти команды из таких языков как RPG и Cobol. Например, многие используют DDS-RPG: DDS для определений данных, RPG для доступа к ним. Интерфейс DDS перешел из System/38 в AS/400, и многие по-прежнему предпочитают его. Бывшим пользователям мэйнфреймов, перешедшим на AS/400, он также нравится, поскольку очень похож на интерфейс базы данных для больших систем IBM – IMS (Information Management System).

Примерно в то же время, когда разрабатывалась AS/400, в IBM и других фирмах выполнялись проекты по стандартизации SQL (из System/R) в качестве языка реляционных баз данных. Проект продвигался не слишком гладко, на создание стандарта потребовалось около десятилетия. Ingres многие годы использовала язык-соперник QUEL, пока, наконец, тоже не поддалась общей тенденции. Появившаяся в 1988 году AS/400 поддерживала и собственный интерфейс DDS, и SQL. Операторы SQL могут включаться непосредственно в программы на RPG, Cobol и С, заменяя «родные» команды, такие как чтение, запись и обновление. Для трансляции этих операторов SQL DB2/400 содержит прекомпиляторы.

При более внимательном взгляде становится видно, что DB2/400 состоит из двух отдельных частей. Собственно СУБД и язык DDS входят в состав OS/400. Query Manager and SQL Development Kit – особый продукт, приобретаемый отдельно. Как следует из названия, этот продукт содержит Query Manager – ПО AS/400 для конечного пользователя, позволяющее выдавать запросы на SQL. В состав продукта входят кроме того интерактивный пользовательский интерфейс к SQL (Interactive SQL), а также прекомпиляторы для различных языков, используемые при вставке операторов SQL в ЯВУ. К несчастью сложилось так, что IBM требует от Вас платить за SQL отдельно, тогда как DDS входит в состав OS/400. Такая ситуация – основная причина непопулярности SQL у многих пользователей AS/400, считающих его внешним продуктом, каковым он на самом деле не является. Сегодня большинство разработчиков баз данных в Рочестере думают в терминах SQL, а не DDS. Интерфейс DDS будет поддерживаться и далее, но новые функции, скорее всего, будут в SQL.

Хотя AS/400 и поддерживает два разных интерфейса к базе данных, крайне важно понимать, что сама база данных только одна. Доступ к данным, определение данных и манипуляции с ними на AS/400 возможны как посредством DDS, так и посредством SQL. Так как интерфейс SQL использует те же команды MI, что и DDS, каждый из интерфейсов может работать с объектами данных, созданных посредством другого интерфейса. Эта возможность смешения двух интерфейсов обеспечивает базе данных AS/400 дополнительные мощь и гибкость.

Самая большая проблема двух интерфейсов состоит в путанице, вызываемой терминологическими различиями. Как и в случае различий имен между объектами OS/ 400 и системными объектами MI, имена для разных интерфейсов базы данных подбирались разными группами. Например, в интерфейсе DDS имеются физические файлы, содержащие данные. Как мы видели ранее, физический файл – это двумерная таблица. В интерфейсе SQL тот же самый физический файл называется таблицей, что больше подходит для этой структуры. Логический файл в интерфейсе DDS не содержит данные, а указывает на реальные данные и дает программе некоторую их проекцию. В SQL логический файл называется проекцией (view). Аналогично, то, что в терминологии DDS – запись и поле, в интерфейсе SQL – строка и столбец (чтобы отразить концепцию таблицы).

Как функционирует база данных

В этом разделе мы рассмотрим различные компоненты базы данных AS/400. Я не ставил здесь перед собой задачу проинструктировать Вас, как использовать эту базу данных. Уже есть целый ряд хороших книг, посвященных внешним аспектам базы данных и использованию двух ее интерфейсов в программах[ 52 ]52
  Моя любимая книга на эту тему—Paul Conte. Database Design and Programming for DB2/400. Duke Press .1997. Настоятельно рекомендую!


[Закрыть]. А я лишь хочу предложить Вам обзор характеристик СУБД и основ ее функционирования.

Раздел состоит из двух частей. В первой содержится описание основных функций, которые должны присутствовать в каждой СУБД, и их реализации в AS/400. Во второй – обзор других характеристик базы данных, некоторые из которых имеют отношение к производительности, а другие обеспечивают поддержку использования AS/400 в качестве сервера базы данных. После этого мы поговорим о внутренней реализации некоторых фундаментальных функций базы данных.

Функции СУБД

Есть много способов реализации реляционной базы данных, но любая система управления ею должна предоставлять следующие семь функций:

определение и описание таблиц базы данных;

операции управления данными (вставка, выборка, обновление и удаление);

возможность определить, что представляют собой данные независимо от программы;

возможность создавать новые проекции данных для удовлетворения изменяющихся требований прикладных программ;

множественные проекции данных для разных прикладных программ;

защита данных;

целостность данных.

Теперь посмотрим, как эти функции реализованы в AS/400.

Описание данных и создание файлов

Для описания физических и логических файлов базы данных можно использовать «родной» язык СУБД AS/400 – DDS. Он содержит операторы, ключевые слова и параметры, позволяющие описывать как атрибуты самого файла, так и полей записей базы данных. DDS можно также применять для описания файлов устройств, используемых AS/400. Эти файлы устройств содержат информацию о формате и типах данных, используемых подключенными к системе физическими устройствами.

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

Операторы DDS помещаются в разделах исходных файлов, которые затем превращаются в файловые объекты с помощью команд OS/400 «CRTPF» («Create Physical File») и «CRTLF» («Create Logical File»). Для описания атрибутов файлов базы данных можно использовать и SQL. В отличие от DDS, представляющего собой только язык описания данных, один оператор SQL и описывает, и создает таблицы и проекции (view). В SQL определение файла неотделимо от команды создания. Например, оператор SQL «Create table» задает имя таблицы, имена столбцов (полей) и их атрибуты. Кроме того, при исполнении этого оператора создается и сама таблица.

Создание физических файлов и таблиц

Физические файлы или, в терминологии SQL, таблицы содержат собственно данные. Запись физического файла имеет фиксированный набор полей. Каждое поле может иметь (хотя и не часто) переменную длину. В терминологии SQL таблица содержит строки фиксированной длины со столбцами переменной длины[ 53 ]53
  Чтобы избежать полной путаницы, я использую, где возможно, более привычную для пользователей AS/400 терминологию «родного» интерфейса, за исключением случаев, когда описывается реализация именно SQL.


[Закрыть].

Физический файл состоит из двух частей. В первой находятся атрибуты файла и описания полей. В набор атрибутов файла входят его имя, владелец, размер, число записей, ключевые поля и некоторые другие характеристики. Описания полей задают атрибуты для каждого поля записей.

Вторая часть физического файла содержит собственно данные. Она может состоять из одного или нескольких разделов, позволяющих подразделять файл. Все записи во всех разделах обязательно имеют один и тот же формат. Это удобный способ разделения записей: например, информацию текущего месяца можно поместить в один раздел, а информацию прошлого – в другой. Каждый раздел имеет уникальное имя, которое можно использовать для доступа к записям. Таблицы SQL могут состоять только из одного раздела, что соответствует самой сути реляционной модели: все данные хранятся в двумерных таблицах. Файлы же имеющие несколько разделов – трехмерные.

Для создания физического файла используется системная команда «CRTPF». Она создает физический файл по операторам из исходного файла. Вновь созданный физический файл не содержит записей данных, для их добавления необходимо использовать отдельную программу или утилиту.

Как было отмечено ранее, оператор определения данных SQL также создает таблицу. Оператор «Create table» можно выполнить с помощью Query Manager, Interactive SQL, или вставив его в программу на ЯВУ. Таблица, созданная этим оператором, является физическим файлом, идентичным созданному с помощью «родного» интерфейса.

Создание логических файлов и проекций

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

Структура логического файла может быть как очень простой, так и очень сложной. Логические файлы и проекции можно подразделить на четыре категории. Перечислю их.

Простые логические файлы и проекции, которые отображают данные из одного физического файла или таблицы на другое описание логических записей.

Многоформатные логические файлы, обеспечивающие доступ к нескольким физическим файлам, каждый из которых имеет собственный формат записей. Данный тип логического файла может быть создан только с помощью «родного» интерфейса; с помощью SQL его создать нельзя.

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

Проекции SQL (view), которые похожи на логические файлы объединения и дают те же результаты, но реализованы совершенно иначе. Файлы объединения хранят путь доступа для каждого объединения. Проекции же SQL определяют пути доступа во время исполнения, руководствуясь хранящимся внутри шаблоном определения запроса (Query Definition Template).

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

Для создания логического файла используется системная команда «CRTLF». Она использует операторы DDS в исходном файле для создания логического файла. Операторы DDS в исходном файле задают имена одного или нескольких физических файлов, служащих основой для логического. Созданный логический файл содержит относительные номера записей данных из одного или нескольких физических файлов.

Оператор SQL «Create view» задает таблицу, представляемую проекцией, вместе с описанием столбцов проекции. Результат создания проекции – логический файл, идентичный создаваемому при использовании «родного» интерфейса.

Логические файлы выполняют три операции: форматирование, включая проекцию, объединение и создание производных полей (field derivation); выборку записей; упорядочение. Логический файл, созданный с помощью DDS, может осуществлять все три операции. Файл, созданный с помощью SQL, может выполнять либо форматирование (проекция SQL), либо упорядочение (индекс SQL), но не обе сразу. На SQL нельзя создать проекций, выделяющих подмножество записей физического файла. Проекция SQL может быть создана с помощью DDS, но DDS обычно не используется для создания файлов, имеющих только возможности проекций SQL.