Тип подключения к SQL Server

При подключении SQL Server поддерживает два режима безопасности:

• режим аутентификации Windows NT;

• смешанный режим аутентификации.

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

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

Пользователи базы данных

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

Единственным исключением из этого правила является пользователь guest (гость). Особое имя пользователя guest разрешает любомуподключившемуся кSQLServer пользователю получить доступ к этой базе данных. Пользователю с именем guest назначена роль public.

Права доступа

Для управления правами доступа в SQLServer используются следующие команды:

• GRANT.Позволяет выполнять действия с объектом или, для команды — выполнять ее;

• REVOKE.Аннулирует права доступа для объекта или, для команды — не позволяет выполнить ее;

• DENY. Не разрешает выполнять действия с объектом.

Объектные права доступа позволяют контролировать доступ к объектам в SQLServer, предоставляя и аннулируя права доступа для таблиц, столбцов, представлений и хранимых процедур. Чтобы выполнить по отношению к некоторому объекту некоторое действие, пользователь должен иметь соответствующее право доступа. Например, если пользователь хочет выполнить оператор SELECT * FROM table, то он должен иметь права выполнения оператора SELECT для таблицы table.

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

CREATE DATABASE — право создания базы данных;

CREATE DEFAULT — право создания стандартного значения для столбца таблицы;

CREATE PROCEDURE — право создания хранимой процедуры.

CREATE ROLE — право создания правила для столбца таблицы;

CREATE TABLE — право создания таблицы;

CREATE VIEW — право создания представления;

BACKUP DATABASE — право создания резервной копии;

BACKUP TRANSACTION — право создания резервной копии журнала транзакций.

Роли

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

• роли уровня сервера;

• роли уровня базы данных.

Роли уровня сервера

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

В SQL Server существуют следующие типы ролей уровня сервера:

Sysadmin — дает право выполнить любое действие в SQL Server;

Serveradmin — дает право изменить параметры SQL Server и завершить его работу;

Setupadmin — дает право инсталлировать систему репликации и управлять выполнением расширенных хранимых процедур;

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

Processadmin — дает право управлять ходом выполнения процессов в SQL Server;

Dbcreator — дает право создавать и модифицировать базы данных;

Diskadmin — дает право управлять файлами баз данных на диске.

Роли уровня базы данных

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

В SQL Берег существует три типа ролей:

• заранее определенные роли;

• определяемые пользователем роли;

• неявные роли.

Заранее определенными являются стандартные роли уровня БД. Эти роли имеет каждая база данных SQL Server. Они позволяют легко и просто передавать обязанности.

Заранее определенные роли зависят от конкретной базы данных

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

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

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

Db_ datareader — определяет полный доступ к выборке данных из любой Таблицы базы данных. Запрещает выполнение операторов INSERT, DELETE и UPDATE для;: любой таблицы БД;

Db_ datawriter — разрешает выполнять операторы INSERT, DELETE и UPDATE для любой таблицы базы данных. Запрещает выполнение оператора SELECT для любой таблицы базы данных;

Db_ ddladmin — дает возможность создавать, модифицировать и удалять объекты базы данных;

Db_ securityadmin — управляет системой безопасности базы данных, а также назначением объектных и командных разрешений и ролей для базы данных;

Db_ backupoperator — позволяет создавать резервные копии базы данных;

Db_ denydatareader — отказ в разрешении на выполнение оператора SELECTдля всех таблиц базы данных. Позволяет пользователям изменять существующие структуры таблиц, но не позволяет создавать или удалять существующие таблицы;

Db_ denydatawriter — отказ в разрешении на выполнение операторов модификации данных (INSERT, DELETE и UPDATE) для любых таблиц базы данных;

public — автоматически назначаемая роль сразу после предоставления права доступа пользователя к БД.

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

Существуют два типа ролей уровня базы данных, определяемых пользователем:

• стандартная роль;

• роль уровня приложения.

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

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

49. Управление обработкой. Представление, хранимые процедуры, триггеры (представление, хранимые процедуры, триггеры)?

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

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

Представление — это по существу некая виртуальная таблица, содержащая результаты выполнения запроса (оператора SELECT) кодной или нескольким таблицам. Для конечного пользователя представление выглядит как обычная таблица в базе данных, над которой можно выполнять операторы SELECT, INSERT, UPDATE и DELETE. В действительности представление хранится в виде предопределенного оператора SQL.

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

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

• подмножество записей таблицы — включает определенное количество записей таблицы и также применяется для обеспечения безопасности;

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

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

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

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

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

CREATE VIEW имя_ представления [столбец[…]]

AS SELECT-оператор

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

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

Хранимая процедура (stored procedure) — это набор операторов Т-SQL, которые SQL SERVER компилирует в единый план выполнения. Этот план сохраняется в кэше процедур при первом выполнении хранимой процедуры, и затем план можно повторно использовать уже без рекомпиляции при каждом вызове. Хранимая процедура аналогична процедурам в языках программирования: она может принимать входные параметры, возвращать данные и коды завершения.

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

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

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

CREATE PROCEDURE имя_ процедуры [(%параметр1 mun_данных] …]]

AS SQL-операторы

Существует два типа хранимых процедур: системные и пользовательские. Первые поддерживается SQL Server и применяются для управления сервером и отображения информации о базах данных и пользователях. Вторые создаются пользователями для выполнения прикладных задач.

Триггеры

Триггер (trigger) — это особый тип хранимой процедуры, которая автоматически выполняется при изменении таблицы с помощью операторов UPDATE, INSERT или DELETE. Как и хранимые процедуры, триггеры содержат операторы Т-SQL, но в отличие от процедур запускаются не индивидуально, а автоматически при выполнении операций изменения данных. Триггеры наряду с ограничениями обеспечивают целостность данных и соблюдение бизнес правил, однако их следует использовать разумно. Например, не, нужно создавать триггер, проверяющий наличие значения первичного ключа в одной таблице, чтобы определить, можно ли вставить значение в соответствующее поле другой таблицы. Однако трудно обойтись без триггеров при выполнении каскадных изменений в дочерних таблицах.

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

Существуют три типа триггеров: UPDATE, INSERT и DELETE, каждый из которых инициируется при выполнении одноименной команды. Операции UPDATE, INSERT и DELETE иногда называют событиями изменения данных. Можно создать триггер, который будет срабатывать при возникновении более чем одного события, например, запускаться в ответ на операторы UPDATE или INSERT. Такие комбинированные триггеры называются UPDATE/INSERT. Возможно создание триггеров, срабатывающих при выполнении любого из трех операторов обновления данных (триггер UPDATE/ INSERТ/DELETE).

Триггеры, как и представления, можно создавать различными способами: использовать для этого «мастер» или команду Т-SQL, имеющую в общем случае следующий формат:

CREATE TRIGGER имя_ триггера

ON имя_ таблицы

FOR [INSERT] [,] [UPDATE] [,] [DELETE]

AS SQL-операторы

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

Работа триггеров подчиняется следующим правилам:

• триггеры запускаются только после завершения выполнения вызывающего их оператора. Например, триггер UPDATE не начинает работать, пока не завершится выполнение оператора UPDATE;

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

• триггер и вызывающий его оператор образуют транзакцию. В результате вызова из триггера оператора ROLLBACK отменяются изменения, выполненные триггером и оператором. При возникновении серьезной ошибки, например, при отключении пользователя, SQL -Server автоматически выполнит откат всей транзакции;

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

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

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

В MS SQLServer возможно создание нескольких триггеров на таблице для каждого события изменения данных (UPDATE, INSERT или DELETE)и рекурсивный вызов триггера. Например, если для таблицы уже определен триггер UPDATE,то можно определить еще один триггер UPDATEдля той же самой таблицы. В этом случае после выполнения соответствующего оператора сработают оба триггера. Кроме того, допускаются вложенные триггеры, которые срабатывают в результате выполнения других триггеров. Они отличаются от рекурсивных тем, что не запускают сами себя.

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

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

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

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

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

• агент чтения журнала (Log Reader Agent). Считывает из журнала транзакций публикующего сервера подлежащие репликации транзакции и помещает их в базу данных рассылки;

• агент рассылки (Distributation Agent). Пересылает подлежащие репликации транзакции из базы данных рассылки всем подписчикам на публикацию.

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

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

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

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

Триггеры размещаются на стороне подписчика. Это гарантирует, что любая начатая на сервере-подписчике транзакция будет обязательно зафиксирована на публикующем сервере, прежде чем появится возможность зафиксировать ее на сервере-подписчике. Здесь используется протокол с двухступенчатой фиксацией изменений (Two Phase Commit — 2PC). Если транзакцию не удастся зафиксировать на публикующем сервере, она будет отменена и на сервере подписчике, поэтому состояние обеих баз данных останется согласованным.

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

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

51. Резервное копирование и восстановление?

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

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

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

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

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

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

• запись в журнал транзакций списка незавершенных транзакций;

• запись в журнал транзакций всех измененных страниц;

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

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

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

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

Резервное копирование журнала транзакций обеспечивает архивирование и усечение журнала.

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

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

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

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

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

52. Проектирование и реализация систем БД?

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

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

Это объясняется несколькими, отчасти субъективными, при» чинами:

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

• высокими требования к квалификации проектировщиков в области теоретических основ классического проектирования БД;

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

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

Спустя годы и десятилетия после объявления своих классических моделей и концепций классики в явном виде указали на их oграниченность. Так, в [25] было признано, что «при обсуждении моделирования семантики данных акцент делается на структурные аспекты в ущерб аспектам обработки. Структура без соответствующих операций или подразумеваемых методов подобна анатомии в отсутствие физиологии». А в [26] отмечается, что «...обладание большой корпоративной БД имеет маленькое значение, если конечные пользователи не имеют возможностей легко синтезировать необходимую информацию из этих запасов данных». Проектирование БД (и ИС в целом) по классическим правилам полноты и целостности часто стало признаваться практически бессмысленным. «К 1990 году почти все аспекты стандартной процедуры работы с информационными технологиями быть оспорены, и вычислительные архитектуры вырвались из-под контроля.... Стандарты программирования размывались, а понятие не избыточных, непротиворечивых, высококачественных данных годилось разве что для груды хлама» [16].

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

Это в свою очередь стимулировало появление технологии бизнес реинжиниринга [27] и строительство киберкорпораций [15]. Эти подходы ориентированы, в первую очередь, на осуществление радикальных изменений в организации основной деятельности предприятий и, в частности, на резкое снижение затрат времени, числа работников и других ресурсов; глобализацию работы с клиентами и партнерами в любой точке мира, в том числе в режиме 24*365; увеличение мобильности персонала — снабжение работника всеми возможностями для самостоятельного получения конечного результата и ориентацией на будущие потребности клиента.

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

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

• использование архитектуры и программных средств хранилища данных, средств Оперативной Аналитической Обработки Данных (OLAP), применение средств быстрой разработки приложений (RAD), средств поддержки принятия решений (DSS) на основе хранилища данных, ОЕАР и RAD/Е1S~применение средств DSS на основе анализа БД прецедентов, а также методов логического вывода, нейронных сетей и др.;

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

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

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

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

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

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

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

• открытость БД для включения в нее и получения из нее информации с использованием принципов и средств глобальной сети Internet;

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

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

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

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

• ориентированная на интеграцию данных технология Хранилища данных — построение федеративных систем неоднородных БД, объединяющая на логическом или физическом уровне на следованные форматированные данные, архивные текстовые документы, звуковые и видеоархивы, и включающая средства оперативной аналитической обработки данных, необходимые виды «дружественных» интерфейсов;

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

53. Объектно-ориентированные БД?

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

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

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

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

В [1] определены следующие свойства, положенные в основу создания объектно-ориентированных баз данных.

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