9 февраля, 2020 20:28

:

Введение……………………………………………………….………….…..…3

1. I. Теоретическая часть:
   • История создания и развития SQL Server0………………………..…4
   • Что такое Microsoft SQL Server 7.0?…………………………………………………5
   • Цели разработки. Назначение ……… …………………………………..6
   • Лидерство и новаторство……………………………….……………..…7
   • Масштабируемость и надежность……………………….……………….8

1. II. Практическая часть:  

• Совместимость……………………………………….…..……….………9
• Архитектура «клиент-сервер»…………………………………………..10
• Активное администрирование и объектный интерфейс………………13
  • Использование электронной почты для доступа к ресурсам сервера………………………………………………………….….…16
  • Microsoft SQL Server Distributed Management Framework ……..….17
  • SQL Executive…………………………………………………….…..18
  • SQL Server Distributed Management Objects…………………….….19
  • SQL Server Enterprise Manager……………………………………….21
  • Расширение возможностей языка и программного доступа…..…..22
  • Автоматизация выполнения административных задач………..…..23
  • Параллельное сканирование и асинхронное чтение………….…….23
  • Тиражирование данных………………………………………….…..23
  • Графические средства конфигурирования, администрирования…25
• Архитектура Microsoft SQL Server……………………………….……..26
  • Хранение данных…………………………………………………….26
  • Процессор запросов……………………………………………….…27
  • Безопасность……………………………………………………….…29
• Легкость использования …………………………………………….…..30
  • Для персонального пользования……………………………….……30
  • Для рабочих групп……………………………………………..……..30
  • Для предприятия………………………………………………..…….30
• Администрирование учетных записей….………………………….……31
  • Сопоставление учетных записей …………………………….………32
• Роли………………………………………………………………………..33
  • Установка разрешений доступа для объектов, ролей и пользователей…………………………………………………………35
  • Правила использований учетных записей…………………………..36
  • Вспомогательные средства обеспечения безопасности……………37

2.8 Управление транзациями………………………………………………….40

2.8.1 SQL – выражения для транзакций……………………………………41

III. Аналитическая часть

3.1 Среда использования QL Server 7.0………………………………………42

Заключение…………………………………………………………………….…49

Список используемой литературы…………………………………………..….51

 

 

Введение

 

 

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

 

Выбранная мной,  тема курсовой работы :  «Активное администрирование приложений SQL Server 7.0»,  является  актуальной т.к. многие корпорации и независимые поставщики программного обеспечения, создающие приложения для бизнеса, остановили свой выбор на СУБД SQL Server как на лучшей системе управления базами данных для Windows NT®.

 

     Microsoft® SQL Server™ версии 7.0 — это масштабируемый, надежный и простой в использовании продукт, представляющий собой прекрасную основу для разработки приложений следующего столетия.

 

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

1.1 История создания и развитие

 

Исходный код MS SQL Server (до версии 7.0) основывался на коде Sybase SQL Server, и это позволило Microsoft выйти на рынок баз данных для предприятий, где конкурировали Oracle, IBM, и, позже, сама Sybase. Microsoft, Sybase и Ashton-Tate первоначально объединились для создания и выпуска на рынок первой версии программы, получившей название SQL Server 1.0 для OS/2 (около 1989 года), которая фактически была эквивалентом Sybase SQL Server 3.0 для Unix, VMS и др. Microsoft SQL Server 4.2 был выпущен в 1992 году и входил в состав операционной системы Microsoft OS/2 версии 1.3. Официальный релиз Microsoft SQL Server версии 4.21 для ОС Windows NT состоялся одновременно с релизом самой Windows NT (версии 3.1). Microsoft SQL Server 6.0 был первой версией SQL Server, созданной исключительно для архитектуры NT и без участия в процессе разработки Sybase.

К тому времени, как вышла на рынок ОС Windows NT, Sybase и Microsoft разошлись и следовали собственным моделям программного продукта и маркетинговым схемам. Microsoft добивалась исключительных прав на все версии SQL Server для Windows. Позже Sybase изменила название своего продукта на Adaptive Server Enterprise во избежание путаницы с Microsoft SQL Server. До 1994 года Microsoft получила от Sybase три уведомления об авторских правах как намёк на происхождение Microsoft SQL Server.

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

 

История выпусков:

• 1992 — SQL Server 4.2
• 1993 — SQL Server 4.21 под Windows NT
• 1995 — SQL Server 6.0, кодовое название SQL95
• 1996 — SQL Server 6.5, кодовое название Hydra
• 1999 — SQL Server 7.0, кодовое название Sphinx
• 1999 — SQL Server 7.0 OLAP, кодовое название Plato

1.2 Что такое Microsoft SQL Server 7.0?

 

       SQL Server 7.0 — это СУБД, рассчитанная на операционные системы, совместимые с Windows, разработанная корпорацией Microsoft. Эта система позволяет создавать высокомасштабируемые решения, она прекрасно интегрирована с Microsoft Office, имеет значительные усовершенствования в выполнении транзакций, оперативном резервировании и тиражировании, а также новшества в области автонастройки и автоматического выбора конфигурации. SQL Server 7.0 — это самая простая платформа для разработки, создания и использования хранилищ данных, а также управления ими. Это первая реляционная СУБД, снабженная встроенной системой преобразования данных Data Transformation Services, службами OLAP и Microsoft Repository 2.0.

Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями.                                                                                                  Используется для небольших и средних по размеру баз данных, и в последние 5 лет — для крупных баз данных масштаба предприятия, конкурирует с другими СУБД в этом сегменте рынка.

Сервер имеет средства удаленного администрирования и управления операциями, организованные на базе объектно- ориентированной распределенной среды управления. Новые возможности, такие как OLE Automation и средства программирования административных задач на языке Visual Basic for Applications, обеспечивают интеграцию с приложениями, работающими на ПК. Microsoft SQL Server 7.0 входит в состав семейства Microsoft BackOffice, объединяющего пять серверных приложений, разработанных для совместного функционирования в качестве интегрированной системы. Она позволяет пользователям повысить производительность процесса принятия решений средствами систем, базирующихся на архитектуре клиент-сервер. Кроме того, Microsoft SQL Server 6.0 завершает линию средств разработки, включающих Microsoft Access, Visual FoxPro®, Visual Basic и Visual C++™.

1.3 Цели разработки. Назначение

 

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

 

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

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

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

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

 

 1.4 Лидерство и новаторство

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

Лидерство и новаторство Microsoft SQL Server 7.0 определяется следующими его свойствами.

• Это первая система управления базами данных, масштабируемая от портативных компьютеров до уровня предприятий с использованием одного и того же базового программного кода, что обеспечивает стопроцентную совместимость приложений.
• Это первая система управления базами данных, которая может автоматически конфигурироваться и самонастраиваться.
• Это первая система управления базами данных, в которую встроен сервер OLAP.
• Это первая система управления базами данных со встроенными Data Transformation Services (службами преобразования данных).
• Data Warehousing Framework – первый всеобъемлющий подход к решению проблемы метаданных.
• Это первая система управления базами данных, обеспечивающая управление большим числом серверов с одного центрального компьютера.
• Самый широкий выбор возможностей тиражирования по сравнению с любой другой системой управления базами данных.
• Лучшая интеграция с Windows NT Server, Microsoft Office и семейством продуктов BackOffice®.
• Соответствие Universal Data Access (универсальный доступ к данным) – стратегия Microsoft по обеспечению высокопроизводительного доступа к различным источникам информации.

1.5 Масштабируемость и надежность

Клиенты стремятся защитить свои инвестиции в бизнес-приложения и, по мере роста организации, базы данных должны развиваться, чтобы обеспечить обработку большего объема данных, увеличенного количества транзакций и обслуживания растущего числа пользователей. SQL Server 7.0 предоставляет единое ядро СУБД, масштабируемое от портативных компьютеров под управлением операционной системы Microsoft Windows® 95 или Windows 98 до кластеров с симметричной мультипроцессорной архитектурой, работающих в среде Microsoft Windows NT® Server, Enterprise Edition. Все эти системы должны удовлетворять требованиям высокой безопасности и надежности, которые выдвигаются со стороны критических бизнес-приложений.

Следующие особенности служат основой высокой масштабируемости:

• Новый формат дисков и подсистемы хранения данных, обеспечивающих работу, как с небольшими, так и с обширными базами данных
• Переработанные утилиты для поддержки эффективной работы с большими базами данных объемом в несколько терабайт
• Поддержка оперативной памяти большого объема для снижения частоты обращения к дискам
• Динамическая блокировка на уровне строк, увеличивающая возможности параллельной обработки, особенно в приложениях с интерактивной обработкой транзакций (online transaction processing — OLTP)
• Поддержка Unicode для многоязычных приложений

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

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

2.1 Совместимость

 

Совместимость со стандартом ANSI/ISO SQL-92 улучшена, причем SQL-92 рассматривается в качестве предпочтительного диалекта SQL. Решены проблемы с совместимостью, имевшиеся в предыдущих версиях, в том числе те случаи, когда реальное поведение системы отличалось от документированного. В небольшом числе случаев, когда изменение поведения «по умолчанию» могло повлиять на существующие приложения, предусмотрена возможность отменить изменения и сохранить прежнее поведение. Аспекты (Views) включены в таблицы с информацией о схеме данных ANSI/ISO так, как это определено в SQL-92; тем самым обеспечивается стандартный способ представления метаданных в базах данных, управляемых Microsoft SQL Server.

                                       

Переход к новой версии

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

     В зависимости от количества места на диске, обновление системы на одном и том же компьютере можно провести через именованный канал (pipe), соединяющий диск с диском, или через промежуточную ленту. Если используется канал, то нужно, чтобы на диске было достаточно места. В противном случае, программа-мастер (Version Upgrade wizard) может экспортировать данные каталогов, объекты и базы данных SQL Server 6.x на ленточный накопитель, используемый для резервного копирования, или на сетевой диск. Затем пространство, которое занимал на диске SQL Server 6.x, освобождается и программа-мастер запускается снова, чтобы импортировать и преобразовать для использования с новой версией данные каталогов, объектов и баз данных, выгруженных из SQL Server 6.x. По окончании преобразования SQL Server 7.0 немедленно начинает предоставлять услуги в рабочем режиме.

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

2.2 Архитектура «клиент-сервер»

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

На смену пришла сетевая архитектура «клиент-сервер«. При использовании этой архитектуры, как и при централизованной обработке информации также необходимо наличие центрального компьютера — сервера. Но его функции иные, чем у мэйнфрейма. Клиентские компьютеры запрашивают у сервера необходимые данные, выполняют их обработку и отсылают обратно. Приложения, написанные для архитектуры «клиент-сервер», обычно состоят из раздельных серверных и клиентских компонентов. Эта технология стала доминирующей в мировоззрении программистов 90-х годов. Большинство современных сетевых продуктов, имеющих коммерческий успех, созданы с использованием архитектуры «клиент-сервер». Рассмотрим термины, употребляемые при работе с архитектурой «клиент-сервер»:   сервером (server) называется компьютер, предоставляющий доступ к своим ресурсам для других компьютеров, называемых клиентами (client). Клиент может быть одного из двух типов: толстый клиент (thick client) или тонкий клиент (thin client). Толстый клиент характеризуется тем, что он содержит средства доступа к базе данных, средства обработки и отображения информации. Каждое клиентское приложение копирует себе все необходимые данные, выполняет их обработку и отсылает результат обратно на сервер. Функции тонкого клиента сводятся в основном к выводу результатов обработки данных, осуществляемой на сервере. Клиент лишь отсылает серверу список задач, которые необходимо выполнить, а в ответ принимает обработанные данные. Все правила и логика обработки данных хранятся на сервере и лишь вызываются клиентом. Такой подход позволяет облегчить изменения алгоритмов обработки данных, так как при этом не нужно модифицировать клиентское программное обеспечение, а достаточно изменить только хранимую процедуру на сервере.

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

Дилеры выступают в роли тонких клиентов, приложения, с которыми работают менеджеры компании,  соответственно, в роли толстых клиентов. Internet Information Server, обеспечивающий функционирование Web-сервера компании, является приложением, которое посредством Internet Database Connector осуществляет прямой доступ к базе данных. При этом для тонких клиентов неважно, где находится сервер баз данных. Это имеет значение только для толстых клиентов и для приложения, осуществляющего доступ к базам данных.

Примечание: Клиент и SQL Server могут располагаться на одном компьютере. В этом случае, как будет показано дальше, клиент осуществляет соединение с сервером посредством IPC-компонентов, таких как совместно используемая память (Shared Memory) или локальные именованные каналы (Named Pipes).

 

 

Рис.  1. Способ доступа клиентов к серверу баз данных

Клиентские компоненты

 

Клиент и сервер —  термины, означающие не только роль компьютера в сети. Приложения также могут играть роли клиентов и серверов. Клиентское приложение инициирует запрос, а серверное приложение обрабатывает его и возвращает результат работы клиенту. Для осуществления этого взаимодействия необходим механизм, позволяющий организовать доступ клиента к серверу. Этот механизм реализуется через специальные интерфейсы программирования (Application Programming Interface — API) доступа к базам данных. Для обращения к базам данных SQL Server 7.0 можно использовать интерфейсы OLE DB и ODBC. Если необходимо обратиться к данным из приложения, написанного на языке высокого уровня, можно использовать специализированные API: ActiveX Data Object (ADO), DNA, RDO. Интерфейсы OLE DB и ODBC являются встроенными интерфейсами. Это означает, что запрос отправляется непосредственно серверу, избегая дополнительных трансформаций. При использовании других интерфейсов и API запрос сначала преобразуется в поддерживаемый формат и уже затем отправляется серверу.

В целях сохранения совместимости с приложениями, разработанными для предыдущих версий SQL Server, в SQL Server 7.0 сохранена поддержка интерфейса DB-Library. DB-Library является устаревшим интерфейсом и не реализует множества нововведений SQL Server. Кроме того, реализована поддержка встроенных SQL-приложений, которые используют DB-Library для связи с SQL Server (рис. 2 ).

Все API реализованы в виде .dll-файлов, которые взаимодействуют с SQL Server через специальную сетевую библиотеку клиента (Net-Library).

 

Рис. 2.2. Взаимодействие клиентов и сервера

2.3 Активное администрирование и объектный интерфейс SQL   Server

Центральная административная консоль SQL Server 7.0 заменила собой набор утилит, которые существовали в предыдущей версии сервера. Из этой консоли, называемой Microsoft SQL Enterprise Manager, администратор способен выполнять любые действия по администрированию системы, как бы велика она ни была. На рис. 3   видны несколько групп серверов.

 

Рис. 3. Административная консоль SQL Server

Администратор может создавать новые группы, группировать серверы удобным с административной точки зрения образом, выполнять манипуляции над объектами (базами данных, таблицами, хранимыми процедурами, триггерами и т.д.).
В крупных информационных системах СУБД выполняет не только функции «мясорубки» по перемалыванию колоссальных объемов информации, но и сложные функции администрирования.
Microsoft SQL Server 7.0 предлагает «активную» модель администрирования системы. В отличие от предыдущей версии продукта, администратор получил в свое распоряжение средства, позволяющие предупреждать неблагоприятное развитие событий. SQL Server 7.0 позволяет определять так называемые предупреждения (alert), которые являются реакцией системы на возникновение того или иного события.
Как видно из рис.4 , предупреждение срабатывает при возникновении ошибки с кодом 018 в базе данных master.

Рис.4. Диалог описания предупреждения

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

• команду операционной системы, .CMD или .EXE файл;
• команду процесса тиражирования;
• команду чтения журнала;
• команду процесса синхронизации процесса тиражирования;
• выражение языка Transact-SQL (в том числе имя хранимой процедуры).

В результате система в состоянии сделать попытку самостоятельно решить возникшую проблему (конечно, если администратор заранее подготовил ее к этому). И только в том случае, если задача после выполнения сообщает о невозможности решения возникшей проблемы, имеет смысл прибегать к помощи человека. Каждой задаче можно назначить вызов администратора по электронной почте или пейджеру при успешном завершении или провале.(Рис.3)

Рис.5. Диалог описания задачи

Пример, по которому могут развиваться события. Ночью произошел сбой в электросети. Источник бесперебойного питания выработал свой ресурс, потом выполнил ShutDown сервера, и система прекратила работу. Со временем электропитание было восстановлено, и компьютер снова включился. Не секрет, что Windows NT способна выполнять автоматическую, без участия человека, регистрацию в сети. В силу того, что SQL Server и SQL Executive представляют собой сервисы операционной системы, им можно назначить атрибут «стартовать автоматически». SQL Server стартовал, и на исполнение была запущена хранимая процедура, которая также имеет атрибут «автостарт». Такая процедура может, например, выполнить проверку целостности базы данных. Если проверка прошла успешно, система продолжает работу в штатном режиме. Если проверка показала, что система неработоспособна, можно пойти как минимум двумя путями: хранимая процедура генерирует ошибку, вызывающую предупреждение, которое, в свою очередь, вызывает на выполнение задачу. Можно сразу поднять тревогу и вызвать администратора. Но электронная почта пригодна не только для того, чтобы поднимать тревогу, она может использоваться и для штатной работы. SQL Server 7.0 умеет читать почту и отвечать на письма. В том случае, когда задержки на прохождение электронного письма не критичны для работы, пользователь или администратор могут использовать почту для посылки запросов серверу и получения от него ответа. Это позволяет обращаться к серверу в режиме Off-line практически с любого компьютера.

 

2.3.1 Использование электронной почты для доступа к ресурсам сервера

Администрировать сервер теперь можно через программу просмотра ресурсов Интернета. Благодаря этому администратор может легко управлять любым SQL Server отовсюду. Кроме того, отпадает необходимость устанавливать все компоненты распределенного управления в полном объеме. Для создания страниц, позволяющих администрировать SQL Server 7.0 через Интернет, используется трехзвенная архитектура распределенного управления, DCOM и компоненты интерфейса пользователя ActiveX®.

   

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

• Послать уведомление оператору
• Записать предупреждение в системный протокол (Windows NT application event log)
• Выработать «прерывание» SNMP
• Выполнить задание

SQL Server Agent следит за событиями в системном протоколе Windows NT application event log. Когда там появляется запись о событии, SQL Server Agent сравнивает его описание с предупреждениями, определенными для соответствующей среды. Обнаружив совпадение, SQL Server Agent выполняет заданные для него действия, а полученные в ходе их выполнения сообщения записывает в тот же системный протокол.

Системный администратор может управлять предупреждениями для одной или нескольких систем SQL Server с помощью SQL Server Enterprise Manager. Кроме того, администратор может задавать расписание пейджинга, так чтобы в зависимости от времени суток и дня недели пейджинговое сообщение получил соответствующий администратор баз данных.

Набор расширенных хранимых процедур SQL Server включает процедуры работы с почтовыми ящиками. Сервер может получить указание прочесть текущую почту и обработать ее (лучше всего это задание оформить как периодически выполняемую задачу). В сообщении размещается вызов хранимой процедуры или набор команд T-SQL. Сервер читает текст сообщения и выполняет размещенные в нем команды. Результат исполнения присоединяется к письму, посылаемому в ответ, в виде текстового файла или файла в формате CSV (поля, разделенные запятыми), который можно непосредственно «взять» в электронную таблицу или импортировать в базу данных. Естественно, возникает вопрос о предохранении данных от несанкционированного доступа. Ограничение числа лиц, которые могут получать таким образом информацию, может быть организовано различным образом, и тут необходимо позаботиться о защите доступа как со стороны SQL Server, так и со стороны ПО, занимающегося отправкой почты. Для каждого пользователя, который посылает запросы на сервер, можно завести соответствующий набор прав, которые смогут эффективно ограничить диапазон действий, позволительных для него.
Каждому пользователю, зарегистрированному на сервере, можно назначать самые разнообразные права — от права делать выборки из тех или иных таблиц и исполнения хранимых процедур до права на модификации или выборки из конкретного поля конкретной таблицы.
SQL Server способен «понять», кто пишет письмо. Можно также ограничить обрабатываемую почту только письмами, которые имеют определенный текст в разделе Subject. Все это вместе взятое позволяет утверждать, что если в организации четко соблюдается дисциплина хранения и назначения паролей, то риск несанкционированного доступа к конфиденциальной информации может быть сведен до минимума. Кроме того, на электронную почту можно возложить обязанности по получению/передаче только безобидной информации, доступ к которой не нуждается в серьезной защите.

2.3.2 Microsoft SQL Server Distributed Management Framework (SQL- DMF)

С появлением SQL Server 7.0 Microsoft предложил на рынке сервер с масштабируемой архитектурой управления, наиболее оптимальным образом подходящей к быстро меняющимся задачам, которые встают перед системами архитектуры клиент-сервер. Microsoft SQL Server Distributed Management Framework (SQL-DMF) имеет трехуровневую объектно- ориентированную архитектуру, которая предоставляет компоненты, сервисы и инструментарий, необходимые для управления распределенными серверами в масштабе предприятия.(Рис.6)

Рис.6. Диалог определения прав доступа

Уровень	Компоненты SQL Server 6.0 DMF
Уровень 1 Представление/Манипуляция	Средство администрирования SQL Enterprise Manager, программирование на Visual Basic или Visual FoxPro
Уровень 2 Объекты управления	OLE интерфейс для доступа ко всем средствам администрирования и управления SQL Server
Уровень 3 Реализация/Обработка	Процессор данных SQL Server, сервисы SQL Executive

 

Архитектура SQL-DMF изначально предназначена для работы в распределенных средах и предоставляет необходимую гибкость и масштабируемость за счет разделения процесса администрирования на три четко определенных уровня:

Преимущества SQL-DMF

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

2.3.3 SQL Executive

Основой SQL-DMF является SQL Executive, исполняемый как сервис операционной системы и управляющий тиражированием, обработкой событий, предупреждений и диспетчированием работы компонентов внутри SQL-DMF. SQL Executive работает как «скрытый» оператор или «интеллектуальный агент», автоматически и постоянно отслеживающий состояние окружения сервера и любых распределенных служб SQL Server. Разработчики сервера убеждены, что критические службы, такие как тиражирование, должны быть частью основного продукта, а не просто «утилитами».

SQL Enterprize Manager	OLE Automation
SQL Server Distributed Manadgement Object (SQL-DMO)
SQL Executive	SQL Server
Тиражирование Менеджер задач Менеджер событий Менеджер уведомлений

Рис.7. Компоненты SQL-DMF

Ранее существовавшие подходы к системному администрированию приводили к запоздалой реакции на сбой системы, а администратору отводилась роль «пожарного». С другой стороны, обработчик событий SQL Executive изначально проектировался для поддержки активной модели администрирования, позволяющей администратору определять предупреждения и проводить корректирующие операции до возникновения проблемы. Кроме того, администратор может заранее определить уведомления, которые будут рассылаться по электронной почте или на пейджер.
SQL Executive работает как сервис операционной системы и при необходимости может быть запущен автоматически для загрузки списка задач, хранящегося в таблице SQL Server.

 2.3.4 SQL Server Distributed Management Objects (DMO)

Другим исключительно важным компонентом являются SQL Server Distributed Management Objects (SQL-DMO). SQL-DMO — OLE Automation интерфейс SQL Server 7.0 открывает объекты, свойства и методы для всех аспектов деятельности SQL Server по управлению и администрированию SQL Server. Объектная модель SQL Server включает более 70 индивидуальных объектов и свыше 1500 свойств и методов. Организация объектов значительно упрощает изучение и продуктивное использование компонентов административного интерфейса SQL Server.
OLE интерфейс поддерживает использование таких средств разработчика, как Visual C++, Visual Basic и Visual FoxPro для создания специализированных административных сценариев, исполнение которых организуется средствами диспетчирования SQL Executive. Справа приведены некоторые из объектов и методов SQL-DMO.
Все функции SQL Server открыты для доступа извне как объекты, свойства и методы. Подобная модель значительно упрощает работу с административным «слоем» за счет организации функций управления в терминах объектной модели SQL Server. Основной объект — «SQL Server» — включает коллекцию объектов «Databases». Объект «Database» включает коллекции объектов «Table», «View» и «StoredProcedure». Объекты имеют свойства (например, SQLServer.Name = «SABERTOOTH») и методы (SQLServer.Start или SQLServer.Stop). Свойства и методы используются для управления SQL Server.

Метод объекта	Действие
SQLServer.Stop	Останавливает SQL Server
SQLServer.Start	Запускает SQL Server
Database.Backup	Выполняет создание страховочной копии
Index.UpdateStatistics	Обновляет информацию оптимизатора по индексам
Database.Table.Add	Добавляет таблицу к базе данных

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.3.5 SQL Enterprise Manager

Администрирование SQL Server осуществляется при помощи развитых графических средств. К ним относится:

SQL Server Enterprise Manager. Это основное средство администратора. Позволяет создавать базы данных, заводить пользователей, управлять их правами, выполнять резервное копирование и восстановление данных и так далее. SQL Server Enterprise Manager (рис. 8) реализован как модуль расширения (snap-in) нового средства управления серверными продуктами — Microsoft Management Console (MMC). Enterprise Manager также позволяет управлять выполнением административных задач по расписанию и описывать реакцию на события.

Рис. 8. SQL Server Enterprise Manager

 

Архитектура SQL-DMF предлагает множество «точек входа» для поддержания конкретных потребностей администратора. В результате серверы могут управляться посредством доступа к объектам SQL-DMO или непосредственно. Мы полагаем, что подобная архитектура создает гибкую среду администрирования, удовлетворяющую требованиям администраторов как мелких, так и крупных систем, без необходимости принесения в жертву простоты или мощности.

Рис.9. Структура объектной модели SQL Server

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

2.3.6 Расширение возможностей языка и программного доступа

Существующая версия SQL Server снабжена мощным языком программирования -Transact-SQL, позволяющим создавать сложную логику триггеров и хранимых процедур. В новой версии язык значительно расширен, теперь он соответствует стандарту ANSI-92, и программисты получили новые возможности (такие как новые, соответствующие ANSI-стандарту, типы данных и соответствующая стандарту ANSI поддержка декларативной целостности данных). Помимо перечисленных возможностей, программист может воспользоваться генератором, автоматически создающим уникальные значения для ключевых полей таблицы, возможностью передавать идентификаторы и данные типа TEXT и IMAGE как параметры хранимым процедурам и многое другое. Использование хранимых процедур, которые запускаются автоматически при каждом старте SQL Server, позволяет создавать системы, способные выполнять различного рода задания без участия администратора. Наиболее же интересным нововведением являются скроллируемые, двунаправленные курсоры. Курсоры SQL Server поддерживают все режимы, определенные расширенными требованиями ANSI, а также и ODBC семантику; они совместимы с существующими курсорами, поддерживаемыми API в DB-Library.

2.3.7 Автоматизация выполнения административных задач

Автоматизация выполнения административных задач позволяет значительно снизить расходы на поддержку сети серверов в организации. Теперь вы можете создавать многошаговые задания, указывая последовательность выполнения очередных шагов в зависимости от результатов предыдущих. В качестве шагов задания могут выступать, как и прежде, оператор языка T-SQL и внешняя программа или командный файл, а также новый элемент — скрипт на языке Visual Basic Scripting Edition или JavaScript.

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

 

2.3.8 Параллельное сканирование и асинхронное опережающее чтение

Параллельное сканирование и асинхронное опережающее чтение повышает на 40 — 400% скорость выполнения некоторых типов запросов и других операций над базой данных в многопроцессорных системах. Повышение производительности достигается за счет использования SQL Server 6.0 множественных потоков операционной системы и алгоритмов определения следующего блока данных, необходимых для вывода в кэш. На приводимом графике показано, как растет время, необходимое для считывания с диска более 10000 страниц из базы данных (меньшие числа показывают более высокую производительность). Эта операция типична для длительного запроса с вычислениями или операции создания отчета. Как видно из графика, по мере роста числа клиентов, SQL Server 6.0 выполняет операцию не менее чем в 4 раза быстрее за счет использования параллельного сканирования таблиц и асинхронного опережающего чтения.
Подобная технология обеспечивает резкое повышение производительности для любой операции, требующей просмотра таблиц, например, SELECT, UPDATE и DELETE с необходимостью поиска, CREATE INDEX, DBCC, DUMP/LOAD и т.п.

2.3.9 Тиражирование данных

Одной из наиболее интересных  возможностей SQL Server 7.0 является тиражирование данных.
В силу того, что продукт изначально создавался для работы с распределенными данными, СУБД снабжена надежной и открытой архитектурой, хорошо интегрированной, гибкой и управляемой.(Рис.10)

Рис.10. Организация тиражирования данных

Организация тиражирования данных в SQL Server 7.0:

• Система тиражирования данных построена на метафоре подписки. В процессе тиражирования участвуют следующие серверы сервер публикаций;
• сервер репликаций;
• сервер подписки.
• тиражирование слиянием (Merge Replication)
• Под публикацией понимается совокупность данных, которые могут подвергаться тиражированию.
  Статья — наименьший возможный элемент публикации. Статья может представлять собой таблицу или любую ее часть. Публикация может включать одну или более статей.
  Наиболее важным требованием к тиражированию данных является устойчивость к сбоям, гарантирующая постоянное, надежное поступление данных и способная противостоять возможным сбоям сети и оборудования.         Система тиражирования должна обеспечивать высокое быстродействие  операций сохранения и переноса данных с минимальным воздействием на центральный сервер и гарантией надежного и защищенного поступления информации. Она должна быть достаточно гибкой, чтобы позволять организациям применять различные подходы и схемы организации процесса тиражирования. Кроме того, поскольку организации не всегда могут себе позволить иметь высококвалифицированного администратора в каждом подразделении, где размещен конкретный сервер, система тиражирования должна быть хорошо интегрирована с самой СУБД для получения возможности удаленного конфигурирования, мониторинга и управления.
  Microsoft создавала SQL Server 7.0 с учетом всех перечисленных требований. Подсистема тиражирования данных, являющаяся составной частью SQL Server, позволяет осуществлять автоматическое тиражирование транзакций и объектов базы данных с единого сервера на один или более серверов, расположенных в географически разделенных подразделениях компании.

2.3.10 Графические средства конфигурирования и администрирования

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

 

2.4 Архитектура Microsoft SQL Server

В архитектуре Microsoft SQL Server в первую очередь следует отметить следующие компоненты:

• система хранения данных;
• процессор запросов;
• система безопасности.

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

В состав Microsoft SQL Server также входят компоненты, обеспечивающие:

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

2.4.1 Хранение данных

Принципиально новым в версии SQL Server 7.0 является то, что система хранения данных взаимодействует с процессором запросов и другими подсистемами по интерфейсу OLE DB, то есть является принципиально открытой. Эта открытость обеспечивает базу для дальнейшего развития продукта — например, для появления специализированных процессоров запросов. Кроме того, она дает принципиальную возможность построения различных приложений, использующих систему хранения данных SQL Server как встроенный компонент.

В системе хранения данных SQL Server 7.0 имеется ряд существенных нововведений, которые мы рассмотрим далее.

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

       Формат страницы. Новый формат единицы дисковой памяти — страницы — отличается в первую очередь размером. Теперь страница занимает 8 Кбайт, что, во-первых, повышает эффективность операций ввода-вывода, а во-вторых, позволяет увеличить максимальный размер символьных типов данных до 8000 байт.

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

      Резервное копирование. В версии 7.0 поддерживается три основных вида резервного копирования: копирование всей базы данных, копирование только журнала транзакций и дифференциальное копирование (копирование только измененных страниц). Комбинируя эти три вида, администратор может выбрать оптимальную стратегию резервного копирования. Новый способ выполнения резервного копирования (обозначаемый в промышленных стандартах термином «fuzzy backup») понижает скорость текущей работы пользователей не более чем на 10-20%. На одном и том же носителе можно хранить результаты резервного копирования SQL Server 7.0 вместе с резервными копиями Windows NT.

2.4.2 Процессор запросов

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

        Использование более одного индекса на таблицу. В предыдущих версиях оптимизатор запросов мог использовать не более одного индекса на каждую таблицу, участвующую в запросе. Теперь это ограничение снято, и оптимизатор может пользоваться несколькими индексами, например, если условие поиска в запросе задано одновременно по нескольким полям. Над индексами могут осуществляться теоретико-множественные операции, например, объединение или пересечение индексов, что упрощает обработку предикатов фильтрации с операторами or или and, а также может применяться для динамического создания покрывающего индекса.

        Новые способы соединения таблиц в запросах (JOIN). Наряду с традиционным алгоритмом разрешения соединения таблиц (JOIN) — вложенным циклом (nested loop), оптимизатор может теперь применять и новые, зачастую более эффективные стратегии — слияние (merge join) и хеширование (hash join). Слияние применяется, когда обе соединяемые таблицы отсортированы по ключу соединения. Хеширование применяется, когда индексы задействовать не удается. Оптимизатор запросов сам определяет наиболее эффективную стратегию для каждого запроса.

        Распределенные и гетерогенные запросы. В версии 7.0 процессор запросов обращается за данными к системе хранения (Storage Engine) через интерфейс OLE DB. Через этот же интерфейс он может обращаться за данными и к любым другим OLE DB-совместимым источникам данных — как локальным (находящимся на этом же компьютере), так и удаленным. Таким образом, стандартные операторы SELECT, INSERT, UPDATE и DELETE могут теперь в одном запросе соединять таблицы из разных источников данных. Этими источниками данных могут быть как Microsoft SQL Server, так и другие СУБД, а также нереляционные источники данных, например Exchange Server, Index Server и др. В зависимости от возможностей OLE DB-провайдера возможны три варианта обращения к удаленным данным — только чтение удаленных данных, их изменение и включение изменений в распределенную транзакцию. При этом изменение локальных данных  возможно в рамках распределенного запроса в любом случае.

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

        Полнотекстовый поиск. SQL Server обеспечивает возможности полнотекстового поиска за счет интеграции с системой полнотекстового индексирования, используемой также в Index Server и Site Server. Взаимодействие с этой системой осуществляется через OLE DB. Управление построением и поддержкой индексов осуществляется из главного средства администрирования SQL Server — SQL Enterprise Manager. Полнотекстовые индексы хранятся за пределами баз данных SQL Server — в специально отведенных файловых каталогах. Обновление индексов осуществляется вручную или по расписанию. Построение индекса возможно по символьным и текстовым полям таблиц. Поиск (SELECT) с использованием полнотекстового индекса осуществляется при использовании двух специальных функций — CONTAINS() и FREETEXT().

2.4.3 Безопасность

SQL Server может авторизовать пользователей двумя путями:

• На основе собственного списка пользователей (в версии SQL Server 6.5 это называлось «стандартный режим»)
• На основе базы пользователей Windows NT (в версии SQL Server 6.5 это называлось «интегрированный режим»)

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

Управление правами пользователей в базах данных также стало более удобным и гибким. Вместо групп пользователей теперь применяются роли. Пользователь может входить в одну или несколько ролей. Роль может включать в себя другие роли. Проявился новый механизм — «роль приложения» (application role), который определяет контекст прав любого пользователя данного приложения, независимо от его прав в базе данных.

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

 

2.5 Легкость использования

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

2.5.1 Для персонального пользования

• Для выполнения стандартных операций не требуется администратор базы данных.
• Скрыты все сложности конфигурирования сервера, проверки целостности базы данных, ведения статистики использования индексов, резервного копирования.
• Устранена необходимость задания жестко кодированной конфигурации сервера. Конфигурация должна приспосабливаться к специфическим потребностям среды.
• Упрощен переход на SQL Server с настольных СУБД, таких как Microsoft Access, FoxPro® и Paradox.

2.5.2 Для рабочих групп

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

2.5.3 Для предприятия

• Обеспечена инфраструктура для распределенного управления большим числом систем SQL Server
• Обеспечены основные возможности для перемещения данных в их среде (хранение и преобразование данных)
• Предоставляются хорошо продуманные инструменты для мониторинга, профилирования и анализа производительности сервера
• Имеются средства устранения проблем пользователя и сервера

 

2.6 Администрирование учётных записей

 

Существует два пути создания учётных записей: с помощью средств NT и непосредственно в SQL Server 7.0. Таким образом, для SQL Server 7.0 могут существовать одновременно записи пользователей и групп NT, собственные (созданные администратором) записи SQL Server 7.0  и установленные по умолчанию (такие, как SA, BUILTIN\Administrator и guest). Все эти записи хранит системная таблица syslogins. Для новой записи права назначаются к установленной по умолчанию базе данных. Полные права имеют записи SA и BUILTIN\Administrator, причём под второй подключаются все администраторы NT. Проще всего добавить новую запись или установить права учётной записи NT с помощью SQL SEM. Однако, если вы сисадмин или администратор безопасности SQL Server 7.0, Вы можете использовать непосредственно системные хранимые процедуры, для администрирования учётных записей:

Sp_grantlogin {«имя домена \ учётная запись NT» до 128 символов} — подключение записи/группы NT к SQLS7;

Sp_revokelogin {…} — удаляет подключение записи/группы NT к SQLS7;

Sp_denylogin {…} — запрещает подключение записи/группы NT к SQLS7.

Используя систему аутентификации Windows NT, Вы в полной мере сможете насладиться теми возможностями и сервисам, которые предоставляет связка этой ОС с SQL Server 7.0. Например, использование одной записи для группы NT позволяет свободно менять состав этой группы средствами администрирования домена даже не обращаясь к средствам SQL Server 7.0. После подключения группы или записи к SQL Server 7.0, соответствующие записи в таблице syslogins можно удалить только средствами SQL Server 7.0.

Порядок удаления записей такой: вначале удаляем пользователя или группу NT, а потом убираем запись в SQL Server 7.0. Получить имя учётной записи NT и домена, к которому она приписана можно с помощью функции SUSER_SNAME.

Для добавления в SQL Server 7.0  учётной записи, не входящей в домен или входящей, но требующей уникальных прав не сопоставимых ни с одной из групп NT, можно использовать системную хранимую процедуру:

 

Sp_addlogin {«имя учётной записи SQL Server 7.0 » до 128 символов, не пустое, не SA и без «\»}.

 

Изменение пароля пользователей SQL Server 7.0  можно осуществить с помощью: Sp_password. Обычные пользователи могут сменить только свои пароли, а DBA может всё (вместо старого пароля вводится NULL).

 

2.6.1 Сопоставление учётных записей ролям и пользователям

 

Используя доверительное подключение групп NT к SQL Server 7.0  Вы, тем самым, уже получаете возможность регулирования прав доступа к объектам SQL Server 7.0. Но, поскольку NT не единственный источник пользователей, сам SQL Server 7.0  имеет обширный набор возможностей для разграничения прав доступа зарегистрированных в таблице sysusers пользователей к своим объектам. Одной из главных задач DBA по обеспечению безопасности данных является грамотное сопоставление учётных записей подключения пользователям и ролям. Данные о каждом пользователе/группе NT, каждом пользователе SQLS7 и о каждой роли в базе данных записываются в sysusers, а права доступа для них хранятся в каждой базе данных в таблице sysprotects.

Кроме SQL SEM, добавить любую из зарегистрированных учётных записей SQL Server 7.0  к базе данных можно с помощью системной процедуры:

 

Sp_grantdbaccess {«имя учётной записи»} [, «имя в базе данных»]

 

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

Естественно, кроме добавления возможно и удаление (Sp_revokedbaccess) и изменение (Sp_change_user_login).

Что бы наглядно рассмотреть сопоставление учётных записей пользователей учётным записям подключения,  обратимся к двум учётным записям, всегда присутствующим в вашем SQL Server 7.0, это DBO и GUEST.

DBO всегда сопоставляется SA и членам роли sysadmin (System Administrators). Кроме того, что dbo не может быть удалена, она ещё и владелец для всех баз данных, которые были, есть и будут созданы в будущем.

В отличие от dbo, учётная запись guest может быть удалена из всех баз данных, кроме master и tempdb. Иногда бывает удобно, что бы к SQL Server 7.0  могли подключиться «гости» или, что бы пользователь имел доступ к SQL Server 7.0, но для некоторых баз данных он всё равно оставался «гостем».

 

2.7 Роли

 

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

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

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

Фиксированные роли сервера в первую очередь направлены на разграничение функций администрирования SQL Server 7.0. Местом их дислокации является таблица syslogins базы master. Как обычно, кроме SQL SEM, включить пользователя в фиксированную роль можно с помощью Sp_addsrvrolemember {учётная запись, фикс. серв. роль}, при условии, что вы член этой фиксированной роли (Sp_dropsrvrolemember — для удаления).

Поскольку роли фиксированные, Вам не удастся их удалить, изменить или добавить. Также Вы не сможете выполнять указанную выше системную хранимую процедуру в рамках запущенной пользователем транзакции.                         Названия фиксированных серверных ролей говорят сами за себя: sysadmin, dbcreator, diskadmin, processadmin (только относящихся к SQL Server 7.0), serveradmin, setupadmin (настройка репликаций), securityadmin (подключения к SQL Server 7.0  и аудит).

Такими же бессмертными являются фиксированные роли баз данных. Если для серверных ролей объектом доступа был сам SQLS7, то для фиксированных ролей баз данных объектом являются базы данных и всё, что их составляет. Кроме того, эти роли хранятся непосредственно в базах, причём каждая база данных содержит только относящийся к ней набор ролей. Для больших не любителей SQL SEM, существует системная хранимая процедура Sp_addrolemember {роль, учётная запись}, которой правда могут воспользоваться только те пользователи, которые уже являются участниками соответствующей роли. Естественно обратный процесс можно запустить с помощью Sp_droprolemember. Роль баз данных бывают как разрешительные, так и запретительные.

Например, роли db_datareader и db_datawriter разрешают соответственно чтение / добавление + изменение + удаление данных из всех таблиц базы.

В то же время роли db_denydatareader и db_denydatawriter несут полностью противоположный смысл. Пять ролей несут администраторские привилегии: db_accessadmin (управление пользователями, группами и ролями), db_ddladmin (управление объектами БД), db_securityadmin (доступ к операторам и объектам), db_backupoperator (резервное копирование), db_owner (владелец всей базы данных). Как и большинство систем оперирующих понятием «пользователь», SQL Server 7.0  содержит специфическую фиксированную роль баз данных — public. Любой пользователь SQL Server 7.0 автоматический становится участником этой роли и будет там состоять, пока его полностью не удалят. Абсолютно все базы SQL Server 7.0  имеют у себя эту роль. Назначение этой роли понятно, существует целый ряд операций, которые должны быть доступны абсолютно всем пользователям SQL Server 7.0  (печать, оповещения и т.п.). Поскольку все пользователи, группы и роли непременным образом входят в эту роль, добавление этой роли кому бы — то ни было не имеет смысла и посему невозможно. Прелесть роли public в том, что даже не имеющий никаких прав пользователь, подключившись к SQL Server 7.0  уже может выполнять операторы или другие задачи, которые не требуют специального разрешения (например, оператор PRINT). Он может видеть содержание системных таблиц и даже выполнять некоторые системные хранимые процедуры, а заодно, для тех баз где этой роли определён Вами некий вариант доступа, он может работать с пользовательскими базами, воспользовавшись учётной записью guest.

К сожалению набор фиксированных ролей не в состоянии охватить все возможные задачи группировки прав пользователей к ресурсам сервера баз данных. Наверняка Вам придётся воспользоваться пользовательскими ролями баз данных. Тем более, что у Вас просто не будет другого выхода, если группы SQL Server 7.0  и NT не совпадают по составу пользователей или вы не можете администрировать учётные записи NT. Для ярых не любителей SQL SEM я бы всё же рекомендовал использовать при работе с пользовательскими ролями именно его, потому что эти роли являются смертными и системных процедур для них придумано больше. Кроме того, Вам придётся помнить, какие фиксированные роли могут создавать те или иные пользовательские роли. Например, только db_securityadmin и db_owner могут воспользоваться системной хранимой процедурой Sp_addrole {роль, владелец}, которая в таблице sysusers текущей базы создаст запись для Вашей новой пользовательской роли. Но когда Вам потребуется добавить пользователя в эту новую роль, выяснится, что кроме уже указанных двух фиксированных ролей баз данных, к ролям способным это сделать добавится sysadmin, а процедурой будет всё та же Sp_addrolemember. Те же лица могут выполнять и обратные действия с помощью; Sp_droprole и Sp_droprolemember.

 

2.7.1 Установка разрешений доступа для объектов, ролей и пользователей

 

Учётным записям подключения пользователей, которые успешно подключились к SQL Server 7.0  и которым сопоставлены учётные записи пользователей сервера БД или роли, для успешной работы необходимо получить разрешение на доступ и работу с объектами баз данных SQL Server 7.0.

Для каждой базы разрешения свои и могут быть трёх типов: предопределённые (для фиксированных ролей и владельцев, не подлежат изменению), объектные (доступ к объектам БД и функциям их создания, изменения, просмотра и удаления), операторные (доступ к операторам создающим: базы, таблицы, представления, процедуры, правила, определения, и резервирующим объекты БД). Само разрешение подразумевает три состояния: предоставлено (GRANT), запрещено (DENY) и отозвано (REVOKE). По умолчанию, до явного определения разрешения пользователю, оно находится в отозванном состоянии и запись о нём хранится в таблице sysprotects. Отозванное разрешение, в силу своей аддитивности, может быть переопределено назначенной ролью, а запрещение переопределить невозможно.

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

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

Разрешения для обычных пользователей могут регулироваться на уровне объектов и операторов. Чётко представляя себе границы прав каждого пользователя, Вы можете установить им разрешения/запрещения на работу с таблицами, столбцами или хранимыми процедурами, а также на возможность использования операторов для создания баз или их элементов. Причём разрешения на операторы применяются не к объекту, на который он воздействует, а к самому оператору. Т.е. права на сам объект (например, БД) у пользователя могут быть сколь угодно большие, но некоторые операторы, воздействующие на этот объект, Вы можете ему запретить использовать. Помните только, что устанавливать разрешения на операторы могут только sysadmin, db_owner и db_securityadmin.

Разрешение на выполнение хранимых процедур сводится, в конечном итоге, к разрешению на выполнение оператора EXECUTE. Правда, часто этого бывает недостаточно, если пользователь не обладает необходимыми объектными разрешениями. Объектные разрешения позволяют Вам тонко регулировать прав доступа к данным и процедурам их обработки. Вы можете предоставлять разрешения на целые таблицы и представления, а также к отдельным столбцам. Важно только помнить некоторые правила, которые проистекают из внутренней природы обработчика запросов T-SQL.     Например, устанавливая разрешения на таблицы и представления, Вы регулируете права доступа пользователей к применению операторов UPDATE, DELETE, INSERT и SELECT, но должны помнить, что возможность применения пользователем БД предложения WHERE в операторах потребует предоставления ему таких разрешений, что бы он мог выполнять операторы UPDATE и SELECT.

Другой пример относится к разрешениям на столбцы. Вы можете регулировать применение пользователем операторов UPDATE, SELECT и REFERENCES к конкретному столбцу, но когда пользователь попытается добавить строку в таблицу, подчиняющуюся ограничению FOREIGN KEY, выяснится, что пользователь должен обладать разрешениями для этого столбца для выполнения операторов SELECT или REFERENCES.

Для предоставления разрешений пользователям удобно воспользоваться SQL SEM или оператором GRANT. Для запрещения пользователю неких прав применяется оператор DENY. С помощью оператора REVOKE можно удалить заданные до этого разрешения или снять запрет. Это бывает удобно, когда вы переводите пользователей в новую групп и собираетесь, в силу аддитивности, делегировать разрешения и запрещения пользователям, устанавливая их для группы.

 

2.7.2 Правила использования учётных записей

 

Постарайтесь минимизировать использование учётных записей подключения sysadmin и BUILTIN\Adminstrators. Тщательно проанализируйте необходимость и возможность их использования.

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

Если нет необходимости, что бы администраторы NT имели полный доступ к SQLS7, уберите пользователя BUILTIN\Adminstrators (под которым скрывается группа Administrators системы Windows NT) из роли sysadmin.

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

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

Если для разграничения прав и разрешений Вам хватит групп Windows NT, старайтесь ограничиваться только ими, при добавлении членов в пользовательские роли. Разрешения старайтесь давать только через пользовательские роли. Роли создавайте по принципу близости набора должностных функций пользователей. Например, сотрудникам одного отдела или сотрудникам, выполняющим одинаковые функции в разных подразделениях (на вскидку: ответственные за имущество).

Старайтесь, чтобы разрешения на создание объектов БД оставалось только за фиксированными ролями баз данных sysadmin, db_owner и db_ddladmin. Лучше, если владельцем всех объектов будет dbo. Это избавит Вас и ваших пользователей от ссылки на владельца объекта (dbo можно опускать). Кроме того, если объект создаёт sysadmin, то владелец получается dbo. Иначе Вам для смены владельца придётся использовать процедуру sp_changeobjectowner. И, кроме того, вы должны для этого быть одним из db_owner, db_ddladmin или членом серверной роли securityadmin.

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

 

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

 

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

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

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

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

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

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

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

Участники ролей db_owner, db_securityadmin и sysadmin с помощью стандартных возможностей SQL SEM или с помощью специальной системной процедуры (sp_addapprole ‘роль’, ‘пароль, который будут вводить пользователи для использования роли’) могут создавать роли приложений, запись о которой добавляется в sysusers текущей базы. Удаляет роль sp_dropapprole (если под этой ролью нет активных пользователей), а изменить пароль можно с помощью sp_apprplepassword. Управление разрешений ролей приложений осуществляется из SQL SEM или с помощью операторов GRANT, REVOKE и DENY. Например, DENY SELECT ON ‘имя таблицы’ TO ‘имя роли приложения’.

Для активизации роли приложения подключённого к серверу баз данных клиента через сопоставленное этой роли приложение, необходимо, что бы в этом приложении был выполнен оператор T-SQL sp_setapprole. Выполнить этот оператор из хранимой процедуры или в определённой пользователем транзакции не получится. Синтаксис оператора следующий:

 

sp_setapprole [@rolename=] ‘роль’,

[@password=] {Encrypt N ‘пароль’} | ‘пароль’

[,[@encrypt=] ‘стиль_шифрования’]

 

Приложение должно уметь подставлять пароль, даже если он зашифрован, например, с использованием функции ODBC ENCRYPT. При шифрации пароля он должен быть преобразован в строку типа Unicode, посредством размещения непосредственно перед ним символа «N».

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

 

2.8 Управление транзакциями

 

 

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

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

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

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

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

В менеджер журнала транзакций SQL Server 7.0 внесены следующие усовершенствования:

• Отсутствует конкуренция со страницами данных за буфер кэша
• Журнал может располагаться в одном или нескольких физических файлах
• Автоматическое увеличение и сокращение размеров журнала
• Возможно быстрое и безопасное усечение
• Учитывает особенности операций с большим объемом ввода-вывода

 

2.8.1 SQL-выражения для управления транзакциями

Для управления транзакциями имеется три выражения:

• SET TRANSACTION — Начинает транзакцию и определяет ее поведение.
• COMMIT — Сохраняет изменения, внесенные транзакцией, в базе данных и завершает транзакцию.

• ROLLBACK — Отменяет изменения, внесенные транзакцией, и завершает транзакцию.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3.1 Среда использования SQL Server 7.0

Медицина.  Какие СУБД прижились в медицине?

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

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

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

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

Подавляющее большинство современных комплексных медицинских информационных систем основано на архитектуре «Клиент-сервер». Практическим опытом доказана неизбежность такого решения для создания комплексной информационной системы, так как настольные базы данных, в том числе с использованием файл-сервера, способны поддерживать только до 10 рабочих станций и небольшой объем базы данных. Кроме того, значительная часть существующих требований к медицинским информационным системам уже реализована в промышленных СУБД, построенных в архитектуре “клиент — сервер”, что позволяет существенно сократить время на создание системы.

 

Распределение отечественных комплексных медицинских информационных систем по применяемым СУБД

 

 

Для сравнения: если проанализировать все медицинское ПО, использующее архитектуру «клиент — сервер», доля СУБД Microsoft SQL Server составит 64%. Некоторые разработчики (17%) допускают использование нескольких СУБД, чаще всего, это комбинация Microsoft SQL Server или Oracle. Две системы (Карельская медицинская информационная система и «Парацельс-А») используют несколько СУБД – Lotus Notes/Domino и реляционную СУБД (Microsoft SQL Sever и IBM DB2 соответственно).

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

Распределение числа внедрений отечественных комплексных медицинских информационных систем по применяемым СУБД

В настоящее время лидером на отечественном рынке комплексных медицинских информационных систем по числу инсталляций является Microsoft SQL Server (различных версий), которому принадлежит 47% всех инсталлированных комплексных медицинских информационных систем. Второе место занимает Oracle (27%), третье – FireBird, у которого 15% всех инсталляций.

Распределение СУБД в зависимости от объема внедрений
комплексных медицинских информационных систем

 

 

Почти такая же ситуация наблюдается при анализе среднего числа инсталляций на одну систему, где лидером является Microsoft SQL Server – в среднем системы, написанные как приложения для этой СУБД, имеют на сегодня 31 внедрение. Почти рядом расположены Oracle и FireBird. Примечательно, что все эти системы являются чисто реляционными СУБД. Значительно отстают от них постреляционные системы – Lotus Notes/Domino и Cache. Вероятно, это связано с тем, что интерес к постреляционным технологиям активно начал проявляться лишь в последние 5-6 лет, дав фору реляционным СУБД.

 

 

 

 

 

 

Примеры внедрения Microsoft SQL Server 7.0

ВНЕДРЕНИЯ В СНГ

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

Интегрированная Налоговая Информационная Система Республики Казахстан
Программные продукты и технологии Microsoft использованы для построения первой очереди распределенной информационной системы налоговых органов Республики Казахстан.

База данных информационной системы банка Заречье переведена на платформу Microsoft SQL Server 7.0

Автоматизация московского офиса Ericsson
Информационная система, построенная на базе технологий Microsoft, позволила повысить производительность труда сотрудников российской компании Ericsson — «Эрикссон Корпорация АО»

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

 

ВНЕДРЕНИЯ ЗА РУБЕЖОМ

Электронная биржа SWX Swiss Exchange: c Microsoft Windows 2000 — в следующее тысячелетие
Электронная биржа SWX Swiss Exchange решила перейти на Microsoft ^® Windows^® 2000. Именно эта платформа корпорации Microsoft ляжет в основу новой системы торгов третьей по величине европейской биржи.

Верховный суд штата Оклахома (США) полностью перешел на Windows 2000; Все 63 сервера и 1200 клиентских компьютеров работают безукоризненно
Создана надежная управляемая инфраструктура для системы наблюдения за судебными делами; Windows 2000 используется на общедоступном веб-узле, на который ежедневно поступает 100 000 обращений.

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

Royal Bank of Scotland открывает электронные двери для вкладчиков и заемщиков
Royal Bank of Scotland укрепил свое присутствие в Интернете, открыв линию по работе с клиентами на базе веб-сайта. Воспользовавшись услугами DPR Consulting и технологиями корпорации «Майкрософт», банк создал новую службу на основе созданной им ранее — первой в Великобритании -системы выполнения транзакций посредством Интернета, и Quista! — провайдера бесплатного доступа к Интернету и веб-портала. Новая служба анализирует потребности клиента и выдает соответствующие рекомендации по выбору банковских услуг. Прием заявок и проверка кредитоспособности выполняются по Интернету. Служба была открыта в сентябре 1999 года и предлагает множество новых возможностей, таких как выполнение вычислений, индивидуальное заполнение форм и внесение депозита в интерактивном режиме, что существенно упрощает открытие новых счетов, управление ими и онлайновое рассмотрение заявок на ссуды.

Полицейское управление г. Гамбурга (Германия): Технологии Microsoft на страже закона
Полиция Гамбурга нуждалась в решении, которое повысило бы эффективность обработки дел. Универсальная система обработки дел во всех сферах деятельности полиции интегрирована с мощной офисной коммуникационной системой. Теперь Microsoft Word, Microsoft Exchange Server и Microsoft Internet Explorer встроены в централизованную базу данных на основе Microsoft SQL Server 7.0, что позволило удовлетворить два казалось бы несовместимых требования: обеспечена не только простота регистрации информации на бланках, но и ее дальнейшая автоматизированная обработка в других системах. При этом достигнута существенная экономия временных затрат на обработку дел.

Comshare и Domino’s Pizza Inc.
Одна из крупнейших в мире частных ресторанных сетей, Domino Pizza завершила внедрение нового решения в области интеллектуального ведения бизнеса на базе технологии DecisionWeb, разработанной имеющей статус Microsoft Certified Partner компанией Comshare, с помощью Microsoft^® SQL Server™ 7.0 OLAP Services. Комбинация этих технологий дает возможность получить сотрудникам штаб-квартиры и удаленных пользователей Domino доступ к более, чем 150 Гбайтам информации, необходимой им для принятия решений из обозревателя Интернета.

ПО Microsoft обеспечивает более эффективную работу персонала Turner Broadcasting и сокращение расходов на поддержку
Одна из основных задач любого крупного предприятия — поддерживать актуальность информации и эффективность бизнес-процессов так, чтобы его сотрудники могли быстро принимать важные решения. Компания Turner Broadcasting рассчитывает, что Microsoft^® Office 2000 предоставит ее специалистам по продажам инструменты, используя которые, они будут тратить меньше времени на поиск и ввод информации и смогут уделять больше внимания тому, что им удается лучше всего — увеличению объемов продаж. Необходимо отметить, что сотрудникам отдела информационных технологий Turner Broadcasting удалось развернуть Office 2000 чрезвычайно эффективным методом.

Pennzoil
Как компания Pennzoil вышла на новый уровень производительности после  перехода на SQL Server 7.0.

L.A. Cellular
Почему телефонная компания, обслуживающая громадную территорию в условиях жесткой конкуренции и быстрого меняющихся требований ее клиентов выбрала SQL Server 7.0 в качестве платформы для своего решения по поддержки при принятии решений

Barnes & Noble
Гигантская компания по торговле книжной продукцией создает магазин электронной торговли с помощью SQL Server 7.0 и других продуктов семейства Microsoft BackOffice.

CBS SportsLine
SQL Server 7.0 в комбинации с Microsoft Site Server 3.0 Commerce Edition — мощное решение для обеспечения управления содержанием и электронной коммерцией в рамках спортивного веб-узла.

Comcast Cellular
С помощью SQL Server 7.0, Comcast Cellular добилась роста производительности и масштабируемости своей системы, что позволяет ей оставаться конкурентноспособной на стремительно развивающемся рынке телекоммуникаций.

 

Заключение:

 

Выбранная мной,  тема курсовой работы :  «Активное администрирование приложений SQL Server 7.0»,  на данный момент времени, является  актуальной, в связи с тем, что  многие корпорации и независимые поставщики программного обеспечения, создающие приложения для бизнеса, остановили свой выбор на СУБД SQL Server как на лучшей системе управления базами данных для Windows NT®.

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

Microsoft SQL Server 7.0 представляет собой совершенную реализацию СУБД Microsoft, созданную на прочной основе SQL Server 6.5. Для SQL Server 7.0 было заявлено более десятка новых патентов в области технологий СУБД. Среди аспектов, которых затронули передовые нововведения:

• Масштабируемость от портативных компьютеров до корпоративных систем при использовании единой программной основы, что обеспечивает абсолютную совместимость на уровне кодов.
• Поддержка автоматического конфигурирования и самонастройки.
• Интеграция OLAP-сервера.
• Интеграция служб преобразования данных (Data Transformation Services — DTS).
• Решение проблемы метаданных с привлечением Data Warehousing Framework как наиболее всеобъемлющего подхода.
• Обеспечение мультисерверного управления для нескольких серверов.
• Широкий спектр возможностей репликации любой базы данных.
• Отличная интеграция с Windows NT Server, Microsoft Office и продуктами семейства Microsoft BackOffice®.
• Высокопроизводительный доступ к информации из разнообразных источников с помощью Универсального доступа к данным (Universal Data Access — UDA).

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

 

В курсовой работе   описываются инновации и усовершенствования в разработке приложений  Microsoft SQL Server 7.0.

В первой части описывается само определение DQL Server 7.0, затем история развития, цели разработки, новаторство, масштабируемость и надежность. Также немного слов о совместимости. Далее идет речь о сетевой архитектуре «клиент-сервер».Следующая часть посвящена непосредственно активному администрированию. Где рассматриваются возможности администратора, способов манипуляции над объектами, свойства приложений и т.д. Затем в архитектуре Microsoft SQL Server описываются имеющиеся компоненты. Далее рассматриваются стороны легкого использования СУБД.      Также об администрировании учетных записей, о ролях, о сопоставлении учетных записей ролям, о правах доступа. Так как все операции, выполняемые с данными на SQL сервере, происходят в контексте транзакций, описана была и эта часть. В завершающей части была указана среда использования Microsoft SQL Server 7.0, а также приведены примеры внедрения.

 

В своей курсовой по дисциплине «Системам баз данных» я рассматривала тему «СУБД Microsoft SQL Server 7.0 ».  Я постаралась просто и понятно описать     активное администрирование приложений.

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Список используемой литературы:

 

 

1. И.М. Тишкевич «Microsoft SQL Server 7.0. Разработка приложений», 2007
2. Диго С.М. Проектирование и использование баз данных. — М.: Финансы и статистика, 1996.
3. Дейт К. Введение в системы баз данных:Пер.с англ. — М.: Наука, 1988.
4. материалы, статьи, лекции с Интернета:

www.google.ru

www.microsoft.com/sql/.

www.citforum.ru

www.sql.ru/supscribe/70028/03.shtml#2

www.intuit.ru/department/database/sql/2/4.html/