Разработка сайта для ресторана 'МАО'
Министерство образования и науки
Российской Федерации
Федеральное государственное бюджетное
образовательное учреждение
высшего профессионального образования
"Оренбургский государственный
университет"
Индустриально-педагогический колледж
Отделение автоматизации
информационных и технологических процессов
Курсовой проект
по дисциплине "Разработка и
эксплуатация автоматизированной информационной системы "
Разработка сайта для ресторана
"МАО"
ИПК ОГУ 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.6 Обзор
обоснования выбора инструментальных средств
Для разработки приложения было выбрано следующее ПО: СУБД (система
управления базами данных) MS Access и система программирования Delphi.
База данных - это совокупность записей различного типа,
содержащая перекрестные ссылки.
СУБД - это комплекс языковых и программных средств,
предназначенный для создания, ведения и совместного использования БД многими
пользователями.
В стандартную поставку Delphi входят основные объекты из 270
базовых классов (рисунок 1), при этом основным достоинством системы является
простота создания графического интерфейса программы. Создание интерфейса
реализуется методом draganddrop (бери и тащи), что делает процесс создания интерфейса
простым и быстрым, требующим минимального написания программного кода [2].
1.7 Обзор
обоснования методов защиты данных
К настоящему времени разработано много различных средств,
методов, мер и мероприятий, предназначенных для защиты информации,
накапливаемой, хранимой и обрабатываемой в автоматизированных информационных
системах.
Сюда входят аппаратные и программные средства,
криптографическое закрытие информации, физические меры, организованные
мероприятия, законодательные меры.
Все эти средства защиты делятся на технические и
нетехнические.
К техническим средствам защиты относят:
аппаратные и программные средства;
криптографическое закрытие информации.
К нетехническим средствам защиты относят:
аппаратные методы защиты;
программные методы защиты;
резервное копирование;
криптографическое шифрование информации;
физические меры защиты.
организационные мероприятия по защите информации.
Основные выводы о способах использования рассмотренных выше
средств, методов и мероприятий защиты, сводится к следующему:
наибольший эффект достигается тогда, когда все используемые
средства, методы и мероприятия объединяются в единый, целостный механизм защиты
информации;
механизм защиты должен проектироваться параллельно с
созданием систем обработки данных, начиная с момента выработки общего замысла
построения системы;
функционирование механизма защиты должно планироваться и обеспечиваться
наряду с планированием и обеспечением основных процессов автоматизированной
обработки информации;
необходимо осуществлять постоянный контроль функционирования
механизма защиты.
В данном АРМ применен программный метод защиты. К программным
средствам защиты относятся специальные программы, которые предназначены для
выполнения функций защиты и включаются в состав программного обеспечения систем
обработки данных [3].
Программная защита является наиболее распространенным видом
защиты, чему способствуют следующие положительные свойства:
универсальность;
гибкость;
простота реализации;
практически неограниченные возможности изменения и развития и
т.п.
2. Проектная
часть
2.1 Анализ
предметной области
Во время предпроектного исследования было составлено описание
предметной области решаемой задачи.
Основная задача состоит в сборе информации о деятельности
куратора учебной группы. Для решения этой задачи разрабатывается
автоматизированное рабочее место, целью которого является экономия рабочего
времени и переход на безбумажные технологии.
Предметная область - фрагмент реального мира, подлежащий
автоматизации. Предметная область содержит только те сущности, их взаимосвязи и
процессы изменения сущностей и взаимосвязей, которые необходимы для корректной
работы рассматриваемой (разрабатываемой) автоматизированной системы. Сущностью
или информационным объектом предметной области называется некоторое понятие,
общее для ряда объектов реального мира. Сущность описывается набором признаков,
важных для рассматриваемой предметной области, состав которых позволяет
отделить объекты (экземпляры) одной сущности от объектов (экземпляров) другой
сущности предметной области, а значения которых позволяют отличить различные
экземпляры одной сущности.
Создаваемая БД должна содержать необходимые структурные
составляющие, обладающие свойством гибкости, то есть позволять вводить новые
данные и изменять существующие.
Разрабатываемая база данных должна обеспечивать точную и
достоверную информацию.
В АРМ входящей информацией является:
список группы;
сведения о студентах, их успеваемости;
сведения об активе учебной группы;
достижение группы;
потери контингента группы за время обучения.
Выходными данными будем считать информацию, необходимую для
формирования банка данных рабочего места куратора группы, содержащего сведения
о курируемой учебной группы.
.1.1 Иерархия
функций
К функциям оператора отнесем следующие:
ввод данных о группе, ее достижениях;
ввод сведений о студентах;
ввод сведений о потери контингента группы;
анализ отчета, составленного на основании таблиц, находящихся
в базе данных.
К функциям администратора отнесем слежение за
работоспособностью, функционированием всех элементов базы данных.
2.1.2
Формализованное описание предметной области
В процессе предпроектного исследования предметной области
были выявлены следующие сущности (сущностью называют какой-либо объект
предметной области, который имеет атрибуты): актив учебной группы, достижения
учебной группы, потери контингента за период обучения, семья, социальный
паспорт учащегося, список группы. Каждой семье соответствует несколько
социальных паспортов учащихся. Каждой семье соответствует несколько записей в
таблице - многодетная, полная, неполная.
Атрибутами сущности "Актив учебной группы"
является: код, староста, заместитель старосты, физкультурно-спортивный сектор,
культурно-массовый сектор, санитарно-бытовой сектор.
Атрибутами сущности "Достижения учебной группы"
является: код, достижения первого полугодия, достижения второго полугодия.
сайт ресторан предметная область
Атрибутами сущности "Потери контингента за период
обучения" является: код, дата отчисления, причина отчисления, отчисление
по другим причинам (указать), ФИО.
Атрибутами сущности "Семья" является: семья,
многодетная, полная, неполная.
Атрибутами сущности "Социальный паспорт учащегося"
является: счетчик, № п/п, фамилия, имя, отчество, дата рождения, гражданство,
домашний адрес, телефон, сведения о состоянии здоровья, семья, отец, мать,
другие сведения, семейное положение, фото.
Атрибутами сущности "Список групп" является;
счетчик, № п/п, фамилия, имя, отчество, контактный телефон.
Формализованное представление базы данных представлено в
таблице 1.
Таблица 1 - Формализованное представление базы данных
|
Название
сущности и ее свойства
|
Ключ/
уникальный идентификатор
|
Физические
характеристики
|
Логические
ограничения
|
Процессы
|
|
Актив
учебной группы
|
|
|
|
|
|
Код
|
УПК
|
автоприращение
|
›0
|
Вводится,
просматривается
|
|
Староста
|
|
Строковый
|
Вводится,
просматривается, редактируется
|
|
Заместитель
старосты
|
|
Строковый
|
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-диаграммы по нотации
Ричарда Баркера [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
|
Типы и свойства полей таблицы "Социальный паспорт
учащегося", разработанной в СУБД 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 -