Загрузка...
Учебная работа. Курсовая работа: Разработка СУБД Оперативный учет производственной деятельности промышленного предприятия 2
Курсовой проект: страничек , рисунков , таблиц , приложений , источников .
Целью написания данного проекта является создание базы данных для контролирования работы ботанического сада.. Этот проект дозволит ознакомиться с растениями, произрастающими на участках, получить о их нужную информацию, просмотреть перечень служащих.
Результатом исследования теоретического материала является реализованная база данных «Функционирование ботанического сада» в СУБД Microsoft Access, имеющая удачный пользовательский интерфейс, созданный для работы разных групп юзеров.
база ДАННЫХ, ТАБЛИЦА, ПОЛЕ, ЗАПИСЬ, ФОРМА, запрос, ОТЧЕТ, БОТАНИЧЕСКИЙ САД, УЧАСТОК
СОДЕРЖАНИЕ
Введение
1 Постановка задачки
1.1 Общая постановка задачки
1.2 Главные составные составляющие проектируемой БД
2 Описание предметной области
3 Описание схемы объект-отношение
4 Выбор и обоснование типа модели данных
4.1 Иерархическая модель данных
4.2 Сетевая модель данных
4.3 Реляционная модель данных
5 Обоснование выбора СУБД
6 Описание концептуальной модели реляционной БД
6.1 Схема данных
6.2 Описание и обоснование полей таблиц
7 Группы юзеров
8 порядок функионирования системы
9. Главные запросы к системе
10 Список сделанных форм
10.1 Короткое описание и назначение форм
11 Список сфомированных отчетов
12 Принципы функционирования системы
12.1 Обоснование сотворения архивов БД
12.2 Режим восстановления данных
13 Набор поставки и порядок установки
Выводы
Перечень применяемой литературы
приложение А Техническое задание
Приложение Б Управление юзера
приложение В Примеры заполненных таблиц
Приложение Г Описание макросов, использованных в БД
приложение Д Листинги программных модулей
ВВЕДЕНИЕ
Данный курсовой проект сотворен в СУБД Ассеss 2000. Преимуществом данной БД является быстрота и легкость сотворения базы данных, не имея проф познаний и приятное предоставление всей нужной инфы. В истинное время, в «эру компов», быстро развиваются компьютерные технологии. Это обосновано тем, что применение компам можно отыскать в хоть какой отрасли индустрии и в хоть какой отрасли людской деятель, а это на данный момент доступно как никогда, тем повышая спроса на доброкачественную и комфортную информацию. За почти все годы работы различные учреждения и компании накопили огромные объемы инфы, которая продолжает возрастать, возникает необходимость в ее классификации и обработке. работать с большой кучей картонной информацией весьма длительно и трудоемко. Выход можно отыскать в разработке электрической базы данных.
Это существенно облегчило работу разных информационных служб. В современном мире различных данных, сведений не попросту много, а циклопическое количество. Часто получая информацию из разных источников, сотрудники компании следили дублирование данных. Это никого не веселило. Перед создателями личной картотеки вставал вопросец: как расположить информацию так, чтоб мало применять физическое дисковое место, оперативную память и при всем этом обеспечить оперативный доступ к данным.
компы просочились в большая часть компаний, учебных заведений, исследовательских институтов, промышленных центров. Это облегчило обработку большущего количества инфы, поиска данных. Большая помощь оказана отделу кадров. сейчас совершенно не тяжело созодать стремительно и отменно разные подборки, запросы по личному составу работников института, по успеваемости студентов института и т.д.
1
ПОСТАНОВКА задачки
1.1 Общая постановка задачки
Целью написания данного ПП является проектирование базы данных, которая будет содержать подробную информацию о функционировании ботанического сада, предоставлять подробную информацию о растениях, сотрудниках, работающих там.
В целом, база данных «Функционирование ботанического сада» обязана:
1) обеспечивать возможность запрашивать, искать, изменять и классифицировать информацию в БД;
2) иметь удачный пользовательский интерфейс для работы с базой данных юзера, не являющегося спецом в области обработки данных;
3) содержать систему помощи, нужную справочную информацию и информацию о программке;
4) содержать нужные запросы и формы для обработки хранимой инфы;
5) обеспечивать защиту от несанкционированного доступа (применять пароли и защиту на уровне юзеров);
6) надзирать избыточность (предугадывать архивацию данных), непротиворечивость, сохранность и достоверность хранимой в БД инфы.
7) содержать нужную информацию и предоставлять ее по просьбе.
1.2 Главные составные составляющие проектируемой БД
Для реализации поставленной задачки в проектируемую БД нужно включить последующие разделы:
1) информация о выращиваемых растениях;
2) информация о сотрудниках;
3) информация о участках.
2 ОПИСАНИЕ ПРЕДМЕТНОЙ области
Для функционирования ботанического сада нужно знать информацию о выращиваемых растениях, работающих сотрудниках и участках.
Ботанический сад содержит несколько участков. У всякого участка есть свое заглавие. На любом участке выращивается определенный набор растений и работает персонал. Любой юзер может просмотреть перечень служащих и растений по любому участку.
О растениях нужно знать на каком участке оно произрастает, его тип, семейство, его заглавие и дату высадки. Типы и семейства растений выбираются из уже имеющегося справочника.
Для настоящего функционирования и контроля над ботаническим садом необходимо знать ФИО всякого сотрудника, его должность, стаж работы, дату рождения, должность и участок, на котором он работает. Все это необходимо для контроля над растениями на любом участке.
Предметная область разработанного проекта представляет собой набор систематизированных сведений нужных для автоматизации функционирования ботанического сада.
3 ОПИСАНИЕ СХЕМЫ объект-ОТНОШЕНИЕ
Исходя из моей предметной области, я выделила последующие объекты: «Растения», «Сотрудники», «Участки», «Должности», «Ученые звания», «Типы растений», «Семейства». Любой объект имеет некие характеристики. Объект «Растения» имеет свойство: «заглавие», «тип», «семейство»; объект «Сотрудники» имеет характеристики: «ФИО», «дата рождения», «должность», «стаж работы», «ученое звание»; У объекта «Участки» есть характеристики: «номер», «заглавие»; У объекта «Должности» свойство: «заглавие»; объект «Ученые звания» имеет свойство: «заглавие»; объект «Типы растений» имеет свойство «заглавие»; объект «Семейства» имеет свойство «заглавие».
Выделим нужные дела меж объектами исходя из схемы объект-отношение, представленной на рисунке 3.1:
1. СОТРУДНИК имеет ДОЛЖНОСТЬ;
2. СОТРУДНИК имеет УЧЕНОЕ ЗВАНИЕ;
3. РАСТЕНИЕ имеет ТИП;
4. РАСТЕНИЕ имеет СЕМЕЙСТВО.
5. СОТРУДНИК выращивает РАСТЕНИЕ на УЧАСТКЕ
объект «Должности» относится к объекту «Сотрудники» как 1/∞ т.к. одну должность может иметь несколько служащих, а один сотрудник может иметь лишь одну должность. объект «Ученые звания» относится к объекту «Сотрудники» как 1/∞ т.к. одно ученое звание может иметь несколько служащих, а один сотрудник может иметь лишь одно ученое звание. объект «Типы растений» относится к объекту «Растения» как 1/∞ т.к. 1-го типа быть может несколько растений, а одно растение быть может лишь 1-го типа. объект «Семейства» относится к объекту «Растения» как 1/∞ т.к. 1-го семейства быть может несколько растений, а одно растение быть может лишь 1-го семейства. объект «Сотрудники» и таблица «Растения» относятся к объекту «Выращивается» как 1/∞ т.к. один сотрудник может растить несколько растений и одно растение может выращиваться несколькими сотрудниками сразу.
Набросок 3.1 – Схема объект-отношение
4
ВЫБОР И ОБОСНОВАНИЕ МОДЕЛИ ДАННЫХ
Огромное количество разработанных к истинному времени различных СУБД соединено с существованием разных моделей данных. При проектировании БД мы сталкиваемся с задачей выбора более пригодной модели данных для определенной предметной области.
Из приведенной схемы (набросок 3.1) видно, что меж объектами есть связи имеющие тип как «один ко почти всем», так и «один к одному». Это дозволяет выполнить проектирование БД с внедрением как реляционной, так и сетевой модели данных. Предпочтение было отдано реляционной модели данных.
БД быть может базирована на одной модели либо на совокупы нескольких моделей. Всякую модель данных можно разглядывать как объект, который характеризуется своими качествами (параметрами), и над ней, как над объектом, можно создавать какие-либо деяния.
Неважно какая модель обязана обеспечивать такие операции над БД:
— поиск обозначенного элемента базы;
— переход от одних данных к иным;
— движение по записям;
— поиск записи;
— удаление записи;
Есть три главных типа моделей данных – реляционная, иерархическая и сетевая.
4.1 Иерархическая модель данных
В иерархической модели связи меж данными обрисовывают при помощи упорядоченного графа (либо дерева). Тип является составным. Он содержит в себе подтипы («поддеревья»), любой из которых, в свою очередь, является типом «дерево». Любой из простых типов, включенных в тип «дерево», является обычным либо составным типом «запись».
Таковым образом, ИМД представляет собой упорядоченную совокупа экземпляров типа «дерево» (деревьев), содержащих экземпляры типа «запись» (записи).
В согласовании с определением типа «дерево», можно заключить, что меж праотцами и потомками автоматом поддерживается контроль целостности связей. Основное правило контроля целостности формулируется последующим образом: потомок не может существовать без родителя, а неких родителей может не быть потомков. Механизмы поддержки целостности связей меж записями разных деревьев отсутствуют.
Данные в базе с приведенной схемой для разрабатываемого ПП могут смотреться, к примеру, как показано на рисунке 4.1.
Набросок 4.1 – Пример иерархической модели данных для проектируемой БД
Корневыми являются сходу два типа Тип и город, которые в свою очередь имеют свои подчиненные типы. Тип, как и город имеет подчиненный тип Предприятие, тогда как Предприятие имеет подчиненный тип Цех. Тип Цех
в свою очередь имеет подчиненный тип Изделие. К плюсам ИМД относят действенное внедрение памяти ЭВМ и хорошие характеристики времени выполнения главных операций над данными. А конкретно: поиск обозначенного экземпляра БД, переход от 1-го дерева к другому, переход от одной записи к иной снутри дерева, вставка новейшей записи в обозначенную позицию, удаление текущей записи. ИМД комфортна для работы с иерархически упорядоченной информацией. Недочетом ИМД является ее громоздкость для обработки инфы с довольно сложными логическими связями, также сложность осознания для обыденного юзера.
4.2 Сетевая модель данных
Сетевая модель дозволяет показывать различные связи частей данных в виде случайного графа, обобщая тем ИМД.
СМД состоит из набора записей и набора соответственных связей. В отличие от ИМД в СМД запись-потомок может иметь случайное число записей-предков (сводных родителей).
Схема СМД для данной БД показана на рисунке 4.2. Типы связей тут обозначены надписями на соединяющих типы записей линиях.
Набросок 4.2 — Сетевая модель данных
Анализируя схему, лицезреем, что все элементы соединены друг с другом. Хоть какой элемент быть может выражен через остальные элементы. С одной стороны это отлично, но с иной плохо: на формирование типов связи не накладываются особенные ограничения, что приводит при выполнении главных операций над данными к нехорошим для проектируемой БД ситуациям. к примеру, в доборной таблице покажутся записи, которые не имеют родительских записей в главный таблице.
Потому недочетом СМД является высочайшая сложность и твердость схемы БД, построенной на ее базе, также сложность для осознания и выполнения обработки инфы в БД обыденным юзером. Не считая того, в СМД ослаблен контроль целостности связей вследствие допустимости установления случайных связей меж записями. Таковым образом, для разработанной в пт 3 схемы объект-отношение данную модель данных использовать не нужно.
Достоинством СМД является возможность действенной реализации по показателям издержек памяти и оперативности. В сопоставлении с ИМД сетевая модель предоставляет огромные способности в смысле допустимости образования случайных связей.
4.3 Реляционная модель данных
Реляционная модель данных некой предметной области представляет собой набор отношений (двумерных таблиц), изменяющихся во времени.
В общем случае можно считать, что реляционная БД включает одну либо несколько таблиц, объединенных смысловым содержанием, также процедурами контроля целостности и обработки инфы в интересах решения некой прикладной задачки. к примеру, при использовании СУБД Microsoft Access в файле БД вместе с таблицами хранятся и остальные объекты базы: запросы, отчеты, формы, макросы и модули.
Достоинство РМД заключается в простоте, понятности и удобстве физической реализации на ЭВМ . При помощи одной таблицы комфортно обрисовывать простой вид связей меж данными, а конкретно деление 1-го объекта, информация о котором храниться в таблице, на огромное количество подобъектов, любому из которых соответствует строчка либо запись таблицы. Физическое размещение данных в реляционных базах на наружных носителях просто осуществляется при помощи обыденных файлов. задачи же эффективности обработки данных этого типа оказались на техническом уровне полностью разрешимыми.
Главными недочетами реляционной модели являются последующие: отсутствие обычных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей.
Переход от схемы объект – отношение к реляционной модели данных осуществляется последующим образом: все объекты схемы объект – отношение это определенные таблицы заглавие полей которых являются качествами объектов, если отношение имеет характеристики то оно также является таблицей в приобретенной реляционной модели данных
Для проектируемой базы данных реляционная модель представлена на рисунке 4.3.
Набросок 4.3 — Реляционная модель данных
Таковым образом, опосля рассмотрения приведенных выше моделей данных для разработанной в пт 3 схемы объект-отношение была выбрана РМД, которая ординарна и понятна для юзера и отвечает требованиям изучаемого курса.
5 ОБОСНОВАНИЕ ВЫБОРА СУБД
Базы современной информационной технологии составляют базы данных (БД – это структурированная определенным образом совокупа данных, относящихся к определенной задачке ) и системы управления базами данных (СУБД представляет собой комплекс инструментальных средств, программных и языковых, реализующих централизованное управление БД и обеспечивающих доступ к данным (конфигурации, прибавления, удаления, запасного копирования и т.д. ), роль которых как одного средства хранения, обработки и доступа к огромным размерам инфы повсевременно растет. Резвое развитие потребностей применений БД выдвигает новейшие требования к СУБД: естественные и действенные представления в БД различных отношений меж объектами предметных областей (к примеру, пространственно-временных с обеспечением визуализации данных); СУБД обязана обеспечивать поиск, модификацию и сохранность данных, также оперативный доступ (время отклика), защиту целостности данных от аппаратных сбоев и программных ошибок, разграничение прав и защита от несанкционированного доступа, поддержка совместной работы нескольких юзеров с данными.
Сиим требованиям отвечают почти все современные СУБД, в том числе и Access. МА содержит в себе классические технологии и способности реляционных СУБД, предоставляет средства сотворения базы нормализованных данных и форм для диалоговой работы с ней и комфортным графическим интерфейсом. С построением базы нормализованных данных тесновато связана разработка и действенная реализация задач юзера. Для рения почти всех задач довольно применять такие объекты Access, как формы, запросы ,отчеты. Эти объекты просто создаются в диалоговом режиме. Для реализации целостного приложения юзера в некой предметной области возникает необходимость в разработке макросов и модуле на языке Visual Basic for Applications (VBA). Механизм обработки событий, возникающих в процессе диалоговой работы с данными, дозволяет соединять воединыжды в приложении юзера отдельные запросы, формы и отчеты и получать неординарные рения в практических приложениях юзера.
программка Microsoft Access 2000 является реляционной СУБД, которая может работать под управлением операционных систем Windows 95/98/Me, Windows NT, Windows XP, и дозволяет воплотить поставленную цель. Обеспечивает удобство работы юзера: имеется возможность сотворения пользовательских интерфейсов при использовании Visual Basic для приложений, автоматизация разработки разных объектов. Для построения и выполнения запросной функции в Access 2000 весьма комфортным и легкодоступным является язык запросов по эталону QBE, поддерживаемый массивным интерфейсом юзера, также интегрированный язык запросов SQL, который является комфортным языком управления базами данных.
программка Microsoft Access 2000 имеет маленький размер вспомогательного программного обеспечения, вследствие чего же предъявляет меньше требований к памяти, чем программки Microsoft Access поздних версий. Не считая того, для проектирования требуемой БД нет необходимости в использовании способностей наиболее поздних программ Office либо остальных компаний производителей. Полностью довольно средств, предоставляемых юзеру Microsoft Access 2000.
6 ОПИСАНИЕ КОНЦЕПИУАЛЬНОЙ МОДЕЛИ РЕЛЯЦИОННОЙ Б
АЗЫ ДАННЫХ
6.1 Схема Данных
Схема данных, отражает логическое области и в информационном плане сохраняла все способности приведенной выше модели без прибавления новейших объектов, фактически нереально.
Нормализация – это разбиение таблицы на две либо наиболее, владеющих наилучшими качествами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такового проекта базы данных, в каком любой факт возникает только в одном месте, т.е. исключена избыточность инфы. Это делается не столько с целью экономии памяти, сколько для исключения вероятной противоречивости хранимых данных.
Таблица находится в первой обычной форме (1НФ) и тогда лишь тогда, когда ни одна из ее строк не содержит в любом собственном поле наиболее 1-го значения и ни одно из ее главных полей не пуст.
Таблица находится во 2-ой обычной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, соединены полной многофункциональной зависимостью с первичным ключом.
Таблица находится в третьей обычной форме (3НФ), если она удовлетворяет определению 2НФ и не одно из ее не главных полей не зависит функционально от хоть какого другого не главного поля.
Набросок 6.2 – Таблица данных в 1НФ
Назв. компании
С 80
Дата открытия компании D10
Назв. Городка
C20
Назв. Типа предпр C30
Назв. Цеха C15
Кол-во рабочих N4
Дата ввода в строй D8
Дата посл реконструкции D8
Месяц С8
Кол-во изделий N6
Стоимость N5
Назв. Изделия C20
Представим многофункциональные зависимости для таблицы в 1НФ:
Заглавие цеха
Заглавие изделия
Заглавие компании
Кол-во рабочих
Кол-во изделий
Дата открытия
Дата ввода в строй
Стоимость изделия
Дата посл. Реконстр.
Месяц выпуска изделия
6.2 Описание и обоснование полей таблиц
В проектируемой базе данных реализовано 6 таблиц. Ниже для каждой таблицы приведены описание, обоснование полей, ограничения на входную информацию, нужные маски ввода, применяемые подстановки. Все примеры заполненных таблиц приведены в приложении В.
Таблица «Предприятие» (таблица 6.2.1):
1. Код компании
-Ключ: первичный ключ;
-Счетчик;
-Длинноватое целое;
-Размер: 3;
-Совпадение не допускаются, потому что это первичный ключ, он считает записи в таблице.
2. Заглавие компании
— Текстовое;
— Размер 80;
— Непременное поле, потому что заглавие компании – это основная изюминка, по которой можно различать компании;
— Пустых строк нет, потому что не быть может предприятие без наименования;
— Совпадения не допускаются, потому что у 2-ух различных компаний не обязано быть схожих заглавий;
3. Дата открытия компании
— Тип дата;
— Размер 10;
— Непременное поле, потому что у всякого компании есть дата открытия;
-Совпадения допускаются, потому что различные компании могут быть открыты в один и этот же денек;
-Маска: 00.00.0000;
—
-Условие на значения <=Date(), потому что предприятие не может открыться позднее, чем в денек рассмотрения его деятель.
4. Город
-Тип длинноватое целое;
-Размер 2;
-Непременное поле, потому что каждое предприятие находится в каком-либо городке;
-Совпадения допускаются, потому что различные компании могут находиться в одном городке;
-Подстановка: из таблицы «Город», поле «Заглавие городка»;
-Наружный ключ.
5. Тип
-Тип длинноватое целое;
-Размер 2;
-Непременное поле, потому что у всякого компании есть собственный тип;
-Совпадения допускаются, потому что различные компании могут иметь один и этот же тип;
-Подстановка: из таблицы «Тип», поле «Заглавие типа»;
-Наружный ключ.
Таблица 6.2.1 «Предприятие»
Предприятие
#Код компании
Заглавие компании
Дата открытия
город
Тип
1
Шахтуглесервис
25.06.1956
Шахтерск
Личное
2
Азовмаш
24.05.1985
Мариуполь
ООО
3
Азовсталь
13.02.1991
Краматорск
Государственное
4
ДМЗ
12.03.1985
Донецк
ОАО
Таблица «Город» (таблица 6.2.2):
1. Код городка
-Ключ: первичный ключ;
-Счетчик;
-Длинноватое целое;
-Размер: 3;
-Совпадение не допускаются, потому что это первичный ключ, он считает записи в таблице.
2. Заглавие городка
— Текстовое;
— Размер 20;
— Непременное поле, потому что город не быть может без наименования;
— Пустых строк нет, потому что город не может иметь пустое заглавие;
— Совпадения не допускаются, потому что различные городка не могут иметь одно и то же заглавие.
Таблица 6.2.2 «Город»
город
#Код городка
Заглавие городка
1
Донецк
2
Шахтерск
3
Мариуполь
4
Краматорск
Таблица «Тип» (таблица 6.2.3):
1. Код типа
-Ключ: первичный ключ;
-Счетчик;
-Длинноватое целое;
-Размер: 3;
-Совпадение не допускаются, потому что это первичный ключ, он считает записи в таблице.
2. Заглавие типа
— Текстовое;
— Размер 30;
— Непременное поле, потому что тип не быть может без наименования;
— Пустых строк нет, потому что тип не может иметь пустое заглавие;
— Совпадения не допускаются, потому что различные типы не могут иметь одно и то же заглавие.
Таблица 6.2.3 «Тип»
Тип
#Код типа
Заглавие типа
1
Государственное
2
Личное
3
ООО
4
ОАО
Таблица «Изделие» (таблица 6.2.4):
1. Код городка
-Ключ: первичный ключ;
-Счетчик;
-Длинноватое целое;
-Размер: 3;
-Совпадение не допускаются, потому что это первичный ключ, он считает записи в таблице.
2. Заглавие изделия
— Текстовое;
— Размер 20;
— Непременное поле, потому что изделия не быть может без наименования;
— Пустых строк нет, потому что тип не может иметь пустое заглавие;
— Совпадения не допускаются, потому что различные изделия не могут иметь одно и то же заглавие.
Таблица 6.2.4 «Изделие»
Изделие
#Код изделия
Заглавие изделия
1
Шайбы
2
Чайники
3
Болты
4
Бочки
5
Движки
6
Сковородки
7
Столы
8
Кровати
9
компы
Таблица «Цех» (таблица 6.2.5):
1. Код цеха
-Ключ: первичный ключ;
-Счетчик;
-Длинноватое целое;
-Размер: 3;
-Совпадение не допускаются, потому что это первичный ключ, он считает записи в таблице.
2. Заглавие цеха
— Текстовое;
— Размер 15;
— Непременное поле, потому что изделия не быть может без наименования;
— Пустых строк нет, потому что цех не может иметь пустое заглавие;
— Совпадения допускаются, потому что различные цеха не могут иметь одно и то же заглавие.
3. количество рабочих
-Тип длинноватое целое;
-Размер 4;
-Совпадения допускаются, потому что различные цеха могут иметь однообразное число количества рабочих;
— Пустых строк нет, потому что хоть какой цех содержит рабочих;
-Условие на 1-го рабочего.
4. Дата ввода в строй
-Тип дата
— Размер 10
— Непременное поле, потому что любой цех имеет дату открытия;
-Совпадения допускаются, потому что различные цеха могут в один денек войти в строй;
— Маска: 00.00.0000;
-Значение по дефлоту =Date();
— Условие на значения <=Date()and<(дата крайней реконструкции), потому что цех не быть может введен в строй позднее, чем была его реконструкция.
5. Дата крайней реконструкции
-Тип дата;
— Размер 10;
— Не непременное поле, потому что цех мог еще не подлежать реконструкции;
-Совпадения допускаются, потому что даты реконструкции различных цехов могут быть схожими;
— Маска: 00.00.0000;
—
— Условие на значения <=Date()and>(дата ввода в строй), потому что цех не быть может отреконструирован ранее, чем он был введен в строй.
6. Предприятие
-Тип длинноватое целое;
-Размер 2;
-Непременное поле, потому что хоть какой цех находится на каком-либо предприятии;
-Совпадения допускаются, потому что несколько цехов могут быть на одном предприятии;
-Подстановка: из таблицы «Предприятие», поле «Заглавие компании»;
-Наружный ключ.
Таблица 6.2.5 «Цех»
Цех
#Код цеха
Заглавие цеха
количество рабочих
Дата ввода в строй
Дата крайней реконструкции
Предприятие
1
Любительский
146
19.05.1999
26.03.2000
Азовсталь
7
Конечный
106
21.07.1998
29.03.2004
Азовсталь
11
Любительский
60
31.05.1996
16.04.2001
Азовмаш
13
Промежный
34
05.10.1995
06.08.1998
ДМЗ
15
Промежный
140
01.02.1986
12.07.1996
Азовмаш
24
Старый
25
03.12.1957
25.05.1959
Шахтуглесервис
25
Любительский
326
18.12.1989
26.04.1995
ДМЗ
34
Конечный
86
29.05.1973
16.11.2001
Шахтуглесервис
Таблица «Выпуск» (таблица 6.2.6):
1. Месяц
-Текстовое;
— Размер 8;
— Непременное поле, потому что все изделия выпускаются в каком-то месяце;
— Совпадения допускаются, потому что изделия могли быть выпущены в один и этот же месяц.
2. количество изделий
-Тип длинноватое целое;
-Размер 4;
-Совпадения допускаются, потому что могло быть выпущено однообразное количество изделий;
-Пустых строк нет, потому что в любом случае было выпущено какое-либо количество изделий.
3. Стоимость изделия
-Тип длинноватое целое;
-Размер 5;
-Совпадения допускаются, потому что стоимость быть может схожей у различных изделий;
-Пустых строк нет, у всех изделий есть своя стоимость.
4. Цех
-Тип длинноватое целое;
-Размер 2;
-Непременное поле, потому что хоть какое изделие выпускается на каком-то цеху;
-Совпадения допускаются, потому что различные изделия выпускаются на одном цеху;
-Подстановка: из таблицы «Цех», поле «Заглавие цеха»
-Наружный ключ.
5. Изделие
-Тип длинноватое целое;
-Размер 2;
-Непременное поле, потому что непременно выпускается како-то изделие;
-Совпадения допускаются, потому что может выпускаться одно и то же изделие;
-Подстановка: из таблицы «Изделие», поле «Заглавие изделия»;
-Наружный ключ.
Таблица 6.2.6
Выпускает
Месяц
количество изделий
Стоимость изделия
Цех
Изделие
Код Выпуска
Январь
2568
107
Любительский
Бочки
2
Февраль
78
34
Любительский
Чайники
7
Март
1000
100
Любительский
Болты
9
Апрель
200
101
Любительский
Чайники
12
Май
567
754
Любительский
Бочки
13
Июнь
155
24
Любительский
Бочки
24
Июль
4535
788
Любительский
Движки
29
Август
636
235
Любительский
Бочки
30
Сентябрь
42
520
Любительский
Шайбы
31
Октябрь
453
445
Любительский
Кровати
32
Январь
535
53
Конечный
Шайбы
33
Февраль
539
278
Конечный
Чайники
34
Март
455
876
Конечный
Болты
35
Апрель
41
7786
Конечный
Кровати
36
Октябрь
572
963
Конечный
Столы
37
Ноябрь
754
912
Конечный
Сковородки
38
Декабрь
476
724
Конечный
Движки
39
Январь
336
26
Промежный
Движки
40
Февраль
561
54
Промежный
Бочки
41
Сентябрь
513
35
Промежный
Болты
42
Август
45
96
Промежный
Движки
44
Март
4
5468
Промежный
Сковородки
45
Апрель
8462
33
Старый
Столы
46
Сентябрь
545
56543
Старый
Болты
47
Ноябрь
654
377
Любительский
компы
48
Декабрь
8974
850
Любительский
Движки
49
Май
6463
55
Конечный
компы
50
Июнь
543
12
Конечный
Шайбы
51
Июль
894
4856
Конечный
Чайники
52
Август
5641
861
Конечный
Болты
53
Сентябрь
563
48
Конечный
Столы
54
Апрель
521
265
Промежный
компы
55
Май
23
2645
Промежный
Сковородки
56
Июнь
452
52
Промежный
Чайники
57
Июль
553
83
Промежный
компы
58
Декабрь
441
333
Промежный
Кровати
59
Ноябрь
478
599
Промежный
Бочки
60
приложение Б
РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ
Б.1 Общие сведения
Разработанная БД создана для предоставления юзеру всей нужной инфы для автоматизации производительной деятельности промышленного компании.
Данная БД имеет удачный графический интерфейс. При запуске программки, возникает основное меню, содержащее все пункты, нужные для работы с приложением (см. Приложение Д рис. Д.1). По мере необходимости добавить, просмотреть либо поменять информацию необходимо избрать помощью кнопок управления курсором либо <Tab> нужную клавишу с заглавием формы, и надавить <Enter> либо открыть форму кликом мыши.
Для пуска программки требуется запустить файл «Course.mdb» в СУБД MS Access.
Б.2 Ввод, удаление, добавление и редактирование данных
Ввод данных осуществляется в формах при помощи клавиатуры. Для ввода данных нужно выделить указателем мыши нужное поле либо перейти на него при помощи кнопок управления курсором либо <Tab>, и ввести данные. Аналогичным образом осуществляется редактирование данных.
Добавление данных осуществляется в формах так же, как и во всех БД.
На удаление записей юзеры «Guest» не имеют права. Удалять записи из таблиц либо форм могут лишь юзеры «Adminstrator» и «User», используя надлежащие клавиши в формах.
Б.3 Просмотр отчетов
Для просмотра отчетов нужно вызвать пункт меню основное меню->открыть отчет. Или пункт меню основное меню->открыть форму->отчеты.
Б.4 Внедрение справочной инфы и выход из программки
Справочная информация в БД. В целом для воплощения нужных действий требуется читать надписи на клавишах либо с ними и жать на эти клавиши.
Выход из приложения MS Access осуществляется при выбирании пт меню основное меню->Выход.
приложение В
ЛИСТИНГИ ПРОГРАММНЫХ МОДУЛЕЙ
1. Модуль: контроль над вводом данных.
Option Compare Database
Sub c()
Dim t As Integer
DoCmd.OpenForm «Предприятие1», acNormal
DoCmd.OpenForm «Цех1», acNormal
If [Forms]![Предприятие1]![дата открытия] < [Forms]![Цех1]![дата ввода в строй] Then
t = MsgBox(«Данные введены, правильно», vbOKOnly, » Сообщение»)
Else: t = MsgBox(«Сообщение: цех был введен в строй, до открытия компании«, vbOKOnly, » Сообщение»)
End If
End Sub
2. Модуль: группы юзеров.
Private Sub Form_Open(Cancel As Integer)
myvalue = InputBox(«Если вы админ или юзер, введите собственный пароль, если гость – нажмите ОК»)
If myvalue = «» Then
Клавиша 13.Visible = False
Клавиша 15.Visible = False
Клавиша 23.Visible = False
Клавиша 16.Visible = False
Клавиша 45.Visible = False
Клавиша 48.Visible = False
Клавиша 49.Visible = False
Клавиша 50.Visible = False
Клавиша 51.Visible = False
Клавиша 52.Visible = False
Клавиша 53.Visible = False
Else
If myvalue = «I am admin» Then
Клавиша 16.Visible = True
Клавиша 23.Visible = True
Клавиша 15.Visible = True
Клавиша 13.Visible = True
Клавиша 33.Visible = True
Клавиша 8.Visible = True
Клавиша 38.Visible = True
Else
If myvalue = «User» Then
Клавиша 48.Visible = False
Клавиша 49.Visible = False
Клавиша 50.Visible = False
Клавиша 51.Visible = False
Клавиша 52.Visible = False
Клавиша 53.Visible = False
Else: MsgBox («введите верный пароль!!!»)
DoCmd.Close acForm, «Основная»
End If
End If
End If
End Sub
3. Модуль: добавление в форму.
Option Compare Database
Sub Verifying() ‘Процедура прибавления элемента в перечень
Dim str, tmp1, tmp2 As String
Dim c, i, t, f As Integer
Dim rst As DAO.Recordset
Dim flag As Boolean
str = «»
Do While str = «»
str = InputBox(«Введите заглавие», «Ввод данных») ‘Вводим новейший элемент
If str = «» Then ‘Предотвращение пустой строчки
t = MsgBox(«Строчка не быть может пустой», vbInformation, «Инфо»)
End If
Loop
DoCmd.OpenForm «Предприятие1», acNormal ‘Открываем форму
DoCmd.GoToRecord acDataForm, «Предприятие1», acNewRec
Set rst = Forms(«Предприятие1»).Recordset
flag = False
rst.MoveFirst
While Not rst.EOF
If rst![Название предприятия] = str Then
flag = True
GoTo m001:
End If
rst.MoveNext
Wend
m001:
If flag Then
t = MsgBox(«Таковой элемент в перечне уже есть. Добавление нереально.», vbCritical)
Else
t = MsgBox(«Вы вправду желаете добавить новейший элемент перечня?», vbQuestion + vbYesNo, «Вы убеждены?»)
If t = 6 Then
rst.AddNew
rst![Название предприятия] = str
rst.Update
z = MsgBox(«Добавленно новое заглавие: » & str, vbInformation)
ElseIf t = 7 Then ‘отказ от прибавления
t = MsgBox(«Прервано юзером!», vbOKOnly + vbCritical, «Error»)
End If
End If
DoCmd.OpenForm «Предприятие1», acNormal ‘Открываем форму
End Sub
]]>