Информационные технологии автоматизированного офиса

Gotta Know Now — Web Page Watcher 2.6. Gotta Know Now может помочь тем, кто постоянно следит за обновлениями на определенных сайтах. Вы можете задать слово или фразу, и программа уведомит вас звуковым сигналом или по почте, если они появятся на указанной странице. На главной странице программы будет отображена информация, которую она обнаружила. Кроме этого, Gotta Know Now может уведомлять вас об обновлениях на выбранных веб-страницах, чтобы вам не пришлось проверять их по нескольку раз в день. Как только программа обнаружит изменения, она сообщит вам об этом, и тогда вы сможете открыть страницу в браузере.

 

3. Разработка автоматизированные  информационных технологий в  организации

3.1. Проектирование базы  данных

 

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

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

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

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

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

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

Товар – непосредственно сам перемещаемый объект. Эта сущность обладает следующими атрибутами:

Название (Name) – краткое наименование товара

Описание (Description) – полное наименвоание товара

Единица измерения (Edizm) – единица измерения товара: шука, упаковка, килограмм и т.д.

Цена (Price) – конечная розничная цена. Данная цена обозначается на соответствующем ценнике.

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

Название (Name) – краткое наименование поставщика

Описание (Description) – полное наименование поставщика

ФИО (FIO_contact) – ФИО контактного лица данного поставщика

Телефон (Tel) – номер контактного телефона поставщика

Факс (Fax) - номер контактного факса поставщика

Адрес (Address) – юридический адрес поставщика

Магазин – характеризует конкретный магазин розничной сети. Эта сущность обладает следующими атрибутами:

Название (Name) – официальное юридическое название магазина

Телефон (Tel) – номер контактного телефона магазина

Факс (Fax) – номер контактного факса магазина

Адрес (Address) – юридический адрес магазина

ФИО (FIO_contact) – ФИО контактного лица данного магазина

Склад – место хранения товара. Эта сущность обладает следующими атрибутами:

Название (Name) – общепринятое наименование склада

Телефон (Tel) – номер контактного телефона склада

Адрес (Address) – адрес склада

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

Для описания движения товара необходимо выделать такие сущности, как Приходная накладная и Расходная накладная:

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

Дата (Date) – дата проводки документа.

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

Список соответствующих количеств товаров – каждому товару в соответствие ставится его количество.

Список соответствующих цен товаров – каждому товару в соответствие ставится его цена, то есть цена покупки товара у поставщика.

Поставщик – в данном случае "продавец" товара.

Склад – склад, в который физически поставляется товар.

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

Дата (Date) – дата проводки документа.

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

Список соответствующих количеств товаров – каждому товару в соответствие ставится его количество.

Список соответствующих цен товаров – каждому товару в соответствие ставится его розничная цена, т.е. конечная цена для клиента.

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

Склад – склад, из которого физически поставляется товар.

Таким образом, проявляется существенное различие между приходными и расходными документами. По приходной накладной товар приходит на склад. По расходной – продается\перемещается со склада "от имени" того или иного магазина.

При обработке перечисленных сущностей получаем диаграмму "сущность-связь":

 

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

 

3.2. Физическое проектирование

 

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

Итак, нормализуем отношения логической модели данных, установив характер связей в разрабатываемой схеме базе данных:

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

"Приход" – "Поставщик": данная связь  носит характер "один ко многим", так как одной приходной накладной  может соответствовать только  один поставщик, но одному поставщику  могут соответствовать несколько  приходных накладных.

"Приход" – "Склад": данная связь носит  характер "один ко многим", так  как одной приходной накладной  может соответствовать только  один склад, но одному складу  могут соответствовать несколько  приходных накладных.

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

"Расход" – "Склад": данная связь носит  характер "один ко многим", так  как одной расходной накладной  может соответствовать только  один склад, но одному складу  могут соответствовать несколько  расходных накладных.

"Расход" – "Магазин": данная связь носит  характер "один ко многим", так  как одной расходной накладной  может соответствовать только  один магазин, но одному магазину  могут соответствовать несколько  расходных накладных.

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

Таким образом, агрегируя все результаты анализа диаграммы сущность-связь получаем следующую физическую схему БД:

 

 

Данные, полученные на этапе "Исследование", были проанализированы, в результате чего была составлена предварительная схема архитектуры будущей системы. В системе четко выделились две части: Клиент и Сервер. В данном контексте клиент отвечает за предоставление интерфейса для работы с Системой. Сама же бизнес-логика реализуется на Сервере. Таким образом, наш Клиент является тонким – а именно, веб-браузером. Сервер же делится на SQL Сервер и Сервер приложений. SQL Сервер хранит данные, а Сервер приложений обеспечивает бизнес логику Системы. Таким образом, образуется трехзвенная архитекрура Системы:

 

 

 

3.3. HTML прототипы

 

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

Для данной Системы прототипы разрабатывались в среде интегрированной разработки Delphi 2006. Дело в том, что к моменту реализации Системы вышла новая версия Delphi, немного более удобная предыдущей в отношении проектирования ASP.NET страниц.

На данном рисунке представлен прототип окна входа в систему (авторизации):

 

 

На данном рисунке представлен прототип окна просмотра Приходных накладных:

 

Для конечного пользователя прототипы компилировались в HTML страницы:

 

Бизнес логика реализовывалась на языке Delphi в одноименной среде разработки. Для соединения с базой данных использовались компоненты SqlConnection, SqlDataAdapter, DataSet, SqlCommand:

 

 

3.4. Разработка интерфейса пользователя

 

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

 

Заключение

 

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

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

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