1. Введение в базы данных. Основные понятия и определения

2. Реляционные базы данных. Ограничения целостности

3. Принципы построения баз данных. Жизненный цикл баз данных

4. Архитектуры баз данных

5. Организация процессов обработки данных в БД. Технология создания приложения в среде Delphi

6. Технология оперативной обработки транзакции

7. Реляционный способ доступа к базе данных. Основные сведения о языке SQL

8. Построение приложений баз данных в архитектуре «клиент-сервер». SQL-сервер Interbase

9. Информационные хранилища. OLAP-технология

10. Перспективы развития БД и СУБД

1. Введение в базы данных. Основные понятия и определения

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

База данных (БД) — именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области.

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

Система управления базами данных (СУБД) — совокупность языковых и программных средств, предназначенных для создания, наполнения, обновления и удаления баз данных.

Основополагающими понятиями в концепции баз данных являются обобщенные категории «данные» и «модель данных».

Понятие «данные» в концепции баз данных — это набор конкретных значений, параметров, характеризующих объект, условие, ситуацию или любые другие факторы, Примеры данных: Петров Николай Степанович, $30 и т. д. Данные не обладают определенной структурой, данные становятся информацией тогда, когда пользователь задает им определенную структуру, то есть осознает их смысловое содержание. Поэтому центральным понятием в области баз данных является понятие модели. Не существует однозначного определения этого термина, у разных авторов эта абстракция определяется с некоторыми различиями но, тем не менее, можно выделить нечто общее в этих определениях.

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

С помощью модели данных могут быть представлены объекты предметной области и взаимосвязи между ними. В зависимости от вида организации данных различают следующие важнейшие модели БД:

• иерархическую
• сетевую
• реляционную
• объектно-ориентированную

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

В сетевой БД данные организуются в виде графа. Недостатком сетевой структуры является жесткость структуры и сложность ее организации.

Реляционная БД получила свое название от английского термина relation (отношение). Была предложена в 70-м году сотрудником фирмы IBM Эдгаром Коддом. Реляционная БД представляет собой совокупность таблиц, связанных отношениями. Достоинствами реляционной модели данных являются простота, гибкость структуры. Кроме того ее удобно реализовывать на компьютере. Большинство современных БД для персональных компьютеров являются реляционными.

Объектно-ориентированные БД объединяют сетевую и реляционную модели и используются для создания крупных БД с данными сложной структуры.

Базы данных можно разделить на базы данных первого поколения: иерархические, сетевые; второго поколения: реляционные; третьего поколения: объектно-ориентированные, обектно-реляционные.

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

Для поиска информации в базах данных используется информационно-поисковая система. Информационно-поисковая система опирается на базу данных, в которой осуществляется поиск нужных документов по заявкам пользователей.

Различают фактографические автоматизированные информационные системы (АИС), у которых базы данных составляются из форматированных (формализованных) записей, и документальные АИС, записями которых могут служить различные неформализованные документы (статьи, письма и т.п.). В фактографических АИС примером форматированных записей могут служить, скажем, записи об операциях по приему и выдаче денег в сберкассе; запись имеет четыре основных атрибута: дата, характер операции (принято, выдано), сумма, остаток вклада.

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

Основной задачей, решаемой в документальных АИС, является поиск документов по их содержанию. Документальная система по заданию пользователя выдает необходимые ему документы (книги, статьи, законы, патенты, отчеты и т.д.). В задании могут указываться сведения об искомых документах: автор, наименование, время издания, издательство и т.д.

2. Реляционные базы данных. Ограничения целостности

Американский математик Э.Ф.Кодд (E.F.Codd) в 1970 впервые сформулировал основные понятия и ограничения реляционной модели. Цели создания реляционной модели формулировались следующим образом:

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

Коммерческие системы на основе реляционной модели данных начали появляться в конце 70-х – начале 80-х годов. Благодаря популярности реляционной модели многие нереляционные системы теперь обеспечиваются реляционным пользовательским интерфейсом, независимо от используемой базовой модели.

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

Реляционная модель основана на математическом понятии отношения, физическим представлением которого является таблица. Дело в том, что Кодд, будучи опытным математиком, широко использовал математическую терминологию, особенно из теории множеств и логики предикатов.

Отношение – это плоская таблица, состоящая из столбцов и строк.

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

Атрибут - это поименованный столбец отношения.

В реляционной модели отношения используются для хранения информации об объектах, представленных в базе данных. Отношение обычно имеет вид двумерной таблицы, в которой строки соответствуют отдельным записям, а столбцы - атрибутам. При этом атрибуты могут располагаться в любом порядке, независимо от их переупорядочивания, отношение будет оставаться одним и тем же, а потому иметь тот же смысл. Например, информация об отделениях компании может быть представлена отношением Branch, включающим столбцы с атрибутами Вno (Номер отделения), Street (Улица), City (Город), Postcode (Почтовый индекс), Tel_ No (Номер телефона) и Fax_ No (Номер факса). Аналогично, информация о работниках компании может быть представлена отношением Staff (Персонал), включающим столбцы с атрибутами Sno (Личный номер сотрудника), FName (Имя), LName (Фамилия), Address (Адрес), Tel_No (Номер телефона), Position (Должность), Sex (Пол), DOB (Дата рождения), Salary (Зарплата), INN (Личный номер социального страхования) и Вno (Номер отделения, в котором данный сотрудник работает). В табл. 1 и 2 показаны примеры отношений Branch и Staff. Каждый столбец содержит значения одного и того же атрибута, например столбец Вnо содержит только номера существующих отделений компании.

Элементами отношения являются кортежи, или строки, таблицы. Кортеж – это строка отношения. В отношении Branch каждая строка содержит 6 значений, по одному для каждого атрибута. Кортежи могут располагаться в любом порядке, при этом отношение будет оставаться тем же самым, а значит, и иметь тот же смысл.

Примеры отношений Branch и Staff.

Таблица 1. Отношение Branch

Bno	City	Postcode	Street	Tel_No	Fax_No
23	Москва	111111	Победы	1231112	1231113
24	Ростов	3334546	Октябрьская	1334456	1334455
25	Самара	456009	Лесная	1213345	1213346

Таблица 2. Отношение Staff

Sno	FName	LName	Adress	Tel_No	Position	Sex	DOB	Salary	INN	Bno
234	Иван	Иванов	Москва Победы 14-24	121112	Менеджер	м	01.01.67	500$	441414	23
235	Марина	Смирнова	Москва Ленина 215-35	1417877	Менеджер	ж	01.01.75	500$	543243	25

Степень отношения определяется количеством атрибутов, которое оно содержит.

Отношение Branch (см. табл. 1) имеет шесть атрибутов и, следовательно, его степень равна шести. Это значит, что каждая строка таблицы является 6-арным кортежем, т.е. кортежем, содержащим шесть значений. Отношение только с одним атрибутом имеет степень 1 и называется унарным (unary) отношением (или 1-арным кортежем). Отношение с двумя атрибутами называется бинарным (binary), отношение с тремя атрибутами – тернарным (ternary), а для отношений с большим количеством атрибутов используется термин n-арный (n-ary). Определение степени отношения является частью заголовка отношения.

Количество содержащихся в отношении кортежей называется кардинальностью отношения. Эта характеристика меняется при каждом добавлении или удалении кортежей. Кардинальность является свойством тела отношения и определяется текущим состоянием отношения в произвольно взятый момент.

Альтернативная терминология. Терминология, используемая в реляционной модели, порой может привести к путанице, поскольку помимо предложенных терминов существует еще один. Отношение в нем называется таблицей , кортежи – записями (records), а атрибуты – полями (fields). Эта терминология основана на том факте, что физически СУБД может хранить каждое отношение в отдельном файле. В табл. 3 показаны соответствия, существующие между упомянутыми выше группами терминов.

Таблица 3. Альтернативные варианты терминов в реляционной модели

Вариант1	Вариант2
Отношение	Таблица
Кортеж	Запись
Атрибут	Поле

Далее в пособии могут использоваться термины из обоих вариантов.

Фундаментальные свойства отношений (таблиц)

Отношение обладает следующими характеристиками:

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

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

Имена столбцов, указанные в их верхней строке, соответствуют именам атрибутов отношения. Значения атрибута Bno берутся из домена BRANCH_NUMBERS - не допускается размещение в этом столбце иных значений, например почтового индекса. Столбцы можно менять местами при условии, что имя атрибута перемещается вместе с его значениями. Таблица все еще будет представлять то же отношение, если атрибут Tel_No расположить в ней перед атрибутом Postcode, хотя для лучшей читабельности разумнее было бы располагать отдельные части адреса поблизости.

Отношение не может содержать кортежей-дубликатов. Например, строка ( 23, Москва, 111111, Победы, 1231112, 1231113) может быть представлена в отношении только один раз. При необходимости строки можно менять местами произвольным образом (например, переместить строку отделения ‘23’ на место строки отделения ‘24’), само отношение при этом останется прежним.

Большая часть свойств отношений происходит от свойств математических отношений реляционной алгебры.

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

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

Рассмотрим терминологию, используемую при работе с реляционными базами данных.

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

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

Требования, предъявляемые к первичному ключу:

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

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

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

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

Связи между таблицами. Записи в таблице могут зависеть от одной или нескольких записей другой таблицы. Такие отношения между таблицами называются связями. Связь определяется следующим образом: поле или несколько полей одной таблицы, называемое внешним ключом, ссылается на первичный ключ другой таблицы. Рассмотрим пример. Так как каждый заказ должен исходить от определенного клиента, каждая запись таблицы Orders (заказы) должна ссылаться на соответствующую запись таблицы Customers (клиенты). Это и есть связь между таблицами Orders и Customers. В таблице Orders должно быть поле, где хранятся ссылки на те или иные записи таблицы Customers.

Существует три типа связей между таблицами.

Один к одному — каждая запись родительской таблицы связана только с одной записью дочерней. Такая связь встречается на практике намного реже, чем отношение один ко многим и реализуется путем определения уникального внешнего ключа. Связь один к одному используют, если не хотят, чтобы таблица «распухала» от большого числа полей. Базы данных, в состав которых входят таблицы с такой связью не могут считаться полностью нормализованными.

Один ко многим — каждая запись родительской таблицы связана с одной или несколькими записями дочерней. Например, один клиент может сделать несколько заказов, однако несколько клиентов не могут сделать один заказ. Связь один ко многим является самой распространенной для реляционных баз данных.

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

Для рассмотрения ссылочной целостности возьмем в качестве примера наиболее часто встречающуюся в базах данных связь один-ко-многим – см таблицы 4 и 5. Как можно заметить, дочерняя и родительская таблицы связаны между собой по общему полю «Товар». Назовем это поле полем связи.

Таблица 4. Таблица «Товары»

Товар	Ед изм	Цена
Сахар	кг	18
Макароны	кг	18
Куры	кг	90
Фанта	бут	20

Таблица 5. Таблица «Отпуск товаров»

Товар	Дата	Количество
Сахар	10.12.07.	100
Сахар	12.12.07.	200
Сахар	14.12.07	50
Макароны	10.12.07	1000
Макароны	12.12.07	500
Фанта	07.12.07	2000
Фанта	05.12.07	3000

Возможны два вида изменений, которые приведут к утере связей между записями в родительской и дочерней таблицах:

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

Рассмотрим первый случай. Если изменить значения поля «Товар» с «Сахар» на «Рафинад» в таблице «Товары», а в таблице «Отпуск товаров» значение поля связи «Сахар» оставить прежним. В результате получим:

• в дочерней таблице «Отпуск товаров» для товара «Рафинад» (таблица «Товары») нет сведений о его отпуске со склада;
• некоторые записи таблицы «Отпуск товаров» содержат сведения об отпуске товара «Сахар», о котором нет информации в таблице «Товары».

Рассмотрим второй случай. Пусть в одной из записей таблицы «Отпуск товаров» значение поля связи «Сахар» изменилось на «Рафинад». В результате:

• в дочерней таблице «Отпуск товаров» недостоверны сведения об отпуске со склада товара «Сахар» (таблица «Товары»);
• одна из записей таблицы «Отпуск товаров» содержит данные об отпуске товара «Рафинад», сведения о котором отсутствуют в таблице «Товары».

И в первом, и втором случае мы наблюдаем нарушение целостности базы данных; это означает, что хранящаяся в ней информация становится недостоверной.

СУБД обычно блокирует действия, которые нарушают целостность связей между таблицами, т.е. нарушают ссылочную целостность. Когда говорят о ссылочной целостности, имеют в виду совокупность связей между отдельными таблицами во всей БД. Нарушение хотя бы одной такой связи делает информацию в БД недостоверной.

Чтобы предотвратить потерю ссылочной целостности, используется механизм каскадных изменений. Он состоит в обеспечении следующих действий:

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

Изменения или удаления в записях дочерней таблицы при одновременном изменении (удалении) записи родительской таблицы называются каскадными изменениями и каскадными удалениями.

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

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

3. Принципы построения баз данных. Жизненный цикл баз данных

Классическая технология проектирования реляционных баз данных связана с теорией нормализации, основанной на анализе функциональных зависимостей между атрибутами отношений. Процесс нормализации имеет своей целью устранение избыточности данных. Нормализация позволяет существенно сократить объем хранимой информации и устранить аномалии в организации хранения данных. Степень нормализации данных может быть различной. Приведение модели к требуемому уровню нормальной формы является основой построения реляционной базы данных.

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

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

Неделимость поля означает, что содержащиеся в нем значения не должны делиться на более мелкие. Например, если в поле «Подразделение» содержится название факультета и кафедры, требование неделимости не соблюдается и необходимо выделить название факультета или кафедры в отдельное поле.

Повторяющимися являются поля, содержащие одинаковые по смыслу значения. Например, если требуется получить статистику продаж четырех товаров по месяцам, можно создать поля для хранения данных о продаже по каждому товару. Однако что делать, если товаров не 4, а 104, и как быть, если количество товаров заранее не известно? Повторяющиеся группы следует устранить, сохранив в таблице единственное поле «Товар». В результате получим запись, содержащую информацию о статистике продаж по одному товару, но этот товар может быть любым.

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

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

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

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

Таблицы базы данных до нормализации

В этом примере предполагается, что:

• студент может записаться на любое число курсов;

• лекторы могут вести несколько курсов;

• каждый лектор всегда проводит занятия в одной и той же аудитории;

• в каждой аудитории читается только один курс.

Пусть для хранения этих сведений используются следующие Таблицы.

Таблица 6. Students (студенты)

Name (имя)	Phoneno (телефон)	CourseRegistrations (посещаемые курсы)
Maijorie Green	415986	Basic Computing, Database Administration
Bun Gringelsby	707938	Database Administration, Advanced Hardware Support
Anico Yokamoto	415935	Advanced Hardware Support

Таблица 7. Courses (курсы)

Course (курс)	Lecturer (лектор)	Room (аудитория)
Basic Computing	Meander Smith	542 South
Database Administration	Dean Straight	221 East
Advanced Hardware Support	Dean Straight	221 East

В этом случае появляются следующие логические противоречия:

• если курсBasic Computing будет закрыт, из таблицы будет удален лектор Meander Smith и аудитория 542 South;
• число курсов, на которые может записаться студент, ограничено длиной записи которую допускает поле Course Registrations;
• трудно выполнять поиск значений в поле Course Registrations, а также использовать его в вычислениях;
• в каждой регистрационной записи повторяется полное название курса. В результате неэффективно используется пространство и растет вероятность появления несогласованных данных, если название курса введено с ошибками. Кроме того, при изменении названия курса потребуется проводить поиск и обновление всех регистрационных записей;
• таблицу Students невозможно индексировать по фамилии, так как в поле name хранятся полные имена студентов;
• если лектор сменит аудиторию, придется обновить сведения обо всех преподаваемых им курсах.

Проведем нормализацию

Таблицы базы данных после нормализации

Таблица 8. Students (студенты)

StudentsID(код студента)	Firstname (имя)	Lastname (фамилия)	Phoneno (телефон)
1001	Maijorie	Green	415986
1002	Bun	Gringelsby	707938
1003	Anico	Yokamoto	415935

Таблица 9. Регистрационные записи (Registrations)

RegID (код записи)	StudentsID(код студента	Courses (курсы)
1	1001	1
2	1002	2
3	1003	3
4	1004	4
5	1005	5

Таблица 10. Courses (курсы)

Course ID(курс)	Course (курс)	LecturerID (код лектора)
1	Basic Computing	1
2	Database Administration	2
3	Advanced Hardware Support	3

Таблица 11. Lecturers (лектор)

LecturerID (код лектора)	Firstname (имя)	Lastname (фамилия)	Room (аудитория)
1	Meander	Smith	542 South
2	Dean	Straight	221 East

Между таблицами существуют следующие связи:

Students (студенты) — Courses (курсы): отношение «многие ко многим» через промежуточную таблицу Registrations (регистрационные записи), другими словами это отношение сведено к двум отношениям «один ко многим»;

Students (студенты) — Registrations (регистрационные записи): отношения «один ко многим»;

Courses (курсы) — Registrations (регистрационные записи): отношение «один ко многим»;

Lecturers (лекторы) — Courses (курсы): отношение «один ко многим».

Очевидные преимущества нормализации этих таблиц:

• каждая таблица содержит только один набор связанных данных. Например, в таблице Students теперь нет сведений о посещаемых курсах;
• в каждой таблице имеется первичный ключ: в таблице Students — это поле StudentID, в таблице Registrations — RegID, в таблице Courses — CourseID и в таблице Lecturers — LecturerW,
• отсутствуют составные поля. Каждое поле описывает только один атрибут. Например, поле, содержавшее имя и фамилию студента, разбито на отдельные поля, которые содержат имя и фамилию студента;
• отсутствуют повторяющиеся данные. Так, теперь имена лекторов записываются только один раз;
• отсутствуют поля, содержащие несколько значений. Например, каждая регистрационная запись курса теперь расположена в отдельной строке таблицы Registrations. Для сравнения взгляните на поле Course Registrations (посещаемые курсы) предыдущего варианта таблицы Students;
• каждое поле полностью зависит от первичного ключа. Например, в таблице Courses нет поля Room. Это связано с тем, что аудитория зависит не от кода курса (CourseID), а от кода лектора (LecturerID).

Вот основные преимущества нормализации:

• облегчается сортировка и создание индекса, поскольку таблицы стали более компактными;
• индексы становятся более компактными;
• меньшее число индексов в одной таблице позволяет быстрее выполнять обновления записей;
• в таблицах содержится меньше значений NULL и избыточных данных, что повышает компактность базы данных;
• уменьшается вероятность конфликтов блокировок таблиц, поскольку блокировать приходится ограниченные наборы данных.

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

Рис. 1. Этапы жизненного цикла БД

Процесс проектирования БД представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели. Можно выделить следующие этапы проектирования:

1. Системный анализ и словесное описание информационных объектов предметной области.
2. Проектирование инфологической модели предметной области - частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ЕR-модели.
3. Даталогическое или логическое проектирование БД, то есть описание БД в терминах принятой дата логической модели данных.
4. Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

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

Рис. 2. Этапы проектирования БД

4. Архитектуры баз данных

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

Появление сетей ЭВМ позволило наряду с централизованными создавать и распределенные базы данных. Распределенная база данных состоит из нескольких, возможно, пересекающихся или даже дублирующих друг друга частей, хранимых в различных ЭВМ вычислительной сети. Однако пользователь распределенной базы данных не обязан знать, каким образом ее компоненты размещены в узлах сети, и представляет себе эту базу данных как единое целое. Работа с такой базой данных осуществляется с помощью системы управления распределенной базой данных (СУРБД). Данные, содержащиеся в распределенной базе данных, их представление на всех уровнях архитектуры СУРБД и размещение в сети описываются в системном справочнике, который сам может быть декомпозирован и размещен в различных узлах сети.

Части распределенной базы данных, размещенные на отдельных ЭВМ сети, управляются собственными (локальными) СУБД и могут использоваться одновременно как самостоятельные локальные базы данных. Локальные СУБД не обязательно должны быть одинаковыми в разных узлах сети. Объединение неоднородных локальных баз данных в единую распределенную базу данных является сложной научно-технической проблемой. Ее решение потребовало проведения большого комплекса научных исследований и экспериментальных разработок.

По способу доступа к данным базы данных разделяются на базы данных с локальным доступом и базы данных с удаленным (сетевым) доступом.

Системы централизованных баз данных с сетевым доступом предполагают различные архитектуры подобных систем:

• файл-сервер;
• клиент-сервер.

Файл-сервер. Данная архитектура систем БД предполагает выделение одной из машин сети в качестве центральной (сервер файлов). На такой машине хранится совместно используемая централизованная БД. Все другие машины сети выполняют функции рабочих станций, с помощью которых поддерживается доступ пользовательской системы к централизованной базе данных. Каждый пользователь может запускать приложение, расположенное на сервере, при этом на компьютере пользователя запускается копия приложения. Файлы базы данных в соответствии с пользовательскими запросами передаются на рабочие станции, где в основном производится обработка. Когда пользователь сети работает с БД, на его компьютере появляется локальная копия общей БД. Эта копия периодически обновляется данными, содержащимися в БД, расположенной на сервере. Архитектура файл-сервер обычно используется в таких сетях, где имеется немного компьютеров. Для ее реализации предназначены персональные СУБД, например Paradox и DBase. При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает.

Клиент-сервер. В этой концепции подразумевается, что помимо хранения централизованной БД сервер базы данных должен обеспечивать выполнение основного объема обработки данных. Технология клиент-сервер разделяет приложение на две части: клиентскую и серверную. Клиентская обеспечивает интерактивный интерфейс, сервер обеспечивает управление данными, разделение информации, администрирование и безопасность. Для получения данных приложение-клиент формирует и отсылает запрос удаленному серверу, на котором размещена БД. Запрос формируется на языке SQL, который является стандартом доступа к серверу при использовании реляционных баз данных. После получения запроса удаленный сервер направляет его SQL-серверу (серверу баз данных). SQL-сервер – это программа, которая управляет удаленной БД и обеспечивает выполнение запроса и выдачу клиенту его результатов – требуемых данных. Вся обработка запроса выполняется на удаленном сервере. Для реализации архитектуры клиент-сервер обычно применяются многопользовательские СУБД, например Qracle, MS SQL Server, InterBase и др. Подобные СУБД называют промышленными, так как они позволяют организовать информационную систему, состоящую из большого числа пользователей.

5. Организация процессов обработки данных в БД. Технология создания приложения в среде Delphi

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

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

В терминах системы Delphi набор данных – это совокупность записей, взятых из одной или нескольких таблиц баз данных. Записи, включаемые в набор, данных отбираются по определенным правилам. Набор данных является логической таблицей, с которой можно работать при выполнении приложения. Взаимодействие таблицы и набора данных напоминает взаимодействие физического файла и файловой переменной. Для выполнения операций с наборами данных используются два способа доступа к данным: навигационный и реляционный.

Навигационный способ доступа заключается в обработке каждой отдельной записи набора данных. Этот способ обычно используется в локальных БД или в удаленных БД небольшого размера. При навигационном способе доступа каждый набор данных имеет невидимый указатель текущей записи. Указатель определяет запись, с которой могут выполняться такие операции, как редактирование или удаление. Поля текущей записи доступны для просмотра. Например, компоненты DBEdit и DBText; отображают содержимое соответствующих полей именно текущей записи. Компонент DBGrid указывает текущую запись с помощью специального маркера.

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

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

Средства для работы с реляционными базами данных.Хотя система Delphi не имеет своего формата таблиц БД, она тем не менее обеспечивает мощную поддержку большого количества различных СУБД — как локальных (например, dBase или Paradox), так и промышленных (например, Sybase или InterBase). Средства Delphi, предназначенные для работы с БД, можно разделить на два вида:

• инструменты

• компоненты

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

Напомним, что в Delphi имеется окно Обозревателя дерева объектов, которое отображает иерархическую структуру объектов текущей формы. При разработке приложений баз данных это окно удобно использовать для просмотра структуры базы данных и изменения связей между компонентами. Кроме того, в окне Редактора кода имеется вкладка Diagram служащая для отображения и настройки взаимосвязей между элементами баз данных.

Технология создания информационной системы. Продемонстрируем возможности Delphi по работе с БД на примере создания простой информационной системы. Эту информационную систему можно разработать даже без написания кода: все необходимые операции выполняются с помощью программы Database Desktop, Конструктора формы и Инспектора объектов. Работа над информационной системой состоит из следующих основных этапов:

• создание БД;

• создание приложения.

Кроме приложения и БД, в информационную систему также входят вычислительная система и СУБД. Предположим, что компьютер или компьютерная сеть уже существуют, и их характеристики удовлетворяют потребностям будущей информационной системы. В качестве СУБД выберем Delphi.

В простейшем случае БД состоит из одной таблицы. Если таблицы уже имеются, то первый этап не выполняется. Отметим, что совместно с Delphi.поставляется большое количество примеров приложений, в том числе и приложений БД. Готовые таблицы также можно использовать для своих приложений.

Для работы с таблицами БД при проектировании приложения удобно использовать программу Database Desktop, которая позволяет:

• создавать таблицы;

• изменять структуры;

• редактировать записи.

Кроме того, с помощью Database Desktop можно выполнять и другие действия над БД (создание, редактирование и выполнение визуальных и SQL-запросов, операций с псевдонимами).

Для примера рассмотрим создание приложения, использующего механизм доступа ВDЕ и позволяющего перемещаться по записям таблицы БД, просматривать и редактировать поля, удалять записи из таблицы, а также вставлять новые. Файл проекта приложения обычно не требует от разработчика выполнения каких-либо действий. Поэтому при создании приложения главной задачей является конструирование форм, в простейшем случае — одной формы.

Компонент Table обеспечивает взаимодействие с таблицей БД. Для связи с требуемой таблицей нужно установить в соответствующие значения свойство DataBaseName, указывающее путь к БД, и свойство TableName, указывающее имя таблицы. После задания таблицы для открытия набора данных свойство Active должно быть установлено в значение True.

В рассматриваемом приложении использована таблица клиентов, входящая в состав поставляемых с Delphi примеров, ее главный файл – Clients.dbf Файлы этой и других таблиц примеров находятся в каталоге, путь к которому указывает псевдоним dbdemos. Настройка псевдонима может быть выполнена с помощью программы BDE Administrator.

Компонент DataSourse1 является промежуточным звеном между компонентом Table, соединенным с реальной таблицей БД, и визуальными компонентами DBGrid и DBNavigator, с помощью которых пользователь взаимодействует с этой таблицей. На компонент Table1, с которым связан компонент DataSourse1, указывает свойство DataSet последнего.

Компонент DBGrid1 отображает содержимое таблицы БД в виде сетки, в которой столбцы соответствуют полям, а строки — записям таблицы. По умолчанию пользователь может просматривать и редактировать данные. Компонент DBNavigator1позволяет пользователю перемещаться по таблице, редактировать, вставлять и удалять записи. Компоненты DBGrid1 и DBNavigator1 связываются со своим источником данных -компонентом DataSourse1 через свойства DataSourse. Взаимосвязь компонентов приложения и таблицы БД и используемые при этом свойства компонентов показаны на рис. 3.

Разрабатывая приложение, можно задавать значения всех свойств компонентов с помощью Инспектора объектов. При этом требуемые значения либо непосредственно вводятся в поле, либо выбираются в раскрывающихся списках. В последнем случае приложение создается с помощью мыши и не требует набора каких-либо символов на клавиатуре. В табл. 12 приведены компоненты, используемые для работы с таблицей БД, их основные свойства и значения этих свойств.

Рис. 3. Взаимосвязь компонентов приложения и таблицы БД

Таблица 12. Значения свойств компонентов

Компонент	Свойства	Значения
Table1	DataBaseName	dbDemos
	TableName	Client.dbf
	Active	True
DataSource1	DataSet	Table1
DBGrid1	DataSource	DataSource1
DBNavigator1	DataSource	DataSource1

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

Для автоматизации процесса создания формы, использующей компоненты для операций с БД, можно вызвать Database Form Wizard (Мастер форм баз данных). Этот Мастер расположен на странице Business Хранилища объектов.

Мастер позволяет создавать формы для работы с отдельной таблицей и со связанными таблицами, при этом можно использовать наборы данных Table или Query.

6. Технология оперативной обработки транзакции

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

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

Цель проектирования транзакций заключается в определении и документировании высокоуровневых характеристик всех транзакций, которые должны будут выполняться в разрабатываемой базе данных. Эту работу следует выполнить еще на начальной стадии проектирования, что позволит обеспечить поддержку всех требуемых транзакций со стороны логической модели данных. При этом очень важно, чтобы характеристики всех транзакций были зафиксированы в документации. Существует несколько методов описания высокоуровневых характеристик транзакций. Наиболее важные из них следующие:

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

Имеется три основных типа транзакций: транзакции извлечения, транзакции обновления и смешанные транзакции.

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

Транзакции обновления используются для вставки новых, удаления старых или же изменения уже существующих записей базы данных. Примером транзакции обновления является внесение в базу подробных сведений о новом объекте недвижимости.

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

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

Любая транзакция всегда должна переводить базу данных из одного согласованного состояния в другое, хотя допускается, что согласованность состояния базы будет нарушаться в ходе выполнения транзакции. Любая транзакция завершается одним из двух возможных способов. В случае успешного завершения результаты транзакции фиксируются (commit) в базе данных, последняя переходит в новое согласованное состояние. Если выполнение транзакции не увенчалось успехом, она отменяется. В этом случае в базе данных должно быть восстановлено то согласованное состояние, в котором она находилась до начала данной транзакции. Этот процесс называется откатом (roll back) транзакции. Зафиксированная транзакция не может быть отменена. Если оказывается, что зафиксированная транзакция была ошибочной, потребуется выполнить другую транзакцию, отменяющую действия, выполненные первой транзакцией. Эту транзакцию называют компенсирующей. Следует отметить, что отмененная транзакция может быть еще раз запущена позже и в зависимости от причин предыдущего отказа вполне успешно завершена и зафиксирована в базе данных.

Никакая СУБД не обладает внутренней возможностью установить, какие именно изменения должны быть восприняты как единое целое, образующее одну логическую транзакцию. Следовательно, должен существовать метод, позволяющий указывать границы каждой из транзакций извне, со стороны пользователя. В большинстве языков манипулирования данными для указания границ отдельных транзакций используются операторы BEGIN TRANSACTION, COMMIT и ROLLBACK (или их эквиваленты). Если эти ограничители не были использованы, вся выполняемая программа расценивается как единая транзакция. СУБД автоматически выполнит команду COMMIT при нормальном завершении этой программы. Аналогично в случае ее аварийного завершения в базе данных автоматически будет выполнена команда ROLLBACK.

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

• Атомарность. Это свойство типа “все или ничего”. Любая транзакция представляет собой неделимую единицу работы, которая может быть либо выполнена вся целиком, либо не выполнена вовсе.
• Согласованность. Каждая транзакция должна переводить базу данных из одного согласованного состояния в другое согласованное состояние.
• Изолированность. Все транзакции выполняются независимо одна от другой. Другими словами, промежуточные результаты незавершенной транзакции не должны быть доступны другим транзакциям.
• Продолжительность. Результаты успешно завершенной (зафиксированной) транзакции должны сохраняться в базе данных постоянно и не должны быть утеряны в результате последующих сбоев.

СУБД, созданная для поддержки оперативной обработки транзакций называется OLTP-системой (Online Transaction Processing). Обычно OLTP-системы проектируются с целью обеспечения максимально интенсивной обработки транзакций. Организация обычно имеет несколько различных OLTP-систем, предназначенных для поддержки таких бизнес-процессов, как контроль товарных запасов, выписка счетов клиентам, продажа товаров. Эти системы генерируют оперативные данные, которые являются очень подробными, текущими и подверженными изменениям. OLTP-системы оптимизированы для интенсивной обработки транзакций, которые проектируются заранее, многократно повторяются и связаны преимущественно с обновлением данных. В соответствии с этими особенностями данные в OLTP-системах организованы согласно требованиям конкретных бизнес-приложений и позволяют принимать повседневные решения большому количеству параллельно работающих пользователей-исполнителей.

7. Реляционный способ доступа к базе данных. Основные сведения о языке SQL

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

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

Появление теории реляционных баз данных и предложенного Коддом Э.Ф. языка запросов “alpha”, основанного на реляционном исчислении, инициировало разработку ряда языков запросов, которые можно отнести к двум классам:

1. Алгебраические языки запросов – языки, позволяющие выражать запросы средствами специализированных операторов, применяемых к отношениям (JOIN – соединить, INTERSECT – пересечь, SUBTRACT – вычесть и т.д.).
2. Языки исчисления предикатов – набор правил для записи выражения, определяющего новое отношение из заданной совокупности существующих отношений.

Из всех этих языков полностью сохранились и развиваются QBE (Query By Example) и SQL (Structured Query Language), а из остальных взяты в расширение внутренних языков СУБД только наиболее интересные конструкции. В начале 1980-х годов SQL “победил” другие языки запросов и стал фактическим стандартом таких языков для профессиональных реляционных СУБД

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

Недавно принятый стандарт ANSI SQL-92 расширяет возможности встроенных SQL-операторов и позволяет включить динамический SQL. И в интерактивной и во встроенной формах SQL имеются многочисленные части, или субподразделения. К сожалению, эти термины не используются повсеместно во всех реализациях. Они подчеркиваются ANSI и полезны на концептуальном уровне, но большинство SQL программ практически не обрабатывают их отдельно, так что они, по существу, становятся функциональными категориями команд SQL. DDL (Data Definition Language – язык определения данных) – так называемый язык описания схемы в стандарте ANSI, состоит из команд, которые создают объекты (таблицы, индексы, просмотры и т.д.) в базе данных. DML (Data Manipulation Language – язык манипулирования данными) – это набор команд, которые определяют, какие значения представлены в таблицах в любой момент времени. DCL (Data Control Language – язык управления данными) – комплекс средств, которые определяют, разрешить ли пользователю выполнять определенные действия или нет.

Реализация в SQL концепции операций, ориентированных на табличное представление данных, позволило создать компактный язык с небольшим (менее 30) набором предложений. Как в интерактивном, так и в встроенном SQL существуют следующие предложения:

• предложения определения данных (определение баз данных, а также определение и уничтожение таблиц и индексов);

• запросы на выбор данных (предложение SELECT);

• предложения модификации данных (добавление, удаление и изменение данных);

• предложения управления данными (предоставление и отмена привилегий на доступ к данным, управление транзакциями и другие).

Кроме того, SQL предоставляет возможность выполнять в этих предложениях следующее:

• арифметические вычисления (включая разнообразные функциональные преобразования), обработку текстовых строк и выполнение операций сравнения значений арифметических выражений и текстов;

• упорядочение строк и (или) столбцов при выводе содержимого таблиц на печать или экран дисплея;

• создание представлений (виртуальных таблиц), позволяющих пользователям иметь свой взгляд на данные без увеличения их объема в базе данных;

• запоминание выводимого по запросу содержимого таблицы, нескольких таблиц или представления в другой таблице (реляционная операция присваивания).

• агрегирование данных: группирование данных и применение к этим группам таких операций, как среднее, сумма, максимум, минимум, число элементов и т.п.

Основные типы данных SQL – используемые языком SQL основные типы данных, форматы которых могут несколько различаться для разных СУБД: целое число; десятичное число; вещественное число; символьная строка фиксированной или переменной длины; дата в формате (по умолчанию mm/dd/yy); время в формате (по умолчанию hh.mm.ss); деньги в формате, определяющем символ денежной единицы и его расположение (суффикс или префикс) и др.

Таблицы создаются командой CREATE TABLE. Эта команда создает структуру таблицы. Значения вводятся с помощью DML команды INSERT (см. далее). Команда CREATE TABLE в основном определяет имя таблицы в виде описания набора имен столбцов, указанных в определенном порядке. Она также определяет типы данных и размеры столбцов. Cинтаксис команды CREATE TABLE будет следующим:

CREATE TABLE базовая_таблица (столбец тип_данных [,столбец тип_данных] ...);

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

Предложение для создания следующее:

CREATE INDEX ON (имя_столбца[,] ...);

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

Представления (View) – это таблицы, чье содержание выбирается или получается из других таблиц. Они работают в запросах и операторах DML точно так же, как и базовые таблицы, но не содержат никаких собственных данных. Представление создается командой CREATE VIEW. Она состоит из слов CREATE VIEW (создать представление), имени представления, которое нужно создать, слова AS (как) и, далее, запроса.

Синтаксис предложения CREATE VIEW имеет вид:

CREATE VIEW имя_представления

[(столбец[,столбец] ...)]

AS подзапрос;

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

Предложение SELECT выглядит следующим образом:

SELECT [ DISTINCT]

<Список полей > или *

FROM < Список таблиц>

[WERE<Условие отбора>]

[ORDER BY <Список полей для сортировки >]

[GROUP BY < Список полей для группирования>]

[HAVING <Условия группирования >]

[UNION<Вложенный оператор SELECT>]

Критерий отбора строк формируется из одного или нескольких условий, соединенных логическими операторами:

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

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

• AND NOT – когда должно удовлетворяться первое условие и не должно – второе;

• OR NOT – когда или должно удовлетворяться первое условие, или не должно удовлетворяться второе.

Операторы языка манипулирования данными DML управляют значениями, представляемыми в таблицах. Значения могут быть помещены и удалены из полей тремя операторами языка DML: INSERT (вставить), UPDATE (модифицировать), DELETE (удалить).

В языке SQL также имеется возможность изменения таблицы после того, как она была создана. Команда ALTER TABLE используется, чтобы изменить определение существующей таблицы. Обычно она добавляет столбцы к таблице. Иногда она может удалять столбцы или добавлять в (удалять из) определение таблицы новые (существующие) ограничения. Типичный синтаксис, чтобы добавить столбец к таблице:

ALTER TABLE имя_таблицы

ADD имя_столбца;

8. Построение приложений баз данных в архитектуре «клиент-сервер». SQL-сервер Interbase

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

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

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

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

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

При работе в архитектуре "клиент-сервер" приложение должно:

• устанавливать соединение с сервером и завершать его;

• формировать и отсылать запрос серверу, получая от него результаты выполнения запроса;

• обрабатывать полученные данные.

При этом обработка данных не имеет принципиальных отличий по сравнению с обработкой данных в локальных БД.

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

• триггеры;

• генераторы;

• хранимые процедуры;

• функции, определяемые пользователем;

• механизм транзакций;

• механизм кэшированных изменений;

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

Система Delphi обеспечивает разработку приложений для различных серверов, предоставляя для этого соответствующие средства. Отметим, что многие описанные ранее принципы разработки приложений и средства для работы с локальными БД относятся и к работе с удаленными БД. В частности, для разработки приложений используются такие компоненты, как источник данных DataSource,_наборы данных Table, ADOTable, SQLTable, IBTable, Query, ADOQuery, SQLQuery, сетка DBGrid и др.

Для реализации реляционного способа доступа к удаленной БД с помощью BDE необходимо использовать только средства языка SQL. Поэтому в качестве компонентов должны выбираться такие как Query, StoredProc, UpdateSQL. Кроме того, для набора данных нельзя использовать методы, характерные для навигационного способа доступа.

Напомним, что если при выполнении модифицирующего БД запроса с помощью компонента Query не нужен результирующий набор данных, то этот запрос предпочтительнее выполнять с помощью метода ExecSQL. Для работы с таблицами и запросами по-прежнему можно использовать такие программы, как Database Desktop и SQL Explorer.

Средства Delphi, предназначенные для работы с удаленными БД, можно разделить на два вида: инструменты и компоненты.

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

• InterBase Server Manager - программа управления запуском сервера InterBase;

• IBConsole - консоль сервера InterBase;

• SQL Monitor - программа отслеживания порядка выполнения SQL-запросов к удаленным БД.

Компоненты предназначены для создания приложений, выполняющих операции с удаленной БД. Перечислим наиболее важные из них:

• Database (соединение с БД);

• Session (текущий сеанс работы с БД);

• StoredProc (вызов хранимой процедуры);

• UpdateSQL (модификация набора данных, основанного на SQL-запросе);

• DCOMConnection (DСОМ-соединение);

• компоненты страниц АDО, dbExpress, Interbase Палитры компонентов.

Отметим, что многие из названных компонентов, например, Database, Session, UpdateSQL, используются также при работе с локальными БД. Так, компонент Database позволяет, реализовать механизм транзакций при навигационном способе доступа к данным с помощью механизма ВDЕ. Однако наиболее часто эти компоненты применяются именно при работе с удаленными базами. Часть компонентов, например, клиентский набор данных ClientDataSet и соединение с сервером DCOMConnection, предназначена для работы в трехуровневой (трехзвенной) архитектуре "клиент-сервер" ("тонкий" клиент) и используется для построения сервера приложений.

В основе операций, выполняемых с удаленными БД как с помощью инструментов, так и программно, лежит язык SQL. Например, при создании таблицы с помощью программы IBConsole необходимо набрать и выполнить SQL-запрос (инструкцию) Create Table. Если создание таблицы с помощью механизма ВDЕ осуществляется из приложения пользователя, то для этой цели используется набор данных Query, который выполняет такой же запрос. Основное различие заключается в том, каким образом выполняется SQL-запрос к удаленной БД.

Итак, для удаленных БД разница между средствами, используемыми в приложении, и инструментами намного меньше, чем для локальных баз данных.

Сервер InterBase.Все серверы имеют похожие принципы организации данных и управления ими. В качестве примера рассмотрим работу с сервером InterBase 6.x, который является "родным" для_Delphi. Совместно с Delphi поставляются две части сервера InterBase 6.x: серверная и клиентская. Серверная часть InterBase является локальной версией сервера InterBase и используется для отладки приложений, предназначенных для работы с удаленными БД, позволяя на одном компьютере проверить их в сетевом варианте. После отладки на локальном компьютере приложение можно перенести на сетевые компьютеры без изменений, для чего нужно:

• скопировать БД на сервер;

• установить для приложения новые параметры соединения с удаленной БД.

Скопировать БД можно с помощью программ типа Проводник Windows. Клиентская часть нужна для обеспечения доступа приложения к удаленной БД.При разработке БД и приложений с использованием локальной версии сервера InterBase нужно иметь в виду, что она имеет ряд ограничений и может не поддерживать, например, механизм событий сервера или определяемые пользователем функции. Полнофункциональная версия сервера InterBase приобретается и устанавливается отдельно от Delphi.Как упоминалось, в основе работы с удаленной БД лежат возможности языка SQL, обеспечивающие соответствующие операции. Назначение и возможности языка SQL для удаленных БД в принципе совпадают с назначением и возможностями этого языка для локальных БД.

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

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

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

Для программирования бизнес-правил в приложении используются компоненты и их средства. Достоинство такого подхода заключается в легкости изменения бизнес-правил и возможности определить правила "своего" приложения. Недостатком является снижение безопасности БД, связанное с тем, что каждое приложение может устанавливать свои правила управления БД.

Информация всей БД сервера InterBase хранится в одном файле с расширением gdb. Размер этого файла может составлять единицы и даже десятки гигабайт. Отметим, что аналогичный размер БД имеет СУБД Microsoft SOL Server, в то время как для более мощных СУБД Oracle и SyBase размер БД достигает десятков и сотен гигабайт.

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

Элементы структуры удаленной БД также называют метаданными. Слово "мета" имеет смысл "над", т. е. метаданные представляют собой данные, которые описывают структуру БД. Для InterBase максимальное число таблиц в БД равно 65 536, а максимальное число столбцов в таблице - 1000. Отметим, что таблицы InterBase имеют меньшее число допустимых типов столбцов (полей), чем таблицы локальных БД Paradox.

Домен представляет собой именованное описание столбца. После определения домена его имя можно использовать для описания других столбцов. Аналогом домена является тип данных.

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

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

• вместо текста запроса серверу передается по сети короткое обращение к хранимой процедуре;

• хранимая процедура не требует предварительной синтаксической проверки.

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

Функция, определяемая пользователем, представляет собой обычную функцию, написанную на алгоритмическом языке, например, Pascal. Созданная функция оформляется в виде динамической библиотеки DLL, откуда может быть вызвана обычным способом. Для обеспечения вызова функции системе Windows должен быть известен путь к соответствующей библиотеке. Использование таких функций расширяет состав функций языка SQL.

Механизм кэшированных изменений заключается в том, что на компьютере клиента в кэше (буфере) создается локальная копия данных, и все изменения в данных выполняются в этой копии. Для хранения локальной копии используется специальный буфер (кэш). Сделанные изменения можно подтвердить, перенеся их в основную БД, хранящуюся на сервере, или отказаться от них. Этот механизм напоминает механизм транзакций, но, в отличие от него, снижает нагрузку на сеть, т. к. все изменения передаются в основную БД одним пакетом. Следует иметь к виду, что для всех записей локальной копии отсутствуют блокировки на изменение их значений. Блокировки могут быть установлены другими приложениями для основной БД, находящейся на сервере. Механизм кэшированных изменений реализуется в приложении, для чего компоненты, в первую очередь Database, Table и Query (используемые при доступе с помощью BDE), имеют соответствующие средства. Кроме того, механизм кэшированных изменений поддерживается предназначенным для этого компонентом UpdateSQL.Основные достоинства рассматриваемого механизма проявляются для удаленных БД, но его можно использовать и при работе с локальными БД.

Привилегии представляют собой права доступа к БД. Управление привилегиями заключается в их установке и удалении. После создания объекта БД (например, таблицы) доступ к ней разрешен только создателю и системному администратору, имеющему имя SYSDBA. Для доступа к БД остальных пользователей им нужно назначить соответствующие привилегии. Сразу после появления нового пользователя, созданного например, с помощью программы InterBase Manager Server , этот пользователь имеет минимальные права доступа: ему разрешено только войти в БД (соединиться с ней), указав свое имя и пароль, однако ни один объект этой БД ему не доступен. Чтобы обеспечить возможность активной работы с БД, нужно определить (переопределить) привилегии.

Установку привилегий выполняет инструкция Grant. Привилегии позволяют разграничить доступ к таблицам и просмотрам со стороны пользователей. При этом под "пользователем" понимается любой объект, обращающийся к данным. Кроме собственно пользователя (приложения), такими объектами могут быть таблицы, просмотры, хранимые процедуры и триггеры. Если привилегия предоставляется одновременно нескольким пользователям, то их имена перечисляются через запятую.

9. Информационные хранилища. OLAP-технология

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

Наиболее упорным и удачливым сторонником технологии хранилищ данных оказался Билл Инмон (Bill Inmon), который за активное продвижение этой концепции был удостоен почетного титула “отца – основателя хранилищ данных”. Хранилище данных – предметно-ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для поддержки принятия решений.

В определении Инмона указанные характеристики данных понимаются следующим образом.

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

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

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

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

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

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

Термин “OLAP” был предложен Коддом в 1993 году и определяет архитектуру, которая поддерживает сложные аналитические приложения. Большинство OLAP- приложений создается на основе специализированных многомерных СУБД или ММ СУБД (multi-dimensional DBMS) с ограниченным набором данных и настраиваемым пользовательским интерфейсом приложений. OLAP-архитектура предусматривает определенные уровни с четким разделением функций между приложением и СУБД. На основе этого разделения появилось новое поколение OLAP-инструментов, предоставляющих такие возможности, которые позволяют обычным СУБД конкурировать со специализированными технологиями ММ СУБД.

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

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

средний_доход_на_сотрудника = общий_доход / количество_сотрудников.

Рассмотрим проблемы обеспечения OLAP-системы данными, что напрямую связано со складами данных (Datawarehouse). Любая крупная и давно существующая корпорация обладает несколькими базами данных, относящимися к разным видам деятельности. Данные могут иметь разные представления, а иногда могут быть даже несогласованными (например, из-за ошибки ввода в одну из баз данных). Это нехорошо даже для OLTP-систем (выше уже говорилось о все более часто возникающих потребностях в интеграции корпоративных информационных OLTP-систем) и в принципе непригодно для OLAP-систем, которые должны обрабатывать общие исторические согласованные корпоративные данные. Более того, для оперативной аналитической обработки требуется привлечение внешних источников данных, которые тем более могут обладать разными форматами и требовать согласования. Видимо, на подобных рассуждениях и возникла концепция склада данных как предметно-ориентированного, интегрированного, неизменчивого, поддерживающего хронологию набора данных, организованного для целей поддержки управления.

В основе концепции склада данных лежат две основные идеи:

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

2. Разделение наборов данных, используемых для оперативной обработки, и наборов данных, применяемых для решения задач анализа.

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

Как было сказано выше, проблемой больших информационных хранилищ является то, что накладные расходы на внешнюю память возрастают нелинейно при возрастании объема хранилища. Следовательно, встает проблема архивации данных. Одним из современных направлений и разработок в этой области является применение фрактальных методов в архивации. Понятия фрактал и фрактальная геометрия, появившиеся в конце 70-х, с середины 80-х прочно вошли в обиход математиков и программистов. Слово фрактал образовано от латинского fractus и в переводе означает состоящий из фрагментов. Оно было предложено Бенуа Мандельбротом в 1975 году для обозначения нерегулярных, но самоподобных структур, которыми он занимался.

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

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

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

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

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

Одни из наиболее мощных приложений фракталов лежат в компьютерной графике. Во-первых, это фрактальное сжатие изображений, и, во-вторых, построение ландшафтов, деревьев, растений и генерирование фрактальных текстур. Достоинства алгоритмов фрактального сжатия изображений - очень маленький размер упакованного файла и малое время восстановления картинки. Фрактально упакованные картинки можно масштабировать без появления пикселизации. Но процесс сжатия занимает продолжительное время и иногда длится часами. Алгоритм фрактальной упаковки с потерей качества позволяет задать степень сжатия, аналогично формату jpeg. В основе алгоритма лежит поиск больших кусков изображения подобных некоторым маленьким кусочкам. И в выходной файл записывается только какой кусочек какому подобен. При сжатии обычно используют квадратную сетку (кусочки - квадраты), что приводит к небольшой угловатости при восстановлении картинки, шестиугольная сетка лишена такого недостатка.

Применение фрактальных методов в архивации помогает решать проблемы сжатия больших объемов информационных массивов.

10. Перспективы развития БД и СУБД

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

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

Приведем некоторые преимущества, которые часто цитируются в поддержку объектно-ориентированного подхода.

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

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

Использование классов и механизма наследования способствует разработке повторно используемых и расширяемых компонентов при создании новых или модернизации существующих систем.

ООСУБД появились сначала в инженерно-конструкторских приложениях и только недавно получили признание у разработчиков финансовых и телекоммуникационных приложений. Хотя доля рынка ООСУБД все еще остается очень маленькой , тем не менее ООСУБД продолжают находить все новые области применения, например в World Wide Web. Действительно, по оценкам некоторых аналитиков, рынок ООСУБД ежегодно будет возрастать на 50%, что выше темпов роста всего рынка баз данных в целом.

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

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

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

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

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

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

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

• "нормальные" типы данных в базе данных (которые можно встретить в реляционной или сетевой базе данных или даже в поддерживаемых самим приложением плоских файлах);

• данные неподвижных изображений, как в фотографиях;

• другие типы графики;

• данные движущихся изображений (видео);

• аудио (т.е. голос, музыкальные звуки, звуки, издаваемые животными);

• текстовые данные, например такие, которые можно найти в документах текстовых процессоров или файлах электронных таблиц.

Итак, мы обсудили систему доставки и информационную базу. Рассмотрим теперь коммуникационную инфраструктуру. Общее правило большого пальца относительно поддержки требований мультимедийных информационных систем заключается в следующем: "Чем больше используется "оживших" данных, тем более широкая необходима полоса пропускания". Под "ожившими" мы понимаем здесь такие данные, как видео- или высококачественные (например, стерео) аудиоданные. Такие данные действительно не только занимают огромные объемы пространства памяти, если не используется техника сжатия данных (на одну минуту не слишком качественного видео при передаче 15 кадров в секунду, что составляет лишь половину телевизионной скорости, потребовалось бы 117 Мбайт памяти15), но требуют также для своей поддержки сетей с высокой пропускной способностью. Это справедливо и для локальных сетей ЭВМ, и для глобальных распределенных сред. Потребности адекватной поддержки крупномасштабной передачи полного спектра мультимедийных типов данных привели к появлению глобальных сетевых технологий (Wide Area Networking, WAN), например таких, как асинхронный режим передачи данных или переключаемый мулътимегабитовый сервис данных.

Один из простых мнемонических способов выражения требований, удовлетворение которых обеспечивает полноценное использование мультимедийной среды на настольном компьютере, состоит в принципе "4-х Г": гигабайт основной памяти, как минимум, гигабайт внешней памяти, гига операций в секунду и гигабит в секунду - скорость передачи данных. При столь быстрых темпах прогресса в области технологий технических средств, к которым мы стали привыкать, такая базовая технология, без сомнения, появится.

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

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

Гипертекстовые БД. Публикация баз данных в Интернете — это размещение информации из баз данных на Web-страницах сети. Отметим, что такая публикация связана с решением следующих типичных задач, встающих перед разработчиками современного программного обеспечения:

• организация взаимосвязи СУБД, работающих на различных платформах;

• построение информационных систем в Интернете на основе многоуровневой архитектуры БД (архитектура таких систем включает дополнительный уровень - Web-сервер с модулями расширения серверной части, который и реализует возможность информационного обмена и публикации БД в глобальной сети);

• построение локальных интранет-сетей на основе технологии публикации БД в Интернете (локальные сети строятся на принципах Интернета с выходом при необходимости в глобальную сеть);

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

• применение БД для упорядочивания (каталогизирования) информации (огромный объем данных, представленных в Интернете, не обладает требуемой степенью структурированности, что делает процесс поиска необходимой информации весьма сложным и долгим);

• применение языка SQL для поиска необходимой информации в БД;

• использование средств СУБД для обеспечения безопасности данных, разграничения доступа и управления транзакциями при создании Интернет-магазинов, защищенных информационных систем и т. д.;

• стандартизация пользовательского интерфейса на основе применения Web-обозревателей с типовым внешним видом пользовательского интерфейса и его типовой реакцией на действия пользователя;

• использование Web-обозревателя в качестве дешевой клиентской программы для доступа к БД.

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

В Интернете вся информация размещается на Web-страницах, для написания которых используются язык HTML (Hyper Text Markup Language - язык разметки гипертекста) или его расширения, такие как DHTML (Dynamic – динамический HTML) и XML ( eXtensible Markup Language - расширяемый язык разметки). В состав Web-страницы могут входить текстовая информация, ссылки на другие Web-страницы, графические изображения, аудио- и видеоинформация и другие данные. Web-страницы хранятся на Web-сервере.

Для доступа к Web-страницам используются специальные клиентские программы – Web-обозреватели (программы просмотра, называемые также Web -браузерами или Web -броузерами — от англ. browser), находящиеся на компьютерах пользователей. Обозреватель формирует запрос на получение требуемой страницы или другого ресурса с помощью специального адреса URL (Uniform Recourse Locator — универсальный указатель ресурса). Этот адрес определяет тип протокола для передачи ресурса, имя домена, используемое для доступа к Web-узлу, номер порта, локальный путь к файлу и дополнительные аргументы. Соединение с Web-узлом устанавливается с помощью протокола передачи данных HTTP (Hyper Text Transfer Protocol - протокол передачи гипертекста).

Как отмечалось, расширяемый язык разметки XML представляет собой развитие языка HTML и по сравнению с ним обеспечивает ряд дополнительных возможностей. Главное отличие XML от HTML заключается в том, что он позволяет определить структуру документа и типы хранимых в нем данных. Напомним, что одно из достоинств XML состоит в том, что в разрабатываемых с его помощью документах описание структуры хранимых данных отделено от собственно данных. В связи с этим XML представляет собой удобное средство обмена данными между отдельными приложениями, т. к. позволяет обеспечить согласованный обмен данными в случаях, когда структуры данных (например, имена и типы полей) в приложениях различаются.

Кроме того, с помощью XML можно упростить доступ к данным, хранимым в базах данных. Например, для доступа к данным персональных БД или табличного процессора Excel пользователю требуется установить соответствующие программные инструменты. Вместо этого можно создать активные серверные или сценарии на языке JScript или VBScript, которые будут извлекать данные из БД и помещать их в документ XML. В дальнейшем информацию из полученного таким образом документа XML можно использовать в других приложениях или отображать на Web-страницах. Т. е. полученные данные становятся доступными для всех пользователей, имеющих обозреватель, независимо от наличия СУБД или табличного процессора. Документы XML могут использоваться как на стороне клиента, так и на стороне сервера.