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

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

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

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

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

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

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

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

Для индексирования таблиц используется оператор INDEX ON <выражение> TAG <имя порядка>,

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

Таблицы могут иметь одновременно много индексов и для выбора нужного порядка необходимо использовать оператор SET ORDER TO <имя-порядка>.

Он логически упорядочивает записи в

соответствующем порядке для быстрого поиска. Для обработки записей в порядке из физического размещения в файле используется оператор SET ORDER TO без указания имени порядка.

Быстрый поиск нужной записи по ключу выполняется, например, функцией SEEK (<значение ключа>, <имя таблицы>, <имя порядка>). Она возвращает значение TRUE, если нужная запись была найдена и эта запись становится текущей, т.е. доступной для обработки.

С помощью индексов можно ограничивать множество записей таблицы, которое доступно для обработки, а остальные временно «скрыть». Область видимости таблиц можно задать одним ключом или диапазоном ключей. Для этого используются операторы SET KEY TO <значение ключа> Или SET KEY TO RANGE <значение ключа-1>,  <значение ключа-2>.  Для физического переупорядочивания записей можно использовать оператор сортировки SORT ON <полей-1>, <полей-2>,… <полей-N>

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

Для поиска нужной записи в неупорядоченной

таблице используется оператор LOCATE FOR <условие>, который будет проверять последовательно все записи на выполнение заданного условия. С помощью функции FOUND () можно узнать, был ли успешным этот поиск – тогда функция возвращает значение TRUE. Другая функция – EOF (), наоборот, возвращает значение TRUE, если при поиске запись не была найдена. Для продолжения поиска следующей записи, удовлетворяющей этому же условию, используется оператор CONTINUE.

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

Подмножество атрибутов отношения будем называть внешним ключом, если:

1.Существует отношение ( и не обязательно различны) с потенциальным ключом .

2.Каждое значение в отношении всегда совпадает со значением для некоторого кортежа из , либо является null-значением.

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

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

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

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

• Получить единичную запись

• Получить выборку записей

• Получить пакет записей

Рассмотрим каждый из них по отдельности:

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

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

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

Между таблицами могут устанавливаться бинарные (между двумя таблицами), тернарные (между тремя таблицами) и, в общем случае, n-арные связи. Рассмотрим наиболее часто встречающиеся бинарные связи.

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

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

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

Для создания постоянной таблицы необходимо задать ее структуру в операторе CREATE TABLE <таблица> (<поле-1>, <поле-2>, …<поле-N>), т.е. указать имя таблицы с местоположением на диске и описать вид каждого поля. При этом можно указывать значение поля по умолчанию, возможность пустого значения, наличие простых индексов по полям и условия достоверности данных на уровне поля и на уровне записи. Это набор логических условий, которым должны удовлетворять новые данные, которые добавляются или заменяют старые значения в полях.

Таблицы, как и любые файлы, перед использованием должны быть подготовлены к работе (открыты), а после окончания обработки желательно их закрывать. Для открытия используется оператор USE <таблица> ALIAS <псевдоним> <режим обработки> <порядок>

Для закрытия таблицы используется тот же оператор в другой форме USE <таблица>

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

Операторы добавления имеют следующий вид APPEND BLANK – добавляет пустую запись в конец активной таблицы или INSERT INTO <таблица> (список полей) VALUES (список значений)

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

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

записей как удаленные, но сами они по-прежнему хранятся в таблице и их можно обрабатывать. Оператор упаковки таблицы PACK физически переписывает всю таблицу и удаляет все помеченные записи из файла. Для стирания пометки у записи используется оператор RECALL. Оператор DELETE-SQL выполняет только физическое удаление всех записей из таблицы, которые удовлетворяют заданному условию  DELETE FROM <таблица> ON <условие для удаления>

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

NEXT <число> – обрабатывается указанное число записей таблицы, начиная от текущей;

ALL – обрабатываются все записи таблицы;

FOR <условие> - обрабатываются все записи таблицы от самого начала, которые удовлетворяют заданному условию;

WHILE <условие> - обрабатываются все записи таблицы от текущей, пока они удовлетворяют заданному условию;

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

APPEND BLANK - добавление новой пустой записи в коней таблицы.

INSERT INTO Data (Date, Number, Name) VALUES () - добавление новой записи в конец таблицы и занесение значений в указанные поля.

DELETE – удаление текущей записи из таблицы.

DELETE FROM Tab WHERE Date = {2004-09-01} – удаление всех записей из таблицы, в которых поле даты содержит значение 1 сентября 2004 года.

REPLACE BirthDay WITH DATE () – замена значения поля BirthDay значением текущей даты.

REPLACE num WITH 0, NAME WITH [-] ALL – замена значений указанных полей на новые во всех записях таблицы.

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

Общий вид оператора выглядит следующим образом: SELECT <описания полей новой таблицы - результата> FROM <список таблиц-источников> INTO <получатель результата> WHERE <условия> GROUP BY <группировка записей в результате> ORDER BY <порядок записей в результате>

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

* - выбрать все поля одной исходной таблицы

Tab.* - выбрать все поля исходной таблицы  с именем Tab

Tab.Name, Tab.Date, Student.Num – выбрать указанные поля из соответствующих таблиц

Tab.Date AS Date1 – выбрать поле из таблицы и в результате дать этому полю новое имя  Если в нескольких таблицах есть одноименные поля, то необходимо уточнять имя поля с помощью имени или псевдонима таблицы.

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

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

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

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

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

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

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

С помощью дополнительных операторов можно задавать объединение (UNION), пересечение (INTERSECT) результатов запросов в новую таблицу. При этом результаты запросов должны иметь идентичную структуру, т.е. одинаковые имена и типы полей. Например, SELECT … UNION SELECT …

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

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

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

   * "один-ко-многим";

   * "один-к-одному";

   * "многие-ко-многим".

Отношение "многие-ко-многим" имеет место в следующих случаях:

   * одной записи в родительской таблице соответствует более одной записи в дочерней таблице;

   * одной записи в дочерней таблице соответствует более одной записи в родительской таблице.

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

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

2. Удаление строки из дочерней таблицы. Никаких нарушений ссылочной целостности не происходит.

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

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

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

* NO ACTION. Удаление строки из родительской таблицы запрещается, если в дочерней таблице существует хотя бы одна ссылающаяся на нее строка.

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

* SET NULL. При удалении строки из родитель

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

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

* NO CHECK. При удалении строки из родительской таблицы никаких действий по сохранению ссылочной целостности данных не предприним

ется.

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

5. БД  Проектирование БД. Метод ER-диаграмм.  Основные этапы проектирования баз данных

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

Основные элементы данной модели:

1. Описание объектов предметной области и связей между ними.

2. Описание информационных потребностей пользователей (описание основных запросов к БД).

3. Описание алгоритмических зависимостей между данными.

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

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

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

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

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

1. основные объекты предметной области (объекты, о которых должна храниться информация в БД);

2. атрибуты объектов;

3. связи между объектами;

4. основные запросы к БД.

Модель Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entity-relationship diagram (ERD)) — модель данных, позволяющая описывать концептуальные схемы. Представляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных.

Сущность изображается в виде прямоугольника,

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

Связь изображается линией, которая связывает две сущности, участвующие в отношении. Степень конца связи указывается графически, множественность связи изображается в виде "вилки" на конце связи. Модальность связи так же изображается графически - необязательность связи помечается кружком на конце связи. Именование обычно выражается одним глаголом в изъявительном наклонении настоящего времени: «Имеет», «Принадлежит» и т. д.; или глаголом с поясняющими словами: «Включает_в_себя», и т.п. Наименование может быть одно для всей связи или два для каждого из концов связи. Во втором случае, название левого конца связи указывается над линией связи, а правого – под линией. Каждое из названий располагаются рядом с сущностью, к которой оно относится.

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

6. БД  Архитектура информационных систем. Модели «клиент-сервер». Под архитектурой программных систем будем понимать совокупность решений относительно:

* организации программной системы;

* выбора структурных элементов, составляющих систему и их интерфейсов;

* поведения этих элементов во взаимодействии с другими элементами;

* объединение этих элементов в подсистемы;

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

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

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

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

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

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

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

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

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

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

* Сервер производит компиляцию полученного оператора.

* Далее (если компиляция завершилась успешно) происходит выполнение оператора.

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

полного перекладывания этой задачи на прикладной уровень.

Преимуществами данной архитектуры являются:

* возможность, в большинстве случаев, распределить функции вычислительной системы между несколькими независимыми компьютерами в сети;

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

* поддержка многопользовательской работы;

* гарантия целостности данных.

Недостатки:

* неработоспособность сервера может сделать неработоспособной всю вычислительную сеть;

* администрирование данной системы требует квалифицированного профессионала;

* высокая стоимость оборудования;

* бизнес логика приложений осталась в клиентском ПО.

При проектировании информационной системы, основанной на архитектуре "клиент-сервер", большее внимание следует обращать на

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

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