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

• Введение
• 1. Общая часть
• 1.1 Описание проблемной области
• 1.2 Описание средств проектирования
• 1.2.1 Язык программирования Delphi 7.0
• 1.2.2 Свойство SQL
• 1.2.3 Доступ к данным
• 2. Специальная часть
• 2.1 Моделирование проблемной области
• 2.2 Моделирование прецедентов
• 2.3 Построение диаграммы последовательности
• 2.4 Диаграмма состояния
• 2.5 Диаграмма классов
• 2.6 Проектирование баз данных
• 2.6.1 Этапы проектирования базы данных
• 2.6.2 Компоненты для работы с БД
• 2.6.3 Запросы и их применение
• 2.6.4 Взаимосвязи таблиц
• 2.6.5 Создание схемы данных
• 2.6.6 Создание контейнера TDataModule
• 2.6.7 Обеспечение целостности данных
• 2.6.8 Каскадное обновление и удаление связанных записей
• 3. Проектирование пользовательского интерфейса
• 4. Охрана труда
• 4.1 Санитарно-эпидемиологические требования к организации и условиям работы с видеодисплейными терминалами и персональными электронно-вычислительными машинами
• 4.1.1 Санитарно-эпидемиологические требования к микроклимату
• 4.1.2 Санитарно-эпидемиологические требования к освещению на рабочих местах
• 4.1.3 Требования к уровням электромагнитных полей на рабочих местах, оборудованных ПЭВМ
• 4.1.4 Обеспечение пожаробезопасности в вычислительном центре
• 4.1.5 Обеспечение электробезопасности в вычислительном центре
• 4.1.6 Санитарно-эпидемиологические требования к уровням шума и вибрации на рабочих местах
• 4.1.7 Требования к уровням неионизирующих и ионизирующих излучений
• 4.2 Расчеты
• 4.2.1 Расчет естественного освещения в помещении
• 4.2.2 Расчет звукопоглощения
• 4.2.2.1 Цель расчета
• 4.2.2.3 Расчет 1
• 4.2.2.4 Расчет 2
• 4.2.3 Расчет защитного зануления
• 5. Экономическая часть
• 5.1 Технико-экономическое обоснование
• 5.2 Расчет коммерческой стоимости разработки программных средств (ПС)
• 5.2.1 Расчет затрат на заработную плату
• 5.2.2 Расходы на статью «материалы»
• 5.2.3 Расходы на статью «Спецоборудование для научных работ»
• 5.2.4 Расчет затрат на разработку алгоритма
• 5.2.5 Расчет затрат на написание и отладку программного продукта
• 5.2.6 Расчет затрат в статье «прочие расходы»
• 5.3 Оценка эффективности внедрения программных средств
• 5.4 Вывод
• Заключение
• Список литературы
• Приложения

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

Дирекция объединяет три проекта АО «Казахтелеком», успешно внедренных на телекоммуникационном рынке: национальную сеть передачи данных Kazakhstan Online, цифровую телефонную бизнес-сеть Jrun и спутниковую сеть Kulan. Объединение трех отделов продаж в одну Дирекцию дает возможность пользователю получить весь спектр современных телекоммуникационных услуг в одном офисе, что связано с заботой об экономии времени клиентами. Предлагая новейшие технологии, Дирекция Корпоративных Продаж обеспечивает полный спектр услуг, отвечающий потребностям самого широкого круга потребителей — от крупных корпораций и банков до государственных структур.

Основу работы ДКП составляет принцип высокого качества предоставляемых услуг. Качественная работа проявляется во всем, начиная с отношения к клиенту, заканчивая расширением спектра предоставляемых услуг и наращиванием продовольственных мощностей. Для этого у Дирекции торговой компании АО «Рамстор» есть все возможности, а именно:

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

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

применение оптимальных сетевых решений.

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

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

1. Общая часть

1.1 Описание проблемной области

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

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

1.2 Описание средств проектирования

1.2.1 Язык программирования Delphi 7.0

Бурное развитие вычислительной техники, потребность в эффективных средствах разработки программного обеспечения привели к появлению систем программирования, ориентированных на так называемую «быструю разработку», среди которых можно выделить Borland Delphi. Delphi представляет собой самый популярный программный продукт фирмы Borland, предназначен для скоростной разработки приложений Windows. С его помощью производство программного обеспечения для Windows становится довольно быстрым. В распоряжении разработчика оказывается вся мощь компилируемого языка программирования (Object Pascal), помещенного в оболочку средств скоростной разработки приложения (RAD-систем, Rapid Application Development среда быстрой разработки приложений). Это значит, что при проектировании интерфейса пользователя (сюда относят различного рода меню, диалоговые панели, главное окно приложения и т. д.) разработчик имеет возможность воспользоваться механикой drap-and-drop. И все это разработчик получает практически бесплатно — даже не жертвуя скоростью выполнения приложений, поскольку Delphi сразу генерирует быстрый машинный код. Delphi замечательно справляется с тем, что касается сокрытия низкоуровневой «кухни» программирования под Windows, но даже она не сможет писать программы.

Delphi это среда быстрой разработки, в которой в качестве языка программирования используется язык Delphi. Язык Delphi строго типизированный объектно-ориентированный язык, в основе которого лежит хорошо знакомый программистам Object Pascal.

Borland Delphi 7.0 позволяет создавать самые различные программы: от простейших однооконных приложений до программ управления распределенными базами. В состав пакета включены разнообразные утилиты, обеспечивающие работу с базами данных, XML-документами, создание справочной системы, решение других задач. Borland Delphi 6 может работать в среде операционных систем от Windows98 до Windows2000. Особых требований, по современным меркам, к ресурсам компьютера пакет не предъявляет: процессор должен быть типа Pentium или Celeron с тактовой частотой не ниже 166 МГц (рекомендуется Pentium II 400 МГц), оперативной памяти — 128 Мбайт (рекомендуется 256 Мбайт), достаточное количество свободного дискового пространства (для полной установки версии Enterprise необходимо приблизительно 475 Мбайт).

Для операций с БД в Delphi имеются следующие средства:

BDE (Borland DataBase Engine) — процессор баз данных, который представляет собой набор библиотек, предназначенных для организации доступа к БД.

BDE Administrator — утилита для настройки BDE.

база статистика табличный процессор

DataBaseDesktop — программа для создания и редактирование таблиц SQL и QBE запросов.

SQL Explorer — проводник БД, позволяет настраивать параметры БД.

SQL Monitor — программа для отслеживания порядка выполнения SQL — запросов.

SQL Links — драйверы для доступа к удаленным программ СУБД, например MSSQL Server Oracle

Local InterBase Server — локальная версия SQL — сервера Borland InterBase

InterBase Server Server for Windows 95 — много пользовательская версия SQL — сервера Borland InterBase, рассчитанная на четыре одновременных соединения.

1.2.2 Свойство SQL

Свойство SQL — вероятно, самая важная часть TQuery. Доступ к этому свойству происходит либо через Инспектор Объектов во время конструирования проекта (design time), или программно во время выполнения программы (run time).

Интересней, конечно, получить доступ к свойству SQL во время выполнения, чтобы динамически изменять запрос. Например, если требуется выполнить три SQL запроса, то не надо размещать три компонента TQuery на форме. Вместо этого можно разместить один и просто изменять свойство SQL три раза. Наиболее эффективный, простой и мощный способ — сделать это через параметризованные запросы, которые будут объяснены в следующей части. Однако, сначала исследуем основные особенности свойства SQL, а потом рассмотрим более сложные темы, типа запросов с параметрами.

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

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

1.2.3 Доступ к данным

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

В данной работе была выбрана ADO-технология доступа к данным. ADO — это стратегически важный API-интерфейс доступа к базам данных и информации на платформе Windows. Он обеспечивает единообразный доступ к данным и обслуживает многие потребности разработки, включая создание внешних клиентов баз данных и бизнес-объектов промежуточного уровня, использующих приложения, инструменты, языки и Интернет-браузеры. ADO был разработан как единственный интерфейс с данными, необходимый для разработки одно — и многоуровневых решений типа «клиент-сервер» или Интернет-приложений, управляемых данными. Главные достоинства интерфейса ADO — простота использования, высокая скорость, низкие дополнительные затраты при работе с памятью и небольшая потребность в дисковых ресурсах.

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

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

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

Наиболее значимые из новых возможностей ADO «сплющенная» объектная модель и усовершенствованная масштабируемость доступа к локальным и удаленным базам данных. Последняя технология еще далеко от совершенства — содержащиеся в ней в настоящий момент ошибки достаточно серьезны, но она позволяет вам делать намного больше и с меньшими усилиями, особенно при доступе к удаленным данным.

В качестве системы управления базами данных была выбрана система Microsoft SQL Server. Microsoft SQL Server 2000 Enterprise Edition — это полнофункциональная система управления базами данных и анализа, предназначенная для быстрой разработки современных масштабируемых бизнес-приложений, систем электронной коммерции и информационных хранилищ.

SQL Server 2000 обеспечивает высокий уровень масштабируемости, что позволяет использовать SQL Server 2000 и на домашних компьютерах и в масштабах предприятия (Standart Edition или Enterprise Edition). Однока основное направление использования SQL Server 2000 сетевой сервер БД. SQL Server 2000 может применяться как в небольших компаниях с несколькими пользователями, так и в транснациональных корпорациях с территориально разобщенными офисами и десятками тысяч сотрудников. В зависимости от числа пользователей, масштаба предприятия и ожидаемой нагрузки можно выбирать версии.

2. Специальная часть

2.1 Моделирование проблемной области

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

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

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

класс получения данных из приложения;

класс заполнения данными базы данных;

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

система формирования диаграммы;

система загрузки данных в MS Excel.

2.2 Моделирование прецедентов

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

На укрупненном уровне ЖЦ включает три этапа:

анализ;

проектирование;

реализация.

На детализированном уровне ЖЦ можно разбить на семь этапов:

установление требований;

спецификация требований;

проектирование архитектуры;

детализированное проектирование;

реализация;

интеграция;

сопровождение.

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

Рассмотрим требования предъявляемые пользователями данной системы. У будущих пользователей возникают следующие требования к разрабатываемой системе:

система должна уменьшить количество затраченного времени на поиск и обработку информацию;

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

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

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

Следующим этапом разработки программного продукта является построение диаграммы прецедентов.

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

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

Диаграмма прецедентов — это документированная модель предполагаемого поведения системы.

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

краткое описание;

предусловия;

детализированное описание потока событий: основной поток и альтернативные потоки;

постусловия.

Диаграмма прецедентов показана на рисунке 2.1.

Рисунок 2.1 — Диаграмма прецедентов

Для дальнейшего более подробного рассмотрения и документирования выделяется прецедент «Формирование письма» .

Приведем описательную спецификацию данного прецедента:

а) прецедент дает возможность оператору провести заполнение письма-уведомления и отобразить результаты в текстовый документ;

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

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

г) альтернативный поток: инженер может импортировать данные MS Excel и перейти к главному окно, а так добавить в базу данных сведения о новом клиенте;

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

2.3 Построение диаграммы последовательности

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

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

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

Диаграмма последовательности состоит из основных элементов:

текста последовательности действий в прецеденте, который записывается сверху вниз по левой стороне;

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

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

Диаграмма последовательности показана на рисунке 2.2.

Рисунок 2.2 — Диаграмма последовательности

2.4 Диаграмма состояния

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

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

Под состоянием понимается абстрактный метакласс, используемый для моделирования отдельной ситуации, в течение которого имеет место выполнение некоторого условия. Состояние может быть задано в виде набора конкретных значений атрибута класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта. Не каждый атрибут класса может характеризовать его состояние. Имеют значение только такие свойства элементов системы, которые отражают динамический или функциональный аспект ее поведения. В этом случае состояние будет характеризоваться некоторым инвариантным условием, включающим в себя только значимые для поведения класса атрибуты и их значения. Состояние определяется именем и списком внутренних действий или деятельностей, которые выполняются в процессе нахождения моделируемого элемента в данном состоянии и характеризуются меткой действия (entry, exit, do, include). Начальное состояние — частный случай состояния, которое не содержит никаких внутренних действий (псевдосостояния), в котором находится объект по умолчанию в начальный момент времени. Конечное состояние — частный случай состояния, которое не содержит никаких внутренних действий (псевдосостояния), в котором находится объект по умолчанию после завершения работы автомата в конечный момент времени. Состояния могут быть составными — т. е. состоящими из других, вложенных в него состояний (подсостояний), которые могут быть как последовательными, так и параллельными; историческими — т. е. запоминающими; синхронизирующими.

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

Сложные переходы:

а) соединение — если имеется две и более входящих дуг;

б) ветвление — если имеется две и более исходящих дуг.

На рисунке 2.3 показана диаграмма состояния.

Рисунок 2.3 — Диаграмма состояния

2.5 Диаграмма классов

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

Моделирование классов — итеративный пошаговый процесс.

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

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

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

Рисунок 2.4 — Диаграмма классов

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

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

2.6.1 Этапы проектирования базы данных

Основные этапы проектирования базы данных:

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

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

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

При проектировании таблиц вовсе не обязательно использовать Database Desktop. Сначала лучше разработать структуру на бумаге. При проектировке таблиц, рекомендуется руководствоваться следующими основными принципами:

1) информация в таблице не должна дублироваться;

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

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

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

1) каждое поле должно быть связано с темой таблицы;

2) не рекомендуется включать в таблицу данные, которые являются результатом выражения;

3) в таблице должна присутствовать вся необходимая информация;

4) информацию следует разбивать на наименьшие логические единицы;

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

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

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

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

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

и) использование средств анализа в Database Desktop. В Database Desktop существует два инструмента для усовершенствования структуры баз данных.

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

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

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

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

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

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

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

2.6.2 Компоненты для работы с БД

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

Наборы данных это совокупность записей, взятых из одной или нескольких таблиц БД. Набор данных является логической таблицей, записи которой отбирается по определенным правилам. Взаимодействия набора данных и таблицы аналогично взаимосвязанного физического файла и файловой переменной. В Delphi для работы с НД используются компоненты Table, Query, StoredProc и DesisionQuery.

StoredProc — для организации взаимодействия с удаленной БД,

DesisionQuery. — для построения систем принятия решений.

Основные возможности доступа к БД обеспечивает класс TDataSet — это перемещение по НД и их редактирование. Компоненты ТTable и ТQuery происходят от класса TBDE TDataSet — потомка класса TDataSet через (класс TBDE TDataSet). Для указания местоположения таблиц БД используется свойство DataBaseName. Для ТQuery дополнительно можно задать в SQL — запросе путь доступа к каждой таблице. Число записей, составляющих НД, определяет свойство RecordCount типа Longint. Управление числом записей в НД осуществляется косвенно путем отбора: через фильтрацию или SQL — запрос.

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

Навигационный

Реляционный

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

Реляционный способ доступа основан на обработке группы записей. Если необходимо обработать одну запись, все равно обрабатывается группа, которая рассматривается как одна. Реляционный способ основан на SQL — запросах и называется SQL ориентированным. Используется для работы с удаленной БД.

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

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

сортировка записей

поиск записей

установка связей между таблицами.

Установить текущий индекс можно с помощью свойств Index Name или Index Fieldnames muna String.

Текущий индекс выбирается из списка индексов, которые были заданы при создании таблицы.

Оба свойства Index Name и IndexFieldNames похожи и используются одинаково, но значением IndexName является имя индекса, заданное при создании таблицы, а значением свойства IndexFieldNames — имя поля, для которого был создан индекс. Если используется индекс, состоящий из нескольких полей, то для свойства IndexName по-прежнему задается имя этого индекса, а для свойства IndexFieldNames перечисляются (через точку с запятой) имена полей, которые входят в этот индекс.

Таблица хранит сведения по конкретному вопросу, например, таблица «Cards», содержит данные только о ID номере карточки и фамилия, имя владельца, а таблица «Продажи» содержит данные только о денежных операциях клиента. Для того, чтобы данные не дублировались и не происходило ошибок при их выдаче, необходимо распределить данные разного рода по разным таблицам. Данные в таблице организованны в столбцы (называемые полями) и в строки (называемые записями).

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

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

Уникальная метка, называемая ключом, используется для определения каждой записи таблицы. Подобно тому, как номерной знак однозначно определяет автомобиль, ключ определяет запись. Ключевые поля в таблицах используются для создания межтабличных связей. Например, поле «Лицевой счет» из таблицы «Реквизиты» используется для объединения сведений о товарах и заказах из разных таблиц для их вывода на печать.

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

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

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

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

Это можно сделать путем выделения директории (или путем создания папки) для компонентов БД.

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

1) C: Primer;

2) C: SYSTEMASTUDENT… Primer.

Обычно в режиме локальных баз данных работают БД (или таблицы БД), созданные в формате СУБД Paradox, dBase и FoxPro.

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

В связи с отмеченным, в утилите BDE Administrator Delphi должен быть:

зарегистрирован псевдоним БД и

указан адрес (путь) к БД.

Создание БД в Delphi или для работы в Delphi начинается с задания места расположения и хранения.

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

Fields Name — имя поля;

Type - тип поля;

Size - размер поля (для строковых полей, поскольку иные поля подразумевают размер, определяемый типом поля);

Key - содержит звездочку '*', если поле входит в состав первичного ключа. Если в первичный ключ входит несколько полей, они должны определяться в той последовательности, в которой они присутствуют в первичном ключе. Кроме того, все поля, входящие в состав первичного индекса, должны определяться перед иными полями, то есть быть в списке полей наверху.

Определим поля, входящие в таблицу «Материалы». Введем Material в столбец Field Name. Для того, чтобы определить тип поля, щелкните по столбцу Type и нажмите клавишу пробела. В ответ на это будет выдан список типов полей, из которых необходимо произвести выбор нужного типа (рис.7).

Рис. 7. Выбор типа поля

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

Мастер таблица по первичному ключу индексируется.

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

Чтобы запомнить сохраненную таблицу на диске, следует нажать кнопку Save As. Затем в появившемся окне следует указать имя таблицы (рис.10) При желании можно указать каталог или псевдоним, отличные от принятых по умолчанию. Напомним, что по умолчанию принимается рабочий каталог или каталог, определяемый рабочим псевдонимом

2.6.3 Запросы и их применение

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

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

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

2.6.4 Взаимосвязи таблиц

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

Одно-многозначные (1: М) или одно-однозначные (1:

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

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

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

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

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

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

Связи-объединения. Между двумя таблицами может быть установлена связь-объединение по некоторому полю связи. Для связи-объединения может быть выбран один из трех способов объединения записей:

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

б) способ 2 — объединение тех записей, в которых связанные поля обеих таблиц совпадают, а также объединение всех записей из первой таблицы, для которых нет связанных во второй, с пустой записью второй таблицы;

в) способ 3 — объединение тех записей, в которых связанные поля обеих таблиц совпадают, а также объединение всех записей из второй таблицы, для которых нет связанных в первой, с пустой записью первой таблицы.

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

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

2.6.5 Создание схемы данных

Создание схемы данных начинается в окне Базы данных (Database) с выполнения команды Сервис|Схема данных (Tools|Relationships) или нажатия кнопки Схема данных (Relationships) на панели инструментов базы данных.

Включение таблиц в схему данных. После нажатия кнопки Схема данных (Relationships) открывается окно Добавление таблицы (Show Table), в котором можно выбрать таблицы и запросы, включаемые в схему данных. Для размещения таблицы в окне Схема данных (Relationships) надо выделить ее в окне Добавление таблицы (Show Table) и нажать кнопку. Добавить (Add). Для выделения нескольких таблиц надо, удерживая клавишу, щелкнуть мышью на каждой из этих таблиц. Включив все нужные таблицы в схему данных, нажать кнопку. Закрыть (Close).

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

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

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

При создании связи по составному ключу необходимо выделить все поля, входящие в ключ главной таблицы, и перетащить их на одно из полей связи в подчиненной таблице. Для выделения всех полей, входящих в составной уникальный ключ, необходимо отмечать поля при нажатой клавише. После создания связи откроется окно Изменение связей (Edit Relationships). При этом в строке Тип отношения (Relationship Type) автоматически установится тип один-ко-многим (One-To-Many).

При составном ключе связи в окне Изменение связей (Edit Relationships) необходимо для каждого поля ключа в главной таблице таблица/запрос (Table/Query) выбрать соответствующее поле подчиненной таблицы, названной связанная таблица/запрос (Related Table/Query).

2.6.6 Создание контейнера TDataModule

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

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

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

1. Доступ каждой формы (и ее компонентов) к БД можно осуществить автономно, независимо от остальных форм.

2. Второй способ предполагает не повторять для каждой формы организацию доступа к БД, а для всех экранных и отчетных форм организовать единый доступ через специальный компонент типа TDataModule. Компонент типа TDataModule представляет собой контейнер, в который можно помещать невизуальные компоненты TTable, TQuery, DataSource, которые необходимы для доступа к БД и т. д. Тогда все те формы, для которых потребуется доступ к БД, доступ получат через компонент TdataModule. Поэтому при создании СУБД для каждой экранной формы необходимо установить связь с компонентой типа TdataModule.

Таким образом, для работы СУБД необходимо создать компонент типа TDataModule.

Создание экземпляра TDataModule в среде Delphi осуществляется через пункт меню File|New Data Module.

Компонент TDataModule служит контейнером компонентов для работы с базами данных. В палитре компонентов Delphi на странице Data Access выберем мышью невизуальный компонент ТТаblе (рис. 20), щелкнем на нем мышью и затем щелкнем мышью в контейнере. После этого, изображение компоненты останется в контейнере.

Рис. 20. Палитра компонентов Delphi

Невизуальным компонент TTable (как и другие компоненты, например, TQuery, TDataSource) называется потому, что он применяется для хранения и доступа к данным, а не для их визуализации — для этой цели применяются визуальные компоненты (TDBGrid, TEdit и другие).

После того, как мы разместили компонент TTable, установим его свойства. Для этой цели воспользуемся инспектором объектов (Object Inspector), который обычно помещается слева от формы. Если он не видим, его можно вызвать, нажав кнопку F11. Инспектор объектов позволяет устанавливать свойства того компонента, который выделен при помощи мыши. Выделим мышью компонент TTable.

Установим значение свойства DatabaseName (псевдоним БД) в PRIMER при помощи выпадающего списка или введя его вручную. Установим значение свойства TableName (имя таблицы БД) в Materialy. DB при помощи выпадающего списка. После этого установим значение свойства Active в True. После этого произойдет реальное связывание компонента TTable (он по умолчанию имеет имя Table1) с реально существующей таблицей Materialy. DB.

Компонент TTable и компонент TQuery (его мы рассмотрим позже) служат для хранения наборов данных. Понятие набора данных несколько шире, чем понятие таблицы БД, поскольку набор данных может содержать:

подмножество записей или полей таблицы БД (компоненты TTable, TQuery);

записи, сформированные из нескольких таблиц БД (компонент TQuery).

Расположим в контейнере DataModule компонент TDataSource. Он служит в качестве связующего звена между невизуальными компонентами (в данном случае Table1) и визуальными компонентами, которые мы добавим в форму № 3 позднее. Поэтому компоненты TDataSource часто называют источниками данных. Установим свойство DataSet (имя набора данных) компонента TDataSource в значение Table1 путем выбора из выпадающего списка.

TDataModule нужно сохранить под каким-либо именем (по умолчанию Unit5. pas). Имя модуля Unit, в котором описан TDataModule, добавляется в текст модулей unit всех иных форм приложения, которые будут использовать БД и TDataSource, расположенные в этом TDataModule. Это производится в главном меню среды Delphi, в элементе меню File|Use Unit.