Информационные технологии в экономике 2 (стр. 12 из 46)

В Access можно создать три типа меню:

1. Menu Bar. Обычное меню, которое может располагаться вверху формы и иметь выпадающие подменю.

2. Tool Bars. Группы пиктограмм, обычно располагающиеся под меню.

3. Shortcut Bar. Меню, всплывающие после щелчка правой кнопки мыши.

Visual Basic for Application

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

В предыдущих версиях Access имела собственный язык Basic, называемый Access Basic. В последних версиях Access он заменен языком Visual Basic for Applications (VBA) компании Microsoft. Несмотря на некоторую схожесть, между этими языками есть существенные различия. VBA становится общим языком для всех приложений Microsoft Office. VBA является современным языком структурного программирования. Находясь в окне модулей, можно создавать и редактировать код VBA и процедуры.Visual Basic для приложений играет важную роль при разработке баз данных Access. С помощью VBA можно настроить формы и отчеты, запустить макросы, а также отобразить объект Access в других приложениях или извлечь данные. Используя Visual Basic для приложений, можно вывести формы и отчеты, выполнить методы объектов, а также создать и изменить элементы. Кроме того, имеется возможность работать с информацией непосредственно: можно создать наборы данных, задать их параметры и изменить информацию в них.

3.4 Реляционные базы данных

В реляционных базах данных (Relational Database System, RDBS) все данные отображаются в двумерных таблицах. Реляционная база данных, таким образом, является набором таблиц.

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

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

RDBS и ориентированные на записи системы организованы на основе стандарта B-Tree или методе доступа, основанном на индексации – Indexed Sequential Access Method (ISAM) и являются стандартными системами, использующимися в большинстве современных программных продуктов. Для обеспечения комбинирования таблиц для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel (Ingres) и RDO

(Digital Equipment), причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных СУБД.

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

Строки таблицы составлены из полей, заранее известных базе данных. В большинстве систем нельзя добавлять новые типы данных. Каждая строка в таблице соответствует одной записи. Положение данной строки может изменяться вместе с удалением или вставкой новых строк. Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле или поля называются первичным ключом (primary key) таблицы и часто являются числами. Если одна таблица содержит первичным ключ другой, это позволяет организовать связь между элементами разных таблиц. Это поле называется внешним ключом (foreign key).

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

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

- требуют большего объема внешней памяти по сравнению с другими моделями;

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

разделение таблиц разными программами; полная независимость данных. При изменении структуры реляционной базы данных изменения, которые требуется произвести в прикладных программах, минимальны;

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

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

для построения запросов и написания прикладных программ нет необходимости знания конкретной организации БД во внешней памяти;

развернутый ―код возврата‖ при ошибках; высокая скорость обработки запросов (команда SELECT языка SQL; результатом выборки является таблица, которая содержит поля, удовлетворяющие заданному критерию).

3.5 Объектно-реляционные методы

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

Некоторые объектные СУБД, например GemStone компании GemStone Systems, могут сами выполнять роль мощного объектно-реляционного адаптера, позволяя объектноориентированным приложениям обращаться к реляционным БД.

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

Производительность в рассмотренных двух подходах зависит от способа доступа к реляционной базе данных. Каждая РСУБД состоит из двух уровней: уровня управления данными (data manager layer) и уровня управления носителем (storage manager layer). Первый из них обрабатывает операторы на языке SQL, а второй отображает данные в базу. Шлюз или адаптер могут взаимодействовать как с уровнем данных (то есть обращаться к РСУБД при помощи SQL), так и с уровнем носителя (вызовами процедур низкого уровня). Производительность в первом случае намного ниже (например, система OpenODB фирмы Hewlett-Packard, которая может выполнять роль шлюза, поддерживает только на высоком уровне).

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

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