|
Читайте также: |
Введение
Microsoft Access обладает всеми чертами классической системы управления базами данных (СУБД). Access – это не только мощная, гибкая и простая в использовании СУБД, но и система для разработки приложений баз данных. К числу наиболее мощных средств Access относятся средства разработки объектов – мастера, которые можно использовать для создания таблиц, запросов, различных типов форм и отчетов. В Microsoft Access включены мастера, помогающие производить анализ структуры данных, импортировать электронные таблицы и текстовые данные, повышать быстродействие приложения, создавать и настраивать одно из более, чем двадцати типов приложений с использованием встроенных шаблонов. Чтобы полностью автоматизировать работу приложения, можно использовать макросы для связывания данных с формами и отчетами. Большинство приложений можно создать, не написав ни единой строки программного кода. Однако при необходимости построения действительно сложного приложения можно использовать язык программирования – Visual Basic для приложений.
К областям применения Microsoft Access можно отнести следующие:
Рассмотрим основные определения, связанные с разработкой баз данных. Краткий словарь терминов приведен в приложении 1.
База данных (БД, data base, DB) – совокупность взаимосвязанных данных, используемых под управлением СУБД.
В самом общем смысле база данных – это набор записей и файлов, организованных специальным образом.
Система управления базой данных (СУБД, DBMS) – программная система, обеспечивающая определение физической и логической структуры базы данных, ввод информации и доступ к ней.
Возможности СУБД: система управления базами данных предоставляет возможность контролировать задание структуры и описание данных, работу с ними и организацию коллективного пользования информацией. СУБД также существенно увеличивает возможности и облегчает каталогизацию и ведение больших объемов хранящейся в многочисленных таблицах информации. СУБД включает в себя три основных типа функций: определение (задание структуры и описание) данных, обработки данных и управление данными.
Основные функции СУБД следующие:
Определение данных. Определяется, какая именно информация будет храниться в базе данных, задается структура данных и их тип (например, количество цифр или символов), а также указывается то, как данные будут связаны между собой. Задаются форматы и критерии проверки данных.
Обработка данных. Данные можно обрабатывать самыми различными способами. Можно выбирать любые поля, фильтровать и сортировать данные. Можно объединять данные с другой связанной информацией и вычислять итоговые значения.
Управление данными. Указываются правила доступа к данным, их корректировки и добавления новой информации. Можно также определить правила коллективного пользования данными.
Модели организации баз данных
1. Иерархический подход к организации баз данных. Иерархические базы данных имеют форму деревьев с дугами-связями и узлами-элементами данных. Иерархическая структура предполагала неравноправие между данными – одни жестко подчинены другим. Подобные структуры, безусловно, четко удовлетворяют требованиям многих, но далеко не всех реальных задач.
2. Сетевая модель данных. В сетевых БД наряду с вертикальными реализованы и горизонтальные связи. Однако унаследованы многие недостатки иерархической и главный из них, необходимость четко определять на физическом уровне связи данных и столь же четко следовать этой структуре связей при запросах к базе.
3. Реляционная модель. Реляционная модель появилась вследствие стремления сделать базу данных как можно более гибкой. Данная модель предоставила простой и эффективный механизм поддержания связей данных.
Во-первых, все данные в модели представляются в виде таблиц и только таблиц. Реляционная модель – единственная из всех обеспечивает единообразие представления данных. И сущности, и связи этих самых сущностей представляются в модели совершенно одинаково – таблицами. Правда, такой подход усложняет понимание смысла хранящейся в базе данных информации, и, как следствие, манипулирование этой информацией.
Избежать трудностей манипулирования позволяет второй элемент модели – реляционно-полный язык (отметим, что язык является неотъемлемой частью любой модели данных, без него модель не существует). Полнота языка в приложении к реляционной модели означает, что он должен выполнять любую операцию реляционной алгебры или реляционного исчисления (полнота последних доказана математически Э.Ф. Коддом). Более того, язык должен описывать любой запрос в виде операций с таблицами, а не с их строками. Одним из таких языков является SQL.
Третий элемент реляционной модели требует от реляционной модели поддержания некоторых ограничений целостности. Одно из таких ограничений утверждает, что каждая строка в таблице должна иметь некий уникальный идентификатор, называемый первичным ключом. Второе ограничение накладывается на целостность ссылок между таблицами. Оно утверждает, что атрибуты таблицы, ссылающиеся на первичные ключи других таблиц, должны иметь одно из значений этих первичных ключей.
4. Объектно-ориентированная модель. Новые области использования вычислительной техники, такие как научные исследования, автоматизированное проектирование и автоматизация учреждений, потребовали от баз данных способности хранить и обрабатывать новые объекты – текст, аудио- и видеоинформацию, а также документы. Основные трудности объектно-ориентированного моделирования данных проистекают из того, что такого развитого математического аппарата, на который могла бы опираться общая объектно-ориентированная модель данных, не существует. В большой степени поэтому до сих пор нет базовой объектно-ориентированной модели. С другой стороны, некоторые авторы утверждают, что общая объектно-ориентированная модель данных в классическом смысле и не может быть определена по причине непригодности классического понятия модели данных к парадигме объектной ориентированности. Несмотря на преимущества объектно-ориентированных систем – реализация сложных типов данных, связь с языками программирования и т.п. – на ближайшее время превосходство реляционных СУБД гарантировано.
Основные этапы разработки приложения
Основы методологии проектирования прикладных программ были заложены в 60-е годы XX века известными специалистами Дж. Мартином, Э. Йордоном и Д. Константайном. На заре применения вычислительной техники разработка программ, поиск и устранение ошибок были настолько дорогостоящими, что опытные программисты-практики часто советовали: прежде чем написать хоть одну строку программы, стоит потратить не менее 60% всего необходимого для разработки времени на проектирование.
Современные технологии разработки прикладных программ делают построение приложений фантастически дешевым и быстрым. Квалифицированный пользователь с помощью Microsoft Access сегодня может за один вечер создать на персональном компьютере то, что на ранних ЭВМ требовало месяцев работы (если это вообще было возможным). Кроме того, сейчас стало значительно легче находить ошибки, устранять их и видоизменять проект в процессе создания приложения. Современные технологии позволяют создавать очень сложные приложения. К тому же скорость вычислений по сравнению даже с предыдущим десятилетием возросла на несколько порядков. Однако несмотря на мощность средств, если вы не потратите значительных усилий на определение задач и принципов работы приложения, то впоследствии вам придется потерять значительно больше времени на всевозможные переделки. Если проект приложения недостаточно продуман, то добавление новых функций или устранение недостатков будет связано с большими временными и финансовыми затратами.
Рассмотрим основные этапы разработки приложения.
Этап 1. Уточнение задач
На первом этапе составляется список всех основных задач, которые в принципе должны решаться этим приложением, – включая и те, которые не нужны сегодня, но могут появиться в будущем. Под «основными» задачами понимаются функции, которые должны быть представлены в формах или отчетах приложения.
Этап 2. Последовательность выполнения задач
Для того, чтобы приложение работало логично и удобно, лучше всего объединить основные задачи в тематические группы и затем упорядочить задачи каждой группы так, чтобы они располагались в порядке их выполнения. Может получиться так, что некоторые задачи будут связаны с разными группами или, что выполнение некоторой задачи должно предшествовать выполнению другой, принадлежащей к иной группе.
Этап 3. Анализ данных
После формирования списка задач, наиболее важным этапом является составление подробного перечня всех данных, необходимых для решения каждой задачи. Некоторые данные понадобятся в качестве исходных и меняться не будут. Другие данные будут проверяться и изменяться в ходе выполнения задачи. Некоторые элементы данных могут быть удалены или добавлены. И наконец, некоторые данные будут получены с помощью вычислений: их вывод будет частью задачи, но в базу данных вноситься они не будут.
Этап 4. Определение структуры данных
После предварительного анализа всех необходимых элементов данных нужно упорядочить их по объектам и соотнести объекты с таблицами и запросами базы данных. Для реляционных баз данных типа Access используется процесс, называемый нормализацией, в результате которого вырабатывается наиболее эффективный и гибкий способ хранения данных.
Этап 5. Разработка макета приложения и пользовательского интерфейса
После задания структуры таблиц приложения, в Microsoft Access легко создать его макет с помощью форм и связать их между собой, используя несложные макросы или процедуры обработки событий. Предварительный рабочий макет легко продемонстрировать заказчику и получить его одобрение еще до детальной реализации задач приложения.
Этап 6. Создание приложения
В случае очень простых задач созданный макет является практически законченным приложением. Однако довольно часто приходится писать процедуры, позволяющие полностью автоматизировать решение всех намеченных в проекте задач. Поэтому, понадобится создать специальные связующие формы, которые обеспечивают переход от одной задачи к другой.
Этап 7. Тестирование и усовершенствование
После завершения работ по отдельным компонентам приложения необходимо проверить функционирование приложения в каждом из возможных режимов. Необходимо проверить работу макросов, использовав пошаговый режим отладки, при котором будет выполняться одна конкретная макрокоманда. При использовании Visual Basic для приложений в вашем распоряжении имеются разнообразные средства отладки, позволяющие проверить работу приложения, выявить и исправить ошибки.
По мере разработки автономных разделов приложения желательно передать их заказчику для проверки их функционирования и получения мнения о необходимости внесения тех или иных изменений. После того как заказчик ознакомится с работой приложения, у него практически всегда возникают дополнительные предложения по усовершенствованию, какой бы тщательной не была предварительная проработка проекта. Пользователи часто обнаруживают, что некоторые моменты, о которых в процессе постановки задач они говорили как об очень важных и необходимых, на самом деле не играют существенной роли при практическом использовании приложения. Выявление необходимых изменений на ранних стадиях разработки приложения позволяет существенно сократить время на последующие переделки.
Стратегия разработки приложения
При разработке приложений СУБД используются два подхода: проектирование сверху вниз, при котором разработка приложения начинается с определения основных функций и задач, и п роектирование снизу вверх, при котором сначала проводится анализ данных и определение их структуры.
Сначала определяются задачи и выполняется их группировка (подход «сверху вниз»). Так как базы данных должны привязываться к решению определенных, связанных между собой групп задач или функций, то для каждой задачи определяется набор необходимых данных. Затем для связанных задач собираются все поля данных и начинается процесс формирования объектов (элементы подхода «снизу вверх»). Данные каждого объекта являются основой для включения в базу данных отдельной таблицы.
Данные и информация
Понимание различия между данными и информацией облегчит выявление сведений, которые необходимо хранить в базе данных. Это различие состоит в том, что данные – это статические значения, хранящиеся в таблицах базы данных, в то время как информация – это сведения, которые запрашиваются пользователем и представляются ему в наиболее удобном виде. Другими словами, данные хранятся, а информация запрашивается. Отличие данных от информации надо учитывать при разработке проекта приложения. Сначала вы определяете задачи (какую информацию можно будет запрашивать и получать), а затем выясняете, что нужно хранить в базе данных для выполнения этих задач (какие данные нужны для получения и представления требуемой информации). Когда вы ссылаетесь на элементы, хранимые в таблицах, запросах, макросах или процедурах, или работаете с ними, вы имеете дело с данными. Аналогично, когда вы работаете с наборами записей запросов, фильтрами, формами или отчетами, вы имеете дело с информацией.
Отбор необходимых данных
После определения задач нужно составить для каждой из них описание данных, необходимых для ее решения. Каждый элемент данных, по характеру его использования, может быть классифицирован одним из следующих признаков: входной, выходной, изменяемый, удаляемый и вычисляемый.
Элемент данных является входным, если для выполнения задачи его необходимо прочитать в базе данных (без изменения). Например, имя и адрес клиента являются входными данными для заполнения заказа.
Подобным образом данные являются выходными для задачи, если в этой задаче они вводятся или вычисляются на основе входных данных, а затем сохраняются. Например, адрес и телефон нового студента являются выходными для задачи ввода данных о студентах.
Данные в задаче изменяются, если они читаются в базе данных, а затем изменяются и записываются обратно. Например, задача обновления адреса студента получает старый адрес студента, изменяет его и сохраняет в базе данных новый.
Соответственно, задача удаляет данные, когда они убираются из базы данных.
И наконец, вычисляемыми данными являются новые значения, получаемые на основе входных данных, которые отображаются на экране или печатаются, но не сохраняются в базе данных.
Нормализация
Для устранения дублирующихся данных используется процесс, называемый нормализацией. Он позволяет организовать поля данных в группы таблиц. Лежащая в основе нормализации математическая теория довольно сложна, но для практического применения ее можно сформулировать в виде довольно простых правил.
Правило 1. Уникальность полей
Неэффективное использование памяти является основным недостатком ненормализованных таблиц, поэтому удаление избыточных полей из таблиц является одним из решений этой проблемы.
Правило 1: Каждое поле любой таблицы должно быть уникальным.
Этого можно достичь созданием отдельных таблиц для повторяющихся данных и установлением связей между новыми таблицами и исходной. Хотя дублируются данные в связующем поле в каждой из таблиц, общий объем хранимых данных значительно сокращается.
Правило 2. Первичные ключи
База данных хорошо спроектирована тогда, когда каждая запись в любой таблице является уникальной. Это означает, что значение некоторого поля (или нескольких полей) не повторяется ни в одной записи в таблице. Такой идентификатор называется первичным ключом (или просто ключом).
Правило 2: Каждая таблица должна иметь уникальный идентификатор, или первичный ключ, который может состоять из одного или нескольких полей.
Если вы создаете таблицу в базе данных, то Access всегда предлагает определить для нее первичный ключ. Вы можете также предоставить Access возможность создать искусственный первичный ключ. В таком случае Access добавляет к каждой записи поле, в которое записывается содержимое счетчика записей. При добавлении новой записи содержимое счетчика увеличивается на единицу.
Правило 3. Функциональная зависимость
Если вы определили для каждой таблицы первичный ключ, то можно проверить, включены ли в таблицы все сведения, относящиеся к соответствующим объектам. Кроме того, следует убедиться, что каждое поле функционально зависит от первичного ключа таблицы.
Правило 3: Для каждого значения первичного ключа значения в столбцах данных должны относиться к объекту таблицы и полностью его описывать.
Это правило используется двояко. Во-первых, в таблице не должно быть данных, не относящихся к объекту, определяемому первичным ключом. Во-вторых, данные в таблице должны полностью описывать объект.
Правило 4. Независимость полей
И наконец, последнее правило позволяет проверить, не возникнут ли у вас проблемы при изменении данных в таблицах.
Правило 4: Изменение значений любого поля (не входящего в первичный ключ) должно выполняться без воздействия на данные других полей.
Чужие ключи
Если при создании новой таблицы в существующую таблицу включается поле, связывающее старую и новую таблицы, то это «связующее» поле называется чужим ключом или внешним ключом.
В хорошо спроектированной базе данных использование чужих ключей обеспечивает эффективность работы приложения. В процессе проектирования нужно внимательно следить за созданием чужих ключей. Задаваемые при создании таблиц в Microsoft Access связи первичных ключей с чужими ключами используются для объединения данных из нескольких таблиц.
Архитектура Microsoft Access
Microsoft Access называет объектами все, что может иметь имя (в смысле Access). В базе данных Access основными объектами являются таблицы, запросы, формы, отчеты, макросы и модули. В других СУБД, как правило, термин база данных обычно относится только к файлам, в которых хранятся данные. В Microsoft Access база данных включает в себя все объекты, связанные с хранимыми данными, в том числе и те, которые определяются для автоматизации работы с ними. Ниже приведен список основных объектов базы данных Access.
1. Таблица. Объект, который определяется и используется для хранения данных. Каждая таблица включает информацию об объекте определенного типа, например о клиентах. Таблица содержит поля (столбцы), в которых хранятся различного рода данные, например фамилия или адрес клиента, и записи (которые называются также строками ). В записи собрана вся информация о некотором объекте (человеке, образце продукции и т.п.). Для каждой таблицы можно определить первичный ключ (одно или несколько полей, содержащих уникальные для каждой записи значения) и один или несколько индексов, помогающих ускорить доступ к данным.
2. Запрос. Объект, который позволяет пользователю получить нужные данные из одной или нескольких таблиц. Для создания запроса можно использовать бланк QBE (запрос по образцу) или инструкции SQL (структурированный язык запросов). Можно создать запросы на выборку, обновление, удаление или добавление данных. С помощью запросов можно также создавать новые таблицы, используя данные из одной или нескольких существующих таблиц.
3. Форма. Объект, предназначенный в основном для ввода данных, отображения их на экране или управления работой приложения. Формы используются для того, чтобы реализовать требования пользователя к представлению данных из запросов или таблиц. Формы можно также распечатать. С помощью формы можно в ответ на некоторое событие, например изменение значения определенных данных, запустить макрос или процедуру VBA.
4. Отчет. Объект, предназначенный для создания документа, который впоследствии может быть распечатан или включен в документ другого приложения.
5. Макрос. Объект, представляющий собой структурированное описание одного или нескольких действий, которые должен выполнить Access в ответ на определенное событие. Например, можно определить макрос, который в ответ на выбор некоторого элемента в основной форме открывает другую форму. С помощью другого макроса можно осуществлять проверку значения некоторого поля при изменении его содержимого. В макрос можно включить дополнительные условия для выполнения или невыполнения тех или иных указанных в нем действий. Из одного макроса можно также запустить другой макрос или процедуру VBA.
6. Модуль. Объект, содержащий программы, написанные на языке Visual Basic для приложений. Модули могут быть независимыми объектами, содержащими функции, вызываемые из любого места приложения, но они могут быть и непосредственно «привязаны» к отдельным формам или отчетам для реакции на те или иные происходящие в них изменения.
Концептуальные взаимосвязи объектов Access показаны на рис. 6.1.
Рис. 6. 1. Взаимосвязи основных объектов в Microsoft Access
В таблицах хранятся данные, которые вы можете извлекать с помощью запросов. Используя формы, вы можете выводить данные на экран или изменять их. Заметим, что формы и отчеты получают данные как непосредственно из таблиц, так и через запросы. Для выполнения нужных вычислений и преобразования данных запросы могут использовать встроенные функции или функции, созданные с помощью Visual Basic для приложений. События, происходящие в формах или отчетах, могут запускать макросы или процедуры VBA.
Событие – любое изменение состояния объекта Microsoft Access. Например, событием является открытие формы, закрытие формы, ввод новой строки в форму, изменение содержимого текущей записи или элемента управления (объекта формы или отчета, который может содержать данные). Для обработки события вы можете создать макрос или процедуру Visual Basic для приложений.
С помощью макросов и модулей вы можете изменять ход выполнения приложения; открывать, фильтровать и изменять данные в формах и отчетах; выполнять запросы и создавать новые таблицы. Используя Visual Basic для приложений, вы можете создать, модифицировать и удалить любой объект Access, обрабатывать данные по строкам или по столбцам, а также каким-либо другим способом. Вы можете даже вызывать процедуры из библиотек динамической компоновки (DLL) Microsoft Windows, чтобы использовать в своем приложении не только встроенные в Access функции, но и возможности Windows.
Дата добавления: 2015-10-29; просмотров: 189 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Крок 3. Аналіз інформації в базі даних | | | Текстовый формат |