Файл: Направление подготовки 27. 03.docx

ВУЗ: Не указан

Категория: Реферат

Дисциплина: Не указана

Добавлен: 07.12.2023

Просмотров: 135

Скачиваний: 8

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.


Уставный капитал: 0 руб.

Телефон: +7 42722 2 42 01.

Федеральная Налоговая служба: 0 руб. (0.00%), ИНН: 7707329152, ОГРН 1047707030513.

Основной вид деятельности: ОКВЭД 2 - 63.11 (Деятельность по обработке данных, предоставление услуг по размещению информации и связанная с этим деятельность).

Дополнительные виды деятельности:

1. ОКВЭД 2 - 62.09 (Деятельность, связанная с использованием вычислительной техники и информационных технологий, прочая);

2. ОКВЭД 2 - 63.11.1 (Деятельность по созданию и использованию баз данных и информационных ресурсов);

3. ОКВЭД 2 - 95.11 (Ремонт компьютеров и периферийного компьютерного оборудования).

4.2 РАЗРАБОТКА МЕРОПРИЯТИЯ ПО ФОРМИРОВАНИЮ ТРЕБОВАНИЙ К СТРУКТУРЕ

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

На этапе варианта выбора программного обеспечения мы выбрали среду разработки СУБД MS Access. Особенность этой системы в том, что она является частью MS Office, полной, практичной и простой в использовании. Использование этой системы не представляло для нас особых трудностей при проектировании системы управления связывающими базами данных. Поэтому моделирование логики данных будем проводить в среде развития СУБД MS Access.

Логическое проектирование данных — это проектирование логической структуры базы данных. Однако на него влияет физическая организация данных, предоставляемых конкретной СУБД. Поэтому существует два уровня интеллектуального анализа данных: логический и физический уровень.

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

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


1. 1-ая нормальная форма;

2. 2-ая нормальная форма;

3. 3-ья нормальная форма;

4. нормальная форма Бойса-Кодда;

5. 4-ая нормальная форма;

6. 5-ая нормальная форма, проективная связанная форма.

Сформулируем правила по нормализации базы данных в филиале ФКУ «Налог-Сервис» ФНС России по Чукотскому АО, 689000 Анадырь.

Первая нормальная форма требует, чтобы все значения полей были элементарными, а все записи — особенными.

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

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

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

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

Реляционные отношения в MS Access представлены в виде двумерной таблицы. Структура таблицы в MS Access разрабатывается в режиме конструктора. На этом этапе присваиваются имена полям таблицы, устанавливается тип данных каждого поля и задаются ключевые поля (первичные и внешние ключи). Результаты проектирования структуры таблиц представлены в таблицах 2-6.

Всего в этой базе данных пять таблиц:

1. Наименование дела;

2. Документы;

3. Сотрудники отдела;

4. Подразделения организации;

5. Сотрудники организации;

6. Штат организации.

Далее определите тип и размер полей формы.
Таблица 2. Структура «Номенклатура дел» в Филиале ФКУ «Налог-Сервис», ФНС России в Чукотском АО, 689000 г. Анадырь

Имя поля

Тип поля

Примечание

КодОтд

Текстовый

Длина 15 символов. Первичный ключ. Обязательное индексированное поле. Совпадения не допускаются.

Название организации

Текстовый

Длина 85 символов

Срок хранения, статья по перечню

Текстовый

Длина 105 символов

Примечание

Текстовый

Длина 255 символов



В данной форме используются следующие типы полей: текст - ввести текст или комбинацию текста и цифр без вычисления. Этот тип выбран для следующих полей: «КодОрг», «Название организации», «Срок годности, позиция в списке», «Примечания». Длина поля выбирается в соответствии с возможной длиной самого длинного значения атрибута.
Таблица 3. Структура «Документы» в Филиале ФКУ «Налог-Сервис», ФНС России в Чукотском АО, 689000 г. Анадырь

Имя поля

Тип поля

Примечание

ID

Счётчик

Длинное целое. Первичный ключ. Обязательное индексированное поле. Совпадения не допускаются.

КодОтд

Текстовый

Длина 25 символов

Название документа

Гиперссылка




Название подразделения

Текстовый

Длина 55 символов

Дата создания

Дата/время

Краткий формат даты

ФИО сотрудника

Текстовый

Длина 255 сиволов символов


В данной таблице используются следующие типы полей: поле "ID" (номер по порядку), тип данных которого - счётчик. Поле, в которое автоматически вводится уникальный номер при добавлении записи. Номер, созданный для записи, не может быть удалён или изменён повторно.

Текст - используется для ввода текста или комбинации текста и чисел без подсчёта. Выберите этот тип для следующих полей: «КодОрг», «Название подразделения», «Имя сотрудника». Длина поля выбирается на основе максимально возможной длины значения атрибута.

Дата/время - этот тип используется для печати даты и времени. Этот тип удобен для полей «дата» с коротким форматом даты.

Гиперссылка - цветной подчёркнутый текстовый или графический объект, который при нажатии переходит к файлу или фрагменту документа. Этот тип данных был выбран для использования в поле «Название документа».
Таблица 4. Структура «Сотрудники организации» в Филиале ФКУ «Налог-Сервис», ФНС России в Чукотском АО, 689000 г. Анадырь

Имя поля

Тип поля

Примечание

ТабНом

Текстовый

Длина 25 символов. Первичный ключ. Обязательное индексированное поле. Совпадения не допускаются.

ФИО

Текстовый

Длина 255 символов

Название должности

Текстовый

Длина 30 символов


В таблице 4 используются следующие типы полей: текст - используется для ввода текста или комбинации текста и чисел, без вычисления. Этот тип выбран для следующих полей: «ТабНом», «Имя сотрудника», «Название должности». Длина полей выбирается исходя из максимально возможной длины значения атрибута.
Таблица 5. Структура «Подразделения организации» в Филиале ФКУ «Налог-Сервис», ФНС России в Чукотском АО, 689000 г. Анадырь

Имя поля

Тип поля

Примечание

НазОтд

Текстовый

Длина 255 символов. Первичный ключ. Обязательное индексированное поле. Совпадения не допускаются.

Руководитель отдела

Текстовый

Длина 25 символов

НомКаб

Числовой

Длинное целое

Телефон

Текстовый

Длина 20 символов.


В таблице 5 представленные следующие типы полей: текстовый - для ввода текста или комбинации текста и чисел, не требующих вычисления. Этот тип выбран для следующих полей: «НазПодр», «Руководитель отдела», «Телефон». Длина полей выбирается исходя из максимально возможной длины значения атрибута.

Числовое значение - значение, используемое для выполнения расчёта. Данный числовой тип поля представлен для следующих полей: «НомКаб» с размером длинное целое.
Таблица 6. Структура «Штат организации» в Филиале ФКУ «Налог-Сервис», ФНС России в Чукотском АО, 689000 г. Анадырь

Имя поля

Тип поля

Примечание

НазДолж

Текстовый

Длина 255 символов. Первичный ключ. Обязательное индексированное поле. Совпадения не допускаются.

Объем нагрузки в часах

Текстовый

Длина 25 символов

ДолжИнст

Гиперссылка





В таблице 6 используются следующие типы полей: текст - Ввод текста или комбинации текста и чисел, без вычисления. Этот тип выбран для следующих полей: «НазДолж, «Объем нагрузки в часах», «ДолжИнст». Длина поля выбирается на основе максимально возможной длины значения атрибута.


Гиперссылка - цветной подчёркнутый текстовый или графический объект, при нажатии на который происходит переход к файлу, фрагменту файла. Этот тип данных выбран для поля «ДолжИнст».

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

Схема данных для проектируемой автоматизированной системы в Филиале ФКУ «Налог-Сервис», ФНС России в Чукотском АО, 689000 г. Анадырь показана на рисунке 2.



Рисунок 2. Схема данных автоматизированной системы
Основным требованием к надёжности СУБД является поддержание целостности данных. Целостность базы данных - это атрибут, означающий, что она хранит полное, последовательное и адекватное представление предметной области. Контроль целостности отношений данных обычно означает анализ связанных таблиц на предмет соблюдения следующих правил:

  1. Каждая запись связанной таблицы соответствует нулю или более записей подчинённой таблицы;

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

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

5. ОТРАБОТКА НАВЫКОВ ПРОВЕРКИ ТЕХНИЧЕСКОГО И ЭКСПЛУАТАЦИОННОЙ ДОКУМЕНТАЦИИ АСУП

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