Домашняя библиотека БД

Чтобы связать две  реляционные таблицы, необходимо ключ первой таблицы ввести в состав ключа  второй таблицы (возможно совпадение ключей); в противном случае нужно ввести в структуру первой таблицы внешний ключ – ключ второй таблицы.

2. Проектирование базы данных

2.1 Режимы работы с базами данных

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

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

Соответственно СУБД имеет  два режима работы: проектировочный  и пользовательский. Первый режим предназначен для создания или изменения структуры базы и создание ее объектов. Во втором режиме происходит использование ранее подготовленных объектов для наполнения базы или получения данных из нее.

2.2 Объекты базы данных

Таблицы. Таблицы – это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства).

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

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

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

Страницы. Это специальные объекты баз данных, реализованных в последней версии СУБД  Microsoft Access (Access 2000). Правда, более коректно их называть страницами доступа к данным. Физически это особый объект, выполненный в коде HTML, размещаемый на Web-странице и передаваемый клиенту вместе с ней. Сам по себе этот объект не является базой данной, но содержит компоненты, через которые осуществляется связь переданной Web-страницы с базой данных, остающейся на сервере. Пользуясь этими компонентами, посетитель Web-узла может просматривать записи базы в полях страницы доступа. Таким образом, страницы доступа к данным осуществляют интерфейс между клиентом, сервером и базой данных, размещенной на сервере. Эта база данных не обязательно должна быть базой данных Microsoft Access. Страницы доступа, созданные средствами Microsoft Access, посволяют работать также с базами данных Microsoft SQL Server.

Макросы и  модули. Эти категории объектов предназначены как для автоматизации повторяющихся операций при работе с СУБД, так и для создания новых функций путем программирования. В СУБД Microsoft Access макросы состоят из последовательности внутренних команд СУБД и являются одним из средств автоматизации работы с базой. Модули создаются средствами внешнего языка програмирования, в данном случае языка Visual Basic for Applications. Это одно из средств, с помощью которых разработчик базы может заложить в нее нестандартные функциональные возможности, удовлетворить специфическое требование заказчика, повысить быстродействие системы управления, а также уровень ее защищенности.

2.3 Типы связей

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

• один к одному (1:1);
• один ко многим (1:М);
• многие ко многим (М:М).

Связь один к одному (1:1) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот.

При связи один ко многим (1:М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А. Графически данное соответствие имеет вид.

Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот.

2.4 Разработка технического задания

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

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

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

При подготовке технического задания  составляют:

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

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

2.5 Разработка структуры базы данных

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

1. Работа начинается с составления генерального списка полей – он может насчитывать десятки и даже сотни позиций.
2. В соответствии с типом данных, размещаемых в каждом поле, определяют наиболее подходящий тип для каждого поля.
3. Далее распределяют поля генерального списка по базовым таблицам. На первом этапе распределение производят по функциональному признаку. Цель – обеспечить, чтобы ввод данных в одну таблицу производился, по возможности, в рамках одного подразделения, а еще лучше – на одном рабочем месте.
4. В каждой из таблиц намечают ключевое поле. В качестве такого выбирают поле, данные в котором повторяться не могут. Например, для таблицы данных о студентах таким поле может служить индивидуальный шифр студента. Для таблицы, в которой содержаться расписание занятий, такого поля можно и не найти, но его можно создать искусственным комбинированием полей «Время занятия» и «Номер аудитории». Эта комбинация не повторима, так как в одной аудитории в одно и то же время не принято проводить два различных занятия. Если в таблице вообще нет ни каких полей, которые можно было бы использовать, как ключевые, всегда можно ввести дополнительное поле типа Счетчик – оно не может содержать повторяющихся данных по определению.
5. С помощью карандаша и бумаги расчерчивают связи между таблицами. Такой чертеж называется схемой данных. Существует несколько типов возможных связей между таблицами. Наиболее распространенными являются связи «один ко многим» и «один к одному». Связь между таблицами организуется на основе общего поля, причем в одной из таблиц оно обязательно должно быть ключевым, то есть на стороне «один» должно выступать ключевое поле, содержащее уникальные, неповторяющиеся значения. Значения на стороне «многие» могут повторяться.
6. Разработкой схемы данных заканчивается «бумажный» этап работы над техническим предложением. Эту схему можно согласовать с заказчиком, после чего приступать к непосредственному созданию базы данных.

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

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

 

3. Создание базы данных «Домашняя библиотека»

3.1. Создание  таблиц

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

При практической разработке БД таблицы-сущности зовутся таблицами, строки-экземпляры - записями, столбцы-атрибуты - полями.

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

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

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

Составляющими базу данных являются 2 таблицы, из них одна основная:

• Вывод данных о книгах – содержит информацию обо всех книгах библиотеки;
• Информация об авторе – содержит информацию об авторе, его работах;

Для создания таблицы  в режиме конструктора необходимо:

• открыть базу данных;
• на вкладке «Таблицы» выбрать «Создание таблицы в режиме конструктора», откроется окно конструктора;
• ввести имена полей таблицы и выбрать тип данных для каждого поля;
• изменить свойства полей, если это необходимо;
• выбрать ключевое поле, если это необходимо;
• выполнить «Файл»®»Сохранить» и сохранить таблицу, при этом если ключевое поле не было выбрано, Access предложит его создать;
• закрыть таблицу.

Ниже описана структура  таблиц Вывод данных о книгах и Информация об авторе.

Структура таблицы Вывод данных о книгах представлена в Таблица 1.

Таблица 1. Структура таблицы «Вывод данных о книгах»

ТИП ДАННЫХ	ПРИМЕНЕНИЕ	ПОЛЕ
Числовой	Числовые данные различных форматов, используемые для проведения расчетов	Номер тома
Текстовый	Текст или числа, не требующие проведения расчетов, например номера телефонов (до 255 знаков)	Автор, название издания, вид издания, место издания, издательство
Дата/время	Для хранения календарных дат и  текущего времени	Год выпуска

Вид таблицы «Вывод данных о книгах» представлен на Рис 2.

Рис 2. Вид таблицы «Вывод данных о книгах»

Таблица «Информация об авторе» предназначена для хранения данных об авторе, его известных произведениях. Структура таблицы представлена в Таблица 2.

Таблица 2. Структура таблицы «Информация об авторе»

ТИП ДАННЫХ	ПРИМЕНЕНИЕ	ПОЛЕ
Дата/время	Для хранения календарных дат и  текущего времени	Годы жизни
Текстовый	Текст или числа, не требующие проведения расчетов, например номера телефонов (до 255 знаков)	Автор
Поле MEMO	Текст или числа, не требующие проведения расчетов, например номера телефонов (>255 знаков)	Известные произведения