Педагогические цели использования СНИТ
Развитие личности обучаемого, подготовка индивида к комфортной жизни в условиях информационного общества
• развитие мышления, (например, наглядно-действенного, наглядно—образного, интуитивного, творческого, теоретического видов мышления);
• эстетическое воспитание (например, за счет использования возможностей компьютерной графики, технологии Мультимедиа);
• развитие коммуникативных способностей
• формирование умений принимать оптимальное решение или предлагать варианты решения в сложной ситуации (например, за счет использования компьютерных игр, ориентированных на оптимизацию деятельности по принятию решения);
• развитие умений осуществлять экспериментально-исследовательскую деятельность (например, за счет реализации возможностей компьютерного моделирования или использования оборудования, сопрягаемого с ЭВМ);
• формирование информационной культуры, умений осуществлять обработку информации (например, за счет-использования интегрированных пользовательских пакетов, различных графических и музыкальных редакторов).
Реализация социального заказа, обусловленного информатизацией современного общества
• подготовка специалистов в области информатики и вычислительной техники;
• подготовка пользователя средствами новых информационных технологий.
Интенсификация всех уровней учебно-воспитательного процесса
• повышение эффективности и качества процесса обучения за счет реализации возможностей СНИТ;
• обеспечение побудительных мотивов (стимулов), обусловливающих активизацию познавательной деятельности (например, за счет компьютерной визуализации учебной информации, вкрапления игровых ситуаций, возможности управления, выбора режима учебной деятельности);
• углубление межпредметных связей за счет использования современных средств обработки информации, в том числе и аудиовизуальной, при решении задач различных предметных областей.
Направления внедрения СНИТ в образование
СНИТ могут быть использованы в качестве:
1) Средства обучения, совершенствующего процесс преподавания, повышающего его эффективность и качество. При этом обеспечивается:
• реализация возможностей программно-методического обеспечения современных ПЭВМ и лр. в целях сообщения знаний, моделирования учебных ситуаций. осуществления тренировки, контроля за результатами обучения;
• использование объектно—ориентированных программных средств или систем (например, системы подготовки текстов, электронных таблиц, баз данных) в целях формирования культуры учебной деятельности;
• реализация возможностей систем искусственного интеллекта в процессе применения обучающих интеллектуальных систем.
2) Инструмента познания окружающей действительности и самопознания.
3) Средства развития личности обучаемого.
4) Объекта изучения (например, в рамках освоения курса информатики).
5) Средства информационно—методического обеспечения и управления учебно—воспитательным процессом. учебными заведениями, системой учебных заведений.
6) Средства коммуникаций (например, на базе асинхронной телекоммуникационной связи) в целях распространения передовых педагогических технологий.
7) Средства автоматизации процессов контроля, коррекции результатов учебной деятельности, компьютерного педагогического тестирования и психодиагностики.
8) Средства автоматизации процессов обработки результатов эксперимента (лабораторного, демонстрационного) а управления учебным оборудованием.
9) Средства организации интеллектуального досуга, развивающих игр.
Базы данных
Системы управления базами данных (СУБД, DBMS – Database Management System) на протяжении всего пути развития компьютерной техники совершенствовались, поддерживая все более сложные уровни абстрактных данных, заданных пользователем, и обеспечивая взаимодействие компонентов, распределенных в глобальных сетях и постепенно интегрирующихся с телекоммуникационными системами. История развития компьютерной техники – это история непрерывного движения от языка и уровня коммуникации машины к уровню пользователя. Если первые машины требовали от пользователя оформления того, что ему нужно (то есть написания программ), в машинных кодах, то языки программирования четвертого уровня (4GLs) позволяли конечным пользователям, не являющимся профессиональными программистами, получать доступ к информации без детального описания каждого шага, но только с встроенными предопределенными типами данных – например, таблицами.
Последним шагом в этом направлении стала объектно-ориентированная технология, радикально изменившая сферу разработки программного обеспечения уже в 1990-х годах. Объектно-ориентированный подход позволяет упаковывать данные и код для их обработки вместе. Таким образом, практически снимается ограничение на типы данных, позволяя работать на любом уровне абстракции.
Эволюция систем управления информацией шла параллельно этому прогрессу, начиная с низкоуровневых программ, которые, например, напрямую производили операции чтения и записи со всей памятью без ограничения доступа, лентой, цилиндрами и дорожками диска и более высокоуровневыми средствами – файловыми системами, которые оперировали с такими понятиями, как массивы, записи и индексы для повышения производительности. Базы данных в свою очередь начинали с модели записей и индексов (ISAM и др.), приобретая со временем способность восстановления после сбоев, проверки целостности данных и возможности работы нескольких пользователей одновременно. Эти ранние модели данных (CODASYL) относились скорее к уровню машинной ориентации. В дальнейшем реляционные базы данных, пришедшие на смену в 1980‑х годах, приобрели механизм запросов, позволяющий пользователю указать требуемое, предоставив СУБД самой оптимальным образом найти результат, используя динамическую индексацию.
Обьектно-ориентированные СУБД (ООСУБД) стали разрабатываться с середины 80‑х годов в основном для поддержки приложений САПР. Сложные структуры данных систем автоматизированного проектирования, оказалось, очень удобно оформлять в виде объектов, а технические чертежи проще хранить в базе данных, чем в файлах. Это позволяет обойтись без декомпозиции графических структур на элементы и записи их в файлы после завершения работы с чертежом, выполнения обратной операции при внесении любого изменения. Если типичные реляционные базы данных имеют связи глубиной в два уровня, то иерархическая информация чертежей САПР обычно включает порядка десяти уровней, что требует достаточно сложных операций для “сборки” результата. Объектные базы данных хорошо соответствовали подобным задачам, и эволюция многих СУБД началась именно с рынка САПР.
Между тем рынок САПР был быстро насыщен, и в начале 90‑х годов производители ООСУБД обратили внимание на другие области применения, уже прочно занятые реляционными СУБД. Для этого потребовалось оснастить ООСУБД функциями оперативной обработки транзакций (OLTP), утилитами администратора баз данных (database administrator – DBA), средствами резервного копирования/восстановления и т. д. Работы в данном направлении продолжаются и сегодня, но уже можно сказать, что переход к коммерческим приложениям идет достаточно успешно.
В реляционных базах данных (Relational Database System, RDBS) все данные отображаются в двумерных таблицах. База данных, таким образом, это ни что иное, как набор таблиц. RDBS и ориентированные на записи системы организованы на основе стандарта B-Tree или методе доступа, основанном на индексации – Indexed Sequential Access Method (ISAM) и являются стандартными системами, использующимися в большинстве современных программных продуктов. Для обеспечения комбинирования таблиц для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel (Ingres) и RDO (Digital Equipment), причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных СУБД.
Оригинальная версия SQL – это интерпретируемый язык, предназначенный для выполнения операций над базами данных. Язык SQL был создан в начале 70‑х как интерфейс для взаимодействия с базами данных, основанными на новой для того времени реляционной теории. Реальные приложения обычно написаны на других языках, генерирующих код на языке SQL и передающих их в СУБД в виде текста в формате ASCII. Нужно отметить также, что практически все реальные реляционные (и не только реляционные) системы помимо реализации стандарта ANSI SQL, включают в себя дополнительные расширения, например, поддержка архитектуры клиент-сервер или средства разработки приложений.
Строки таблицы составлены из полей, заранее известных базе данных. В большинстве систем нельзя добавлять новые типы данных. Каждая строка в таблице соответствует одной записи. Положение данной строки может изменяться вместе с удалением или вставкой новых строк.
Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле или поля называются первичным ключом (primary key) таблицы и часто являются числами. Если одна таблица содержит первичным ключ другой, это позволяет организовать связь между элементами разных таблиц. Это поле называется внешним ключом (foreign key).
Так как все поля одной таблицы должны содержать постоянное число полей заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание, сколько - нибудь сложных взаимосвязей в базе данных. Еще один крупный недостаток реляционных баз данных – это высокая трудоемкость манипулирования информацией и изменения связей.