Информационное обеспечение ИС

Наименование кодируемого множества объектов.

Значность кода.

Система кодирования.

Система классификации.

Вид классификатора.

Номер счета.

Порядковая.

Отсутствует.

Системный.

Серийный номер ключа.

Порядковая.

Отсутствует.

Локальный.

Номер договора о годовой технической поддержке.

Порядковая.

Отсутствует.

Локальный.

Заводской идентификатор ключа.

• · Наименование клиента.
• · Срок действия договора.
• · Условия предоставления услуг технической поддержки.

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

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

• · Договор о предоставлении права пользования программным продуктом.
• · Партнерский договор.
• · Расписка о получении электронного ключа.

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

Характеристика базы данных.

Характеристика инфологической модели БД.

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

Приложение может не входить ни в одну прошивку (например, если оно ещё ни разу не продавалось). Однако одно и тоже приложение может быть в различных прошивках (сущность «приложения прошивки»).

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

Так как электронный ключ может только один раз быть поставлен, соответственно приход его осуществляется только один раз. Поэтому тип связи между сущностями «Электронный ключ» и «приход ключа» — «один-к-одному».

Счет прихода должен содержать не менее одного электронного ключа (счет с нулевым количеством ключа бессмыслен). Этот факт обуславливает связь «один-ко-многим-или-одному».

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

Пользователем может быть или юридическое, или физическое лицо. Поэтому связи между сущностями «Пользователь» — «Юридическое лицо» — «один-к-одному-или-к-нулю», «Пользователь» — «Физическое лицо» — «один-к-одному-или-к-нулю».

Характеристика даталогической модели БД На основе ER-модели построим даталогическую модель (таблица 7).

Таблица 7. Даталогическая модель.

Для всех сущностей, имеющих составные ключи, в соответствующих таблицах создано поле «Идентификатор», при этом были указаны все возможные альтернативные ключи (AK). Это было сделано с целью минимизации объема базы данных. Первичные ключи таблиц выделены жирным шрифтом. Внешние ключи имеют метку «FK».

Для сущности «Пользователь» атрибут «тип» был заменен на «Является юрид. лицом» логического типа. Если значение равно «истина», то пользователь — юридическое лицо, иначе — физическое лицо. Атрибут логического типа будет занимать гораздо меньше памяти ЭВМ, чем хранение строкового. При этом вероятность появления нового типа пользователя крайне мала.

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

Для большинства таблиц добавлены два служебных поля «Запись помечена на удаление» логического типа и «Запись была обновлена», тип данных которого совпадает с типом ключевого поля таблицы.

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

При редактировании (обновлении) записи старая запись остается при этом в поле «Запись была обновлена» добавляется ссылка на новую запись, которую пользователь ввел при редактировании. Старые, уже обновленные, записи конечному пользователю также не выводятся.

Характеристика результатной информации.

Характеристика таблиц с результатной информацией.

Результирующая информация представляется в справочниках и журналах в виде таблиц. Опишем некоторые табличные представления (таблица 8).

Таблица 8. Соответствие представлений и полей таблиц базы данных.

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

Характеристика результатных документов.

Информационная система оперативно формирует требующиеся отчеты. Для чего они необходимы?

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

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

• · Серийный номер ключа.
• · Название организации-владельца ключа.
• · Контактная информации организации-владельца ключа (e-mail, телефон, адрес).
• · Дата выта выдачи.
• · Номер лицензионного договора.

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

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

• · Номер ключа.
• · Дата прошивки.
• · Договор-основание (обычно лицензионный договор).
• · Комплектация ключа согласно прошивки.
• · Версия аналитической платформы.

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

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

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

• · Номер лицензионного ключа.
• · Дата обновления версии.
• · Версия.

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

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

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

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

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

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