Проектирование и разработка БД «Регистрация и учёт юридических и физических лиц в налоговых органах РФ. курсовая работа. Введение Глава История
 Скачать 50.1 Kb.
|
|
Оглавление Введение……………………………………………………………………………1 Глава 1. История…………………………………………………………………...6 1.1. Первый этап - базы данных на больших ЭВМ……………………….6 1.2. Эпоха персональных компьютеров…………………………………...8 1.3. Распределенные многопользовательские базы данных…………….11 Глава 2. Теоретические сведения………………………………………………..14 2.1. Общие положения………………………………………………….…14 2.2. Этапы проектирования базы данных……………………………..…16 2.3 Требования к приложению……………………………………………18 2.4. Основные модели данных……………………………………………19 Глава 3. Проектирование и разработка базы данных по регистрации и учету юридических и физических лиц в налоговых органах РФ…………………….20 3.1. Описание предметной области………………………………………20 3.2. Анализ реквизитного состава и установление функциональных зависимостей между реквизитами………………………………………………20 3.2.1. Определение функциональных зависимостей между реквизитами в соответствии с требованиями первой нормальной формы(1НФ)…………….20 3.2.2. Определение функциональных зависимостей между реквизитами в соответствии с требованиями второй нормальной формы(2НФ) ………..…..20 3.2.3. Определение функциональных зависимостей между реквизитами в соответствии с требованиями третьей нормальной формы(3НФ)…………....21 3.3. Образование информационных объектов установим для каждого описательного реквизита ключевые реквизиты……………………………….21 3.4. Создание информационно-логической модели предметной области в каноническом виде………………………………………………………………22 3.5. Создание даталогической модели реляционной базы данных……22 3.6. Программные разработки……………………………………………23 3.6.1. Разработка структур БД……………………………………………24 3.6.2. Ввод данных………………………………………………………...25 Заключение………………………………………………………………...27 Список использованных источников и литературы…………………….29 ВВЕДЕНИЕ Базы данных — это структура, предназначенная для сохранения больших размеров информации и программных модулей, исполняющих управление данными, их выборку, сортировку и остальные сходные действия. Информация базы данных хранится в одной или нескольких таблицах. Любая таблица с данными складывается из набора однотипных записей, размещенных друг за другом. Они представляют собой строки таблицы, которые можно добавлять, удалять или изменять. Каждая запись представляется комплектом именованных полей, или ячеек, которые могут хранить самую разнообразную информацию, начиная от даты рождения и заканчивая подробным описанием различных видов спорта. Однотипные поля разных записей образуют столбец таблицы. Выстроив одну таблицу, можно получить полноценную базу данных. Однако в реальных услових жизни структуры баз данных, а соответственно и способы их создания, намного сложнее. На протяжении многих лет на первый план выставляется новая отрасль - информационная индустрия, связанная с производством технических средств, методов, технологий для производства новых знаний. Эта отрасль связана с развитием вычислительной техники. В информационном обществе преобладает производство информационного продукта, а физический продукт становится более информационным. Изменится весь образ жизни, система ценностей: возрастет значение культурных развлечений, возрастет потребность в знаниях, повысится способность ума к работе и творчеству. В результате возникают конфликты между ограниченной способностью человека к восприятию и обработке информации и существующим набором хранимой и передаваемой информации. Возникло большое число избыточной информации, в которой временами трудно сориентироваться и выбрать нужные сведения. Для решения подобных проблем применяются автоматизированные базы данных. Они стали неотъемлемой частью практически всех компьютерных систем - от отрасли до отдельного предприятия. За последние несколько лет вырос уровень потребительских качеств систем управления базами данных (СУБД): разнообразие поддерживаемых функций, удобный для пользователя интерфейс, сопряжение с программными продуктами, в частности с другими СУБД, возможности для занятия в сети и т. СУБД разрешает сводить воедино информацию из самых разных источников (электронные таблицы, другие базы данных) и помогает быстро найти необходимую информацию, донести ее до окружающих с помощью отчетов, графиков или таблиц. К настоящему времени накоплен сильный опыт проектирования БД, предназначенных для управления производством, это позволяет сделать процесс создания БД более эффективным. Актуальность темы В настоящее время, невзирая на повышение компьютеризации общества, в сфере образования до сих пор нет средств, позволяющих в достаточной мере автоматизировать процесс ведения документации и отчетности. Одной из составных задач можно рассматривать проблему составления расписания учебного процесса, а также оперативную корректировку расписания при возникновении необходимости в этом. О своевременности и актуальности рассматриваемой проблемы говорит тот факт, что большую часть своего времени администраторы заведений и преподаватели тратят на оформление различной документации и отчетов. Огромное количество учебных заведений и отсутствие предложений в данной сфере гарантируют высокую потребность в данном продукте. Базы данных (БД) составляют в настоящее время базу компьютерного обеспечения информативных процессов, входящих практически во все сферы человеческой деятельности. Действительно, процессы обработки информации носят общий характер и основаны на описаниях фактологических фрагментов, представляемых в виде набора взаимозависимых наборов данных. Базы данных - это эффективный способ представления структур данных и управления ими. Концепция базы данных предполагает использование интегрированных средств хранения информации, которые позволяют централизованно управлять информацией и ее услугами для множества пользователей. При этом БД должна поддерживаться в среде ЭВМ единым программным обеспечением, называемым системой управления базами данных (СУБД). СУБД совместно с прикладными программами называют банком данных. Одно из основных назначений СУБД – поддержка программными средствами представления, соответственного реальности. Целью курсовой работы является: 1. Исследовать теоретические документы по базам данных; 2. Унификация теоретических основ организации баз данных, включая построение принципов на концептуальном, логическом и физическом уровнях; 3. Разработка материалов в соответствии с заданием на курсовую работу. Оформление курсовой работы в соответствии с заданными требованиями. Глава 1. История базы данных 1.1. Первый этап - базы данных на больших ЭВМ История развития СУБД имеет больше 30 лет. В 1968 г. была введена в эксплуатацию первая индустриальная СУБД система IMS фирмы IBM. В 1975 году появился первый стандарт ассоциации по языкам систем обработки данных - Conference of Data System Languages (CODASYL), который определил ряд фундаментальных понятий в теории систем баз данных, которые и до сих пор являются основными для сетевой модели данных. В дальнейшее развитие теории баз данных большой вклад был сделан североамериканским арифметиком Э. Коддом, кто является творцом реляционной модели данных. В 1981 г. Э. Кодд заработал за создание реляционной модели и реляционной алгебры престижную премию Тьюринга Американской ассоциации по вычислительной технике. Меньше двух десятков лет прошло с данного момента, но стремительное развитие вычислительной техники, изменение ее принципиальной роли в жизни общества, обрушившийся бум персональных ЭВМ и, наконец, появление мощных рабочих станций и сетей ЭВМ повлияло также и на развитие технологии баз данных. Можно выделить 4 этапа в развитии этого направления в обработке данных. Однако необходимо заметить, что все же нет жестких скоротечных ограничений в этих этапах: они плавно переходят один в другой и даже сосуществуют параллельно, но тем не менее выделение этих этапов позволит более четко охарактеризовать отдельные стадии развития схемы баз данных, подчеркивать особенности, специфичные для конкретного этапа. Первый момент развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP11 (фирмы Digital Equipment Corporation - DEC), разнообразных моделях HP (фирмы Hewlett Packard). Базы данных сохранялись в внешней памяти основной ЭВМ, пользователями данных баз данных были задачи, запускаемые в основном в пакетном режиме. Интерактивный режим доступа оснащался с помощью консольных терминалов, которые не обладали собственными вычислительными ресурсами (процессором, внешней памятью) и служили только устройствами ввода-вывода для центральной ЭВМ. Программы доступа к БД писались на различных языках и запускались как обычные числовые программы. Сильные операционные системы обеспечивали возможность условно параллельного выполнения всего множества задач. Эти системы можно было отнести к системам распределенного доступа, потому что база данных была централизованной, сберегалась на устройствах внешней памяти одной основной ЭВМ, а доступ к ней поддерживался от многих пользователей-задач. Особенности этого этапа развития выражаются в следующем: · Все СУБД базируются на мощных мультизадачных операционных системах (MVS, SVM, RTE, OSRV, RSX, UNIX), поэтому в основном поддерживается работа с централизованной базой данных в режиме распределенного многопользовательского доступа. · Функции управления распределением ресурсов в основном осуществляются операционной системой (ОС). · Поддерживаются языки невысокого уровня манипулирования данными, ориентированные на навигационные методы доступа к данным. · Внушительная роль отдается администрированию данных. · Проводятся серьезные работы по обоснованию и формализации реляционной модели данных, и была создана первая система (System R), реализующая идеологию реляционной модели данных. · Проводятся теоретические работы по оптимизации запросов и управлению распределенным доступом к централизованной БД, было введено понятие транзакции. · Результаты научных исследований открыто обсуждаются в печати, идет мощный поток общедоступных публикаций, касающихся всех аспектов теории и практики баз данных, и результаты теоретических исследований активно внедряются в коммерческие СУБД. Появляются первые языки высокого уровня для работы с реляционной моделью данных. Однако отсутствуют стандарты для этих первых языков. 1.2. Эпоха персональных компьютеров Персональные компьютеры быстро вошли в нашу жизнь и действительно изменили наше представление о месте и роли компьютерных технологий в жизни общества. Сегодня компьютеры стали ближе и доступнее для любого пользователя. Обычные пользователи больше не боятся сложных и запутанных языков программирования. Мы разработали множество программ, предназначенных для новых пользователей. Эти программы просты в использовании и интуитивно понятны: в первую очередь это текстовые редакторы, электронные таблицы и другие программы. Операции копирования файлов и переноса информации с одного компьютера на другой, печать документов, таблиц и других документов стали простыми и понятными. Системные программисты отошли на задний план. Любой пользователь имеет полный контроль над мощным и удобным устройством, позволяющим автоматизировать многие нюансы операций. И, конечно же, это сказывается и на уроке баз данных. Есть программы, которые называются системами управления базами данных и позволяют хранить большой объем информации, имеют удобный интерфейс для заполнения данных, встроенные инструменты для создания различных отчетов. Эти программы могут автоматизировать важные учетные функции, которые ранее выполнялись вручную. Систематическое уменьшение цен на персональные компьютеры сделало их доступными не только для организаций и фирм, а и для индивидуальных пользователей. Компьютеры стали прибором для ведения документации и собственных учетных функций. Это все сыграло как положительную, так и отрицательную значимость в области развития баз данных. Кажущаяся простота и доступность персональных компьютеров, и их программного обеспечения породила множество дилетантов. Эти разработчики, считая себя знатоками, стали проектировать недолговечные базы данных, что не учитывали многих особенностей объектов реального мира. Много было разработано систем-однодневок, которые не отвечали законам развития и взаимосвязи реальных объектов. Однако простота персональных компьютеров заставила пользователей из многих областей знаний, которые ранее не применяли вычислительную технику в своей деятельности, обратиться к ним. И спрос на развитые удобные программы обработки данных заставлял поставщиков программного обеспечения поставлять все новые системы, которые принято называть настольными (desktop) СУБД. Внушительная конкуренция между поставщиками заставляла улучшать эти системы, предлагая новейшие возможности, улучшая интерфейс и быстродействие систем, снижая их стоимость. Наличие на рынке большого числа СУБД, исполняющих похожие функции, потребовало разработки методов экспорта - импорта данных для этих систем и открытия форматов сохранения данных. Но и в этот период появились любители, которые, вопреки здравому смыслу, разрабатывали собственные СУБД на стандартных языках программирования. Это тупиковый путь, так как последующие разработки показали, что перенос данных из нестандартных форматов в новые СУБД будет намного сложнее и в некоторых случаях требует таких трудозатрат, как было бы проще это сделать. все с нуля, но данные все равно пришлось мигрировать на новую, более перспективную СУБД. И это тоже результат недооценки функций, которые должна выполнять СУБД. Особенности этого этапа следующие: · Все СУБД рассчитаны на создание БД в основном с монопольным доступом. И это понятно. Персональный компьютер, он не был подсоединен к сети, и база данных на нем создавалась для работы одного пользователя. В редких случаях предполагалась последовательная работа нескольких пользователей, например, первоначально оператор, который вводил бухгалтерские документы, а позже главбух, который определял проводки, соответствующие первичным документам. · Большинство СУБД имели развитый и удобный пользовательский интерфейс. В большинстве существовал интерактивный режим работы с БД как в рамках описания БД, так и в рамках проектирования запросов. Кроме того, большинство СУБД предлагали развитый и удобный инструментарий для разработки готовых приложений без программирования. Инструментальная среда состояла из готовых элементов приложения в виде шаблонов экранных форм, отчетов, этикеток (Labels), графических конструкторов запросов, которые достаточно просто могли быть собраны в единый комплекс. · Во всех настольных СУБД поддерживался только внешний уровень представления реляционной модели, то есть только внешний табличный вид структур данных. · При наличии высокоуровневых языков манипулирования данными типа реляционной алгебры и SQL в настольных СУБД поддерживались низкоуровневые языки манипулирования данными на уровне отдельных строк таблиц. · в настольных СУБД отсутствовали средства поддержки ссылочной и структурной целостности базы данных. Эти функции должны были выполнять приложения, однако скудость средств разработки приложений иногда не позволяла это сделать, и в этом случае эти функции должны были выполняться пользователем, требуя от него дополнительного контроля при вводе и изменении информации, хранящейся в БД. · Наличие монопольного режима работы фактически привело к вырождению функций администрирования БД и в связи с этим - к отсутствию инструментальных средств администрирования БД. · И, наконец, последняя и в настоящий момент весьма положительная особенность - это сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД. Вполне работоспособные приложения, разработанные, например, на Clipper, работали на PC 286. · В принципе, их даже трудно назвать полноценными СУБД. Яркие представители этого семейства - очень широко использовавшиеся до недавнего времени СУБД Dbase (DbaseIII+, DbaselV), FoxPro, Clipper, Paradox. 1.3. Распределенные многопользовательские базы данных Всем известно, что история развития идет по спирали, поэтому после процесса «персонализации» начался обратный процесс интеграции. Количество локальных сетей увеличивается, все больше информации передается между компьютерами, остро встает проблема непротиворечивости данных, хранящихся и обрабатываемых в разных местах, но логически друг с другом связанных, возникают задачи, связанные с параллельной обработкой транзакций - последовательностей операций над БД, переводящих ее из одного непротиворечивого состояния в другое непротиворечивое состояние. Удачное решение этих задач приводит к образованию распределенных многопользовательских баз данных, сохраняющих все преимущества настольных СУБД и в то же время позволяющих организовать параллельную обработку информации и поддержку целостности БД. Особенности данного этапа: - Практически все современные СУБД дают поддержку полной реляционной модели, а именно: - структурной целостности - допустимыми являются только данные, представленные в виде отношений реляционной модели; - языковой целостности, то есть языков манипулирования данными высокого уровня (в основном SQL); - ссылочной целостности, контроля за соблюдением ссылочной целостности в течение всего времени функционирования системы, и гарантий невозможности со стороны СУБД нарушить эти ограничения. - Большинство современных СУБД рассчитаны на многоплатформенную архитектуру, то есть они могут работать на компьютерах с разной архитектурой и под разными операционными системами, при этом для пользователей доступ к данным, управляемым СУБД на разных платформах, практически неразличим. - Необходимость поддержки работы нескольких пользователей с базами данных и возможности децентрализованного хранения данных вызывает необходимость разработки средств администрирования баз данных с реализацией общей концепции средств защиты данных. - Потребность в новых реализациях привела к возникновению серьезных теоретических работ по оптимизации реализаций распределенных многопользовательских баз данных и работе с распределенными запросами и транзакциями с результатами реализации, полученными в коммерческих СУБД. - Чтобы не терять клиентов, ранее работавших на десктопных СУБД, почти все современные СУБД имеют средства для подключения клиентских приложений, разработанных с использованием СУБД, на десктоп и средства для экспорта данных из форматов СУБД на десктоп второго этапа разработки. Именно на этом этапе было разработано несколько стандартов в контексте языков манипулирования данными и описания, начиная с SQL89, SQL92, SQL99, и технологий обмена данными между различными СУБД, включая протокол ODBC (Open DataBase Connectivity), предусмотренный от Майкрософта. - Именно к этому этапу можно отнести начало работ, связанных с концепцией объектно-ориентированных БД - ООБД. Представителями СУБД, относящимся ко второму этапу, можно считать MS Access и все современные серверы баз данныхOracle7.3, Oracle 8.4, MS SQL-Server 6.5, MS SQL-Server 7.0, System 10, System 11, Informix, DB2, Progress, SQLBase и другие современные серверы баз данных, которых в настоящий момент насчитывается несколько десятков. Глава 2. Теоретические сведения 2.1. Общие положения База данных (БД) – это совокупность документов, систематизированных таким образом, чтобы их можно было легко найти и обработать с помощью ПК или другого компьютера (ЭВМ). Под документацией можно понимать все: статьи, различные документы, отчеты и т.д. Модели баз данных основаны на современном подходе к обработке информации. Информационная структура базы данных позволяет создавать логические записи об элементах и их отношениях. Отношения могут быть «один к одному», «один ко многим» и «многие ко многим». Применение того или иного типа взаимосвязи определены тремя моделями базы данных: - иерархической - сетевой - реляционной Иерархическая модель данных — это модель данных, где используется представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней. Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка, к потомку, при этом возможна ситуация, когда объект-предок не имеет потомков или имеет их несколько, тогда как у объекта-потомка обязательно только один предок. Объекты, имеющие общего предка, называются близнецами. Достоинства: - эффективное использование памяти - неплохие временные характеристики выполнения операций над данными Недостатки: - сложные логические связи - громоздкость в обработке данных Сетевая модель данных - это логическая модель данных, представляющая их сетевыми структурами типов записей и связанные отношениями мощности один-к-одному или один-ко-многим. В отличие от реляционной модели, содержащиеся в ней отношения моделируются наборами, которые реализуются с помощью указателей. Сетевая модель данных — это расширенная версия иерархической модели, но основное отличие состоит в том, что сетевая модель данных имеет двунаправленные указатели, соединяющие связанную информацию. Достоинства: - высокая эффективность затрат памяти - оперативность обработки данных Недостатки: - сложность и жёсткость схемы базы - сложность понимания - ослаблен контроль целостности, так как в ней разрешено устанавливать различные связи между записями В реляционной базе данных вся информация отображается в виде таблицы, а все операции с данными являются табличными операциями. Таблицы состоят из строк и столбцов. Строки представляют собой записи, а столбцы показывают структуру записи (каждый столбец имеет определенный тип данных и длину данных). Строки таблицы неупорядоченно - у них нет первой или десятой строки. Однако, поскольку на строки нужно каким-то образом ссылаться, было сформировано понятие «первичный ключ». Достоинства: - простота моделирования и физическая реализация - высокая эффективность обработки данных Недостатки: - отсутствие стандартных средств идентификации каждой отдельной записи Проектирование базы данных (БД) – одна из наиболее непростых и ответственных задач, связанных с созданием информационной системы (ИС). В результате её решения должны быть поставлены содержание БД, лучший для всех её будущих пользователей способ организации данных и инструментальные средства управления данными. Главная цель процесса проектирования БД состоит в получении такого проекта, который удовлетворяет следующим требованиям: - корректность схемы БД, т. е. база должна быть гомоморфным образом моделируемой предметной области (ПО), где каждому объекту предметной области соответствуют данные в памяти ЭВМ, а каждому процессу – адекватные процедуры обработки данных; - обеспечение ограничений ; - эффективность функционирования ; - защита данных (от аппаратных и программных сбоев и несанкционированного доступа); - простота и удобство эксплуатации; -гибкость, т. е. возможность развития и адаптации к изменениям предметной области и/или требований пользователей 2.2. Этапы проектирования базы данных Процесс проектирования включает в себя следующие этапы. Концептуальное проектирование – это конструирования информативноймодели, не зависящей от каких-либо физических условий реализации. Логическое проектирование – это конструирования информационной модели на основе существующих моделей данных, не зависимо от используемой СУБД и других условий физической Физическое проектирование – это процедура создания описания конкретной реализации БД с описанием структуры хранения данных, методов доступа к данным. Концептуальный дизайн (информатика) строит семантическую модель предметной области, то есть информационную модель на высшем уровне абстракции. Такая модель создается без ориентации на конкретную СУБД или модель данных. Термины "семантическая модель", "концептуальная модель" и "инфологическая модель" являются синонимами. Кроме того, в этом контексте одинаково могут использоваться слова "модель базы данных" и "модель предметной области" (например, "концептуальная модель базы данных" и "концептуальная модель предметной области"), потому что эта модель является одновременно образом реальности и образ базы данных дизайна для этой реальности. Определенный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам. Больше всего концептуальная модель базы данных содержит в себе: · описание информационных объектов или понятий предметной области и связей между ними. · описание ограничений целостности, т. требований к допустимым значениям данных и к связям между ними. Логическое (даталогическое) проектирование - создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель - набор схем отношений, обычно с указанием первичных ключей, а также "связей" между отношениями, представляющих собой внешние ключи. Изменение концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Данный этап может быть в значительной степени автоматизирован. На этапе логического проектирования учитывается специфика конкретной модели данных, а может не учитываться специфика конкретной СУБД. Физическое проектирование - создание схемы базы данных на конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, объединенных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т. 2.3. Требования к приложению Процесс проектирования базы данных охватывает несколько ключевых областей. Проектировать объекты базы данных (таблицы, представления, индексы, триггеры, хранимые процедуры, функции, пакеты) для представления данных предметной области в базе данных. Разработка интерфейсов для взаимодействия с базой данных (формы, отчеты и т. д.), т. е. разработка приложений, которые будут сохранять данные в базе данных и реализовывать отношения ответов для этих данных. Проектирование базы данных для конкретного компьютера или вычислительной среды (архитектура клиент-сервер, параллельная архитектура, распределенная вычислительная среда). Проектирование баз данных для нужд системы (интеллектуальный анализ данных, OLAP, OLTP и т. д.). Приложения базы данных разрабатываются с учетом физической схемы базы данных, а не отдельно! Компьютерная среда часто используется в качестве исходных данных для проектирования, но иногда проектирование должно выполняться с возможностью переноса на другую аппаратную платформу или технологию в будущем. 2.4. Основные модели данных Модель данных (DM) — это набор правил создания структур данных в базе данных, действий над ними, а также ограничений целостности, определяющих отношения данных и значения, разрешающих, предписывающих изменять их. Базы данных создаются для достижения определенных исследовательских целей, и в зависимости от изменения или расширения целей модель базы данных может измениться. Развитие теории и практики проектирования и эксплуатации баз данных сопровождается углубленной разработкой моделей данных. Первой DM, использованной для построения концептуальных карт, была иерархическая модель. Затем появились сетевые модели. Затем появились ER-модели, а в результате их развития — реляционные и постреляционные модели. Каждая из этих моделей имеет свои преимущества и недостатки. Свойство проявляется, когда логика представления предметной области полностью описывается выбранной моделью данных. Глава 3. Проектирование и разработка базы данных по регистрации и учету юридических и физических лиц в налоговых органах РФ. 3.1. Описание предметной области Муниципальная налоговая инспекция создает базу данных юридических лиц с указанием всех их реквизитов и видов деятельности, причем у юридического лица может быть несколько видов деятельности. Должна быть возможность просматривать как список юридических лиц по каждому виду деятельности, так и перечень видов деятельности по каждому юридическому лицу, а также обеспечить формирование запросов-выборок по различным условиям. Юридические лица могут иметь несколько фирм. 3.2. Анализ реквизитного состава и установление функциональных зависимостей между реквизитами Анализ реквизитного состава проведем на основании описанной предметной области. 3.2.1. Определение функциональных зависимостей между реквизитами в соответствии с требованиями первой нормальной формы(1НФ) Проведем анализ реквизитного состава и определим функциональные зависимости. В рамках решаемой задачи все реквизиты содержат простые (атомарные) данные, следовательно, отношения находятся в 1НФ форме. Анализ функциональных зависимостей показал, так как одно юридическое лицо может занимать несколько видов деятельности, а вид деятельности может иметь нескольких юридических лиц, то нужно ввести добавочные коды. Ключевыми полями будут Код юридического лица- КодЮридическогоЛица, Код вида деятельности- КодВидаДеятельности. 3.2.2. Определение функциональных зависимостей между реквизитами в соответствии с требованиями второй нормальной формы(2НФ) По определению отношение находится во второй нормальной форме тогда, когда оно находится в первой нормальной форме и не содержит неполных функциональных зависимостей не первичных атрибутов от атрибутов первичного ключа. Во всех отношениях ключевые поля простые, следовательно, отношения автоматически находятся во второй нормальной форме. 3.2.3. Определение функциональных зависимостей между реквизитами в соответствии с требованиями третьей нормальной формы(3НФ) По определению отношение находится в третьей нормальной форме тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей не первичных атрибутов от атрибутов первичного ключа. Для представления отношений в 3НФ функциональные зависимости в них должны выглядеть так как представлено в Таблице 1.2. 3.3. Образование информационных объектов установим для каждого описательного реквизита ключевые реквизиты. В таблицу не включаются повторы соответствия описательных и ключевых реквизитов. Образование информационных объектов происходит на основании объединения реквизитов. Сгруппируем описательные реквизиты, одинаково зависимые от ключевых реквизитов, и объединим их с ключевыми в один информационный объект. Сгруппируем описательные реквизиты, одинаково зависимые от ключевых реквизитов, и объединим их с ключевыми в один информационный объект. Связи между информационными объектами осуществляется через внешние ключи. Информационные объекты сключами связи и типом отношения. 3.4. Создание информационно-логической модели предметной области в каноническом виде Информационно-логическая модель настоящей области в каноническом виде демонстрирует иерархию подчинения информационных объектов по уровням, характеризуемым количеством связей в наиболее длинном пути через вершины модели к объекту. На уровне 0 распределяются информационные объекты, что не содержат внешних ключей. На уровне 1 находятся информационные объекты, что содержат только внешние ключи объектов, располагающиеся на уровне 0. На уровне 2 размещаются информационные объекты, которые содержат внешние ключи объектов, расположенных на уровне 0, 1. 3.5. Создание даталогической модели реляционной базы данных Даталогическая модель реляционной базы данных определяется совокупностью логически с объединённых реляционных таблиц. Каждая таблица имеет структуру, определяемую реквизитным составом информационного объекта информационно-логической модели. Логические связи между таблицами соответствуют структурным связям между информационными объектами и устанавливаются на уровне ключей связи (внешним ключом подчиненной таблицы и первичным ключом главной таблицы). налоговый инспекция база данные Логическая структура реляционной базы данных (схема данных), построенная на основе информационно-логической модели предметной области. Логическая структура реляционных таблиц зависит от СУБД, с помощью которой будет разрабатываться база данных. Разные СУБД поддерживают разные типы данных, имеют разные ограничения на длину имени поля и символы, используемые в имени, свойства поля могут быть разными и т.д. В таблицах представлена логическая структура реляционных таблиц базы данных MS Access. 3.6. Программные разработки Для реализации исследованной информационной системы подобрана СУБД MS Access, что является реляционной СУБД функционирующей в среде Windows. Как и иные продукты этой категории, она предназначена для хранения и поиска данных, представления информации в комфортном виде и автоматизации часто повторяющихся операций. С помощью Access можно проектировать простые и удобные формы ввода данных, а также реализовывать обработку данных и выдачу сложных отчетов. В системе Access предусмотрены: контекстно-зависимая справка; простые в применении профессионалы и конструкторы; импортирование, экспортирование и связывание внешних файлов; формы и отчеты, конструируемые по принципу WYSIWYG (What You See Is What You Get - что видишь, то и получишь); многотабличные запросы и отношения; разработка графиков и диаграмм; и многое другое. СУБД MS Access ориентирована на работу с объектами, к которым относятся: таблицы, запросы, формы, отчеты, страницы доступа к данным, макросы и модули. В Access все объекты находятся в одном файле. Документ баз данных имеет оформленное в Windows расширение. Таблица - главный структурный элемент системы управления реляционной базы данных. В Microsoft Access таблицей называется объект, в котором данные хранятся в формате записей (строк) полей (столбцов). Данные в отдельной таблице используются в определенной категории, например, сведения о сотрудниках или заказах. Запросы - этотребования на разбор данных, хранящиеся в таблицах, или требование на выполнение поставленных действий с данными. Запрос разрешает создать набор записей из данных, находящихся в различных таблицах, и использовать этот набор как источник данных для формы или отчета. Формы - это объект базы данных Microsoft Access, в котором разработчик раставляет элементы управления, принимающие действия пользователей или служащих для ввода, отображения или изменения данных в полях. Отчет - это объект базы данных Microsoft Access, нужный для отображения данных, созданных и отформатированных в соответствии со спецификациями пользователя. С помощью отчетов оформляются коммерческие сводки, различные списки. Макрос - макрокоманда или набор макрокоманд, используемый для автоматического выполнения определенных операций. Модуль - это описания, инструкций и процедур, сохраненная под общим именем. В Microsoft Access имеются модули двух типов: стандартный модуль и модуль класса. Модули форм и отчетов являются модулями классов и содержат программы, являющиеся локальными для этих объектов. Процедуры обычного модуля, если они явно необъявлены локально в содержащем их модуле, распознаются и могут вызываться процедурами других модулей той же базы данных или базы данных, на которую ссылаются. Создание новой базы данных выполняется по ее структуре, полученной в результате проектирования. 3.6.1. Разработка структур БД Создание новой базы данных производится в соответствии с ее структурой, полученной проектом. Реляционная модель данных представляет собой комплекс взаимосвязанных таблиц. Таким образом, таблицы являются основным объектом реляционной базы данных и предназначены для хранения данных в домене. Создание таблицы в базе данных — это двухэтапный процесс. Сначала описывается структура таблиц и устанавливаются связи между ними. На втором этапе таблицы заполняются данными. Схема данных определяет логическую структуру базы данных. Он устанавливает отношения между таблицами и поддерживает целостность связанных данных. Схема данных позволяет упростить проектирование многотабличных форм, запросов и отчетов при построении схемы, СУБД MS Access автоматически определяет тип связи между таблицами. Если поле, по которому устанавливается связь, является уникальным ключом, как в главной таблице, так и в подчиненной, Access устанавливает связь 1:1. Если поле связи является уникальным ключом в главной таблице, а в подчиненной таблице является неключевым или входит в состав составного первичного ключа, Access устанавливает связь 1:М от главной таблицы к подчиненной. Обеспечение целостности означает выполнение для взаимосвязанных таблиц следующих условий: a) в подчиненную таблицу не может быть добавлена запись с несуществующим в главной таблице значением ключа связи; b) в главной таблице нельзя удалить запись, если не удалены связанные с ней записи в подчиненной таблице в главной таблице нельзя изменить значение ключа связи, если в записях подчиненной таблицы используется значение ключа связи. При попытке нарушения этих условий в операциях обновления или удаления данных СУБД отменяет выполнение этих операций. 3.6.2 Ввод данных Форма — это настраиваемое интерактивное окно, дозволяющее организовать интуитивно простой и удобный пользовательский интерфейс для работы с данными. Назначение форм: внесение записей в таблицу; тип записей в таблице: добавлять и удалять записи, изменять значения в полях; представление и анализ информации; Сгенерированная база данных может иметь четыре формы ввода данных и одну форму основного узла. Формы для ввода Авто, Водитель, Авто-водитель, День созданы на основе одноименных таблиц. Для отображения или выбора значений полей, содержащих коды наружных ключей использован мастер подстановки. Главная форма связывает все объекты между собой, обеспечивая удобство работы с БД. Для получения печатного документа в СУБД MS Access предусмотрено несколько возможностей: - печать таблицы в системе таблицы (вывод всех записей или записей, удовлетворяющих условиям фильтрации в табличном виде); - печать набора записей запроса в режиме таблицы; - печать отчета. Отчет - настраиваемое диалоговое окно, позволяющее организовать форматированное представление данных, предназначенное для вывода на экран, принтер или в файл. Отчеты представляют собой наилучшее средство для представления информации из базы данных в виде печатного документа. По сравнению с другими средствами вывода данных на печать, отчеты обладают 2-мя базисными преимуществами: дают большие способности для группировки, сортировки и вычисления промежуточных и общих итогов для больших наборов записей (вычисления можно делать в разрезе группы, нескольких групп и по отчету в целом); позволяют осуществлять вывод данных в виде, приближенном к стандартным бланкам документов. Для разрабатываемой БД создано три отчета. Все отчеты сделаны на основе одинаковых запросов. Заключение Преимущества применения БД Рассмотрим, какие преимущества приобретает пользователь при использовании БД как безбумажной технологии: Компактность Информация находится в БД, нет необходимости хранить многотомные бумажные картотеки Скорость Скорость обработки информации (поиск, введение изменений) компьютером намного выше ручной обработки Низкие трудозатраты Нет необходимости в утомительной ручной работе над данными Применимость Всегда доступна новая информация Дополнительные преимущества возникают при использовании БД в многопользовательской среде, поскольку становится возможным осуществлять централизованное управление данными. Современные СУБД гарантируют как физическую независимость (независимость режимов хранения и доступа), так и логическую независимость данных (возможность изменить приложение, не изменяя его (другие приложения работают с теми же данными). Современные СУБД дают возможность включать в них не только текстовую и графическую информацию, но и звуковые фрагменты и даже видеоклипы. Простота использования СУБД позволяет создавать новые базы данных, не прибегая к программированию, а пользуясь только встроенными функциями. СУБД обеспечивают правильность, полноту и непротиворечивость данных, а также удобный доступ к ним. Популярные СУБД FoxPro, Access for Windows, Paradox. Для менее сложных применений вместо СУБД используются информационнопоисковые системы (ИПС), которые выполняют следующие функции: · хранение большого объема информации; · быстрый поиск требуемой информации; · добавление, удаление и изменение хранимой информации; · заключение ее в удобном для человека виде. Система функционирует довольно устойчиво и не утрачивает работоспособность при некорректных действиях пользователя. В разработанной БД использованы все возможности СУБД по поддержке целостности данных и ссылочной целостности. В рамках задачи реализованы все требуемые функций. В диалоговом инструменте используются только понятные пользователю термины, а цвета соответствуют общепринятым рекомендациям. Экранные формы для набора и редактирования могут быть во всем «похожи» на привычные пользователю документы. Программный продукт выполняет следующие операции с базой данных. База данных состоит из таблиц, объединенных вместе для обеспечения просмотра и поиска. Рейтинги используются с помощью индексации и сортировки. Всю информацию можно просматривать и редактировать. Записи с несколькими полями можно просматривать в виде таблиц и нумерации страниц. Этот проект разработан так, как будто он является учебным и не имеет реальной практической ценности. Список использованных источников и литературы 1. Вейскас Д. Эффективная работа с Microsoft Access. - СПб: Питер, 1996. - 864с. 2. Дейт К.Дж. Введение в системы баз данных: Пер. с англ.. - К.: Діалектика, 1998. - 784с. 3. Карпова Т.С. Базы данных: модели, разработка, реализация. -СПб.:Питер, 2002. -304с.: ил. . 4. Золотова С.И. Практикум по Access. М.: Финансы и статистика, 2005.- 144 с.: ил. . 5. Конноли, Томас, Бег, Каролин, Страчан, Анна. Базы данных. Проектирование, реализация и сопровождение. Теория и практика, 2-е изд. : Пер. с англ. - М.: Издательский дом "Вильямс",2001. - 1120с. . 6.Хоменко А.Д., Гридин В.В. Microsoft Access. Быстрый старт. - СПб.: БХВ-Петербург, 2002.-304 с.: ил. 7. Шарохина, С.В. Принципы правового государства, определяющие налоговую систему страны [Текст] // Актуальные проблемы гуманитарных и социально-экономических наук. 2017. Т. 6. № 11 (11). С. 122-125. 8. Макшанов А.В. Технологии интеллектуального анализа данных: Учебное пособие / А.В. Макшанов, А.Е. Журавлев. — СПб.: Лань, 2018. — 212 c. 9. Макшанов А.В. Технологии интеллектуального анализа данных. — М.: Лань. 2019. 212 с. 10. Ниворожкина Л.И. Статистические методы анализа данных: Учебник / Л.И. Ниворожкина, С.В. Арженовский, А.А. Рудяга. — М.: Риор, 2018. — 320 c. 11. Панкратова Е.В. Анализ данных в программе SPSS для начинающих социологов / Е.В. Панкратова, И.Н. Смирнова, Н.Н. Мартынова. — М.: Ленанд, 2018. — 200 c. 12. Рафалович В. Data mining, или интеллектуальный анализ данных для занятых. Практический курс / В. Рафалович. — М.: SmartBook, 2018. — 352 c. 13. Салин В. Н., Чурилова Э. Ю. Статистический анализ данных цифровой экономики в системе "Statistica". Учебно-практическое пособие. — М.: КноРус. 2019. 240 с. 14. Сидняев Н. И. Теория планирования эксперимента и анализ статистических данных. — М.: Юрайт. 2020. 496 с. 15. Форман Дж. Много цифр: Анализ больших данных при помощи Excel / Дж. Форман. — М.: Альпина Паблишер, 2019. — 461 c. 16. Лыкова, Л. Н. Налоги и налогообложение [Текст] / Л.Н. Лыкова. — М.: Издательство Юрайт, 2019. — 357с. 17. Проектирование и реализация баз данных в СУБД MySQL с использованием MySQL Workbench: Учебное пособие / С.А. Мартишин и др. - М.: ИД ФОРУМ: НИЦ Инфра-М, 2012. - 160 с. URL: http://www.znanium.com/bookread.php?book=318518 |