Характеристика современных автоматизированных информационных систем

По умолчанию каждая команда Transact-SQL рассматривается как отдельная транзакция. В обычном режиме ни одна команда изменения данных не может быть выполнена вне транзакции, тем самым обеспечивается целостность данных. Имеются определенные требования к выполнению транзакций системой управления базами данных. Эти требования, известные как требования ACID (Atomicity, Consistency, Isolation и Durability), описывают, как должны обра-

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

Выполнение требования ACID по обработке транзакций распространяется на систему управления базами данных, т.е. пользователь не должен предпринимать никаких дополнительных усилий, чтобы соблюсти перечисленные требования. SQL Server 2000, как и многие другие системы, автоматически гарантирует выполнение требований ACID, скрывая их от пользователей. Например, чтобы обеспечить соблюдение требования изолированности транзакций, в SQL Server 2000 используются блокировки (locks). Блокировкой (locks) называется временное ограничение, накладываемое системой на использование тех или иных ресурсов.

Индексы в SQLServer 2000.

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

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

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

Хранимые процедуры в SQLServer 2000.

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

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

В SQL Server 2000 различают:

-системные хранимые процедуры, предназначенные для работы с системными данными;

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

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

Использование курсоров в SQLServer 2000.

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

Исходный набор данных, к которому обращается пользователь, называется полным набором строк (complete set of rows). В результате выполнения запроса select пользователю возвращается набор данных, называемый результирующим набором (resulting set). Результирующий набор формируется в результате применения к полному набору строк горизонтального и вертикального фильтров. Горизонтальная фильтрация выполняется с помощью указания одного или более логических условий в разделе where. Вертикальная же фильтрация подразумевает включение в результирующий набор не всех столбцов исходного набора данных. Горизонтальная и вертикальная фильтрации могут использоваться как по отдельности, так и вместе. Курсоры SQL Server 2000 работают с результирующим набором, предлагая пользователям дополнительные средства по его обработке.

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

-курсоры Transact-SQL (Transact-SQL Cursors). Создание курсоров этого типа и работа с ними ведется средствами команд Transact-SQL. Эти курсоры создаются на сервере. Интенсивное применение может потребовать использования дополнительной оперативной памяти для хранения данных курсоров. Курсоры Transact-SQL могут создаваться и работать в транзакциях, хранимых процедурах и триггерах;

-курсоры API сервера (API Server Cursors). Этот тип курсоров используется приложениями при работе с различными механизмами доступа к данным (ODBC, OLE DB, DB Library и т. д.). Используя соответствующий API, клиент выполняет команду создания курсора. API сервера принимает запрос и создает на сервере курсор Transact-SQL. Работа с этим курсором выполняется средствами API, реализующего все базовые операции с курсорами и, возможно, некоторые дополнительные операции. Как и в случае с курсорами Transact-SQL, при действиях с курсорами API сервера данные хранятся на сервере;

Триггеры в SQLServer 2000.

Триггеры (triggers) SQL Server 2000 представляют собой набор команд TransactSQL, выполняемых автоматически при осуществлении тех или иных модификаций данных в таблице. Физически триггеры являются ни чем иным, как хранимыми процедурами специального типа. Каждый триггер связан с конкретной таблицей и запускается сервером автоматически каждый раз, когда пользователи пытаются произвести вставку, изменение или удаление данных. Триггер получает всю информацию о выполняемых пользователем изменениях в таблице. Разработчик реализовывает в триггере необходимые проверки и изменения данных в других таблицах базы данных.

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

-Create Alert Wizard – с помощью этого мастера можно создать оповещение;

-Create Job Wizard – этот мастер предназначен для создания заданий;

-Make Master Server Wizard – применяя данный мастер, можно создать главный сервер;

-Make Target Server Wizard – при помощи этого мастера создается сервер назначения.

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

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

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

“Microsoft” не советует изменять или читать системные данные напрямую. Взамен настоятельно рекомендуется использовать специальные хранимые процедуры, в достатке имеющиеся в SQL Server 2000. “Microsoft” не гарантирует, что структура системных таблиц, типы данных колонок и их назначение останутся неизменными в последующих версиях. Хранимые процедуры обеспечивают совместимость приложений, написанных для SQL Server 2000, с последующими версиями этого продукта.

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

Язык QBE. Средства генерации запросов MSAccess.

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

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

Использование QBE для создания запросов на выборку данных.

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

Окно Select Query представляет собой графический инструмент языка QBE. Для определения образца интересующих нас записей в графической среде этого окна для выборки, перетаскивания или манипулирования содержащимися в нем объектами можно использовать мышь. Определение полей и записей, которые должны быть включены в результаты запроса, производится в сетке языка QBE. При создании запроса в сетке конструирования QBE-запроса МS Access неявно генерирует для него эквивалентный SQL-оператор. Посмотреть и отредактировать этот оператор можно в окне SQL.

Более сложные типы QBE запросов. Активные запросы.

Параметрические запросы

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

Перекрестные запросы

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

Преимущества СУБД

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

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

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

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

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

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

6.Применение стандартов. Интеграция позволяет определять и применять необходимые стандарты. Например, стандарты отдела и организации, государственные и международные стандарты могут регламентировать формат данных при обмене ими между системами, соглашения об именах, форму представления документации, процедуры обновления и правила доступа. 7.

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

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

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

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

Логическое проектирование

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

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

1.Удаление связей типа M:N.

2.Удаление сложных связей.

3.Удаление рекурсивных связей.

4.Удаление связей с атрибутами.

5.Удаление множественных атрибутов.

6.Перепроверка связей типа 1:1.

7.Удаление избыточных связей.

1. Удаление связей типа M:N. Если в концептуальной модели присутствуют связи типа M:N (“многие-ко-многим”), то их следует устранить путем определения некоторой промежуточной сущности. Связь типа M:N заменяется двумя связями типа 1:М, устанавливаемыми со вновь созданной сущностью.

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

Рис. 6. M:N связь

С целью устранения этой связи мы определяем промежуточную сущность ОБЪЯВЛЕНИЕ и создаем две новые связи типа 1:М. В результате связь типа M:N будет заменена двумя связями (рис. 7).

Рис. 7. Связи типа 1 : M

2. Удаление сложных связей. Сложной называется связь, существующая между тремя и больше типами сущностей. Если в концептуальной модели присутствует сложная связь, ее следует устранить с помощью промежуточной сущности. Сложная связь заменяется необходимым количеством бинарных связей типа 1:М, устанавливаемых со вновь созданной сущностью. Например, тройная связь “Сдается внаем” (изображается ромбом) отражает отношения, существующие между оформляющим аренду работником компании, земельным участком и арендатором (рис. 8).

Рис. 8. Сложная связь

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

В нашем примере связь “Сдается внаем” можно устранить посредством введения новой слабой сущности с именем Соглашение. Вновь созданная сущность будет связана с исходными сущностями тремя новыми бинарными связями (рис. 9).

Рис. 9. Упрощение сложной связи

3.Удаление рекурсивных связей. Рекурсивными называются такие связи, в которых сущность некоторого типа взаимодействует сама с собой. Если концептуальная модель содержит рекурсивные связи, они должны быть устранены посредством определения некоторой промежуточной сущности. Например, для отображения ситуации, когда один из работников руководит группой других работников, может быть установлена рекурсивная связь типа “один-ко-многим” (1:М).

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