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

Размещено на http://www.allbest.ru/

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

Корнеева Е.В., ст. преподаватель,

ФГОУВПО «Российский государственный университет туризма и сервиса», г. Москва

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

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

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

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

Одной из наиболее ответственных и трудных задач, связанных с созданием информационной системы, является проектирование баз данных (БД). В результате ее решения должны быть определены содержание БД, эффективный с точки зрения будущих пользователей способ ее организации, а также инструментальные средства управления данными, которые будут применяться в создаваемой системе [1,2].

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

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

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

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

В отношении проектирования БД созданы и интегрированы в стройные схемы методы выполнения следующих проектных этапов [1]:

· концептуальное проектирование БД, построение концептуальной модели базы данных;

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

· выбор инструментальных программных средств обработки данных;

· логическое проектирование БД, построение логической модели БД;

· физическое проектирование БД, построение физической модели БД.

Для указанных методов разработаны полные, целостные методические системы. Для большинства методов предложены формализованные модели, которые нашли реальное применение в практике проектирования [1,2].

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

Наряду с относительно дешевыми системами проектирования БД с весьма ограниченными возможностями используются САПР баз данных с использованием CASE-средств. Можно выделить два основных направления развития CASE-систем и технологий проектирования:

1) CASE-системы для проектирования собственно БД; эти системы имеют также средства для описания функций обработки информации;

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

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

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

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

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

Слабоструктурированными называются данные, обладающие какими-либо из следующих характеристик:

схема данных не задана заранее и может неявно содержаться в данных;

схема данных сравнительно велика (объем данных) и может часто изменяться;

схема данных является описательной, т.е. она описывает текущее состояние данных, допускаются нарушения этой схемы;

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

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

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

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

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

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

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

· подсистемы проектирования БД на основе хранимой слабоструктурированной информации в формате MS Word;

· подсистемы создания спроектированной базы данных;

· подсистемы ввода информации в базу данных.

Основные цели проектирования БД на основе хранимой слабоструктурированной информации следующие:

возможность хранения в БД всех необходимых данных;

сведение к минимуму числа хранимых в БД таблиц;

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

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

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

Нормализация представляет собой формальную процедуру, в ходе которой одна таблица разбивается на две или несколько в соответствии со специальной процедурой разбиения [1,2]. Задачами нормализации являются:

· исключение из таблиц повторяющейся информации;

· создание структуры, в которой предусмотрена возможность ее будущих изменений;

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

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

· первая нормальная форма (1NF);

· вторая нормальная форма (2NF);

· третья нормальная форма (3NF);

· нормальная форма Бойса-Кодда (BCNF);

· четвертая нормальная форма (4NF);

· пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).

Перечислим основные свойства нормальных форм:

· каждая следующая нормальная форма в некотором смысле лучше предыдущей;

· при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.

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

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

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

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

Рис. 1. Процесс нормализации БД

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

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

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

Прочитать шаблон в формате MS Word.

Прочитать все поля в файле шаблона и их названия.

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

Методика ввода информации в БД включает в себя следующие этапы.

Если БД отсутствует, требуется создать ее.

Прочитать файл в формате MS Word, созданный по определенному шаблону.

Прочитать все поля в файле и их имена.

Добавить запись в БД (каждому файлу MS Word соответствует одна запись в базе данных).

Перенести значения полей из файла в соответствующие поля БД. Если поле имеет тип «список», занести в поле индекс БД соответствующее значение из соответствующей таблицы (справочника).

Если файлы еще есть, перейти к п. 2.

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

· проектирование БД на основе хранимой слабоструктурированной информации в формате MS Word;

· создание спроектированной БД;

· ввод информации в БД.

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

Рис. 2. Функциональная схема системы проектирования БД на основе хранимой слабоструктурированной информации

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

В качестве средства разработки выбран такой компонент MS Visual Studio, как Visual Basic, что обусловлено следующими соображениями:

1) язык Visual Basic является встроенным языком среды MS Word, таким образом, обеспечивается единство языка реализации в рамках всего проекта;

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

Для связи с БД используется протокол ODBC (Open Database Connectivity -- открытые средства связи с базами данных) [1]. Протокол ODBC является частью стандарта Windows Open System Architecture (открытая архитектура системы Windows) фирмы Microsoft. Протокол ODBC представляет собой набор функций интерфейса прикладного программирования (API), позволяющих разработчику легко подключаться к разнообразным базам данных различных форматов. При использовании стандартного механизма ODBC операции обработки данных в программе не зависят от используемого формата данных, что повышает переносимость кода. Таким образом, в любой момент формат базы данных можно изменить, например, при создании распределенной системы по технологии клиент-сервер.

В качестве формата базы данных выбирается формат MS Access как стандартный формат реляционных БД Microsoft для персональных компьютеров [1,4]. При этом для изменения формата данных достаточно сменить драйверы БД, никаких дополнительных изменений в программу вносить не нужно.

Алгоритм функционирования системы можно описать следующим образом (рис. 3).

Рис. 3. Алгоритмическая схема системы автоматизированного проектирования БД

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

Разработанная система обеспечивает:

· проектирование и создание БД консультативных запросов;

· извлечение информации о запросах из архива запросов, хранимых в формате MS Word;

· работу со справочниками клиентов, консультантов, профилей консультантов (рис. 4);

· занесение данных в локальную базу данных формата MS Access для удобства последующего поиска информации и статистического анализа (рис. 5);

· выполнение типовых запросов и печать отчетов.

Рис. 4. Работа со справочниками

Рис. 5. Работа с БД консультативных запросов

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

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

Литература

1. Малыхин М.П. Базы данных: основы, проектирование, использование. СПб.: БХВ-Петербург, 2004.

2. Райордан Р. Основы реляционных баз данных. М.: Изд.-торг. дом «Русская редакция», 2001.

3. Шаньгин В.Ф. Информационная безопасность компьютерных систем и сетей. М.: ИД «ФОРУМ» -- ИНФРА-М, 2008.

4. Диго С.М. Access: учебно-практическое пособие. М.: ТК Велби, Изд-во Проспект, 2006.

Размещено на Allbest.ru