Что такое база данных, модель данных, банк данных и каким образом формируются данные в них.

Ба́за да́нных — представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ).

Классификация по модели данных

Примеры:

• Иерархическая

• Объектная и объектно-ориентированная

• Объектно-реляционная

• Реляционная

• Сетевая

• Функциональная.

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

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

1. Удовлетворять актуальным информационным потребностям внешних пользователей, обеспечивать возможность хранения и модификации больших объемов многоаспектной информации.

2. Обеспечивать заданный уровень достоверности хранимой информации.

3. Обеспечивать доступ к данным только пользователям с соответствующими полномочиями.

4. Обеспечивать возможность поиска информации по произвольной группе признаков.

5. Удовлетворять заданным требованиям по производительности при обработке запросов.

6. Иметь возможность реорганизации и расширения при изменении границ ПО.

7. Обеспечивать выдачу информации пользователю в различной форме.

8. Обеспечивать простоту и удобство обращения внешних пользователей за информацией.

9. Обеспечивать возможность одновременного обслуживания большого числа внешних пользователей.

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

Кроме выбора платформы на этапе проектирования определяются следующие характеристики архитектуры: 1) будет ли эта архитектура файл-сервер или клиент-сервер (определение написать)

Файл-сервер — это выделенный сервер, предназначенный для выполнения файловых операций ввода-вывода и хранящий файлы любого типа. Как правило, обладает большим объемом дискового пространства, реализованном в форме RAID-массива для обеспечения бесперебойной работы и повышенной скорости записи и чтения данных.

Клиент-сервер (англ. Client-server) — вычислительная или сетевая архитектура, в которой задания или сетевая нагрузка распределены между поставщиками услуг, называемыми серверами, и заказчиками услуг, называемыми клиентами. 2) будет ли это трехуровневая архитектура; (какие еще уровни)

Уровни архитектуры баз данных определены соответствующей группой ANSI/SPARC. Комитет планирования и стандартизации баз данных. Три уровня архитектуры:

1. Внешний уровень (External Level) – уровень, наиболее близкий к пользователю. Фактически он связан с тем, как видит данные конкретный пользователь. В этом случае нет никакой зависимости от конкретного языка и фактически внешний уровень – это то, как каждый конкретный пользователь видит те данные, которые ему определил программист, т.е. это внешнее представление конкретного пользователя.

2. Концептуальный уровень (Conceptual Level) – это обобщенное представление всех пользователей. По сути, если обобщить для SQL-сервера, то это то представление, каким видит базу данных администратор, а он, как правило видит все: все таблицы и т.д. Часто БД создает администратор –есть такая штатная единица – он отвечает за БД. Каждый конкретный пользователь может видеть свою часть – раздел бухгалтерия, склад, расписание и т.д. Администратор видит все. Это и есть концептуальный уровень.

3. Внутренний уровень (Internal Level) – уровень, фактически связанный с физическим хранением, со способом хранения. Здесь уже в каждой СУБД все может быть по-разному. Все зависит от того, как, например, представлены вещественные числа, как символы представлены – один или два байта – и.д. Фактически это важно только разработчикам СУБД. На первых двух уровнях, как правило, таблицы должны быть представлены пользователю реляционно, а на внутреннем уровне такого требования нет и как они представлены – дело разработчика. Главное, как представляются БД пользователю, а не разработчикам.

3) будет ли база данных централизованной или распределенной (определение) и тд. Этап проектирования завершается разработкой технического проекта.

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

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

15.10.14 Развитию ИТ-аутсорсинга способствуют следующие факторы: 1) потребность в более стабильном функционировании ИС предприятия 2) потребность сокращения затрат на содержание собственного ИТ-персонала  3) потребность повышения эффективности ИТ-инвестиций засчет более грамотного использования вычислительных и коммуникационных мощностей 4) недостаток собственной экспертизы и практики в области обслуживания ИС 5) желание сконцентрировать свои усилия на решение ключевых бизнес-задач и тд.

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

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

Нередко бизнес-подразделения формулируют свои требования, а, затем (за время разработки), забывают о проекте и начинают проявлять активность в момент испытаний, которые при таком отношении оказываются неудачными. Хотя после утверждения технических спецификаций, общее направление проекта обычно не меняется, примерно 80% решений, напрямую сказывающихся на удобстве и полезности системы для пользователя принимаются уже после разработки спецификаций и до приемочного тестирования. Таким образом, если будущие пользователи системы не учавствуют в постоянном процессе принятия решения, то впоследствии они обнаруживают, что результат не соответствует их ожиданиям.

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

Для ускорения процесса обучения рационально организовать систему поддержки пользователей, чтобы они могли задавать вопросы, а так же отмечать неудобства или проблемы в работе внедряемой системы. Инструменты и методы обеспечения проектирования АИС Основы компьютерной поддержки инженерии систем

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

Современные CASE средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств, анализа и документирования до полно масштабных средств автоматизации, покрывающих весь ЖЦ ПО.  В зависимости от фазы ЖЦ, на который применяется тот или иной инструмент, множество case средств подразделяются на следующие компоненты:

Инструменты высокого уровня - это средства поддержки определения и структурирования проекта, инициирование и планирование проекта, анализа и проектирования; как правило, эти средства не зависят от среды их применения.

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

Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых case средства обеспечивают качества принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.

В разряд case средств попадают как относительно дешевые системыдля персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных средств. Обычно к case средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов ЖЦ ПО и обладающие следующими особенностями: 1) мощные графические средства 2) интеграция отдельных компонентов case средств, обеспечивающая управляемость процессом разработки ИС 3) использование специальным образом организованного хранилища проектных метаданных

17.10.14 Выделяют следующие типы case систем: 1) анализ и проектирование. Средства этой группы используются для создания спецификаций системы и ее проектирования. Они поддерживают широко известные методологии проектирования (Design Generator, Pose, Analist/Designer и тд) 2) проектирование баз данных и файлов. Средства обеспечивают логическое моделирование данных, генерацию схем баз данных и описание формата файлов (Idef/Leverage, Chen Toolkit) 3) программирование. Поддерживаются шаги программирования и тестирования, а так же автоматическую кодогенерацию из спецификаций (Cobol/Workbench, Decase) 4) сопровождение и реинженерия. К таким средствам относятся документаторы, анализаторы программ, средства реструктурирования и обратной инженерии (Adpac Case Tools, Superstructure) 5) окружение. Средства, поддерживающие платформы для интеграции, создание и придание товарного вида (Multi/Cam, Sylvia Foondey) 6) управление проектом. Средства, поддерживающие планирование, контроль руководства, взаимодействия, тоесть функции, необходимые в процессе разработки и сопровождения проекта (Project Workbench)

В настоящее время на рынке представлено большое количество case систем, которые используют практически все известные методологии проектирования.  По степени интегрированности и выполняемым функциям они могут быть: 1) локальные, решающие небольшие автономные задачи и поддерживающие один-два типа моделей и методов (Design/IDE F, Pro Cap, PowerDesigner) 2) мало интегрированные средства моделирования, поддерживающие несколько типов моделей и методов (ERwin, BPwin) 3) средне интегрированные, поддерживающие до 15 типов моделей и методов (Rational Rose, Paradigm Plus) 4) крупные интегрированные средства моделирования, поддерживающие более 15 средств моделирования (ARIS Toolset)

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

Надо отметить, что проекты предприятия в области ИТ, как правило, индивидуальны. Они различаются по величине и быстроте возможной отдачи, поэтому требуют разных методов оценки. Для оценки вклада информационных проектов в общеэкокномические показатели компании разработан целый ряд инструментов, который можно разделить на 3 категории: 1) традиционные финансовые методики 2) инструменты качественного анализа 3) вероятностные подходы, использующие математические и статистические модели для измерения рисков и новых возможностей Традиционные финансовые методики: 1) совокупная стоимость владения (TCO). Применение данной методики может оказать помощь в определении прямых и косвенных затрат и выгод, связанных с любым компонентом компьютерных систем.

Основные цели методики: 1) оценка совокупных затрат на ИТ 2) выявление избыточных статей расхода 3) оценка возможностей возврата вложенных в ИТ средств 4) анализ привлекательности ИТ как объекта инвестиций Ключевой момент применения методики в совокупной стоимости владения заключается в сравнении с аналогичными показателями других компаний схожего профиля. Стоит отметить, что получение точной оценки стоимости владения довольно сложный процесс из-за трудностей сбора исходных данных. Наиболее просто собрать данные о стоимости оборудования, ПО, затрат на ремонт, простои серверов и тд. Вычисление эффективности действий сотрудников наиболее затруднительно, если функции, которые они выполняют различаются.

2) экономическая добавленная стоимость (EVA) В качестве основной характеристики используют чистую операционную прибыль, из которой вычитаются соответствующие денежные затраты. При оценке, например, новой системы ERP, данная методология требует учета всех инвестиций, в том числе первоначальных денежных вложений, расходов на поддержку, затрат на внутренние и внешние обучения и тд. Все эти расходы считаются платой за предполагаемую выгоду, которая будет способствовать увеличению оборота и снижению издержек. 3) совокупный экономический эффект заключается в определении уровня риска для 3х основных параметров: - стоимость (как правило расчитывается по методу совокупной стоимости владения) - преимущества (оценка проводится с точки зрения стоимости проекта и стратегических вложений, выходящих за рамки ИТ) - гибкость (определяется с использованием методологий, расчетов фьючерсов и опционов) 4) быстрое экономическое обоснование. Данная методология предусматривает конкретизацию модели совокупной стоимости владения путем установления соотношения между расходами на ИТ и приоритетами бизнеса.

Качественные методы: Применение таких методов позволяет учитывать не только количественную сторону процессов, но и качественную. 1) система сбалансированных показателей. Метод позволяет оценить такие нематериальные активы, как: - уровень корпоративных инноваций - степень удовлетворенности сотрудников  - эффективность приложений и тд. Данные параметры рассматриваются с 4х точек зрения: финансовой, удовлетворение потребностей клиентов, внутренних процессов, дальнейшего роста и обучения. 2) информационная экономика  3) управление портфелем активов 4) система показателей  Вероятностные показатели: 1) справедливая цена опционов  2) прикладная информационная экономика

22