БАЗЫ ДАННЫХ      2009                                    

 Данный файл содержит 1-4, 6, 10, 13, 14 лекции                                                
Лекция 1

                                                 Введение

        В начале 70-х годов для удобства работы с большими массивами данных сформулирована   концепция баз данных. Ее основными положениями были:

1.Независимость прикладных программ от данных, размещенных во внешней памяти

2. Отсутствие избыточности в данных

3.Способность системы противостоять сбоям и отказам.

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

Эта система была названа СУБД (система управления базами данных).

     


 

        С 70 годов стали появляться различные СУБД. Наиболее известными из них были: IMS/360, TOTAL, ADABAS, ОКА, БАНК, СЕТОР, СЕДАН, ДИСОД. Эти системы разрабатывались для больших вычислительных машин. Они были мощные и интересные по своим возможностям, но достаточно сложные для понимания и освоения. 

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

       Наиболее известными и широко используемыми в настоящее время являются

 СУБД Oracle, MS SQL Server и DB/2.

           
Тема 1. Основные положения теории баз данных

                         1.1   База данных и ее компоненты

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

 Под объектом может пониматься предмет или процесс окружающего мира.

     

На рис. 1.1 представлен типичный состав БД и показана связь БД с пользователем.
                
                                                                                                     
                         

   

                                  Рис. 1.1   Взаимодействие пользователя с БД                          

 

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

        Индексы – это специальные элементы  структуры БД, служащие для ускорения обработки запросов пользователя.

      Представления – виртуальные таблицы,  предоставляемые пользователям  для повышения производительности и надежности системы.

    Хранимые процедуры -  программные модули  для реализации самых разных задач, хранимые непосредственно в БД.

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

     Метаданные – данные, которые описывают  данные пользователя (структуру, особенности, права пользователя и т.д.), т. е.  это данные о данных. Метаданные используются самой СУБД,  а не пользователями.
                                  1.2. Использование БД

   Основным инструментом пользователя при использовании БД является СУБД.

СУБД- сервисная программная система, служащая для создания и поддержки БД.

    Таким образом, любая СУБД должна:

1)      уметь создавать БД.

2)      поддерживать БД

К функциям поддержки прежде всего относятся: 

-управление внешней памятью,

-управление буферами,

- поддержка встроенного языка,

- управление транзакциями.

    Все современные СУБД могут работать в двух режимах:

-         в режиме диалога

-         в режиме прикладных программ.

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

     Как видно из рис.1.1, приложения

1) создают и передают запросы к БД на поиск или модификацию необходимых данных

2)     создают и обрабатывают формы и отчеты

Отчет – это некоторая выборка данных из БД, структурированная

определенным образом.

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

 1 Конечные пользователи (это лица, для которых создается система с БД)

  2 Разработчики приложений (программисты)

 Программисты используют БД  на стадии разработки системы с БД (информационной системы).

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

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

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

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

    Тема  2    Интеграция данных
                       2.1. Хранилища данных

      

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

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

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

                    Хранилище  - это  предметно - ориентированный,   интегрированный,   привязанный   ко  времени и неизменяемый набор данных, предназначенный для поддержки принятия решений.

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

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

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

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

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

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

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

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

       После того как данные записаны в хранилище (т.е. выполнена операция вставки) они никогда из него не удаляются, оно постоянно растет. Кроме того эти данные не модифицируются (т.е. не выполняются операции типа Update).

  

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

      На рис. 2.1 представлен пример интеграции данных на основе двух источников.

                              

                   Рис.2.1 Организация хранилища данных

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

      Компонент трансляции/загрузки данных – программное средство, обеспечивающее:

1)                                             объединение (интеграцию) данных, извлеченных из разных источников,

2)                                             преобразование форматов извлеченных данных в форматы, используемые хранилищем,

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

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

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

      

          Существует  три  основных способа  сбора информации в хранилище данных.

1.Содержимое хранилища периодически (скажем, еженощно) реконструируется на основе текущей информации источников — наиболее общий подход, основной недостаток которого зачастую связан с необходимостью "отключения" системы от внешнего мира на время выполнения процедуры трансляции/загрузки, нередко весьма продолжительной. Другой изъян заключается в том, что данные в хранилище быстро теряют актуальность.
 2. В хранилище периодически заносятся данные из    источников,    претерпевшие  изменения с момента осуществления последней загрузки.

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

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

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

                                              

                                                    2.2.    Медиаторы



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

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

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

                 Как видно из рис.2.2, медиатор посылает запросы каждой из оболочек, а те в свою очередь адресуют их соответствующим источникам. (В определенных случаях медиатор способен направлять какой-либо оболочке целую серию запросов, а к некоторым другим оболочкам не обращаться вовсе.) Оболочка передает медиатору полученный ею итог обработки запроса, а медиатор, осуществляя объединение и трансляцию данных, возвращенных оболочками, формирует окончательный результат и отсылает его пользователю
Лекция 14

ТЕМА 3.   К
лиент-серверные системы

                                              3.1. Основные понятия

         Ранее мы отмечали, что с БД одновременно может работать много пользователей. Это достигается использованием технологии  "клиент/сервер".

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

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

Сервер – это часть системы,  обслуживающая  клиента, т.е. предоставляющая сервисы по запросам клиентов.

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

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

1 функции ввода-вывода и отображения данных

2 функции реализации прикладной задачи

3 функции обработки данных внутри прикладной задачи

4 функции управления базой данных

5 служебные функции

 Состав типового приложения,  работающего с БД,  представлен на рис.3.1.



                        Рис.3.1. Состав типового приложения

1. Ввод-вывод и отображение  предусматривает:

 - формирование экранных изображений

- чтение и запись информации в экранные формы

- обработка движений мыши и нажатий клавиш и пр.

Для этого используются различные графические интерфейсы, например,

GUI,  который поддерживается в разных операционных системах Windows,

OS/2  и др.

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

Обычно для такой реализации используются базовые или другие алгоритмические языки (Cи++, Visual Basic и др.).
3. Обработка данных внутри  прикладной задачи предполагает использование запросов к БД на выборку или модификацию требуемых данных. Для этого используются операторы языка SQL.

4. Функции управления БД – это функции самой СУБД.

5. Служебные функции выполняют роль связок между первыми четырьмя функциями. Эти функции обеспечиваются промежуточным программным обеспечением (ППО).
      Распределение указанных 5-ти функций между клиентами и сервером является основной задачей проектирования клиент-серверных систем.

      В настоящее время нет какой-либо методики такого распределения.

 Как правило,  распределить 5 функций  строго не удается: отдельные  части какой-либо функции могут присутствовать и на клиенте и на сервере.

      Далее будут рассмотрены наиболее распространенные модели реализации архитектуры “клиент-сервер”.   
               3.2 Модели клиент –сервер в архитектуре баз данных
                     Модель удаленного доступа к данным

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

          Основное достоинство – унификация интерфейса: общение между клиентом и сервером основывается на языке SQL.

         Недостаток: Разные клиенты могут выполнять одинаковые операции. Следовательно,  с одной стороны,  дублируется код клиентов, а с другой – сервер выполняет одинаковые операции.
                              Модель активного сервера БД

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

Обработка данных выполняется операторами встроенного SQL.

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

                  Клиент                                                 Сервер




            
                           Рис.3.3. Модель активного сервера БД

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

     Недостатком модели является большая загрузка сервера.
                                  Модель сервера приложений

Данная трехзвенная модель находит В настоящее время все большее число поклонников находит трехзвенная модель сервера приложений (рис.3.4). Это обусловлено ее гибкостью


            Клиент                     Сервер приложений      Сервер БД





                Рис.3.4. Модель сервера приложений        

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

        К недостаткам модели следует отнести  большие затраты на ее реализацию, обусловленные большей сложностью.

Кроме того эта модель менее надежная по сравнению с двухзвенной.

  
                                  3.3.     Промежуточное программное обеспечение

          Клиенты и серверы в принципе могут располагаться на одном ПК.

Но более типично использование нескольких ПК,  связанных сетью.

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

    На рис.3.5 показано взаимодействие между компонентами ППО.

      
                                       Рис.3.5. Взаимодействие между компонентами ППО

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

     Таким образом,  ППО обычно включает в себя 3 компонента, показанные на  рис.3.6:

-программный  интерфейс приложения (Application Programming Interfase, API),

-         транслятор запросов,

-   сетевой транслятор.

                               



                         Рис. 3.6. Компоненты ППО
         Эти компоненты (или их функции) в основном распределяются по нескольким  уровням программного обеспечения.

          Программный интерфейс приложения (АР1)  открыт для  клиентского приложения.  Программист взаимодействует с ППО через АРI, поставляемый вместе с  ППО. API ППО позволяет программисту писать стандартный код SQL вместо кода, специфичного для данного сервера БД. Иначе говоря, АР1 обеспечивает  независимость клиентского процесса от сервера БД. Такая независимость означает, что сервер можно заменить без необходимости переписывать клиентское приложение.

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

     Сетевой транслятор управляет сетевыми  коммуникационными протоколами.   

Напомним,  что сервер может использовать любые сетевые протоколы. Поэтому если клиентское приложение подключается к двум базам данных, в одной из которых используется протокол TCP/IP,  а в другой  IPX/SPX , то сетевой транслятор обрабатывает все детали связи каждой базы данных прозрачно для клиентского приложения.