Информационные системы / ИС_Тема04

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

Эти стратегии являются стандартными и присутствуют во всех СУБД, в которых имеется поддержка ссылочной целостности.

Можно рассмотреть дополнительные стратегии поддержания ссылочной целостности:

•SET NULL (УСТАНОВИТЬ В NULL) - разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на nullзначения. Эта стратегия имеет два недостатка. Во-первых, для нее требуется допустить использование null-значений. Во-вторых, кортежи дочернего отношения теряют всякую связь с кортежами родительского отношения. Установить, с каким кортежем родительского отношения были связаны измененные кортежи дочернего отношения, после выполнения операции уже нельзя.

•SET DEFAULT (УСТАНОВИТЬ ПО УМОЛЧАНИЮ) - разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на некоторое значение, принятое по умолчанию. Достоинство этой стратегии по сравнению с предыдущей в том, что она позволяет не пользоваться nullзначеними. Недостатки заключаются в следующем. Во-первых, в родительском отношении должен быть некий кортеж, потенциальный ключ которого принят как значение по умолчанию для внешних ключей. В качестве такого "кортежа по умолчанию" обычно принимают специальный кортеж, заполненный нулевыми значениями (не null-значениями!). Этот кортеж нельзя удалять из родительского отношения, и в этом кортеже нельзя изменять значение потенциального ключа. Таким образом, не все кортежи родительского отношения становятся равнозначными, поэтому приходится прилагать дополнительные усилия для отслеживания этой неравнозначности. Это плата за отказ от использования null-значений. Во-вторых, как и в предыдущем случае, кортежи дочернего отношения теряют всякую связь с кортежами родительского отношения. Установить, с каким кортежем родительского отношения были связаны измененные кортежи дочернего отношения, после выполнения операции уже нельзя.

Внекоторых реализация СУБД рассматривается еще одна стратегия поддержания ссылочной целостности:

•IGNORE (ИГНОРИРОВАТЬ) - выполнять операции, не обращая внимания на нарушения ссылочной целостности.

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

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

Применение стратегий поддержания ссылочной целостности

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

21

При обновлении кортежа в родительском отношении

Допустимые стратегии:

RESTRICT (ОГРАНИЧИТЬ) - не разрешать обновление, если имеется хотя бы один кортеж в дочернем отношении, ссылающийся на обновляемый кортеж.

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

SET NULL (УСТАНОВИТЬ В NULL) - выполнить обновление и во всех кортежах дочернего отношения, ссылающихся на обновляемый кортеж, изменить значения внешних ключей на null-значение.

SET DEFAULT (УСТАНОВИТЬ ПО УМОЛЧАНИЮ) - выполнить обновление и во всех кортежах дочернего отношения, ссылающихся на обновляемый кортеж, изменить значения внешних ключей на некоторое значение, принятое по умолчанию.

IGNORE (ИГНОРИРОВАТЬ) - выполнить обновление, не обращая внимания на нарушения ссылочной целостности.

При удалении кортежа в родительском отношении

Допустимые стратегии:

RESTRICT (ОГРАНИЧИТЬ) - не разрешать удаление, если имеется хотя бы один кортеж в дочернем отношении, ссылающийся на удаляемый кортеж.

CASCADE (КАСКАДИРОВАТЬ) - выполнить удаление и каскадно удалить кортежи в дочернем отношении, ссылающиеся на удаляемый кортеж.

SET NULL (УСТАНОВИТЬ В NULL) - выполнить удаление и во всех кортежах дочернего отношения, ссылающихся на удаляемый кортеж, изменить значения внешних ключей на null-значение.

SET DEFAULT (УСТАНОВИТЬ ПО УМОЛЧАНИЮ) - выполнить удаление и во всех кортежах дочернего отношения, ссылающихся на удаляемый кортеж, изменить значения внешних ключей на некоторое значение, принятое по умолчанию.

IGNORE (ИГНОРИРОВАТЬ) - выполнить удаление, не обращая внимания на нарушения ссылочной целостности.

При вставке кортежа в дочернее отношение

Допустимые стратегии:

RESTRICT (ОГРАНИЧИТЬ) - не разрешать вставку, если внешний ключ во вставляемом кортеже не соответствует ни одному значению потенциального ключа родительского отношения.

SET NULL (УСТАНОВИТЬ В NULL) - вставить кортеж, но в качестве значения внешнего ключа занести не предлагаемое пользователем некорректное значение, а nullзначение.

SET DEFAULT (УСТАНОВИТЬ ПО УМОЛЧАНИЮ) - вставить кортеж, но в качестве значения внешнего ключа занести не предлагаемое пользователем некорректное значение, а некоторое значение, принятое по умолчанию.

22

IGNORE (ИГНОРИРОВАТЬ) - вставить кортеж, не обращая внимания на нарушения ссылочной целостности.

При обновлении кортежа в дочернем отношении

Допустимые стратегии:

RESTRICT (ОГРАНИЧИТЬ) - не разрешать обновление, если внешний ключ в обновляемом кортеже становится не соответствующим ни одному значению потенциального ключа родительского отношения.

SET NULL (УСТАНОВИТЬ В NULL) - обновить кортеж, но в качестве значения внешнего ключа занести не предлагаемое пользователем некорректное значение, а nullзначение.

SET DEFAULT (УСТАНОВИТЬ ПО УМОЛЧАНИЮ) - обновить кортеж, но в качестве значения внешнего ключа занести не предлагаемое пользователем некорректное значение, а некоторое значение, принятое по умолчанию.

IGNORE (ИГНОРИРОВАТЬ) - обновить кортеж, не обращая внимания на нарушения ссылочной целостности.

4.5.5. Основные компоненты реляционной базы данных

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

Не все из перечисленных компонент поддерживаются современными СУБД.

Таблицы

Таблицы предназначены для хранения данных.

В столбцах таблиц располагаются данные следующих типов.

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

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

Currency (Валюта). Специальный тип числового поля используется для представления "валютных" данных.

Dates (Даты). Любую конкретную дату можно задать целым числом, например, количеством дней от Рождества Христова.

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

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

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

Индексы

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

23

Индекс (index) представляет собой список позиций записей, который показывает порядок их следования.

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

Например, записи в таблице Продукт в некий момент времени располагаются в порядке, приведенном в табл. 4.1.

Таблица 4.2. представляет эти данные, упорядоченные по значениям поля Название. Таблица 4.2

Таким образом, индекс поля Название таблицы Продукт определяется последовательностью номеров позиций 1, 6, 2, 5, 4, 3. Индекс для поля Код продукта будет другим: 3, 2, 6, 1, 4, 5.

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

Если необходимо вывести данные о продуктах, название которых начинается с символа "м", используя при этом поле Название как индекс, мы можем найти позицию этих записей в индексе (в данном случае, 6 и 2), а затем выбрать эти записи из базы данных, не просматривая всю таблицу. Таким образом, использование индексов снижает время, необходимое на выборку данных.

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

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

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

24

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

Некоторые типы полей, например memo-и BLOB-поля, не могут быть проиндексированы.

Ограничения

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

Ограничение (constraint) — это условие, которому должны удовлетворять возможные значения, хранящиеся в поле.

Существуют следующие типы ограничений

•ограничение по сущностям

•ограничение по ссылкам

•пользовательские ограничения

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

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

Представления

Представление — это виртуальная таблица, обычно создаваемая как подмножество столбцов из одной и более таблиц.

Представление является всего лишь описанием и не содержит каких-либо записей.

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

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

Курсоры

Программное обеспечение обычно принимает данные в виде набора строк. Обычно этот набор строк идентичен таблице.

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

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

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

курсором.

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

Хранимые процедуры и триггеры

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

25

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

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

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

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

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

Объекты для генерации первичных ключей

Очень часто СУБД генерируют первичные ключи.

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

Такие объекты поддерживаются, в частности в Oracle (где они называются

последовательностями) и в InterBase (где они именуются генераторами).

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

Пользователи и роли

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

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

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

Некоторые системы управления базами данных типа клиент/сервер также поддерживают роли. Роль (role) представляет собой набор разрешений (grants) и привилегий (priveleges). Если роль предоставляется определенному пользователю, он автоматически получает все права, предусмотренные данной ролью.

Системный каталог

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

26

В некоторых СУБД (dBase и Paradox) нет системного каталога. В этом случае списки таблиц получают через операционную систему и ее средств выбора имен файлов.

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

Запросы

Запрос (query) — это требование модификации или выборки данных.

Одним из популярных способов манипулирования данными является создание запросов по образцу (Query By Example — QBE). QBE состоит из визуального связывания таблиц и последующего выделения полей, которые должны быть получены по данному запросу.

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

Транзакции

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

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

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

Транзакция должна отвечать следующим требованиям, именуемым ACID-свойствами. Элементарность или атомарность (Atomicity). Свойство атомарности означает, что транзакция должна выполняться как единая операция доступа к БД. Она должна быть выполнена полностью либо не выполнена совсем. То есть должны быть выполнены все операции манипулирования данными, которые входят в транзакцию, либо, если по каким-то причинам выполнение части операций невозможно, ни одна из операций не должна выполняться. Свойство атомарности обычно коротко выражают фразой: "все или ничего".

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

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

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

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

27

SQL

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

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

SQL-операторы можно разделить на несколько категорий.

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

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

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

4.Операторы языка управления транзакциями, используемые для управления изменениями, производимыми группой операторов языка манипулирования данными.

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

4.6. Объектная модель данных

Объектно-ориентированные СУБД стали разрабатываться с середины 80-х годов в основном для поддержки приложений систем автоматизированного проектирования (САПР).

Сложные структуры данных САПР оказалось очень удобно представлять в виде объектов. Если связи типичные для реляционной базы данных имеют глубину в два уровня, то информация чертежей САПР обычно включает порядка десяти уровней, что требует достаточно сложных операций для “сборки” результата.

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

•понятие сложных объектов,

•идентификация объектов,

•классы и типы

•инкапсуляция,

•наследование.

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

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

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

Класс — это некоторый шаблон для построения объектов, обладающих одинаковым состоянием и поведением.

Классы обладают свойствами и методами.

28

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

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

Наследование. О наследовании говорят, когда класс объектов порождается из другого класса. Порожденный класс находится со своим родительским классом в отношении «класс

— есть подкласс родительского класса» и наследует все свойства и методы родительского класса.

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

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

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

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

•организации не уверены, что затраты, связанные с переходом на объектные базы данных, окупятся

•сопровождение реляционных баз данных не требует от администраторов БД знания языков программирования, а только языка SQL/

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

•объектно-реляционный адаптер

•объектно-реляционный шлюз

•гибридные объектно-реляционные СУБД

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

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

И, наконец, гибридных объектно-реляционных СУБД, являются еще одним решением, которое позволяет хранить данные как в виде реляционных таблиц, так и в виде объектов.

29

4.7. Техническая реализация баз данных

По способу организации СУБД делят на

•СУБД для настольных компьютеров;

•СУБД с архитектурой файл-сервер;

•СУБД с архитектурой клиент-сервер;

•СУБД с архитектурой «тонкий клиент» – сервер приложений — сервер базы данных.

Базы данных для настольных компьютеров

20-30 лет назад данные обрабатывались централизованно с помощью мейнфреймов. СУБД и БД размещались и функционировали на центральном компьютере, а пользователи получают доступ к базе данных при помощи обычных терминалов. Такой способ обработки данных имеет некоторые преимущества.

1.Совместное использование ресурсов и устройств (центральный процессор, оперативная память, периферийное оборудование )

2.Централизация хранения данных.

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

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

многих пользователей привлекала возможность "персонализации" рабочего пространства. Теперь каждый пользователь мог приобрести необходимое программное обеспечение.

Базы данных для настольных компьютеров были очень популярными (включая dBase, FoxBASE, Paradox и ряд других) 10—15 лет назад. Эти СУБД не содержали специальных механизмов доступа к данным. Они манипулировали хранением данных, используя службы доступа к файлам операционной системы.

Базы данных с архитектурой файл-сервер

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

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

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

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

30