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

При проектировании КТС должны соблюдаться общие принципы:

1. совместимость всех технических средств, кодов, техники и программ;

2. соответствующая пропускная способность всего КТС;

3. максимальное использование устройств;

4. надежность как самих средств, так и системы;

5. агрегатированность, возможность наращивать, перестраивать.

К КТС предъявляются след. требования:

1. решение всех задач системы в заданное время и в необходимом объеме;

2. выполнение всех этапов автоматической обработки информации;

3. возможность контроля информации на всех этапах обработки;

4. возможность развития (расширение);

5. эффективность функционирования задач, оптимальность решения.

Структура ПО – это операционные системы, сервисные системы (оболочки, утилиты и т.п.), система технического обследования, пакеты прикладных программ, собственно обеспечивающие программы (сетевые программы). При выборе программных средств отталкиваются от анализа решаемых задач.

Рекомендации по выбору сетевых программ:

1. топология сетей;

2. максимальное удаление ЭВМ др. от др.

3. кол-во ЭВМ по сети;

4. решить будут ли однородными или неоднородными ЭВМ по сети;

5. надежность;

6. передающая среда.

При выборе прикладных программ АИС необходимо учитывать следующие их характеристики: технические, сервисные, эксплуатационные.

Технические – ориентирована на определенные ЭВМ и операционную систему, объем основной памяти, доступное кол-во рабочих станций.

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

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

44. Оценка эффективности проектируемой АИС.

Эффективность АИС бывает разная. Рассмотрим несколько эффективностей:

- общая экономическая эффективность от внедрения АИС (с т.зр. финансов);

- прагматические показатели (с т.зр. потребителя);

- семантические показатели – мера полноты, точности.

Оценка экономической эффективности производится минимум 3 раза: на этапе предпроектной стадии, на этапе технического проектирования, после внедрения АИС.

По методике принятой в АСНТИ, АСУ рассматриваются 2 показателя:

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

Эф-сть годовая = А (Со – С1) – Ен* Кв;

где А – кол-во поиска в год;

Со – себестоимость поиска до внедрения;

С1 - себестоимость поиска после внедр-я;

Ен – нормативный коэф-т окупаемости затрат;

Кв – затраты на внедрение.

Срок окупаемости затрат:

То=

Ер =

Для того, чтобы определить будет ли эффективна новая АИС необходимо сравнить: Ер – Ен, если от 0,13 до 0,25, то она эффективна.

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

45. Этапы проектирования БД.

В БД отражается информация об определенной ПО. В АИС отражение ПО представлено моделями данных нескольких уровней. Можно выделить соответствующим им этапы проектирования БД.

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

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

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

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

46. Инфологическая модель ПО.

Чтобы спроектировать структуру БД необходима исходная информация о ПО. Описание ПО, выполненное без ориентации на используемые в дальнейшем программы и технические средства называется ИМ ПО.

ИМ ПО строится первой. ИМ должна строится вне зависимости от того, будете ли ВЫ в дальнейшем использовать какую-либо СУБД или пользоваться др. программными средствами для реализации своей ИС.

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

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

ИМ должна легко восприниматься разными категориями пользователей.

47. Даталогическое проектирование БД.

ДМ – модель логического уровня, ориентирована на тип СУБД.

При проектировании ДМ – большое влияние оказывает ИМ. Результатом ДП будет описание логической структуры БД на языке описания данных (ЯОД), схематичное изображение структуры БД.

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