Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Методичка по курсовой БД_полн.doc
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
598.02 Кб
Скачать

Экземпляр

Инвентарный номер экземпляра

Место размещения

Вкладыш

Рис.1. Инфологическая модель предметной области «Библиотека»

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

4.3. Выбор субд

Обосновать выбор той или иной СУБД, например, СУБД Microsoft Access 2000. Дать описание СУБД и ее основных характеристик, желательно в сравнении с другими СУБД.

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

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

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

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

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

В результате получили следующие отношения:

Книга (Шифр книги, Название, Автор, Издательство, Город издания, Год издания, Количество страниц, Количество экземпляров в библиотеке, Цена, Номер области знаний, Название области знаний)

Экземпляр (Инвентарный номер книги, Шифр книги, Место размещения,

№ читательского билета, Дата выдачи, Дата возврата)

Читатель (№читательского билета, Фамилия И.О., Дата рождения, Домашний адрес, Место работы, Телефон(рабочий), Телефон (домашний)).

      1. Нормализация отношений

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

Рассмотрим отношение «Книги». Каждая книга может относиться к многим областям знаний , т.е. атрибуты номер области знаний и название области знаний – сложные, а это значит, что нарушена 1-ая нормальная форма. Чтобы привести к 1-ой нормальной форме добавим к ключу еще один атрибут – номер области знаний.

Функциональные зависимости между атрибутами отношений после приведения отношения «Книги» к первой нормальной форме приведены на рис.2. Отношения «Читатель» и «Экземпляр» находятся в 1-ой нормальной форме, т.к. не имеют сложных атрибутов.

Поскольку отношения «Читатель» и «Экземпляр» имеют простые ключи, они уже во 2-ой нормальной форме. В отношении «Книги» 2-ая нормальная форма нарушена, т.к. есть неключевые атрибуты, зависящие только от части ключа, а не от всего составного ключа. Приведем это отношение ко 2-ой форме, разделив отношение на три отношения по зависимости от ключа или части ключа. Результат представлен на рис.3.

Назовем новые отношения: «Книги», «Области знаний», «Принадлежность книги к области знаний».

В результате мы получили 5 отношений: «Книги», «Экземпляр»,

«Области знаний», «Принадлежность книги к области знаний», «Читатель» .

Отношение «Книги»

ш ифр книги

н омер области знаний

н азвание области знаний

н азвание

ф амилии авторов

и здательство

г ород издания

г од издания

к оличество страниц в книге

ц ена книги

к оличество экземпляров в библиотеке

Отношение «Читатели»

читательского билета

Ф амилия, имя, отчество

д ата рождения

а дрес

м есто работы

т елефон домашний

т елефон рабочий

Отношение «Экземпляры»

и нвентарный номер книги

м есто размещения

д ата выдачи

д ата возврата

№ читательского билета

ш ифр книги

Рис.2. Функциональные зависимости отношений

Отношение «Книги»

ш ифр книги

н азвание

ф амилии авторов

и здательство

г ород издания

г од издания

к оличество страниц в книге

ц ена книги

к оличество экземпляров в библиотеке

Отношение «Области знаний»

н омер области знаний

н азвание области знаний

Отношение «Принадлежность книги к области знаний»

ш ифр книги

н омер области знаний

Рис.3. Приведение отношения «Книги» ко 2-ой нормальной форме.

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