бесплатно рефераты скачать
  RSS    

Меню

Быстрый поиск

бесплатно рефераты скачать

бесплатно рефераты скачатьРеферат: База данных MS Access

Реферат: База данных MS Access

СОДЕРЖАНИЕ

ВВЕДЕНИЕ. 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) на соответствующее описание тиражирования. Здесь будет поддерживаться (с небольшой задержкой) копия первичных данных.

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

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

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

СУБД, хранящая вторичные данные, может быть любой из ряда доступных через шлюз: будь то Oracle, Informix, DB2, RMS, ISAM и т.п.. СУБД, хранящая первичные данные, требует наличия менеджера журнала транзакций (Log Transfer Manager - LTM). Сейчас разработаны LTM для Sybase SQL Server и Oracle; на очереди другие СУБД. Интерфейс LTM является открытым, и в скором времени, возможно, подобные модули будут созданы для нестандартных источников данных.

Вообще, тиражирование данных может найти самое разнообразное применение:

- для разгрузки сервера, выполняющего активное обновление данных (OLTP) от сложных запросов, связанных с поддержкой принятия решений (decision-support);

- для консолидации данных от подразделений в центре;

- для обмена данными по медленным или ненадежным линиям связи;

- для поддержания резервной базы данных;

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

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

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

Исторически первым появился метод синхронного внесения изменений в несколько БД, называемый двухфазной фиксацией (2РС, two- phase commit). Этот механизм реализован сейчас практически всеми производителями СУБД. Суть метода двухфазной фиксации состоит в том, что при завершении транзакции серверы БД, участвующие в ней, получают команду «приготовиться к фиксации транзакции». После получения подтверждений от всех серверов транзакция фиксируется на кадом из них. Таким образом, в любой момент времени обеспечивается целостность данных в распределенной системе. Платой за это являются требование доступности всех участвующих серверов и линий связи во время проведения транзакции, а также невозможность работы приложений-клиентов при недоступности, например, удаленного сервера. Кроме того, необходимо высокое быстродействие линий связи для обеспечения приемлемого времени реакции у приложения-клиента.

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

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

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

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

Страницы: 1, 2, 3


Новости

Быстрый поиск

Группа вКонтакте: новости

Пока нет

Новости в Twitter и Facebook

  бесплатно рефераты скачать              бесплатно рефераты скачать

Новости

бесплатно рефераты скачать

© 2010.