База данных библиотеки ВУЗа

EntityNameAttributePrimary Key AttributeT_avtorT_bibliotekarT_chitatelT_izdatelstvoT_literaturaT_mesto_hraneniya_litT_sostav__T_chitatT_sostav_litAttribute(s) of "T_avtor" EntityNameIs In Key GroupIs PKIs FKАвторYesNoФамилияNoNoИмяNoNoОтчествоNoNoКомментарииNoNoIs In Key Group(s) of "Автор" AttributeNamePrimary KeyIs In Key

База данных библиотеки ВУЗа

Дипломная работа

Компьютеры, программирование

Другие дипломы по предмету

Компьютеры, программирование

Сдать работу со 100% гаранией
дого читателя и прослеживать его историю пользования книгами: код читателя, ФИО, дата регистрации, дата окончания регистрации.

8.Библиотекарь.

В данной сущности выбраны атрибуты, идентифицирующие каждого работника библиотеки.

Разработка ключей.

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

Значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности [2]. Сотрудник библиотеки или читатель может сменить как фамилию, так и паспорт. Поэтому атрибуты, содержащие ФИО, номер паспорта не подходят на роль первичного ключа. Поэтому принято решение в сущностях ЧИТАТЕЛЬ и БИБЛИОТЕКРАЬ на роль первичных ключей разработать уникальный код, который бы идентифицировал каждого человека уникально.

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

При работе ИС часто бывает необходимо обеспечить доступ к нескольким экземплярам сущности, объединенным каким-либо одним признаком. Для повышения производительности в этом случае используются неуникальные индексы. ERwin позволяет на уровне логической модели назначить атрибуты, которые будут участвовать в неуникальных индексах. Атрибуты, участвующие в неуникальных индексах, называются Inversion Entries. Inversion Entry - это атрибут или группа атрибутов, которые не определяют экземпляр сущности уникальным образом, но часто используются для обращения к экземплярам сущности. ERwin генерирует неуникальный индекс для каждого Inversion Entry.Внешние ключи (FK) создаются автоматически, когда связь соединяет сущности: связь образует ссылку на атрибуты первичного ключа в дочерней сущности и эти атрибуты образуют внешний ключ в дочерней сущности (миграция ключа) [1]

 

Таблица №1 Первичные, альтернативные, внешние ключи, индексы и атрибуты логической модели.

СущностьПервичный ключАтрибутыАвторКод_авторФамилия (IE1.1) Имя (IE1.2) Отчество (IE1.3)ЛитератураКод_литератураКод_издательства (FK) Наименование Кол-воСтраниц ISBN (AK1.1) BBK (AK1.2) UDK ДопИнформация Аннотация Год Вид ТипИздательствоКод_издательства СокрНаименИзд-ва ПолноеНаименИзд-ва ГородЭкземплярыИд_номерКод_издательства ИД _Место ДатаУчёта ДатаСписания Код_Литература (FK) Библиотекарь_номер ПримечаниеМесто храненияИД_ МестоНомерПомещения Стеллаж Раздел ПолкаВыдачаИд_номер Код_читателя Библиотекарь_номер (FK) ДатаВыдачи ДатаВозврата ПримечаниеЧитательКод_читателяФамилия (IE1.1) Имя (IE1.2) Отчество (IE1.3) ДатаРегистрации ДатаОкончанияРегистрБиблиотекарьБиблиотекарь_номерФамилия (AK1.1) Имя (AK1.2) Отчество (AK1.3) Стаж

Связи.

В IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю сущность в зависимую.

Можно выделить три типа связей между таблицами:

·идентифицирующая связь (1:1) - каждой записи одной таблицы соответствует только одна запись другой таблицы;

·неидентифицирующая связь (1:М) - одной записи главной таблицы могут соответствовать несколько записей подчиненной таблицы;

·многие ко многим (М:М) - одна запись главной таблицы связана с несколькими записями подчиненной таблицы, а одна запись подчиненной таблицы связана с не сколькими записями главной таблицы [1].

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

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

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

 

 

Рис. 5. Логическая модель

 

Приведение модели к требуемому уровню нормальной формы

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

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

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

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

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

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

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

 

 

2.3 Разработка запросов к базе данных

 

Процессор обработки данных Jet является составной частью Access и выполняет инструкции Access SQL (Jet SQL).

СУБД Access позволяет создавать запросы в режиме «Конструктор» или «Режим SQL»

Чтобы войти в режим SQL в Access нужно в поле конструктора запроса нажать левой кнопкой и в появившемся окне нажать «Режим SQL».

В появившемся окне прописываем SQL запрос. К примеру, нам надо показать какие данные находятся в таблице «Литература». Прописываем:

SELECT id_literatura, naimenovanie

FROM T_literatura;

В итоге появится таблица, в которой мы видим «идентификационный номер» книги и её название.

Для удобства поиска автора по его инициалам создаём запрос, где требуется в таблице «Автор» упорядочить фамилии в алфавитном порядке, создаем SQL запрос следующего вида:

SELECT familiya, imya, otchestvoT_avtor BY familiya;

Создадим запрос на поиск книги по фамилии автора:

SELECT familiya, imya, otchestvo,

[nimenovanie], [izdatel]T_avtor, T_literatura, T_izdatelstvo;

Запрос на выведение информации по книгам, которые находятся на руках читателей:

SELECT id_inv_nomer, naimenovanie,, imya, otchestvo, data_vid, data_vozvrataT_ekzemplyary_T_chitat, T_literatura, T_chitatel;

3. Реализация БД

 

.1 Выбор СУБД

 

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

Похожие работы

<< < 1 2 3 4 5 6 7 > >>