Главная > Документ


МОУ лицей № 17 г. Костромы










Реферат

Методика преподавания баз данных в школе





Выполнил: учитель информатики

МОУ лицей № 17 г. Костромы

Виноградова Юлия Николаевна







Кострома

2006

Оглавление

Введение 3

Основная часть 5

Глава 1 Базы данных 5

1.2 Этапы создания информационных систем 6

1.5 Выбор среды разработки информационной базы интеллектуальной системы управления. 12

Глава 2 Технология создания баз данных 15

Глава 3 Поиск, хранение и сортировка информации 21

5.В чем заключается функция ключевого поля? 53

6.Что такое запрос? 53

Заключение 58

Список литературы 59

Введение

Российская образовательная система находится на пороге важных событий. Нас ждет массовое проникновение в учебную жизнь электронных пособий, дистанционного обучения, Интернета. Это время принятия ключевых решений, влияние которых распространяется на многие годы. На сегодняшний день основой общероссийского образования является Концепция модернизации российского образования на период до 2010 года, утвержденной распоряжением Правительства Российской Федерации от 29.12.2001 г. № 1756-р, приоритетными направлениями развития образовательной системы Российской Федерации иФедеральной целевой программой развития образования, утвержденной постановлением Правительства Российской Федерации от 23.12.2005 г. № 803. Согласно этим программам в качестве основного фактора обновления профессионального образования выступают запросы развития экономики и социальной сферы, науки, техники, технологий, федерального и территориальных рынков труда, а также перспективные потребности их развития.1

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

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

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

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

В реферате содержится теоретический материал «Основные понятия баз данных», а также приведено примерное тематическое и поурочное планирование по учебнику Н.Д. Угриновича темы «Поиск, хранение и обработка информации», конспекты уроков.

В качестве изучения СУБД была выбрана Microsoft Access.

Microsoft Access является СУБД реляционного типа, в которой разумно сбалансированы все средства и возможности, типичных для современных СУБД. Реляционная база упрощает поиск, анализ, поддержку и защиту данных, поскольку они сохраняются в одном месте. Microsoft Access в переводе с английского означает «доступ». Microsoft Access — это функционально полная реляционная СУБД. Кроме того, Microsoft Access одна из самых мощных, гибких и простых в использовании СУБД. В ней можно создавать большинство приложений, не написав ни единой строки программы, но если нужно создать нечто очень сложное, то на этот случай Microsoft Access предоставляет мощный язык программирования — Visual Basic Application.

Основная часть

Глава 1 Базы данных

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

При обработке на ЭВМ данные трансформируются, условно проходя следующие этапы:

  1. D1 – данные как результат измерений и наблюдений;

  2. D2 – данные на материальных носителях информации (таблицы, протоколы, справочники);

  3. D3 – модели (структуры) данных в виде диаграмм, графиков, функций;

  4. D4 – данные в компьютере на языке описания данных;

  5. D5 – базы данных на машинных носителях информации.1

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

Данные и знания необходимы при разработке ИС. Проектируя сложную ИС, ее разбивают на части, каждая из которых затем рассматривается отдельно. Возможны два различных способа такого разбиения ИС на подсистемы: структурное (или функциональное) разбиение и объектная (компонентная) декомпозиция.

Суть функционального разбиения хорошо отражена в известной формуле:

«Программа = Данные + Алгоритмы».

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

Объектное разбиение в последнее время называют компонентным, что нашло отражение в специальном термине: «разработка, основанная на компонентах» (Component Based Development - CBD). При этом используется иной принцип декомпозиции - система разбивается на «активные сущности» – объекты или компоненты, которые взаимодействуют друг с другом, обмениваясь сообщениями и выступая, друг к другу в отношении «клиент/сервер». Сообщения, которые может принимать объект, определены в его интерфейсе. В этом смысле посылка сообщения «объекту-серверу» эквивалентна вызову соответствующего метода объекта. Большинство существующих CASE-средств опираются в основном на структурные методологии.

Примером системы, в которой осуществляется функциональное разбиение, является BPwin (система моделирования потоков данных), поддерживающая методологии IDEF0 (функциональная модель) , IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram).3 Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии и идеального положения вещей – того, к чему нужно стремиться. Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования.

1.2 Этапы создания информационных систем

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

Цель моделирования данных на логическом уровне состоит в обеспечении разработчика ИС концептуальной схемой базы данных в форме одной модели или нескольких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Логический уровень это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Отдел», «Фамилия сотрудника». Объекты, модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например модели процессов. Такая модель данных является универсальной и никак не связана с конкретной реализацией СУБД (системы управления базой данных). Построение логической модели ИС до ее программной разработки или до начала проведения архитектурной реконструкции столь же необходимо, как наличие проектных чертежей перед строительством большого здания. Хорошие модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков.

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

1.3 Логические модели. На логическом уровне проектирования строится так называемая визуальная модель объекта.

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

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

  • повышение качества программного продукта,

  • сокращение стоимости проекта,

  • поставка системы в запланированные сроки.

Существует множество подходов к построению таких моделей: продукционные, фреймы, графовые модели, семантические сети, модель «сущность-связь» (ERD), UML и т.д.

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

Сначала стали использовать иерархическиедаталогические модели.

Иерархические БД состоят из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева.

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

Пример типа дерева приведен на рис.1

Рис.1 Иерархическая модель данных.

Здесь Отдел является предком для Начальника и Сотрудники, а Начальник и Сотрудники – потомки отдела. Между типами записи поддерживаются связи. Никакой потомок не может существовать без своего родителя, причем предок должен быть один.

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

Сетевые модели также создавались для мало ресурсных ЭВМ.

Сетевой подход к организации данных является расширением иерархического. В этой модели потомок может иметь любое число предков.

Сетевая БД (рис.2) состоит из набора записей и набора связей между этими записями, а если говорить более точно, из наборов экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи. Тип связи определяется для двух типов записи предка и потомка.

Рис.2. Сетевая модель данных.

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

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

Сегодня наиболее распространены реляционные(основанные на двумерных таблицах) модели данных. Любая система данных, не имеет значения какой сложности, может быть сведена к набору таблиц (или «отношений» в терминологии СУРБД). Каждое отношение (таблица) может быть представлено в виде прямоугольного массива со следующими свойствами:

  • каждая ячейка в таблице представляет точно один элемент данных; нет повторяющихся групп;

  • каждая таблица имеет однородные столбцы; все элементы в любом из столбцов одного и того же вида;

  • каждому столбцу назначено определенное имя;

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

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

  • каждая строка олицетворяет уникальный элемент данных, который ею и описывается;

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

Строки обычно называют записями, а столбцы – полями.

Вообще, лишь немногие реальные базы данных могут быть описаны при помощи единственной таблицы. Большинство приложений используют множество таблиц, которые содержат столбцы (поля) с одинаковым именем. Эти общие данные позволяют, объединяя две (или несколько) таблиц, строить осмысленные ассоциации.



Рис.3 Реляционная модель данных.

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

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

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

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

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

Несмотря на всю свою привлекательность и «привычность», классические реляционные системы управления базами данных являются ограниченными. Они идеально походят для таких традиционных приложений, как системы резервирования билетов или мест в гостиницах, а также банковских систем, но их применение в системах автоматизации проектирования, интеллектуальных производственных системах и других системах, основанных на знаниях, часто является затруднительным. Это, прежде всего, связано с примитивностью структур данных, лежащих в основе реляционной модели данных. Плоские нормализованные отношения универсальны и теоретически достаточны для представления данных любой предметной области. Однако в нетрадиционных приложениях в базе данных появляются сотни, если не тысячи таблиц, над которыми постоянно выполняются дорогостоящие операции соединения, необходимые для воссоздания сложных структур данных, присущих предметной области.

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

В качестве других недостатков реляционных СУБД отмечаются следующие:

  • негибкость структуры для развивающихся БД;

  • затруднения в построении концептуальной модели для объектов с многочисленными связями «многие – ко – многим»;

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

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

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

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

Реляционные БД с их строгим определением структуры и ограниченным набором разрешенных операций, бесспорно, не подходят в качестве базовой платформы для ООБД.4

1.5 Выбор среды разработки информационной базы интеллектуальной системы управления.

За исключением некоторых систем, иерархические СУБД почти полностью ушли с рыночной арены, а также и из сознания разработчиков приложений. Лидирующее положение два последних десятилетия занимает реляционная модель данных, представленная на рынке большими и маленькими коммерческими пакетами, такими как Oracle, Sybase, Access и др. Несмотря на полный коммерческий успех, многие эксперты ожидают изменений основополагающих принципов технологии БД в ближайшие пять лет.

В качестве недостатков реляционных СУБД отмечаются следующие:

- негибкость структуры для развивающихся БД;

- затруднения в построении концептуальной модели для объектов с многочисленными связями «многие - ко – многим»;

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

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

Что касается объектно-ориентированных СУБД, то можно сказать, что теоретическая модель для них на сегодняшний день не разработана, а прикладные коммерческие продукты, провозглашенные как объектно-ориентированные, либо таковыми не являются, либо незрелы. Заявления об их будущей конкурентоспособности носят явно предположительный характер. Крупнейшие разработчики СУБД стали встраивать в свои продукты поддержку объектной ориентации, по соображениям совместимости предполагая смешанный подход – объектно-реляционный.

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

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

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

Несмотря на все вышесказанные недостатки реляционной модели данных, всё же она является наиболее современной на сегодняшний день. Поэтому, нет смысла использовать ранние модели ввиду их неконкурентоспособности по сравнению с реляционными, и нет смысла использовать системы, провозгласившие себя ОО, ввиду того, что под ними нет теоретической основы. Но и строить БД на основе чисто реляционной структуры было бы то же неуместно, ввиду её нереальности отображения семантики мира. Поэтому необходимо найти систему, которая основывалась на реляционном подходе и имела определённые разработки в объектно-ориентированных направлениях. При этом реляционный подход к организации БД должен быть наиболее популярным. И такой подход уже давно развит. Он основан на использовании техники B-деревьев. С точки зрения внешнего логического представления B-дерево - это сбалансированное сильно ветвистое дерево во внешней памяти. Сбалансированность означает, что длина пути от корня дерева к любому его листу одна и та же. Ветвистость дерева - это свойство каждого узла дерева ссылаться на большое число узлов-потомков. Поиск в B-дереве - это прохождение от корня к листу в соответствии с заданным значением ключа. Заметим, что поскольку деревья сильно ветвистые и сбалансированные, то для выполнения поиска по любому значению ключа потребуется одно и то же (и обычно небольшое) число обменов с внешней памятью. Более точно, в сбалансированном дереве, где длины всех путей от корня к листу одни и те же, если во внутренней странице помещается n ключей, то при хранении m записей требуется дерево глубиной где вычисляет логарифм m по основанию n. Если n достаточно велико (обычный случай), то глубина дерева невелика, и производится быстрый поиск. Основной «изюминкой» B-деревьев является автоматическое поддержание свойства сбалансированности.

Одной из систем удовлетворяющих выше поставленным условиям является СУБД Cache.



Скачать документ

Похожие документы:

  1. Сборник материалов vi международной научно-практической конференции «михоило-архангельские чтения» 17 ноября 2011 года г рыбница

    Документ
    Аверченков В.И., Шкаберин В.А. ОПЫТ И ПЕРСПЕКТИВНЫЕ НАПРАВЛЕНИЯ ИСПОЛЬЗОВАНИЯ ИНФОРМАЦИОННО-КОММУНИКАЦИОННЫХ ТЕХНОЛОГИЙ В НАУЧНО-ОБРАЗОВАТЕЛЬНОЙ ДЕЯТЕЛЬНОСТИ БРЯНСКОГО ГТУ
  2. Научный редактор рецензенты (1)

    Учебно-методическое пособие
    Раздел 3: п.3.1.-3.3, 3.5 - Гендина Н.И., Скипор И.Л.; п. 3.4. - Колкова Н.И.; Раздел 4: п. 4.1 - Гендина Н.И., Колкова Н.И., Скипор И.Л., Стародубова Г.
  3. Научный редактор рецензенты (2)

    Учебно-методическое пособие
    Раздел 3: п.3.1.-3.3, 3.5 - Гендина Н.И., Скипор И.Л.; п. 3.4. - Колкова Н.И.; Раздел 4: п. 4.1 - Гендина Н.И., Колкова Н.И., Скипор И.Л., Стародубова Г.
  4. Организация учебно-воспитательной работы в малокомплектной сельской школе

    Методические рекомендации
    КРАЕВОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ДОПОЛНИТЕЛЬНОГО ОБРАЗОВАНИЯ ВЗРОСЛЫХ «КАМЧАТСКИЙ ИНСТИТУТ ПОВЫШЕНИЯ КВАЛИФИКАЦИИ ПЕДАГОГИЧЕСКИХ КАДРОВ»
  5. -Мурза Советская цивилизация (том II) Оглавление

    Документ
    После победы в Великой Отечественной войне и капитуляции Японии 3 сентября 1945 г. начался совершенно новый период в жизни советского государства. Он оказался самым трудным и завершился уничтожением как СССР и его государственной
  6. -Мурза Советская цивилизация (том II) Оглавление

    Документ
    После победы в Великой Отечественной войне и капитуляции Японии 3 сентября 1945 г. начался совершенно новый период в жизни советского государства. Он оказался самым трудным и завершился уничтожением как СССР и его государственной

Другие похожие документы..