Единое окно доступа к образовательным ресурсам

Введение в системы баз данных: Учебное пособие

Голосов: 3

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

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

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




                 Рис. 2.3. Модель файлового сервера

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


                                 22


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

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




                  Рис. 2.4. Модель удаленного доступа

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


                                  23


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

      Модель сервера баз данных
      Технологию "клиент — сервер" поддерживают большинство
современных СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server. В
основу данной модели добавлен механизм хранимых процедур и механизм
триггеров.
      Механизм хранимых процедур позволяет создавать подпрограммы,
работающие на сервере и управляющие его процессами.
      Таким образом, размещение на сервере хранимых процедур означает,
что прикладные функции приложения разделены между клиентом и
сервером. Трафик обмена информацией между клиентом и сервером резко
уменьшается.
      Централизованный контроль целостности базы данных в модели
сервера баз данных выполняется с использованием механизма триггеров.
Триггеры также являются частью БД.
      Триггер — это особый тип хранимой процедуры, реагирующий на
возникновение определенного события в БД. Он активизируется при
попытке изменения данных — при операциях добавления, обновления и
удаления. Триггеры определяются для конкретных таблиц БД.
      Внедрение триггеров незначительно влияет на производительность
сервера и часто используется для усиления приложений, выполняющих
многокаскадные операции в БД.
      В данной модели (рис. 2.5) сервер является активным, потому что не
только клиент, но и сам сервер, используя механизм триггеров, может быть
инициатором обработки данных в БД. Поскольку функции клиента
облегчены переносом части прикладных функций на сервер, он в этом
случае называется "тонким".
      При всех положительных качествах данной модели у нее все же есть
один недостаток — очень большая загрузка сервера.




                                   24


                    Рис. 2.5. Модель сервера БД

2.4.2. Сервер приложений. Трехуровневая модель
      Эта модель является расширением двухуровневой модели и в ней
вводится дополнительный промежуточный уровень между клиентом и
сервером. Архитектура трехуровневой модели приведена на рис. 2.6.




             Рис. 2.6. Архитектура трехуровневой модели

                                 25


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

3. Концепции проектирования БД

3.1. Жизненный цикл БД
      Как и любой программный продукт, база данных обладает
собственным жизненным циклом (ЖЦБД). Главной составляющей в
жизненном цикле БД является создание единой базы данных и программ,
необходимых для ее работы.
      ЖЦБД включает в себя следующие основные этапы (рис. 3.1):
   1. планирование разработки базы данных;
   2. определение требований к системе;
   3. сбор и анализ требований пользователей;
   4. проектирование базы данных:
            концептуальное проектирование базы данных;
            логическое проектирование базы данных;
            физическое проектирование базы данных;
   5. разработка приложений:
            проектирование транзакций;
            проектирование пользовательского интерфейса;
   6. реализация;
   7. загрузка данных;
   8. тестирование;
   9. эксплуатация и сопровождение:


                                26


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




                     Рис. 3.1. Жизненный цикл БД


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

                                  27


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

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

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

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

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



                                  28


     Этот подход начинается с разработки моделей данных, которые
содержат несколько высокоуровневых сущностей и связей, затем работа
продолжается в виде серии нисходящих уточнений низкоуровневых
сущностей, связей и относящихся к ним атрибутов.
     Нисходящий подход демонстрируется в концепции модели
"сущность — связь" (Entity-Relationship model — ER-модель) — самой
популярной технологии высокоуровневого моделирования данных,
предложенной П. Ченом.
     Модель "сущность — связь" относится к семантическим моделям.
Семантическое моделирование данных, связанное со смысловым
содержанием данных, независимо от их представления в ЭВМ.
     В построении общей концептуальной модели данных выделяют ряд
этапов.
     Выделение локальных представлений, соответствующих обычно
     относительно независимым данным. Каждое такое представление
     проектируется как подзадача.
     Формулирование сущностей, описывающих локальную предметную
     область проектируемой БД, и описание атрибутов, составляющих
     структуру каждой сущности.
     Выделение ключевых атрибутов.
     Спецификация связей между сущностями. Удаление избыточных
     связей.
     Анализ и добавление неключевых атрибутов.
     Объединение локальных представлений.
     Созданная концептуальная модель данных предприятия является
источником информации для фазы логического проектирования базы
данных.

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



                                 29


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

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

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

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


                                  30


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

3.1.6. Реализация
      На данном этапе осуществляется физическая реализация базы
данных и разработанных приложений, позволяющих пользователю
формулировать требуемые запросы к БД и манипулировать данными в БД.
      База данных описывается на языке определения данных выбранной
СУБД. В результате компиляции его команд и их выполнения создаются
схемы и пустые файлы базы данных. На этом же этапе определяются и все
специфические пользовательские представления.
      Прикладные программы реализуются с помощью языков третьего
или четвертого поколений. Кроме того, на этом этапе создаются другие
компоненты проекта приложения — например, экраны меню, формы ввода
данных и отчеты.
      Реализация этого, а также и более ранних этапов проектирования БД
может осуществляться с помощью инструментов автоматизированного
проектирования и создания программ, которые принято называть CASE-
инструментами (Computer-Aided Software Engineering).

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

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


                                   31



    
Яндекс цитирования Яндекс.Метрика