72675

Проект информационной системы для работы с реляционной базой данных активного сетевого оборудования

Курсовая

Информатика, кибернетика и программирование

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

Русский

2014-11-26

531.48 KB

4 чел.


СОДЕРЖАНИЕ

СОДЕРЖАНИЕ 1

ВВЕДЕНИЕ 2

ТЕХНИЧЕСКОЕ ЗАДАНИЕ 3

1. Описание целевой СУБД 4

2. Инфологическая модель 6

Рис. 1. «Инфологическая модель» 7

3. Концептуальная модель 9

3.1. Реляционная схема концептуальной модели 11

4. SQL-скрипт создания физической модели 12

4.1. Комментарии к SQL-скрипту 16

5. Внешняя модель 17

5.2. Пример кода внешней модели 35

ЗАКЛЮЧЕНИЕ 38

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ 39


ВВЕДЕНИЕ

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

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

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

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

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

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

  1. местонахождение устройства;
  2. модель, серийный номер и тип устройства;
  3. ip-адрес устройства;
  4. snmp-ключ и его параметры.


1. Описание целевой СУБД

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

Логическая архитектура MySQL:

  1. На самом верхнем уровне содержатся службы, которые не являются уникальными для MySQL. Эти службы необходимы большинству сетевых клиент-серверных инструментов и  серверов: они обеспечивают поддержку соединений, идентификацию, безопасность и т. п.
  2. Второй уровень представляет гораздо больший интерес. Здесь сосредоточена значительная часть интеллекта MySQL: синтаксический анализ запросов, оптимизация, кэширование и  все встроенные функции (например, функции работы с  датами и  временем, математические функции, шифрование). На этом уровне реализуется любая независимая от подсистемы хранения данных функциональность, например хранимые процедуры, триггеры и представления.
  3. Третий уровень содержит подсистемы хранения данных. Они отвечают за сохранение и  извлечение всех данных, хранимых в  MySQL. Подобно различным файловым системам GNU/Linux, каждая подсистема хранения данных имеет свои сильные и слабые стороны. Сервер взаимодействует с ними с помощью API (интерфейса прикладного программирования) подсистемы хранения данных. Этот интерфейс скрывает различия между подсистемами хранения данных и  делает их почти прозрачными на уровне запросов. Кроме того, данный интерфейс содержит пару десятков низкоуровневых функций, выполняющих операции типа «начать транзакцию» или «извлечь строку с таким первичным ключом». Подсистемы хранения не производят синтаксический анализ  кода SQL и не взаимодействуют друг с другом, они просто отвечают на исходящие от сервера запросы.

MySQL поддерживает множество подсистем хранения данных, каждая из которых имеет свои накладные расходы, стратегию блокировки, поддерживает те или иные возможности. Чаще всего используются подсистемы хранения MyISAM и InnoDB.

MyISAM является компромиссом между производительностью и функциональностью. Она предоставляет полнотекстовое индексирование, сжатие и пространственные функции. Не поддерживает транзакции и блокировки на уровне строк.

InnoDB была разработана для транзакционной обработки, в частности для обработки большого количества краткосрочных транзакций. Обеспечивает высокую степень конкуренции, реализует все стандартные уровни изоляции SQL. Поддерживает ограничения целостности типа «внешний ключ». [1]


2. Инфологическая модель

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

Непосредственный интерес в данной предметной области представляют:

  1. помещение, в котором установлено устройство (см. рис.1 «Инфологическая модель», фрейм F0);
  2. сводная информация об устройстве (см. рис.1 «Инфологическая модель», фрейм F1);
  3. аутентификационный ключ, настроенный программно в сетевом оборудовании (см. рис.1 «Инфологическая модель», фрейм F2);

Анализ инфологии данной предметной области позволяет предложить следующую инфологическую модель:

Рис. 1. «Инфологическая модель»

Каждый фрейм может иметь иерархическую структуру любой сложности. Любой фрейм может вступать в отношения с другим фреймом с помощью связей типа K, Q, H. В данном проекте используются связи только типа H.

В нашей инфологической модели представлено три объекта, описанных фреймами F0, F1 и F2.

1. Фрейм F0 описывает размещение оборудования. Размещение включает в себя помещение, за которым закреплён список устройств. Имеет следующие атрибуты: X1, X2, X3, X6.

2. Фрейм F1 описывает активное сетевое оборудование. Оно включает в себя модель и конкретные экземпляры устройств. Характеризуется следующими атрибутами: X4, X5, X6, X7, X8.

3. Фрейм F2 описывает аутентификационный ключ. Включает в себя номер ключа и сам ключ. Имеет следующие атрибуты: X8, X9.

Для каждого объекта существуют ограничения, они описаны далее.

  1. Каждая единица активного сетевого оборудования может быть использована (быть установлена) только в одном помещении, номер устройства в общем списке уникален, назначается автоматически. Формально это записывается следующей функциональной зависимостью: X1X6 ↔ X3;
  2.  IP-адрес, назначаемый каждому устройству, уникален, выбирается вручную сетевым инженером из доступного частного диапазона IP-сетей. Ограничение реализуется встроенными в СУБД средствами;
  3.  Каждое помещение должно иметь уникальное местонахождение, номер помещения является абстрактным, уникальным и назначается автоматически. Формально это записывается так: X1 ↔ X2;
  4. Номер ключа уникален, назначается автоматически. Формально это записывается так: X8 ↔ X9;
  5.  Производитель устройства несущественен, важна только конкретная модель (для лучшего восприятия будем считать название производителя частью названия модели). Таким образом, название модели уникально. Формально это записывается так: X4 ↔X5.

3. Концептуальная модель

X1 — абстрактный номер помещения;

X2 — местонахождение;

X3 — абстрактный номер устройства в списке;

X4 — модель устройства;

X5 — тип устройства (router, MLS, MLS3);

X6 — ip-адрес устройства;

X7 — серийный номер устройства;

X8 — номер ключа;

X9 — ключ.

X1 ↔ X2

X1X6 ↔ X3

X4 ↔X5

X6 ↔ X4X7

X8 ↔ X9

R(X1, X2, X3, X4, X5, X6, X7):

X1

X2

X3

X4

X5

X6

X7

1

1

1

1

1

1

1

1

1

1

1

1

2

2

2

2

2

1

1

1

1

1

1

1

1

1

1

1

R0 (X8, X9);

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

  1. Связка: модель устройства + серийный номер устройства определяет конкретный экземпляр активного сетевого оборудования, соответственно, должна проверяться на уникальность. Формально это записывается так: X6 ↔ X4X7.

  1.  1НФ предполагает атомарность атрибутов.
  2.  2НФ предполагает, что отношение находится в 1НФ и каждый непервичный атрибут функционально полно зависит от каждого возможного ключа.
  3.  3НФ предполагает, что отношение находится в 2НФ и отсутстсуют транзитивные зависимости атрибутов от возможных ключей, т. е. каждый непервичный атрибут нетранзитивно зависит от каждого возможного ключа отношения.
  4.  БКНФ предполагает, что отношение находится в 3НФ и каждая детерминанта (левая часть функциональной зависимости) является возможным ключом.

R1 (X1, X2) - (Таблица «room»);

R2 (X3, X1, X6) - (Таблица «list»);

R3 (X4, X5) - (Таблица «model»);

R4 (X6, X4, X7, X8) - (Таблица «device»);

R5 (X8, X9) - (Таблица «snmp_key»).

3.1. Реляционная схема концептуальной модели

                 

Рис. 2. «Реляционная схема концептуальной модели»

4. SQL-скрипт создания физической модели

--

-- Структура таблицы `device`

--

CREATE TABLE IF NOT EXISTS `device` (

 `device_id` char(15) NOT NULL,

 `model_id` char(255) NOT NULL,

 `snmp_key_id` int(11) NOT NULL,

 `device_sn` char(255) NOT NULL,

 PRIMARY KEY (`device_id`),

 KEY `device2_ibfk_3` (`snmp_key_id`),

 KEY `device_ibfk_1` (`model_id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

--

-- Структура таблицы `list`

--

CREATE TABLE IF NOT EXISTS `list` (

 `list_id` int(11) NOT NULL AUTO_INCREMENT,

 `room_id` int(11) NOT NULL,

 `device_id` char(15) NOT NULL,

 PRIMARY KEY (`list_id`),

 KEY `list_ibfk_2` (`device_id`),

 KEY `list_ibfk_3` (`room_id`)

) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=5 ;

--

-- Структура таблицы `model`

--

CREATE TABLE IF NOT EXISTS `model` (

 `model_id` char(255) NOT NULL,

 `model_type` enum('router','mls','mlsl3') NOT NULL,

 PRIMARY KEY (`model_id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

--

-- Структура таблицы `room`

--

CREATE TABLE IF NOT EXISTS `room` (

 `room_id` int(11) NOT NULL AUTO_INCREMENT,

 `room_description` char(255) NOT NULL,

 PRIMARY KEY (`room_id`) ,

 UNIQUE KEY `room_description` (`room_description`)

) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=57 ;

--

-- Структура таблицы `snmp_key`

--

CREATE TABLE IF NOT EXISTS `snmp_key` (

 `snmp_key_id` int(11) NOT NULL AUTO_INCREMENT,

 `snmp_key_version` enum('1','2c','3') NOT NULL,

 `snmp_key_level` enum('noAuthNoPriv','authNoPriv','authPriv') NOT NULL,

 `snmp_key_auth` char(255) NOT NULL,

 `snmp_key_encryption` enum('no','DES') NOT NULL,

 PRIMARY KEY (`snmp_key_id`)

) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=2 ;

--

-- Ограничения внешнего ключа сохраненных таблиц

--

--

-- Ограничения внешнего ключа таблицы `device`

--

ALTER TABLE `device`

 ADD CONSTRAINT `device_ibfk_1` FOREIGN KEY (`model_id`) REFERENCES `model` (`model_id`) ON DELETE NO ACTION ON UPDATE CASCADE,

 ADD CONSTRAINT `device_ibfk_2` FOREIGN KEY (`snmp_key_id`) REFERENCES `snmp_key` (`snmp_key_id`) ON DELETE NO ACTION ON UPDATE CASCADE;

--

-- Ограничения внешнего ключа таблицы `list`

--

ALTER TABLE `list`

 ADD CONSTRAINT `list_ibfk_1` FOREIGN KEY (`room_id`) REFERENCES `room` (`room_id`) ON DELETE NO ACTION ON UPDATE CASCADE,

 ADD CONSTRAINT `list_ibfk_2` FOREIGN KEY (`device_id`) REFERENCES `device` (`device_id`) ON DELETE CASCADE ON UPDATE CASCADE;

4.1. Комментарии к SQL-скрипту

В конце скрипта описаны ограничения внешних ключей. Рассмотрим некоторые из них:

ALTER TABLE `list`

ADD CONSTRAINT `list_ibfk_1` FOREIGN KEY (`room_id`) REFERENCES `room` (`room_id`) ON DELETE NO ACTION ON UPDATE CASCADE,

ADD CONSTRAINT `list_ibfk_2` FOREIGN KEY (`device_id`) REFERENCES `device` (`device_id`) ON DELETE CASCADE ON UPDATE CASCADE;

Вторая строка означает следующее: при удалении или изменении записи с конкретным «device_id» в отношении «device» сработает триггер, который произведёт аналогичное действие с записью в отношении «list». Т.е. если мы удалим запись в отношении «device», связанная с ней запись в отношении «list» также будет удалена.

Первая строка означает следующее: при попытке удалении записи с конкретным «room_id» из отношения «room» в случае, если в отношении «list» найдутся записи, связанные с этим «room_id», попытка удаления будет проигнорирована. При попытке изменения записи, будет также обновлено значение соответствующего атрибута в отношении «list».

Конкретное действие описывается в конструкции ON DELETE … ON UPDATE …


5. Внешняя модель

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

  1. HTML (разметка страницы);
  2. CSS (стиль элементов страницы);
  3. JavaScript (элементы взаимодействия с пользователем);
  4. Perl (логика веб-приложения - «backend»).

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

  1. twitter bootstrap (CSS, JavaScript - стиль элементов страницы, элементы взаимодействия с пользователем);
  2. jquery (библиотека для JavaScript — элементы взаимодействия с пользователем);
  3. Catalyst Framework (framework для создания Perl-приложений в нотации MVC).

Рассмотрим внешнюю модель.

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

Для каждой «таблицы» доступны четыре стандартных действия:

  1. просмотр;
  2. добавление;
  3. изменение;
  4. удаление.

Есть два режима работы — обычный (доступен по ссылке «Информация», доступен только просмотр) и административный (доступен по ссылке «Панель управления», возможны любые действия). (см. Рис. 4, 5, 6)

Рис. 4. «Выбор режима работы»

Рис. 5. «Обычный режим»

Рис. 6. «Административный режим»

В режиме просмотра отражается та часть информации, которая может быть необходима для обычной работы. Это список устройств (см. рис. 7), список моделей (см. рис. 8), список помещений (см. рис. 9).

В режиме просмотра предусмотрена возможность загрузки сокращённого списка устройств, включающего, к примеру, только те устройства, которые находятся в конкретном помещении (см. рис. 10), или устройства конкретной модели (см. рис. 11).

Рис. 7. «Список устройств в режиме просмотра»

Рис. 8. «Список моделей в режиме просмотра»

Рис. 9. «Список помещений в режиме просмотра»

Рис. 10. «Список устройств в помещении, режим просмотра»

Рис. 11. «Список устройств конкретной модели, режим просмотра»

Страницы режима администрирования выглядят несколько схоже с режимом просмотра, за исключением колонки «Действия» (в ней есть ссылки на редактирование и удаление) и наличия кнопки «Добавить». Также присутствует некоторая информация, в которой нет необходимости знакомиться в режиме просмотра (см. рис. 12, рис. 13, рис. 14, рис. 15).

Рис. 12. «Список ключей, административный режим»

Рис. 13. «Список моделей, административный режим»

Рис. 14. «Список помещений, административный режим»

Рис. 15. «Список помещений, административный режим»

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

Для добавления устройства необходимо перейти в список устройств и нажать кнопку «Добавить» (см. рис. 7). После этого появится незаполненная форма со всеми полями, необходимыми для внесения устройства в список (см. рис. 16), заполняем её (см. рис. 17) и нажимаем на кнопку «Добавить». Поскольку в списке ранее отсутствовало устройство с таким IP-адресом и связкой модель и серийный номер, попытка внесения устройства в список оказывается успешной (см. рис. 18). Теперь попытаемся проверить, удастся ли нам внести устройство с такими же значениями. Попытка оказалась неудачной (см. рис. 19).

Для редактирования устройства необходимо перейти в список устройств и нажать на значок ручки в колонке «Действия:», после чего откроется страница (см. рис. 20), аналогичное странице добавления устройства, но уже с заполненными полями (см. рис. 16). После внесения исправлений необходимо нажать кнопку «Сохранить». Если данные введены корректно, то мы увидим уведомление об успешном изменении информации (см. рис. 21), в противном случае — уведомление о некорректности введённых данных (см. рис. 22).

Также мы можем удалить устройство из списка. Для этого необходимо перейти в список устройств и найти в колонке «Действия» пиктограмму с подписью «Удалить». После нажатия увидим результат (см. рис. 23 и рис. 24).

Рис. 16 «Добавление устройства, административный режим»

Рис. 17 «Добавление устройства (заполненные поля), административный режим»

Рис. 18. «Успешное добавление устройства, административный режим»

Рис. 19. «Неудачная попытка добавления устройства, административный режим»

Рис. 20. «Редактирование устройства, административный режим»

Рис. 21. «Успешная попытка редактирования устройства»

Рис. 22. «Неудачная попытка редактирования устройства»

Рис. 23. «Успешная попытка удаления устройства»

Рис. 24 «Неудачная попытка удаления устройства»


5.2. Пример кода внешней модели

# Функция для внесения изменений в список помещений

sub room_edit_result :Chained('/') :PathPart('admin/room/edit/result') :Args(0) {

   my ( $self, $c ) = @_;

# Проверяем наличие полей со старыми и новыми данными

   if( exists($c->req->body_params->{'room_id'}) && exists($c->req->body_params->{'room_description'}) && exists($c->req->body_params->{'room_description_prev'}) )

   {

       my $result = ""; # Результат действия

       my $result_description = ""; # Комментарий к результату действия

       my $room_id = $c->req->body_params->{'room_id'};

       my $room_description =  $c->req->body_params->{'room_description'};

my $room_description_prev = $c->req->body_params->{'room_description_prev'};

       

# Проверяем корректность полученных от пользователя данных

       if( ($room_id =~ /^(?:\d){1,11}$/) && ($c->model('MInformation')->check_room($room_description)) && ($c->model('MInformation')->check_room($room_description_prev)) )

       {

           #Ищем нужную запись

           my @temp = $c->model('DevManDB::room')->search({ room_id => $room_id, room_description => $room_description_prev });

           #Смотрим, есть ли уже записи, у которых такое же "room_description" (новое)

           my $temp2 = $c->model('DevManDB::room')->search({ room_description => $room_description })->count;

           #Пригодится, когда потребуется изменить регистр букв

           if($room_description == $room_description_prev)

           {

               $temp2 = 0;

           }

       # Если нужная запись найдена, а новая не противоречит ограничениям целостности (в данном случае это отсутствие дубликатов атрибута room_description

           if ( (scalar @temp == 1) && (scalar $temp2 == 0) )

           {

               my $row = pop @temp;

               $row->update({ room_description => $room_description });

               #проверяем, изменилась ли запись

               my $temp2 = $c->model('DevManDB::room')->search({ room_id => $room_id, room_description => $room_description })->count;

               if( $temp2 == 1)

               {

                   $result = 'edit_success';

               }

               else

               {

                   $result = 'edit_fail';

               }

           }

           else

           {

               $result = 'edit_fail';

               $result_description = "Помещения с таким номером не существует, либо такое помещение уже есть в списке.";

           }

       }

       else

       {

           $result = 'add_fail';

           $result_description = "Поля заполнены некорректно.";

       }

# Загружаем страницу внешней модели

       $c->stash(section => 'admin', subsection => 'room', page => 'edit', title => 'Редактировать помещение', result => $result, result_description => $result_description, template => 'src/admin/room/room_result.tt');

       return 1;

   }

# Если от пользователя не поступили все необходимые данные, страница переадресовывается в зону ошибки

   $c->res->redirect($c->uri_for('/dev/null'));

}

ЗАКЛЮЧЕНИЕ

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

  1. Шварц Б., Зайцев П., Ткаченко В., Заводны Дж., Ленц А., Бэллинг Д. - MySQL. Оптимизация производительности, 2-е издание. – Пер. с англ. – СПб.:
  2. Символ-Плюс, 2010. – 832 с., ил.
  3. Базы данных: учебно-методический комплекс /сост.: М.В. Копейкин, В.В.    Спиридонов, Е.О. Шумова. - СПб.: Изд-во СЗТУ, 2010. – 175 с.
  4. Копейкин М.В., Спиридонов В.В., Шумова Е.О. Базы данных: учебное    пособие: в 2 кн. Кн. 1. – СПб.: Изд-во СЗТУ, 2010. – 247.
  5. Копейкин М.В., Спиридонов В.В., Шумова Е.О. Базы данных: учебное пособие: в 2 кн. Кн. 2. – СПб.: Изд-во СЗТУ, 2010. – 219 c.
  6.  Antano Solar John. -  Catalyst 5.8 The Perl MVC Framework : Build scalable and extendable web applications using the Agile MVC framework. - Packt Publishing, 2009.
  7. Ларри Уолл, Том Кристиансен и Джон Орвант. Программирование на Perl. – Пер. с англ. – СПб: Символ Плюс, 2002. – 1152 с., ил.
  8.  http://www.template-toolkit.org/
  9.  http://twitter.github.com/bootstrap/


 

А также другие работы, которые могут Вас заинтересовать

5629. Система налогообложения для сельскохозяйственных товаропроизводителей (единый сельскохозяйственный налог - ЕСХН) 30 KB
  Система налогообложения для сельскохозяйственных товаропроизводителей (единый сельскохозяйственный налог - ЕСХН) Сельскохозяйственные товаропроизводители - это организации и индивидуальные предприниматели, производящие сельскохозяйственную...
5630. Ответственность за нарушение налогового законодательства. Административная и уголовная ответственность в налоговой сфере 78.5 KB
  Ответственность за нарушение налогового законодательства Понятие налоговой ответственности. Составы налоговых правонарушений. Ответственность в соответствии с НК РФ. Административная и уголовная ответственность в налоговой...
5631. Налоговый контроль. Камеральная и выездная налоговые проверки 76 KB
  Налоговый контроль Понятие и виды налогового контроля. Камеральная и выездная налоговые проверки. Порядок оформления результатов проверок. Административная и судебная защита прав налогоплательщиков. Налоговый контроль
5632. Федеральная налоговая служба. Государственные органы как участники отношений в налоговой сфере 76.5 KB
  Государственные органы как участники отношений в налоговой сфере Федеральная налоговая служба. Таможенные органы. Федеральная служба по борьбе с налоговыми и экономическими преступлениями. Другие участники отношений в налогов...
5633. Налоговое производство. Порядок исчисления и уплаты налога 75 KB
  Налоговое производство Понятие налогового производства. Бухгалтерский и налоговый учет при исчислении налога. Порядок исчисления налога. Порядок уплаты налога. Юридической обязанностью налогоплательщика является уплата нал...
5634. Система налогов. Направления развития системы налогообложения в РФ 76 KB
  Система налогов Направления развития системы налогообложения в РФ. Перечень налогов, взимаемых на территории РФ. Общие сведения о налогах. Реформирование налоговой системы - это ее преобразование, исходя из направлений...
5635. Основы российской налоговой системы. Принципы налогообложения 68 KB
  Основы российской налоговой системы Понятие налоговой системы и налоговой политики. Принципы налогообложения в РФ. Система налогового законодательства. Бюджетный процесс и налогообложение. Основные характеристики налого...
5636. Дискретная математика. Теория вероятностей и математическая статистика 1.01 MB
  Учебно-методическое пособие разработано по дисциплине Математика и содержит краткий теоретический материал и упражнения по двум разделам дисциплины: дискретная математика, теория вероятностей и математическая статистика. Для организации самостоятель...
5637. Изучение и расчет конструкции дробилок 2.65 MB
  Введение Увеличивающиеся из года в год объемы промышленного, гидротехнического, жилищного, дорожного и других видов строительства требуют огромного количества нерудных строительных материалов (щебня, гравия, песка), идущих на изготовление железобето...