Электронная таблица Microsoft Excel

 

 

 

 

 

 

 

 

65

 

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

системы.

3.4. Внутримашинное информационное обеспечение

3.4.1. Понятие базы данных

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

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

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

66

 

 

Например, для подсистемы материально-технического снабжения было предусмотрено выполнение запросов о наличии на складе предметов, об операциях выдачи предметов со склада и их получении. Впоследствии возникла необходимость в информации об общем объеме поставок от конкретного поставщика. При отсутствии СУБД для отработки такого запроса будет нужно разработать специальную прикладную программу. Однако СУБД, обладая достаточными знаниями о предметной области, может обеспечить универсальный язык запросов, позволяющий сформулировать произвольный запрос на выборку сведений из базы данных. Такой запрос может быть в любой момент подан с терминала оператором или встроен в одну из прикладных программ, входящих в состав специального программного обеспечения АИС.

Третья особенность заключается  в том, что большинство современных СУБД способно обеспечить так называемый «режим мультидоступа». Каждый из пользователей может в любой момент времени обратиться к базе данных с некоторым запросом, и СУБД выполнит запросы нескольких пользователей так, что каждый из них практически не замени задержки ответа. При этом такое «параллельное» выполнение вполне корректно, т.е. результат получается таким, как если бы несколько параллельных транзакций выполнялись последовательно.

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

3.4.2. Базы данных и файловые системы

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

67 

 

 

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

Каким образом поставленная задача может быть решена в файловой системе? Рассмотрим вариант ее решения путем расширения базовых возможностей файловой

системы за счет специальной библиотеки функций. Вся информация о сотрудниках будет храниться в одном файле. Поскольку минимальной информационной единицей в данном случае является сотрудник, естественно потребовать, чтобы в этом файл содержалась одна запись для каждого сотрудника. Какие поля должна содержать такая запись? Полное имя сотрудника (СОТР_ИМЯ), номер его удостоверения (СОТР_НОМЕР), информацию о его соответствии занимаемой должности (для простоты: «да» или «нет») (СОТР_СТАТ), размер зарплаты (СОТР_ЗАРП), номер отдела (СОТР_ОТД_НОМЕР). Поскольку используется только один файл, запись должна содержать также имя руководителя отдела (СОТР_ОТД_РУК).

Функции информационной системы требуют, чтобы обеспечивалась возможность доступа к этому файлу по уникальным ключам (т.е. недублируемым разных записях признакам) СОТР_ИМЯ и СОТР НОМЕР. Кроме того, должна обеспечиваться возможность выбора всех записей с общем значением СОТР_ОТД_НОМЕР, то есть доступ по неуникальному ключу. Дня того, чтобы получить численность отдела или общий размер зарплаты, каждый раз при выполнении такой функции информационная система должна будет выбрать все записи о сотрудниках отдела и посчитать соответствующие общие значения.

Таким образом, даже для такой простой системы ее реализация на базе файловой   системы,   во-первых,   требует   создания   специальной   надстройки (прикладной  программы) для многоключевого доступа к файлам,  во-вторых, вызывает требование избыточности хранения (для каждого сотрудника одного отдела повторяется имя руководителя), а также выполнения массовой выборки и вычислений для получения суммарной информации об отделах. Кроме того, если в ходе эксплуатации системы возникнет необходимость выдавать списки сотрудников, получающих заданную зарплату, то придется либо полностью просматривать файл, либо реструктуризовать его, объявив ключевым поле СОТР_ЗАРП.

 

68

Эту задачу можно решить, если поддерживать два многоключевых файла: СОТРУДНИКИ и ОТДЕЛЫ. Первый   файл   содержит   поля   СОТР_ИМЯ,   СОТР_НОМЕР,   СОТР_СТАТ, СОТР_ЗАРП   и   СОТР_ОТД_НОМЕР,   а  второй  -  ОТД_НОМЕР,   ОТД_РУК, ОТД_СОТР_ЗАРП (общий размер зарплаты) и ОТД_РАЗМЕР (общее  число сотрудников в отделе). Большинство неудобств, перечисленных в предыдущем абзаце, будут преодолены. Каждый из файлов будет содержать только недублируемую информацию, необходимости в динамических вычислениях суммарной информации не возникает. Но заметим, что при таком переходе информационная система должна обладать некоторыми новыми особенностями, сближающими ее с СУБД.

Прежде всего, система  должна теперь знать, что она работает с двумя информационно связанными файлами (это шаг в сторону схемы базы данных), должна знать структуру и смысл каждого поля (например, что СОТР_ОТД_НОМЕР в файле СОТРУДНИКИ и ОТД_НОМЕР в файле ОТДЕЛЫ означают одно и то же), а также понимать, что в ряде случаев изменение информации в одном файле должно автоматически вызывать модификацию во втором файле, чтобы их общее содержимое было согласованным. Например, если на работу принимается новый сотрудник, то необходимо добавить запись в файл СОТРУДНИКИ, а также соответствующим образом изменить поля ОТД_ЗАРП и ОТД_РАЗМЕР в записи файла ОТДЕЛЫ, описывающей отдел этого сотрудника.

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

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

     Например, на специальном языке SQL (Structured Query Language - язык структурированных запросов) этот запрос можно было бы выразить в форме:

SELЕСТ ОТД_РАЗМЕР

FRОМ СОТРУДНИКИ, ОТДЕЛЫ

WHERE COTP_ИМЯ = «ПЕТР ИВАНОВИЧ СИДОРОВ»

АND СОТР_ОТД_НОМЕР = ОТД_НОМЕР

Таким образом, при формулировании запроса СУБД позволит не задумываться о том, как будет выполняться этот запрос. Среди ее метаданных будет содержаться информация о том, что поле СОТР_ИМЯ является ключевым для файла СОТРУДНИКИ, а ОТД_НОМЕР - для файла ОТДЕЛЫ, и система сама воспользуется этим. Если же возникнет потребность в получении списка сотрудников, не соответствующих занимаемой должности, то достаточно предъявить системе запрос

SELЕСТ СОТР _ИМЯ, СОТР_НОМЕР

FRОМ СОТРУДНИКИ

WHERE СОТР_СТАТ = «НЕТ»,

и   система   сама   выполнит   необходимый   полный    просмотр   файла   СОТРУДНИКИ, поскольку поле СОТР_СТАТ не является ключевым.

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

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

70

 

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

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

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

Выделяются два традиционных подхода к проектированию баз  данных в АИС: функционально-ориентированный и ориентированный на данные.

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

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

71

 

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

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

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

На этапе предварительного планирования собирается информация, отвечающая на вопросы:

• Сколько прикладных программ используется в системе управления, и какие функции они выполняют?