Постановка задачи. Delphi — императивный, структурированный, объектно-ориентированный язык программирования со строгой статической типизацией переменных

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

Первоначально носил название Object Pascal и исторически восходит к одноименному диалекту языка, разработанному в фирме Apple в 1986 году группой Ларри Теслера. Однако в настоящее время термин Object Pascal чаще всего употребляется в значении языка среды программирования Delphi. Начиная с Delphi 7в, в официальных документах Borland стала использовать название Delphi для обозначения языка Object Pascal.

Целью дипломного проекта является разработка программного обеспечения в объектно-ориентированной среде визуального программирования Delphi 7, реализующую базу данных «Техническое обслуживание станков». Программа позволит работать с базой данных, где будет поддерживать возможность добавления, удаления, редактирования, поиска, сохранения и считывание из файла.

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

Основные компоненты MS Access:

-построитель таблиц;

-построитель экранных форм;

-построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);

-построитель отчётов, выводимых на печать.

Они могут вызывать скрипты на языке VBA, поэтому MS Access позволяет разрабатывать приложения и БД практически «с нуля» или написать оболочку для внешней БД.

Основные задачи, реализуемые приложением:

1. обеспечение ввода, корректировки и выборки данных;

2. учет поставок станков;

3. учёт финансовой деятельности ремонта станков;

4. учет ремонта станков.

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

1. Создание/удаление БД;

2. Заполнение БД;

3. Удаление/добавление информации в таблицах, корректировка записей, поиск данных в БД;

4. Создание отчётов.

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

2.2. Проектирование информационно – логической модели БД

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

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

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

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

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

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

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

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

На этом шаге желательно создание следующих документов:

-набора подсхем;

-спецификаций для физического проектирования приложений;

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

-руководства по сопровождению БД.

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

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

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

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

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

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

Составим логическую модель предметной области (рис 1.)

Рис. 1. Логическая модель предметной области

На базе данной модели, составим таблицу для наглядного описания (табл.1)