База данных книжного магазина

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

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

Атрибут (поле) - любой столбец  в таблице.

Домен - множество значений, которые может принимать атрибут.

Кортежи (записи) - строки таблицы.

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

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

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

 

Рисунок 2: схема данных

 

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

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

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

Исключить дублирование информации в таблицах.

Обеспечить возможность  изменений в структуре таблиц.

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

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

Ненормализованные данные

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

Первая нормальная форма

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

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

Вторая нормальная форма

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

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

Третья нормальная форма

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

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

Четвёртая нормальна  форма

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

Пятая нормальная форма и комбинированные элементы

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

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

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

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

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

4. Модель  физической организации данных

 

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

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

Файлом базы данных в теории баз данных называется таблица реляционной  модели.

Физические модели для  базы данных Продажи Книг выглядят следующим образом:

 

 

 

. Реализация  баз данных в MS Access

 

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

·управление данными во внешней  памяти (на дисках);

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

·журнализация изменений  и восстановление БД после сбоев;

·поддержание языков БД (язык определения данных, язык манипулирования  данными).

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

Для создания базы данных "продажи  Книг" необходимо создать таблицы, заполнить их в соответствии с  исходными данными и реализовать  связи между таблицами в режиме "схема данных".

 

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

 

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

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

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

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

 
 

 

 

 

5.2 Создание  запросов

 

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

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

 

 

Все запросы БД "Продажи  книг"

1) Поиск

Поиск книг в таблице "Books":

 
 

DISTINCTROW Books. [id_ книги], Books. Номер, Books. издательство, Books. Автор, Books. Название, Books. Переплет, Books. Серия, Books. Жанр, Books. [Дата выпуска], Books. Цена, Books. КоличествоBooks(Books. Номер Like Forms! ПоискКниг! ПоискНомера & "*") And (Books. издательство Like Forms! ПоискКниг! ПоискИздательства & "*") And (Books. Автор Like Forms! ПоискКниг! ПоискАвтора & "*") And (Books. Название Like Forms! ПоискКниг! ПоискНазвания & "*") And (Books. Жанр Like Forms! ПоискКниг! ПоискЖанра & "*") And (Books. Серия Like Forms! ПоискКниг! ПоискСерии & "*");

2) Поиск скидки  покупателя (ПРОМЕЖУТОЧНАЯ)

Поиск скидки покупателя в  таблице "Покупатели":

 

Покупатели. ID_покупателя, Покупатели. СТАТУС, Покупатели. Скидка, Покупатели. Фамилия, Покупатели. Имя, Покупатели. ОтчествоПокупатели( ( (Покупатели. ID_покупателя) = [Forms]! [Продажи]! [ID_client]));

3) Цена с учетом  скидки покупателя

Расчет итоговой цены с  учетом скидки; покупатель, не имеющий  регистрации в БД, имеет ID=1 и не имеет скидки.

 

Books. Цена, [Поиск скидки покупателя]. Скидка,. Цена - [Поиск скидки покупателя]. Скидка AS ITOGBooks, [Поиск скидки покупателя]Books. Номер=Forms! Продажи! NumberBooks;

4) Продажи_добавлениеВсчета (ДОБАВЛЕНИЕ)

Регистрация продажи: добавление в таблицу "Счета" итоговой цены, номера книги, покупателя, сотрудника

 

INTO Счета ([Номер книги], [Цена продажи], Покупатель, Сотрудник)Books. Номер, [Цена с учетом скидки]. ITOG, [Поиск скидки покупателя]. ID_покупателя, Сотрудники. ID_сотрудникаBooks, [Цена с учетом скидки], [Поиск скидки покупателя], Сотрудники(Books. Номер=Forms! Продажи! NumberBooks) And (Сотрудники. ID_сотрудника=Forms! Продажи! Prodavez);

5) Уменьшение на 1 (Обновление)

Обновление таблицы Books: уменьшение количества книг после продажи

 

Books, Сотрудники SET Books. количество = Books. количество-1(номер=Forms! Продажи! NumberBooks) And (Сотрудники. ID_сотрудника=Forms! Продажи! Prodavez);

6) Удаление строк  (УДАЛЕНИЕ)

Запрос на удаление срок в таблице Books, если количество <1*BooksКоличество<1;

7) Вархив (ДОБАВЛЕНИЕ)

Запрос на добавление данных в Архив после регистрации  продажи

 

INTO АРХИВпроданныхКНИГ (Название, Автор, Серия, Жанр, Издательство)Books. Название, Books. Автор, Books. Серия, Books. Жанр, Books. ИздательствоBooks, Сотрудники(Books. Номер=Forms! Продажи! NumberBooks) And (Сотрудники. ID_сотрудника=Forms! Продажи! Prodavez);

8) количество проданных  книг по авторам (сериям) (Перекрестный  запрос)

 

Last (Books. Количество) AS [Last-Количество]Books. АвторСерии INNER JOIN Books ON Серии. ID_серии = Books. СерияBY Books. АвторСерии. [Название серии];

9) Статистика

Запрос на расчет максимальной, минимальной и т.п. цен проданных  книг