Файл: Тема курсовой работы Разработка базы данных магазина бытовой техники. Целью курсовой работы является разработка базы данных магазина бытовой техники. 4.docx
Добавлен: 18.03.2024
Просмотров: 76
Скачиваний: 0
СОДЕРЖАНИЕ
1. Теоретические основы проектирования и разработки баз данных
1.1. Основные принципы проектирования реляционных баз данных
1.2. Этапы физической реализации проектируемой базы данных
3. Даталогическое и инфологическое проектирование по выбранной теме курсового проекта
3.1. Определение сущностей, атрибутов, взаимосвязей между сущностями, ключей
3.2. Построение диаграмм ER-типа с учетом всех сущностей и их связей
3.3. Проведение процесса нормализации и денормализации
3.5. Схема проектируемой базы данных
3.6. Проектирование ER-модели в реляционную модель
4. Физическая реализация проектируемой базы данных
4.1. Средства создания, изменения описания, удаления таблиц и данных
4.2. Формирование простых и сложных запросов к базе данных
Принятые решения по изложенным вопросам вносятся в сопутствующие документы.
4. Создание стратегии по защите базы данных. База данных является важным корпоративным ресурсом, и для создания ее защиты уделяется особое внимание. Для создания оптимальной защиты проектировщики обязаны иметь исчерпывающее представление обо всех имеющихся в выбранной СУБД средствах защиты.
5. Организация контроля и наблюдения за функционированием базы данных, настройка. После завершения создания физического проекта базы данных организуется непрерывный мониторинг ее работы. Полученная информация о степени производительности базы данных используется для ее дальнейшей настройки. Для этого используются и средства выбранной СУБД.
Решения о внесении любых изменений в функционирующую базу данных должны быть обдуманными и тщательно взвешенными.
2. Существующая организация бизнес-процессов и процессов обработки данных исследуемого объекта по теме курсового проекта
Областью применения базы данных является магазин бытовой техники. Работа продавца магазина состоит в следующем: обеспечение продажи товара, формирование счета на оплату покупки, владение информацией о наличии товара на складе и о самом продаваемом товаре.
Работа менеджера магазина состоит в анализе продаж товаров, наличия товаров на складах; добавлении или изменении информации о товарах, поставщиках, покупателях, партиях товара.
Для этого нужна совместная база данных, включающая всю необходимую информацию. Программа является очень актуальной на сегодняшний день, т.к. она автоматизирует работу с базой данных.
В базе данных банка используются следующие входные данные:
– информация о товаре;
– информация о продаже товаров;
– информация о покупателях;
- информация поставщиках и партиях товара.
Выходной информацией являются результаты работы запросов, на печать информация выводится в виде отчетов, а именно:
-
Счет на оплату покупки; -
Итоги дня; -
Вывод товара по поставщику; -
Наличие товара на складе; -
Анализ продажи товаров.
При работе с базой данных продавец должен уметь решать следующие задачи такие, как:
-
Обеспечение продажи товара; -
Формирование счета на оплату покупки; -
Владеть информацией о наличии товара на складе и о продаваемом товаре;
Менеджер магазина должен уметь решать следующие задачи:
-
Анализ продаж товаров, наличие товаров на складах; -
Добавление или изменение информации о товарах, поставщиках, покупателях, партиях товара.
3. Даталогическое и инфологическое проектирование по выбранной теме курсового проекта
Инфологическая модель создается по результатам проведения исследований предметной области. Инфологическая модель представляет собой описание будущей базы данных, представленное с помощью естественного языка, формул, графиков, диаграмм, таблиц и других средств, понятных как разработчикам БД, так и обычным пользователям. Назначение такой модели состоит в адекватном описании процессов, информационных потоков, функций системы с помощью общедоступного и понятного языка, что делает возможным привлечение экспертов предметной области, консультантов, пользователей для обсуждения модели и внесения исправлений. В данном случае под созданием инфологической модели будем понимать именно ее создание для БД. В общем случае, инфологическая модель может создаваться для любой проектируемой системы и представляет ее описание (в общем случае в произвольной форме).
Создание инфологической модели является естественным продолжением исследований предметной области, но в отличие от него является представлением БД с точки зрения проектировщика (разработчика). Наглядность представления такой модели позволяет экспертам предметной области оценить ее точность и внести исправления. От правильности модели зависит успех дальнейшей разработки [7].
3.1. Определение сущностей, атрибутов, взаимосвязей между сущностями, ключей
В проекте «База данных магазина бытовой техники» в соответствии с предметной областью были созданы следующие сущности:
-
«Товары» – хранится информация об продаваемых в магазине товарах; -
«Типы товаров» – хранится информация о типах продаваемого товара; -
«Производители» – хранится информация о производителях товара; -
«Партии товара» – хранится информация о партиях поступившего в магазин товара; -
«Поставщики» – хранится информация о поставщиках поступившего в магазин товара; -
«Продажи» – хранится информация о продажах товара; -
«Покупатели» – хранится информация о покупателях товара;
Каждому объекту соответствуют свои атрибуты:
-
«Товары» – Код товара, Код типа, Название, Код производителя, Дата выпуска, Срок гарантии, Цена, Номер партии, Количество на складе, Изображение; -
«Типы товаров» – Код типа, Наименование; -
«Производители» – Номер производителя, Производитель; -
«Партии товара» – Номер партии, Номер поставщика, Дата; -
«Поставщики» – Номер поставщика, Название; -
«Продажи» – Номер покупателя, Код товара, Количество, Дата покупки, Скидка %; -
«Покупатели» – Номер покупателя, Фамилия (Название фирмы), Имя, Отчество, Номер паспорта, Контактный телефон, Номер кредитного счета.
Выберем для каждой сущности ключевые атрибуты, однозначно определяющие сущность. Для сущности «Товары» это будет уникальный код товара, для сущности «Типы товаров» это будет уникальный код типа. Сущность «Производители» определяется уникальным номером производителя, сущность «Партии товара» - уникальным номером партии. Сущность «Поставщики» определяется уникальным номером поставщика. Для сущности «Продажи» будет составной ключ Номер покупателя и код товара и для сущности «Покупатели» - уникальный номер покупателя.
При проведении связи между сущностями первичный ключ главной сущности помещается в дочернюю сущность, то есть в сущность «Товары» будет вставлен первичный ключ сущности «Типы товаров» - Код типа, а также первичный ключ сущности «Производители» - Код производителя и сущности «Партии товара» - Номер партии. В сущность Партии товара будет вставлен первичный ключ сущности «Поставщики» - Номер поставщика.
В базе данных банка определены следующие отношения между таблицами:
Таблица 3.1.1. – Классификация связей
№ | Родительская таблица | Дочерняя таблица | Ключи | Вид связи | |
1 | Типы товаров | Товары | Код типа | Код типа | 1:М |
2 | Производители | Товары | Номер производителя | Номер производителя | 1:М |
3 | Партии товара | Товары | Номер партии | Номер партии | 1:М |
4 | Поставщики | Партии товара | Номер поставщика | Номер поставщика | 1:М |
5 | Товары | Продажи | Код товара | Код товара | 1:М |
6 | Покупатели | Продажи | Номер покупателя | Номер покупателя | 1:М |
Выбор таких связей между таблицами «Типы товаров», «Товары» и «Производители», «Товары» обусловлен тем что, у одного типа товаров может быть несколько марок, и один Производитель может выпускать несколько товаров. Выбор связи между таблицами «Партии товара» и «Товары» обусловлен тем что, в одной партии товара может быть несколько товаров. Выбор связи между таблицами «Поставщики» и «Партии товара» обусловлен тем что, в один поставщик может поставить в магазин несколько партий. Выбор таких связей между таблицами «Товары», «Продажи» и «Покупатели», «Продажи» обусловлен тем что, один товар может продаваться несколько раз, и один покупатель может приобрести несколько товаров.
3.2. Построение диаграмм ER-типа с учетом всех сущностей и их связей
Существует несколько способов описания инфологической модели, однако, в настоящее время одним из наиболее широко распространенных подходов, применяемых при инфологическом моделировании, является подход, основанный на применении диаграмм «сущность-связь» (ER – Entity Relationship) [1].
На рисунке 3.2.1 представлена инфoлoгическaя модель базы данных, на которой отображены все сущности БД, отношение между ними и атрибуты.
Рисунок 3.2.1 – Инфологическая модель базы данных
3.3. Проведение процесса нормализации и денормализации
Описание процедуры нормализации и определения 1НФ, 2РФ, 3НФ и НФБК [1]:
-
Первая нормальная форма. Переменная-отношение находится в 1НФ тогда и только тогда, когда ее в любом допустимом значении этой переменной-отношения каждый ее кортеж содержит только одно значение для каждого из атрибутов. -
Вторая нормальная форма. Переменная-отношение находится в 2НФ тогда и только тогда, когда она находится в первой нормальной форме и каждый неключевой атрибут неприводимо зависит от ее первичного ключа. -
Третья нормальная форма. Переменная-отношение находится в 3НФ тогда и только тогда, когда она находится во второй нормальной форме и каждый неключевой атрибут нетранзитивно зависит от ее первичного ключа. Под нетранзитивной зависимостью подразумевается отсутствие какой-либо взаимной зависимости. -
Переменная-отношение находится в нормальной форме Бойса-Кодда тогда и только тогда, когда детерменанты всех ее функциональных зависимостей являются потенциальными ключами.
В базе данных банка проведена нормализация отношений:
Проанализировав таблицу «Товары», можно сделать вывод, что она находится в первой нормaльной фoрме, так как она имеет первичный ключ, каждое поле таблицы представляет уникaльный тип инфoрмации, все поля атомарны. Так же данная таблица находится и во 2НФ, так как она удовлетворяет условиям 1НФ, а так же каждое поле функционально зависит от пeрвичнoгo ключa, кoтoрый идeнтифицируeт исхoдный oбъект тaблицы. Тaблица «Товары» нaходится в 3НФ, так как она находится во 2НФ и не coдержит трaнзитивных зaвисимостей, т.е. столбцы, не являющиеся ключевыми, зaвисят от первичнoго ключа тaблицы и не зависят от всeх ocтальных стoлбцoв. Можно изменять значения любого поля (не входящего в первичный ключ) без воздействия на данные других полей. Таблица «Товары» находится в БКНФ, т.к она находится в 3НФ и в ней отсутствуют зависимости ключей от неключевых атрибутов [4].
Остальные таблицы аналогично таблице «Товары» находятся во всех четырех нормальных формах.
Таким обрaзом, прoанaлизирoвaв рaзрaбoтaнную бaзу дaнных, мoжнo сделать вывод, что она нормализована и соответствует четырем нормальным формам.
3.5. Схема проектируемой базы данных
При даталогическом моделировании используется инфологическая модель предметной области. При этом основной целью даталогического моделирования является описание свойств понятий предметной области, их взаимосвязь и ограничения, накладываемые на данные. Даталогическая модель является начальным прообразом создаваемой базы данных. Все понятия, выделенные при исследовании предметной области, и их взаимосвязи в будущем будут преобразованы в конкретные структуры какой-либо конкретной базы данных.
Результатом создания даталогической модели является модель, построенная с учетом выбранной модели данных, полученная путем реорганизации инфологической модели с учетом установленных правил.
Итак, даталогическая модель отражает структуру БД с учетом особенностей модели данных. Так как сейчас наиболее популярной является реляционная модель данных, рассмотрим преобразование инфологической модели в даталогическую реляционную модель.
На рисунке 3.5.1. пpивeдена схема бaзы дaнных магазина бытовой техники.
Рисунoк 3.5.1. – Сxeма бaзы дaнных магазина бытовой техники
3.6. Проектирование ER-модели в реляционную модель
Рассмотрим правила преобразования ER-модели в реляционную модель[3].
-
Каждой сущности ставится в соответствие отношение реляционной модели данных. При этом имена сущности и отношения могут быть разными, потому что на имена сущностей не накладываются дополнительные синтаксические ограничения, кроме уникальности имени в рамках модели. -
Каждый атрибут сущности становится атрибутом соответствующего отношения. Для каждого атрибута задается конкретный тип данных допустимый в СУБД и обязательность или необязательность данного атрибута (то есть допустимость или недопустимость NULL значений для него). -
Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL). -
В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREIGN KEY). -
Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределенных значений (признак NULL). При обязательном типе связи атрибуты получают свойство отсутствия неопределенных значений (признак NOT NULL).