Автоматизация обработки информации в системах управления базами данных «СУБД»

       Обычно современная СУБД содержит  следующие компоненты:

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

     1.3 Жизненный цикл СУБД 

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

       Часто встречаемые этапы: 

1. Исследование и анализ проблемы, для решения которой создается база данных.
2. Построение Инфологической и Даталогической модели.
3. Нормализация полученных Инфологических и Даталогических моделей. По окончанию этого этапа, как правило, получают заготовки таблицы БД и набор связей между ними (первичные и вторичные ключи).
4. Проверка целостности БД (Целостность базы данных).
5. Выбор физического способа хранения и эксплуатации (технического средства) базы данных.
6. Проектирование входных и выходных форм.
7. Разработка интерфейса приложения.
8. Функциональное наполнение приложения.
9. Отладка: проверка на корректность работы функционального наполнения системы.
10. Тестирование: тест на корректность ввода вывода данных, тест на максимальное количество активных сессий и т. д.
11. Ввод в эксплуатацию: отладка ИТ – инфраструктуры, обучение пользователей и ИТ – персонала.
12. При необходимости добавления выходных форм и дополнительной функциональности. В случае если необходимы более серьезные изменения, следует повторить все шаги с первого.
13. Вывод из эксплуатации: перенос данных в новую СУБД.

     1.4 Классификация баз данных 

     Многообразие  характеристик и видов баз  данных порождает многообразие классификации. Рассмотрим основные виды классификации.

     По  технологии обработки данных базы данных подразделяются на централизованные и  распределенные.

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

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

     По  способу доступа к данным базы данных подразделяются на базы данных с локальным доступом и базы данных с удаленным (сетевым) доступом.

     Системы централизованных баз данных с сетевым  доступом предполагают различные архитектуры  подобных систем:

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

     На  данный момент файл – серверные  СУБД считаются устаревшими.

       Примеры: Microsoft Access, Borland Paradox.

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

       Примеры: Firebird, Interbase, MS SQL Server, Sybase, Oracle, MySQL, PostgreSQL.2

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

     Модель  данных – совокупность структур данных и операций их обработки.

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

• иерархические;
• сетевые;
• реляционные.

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

     К основным понятиям иерархической структуры  относятся: уровень, элемент (узел), связь.

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

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

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

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

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

       Каждая реляционная таблица обладает  следующими свойствами:

• каждый элемент таблицы – один элемент данных;
• все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковые характеристики и свойства;
• каждый столбец имеет уникальное имя;
• одинаковые строки в таблице отсутствуют;
• порядок следования строк и столбцов может быть произвольным.

     Понятие реляционный (relation – отношение) связано  с разработками известного американского  специалиста в области баз  данных Э. Кодда. В основу реляционной  базы данных положено понятие алгебры  отношения и реляционного исчисления.

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

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

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

     Реляционная база данных является объединением нескольких двумерных таблиц, между которыми установлены связи.

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

• один к одному – эта связь предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот; например, начальник курса – курс;
• один к многим – эта связь предполагает, что одному экземпляру информационного объекта А соответствует 0, 1, 2 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А, например, начальник курса – курсант;
• многие к многим – эта связь предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1, 2 или более экземпляров объекта В и наоборот, например, учебная дисциплина - курсант.

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

       При этом должен выполняться  принцип нормализации:

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

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

     1.5 Типы СУБД 

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

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

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

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