Проектирование баз данных для домашней библиотеки (Архитектура базы данных: понятие, определение, уровни)

Содержание:

ВВЕДЕНИЕ

Современное общество всё чаще называют «информационным». Это связано с тем, что сегодня в любой среде человеческой деятельности одной из главных задач является организация хранения и обработки большого количества информации. В этом существенную помощь могут оказать компьютерные системы обработки данных. Основная цель подобных систем – повышение эффективности работы отдельной фирмы, предприятия или организации.

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

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

Целью курсовой работы является изучение базы данных, рассмотрение проектирования баз данных для домашней библиотеки.

Для достижения поставленной цели необходимо решить следующие задачи:

- рассмотреть понятие, определение, уровни архитектуры базы данных;

- исследовать создание, редактирование, обновление схемы данных в Access;

- исследовать проектирование баз данных для домашней библиотеки.

Объект исследования: база данных.

Предмет исследования: проектирования баз данных для домашней библиотеки.

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

Информационной базой для проведения исследования послужила специальная литература по теме исследования, а так же информация сети Интернет.

Основная часть

1. Архитектура базы данных: понятие, определение, уровни

Как называется совокупность основных структурных, функциональных компонентов различных БД, СУБД (систем управления базами данных)? Этот комплекс в информационной науке принято называть архитектурой базы данных, СУБД. Предлагаем вам досконально разобрать это понятие, типы подобных комплексов, их трехуровневое разбиение.

Архитектура базы данных - комплекс структурных компонентов БД, а также средств, обеспечивающих их взаимодействие как друг с другом, так и с конечным пользователем, системным персоналом.

Данное определение отражает одну из важнейших функций хранилищ информации - обеспечение возможности абстракции сведений БД. Она и формирует сложившийся в наши дни подход к архитектуре данных^[1].

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

• 1. Виды базы данных

Архитектура систем управления базами данных будет различной в зависимости от разновидности последних. На сегодня выделяется два вида БД:

•централизованный;

•распределенный.

С особенностями каждой из разновидностей мы предлагаем читателю ознакомиться далее.

Главное отличие этих БД: они хранятся в памяти одной вычислительной системы. Но если база, в свою очередь, будет компонентом сетей ЭВМ, то становится возможным распределенный доступ к базам данных. То есть БД будет открытой для пользователей электронно-вычислительных машин, подключенных к данной сети. Подобное использование характерно для локальных систем ЭВМ, создаваемых на базе организаций, компаний.

Распределенные базы данных

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

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

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

Архитектура базы данных также будет различаться по способу доступа к находящейся в хранилище информации:

•Доступ локальный.

•Доступ удаленный (сетевой).

Последний тип доступа предполагает разделение архитектуры подобных систем еще на две вариации:

•Тип "файл-сервер".

•Тип "клиент-сервер".

Снова предлагаем читателю разобраться с представленными разновидностями подробнее.

БД "файл-сервер"

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

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

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

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

БД "клиент-сервер"

Здесь также предполагается наличие машины в сети, которая будет являться главной. Однако архитектура базы данных "клиент-сервер" имеет и собственную особенность. Главный компьютер не только хранит централизованную БД, но и обеспечивает основную часть обработки требуемых пользователю данных.

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

Что предполагает архитектура клиент-серверных баз данных? Клиентское приложение здесь оформляет и отправляет запрос удаленному компьютеру-серверу, где расположено централизованное хранилище информации. Он (запрос) составлен на специальном языке SQL - стандарте доступа к серверу при использовании реляционных БД^[2].

После получения запроса удаленный сервер перенаправляет его SQL-серверу. Так называется программа, ответственная за управление удаленной базой данных. Она обеспечивает выполнение запроса, предоставляет клиенту требуемые результаты по нему.

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

1.2 Три уровня архитектуры базы данных

Архитектура баз данных подразделяется на три основных уровня - три степени описания элементов БД:

•Внешний. На данном уровне информация воспринимается пользователями.

•Внутренний. На этом уровне информация воспринимается операционными системами, СУБД (системами управления базами данных).

•Концептуальный. Здесь осуществляется отображение внешнего уровня архитектуры системы баз данных на внутренний, обеспечение необходимой их независимости друг от друга.

Предлагаем читателю более подробно познакомиться с каждой из вышепредставленных степеней.

Внешний уровень

Внешний уровень архитектуры систем баз данных - это предоставление информации с позиции людей-пользователей.

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

Что удобно, каждый пользователь здесь имеет дело с таким образом "реального мира", который более всего адаптирован под него. Внешнее представление будет содержать в себе только те сущности, связи и атрибуты, что интересны и полезны конкретному "юзеру".

Не стоит полагать, что ненужные для пользователя атрибуты, сущности и связи не существуют в базе данных. Они есть, но "юзер" чаще всего не подозревает об их существовании.

Если обратиться к терминологии ANSI/SPARC (Американского национального института стандартов), то представление каждого отдельного пользователя здесь будет называться внешним. В него будет входить содержимое БД - такое, каким его видит конкретный "юзер". Каждое такое внешнее представление определяется посредством внешней системы. Она же состоит из определения записи каждого типа, присутствующего во внешнем представлении.

Концептуальный уровень

Продолжаем разбирать архитектуру сервера, баз данных. Следующий ее уровень - концептуальный. Он включает в себя обобщающее представление о хранилище информации. Будет описывать, какие именно сведения хранятся в базе данных, а также каковы связи, их объединяющие.

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

Перечислим компоненты, представленных на концептуальном уровне архитектуры:

•Совокупность сущностей, их атрибутов, связей между ними.

•Ограничения, что могут быть наложены на данные.

•Семантическая информация о сведениях в БД (связанная с их смыслом и значением).

•Информация по мерам обеспечения безопасности хранения данных, общей поддержки их целостности.

Концептуальный уровень призван поддерживать каждое из внешних представлений. Любая доступная пользователю информация из БД должна содержаться (или может быть вычислена) именно на данном уровне. Однако следует помнить, что информация о методах хранения данных в системе здесь не хранится.

И последняя ступень трехуровневой архитектуры базы данных. Тут находится физическое представление в компьютере БД. Что это значит? Уровень предназначен для описания физической реализации базы данных. Кроме того, с его помощью достигается оптимальная производительность, обеспечивается экономное использование дискового пространства компьютерной системы.

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

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

Элементы внутреннего уровня

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

•О распределении дискового пространства для сохранения индексов и сведений.

•Подробное описание сохранения записи (где указываются реальные объемы сохраняемых данных).

•Информация о размещении записей.

•Сведения о сжатии данных, избранных методик их шифрования.

Вы познакомились с распространенными типами, видами архитектур систем баз данных. Также мы представили уровни архитектуры СУБД - внешний, внутренний и концептуальный, их характеристики и элементы

2. Схема данных в Access: создание, редактирование, обновление

Практически в любой организации существует своя база данных. Да что уж там, даже сайты используют их, чтобы работать с информацией было легче и проще. Действительно, базы данных позволяют безо всяких проблем делать расчеты, быстро находить нужные данные, да и вообще, просто создают порядок в любой информации^[3].

MS Access представляет собой систему управления базами данных, которая поставляется в комплекте с распространяемым пакетом программ Microsoft Office. И хоть функционал у нее несколько ниже, чем у специализированных программ, многие пользуются приложением за простоту в работе. Создание отчетов в Access – необходимый процесс для осуществления работы. Отчеты являются способом выборки данных с готовой базой данных по одному или нескольким заданным параметрам.

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

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

В качестве примера рассмотрим связи в БД туристического агентства. В ее состав входит таблица гостиниц Таиланда – страны, в которую турагентство отправляет гостей. Отели расположены в различных регионах Королевства.

Если компания работает с отелями только нескольких регионов, а в каждой из областей находятся десятки или сотни гостиниц, то заполнять каждый раз поле региона для каждого отеля – пустая работа. Поэтому в базе создается отдельная таблица, содержащая только список регионов, а при вводе отеля пользователь просто выбирает нужный из выпадающего списка.

Преимущества СУБД Microsoft Access:

- Простой и понятный интерфейс. Приступить к работе с данной СУБД можно, не имея никаких особых навыков. Кроме того, на помощь новичку приходят многочисленные справочные пособия, онлайн- и офлайн-курсы.

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

- Практически безграничные возможности экспорта данных: данные из таблиц щелчком одной клавиши мыши можно перенести в Excel, Word, экспортировать в XML, опубликовать в PDF, не говоря уже о том, чтобы без проблем перенести выбранные объекты в другую базу данных.

- Невысокая цена. Если покупать MS Access в составе полного пакета Microsoft Office, то, по сравнению с другими платными СУБД, цена окажется очень заманчивой.

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

- Широкие возможности импорта данных: если у вас есть табличные данные, созданные при помощи текстового процессора MS Word или табличного процессора MS Excel, вы с помощью мастера без труда перенесете их в свою базу. Импорт, кроме того, можно выполнить из простого текстового документа, из документа XML, а также из файлов баз данных, созданных в других СУБД (таких как dBASE, PARADOX).

- Возможность создания пароля на своей базе данных.

- Встроенный язык VBA высокого уровня.

- Возможность записи макросов.

- Редактор SQL.

По аналогии добавлен список стран для компании, работающей с несколькими государствами. Тогда к перечню регионов добавляется еще одно поле – «Страна», а в базу вносится справочник стран, наименования которых затем выбираются из списка^[4].

Таблицы связаны по типу один-ко-многим. Это означает, что одна запись из таблицы «Регионы» встречается много раз в таблице «Отели». Кроме этого, существуют виды «многие-ко-многим» и «один-к-одному». Но последняя крайне редко применяется на практике. Ниже мы ознакомимся, как эти типы обозначаются на схемах данных в Access.

Схема данных БД

В приведенном примере «Отели» связаны с «Регионами», а те, в свою очередь, со «Странами». Эта информация, написанная текстом, не слишком наглядно показывает связи между объектами. И в нашей базе всего три таблицы, а их могут быть сотни. Держать в голове все соединения разработчику затруднительно.

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

Прямоугольниками обозначены таблицы со списком полей, линии между ними – связи. На линии связи в местах примыкания к прямоугольникам таблиц сделаны обозначения: «1» и «∞». Они показывают, какой тип связи применен в этом отношении. Значок «1» у таблицы-источника со значком «∞» у приемника обозначают вид «один-ко-многим». Обе связи в нашей БД – такого типа.

Соответственно, две единицы у двух концов линии говорят о виде «один-к-одному», а два знака бесконечности – «многие-ко-многим».

Для создания схемы данных в Access добавлен инструмент на панели «Работа с базами данных». СУБД автоматически создает схему по тем таблицам и связям, что существуют в базе. Приведенная выше схема создана системой самостоятельно. Пользователь может внести изменения в макет. Некоторые из них не отразятся на структуре БД, только на отображении информации. А некоторые приведут к изменениям в структуре.

В режиме "Конструктора" доступна операция «Очистить макет». При ее выполнении экран схемы данных в Access очищается, а таблицы и отношения скрываются. Это не значит, что они пропадают из базы - просто не отражаются в макете схемы.

Операция «Скрыть таблицу» произведет то же действие над выделенным объектом. Он просто исчезнет с экрана вместе со своими линиями-отношениями. Вернуть скрытые таблицы поможет операция «Отобразить таблицу». Выбираются объекты, которые нужно добавить в макет. При этом связи с ним отображаются автоматически.

В нашем примере отношения между таблицами уже были определены во время создания. Остановимся более подробно на том, как это сделать. Как мы уже знаем, «Отели» содержит поле «Регион», данные для которого берутся из одноименной таблицы. При добавлении столбца «Регион» указывается тип поля «Подстановка и отношение».

Открывается мастер создания поля, в котором мы выбираем вариант получения значения ячеек из другого объекта. На втором шаге мастера выбираем объект, из которого будут подставляться значения. В нашем случае это таблица «Регионы». Из списка доступных для отображения полей нам нужно «Наименование» - в таблице отелей будут показаны названия регионов. При необходимости задаем порядок сортировки наименований и ширину столбца.

На последнем шаге даем имя новому полю и указываем параметр целостности. Подробнее на нем мы остановимся ниже. После нажатия на кнопку «Готово» в таблицу отелей добавлен столбец «Регион», значения для него берутся из указанного объекта.

Связь между таблицами отелей и регионов теперь отображается на схеме.

Изменение отношений

Если отношение не добавлено при добавлении столбца в объект, это делается непосредственно в макете схемы данных в Access. Как создать новую связь, покажем на примере. Нажмите кнопку «Изменить связи». В редактировании отношений для создания новой связи нажмите «Новое». В форме «Создание» выбираем таблицы для связи и поля, которые будут соответствовать друг другу.

Для уже созданной связи есть возможность изменять параметры объединения записей в запросах. Для этого вызываем диалоговое окно схемы данных MS Access «Изменение связей» и нажимаем кнопку «Объединение». В форме редактирования параметров предложены варианты объединений:

В первом случае в результатах запроса отображаются только те строки, в которых поля таблиц «Отели» и «Регионы» совпадают^[5].

Во втором случае объединяются все строки «Регионов» и только совпадающие «Отелей».

В третьем ситуация обратна второму – все строки «Отелей» объединяются с совпадающими «Регионов».

Мы оставляем автоматический выбор системы – первый вариант.

Целостность данных БД

Связи между объектами БД на схеме данных в Access подводят нас к понятию целостности данных. Как было показано выше, при создании связей между полями объектов базы указывается параметр целостности. Если он включен, связи между объектами поддерживаются и охраняются системой.

Покажем это наглядно на примере базы туристической компании. В «Отелях» гостиница с наименованием Anantara Lawana Koh Samui Resort относится к региону Самуи. Предположим, мы удалили этот район из «Регионов». Теперь поле ссылается на запись, которой не существует. Это и есть нарушение целостности.

Аналогично при установленном требовании соблюдения целостности мы не сможем выбрать в этом поле район «Чианг Май», потому что его не существует в таблице регионов.

При необходимости схемы базы данных Access выгружаются в отчет и отправляются на печатное устройство, преобразуются в файл или отправляются по электронной почте.

3. Проектирование баз данных для домашней библиотеки

При выполнении практической части курсовой работы - создание базы данных «Домашняя библиотека» в приложении Microsoft Access - были созданы 2 основные таблицы: «Книги», «Журнал»; 3 вспомогательные: «Жанры», «Темы», «Издательства»; сделана схема данных, 2 запроса, 4 формы, 2 отчета. При создании таблицы «Журнал» были включены следующие имена полей: Номер_записи, Номер_книги, Кому_дана, Дата_выдачи, Дата_возврата. (Рисунок 1).

Рис.1. Таблица «Журнал»

Поле Номер_записи., определено как ключевое поле. Тип данных у поля-Номер_записи, Номер_книги - числовой; Кому_дана - текстовый; Дата_выдачи, Дат_возврата - Дата/Время. (Рисунок 2).

Такую таблицу можно рассмотреть как однотабличную базу данных. Однако при подобной организации в ней будет содержаться значительное количество повторяющейся информации. Например, сведения о конкретном читателе библиотеки будут дублироваться при регистрации каждого нового сделанного им заказа. То же самое можно сказать и о сведениях о книгах. Всё это приведет к тому, что придется тратить значительное время на ввод повторяющихся данных. При изменении какой-либо информации, например при изменении телефона читателя, придётся корректировать все записи, содержащие сведения о заказах этого читателя. Кроме того, наличие повторяющейся информации приводит к неоправданному увеличению размера базы данных^[6].

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

Первое правило при проектировании базы данных: в таблице должны отсутствовать повторяющиеся группы полей. Это можно осуществить, переместив поля с повторяющейся информацией о читателях в отдельную таблицу «Читатели».

Таким образом можно избавиться от дублирования информации о читателях. Чтобы в таблице «Заказы» велась регистрация читателей, заказывающих книги, каждому читателю присваивается уникальный код, записываемый в поле Код читателя таблицы «Читатели», а в таблицу «Заказы» добавляется поле Читатели, где и будет указываться код читателя, сделавшего заказ. Так же мы выделили отдельную таблицу «Книги», а в таблице «Заказы» фиксировать только Код книги. Из таблицы «Книги» выделив в отдельную таблицу информацию о тематике книг. Поскольку в отдельный заказ может быть включено несколько книг, имеет смысл информацию о содержании заказа (заказанных книгах) также выделить в отдельную таблицу и фиксировать в ней код заказа. В результате новая таблица «Заказанные книги» будет содержать поля Код заказа, Код книги и дополнительное поле Отметка о возврате. Связь между таблицами «Заказа» и «Заказанные книги» осуществляется через совпадающие значения полей Код заказа. Результат подобного преобразования показан на

Рис. 2. Общие данные таблицы

Таким образом, в этой таблице были указаны все данные о выдачи книг. Таким же образом мы создаем данные нам таблицы. Их вы можете увидеть на рисунках.

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

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

Рис. 3 Вспомогательная таблица «Жанры»

Рис. 4 Вспомогательная таблица «Темы»

Рис.5 Вспомогательная таблица «Издательства»

Затем мы делаем схему данных.

Рис.6. Схема данных

Далее создаем запрос по Книгам. В запрос включили поля: Название, Автор, Жанр, Тема, Издательство, Год, Шкаф, Полка. Запрос нужен для того чтобы видеть виртуальную таблицу, включающую только те данные, которые были отобраны. Вводим в значение параметра по названию (Рисунок 7).

При вводе в ячейку «Война и мир» мы получаем данный запрос.

Рис. 8 Запрос «Книги»

По остальным таблицам были так же сделаны запросы. Далее нужно создать Формы. В качестве примера возьмем форму «Книги». По остальным таблицам были так же сделаны формы^[7].

Заключительным этапом работы было создание отчетов. В качестве примера приведу отчет «Журнал». Данные отчета вы можете увидеть на Рисунке 9

По остальным таблицам были так же сделаны отчеты. Их вы можете увидеть в практической части курсовой работы.

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

Запрос – объект базы данных, который используется для извлечения нужной информации из одной или нескольких таблиц базы данных или для выполнения определенных действий с данными.

При выполнении запроса MS Access создает набор записей, содержащий выбранные данные. Этот набор называется выборкой или динамической таблицей^[8].

Выборка – представление на экране результат выполнения запроса.

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

По результатам действия и особенностям выполнения нами использовались следующие типы запросов:

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

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

- параметрические запросы (или запросы с параметрами), которые позволяют задавать конкретные условия отбора непосредственно при выполнении запроса. Например, условием выбора являются книги на определенную тему.

Использование форм для ввода, корректировки и просмотра

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

Форма – объект БД, позволяющий создать удобный пользовательский интерфейс для работы с данными.

Формы позволяют:

- ограничить объём информации, отображаемой на экране, и представить её в требуемом виде;

- выбрать, какие поля и в какой последовательности должны быть в ней представлены, разбить их на логические связанные группы, задать удобное расположение на экране;

- содержать иллюстрации, графически предоставлять хранящуюся в БД информацию;

- уменьшить количество ошибок при вводе;

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

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

- переход по записям источника формы, обработка записей (добавление, удаление, поиск);

- работа с формой (закрытие, обновление данных)

Использование кнопочной формы

Выше были рассмотрены объекты БД Access: таблицы, запросы, формы. При этом разрозненность большого количества объектов в окне БД «Библиотека» затрудняет работу пользователя с приложением.

Поэтому для приложения создан специальный интерфейс, в котором объекты группируются по функциональному назначению, и обеспечивается удобный доступ к ним. При этом работа пользователя непосредственно с таблицами БД «Библиотека» исключается.

С помощью диспетчера кнопочных форм создана кнопочная форма, которая используется как панель управления БД «Библиотека». Пользователь (библиотекарь), нажимая кнопку на панели управления, инициирует событие нажатия кнопки, например, «Сведения о книгах». К этому событию привязывается действие по открытию другой кнопочной формы, «О книгах» или обращение к нужным объектам компонента – формам, например, «Заказы».

 

ЗАКЛЮЧЕНИЕ

Таким образом, в своей курсовой работе мы показали, как создать базу данных «Домашняя библиотека» для повышения экономии времени.

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

Создание базы данных «Домашняя библиотека» на этом не ограничивается. Возможно продолжение работы в следующих направлениях:

- классификация художественной литературы (по исторической хронологии, по литературным направлениям и т.д.);

- учебно-дидактический компонент;

- классификация методической литературы.

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

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

Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер». Фактически, у любой современной СУБД существует аналог, выпускаемый другой компанией, имеющий аналогичную область применения и возможности, любое приложение способно работать со многими форматами представления данных, осуществлять экспорт и импорт данных благодаря наличию большого числа конвертеров.

Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

СПИСОК ИСТОЧНИКОВ

1. Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems - 8-е изд. - М.: Вильямс, 2015.
2. Аладьев, В.В. Основы информатики [Текст]: учебное пособие/ В.В. Аладьев, Ю.Я. Хунт, М.Л. Шишаков, М., 2018.
3. Информатика. Учебное пособие /Ломтадзе В.В., Шишкина Л.П. - Иркутск: ИрГТУ, 2019
4. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management - 3-е изд. - М.: Вильямс, 2017.
5. Марков А.С. Базы данных. Введение в теорию и методологию /Лисовский К. Ю., Москва, 2018
6. Когаловский М.Р. Технология баз данных на персональных ЭВМ. / М.: Финансы и статистика, 2018
7. Ревунков Г.И., Самохвалов Э.Н., Чистов В.В. Базы и банки данных и знаний: Учеб. для вузов / Под ред. Четверикова В.Н. - М.: Высш. шк., 2015
8. Тиори Т., Фрай Дж. Проектирование структур баз данных : В 2-х кн. Пер. с англ. / М.: Мир, 2014
9. Голицина О. Л. Базы данных / Голицина О. Л., Максимов Н. В., Попов И. И. - М.: Форум, 2017
10. Карпова Т.С. Базы данных: модели, разработка, реализация / Питер, 2013
11. Бемер С., Фратер Г. Microsoft Access для пользователя / Микап, Москва 2017
12. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение / Москва, Питер, Киев, 2013
13. Мейер, М. Теория реляционных баз данных / М. Мейер - М.: Мир, 2017
14. Хаббард, Дж. Автоматизированное проектирование баз данных / Хаббард Дж. - М.: Мир, 2018
15. Бойко, В. В. Проектирование баз данных информационных систем / Бойко В.В., Савинков В.М. - М.: Финансы и статистика, 2019
16. Бакаревич, Ю. Б. Самоучитель Microsoft Access 2002 / Бакаревич Ю.Б., Пушкина Н.В. - СПб.: БХВ-Петербург, 2012.

1. Информатика. Учебное пособие /Ломтадзе В.В., Шишкина Л.П. - Иркутск: ИрГТУ, 2019 ↑

2. Ревунков Г.И., Самохвалов Э.Н., Чистов В.В. Базы и банки данных и знаний: Учеб. для вузов / Под ред. Четверикова В.Н. - М.: Высш. шк., 2015 ↑

3. Тиори Т., Фрай Дж. Проектирование структур баз данных : В 2-х кн. Пер. с англ. / М.: Мир, 2014 ↑

4. Карпова Т.С. Базы данных: модели, разработка, реализация / Питер, 2013 ↑

5. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение / Москва, Питер, Киев, 2013 ↑

6. Хаббард, Дж. Автоматизированное проектирование баз данных / Хаббард Дж. - М.: Мир, 2018 ↑

7. Бакаревич, Ю. Б. Самоучитель Microsoft Access 2002 / Бакаревич Ю.Б., Пушкина Н.В. - СПб.: БХВ-Петербург, 2012. ↑

8. Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems - 8-е изд. - М.: Вильямс, 2015. ↑