Базы данных. Курс лекций

увеличение значения поля «Всего отпущено товара» на значение «Отпущено ед.»; если запись по такому товару в таблице «Статистика по покупателю» отсутствует, она должна быть добавлена;

• отыскание записи по данному покупателю в таблице «Статистика по покупателю»; вычисление стоимости отпущенного товара и увеличение на это значение поля «Всего отпущено»; если запись по такому товару в таблице «Статистика по покупателю» отсутствует, она должна быть добавлена.

Всего_отпущено_товара Всего_отпущено

ТОВАРЫ ПОКУПАТЕЛИ

Товар Покупатель

Ед_измерения Город Цена_за_ед_изм Адрес

НАКЛАДНЫЕ

Номер_накладной

Дата Покупатель (FK)

ОТПУСК ТОВАРОВ СО СКЛАДА

Товар (FK) Номер_накладной (FK)

Отпущено_ед

Рис. 32. Добавление таблиц для накапливания статистики Рассмотрим случай отгрузки товара «Макароны» в количестве 100 кг по це-

не 35 руб. за кг покупателю «Продбаза № 4». Если в рамках транзакции произо-

50

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

Если произошел сбой на добавлении записи в таблицу «Отпуск товаров», выполнение других операций приведет к увеличению статистики в соответствующих таблицах по товару «Макароны» на 3000 кг и по покупателю «Продбаза № 4» на 3500 руб., хотя в действительности сведения о такой отгрузке в таблице «Отпуск товаров» будут отсутствовать.

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

Если произошел сбой при записи в таблицу «Статистика по покупателю», а другие операции завершились успешно, данная таблица будет содержать недостоверные сведения о сумме отпуска товаров покупателю «Продбаза № 4».

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

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

51

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

3.11. Типы таблиц БД по виду их изменения – справочные, операционные и транзакционные

Разные таблицы БД различаются по способу формирования в них информации и по типу их изменения в процессе работы с приложениями, обеспечивающими

Транзакционные таблицы

Всего_отпущено_товара Всего_отпущено

Справочные таблицы

ТОВАРЫ ПОКУПАТЕЛИ

Товар Покупатель

Ед_измерения Город Цена_за_ед_изм Адрес

НАКЛАДНЫЕ

Операционные таблицы

Номер_накладной

Дата Покупатель (FK)

ОТПУСК ТОВАРОВ СО СКЛАДА

Товар (FK) Номер_накладной (FK)

Отпущено_ед

Рис. 33. Типы таблиц в составе базы данных «Отпуск товаров со склада»

52

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

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

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

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

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

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

53

история цен на конкретный товар, в эту таблицу следовало бы добавить два поля «Срок действия цены» (начало периода, конец периода действия цены) или хотя бы одно поле (начало периода действия цены). В нашем примере мы для простоты в таблицу «Товары» механизм истории цен не вводили.

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

Врассматриваемом нами примере в качестве операционных выступают таблицы «Накладные» и «Отпуск товаров со склада». В них ежедневно добавляется информация об отпуске товаров со склада. Занесение данных в эти таблицы вызывает одновременные или периодические изменения в транзакционных таблицах «Статистика по товару» и «Статистика по покупателю».

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

ит. д.).

Внашем примере в качестве транзакционных выступают таблицы «Статистика по товару» и «Статистика по покупателю». Информация в них формируется на основании данных в операционных таблицах «Накладные» и «Отпуск товаров со склада».

3.12.Типы информационных систем по виду накапливания итоговой информации – операционные и накопительные

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

54

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

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

Можно выделить два принципа формирования итоговой информации в информационных системах.

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

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

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

55

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

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

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

3.13. Навигационный и SQL-ориентированный подходы к операциям над данными

Существует два основных подхода к операциям над данными в ТБД. Навигационный подход ориентирован на обработку каждой записи таблицы

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

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

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

56

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

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

По технологии обработки данных базы данных подразделяются на цен-

трализованные и распределенные.

Централизованная база данных хранится в памяти одной вычислительной системы. Эта вычислительная система может быть мэйнфреймом – тогда доступ к ней организуется с использованием терминалов – или файловым сервером локальной сети ПК.

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

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

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

57

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

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

По способу доступа к данным базы данных разделяются на базы данных с

локальным доступом и базы данных с сетевым доступом.

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

Централизованные базы данных с сетевым доступом могут иметь сле-

дующую архитектуру:

•файл-сервер;

•клиент-сервер базы данных;

•«тонкий клиент» – сервер приложений – сервер базы данных (трехуровневая архитектура).

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

58

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

Рис. 35. Схема работы с БД в локальной сети с выделенным файловым сервером

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

Рис. 36. Схема работы с БД в архитектуре «Клиент-сервер»

Трехуровневая архитектура функционирует в интранет- и интернет-сетях. Клиентская часть («тонкий клиент»), взаимодействующая с пользователем, представляет собой HTML-страницу в Web-браузере либо Windows-приложение,

59