СОДЕРЖАНИЕ
ВВЕДЕНИЕ. 3
1. СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ.. 4
1.1. Системы управления базами данных. 4
1.2. Настольные (локальные) СУБД.. 5
1.3. СУБД структуры «сервер-клиент». 7
2. БАЗА ДАННЫХ MSACCESS. 17
2.1. Microsoft Access - функционально полная реляционная СУБД.. 17
2.2. Предназначение СУБД Access. 18
ЗАКЛЮЧЕНИЕ. 35
СПИСОК ЛИТЕРАТУРЫ.. 37
Базы данных (БД)составляют в настоящее время основу компьютерного обеспечения информационных процессов, входящих практически во все сферы человеческой деятельности.
Действительно, процессы обработки информации имеют общую природу и опираются на описание фрагментов реальности, выраженное в виде совокупности взаимосвязанных данных. Базы данных являются эффективным средством представления структур данных и манипулирования ими. Концепция баз данных предполагает использование интегрированных средств хранения информации, позволяющих обеспечить централизованное управление данными и обслуживание ими многих пользователей. При этом БД должна поддерживаться в среде ЭВМ единым программным обеспечением, называемым системой управления базами данных (СУБД). СУБД вместе с прикладными программами называют банком данных.
Одно из основных назначений СУБД – поддержка программными средствами представления, соответствующего реальности.
Предметной областью называется фрагмент реальности, который описывается или моделируется с помощью БД и ее приложений. В предметной области выделяются информационные объекты – идентифицируемые объекты реального мира, процессы, системы, понятия и т.д., сведения о которых хранятся в БД.
В мире существует множество систем управления базами данных. Несмотря на то, что они могут по-разному работать с разными объектами и предоставляют пользователю различные функции и средства, большинство СУБД опираются на единый устоявшийся комплекс основных понятий. В качестве такого объекта мы выберем СУБД MicrosoftAccess, входящую в пакет MicrosoftOffice.
Для взаимодействия пользователя с БД используеся системы управления базами данных (СУБД), которые обеспечивают:
- набор средств для поддержки таблиц и соотношений между ними;
- развитый пользовательский интерфейс, позволяющий вводить и модифицировать информацию, производить поиск и представлять результаты;
- средства программирования высокого уровня, позволяющие создавать собственные приложения.
Подход к постоению СУБД значительно видоизменялся на протяжении почти 40 лет. На смену ВЦ предприятия и АСУП на их основе пришли персональные компьютеры и настольные (персональные) системы управления базами данных, затем с развитием коммуникаций появились распределенные системы и концепции управления крупными предприятиями - корпорациями на основе бизнес-процессов.
При этом в условиях динамичного изменения бизнес-процессов в последние годы сформулировался ряд определенных требований к функциональным возможностям тех СУБД, производители которых стремятся поддерживать свои продукты на высоком, конкурентоспособном уровне.
1.Создаваемые средствами СУБД приложения должны обладать высокой степенью мобильности и легко переноситься на разные компьютерные и сетевые платформы.
2.Коммуникационный обмен данными становится асинхронным, а информационные процессы длительными, и поэтому возникает необходимость журнализации состояния баз данных и проведения возможного отката/восстановления для расширенных временных рамок (дни, недели).
3.Средства СУБД должны допускать возможность гибкого варьирования архитектуры различных ИС для соблюдения разумного компромисса при разделении функциональных возможностей системы между рабочими станциями клиентов и серверами.
4.Создание "менеджеров процессов" может быть эффективным только в таких условиях, когда средства программирования СУБД объектно-ориентированы и возможно создание стабильных приложений при динамичном изменении маршрутизации сквозь эти задачи.
5.Производителям СУБД следует обеспечить соответствие поставляемых ими продуктов открытым стандартам взаимодействия.
6.Расширение бизнес-процессов за пределы одной компании и необходимость создания глобальных информационных связей выдвигает серьезную задачу поддержки высокой степени готовности систем, работающих 24 часа в сутки все 365 дней в году.
Перечисленные требований к СУБД как к интегрирующим звеньям информационных систем новой архитектуры позволяют взглянуть на существующие ныне на рынке продукты разных производителей под соответствующим углом зрения. Адекватность предлагаемых сегодня СУБД новым требованиям определит для их будущих владельцев и клиентов преимущества создаваемых ИС, их гибкость, мобильность, возможность легкой перестройки и, в конечном счете, способность к выживанию.
Важным этапом в развитии настольных систем управления базами данных стали СУБД dBASEIII и dBASEIIIPLUS фирмы AshtonTate (Ребус в отечественном варианте), которые по существу стали стандартом для программных продуктов данного класса. После версии "третья с плюсом" разрабатывался проект dBASE IV, результатом которого стал пакет-монстр, трудный в освоении и малоэффективный, что привело фирму к краху.
Фирма Fox Software начинала с FохBase. Поначалу этот продукт мало отличался от dBASE: он лишь значительно быстрее работал и имел ряд полезных функций, которых у dBASE не было (русская "пиратская" версия FoxBase называлась "Карат-М"). Потом появился FoxPro - этот продукт оказался достаточно мощным, и очень многие программисты перешли на него. В последствии этот продукт купила MicroSoft и выпустила свою версию FoxPro 2.5, затем превратив его в визуальный объектно-ориентированный продукт VisualFoxPro 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: MSAccess из состава Office 95 и 97, Paradox 7.0 из состава CorelOffice 97, Approach из состава Lotus SmartSuite 97.
Построение распределенных систем имеет важное значение, особенно в условиях бессистемного оснащения предприятия компьютерной техникой, когда многие уже, как правило, работают (или им необходимо работать) с системами, состоящими из множества компьютеров разного типа (серверов, мини-компьютеров, больших машин).
Централизованное хранение данных и доступ к центральной БД в условиях географически распределенной системы приводят к необходимости установления соединений между центральным сервером, хранящим данные, и компьютерами-клиентами. Большинство компьютеров-клиентов отделены от центрального сервера медленными и недостаточно надежными линиями связи, и работа в режиме удаленного клиента становится почти невозможной. Этим можно объяснить существующую ситуацию, когда в узлах распределенной системы функционируют группы автоматизированных рабочих мест (АРМ), абсолютно не связанные друг с другом.
Содержательная сторона задачи обычно требует обмена данными между группами АРМ, так как изменения в какие-либо данные могут вноситься в одной группе, а использоваться они могут в другой. На практике обмен информацией реализуется регламентной передачей файлов - через модемное соединение или «с курьером».
То, что данные доставляются к месту назначения не системными средствами, а путем экспорта/импорта файлов, приводит к необходимости участия человека в процессе обмена, а это влечет за собой малую оперативность поступления данных и необходимость реализации внешних механизмов контроля целостности и непротиворечивости. В результате возрастает вероятность появления ошибок. Кроме того, реализация всех алгоритмов обмена данными и контроля в этом случае возлагается на прикладных программистов, проектирующих АРМ. Объем работ по программированию и отладке подпрограмм обмена соответствует числу различных АРМ. Это также приводит к повышению вероятности сбоев в системе.