- •Ит (Гутгарц р.Д.)
- •1__Признаки группировки информации в компьютере
- •2__Программное обеспечение: понятие, структура системного и прикладного по.
- •3__Характеристики оценки прикладных программ: стандартные, технические, технологические, инструментальные, взаимодействие с другими пакетами, функциональные.
- •4__Практические рекомендации по оценке программных продуктов
- •5__Понятие информация (определение, формулы измерения информации)
- •Синтаксическая мера информации
- •Семантическая мера информация
- •Прагматическая мера информации
- •6__Информационный процесс. Его стадии и особенности
- •7__Качества или свойства информации
- •8__ Понятия данных и знаний. Взаимосвязь информации, данных и знаний (пример)
- •9__Видеоконференция. Особенности работы и области применения
- •10__Телеработа. Понятие. Преимущества для работника и работодателя. Особенности применения
- •11__Дистанционное обучение и мультимедиа системы. Особенности и направления использования
- •12__Интернет – тестирование. Плюсы и минусы. Область применения
- •13__Трудоустройство в Интернет. Структура Интернет – услуг по трудоустройству
- •По системологии(Гутгарц р.Д. )
- •14__Принципы системного подхода.
- •15__Неформализуемые этапы системного анализа.
- •16__ Формулирование и классификация проблем
- •17__ Выявление целей и формирование критериев
- •18__ Генерирование альтернатив: источники альтернатив, способы увеличения и сокращения числа альтернатив
- •19__Способы генерирования альтернатив
- •20__Методы анализа систем управления: проведение интервью (структура, советы по применению), анкетирование, обзор документов, наблюдение
- •4.1 Интервьюирование
- •4.2 Анкетирование
- •4.3. Обзор документов
- •4.4 Наблюдение
- •Информационные сети (Бахвалов с.В.)
- •21__Понятия о функциональной, структурной организации и архитектуре вм; основные характеристики вм, методы оценки
- •22__Классификация вычислительных систем (вс) по способу организации обработки. Многопроцессорные и многомашинные комплексы.
- •23__Особенности архитектуры локальных сетей ( стандарты ieee 802).
- •24__Сеть Internet, доменная организация, семейство протоколов tcp/ip. Информационно-вычислительные сети и распределенная обработка информации.
- •По Операционным системам (Скрипкин с.К. )
- •25.__Обзор современных операционных систем и операционных оболочек
- •1. Семейство Microsoft Windows.
- •4. Семейство unix
- •26.__Машинно-зависимые свойства операционных систем
- •27.__Машинно-независимые свойства операционных систем
- •28__Динамические, последовательные и параллельные структуры программ;
- •29__Способы построения операционных систем
- •По Мультимедиатехнологии (Скрипкин с.К. )
- •30__Классификации и области применения мультимедиа
- •3.1. Различные области применения мультимедиа
- •31__Звуковые файлы: музыка, речь и звуковые эффекты.
- •32__Графика (растровая, векторная, трехмерная, фрактальная и др.) и анимация
- •Растровая и векторная графика
- •33__Линейный, нелинейный и смешанный монтаж для видео.
- •34__Виртуальная и расширенная реальности.
- •Моделирование систем (Петров а.В.)
- •35__Модели и моделирование
- •36__Математическое моделирование
- •37__Имитационное моделирование
- •38__Динамическое моделирование по Дж. Форрестеру
- •39__Индивидуальное имитационное моделирование объектов
- •Надёжность, эргономика и качество асоиу, Управление проектами Засядко а.А.)
- •40__Показатели надёжности
- •41__Факторы надёжности информационных систем
- •42__Принципы управления проектами
- •43__Методология управления проектами
- •44__Автоматизация управления проектами
- •Интеллектуальные информационные системы (Массель л.В.)
- •45__Основные понятия и принципы организации хранилищ данных.
- •Data Mart (Витрины данных)
- •46__Классификация искусственных нейронных сетей. Самоорганизующиеся карты Кохонена.
- •Многослойные нейронные сети прямого распространения. Базовая архитектура.
- •47__Модель искусственного нейрона. Активационная функция.
- •49__Нечеткие множества.
- •50__Онтологии. Основные понятия и типы онтологий.
- •Представление знаний. (Массель л.В.)
- •51__Классификациям моделей представления знаний.
- •52__Архитектура экспертной системы. Типы экспертных систем.
- •53__Классификация методов извлечения знаний.
- •54__Инструментальные средства и стадии разработки эс.
- •55__Отличие данных от знаний. Формы данных и знаний.
- •Проектирование информационных систем.( Массель л.В.)
- •56__Определение и классификация информационных систем
- •57__Структурный подход к проектированию информационных систем.
- •58__Объектный подход к проектированию информационных систем.
- •59__Rad-технология разработки информационных систем.
- •60__Каскадный и спиральный жизненные циклы разработки информационных систем.
- •61__Виды обеспечения и этапы разработки автоматизированных информационных систем
- •Основы сппр(Массель л.В.)
- •62__Определение, типы и классы сппр. 63__Состав и структура сппр.
- •64__Сппр. Критерии принятия решений и их шкалы.
- •65__Сппр. Основные составляющие задачи принятия решения.
- •66__Сппр. Генерация решений: формирование когнитивной карты.
- •Психологические основы проектирования интерфейсов.( Массель л.В.)
- •67__Принципы проектирования и критерии эффективности интерфейсов.
- •Окна диалогов с закладками
- •68__Организация пространства при компоновке интерфейса. Организация пространства
- •Расположение большого числа элементов
- •Перегруженность элементами управления
- •Расположение информации на экране
- •69__Элементы дизайна при проектировании интерфейса: шрифты, эффекты, цвета.
- •Эффекты
- •Выравнивание текста
- •Рекомендуются следующие правила использования цвета:
- •Способы уменьшения видимости задержки:
- •Рекомендуются следующие правила использования цвета:
- •Управление данными (Трипутина в.В.)
- •72__Классификация моделей данных
- •73__Понятие базы данных. Основные характеристики баз данных
- •74__Методика проектирования баз данных. Этапы проектирования баз данных
- •75__Реляционная модель данных. Основные понятия
- •76__Нормальные формы отношений
- •77__Модели доступа к данных в архитектуре «клиент-сервер»
- •78__Понятие транзакций. Свойства, обработка, блокировки транзакций
- •79__Субд. Понятие, основные функции, требования к серверу баз данных
- •Анализ бизнес-процессов (Гонегер п.А.)
- •80_Процессный и функциональный подходы в управлении. Организация управления в соответствии с госТами исо 9000-2001 и исо 9001-2001.
- •81_Основные понятия процессного подхода. Виды бизнес-процессов. Схема управления бизнес-процессом. Цели описания бизнес-процессов. Информация, необходимая при описании бизнес-процессов.
- •82_Характеристика методов улучшения бизнес-процессов.
- •83_Требования к организационной структуре. Характеристика основных организационных структур. Связь процессов и структуры.
- •84_Характеристика методологий, используемых для описания бизнес-процессов.
- •Основы теории управления (Ружников г.М.)
- •85__Передаточные функции последовательного и параллельного соединения звеньев.
- •86__Передаточная функция замкнутой системы.
- •87__Устойчивость линейных систем (вывод).
- •88__Критерий устойчивости Михайлова (вывод - случай вещественных корней).
- •89__Частотная передаточная функция и частотные характеристики (определения, формы записи, графики).
74__Методика проектирования баз данных. Этапы проектирования баз данных
При проектировании базы данных решаются две основные проблемы:
1. Отображение объектов предметной области в абстрактные объекты модели данных таким образом, чтобы это отображение не противоречило семантике предметной области и было по возможности лучшим (эффективным, удобным и т.д.). Часто эту проблему называют проблемой логического проектирования баз данных.
2. Обеспечение эффективного выполнения запросов к базе данных, т.е. рациональное расположение данных во внешней памяти, создание полезных дополнительных структур (например, индексов) с учетом особенностей конкретной СУБД. Эту проблему называют проблемой физического проектирования баз данных.
Шаги проектирования базы данных
I. Первый шаг состоит в определении информационных потребностей базы данных. Он включает в себя опрос будущих пользователей для того, чтобы понять и задокументировать их требования. Следует выяснить следующие вопросы:
сможет ли новая система объединить существующие приложения или их необходимо будет кардинально переделывать для совместной работы с новой системой;
какие данные используются разными приложениями; смогут ли Ваши приложения совместно использовать какие-либо из этих данных;
кто будет вводить данные в базу и в какой форме; как часто будут изменяться данные;
достаточно ли будет для Вашей предметной области одной базы или Вам потребуется несколько баз данных с различными структурами;
какая информация является наиболее чувствительной к скорости ее извлечения и изменения.
II. Следующий шаг включает в себя анализ объектов реального мира, которые необходимо смоделировать в базе данных.
Формирование концептуальной модели базы данных включает в себя:
идентификацию функциональной деятельности Вашей предметной области. Например, если речь идет о деятельности предприятия, то в качестве функциональной деятельности можно идентифицировать ведение учета работающих, отгрузку продукции, оформление заказов и т.п.
идентификацию объектов, которые осуществляют эту функциональную деятельность, и формирование из их операций последовательности событий, которые помогут Вам идентифицировать все сущности и взаимосвязи между ними. Например, процесс “ведение учета работающих” идентифицирует такие сущности как РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ.
идентификацию характеристик этих сущностей. Например, сущность РАБОТНИК может включать такие характеристики как Идентификатор Работника, Фамилия, Имя, Отчество, Профессия, Зарплата.
идентификацию взаимосвязей между сущностями. Например, каким образом сущности РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ взаимодействуют друг с другом? Работник имеет одну профессию (для простоты!) и значится в одном отделе, в то время как в одном отделе может находиться много работников.
III. Третий шаг заключается в установлении соответствия между сущностями и характеристиками предметной области и отношениями и атрибутами в нотации выбранной СУБД. Поскольку каждая сущность реального мира обладает некими характеристиками, в совокупности образующими полную картину ее проявления, можно поставить им в соответствие набор отношений (таблиц) и их атрибутов (полей).
Перечислив все отношения и их атрибуты, уже на этом этапе можно начать устранять излишние позиции. Каждый атрибут должен появляться только один раз; и Вы должны решить, какое отношение будет являться владельцем какого набора атрибутов.
IV. На четвертом шаге определяются атрибуты, которые уникальным образом идентифицируют каждый объект. Это необходимо для того, чтобы система могла получить любую единичную строку таблицы. Вы должны определить первичный ключ для каждого из отношений. Если нет возможности идентифицировать кортеж с помощью одного атрибута, то первичный ключ нужно сделать составным - из нескольких атрибутов. Хорошим примером может быть первичный ключ в таблице работников, состоящий из фамилии, имени и отчества. Первичный ключ гарантирует, что в таблице не будет содержаться двух одинаковых строк. Во многих СУБД имеется возможность помимо первичного определять еще ряд уникальных ключей. Отличие уникального ключа от первичного состоит в том, что уникальный ключ не является главным идентифицирующим фактором записи и на него не может ссылаться внешний ключ другой таблицы. Его главная задача - гарантировать уникальность значения поля.
V. Пятый шаг предполагает выработку правил, которые будут устанавливать и поддерживать целостность данных. Будучи определенными, такие правила в клиент-серверных СУБД поддерживаются автоматически - сервером баз данных; в локальных же СУБД их поддержание приходится возлагать на пользовательское приложение.
Эти правила включают:
определение типа данных
выбор набора символов, соответствующего данной стране
создание полей, опирающихся на домены
установка значений по умолчанию
определение ограничений целостности
определение проверочных условий.
VI. На шестом шаге устанавливаются связи между объектами (таблицами и столбцами) и производится очень важная операция для исключения избыточности данных - нормализация таблиц.
Каждый из различных типов связей должен быть смоделирован в базе данных. Существует несколько типов связей:
- связь “один-к-одному”
- связь “один-ко-многим”
- связь “многие-ко-многим”.
Связь “один-к-одному” представляет собой простейший вид связи данных, когда первичный ключ таблицы является в то же время внешним ключом, ссылающимся на первичный ключ другой таблицы. Такую связь бывает удобно устанавливать тогда, когда невыгодно держать разные по размеру (или по другим критериям) данные в одной таблице. Например, можно выделить данные с подробным описанием изделия в отдельную таблицу с установлением связи “один-к-одному” для того чтобы не занимать оперативную память, если эти данные используются сравнительно редко.
Связь “один-ко-многим” в большинстве случаев отражает реальную взаимосвязь сущностей в предметной области. Она реализуется уже описанной парой “внешний ключ-первичный ключ”, т.е. когда определен внешний ключ, ссылающийся на первичный ключ другой таблицы. Именно эта связь описывает широко распространенный механизм классификаторов. Имеется справочная таблица, содержащая названия, имена и т.п. и некие коды, причем, первичным ключом является код. В таблице, собирающей информацию - назовем ее информационной таблицей - определяется внешний ключ, ссылающийся на первичный ключ классификатора. После этого в нее заносится не название из классификатора, а код. Такая система становится устойчивой от изменения названия в классификаторах. Имеются способы быстрой “подмены” в отображаемой таблице кодов на их названия как на уровне сервера БД (для клиент-серверных СУБД), так и на уровне пользовательского приложения.
Связь “многие-ко-многим” в явном виде в реляционных базах данных не поддерживается. Однако имеется ряд способов косвенной реализации такой связи, которые с успехом возмещают ее отсутствие. Один из наиболее распространенных способов заключается во введении дополнительной таблицы, строки которой состоят из внешних ключей, ссылающихся на первичные ключи двух таблиц.
Итак, после определения таблиц, полей, индексов и связей между таблицами следует посмотреть на проектируемую базу данных в целом и проанализировать ее, используя правила нормализации, с целью устранения логических ошибок. Важность нормализации состоит в том, что она позволяет разбить большие отношения, как правило, содержащие большую избыточность информации, на более мелкие логические единицы, группирующие только данные, объединенные “по природе”. Таким образом, идея нормализации заключается в следующем. Каждая таблица в реляционной базе данных удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное значение, и никогда не может быть множества таких значений.
После применения правил нормализации логические группы данных располагаются не более чем в одной таблице. Это дает следующие преимущества:
- данные легко обновлять или удалять
- исключается возможность рассогласования копий данных
- уменьшается возможность введения некорректных данных.
Процесс нормализации заключается в приведении таблиц в так называемые нормальные формы. Существует несколько видов нормальных форм: первая нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная форма (3НФ), нормальная форма Бойса-Кодда (НФБК), четвертая нормальная форма (4НФ), пятая нормальная форма (5НФ). С практической точки зрения, достаточно трех первых форм - следует учитывать время, необходимое системе для “соединения” таблиц при отображении их на экране.
Этот процесс включает:
·устранение повторяющихся групп (приведение к 1НФ)
·удаление частично зависимых атрибутов (приведение к 2НФ)
·удаление транзитивно зависимых атрибутов (приведение к 3НФ).
Необходимо четко понимать, что разбиение информации на более мелкие единицы с одной стороны, способствует повышению надежности и непротиворечивости базы данных, а с другой стороны, снижает ее производительность, так как требуются дополнительные затраты процессорного времени (серверного или машины пользователя) на обратное “соединение” таблиц при представлении информации на экране. Иногда для достижения требуемой производительности нужно сделать отход от канонической нормализации, при этом ясно осознавая, что необходимо обеспечить меры по предотвращению противоречивости в данных. Поэтому всякое решение о необходимости того или иного действия по нормализации можно принимать только тщательно проанализировав предметную область и класс поставленной задачи. Может потребоваться несколько итераций для достижения состояния, которое будет желаемым компромиссом между четкостью представления и реальными возможностями техники.
VII. Седьмой шаг является последним в нашем списке, но не последним по важности в процессе проектирования базы данных. На этом шаге мы должны спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации. Для этого необходимо ответить на следующие вопросы:
кто будет иметь права (и какие) на использование базы данных
кто будет иметь права на модификацию, вставку и удаление данных
нужно ли делать различие в правах доступа
каким образом обеспечить общий режим защиты информации и т.п.
Предметная область - часть реального мира, подлежащая изучению с целью организации управления и, в конечном счете, автоматизации. Предметная область представляется множеством фрагментов, например, предприятие - цехами, дирекцией, бухгалтерией и т.д. Каждый фрагмент предметной области характеризуется множеством объектов и процессов, использующих объекты, а также множеством пользователей, характеризуемых различными взглядами на предметную область.
Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (так называемая модель ANSI/SPARC):
Внешнее представление (внешняя схема) данных является совокупностью требований к данным (т.е. определенным образом представленная информация) со стороны некоторой конкретной функции, выполняемой пользователем или со стороны конкретного пользователя. Концептуальная схема является полной совокупностью всех требований к данным, полученной из пользовательских представлений о реальном мире. Внутренняя схема - это сама база данных.
Воронка Сенко – внешний уровень, концептуальный уровень, внутренний уровень.
Основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:
Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:
обследование предметной области, изучение ее информационной структуры
выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами
моделирование и интеграция всех представлений
По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели "сущность-связь".
Логическое проектирование - преобразование требований к данным в структуры данных. На выходе получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.
Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д.
КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ
|
Представление аналитика |
ЛОГИЧЕСКИЙ УРОВЕНЬ
|
Представление программиста |
ФИЗИЧЕСКИЙ УРОВЕНЬ
|
Представление администратора |