База данных. 2
Введение
Базы данных (БД) и их использование в информационных системах (ИС) составляют в настоящее время основу компьютерного обеспечения информационных процессов, входящих практически во все сферы человеческой деятельности.
Действительно, процессы обработки информации имеют общую природу и опираются на описание фрагментов реальности, выраженное в виде совокупности взаимосвязанных данных. Базы данных являются эффективным средством представления структур данных и манипулирования ими. Концепция баз данных предполагает использование интегрированных средств хранения информации, позволяющих обеспечить централизованное управление данными и обслуживание ими многих пользователей.
База данных – это организованная
структура, предназначенная для
хранения информации. Сегодня большинство
систем управления базами данных позволяют
размещать в своих структурах
не только данные, но и методы (то есть
программный код), с помощью которых
происходит взаимодействие с потребителем
или с другими программно-
Для представления одной и той же информации во внутримашинной сфере могут быть использованы различные структуры и модели данных. Их выбор возлагается на пользователя, создающего информационную базу, и зависит от многих факторов, в том числе от выбранной СУБД, имеющегося технического обеспечения, определяется сложностью автоматизируемых задач и объемом информации.
Целью настоящего курсового проекта было разработать базу данных налогового комитета, меню приложения и средства диалога, формы ввода и изменения данных, запросы (если они нужны), отчеты для вывода на печать и т.д.
При выполнении курсового проекта стояло две задачи: спроектировать информационно систему и реализовать ее средствами СУБД.
Проект состоит из трех разделов. Первый посвящен теоретическим разработкам БД: описана предметная область, проведен анализ реквизитного состава, образование информационных объектов. Второй раздел посвящен даталогическому проектированию, в результате которого разработаем даталогическую модель.
Третий раздел посвящен реализации разработанной БД средствами СУБД MS Access.
1 КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ
1.1 Описание предметной области
Учет налоговых платежей и налоговой отчетности осуществляется налоговым органом. Исполнение налогового обязательства по составлению и представлению налоговой отчетности, уплате начисленных сумм налогов и других обязательных платежей в бюджет налогоплательщик осуществляет самостоятельно в порядке и в сроки, установленные налоговым законодательством
Прогресс
в сфере компьютерных и телекоммуникационных
технологий создает технические
предпосылки для постепенного перехода
от традиционного
В составе электронных информационных налоговых систем функционируют следующие программы:
- ИС НДС - система заполнения форм налоговой отчетности по НДС и реестров счетов-фактур;
- ИСИД - система учета получателей доходов у источника выплаты;
- ЭФНО - система формирования
- ИНИС - ведомственная система
- РНиОН - система государственного реестра налогоплательщиков и объектов налогообложения;
- СГДС - система гарантированной доставки сообщений.
Все информационные
системы функционируют
Также все системы делятся на
программное обеспечение
В налоговых
органах учет налогов, других обязательных
платежей в бюджет, обязательных пенсионных
взносов и социальных отчислений,
а также пеней и штрафов
ведется в интегрированной
С помощью
этой информационной системы налоговые
органы открывают лицевые счета
на каждого налогоплательщика (налогового
агента) по соответствующим кодам
бюджетной классификации
Городской налоговый комитет создает базу данных юридических лиц с указанием всех их реквизитов и видов деятельности, причем юридическое лицо может иметь несколько видов деятельности. Надо иметь возможность просматривать как список юридических лиц по каждому виду деятельности, так и перечень видов деятельности по каждому юридическому лицу, а также обеспечить формирование запросов-выборок по различным условиям. Разработать БД НАЛОГОВОГО КОМИТЕТА.
Уточним предметную область. Юридические лица могут иметь несколько фирм.
1.2 Построение ИЛМ
2 ДАТАЛОГИЧЕКОЕ ПРОЕКТИРОВАНИЕ
2.1 Анализ реквизитного состава и установление функциональных зависимостей между реквизитами
Анализ реквизитного состава проведем на основании описанной предметной области.
Определение функциональных зависимостей
между реквизитами в
Реквизиты, описанные в предметной области сведем в Таблицу 1.1. Проведем анализ реквизитного состава и определим функциональные зависимости.
В рамках решаемой задачи все реквизиты содержат простые (атомарные) данные, следовательно, отношения находятся в 1НФ форме.
Таблица 1.1 - Функциональные зависимости в 1НФ
Наименование реквизита |
Имя реквизита |
Функциональные зависимости в 1НФ |
Юридическое лицо |
ЮридическоеЛицо |
|
Вид деятельности |
ВидДеятельности | |
ФИО директора |
ФИОДиректора | |
Адрес |
Адрес | |
Телефон/Факс |
Тел/Факс | |
Дата занятия |
ДатаЗянятия | |
Номер лицензии |
НомерЛицензии |
Анализ функциональных зависимостей показал, так как одно юридическое лицо может занимать несколько видов деятельности, а вид деятельности может иметь нескольких юридических лиц, то нужно ввести вспомогательные коды. Ключевыми полями будут Код юридического лица– КодЮридическогоЛица, Код вида деятельности– КодВидаДеятельности.
Определение функциональных зависимостей
между реквизитами в
По определению отношение находится во второй нормальной форме тогда и только тогда, когда оно находится в первой нормальной форме и не содержит неполных функциональных зависимостей не первичных атрибутов от атрибутов первичного ключа.
Во всех
отношениях ключевые поля простые, следовательно
отношения автоматически
Определение функциональных зависимостей
между реквизитами в
По определению отношение находится в третьей нормальной форме тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей не первичных атрибутов от атрибутов первичного ключа.
Для представления отношений в 3НФ функциональные зависимости в них должны выглядеть так как представлено в Таблице 1.2.
Таблица 1.2 – Функциональные зависимости во 3НФ
Наименование реквизита |
Имя реквизита |
Функциональные зависимости в 3НФ |
Код юридического лица |
КодЮридическогоЛица |
|
Юридическое лицо |
ЮридическоеЛицо | |
Код вида деятельности |
КодВидаДеятельности | |
Вид деятельности |
ВидДеятельности | |
ФИО директора |
ФИОДиректора | |
Адрес |
Адрес | |
Телефон/Факс |
Тел/Факс | |
Дата занятия |
ДатаЗянятия | |
Номер лицензии |
НомерЛицензии | |
2.2 Образование информационных объектов
Установим
для каждого описательного
Образование
информационных объектов происходит на
основании объединения
Сгруппируем описательные реквизиты, одинаково зависимые от ключевых реквизитов, и объединим их с ключевыми в один информационный объект. Результат группировки в таблице 1.3.
Таблица 1.3 – Информационные объекты
Имя реквизита |
Вид ключа |
Имя ИО |
Семантика |
КодЮридическогоЛица |
П, У |
Юридическое лицо |
Сведения о юридических лицах |
Названия |
|||
Адрес |
|||
Тел/Факс |
|||
ФИОДиректора |
|||
ДатаЗанятия |
|||
НомерЛицензии |
|||
КодВидаДеятельности |
П, У |
Вид Деятельности |
Сведения о видах деятельностей |
Названия |
|||
КодЛицоЗанимаетсяДеятельностью |
П, У |
Лицо занимается деятельностью |
Сведения какой деятельностью занимаются лица |
КодЮридическогоЛица |
В |
||
КодВидаДеятельности |
В |
2.3 Выявление связей информационных объектов
Связи между
информационными объектами
В таблице 1.4 представлены главные и подчиненные информационные объекты с ключами связи и типом отношения.
Таблица
1.4 – Связи между
Номер связи |
Главный ИО |
Тип отношения | |
Имя |
Ключ связи | ||
КодЮридическогоЛица |
КодЛицоЗанимаетсяДеятельностью |
1:М | |
КодВидаДеятельности |
КодЛицоЗанимаетсяДеятельностью |
1:М | |
2.4 Создание информационно–логической модели предметной области в каноническом виде
Информационно–логическая модель предметной области в каноническом виде отражает иерархию подчинения информационных объектов по уровням, определяемым количеством связей в наиболее длинном пути от вершины модели к объекту.
На уровне 0 размещаются информационные объекты, которые не содержат внешних ключей: Авто, Водитель.
На уровне 1 размещаются информационные объекты, которые содержат только внешние ключи объектов, расположенных на уровне 0.
На уровне 2 размещаются информационные объекты, которые содержат внешние ключи объектов, расположенных на уровне 0, 1.
Информационно – логическая модель предметной области в каноническом виде представлена на рисунке 1.1.
Уровень 0
Уровень 1
Рисунок 1.1 - Информационно – логическая модель предметной области
2.5 Создание даталогической модели реляционной базы данных
Даталогическая
модель реляционной базы данных определяется
совокупностью логически
Каждая
таблица имеет структуру, определяемую
реквизитным составом информационного
объекта информационно–
Логические
связи между таблицами
Логическая структура реляционной базы данных (схема данных), построенная на основе информационно–логической модели предметной области представлена на рисунке 1.2.
Логическая структура реляционных таблиц зависит от СУБД, с помощью которой будет разрабатываться база данных.
В различных СУБД поддерживаются различные типы данных, существуют различные ограничения на длину имени поля и символы, используемые в имени, могут отличаться и свойства полей и т.п.
В таблицах представлена логическая структура реляционных таблиц базы данных MS Access.
Рисунок 1.2 - Даталогическая модель реляционной базы данных
Структура информационных объектов представлена в таблицах 1.5, 1.6, 1.7, 1.8.
Таблица 1.5 – Отношение "Юридическое лицо"
Атрибут (поле) |
Вид ключа |
Формат поля | |||
Имя |
Наименование |
тип |
размер |
Обязательное поле | |
КодЮридическогоЛица |
Код юридического лица |
П, У |
счетчик |
да | |
Названия |
Названия |
текстовый |
50 |
да | |
Адрес |
Адрес |
текстовый |
50 |
да | |
Тел/Факс |
Телефон/Факс |
текстовый |
50 |
да | |
ФИОДиректора |
ФИО директора |
текстовый |
50 |
да | |
ДатаЗанятия |
Дата занятия |
Дата\время |
Краткий формат даты |
да | |
НомерЛицензии |
Номер лицензии |
текстовый |
50 |
да | |
Таблица 1.6 – Отношение "Вид деятельности"
Атрибут (поле) |
Вид ключа |
Формат поля | |||
Имя |
Наименование |
тип |
размер |
Обязательное поле | |
КодВидаДеятельности |
Код вида деятельности |
П, У |
счетчик |
да | |
Названия |
Названия |
текстовый |
50 |
да | |
Таблица 1.7 – Отношение "Лицо занимается деятельностью"
Атрибут (поле) |
Вид ключа |
Формат поля | |||
Имя |
Наименование |
тип |
размер |
Обязательное поле | |
КодЛицоЗанимаетсяДеятельностью |
Лицо занимается деятельностью |
П, У |
счетчик |
да | |
КодЮридическогоЛица |
Код юридического лица |
В |
числовой |
да | |
КодВидаДеятельности |
Код вида деятельности |
В |
числовой |
да | |
2.6 Разработка данных контрольного примера
В данных контрольного примера отразим требования описания предметной области:
Таблица 1.9 – Таблица Юридические лица (уровень 0)
КодЮридическогоЛица |
Название |
Адрес |
Тел/Факс |
ФИОДиректора |
4 |
ТК ВИСТ |
Старопетровкий пер 11/1 |
159-40-01 |
Раппопорт А.И. |
5 |
ООО КОМУС |
Семеновская 49 |
366-98-87 |
Павлов П.И. |
6 |
ФК ГЕРМЕС |
Пр.Мира 45 |
654-78-98 |
Мавроди И.И. |
Таблица 1.10 – Таблица Виды деятельности (уровень 0)
КодВидаДеятельности |
Название |
1 |
Торговля спиртными напитками (>40) |
2 |
Торговля автомобилями и автозапчастями |
3 |
Производство детских игрушек |
4 |
Полиграфия |
5 |
Производство спортинвентаря |
6 |
Банковская деятельность |
7 |
Ценнные бумаги |
Таблица 1.12 – Таблица Лицо занимается деятельностью (уровень 1)
КодЮридическогоЛица |
КодВидаДеятельности |
ДатаЗанятия |
НомерЛицензии |
4 |
1 |
01.01.2009 |
321321321-ЭЖД |
4 |
2 |
01.01.2006 |
98989898-ФЫВ |
5 |
1 |
01.10.2008 |
fghfghfghf-RTY |
5 |
4 |
05.05.2007 |
78998-ААА |
5 |
5 |
01.12.2007 |
32321-ВВВ |
6 |
6 |
01.01.2007 |
654654654-ыва |
6 |
7 |
01.01.2006 |
32132132132-НЕК |
3 РАЗРАБОТКА БД
3.1 Программные разработки
Для реализации разработанной информационной системы выбрана СУБД MS Access, которая является реляционной СУБД работающей в среде Windows. Как и другие продукты этой категории, она предназначена для хранения и поиска данных, представления информации в удобном виде и автоматизации часто повторяющихся операций. С помощью Access можно разрабатывать простые и удобные формы ввода данных, а также осуществлять обработку данных и выдачу сложных отчетов.
В системе Access предусмотрены:
- контекстно-зависимая справка;
- простые в использовании мастера и конструкторы;
- импортирование, экспортирование и связывание внешних файлов;
- формы и отчеты, конструируемые по принципу WYSIWYG (What You See Is What You Get - что видишь, то и получишь);
- многотабличные запросы и отношения;
- разработка графиков и диаграмм;
и многое другое.
СУБД MS Access ориентирована на работу с объектами, к которым относятся: таблицы, запросы, формы, отчеты, страницы доступа к данным, макросы и модули.
В Access все объекты находятся в одном файле. Файл баз данных имеет зарегистрированное в Windows расширение .mdb.
Таблица – основной структурный элемент системы управления реляционной базы данных. В Microsoft Access таблицей называют объект, в котором данные сохраняются в формате записей (строк) полей (столбцов). Данные в отдельной таблице относятся к определенной категории, например, сведения о сотрудниках или заказах.
Запросы – требования на отбор данных, хранящиеся в таблицах, или требование на выполнение определенных действий с данными. Запрос позволяет создать общий набор записей из данных, находящихся в разных таблицах, и использовать этот набор как источник данных для формы или отчета.
Формы – объект базы данных Microsoft Access, в котором разработчик размещает элементы управления, принимающие действия пользователей или служащих для ввода, отображения или изменения данных в полях.
Отчет –
объект базы данных Microsoft Access, предназначенный
для отображения данных, организованных
и отформатированных в
Макрос – макрокоманда или набор макрокоманд, используемый для автоматического выполнения некоторых операций.
Модуль – совокупность описаний, инструкций и процедур, сохраненная под общим именем. В Microsoft Access существуют модули двух типов: стандартный модуль и модуль класса. Модули форм и отчетов являются модулями классов и содержат программы, являющиеся локальными для этих объектов. Процедуры из стандартного модуля, если они не описаны явно как локальные для содержащего их модуля, распознаются и могут вызываться процедурами из других модулей в той же базе данных или из адресуемых баз данных.
Создание новой базы данных осуществляется в соответствии с ее структурой, полученной в результате проектирования.
3.2 Разработка структур БД
Создание новой базы данных осуществляется в соответствии с ее структурой, полученной в результате проектирования.
Реляционная модель данных – совокупность взаимосвязанных таблиц. Поэтому таблицы являются основным объектом реляционных баз данных и предназначены для хранения данных о предметной области.
Создание таблиц в БД происходит в два этапа.
На первом этапе описываются структуры таблиц и устанавливаются связи между ними. На втором этапе – таблицы заполняются данными.
Описание структуры таблиц (рисунок 2.1) производится на основании даталогической модели, полученной на этапе проектирования.
Рисунок 2.1– Структура таблиц
Схема данных
(рисунок 2.2) задает логическую структуру
БД. В ней определяются связи между
таблицами, а также обеспечивается
поддержание целостности (рисунок 2.3)
взаимосвязанных данных. Схема данных
позволяет упростить
При построении схемы, СУБД MS Access автоматически определяет тип связи между таблицами. Если поле, по которому устанавливается связь, является уникальным ключом, как в главной таблице, так и в подчиненной, Access устанавливает связь 1:1. Если поле связи является уникальным ключом в главной таблице, а в подчиненной таблице является неключевым или входит в состав составного первичного ключа, Access устанавливает связь 1:М от главной таблицы к подчиненной.
Рисунок 2.2– Схема БД
Рисунок 2.3– Обеспечение целостности БД
Обеспечение целостности означает выполнение для взаимосвязанных таблиц следующих условий:
- в подчиненную таблицу не может быть добавлена запись с несуществующим в главной таблице значением ключа связи;
- в главной таблице нельзя удалить запись, если не удалены связанные с ней записи в подчиненной таблице;
- в главной таблице нельзя изменить значение ключа связи, если в записях подчиненной таблицы используется значение ключа связи.
При попытке нарушения этих условий в операциях обновления или удаления данных СУБД отменяет выполнение этих операций.
3.3 Ввод данных
Форма – настраиваемое диалоговое окно, позволяющее организовать удобный и интуитивно понятный интерфейс пользователя для работы с данными.
