Шпаргалка по "Программированию и компьютеру"

1.Данные и ЭВМ

Восприятие  реального мира можно соотнести  с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать  эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.

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

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

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

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

2Концепция  БД

Активная  деятельность по отысканию приемлемых способов обобществления непрерывно растущего  объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых "Системы управления базами данных" (СУБД).

Основная  особенность СУБД – это наличие  процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием  хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД).

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

СОЗДАТЬ ТАБЛИЦУ  Расписание

  (Номер_рейса        Целое

   Дни_недели         Текст (8)

   Пункт_отправления   Текст (24)

   Время_вылета       Время

   Пункт_назначения   Текст (24)

   Время_прибытия     Время

   Тип_самолета       Текст (8)

   Стоимость_билета   Валюта);

и ввести его  вместе с данными в БД "Аэропорт". 

Язык запросов СУБД позволяет обращаться за данными  как из программ, так и с терминалов (рис. 1.2). Сформировав запрос 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

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

СУБД должна предоставлять доступ к данным любым  пользователям, включая и тех, которые  практически не имеют и (или) не хотят  иметь представления о:

• физическом размещении в памяти данных и их описаний;
• механизмах поиска запрашиваемых данных;
• проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
• способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;
• поддержании баз данных в актуальном состоянии

и множестве  других функций СУБД.

При выполнении основных из этих функций СУБД должна использовать различные описания данных.

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

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

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

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

4.Модели данных и основные типы СУБД

Как отмечалось в п. 1.3, инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д.

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

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

Сетевые модели также создавались для мало ресурсных  ЭВМ. Это достаточно сложные структуры, состоящие из "наборов" – поименованных двухуровневых деревьев. "Наборы" соединяются с помощью "записей-связок", образуя цепочки и т.д. При разработке сетевых моделей было выдумано множество "маленьких хитростей", позволяющих увеличить производительность СУБД, но существенно усложнивших последние. Прикладной программист должен знать массу терминов, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п. Один из разработчиков операционной системы UNIX сказал "Сетевая база – это самый верный способ потерять данные".

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

Сегодня наиболее распространены реляционные модели, которые будут подробно рассмотрены в главе 3.

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

5.CALS-технология понятие

Класс информационных технологий, направленных на обеспечение  безбумажной информационной поддержки  жизненного цикла продукта, именуется CALS-технологиями.

технологии  непрерывной информационной поддержки жизненного цикла продукции (CALS) позволяют:

решать различные  задачи, связанные с обработкой данных об изделии;

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

Этапы жизненного цикла

1. Маркетинговые исследования
2. Проектирование продукта
3. Планирование и разработка процесса
4. Закупка
5. Производство или обслуживание
6. Проверка
7. Упаковка и хранение
8. Продажа и распределение
9. Монтаж и наладка
10. Техническая поддержка и обслуживание
11. Послепродажная деятельность
12. Утилизация и(или) переработка

7. Методологии и  средства системного  проектирования

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

Технология  проектирования определяется как совокупность трех составляющих:

· пошаговой  процедуры, определяющей последовательность технологических операций проектирования (рис. 1.4);

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

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

 

Технология  проектирования, разработки и сопровождения  ИС должна удовлетворять следующим общим требованям:

· технология должна поддерживать полный ЖЦ ПО;

· технология должна обеспечивать гарантированное  достижение целей разработки ИС с  заданным качеством и в установленное  время;

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

· технология должна обеспечивать возможность ведения  работ по проектированию отдельных  подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости  коллектива и повышения производительности за счет минимизации числа внешних связей;

· технология должна обеспечивать минимальное время  получения работоспособной ИС.

· технология должна обеспечивать независимость  выполняемых проектных решений  от средств реализации ИС операционных систем, языков и систем программирования;