База данных «Грузоперевозки»

Курсовая работа

интерфейс информационный грузоперевозка

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

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

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

Для разработки базы данных «Грузоперевозки» можно выбрать MicrosoftAccess, BorlandDelphi, SQL.

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

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

1. Анализ предметной области. Постановка задачи

Грузоперевозки — одна из нужных услуг в повседневной жизни.

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

Основные функции грузоперевозок:

1. Легко и быстро принять заказ.

2. Оказание качественной работы по перевозки груза.

3. Загрузка и разгрузка.

В данной курсовой работе рассматривается задачи, выполняемые диспетчерами компании грузоперевозок. Данная информационная система обеспечивает: хранение информации и клиентах, водителях, грузе, автомобилях, дате заказа и маршруте.

8 стр., 3828 слов

Курсовая работа реляционные базы данных и субд

... модели данных СУБД разделяют на иерархические, сетевые, реляционные, объектно-ориентированные и др. Некоторые СУБД могут одновременно поддерживать несколько моделей данных. Для работы с данными, хранящимися в базе, ... задачи: изучить теоретический материал по видам СУБД; выполнить расчет ведомости продаж. Для оформления курсовой работы использован пакет прикладных программ MicrosoftOffice и ...

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

Постановка задачи

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

В БД будут храниться сведения о:

Сотрудниках: ФИО,

Автомобилях: Марка, габариты, тоннаж.

Заказах: ФИО клиента, ФИО водителя, марка авто, тип груза, маршрут.

Клиентах: ФИО, паспортные данные, телефон, адрес.

Грузе: Тип груза, габариты.

Диспетчеры могут вносить следующие изменения в БД:

  • Добавление, удаление нового клиента
  • Добавление изменение нового водителя
  • Оформление нового заказа
  • Вносить изменения связанные с заказом

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

2. Техническое задание на разработку базы данных составленное в соответствии с ГОСТ34.602

1. Введение

1.1 Наименование программы

Наименование программы: «База данных Грузоперевозки».

1.2 Краткая характеристика области применения

База данных предназначена для организации деятельности компании грузоперевозок.

1.3 Условные обозначения и сокращения

БД — База данных;

ТЗ — Техническое задание

СУБД-Система управления базой данных

2. Основания для разработки

Основанием для разработки БД является задание на курсовое проектирование по междисциплинарному курсу МДК.02.02 «Технология разработки и защиты баз данных», выданное 19 февраля 2015 года. преподавателем КарауловойВ.И.

2.1 Наименование и условное обозначение темы разработки

Наименование темы разработки — Разработка БД «Грузоперевозки»

3. Назначение разработки

3.1 Функциональное назначение

Функциональное назначением БД является информационное обеспечение сотрудников

Компании грузоперевозок о клиентах, водителях, заказах и дате их выполнения.

4. Требования к программе или программному изделию

4.1 Требования к функциональным характеристикам

Требования к составу выполненных функций

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

1. Учет контактной информации о сотрудниках

2. Ввод, редактирование, просмотр информации о клиентах

3. Поиск информации:

  • По «ФИО клиента»
  • По «Дате заказа»
  • По «Маршруту»

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

4.1.2 Требования к организации входных данных. Входные данные представлены в ниже перечисленных таблицах:

Ввод входных данных осуществляется символами кириллицы.

4.1.3 Требования к организации выходных данных

27 стр., 13067 слов

Разработка информационной системы учета товаров на оптовом складе

... баз данных вести весь документооборот, касающийся складского учета вести ... информации решает задачу автоматизации процессов работы оптового склада. 3.3 Цель системы Задачу автоматизации склада можно разбить на подзадачи: 1) Учет приходящих товаров. 2) Учет количества товара на складе. 3) Учёт ... данных (поставщики, покупатели, товары) получение отчетов по запросам к базе данных. 3.4.2 Требования ...

Выходные данные соответствуют входным данным. Просмотр выходных данных осуществляется на мониторе и должен отображается в виде таблицы.

Формат полей соответствует формату идентичных входным данным.

Таблица 1_Клиенты

Клиенты

Тип

Размер

Описание параметра

Фамилия

Текстовый

30

Имя

Текстовый

30

Отчество

Текстовый

30

Адрес клиента

Текстовый

50

Телефон

Числовой

11

Расчетный счет

Текстовый

30

Паспорт

Текстовый

30

Таблица 2_Автомобили

Автомобиль

Тип

Размер

Описание параметра

Марка

Справочник

30

Ссылка на элемент справочника МаркаАвто

Тоннаж

Текстовый

30

Габариты

Текстовый

30

Ссылка на элемент справочника Габариты

ГосНомер

Текстовый

10

Ссылка на элемент справочника ГосНомер

Таблица 3_Водители

Водители

Тип

Размер

Описание параметра

Фамилия

Текстовый

30

Имя

Текстовый

30

Отчество

Текстовый

30

НомерВодПрав

Числовой

11

Категория

Справочник

Ссылка на элемент справочника Категории

Страховой полис

Числовой

11

Таблица 4_Заказ

Заказ

Тип

Размер

Описание параметра

ФИО клиента

Текстовый

30

Хранение списка клиентов

Тип Груза

Справочник

Ссылка на элемент справочник Тип груза

Тоннаж Груза

Текстовый

10

Габариты Груза

Текстовый

15

Марка Авто

Справочник

30

Ссылка на элемент справочника Марка Авто

Гос Номер

Текстовый

15

Ссылка на элемент справочника ГосНомер

Водитель

Справочник

20

Ссылка на элемент справочника Водители

Дата Заказа

Дата / Время

Маршрут

Справочник

20

Ссылка на элемент справочника Маршрут

Справочники

Таблица 5_Маркаавто

Название параметра

Тип

Размер

Описание параметра

МаркаАвто

Текстовый

30

Хранение списка марка авто

Таблица 6_ТипГруза

Название параметра

Тип

Размер

Описание параметра

Тип Груза

Текстовый

30

Хранение списка тип груза

Таблица 7_Категории

Название параметра

Тип

Размер

Описание параметра

Категории

Текстовый

30

Хранение списка категории

Таблица 8_Маршрут

Название параметра

Тип

Размер

Описание параметра

Маршрут

Текстовый

30

Хранение списка маршрут

Таблица 9_ТоннажАвто

Название параметра

Тип

Размер

Описание параметра

ТоннажАвто

Текстовый

30

Хранение списка Тоннаж Авто

4.1.4 Требование к временным характеристикам

Требования к временным характеристикам БД не предъявляются.

4.2 Требования к надежности

4.2.1 Требования к обеспечению надежного (устойчивого) функционирования программы

Надежное функционирование БД должно быть обеспечено сотрудниками компании грузоперевозок и сотрудником компьютерного отдела:

1) Своевременным ведение БД;

2) Организацией бесперебойного питания серверного и коммуникационного оборудования;

3) Использованием лицензионного программного обеспечения.

4.2.2 Время восстановление после отказа

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

4.2.3 Отказы из-за некорректных действий оператора

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

4.3 Условия эксплуатации

4.3.1 Климатические условия эксплуатации

Требования не предъявляются

4.3.2 Требования к видам обслуживания

Обслуживание БД включает в себя:

1) информационное обслуживание — ввод и редактирование информации БД;

2) системное администрирование БД «Грузоперевозки»

4.3.3 Требование к численности персонала

Минимальное количество персонала, требуемое для нормального функционирования, должно составлять не менее 1 человека.

4.4 Требования к параметру и составу технических средств

Минимальные аппаратные требования:

  • Процессор Intel совместимый, тактовая частота не ниже 500 MHz;
  • Объем свободной оперативной памяти — не менее 512 Мб;
  • Не менее 1 ГБ свободного дискового пространства;
  • Клавиатура;
  • Мышь;
  • Монитор с минимальным разрешением — 800х600 пикселей;
  • Принтер.

4.5 Требования к информационной и программной совместимости

4.5.1 Требования к информационным структурам и методам решения

Проектирование структуры БД должно быть выполнено в рамках разработки технического проекта.

4.5.2 Требования к программным средствам, используемым программой

Система должна работать под управлением ОС Windows (все).

4.6 Требования к защите информации и программ

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

4.7 Требования к упаковке и маркировке

Особые требования не предъявляются.

4.8 Специальные требования

4.8.1 Требования к пользовательскому интерфейсу

Интерфейс должен быть понятным для пользователя.

4.8.2 Требования к архивированию и резервному копированию данных

5. Требования к программной документации

5.1 Предварительный состав программной документации

Состав программной документации должен включать:

Руководство программиста ГОСТ 19.504-79. ЕСПД.

3. Выбор средств / методологии проектирования. Выбор СУБД

В настоящее время для проектирования информационных систем используют 2 подхода:

  • Структурное (функциональное проектирование);
  • Объектно-ориентированный подход к проектированию.

Структурный подход традиционно используется для моделирования организационных систем (бизнес-процессов).

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

  • ФункциональнаямодельSADT (Structured Analysis and Design Technique)
  • Модель IDEF 3;
  • МодельDFD (DataFlowDiagrams) — диаграмма потов данных.

SADT модель может ориентироваться по функции системы (функциональная модель) и объектов системы (модель данных).

Достоинствами применения моделей SADT для описания бизнес-процессов являются:

  • Полнота описания бизнес-процессов;
  • Жесткие требования метода;
  • Соответствие подхода к описанию процессов стандартам.

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

Метод IDEF 3 предназначен для таких моделей процессов, в которых важно понять последовательность выполнения действий и взаимозависимость между ними.

Основой модели IDEF 3 служит сценарий процесса, который выделяет последовательность действий и процессов анализируемой системы.

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

Наиболее распространенным средством моделирования данных является модель «сущность-связь». Она традиционно используется в структурном анализе и проектировании и представляет собой подмножество объектной модели предметной области. Здесь чаще всего используется метод IDEF 1x.

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

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

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

Так, например, после выполнения структурного анализа бизнес-процесса иногда переходят к разработке классов и объектов.

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

4. Инфологическая (концептуальная) модель базы данных

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

Для этого осуществляются следующие мероприятия:

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

В соответствии с анализом предметной области см стр. 3 и в соответствии с ТЗ пункт № 4.1.2 и 4.1.3 (входные выходные данные) составлена концептуальная модель схема 1 см. Приложение Б).

Концептуальная модель построена с помощью программы StarUML.

StarUML — программный инструмент моделирования, который поддерживает UML (Унифицированный язык моделирования).

StarUMLориентирован на UML версии 1.4 и поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0. Он активно поддерживает подход MDA (Модельно-управляемая архитектура), реализуя концепцию профилей UML. Среда разработки StarUML превосходно настраивается в соответствии с требованиями пользователя и имеет высокую степень расширяемости, особенно в области своих функциональных возможностей.

В UML выделяют 9 диаграмм: диаграмма классов, диаграмма объектов, диаграмма последовательностей, диаграмма прецедентов, диаграмма кооперации, диаграмма состояний, диаграмма действий, диаграмма компонентов, диаграмма развертывания.

Рисунок 1 — Главная форма StarUML

1. Меню программы;

2. Рабочая диаграмма;

3. Инструменты;

4. Проводник;

5. Редактор;

6. Рабочее поле.

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

На диаграмме прецедентов представлены прецеденты и актеры, а также отношения между ними. Используются для моделирования поведения системы.

Схема 1 — Элементы диаграммы

В программе StarUML в главном меню во вкладке Model необходимо выбрать AddDiagram и необходимую диаграмму UseCaseDiagram (диаграмма прецедентов).

Рисунок 2 — Выбор диаграммы прецедентов

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

Определение информационных объектов и их атрибутов

В соответствии с разработанной концептуальной моделью (см схема 1) и описанием предметной области (ограничения) и ТЗ пункт № 4.1.3 (выходные данные) определяем объекты и их атрибутов ниже перечисленных таблицах: Таблица 10 — Таблица 19.

Таблица 10_Автомобили

Сущность

Атрибут

Тип

Автомобили

Код

Марка

ГосНомер

Габариты

Тоннаж

ГосНомерПрицепа

Счетчик (Первичный ключ)

Текстовый(30)

Текстовый(30)

Текстовый(30)

Текстовый(30)

Текстовый(30)

Таблица 11_Водители

Сущность

Атрибут

Тип

Водители

Код

Фамилия

Имя

Отчество

НомерВодПрав

СтраховойПолис

Категория

Счетчик (Первичный ключ)

Текстовый(30)

Текстовый(30)

Текстовый(30)

Текстовый(11)

Текстовый(30)

Справочник (внеш. ключ)

Таблица 12_Габариты

Сущность

Атрибут

Тип

Габариты груза(м)

Код

Габариты груза

Счетчик (Первичный ключ)

Текстовый(30)

Таблица 13_ТипГруза

Сущность

Атрибут

Тип

Тип Груза

Код

ТипГруза

Счетчик (Первичный ключ)

Текстовый(30)

Таблица 14_Категория

Сущность

Атрибут

Тип

Категория

Код

Категории

Счетчик (Первичный ключ)

Текстовый(30)

Таблица 15_Заказы

Сущность

Атрибут

Тип

Заказы

Код

ДатаЗаказа

Автомобиль

Водитель

Габариты груза(м)

ГабаритыПрицепа(м)

ТипГруза

Маршрут

Счетчик (Первичный ключ)

Дата / Время

Справочник (Внешний ключ)

Справочник (Внешний ключ)

Текстовый(30)

Текстовый(30)

Справочник (Внешний ключ)

Справочник (Внешний ключ)

Таблица 16_Маршрут

Сущность

Атрибут

Тип

Маршрут

Код

Маршрут

Счетчик (Первичный ключ)

Текстовый(30)

Таблица 17_Клиенты

Сущность

Атрибут

Тип

Клиенты

Код

КодФамилия

Имя

Отчество

Телефон

Паспорт

Адрес

Расчетный счет

Счетчик (Первичный ключ)

Текстовый(30)

Текстовый(30)

Числовой(30)

Числовой(30)

Текстовый(30)

Текстовый(30)

Числовой(30)

Таблица 18_МаркаАвто

Сущность

Атрибут

Тип

МаркаАвто

Код

Марка Авто

Счетчик (Первичный ключ)

Текстовый(30)

Таблица 19_ТипГруза

Сущность

Атрибут

Тип

Типгруза

Код

Тип груза

Счетчик (Первичный ключ)

Текстовый(30)

5. Логическая структура базы данных

На основе концептуальной модели (пункт 4.1), выделенных информационных объектов и их атрибутов (пункт 4.2), можно представить взаимосвязь между объектами.

Связи между объектами отображены в таблице 8

Таблица 8 — Связи между таблицами

Код связи

Исходная таблица

Конечная таблица

Поле связи

Связь 1

Заказ

Клиенты

Код, ФИО Клиента

Связь 2

Заказ

Тип Груза

Код Груза

Связь 3

Заказ

Гос Номер

Код Авто

Связь 4

Автомобиль

Габариты Авто

Код Авто

Связь 5

Заказ

Марка Авто

Код Марки Авто

Связь 6

Заказ

Водители

Код Водителя

Связь 7

Водители

Категории

Код Категории

Связь 8

Заказ

Маршрут

Код Маршрута

Нормализация БД

Нормализация — процесс построения эффективной структуры данных для уменьшения избыточности информации в базе данных. Избыточность информации уменьшается от первой до пятой нормальной формы.

1. Требования первой нормальной формы:

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

2. Требования второй нормальной формы:

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

3. Требования третьей нормальной формы:

  • все условия второй нормальной формы
  • любой не ключевой атрибут функционально зависит только от первичного ключа

4. Требования четвертой нормальной формы:

  • все условия третьей нормальной формы
  • исключение многозначных зависимостей

База имеет третью нормальную форму, т.к. соответствует требованиям, предъявляемым к третьей нормальной форме.

6. Физическая структура базы данных

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

Данная структура построена с помощью программы StarUML — диаграмма классов (см. Приложение Б).

Диаграммы классов показывают классы, интерфейсы, объекты и кооперации, а также их отношения.

Схема 2 — Элементы диаграммы классов

Фигура

Положение

Передвинуть()

Изм_размер()

Показать()

Скрыть()

В программе StarUML в главном меню во вкладке Model необходимо выбрать AddDiagram и UseClassDiagram (диаграмма классов).

Рисунок 4 — Выбор диаграммы классов

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

7. Реализация проекта в среде конкретной СУБД

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

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

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

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

В базе данных «Грузоперевозки» таблицы связаны друг с другом двумя связями «один ко многим».

Создание таблицы

Таблица — это основной компонент, в поле таблице могут быть представлены разные типы данных. Все таблицы были созданы в режиме «Конструктор».

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

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

Рисунок 6. Таблица «Автомобиль», в режиме «Конструктор»

Рисунок 7. Таблица «Тип груза», в режиме «Конструктор»

Создание интерфейса

Интерфейс программы «Грузоперевозки» был создан с помощью визуальной среды программирования BorlandDelphi.

Для подключения базы данных с BorlandDelphi используется компонент ADOConnection. ПризапускеDelphi, необходимовыбратьFile ->New->VCLFormsApplication — Delphi. В свойстве LoginPromptпоставить значение на False. Это делается для того, чтобы при подключении к БД пароль не запрашивался. В свойстве ConnectionString необходимо нажать на кнопку с «…»

Рисунок 8 — Свойство ConnectionString

В появившемся окне нажать на кнопку « Build…» Появляется следующее окно:

Рисунок 9 — Список провайдеров

В данном окне необходимо выбрать провайдера MicrosoftJet 4.0 OLE DB Provaider. Далее во вкладке «Соединение» необходимо указать путь к базе данных.

Затем из панели компонентов dbGo (ADO) необходимо разместить на форму компонент ADOTable, к нему подключается таблица из базы данных. В инспекторе объектов для таблицы свойства Connection устанавливаем ->Connection1, Name, Active-> True.

Рисунок 10 — Инспектор объектов для ADOTable

Из вкладки Data Access расположить на форму компонент DataSource. В инспекторе объектов для него устанавливаем следующие свойства: DataSet.

Рисунок 11 — Инспектор объектов для компонента DataSet

Из вкладки Data Controls разместить на форму компонент DBGrid. В инспекторе объектов для него установить следующие свойства: DataSource.

Рисунок 12 — Инспектор объектов для компонента DBGrid

Рисунок 13 — Компонент DBNavigator

Рисунок 12 — Подчиненная форма Студенты

1) DataSet — компонент для подключения таблиц из базы данных;

2) DBEdit — компонент для редактирования записей таблицы вручную;

3) DBLookupComboBox — компонент для выбора одного из предложенных значений;

4) DBGrid — компонент для отображения записей в таблицу;

5) DBNavigator — компонент для редактирования записей таблицы;

6) Label — компонент для отображения текста;

7) Edit_ввод данных для поиска;

8) Выход из формы;

Назначение прав доступа

Для назначения прав доступа используется свойство LoginPrompt компонента ADOConnection. В инспекторе объектов необходимо поменять свойство LoginPrompt ->True.

Рисунок 13 — Инспектор объектов ADOConnection

В появившемся окне в поле UserName вводим логин, а в поле Password — пароль.

Рисунок 14 — Форма для пароля

Право доступа в базе данных не разграничено. Для всех пользователей логин и пароль идентичен: логин adminпароль 12345

Заключение

Целью курсового проекта являлась разработка базы данных «Грузоперевозки».

В ходе выполнения курсового проекта был произведен анализ предметной области, определены ограничения по входным данным (см. страницы 5-6).

На основании анализа предметной области разработано техническое задание в соответствии с ГОСТ 34.602-89. (см. страницы 6-10), произведен выбор средств методологии проектирования (см. страницы 11-12).

На основании анализа предметной области и технического задания разработана концептуальная модель базы данных с использованием StarUML — программный инструмент моделирования; для построения концептуальной модели использовалась диаграмма прецедентов (см. Приложение Б. Концептуальная модель базы данных).

Выделены информационные объекты базы данных и определены их атрибуты (см. страницы 15-16).

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

Разработана физическая модель базы данных с использованием StarUML; для построения физической модели использовалась диаграмма классов (см. Приложение Б. Физическая модель базы данных).

Разработка базы данных была выполнена в среде MSAccess 2007; в ней были созданы таблицы и связи между ними (см. страницу 20).

Среда MSAccess 2007 выбрана для разработки в связи с тем, что разработка интерфейса и назначения прав доступа проводилось в инструментальной среде программирования BorlandDelphi 7 (см. страницы 20-28).

База данных «Грузоперевозки» разработана и отлажена, установлены права доступа. База данных находится на диске D:\ Курсовой\Баженов\Project.exe

На базу данных «Грузоперевозки» разработана программная документация, в том числе руководство программиста (см. Приложение В. Руководство программиста (ГОСТ 19.504-79.ЕСПД.)).

Список использованной литературы

[Электронный ресурс]//URL: https://obzone.ru/kursovaya/baza-dannyih-v-access-perevozki/

1) Бобровский Сергей Delphi 7. Учебный курс; СПб: Питер — Москва, 2014 . — 736 c.

2) Глушаков С.В., Ломотько Д.В. Базы данных; Харьков: Фолио — Москва, 2012 . — 504 c.

3) Калверт Ч. Базы данных в Delphi 4; Киев: ДиаСофт — Москва, 2011 . — 464 c.

4) Понамарев В. Базы данных в Delphi 7. Самоучитель; СПб: Питер — Москва, 2013 . — 224 c.

5) Хаббард Дж. Автоматизированное проектирование баз данных; М.: Мир — Москва, 2013 . — 296 c.

6) http://delphidevelop.ru/publ/28 — Учебник по Delphi для новичков.

7) http://www.delphikingdom.ru — Королевство Delphi. Виртуальный клуб программистов.

8) http://www.intuit.ru/studies/courses/614/470/info — Программирование баз данных в Delphi.