Структура программного комплекса

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

В файлах формы хранится информация о формах. В файле с расширением .dfm (файл описания формы) хранится информация о внешнем виде формы, ее размерах, местоположении на экране и т. д. Файл модуля (.pas) — это текстовый файл, хранящий код модуля, соответствующего данной форме.

На рисунке представлена схема программного комплекса.

Рисунок 2.7 Схема структуры программного комплекса.

Разработка структуры базы данных (БД) и алгоритмов обработки

Процесс, в ходе которого решается, какой вид будет у вновь создаваемой базы данных, называется проектированием базы данных (database design). Работа по проектированию базы данных включает выбор:[15.16].

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

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

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

• 1. Независимость логической структуры от физического и пользовательского представления.
• 2. Гибкость структуры базы данных — конструктивные решения не ограничивают возможности выполнять в будущем самые разнообразные запросы.

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

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

Часто при обсуждении вопросов проектирования реляционных баз данных почти все внимание уделяется применению правил нормализации. В ходе нормализации обеспечивается защита целостности данных путем устранения дублирования данных [4]. В результате таблица, которая первоначально казалась «имеющей смысл», разбивается на две или более связанных таблиц, которые могут быть «собраны вместе» с помощью операции объединения. Этот процесс называется декомпозицией без потерь (non-loss decomposition) и просто означает разделение таблицы на несколько меньших таблиц без потери информации. Нормализация наиболее полезна для проверки созданной вами структуры. Можно проанализировать свои решения о том, какие столбцы должны быть включены в ту или иную таблицу с точки зрения правил нормализации, убедившись при этом, что не сделали каких-то фатальных ошибок. Понимание основ процесса нормализации также может помочь в процессе проектирования базы данных, но оно не является универсальным рецептом при построении базы с нуля. Итак, как определить, какие столбцы должны располагаться в начале таблицы. Общего правила на этот счет не существует. Однако здесь вам может оказать существенную помощь моделирование зависимостей — анализ сущности данных (в терминах объектов или вещей) и зависимостей между ними (один к одному, один ко многим, многие ко многим).

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

Исследования информационной среды для моделирования.

• — Откуда поступает информация и в каком виде?
• — Как она будет вводиться в систему и кто этим будет заниматься?
• — Как часто она изменяется?
• — Какие параметры системы будут наиболее критическими с точки зрения времени реакции на запрос и надежности?
• — Изучение всех бумажных материалов, а также информационных файлов и форм, которые используются в организации для хранения и обработки данных.
• — Уточнение, в каком виде информация должна извлекаться из базы данных — в форме отчетов, заказов, статистической информации.
• — Кому она будет предназначаться.
• 2. Создание списка объектов (вещей, которые будут предметом базы данных) вместе с их свойствами и атрибутами. Объекты, скорее всего, должны быть собраны в таблицы (каждая строка таблицы будет описывать один объект, например организацию, счет или платежное поручение), свойства объектов будут представлены столбцами таблицы (например, адрес компании, стоимость дистрибутива).
• 3. В ходе работы обязательно должен создаваться макет таблиц и связей между ними, называемый структурой данных (data structure), или диаграммой зависимостей между объектами (E-R diagram).
• 4. Предварительно разобравшись с объектами и их атрибутами, надо убедится, что каждый объект имеет атрибут (или группу атрибутов), по которому однозначно можно идентифицировать любую строку в будущей таблице. Этот идентификатор обычно называется первичным ключом. Если такового нет, то для получения искусственного ключа следует создать дополнительный столбец.

Затем должны быть рассмотрены зависимости между объектами.

• — Имеются ли зависимости типа один ко многим (один заказчик может иметь множество выписанных счетов, но каждый счет может быть выписан только на одного заказчика) или многие ко многим?
• — Есть ли возможности для объединения связанных таблиц? Для этого служат внешние ключи (foreign key), столбцы в связанных таблицах с совпадающими значениями первичных ключей.
• 6. Анализ структуры базы данных с точки зрения правил нормализации для поиска логических ошибок. Исправление всех отклонений от нормальных форм или обоснование решения отказаться от выполнения ряда правил нормализации в интересах простоты освоения или производительности. Документирование причины таких решений.
• 7. Непосредственному созданию структуры базы данных и помещению в нее некоторых прототипов данных. Обязательное экспериментирование с запросами, изучение полученных результатов. Выполнение рядов тестов на производительность, чтобы проверить разные технические решения.
• 8. Оценка базы данных с точки зрения того, удовлетворяют ли заказчика полученные результаты.