Введение. Банки и базы данных. Архитектура СУБД.

Проектирование баз данных.

Лекция 1.

Введение. Банки и базы данных. Архитектура СУБД.

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

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

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

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

Банк данных – организация либо структурная единица организации, предназначенная для сбора и обработки информации о предметной области. В функции банка данных входит сбор информации о первичной области, ее обработка и хранение, а также генерация на ее основе результирующей информации. Следует отметить, что иногда технологии обработки информации, характерные для банков данных реализуются не в «чистом» виде, а как составная часть других систем, например, в задачах САПР (Систем Автоматизированного ПPоектирования).

Информация о состоянии предметной области, которая обрабатывается банком данных, накапливается и хранится в базе данных.

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

Для выполнения своих задач банку данных необходимы следующие компоненты.

1. Аппаратное обеспечение (вычислительная техника). Поскольку в почти любом банке данных предполагается работа нескольких операторов одновременно, постольку банк данных должен быть оснащен какой- либо многопользовательской системой. До середины 80-х годов наиболее популярными были дисплейные классы на базе машин класса мейнфрейм. Подобные комплексы позволяют подсоединение до нескольких десятков терминалов (дисплей + клавиатура) к одному центральному процессору. С появлением и развитием ЭВМ персонального класса наиболее популярным (дешевым) решением стали локальные вычислительные сети на их базе. (Собственно, технология локальных сетей исторически развивалась для нужд банков данных).

2. Программное обеспечение. Для банков данных, как и вообще для программно- аппаратных комплексов подобной сложности необходимо развитое и многоуровневое ПО. Во – первых, это операционное программное обеспечение. Оно должно обеспечивать функционирование и каждого рабочего места и обмен информацией между компьютерами. Благодаря стандартизации современных сетевых протоколов, возможно применение в рамках одной локальной сети различных операционных систем и даже различных типов компьютеров (Windows различных вариантов и NetWare, компьютеры Intel – Mackintosh – Alpha и т.д.) Как правило, для решения объемных задач характерно как раз применение нескольких операционных систем, как минимум, для рабочих станций и сервера. Во – вторых, это СУБД (системы управления базами данных), функционирующие в данной операционной среде. Возможно применение нескольких различных СУБД при условии обеспечения общего доступа к базе данных. В – третьих, приложения, разработанные для определенных СУБД и использующие их поддержку для функционирования. Как правило, в рамках одного банка данных работают несколько приложений, обрабатывающие различные аспекты информационной модели. Именно наличием большого числа ранее разработанных приложений и высокой стоимостью разработки и внедрения новых оправдывается необходимость функционирования нескольких, зачастую устаревших, СУБД в одном банке данных.

3. Организационное обеспечение. В общем случае персонал банка данных можно разделить на следующие группы: группа ввода информации, занимающаяся вводом первичной документации в базу данных; группа вывода, которая формирует выходную информацию и получает выходные документы для передачи их «конечным потребителям» информации; группа обслуживания, поддерживающая бесперебойное функционирование аппаратного и программного обеспечения; группа администрирования, функциями которой являются проблемы разграничения доступа, а также решение вопросов о необходимости изменений информационной модели и изменений существующих приложений либо разработки новых. В таком или почти таком «классическом» виде существовали банки данных, основой аппаратного обеспечения которых были мейнфреймы. Развитие персональных ЭВМ наложило свой отпечаток на структуру банка данных, выразившийся в полном либо частичном отказе от применения профессиональных операторов при вводе/выводе информации за счет передачи их функций конечным «потребителям» информации.

Рассмотрим архитектуру системы базы данных (рис. 1). Подобная архитектура была предложена в середине 70-х годов Исследовательской группой по системам управления Американского национального института стандартов (ANSI/SPARC Study Group on DBMS). Приведенная схема соответствует, и достаточно хорошо, большому числу современных реальных систем. Разумеется, для конкретных задач архитектура системы может отличаться, например, в сторону упрощения.

Рис. 1. Архитектура системы баз данных.

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

Концептуальная модель данных – это представление данных, свободное от особенностей физической реализации. Современные СУБД используют для представления понятие таблицы. Таблица СУБД близка к типизированному файлу записей, применяемому во многих языках программирования, хотя есть некоторые отличия, которые будут рассмотрены ниже. База данных представима как набор таблиц. На этом уровне термин «модель данных» означает описание полей таблиц, входящих в БД. Структуру таблицы на физическом уровне (на уровне файлов) рассмотрим на примере весьма популярного формата DBF.

Таблица может состоять из нескольких файлов. «Главным» среди них является файл, имеющий расширение DBF (откуда и название формата). Имя этого файла является именем таблицы. Он собственно и образует таблицу, все остальные файлы выполняют скорее вспомогательные функции. В заголовке DBF- файла содержится описание всей таблицы, в первую очередь – описание имен, типов и длины полей. Кроме этого, заголовок описывает и некоторую служебную информацию, например, модификацию формата, кодовую страницу (для Windows), количество записей в таблице и пр. Далее в DBF файле следуют собственно записи, без каких – либо разделителей. Кроме того, в состав таблицы может входить файл, имя которого совпадает с именем таблицы, и имеющий расширение.FPT. Здесь находится содержимое MEMO- полей, или полей комментариев; их хранение вместе с основной таблицей привело бы к неоправданному увеличению ее размера. Кроме этого, в состав таблицы еще входят файлы с индексами. Посредством индексирования организуется прямой доступ к записям таблицы. В зависимости от формата и используемой СУБД возможен либо один составной (compound) индексный файл, либо несколько отдельных для каждого из индексов (в случае с FoxPro – соответственно CDX и IDX файлы)

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

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

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

Дата добавления: 2015-07-19