Разработка структуры ООО "Бурят-Терминал" г. Улан-Удэ в СУБД MS Access

 

Содержание


Введение

1.Описание предметной области и требований к информационной системе

2. Проектирование базы данных

.1 Концептуальная модель базы данных

.2 Логическая модель реляционной базы данных

.3 Физическое проектирование

.4 Описание таблиц базы данных

.5 Реализация базы в СУБД MS Access

Заключение

Список литературы

Приложение


Введение


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

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

Задачи:

Создание

. Концептуальной (инфологической) модели;

. Логической (даталогической) модели;

. Физической модели

Система управления базами данных (СУБД) - это общесистемное программное средство, предназначенное для создания, поддержания и использования базы данных.

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

Способ организации логической структуры хранения данных в базе данных называется моделью данных. Модели данных определяются тремя компонентами:

1.Допустимой организацией данных;

2.Ограничениями целостности;

.Множеством допустимых операций.

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

·Профессиональные или промышленные;

·Персональные или настольные.

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

Базы данных разработанные в MS Access, применяются в информационных системах как небольших магазинов, фирм, так и систем государственных, общественных, социальных структур. Примером такой структуры и объектом будет являться разработка структуры ООО «Бурят-Терминал» г.Улан-Удэ. Предметом - СУБД MS Access, упоминаемый ранее.

1.Описание предметной области и требований к информационной системе


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

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

Составим схему разрабатываемой базы данных:


2.Проектирование базы данных


2.1Концептуальная модель базы данных


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

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

Требования, предъявляемые к концептуальной модели:

. Адекватное, отображение предметной области;

. Недопущение неоднозначной трактовки модели;

. Четкое определение моделируемой предметной области;

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

. Легкое восприятие различными категориями пользователей.

Изобразим потоки данных в разрабатываемой базе данных:



.2 Логическая модель реляционной базы данных


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

Для преобразования сущностей в совокупность отношений требуется выполнить следующие действия:

. Создать по одной таблице для каждой сущности.

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

Проведем это преобразование для нашего примера.

. На основе концептуальной модели создадим 8 таблиц с полями, соответствующими атрибутам сущностей.

. Зададим первичные ключи для таблиц Отдел кадров, Договор, Услуги.

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

·Идентификации строк в таблице;

·Ускорения работы со строками в таблице;

·Связывания таблицы.

В качестве первичных ключей лучше всего назначить некоторый числовой идентификатор записи.

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

Сущности вступают во взаимоотношения, называемые связями. Наиболее распространена связь «один ко многим». В нашем примере сущность Отдел кадров связана с сущностями Услуги, Договоры с поставщиками, Бухгалтерия; сущность Поставщики связана с сущностью Договоры с поставщиками, сущность Услуги связана с сущностью Договоры с клиентами связью «один ко многим», сущность Отдел кадров связана с сущностями Материальная часть и Бухгалтерия связью «один к одному».


Рисунок 1. Логическая модель базы данных. Связи между сущностями

реляционная база данные access

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

. Запросы

·Договоры с поставщиками, срок действия которых заканчивается в 2013 году.

·Список сотрудников, получающих заработную плату больше 20 000 рублей.

·Список сотрудников, которые ездили в командировки в 2011 году.

·Список сотрудников, получивших премию больше 2000 рублей.

·Модели несписанных машин, стоимость которых меньше 100 000 рублей.

·Список договоров, заключенных в текущем году.

·Список сотрудников, стаж работы которых больше 9 лет.

·Списанное оборудование.

2.Формы

·Отдел кадров

·Услуги

·Клиенты

·Поставщики

·Договоры с поставщиками

·Договоры с клиентами

·Бухгалтерия

·Материальная часть

3.Отчеты

·Отчет о списанном оборудовании.

·Отчет о заключенных договорах с поставщиками в текущем году.

·Отчет о доходах организации.

·Отчет о премиях сотрудникам.

·Отчет о расходах организации.


.3 Физическое проектирование


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


Рис. 1.1 Схема связей между отношениями


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

В табл.1.3. перечислены индексные поля для таблиц базы данных ООО «Бурят-Терминал».


Таблица 1.3. Индексные поля

Индексированное полеОписаниеТаблица Отдел кадровId сотрудникаПервичный ключТаблица КлиентыId клиентаПервичный ключТаблица ПоставщикиId организации Первичный ключТаблица Договор с клиентами№ договораПервичный ключТаблица Договор с поставщиками № договораПервичный ключТаблица БухгалтерияId сотрудникаПервичный ключТаблица Материальная частьКод машиныПервичный ключId сотрудникаДля поиска по сотрудникамТаблица УслугиId услугиПервичный ключ

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


.4 Описание таблиц базы данных ООО «Бурят-Терминал»


Результат проведенного проектирования базы данных для нашего примера можно представить в виде полного описания свойств полей для всех таблиц (табл. 1.4 - 1.10). Имена полей заданы в виде английских слов без пробелов, так как при реализации в СУБД при построении модулей с использованием языка запросов SQL или другого языка программирования существуют ограничения на имена идентификаторов (латинские буквы, цифры, символ подчеркивания). Свойства полей указаны в том виде и перечислены в том порядке, в котором они представлены в окне Конструктора таблиц MS Access. При заполнении таблиц, вообще говоря, можно не вводить данные в неключевые поля. Для задания обязательности ввода данных в поле используется свойство Обязательное поле. Тип данных поля выделен в отдельный столбец, названия и значения остальных свойств перечислены в следующих двух столбцах.


Таблица 1.4 Отдел кадров

Имя поляТип данныхСвойства поляСвойствоЗначениеId сотрудникаЧисловой Размер поля Обязательное поле ИндексДлинное целое Да Да(совпадения не допускаются)ФамилияТекстРазмер поля Обязательное поле Индекс255 Нет НетИмяТекстРазмер поля Обязательное поле Индекс255 Нет НетОтчествоТекстРазмер поля Обязательное поле Индекс255 Нет НетДата рожденияДата/времяОбязательное поле Формат поля Индекснет Краткий формат НетРегистрацияТекстРазмер поля Обязательное поле Индекс255 Нет НетФактическое проживаниеТекстРазмер поля Обязательное поле Индекс255 Нет НетТелефонТекстРазмер поля Обязательное поле Индекс255 Нет НетПенсионное страховое свидетельствоТекстРазмер поля Обязательное поле Индекс255 Нет НетМедицинское страховое свидетельствоТекстРазмер поля Обязательное поле Индекс255 Нет НетПаспортТекстРазмер поля Обязательное поле Индекс255 Нет НетИННТекстРазмер поля Обязательное поле Индекс255 Нет НетПодразделениеТекстРазмер поля Обязательное поле Индекс255 Нет НетОтметка о командировкеЛогическийФормат поля ИндексДа/нет НетНачало командировкиДата/времяОбязательное поле Формат поля Индекснет Краткий формат НетОкончание командировкиДата/времяОбязательное поле Формат поля Индекснет Краткий формат НетФотоПоле объекта OLEОбязательное полеНет Командировочные расходыДенежныйФормат поля Обязательное поле ИндексДенежный Нет НетДата поступления на работуДата/времяОбязательное поле Формат поля Индекснет Краткий формат НетДата увольненияДата/времяОбязательное поле Формат поля Индекснет Краткий формат нет

Таблица 1.5 Услуги

Имя поляТип данныхСвойства поляСвойствоЗначениеId услугиЧисловойРазмер поля Обязательное поле ИндексДлинное целое Да Да(совпадения не допускаются)НаименованиеТекстовыйРазмер поля Обязательное поле Индекс255 Нет нетСтоимостьДенежныйФормат поля Обязательное поле ИндексДенежный Нет нетЕдиница измерения ТекстовыйРазмер поля Обязательное поле Индекс255 Нет нетПоказатель измеренияЧисловойРазмер поля Обязательное поле ИндексДлинное целое нет нет Id сотрудникаЧисловойРазмер поля Обязательное поле ИндексДлинное целое да нет

Таблица 1.6 Клиенты

Имя поляТип данныхСвойства поляСвойствоЗначениеId организацииЧисловойРазмер поля Обязательное поле ИндексДлинное целое Да Да(совпадения не допускаются)Наименование организацииТекстРазмер поля Обязательное поле Индекс255 Нет НетАдресТекстРазмер поля Обязательное поле Индекс255 Нет НетАдрес эл.почты ТекстРазмер поля Обязательное поле Индекс255 Нет НетТелефонТекстРазмер поля Обязательное поле Индекс255 Нет Нет

Таблица 1.7 Поставщики

Имя поляТип данныхСвойства поляСвойствоЗначениеId организацииЧисловойРазмер поля Обязательное поле ИндексДлинное целое Да Да(совпадения не допускаются)Наименование организацииТекстРазмер поля Обязательное поле Индекс255 Нет НетАдресТекстРазмер поля Обязательное поле Индекс255 Нет НетАдрес эл.почты ТекстРазмер поля Обязательное поле Индекс255 Нет НетТелефонТекстРазмер поля Обязательное поле Индекс255 Нет НетПоставкаТекстРазмер поля Обязательное поле Индекс255 Нет НетФИО ответственного лицаТекстРазмер поля Обязательное поле Индекс255 Нет Нет

Таблица 1.8 Материальная часть

Имя поляТип данныхСвойства поляСвойствоЗначениеКод машиныЧисловойРазмер поля Обязательное поле ИндексДлинное целое Да Да(совпадения не допускаются)МодельТекстРазмер поля Обязательное поле Индекс255 Нет НетДата начала эксплуатацииДата/времяОбязательное поле Формат поля Индекснет Краткий формат нетДата списания Дата/времяОбязательное поле Формат поля Индекснет Краткий формат нетДата проверки работоспособностиДата/времяОбязательное поле Формат поля Индекснет Краткий формат нетОценка работоспособностиТекст Размер поля Обязательное поле Индекс255 Нет НетОтметка о списанииЛогическийФормат поля ИндексДа/нет нетСтоимостьДенежныйРазмер поля Обязательное поле ИндексДенежный Нет нетId сотрудникаЧисловойРазмер поля Обязательное поле ИндексДлинное целое Да Да(совпадения не допускаются)

Таблица 1.9 Договор с клиентами

Имя поляТип данныхСвойства поляСвойствоЗначение№ договораЧисловойРазмер поля Обязательное поле ИндексДлинное целое Да Да(совпадения не допускаются)Id клиентаЧисловойРазмер поля Обязательное поле ИндексДлинное целое Нет нетДата заключенияДата/времяОбязательное поле Формат поля Индекснет Краткий формат нетСрок действияДата/времяОбязательное поле Формат поля Индекснет Краткий формат нетСумма к оплатеДенежныйРазмер поля Обязательное поле ИндексДенежный Нет нетДата оплатыДата/времяОбязательное поле Формат поля Индекснет Краткий формат нетКоличествоЧисловойРазмер поля Обязательное поле Индексцелое нет нетId услугиЧисловойРазмер поля Обязательное поле Индексцелое нет нет

Таблица 1.10 Бухгалтерия

Имя поляТип данныхСвойства поляСвойствоЗначениеId сотрудникаЧисловойРазмер поля Обязательное поле ИндексДлинное целое Да Да(совпадения не допускаются)Налог ЧисловойРазмер поля Обязательное поле Индексцелое нет нетПремияДенежныйРазмер поля Обязательное поле ИндексДенежный Нет нетКомандировочные расходыЧисловойРазмер поля Обязательное поле ИндексДлинное целое Нет нет№ банковского счетаТекст Размер поля Обязательное поле Индекс255 Нет НетДоход организацииЧисловойРазмер поля Обязательное поле ИндексДлинное целое Нет нетФорма оплатыТекст Размер поля Обязательное поле Индекс255 Нет НетЗаработная платаЧисловойРазмер поля Обязательное поле ИндексДлинное целое Нет нетПредоплатаЧисловойРазмер поля Обязательное поле ИндексДлинное целое Нет нет

.5 Реализация базы данных в СУБД MS Access


Создание таблиц и схем данных. На первом этапе необходимо создать структуру всех таблиц в режиме Конструктора таблиц. На рис. 1.2. представлено окно конструктора с описанием таблицы Отдел кадров. Введем в них следующие данные.


Таблица 2. Отдел кадров

Рис. 1.2 Окно Конструктора


Таблица2.1Услуги

Таблица 2.2 Поставщики


Таблица 2.3 Материальная часть


Таблица 2.4 Клиенты


Таблица 2.5 Договоры с поставщиками


Таблица 2.6 Договоры с клиентами


Таблица 2.7 Бухгалтерия


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



Разработка запросов к базе данных

Основным видом использования базы данных является поиск нужной информации для вывода или последующей обработки. Простейшими операциями поиска являются фильтрация и сортировка записей в одной таблице. Однако наиболее общий и гибкий путь - это построение запросов к базе данных. Большинство запросов создается сразу на этапе создания базы данных, так как это регулярно востребуемая информация, для получения которой и создавалась база данных. В то же время на любом этапе эксплуатации базы данных могут быть построены новые запросы для реализации новой функции. В MS Access запросы могут быть записаны на языке SQL или построены с помощью Конструктора запросов. Понятие запроса употребляется в Access в расширенном плане. Его следует трактовать как некоторую команду на выбор, просмотр, изменение, создание или удаление данных. Наиболее распространенными являются запросы на выборку. Результатом выполнения такого запроса является таблица, в которой по определенным критериям выбираются определенные поля одной или нескольких взаимосвязанных таблиц. При создании нового запроса в режиме Конструктора запросов для него по умолчанию устанавливается тип Запрос на выборку.

В процессе создания запроса в режиме Конструктора можно выделить ряд принципиальных этапов:

указание таблиц и полей, данные из которых должны присутствовать в запросе;

задание порядка, в котором должны выводиться строки при выполнении запроса;

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

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


Рис. 1.5 Запрос на выборку «Договоры с поставщиками, заключенные в 2012 году»


Рис. 1.6 «Список сотрудников, заработная плата которых превышает 20000 рублей»


Рис. 1.7 Запрос «Несписанные машины, стоимость которых не превышает 100000»


Рис. 1.8 Результат запроса « Несписанные машины, стоимость которых не превышает 100000»


Конструирование экранных форм.

До сих пор мы рассматривали ввод данных непосредственно в таблицы. Однако при эксплуатации базы данных ввод и редактирование данных обычно производится пользователями, для которых нужен некоторый интерфейс в виде экранных форм. Использование специального интерфейса вызывается несколькими причинами. Во-первых, из соображений безопасности данных пользователь вообще не должен иметь доступ к таблицам, а только к тем полям и тех таблиц, которые связаны с реализацией той или иной функции, например, вводом данных о книгах или выводом отчетов. Во-вторых, экранные формы предоставляют более удобный ввод данных. В-третьих, логика использования базы данных может потребовать построения некоторого сценария, то есть последовательности вызова различных форм. В этом случае можно говорить о разработке приложения под MS Access. Простейший способ создания формы в MS Access - с помощью надстройки Автоформа.

Так же форму с добавленными элементами оформления можно создать в режиме Конструктор - рис. 1.11. В режиме Конструктор явно видна структура формы. Она состоит из трех частей: Заголовок, Область данных и Примечание формы. Как сама форма, так и ее разделы рассматриваются как элементы управления, обладающие некоторыми настраиваемыми наборами свойств.


Рис. 1.11 Конструктор формы Отдел кадров


Рис 1.12 Форма Отдел кадров


Рис. 1.13 Кнопочная форма ООО «Бурят-Терминал»


Конструирование отчетов.

Важной функцией любых программных систем, связанных с обработкой данных, является составление отчетов по имеющейся в наличии информации. Под отчетом понимается структурированный определенным образом документ. Эти требования зависят от назначения отчета. Рассмотрим способы создания отчетов средствами MS Access. Для его создания можно воспользоваться надстройками Автоотчет в столбец или Автоотчет табличный. В режиме Конструктор могут быть добавлены те же управляющие элементы, что и при конструировании макета экранной формы. Более сложные отчеты строятся обычно не по таблицам, а по запросам и с помощью Мастера отчетов.


Рис. 1.14 Конструктор отчета «Договоры с поставщиками за 2012 год»


Рис. 1.15 Отчет «Договоры с поставщиками за 2012 год»


Рис 1.16 Конструктор отчета «Списанное оборудование»

Рис. 1.17 Отчет «Списанное оборудование»

Заключение


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

«Отдел кадров», «Услуги», «Клиенты», «Поставщики», «Договоры с поставщиками», «Договоры с клиентами», «Бухгалтерия», «Материальная часть»; отчеты, позволяющие быстро проанализировать данные: «Премии», «Расходы организации», «Доходы организации», «Договоры с поставщиками за текущий год», «Списанное оборудование».

Таким образом, созданная нами в СУБД MS Access база данных ООО «Бурят-Терминал» позволяет нам решить многие управленческие задачи и систематизировать процессы учета финансов, материальной части и др.

Список литературы


1.Кушнир, А.Н. Microsoft Office Access 2007. Просто как дважды два// А.Н. Кушнир - Эксмо, 2007.-272с.

2.Кошелев, В.Е. Access 2007: Эффективное использование: Разработка проекта электронной библиотеки; Базы данных Microsoft Office Access 2007; Планирование баз данных и др.// В.Е. Кошелев - Бином-Пресс,2008.-592 с.

3.Туманов, В.Е. Основы проектирования реляционных баз данных// В.Е. Туманов - M:ISBN, 2010.- 420 с.

.Интернет ресурс Microsoft.com

.Интернет ресурс interface.ru



Содержание Введение 1.Описание предметной области и требований к информационной системе 2. Проектирование базы данных .1 Концептуальная модель б

Больше работ по теме:

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ