45080 (Ответы к экзамену по специальности Информатик-технолог), страница 6

Для каждого класса устанавливается формат (состав, структура реквизитов). Для библиографической БД перечень элементов устанавливается ГОСТом для каждого класса док-тов (формат MARC).

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

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

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

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

43. Проектирование комплекса технических и программных средств.

Комплекс технических средств (КТС) – материальная основа. В КТС принято различать 2 части: центральную и периферийную.

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

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

Существуют 2 основных способа регистрации: централизованный и децентрализованный.

При 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. Даталогическое проектирование БД.

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

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

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

Основные принципы ДП:

ДМ – ориентируется на тип СУБД. Процесс проектирования предусматривает предварительное инфологическое проектирование, при котором происходит классификация ПО, систематизируется представление объектов и их взаимосвязь. Процесс ДМ – преобразование ИМ в ДМ. Проверка адекватности получаемой ДМ (в соответствии с потребностями, в соответствии с ПО).

Для любой ПО существует множество БД. При этом в 1-ую очередь определяется состав БД, минимальной логической единицей БД является свойство объекта.

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

Этапы ДП:

1. определение состава БД. Переход от ИМ к ДМ (ИМ должна включать всю информацию о ПО, но при этом не все сущности переходят в ДМ). Важно принять решение какая информация будет храниться, а какая будет синтезироваться.

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

48. Физическое проектирование БД.

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

- выбор типа носителя;

- выбор способа организации данных;

- выбор методов доступа;

- определение физических размеров, блоков;

- размещение данных и управление этим размещением на внешних носителях;

- управление свободной памятью;

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

1. оценка физической модели данных.

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

Ограничение целостности в общем случае определяется 2 группами факторов:

1. семантическое – исходя из особенностей ПО;

2. синтаксическое – определяется способом организации данных.

Для полей чаще всего используется следующие виды ограничений:

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

Ограничения на запись: ограничение на значение всей строки, ограничение на значение некоторых полей данной строки, записи.

Ограничение целостности на таблицы: запрет на обновление – поле, запись, файл.

49. Исключения. Обработка исключений. Блоки try…finally, try…except.

Исключения – способ передачи информации об ошибке во время исполнения программы.

Причины:

1. из-за математических ошибок;

2. при использовании индекса, выход за предел массива;