База данных. 2

Введение

 

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

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

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

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

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

При выполнении курсового проекта стояло две  задачи: спроектировать информационно  систему и реализовать ее средствами СУБД.

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

Третий раздел посвящен реализации разработанной БД средствами СУБД MS Access.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1 КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ

1.1 Описание предметной области

 

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

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

В составе  электронных информационных налоговых  систем функционируют следующие  программы:

- ИС НДС - система заполнения  форм налоговой отчетности по  НДС и реестров счетов-фактур;

- ИСИД - система учета получателей  доходов у источника выплаты;

- ЭФНО - система формирования электронных  форм налоговой отчетности;

- ИНИС - ведомственная система регистрации  налогоплательщиков и учета платежей;

- РНиОН - система государственного  реестра налогоплательщиков и  объектов налогообложения;

- СГДС - система гарантированной  доставки сообщений.

Все информационные системы функционируют независимо друг от друга.

Также все системы делятся на программное обеспечение налогоплательщика (клиентское приложение) и программное  обеспечение налогового органа.

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

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

Городской налоговый комитет создает базу данных юридических лиц с указанием всех их реквизитов и видов деятельности, причем юридическое лицо может иметь несколько видов деятельности. Надо иметь возможность просматривать как список юридических лиц по каждому виду деятельности, так и перечень видов деятельности по каждому юридическому лицу, а также обеспечить формирование запросов-выборок по различным условиям. Разработать БД НАЛОГОВОГО КОМИТЕТА.

Уточним предметную область. Юридические лица могут иметь несколько фирм.

 

 

 

1.2 Построение ИЛМ

 

 




 


 

 

 








 

 

 


 


 


 

 

 

 

2 ДАТАЛОГИЧЕКОЕ ПРОЕКТИРОВАНИЕ

2.1 Анализ реквизитного состава и установление функциональных зависимостей между реквизитами

 

Анализ  реквизитного состава проведем на основании  описанной предметной области.

 

Определение функциональных зависимостей между реквизитами в соответствии с требованиями первой нормальной формы(1НФ)

Реквизиты, описанные в предметной области  сведем в Таблицу 1.1. Проведем анализ реквизитного состава и определим  функциональные зависимости.

В рамках решаемой задачи все реквизиты содержат простые (атомарные) данные, следовательно, отношения находятся в 1НФ форме.

 

Таблица 1.1 - Функциональные зависимости в 1НФ

Наименование реквизита

Имя реквизита

Функциональные зависимости  в 1НФ

Юридическое лицо

ЮридическоеЛицо

Вид деятельности

ВидДеятельности

ФИО директора

ФИОДиректора

Адрес

Адрес

Телефон/Факс

Тел/Факс

Дата занятия

ДатаЗянятия

Номер лицензии

НомерЛицензии


 

 

Анализ  функциональных зависимостей показал, так как одно юридическое лицо может занимать несколько видов  деятельности, а вид деятельности может иметь нескольких юридических  лиц, то нужно ввести вспомогательные  коды. Ключевыми полями будут Код юридического лица– КодЮридическогоЛица, Код вида деятельности– КодВидаДеятельности.

 

Определение функциональных зависимостей между реквизитами в соответствии с требованиями второй нормальной формы(2НФ)

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

Во всех отношениях ключевые поля простые, следовательно  отношения автоматически находятся  во второй нормальной форме.

 

Определение функциональных зависимостей между реквизитами в соответствии с требованиями третьей нормальной формы(3НФ)

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

Для представления  отношений в 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– Обеспечение целостности  БД

 

Обеспечение целостности означает выполнение для  взаимосвязанных таблиц следующих  условий:

  1. в подчиненную таблицу не может быть добавлена запись с несуществующим в главной таблице значением ключа связи;
  2. в главной таблице нельзя удалить запись, если не удалены связанные с ней записи в подчиненной таблице;
  3. в главной таблице нельзя изменить значение ключа связи, если в записях подчиненной таблицы используется значение ключа связи.

При попытке  нарушения этих условий в операциях  обновления или удаления данных СУБД отменяет выполнение этих операций.

 

3.3 Ввод данных

 

Форма –  настраиваемое диалоговое окно, позволяющее  организовать удобный и интуитивно понятный интерфейс пользователя для  работы с данными.