Главная Коллекция "Otherreferats" Программирование, компьютеры и кибернетика Автоматизация документооборота

Автоматизация документооборота

Разработка информационной системы учета документации в метрологической службе с использованием технологии NET. Анализ требований к функциональным и нефункциональным характеристикам информационной системы. Проектирование реляционной БД "Сущность-связь".

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 02.09.2011
Размер файла 2,6 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Страница:

Размещено на http://www.allbest.ru/

70

Размещено на http://www.allbest.ru/

Москва 2009

Аннотация

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

В процессе работы формулируются требования к функциональным и нефункциональным характеристикам информационной системы. Излагаются концепции технологии быстрой разработки приложений ADO.Net. Предлагается изучить особенности ADO.Net, объекты ADO.Net, поставщики данных .Net, подключаемые классы и объекты. Излагается методология проектирования реляционной БД: метод «Сущность-связь» и генерацию правил получения реляционной модели БД из ER-диаграммы. В процессе проектирования информационной системы составляются ER-диаграммы. С помощью правил из ER-диаграмм составляется реляционная модель БД. Реляционная модель в процессе конструирования реализуется средствами MS SQL Server 2008. Проектируются запросы на выборку к БД и реализуются с помощью технологии ADO.Net в среде MS Visual Studio 2008. Устанавливаются требования к графическому интерфейсу пользователя, который реализуется средствами MS Visual Studio 2008.

Содержание

Аннотация

Введение

1. Постановка задачи

1.1 Актуальность

1.2 Перечень решаемых подзадач

1.3 Требования к функциональным характеристикам информационной системы

1.4 Требования к нефункциональным характеристикам информационной системы

Выводы

2. Концепции технологии быстрой разработки БД - ADO.NET

2.1 Особенности ADO.NET

2.2 Объекты ADO.NET

2.3 Поставщики данных .NET

2.4 Подключаемые классы и объекты

2.5 Поведение объектов подключения

2.6 Транзакции

2.7 Автономные классы и объекты

Выводы к разделу

3. Метод проектирования реляционной БД «Сущность-связь»

3.1 Основные понятия и определения

3.2 Генерация правил получения реляционной модели БД из ER-диаграммы

Выводы

4. Проектирование ИС учета документации в метрологической службе 28

4.1 Проектирование реляционной БД

4.2 Проектирование запросов на выборку к БД

4.3 Проектирование графического интерфейса пользователя

Выводы

5. Конструирование ИС учета документации в метрологической службе

5.1 Реализация реляционной БД средствами СУБД SQL - сервер

5.2 Реализация запросов на выборку к БД с помощью технологии ADO.Net

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

5.5 Программная документация эксплуатационная

6. Раздел охраны труда

6.1 Исследование возможных опасных и вредных факторов при эксплуатации ЭВМ и их влияния на пользователей

6.2 Анализ влияния опасных и вредных факторов на пользователя

6.3 Методы и средства защиты пользователей от воздействия на них опасных и вредных факторов

6.4 Эргономические требования к рабочему месту пользователей

Выводы

Выводы по дипломному проекту

Используемые источники

Введение

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

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

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

Информационная система, разрабатывается в дипломном проекте в рамках международного стандарта ISO 9001:2008 «Системы менеджмента качества. Требования».

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

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

1. Постановка задачи

1.1 Актуальность

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

Разработка информационной системы учета документации является актуальной проблемой для ФГУП ВНИИОФИ. Специфика предприятия - большое количество своеобразных заказов, которые находятся у исполнителей. Проследить за выполнением каждого заказа становится все сложнее с ростом их количества. Информационная система необходима, чтобы улучшить связь конкретных исполнителей с бухгалтерией, улучшить прослеживаемость выполнения заказов исполнителями по ходу работы, чтобы ускорить реагирование бухгалтерии на выполнение заказа закрытием договора, либо продлением договора в случае невыполнения заказа. Информационная система также позволит производить контроль за загруженностью секторов отдела, нагружать сектора заказами равномерно.

Рассмотрим существующие на рынке решения.

Система PartY PLUS 

Система PartY PLUS позволяет автоматизировать практически все задачи, связанные с управлением документацией в проектных и архитектурно-строительных организациях. PartY PLUS соответствует требованиям отечественных стандартов (СПДС, ЕСКД и др.) и одновременно ориентирована на поддержку международных стандартов (ISO 9000, STEP).

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

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

PartY PLUS позволяет не только хранить уже разработанную документацию, но и управлять процессом ее разработки. При этом документация может быть структурирована уже непосредственно на этапе ее создания.

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

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

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

Система TopS BI DocHouse

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

За счёт максимального использования готовых технологий Microsoft Office System и интеграции c Microsoft Active Directory, TopS BI DocHouse предоставит пользователям возможность работать с документами через привычный интерфейс и позволит значительно снизить затраты на сопровождение корпоративной библиотеки документов.

Возможности Tops BI DocHouse для организации хранилища документов.

· Централизованное хранение документов.

· Создание шаблонов и типовых вариантов документов.

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

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

· Контроль версий документов (ручной и автоматический).

· Рассылка оповещений об изменении содержания и статуса документов.

· Интеграция с Microsoft Office и внешними источниками информации.

· Коллективная работа с документами.

· Механизм напоминаний и уведомлений (событийных и управляемых).

· Управление правами доступа пользователей.

· Удаленный доступ к корпоративным данным пользователей мобильных устройств.

Возможности TopS BI DocHouse для организации документооборота.

· Централизованное управление корпоративными документами.

· Настройка маршрутов обработки документов любой степени сложности с помощью простого и удобного редактора маршрутов на базе Microsoft Visio.

· Механизм заместителей (система предусматривает возможность настройки прав доступа для заместителей сотрудников, то есть сотрудник может войти в систему под именем пользователя, которого он замещает).

· Механизм автоматической обработки документов.

· Механизм истечения срока обработки документа.

· Возможность пакетной обработки документов.

· Интеграция с системой электронной почты Microsoft Outlook.

· Возможность построения отчетов.

· Ведение истории работы с документами.

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

· Microsoft CRM,

· Microsoft Project,

· Web Services,

· Active Directory,

· SQL Server.

Система LANDOCS 

LanDocs - разработанная специалистами ЛАНИТ линия масштабируемых продуктов для комплексной автоматизации делопроизводства, создания/поддержки корпоративных архивов электронных документов и управления деловыми процессами. Система LanDocs позволяет унифицировать процедуры документирования и работы с документами, внедрить современные методы организации делопроизводственной деятельности. LanDocs реализует учет различных типов документов, их рассылку исполнителям, контроль движения и исполнения документов, управление хранением электронных документов, интеграцию с офисными приложениями, разграничение доступа пользователей к документной информации. Система может строиться в любой из трех архитектур: в двухзвенной архитектуре "клиент-сервер" на базе основных промышленных СУБД; в трехзвенной архитектуре со специализированным WEB-сервером приложений, обеспечивающим возможность удаленного доступа к данным системы через сеть Internet; на базе стандартного клиента электронной почты (Microsoft Exchange или Lotus Notes). Система позволяет организовать обмен документами на основе XML-стандарта между двумя территориально-удаленными системами LanDocs, работающими на собственных базах данных

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

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

1.2 Перечень решаемых подзадач

Решение задачи состоит из двух основных этапов: проектирование и разработка системы. Каждый из этапов делится на подзадачи.

1. Проектирование системы делится на следующие этапы:

· Проектирование реляционной модели БД

· Проектирование запросов на выборку к БД

· Проектирование графического интерфейса пользователя

2. Разработка системы состоит из следующих частей:

· Реализация реляционной модели БД средствами СУБД SQL - сервер.

· Реализация запросов на выборку к БД с использованием технологии ADO.Net

· Реализация графического интерфейса пользователя посредством среды разработки Framevork 3.0

· Политика информационной безопасности для разработанной ИС

· Программная документация

1.3 Требования к функциональным характеристикам информационной системы

Требования к пользовательскому интерфейсу.

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

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

Требования к политике безопасности.

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

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

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

1.4 Требования к нефункциональным характеристикам информационной системы

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

· информация об отдельной фирме,

· информация об отдельном счете,

· информация об отдельном договоре,

· информация об отдельном исполнителе,

· информация об отдельном контактном лице,

· сортировка гарантийных писем по названию фирмы,

· список всех гарантийных писем,

· список всех счетов,

· отображение пройденных этапов для каждого гарантийного письма,

· список всех фирм,

· список всех гарантийных писем,

· список всех счетов,

· список всех исполнителей,

· список всех контактных лиц,

· список всех секторов,

· вывод для каждого сектора ФИО исполнителя, всех этапов, номера договора,

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

Выводы

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

2. Концепции технологии быстрой разработки БД - ADO.NET.

2.1 Особенности ADO.NET

ADO.NET - это часть Microsoft .NET Framework, т.е. набор средств и слоев, позволяющих приложению легко управлять и взаимодействовать со своим файловым или серверным хранилищем данных.

В NET Framework библиотеки ADO.NET находится в пространстве имени System.Data. Эти библиотеки обеспечивают подключение к источникам данных, выполнении команд, а также хранилище, обработку и выборку данных (рис 1.2).


Рис. 1.2

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

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

Важным элементом автономного доступа к данным является контейнер для табличных данных, который не знает о СУБД. Такой незнающий о СУБД автономный контейнер для табличных данных представлен в библиотеках ADO.NET классом DataSet или DataTable.

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

2.2 Объекты ADO.NET

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

Архитектуру ADO.Net можно разделить на две фундаментальные части: подключаемую и автономную. Все классы в ADO.NET можно поделить по этому критерию. Единственное исключение - класс DataAdapter, который является посредником между подключенной и автономной частями ADO.Net.

2.3 Поставщики данных .NET

Подключаемая часть ADO.Net представляет собой набор объектов подключений.

Объекты подключений разделяются в ADO.NET по конкретным реализациям для различных СУБД. То есть для подключения к базе данных SQL SERVER имеется специальных класс SqlConnection. Эти отдельные реализации для конкретных СУБД называются поставщиками данных .NET

При наличии широкого выбора доступных источников данных ADO.NET должна иметь возможность поддерживать множество источников данных. Каждый такой источник данных может иметь свои особенности или набор возможностей.

Поэтому ADO.NET поддерживает модель поставщиков. Поставщики для конкретного источника данных можно определить как совокупность классов в одном пространстве имен созданных специально для данного источника данных. Эта особенность несколько размыта для источников данных OleDb, ODBC, так как они по своей сути созданы для работы с любой базой данных совместимых с OLE и ODBC.

2.4 Подключаемые классы и объекты

В подключаемой части ADO.NET имеются следующие основные классы:

· Connection. Этот класс, позволяющий устанавливать подключение к источнику данных. ( OleDbConnection, SqlConnection, OracleConnection)

· Transaction. Объект транзакций (OleDbTransaction, SqlTransaction, OracleTransaction. В ADO.NET имеется пространство имен System.Transaction)

· DataAdapter. Это своеобразный шлюз между автономными и подключенными аспектами ADO.NET. Он устанавливает подключение, и если подключение уже установлено, содержит достаточно информации, чтобы воспринимать данные автономных объектов и взаимодействовать с базой данных. (DataAdapter - SqlDataAdapter, OracleDataAdapter)

· Command. Это класс представляющий исполняемую команду в базовом источнике данных.

· Parameter. Объект параметр команды.

· DataReader. Это эквивалент конвейерного курсора с возможностью только чтения данных в прямом направлении.

2.5 Поведение объектов подключения

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

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

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

Сам объект подключения источника данных наследуется от класса DbConnection и получает уже готовую логику, реализованную в базовых классах.

Приложение должно разделять дорогостоящий ресурс - открытое подключение - и совместно использовать его с другим пользователем. Именно для этих целей и был введен пул подключений. По умолчанию пул подключений включен. При запросе ADO.NET неявно проверяет, имеется ли доступное неиспользуемое физическое подключение к базе данных. Если такое подключение имеется, то она использует его. Для принятия решения имеется ли такое физическое подключение или нет ADO.Net учитывает загрузку приложения, и если поступает слишком много одновременных запросов, ADO.Net может удерживать одновременно открытыми несколько физических подключений, то есть увеличивать при необходимости количество подключений. Если детально рассмотреть картину, то ситуация такова:

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

Вторым наиболее ресурсоемким объектом в ADO.NET являются транзакции, отвечающие за корректность изменений в БД.

2.6 Транзакции

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

Обычно транзакции следуют определенным правилам, Известным как свойства ACID: неделимой (Atomic), согласованной (Consistent), изолированной (Isolated) и долговечной (Durable).

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

В ADO.NET реализован мощный механизм поддержки транзакций БД. Сама ADO.NET поддерживает транзакции одиночной БД, которые отслеживаются на основании подключений. Но она может задействовать пространство имен System.Transactions для выполнения транзакций с несколькими БД или транзакций с несколькими диспетчерами ресурсов.

В ADO.NET класс подключений используется просто для начала транзакции.

Все управляемые NET поставщики, доступные в NET Framework OleDb, SqlClient, OracleClient, ODBC имеют свои собственные реализации класса транзакций.

Все эти классы реализуют интерфейс IDbTransaction из пространства имен System.Data.

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

Подключение к БД необходимо производить перед вызовом метода BeginTransaction класса Connection. Так как в данном случае ресурс физического подключения используется меньше, что уменьшает нагрузку на СУБД.

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

Для гибкого управления поведением транзакций используется уровни изоляции.

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

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

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

Может понадобиться такое поведение транзакций, чтобы вторая транзакция могла видеть записи, вставленные первой. В этом случае возможна ситуация:

1. Неверного извлечения данных, называемое "грязным чтением"

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

3. "Фантомные строки" - пусть транзакция А работает с набором из 100 строк выбранные по определенные критерием, а транзакция. Б изменяет данные, в результате чего при повторной выборке транзакцией А она имеет уже другой набор строк.

В ADO.NET уровни транзакций описаны в перечислении IsolationLevel:

· Chaos. Ожидающие записи изменения транзакций более высоких уровней изоляций не могут быть перезаписаны. Это параметр не поддерживается в SQL Server и Oracle

· ReadUncommited. Разрешается "грязное чтение". Пример использования: мониторинг системы администратором.

· ReadCommited. Пока транзакция читает данные, удерживается "разделяемые блокировки. Это позволяет избежать "грязного чтения", но данные могут быть изменены до завершения транзакции. В результате может возникнуть "невоспроизводимое чтение". Или может возникнуть "фантомные строки". Этот уровень изоляции поддерживается в Oracle и SLQ Server.

· RepeatableRead. В этом случае разделяемые блокировки устанавливаются на все данные, используемые в предикате (критерии) запроса. Это предотвращает модификацию данных другими транзакциями и невоспроизводимое чтение. Однако возможны и фантомные строки. Этот уровень изоляции не поддерживается в Oracle.

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

· Serializable. В этом случае данные блокируются, что предотвращает обновление или вставку строк в DataSet другими пользователя до тех пор, пока транзакция не завершится. Эту блокировку можно установить на строку, страницу или таблицу. Данный уровень изоляции поддерживается в Oracle

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

Точки отката - это маркеры, реализующие роль закладок. Во время выполнения транзакции, можно поместить какую-либо точку, и затем выполнить откат к этой точке вместо полного отката всей транзакции. Для этих целей предусмотрен метод Save в объекте транзакции. Но надо отметить, что данный метод доступен лишь для подключений к SQL SERVER. Поставщик Oracle не поддерживает точки сохранения, но их всегда можно реализовать через прямые запросы или используя хранимые процедуры.

Но есть несколько моментов делающее точки сохранения не очень удобными. Одна из них заключается в том, что необходимо вызывать методы Commit Rollback при откате транзакции к одной из точек сохранения. Еще на что стоит обратить внимание, что после отката транзакции к определенной точке, все точки отказа, находящиеся за текущей, теряются. И если возникнет в них потребность, их придется установить заново.

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

При работе с разнородными данными используют распределенные транзакции - это транзакции, охватывающие несколько ресурсов.

В распределенных транзакциях могут быть блоки, называемые диспетчерами ресурсов (resource manager - RM). Но кроме этих диспетчеров необходимо приложение, прислушивающиеся к ним и координирующие их действия. Оно называется координатором распределенных транзакций (Distributed Transaction Coordinator - DTC) или диспетчером транзакций.

Координатор транзакций, которых представлен с Windows, называется координатором распределенных транзакций Microsoft (MSDTC) и представляет собой службу Windows, которая выполняет координацию транзакций для распределенных транзакций.

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

· Приложение начинает транзакцию, запрашивая ее у MSDTC. Это приложение обычно называется инициатором.

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

· Если все нормально, то приложение фиксирует транзакцию.

· Если что-то не так, каждый шаг может выполнять откат.

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

При работе с распределенными транзакциями различные RM должны реализовывать надежный протокол фиксации: наиболее распространенная реализация такого протокола называется двух фазной фиксацией (two-phase commit).

Если подвести небольшой итог, то ADO.NET имеет хорошую поддержку транзакций, но их далеко не всегда нужно применять. Так как использование транзакций это дополнительная нагрузка на систему. Кроме того, транзакции могут блокировать некоторые строки таблицы, что непосредственно сказывается на производительности. Особенно это хорошо заметно при использовании MSDTC.

2.7 Автономные классы и объекты

Одни лишь подключенные приложения не удовлетворяют всем требованиям, предъявляемым к современным распределенным приложениям. В автономных приложениях, созданных с помощью ADO.NET, используются другой подход. Но для обеспечения автономности используются объекты DataAdapter. Они осуществляют выполнение запросов, используя для этого объекты подключения. А результаты выполнения, то есть данные, передает автономным объектам. Благодаря такому принципу автономные объекты не знают о существовании объектов подключения, так как напрямую не работают с ними. То есть реализация объекта, хранящего данные, не должна зависеть от конкретного поставщика данных, а именно от СУБД. Поскольку конкретная реализация адаптера данных зависит от соответствующего источника данных, конкретные адаптеры данных реализованы в составе конкретных поставщиков.

Автономные приложения обычно подключаются к базе как можно позже и отключаются как можно раньше. Важным элементом в такой схеме подключения и предоставления автономного доступа к данным является контейнер для табличных данных, который не знает о СУБД. Такой незнающий о СУБД автономный контейнер для табличных данных представлен в библиотеках ADO.NET классом DataSet или DataTable.

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

Можно выделить несколько основных классов автономной модели ADO.NET:

· DataSet. Класс DataSet является ядром автономного режима доступа к данным в ADO.NET. Лучше всего рассматривать, как будто в нем есть своя маленькая СУБД, полностью находящаяся в памяти.

· DataTable. Больше всего этот класс похож на таблицу БД. Он состоит из объектов DataColumn, DataRow, представляющих из себя строки и столбцы.

· DataView. Это объект представлений базы данных.

· DataRelation. Этот класс позволяет задавать отношения между различными таблицами, с помощью которых можно проверять соответствие данных из различных таблиц.

Выводы к разделу

Рассмотрены следующие особенности технологии ADO.Net:

· подключение к источникам данных, выполнение команд, хранилище, обработка и выборка данных обеспечивается библиотеками ADO.Net;

· ADO.Net позволяет взаимодействовать с базой данных автономно;

· важным элементом автономного доступа к данным является контейнер для табличных данных, который не знает о СУБД;

Архитектуру ADO.Net можно разделить на две фундаментальные части: подключаемую и автономную. ADO.NET поддерживает модель поставщиков.

В подключаемой части ADO.NET имеются следующие основные классы:

· Connection

· Transaction

· DataAdapter

· Command

· Parameter

· DataReader

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

В ADO.NET реализован мощный механизм поддержки транзакций БД. Основное преимущество транзакций - производительность. При одиночных или коротких операциях транзакции могут, выполняются медленнее, но для больших наборов данных они быстрее.

Основными классами автономной модели ADO.NET являются:

· DataSet

· DataTable

· DataView

· DataRelation

3. Метод проектирования реляционной БД «Сущность-связь»

3.1 Основные понятия и определения

Реляционная модель данных (РМД) некоторой предметной области представляет собой набор отношений, изменяющихся во времени. При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области и моделировать связи между ними. Элементы РМД и формы их представления приведены в таблице:

Элемент реляционной модели

Форма представления

Отношение

Таблица

Схема отношения

Строка заголовков столбцов таблицы

(заголовок таблицы)

Кортеж

Строка таблицы

Сущность

Описание свойств объекта

Атрибут

Заголовок столбца таблицы

Домен

Множество допустимых значений атрибута

Значение атрибута

Значение поля в записи

Первичный ключ

Один или несколько атрибутов

Тип данных

Тип значений элементов таблицы

Отношение является важнейшим понятием и представляет собой двумерную таблицу, содержащую некоторые данные.

Сущность есть объект любой природы, данные о котором хранятся в базе данных. Данные о сущности хранятся в отношении.

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

Математически отношение можно описать следующим образом. Пусть даны n множеств Dl, D2, D3,..., Dn, тогда отношение R есть множество упорядоченных кортежей <dl, d2, d3 ,..., dn>, где dk € Dk, dk -- атрибут, a Dk -- домен отношения R.

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

Формально, если переставить атрибуты в отношении, то получается новое отношение. Однако в реляционных БД перестановка атрибутов не приводит к образованию нового отношения.

Домен представляет собой множество всех возможных значений определенного атрибута отношения.

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

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

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

Ключи обычно используют для достижения следующих целей:

1) исключения дублирования значений в ключевых атрибутах (остальные атрибуты в расчет не принимаются);

2) упорядочения кортежей. Возможно упорядочение по, возрастанию или убыванию значений всех ключевых атрибутов, а также смешанное упорядочение (по одним -- возрастание, а по другим -- убывание);

3) ускорения работы к кортежами отношения;

4) организации связывания таблиц;

Пусть в отношении R1 имеется не ключевой атрибут А, значения которого являются значениями ключевого атрибута В другого отношения R2. Тогда говорят, что атрибут А отношения R1 есть внешний ключ.

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

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

1) Все строки таблицы должны быть уникальны, т. е. не может быть строк с одинаковыми первичными ключами.

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

3) Все строки одной таблицы должны иметь одну структуру, соответствующую именам и типам столбцов.

4) Порядок размещения строк в таблице может быть произвольным.

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

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

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

Если задаваемое таблицей отношение имеет ключ, то считается, что таблица тоже имеет ключ, и ее называют ключевой или таблицей с ключевыми полями.

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

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

Основной единицей обработки данных в реляционных БД является отношение, а не отдельные его кортежи (записи).

На начальном этапе проектирования БД выделяются атрибуты, составляющие ключи сущностей.

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

Степень связи является характеристикой связи между сущностями, которая может быть типа: 1:1, 1:М, М:1, М:М.

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

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

3.2 Генерация правил получения реляционной модели БД из ER-диаграммы

Правила формирования отношений основываются на учете следующего:

* степени связи между сущностями (1:1, 1:М, М:1, М:М);

* класса принадлежности экземпляров сущностей (обязательный и необязательный). Рассмотрим формулировки шести правил формирования отношений на основе диаграмм ER-типа.

3.2.1 Формирование отношений для связи 1:1

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

На рисунке ниже приведены диаграмма ER-типа и отношение, сформированное по правилу 1 на ее основе.

Па рисунке используются следующие обозначения:

C1, C2 - сущности 1 и 2;

K1, K2 - ключи первой и второй сущности соответственно;

R1 - отношение 1, сформированное на основе первой и второй сущностей;

K1vK2 - означает, что ключом сформированного отношения может быть либо К1, либо К2.

Правило 2. Если степень связи 1:1 и класс принадлежности одной сущности обязательный, а второй - необязательный, то под каждую из сущностей формируется по отношению с первичными ключами, являющимися ключами соответствую!! их сущностей. Далее к отношению, сущность которого имеет обязательный КП, добавляется в качестве атрибута ключ сущности с необязательным КП.

На рисунке ниже приведены диаграмма ER-типа и отношения, сформированные по правилу 2 на ее основе.

Правило 3. Если степень связи 1:1 и класс принадлежности обеих сущностей является необязательным, то необходимо использовать три отношения. Два отношения соответствуют связываемым сущностям, ключи которых являются первичными в этих отношениях. Третье отношение является связным между первыми двумя, поэтому его ключ объединяет ключевые атрибуты связываемых отношений.

3.2.2 Формирование отношений для связи 1:М

Если две сущности С1 и С2 связаны как 1:М, сущность С1 будем называть односвязной (1-связпой), а сущность С2 - многосвязной (М-связной). Определяющим фактором при формировании отношений, связанных этим видом связи, является класс принадлежности М-связной сущности. Так, если класс принадлежности М-связной сущности обязательный, то в результате применения правила получим два отношения, если необязательный - три отношения. Класс принадлежности односвязной сущности не влияет на результат.

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

На рисунке ниже приведены диаграмма ER-типа и отношения, сформированные по правилу 4.

Правило 5. Если степень связи 1:М (М:1) и класс принадлежности М-связной сущности является необязательным, то необходимо формирование трех отношений

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

3.2.3 Формирование отношений для связи М:М

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

Правило 6. Если степень связи М:М, то независимо от класса принадлежности сущностей формируются три отношения. Два отношения соответствуют связываемым сущностям и их ключи являются первичными ключами этих отношений. Третье отношение является связным между первыми двумя, а его ключ объединяет ключевые атрибуты связываемых отношений. На рисунке ниже приведены диаграмма ER-типа и отношения, сформированные по правилу 6. Нами показан вариант с классом принадлежности сущностей Н-Н, хотя, согласно правилу 6, он может быть произвольным.

К1,...

К2,...

К1,К2

Выводы

В разделе рассмотрен метод «Сущность-связь», приведены правила перехода от ER-диаграмм к реляционной модели БД. В процессе проектирования планируется использовать рассмотренный метод. В процессе построения реляционная модели БД необходимо использовать приведенные правила.

4. Проектирование ИС учета документации в метрологической службе

4.1 Проектирование реляционной БД

4.1.1 Составление ER-диаграмм

Диаграмма «Контактное_лицо-Фирма»:

Получаем отношение «Контактное_лицо-Фирма»:

ФИРМА КОНТАКТНОЕ ЛИЦО

Ключ_фирма

Фирма

Ключ_лицо

Контактное лицо

Ключ_фирма

Диаграмма «Счет-Договор»:

Получаем отношение «Счет-Договор»:

ДОГОВОР

Ключ_договор

Договор номер

СЧЕТ

Ключ_счет

Счет номер

Ключ_договор

Диаграмма «Фирма-Гарантийное письмо»:

Получаем отношение «Фирма-Гарантийное письмо»:

ФИРМА КОНТАКТНОЕ ЛИЦО

Ключ_фирма

Фирма

Ключ_лицо

Контактное лицо

Ключ_фирма

Диаграмма «Исполнитель-Договор»:

Получаем отношение «Исполнитель-Договор»:

ИСПОЛНИТЕЛЬ

Ключ_исполнитель

Исполнитель

ДОГОВОР

Ключ_договор

Договор номер

Ключ_исполнитель

Диаграмма «Сектор-Договор»:

Получаем отношение «Сектор-Договор»:

СЕКТОР

Ключ_сектор

Исполнитель

ДОГОВОР

Ключ_договор

Договор номер

Ключ_сектор

Диаграмма «Договор-Этап»:

Получаем отношение «Договор-Этап»:

ЭТАП

Ключ_этап

Начало

В процессе

Завершен

ДОГОВОР

Ключ_договор

Договор номер

Ключ_этап

Диаграмма «Гарантийное_письмо-Договор»:

Получаем отношение «Гарантийное_письмо-Договор»:

ДОГОВОР

Ключ_договор

Договор номер

ГАРАНТИЙНОЕ ПИСЬМО

Ключ_письмо

Договор номер

Ключ_договор

Диаграмма «Договор-Вид»:

Получаем отношение «Договор-Вид»:

ВИД

Ключ_вид

Вид

ДОГОВОР

Ключ_договор

Договор номер

Ключ_вид

4.1.2 Реляционная модель БД

1) Договор (ключ_договор, номер договора, сумма, сроки, закрытие, протокол, ключ_вид, ключ_исполнитель, ключ_этап, ключ_сектор)

2) Вид (ключ_вид, вид)

3) Исполнитель (ключ_исполнитель, исполнитель, телефон, e-mail, прочая информация)

4) Счет (ключ_счет, номер счета, предмет счета, оплата, задержка, акт, счет-фактура, дата, предоплата)

5) Сектор (ключ_сектор, сектор)

6) Гарантийное письмо (ключ_письмо, гарантийное письмо, ключ_договор, ключ_фирма)

7) Этап (ключ_этап, начало, в процессе, завершен)

8) Фирма (ключ_фирма, фирма, адрес, телефон, e-mail, юридический адрес, реквизиты, директор)

9) Контактное лицо (ключ_лицо, контактное лицо, телефон, e-mail, прочая информация)

4.2 Проектирование запросов на выборку к БД

1) Вывод всех столбцов из таблицы Договор

2) Вывод всех столбцов из таблицы Исполнитель

3) Вывод всех столбцов из таблицы Счет

4) Вывод всех столбцов из таблицы Гарантийное письмо

5) Вывод всех столбцов из таблицы Фирма

6) Вывод всех столбцов из таблицы Контактное лицо

4.3 Проектирование графического интерфейса пользователя

Главное окно программы.

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

Окно просмотра информации о фирмах.

Окно просмотра информации о фирмах должно предоставлять возможность выбора фирмы из поля с выпадающим списком. Окно должно содержать поля, заполняемые автоматически и отображающие информацию о названии фирмы, адресе, телефоне, e-mail, юридическом адресе, реквизитах, директоре. Пользователю должна предоставляться возможность перехода к окну просмотра информации о контактных лицах. Пользователю должна предоставляться возможность закрыть окно с помощью кнопки «Выход».

Окно просмотра информации о контактных лицах.

Окно просмотра информации о контактных лицах должно предоставлять возможность выбора фирмы из поля с выпадающим списком и выбора контактного лица из поля со списком, содержащего список контактных лиц для этой фирмы. Окно должно содержать поля, заполняемые автоматически и отображающие информацию о Ф.И.О., телефоне, e-mail, фирме, прочую информацию. Пользователю должна предоставляться возможность перехода к окну просмотра информации о контактных лицах. Пользователю должна предоставляться возможность закрыть окно с помощью кнопки «Выход».

Окно просмотра информации об исполнителях.

Окно просмотра информации об исполнителях должно предоставлять возможность выбора исполнителя из поля с выпадающим списком. Окно должно содержать поля, заполняемые автоматически и отображающие информацию о Ф.И.О., телефоне, e-mail, прочую информацию. Пользователю должна предоставляться возможность перехода к окну просмотра информации о контактных лицах. Пользователю должна предоставляться возможность закрыть окно с помощью кнопки «Выход».

Окно просмотра информации о загруженности секторов.

Окно просмотра информации о загруженности секторов должно предоставлять возможность выбора сектора из поля со списком. Окно должно содержать поля, заполняемые автоматически и отображающие название выбранного сектора. Информация о загруженности секторов должна отображаться с помощью трех индикаторов загрузки, данные которых должны соответствовать количеству договоров с отметками о прохождении этапов «начало», «в процессе» и «завершен». Пользователю должна предоставляться возможность закрыть окно с помощью кнопки «Выход».

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены