В начало
Лекция. Основные понятия БД
1. Банки данных 2. Организация баз данных 3. Архитектуры информационных систем Для успешного функционирования различных организаций
требуется наличие развитой информационной системы, которая реализует
автоматизированный сбор, обработку и манипулирование данными. 1.
Банки данных Современной формой информационных систем являются
банки данных, включающие в свой состав следующие составляющие:
·
одну или
несколько баз данных (БД); ·
набор прикладных
программ (приложений БД). База данных обеспечивает хранение информации, а также
удобный и быстрый доступ к данным. Она представляет собой совокупность данных
различного характера, организованных по определенным правилам. Информация в БД
должна быть: · непротиворечивой; · неизбыточной; · целостной. Система управления базой данных (СУБД) – это
совокупность языковых и программных средств, предназначенных для создания,
ведения и использования БД. По характеру применения СУБД разделяют на
персональные и многопользовательские. Персональная СУБД обеспечивает возможность создания
локальных БД, работающих на одном компьютере. К персональным СУБД относятся Paradox, dBase, FoxPro, Access и др. Замечание СУБД MS Office Access обеспечивают возможность многопользовательского доступа к данным. Многопользовательские СУБД позволяют создавать
информационные системы, функционирующие в архитектуре
"клиент-сервер". Наиболее известными многопользовательскими СУБД
являются Oracle, Informix, SyBase, Microsoft SQL Server, InterBase. В состав языковых средств современных СУБД входят: · язык описания данных, предназначенный для описания
логической структуры данных; · язык манипулирования данными, обеспечивающий
выполнение основных операций над данными – ввод, модификацию и выборку; · язык структурированных запросов (SQL – Structured Query Language), обеспечивающий
управление структурой БД и манипулирование данными, а также являющийся
стандартным средством доступа к удаленным БД; · язык запросов по образцу (QBE – Query By Example), обеспечивающий
визуальное конструирование запросов к БД. Прикладные программы, или приложения, служат для
обработки данных, содержащихся в БД. Пользователь осуществляет управление БД и
работу с ее данными именно с помощью приложений, которые также называют приложениями
БД. Иногда термин "база данных" трактуют в более
широком смысле и обозначают им не только саму БД, но и приложения,
обрабатывающие ее данные. Хотя система Delphi и
не является СУБД в буквальном смысле этого слова, она тем не менее обладает
вполне развитыми возможностями СУБД. Предоставляемые Delphi средства обеспечивают создание и ведение локальных и
клиент-серверных БД, а также разработку приложений для работы практически с любыми
БД. Назвать Delphi обычной СУБД мешает,
наверное, только то, что, с одной стороны, она не имеет своего формата таблиц
(языка описания данных) и использует форматы таблиц других СУБД, например, dBase, Paradox или InterBase. Это вряд ли является недостатком, поскольку
названные форматы хорошо себя зарекомендовали. С другой стороны, в плане
создания приложений различного назначения, в том числе приложений БД,
возможности Delphi не уступают возможностям
специализированных СУБД, а зачастую и превосходят их. 2. Организация баз данных База данных содержит данные, используемые некоторой
прикладной информационной системой (например, системами "Сирена" или
"Экспресс" продажи авиа- и железнодорожных билетов). В зависимости от
вида организации данных различают следующие основные модели представления данных
в базе: ·
иерархическую; ·
сетевую;
В иерархической
модели данные представляются в виде древовидной (иерархической) структуры. Подобная
организация данных удобна для работы с иерархически упорядоченной информацией,
однако при оперировании данными со сложными логическими связями иерархическая
модель оказывается слишком громоздкой. В сетевой
модели данные организуются в виде произвольного графа. Недостатком сетевой
модели является жесткость структуры и высокая сложность ее реализации. Кроме того, значительным недостатком иерархической и
сетевой моделей является также то, что структура данных задается на этапе
проектирования БД и не может быть изменена при организации доступа к данным. В объектно-ориентированной
модели отдельные записи базы данных представляются в виде объектов. Между
записями базы данных и функциями их обработки устанавливаются взаимосвязи с
помощью механизмов, подобных соответствующим средствам в
объектно-ориентированных языках программирования. Объектно-ориентированные
модели сочетают особенности сетевой и реляционной моделей и используются для
создания крупных БД со сложными структурами данных. Реляционная модель получила свое название от английского термина relation (отношение) и была предложена в 70-х годах
сотрудником фирмы IBM Эдгаром Коддом. Реляционная БД
представляет собой совокупность таблиц, связанных отношениями. Достоинствами
реляционной модели данных являются простота, гибкость структуры, удобство
реализации на компьютере, наличие теоретического описания. Большинство
современных БД для персональных компьютеров являются реляционными. При
последующем изложении материала речь пойдет именно о реляционных БД. 3. Архитектуры информационных систем В зависимости от взаимного расположения приложения и
БД можно выделить: · локальные БД; · удаленные БД. Для выполнения операций с локальными БД
разрабатываются и используются так называемые локальные приложения, а для
операций с удаленными БД – клиент-серверные приложения. Расположение БД в значительной степени влияет на
разработку приложения, обрабатывающего содержащиеся в этой базе данные. Delphi-приложение осуществляет доступ к БД через BDE (Borland Database Engine
– процессор баз данных фирмы Borland). BDE представляет собой совокупность динамических библиотек
и драйверов, обеспечивающих доступ к данным. BDE должен устанавливаться на всех компьютерах, на
которых выполняются Delphi-приложения, осуществляющие
работу с БД. Приложение через BDE передает
запрос к базе данных, а обратно получает требуемые данные. Локальные БД располагаются на том же компьютере, что и
работающие с ними приложения. В этом случае говорят, что информационная система
имеет локальную архитектуру (рис. 2.1). Работа с БД происходит, как правило, в
однопользовательском режиме. При необходимости можно запустить на
компьютере другое приложение, одновременно осуществляющее доступ к этим же
данным. Для управления совместным доступом к БД необходимы специальные среде а
контроля и защиты. Эти средства могут понадобиться, например, в случае, когда
приложение пытается изменить запись, которую редактирует другое приложение.
Каждая разновидность БД осуществляет подобный контроль своими способами и
обычно имеет встроенные средства разграничения доступа. Рис. 2.1. Локальная
архитектура Для доступа к локальной БД процессор баз данных BDE использует стандартные драйверы, которые позволяют
работать с форматами БД dBase, Paradox, FoxPro, а также
с текстовыми файлами. При использовании локальной БД в сети возможна
организация многопользовательского доступа. В этом случае файлы БД и
предназначенное для работы с ней приложение располагаются на сервере сети. Каждый
пользователь запускает со своего компьютера это расположенное на сервере
приложение, при этом у него запускается копия приложения. Такой сетевой вариант
использования локальной БД соответствует архитектуре "файл-сервер".
Приложение при архитектуре "файл-сервер" также может быть записано и
на каждый компьютер сети, в этом случае приложению отдельного компьютера должно
быть известно местонахождение общей БД (рис. 2.2). При работе с данными на каждом пользовательском
компьютере сети используется локальная копия БД. Эта копия периодически
обновляется данными, содержащимися в БД на сервере. Архитектура "файл-сервер" обычно применяется
в сетях с небольшим количеством пользователей, для ее реализации подходят
персональные СУБД, например, Paradox или dBase. Достоинствами этой архитектуры являются простота
реализации, а также то, что приложение фактически разрабатывается в расчете на
одного пользователя и не зависит от компьютера сети, на который оно устанавливается. Однако архитектура "файл-сервер" имеет и
существенные недостатки. · Пользователь работает со своей локальной копией БД,
данные в которой обновляются при каждом запросе к какой-либо из таблиц. При
этом с сервера пересылается новая копия всей таблицы, данные которой
затребованы. Таким образом, если пользователю необходимо несколько записей
таблицы, с сервера по сети пересылается вся таблица. В результате циркуляции в
сети больших объемов избыточной информации резко возрастает нагрузка на
сеть, что приводит к соответствующему снижению ее быстродействия и производительности
информационной системы в целом. · В связи с тем, что на каждом компьютере имеется своя
копия БД, изменения, сделанные в ней одним пользователем, в течение некоторого
времени являются неизвестными другим пользователям. Поэтому требуется постоянное
обновление БД. Кроме того, возникает необходимость синхронизации работы
отдельных пользователей, связанная с блокировкой в таблицах записей, которые в
данный момент редактирует другой пользователь. · Управление БД осуществляется с разных компьютеров,
поэтому в значительной степени затруднена организация контроля доступа, соблюдения
конфиденциальности и поддержания целостности БД. Рис. 2.2. Архитектура "файл-сервер" Удаленная БД размещается
на компьютере-сервере сети, а приложение, осуществляющее работу с этой БД,
находится на компьютере пользователя. В этом случае мы имеем дело с
архитектурой "клиент-сервер" (рис. 2.3), когда информационная
система делится на неоднородные части – сервер и клиент БД. В связи с тем, что
компьютер-сервер находится отдельно от клиента, его также называют удаленным
сервером. Клиент – это приложение пользователя. Для получения данных
клиент формирует и отсылает запрос удаленному серверу, на котором размещена
БД. Запрос формулируется на языке SQL,
который является стандартным средством доступа к серверу при использовании реляционных
моделей данных. После получения запроса удаленный сервер направляет его SQL-серверу (серверу баз данных) – специальной программе,
управляющей удаленной БД и обеспечивающей выполнение запроса и выдачу его
результатов клиенту. Таким образом, в архитектуре "клиент-сервер"
клиент посылает запрос на предоставление данных и получает только те данные,
которые действительно были затребованы. Вся обработка запроса выполняется на
удаленном сервере. Такая архитектура обладает следующими достоинствами. · Снижение нагрузки на сеть, поскольку теперь в ней
циркулирует только нужная информация. · Повышение безопасности информации, связанное с тем,
что обработка запросов всех клиентов выполняется единой программой,
расположенной на сервере. Сервер устанавливает общие для всех пользователей
правила использования БД, управляет режимами доступа клиентов к данным, запрещая,
в частности, одновременное изменение одной записи различными пользователями. · Уменьшение сложности клиентских приложений за счет
отсутствия в них Рис. 2.3. Архитектура "клиент-сервер" ("толстый" клиент) Для реализации архитектуры "клиент-сервер"
обычно используются многопользовательские СУБД, например, Oracle или Microsoft SQL Server. Подобные СУБД также называют промышленными, т. к.
они позволяют создать информационную систему организации или предприятия с
большим числом пользователей. Промышленные СУБД являются сложными системами и
требуют мощной вычислительной техники и соответствующего обслуживания.
Обслуживание выполняет специалист (или группа специалистов), называемый
системным администратором БД (администратором). Основными задачами системного
администратора являются: § защита БД; § поддержание целостности БД; § обучение и подготовка пользователей; § загрузка данных из других БД; § тестирование данных; § резервное копирование и восстановление; § внесение изменений в информационную систему. Доступ Delphi-приложения
к промышленным СУБД осуществляется через драйверы SQL-Links. Отметим,
что при работе с "родной" для Delphi СУБД InterBase можно
обойтись без драйверов SQL-Links. Описанная архитектура является двухуровневой –
приложение-клиент и сервер БД. Клиентское приложение также называют сильным,
или "толстым", клиентом. Дальнейшее развитие данной архитектуры
привело к появления трехуровневого варианта "клиент-сервер" –
приложение-клиент, сервер приложений и сервер БД (рис. 2.4). Рис. 2.4.
Трехуровневая архитектура "клиент-сервер" ("тонкий" клиент) В трехуровневой архитектуре часть средств и кода,
предназначенных для организации доступа к данным и их обработке, из
приложения-клиента выделяется в сервер приложений. Само клиентское приложение
при этом называют слабым, или "тонким", клиентом. В сервере
приложений удобно располагать средства и код, общие для всех клиентских
приложений, например, средства доступа к БД. Основные достоинства трехуровневой архитектуры
"клиент-сервер" состоят в следующем: § разгрузка сервера от выполнения части операций,
перенесенных на сервер § уменьшение размера клиентских приложений за счет
разгрузки их от лишнего кода; § единое поведение всех клиентов; § упрощение настройки клиентов – при изменении общего
кода сервера приложений автоматически изменяется поведение
приложений-клиентов. Отметим, что локальные приложения БД называют одноуровневыми,
а клиент-серверные приложения БД – многоуровневыми. |
| |