Государственный университет – Высшая школа экономики Пермский филиал
Л.Н. Лядова, л.Н. Ланин Основы субд Access Учебно-методическое пособие по курсу «Базы данных»
Пермь 2009
УДК 004.65 ББК Л97 Лядова Л.Н., Ланин В.В. Л 97 Основы СУБД Access: учеб.-метод. пособие / Л.Н. Лядова; Пермский филиал ГУ‑ВШЭ. – Пермь, 2009. – 100 с.: ил.
ISBN
Рассматриваются основные понятия, используемые при работе с базами данных, а также общий подход к проектированию реляционных баз данных. Описываются средства создания баз данных СУБД Microsoft Access: средства создания таблиц, форм, запросов и отчетов. Приведен пример создания базы данных и работы с ней. Рассматриваются технологии доступа к источникам данных и методы доступа к данным из приложений MS Office. Описываются особенности разработки приложений на основе средств MS Office, преимущества и недостатки использования раннего и позднего связывания в программах на VBA. Кратко описываются средства автоматизации приложений MS Office (команда слияния, макросы). В пособие включены лабораторные работы и задания для самостоятельного выполнения.
Предназначено для преподавателей и студентов, изучающих информационные технологии, в частности, средства разработки баз данных.
УДК 004.65 ББК
ISBN © Пермский филиал ГУ‑ВШЭ, 2009 © Л.Н. Лядова, 2009
Глава 1.Основы субд access
Система управления базами данных (СУБД) Access является одной из наиболее мощных реляционных систем управления базами данных настольного типа.
Рассмотрим основные этапы разработки базы данных (БД) на примере БД, содержащей информацию о местах работы сотрудников, которые (кроме основного места работы) могут работать по совместительству в других местах.
1.1.Основные понятия
База данных (БД) – это именованная совокупность взаимосвязанных данных, отражающая состояние объектов рассматриваемой предметной области и их отношений. БД могут использоваться несколькими приложениями под управлением системы управления базой данных (СУБД).
При работе с информацией различают два уровня представления данных. Физические данные – это данные, хранящиеся в памяти ЭВМ, на ее запоминающих устройствах. Для долговременного хранения больших объемов данных используется вторичная память (внешние запоминающие устройства – ВЗУ). Логическое представление данных соответствует Пользовательскому представлению о данных. Логическое представление отражает существующие взаимосвязи между элементами данных.
В обычном смысле БД представляет собой файл или множество файлов, имеющих определенную организацию. Однако при работе с обычными системами файловой обработки возникает ряд проблем, связанных, в частности, с избыточностью и зависимостью хранящихся в них данных.
Для решения конкретных задач, связанных с организацией хранения и обработки информации, в каждом приложении (прикладной программе), соответствующем задаче, определяются формат, организация и содержимое файлов данных, используемых для хранения информации. В файлах каждой прикладной системы содержится только необходимая ей информация, но часть данных может быть общей для нескольких приложений и эти данные дублируются в нескольких файлах. Согласование между наборами данных различных приложений при реализации такого подхода к разработке систем обработки данных отсутствует. Таким образом, использование автономных систем файловой обработки вследствие дублирования данных в них часто приводит, во-первых, к значительной избыточности данных, а во-вторых – существует опасность возникновения несоответствия данных, находящихся в файлах, с которыми работают различные приложения, нарушения их целостности.
Решение данной проблемы требует выполнения ряда шагов:
объединение файловых систем всех приложений в единую базу данных, в которой будет содержаться только одна копия каждого логического элемента данных, поэтому избыточность будет исключена;
согласование работы различных приложений с базой данных через использование общей управляющей программы, которая организовывала бы доступ всех приложений к информации в БД;
отделение логической структуры данных (организации данных с точки зрения пользователя) от физической (организации данных с точки зрения их представления на ВЗУ).
Необходимость решения этой задачи привела к возникновению нескольких уровней представления информации, для работы с которой было разработано специальное программное обеспечение.
При решении этих задач можно описать хранимую и обрабатываемую информацию с различных точек зрения и с разной степенью детализации. Выделяется три основных уровня представления:
Внешний уровень – уровень описания информационных потребностей конечного пользователя.
Концептуальный уровень – описание информации на уровне понятий всей информационной системы.
Внутренний уровень – описание способа хранения информации в памяти, на внешних запоминающих устройствах и методов доступа к ней.
Информационные потребности отдельного пользователя обычно затрагивают лишь часть данных, хранящихся в информационной системе, и описание этих потребностей может не совпадать со способом представления этих данных. Например: в базе данных информационной системы предприятия хранится информация обо всех его сотрудниках, но представление о том, какая именно информация необходима для работы, будет разным для разных групп пользователей, специалистов в различных областях – оно зависит от выполняемых ими обязанностей (специалист отдела кадров и сотрудники бухгалтерии, руководитель подразделения и т.д. нуждаются для выполнения своих функций в различных данных). Эти потребности и описываются на внешнем уровне представления данных (представления А, В, и С, рис. 1).
Внешних описаний данных, хранящихся в БД, следовательно, может быть множество.
Правила описания данных определяются выбранной моделью данных (основными являются реляционная модель данных, сетевая и иерархическая модели; широко распространен объектно-ориентированный подход).
Описание данных для конкретной информационной системы называется схемой. Данные требуется описывать на различных уровнях абстрагирования, описание каждого уровня представляет собой соответствующую схему.
Схема – это средство, с помощью которого описывается модель данных приложения. Модель данных состоит из трех компонентов:
структура данных, представляющая точку зрения пользователя на БД;
допустимые операции, выполняемые на определенной структуре данных;
ограничения для контроля целостности данных.
Таким образом, в схеме присутствует и некоторая семантическая (смысловая) информация, относящаяся к приложению.
С помощью схемы описываются свойства и взаимосвязи между отдельными элементами данных, вытекающие из существующих связей в «реальном мире» предметной области.
Схемы соответствуют уровням описания данных, т.е. рассматриваются внешние схемы, концептуальная и внутренняя схемы. Описания (схемы) используются в процессе проектирования БД информационных систем. Кроме описания БД как единого целого на уровне абстракции концептуальной схемы часто требуются ее описания с различных точек зрения. Каждое такое описание можно считать частичным или переопределенным описанием БД. Эти описания являются внешними схемами или подсхемами.
Система управления базой данных (СУБД) – это программная система, обеспечивающая определение логической и физической структуры базы данных, ввод информации и доступ к ней. При этом все СУБД обеспечивают независимость прикладной программы от организации физических данных: изменения физической организации и/или параметров запоминающих устройств воспринимаются и «перехватываются» СУБД, но не влияют на прикладную программу. С другой стороны, изменение пользовательского представления и/или добавление нового представления также поддерживаются СУБД и не требуют затрат на реорганизацию и изменение механизма доступа к физическим данным в файлах. Еще одна задача СУБД – поддержание целостности данных, хранящихся в БД.
База данных – это файл или совокупность файлов, для определения которых и обращения к ним используются средства СУБД. Это означает, что БД определяется посредством схемы, не зависящей от программ, которые к этой БД обращаются.
Другим свойством БД является реализация их в виде «запоминающего устройства» с прямым доступом. Использование СУБД обеспечивает лучшее управление данными, более совершенную организация файлов и более простое обращение к ним по сравнению с обычным способом хранения данных в файлах.
Целостность БД означает поддержание данных в ней в таком состоянии, когда все значения данных «правильны» (отражают состояние реального объекта в пределах заданных ограничений по точности и временнόй согласованности) и подчиняются правилам взаимной непротиворечивости. Поддержание целостности включает проверку целостности данных в БД и восстановление БД из любого неправильного состояния, которое может быть обнаружено в процессе проверки.
Все СУБД ориентированы на хранение и обработку информации, но существуют различные подходы к реализации этой задачи.
Реляционный подход к управлению БД основан на математической модели, использующей методы реляционной алгебры и реляционного исчисления. При использовании этого подхода основными свойствами СУБД являются следующие:
вся информация в БД представлена в виде таблиц;
поддерживается три реляционных оператора – выбора, проектирования и объединения, с помощью которых можно получить все необходимые данные.
Определение реляционной модели включает ряд фундаментальных правил.
Каждая таблица поименована, состоит из строк и столбцов. Каждая строка описывает объект или сущность. Каждый столбец описывает одну характеристику (атрибут) объекта, его свойство.
Атрибут – это информационное отображение отдельного свойства некоторого объекта. Атрибут характеризуется именем и значением. Имя используется в качестве условного обозначения при обработке данных. Значение атрибута – это величина, характеризующая некоторое свойство объекта при конкретных обстоятельствах. Каждое значение принадлежит определенному типу (число, текст и т.п.).
Отношение (relation), или таблица, определяется как множество упорядоченных строк (хотя упорядочение строк несущественно, оно может повлиять только на эффективность доступа). Реляционные таблицы выражают отношение и состоят из строк и столбцов, удовлетворяющих следующим условиям: имена столбцов уникальны, нет повторяющихся строк, нет повторяющихся групп данных.
Отношение называется нормализованным, если каждый компонент строки является простым (атомарным, не состоящим из группы значений) значением. Это не позволяет заменять значение атрибута другим отношением (это привело бы к сетевому или иерархическому представлению).
Для создания реляционной БД, в которой хранилась бы описанная выше информация, необходимо выполнить ее проектирование, целью которого является определение структуры БД в соответствии с требованиями, предъявляемыми к реляционным БД. Этот процесс очень важен, так как ошибки в проектировании могут привести не только к неэффективной обработке данных, хранящихся в БД, но и к искажению данных, к нарушению их целостности. Более подробно процесс проектирования описан ниже.
В отношении могут существовать несколько одиночных или составных атрибутов, которые однозначно идентифицируют каждую строку таблицы. Такие атрибуты называют ключами. Один из них выбирается в качестве первичного ключа.
Каждый элемент данных (значение атрибута объекта) определяется пересечением строки и столбца. Чтобы найти нужный элемент нужно указать имя содержащей его таблицы, значение первичного ключа строки (или ее уникального идентификатора) и столбец, содержащий этот атрибут.
Для упорядочения записей в таблице по значениям выбранного поля или нескольких полей используются индексы, добавляемые к таблицам. Каждой таблице может соответствовать несколько индексов, позволяющих выполнять быстрый поиск данных (используется специальный алгоритм быстрого поиска, например – двоичный поиск) в таблице по различным ключам. Фактически данные в таблице хранятся в неупорядоченном виде (в порядке записи), а упорядоченными являются только индексы.
Данные, хранящиеся в различных таблицах, взаимосвязаны. Поэтому при создании БД в ней размещаются не только сами таблицы, но и сохраняются существующие между ними связи (отношения). Создавать и запоминать связи в БД необязательно, но их использование гарантирует получение правильных результатов при выполнении сложных запросов.
Существуют различные типы отношений:
Один-ко-многим (1:N): единственной записи в первой таблице может соответствовать несколько записей во второй таблице (например: если в первой таблице хранится информация об издательствах, а во второй – о выпущенных ими книгах, то, так как каждое издательство может выпустить множество книг, между этими данными существует отношение 1:N );
Многие-ко-многим (N:N): записям в первой таблице может соответствовать несколько записей во второй и наоборот – каждой записи из второй таблицы может соответствовать множество записей в первой таблице (например: если в одной таблице хранится информация об авторах книг, а в другой – информация о книгах, то, так как каждый автор может написать несколько книг, а у каждой книги может быть несколько авторов, между этими таблицами существует связь N:N);
Один-к-одному (1:1): каждой записи в одной таблице соответствует одна запись во второй (эти данные могли бы размещаться в одной таблице, такие данные размещают в различных таблицах обычно только для того, чтобы ускорить доступ к ним, например: редко используемые при запросах данные можно вынести в отдельную таблицу, чтобы не обрабатывать их при выполнении каждого запроса).
Реализовать отношение «один-ко-многим» можно, добавив во вторую таблицу внешний ключ, идентифицирующий соответствующую строку в первой таблице. Это обеспечивает минимальную избыточность данных. Внешний ключ – это столбец или комбинация столбцов в таблице, значение которого(ых) совпадает со значением первичного ключа в другой таблице.
Для описания отношения «многие-ко-многим» в БД строится отдельная таблица, описывающая связи между первой и второй таблицами. Вместо объектов такая таблица описывает связи между ними. Она содержит в каждой записи внешние ключи, идентифицирующие взаимосвязанные записи в исходных таблицах.
Таким образом, в реляционных БД есть два типа таблиц: пользовательские (они содержат собственно информацию) и системные (содержат описание самой БД, служебную информацию). Системные таблицы обычно поддерживаются самой СУБД.
Данные объединяются в БД с целью адекватного отображения изменяющегося реального мира, поэтому кроме собственно данных в БД могут храниться специальные процедуры, описывающие алгоритмы функционирования соответствующих объектов. Использование таких процедур позволяет «активизировать» БД, заставить выполняться описанные в них действия автоматически при изменении состояния объектов, которым они приписаны, контролировать изменения информации.
Процесс, в ходе которого решается, какой будет структура создаваемой БД, называется проектированием. Эта работа включает определение набора таблиц, которые будут входить в БД; столбцов, принадлежащих каждой таблице; ключевых атрибутов индексов; взаимосвязей между таблицами и столбцами.
При работе с БД в данных может возникнуть несогласованность по ряду причин: вследствие сбоя, ошибки в программе, некорректного проектирования и т.п. В этом случае говорят о нарушении целостности данных. Данные должны быть защищены от такого рода разрушений. Целостность в первую очередь обеспечивается при проектировании БД. Хорошая структура БД максимально упрощает взаимодействие с ней, гарантирует согласованность данных.
При проектировании БД могут быть приняты различные решения, но существуют базовые требования, которые должны учитываться в процессе работы:
множество отношений должно обеспечивать минимальную избыточность представления информации;
манипулирование данными, корректировка отношений не должна приводить к нарушению целостности данных, двусмысленности и потере информации;
перестройка набора отношений при добавлении в БД новых атрибутов должна быть минимальной.
Описание реальных объектов и взаимосвязей между ними во многом носит субъективный характер, но есть определенные общие правила, в частности, правила нормализации.
В ходе нормализации обеспечивается защита целостности данных путем устранения дублирования данных. В результате представление данных об одном объекте может быть разбито на несколько более мелких связанных таблиц (декомпозиция без потерь).
Ограничения, которые должны соблюдаться при проектировании реляционной БД, достаточно многочисленны. Соблюдение ограничений при определении конкретных отношений в БД связано с реализацией так называемых нормальных форм. Нормальные формы нумеруются последовательно, начиная от первой. Чем больше номер нормальной формы, тем больше ограничений на хранимые в БД данные должно соблюдаться. Можно к типичным для реляционных СУБД ограничениям ввести дополнительный набор ограничений, что приведет к увеличению числа нормальных форм.
Нормальная форма представляет собой определенный стандарт. Обычно рассматривают до пяти нормальных форм. Так как каждая следующая нормальная форма предусматривает дополнительные ограничения, нормализация выполняется в порядке возрастания этих требований – от первой нормальной формы и до пятой.