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

ОГЛАВЛЕНИЕ

  ВВЕДЕНИЕ…………………………………………………………………..…3

1. Описание предметной области…………………………………………......4
2. Постановка задачи и обзор методов ее решения………………………….5

2. Концептуальное проектирование. Перечень сущностей и

атрибутов ……………………………………………………..…………….......6

3. Инфологическое проектирование БД……………………………………....7

3.1 Модель «сущность-связь»……………………………………………7

3.2 Классификация связей…………………………………………….….8

4. Реляционная модель  БД………………………………………………….….9

4.1 Выбор ключей………………………………………………………....9

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

5. Физическое проектирование  БД…………………………………………..12

5.1 Состав таблиц БД……………………………………………………12

5.2 Запросы к БД…………………………………………………………13

ЗАКЛЮЧЕНИЕ…………………………………………………………….....15

БИБЛИОГРАФИЧЕСКИЙ СПИСОК………………………………………..16

 

 

 

 

 

ВВЕДЕНИЕ

 

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

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

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

 

 

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

 

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

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

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

Основные данные, которые  использовались в данной БД, были данные о книгах:

- уникальный номер  книги,

- имя книги,

- автор,

- стоимость книги,

- количество книг, имеющихся  на полках магазина,

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

- жанр,

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

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

 

 

 

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

 

Разработать базу данных в программе mysql для предметной области «Книжный магазин».

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

База данных предполагает ввод-вывод следующих данных:

1. Вводить данные о книгах;
2. Выводить информацию об имеющихся книгах по любому запросу.

В информационной системе  предполагается наличие следующих  функций:

ввод, редактирование и  удаление данных о книгах..

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

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

 

3. Концептуальное проектирование. Перечень сущностей и атрибутов

 

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

- книги;

- клиенты;

- бронирование;

Рассмотрим каждую сущность по отдельности.

Сущность «книги» содержит информацию обо всех книгах и имеет следующие атрибуты:

• id – уникальный номер книги;
• name – название книги;
• autor – автор;
• janr – жанр;
• izdatelstvo – издательство;
• kol-vo stranic – количество страниц;
• cena – цена каждой книги;
• nalichie – наличие в магазине.

Сущность «клиенты» содержит информацию о клиентах магазина и имеет следующие атрибуты:

• id– уникальный номер клиента;
• fam – фамилия;
• name – имя;
• otch – отчество;
• address – адрес.

Сущность «бронирование» содержит информацию о заказах книг и имеет следующие атрибуты:

• id_book – уникальный номер книги;
• id_client – уникальный номер клиента;
• date – дата бронирования.

3. Инфологическое проектирование БД

1.  Модель «сущность-связь»

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

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

Проблема представления  семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLeon) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель "сущность—связь", предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена "сущность—связь", или "Entity Relationship", стала фактическим стандартом при инфологическом моделировании баз данных.

Модель «сущность-связь» называют также «ER-моделью» (essence-сущность, relation-связь).

 

3.2    Классификация связей

При проектирование БД информацию обычно размещают в нескольких таблицах. Таблицы при этом связывают с семантикой информации. В реляционной СУБД для указания связей в таблице производят операции их связывания.

Сущности «книги» и  «бронирование», «клиенты» и «бронирование», соединены между собой связями «один ко многим» (Рисунок 1). Первая связь говорит о том, что одна книга может быть заказана несколько раз. Вторая связь говорит о том, что один клиент может создать множество заказов.

 

Рисунок 1

 

4.    Реляционная модель БД

 

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

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

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

1.   Выбор ключей

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

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

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

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

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

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

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

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

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

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

 

5. Физическое проектирование БД

 

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

3. Состав таблиц БД