СОДЕРЖАНИЕ

ВВЕДЕНИЕ 3

1. СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ 4

1.1. Системы управления базами данных 4

1.2. Настольные (локальные) СУБД 5

1.3. СУБД  структуры «сервер-клиент» 7

2. БАЗА ДАННЫХ MS ACCESS 17

2.1. Microsoft Access - функционально полная реляционная СУБД 17

2.2. Предназначение СУБД Access 18

ЗАКЛЮЧЕНИЕ 35

СПИСОК ЛИТЕРАТУРЫ 37

ВВЕДЕНИЕ

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

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

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

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

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

1. СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

1.1. Системы управления базами данных

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

- набор средств для поддержки таблиц и соотношений между ними;

- развитый пользовательский интерфейс,  позволяющий вводить и модифицировать информацию, производить поиск и представлять результаты;

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

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

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

1.Создаваемые средствами СУБД приложения должны обладать высокой степенью мобильности и легко переноситься на разные компьютерные и сетевые платформы.

2.Коммуникационный обмен данными становится асинхронным, а информационные процессы длительными, и поэтому возникает необходимость журнализации состояния баз данных и проведения возможного отката/восстановления для расширенных временных рамок (дни, недели).

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

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

5.Производителям СУБД следует обеспечить соответствие поставляемых ими продуктов открытым стандартам взаимодействия.

6.Расширение бизнес-процессов за пределы одной компании и необходимость создания глобальных информационных связей выдвигает серьезную задачу поддержки высокой степени готовности систем, работающих 24 часа в сутки все 365 дней в году.

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

1.2. Настольные (локальные) СУБД

Важным этапом в развитии настольных систем управления базами данных стали СУБД dBASE III и dBASE III PLUS фирмы Ashton Tate (Ребус в отечественном варианте), которые по существу стали стандартом для программных продуктов данного класса. После версии "третья с плюсом" разрабатывался проект dBASE IV, результатом которого стал пакет-монстр, трудный в освоении и малоэффективный, что привело фирму к краху.

Фирма Fox Software начинала с FохBase. Поначалу этот продукт мало отличался от dBASE: он лишь значительно быстрее работал и имел ряд полезных функций, которых у dBASE не было (русская "пиратская" версия FoxBase называлась "Карат-М"). Потом появился FoxPro - этот продукт оказался достаточно мощным, и очень многие программисты перешли на него. В последствии этот продукт купила MicroSoft и выпустила свою версию FoxPro 2.5, затем превратив его в визуальный объектно-ориентированный продукт Visual FoxPro 3.0. с последующим развитием.

Компания Nantucket производила компилятор Clipper. Пакет Clipper имел преимущество перед другими XBASE-продуктами по той простой причине, что позволял создавать исполняемые модули (ЕХЕ-файлы). Кроме того, у него было одно важное свойство, актуальное и по сей день: он позволял быстро и довольно простыми средствами создавать корпоративные программы средней сложности (АРМ "Кадры", "Финансы", "Библиотека" и пр.). Второе очевидное преимущество - простота освоения. В Clipper многие компоненты были уже готовы или собирались из кусочков за считанные минуты, для DOS по тем временам это было большое достижение. Недостатком являлось то,что у Clipper не было своей среды разработки. Программы набирались в каком-нибудь редакторе, а потом компилировались и запускались. Развивая его как язык программирования, фирма Nantucket намеревалась сделать из Clipper нечто, подобное языку Си++. Ориентация на объектно-ориентированный язык программирования привела к тому, что Clipper nepeстал быть самим собой. Пропала простота освоения, а требования к ресурсам неимоверно возросли. Проект потерпел неудачу, эту фирму купила компания Computer Associates и новый производитель выпустил Windows-вариант доработанного продукта под названием Visual Objects.

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

Современные настольные СУБД входят в состав интегрированных программных продуктов типа Office: MS Access из состава Office 95 и 97, Paradox 7.0 из состава Corel Office 97, Approach из состава Lotus SmartSuite 97.

1.3. СУБД структуры «сервер-клиент»

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

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

Содержательная сторона задачи обычно требует обмена данными между группами АРМ, так как изменения в какие-либо данные могут вноситься в одной группе, а использоваться они могут в другой. На практике обмен информацией реализуется регламентной передачей файлов - через модемное соединение или «с курьером».

То, что данные доставляются к месту назначения не системными средствами, а путем экспорта/импорта файлов, приводит к необходимости участия человека в процессе обмена, а это влечет за собой малую оперативность поступления данных и необходимость реализации внешних механизмов контроля целостности и непротиворечивости. В результате возрастает вероятность появления ошибок. Кроме того, реализация всех алгоритмов обмена данными и контроля в этом случае возлагается на прикладных программистов, проектирующих АРМ. Объем работ по программированию и отладке подпрограмм обмена соответствует числу различных АРМ. Это также приводит к повышению вероятности сбоев в системе.

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

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

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

Транзакция может вносить изменения (то есть добавлять, удалять и изменять записи) в одну или несколько таблиц базы данных. Выбранные для репликации таблицы специальным образом помечаются. Для каждой такой таблицы или группы ее строк, выбранной по заданному условию, определяется один узел (СУБД), в котором данные таблицы являются первичными. Это тот узел, в котором происходит наиболее активное обновление данных. Репликационному серверу, обслуживающему БД с первичными данными, задается описание тиражирования (replication definition). В этом описании, к примеру, могут быть заданы интервалы значений первичного ключа таблицы или какое-нибудь другое условие, при выполнении которого измененные данные будут тиражироваться из этого узла к подписчикам. Если условие не задано, то описание тиражирования действует для всех записей таблицы. Возможность тиражирования группы записей таблицы означает, в частности, что часть записей может быть первичными данными в каком- то одном узле, а еще часть - в других узлах. В одном или нескольких узлах (СУБД), которым нужны измененные данные, в обслуживающем его репликационном сервере создается подписка (subscription) на соответствующее описание тиражирования. Здесь будет поддерживаться (с небольшой задержкой) копия первичных данных.

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

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