Разработка сайта для ресторана "МАО"
Разработка сайта для облегчения получения пользователями актуальной информации о ресторане и его деятельности на примере ресторана "МАО". Выбор инструментальных средств. Основные методы защиты данных. Анализ предметной области, руководство пользователя.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | русский |
Дата добавления | 17.03.2014 |
Размер файла | 965,1 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Министерство образования и науки Российской Федерации
Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
"Оренбургский государственный университет"
Индустриально-педагогический колледж
Отделение автоматизации информационных и технологических процессов
Курсовой проект
по дисциплине "Разработка и эксплуатация автоматизированной информационной системы "
Разработка сайта для ресторана "МАО"
ИПК ОГУ 230103.51.4014.23 КП
Руководитель работы О.В. Саликова
Исполнитель студент группы АСУ-10
А.И. Рубинштейн
Оренбург 2014
Содержание
- Введение
- 1. Аналитическая часть
- 1.1 Описание объекта автоматизации
- 1.2 Обоснование необходимости автоматизации
- 1.3 Анализ аналогов подобных программных систем
- 1.4 Постановка задачи
- 1.5 Описание структуры разрабатываемого АРМ
- 1.6 Обзор обоснования выбора инструментальных средств
- 1.7 Обзор обоснования методов защиты данных
- 2. Проектная часть
- 2.1 Анализ предметной области
- 2.1.1 Иерархия функций
- 2.1.2 Формализованное описание предметной области
- 2.2 Концептуальный уровень базы данных
- 2.2.1 Модель "объект - отношение"
- 2.2.2 Даталогическая модель БД
- 2.2.3 Анализ схем отношений на соответствие нормальной формы Бойса - Кодда
- 2.3 Физическая модель БД на основе выбранной СУБД
- 2.3.1 Описание проектируемых объектов БД
- 2.3.2 Технология создания базы данных
- 2.3.3 Реализация ограничения целостности базы данных
- 2.4 Проектирование интерфейса АРМ
- 2.4.1 Требования к пользовательскому интерфейсу
- 2.4.2 Создание справочной системы
- 2.5 Инсталляция АИС
- 2.6 Руководство пользователя
- Заключение
- Список использованных источников
- Приложения
Введение
Достаточно актуальной в наше время становится реклама в системе Интернет, число пользователей которого постоянно увеличивается. По моим оценкам правильно организованный и хорошо сайт способен давать до 20-25% посетителей. Мощное и раскрученное недорогое по сравнению с другими средствами СМИ средство продвижения ресторана. Возможность оперативного размещения новой либо корректировки уже имеющейся информации. Наличие обратной связи со своими клиентами, позволяющей проводить опросы о качестве обслуживания ресторана, его достоинствах и недостатках, пожеланиях и предложениях посетителей. Прежде всего, надо отметить, что сайт ресторана - это второе "я" заведения. Будучи безмолвным помощником, он, в то же время, красноречиво
Тема данного курсового проекта: Разработка сайта для ресторана "МАО"
Цель проекта: Создания сайта для ресторана "МАО"
Задачи:
обеспечение удобного и эффективного интерфейса пользователя;
разработка дизайна, делающего нахождение пользователя на сайте максимально комфортным;
обеспечение удобного просмотра меню ресторана;
возможность пользователя оставить отзыв о сайте или об отдельных блюдах либо пожелание, чтобы соответственно таким отзывам координировать работу сайта;
обеспечить возможность регистрации пользователя на сайте для его удобства и дополнительной безопасности;
обеспечение удобного и эффективного интерфейса служащих;
1. Аналитическая часть
1.1 Описание объекта автоматизации
Основная цель проектирования разработка сайта для ресторана "МАО". Разрабатываемый сайт должен представлять собой автоматизированный сайт для облегчения получения пользователями актуальной информации о ресторане и его деятельности. Создаваемый сайт должен представлять собой открытую, расширяемую, масштабируемую и модифицируемую систему.
Стандартный интерфейс окна приложения должен позволять работать с системой любому пользователю, знакомому со стандартными программами, работающими с операционной системой Windows [1].
1.2 Обоснование необходимости автоматизации
Пользователей интернета с каждым днем становится все больше. А это значит, что распространение информации в сети происходит очень быстро. Теперь с легкостью можно заказать еду он-лайн или забронировать столик в ресторане используя сеть интернет. Поэтому необходимо размещать информациб не только в печатных источниках, но в интернете. Web - ресурс необходим ресторану для предоставления пользователям сети и потенциальным клиентам ресторана постоянно меняющейся информации. Любой посетитель должен иметь возможность оценить уровень сервиса в данном заведении не только путем личного присутствия, но и с помощью различных доступных ему ресурсов, в том числе интернета. Сайт в качестве визитной карточки ресторана позволяет клиенту узнать по карте города, где размещается заведение, как можно удобно добраться, юридический адрес заведения, контактные телефоны, а также часы работы и особые предложения, которые появляются в тот или иной период. Сайт ресторана дает возможность забронировать понравившиеся места того или иного зала, клиент может в онлайн-режиме ознакомиться с меню блюд и винной картой на день посещения. При выборе может быть доступен такой достаточно важный показатель, как средняя ориентировочная стоимость счета.
Потенциальный посетитель ресторана при принятии решения может ориентироваться на систему скидок, которую он может увидеть на страницах сайта. Солидному ресторану нужен полнофункциональный ресурс с постоянно обновляющейся актуальной информацией. Если сайт ресторана будет находиться в топе, количество клиентов существенно увеличится, а, следовательно, и доход фирмы.
1.3 Анализ аналогов подобных программных систем
Недостатками существующей системы, в которой преобладает ручной труд, являются, в первую очередь, хранение данных в бумажном варианте.
В связи с тем, что бумажный носитель постоянно находится в эксплуатации, он подвержен разнообразным физическим воздействиям, быстро изнашивается. Следовательно, можно сделать вывод, что создание программы поможет решить проблему, связанную с потерей рабочего времени.
1.4 Постановка задачи
Целью разработки АРМ преподавателя, является автоматизация поиска и сбора данных, а так же упрощения формы хранения различных видов данных.
Основными функциями и задачами создаваемой программы являются следующие:
физическое размещение в памяти данных;
обеспечения защиты данных от некорректных обновлений и несанкционированного доступа;
организация понятного и простого в управлении пользовательского интерфейса;
организация банка данных, для дальнейшего использования;
обеспечение более удобного доступа к данным путем гибкого поиска;
В информационной системе должны быть реализованы функции добавления, редактирования, удаления всех данных.
1.5 Описание структуры разрабатываемого АРМ
Информация, необходимая для работы куратора должна храниться в базе данных. Входными данными являются сведения о студентах, их успеваемости, активе учебной группы, достижениях группы, потере контингента за время обучения, списке группы. На основании этих данных и будет осуществляться формирование банка данных рабочего места куратора группы.
Все информационное обеспечение будет представлено в виде связанных между собой таблиц, реализующих ссылочную целостность.
1.6 Обзор обоснования выбора инструментальных средств
Для разработки приложения было выбрано следующее ПО: СУБД (система управления базами данных) MS Access и система программирования Delphi.
База данных - это совокупность записей различного типа, содержащая перекрестные ссылки.
СУБД - это комплекс языковых и программных средств, предназначенный для создания, ведения и совместного использования БД многими пользователями.
В стандартную поставку Delphi входят основные объекты из 270 базовых классов (рисунок 1), при этом основным достоинством системы является простота создания графического интерфейса программы. Создание интерфейса реализуется методом draganddrop (бери и тащи), что делает процесс создания интерфейса простым и быстрым, требующим минимального написания программного кода [2].
1.7 Обзор обоснования методов защиты данных
К настоящему времени разработано много различных средств, методов, мер и мероприятий, предназначенных для защиты информации, накапливаемой, хранимой и обрабатываемой в автоматизированных информационных системах.
Сюда входят аппаратные и программные средства, криптографическое закрытие информации, физические меры, организованные мероприятия, законодательные меры.
Все эти средства защиты делятся на технические и нетехнические.
К техническим средствам защиты относят:
аппаратные и программные средства;
криптографическое закрытие информации.
К нетехническим средствам защиты относят:
аппаратные методы защиты;
программные методы защиты;
резервное копирование;
криптографическое шифрование информации;
физические меры защиты.
организационные мероприятия по защите информации.
Основные выводы о способах использования рассмотренных выше средств, методов и мероприятий защиты, сводится к следующему:
наибольший эффект достигается тогда, когда все используемые средства, методы и мероприятия объединяются в единый, целостный механизм защиты информации;
механизм защиты должен проектироваться параллельно с созданием систем обработки данных, начиная с момента выработки общего замысла построения системы;
функционирование механизма защиты должно планироваться и обеспечиваться наряду с планированием и обеспечением основных процессов автоматизированной обработки информации;
необходимо осуществлять постоянный контроль функционирования механизма защиты.
В данном АРМ применен программный метод защиты. К программным средствам защиты относятся специальные программы, которые предназначены для выполнения функций защиты и включаются в состав программного обеспечения систем обработки данных [3].
Программная защита является наиболее распространенным видом защиты, чему способствуют следующие положительные свойства:
универсальность;
гибкость;
простота реализации;
практически неограниченные возможности изменения и развития и т.п.
2. Проектная часть
2.1 Анализ предметной области
Во время предпроектного исследования было составлено описание предметной области решаемой задачи.
Основная задача состоит в сборе информации о деятельности куратора учебной группы. Для решения этой задачи разрабатывается автоматизированное рабочее место, целью которого является экономия рабочего времени и переход на безбумажные технологии.
Предметная область - фрагмент реального мира, подлежащий автоматизации. Предметная область содержит только те сущности, их взаимосвязи и процессы изменения сущностей и взаимосвязей, которые необходимы для корректной работы рассматриваемой (разрабатываемой) автоматизированной системы. Сущностью или информационным объектом предметной области называется некоторое понятие, общее для ряда объектов реального мира. Сущность описывается набором признаков, важных для рассматриваемой предметной области, состав которых позволяет отделить объекты (экземпляры) одной сущности от объектов (экземпляров) другой сущности предметной области, а значения которых позволяют отличить различные экземпляры одной сущности.
Создаваемая БД должна содержать необходимые структурные составляющие, обладающие свойством гибкости, то есть позволять вводить новые данные и изменять существующие.
Разрабатываемая база данных должна обеспечивать точную и достоверную информацию.
В АРМ входящей информацией является:
список группы;
сведения о студентах, их успеваемости;
сведения об активе учебной группы;
достижение группы;
потери контингента группы за время обучения.
Выходными данными будем считать информацию, необходимую для формирования банка данных рабочего места куратора группы, содержащего сведения о курируемой учебной группы.
2.1.1 Иерархия функций
К функциям оператора отнесем следующие:
ввод данных о группе, ее достижениях;
ввод сведений о студентах;
ввод сведений о потери контингента группы;
анализ отчета, составленного на основании таблиц, находящихся в базе данных.
К функциям администратора отнесем слежение за работоспособностью, функционированием всех элементов базы данных.
2.1.2 Формализованное описание предметной области
В процессе предпроектного исследования предметной области были выявлены следующие сущности (сущностью называют какой-либо объект предметной области, который имеет атрибуты): актив учебной группы, достижения учебной группы, потери контингента за период обучения, семья, социальный паспорт учащегося, список группы. Каждой семье соответствует несколько социальных паспортов учащихся. Каждой семье соответствует несколько записей в таблице - многодетная, полная, неполная.
Атрибутами сущности "Актив учебной группы" является: код, староста, заместитель старосты, физкультурно-спортивный сектор, культурно-массовый сектор, санитарно-бытовой сектор.
Атрибутами сущности "Достижения учебной группы" является: код, достижения первого полугодия, достижения второго полугодия.
сайт ресторан предметная область
Атрибутами сущности "Потери контингента за период обучения" является: код, дата отчисления, причина отчисления, отчисление по другим причинам (указать), ФИО.
Атрибутами сущности "Семья" является: семья, многодетная, полная, неполная.
Атрибутами сущности "Социальный паспорт учащегося" является: счетчик, № п/п, фамилия, имя, отчество, дата рождения, гражданство, домашний адрес, телефон, сведения о состоянии здоровья, семья, отец, мать, другие сведения, семейное положение, фото.
Атрибутами сущности "Список групп" является; счетчик, № п/п, фамилия, имя, отчество, контактный телефон.
Формализованное представление базы данных представлено в таблице 1.
Таблица 1 - Формализованное представление базы данных
Название сущности и ее свойства |
Ключ/ уникальный идентификатор |
Физические характеристики |
Логические ограничения |
Процессы |
|
Актив учебной группы |
|||||
Код |
УПК |
автоприращение |
›0 |
Вводится, просматривается |
|
Староста |
Строковый |
60 |
Вводится, просматривается, редактируется |
||
Заместитель старосты |
Строковый |
60 |
|||
Физкультурно-спортивный сектор |
Строковый |
60 |
|||
Культурно-массовый сектор |
Строковый |
60 |
|||
Санитарно-бытовой сектор |
Строковый |
60 |
|||
Достижения учебной группы |
|||||
Код |
УПК |
автоприращение |
›0 |
Вводится, просматривается |
|
1 полугодие |
Символы |
60 |
Вводится, просматривается, редактируется |
||
2 полугодие |
Символы |
60 |
|||
Потери контингента |
|||||
Код |
УПК |
автоприращение |
›0 |
Вводится, просматривается |
|
Дата отчисления |
9 |
Вводится, просматривается, редактируется |
|||
Причина отчисления |
Символы |
60 |
|||
По другим причинам (указать) |
Символы |
60 |
|||
ФИО |
Символы |
60 |
|||
Семья |
|||||
Семья |
УПК |
автоприращение |
›0 |
Вводится, просматривается |
|
Многодетная |
Символы |
60 |
Вводится, просматривается, редактируется |
||
Полная |
Символы |
60 |
|||
Неполная |
Символы |
60 |
|||
Социальный паспорт учащегося |
|||||
Счетчик |
УПК |
автоприращение |
›0 |
Вводится, просматривается |
|
№ п/п |
Символы |
60 |
Вводится, просматривается, редактируется |
||
Фамилия |
Символы |
60 |
|||
Имя |
Символы |
60 |
|||
Отчество |
Символы |
60 |
|||
Дата рождения |
Символы |
8 |
|||
Гражданство |
Символы |
50 |
|||
Домашний адрес |
Символы |
60 |
|||
Телефон |
Символы |
60 |
|||
Сведения о состоянии здоровья |
Символы |
60 |
|||
Код семьи |
целое |
Вводится, просматривается |
|||
Отец |
Символы |
60 |
Вводится, просматривается, редактируется |
||
Мать |
Символы |
60 |
|||
Другие сведения |
Символы |
60 |
|||
Семейное положение |
Символы |
60 |
|||
Фото |
Поле объекта OLE |
||||
Список группы |
|||||
Счетчик |
УПК |
автоприращение |
›0 |
Вводится, просматривается |
|
№ п/п |
Символы |
3 |
Вводится, просматривается, редактируется |
||
Фамилия |
Символы |
60 |
|||
Имя |
Символы |
60 |
|||
Отчество |
Символы |
60 |
|||
Контактный телефон |
Символы |
30 |
После определения основных сущностей и их свойств, определим связи между ними. Какие связи реализованы между сущностями разрабатываемой базы данных, видно из таблицы 2.
Таблица 2 - Связи объектов
Класс объектов связи |
Тип связи |
Опциональность связи |
||||
Р |
П |
Р |
П |
Р |
П |
|
Семья |
Социальный паспорт учащегося |
1 |
м |
Может |
должен |
2.2 Концептуальный уровень базы данных
Концептуальная модель является представлением точки зрения пользователя на предметную область и не зависит ни от программного обеспечения СУБД, ни от технических решений. Концептуальная схема является "сердцем" базы данных. Она поддерживает все внешние представления, а сама поддерживается средствами внутренней схемы. Однако внутренняя схема является всего лишь физическим воплощением концептуальной схемы. Именно концептуальная схема призвана быть полным и точным представлением требований к данным в рамках некоторой предметной области.
Концептуальное моделирование базы данных - это процесс конструирования модели использования информации. Этот процесс не зависит от таких подробностей, как используемая СУБД, прикладные программы, языки программирования или любые другие вопросы физической организации информации. Подобная модель называется концептуальной моделью данных.
На концептуальном уровне построения базы данных строится ER диаграмма.
2.2.1 Модель "объект - отношение"
Модели типа "Объект - Отношение" (ER-модель) относится к классам моделей данных, которые называются расширенными или семантическими моделями. Они позволяют включать сведения о смысловом значении данных, хранящейся в БД. С помощью этой модели строится инфологическая модель предметной области.
Основные преимущества ER-модели:
хорошая наглядность;
подобная модель позволяет проектировать БД с внушительным количеством атрибутов и объектов;
ER-модель реализована в большинстве современных систем для автоматизированного проектирования БД.
Основные элементы ER-моделей:
атрибуты объектов;
объекты (сущности);
связи между объектами.
Данная модель отражает классы, объекты и связи между ними, что позволяет заказчику отразить логику работы разрабатываемой базы данных.
Существует несколько методик построения ER-диаграмм. Наиболее известными являются диаграммы, построенные по методике Ричарда Баркера. Для сравнительного анализа так же была рассмотрена методика Мартина.
В нотации Баркера используется только один тип диаграмм - ER Сущность представляется прямоугольником любого размера, содержащим внутри себя имя сущности, список имен атрибутов (возможно, неполный) и указатели ключевых атрибутов (знак "#" перед именем атрибута). Все связи являются бинарными и представляются линиями с двумя концами (соединяющими сущности), для которых должно быть определено имя, степень множественности и степень обязательности. Для множественной связи линия присоединяется к прямоугольнику сущности в трех точках, а для одиночной связи - в одной точке. При обязательной связи рисуется непрерывная линия до середины связи, при необязательной - пунктирная линия.
В нотации Мартина основными элементами являются прямоугольники, содержащими внутри имя сущности, зависимая сущность отображается как прямоугольник в прямоугольнике. Список атрибутов приводится внутри прямоугольника, обозначающего сущность. Ключевые атрибуты подчеркиваются. Связи изображаются линиями, соединяющими сущности, вид линии в месте соединения с сущностью определяет кардинальность связи. Имя связи указывается на обозначающей ее линии.
Исходя из вышеперечисленного, можно утверждать, что наиболее удобной для использования в учебном процессе является методика построения ER-диаграммы по нотации Ричарда Баркера [4].
ER диаграмма нашей базы данных представлена на рисунке 2.
Рисунок 2 - ER-диаграмма базы данных АРМ
2.2.2 Даталогическая модель БД
Представим математическую запись даталогической модели нашей базы данных. Предлагаемый способ записи удобен для дальнейшей нормализации схем отношений:
актив учебной группы (код, староста, заместитель старосты, физкультурно-спортивный сектор, культурно-массовый сектор, санитарно-бытовой сектор);
достижения учебной группы (код, достижения первого полугодия, достижения второго полугодия);
потери контингента за период обучения (код, дата отчисления, причина отчисления, отчисление по другим причинам (указать), ФИО);
семья (код, многодетная, полная, неполная);
социальный паспорт учащегося (счетчик, № п/п, фамилия, имя, отчество, дата рождения, гражданство, домашний адрес, телефон, сведения о состоянии здоровья, семья, отец, мать, другие сведения, семейное положение, фото).
список групп (счетчик, № п/п, фамилия, имя, отчество, контактный телефон).
Более удобным считается графическое отображение даталогической модели базы данных (рисунок 3).
Рисунок 3 - Графическое изображение даталогической модели базы данных разрабатываемого АРМ.
2.2.3 Анализ схем отношений на соответствие нормальной формы Бойса - Кодда
Нормальная форма - свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение.
Процесс преобразования отношений базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры базы данных к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма БД. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации. Общее назначение процесса нормализации заключается в следующем:
исключение некоторых типов избыточности;
устранение некоторых аномалий обновления;
разработка проекта базы данных, который является достаточно "качественным" представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;
упрощение процедуры применения необходимых ограничений целостности.
Устранение избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов).
Существует метод постепенного перехода от универсального отношения, находящегося в первой нормальной форме (1НФ) к совокупности отношений, находящихся в нормальной форме Бойса-Кодда (НФБК). В этом методе отношения последовательно приводятся ко второй нормальной форме (2НФ), а затем к третьей (3НФ), и усиленной третьей нормальной форме или, как ее иначе называют, НФБК. НФ обладает свойством вложенности.
Для того чтобы воспользоваться этим методом, необходимо сначала определить первую, вторую и третью нормальные формы.
Схема находится в 1НФ если все значения атрибутов являются атомарными. Так как в разрабатываемой базе данных все значения атрибутов атомарны (фамилия, имя, отчество, статус и т.д.), то она соответствует 1НФ.
Определение 2НФ. Отношение находится во 2НФ, если оно находится в 1НФ, и каждый неключевой атрибут функционально полно зависит от составного ключа, то есть зависит от всего ключа и не зависит от его частей. Также можно утверждать, что наша база данных удовлетворяет этому условию.
Отношение находится в 3НФ тогда и только тогда, когда выполняются следующие условия:
отношение находится во второй нормальной форме;
каждый неключевой атрибут отношения находится в нетранзитивной (то есть прямой) зависимости от потенциального ключа.
Так в нашем случае отношения находятся во 2 НФ и прямой зависимости от ключевого поля, то говорим о том, что и этому условию наша база данных удовлетворяет.
Отношение находится в НФБК тогда и только тогда, когда каждая ее нетривиальная и неприводимая слева функциональная зависимость имеет в качестве своего детерминанта некоторый потенциальный ключ.
Это более строгая версия третьей нормальной формы, которая приобретает актуальность при наличии в отношении нескольких потенциальных ключей, хотя бы один из которых является составным. Если в отношении только один потенциальный ключ или все потенциальные ключи являются простыми (несоставными), то НФБК эквивалентна 3НФ, так как у нас все ключи являются простыми, то и это условие выполняется.
Таким образом, разрабатываемая база находится в 3НФБК, и можно предполагать, что она не содержит избыточных данных, а значит, при вводе или изменении данных не будет наблюдаться аномалий.
2.3 Физическая модель БД на основе выбранной СУБД
Компонентами физической модели данных являются таблицы, столбцы и отношения. Сущности логической модели станут таблицами в физической модели. Логические атрибуты станут столбцами. Логические отношения станут ограничениями целостности связей.
2.3.1 Описание проектируемых объектов БД
Рассмотрим каждый объект проектируемой системы, его атрибуты были представлены ранее, приведём наглядный пример таблиц данного объекта.
Типы и свойства полей таблицы "Актив учебной группы", разработанной в СУБД MS Access представлен на рисунке 4.
Рисунок 4 - Физическое представление таблицы "Актив учебной группы" в СУБД MS Access
Типы и свойства полей таблицы "Отделение" представлены в таблице 4.
Таблица 4 - Тип и свойство полей таблицы "Отделение"
Признак ключа |
Поле |
Тип поля |
Размер поля |
|
Ключ |
Код |
автоприращение |
›0 |
|
Староста |
Строковый |
60 |
||
Заместитель старосты |
Строковый |
60 |
||
Физкультурно-спортивный сектор |
Строковый |
60 |
||
Культурно-массовый сектор |
Строковый |
60 |
||
Санитарно-бытовой сектор |
Строковый |
60 |
Типы и свойства полей таблицы "Достижения учебной группы" разработанной в СУБД MS Access представлены на рисунке 5.
Рисунок 5 - Физическое представление таблицы "Достижения учебной группы", разработанной в СУБД MS Access
Типы и свойства полей таблицы "Достижения учебной группы" представлены в таблице 5.
Таблица 5 - Типы и свойства полей таблицы "Достижения учебной группы"
Признак ключа |
Поле |
Тип поля |
Размер поля |
|
Ключ |
Код |
автоприращение |
›0 |
|
1 полугодие |
Строковый |
60 |
||
2 полугодие |
Строковый |
60 |
Типы и свойства полей таблицы "Потери контингента за период обучения", разработанной в СУБД MS Access, представлен на рисунке 6.
Рисунок 6 - Физическое представление таблицы "Потери контингента за период обучения", разработанной в СУБД MS Access
Таблица 6 - Тип и свойства полей таблицы "Потери контингента за период обучения"
Признак ключа |
Поле |
Тип поля |
Размер поля |
|
Ключ |
Код |
автоприращение |
›0 |
|
Дата отчисления |
Строковый |
60 |
||
Причина отчисления |
Строковый |
60 |
||
По другим причинам (указать) |
Строковый |
60 |
||
ФИО |
Строковый |
60 |
Типы и свойства полей таблицы "Семья", разработанной в СУБД MS Access, представлены на рисунке 7.
Рисунок 7 - Физическое представление таблицы "Семья", разработанной в СУБД MS Access
Таблица 7 - Типы и свойства полей таблицы "Семья"
Признак ключа |
Поле |
Тип поля |
Размер поля |
|
Ключ |
Семья |
автоприращение |
›0 |
|
Многодетная |
Строковый |
60 |
||
Неполная |
Строковый |
60 |
||
Полная |
Строковый |
60 |
Типы и свойства полей таблицы "Социальный паспорт учащегося", разработанной в СУБД MS Access, представлен на рисунке 8.
Рисунок 8 - Физическое представление таблицы "Социальный паспорт учащегося", разработанный в СУБД MS Access
Таблица 8 - Типы и свойства полей таблицы "Социальный паспорт учащегося"
Признак ключа |
Поле |
Тип поля |
Размер поля |
|
Ключ |
Счетчик |
›0 |
||
№ п/п |
Строковый |
60 |
||
Фамилия |
Строковый |
60 |
||
Имя |
Строковый |
60 |
||
Отчество |
Строковый |
60 |
||
Дата рождения |
Строковый |
8 |
||
Гражданство |
Строковый |
50 |
||
Домашний адрес |
Строковый |
60 |
||
Телефон |
Строковый |
60 |
||
Сведения о состоянии здоровья |
Строковый |
60 |
||
Код семьи |
Целое |
|||
Отец |
Строковый |
60 |
||
Мать |
Строковый |
60 |
||
Другие сведения |
Строковый |
60 |
||
Семейное положение |
Строковый |
60 |
||
Фото |
Поле объекта OLE |
2.3.2 Технология создания базы данных
Доступ к базе данных в системе Delphi выполняется достаточно просто, с использованием богатого набора невизуальных компонентов работы СУБД. Как правило эти компоненты группируются в создаваемой программе в специальном модуле данных (TDataModule). Модуль данных представляет собой хранилище объектов, которое позволяет централизовано управлять их работой и отделяет программную логику, связанную с базой данных от программного кода, выполняющего вычислительные, поисковые и другие действия отображения данных на форме.
Для доступа к таблице базе данных Access используется компонент ADOConnection с панели компонентов ADO , к компоненту ADOConnection подключаем компонент ADOTable для каждой таблицы, используемой для работы в конкретной форме, а затем к нему подключаем компонент промежуточного уровня TDataSoure c панели DataAccess (доступ к данным). Этот компонент служит посредником между таблицами СУБД и экранными элементами управления.
В нашем случае было использовано не DataModule, а ADOTable и TDataSoure по конкретным формам. Каждый источник данных после размещения по конкретным формам связывается с конкретной таблицей с помощью свойства DataSet [6]. Соответственно, для каждой формы надо подготовить по одному из перечисленных компонентов, связать каждый из них со своей таблицей.
В нашем случае не используется DataModule, так как ADOTable и TDataSoure были размещены на конкретных формах.
Рисунок 9 - Компоненты на форме
На некоторых формах (за исключением главной), необходимо сделать отображения данных, хранимых в БД Access, в виде таблицы. Для этой цели используем компонент TDBGrid с панели DataControls (Элементы управления данными) (рисунок 10).
Рисунок 10 - Таблица с данными о списке группы
Для упрощения навигации по таблице, а так же по формам, где отображения в таблицы отсутствует (что немаловажно при наличии большого количества записей) в системе Delphi 7 имеется компонент TDBNavigator . Этот компонент размещается на форме под компонентом TDBGrid и привязывается к нему через свойство DataSoure. Значение этого свойства должно совпадать со значением такого же свойства связанной таблицы (рисунок 11).
Рисунок 11 - Размещение на форме присоединенного средства навигации
2.3.3 Реализация ограничения целостности базы данных
Создаваемая и эксплуатируемая реляционная база данных должна быть целостной и надежной. Правила поддержки ограничений целостности и надежности определяются используемой моделью данных и накладываются также предметной областью. Правила ограничения целостности описаны в физическом модуле БД и реализована средствами СУБД. Целостность данных - это поддержка точности и корректности данных, хранящихся в БД (рисунок 12).
Рисунок 12 - Ограничение целостности БД
2.4 Проектирование интерфейса АРМ
Проектирование интерфейса является важным этапом разработки АРМ, так как интерфейс является средством взаимодействия пользователя с программным средством.
Для создания интерфейса АРМ использовались визуальные компоненты панели Standart, additional и другие.
Основными компонентами использованными при создании интерфейса стали:
TLabel - используется для отображения текста в форме, которую нельзя изменять непосредственно через графический интерфейс пользователя;
TEdit - однострочное редактируемое текстовое поле, хранящее в себе текст, который можно помещать в данный компонент, как во время проектирования, так и во время выполнения программы;
TMemo - (Область просмотра) предназначен для вывода на экран нескольких строк текста;
ТChart - позволяет строить различные диаграммы и графики. В данном случае была построена линейная диаграмма;
ТDBGrid - компонент визуальных данных, в котором отражаются данные формы;
ТTimer - позволяет задавать в приложении интервалы времени;
Button - наиболее часто используемая кнопка, которая предназначена для выполнения какой-либо операции;
ADOConnection - используется для связи с набором данных ADO, может работать с несколькими компонентами наборов данных как диспетчер выполнение их команд;
ADOTable - используется для работы с одной таблицей. Может связываться с ней непосредственно, или через ADOConnection;
ADOQuery - используется для работы с набором данных с помощью запросов SQL, включая такие запросы языка DDL (datadefinitionlanguage), как Createtable. Может связываться с набором данных непосредственно или через ADOConnection.
Для проектирования ввода пароля были использованы элементы edit и button. Так же был использован алгоритм проверки правильности ввода данных, для входа в систему администрирования (рисунок 13).
Это сделано для того, чтобы обезопасить хранилище БД от несанкционированного доступа.
Рисунок 13 - Форма ввода пароля
После успешного ввода пароля появляется главное окно программы (рисунок 14). Основным элементом главной формы является компонент "Главное меню", позволяющий осуществлять необходимые действия.
Рисунок 14 - Главное окно программы
В данном окне программы в главном меню находится:
"Ввод данных личных данных студента";
"Просмотр и редактирование актива группы";
"Просмотр и редактирование списка группы";
"Просмотр и редактирование данных о потери контингента группы";
"Просмотр и редактирование данных о достижениях группы".
Рисунок 15 - Форма просмотра, редактирования сведений о студентах
Рисунок 16 - Форма просмотра, редактирования сведений об активе группы
Рисунок 17 - Форма просмотра, редактирования списка группы
Рисунок 18 - Форма просмотра, редактирования данных о потери контингента группы
Рисунок 19 - Форма просмотра, редактирования данных о достижениях группы
2.4.1 Требования к пользовательскому интерфейсу
Интерфейс автоматизированной подсистемы по графическим и дизайнерским решениям должен не нарушать установленные стандарты. То есть, выполнен в мягких не напрягающих зрение тонах, иметь дружественный и удобный интерфейс, иметь легкодоступное меню управления, другими словами, соблюдать все требования законов эргономики [7].
2.4.2 Создание справочной системы
Каждая программа должна обеспечивать пользователю доступ к справочной системе, содержащей исчерпывающую информацию о программе и о том, как с ней работать. Справочная система программ, работающих в Windows, в том числе и справочная система Delphi, представляет собой набор файлов определенной структуры, используя которые программа Winhelp, являющаяся составной частью Windows, выводит справочную информацию по запросу (требованию) пользователя.
Основным элементом справочной системы являются HLP-файлы, в которых находится справочная информация. В простейшем случае справочная система программы может представлять собой один единственный HLP-файл. Создать справочную систему (HLP-файл) можно, например, при помощи поставляемой вместе с Delphi программы MicrosoftHelpWorkshop. Исходным "материалом" для создания HLP-файла является текст справочной информации, представленный в виде RTF-файла.
Процесс создания справочной системы (HLP-файла) можно представить как последовательность следующих действий:
подготовка справочной информации (создание файла документа справочной информации);
преобразование файла справочной информации в файл справочной системы [8].
Рисунок 20 - Справочная система
2.5 Инсталляция АИС
Для инсталляции программного средства необходимо запустить исполняемый файл Auto_Installer_АРМ. exe. В появившемся диалоговом окне будет предложено подтвердить установку программы в указанную директорию, при необходимости укажите нужный вам путь установки и нажмите Install. После установки программы будет автоматически создан ярлык к ней на рабочем столе, а так же запущена сама программа, полностью готовая к работе.
2.6 Руководство пользователя
Запуск программы осуществляется с помощью файла с расширением Project1. exe, либо по ярлыку, размещенному на рабочем столе при инсталляции программы, после чего можно работать с программным модулем.
После запуска программы появится окно с предложением ввести учетные данные администратора, либо одного из зарегистрированных в системе пользователей. При успешной авторизации откроется главное окно программы, с которого будут доступны все формы для работы с данными.
Через главное меню главного окна программы можно закрыть программу, через меню "Открыть" и "Справочники" открыть необходимую форму и работать с данными, хранящимися в БД; вносить новые данные или править существующие.
Кнопка "Печать" выполняет функцию вывода отчета на печать. В данной АРМ отчет представляет собой данные о студентах и активе группы.
Заключение
Темой курсового проектирования являлась разработка автоматизированного рабочего места куратора учебной группы.
Основной задачей курсового проектирования было создание базы данных, и интерфейса взаимодействия пользователя с базой данных, где хранятся сведения об успеваемости группы.
Данное АРМ позволяет вводить, хранить и редактировать сведения о списке группы, сведения о студентах, их успеваемости, сведения об активе учебной группы, достижениях группы, потери контингента группы за время обучения. Выходными данными будем считать информацию, необходимую для формирования банка данных рабочего места куратора группы, содержащего сведения об успеваемости группы и повышения эффективности и качества работы куратора группы.
В результате проделанной работы по описанию предметной области была разработана концептуальная, а затем и реляционная модели БД. Разработанная АРМ отвечает всем требованиям предметной области.
База данных спроектирована с выполнением условий целостности, что позволяет говорить о том, что данные в базе не повторяются, не дублируют друг друга, что означает, что при внесении сведений в нее не будут возникать ошибки. В ходе тестирования были обнаружены недочеты программы, которые были устранены.
АРМ было разработано в среде программирования Delphi 7, с использованием базы данных MS Access.
В перспективе возможно обновление базы данных по мере обновления сведений о группе: ее контингента, успеваемости, достижениях и прочего, с учетом чего и была спроектирована программа.
Поставленная цель курсового проекта достигнута, задачи решены.
Список использованных источников
1. Архангельский, А.Я. Программирование вDelphi для Windows. Версии 2010, 2012, TurboDelphi / А.Я. Архангельский. - М.: Бином - Пресс, 2010. - 617 с. - ISBN 978-5-9518-0202-6.
2. Бобровский, С.И. Б72 Delphi 7: учебное пособие - СПб.: Питер, 2010. - 736 с. - ISBN 5-8046-0086-9.
3. Григорьев, А.Б. О чем не пишут в книгах по Delphi / А.Б. Григорьев - М.: БХВ-Петербург, 2010. - 623с. ISBN 978-5-9775-0190-3.
4. Могилев, А.В. Практикум по информатике: учебное пособие / А.В. Могилев. - М.: Академия, 2010. - 608с. - ISBN 978-5-7695-6591-5.
5. Сафонов, В.О. Основы современного программирования Delphi: учебное пособие / В.О. Сафонов. - М.: Бином - Пресс, 2011. - 583с. - ISBN 8-5-993-0495-0.
6. Фигурнов, В.Э. Delphi для разработчика / В.Э. Фигурнов. - М.: ИНФРА, 2011. - 408с. - ISBN 5-86225-471-4.
7. Фаронов, В.В. Программирование баз данных в Delphi 7: учебный курс / В.В. Фаронов. - СПб.: Питер, 2011. - 352 с. - ISBN 5-318-00100-9.
8. Гофман В. Delphi 7/Хоменко А., Гофман В., Мещеряков Е., Никифоров В. - М.: БХВ - Петербург, 2011. - 1216 с. - ISBN 5-9964-0168-8.
Приложения
Приложение А
(справочное)
Листинг программы
unit Unit8;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, Buttons, DB, ADODB, DBCtrls, ExtCtrls;
type
TForm8 = class (TForm)
Panel1: TPanel;
Label1: TLabel;
Label2: TLabel;
Edit1: TEdit;
DBLookupComboBox1: TDBLookupComboBox;
ADOConnection1: TADOConnection;
ADOTable1: TADOTable;
DataSource1: TDataSource;
BitBtn1: TBitBtn;
BitBtn2: TBitBtn;
Button1: TButton;
procedure BitBtn1Click (Sender: TObject);
procedure BitBtn2Click (Sender: TObject);
procedure Button1Click (Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form8: TForm8;
implementation
uses Unit1, Unit2;
{$R *. dfm}
procedure TForm8. BitBtn1Click (Sender: TObject);
begin
Application. Terminate;
end;
procedure TForm8. BitBtn2Click (Sender: TObject);
begin
if Edit1. Text=ADOTable1. FieldByName ('Пароль'). AsString then
begin
form8. Visible: =false;
form1. ShowModal;
form8. Close;
end
else
if Edit1. Text='' then
ShowMessage ('Введите пороль')
else
if Edit1. Text<>ADOTable1. FieldByName ('Пароль'). AsString then
ShowMessage ('Введенный пороль не верный');
end;
procedure TForm8. Button1Click (Sender: TObject);
begin
Messagedlg ('Введите Ваши имя пользователя и пароль! ',mtinformation, [mbOk],0);
end;
end.
unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, XPMan, Menus, ExtCtrls, StdCtrls, jpeg;
type
TForm1 = class (TForm)
MainMenu1: TMainMenu;
N1: TMenuItem;
N5: TMenuItem;
N7: TMenuItem;
XPManifest1: TXPManifest;
N2: TMenuItem;
N3: TMenuItem;
N10: TMenuItem;
N17: TMenuItem;
N18: TMenuItem;
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
procedure N3Click (Sender: TObject);
procedure N9Click (Sender: TObject);
procedure N10Click (Sender: TObject);
procedure N5Click (Sender: TObject);
procedure N6Click (Sender: TObject);
procedure N15Click (Sender: TObject);
procedure N16Click (Sender: TObject);
procedure N17Click (Sender: TObject);
procedure N18Click (Sender: TObject);
procedure N19Click (Sender: TObject);
procedure N20Click (Sender: TObject);
procedure N7Click (Sender: TObject);
procedure N4Click (Sender: TObject);
procedure N8Click (Sender: TObject);
procedure N13Click (Sender: TObject);
procedure N11Click (Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
uses Unit2, Unit3, Unit4, Unit9, Unit11, Unit13, Unit15, Unit17, Unit19,Unit21, Unit23, Unit25, Unit27, Unit29, Unit32;
{$R *. dfm}
procedure TForm1. N3Click (Sender: TObject);
begin
Form2. ShowModal;
end;
procedure TForm1. N9Click (Sender: TObject);
begin
Form3. ShowModal;
end;
procedure TForm1. N10Click (Sender: TObject);
begin
Form1. Close;
end;
procedure TForm1. N5Click (Sender: TObject);
begin
Form4. ShowModal;
end;
procedure TForm1. N6Click (Sender: TObject);
begin
Form9. ShowModal;
end;
procedure TForm1. N15Click (Sender: TObject);
begin
Form11. ShowModal;
end;
procedure TForm1. N16Click (Sender: TObject);
begin
form13. showModal;
end;
procedure TForm1. N17Click (Sender: TObject);
begin
Form15. ShowModal;
end;
procedure TForm1. N18Click (Sender: TObject);
begin
Form17. ShowModal;
end;
procedure TForm1. N19Click (Sender: TObject);
begin
Form19. ShowModal;
end;
procedure TForm1. N20Click (Sender: TObject);
begin
Form21. ShowModal;
end;
procedure TForm1. N7Click (Sender: TObject);
begin
Form23. ShowModal;
end;
procedure TForm1. N4Click (Sender: TObject);
begin
Form25. ShowModal;
end;
procedure TForm1. N8Click (Sender: TObject);
begin
Form27. ShowModal;
end;
procedure TForm1. N13Click (Sender: TObject);
begin
Form29. ShowModal;
end;
procedure TForm1. N11Click (Sender: TObject);
begin
Form32. ShowModal;
end;
end.
unit Unit15;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, DB, ADODB, DBCtrls, Mask, ExtCtrls, Buttons;
type
TForm15 = class (TForm)
Panel1: TPanel;
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
Label4: TLabel;
DataSource1: TDataSource;
DBEdit1: TDBEdit;
DBEdit2: TDBEdit;
DBEdit3: TDBEdit;
DBComboBox1: TDBComboBox;
ADOTable1: TADOTable;
ADOConnection1: TADOConnection;
GroupBox1: TGroupBox;
BitBtn1: TBitBtn;
BitBtn2: TBitBtn;
BitBtn3: TBitBtn;
BitBtn4: TBitBtn;
DBNavigator1: TDBNavigator;
procedure BitBtn1Click (Sender: TObject);
procedure BitBtn2Click (Sender: TObject);
procedure BitBtn4Click (Sender: TObject);
procedure BitBtn3Click (Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form15: TForm15;
implementation
uses Unit16;
{$R *. dfm}
procedure TForm15. BitBtn1Click (Sender: TObject);
begin
Form15. Close;
end;
procedure TForm15. BitBtn2Click (Sender: TObject);
begin
if MessageDlg ('Удалить текущую запись? '
,mtConfirmation, [mbYes, mbNo],0) = idYes
then
Form15. ADOTable1. Delete;
end;
procedure TForm15. BitBtn4Click (Sender: TObject);
begin
if MessageDlg ('Сохранить измененя? '
,mtConfirmation, [mbYes, mbNo],0) = idYes
then
begin
Form15. ADOTable1. Edit ();
Form15. ADOTable1. Post ();
end;
end;
procedure TForm15. BitBtn3Click (Sender: TObject);
begin
if MessageDlg ('Добавить новую запись? '
,mtConfirmation, [mbYes, mbNo],0) = idYes
then
begin
Form15. ADOTable1. Insert ();
form16. ShowModal;
end;
end;
end.
unit Unit17;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, DBCtrls, StdCtrls, DB, Grids, DBGrids, ADODB, ExtCtrls, Buttons;
type
TForm17 = class (TForm)
Panel1: TPanel;
ADOConnection1: TADOConnection;
ADOTable1: TADOTable;
DataSource1: TDataSource;
GroupBox1: TGroupBox;
DBGrid1: TDBGrid;
ADOTable1DSDesigner: TAutoIncField;
ADOTable1DSDesigner1: TWideStringField;
ADOTable1DSDesigner2: TWideStringField;
Label1: TLabel;
DBNavigator1: TDBNavigator;
BitBtn1: TBitBtn;
BitBtn2: TBitBtn;
BitBtn3: TBitBtn;
BitBtn4: TBitBtn;
procedure BitBtn1Click (Sender: TObject);
procedure BitBtn2Click (Sender: TObject);
procedure BitBtn3Click (Sender: TObject);
procedure BitBtn4Click (Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form17: TForm17;
implementation
uses Unit18;
{$R *. dfm}
procedure TForm17. BitBtn1Click (Sender: TObject);
begin
Form17. Close;
end;
procedure TForm17. BitBtn2Click (Sender: TObject);
begin
if MessageDlg ('Удалить текущую запись? '
,mtConfirmation, [mbYes, mbNo],0) = idYes
then
Form17. ADOTable1. Delete;
end;
procedure TForm17. BitBtn3Click (Sender: TObject);
begin
if MessageDlg ('Добавить новую запись? '
,mtConfirmation, [mbYes, mbNo],0) = idYes
then
begin
Form17. ADOTable1. Insert ();
form18. ShowModal;
end;
end;
procedure TForm17. BitBtn4Click (Sender: TObject);
begin
if MessageDlg ('Сохранить измененя? '
,mtConfirmation, [mbYes, mbNo],0) = idYes
then
begin
Form17. ADOTable1. Edit ();
Form17. ADOTable1. Post ();
end;
end;
end.
unit Unit2;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, DB, ADODB, Grids, DBGrids, ExtCtrls, StdCtrls, Buttons, DBCtrls;
type
TForm2 = class (TForm)
Panel1: TPanel;
DBGrid1: TDBGrid;
ADOConnection1: TADOConnection;
DataSource1: TDataSource;
ADOTable1: TADOTable;
ADOTable1DSDesigner2: TWideStringField;
ADOTable1DSDesigner3: TWideStringField;
ADOTable1DSDesigner4: TWideStringField;
ADOTable1DSDesigner5: TIntegerField;
GroupBox1: TGroupBox;
BitBtn1: TBitBtn;
BitBtn2: TBitBtn;
BitBtn3: TBitBtn;
BitBtn4: TBitBtn;
DBNavigator1: TDBNavigator;
procedure BitBtn4Click (Sender: TObject);
procedure BitBtn3Click (Sender: TObject);
procedure BitBtn2Click (Sender: TObject);
procedure BitBtn1Click (Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form2: TForm2;
implementation
uses Unit6;
{$R *. dfm}
procedure TForm2. BitBtn4Click (Sender: TObject);
begin
if MessageDlg ('Сохранить измененя? '
,mtConfirmation, [mbYes, mbNo],0) = idYes
then
begin
Form2. ADOTable1. Edit ();
Form2. ADOTable1. Post ();
// form2. ADOTable1. Sort: ='Код';
end;
end;
procedure TForm2. BitBtn3Click (Sender: TObject);
begin
if MessageDlg ('Добавить новую запись? '
,mtConfirmation, [mbYes, mbNo],0) = idYes
then
begin
Form2. ADOTable1. Insert ();
Form6. ShowModal;
end;
end;
procedure TForm2. BitBtn2Click (Sender: TObject);
begin
if MessageDlg ('Удалить текущую запись? '
,mtConfirmation, [mbYes, mbNo],0) = idYes
then
Form2. ADOTable1. Delete;
end;
procedure TForm2. BitBtn1Click (Sender: TObject);
begin
Form2. Close;
end;
end.
unit Unit23;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, Buttons, Mask, DBCtrls, ExtCtrls, DB, ADODB;
type
TForm23 = class (TForm)
ADOConnection1: TADOConnection;
ADOTable1: TADOTable;
DataSource1: TDataSource;
Panel1: TPanel;
Label1: TLabel;
Label2: TLabel;
Label3: TLabel;
Label8: TLabel;
Label10: TLabel;
Label12: TLabel;
Label15: TLabel;
GroupBox1: TGroupBox;
DBNavigator1: TDBNavigator;
BitBtn1: TBitBtn;
BitBtn2: TBitBtn;
BitBtn3: TBitBtn;
BitBtn4: TBitBtn;
DBEdit1: TDBEdit;
DBEdit2: TDBEdit;
DBEdit7: TDBEdit;
DBEdit9: TDBEdit;
DBEdit11: TDBEdit;
Button1: TButton;
procedure BitBtn4Click (Sender: TObject);
procedure BitBtn3Click (Sender: TObject);
procedure BitBtn2Click (Sender: TObject);
procedure BitBtn1Click (Sender: TObject);
procedure Button1Click (Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form23: TForm23;
implementation
uses Unit24, Unit34;
{$R *. dfm}
procedure TForm23. BitBtn4Click (Sender: TObject);
begin
if MessageDlg ('Сохранить измененя? '
,mtConfirmation, [mbYes, mbNo],0) = idYes
then
begin
Form23. ADOTable1. Edit ();
Form23. ADOTable1. Post ();
end;
end;
procedure TForm23. BitBtn3Click (Sender: TObject);
begin
if MessageDlg ('Добавить новую запись? '
,mtConfirmation, [mbYes, mbNo],0) = idYes
then
begin
Form23. ADOTable1. Insert ();
end;
end;
procedure TForm23. BitBtn2Click (Sender: TObject);
begin
if MessageDlg ('Удалить текущую запись? '
,mtConfirmation, [mbYes, mbNo],0) = idYes
then
Form23. ADOTable1. Delete;
end;
procedure TForm23. BitBtn1Click (Sender: TObject);
begin
Form23. Close;
end;
procedure TForm23. Button1Click (Sender: TObject);
begin
// Form34. QuickRep1. PreviewModal;
end;
end.
unit Unit4;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, DB, ADODB, StdCtrls, Mask, DBCtrls, ExtCtrls, Grids, DBGrids,
Buttons, ExtDlgs, OleCtnrs;
type
TForm4 = class (TForm)
Label1: TLabel;
Panel1: TPanel;
Label2: TLabel;
DBEdit1: TDBEdit;
Label3: TLabel;
DBEdit2: TDBEdit;
Label4: TLabel;
DBEdit3: TDBEdit;
Label5: TLabel;
DBEdit4: TDBEdit;
Label6: TLabel;
DBEdit5: TDBEdit;
Label8: TLabel;
DBEdit7: TDBEdit;
Label9: TLabel;
DBEdit8: TDBEdit;
Label10: TLabel;
Label11: TLabel;
DBEdit9: TDBEdit;
DBComboBox1: TDBComboBox;
Label13: TLabel;
DBComboBox2: TDBComboBox;
GroupBox1: TGroupBox;
BitBtn1: TBitBtn;
BitBtn4: TBitBtn;
BitBtn3: TBitBtn;
BitBtn2: TBitBtn;
DBNavigator1: TDBNavigator;
Label14: TLabel;
DBEdit11: TDBEdit;
Label15: TLabel;
DBEdit12: TDBEdit;
OpenPictureDialog1: TOpenPictureDialog;
BitBtn5: TBitBtn;
DBImage1: TDBImage;
Button1: TButton;
DataSource1: TDataSource;
ADOTable1: TADOTable;
ADOConnection1: TADOConnection;
procedure BitBtn1Click (Sender: TObject);
procedure BitBtn2Click (Sender: TObject);
procedure BitBtn3Click (Sender: TObject);
procedure BitBtn4Click (Sender: TObject);
procedure BitBtn5Click (Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form4: TForm4;
implementation
uses Unit5, Unit31;
{$R *. dfm}
procedure TForm4. BitBtn1Click (Sender: TObject);
begin
Form4. Close;
end;
procedure TForm4. BitBtn2Click (Sender: TObject);
begin
begin
if MessageDlg ('Сохранить измененя? '
,mtConfirmation, [mbYes, mbNo],0) = idYes
then
begin
Form4. ADOTable1. Edit ();
Form4. ADOTable1. Post ();
end;
end;
end;
procedure TForm4. BitBtn3Click (Sender: TObject);
Подобные документы
Актуальность создания фирменного web-сайта. Разработка, внедрение web-сайта под названием "Удачная постройка". Анализ существующих программных решений, выбор инструментальных средств разработки. Архитектура сайта, структура данных. Тестирование и отладка.
дипломная работа [4,7 M], добавлен 19.01.2017Cоздание WEB-сайта для ООО "Сельинвест", способного представлять текстовую и графическую информацию пользователю, осуществлять доступ к базе данных и файлам для получения интересующей информации. Модель предметной области и инфологическая модель сайта.
дипломная работа [1,3 M], добавлен 21.09.2012Теоретические исследования алгоритма создания веб-сайта студии звукозаписи для увеличения количества потенциальных клиентов на платформе php и mysql. Выбор инструментальных средств, разработка структуры базы данных, технология проектирования веб-сайта.
курсовая работа [5,4 M], добавлен 25.01.2013Анализ предметной области и функций сайта. Разработка структуры базы данных, структуры и дизайна web-сайта. Описание установки CMS "Joomla!" и программной оболочки Denwer, создание гостевой книги, галереи и карты Google, результаты их тестирования.
дипломная работа [2,3 M], добавлен 19.01.2017Выбор инструментальных и программных средств для создания сайта. Структура программного продукта. Создание сайта при помощи программы WordPress. Тестирование разработанной программы. Разработка структуры и дизайна сайта. Наполнение сайта контентом.
курсовая работа [1,0 M], добавлен 09.01.2014Основы моделирования и разработки Web-сайтов. Обзор и сравнительный анализ языков программирования. Фреймворки, используемые при создании сайта. Разработка графического дизайна, моделирование и создание Web-сайта, руководство по администрированию.
курсовая работа [1,7 M], добавлен 07.11.2013Технологии и методы создания сайта для офиса рекламного агентства "Рона" в соответствии с деятельностью всей организации. Выбор инструментальных программных средств. Структура программного продукта Web–сайта. Функциональные возможности разделов.
курсовая работа [1,5 M], добавлен 30.12.2014Создание программы, осуществляющей хранение информации о Ресторане. Структура предприятия, нормализация отношений. Разработка пользовательского интерфейса базы данных "АРМ администратора ресторана" в Borland Delphi 7. Характеристики для поиска данных.
курсовая работа [835,5 K], добавлен 18.06.2015Разработка Web-сайта с подключенной к нему базой данных для управления пользователями, их авторизацией и регистрацией. Подключение базы данных к сайту. Использование технологии AJAX. Виды SQL инъекций и способы защиты базы данных от попыток взлома.
дипломная работа [2,9 M], добавлен 13.02.2016Изучение теоретических основ создания сайта. Выбор инструментальных и программных средств для создания сайта кафедры; разработка структуры и дизайна, программной документации; напыление контентом. Расчет себестоимости, затрат на внедрение и эксплуатацию.
дипломная работа [1,3 M], добавлен 24.09.2015