Цели использования баз данных. Организация баз данных

Введение

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

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

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

1. Организация баз данных

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

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

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

Схемы и подсхемы базы данных часто изображают в виде диаграмм. На рис. 1 приведена общая схема логической структуры базы данных и подсхемы двух прикладных программистов, которые имеют различные представления о данных. Сплошные линии обозначают связи на схеме. Простые связи обозначаются одной стрелкой, связи "один ко многим" - двойной стрелкой. Штриховые линии отображают перекрестные ссылки. Наличие перекрестных ссылок позволяет избежать повторения записей ПОСТАВЩИК и СПЕЦИФИКАЦИИ - ПАРТИИ -ТОВАРА в каждой записи СТАТЬЯ ЗАКУПКИ.

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

2. Системы управления базами данных

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Выбор СУБД

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

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

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

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

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

Ниже приведены краткие характеристики некоторых универсальных СУБД.

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

В системе допускается обращение к данным из прикладных программ пользователя, написанных на языке АССЕМБЛЕР, ПЛ/1, КОБОЛ, АЛГОЛ-60, ФОРТРАН-4.

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

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

СУБД КВАНТ-М представляет собой систему реального времени, предназначенную для работы на мини-ЭВМ и используемую для решения задач в информационно-поисковых и справочных системах (фактографических, библиографических, резервирования заказов и т.п.).

Пользовательские программы могут быть написаны на языках КОБОЛ, ФОРТРАН, БЕЙСИК-2 и обращаются к базе данных с помощью САМ-интерфейса.

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

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

Языком манипулирования данными является язык КВАНТ СКРИПТ-М. Это англоподобный диалоговый язык, предназначенный для эффективного поиска и выделения записей в базе данных и вывода их на дисплей.

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

4. Специализированные базы данных

Процесс проектирования специализированной базы данных включает: логическое проектирование, физическое проектирование, разработку специализированной СУБД.

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

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

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

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

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

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

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

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

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

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

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

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

Наиболее широко используемым является индексно-последовательный способ адресации. При этом можно использовать два метода доступа – ISAM и VSAM. В методе доступа ISAM записи группируются так, чтобы они могли располагаться на отдельных дорожках цилиндров модуля дисков, а одна дорожка на каждом цилиндре отводится для индексов, указывающих на записи, расположенные на данном цилиндре. При необходимости внесения новых данных они помещаются в область переполнения (в дорожку индексов включаются также указатели на области переполнения). Метод доступа VSAM аналогичен методу ISAM, однако метод VSAM не зависит от типа оборудования и не оперирует такими категориями, как дорожки и цилиндры. Вместо цилиндров, разделенных на дорожки, используются управляемые области, в свою очередь подразделяемые на управляемые интервалы. В методе VSAM для одной управляемой области имеется один набор указателей (индекс).

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

5. Распределенные базы данных

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

Основной проблемой при создании РБД является размещение данных; это определяет такие характеристики РБД, как объемы хранимых и обновляемых данных, интенсивность потоков информации и надежность систем.

Проектирование РБД может проходить в условиях:

а) создание АСУ только начинается и стоит задача выбора оптимальной структуры РБД и размещения отдельных ЛБД;

б) существует определенное количество ЛБД и ВЦ и стоит задача размещения дополнительного числа ЛБД и оптимального изменения структуры связей в системе;

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

Наиболее характерными задачами при проектировании РБД являются определение структуры РБД, определение топологии связей, выбор стратегии поиска и обновления информации, выбор системы управления РБД.

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

Выбор топологии сети ЛБД определяется характером их информационных взаимосвязей, направлением и интенсивностью информационных потоков, необходимой надежностью и достоверностью передачи информации. Обычно пользователи прикрепляются к одной ЛБД и через эту ЛБД связываются с остальными базами данных в РБД. Различают следующие типы структур связей ЛБД в РБД: радиальную, радиально-узловую, кольцевую, каждый с каждым, комбинированную (рис. 4, а - г). Наиболее надежной, с быстрым поиском информации является система со структурой "каждый с каждым". Информационные связи такого типа характерны для объектов, подчиненных друг другу только функционально.

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

1) по структурной информации о размещении данных в РБД происходит поиск необходимой ЛБД и обращение к этой ЛБД;

2) осуществляется поиск в ЛБД более высокого ранга; если необходимая информация отсутствует, анализируется структурная информация о содержании всех подчиненных ЛБД; если необходимая информация отсутствует, переходят к ЛБД более высокого уровня иерархии;

3) осуществляется обращение в управляющую ЛБД, где хранится структурная информация о всех ЛБД;

4) осуществляется опрос всех ЛБД либо параллельно, либо последовательно.

Стратегия 1 обеспечивает минимальные объемы запросной информации, но в каждой ЛБД необходимо хранить структурную информацию о размещении массивов в РБД.

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

Стратегия 3 минимизирует структурную информацию.

Стратегия 4 отличается большими потоками запросной информации.

Функционирование РБД предполагает наличие в ней потоков обновления информации. Среди стратегий обновления можно выделить следующие: обновление всех дублируемых массивов по всем ЛБД выполняет источник информации; источник обновляет информацию только в ближайшей ЛБД, все остальные дублируемые массивы обновляются по инициативе этой ЛБД; обновление дублируемых массивов проводится по алгоритму (например, минимизирующему суммарные потоки обновления). Стратегия обновления должна обеспечивать заданную надежность, достоверность и быстродействие РБД. Разработка и внедрение эффективных систем управления РБД находятся в настоящее время на начальном этапе. Основной критерий при разработке системы управления РБД – минимальная трудоемкость создания и внедрения ее математического обеспечения. Задача может решаться доработкой и подстройкой существующих СУБД или созданием эффективных специальных систем управления РБД.

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

Кроме того, что база описывает данные, объясняет их значение и структуру, она поддерживает определенные ограничения, накла­дываемые на эти данные, например определяет тип данных, их размерность и т.п.

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

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

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

Рис. 2.5. Схема организации программного и информационного обеспечения

С использованием субд

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

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

На самом деле на этапе компиляции происходит слияние ядра базы данных и приложения (рис. 2.6).

Рис. 2.6. Схема слияния ядра БД и приложений

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

Элементы базы данных

База данных является системой, т.е. она состоит из некоторого числа элементов и отношений между ними (рис. 2.7)

Рис. 2.7. Структурные единицы БД

Наименьшим из них является элемент данных, который в ряде случаев называют также полем или атрибутом и который соответ­ствует одному реквизиту. Итак, элемент данных - это наименьшая семантически значимая поименованная единица данных. Элемент данных определяется следующими характеристиками: именем (Ф.И.О., дата рождения, наименование предприятия), типом (сим­вольный, числовой, календарный), длиной (максимально возмож­ное количество символов - 15 байт) и точностью (количество знаков после запятой для числовых данных).

Элементы данных организуются в записи, называемые корте­жами. Запись в общем случае соответствует показателю и несет данные об одном из однородных объектов, например одном счете, одном работнике и т.п. В ряде случаев применяют понятие агрега­та данных, которое занимает промежуточное положение между элементом данных и записью. Агрегат данных может быть простым (состоящим только из элементов данных) и составным (состоящим из элементов и простых агрегатов данных).

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

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

Значение приведенных терминов можно пояснить на схеме (рис. 2.8).

Элемент данных содержит один реквизит, в данном случае на­звание города - Москва. Агрегат данных состоит из нескольких реквизитов, рассматриваемых как одно целое. Запись состоит из одного или нескольких элементов данных и содержит информацию об одном объекте, в приведенном примере - об одном предприя­тии. Совокупность однотипных записей составляет файл базы дан­ных, на рисунке - это файл с информацией о предприятиях. Со­вокупность таких файлов, тем или иным способом взаимосвязан­ных между собой, представляет собой базу данных. На схеме показаны три файла информации, связанной между собой следу­ющим образом: предприятия обслуживаются банками, у них открыты счета в этих банках. Если связи между файлами нет, то их совокупность нельзя считать базой данных.

Рис. 2.8. Пример взаимосвязи структурных единиц БД

Жизненный цикл баз данных

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

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

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

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

Эксплуатация базы данных. Целями данной стадии жизненного цикла являются: обеспечение реализации и непрерывного функ­ционирования БД; сохранность данных в случае сбоев компьютер­ной системы и других аварийных ситуаций; анализ функциониро­вания системы баз данных с точки зрения ее эффективности и производительности. В качестве критериев оценки базы данных используется система количественных и качественных показате­лей. К количественным показателям относятся: время отклика на запрос, используемая внешняя и оперативная память, надежность и другие затраты (на обновление базы данных, на создание, реор­ганизацию, реструктуризацию). Качественными показателями являются гибкость, адаптивность, динамичность, восстанавлива­емость, возможность поддержания целостности данных и др.

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

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

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

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

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

Существует множество подходов к построению концептуальной модели данных: графовые модели, семантические сети, модель «сущность-связь» и т.д. Наиболее популярной из них является модель «сущность-связь» (ER -модель, от англ. Entity - Relation ). ER -модель была предложена американским ученым Питером Пин Шен Ченом в 1976 г. К настоящему времени разработано несколь­ко ее разновидностей, но все они базируются на графических диаграммах, предложенных Ченом.

Модель «сущность-связь» изображается графически в форме ER -диаграммы, которая состоит из набора множеств значений, описывающих свойства сущности и связи (Entity - Relationship Diagrams ).

К достоинствам этой модели относятся:

легкость формализации,

простота понимания;

описание графическими средствами;

наглядность изображения различных типов связей;

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

Основными компонентами модели «сущность-связь» являют­ся сущность, атрибуты и связи (рис. 2.9).

Рис. 2.9. ER -диаграмма

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

Связь (Relationship ) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.

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

Концептуальная модель составляется на основе интервью и опросов экспертов - специалистов в предметной области и долж­на удовлетворять ряду требований:

должна быть независима от конкретной СУБД;

должна быть понятна как разработчикам информационной сис­темы, так и специалистам в предметной области;

должна минимизировать усилия дальнейшего проектирования. Это означает, что ее структуры должны легко преобразовывать­ся в структуры логической модели;

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

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

На втором этапе проектирования создается логическая, или даталогическая, модель. Такая модель строится уже не в терминах объектов и связей, а в терминах той конкретной СУБД, в которой предполагается использовать базу данных. Эту модель также назы­вают схемой БД.

В настоящее время известны три логические модели данных (их еще называют классическими или замечательными моделями), а именно иерархическая, сетевая и реляционная.

Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 1960-х гг. В начале 1970-х гг. была предложена реляционная модель данных.

Основными элементами любой из этих моделей являются объек­ты и взаимосвязи между ними, а отличительным признаком - раз­личие в способах представления взаимосвязей между объектами.

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

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

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

на этапе концептуального проектирования широко применя­ются графические методы;

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

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

Типы логических моделей данных

Как отмечалось выше, основными типами логических моделей данных являются: иерархическая, сетевая и реляционная.

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

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

Основные достоинства иерархической модели - простота опи­сания иерархических структур реального мира и быстрое выпол­нение запросов, соответствующих структуре данных. Однако такие модели часто содержат избыточные данные и плохо приспособле­ны для представления взаимосвязей типа «многие ко многим». Кроме того, не всегда удобно каждый раз начинать поиск нужных данных с корня, а другого способа перемещения по базе в иерар­хических структурах не имеется. Иерархические системы - ста­рейшее поколение систем баз данных, они разрабатывались для больших ЭВМ.

Рис. 2.10. Иерархическая структура модели БД

Сетевая модель данных основывается также на графическом представлении взаимосвязей объектов. Однако здесь помимо вер­тикальных связей существуют и горизонтальные, т.е. допускается подчиненность одного объекта многим объектам. Таким образом, в отличие от иерархических сетевые модели поддерживают взаи­мосвязь типа «многие ко многим». Каждый порожденный элемент в них может иметь более одного предка (рис. 2.11).

Рис. 2.11. Сетевая структура модели БД

Однако сетевые системы довольно сложны и требуют солидно­го программного обеспечения. В них, так же как и в иерархических системах, переход от записи к записи производится по вставлен­ным в каждую запись ссылкам. В свое время они были достаточно популярны и применялись для мини-компьютеров и больших ЭВМ.

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

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

Основные понятия реляционных баз данных

Реляционная модель данных, разработанная Е. Коддом в 1970-х гг., основывается на математической теории отношений и опирается на систему понятий реляционной алгебры, важнейшими из которых являются таблица (отношение), строка (кортеж), стол­бец (атрибут), содержимое столбца (домен), первичный ключ, внешний ключ.

В реляционной модели данные представляются в виде таблиц, связанных между собой. Каждая таблица состоит из строк (одно­типных записей, или кортежей) и столбцов (полей, или атрибутов) и имеет имя, уникальное внутри базы данных. Слово «однотипных» означает, что все записи обладают одним и тем же набором атри­бутов, или полей, хотя для каждой записи атрибут может прини­мать свое собственное значение. Каждый столбец таблицы имеет уникальное для своей таблицы имя. Столбцы расположены в таб­лице в соответствии с порядком следования их имен при ее созда­нии. Каждый атрибут может принимать некоторое подмножество значений из определенной области (домен). В отличие от столбцов строки не имеют имен, порядок их следования в таблице не опре­делен, а количество не ограничено.

Поясним перечисленные выше понятия на примере реляцион­ной модели БД, содержащей сведения о сотрудниках некоторой фирмы. Рассмотрим таблицу с данными о сотрудниках фирмы (табл. 2.6).

Таблица 2.6

Сотрудники

Табельный номер	Фамилия И.О.	Код отдела	Рабочий телефон
	ПЕТРОВ А.В.
	РОМАНЕНКО С.Т.
	СТЕПАНОВА И.С.

Можно увидеть, что у всех трех записей атрибуты одинаковы, однако принимают разные значения. Так, для записи № 1 атрибут «табельный номер» принимает значение 008976, а для записи № 2 - 008980 и т.д. Значения некоторых атрибутов у разных запи­сей могут совпадать, например у записей № 1 и № 2 одинаковое значение атрибута «код отдела». Однако в каждой таблице должен быть атрибут (или совокупность атрибутов), значение которого никогда не повторяется и однозначно идентифицирует каждую строку таблицы. Это нужно для того, чтобы при работе с базой можно было отличать одну запись от другой. Такие атрибуты на­зывают уникальными. Уникальный атрибут таблицы или совокуп­ность ее уникальных атрибутов называют первичным ключом или ключевым полем. В данной таблице ключом является атрибут «та­бельный номер».

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

В ряде случаев атрибут может не иметь никакого значения: например, у сотрудника № 3 нет рабочего телефона и соответ­ствующий атрибут не заполнен. В этом случае говорят, что атри­бут имеет нулевое значение. Ключ не может иметь нулевое зна­чение.

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

Таблица 2.7

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

РОМАНЕНКО С.Т.

ОТДЕЛ КАДРОВ

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

Первичный ключ таблицы 2

Постреляционные базы данных

Как уже говорилось, реляционные базы данных состоят из дву­мерных таблиц, связанных между собой. Таким образом, при про­ектировании реляционной БД вся информация разбивается на множество двумерных массивов. В некоторых случаях таблица соответствует множеству реальных объектов, например «отделы», «сотрудники», «счета» и т.п. Но иногда, когда приходится иметь дело с иерархической информацией, один и тот же объект прихо­дится «раскладывать» на несколько таблиц.

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

Такой подход имеет ряд недостатков. Во-первых, увеличивается число таблиц и связей между ними, что в масштабах всей базы данных приводит к замедлению выполнения запросов. Во-вторых, не учитываются иерархия и логическое единство таблиц. В данном примере таблицу «Строки счетов-фактур» можно считать подчи­ненной по отношению к таблице «Счета-фактуры», так как она не может существовать без нее. И только в единстве эти две таблицы описывают так называемый бизнес-объект - аналог реального документа. Разбиение бизнес-объектов на несколько таблиц услож­няет структуру базы данных и ее понимание пользователями.

СЧЕТА-ФАКТУРЫ СТРОКИ

СЧЕТОВ-ФАКТУР

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

Ограничение на атомарность атрибутов означает, что в реляци­онной базе данных атрибут (поле) каждой записи может содержать только одно значение. В постреляционной модели, напротив, поле может содержать несколько значений или даже целую таблицу. Таким образом, появляется возможность «вложить» одну таблицу в другую.

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

Как утверждают разработчики постреляционных СУБД, ско­рость выполнения запросов в них возрастает до 20 раз по сравне­нию с реляционными СУБД. Однако переход от реляционных баз данных, получивших повсеместное распространение, к постреля­ционным связан со значительными затратами и пока носит огра­ниченный характер.

Хранилище данных

Хранилище данных - это система, предназначенная для обес­печения единого информационного пространства с целью анализа и оптимизации его бизнеса.

Деятельность любого экономического объекта связана с исполь­зованием и обработкой информации, которая является важнейшим экономическим ресурсом для достижения высоких экономических показателей. Однако особенностью ЭИС является необходимость обработки двух типов данных, а именно оперативных и аналитических. Поэтому в процессе функционирования ЭИС приходится решать два класса задач:

обеспечение повседневной работы пред­приятия по вводу и обработке информации;

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

Задачи первого класса - автоматизация оперативной деятельности - пол­ностью решаются О LT Р -системами (Online Transactional Process ­ ing - оперативная обработка трансакции), к которым относятся автоматизированные банковские системы, учетные системы и др. Для работы с аналитическими данными предназначены OLAP - системы (Online Analytical Processing - оперативная аналитическая обработка), которые построены по технологии хранилища данных и предназначены для агрегированного анализа больших объемов данных. Эти системы являются составной частью систем принятия решений или управленческих систем класса middle и top manage ­ ment , т.е. систем, предназначенных для пользователей среднего и высшего уровней управления компанией.

Сравнительные характеристики использования данных в сис­темах операционной и аналитической обработки приведены в табл. 2.8.

Таблица 2.8

Характеристики операционных и аналитических информационных систем

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

Таким образом, современная ЭИС представляет собой систему, основанную на совместном использовании трансакционных OLTP - систем и хранилищ данных (Data Warehouse ).

Термин «хранилище данных» стал популярен в 1990-х гг. Соглас­но определению Уильяма Инмона, который является основопо­ложником данной технологии, хранилище данных (ХД) представ­ляет собой предметно-ориентированный, интегрированный, не­изменчивый, поддерживающий хронологию набор данных, организованный для целей поддержки принятия решений.

Отличительными чертами хранилища данных являются:

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

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

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

Агрегация, предусматривающая одновременное хранение в базе агрегированных и первичных данных, чтобы запросы на опре­деление суммарных величин выполнялись достаточно быстро.

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

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

В настоящее время разрабатываются такие хранилища, в кото­рых не только собираются данные, но и предоставляется возмож­ность их изменения: расставление аналитических признаков, выполнение управленческих корректировок, дополнение недоста­ющими данными.

Система управления хранилищем данных состоит из несколь­ких функциональных блоков.

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

Инструменты настройки базы данных и управления метаданными. Эти инструменты предназначены для настройки информационной модели хранилища данных при внедрении и изменения этой мо­дели в процессе эксплуатации, для постепенного расширения функциональности хранилища данных. Кроме того, для обеспече­ния максимальной гибкости и адаптируемости хранилища данных в базе данных как отдельная информация должны храниться мета­данные (Metadata ) - данные о данных. Метаданные включают информацию о физических данных, технических и бизнес-процес­сах, правилах и структуре данных. Таким образом, они игра­ют роль справочника, содержащего сведения об источниках пер­вичных данных, алгоритмах обработки, которым исходные данные были подвергнуты, описание структур данных и их взаимосвязей и др.

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

Для сбора данных применяются два подхода: ETL - системы и корпоративный стандарт формата обмена данными. Первый спо­соб сбора данных - применение средств ETL (Extract , Transforma ), специальных систем для извлечения данных из дру­гих БД, трансформации по описанным в этой системе правилам и загрузке в хранилище. Второй подход - применение стандартного формата для сбора данных и разработка процедур выгрузки данных на стороне источника. Это позволяет собирать однородные данные из разнородных систем, децентрализовать разработку процедур выгрузки данных, предоставляя решение этой задачи специалис­там, обладающим знанием об исходной системе.

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

Аппарат выполнения расчетов. Специальный аппарат выполне­ния расчетов обеспечивает:

агрегацию данных - расчет обобщенных показателей, напри­мер вычисление месячного, квартального и годового баланса;

консолидацию данных - суммирование данных по организа­ционной иерархии, например вычисление сводного баланса банка;

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

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

Интерфейсы для внешних систем. Хранилище данных предостав­ляет информацию внешним аналитическим системам и генерато­рам отчетов. Для этого применяются промышленные стандарты доступа к данным.

Архитектура системы управления хранилищем данных показа­на на рис. 2.15.

Рис. 2.15. Архитектура системы управления хранилищем данных

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

Хранилище данных ориентировано на высшее и среднее руководство фирмы, ответственное за принятие решений и развитие бизнеса. Это руководители структурных, финансовых и клиентских подразделений, а также подразделений маркетинга, управление анализа и планирования, например, управление отчетности, глав­ная бухгалтерия, казначейство, аналитическое управление, управ­ление маркетинга и др.

В основе хранилища данных лежит понятие многомерного ин­формационного пространства, или гиперкуба (многомерный куб). Величины, хранящиеся в ячейках этого куба и называемые факта­ми, представляют собой количественные показатели, характери­зующие деятельность компании. В частности, это могут быть дан­ные об оборотах и остатках по счетам, структуре расходов и доходов, состоянии и движении денежных средств и т.д. Измерения куба, образующие одну из его граней, - это множество однотип­ных данных, предназначенных для описания фактов, например филиалы, товары, поставщики, клиенты и валюты и др., т.е. они отвечают за описание качественных характеристик компании. Аг­регация данных выполняется по измерениям куба, поэтому эле­менты измерений принято группировать в иерархические структу­ры, например филиалы часто группируются по территориальному признаку, клиенты - по отраслевому признаку, даты - в недели, месяцы, кварталы и годы. Каждая ячейка данного куба «отвечает» за конкретный набор значений по его отдельным измерениям, например обороты балансовых счетов за день, квартал, год в раз­резе филиалов.

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

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

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

Таким образом, многомерную модель ХД целесообразно ис­пользовать, когда ее объем невелик (не более 10-20 гигабайт), а гиперкуб имеет стабильный во времени набор измерений.

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

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

Рис. 2.16. Логическая схема комбинированного хранилища данных

Витрины данных

Одним из вариантов реализации на практике хранилища дан­ных является построение витрин данных (Data Marts ). Иногда их называют также киосками данных. Витрина данных - это пред­метно-ориентированная совокупность данных, имеющая специ­фическую организацию. Содержание витрин данных, как правило, предназначено для решения некоего круга однородных задач одной или нескольких смежных предметных областей, либо для выпол­нения конкретных бизнес-функций, либо для конкретных подраз­делений. Например, для решения задач, связанных с анализом кредитных услуг банка, используется одна витрина, а для работ по анализу деятельности банка на фондовом рынке - другая.

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

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

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

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

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

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

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

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

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

Рис. 2.17. Взаимосвязь витрин данных и хранилища данных

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

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

Данные, попав в хранилище, могут быть распространены среди многих витрин данных для доступа пользовательских запросов. Эти витрины данных могут принимать различные формы - от баз данных «клиент-сервер» до баз данных на рабочем столе, OLAP - кубов или даже динамических электронных таблиц. Выбор инстру­ментов для пользовательских запросов может быть широким и отображать предпочтения и опыт конкретных пользователей. Ши­рокий выбор таких инструментов и простота их применения сде­лают их внедрение наиболее дешевой частью реализации проекта хранилища данных. Если данные в хранилище имеют хорошую структуру и проверенное качество, то их передача в другие витрины данных станет рутинной и дешевой операцией.

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

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

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

В этой статье

Совместное использование данных с помощью сетевых папок

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

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

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

Совместное использование базы данных с помощью сетевой папки

Если общая сетевая папка отсутствует, ее нужно настроить.

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

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

1. Запустите Access и на вкладке Файл выберите пункт Параметры .

   В окне Параметры Access выберите пункт Параметры клиента .

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

На компьютере каждого пользователя создайте ярлык для файла базы данных. В диалоговом окне "Свойства ярлыка" укажите путь к файлу базы данных в свойстве Цель , используя вместо буквы подключенного диска UNC-адрес. Например, вместо пути F:\sample.accdb укажите путь \\имя_компьютера\shared.accdb .

Примечание: Это действие пользователи могут выполнить самостоятельно.

Совместное использование разделенной базы данных

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

Преимущества разделения базы данных

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

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

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

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

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

Если этот метод вам подходит, перейдите к инструкциям в статье Разделение базы данных Access .

Совместное использование базы данных на сайте SharePoint

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

Опубликованная база данных размещается в Интернете. Можно создавать веб-формы и отчеты, запускаемые в окне браузера, а также стандартные объекты Access (их иногда называют клиентскими объектами, чтобы отличать их от веб-объектов). Для использования клиентских объектов Access необходимо установить приложение Access, однако все объекты базы данных, которые хранятся на SharePoint, используются совместно.

Примечание: Если на компьютере установлено приложение Access, можно использовать клиентские объекты из веб-базы данных, а не только объекты веб-базы данных.

Службы Access предоставляют платформу для создания без данных, которые можно использовать в Интернете. Веб-базы данных конструируются и публикуются с использованием Access 2010 и SharePoint, после чего можно использовать веб-базу данных через веб-браузер.

Формы, отчеты и макросы интерфейса выполняются внутри браузера.

Если вы используете веб-базу данных, данные хранятся в списках SharePoint: все таблицы преобразуются в списки SharePoint, а записи становятся элементами списков. Это позволяет управлять доступом к веб-базе данных с помощью разрешений SharePoint.

Запросы и макросы данных выполняются на сервере: вся обработка SQL-кода выполняется на сервере. Это повышает производительность сети, так как по ней передаются лишь результирующие наборы.

Сохранение базы данных в библиотеке документов

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

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

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

На вкладке Файл выберите пункт Сохранить как .

Примечание: Если вы используете Access 2010, выберите элементы Файл > Сохранить и опубликовать > Сохранить базу данных как > SharePoint .

В диалоговом окне Сохранение в SharePoint перейдите к соответствующей библиотеке документов.

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

Дополнительные сведения см. в статьях Публикация в службах Access и Импорт и связывание данных со списком SharePoint .

Совместное использование базы данных путем связывания со списками SharePoint

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

Этот способ включает три основных действия.

Перемещение данных в списки SharePoint.

Создание ссылок на эти списки.

Распространение файла базы данных.

Для выполнения первых двух действий можно использовать мастер переноса на сайт SharePoint, а последнее действие можно выполнить с помощью любых доступных средств.

Использование мастера экспорта таблиц в SharePoint

На вкладке Работа с базами данных в группе Перенос данных щелкните элемент SharePoint .

Примечание: Этот элемент доступен только в том случае, если файл базы данных сохранен в формате ACCDB.

Следуйте указаниям мастера экспорта таблиц в SharePoint; в частности, укажите расположение сайта SharePoint. Чтобы отменить процесс, нажмите кнопку Отмена .

Чтобы просмотреть дополнительные сведения о переносе, на последней странице мастера установите флажок Подробности .

На этой странице содержатся сведения о том, какие таблицы связаны со списками, а также сведения о расположении резервных копий и URL-адрес базы данных. Здесь также выводится предупреждение при возникновении проблем с переносом и указывается расположение таблицы журнала, в которой можно просмотреть дополнительные сведения о проблемах.

Когда все действия мастера будут завершены, нажмите кнопку Готово .

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

Примечание: Чтобы просмотреть списки на сайте SharePoint, щелкните в области быстрого запуска кнопку Списки или выберите пункт Просмотреть все содержимое узла . Может потребоваться обновить страницу в веб-браузере. Чтобы отобразить списки в области быстрого запуска на сайте SharePoint или изменить другие параметры (например, включить отслеживание версий), можно изменить параметры списков на сайте SharePoint. Дополнительные сведения см. в справке для сайта SharePoint.

Совместное использование базы данных с помощью сервера

Совместное использование базы данных можно организовать с помощью приложения Access и сервера баз данных (например, сервера SQL Server). Этот способ обеспечивает много преимуществ, но для него требуется дополнительное программное обеспечение - сервер баз данных.

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

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

Высокая производительность и масштабируемость Во многих случаях сервер базы данных повышает производительность, чем единственный файл базы данных Access. Многие серверные продукты баз данных также обеспечивают поддержку очень больших баз данных размером примерно в 500 в течение интервала (2 ГБ) для файла базы данных Access (два гигабайта). Продукты сервера баз данных обычно работают очень эффективно, параллельно обрабатывая запросы (используя несколько собственных потоков в одном процессе для обработки запросов пользователей), а также свести к минимуму дополнительные требования к памяти при добавлении новых пользователей.

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

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

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

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

Основные этапы использования Access с сервером баз данных

Факторы, которые следует учитывать при выборе метода

Требования метода	Разделение базы данных	Сетевая папка	Сайт SharePoint	Сервер баз данных
Необходимость наличия программного обеспечения сервера баз данных
Необходимость наличия SharePoint
Необходимость наличия служб Access на сервере SharePoint			Зависит от сценария: связывание со списками и сохранение в библиотеке документов не требует наличия служб Access; публикация в виде веб-базы данных или веб-приложения требует наличия служб Access.
Доступность данных		Подходит для небольших групп, если данные мало изменяются	Наилучшая. Подходит для сценариев автономного использования.	Наилучшая
Безопасность	Зависит от дополнительных мер	Наименее безопасный способ	Наилучшая	Наилучшая
Гибкость	Гибкий способ. Можно легко разрабатывать новые функции базы данных без нарушения работы. Пользователи могут изменять структуру в собственной копии.	Менее гибкий способ. Разработку можно осуществлять с использованием автономной копии базы данных, которая затем заменяется. Отсутствует возможность индивидуального изменения структуры базы данных пользователями.	Гибкий способ. Использование разрешений SharePoint для управления доступом и изменения структуры. Позволяет использовать некоторые объекты базы данных, например формы, на основе браузера.	Гибкий способ. Можно легко разрабатывать новые функции базы данных без нарушения работы. Пользователи могут изменять структуру объектов в собственной копии.

30.03.17 3.4K

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

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

Надлежащим образом структурированная база данных:

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

Разработка БД включает в себя следующие этапы:

1. Анализ требований или определение цели базы данных;
2. Организация данных в таблицах;
3. Указание первичных ключей и анализ связей;
4. Нормализация таблиц.

Рассмотрим каждый этап проектирования баз данных подробнее. Обратите внимание, что в этом руководстве рассматривается реляционная модель базы данных Эдгара Кодда , написанная на языке SQL (а не иерархическая, сетевая или объектная модели ).

Анализ требований: определение цели базы данных

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

Вот несколько способов сбора информации перед созданием базы данных:

• Опрос людей, которые будут ее использовать;
• Анализ бизнес-форм, таких как счета-фактуры, расписания, опросы;
• Рассмотрение всех существующих систем данных (включая физические и цифровые файлы ).

Начните со сбора существующих данных, которые будут включены в базу. Затем определите типы данных, которые нужно сохранить. А также объекты, которые описывают эти данные. Например:

Клиенты

• Адрес;
• Город, штат, почтовый индекс;
• Адрес электронной почты.

Товары

• Название;
• Цена;
• Количество в наличии;
• Количество под заказ.

Заказы

• Номер заказа;
• Торговый представитель;
• Дата;
• Товар;
• Количество;
• Цена;
• Стоимость.

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

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

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

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

Чтобы преобразовать списки данных в таблицы, начните с создания таблицы для каждого типа объектов, таких как товары, продажи, клиенты и заказы. Вот пример:

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

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

• CHAR — конкретная длина текста;
• VARCHAR — текст различной длины;
• TEXT — большой объем текста;
• INT — положительное или отрицательное целое число;
• FLOAT , DOUBLE — числа с плавающей запятой;
• BLOB — двоичные данные.

Некоторые СУБД также предлагают тип данных Autonumber , который автоматически генерирует уникальный номер в каждой строке.

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

При проектировании информационной базы данных необходимо решить, какие атрибуты будут служить в качестве первичного ключа для каждой таблицы, если таковые будут. Первичный ключ (PK ) — это уникальный идентификатор для данного объекта. С его помощью вы можете выбрать данные конкретного клиента, даже если знаете только это значение.

Атрибуты, выбранные в качестве первичных ключей, должны быть уникальными, неизменяемыми и для них не может быть задано значение NULL (они не могут быть пустыми ). По этой причине номера заказов и имена пользователей являются подходящими первичными ключами, а номера телефонов или адреса — нет. Также можно использовать в качестве первичного ключа несколько полей одновременно (это называется составным ключом ).

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

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

Создание связей между сущностями

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

Каждый объект может быть взаимосвязан с другим с помощью одного из трех типов связи:

Связь «один-к одному»

Когда существует только один экземпляр объекта A для каждого экземпляра объекта B, говорят, что между ними существует связь «один-к одному » (часто обозначается 1:1 ). Можно указать этот тип связи в ER-диаграмме линией с тире на каждом конце:

Если при проектировании и разработке баз данных у вас нет оснований разделять эти данные, связь 1:1 обычно указывает на то, что в лучше объединить эти таблицы в одну.

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

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

Связь «один-ко-многим»

Эта связи возникают, когда запись в одной таблице связана с несколькими записями в другой. Например, один клиент мог разместить много заказов, или у читателя может быть сразу несколько книг, взятых в библиотеке. Связи «один- ко-многим » (1:M ) обозначаются так называемой «меткой ноги вороны», как в этом примере:

Чтобы реализовать связь 1:M , добавьте первичный ключ из «одной » таблицы в качестве атрибута в другую таблицу. Если первичный ключ таким образом указан в другой таблице, он называется внешним ключом. Таблица со стороны связи «1 » представляет собой родительскую таблицу для дочерней таблицы на другой стороне.

Связь «многие-ко-многим»

Когда несколько объектов таблицы могут быть связаны с несколькими объектами другой. Говорят, что они имеют связь «многие-ко-многим » (M:N ). Например, в случае студентов и курсов, поскольку студент может посещать много курсов, и каждый курс могут посещать много студентов.

На ER-диаграмме эти связи отображаются с помощью следующих строк:

При проектировании структуры базы данных реализовать такого рода связи невозможно. Вместо этого нужно разбить их на две связи «один-ко-многим ».

Для этого нужно создать между этими двумя таблицами новую сущность. Если между продажами и продуктами существует связь M:N , можно назвать этот новый объект «sold_products », так как он будет содержать данные для каждой продажи. И таблица продаж, и таблица товаров будут иметь связь 1:M с sold_products . Этот вид промежуточного объекта в различных моделях называется таблицей ссылок, ассоциативным объектом или таблицей связей.

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

Обязательно или нет?

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

Два объекта могут быть взаимозависимыми (один не может существовать без другого ).

Рекурсивные связи

Иногда при проектировании базы данных таблица указывает на себя саму. Например, таблица сотрудников может иметь атрибут «руководитель», который ссылается на другое лицо в этой же таблице. Это называется рекурсивными связями.

Лишние связи

Лишние связи — это те, которые выражены более одного раза. Как правило, можно удалить одну из таких связей без потери какой-либо важной информации. Например, если объект «ученики » имеет прямую связь с другим объектом, называемым «учителя », но также имеет косвенные отношения с учителями через «предметы », нужно удалить связь между «учениками » и «учителями ». Так как единственный способ, которым ученикам назначают учителей — это предметы.

Нормализация базы данных

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

В то же время не все базы данных необходимо нормализовать. В целом, базы с обработкой транзакций в реальном времени (OLTP ), должны быть нормализованы.

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

Первая форма нормализации

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

Возможно, у вас возникнет желание обойти это ограничение, разделив данные на дополнительные столбцы. Но это также противоречит правилам: таблица с группами повторяющихся или тесно связанных атрибутов не соответствует первой форме нормализации. Например, приведенная ниже таблица не соответствует 1NF :
Вместо этого во время физического проектирования базы данных разделите данные на несколько таблиц или записей, пока каждая ячейка не будет содержать только одно значение, и дополнительных столбцов не будет. Такие данные считаются разбитыми до наименьшего полезного размера. В приведенной выше таблице можно создать дополнительную таблицу «Реквизиты продаж », которая будет соответствовать конкретным продуктам с продажами. «Продажи » будут иметь связь 1:M с «Реквизитами продаж ».

Вторая форма нормализации

Вторая форма нормализации (2NF ) предусматривает, что каждый из атрибутов должен полностью зависеть от первичного ключа. Каждый атрибут должен напрямую зависеть от всего первичного ключа, а не косвенно через другой атрибут.

Например, атрибут «возраст » зависит от «дня рождения », который, в свою очередь, зависит от «ID студента », имеет частичную функциональную зависимость. Таблица, содержащая эти атрибуты, не будет соответствовать второй форме нормализации.

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

Таким образом, таблица с этими полями не будет соответствовать второй форме нормализации, поскольку атрибут «название товара » зависит от идентификатора продукта, но не от номера заказа:

• Номер заказа (первичный ключ );
• ID товара (первичный ключ );
• Название товара.

Третья форма нормализации

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

В соответствии с 3NF , нельзя хранить в таблице любые производные данные, такие как столбец «Налог », который в приведенном ниже примере, напрямую зависит от общей стоимости заказа:

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

Многомерные данные

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

Правила целостности данных

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

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

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

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

Добавление индексов и представлений

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

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

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

Расширенные свойства

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

SQL и UML

Унифицированный язык моделирования (UML ) — это еще один визуальный способ выражения сложных систем, созданных на объектно-ориентированном языке. Некоторые из концепций, упомянутых в этом руководстве, известны в UML под разными названиями. Например, объект в UML известен, как класс.

Сейчас UML используется не так часто. В наши дни он применяется академически и в общении между разработчиками программного обеспечения и их клиентами.

Хорошо Плохо

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

Если вы владелец малого бизнеса, и в своей работе еще не используете Систему управления взаимоотношениями с клиентами (CRM или Customer Relationship Management), автоматизирующую генерацию стратегий взаимодействия с клиентами, то успех вашего дела подвержен определённым рискам. Помните, что ваши конкуренты не дремлют!

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

Filemaker Pro 12

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

Microsoft Access 2010

Долгое время система управления базами данных Access из пакета Microsoft Office была самым популярным решением для большинства предприятий малого бизнеса. Однако сейчас она столкнулась с конкуренцией других СУБД, которые проще в использовании, лучше интегрированы с облачными системами, не требуют больших знаний в создании, ведении баз данных и в разработке программного обеспечения.

Если у вас уже имеется база данных, есть вероятность, что она была построена при помощи Microsoft Access. Новая версия 2010 года выглядит и работает лучше, проще в использовании, по сравнению с предыдущими версиями, например, с массово используемой версией 2003 года. Несмотря на то, что эту СУБД начали теснить конкуренты, она все ещё занимает лидирующие позиции в этом сегменте рынка программного обеспечения.

Oracle Application Express (APEX) база данный бизнес

APEX представляет собой систему управления базами данных, построенную на мега-успешном движке базы данных Oracle. APEX доступен совершенно бесплатно, если вы уже являетесь клиентом Oracle и обеспечивает более продвинутую систему создания бизнес приложений, чем Microsoft Access или FileMaker Pro. Однако использование APEX не так просто в сравнении с простым введением данных в таблицы, как это происходит в базе данных Access.

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

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

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

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

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

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

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

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

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

Реакция на появление этих новых технологий была вполне предсказуемой: в крупном бизнесе сохраняли еще больше информации и требовали все более быстрого оборудования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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