Методика преподавания баз данных в школе учитель информатики (стр. 2 из 10)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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