Автор: Пользователь скрыл имя, 28 Февраля 2012 в 13:01, курсовая работа
Основная цель разработки и последующего совершенствования автоматизированной информационной системы (АИС) налоговых органов – построение функционально полной информационной системы, объединяющей все структуры налоговой системы на базе единой вычислительной сети с поэтапной интеграцией в единое информационное пространство административных органов федерального, регионального и территориального уровней, а также других заинтересованных организаций (ГУВД, судов, таможни, банков и др.).
1. Понятие, концепции, проблемы налоговых информационных систем.
2. Роль и место информационных систем в деятельности налоговых органов.
3. Основные требования к АИС налоговых органов.
4. Основные принципы построения и использования ИС в налогообложении.
Пример.
Имя отношения: Деталь | |||||
Поле | Признак ключа | Формат поля | |||
Имя поля | Наименование | Тип | Длина | Точность | |
Номер детали | Номер детали | * | Числовой | Целое |
|
Название детали | Название детали |
| Символьный | 20 |
|
Цвет | Цвет детали |
| Символьный | 20 |
|
Вес | Вес детали, г |
| Числовой | С плавающей точкой | 3 |
Логическое проектирование осуществляется с целью выбора конкретной СУБД и преобразования концептуальной модели в логическую. Разрабатываются структуры таблиц, связи между ними и определяются ключевые реквизиты.
Этап физического проектирования дополняет логическую модель характеристиками, которые необходимы для определения способов физического хранения и использования БД, объема памяти и типа устройств хранения. При физической организации БД имеют дело не с представлением данных в прикладных программах, а с их размещением на запоминающих устройствах.
В результате проектирования БД должна быть разработана информационно-логическая модель данных, т.е. определен состав реляционных таблиц, их структура и логические связи. Структура реляционной таблицы определяется составом полей, типом и размером каждого поля, а также ключом таблицы.
Эксплуатация БД начинается с заполнения БД реальными данными. На этом этапе требуется сопровождение БД – проведение контроля целостности данных, непротиворечивости, резервное копирование, архивирование.
В последние годы широко внедряются постреляционная, многомерная и объектно-ориентированная модели данных. Они служат для интеграции баз данных, баз знаний и языков программирования.
Язык структурированных запросов SQL является стандартным языком запросов при работе с реляционными базами данных. Он предназначен для выполнения операций над таблицами (создание, удаление, изменение структуры) и над данными таблиц (выборка, добавление, удаление). SQL не содержит операторов управления, организации подпрограмм, ввода-вывода и поэтому автономно не используется. Обычно он погружен в среду встроенного языка программирования СУБД.
4.5. Нормализация отношений.
В реляционной БД на каждое отношение накладывается такое ограничение – они должны быть нормализованы.
Нормализация отношений – формальный аппарат ограничений на формирование отношений, который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных.
Основателем реляционной модели данных Е. Коддом выделены три нормальные формы отношений. Этот набор в дальнейшем был дополнен нормальной формой Бойса-Кодда, и далее четвертой и пятой нормальными формами.
Первая нормальная форма.
Ее суть состоит в требовании атомарности (неделимости) полей и единственности значений по полям в реляционной модели данных.
Пример: СПИСОК
Студент | Номер зачетной книжки | Дисциплина | Семестр | Оценка | ||
Фамилия | Номер комнаты | Номер телефона | ||||
Иванов | 101 | 29-07-64 | 111 | Математика | 1 | Хорошо |
Кузнецов | 101 | 29-07-64 | 112 | Информатика | 2 | Отлично |
Горбунова | 202 | 29-08-15 | 110 | Психология | 3 | Хорошо |
Данное отношение не нормализовано, так как содержит сложный атрибут Студент. Чтобы привести отношение к нормализованному виду, надо от него избавиться. Полученное соотношение СПИСОК (Фамилия, Номер_комнаты, Номер_телефона
Операции над отношениями.
В реляционной БД на каждое отношение накладывается и другое ограничение - они должны быть нормализованы. Это означает, что каждый атрибут должен быть простым - содержать атомарные, неделимые значения.
Нормализация отношений — формальный аппарат ограничений на формирование отношений (таблиц), который позволяет устранить дублирование, обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты на ведение (ввод, корректировку) базы данных.
Е.Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.
Первая нормальная форма
Пример: приведенное ниже отношение СТУДЕНТ не нормализовано, поскольку содержит сложный атрибут "Спорт".
СТУДЕНТ
Фамилия | Курс | Специальность | Спорт | |
Вид | Разряд | |||
Иванов Савинов Петров | 1 3 1 | Бух.учет ФИК Статистика | Плавание Шахматы Теннис | м.с. к.м.с. I |
Чтобы привести это отношение к нормализованному виду, надо избавиться от сложного атрибута "Спорт". Тогда полученное отношение СТУДЕНТ(Фамилия, Вид_спорта, Курс, Специальность, Спорт_разряд) является нормализованным. Ключ в нем является составным, состоящим из атрибутов "Фамилия" и "Вид_спорта".
Отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые (далее неделимы). Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа.
Например, отношение СТУДЕНТ(Номер, Фамилия, Имя, Отчество, Дата, Группа) находится в первой нормальной форме.
Вторая нормальная форма
Чтобы рассмотреть вопрос приведения отношений ко второй нормальной форме, необходимо дать пояснения к таким понятиям, как функциональная зависимость и полная функциональная зависимость.
Описательные реквизиты информационного объекта логически связаны с общим для них ключом, эта связь носит характер функциональной зависимости реквизитов.
Функциональная зависимость реквизитов — зависимость, при которой в экземпляре информационного объекта определенному значению ключевого реквизита соответствует только одно значение описательного реквизита.
Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты.
Пример графического изображения функциональных зависимостей реквизитов СТУДЕНТ показан на рис. 19, на котором ключевой реквизит указан *.
Рис. 19. Графическое изображение функциональной зависимости реквизитов
В случае составного ключа вводится понятие функционально полной зависимости.
Функционально полная зависимость неключевых атрибутов заключается в том, что каждый неключевой атрибут функционально зависит от ключа, но не находится в функциональной зависимости ни от какой части составного ключа.
Отношение будет находиться во второй нормальной форме, если оно находится в первой нормальной форме, и каждый неключевой атрибут функционально полно зависит от составного ключа.
Пример: Отношение СТУДЕНТ(Номер, Фамилия, Имя, Отчество, Дата, Группа) находится в первой и во второй нормальной форме одновременно, так как описательные реквизиты однозначно определены и функционально зависят от ключа Номер. Отношение УСПЕВАЕМОСТЬ(Номер, Фамилия, Имя, Отчество, Дисциплина, оценка) находится в первой нормальной форме и имеет составной ключ Номер+Дисциплина. Это отношение не находится во второй нормальной форме, так как атрибуты Фамилия, Имя, Отчество не находятся в полной функциональной зависимости с составным ключом отношения.