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

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

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

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

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

- среда пользователя, дающая возможность непосредственного управления данными с клавиатуры;

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

- компилятор для придания завершенной программе вида готового коммерческого продукта в форме независимого EXE‑файла;

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

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

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

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

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

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

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

Процесс проектирования базы данных информационной системы разбивается на основные этапы:

· Инфологическое проектирование – сбор, анализ, описание объектов и связей между ними.

· Логическое проектирование – преобразование требований к данным в структуры данных. На выходе получаем структуру базы данных и спецификации прикладных программ.

· Физическое проектирование – определение особенностей хранения данных, методов доступа и т.д.

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

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

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

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

Цель логического проектирования – применение принципов модели разработки приложения к конкретной задаче. Результат этого этапа – структура решения и связи между его элементами. Как правило, в результате логического проектирования определяется набор необходимых объектов, атрибутов и связей, принципы проектирования пользовательского интерфейса и логическая модель данных. (43, с. 290–294) Нормализация – это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных. Каждая таблица в реляционной БД удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное атомарное значение, и никогда не может быть множества таких значений. Любая таблица, удовлетворяющая этому условию, называется нормализованной. Фактически, ненормализованные таблицы, т.е. таблицы, содержащие повторяющиеся группы, даже не допускаются в реляционной БД. Интерфейс определяет переход от представления данных в БД к представлению, принятому среди пользователей, и обратно. В общем случае пользователи представляют данные в виде документов различных видов, от произвольных текстов до справок и таблиц фиксированного формата.

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