Размещено на http://www.allbest.ru/

КУРСОВАЯ РАБОТА

по дисциплине

«Базы данных и знаний»

на тему:

«Разработка базы данных библиотеки»

СОДЕРЖАНИЕ

Список условных сокращений

Введение

Реализация разработки базы данных «Библиотека»

1. Системный анализ предметной области

2. Инфологическое моделирование

2.1 Выявление сущностей инфологической модели «Библиотека»

2.2 Связи между сущностями инфологической модели

3. Даталогическое проектирование базы данных «Библиотека»

3.1 Построение таблиц и нормализация базы данных

3.2 Описание внешних моделей в терминах выбранной СУБД

4. Физическое проектирование базы данных «Библиотека»

5. Реализации базы данных «Библиотека»

6. Создание интерфейса приложения «Библиотека»

Заключение

Список использованных источников

Приложение А Листинг SQL-запросов

Список условных сокращений

АСИС - автоматизированная справочно-информационная система;

БД - база данных;

ПК - персональный компьютер;

ПЭВМ - персональная электронно-вычислительная машина;

СУБД - система управления базами данных;

SQL - Structured Query Language);

ER-модель - «Entity Relationship» - модель «сущность-связь».

база библиотека инфологический моделирование даталогический

Введение

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

Задачами, которые следует решить для раскрытия выбранной темы, являются:

· сбор документов для описания предметной области;

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

· выявление сущностей инфологической модели и моделирование связей между ними (этап инфологического моделирования);

· построение набора таблиц базы данных и нормализация базы (этап даталогического проектирования);

· описание внешних моделей в терминах выбранной СУБД (этап даталогического проектирования);

· выбор схемы размещения данных, определение числа и типа индексов (этап физического моделирования);

· реализация базы данных и организация запросов в выбранной СУБД (этап реализации базы данных);

· реализация программного интерфейса к базе данных (этап создания интерфейса приложения).

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

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

- целостность и непротиворечивость данных,

- достоверность данных,

- простота управления данными,

- безопасность доступа к данным.

Этим требованиям удовлетворяют реляционные базы данных, реализованные в современных профессиональных СУБД.

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

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

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

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

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

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

Реализация разработки базы данных «Библиотека»

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

1. Системный анализ и словесное описание информационных объектов предметной области.

2. Проектирование инфологической модели предметной области - частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER-модели.

3. Даталогическое или логическое проектирование БД, то есть описание БД в терминах принятой даталогической модели данных.

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

Рис. 1. Этапы проектирования БД

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

1. Системный анализ предметной области

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

В общем случае существуют два похода к выбору состава и структуры предметной области:

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

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

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

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

Рассмотрим проектирование БД на примере предметной области «Библиотека».

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

Пусть необходимо построить базу данных, содержащую информацию о деятельности библиотеки [1]:

· списки сотрудников библиотеки;

· перечень каталогов;

· сведения о книгах;

· сведения об абонентах;

· результаты выдачи книг.

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

· Документы справочной информации. Справочная информация содержится в документах «Список сотрудников», «Книги», «Абоненты». На рис. 2, 3 приведены формы справочных документов

· Документы учетной информации. Учетная информация может быть представлена в списках каталогов, содержащих перечень сведений о книгах в библиотеке (рис. 4), а также в заполненных талонах выдачи книга (рис. 5).

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

Список сотрудников

Код сотрудника	Фамилия И.О.	Год рождения	Адрес	Телефон
567	Иванов И.И.	1965	ул.Савушкина 1а	256789
457	Петров П.П.	1970	Ул.Маркина 25	356756
579	Сидоров С.С.	1981	Ул Свердлова 5	354323

Рис. 2. Форма документа со списком сотрудников

Абоненты

Код абонента	Фамилия И. О.	Адрес	Телефон
0401	Сидоров И.Н.	ул Савельева 23	245676
0402	Соколов А.Н.	ул Мира, 23,1	354567
0403	Орлов А.А.	ул Савушкина 25	356723

Рис. 3. Форма документа со списком абонентов

Сведения о книгах

Шифр книги	Код экземпляра	Автор	Название	Год издания	Издатель-ство
Б/65.01 Д54	Д54-1	Дятел В.В.	Экономика	2001	Тула-С
681.3 М81	1	Мартьянова А..	Базы данных и знаний	2004	Астра-М
Б/65.01 П25	П25-1	Петров Л.А	Экономика	2000	Москва

Рис. 4. Форма документа с перечнем книг

Талон на выдачу книги

Номер талона	Код абонента	Код книги	Код экземпляра	Код сотрудника	Дата выдачи
45	0401	Б/65.01 Д54	Д54-1	ОГРНСБ3	06.04.05
68	0402	681.3 М81	1	ОГРНСБ2	06.04.05
17	0403	Б/65.01 П25	П25-1	ОГРНСБ1	07.04.05

Рис. 5. Форма документа-талона на выдачу книги

2. Инфологическое моделирование

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

2.1 Выявление сущностей инфологической модели «Библиотека»

На основании внимательного предметной области выделим следующие сущности модели «сущность-связь» («Entity Relationship» - ER-модели): «Сотрудники», «Абоненты», «Каталоги», «Книги», «Экземпляры» и изобразим их в виде графических обозначений (прямоугольник, в верхней части которого записано имя сущности, а ниже перечисляются атрибуты, причем ключевые атрибуты помечаются подчеркиванием) - см. рис. 6 - 10.

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

СОТРУДНИК
Читательский номер
Фамилия
Имя
Отчество
Адрес
Домашний телефон

Рис. 6. Определение сущности «Сотрудник» в модели ER

АБОНЕНТЫ
Читательский номер
Фамилия И.О.
Адрес
Телефон

Рис. 7. Определение сущности «Абоненты» в модели ER

КАТАЛОГИ
Код каталога
Название каталога

Рис. 8. Определение сущности «Каталоги» в модели ER

КНИГИ
Код книги
Автор
Название
Год издания
Издательство
Количество страниц

Рис. 9. Определение сущности «Книги» в модели ER



ЭКЗЕМПЛЯРЫ
Код книги
Код экземпляра
Номер экземпляра

Рис. 10. Определение сущности «Экземпляры» в модели ER

2.2 Связи между сущностями инфологической модели

Между выделенными сущностями можно выделить следующие связи:

1. «Книги» объединены в «Каталоги» (связь М:1).

2. «Книги» имеют «Экземпляры» (связь 1: М).

3. «Сотрудники» выдают «Экземпляры» (связь 1:М).

5. «Абоненты» берут «Экземпляры» (связь М:М).

На рис.11 показана версия полной ER-модели для базы данных «Библиотека».

Рис. 11. Моделирование связей между сущностями предметной области БД «Библиотека»

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

3. Даталогическое проектирование базы данных «Библиотека»

3.1 Построение таблиц и нормализация базы данных

Построение даталогической модели является следующим этапом проектирования. Задача этого этапа заключается в преобразовании ER-диаграммы «Библиотека» в реляционную схему.

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

Результатом выполнения этапа даталогического проектирования является следующее:

- концептуальная схема БД;

- корректная схема БД, ориентированная на реляционную модель данных;

- концептуальная схема БД, описанная в терминах выбранной СУБД;

- внешние модели, описанные в терминах выбранной СУБД;

- декларативные правила поддержки целостности базы данных;

- разработанные процедуры поддержки семантической целостности базы данных.

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

При даталогическом проектировании связи предметной области могут отображаться двумя путями:

1) декларативным - в логической схеме,

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

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

Наиболее часто встречаются бинарные связи (каждая связь связывает только 2 сущности). Такие связи присутствуют и в разрабатываемой нами БД. Тип этих связей - 1:М (один ко многим). И здесь будет действовать четвертое правило разрешения связей ER-диаграммы, которое гласит, что если степень бинарной связи равна 1:M и класс принадлежности M-связной сущности является обязательным, то достаточным является использование двух таблиц (по одной на каждую сущность), при условии, что ключ каждой сущности служит в качестве первичного ключа для соответствующей таблицы [ ] Помимо этого, ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, отводимую n-связной сущности.

Так как преобразование ER-диаграммы в реляционную схему заключается в превращении каждой сущности в отношение (таблицу), то каждое свойство становится атрибутом - столбцом соответствующей таблицы. Каждая простая сущность превращается в таблицу с тем же именем: «Абонент», «Выдача книг», «Сотрудник», «Книги», «Экземпляр», «Каталог». Каждый атрибут становится столбцом с тем же именем. Компоненты уникальных идентификаторов сущностей превращаются в первичные ключи соответствующих отношений.

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

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

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

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

На рисунке изображены таблицы БД «Библиотека», их столбцы, первичные и внешние ключи.

Рисунок 11. Структура базы данных «Библиотека

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

Давайте на примере таблиц 1-6 рассмотрим структуры таблиц базы данных «Библиотека» с типами данных столбцов и предлагаемыми ограничениями целостности.

Графа «Уникальное поле» показывает, что отмеченное поле индексируется: если в графе стоит «Да», то свойство Индексированное поле принимает значение «Да (Совпадения не допускаются)», если в графе стоит «Нет» - свойство Индексированное поле принимает значение «Да (Допускаются совпадения)».

Далее, в каждой таблице должны быть выделены столбцы, которые обязательно должны быть заполнены при создании отдельной строки таблицы.

Следующий важный момент - задание для столбцов значений по умолчанию. Значение по умолчанию впоследствии будет автоматически вводиться в указанный столбец для каждой строки таблицы. Например, в столбец Дата выдачи таблицы «Выдача книг» при заполнении очередной строки может автоматически заноситься текущая дата.

Ниже, в табл. 1-6 представлены параметры структуры таблиц базы данных «Библиотека» с типами данных столбцов и предлагаемыми ограничениями целостности.

Таблица 1. Описание свойств полей таблицы СОТРУДНИКИ

Имя поля	Клю-чевое поле	Уни-кальное поле	Обяза-тельное поле	Тип данных	Размер
Код сотрудника	Первичное	Да	Да	Текстовой	15
Фамилия		Нет	Да	Текстовой	15
Имя		Нет	Нет	Текстовой	15
Отчество		Нет	Нет	Текстовой	15
Год рождения		Нет	Нет	Текстовой	15
Адрес		Нет	Нет	Текстовой	15
Телефон		Нет	Нет	Текстовой	15

Таблица 2. Описание свойств полей таблицы АБОНЕНТЫ

Имя поля	Ключевое уникальное поле	Обязатель-ное поле	Тип данных	Размер
Код абонента	Первичное	Да	Текстовой	15
Фамилия	нет	нет	Текстовой	15
Имя	Нет	Нет	Текстовой	15
Отчество	Нет	Нет	Текстовой	15
Адрес	Нет	Нет	Текстовой	15
телефон	Нет	Нет	Текстовой	15

Таблица 3. Описание свойств полей таблицы КАТАЛОГИ

Имя поля	Клю-чевое поле	Уни-кальное поле	Обяза-тельное поле	Тип данных	Размер
Код каталога	Первичное	Да	Да	Текстовой	15
название		Нет	Нет	Текстовой	15

Таблица 4. Описание свойств полей таблицы КНИГИ

Имя поля	Клю-чевое поле	Уни-кальное поле	Обяза-тельное поле	Тип данных	Размер
Код каталога	Внешние	Нет	Нет	Текстовой	15
Код книги	Первиное	Да	Да	Текстовой	15
Автор		Да	Да	Текстовой	10
Название		Да	Да	Текстовой	10
Год издания		Да	Да	Текстовой	10
Издательство		Да	Да	Текстовой	10
Количество страниц		Да	Да	Текстовой	10

Таблица 5. Описание свойств полей таблицы ЭКЗЕМПЛЯРЫ

Имя поля	Ключевое поле	Уникальное поле	Обяза-тельное поле	Тип данных	Размер
Код книги	Внешние	Нет	Нет	Текстовой	15
Код экземпляра	Первичное	Да	Да	Текстовой	15
Номер экземпляра		Да	Да	Текстовой	10

Таблица 6. Описание свойств полей таблицы ВЫДАЧА КНИГ

Имя поля	Ключевое поле	Уникаль-ное поле	Обязательное поле	Тип данных	Размер
Код выдачи	Первичный	Да	Да	Счетчик	Длинное целое
Код книги	Внешний	Нет	нет	Текстовой	15
Код экземпляра	Внешний	Нет	нет	Текстовой	15
Код абонента	Внешний	Нет	нет	Текстовой	15
Код сотрудника	Внешний	Нет	нет	Текстовой	15
Дата Выдачи				Дата/время	10

3.2 Описание внешних моделей в терминах выбранной СУБД

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

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

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

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

Рис.12 Схема базы данных «Библиотеки»

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

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

Тестовые сведения для заполнения таблиц базы данных «Библиотека» приведены в табл. 7 - 12.

Таблица 7. Сведения для заполнения таблицы СОТРУДНИКИ

Код сотрудника	Фамилия	Имя	Отчество	Год рождения	Адрес	телефон
ОГРНСБ1	Иванова	Ира	Ивановна	1965	ул.Савушкина 1а	256789
ОГРНСБ2	Петрова	Анна	Петровна	1970	ул Маркина 24	356756
ОГРНСБ3	Сидорова	Анна	Сидоровна	1981	ул. Свердлова 5	354323

Таблица 8. Сведения для заполнения таблицы АБОНЕНТЫ

Код читательского номера	Фамилия	Имя	отчество	Адрес	телефон
0401	Сидоров	Иван	Николаевич	ул Савельева 23	245676
0402	Соколов	Анатолий	Петрович	ул Мира, 23,1	354567
0403	Орлов	Алексей	Алексеевич	ул Савушкина 25	356723

Таблица 9. Сведения для заполнения таблицы КАТАЛОГИ

Код каталога	Название
31	База данных и знаний
5	Политология

Таблица 10. Сведения для заполнения таблицы КНИГИ

Код каталога	Код книги	Автор	Название	Год издания	Издательство	Количество страниц
4	Б/65.01 Д54	Дятел В.В.	Экономика	2001	Тула-С	395
31	681.3 М81	Мартьянова А.Е.	Базы данных и знаний	2004	Астра-М	284
5	Б/66.01 П25	Петров Л.А.	Политология	2000	Москва	439

Таблица 11. Сведения для заполнения таблицы ЭКЗЕМПЛЯРЫ

Код книги	Код экземпляра	Номер экземпляра
Б/65.01 Д54	Д54-1	1
Б/65.01 Д54	Д54-2	2

Таблица 12. Сведения для заполнения таблицы ВЫДАЧА КНИГ

Код выдачи	Код книги	Код экземпляра	Код абонента	Код сотрудника	Дата выдачи
1	53 С17	С17-1	0401	Сидорова	06.04.05
2	53 С17	С17-2	0402	Иванченко	06.04.05
3	53 С17	С17-1	0402	Петрова	07.04.05

4. Физическое проектирование базы данных «Библиотека»

Стадия физического проектирования базы данных в общем случае включает:

· выбор способа организации базы данных (физические модели баз данных);

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

· описание отображения концептуальной схемы во внутреннюю.

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

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

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

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

В нашем случае уникальными являются следующие поля:

- поле Код Сотрудника таблице «Сотрудники»;

- поле Код читательского номера в таблице «АБОНЕНТ»;

- поле Код выдачи в таблице «ВЫДАЧА КНИГ»;

- поле Код экземпляра в таблице «ЭКЗЕМПЛЯР»;

- поле Код книги в таблице «КНИГИ»;

- Поле код каталога в таблице «КАТАЛОГ».

На эти поля установлено свойство индексированное поле - Да (Совпадения не допускаются). И этим полям присвоен уникальный индекс.

5. РЕАЛИЗАЦИИ БАЗЫ ДАННЫХ «БИБЛИОТЕКА»

Следующим этапом нашей работы будет создание приложения «Библиотека» в выбранной СУБД MS Access. Адекватным отображением полученной модели БД «Библиотека» является логическая структура реляционной БД Access. Каждая реляционная таблица отображает сущность модели. Структура каждой реляционной таблицы определяется атрибутами соответствующей сущности, где каждый столбец (поле) соответствует одному из атрибутов сущности. Уникальный ключ реляционной таблицы образуют ключевые атрибуты объекта. Для каждого столбца задается тип, размер данных и другие свойства. Экземплярам объекта соответствуют строки таблицы, которые формируются при загрузке таблицы. Связи между объектами модели реализуются одинаковыми атрибутами - ключами в соответствующих таблицах. При этом ключом всегда является уникальный ключ главной таблицы. Внешним ключом в подчиненной таблице является либо некоторая часть уникального ключа в ней, либо поле, не входящее в состав первичного ключа. В нашем примере это код сотрудника в таблице «Сотрудники».

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



Рисунок 13. Схема данных базы данных «Библиотека» в реляционной СУБД MS Access

6. Создание интерфейса приложения «Библиотека»

В процессе создания приложений СУБД MS Access используются запросы, формы, отчеты, макросы. Если нам нужно получить данные из базы, то мы будем использовать запросы. В нашем случае выполнены следующие запросы: «Абонент», «Книги», «Сотрудники», «Каталог», «Выдача книг», «Экземпляр» (листинг запросов см. приложение А).

Чтобы вывести данные на экран в удобном для нас виде, мы будем использовать формы, которые также можно использовать и для поиска данных. Формы позволяют пользователям вводить данные в таблицы базы данных без непосредственного доступа к самим таблицам. Кроме того, они позволяют выводить результаты работы запросов не просто в виде таблиц, а в виде красиво оформленных форм.

В приложении на основании таблиц БД «Библиотека» в режиме автоформы мы создали формы: «Абонент», «Книги», «Сотрудники», «Каталог», «Выдача книг», «Экземпляр», которые позволят заполнить эти таблицы. С помощью мастера форм формы «Абонент», «Книги», «Сотрудники», «Каталог», «Выдача книг», «Экземпляр».

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

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

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

В Access имеется так называемый диспетчер кнопочных форм - средство автоматизированной разработки интерфейса управления приложением. С его помощью создана главная кнопочная форма, на которой располагаются следующие кнопки: «АбонентЫ», «СОТРУДНИКИ», «ВЫДАЧА КНИГ», «КАТАЛОГ», «ЭКЗЕМПЛЯР», «Выход» (рисунок 14).



Рис. 14 Диспетчер кнопочных форм.

Рис.15 Параметры запуска.

Заключение

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

В результате анализа базы данных было выполнено:

- выявлена сущность инфологической модели и моделирование связей между ними;

- построение набора таблиц базы данных и нормализация базы;

- описание внешних моделей в терминах выбранной СУБД;

- реализация базы данных и организация запросов в выбранной СУБД;

- реализация программного интерфейса к базе данных.

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

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

Список использованных источников

1. Мартьянова, А.Е. Лабораторный практикум по дисциплине «Базы данных и знаний». Часть 1. Учебно-методическое пособие для студентов специальности 350800 «Документоведение и документационное обеспечение управления» (электронный вариант). - Астрахань: АГТУ. - 2004, 143 с.

2. Виноградова И.А., Грибова Е.А., Зубков В.Г. Практикум на ЭВМ. MS Access: Учебное пособие для студентов заочной (дистанционной) формы обучения. - М.: ГИНФО, 2000. - 124 с.

3. Голицина О.Л., Максимов Н.В., Попов И.И. Базы данных: Учебное пособие. - М.: ФОРУМ: ИНФРА-М, 2003. - 352 с.

4. Информатика. Базовый курс. /Под ред. С.В.Симоновича. - СПб.: Питер, 1999.-640с.

5. Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб.: Питер, 2002. - 304 с.

6. Петров В.Н. Информационные системы. - СПб.: Питер, 2003. - 688 с.

7. Тихомиров Ю.В. MS SQL Server 2000: разработка приложений. - СПб.: БХВ-Петербург, 2000. - 368 с.

Приложение А Листинг SQL-запросов

Режим SQL: «АБОНЕНТЫ»

SELECT абоненты.[код читательский номер], абоненты.фамилия, абоненты.имя, абоненты.отчество, книги.[код книги], книги.автор, книги.название, [выдача книг].[код выдачи]

FROM (книги INNER JOIN экземпляры ON книги.[код книги] = экземпляры.[код книги]) INNER JOIN (абоненты INNER JOIN [выдача книг] ON абоненты.[код читательский номер] = [выдача книг].[код абонента]) ON экземпляры.[код экземпляра] = [выдача книг].[код экземпляра]

WHERE (((абоненты.[код читательский номер])=[]));

Режим SQL: «ВЫДАЧА КНИГ»

SELECT [выдача книг].[код выдачи], [выдача книг].[код книги] AS [выдача книг_код книги], [выдача книг].[код экземпляра] AS [выдача книг_код экземпляра], [выдача книг].[код абонента], [выдача книг].[код сотр], [выдача книг].[дата выдачи], экземпляры.[код книги] AS [экземпляры_код книги], экземпляры.[код экземпляра] AS [экземпляры_код экземпляра], экземпляры.[номер экземпляра]

Режим SQL: «ЭКЗЕМПЛЯР»

FROM экземпляры INNER JOIN [выдача книг] ON экземпляры.[код экземпляра] = [выдача книг].[код экземпляра];

Режим SQL: «КОД КАТАЛОГА»

SELECT [код каталога], [название]

FROM каталог;

Режим SQL: «КНИГИ»

SELECT книги.[код каталога], книги.[код книги], книги.автор, книги.название, книги.[год издания], книги.издательство, книги.[количество страниц], экземпляры.[код экземпляра], экземпляры.[номер экземпляра]

FROM книги INNER JOIN экземпляры ON книги.[код книги] = экземпляры.[код книги];

Режим SQL: «СОТРУДНИКИ»

SELECT сотрудники.[код сотр], сотрудники.фамилия, [выдача книг].[код выдачи], [выдача книг].[код книги], [выдача книг].[код экземпляра], [выдача книг].[код абонента], [выдача книг].[дата выдачи]

FROM сотрудники INNER JOIN [выдача книг] ON сотрудники.[код сотр] = [выдача книг].[код сотр]

WHERE (((сотрудники.фамилия)=[Введите Фамилию]));

Режим SQL: «ЭКЗЕМПЛЯР»

SELECT экземпляры.[код книги] AS [экземпляры_код книги], экземпляры.[код экземпляра], экземпляры.[номер экземпляра], книги.[код каталога], книги.[код книги] AS [книги_код книги], книги.автор, книги.название, книги.[год издания], книги.издательство, книги.[количество страниц]

FROM книги INNER JOIN экземпляры ON книги.[код книги] = экземпляры.[код книги]

Размещено на Allbest.ru