Базы данных и их применение для решения экономических задач
Период применения компьютеров в экономике можно разделить на два этапа: до и после появления баз данных (см. рис. 4.20).
Рис. 4.20. Последствия появления баз данных
До появления баз данных в связи с тем, что конечный пользователь не мог общаться с компьютером из-за незнания языка программирования, существовало передаточное звено – программист. В функции программиста входило выяснение содержания задачи, которое знал конечный пользователь, разработка соответствующего алгоритма и написание программы. Препона между пользователем и компьютером в виде программиста, серьезно затрудняло и замедляло процесс решения задач. Кроме того, существующие в то время операционные системы и системные программные средства, предназначенные для обработки файлов (так назывались данные сгруппированные для обработки), обладали недостатками, которые ставили под сомнение целесообразность использования компьютеров в экономике. Причин для этого было две: существовала избыточность данных и высокая зависимость прикладных программ от структурных изменение файлов. Все это потребовало пересмотра базовых принципов хранения данных, что привело к созданию баз данных.
База данных – это ориентированное на пользователя-непрограммиста множество взаимосвязанных данных, структурированных таким образом, что достигается их минимальная избыточность и максимальная независимость от прикладных программ. Данные в базе находятся в памяти в соответствии с некоторой моделью.
Распространенными моделями баз данных являются: реляционная, сетевая и иерархическая. Так как в процессе управления предприятиями и организациями широко используются таблицы, поэтому наиболее распространенной моделью баз данных в настоящее время является реляционная модель.
Реляционная модель основывается на понятии “отношение”, и представляется совокупностью таблиц. На рис. 4.21 приведены базовые понятия данной модели.
Рис. 4.21. Основные понятия реляционной модели базы данных
Домен – это множество значений, принимаемых свойствами (характеристиками) отражаемого объекта.
Атрибут – это имя множества значений, входящих в домен. Атрибуты используются в качества средства для обращения к доменам.
Кортеж – это множество элементов из доменов, составляющих одну строку отношения (таблицы).
Отношение – это множество кортежей, отражающих свойства объекта в форме таблицы.
Ключ таблицы – это такой атрибут, который позволяет определить значения искомых строк таблицы.
Таблицы, входящие в реляционную модель, строятся в рамках ограничений, диктуемых операциями их обработки. Это следующие ограничения:
- таблица должна иметь имя (например, ДЕТАЛЬ, ПОСТАВЩИК,
ПОСТАВКИ);
- таблица должна быть простой, то есть не содержать составных элементов, например, у поставщика должен быть только один номер телефона, указанный в одной строке;
- в таблице не должно быть одинаковых строк;
- должен быть известен первичный ключ, используемый для поиска или выполнения других логических операций.
Таблицы реляционной модели обрабатываются с помощью операций реляционной алгебры. Выделяют три основных операций: ВЫБОРКА, ПРОЕКЦИЯ, СОЕДИНЕНИЕ. Операцию ВЫБОРКА продемонстрируем с помощью базы данных ПОСТАВКИ, представленной на рис. 4.22.
ПОСТАВКИ
Код поставщика | Код детали | Количество (шт.) |
КР | KD | Q |
П1 | ||
П1 | ||
П2 | ||
П3 | ||
П3 | ||
П4 | ||
П4 |
Рис. 4.22. База данных «ПОСТАВКИ»
В данной таблице обозначения KP, KD и Q являются идентификаторами соответствующих характеристик (атрибутов).
Данный оператор применяется к одной таблице. В результате получают новую таблицу, в которой находятся лишь те строки, которые удовлетворяют заданному условию. Общая форма оператора, используемого СУБД, имеет вид:
ВЫБОРКА ИЗ <имя исходной таблицы>
ГДЕ <условие>
ПОЛУЧАЯ <имя результирующей таблицы>
Допустим, из базы данных ПОСТАВКИ необходимо выбрать тех поставщиков, которые поставляли детали с кодом 101.
Заполнив общую форму оператора получим:
ВЫБОРКА ИЗ ПОСТАВКИ
ГДЕ KD = 101
ПОЛУЧАЯ ПОСТАВЛЕННЫЕ ДЕТАЛИ
В результате будет получена таблица, представленная на рис. 4.23.
ПОСТАВЛЕННЫЕ ДЕТАЛИ
Код поставщика | Код детали | Количество (шт.) |
КР | KD | Q |
П1 | ||
П2 | ||
П4 |
Рис. 4.23. Результат выполнения оператора «ВЫБОРКА»
Для обработки нескольких таблиц устанавливаются связи. Связи между первичными ключами, то есть теми атрибутами таблиц, которые однозначно определяют их строки. На рис. 4.24 эти связи указаны с помощью стрелок.
Рис. 4.24. Реляционная база данных «Поставщики-Детали»
Для объединения таблиц используется оператор СОЕДИНЕНИЕ, общий вид которого следующий:
СОЕДИНЕНИЕ <имя таблицы 1> И <имя таблицы 2>
ПО <атрибут таблицы 1> и <атрибут таблицы 2>
ПОЛУЧАЯ<имя результирующей таблицы>
Допустим необходимо для расшифровки кодов поставщиков в таблице ПОСТАВЛЕННЫЕ ТОВАРЫ (рис. 4.23) соединить ее с таблицей ПОСТАВЩИК (рис. 4.24). Тогда данный оператор приобретает вид:
СОЕДИНЕНИЕ ПОСТАВЛЕННЫЕ ДЕТАЛИ И ПОСТАВЩИК
ПО KP И KP1
ПОЛУЧАЯ ПОСТАВЩИКИ ДЕТАЛЕЙ
На рис. 4.25 представлены результаты выполнения оператора СОЕДИНЕНИЕ.
ПОСТАВЩИКИ ДЕТАЛЕЙ
Код поставщика | Код детали | Количество | Код поставщика | Наименование поставщика | Адрес поставщика |
KP | KD | Q | KP1 | NP | AP |
П1 | П1 | Заря | Москва | ||
П2 | П2 | Восход | Тверь | ||
П3 | П3 | Рассвет | Тула |
Рис. 4.25. Результат выполнения оператора «СОЕДИНЕНИЕ»
Теперь рассмотрим, каким образом в базе данных ликвидируются оставшиеся недостатки, присущие файловой системе.
Согласно приведенному выше определению базы данных должны создаваться таким образом, чтобы выполнялось два условия:
- достигался минимум затрат на корректировку данных;
- достигался минимум затрат на перепрограммирование, необходимое в случае изменения структуры базы данных (добавление новых или сокращение старых атрибутов).
Для удовлетворения этих условий базы данных создаются на основе двух принципов:
- неизбыточность;
- независимость.
Требование первого принципа означает сокращение до минимума объема дублируемых данных. Для этого над таблицами выполняют процедуру нормализации. Пусть имеется ненормализованная таблица СЛУЖАЩИЙ-НАЧАЛЬНИК-ТЕЛЕФОН, в которой имеется излишне дублируемые данные
Рис. 4.26. Результаты нормализации таблицы
(см. рис. 4.26). Для их ликвидации данная процедура требует деления исходной таблицы таким образом, чтобы в результате получились более простые таблицы.
Существует несколько уровней ликвидации дублирования данных – чем выше уровень, тем меньше дублирования. Первый уровень соответствует 1-й нормальной форме Кодда (1НФ), 2-й уровень – 2-й нормальной форме Кодда и третий уровень – 3-й нормальной форме Кодда (уровни названы в честь их создателя). Целесообразный уровень зависит от специфики информации, находящейся в базе данных. В результате нормализации избыточные номера телефонов (3051, 2222) в таблице НАЧАЛЬНИК исчезли, так как получен достаточно высокий уровень нормализации (3-я нормальная форма Кодда).
Реализация второго принципа, требует максимальной независимости прикладных программ от структуры базы данных. Независимость достигается за счет отделения процедурной части программы от описания структуры базы данных. Отделение происходит с помощью системы управления базами данных (СУБД).
В модели данные представлены в виде совокупности таблиц. Между атрибутами таблиц могут быть установлены связи (отношения) следующих типов:
- «один-к-одному»;
- «один-ко-многим»;
- «многие-ко-многим».
Связи могут устанавливаться между соответствующими полями динамически, в момент доступа к данным. Каждое отношение имеет ключевой признак (ключ). Различают два вида ключей: простой (атрибут) и составной (совокупность атрибутов). Ключ исключает дублирование данных в отношении и ускоряет процесс поиска и доступа к данным.
Существует несколько режимов взаимодействия пользователей СУБД:
- режим конечного пользователя с применением конструктора баз данных и запросов;
- программный режим, предполагающий знание пользователем языка СУБД и позволяющий создавать прикладные программы.
Конечный пользовать, как правило, пользуется конструктором, с помощью которого задается структура БД, формулы для расчетов и структура отчета. Достаточно популярной СУБД для данного класса является MS Access.
Программный режим предполагает создание программ с помощью программистов-профессионалов.
Для того чтобы использовать базу данных для решения экономических задач необходимо выполнить ряд этапов, предназначенных для ее создания. Для этого предварительно всю управленческую документацию, имеющую непосредственное отношение к данной задаче, следует сгруппировать следующим образом:
- выделить входные оперативные документы, содержащие переменную информацию и отражающие текущие производственно-хозяйственные факты или финансовые операции (оперативные базы данных);
- выделить условно-постоянные документы, содержащие нормативно-справочные данные (условно-постоянные базы данных);
- разработать результирующие документы, таблицы, отчеты (результирующие базы данных);
- определить документы, предназначенные для корректировки условно-постоянных данных.