Kursovaya rabota

Негосударственное образовательное учреждение
высшего образования
Московский технологический институт
Факультет: Техники и современных
технологий
Кафедра: Информатики и
автоматизации
КУРСОВАЯ РАБОТА
по дисциплине «Базы данных»
на тему:
«Система управления базами данных MS Access »
Выполнил:
Студент ___ курса
Форма обучения: заочная
Москва 2018
СОДЕРЖАНИЕ
ВВЕДЕНИЕ........................................................................................................ 4
ГЛАВА 1 ПОНЯТИЕ СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ 6
1.1
Базы данных: основные понятия ..................................................... 6
1.2
Реляционные базы данных ............................................................... 9
1.3
Функции БД ..................................................................................... 10
ГЛАВА 2 РЕЛЯЦИОННЫЕБАЗЫ ДАННЫХ .......................................... 13
2.1
Основные понятия реляционной базы данных ............................ 13
2.2
Преимущества реляционных баз данных ..................................... 14
2.3
Недостатки реляционных баз данных ........................................... 17
2.4
Реляционные СУБД ........................................................................ 19
ГЛАВА 3 АНАЛИХ
ИСПОЛЬЗУЕМЫХ
ИНФОРМАЦИОННЫХ
СИСТЕМ НА ОСНОВЕ АТС ............................................................................... 20
3.1
Анализ предметной области .......................................................... 20
3.1.1
Описание предметной области и функции решаемых задач 20
3.1.2
Перечень входных данных ....................................................... 21
3.1.3
Перечень выходных данных..................................................... 22
3.1.4
Ограничения предметной области ........................................... 22
3.1.5
Взаимодействие с другими программами............................... 22
3.2
Постановка задачи .......................................................................... 22
3.3
Разработка инфологической модели предметной области ......... 23
3.3.1
Описание бизнес-процессов предметной области ................. 23
3.3.2
Выделение
информационных
объектов.
Определение
атрибутов объектов ......................................................................................... 26
3.3.3
Определение отношений и мощности отношений между
объектами 27
3.3.4
Построение схемы инфологической модели .......................... 28
2
3.4
Разработка даталогической структуры базы данных .................. 30
3.5
Создание клиентской части приложения в Visual Studio C#. SQL-
запросы
37
3.5.1
Компоненты клиентского приложения ................................... 37
3.5.2
Результаты работы клиентского приложения ........................ 38
3.5.3
Создание SQL-запросов проектируемой БД .......................... 39
ЗАКЛЮЧЕНИЕ ............................................................................................... 44
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ ....................................... 45
ПРИЛОЖЕНИЕ 1 ЛИСТИНГ ПРОГРАММЫ ............................................. 48
3
ВВЕДЕНИЕ
Согласно ГОСТ Р 51275-2006 «Объект информатизации: совокупность
информационных ресурсов, средств и систем обработки информации,
используемых в соответствии с заданной информационной технологией, а
также
средств
их
обеспечения,
помещений
или
объектов
(зданий,
сооружений, технических средств), в которых эти средства и системы
установлены, или помещений и объектов, предназначенных для ведения
конфиденциальных переговоров» [1].
Для успешной эксплуатации АТС одну из основных ролей играет
эффективное использование подсистемы моделирования и оптимизации,
которая
обеспечивает
компанию
инструментарием
для
описания
и
оптимизации процессов выполнения различных функций.
В рамках данной работы необходимо описать понятие реляционной
системы
управления
базами
данных
(СУБД)
и
спроектировать
автоматизированную систему управления АТС.
В настоящее время практически ни одна современная организация не
обходится без использования баз данных в своей деятельности. В России нет
ни одной крупной торговой фирмы, которые не использовали бы в своей
деятельности базы данных, поэтому проектирование баз данных является
актуальной темой.
Данная тема является актуальной, так как способствует улучшению
качества обслуживания клиентов и, как следствие, повышение уровня
продаж и способствует росту оборота торговых компаний.
Цель курсовой работы – описать понятие реляционной СУБД в
теоретической части и разработать автоматизированную систему АТС в
программной части.
Задачи курсовой работы:
- дать понятие системы управления базами данных;
4
- дать понятие реляционной системы управления базами данных;
-
проанализирвоать
организационную
структуру
исследуемого
предприятия;
- проанализирвоать бизнес-процессы в технологии АТС;
- определить стратегии автоматизации технологии управления АТС;
- создать информационную систему технологии управления АТС;
изучить
-
возможности
информационной системы
и
программных
обосновать
выбор
средств
реализации
программной
среды
реализации проекта (например, MS Access, Visual C++, Java, 1C:
Предприятие и т.д.).
Объектом исследования является реляционные базы данных.
Предмет исследования –управление АТС с помощью информационной
системы.
Метод исследования – изучить текущее состояние бизнес-процессов в
АТС, изучить литературу по информационным технологиям, CASE-системам
и языкам программирования.
Работа содержит введение, 3 главы, заключение, список использованной
литературы и приложение.
При написании курсовой работы использовались научные труды
следующих авторов: Венерова А.М. [5], Вдовина В.М. [3], Золотова С.Ю. [9],
Грекул В.И. [18], Вендрова А.М. [4] и другие.
5
ГЛАВА 1
ПОНЯТИЕ СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ
ДАННЫХ
Базы данных: основные понятия
1.1
Понятие «база данных» (БД) имеет в литературе множество
определений, каждое их которых отражает по большей части субъективное
мнение автора, однако его общепризнанной единой формулировки нет.
Согласно ГОСТ Р ИСО МЭК ТО 10032-2007 база данных «совокупность данных, хранимых в соответствии со схемой данных,
манипулирование которыми выполняют в соответствии с правилами средств
моделирования данных» [2].
По мнению К. Дж. Дейта база данных - «некоторый набор
перманентных (постоянно хранимых) данных, используемых прикладными
программными системами какого-либо предприятия» [22].
Довольно часто в настоящее время используется определение М.Р.
Когаловского, гласящее, что «база данных - организованная в соответствии с
определёнными правилами и поддерживаемая в памяти компьютера
совокупность данных,
характеризующая актуальное состояние некоторой
предметной области и используемая для удовлетворения информационных
потребностей пользователей» [10].
База данных
хранится и
подвергается обработке в
какой-либо
вычислительной системе. Данные в базе данных логически структурированы
для предоставления возможности их результативного поиска и обработки.
В базу данных включаются метаданные, которые описывают в формальном
виде логическую структуру БД (схема).
«Постоянные данные в среде базы данных включают в себя схему и
базу данных. Схема включает в себя описания содержания, структуры и
ограничений целостности, используемые для создания и поддержки базы
данных. База данных включает в себя набор постоянных данных,
6
определённых с помощью схемы. Система управления данными использует
определения данных в схеме для обеспечения доступа и управления
доступом к данным в базе данных» [2].
База данных содержит информацию, упорядоченную в виде набора
записей, имеющих одинаковую структуру. Обработку записей осуществляют
специальные программы. Базы данных - часть компьютерной технологии
хранения, сортировки и поиска информации.
Система управления базами данных (СУБД) представляет собой
совокупность программных и языковых средств, осуществляющую доступ к
данным, позволяющую их создавать, изменять и удалять, обеспечивающая
безопасность данных и т.д.
«Логическую структуру хранимых в базе данных называют моделью
представления
данных.
К
основным
моделям
относятся следующие: реляционная, иерархическая,
представления данных
сетевая,
объектно-
ориентированная. Некоторые СУБД могут одновременно поддерживать
несколько моделей данных» [4].
Основными моделями баз данных являются: иерархическая, сетевая и
реляционная.
Иерархическая модель строится на основе иерархической структуры
данных, то есть у каждой записи в БД может быть любое количество
потомков, но лишь один родитель.
Сетевая модель представляет собой расширение иерархической,
предполагая наличие любого числа предков у одного потомка. Сетевые базы
данных отличаются низким уровнем быстродействия и требуют большого
количество памяти.
Широко распространены базы данных с табличной структурой. БД, в
которых имеются связанные таблицы, также называют реляционными базами
данных. Все данные в них хранятся в разных таблицах и не связаны между
собой физически. Столбцы в этих таблицах называются атрибутами или
7
полями, а строки - кортежами или записями. Структуру базы данных
образуют поля, тогда как записи - это информация, которая содержится в БД.
Неизменным правилом создания таблицы является отсутствие в ячейках
базовых таблиц вычисляемых значений. Структура каждой таблицы
разрабатываются отдельно.
Координация
выполняется
через
установление
связей
между
таблицами.
Для
обеспечения
надежной
связи
между
таблицами,
следует
предусмотреть наличие в таблице уникальных полей.
«Уникальное поле - это поле, значения в котором не могут повторяться.
Если ни одно поле таблицы не приемлемо в качестве уникального, его можно
создать искусственно. Кроме этого, существует понятие ключевого поля. При
создании структуры таблиц одно поле (или одну комбинацию полей) можно
назначить ключевым. С ключевыми полями СУБД работает особо. Она
проверяет их уникальность и быстрее выполняет сортировку по таким полям.
Ключевое поле - очевидный кандидат для создания связей. Иногда ключевое
поле называют первичным ключом» [15].
«В качестве первичного ключа в таблицах часто используют поле,
имеющее тип Счетчик. Ввести два одинаковых значения в такое поле нельзя
по определению, поскольку приращение значения поля производится
автоматически. Структура связей между таблицами называется схемой
данных» [15].
Еще один важный ключ в реляционных базах данных - внешний ключ,
представляющий собой поле одной таблицы, ссылающееся на первичный
ключ иной таблицы.
В случае использования больших таблиц, имеющих много полей, для
индексации
содержимого
таблицы
часто
оказывается
недостаточно
первичного ключа и возникает потребность в создании вторичных ключей,
или индексов. «Индекс - это средство автоматической сортировки записей в
8
таблице по значению индексируемого поля. Существует два вида индексов:
допускающие и не допускающие повторение значений поля» [15].
Использование индексов в значительной мере ускоряет работу с данными,
однако каждый индекс занимает на жестком диске и в оперативной памяти
дополнительное место.
Объектно-ориентированные
базы
данных
представляют
собой
дальнейшее развитие этого направления. В таких БД данные, имеющие
различные отношения рассматриваются как единый объект. «Поэтому
разработчик может не беспокоиться о связывании и разделении данных. В
настоящее время БД этого типа распространены сравнительно мало» [15].
Довольно часто
функции управления базами
данных, которые
запрашивают другие программы, реализуют серверы баз данных.
Средства разработки пользовательских приложений:

языки высокого программирования;

инструментальные системы;

мониторы транзакций.
1.2
Реляционные базы данных
Реляционные базы данных являются сложными коммерческими
приложениями. Если рассматривать практическое использование, текстовый
процессор является усовершенствованной пишущей машинкой. Вычисления
и построение диаграмм в электронной таблице може усвоить любой
пользователь. А работа с электронной почтой – как обычная работа с
корреспонденцией.
Реляционная модель имеет математические принципы, которые
основаны на теории множеств и логики предикатов. Эти принципы впервые
сформулировал в конце 60-х гг. доктор Е.Ф. Кодд.
Реляционная модель представляет данные двумерными таблицами,
которые называются отношениями.
9
Для хранения и манипулирования данными применяется не только
реляционная модель, но и сетевая, звездообразная, иерархическая. Каждая из
них
имеет
свои
преимущества
и
недостатки
и
применяется
для
определенного круга задач.
В общих чертах основные принципы реляционных систем баз данных
можно сформулировать так,
• Все данные на концептуальном уровне представлены строками и
столбцами и называются отношением.
• Все значения - скаляры. Любая строка и столбец любого отношения
имеет только одно значение.
•Если в операции используются целые отношения, то и результатом
выполнения операции будет целое отношение.
Реляционная база данных состоит из множества взаимосвязанных
таблиц, каждая таблица содержит информацию об объектах определенного
вида. Каждая строка таблицы содержит данные об одном объекте (например,
сотруднике, автомобиле, технике, оборудовании), а столбцы таблицы
содержат различные характеристики этих объектов - атрибуты (например,
ФИО сотрудника, Дата рождения, Специальность, Адрес проживания).
1.3
Функции БД
1) Определение структуры БД, её инициализация и выполнение
начальной загрузки.
2) Предоставление пользователям возможности манипулирования
данными (выборка, разработка интерфейса ввода-вывода, визуализация). Эти
возможности в СУБД предоставляются с помощью языка программирования,
либо интерфейса.
3) Обеспечение независимости прикладных программ и данных
(логическая и физическая независимость).
10
4) Защита логической целостности в БД. Основной целью этой функции
является достоверность данных в БД.
Целостность БД может быть нарушена при вводе противоречивых
данных в БД, а также в процессе обработки данных.
Для повышения достоверности данных в системе обрабатываются так
называемые целостности, которые позволяют отлавливать неверные данные.
Все ограничения целостности делятся на 2 класса:
1) декларативные
2) процедурные
Декларативные ограничения целостности задаются при создании и
описании структуры БД.
Процедурные ограничения целостности реализуются программным
образом.
Под
целостностью
БД
понимают
набор
правил,
позволяющих
поддерживать БД в корректном непротиворечивом состоянии.
5) Защита физической целостности
При работе компьютера возможны сбои. В связи с этим могут быть
нарушены связи с этими данными.
Современные СУБД имеют специальные средства восстановления
данных. Важным используемым понятием является транзакции – единица
действий, производимых с БД. Может состоять из одного оператора или
нескольких. Важно, что все операторы, входящие в транзакцию либо будут
выполнены, либо не будет выполнен ни один из них и произойдёт откат
транзакции.
6) Управление полномочиями пользователей на доступ к БД
Имеются ограничения на пользование данных БД. Организуются с
помощью паролей, либо полномочий (привилегий) пользователей.
7) Синхронизация работы нескольких пользователей
11
Часто возникают ситуации, когда пользователи могут работать с одними
данными. Чтобы не нарушать целостность, система не допускает обновление
данных, с которыми работает другой пользователь. Основным механизмом
является механизм блокировок.
8) Управление ресурсами среды хранения
СУБД выделяет ресурсы памяти для новых данных, перераспределяет
освобождённую память.
9. Поддержка деятельности системного персонала
В процессе эксплуатации может возникнуть необходимость изменения
параметров СУБД, выбор новых методов доступа к данным, изменение
структуры данных.
В данной главе рассмотели понятие базы данных, в частности,
реляционной базы данных, функции баз данных.
12
ГЛАВА 2 РЕЛЯЦИОННЫЕБАЗЫ ДАННЫХ
2.1
Основные понятия реляционной базы данных
Система
управления
базами
данных
(СУБД)
–
программное
обеспечение (ПО), с помощью которого пользователи могут определять,
создавать и поддерживать базу данных, а также получать к ней
контролируемый доступ [5, с. 123].
Реляционная база данных - это реализация реляционной модели
(модели данных) на физическом уровне, и потому важно четко различать два
понятия: модель данных и базу данных [1, с. 26].
Реляционная база данных создается и используется в системе
управления реляционными базами данных (СУБД). Необходимо отметить,
что реляционная СУБД функционирует так же, как и иерархическая и сетевая
СУБД, однако она состоит и из дополнительных функций, чтобы проще
реляционную модель можно было внедрять и понимать.
Хотя для реляционных баз данных нет прямых аналогий в реальном
мире, большинство их предназначено для моделирования некоторых
аспектов реальности. Именно этот «кусочек» реального мира» называется
предметной областью.
Предметная область неупорядочена, поэтому необходима реляционная
модель. Но для успешной реализации проекта необходимо ограничить
проектируемую систему определенными рамками, в которые будет входить
отдельная, четко определенная совокупность объектов и связей между ними
[1, с. 27].
Наиболее важное преимущество реляционной СУБД - возможность
оперирования человеческой логикой для пользователей и проектировщиков.
Реляционная СУБД управляет созданием физической модели базы данных.
Именно поэтому реляционная БД представляет пользователю набор таблиц,
хранящий данные.
13
Каждая таблица - это матрица, содержащая набор пересекающихся
строк и столбцов. Каждая таблица называется отношением, в зависимости от
свойств объекта связаны друг с другом. Например, таблица Заказ содержит
список клиентов из таблицы Клиент.
Реляционная
модель
даёт
возможность
вести
контрольнад
избыточностью данных, и если таковая имеется в системах файлов, устраняет
её.
В СУБД каждый объект – это сущность. Реляционная таблица хранит
наборы сущностей, связанных логически между собой. В этих связях таблица
БД схожа с файлом. Однако есть очень важное отличие: в таблице данные
полностью независимы, а также структурно независимы, так как являются
логической структурой. Пользователь и проектировщик совершенно не
думает отом, как данные физически располагаются в базе данных; здесь
принимается во внимание, как они представляют структуру данных. Именно
это свойство в реляционной моделе произвело настоящую революцию в
базах данных.
2.2
Преимущества реляционных баз данных
Э. Кодд (Е. F. Codd, компания IBM) предложил реляционную модель,
которая стала настоящим прорывом и для пользователя,
и для
проектировщика. Если сравнить с автомобилем, реляционная модель имела
"автоматическую коробку передач", а иерархические и сетевые модели имели
"ручную коробку передач". Концептуальная простота реляционной базы
данных произвела подлинную революцию в сфере баз данных.
Открытие Э. Кодда в 70-х годах прошлого столетия считалось весьма
остроумным, но абсолютно непрактичным. Концептуальное построение
реляционной модели строится с
использованием ресурсов компьютера,
который в то время не имел достаточной мощности, чтобы реализовать
реляционную модель. К настоящему времени, к счастью, возможности
14
компьютеров
стремительно
выросли,
и
увеличилась
эффективность
операционных систем. Следует отметить, что стоимость аппаратных
устройств компьютера снижалась намного быстрее, чем возрастали ее
возможности. На сегодняшний день даже настольные персональные
компьютеры, по возможностям намного уступающием мощным серверам,
могут позволить себе установку и работу с такими реляционными системами
управления базами данных, как InterBase, MySQL, Informix, Oracle, Ingress,
DB2 и др.
Считается, что сильной стороной реляционных баз данных является
развитая математическая теория, лежащая в их основе - реляционная алгебра.
Саом слово «реляционная» происходит от англ. relation - отношение. Но в
случае реляционных баз слово «отношение» выражает не взаимосвязь между
таблицаи-сущностями, а определение самой таблицы как математического
отношения доменов [2, с.22]
В общих чертах основные принципы реляционных систем баз данных
можно сформулировать так:
- Все данные на концептуальном уровне представляются в виде
упорядоченной организации, определенной в видестрок и столбцов и
называемой отношением.
- Все значения являются скалярными. Это означает, что для любой
строки и столбца любого отношения существует одно и только одно
значение.
- Все операции выполняются над целым отношением, и результатом
выполнения этих операций также является целое отношение [1, с. 34].
Как иерархические и сетевые БД, реляционные базы данных являются
единым хранилищем данных, которые обеспечивают их независимость. Но
реляционная БД имеет дополнительные преимущества.
• Структурная независимость. Так как реляционная модель базы
данных не использует навигационную схему доступа к данным, то путь
15
доступа к данным не обязателен для проектировща, программиста и
конечного пользователя реляционной БД. Если изменяется структура
реляционной базы данных, то этот факт ни в коем случае не влияет на доступ
к данным системы урпвления базами данных. По этой причине реляционная
модель базы данных имеет структурную независимость, не свойственную
сетевой и иерархической моделям.
• Концептуальная схема. Система файлов имеет более сложную
структуру, чем иерархическая и сетевая модели, а концептуальный уровень
реляционной модели еще более прост для понимания. Так как в реляционной
модели не рассматриваются подробности физического хранения данных,
программист или пользователь может полностью рассматривать только
логическое представление базы данных, т. е. больше рассматривается наше
естественное представление о хранении данных, а не популярный, но
"трудно постижимомый" метод "взгляда" на БД со стороны компьютера.
• Проектирование, реализация, управление и использование четкое,
понятное, простое. Поскольку реляционная модель независима по данным, и
структурно независима, проектирование базы и управление ее содержимым
становится проще.
• Нерегламентированные запросы. Есть ещё одни немаловажный
фактор, почему реляционные БД занимают доминирующее положение на
рынке - мощная и гибкая возможность создания запросов. Большая часть
программного обеспечения реляционных баз данных имеет стандартный
структурированный язык запросов
Structured Query Language (SQL).
Программисты и проффесионалы даже создали такой стишок "реляционная
модель применяет SQL", который применяют и на встречах, и в
компьютерных журналах. Благодаря SQL язык структурированных запросов
стал реальностью. В реляционной СУБД язык SQL используют, когда
транслируется запрос пользователя в специальный код для того, чтобы
извлечь запрошенную информацию. Вывод - любой запрос в реляционной БД
16
создается с минимальным программированием, в отличие от любой другой
базы или среды системы файлов.
Любое SQL-приложение базы данных
состоит из интерфейса
пользователя, набора таблиц внутри программы и SQL-машины. Интерфейс
состоит из системы меню, операций запросов и генераторов отчетов.
Благодаря такому интерфейсу конечный пользователь взаимодействует с
данными. Существуют генераторы приложений, являющиеся в настоящее
время стандартным программным обеспечением БД.
То, какой объем работы выполняет SQL-машина, практически скрыто
от конечного пользователя. SQL находится внутри реляционной СУБД и
предназначено, чтобы создавать структуру таблиц, обслуживать словарь
данных и системный каталог, обеспечивать доступ к таблицам базы данных,
а также чтобы транслировать запросы пользователя в формат, который
пригоден для компьютера. Обслуживать систему базы данных - важнейшая
задача, которую выполняет реляционная СУБД.
Хорошая реляционная СУБД имеет более сложное программное
обеспечение, чем СУБД иерархической и сетевой БД. Это потому, что
РСУБД выполняет намного большие задачи (и значительно более сложные) и
для проектировща, и для пользователя.
В результате и проектировщик, и пользователь в хорошей РСУБД не
видят физического уровня сложности системы.
Поэтому, так как реляционная СУБД выполняет скрытую работу
управления оборудованием, то не рассматриваются физические аспекты
реляционной базы данных.
2.3
Недостатки реляционных баз данных
Если рассматривать реляционную, сетевую и иерархическую базы
данных, то реляционная БД в значительной мере превосходит остальные и
имеет значительные достоинства. Однако недостатки тоже имеются.
17
К основным недостаткам реляционной модели относятся отсутствие
стандартных средств идентификации отдельных записей и сложность
описания иерархических и сетевых связей [11, с.8].
Основные недостатки:
- Оборудование и системное программное обеспечение должно быть на
высоком уровне. Для реляционной СУБД, скрывающей от глаз пользователя
всё самое сложное, необходимы значительные системные и аппаратные
ресурсы. Чтобы решить все необходимые задачи реляционной СУБД,
необходим достаточно мощный компьютер. То есть, если взять работу трех
СУБД с равными условиями, то реляционная база данных будет
обрабатывать информацию значительно медленнее, чем иерархическая или
сетевая. Но надо учитывать и возможности современного оборудования и
постоянное развитие операционных систем, поэтому вышеописанное не
является таким уж сильным недостатком.
- "Скороспелые" проекты и реализации. По понятным причинам удобно
и просто использовать среду разработки реляционных БД, однако этом факт
может быть и источником неприятностей. Реляционная СУБД, особенно
используемая
в
настольных
компьютерах,
настолько
просто
в
использовании, что относительно малознающий пользователь может легко
создавать сложнейшие таблицы, формы, отчеты, и, наконец, запросы без
проектирования базы данных. Увеличиваясь в размерах, база данных без
достатоного проектирования начинает замедлять работу системы и может
привести к нарушению целосности данных.
- Возможность создания "информационных островков". Так как реляционную базу данных легко использовать, много пользоватлей создают
собственные программы и приложения для баз данных. Хоть это и хорошо,
когда конечный пользователь работает автономно, когда он запрашивает
данные из общей базы данных, этот факт может стать причиной, что будут
разрабатываться подмножества базы данных, создаваемые подразделениями
18
или отдельными лицами. Появляются так называемые "информационные островки", свойственные системам файлов, в которых наблюдается несовместимость данных, что приводит к проблеме структурирования данных и ее верификации.
Все же реляционная база данных имеет очень мало несущественных
недостатков, поэтому реляционные БД существенно доминируют на рынке
баз данных.
заставляет
Но расслабляться не стоит - возрастание сложности ИС
профессиональных
разработчиков
искать
альтернативные
концепции моделирования данных. Важное внимание при развитии моделей
акцентируют на визуальный компонент.
2.4
Реляционные СУБД
В отличие от ранних систем баз данных, пользователю реляционной
СУБД вовсе не требуется знать об особенностях организации хранения
информации на носителе. Запросы к такой базе данных выражаются
средствами высокоуровневого языка, позволяющего значительно повысить
эффективность работы программиста [8, с.34].
Примерами зарубежных реляционных СУБД для ПЭВМ являются:
DB2, Paradox, FoxPro, Access, Clarion, Ingres, Oracle.
К отечественным СУБД реляционного типа относятся системы
ПАЛЬМА и HyTech [6, с.10].
Ознакомились с понятием реляционной базы данных. Рассмотрели
достоинства и недостатки реляционных баз данных.
19
ГЛАВА 3 АНАЛИХ ИСПОЛЬЗУЕМЫХ ИНФОРМАЦИОННЫХ
СИСТЕМ НА ОСНОВЕ АТС
3.1
Анализ предметной области
3.1.1 Описание предметной области и функции решаемых задач
Рассмотрим построение информационной системы для городсой
телефонной сети.
Предметной областью автоматизации являются должностные функции
работника АТС.
ГТС представляет собой разветвленную сеть локальных АТС. АТС
подразделяются на городские, ведомственные и учрежденские и возможно
обладают характерными только для этой группы набором атрибутов.
У каждой АТС есть свои абоненты. У абонента можест стоять телефон
одного из трех типов (основной, параллельный или спаренный). За каждым
абонентом (у него есть фамилия, имя, отчество, пол, возраст и т.д.) закреплен
свой номер телефона, причем у нескольких абонентов может быть один и тот
же номер (при параллельном и спаренном телефоне). Каждому номеру
телефона свидетельствует адрес (индекс, район, улица, дом, квартира),
причем параллельные или спаренные телефоны обязательно должны
находится в одном доме.
Все телефоны городской АТС имеют выход на межгород, но для
конкретного абонента он может быть либо открыт, либо закрыт по какой либо причине (отключен по желанию абонента, за неуплату и т.д.).
Ведомственные и учрежденские АТС имеют свою внутреннюю замкнутую
сеть телефонов. Сведения о междугородных переговорах собираются и
анализируются га ГТС.
Абоненты обязаны платить абоненскую плату. Плата должна вносится
каждый месяц до 20-го числа.
20
3.1.2 Перечень входных данных
Входную информацию делят на условно-постоянную, сохраняющую
свои значения на длительный период времени, и на постоянно меняющуюся
оперативно-учетную.
В результате обследования предметной области определены входные
данные, необходимые для решения комплекса задач учета абонентов и всех
телефонов городской АТС.
Поэтому при разработке базы данных необходимо создать формы для
ввода этой информации.
Входная
информация
может
быть
представлена
следующими
документами:
Абонент № _______
Дата оплаты __________
АТС _________________________________
№
п/п
1
Вид платы
Тариф
Стоимость
2
3
4
Принял к оплате________________ _______________________
(подпись)
(расшифровка подписи)
Завизировал_____________ _______________________
(подпись)
(расшифровка подписи)
Таблица 1 – Входные данные по абоненту
Код
абонента
…
ФИО
…
Телефон
…
Адрес
…
Таблица 2 – Входные данные по телефонам
Код
Телефон Индекс
телефона
…
…
…
Район
Город
…
21
Улица
Дом
Квартира
3.1.3 Перечень выходных данных
Выходная информация представляется в виде отчетов.
Выходную информацию представим в виде следующих отчетных
форм:
-отчет «Абоненты»: код абонента, ФИО, пол, дата рождения, адрес,
телефон,
тип
телефона,
выход
на
межгород,
категория.
Отражает
информацию об абонентах АТС.
- отчет «Телефоны»: код телефона, телефон, индекс, район, город,
улица, дом, квартира. Отражает информацию о телефонах АТС.
3.1.4 Ограничения предметной области
По
рассматриваемой
предметной
области
введем
некоторые
ограничения:

В таблице «Тарифы» значение поля «Стоимость» должно быть больше
нуля.

В таблице «Абоненты» значение поля «Выход на межгород» должно
быть логическим (да или нет).
3.1.5 Взаимодействие с другими программами
Представленная информационная система должна выводить отчеты в
текстовый редактор MS Word. Таблица Абонентская плата может выводится
в MS Excel.
3.2
Постановка задачи
Разрабатываемая
информационная
система
предназначена
для
структурированного хранения данных и вывода информации о абонентской
плате и абонентах на АТС.
Разрабатываемая
информационная
система
следующие функции:

Добавление информации о телефонах.
22
должна
выполнять

Добавление абонентов.

Оформление абоненской платы.

Осуществлять поиск абонентов по номеру телефона.

Оформление данных по абонплате абонентов.

Отображение сводной информации по абонентам АТС.
3.3
Разработка инфологической модели предметной области
3.3.1 Описание бизнес-процессов предметной области
Для описания бизнес-процессов предметной области сформируем
схемы IDEF0 в программе BPWin с различным уровнем детализации.
Блок А0 – Функционирование телефонной сети. Вход - заявка
абонента, договор. Управление - юридический документ, договор. Механизм
- менеджер, клиент, сотрудники. Выход - предоставленные услуги, договор
(рис. 1).
Рисунок 1 – Функционирование телефонной системы
В блок А0 входят блоки А1, А2.
23
Блок А1 - Договор. Вход - заявка клиента. Управление - юридический
документ. Механизм - менеджер. Выход – заявка на установку.
Блок А2 –Установка. Вход – заявка на установку. Управление договор. Механизм - сотрудники. Выход - предоставленные услуги (рис. 2).
Рисунок 2 – Установка
Блок А1 в свою очередь подразделяется на блоки А11, А12.
Блок А11 – Звонок в компанию. Вход - заявка клиента. Управление юридический документ. Механизм - менеджер. Выход - запрос на
заключение договоров.
Блок А12 – Заключение договора. Вход - запрос на заключение
договоров. Управление - юридический документ. Механизм - менеджер.
Выход – договор (рис. 3).
24
Рисунок 3 – Заключение договора
Блок А2 подразделяется на блоки А21, А22,А23.
Блок А21 – Назначение номера. Вход – договор. Управление – договор.
Механизм – сотрудники. Выход – заявка на монтаж.
Блок А22 – Прокладка линий. Вход – заявка на монтаж. Управление –
договор. Механизм – сотрудники. Выход – подключение аппаратуры и узлов.
Блок А23 – Тестирование системы. Вход – подключение аппаратуры и
узлов.
Управление
–
договор. Механизм
предоставленные услуги (рис. 4).
25
–
сотрудники.
Выход
–
Рисунок 4 – Тестирование системы
3.3.2 Выделение
атрибутов объектов
На
основе
информационных
бизнес-процессов
объектов.
предметной
Определение
области
выделим
информационные объекты и их атрибуты. Выделяем объекты-сущности
«Телефоны»,
«Тип
телефона»,
«Тарифы»,
«Абоненты»,
«Категории
абонентов», «АТС», «Абоненская плата».
Рассмотрим атрибуты перечисленных объектов.
Таблица 3 – Атрибуты объектов
Объект
«Абоненты»
«Телефоны»
«АТС»
«Категории абонентов»
«Тарифы»
«Тип телефона»
Атрибуты объектов
Код абонента, ФИО абонента, Пол, Дата
рождения, Телефон, Тип телефона, Выход на
межгород, Категория
Код телефона, Телефон, Индекс, Район,
Улица, Дом, Квартира
Код АТС, Название АТС
Код категории, Категория
Код тарифа, Вид оплаты, Стоимость
Код типа, Тип телефона
26
«Абоненская плата»
«Абоненты АТС»
Необходимо
Код платы, Абонент, Дата оплаты, Тариф
Код абонента, Код АТС, Выход на межгород
проанализировать
каждый
атрибут
на
наличие
взаимосвязей с другими реквизитами объекта. Реквизит приобретает смысл
только тогда, когда он связан с другими атрибутами, обладающими
смысловым единством.
3.3.3 Определение отношений и мощности отношений между
объектами
Рассмотрим взаимосвязи между объектами и мощности отношение и
построим матрицу отношений.
«Тарифы» -> «Абоненская плата». «Тарифы» главный объект, а
«Абоненская плата» подчинѐнный объект. Тип связи «один ко многим»
(Рисунок 5). Так как по одному тарифу могут быть несколько абоненских
плат. Связь между этими объектами осуществляет атрибут «код_тарифа».
Тарифы
Абоненская плата
1:N
Рисунок 5 – Связь между объектами «Тарифы» и «Абоненская плата»
«Телефоны»
->
«Абоненты».
«Телефоны»
главный
объект,
а
«Абоненты» подчинѐнный объект. Тип связи «один ко многим» (Рисунок 8).
Одна телефон может быть у нескольких абонентов. Связь между этими
объектами осуществляет атрибут «код_телефона».
Телефоны
Абоненты
1:N
Рисунок 6 – Связь между объектами «Телефоны» и «Абоненты»
«Тип телефона» -> «Абоненты». «Тип телефона» главный объект, а
«Абоненты» подчинѐнный объект. Тип связи «один ко многим» (Рисунок 7).
Один тип телефона может быть у нескольких абонентов. Связь между этими
объектами осуществляет атрибут «код_типа».
27
Тип телефона
Абоненты
1:N
Рисунок 7 – Связь между объектами «Тип телефона» и «Абоненты»
Абоненты ->Абоненская плата. «Абоненты» главный объект, а
«Абоненская плата» подчинѐнный объект. Тип связи «один ко многим»
(Рисунок 8). Множество абонплат может быть у одного абонента. Связь
между этими объектами осуществляет атрибут «код_абонента».
Абоненты
Абонплата
1:N
Рисунок 8 – Связь между объектами «Абоненты» и «Абоненская плата»
«Категории»
->
«Абоненты».
«Категории»
главный
объект,
а
«Абоненты» подчинѐнный объект. Тип связи «один ко многим» (Рисунок 9).
Одна категория может быть у нескольких абонентов. Связь между этими
объектами осуществляет атрибут «код_категории».
Категория телефона
Абоненты
1:N
Рисунок 9 – Связь между объектами «Категория телефона» и
«Абоненты»
3.3.4 Построение схемы инфологической модели
На основе полученных объектов, атрибутов объектов и отношений
между ними, можно построить инфологическую модель (Рисунок 10)
28
Рисунок 10 – Инфологическая модель БД
Каждая сущность логической схемы должна быть представлена
таблицей реляционной базы данных, в которой каждый столбец - это атрибут
сущности. На каждую таблицу составляется описание логической структуры,
в ней определяются основные характеристики каждого поля (атрибута)
таблицы, значения характеристик будут использованы при создании базы
данных в конкретной СУБД.
Сущности с атрибутами и с характеристиками каждого поля «АТС»
(Рисунок 11):
Рисунок 11 – Сущности с атрибутами и с характеристиками каждого поля
«АТС»
29
3.4
Разработка даталогической структуры базы данных
Даталогическая структура реляционной базы данных определяется
совокупностью логически связанных реляционных таблиц.
Логические
связи
соответствуют
структурным
связям
между
объектами в концептуальной модели, каждый объект в логической модели
отображается соответствующей реляционной таблицей.
Связи
между
таблицами
осуществляются
посредством
общих
атрибутов. Таблица 4 содержит информацию о АТС (автоматизированных
телефонных сетях).
Таблица 4 – Описание логической структуры таблицы «АТС»
Признак
ключа
Имя поля
Тип данных
поля
Длина
Pk
Код АТС
Счетчик
Длинное
целое
Точность
числа
ограничения
Авто
>0
Название АТС
Таблица 5 содержит информацию об абонентской плате.
Таблица 5 – Описание логической структуры таблицы «Абонентская
плата»
Имя
Признак поля
ключа
Тип
поля
данных
Длина
Точность
числа
ограничения
Pk
Код платы
Счетчик
Длинное целое
-
-
Fk
Абонент
Числовой
Длинное целое
Авто
>0
Fk
-
Дата
оплаты
Тариф
Цена
Дата/время
Числовой
Денежный
Длинное целое
Денежный
Авто
Авто
>0
-
Таблица 6 содержит информацию об абонентах.
Таблица 6 – Описание логической структуры таблицы «Абоненты»
30
Имя
Признак поля
ключа
Тип
поля
данных
Код абонента Счетчик
Pk
ФИО
Текстовый
Пол
Текстовый
Дата
оплаты
Дата/время
Категория
Числовой
Телефон
Текстовый
Выход
на
межгород
Логический
Тип телефона Числовой
Fk
-
Fk
Длина
Точность
числа
ограничения
Длинное целое
-
-
Длинное целое
50
Авто
-
>0
-
Длинное целое
Авто
>0
50
1
Таблица 7 содержит информацию о категориях абонентов.
Таблица 7 – Описание логической структуры таблицы «Категории
абонентов»
Признак
ключа
Имя поля
Pk
Код абонента Счетчик
Категория
Тип данных
поля
Текстовый
Длина
Длинное
целое
50
Точность
числа
ограничения
Авто
>0
Таблица 8 содержит информацию о типах телефона.
Таблица 8 – Описание логической структуры таблицы «Типы
телефонов»
Признак
ключа
Имя поля
Тип данных
поля
Длина
Pk
Код типа
Счетчик
Длинное
целое
50
Тип телефона
Текстовый
Точность
числа
ограничения
Авто
>0
Таблица 9 содержит информацию о тарифах.
31
Таблица 9 – Описание логической структуры таблицы «Тарифы»
Признак
ключа
Имя поля
Тип данных
поля
Длина
Pk
Код тарифа
Счетчик
Длинное
целое
50
Длинное
целое
Fk
Вид оплаты
Текстовый
Стоимсоть
Числовой
Точность
числа
ограничения
Авто
>0
Авто
>0
Таблица 10 содержит информацию о телефонах.
Таблица 10 – Описание логической структуры таблицы «Телефоны»
Имя
Признак поля
ключа
Pk
Тип
поля
данных
Код телефона Счетчик
Телефон
Индекс
Район
Город
улица
Дом
Квартира
Текстовый
Текстовый
Текстовый
Текстовый
Текстовый
Текстовый
Текстовый
Длина
Точность
числа
ограничения
Длинное целое
-
-
-
-
50
10
50
50
50
50
50
При создании БД в СУБД ACCESS были созданы таблицы, которые
заполнялись данными.
В таблице «Телефоны» созданы следующие поля и заданы типы
данных (Рисунок 12):
32
Рисунок 12 – Таблица «Телефоны» в режиме конструктора
Затем был выполнен ввод данных в таблицу «Телефоны» (Рисунок 13).
Рисунок 13 – Таблица «Телефоны» с введенными данными
В таблице «Абонентская плата» созданы следующие поля и заданы
типы данных (Рисунок 15):
Рисунок 14 – Таблица «Абонентская плата» в режиме конструктора
Затем был выполнен ввод данных в таблицу «Абонентская плата»
(Рисунок 13).
33
Рисунок 15 – Таблица «Абонентская плата» с введенными данными
В таблице «Абоненты» созданы следующие поля и заданы типы
данных (Рисунок 16):
Рисунок 16 – Таблица «Абоненты» в режиме конструктора
Затем был выполнен ввод данных в таблицу «Абоненты» (Рисунок 17).
34
Рисунок 17 – Таблица «Абоненты» с введенными данными
В таблице «АТС» созданы следующие поля и заданы типы данных
(Рисунок 18):
Рисунок 18 – Таблица «АТС» в режиме конструктора
Затем был выполнен ввод данных в таблицу «АТС» (Рисунок 19).
Рисунок 19 – Таблица «АТС» с введенными данными
В таблице «Категории абонентов» созданы следующие поля и заданы
типы данных (Рисунок 20):
Рисунок 20 – Таблица «Категории абонентов» в режиме конструктора
Затем был выполнен ввод данных в таблицу «Категории абонентов»
(Рисунок 21).
35
Рисунок 21 – Таблица «Категории абонентов» с введенными данными
В таблице «Тарифы» созданы следующие поля и заданы типы данных
(Рисунок 22):
Рисунок 22 – Таблица «Тарифы» в режиме конструктора
Затем был выполнен ввод данных в таблицу «Тарифы» (Рисунок 23).
Рисунок 23 – Таблица «Тарифы» с введенными данными
В таблице «Тип телефона» созданы следующие поля и заданы типы
данных (Рисунок 24):
Рисунок 24 – Таблица «Тип телефона» в режиме конструктора
Затем был выполнен ввод данных в таблицу «Тип телефона» (Рисунок
25).
Рисунок 25 – Таблица «Тип телефона» с введенными данными
36
Также была сформирована схема связей данных, которая находится во
вкладке "Работа с базой данных"-> "Схема данных". Изображение схемы
находится на рисунке 26.
Рисунок 26 – Схема связей данных в СУБД ACCESS
3.5 Создание клиентской части приложения в Visual Studio C#.
SQL-запросы
Описать способ подключения клиентсконо приложения Visual
Studio C# к базе данных Access. Отобразить разработанные формы
клиентсконо приложения для работы с базой данных.
3.5.1 Компоненты клиентского приложения
На
форму
приложения
был
добавлен
компонент
TabControl,
позволяющий использовать вкладки для упрощения пользования программой
(Рисунок 15).
37
Рисунок 15 – Внутреннее построение приложения
На каждой из вкладок были добавлены компоненты Dataset,
BindingSource, DataGridView, BindingNavigator (два последних являются
визуальными компонентами, первый из них служит для интуитивно
понятного переключения между ячейками таблиц, а второй отображает
таблицы, которые сохранены в БД ACCESS). В событии FormLoad
прописаны команды загрузки таблиц из БД.
3.5.2 Результаты работы клиентского приложения
После
настройки компонентов визуализации таблицы БД на
каждой
вкладке, программа отображает записи таблицы БД. Таблица «Материалы»
показана на рисунке
Рисунок 16 - Таблица «Материалы»
38
3.5.3 Создание SQL-запросов проектируемой БД
Кроме того, была создана одна дополнительная вкладка "Запросы",
которая помимо обычных компонентов содержит 5 кнопок, для каждой из
которых была написана процедура, выполняющая определенный SQL-запрос.
Далее приведены примеры SQL кода в процедурах (полный код в
приложении):
1. Запрос «Общее число абонентов по полу»:
SQL-код:
SELECT Абоненты.Пол, Count(Абоненты.[ФИО абонента]) AS [CountФИО абонента]
FROM Абоненты
GROUP BY Абоненты.Пол;
Результат выполнения запроса показан на рисунке .
2. Запрос «Общее число свободных номеров»:
SQL-код:
SELECT Count(Телефоны.Телефон) AS [Count-Телефон]
FROM Телефоны LEFT JOIN Абоненты ON Телефоны.[Код телефона]
= Абоненты.[Телефон]
GROUP BY Абоненты.Телефон
HAVING (((Абоненты.Телефон) Is Null));
3. Запрос «Перечень должников на указанной АТС»:
SQL-код:
SELECT
Абоненты.[ФИО
абонента],
АТС.[Название
АТС],
[Абоненская плата].[Дата оплаты], Day([Абоненская плата]![Дата оплаты])
AS [День оплаты]
FROM АТС INNER JOIN ((Абоненты INNER JOIN [Абоненская плата]
ON Абоненты.[Код абонента] = [Абоненская плата].Абонент) INNER JOIN
[Абоненты АТС] ON Абоненты.[Код абонента] = [Абоненты АТС].[Код
абонента]) ON АТС.[Код АТС] = [Абоненты АТС].[Код АТС]
39
WHERE (((АТС.[Название АТС])=[Введите название АТС]) AND
((Day([Абоненская плата]![Дата оплаты]))>20));
4. Запрос «АТС с самым большим числом должников»:
SQL-код:
SELECT TOP 1 [3_Перечень должников по типам АТС].[Название
АТС], Count([3_Перечень должников по типам АТС].[ФИО абонента]) AS
[Count-ФИО абонента]
FROM [3_Перечень должников по типам АТС]
GROUP BY [3_Перечень должников по типам АТС].[Название АТС]
ORDER BY Count([3_Перечень должников по типам АТС].[ФИО
абонента]) DESC;
5. Запрос «Перечень таксофонов во всем городе»:
SQL-код:
SELECT
АТС.[Название
АТС],
Районы.Район,
Count(Таксофоны.[Номер таксофона]) AS [Count-Номер таксофона]
FROM АТС INNER JOIN (Районы INNER JOIN Таксофоны ON
Районы.[Код
района]
=
Таксофоны.Район)
ON
АТС.[Код
АТС]
=
Таксофоны.АТС
GROUP BY АТС.[Название АТС], Районы.Район;
6. Запрос «Количество абонентов на каждой АТС»:
SQL-код:
SELECT АТС.[Название АТС], Count([Абоненты АТС].[Код абонента])
AS [Count-Код абонента]
FROM АТС INNER JOIN (Абоненты INNER JOIN [Абоненты АТС] ON
Абоненты.[Код абонента] = [Абоненты АТС].[Код абонента]) ON АТС.[Код
АТС] = [Абоненты АТС].[Код АТС]
GROUP BY АТС.[Название АТС];
7. Запрос «Перечень абонентов с параллельными телефонами по всей
ГТС»:
40
SQL-код:
SELECT Абоненты.[ФИО абонента], [Тип телефона].[Тип телефона]
FROM [Тип телефона] INNER JOIN (Абоненты INNER JOIN
[Абоненты АТС] ON Абоненты.[Код абонента] = [Абоненты АТС].[Код
абонента]) ON [Тип телефона].[Код типа] = Абоненты.[Тип телефона]
WHERE ((([Тип телефона].[Тип телефона])="параллельный"));
8. Запрос «Количество абонентов с выхоом на межгород»:
SQL-код:
SELECT Count([Абоненты АТС].[Выход на межгород]) AS [CountВыход на межгород]
FROM [Абоненты АТС]
HAVING (((Count([Абоненты АТС].[Выход на межгород]))=Yes));
9.
Запрос
«Город
с
большим
количеством
междугородных
переговоров»:
SQL-код:
SELECT
TOP
1
Телефоны.Город,
Count(Абоненты.[Выход
на
межгород]) AS [Count-Выход на межгород]
FROM Телефоны INNER JOIN ((Абоненты INNER JOIN [Абоненская
плата] ON Абоненты.[Код абонента] = [Абоненская плата].Абонент) INNER
JOIN [Абоненты АТС] ON Абоненты.[Код абонента] = [Абоненты АТС].[Код
абонента]) ON Телефоны.[Код телефона] = Абоненты.Телефон
GROUP BY Телефоны.Город
ORDER BY Count(Абоненты.[Выход на межгород]) DESC;
10. Запрос «Информация об абонентах с заданным номером телефона»:
SQL-код:
SELECT
Телефоны.Телефон,
Абоненты.[Код
абонента],
Абоненты.[ФИО абонента], Абоненты.Пол, Абоненты.[Дата рождения],
Абоненты.[Тип
телефона],
Абоненты.[Выход
Абоненты.Категория
41
на
межгород],
FROM Телефоны INNER JOIN Абоненты
ON Телефоны.[Код
телефона] = Абоненты.Телефон
WHERE (((Телефоны.Телефон)=[Введите номер телефона]));
11. Запрос «Перечень спаренных телефонов»:
SQL-код:
SELECT
DISTINCT
[Тип
телефона].[Тип
телефона],
Телефоны.Телефон
FROM [Тип телефона] INNER JOIN (Телефоны INNER JOIN Абоненты
ON Телефоны.[Код телефона] = Абоненты.Телефон) ON [Тип телефона].[Код
типа] = Абоненты.[Тип телефона]
WHERE ((([Тип телефона].[Тип телефона])="спаренный"));
12. Запрос «Перечень телефонов в ведомствах и учреждениях АТС»:
SQL-код:
SELECT АТС.[Название АТС], Телефоны.Телефон
FROM АТС INNER JOIN ((Телефоны INNER JOIN Абоненты ON
Телефоны.[Код телефона] = Абоненты.Телефон) INNER JOIN [Абоненты
АТС] ON Абоненты.[Код абонента] = [Абоненты АТС].[Код абонента]) ON
АТС.[Код АТС] = [Абоненты АТС].[Код АТС]
WHERE (((АТС.[Название АТС])="учрежденская" Or (АТС.[Название
АТС])="ведомственная"));
13. Запрос «Перечень должников»:
SQL-код:
SELECT
Абоненты.[ФИО
абонента],
АТС.[Название
АТС],
[Абоненская плата].[Дата оплаты], Day([Абоненская плата]![Дата оплаты])
AS [День оплаты]
FROM АТС INNER JOIN ((Абоненты INNER JOIN [Абоненская плата]
ON Абоненты.[Код абонента] = [Абоненская плата].Абонент) INNER JOIN
[Абоненты АТС] ON Абоненты.[Код абонента] = [Абоненты АТС].[Код
абонента]) ON АТС.[Код АТС] = [Абоненты АТС].[Код АТС]
42
WHERE (((Day([Абоненская плата]![Дата оплаты]))>20));
Рисунок 17 – Запрос «Количество более 1000»
43
Заключение
Проделанная работа позволяет любому пользователю хранить большие
объёмы информации, обрабатывать их, сортировать, делать выборки по
определённым
критериям.
Разработанная
база
данных
может
быть
использована в работе городской телефонной сети.
База данных была разработана с помощью СУБД Microsoft Access 2010,
а клиентское приложение для работы с базой данных на языке
программирования C# VISUAL STUDIO 2010. Реализован учет абонентов и
абонентской платы.
Цель, поставленная перед началом выполнения курсовой работы,
достигнута.
Данная база данных обладает рядом преимуществ и недостатков.
Преимуществами являются:
- легкость и удобство в исполнении;
- широкие возможности расширения базы данных;
- быстрый поиск необходимых данных;
- легко переносится с одного компьютера на другой;
- возможность редактирования результатов запросов.
Недостатками являются:
- очень громоздкие базы данных;
- не очень высокий уровень безопасности.
Автоматизация рабочего места позволит:

вводить и корректировать данные о телефонах АТС;

формировать
и
выдавать
документов;
44
различные
формы
выходных
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ
1.
Балдин К. В. Информационные системы в экономике [Электронный
ресурс] : учебник / К. В. Балдин, В. Б. Уткин. - 7-е изд. - Москва : Дашков и
К°, 2012. - 395 с. – ISBN 978-5-394-01449-9.
2.
Буренин
С.
Н.
Web-программирование
и
базы
данных
[Электронный ресурс] : учеб. практикум / С. Н. Буренин. - Москва : Моск.
гуманит. ун-т, 2014. - 120 с. - ISBN 978-5-906768-17-9.
3.
Вдовин
В.
М.
Предметно-ориентированные
экономические
информационные системы [Электронный ресурс] : учебное пособие / В. М.
Вдовин, Л. Е. Суркова, А. А. Шурупов. - 3-е изд. - Москва : Дашков и К°,
2013. - 388 с. : ил. - ISBN 978-5-394-02262-3.
4.
Вендров А. М. CASE-технологии: Современные методы и средства
проектирования информационных систем. [Текст] / М.: Финансы и
статистика, 2013 – 176 стр.
5.
Вендров А. М., Практикум по проектированию программного
обеспечения экономических информационных систем: Учеб. пособие. – 2-е
изд., перераб. и доп. [Текст] / М.: Финансы и статистика, 2013 – 192 стр.
6.
Гагарина Л.Г. Технология разработки программного обеспечения:
учебное пособие [текст] / Л.Г.Гагарина, Е.В. Кокорева, Б.Д. Виснадул. – М.:
ИД «ФОРУМ»: ИНФРА-М, 2016. – 400 с.
7.
Годин В. В., Корнев И. К. Информационное обеспечение
управленческой деятельности: Учебник. — М.: Мастерство: Высшая школа,
2016. -213с.
8.
Грекул В. И.Проектирование информационных систем [Текст] :
Курс лекций. Учеб. пособие для вузов / В.И.Грекул. - М. : ИНТУИТ.ru
(Интернет-Ун-т Информ. Технологий),2005. - 304 с.
9.
Золотов
С.
Ю.
Проектирование
информационных
систем
[Электронный ресурс] : учеб. пособие / С. Ю. Золотов ; Томский гос. ун-т
45
систем управления и радиоэлектроники. - Томск : Эль Учебное пособие
Контент, 2013. - 86 с. - ISBN 978-5-4332-0083-8.
10. Калянов, Г.Н.
Моделирование,
анализ,
реорганизация
и
автоматизация бизнес-процессов : учеб. пособие для вузов / Г.Н. Калянов. –
М. : Финансы и статистика, 2006. – 240 с.
11. Карпова И. П. Базы данных : курс лекций и материалы для практ.
занятий : учеб. пособие для студентов техн. фак. / И. П. Карпова. - СанктПетербург : Питер, 2013. - 240 с. : ил. - (Учебное пособие). - Библиогр.: с.
233-234. - Прил.: с. 211-232. - Алф. указ.: с. 235-240. - ISBN 978-5-496-005463 : 418-60.
12. Маклаков, С.В. Моделирование бизнес-процессов с AllFusion
Process Modeler (BPwin 4.1) / С.В. Маклаков. – М. : ДИАЛОГ-МИФИ, 2004. –
240 с.
13. Методы и модели информационного менеджмента : учеб. пособие /
Д.В. Александров, А.В. Костров, Р.И. Макаров, Е.Р. Хорошева ; под ред. А.В.
Кострова. – М. : Финансы и статистика, 2007. - 336 с.
14. Реинжиниринг бизнес-процессов [Электронный ресурс] : учеб.
пособие / А. О. Блинов [и др.] ; под ред. А. О. Блинова. - Москва : ЮНИТИДАНА, 2012. - 341 c. - ISBN 978-5-238-01823-2.
15. Смирнова,Г. Н.Проектирование экономических информационных
систем [Текст] : учеб.для вузов / Г.Н.Смирнова,А.А.Сорокин,Ю.Ф.Тельнов. М. : Финансы и статистика,2005. - 512 с.
16. Советов Б.Я., Цехановский В.В., Чертовской В.Д. Базы данных.
Теория и практика.– Высшая школа, 2010. – С.49
17. Цуканова О. А. Методология и инструментарий моделирования
бизнес- процессов: учебное пособие – СПб.: Университет ИТМО, 2015. – 100
с.
46
18. Фуфаев Э. В.,
Фуфаев Д.Э. Базы данных, 7-ое издание.
- М.:
Издательсий центр «Академия», 2012. - 320с.
19. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных. - М.:
Корона-век, 2010. – 736 с.
20. Чудинов И.Л., Осипова В.В. Базы данных: Учебное пособие. –
Томск: Изд-во Томского политехнического университета, 2011. – 144 с.
47
ПРИЛОЖЕНИЕ 1 Листинг программы
Листинг запроса «Количество материалов более 1000»
privatevoid button1_Click_1(object sender, EventArgs e)
{
varПодключение = new System.Data.OleDb.OleDbConnection("Data
Source=\"E:\БДскладматериалов.mdb\";User " +
"ID=Admin;Provider=\"Microsoft.Jet.OLEDB.4.0\";");
Подключение.Open();
var command = new System.Data.OleDb.OleDbCommand("SELECT
Материалы.* FROM Материалы WHERE ([Кол-во] > 1000);", Подключение);
varАдаптер = new System.Data.OleDb.OleDbDataAdapter(command);
varНаборДанных = new System.Data.DataSet();
Адаптер.Fill(НаборДанных, "Материалы"); dataGridView7.DataSource =
НаборДанных; dataGridView7.DataMember = "Материалы";
Подключение.Close();
}
48