Разработка структуры ООО 'Бурят-Терминал' г. Улан-Удэ в СУБД 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
|
Обязательное
поле
|
Нет
|
|
Командировочные
расходы
|
Денежный
|
Формат поля
Обязательное поле Индекс
|
Денежный Нет
Нет
|
|
Дата
поступления на работу
|
Дата/время
|
Обязательное
поле Формат поля Индекс
|
нет Краткий
формат Нет
|
|
Дата увольнения
|
Дата/время
|
Обязательное
поле Формат поля Индекс
|
нет Краткий
формат нет
|
Имя поля
|
Тип данных
|
Свойства поля
|
|
|
Свойство
|
Значение
|
|
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 услуги
|
Числовой
|
Размер поля
Обязательное поле Индекс
|
целое нет нет
|
|
|
|
|
|
Таблица 1.10 Бухгалтерия
|
Имя поля
|
Тип данных
|
Свойства поля
|
|
|
Свойство
|
Значение
|
|
Id сотрудника
|
Числовой
|
Размер поля
Обязательное поле Индекс
|
Длинное целое
Да Да(совпадения не допускаются)
|
|
Налог
|
Числовой
|
Размер поля
Обязательное поле Индекс
|
целое нет нет
|
|
Премия
|
Денежный
|
Размер поля
Обязательное поле Индекс
|
Денежный Нет
нет
|
|
Командировочные
расходы
|
Числовой
|
Размер поля
Обязательное поле Индекс
|
Длинное целое
Нет нет
|
|
№ банковского
счета
|
Текст
|
Размер поля
Обязательное поле Индекс
|
255 Нет Нет
|
|
Доход
организации
|
Числовой
|
Размер поля
Обязательное поле Индекс
|
Длинное целое
Нет нет
|
|
Форма оплаты
|
Текст
|
Размер поля
Обязательное поле Индекс
|
255 Нет Нет
|
|
Заработная
плата
|
Числовой
|
Размер поля
Обязательное поле Индекс
|
Длинное целое
Нет нет
|
|
Предоплата
|
Числовой
|
Размер поля
Обязательное поле Индекс
|
Длинное целое
Нет нет
|
.5 Реализация базы данных в СУБД MS Access
Таблица 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
Похожие работы на - Разработка структуры ООО 'Бурят-Терминал' г. Улан-Удэ в СУБД MS Access
|