Лекции по автоматизации и управлению

Подождите немного. Документ загружается.

Вопрос №19. "Основные понятия имитационного

моделирования".

Имитационная модель (ИМ) - программа, при выполнении которой на

ЭВМ в численном виде воспроизводится процесс функционирования системы в

соответствии с известным причинно-следственным механизмом, определяющим

состояния элементов системы в очередные моменты времени через их

состояния в прошлом.

Системы делятся на непрерывные (все переменные представляют собой

непрерывные функции времени) и дискретные.

Движение в модельном времени в программе осуществляется по

принципу ∆t - малых приращений времени. Поэтому мат. аппарат при

моделировании непрерывных систем в значительной мере совпадает с

численными методами решения диф. уравнений. В дискретных системах все

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

изменение осуществляется мгновенно в отдельные моменты времени, между

которыми значения переменных не меняются. Все изменения называются

событиями. Количество типов событий для данного класса систем ограничено.

Каждый тип события моделируется отдельной программной процедурой.

Перемещения в модельном времени происходят по принципу ∆z - от события к

событию.

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

моделирования дискретных систем, языки моделирования непрерывных систем,

языки моделирования непрерывно - дискретных систем. Всего известно

несколько сотен хорошо документированных языков ИМ. Наиболее

распространенным и проверенным считается язык GPSS.

ИМ отличается от аналитического тем, что не требует составления и

решения уравнений, не связано с применением формальных понятий

определенного мат. аппарата, уровень детализации при моделировании может

быть произвольным. Поэтому реальная система может быть промоделирована с

любой точностью (единственное ограничение - хорошее знание исследуемой

системы).

Выполнение ИМ на ЭВМ называется имитационным экспериментом

(ИЭ). Чтобы накопить информацию о показателях функционирования системы

применяют два метода планирования ИЭ:

 параллельный эксперимент - при заданном начальном состоянии системы

прогон модели осуществляется N раз. В каждом прогоне начальные

значения датчиков БСВ (непрерывная случайная величина, равномерная

распределенная на интервале от 0 до 1). В результате получается N

независимых реализаций процесса. Так как все реализации независимы,

можно находить не только среднее значение процесса, но и определить

точность результата усреднения классическими методами. Результат

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

и стационарного процессов.

 последовательный эксперимент - основан на применении теоремы об

эргодическом процессе: "для эргодического процесса среднее по множеству

равно среднему по времени". В последовательном эксперименте

выполняется один достаточно длинный прогон, в котором среднее значение

процесса определяется как среднее по времени. Последовательный

эксперимент позволяет рассчитывать оценки достаточно легко, но в нем

теряется информация о переходном процессе.

Вопрос №20. Основы концептуального

проектирования БД

Этап концептуального проектирования связан с описанием и синтезом

разнообразных информационных требований пользователей в первоначальный

проект баз данных. Результатом этого этапа является высокоуровневое

представление информационных требований, например, такое как диаграмма

«сущность-связь». Основу этой диаграммы составляет набор сущностей,

который представляет или моделирует определенную совокупность сведений,

специфицированную в требованиях. Сущности могут быть описаны

атрибутами, позволяющими детализировать свойства сущности. Один или

несколько атрибутов могут служить идентификатором для обозначения

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

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

Существует несколько подходов к построению диаграмм типа «сущность-

связь». Общим для всех подходов является набор из четырех основных

проектных решений или шагов:

1. Определение сущностей.

2. Определение атрибутов сущностей.

3. Идентификация ключевых атрибутов сущностей.

4. Определение связей между сущностями.

Хотя существует некоторая общность мнений о необходимости этих шагов

для построения информационной структуры, тем не менее нет общего

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

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

бы частично независимой от процесса обработки, что позволит обеспечить

гибкость процесса проектирования.

Подход к концептуальному проектированию обычно предполагает, что

рассматривается представление одного-единственного пользователя. При этом

возможно предположить, что таким единственным пользователем является

администратор или проектировщик базы данных, который понимает требования

всех пользователей и объединяет эти требования в полный набор согласованных

спецификаций. Альтернативным является подход, в котором «интеграция

представлений» выполняется как часть процесса концептуального

проектирования.

Основы концептуального проектирования.

Концептуальное проектирование оперирует информацией, независимой от

любой фактической реализации (т. е. от любой конкретной системы

технического или программного обеспечения). Цель концептуального

проектирования именно в том и состоит, чтобы представить информацию в

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

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

Существует два подхода к концептуальному проектированию:

 Объектное представление;

 Моделирование сущностей.

Экспертные оценки концептуальной модели данных.

Метод экспертных оценок ставит следующие основные вопросы:

 Обладает ли концептуальная модель достаточной полнотой?

 Достаточно ли хорошо она отражает предметную область?

 Корректна ли она?

Подобные или более детализированные вопросы относительно всех аспектов

системы (требований пользователя, программирования, операций и т. д.) не

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

проекте упущено, и это несомненно идет на пользу его полноте.

Корректность модели тщательно проверяется при анализе архитектуры

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

типизации процессов и данных рассматриваются с различных позиций.

В ходе экспертизы проекта исследуются особенности преобразования

данных, т. е. процесс трансформации информационной модели в СУБД-

зависимое представление. Первый шаг - определение правильности и полноты

самой информационной модели. На следующем шаге исследуется СУБД-

зависимое представление.

Вопрос №21.

Проектирование физической реализации БД.

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

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

который может быть включаться в программу СУБД.

Различают следующие методы доступа к БД:

*0 блочный

*1 индексно-последовательный

*2 прямой (с относительной или абсолютной адресацией )

*3 к инвертированным файлам

*4 виртуальный метод

Запросы к БД могут быть следующие:

 «Получить всё» ( 90-100 % информации из БД )

 «Получить одну» ( GET UNIKUM )

 «Получить некоторые» ( 0 - 10 % информации из БД )

Выгрузка и загрузка БД осуществляется последовательным методом

( «получить всё» )

При этом применяются следующие методы и функции:

 Функция хеширования ( рандомизации )

 Мультисписковый файл - дополнительный служебный файл, в котором

указаны отдельные данные, хранящиеся в БД.

 Доступ к инвертированным файлам

При физической реализации БД следуют двум критериям:

1. Объём внешней памяти

2. Время реакции на запрос

Характеристики методов доступа к БД с учётом указанных выше критериев:

( знак «+» означает возрастание критерия, «-» - убывание )

 Последовательный метод : 1 - «-», 2 - «+»

 К инвертированному файлу : 1 - «+», 2 - «-»

 Хеширования : 1 - «+», 2 - «-»

Время реакции на запрос.

Т. ожид. Т  0

 t = Tn/2 Работа процессора Работа Т. ожид На

интерпретации ядра экран

Т.

Т общ. =  ожид.

Работа

накопителя

Вопрос №23. Функции администратора БД.

Администратор базы данных (АБД) - под этим понятием подразумевается

лицо (или группа лиц, возможно, целое штатное подразделение), на которое

возложено управление средствами базы данных организации.

АБД должен быть энергичной и способной личностью, организатором по

призванию, желательно с техническим уклоном.

В его функции входит:

 координировать все действия по проектированию, реализации и ведению

БД; учитывать перспективные и текущие требования пользователей;

следить, чтобы БД удовлетворяла актуальным информационным

потребностям;

 решать вопросы, связанные с расширением БД в связи с изменением границ

ПО;

 разрабатывать и реализовывать меры по обеспечению защиты данных от

некомпетентного их использования, от сбоев технических средств, по

обеспечению секретности определенной части данных и разграничению

доступа к данным;

 выполнять работы по ведению словаря данных; контролировать

избыточность и противоречивость данных, их достоверность;

 следить за тем, чтобы БнД отвечал заданным требованиям по

производительности, т. е. чтобы обработка запросов выполнялась за

приемлемое время; -выполнять при необходимости изменения методов

хранения данных, путей доступа к ним, связей между данными, форматов

данных; определять степень влияния изменений в данных на всю БД; -

координировать вопросы технического обеспечения системы аппаратными

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

 координировать работы системных программистов, разрабатывающих

дополнительное программное обеспечение для улучшения

эксплуатационных характеристик системы.

 координировать работы прикладных программистов, разрабатывающих

новые ПП и выполнять проверку и включение прикладных программ в

состав программного обеспечения системы И Т. П.

Вопрос №24. "СУБД. Определение и архитектура".

СУБД - комплекс программных средств, который позволяет создать БД

(файл, структура и хранение в котором построены так, что информация из него

берется путем запроса), поддерживать ее в актуальном состоянии и

осуществляет выдачу ответов на запросы БД.

Основные функции СУБД:

 создание БД;

 поддержка логической (изменение логических представлений, не затрагивая

их физических представлений) и физической независимости данных;

 организация доступа пользователю;

 разграничение прав доступа пользователю: явное указание прав доступа,

паролевая защита;

 обеспечение логической (наличие непротиворечивых данных) и физической

(сохранность на физическом уровне: копирование, организация зеркальных

дисков) целостности данных;

 должны быть средства настройки;

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

Модули СУБД:

 ядро, которое управляет накопителем;

 окружение системы - ряд утилит, которые выполняют определенные

действия:

 утилиты администрирования,

 средства разработки приложений,

 утилиты копирования, восстановления,

 утилиты импорта / экспорта файла,

 обучающая утилита.

Архитектура СУБД:

Архитектура - компоненты, которые поддерживают определенный взгляд на

данные.

Уровень 1 - внешний: компоненты, которые поддерживают уровень

пользователя.

Уровень 2 - внутренний: функциональные компоненты, которые поддерживают

БД в среде хранения.

Уровень 3 - концептуальный: обеспечивает единый взгляд на БД. Этот уровень

содержит внешний интерфейс (связь с пользователем) и внутренний интерфейс

(связь между уровнями).

Вопрос №25. Понятие и назначение интерфейса при

проектировании БД

Наиболее развитые СУБД имеют следующие преимущества и характерные

особенности:

 "дружественный" интерфейс с пользователем;

 встроенную программу интерактивной помощи, а иногда и наличие

интерактивной обучающей программы;

 средства автоматического создания, использования и модификации

базы данных без необходимости программирования, генераторы

программ, отчетов, форматов;

 развитые языки программирования баз данных — более 200 команд и

функций.

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

построенное меню. С его помощью выбирается требуемая функция системы.

Для ввода данных, их просмотра и редактирования в базе данных чаще всего

используются два способа их представления - табличный и в виде экранных

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

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

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

псевдографика, и выводятся они на экран в текстовом режиме. Вывод

результатов обработки пользовательских запросов осуществляется в виде так

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

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

групп записей с одинаковым значением некоторой части ключа или полного

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

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

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

Наряду с табличной используется и так называемая ленточная или свободная

форма отчета, каждая запись которого может занимать несколько строк, и

форматы разных записей могут быть различны.

Выводимые прикладной системой отчеты могут выводиться на экран дисплеем

или печататься на принтере.

Традиционно построенное приложение использующее перечисленные

функциональные компоненты, предусматривает выполнение некоторого набора

типовых процедур. Обеспечивается, в частности, ввод записей в базу данных с

верификацией их по заданным простым ограничениям целостности, например,

по диапазону изменения значений числового поля формы или по шаблону

значения строкового поля. Кроме того, возможны просмотр, редактирование и

удаление записей, а также поиск записей по задаваемому через экранную форму

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

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

записи, имеющие такие же значения всех поисковых полей. К числу типовых

процедур приложения относится также вывод отчета по любой форме,

известной системе, на экран дисплея или на принтер.

Дружественный характер СУБД для ПЭВМ хорошо сочетается с главной

направленностью технологии персональных ЭВМ на обеспечение комфортных

условий работы пользователей. Благодаря этому достигается существенно более

высокая производительность труда пользователя при создании и эксплуатации

"персональных" баз данных, чем при выполнении подобных работ на "больших"

ЭВМ со свойственными их социальной пользовательской среде значительными

накладными расходами и более низкой надежностью.

Интерфейс СУБД с различными классами пользователей обычно

обеспечивается широким диапазоном языков. В нем также предусматриваются

соответствующие средства для проектирования и использования баз данных. В

подавляющем большинстве СУБД для ПЭВМ предусматривается

интерактивный режим работы пользователей. При этом широко используются

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

вариантов выбора возможных действий и способов их инициирования, с

отображением текущего состояния системы БД и диагностикой ошибок. В

системах, обладающих языками программирования ("программируемые"

СУБД), средства такого интерфейса избавляют пользователя от необходимости

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

Благодаря этому расширяется круг возможных пользователей системы. В

некоторых развитых СУБД предусматривается несколько уровней

пользовательских интерфейсов, предъявляющих различные требования к их

квалификации. Такие возможности предусмотрены, например, в системах

dBaseIII РLUS и dВаsе IV, R:Base, Раrаdох. Значительное внимание уделяется

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

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

системных средств и интерпретация возникающих в процессе работы ситуаций

существенно облегчаются благодаря созданию эффективных электронных

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

в оперативном режиме, а также средств диагностики ошибок. Такие средства

стали необходимыми компонентами любого программного продукта для

ПЭВМ.

Многие СУБД предоставляют пользователю возможность взаимного обмена

данными, содержат соответствующие программы-конверторы для

преобразования данных из одного формата в другой.

Сбалансированное сочетание простоты освоения и использования

"поверхностных" функций таких массовых СУБД, как dBaseIII РLUS , R:Base,

Раrаdох, обширных функциональных возможностей и прочих интерфейсов,

обеспечивает этим системам широкую сферу применения. Например, первые

впечатления от таких СУБД даже порождают у непрофессионального

пользователя иллюзию того, что любую ИС можно реализовать вообще без

какого-либо программирования в кратчайшие сроки и без заметных

трудозатрат, что в этой области вообще не существует проблем и

профессиональной специфики, требующей специальных знаний. Однако, по

мере усложнения информационных потребностей, когда уже не удается

обойтись средствами простейшего пользовательского интерфейса с системой и

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

рассеиваться.

Если объемы данных в БД достигают значительных размеров, при

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

беспокоить недостаточно высокая реактивность системы. Для решения

проблемы повышения производительности системы БД уже недостаточно

хорошего знания только языка программирования. Необходимы

профессиональные знания в области технологии БД, понимание архитектуры

системы, знание механизмов доступа к БД в рассматриваемой СУБД, умение

эффективно проектировать базу данных.