база данных. База данных Ани. 3 Проектирование методом Сущностьсвязь

• Название: 3 Проектирование методом Сущностьсвязь
• Анкор: база данных
• Дата: 29.01.2022
• Размер: 2.28 Mb.
• Имя файла: База данных Ани.docx
• Тип: Реферат; #345412

Министерство науки и высшего образования Российской Федерации

Федеральное государственное бюджетное

образовательное учреждение высшего образования

«Комсомольский-на-Амуре государственный университет»
Факультет компьютерных технологий

Кафедра «Проектирование, управление и разработка информационных систем»

РАСЧЕТНО-ГРАФИЧЕСКАЯ РАБОТА

по дисциплине «Базы данных»

\

Преподаватель А.Н. Петрова

2021

Содержание

Введение 2

1 Анализ предметной области и постановка задачи 3

2 Информационно - логическое проектирование 7

3 Проектирование методом «Сущность-связь». 9

4 Использование CASE-средств при проектировании и реализации реляционных баз данных 10

5 Создание ограничения целостности для реляционной БД в СУБД MS SQL Server 16

6 Проектирование БД декомпозиционным методом. 19

Заключение 24

Список использованных источников 25

Введение

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

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

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

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

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

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

1 Анализ предметной области и постановка задачи

Основные объекты:

• 
  Сотрудники;
  
• 
  Товар;
  
• 
  Поставщики;
  

Основные процессы:

• 
  Поставка товара;
  
• 
  Продажа товара;
  

Периодичность выполнения процессов:

• 
  Снятие отчетов;
  
• 
  Поступление товара;
  
• 
  Проведение ревизии;
  
• 
  Сдача отчетов в налоговую;
  

Организационная структура фирмы приведена на рисунке 1.

Директор

Бухгалтер

Оператор

Продавец



Рисунок 1 – Организационная структура фирмы
Организация совместной работы: рабочие места, связанные локальной сетью.

Мотивация: контроль работы, повышение эффективности работы сотрудников, уменьшение времени на заказ товара.

На основании анализа предметной области были сформулированы следующие пункты технического задания:

Наименование автоматизированной системы: Автоматизированная система учета товара.

Цель создания системы:

• 
  повышение эффективности работы сотрудников магазина;
  
• 
  уменьшение времени на подготовку отчетов;
  
• 
  повышения контроля выполняемых работ сотрудниками;
  

Характер объекта автоматизации: Сведения о проданной поставки переносятся в архив ежемесячно.

Требования к функциям, выполняемым системой:

• 
  формирование заказов;
  
• 
  формирование отчетов по наличию товаров;
  
• 
  формирование отчетов по поставщикам;
  

Перечень входной информации:

• 
  Информация о товаре:
  

- код;

- наименование;

• 
  Информация о сотрудниках:
  

- фамилия, имя, отчество;

- табельный номер;

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

- контактные данные;

• 
  Поставщики:
  

-ИНН;

-название;

- фамилия, имя, отчество;

-телефон;

- электронная почта;

• 
  Приходная накладная:
  

-номер;

- дата;

- поставщик;

- оператор;

- список товаров;

- количество;

- цена;

• 
  Расходная накладная:
  

- номер;

- дата;

- оператор;

- список товаров;

- количество;

- цена;

Перечень выходной информации:

• 
  Расходная накладная
  

-номер;

-дата;

-оператор;

-список товаров;

-количество;

-цена;

• 
  Чек:
  

-номер;

-дата;

-продавец;

-список товаров;

-количество;

-цена;

• 
  Отчеты:
  

-отчет кассира;

-остатки на складе;

- движение товара за месяц;
Требование к программному обеспечению:

• 
  На сервере: ОС - Windows XP/7/8/10,  Веб-сервер - Apache версии не ниже 1.4.29;СУБД - MySQL версии не ниже 4.24.
  
• 
  На клиенте: ОС - Windows XP/7/8/10. 
  

Требования к техническому обеспечению:

• 
  На сервере: процессор - 4 ядра (8 логических потоков), частота – 3-3,5 ГГц, оперативная память - 32ГБ, SSD для SQL - 300 ГБ и больше,
  

HDD для IIS и документов 50 ГБ (зависит от размера хранимых в системе документов).

• 
  На клиенте: МФУ HP LaserJet Pro M28.
  

2 Информационно - логическое проектирование

Основной частью информационно-логической модели (ИЛМ) является ER – диаграмма (рисунок 2) , с нее и начинается создание модели.






Рисунок 2 – ER – диаграмма предметной области «Магазин»
Информационные потребности пользователей:

• 
  Директор:
  

-просматривает итоговые отчеты;

-подписывает документы;

• 
  Бухгалтер:
  

-ведет список сотрудников;

-готовит приказы;

-ведет счета;

-начисляет заработную плату;

-формирует отчеты;

• 
  Оператор:
  

-вносит товар в базу данных;

-формирует остатки на складе;

• 
  Продавец:
  

-заказывает товар;

-продажа товара;

Алгоритмические связи показателей:

При добавлении покупки остаток на складе должен уменьшиться (чек (покупка-цена) – остаток).

Обеспечение целостности данных:

Некоторые свойства объектов не могут иметь произвольные значения, а должны подчиняться определенным правилам:

• 
  В магазине отсутствуют сотрудники, являющиеся полными однофамильцами и рождены в один день, то есть набор полей «Фамилия, Имя, Отчество» и «Дата рождения» не могут дублироваться;
  
• 
  Количество товара и остаток >0;
  
• 
  Сумма целое положительное число;
  
• 
  Дата текущая ( getdate())
  

Лингвистические отношения:

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

Сотрудники – это занятые на предприятии работники, прошедшие специальную подготовку и имеющие опыт и навыки труда.

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

Код товара - уникальная последовательность цифр, которая присваивается товару после появления его описания на специальном ресурсе, где хранятся и учитываются все данные о товаре по номенклатуре.

Цена – количество денег, в обмен на которые продавец готов передать (продать) единицу товара. 

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

3 Проектирование методом «Сущность-связь».

Даталогическое проектирование является проектированием логической структуры БД.

При проектировании логической структуры БД осуществляются:

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

Полная схема данных реляционной БД приведена на рисунке 3.



Рисунок 3 – Схема БД «Магазин»

4 Использование CASE-средств при проектировании и реализации реляционных баз данных

Метод проектирования «Сущность-связь» был положен в основу программных продуктов, позволяющих на основе ER-диаграммы сгенерировать код на языке описания данных, которые создает таблицы и связи между ними. На рисунке 4 показано создание таблиц на основе ER-диаграммы.



Рисунок 4 – Создание таблиц в среде DB Designer Fork

На рисунке 5 показана созданная модель для предметной области «Магазин».



Рисунок 5 –Модель БД в среде DB Designer Fork

В среде DB Designer Fork существует два способа экспорта модели данных СУБД: генерация SQL-команды для создания таблиц и перенос данных через непосредственное подключение к БД.

Для того чтобы сгенерировать SQL-команды описания структуры данных, необходимо перейти в меню File-Export- SQL Create Script (рисунок 6).




Рисунок 6 – Команда экспорта кода

Для генерации команд SQL. После настройки всех параметров (рисунок 7), необходимо нажать кнопку «Save Script to file» и указать путь для сохранения файла. В результате будет сформирован файл с расширением sql. SQL-команды для таблиц:

CREATE TABLE Поставщики (

ИНН INTEGER NOT NULL IDENTITY ,

Название_организации VARCHAR(45) ,

ФИО VARCHAR(45) ,

Телефон INTEGER ,

Электронная_почта VARCHAR(45) ,

PRIMARY KEY(ИНН));

GO

CREATE TABLE Сотрудники (

Табельный_номер INTEGER NOT NULL IDENTITY ,

ФИО VARCHAR(45) ,

Дата_рождения DATE ,

Контактные_данные INTEGER ,

PRIMARY KEY(Табельный_номер));

GO


CREATE TABLE Товар (

код INTEGER NOT NULL IDENTITY ,

Наименование VARCHAR(45) ,

PRIMARY KEY(код ));

GO


CREATE TABLE Расход (

Номер_накладной_расход INTEGER NOT NULL IDENTITY ,

Сотрудники_Табельный_номер INTEGER NOT NULL ,

Дата_расход DATETIME ,

PRIMARY KEY(Номер_накладной_расход) ,

FOREIGN KEY(Сотрудники_Табельный_номер)

REFERENCES Сотрудники(Табельный_номер));

GO

CREATE INDEX Расход_FKIndex1 ON Расход (Сотрудники_Табельный_номер);

GO

CREATE INDEX IFK_Rel_01 ON Расход (Сотрудники_Табельный_номер);

GO

CREATE TABLE Приход (

Номер_накладной_приход INTEGER NOT NULL ,

Сотрудники_Табельный_номер INTEGER NOT NULL ,

Поставщики_ИНН INTEGER NOT NULL ,

Дата_приход DATETIME ,

PRIMARY KEY(Номер_накладной_приход) ,

FOREIGN KEY(Сотрудники_Табельный_номер)

REFERENCES Сотрудники(Табельный_номер),

FOREIGN KEY(Поставщики_ИНН)

REFERENCES Поставщики(ИНН));

GO

CREATE INDEX Приход_FKIndex1 ON Приход (Сотрудники_Табельный_номер);

GO

CREATE INDEX Приход_FKIndex2 ON Приход (Поставщики_ИНН);

GO

CREATE INDEX IFK_Rel_02 ON Приход (Сотрудники_Табельный_номер);

GO

CREATE INDEX IFK_Rel_03 ON Приход (Поставщики_ИНН);

GO

CREATE TABLE Перечень_товара_приход (

Номер_перечня INTEGER NOT NULL IDENTITY ,

Приход_Номер_накладной_приход INTEGER NOT NULL ,

Товар_код INTEGER NOT NULL ,

Количество INTEGER ,

Цена INTEGER ,

PRIMARY KEY(Номер_перечня) ,

FOREIGN KEY(Товар_код )

REFERENCES Товар(код ),

FOREIGN KEY(Приход_Номер_накладной_приход)

REFERENCES Приход(Номер_накладной_приход));

GO

CREATE INDEX Перечень_товара_приход_FKIndex1 ON Перечень_товара_приход (Товар_код );

GO

CREATE INDEX Перечень_товара_приход_FKIndex2 ON Перечень_товара_приход (Приход_Номер_накладной_приход);

GO

CREATE INDEX IFK_Rel_04 ON Перечень_товара_приход (Товар_код );

GO

CREATE INDEX IFK_Rel_08 ON Перечень_товара_приход (Приход_Номер_накладной_приход);

GO

CREATE TABLE Перечень_товара_расход (

Расход_Номер_накладной_расход INTEGER NOT NULL ,

Перечень_товара_приход_Номер_перечня INTEGER NOT NULL ,

Количество INTEGER ,

PRIMARY KEY(Расход_Номер_накладной_расход, Перечень_товара_приход_Номер_перечня) ,

FOREIGN KEY(Перечень_товара_приход_Номер_перечня)

REFERENCES Перечень_товара_приход(Номер_перечня),

FOREIGN KEY(Расход_Номер_накладной_расход)

REFERENCES Расход(Номер_накладной_расход));

GO

CREATE INDEX Перечень_товара_расход_FKIndex1 ON Перечень_товара_расход (Расход_Номер_накладной_расход);

GO

CREATE INDEX IFK_Rel_06 ON Перечень_товара_расход (Перечень_товара_приход_Номер_перечня);

GO

CREATE INDEX IFK_Rel_07 ON Перечень_товара_расход (Расход_Номер_накладной_расход);

G O


Рисунок 7 –Окно экспорта SQL команд

Запускаем Microsoft SQL Server 2014 (рисунок 8). После запуска необходимо пройти авторизацию, указав: вариант аутентификации, местонахождение и название сервера СУБД, имя пользователя и пароль.



Рисунок 8 – Запуск программы MS SQL Server

В итоге будет получена диаграмма БД, содержащая все таблицы и связи между ними (рисунок 9).



Рисунок 9 –Диаграмма БД

5 Создание ограничения целостности для реляционной БД в СУБД MS SQL Server

Зададим условие, что количество товара не может быть меньше нуля (рисунок 10).


Рисунок 8 –Ввод ограничений


Рисунок 10 – Окно задания ограничений


С оздание генерации объектов SQL Server (рисунок 11).

Рисунок 11- Генерация объектов с SQL Server

В результате добавления ограничения целостности были изменены косанды создания таблиц в :
Сотрудники_Табельный_номер INTEGER NOT NULL ,

Дата_расход DATETIME ,

PRIMARY KEY(Номер_накладной_расход) ,

FOREIGN KEY(Сотрудники_Табельный_номер)

REFERENCES Сотрудники(Табельный_номер));

GO

CREATE INDEX Расход_FKIndex1 ON Расход (Сотрудники_Табельный_номер);

GO

CREATE INDEX IFK_Rel_01 ON Расход (Сотрудники_Табельный_номер);

GO

CREATE TABLE Приход (

Номер_накладной_приход INTEGER NOT NULL ,

Сотрудники_Табельный_номер INTEGER NOT NULL ,

Поставщики_ИНН INTEGER NOT NULL ,

Дата_приход DATETIME ,

PRIMARY KEY(Номер_накладной_приход) ,

FOREIGN KEY(Сотрудники_Табельный_номер)

REFERENCES Сотрудники(Табельный_номер),

FOREIGN KEY(Поставщики_ИНН)

REFERENCES Поставщики(ИНН));

GO

CREATE INDEX Приход_FKIndex1 ON Приход (Сотрудники_Табельный_номер);

GO

CREATE INDEX Приход_FKIndex2 ON Приход (Поставщики_ИНН);

GO

CREATE INDEX IFK_Rel_02 ON Приход (Сотрудники_Табельный_номер);

GO

CREATE INDEX IFK_Rel_03 ON Приход (Поставщики_ИНН);

GO

CREATE TABLE Перечень_товара_приход (

Номер_перечня INTEGER NOT NULL IDENTITY ,

Приход_Номер_накладной_приход INTEGER NOT NULL ,

Товар_код INTEGER NOT NULL ,

Количество INTEGER ,

Цена INTEGER ,

PRIMARY KEY(Номер_перечня) ,

FOREIGN KEY(Товар_код )

REFERENCES Товар(код ),

FOREIGN KEY(Приход_Номер_накладной_приход)

REFERENCES Приход(Номер_накладной_приход));

GO

CREATE INDEX Перечень_товара_приход_FKIndex1 ON Перечень_товара_приход (Товар_код );

GO

CREATE INDEX Перечень_товара_приход_FKIndex2 ON Перечень_товара_приход (Приход_Номер_накладной_приход);

GO

CREATE INDEX IFK_Rel_04 ON Перечень_товара_приход (Товар_код );

GO

CREATE INDEX IFK_Rel_08 ON Перечень_товара_приход (Приход_Номер_накладной_приход);

GO

CREATE TABLE Перечень_товара_расход (

Расход_Номер_накладной_расход INTEGER NOT NULL ,

Перечень_товара_приход_Номер_перечня INTEGER NOT NULL ,

Количество INTEGER ,

PRIMARY KEY(Расход_Номер_накладной_расход, Перечень_товара_приход_Номер_перечня) ,

FOREIGN KEY(Перечень_товара_приход_Номер_перечня)

REFERENCES Перечень_товара_приход(Номер_перечня),

FOREIGN KEY(Расход_Номер_накладной_расход)

REFERENCES Расход(Номер_накладной_расход));

GO
CREATE INDEX Перечень_товара_расход_FKIndex1 ON Перечень_товара_расход (Расход_Номер_накладной_расход);

GO
CREATE INDEX IFK_Rel_06 ON Перечень_товара_расход (Перечень_товара_приход_Номер_перечня);

GO

CREATE INDEX IFK_Rel_07 ON Перечень_товара_расход (Расход_Номер_накладной_расход);

GO

6 Проектирование БД декомпозиционным методом.

Этапы проектирования:

• 
  Разрабатывается универсальное отношение для БД.
  
• 
  Определяются все функциональные зависимости между атрибутами данного отношения.
  
• 
  Определяется, находится ли отношение НФБК:
  

• 
  если да, то проектирование завершается;
  
• 
  если нет, то осуществляется декомпозиция по теореме Хита. Каждый определитель (с зависимыми полями)- в отдельную таблицу.
  

• 
  Шаги 2 и 3 повторяются для каждого нового отношения, полученного в результате декомпозиции. Проектирование завершается, когда все отношения будут находиться в НФБК.
  

О пределим функциональные зависимости. Результаты приведены на рисунках 12-15.

Рисунок 12 – Функциональные зависимости



Рисунок 13 – Функциональные зависимости таблиц Товар, Сотрудник, Поставщик_покупатель



Рисунок 14 – Функциональные зависимости таблиц

Приход и Расход


Рисунок 15 – Функциональные зависимости таблиц

Приход_товара и Расход_товара
Вывод: Схема данных «Сущность-связь» и декомпозиционная отличаются тем, что добавили поля: количество товара склад, цена товара розница, изменили ИНН на ИНН контрагент.

Покажем, что каждая проекция находится в НФБК:

1. 
   Отношение Товар:
   

• 
  находится в 1НФ так, как ключевое поле Код товара всегда заполнено, если код не известен, то нет потребности добавлять запись в таблицу, в каждом поле содержится по одному значению (все зависимости однозначные);
  
• 
  находится во 2 НФ, так как потенциальный ключ простой;
  
• 
  находится в 3 НФ так, как нет неключевых полей, зависящих от других неключевых полей;
  
• 
  находится в НФБК так, как единственный определитель функциональной зависимости является ключом отношения;
  
• 
  находится в 4 НФ так, как в отношении нет многозначной зависимости;
  
• 
  находится в 5 НФ так, как при любом разбиении отношения на проекции в проекциях ключами будут те же атрибуты, что и в исходном отношении;
  
• 
  Отношение Сотрудник:
  
• 
  находится в 1НФ так, как ключевое поле Код товара всегда заполнено, если код не известен, то нет потребности добавлять запись в таблицу, в каждом поле содержится по одному значению (все зависимости однозначные);
  
• 
  находится во 2 НФ, так как потенциальный ключ простой;
  
• 
  находится в 3 НФ так, как нет неключевых полей, зависящих от других неключевых полей;
  
• 
  находится в НФБК так, как единственный определитель функциональной зависимости является ключом отношения;
  
• 
  находится в 4 НФ так, как в отношении нет многозначной зависимости;
  
• 
  находится в 5 НФ так, как при любом разбиении отношения на проекции в проекциях ключами будут те же атрибуты, что и в исходном отношении;
  
• 
  Отношение Поставщик_Покупатель:
  
• 
  находится в 1НФ так, как ключевое поле Код товара всегда заполнено, если код не известен, то нет потребности добавлять запись в таблицу, в каждом поле содержится по одному значению (все зависимости однозначные);
  
• 
  находится во 2 НФ, так как потенциальный ключ простой;
  
• 
  находится в 3 НФ так, как нет неключевых полей, зависящих от других неключевых полей;
  
• 
  находится в НФБК так, как единственный определитель функциональной зависимости является ключом отношения;
  
• 
  находится в 4 НФ так, как в отношении нет многозначной зависимости;
  
• 
  находится в 5 НФ так, как при любом разбиении отношения на проекции в проекциях ключами будут те же атрибуты, что и в исходном отношении;
  
• 
  Отношение Приход_товара:
  
• 
  находится в 1НФ так, как при внесении записи в таблицу всегда известно номер накладной, иначе запись в таблицу не вносится (поэтому все ключевые поля заполнены), а так же в поле содержится по одному значению;
  
• 
  находится во 2 НФ, так как неключевое поле находится в полной функциональной зависимости от составного ключа и не зависит от его частей;
  
• 
  находится в 3 НФ так, как нет ключевых полей, зависящих от других неключевых полей;
  
• 
  находится в НФБК так, как единственный определитель функциональной зависимости является ключом отношения;
  
• 
  находится в 4 НФ так, как в отношении нет многозначной зависимости;
  
• 
  находится в 5 НФ так, как отношение не обладает полной декомпозицией, нет функциональных зависимостей, которые можно вынести в отдельную таблицу;
  
• 
  Отношение Расход_товара:
  
• 
  Находится в 1 НФ, 2 НФ, 3 НФ, 4НФ, 5 НФ, НФБК по тем же причинам что и отношение Приход_товара;
  
• 
  Отношение Приход:
  
• 
  Находится в 1 НФ, 2 НФ, 3 НФ, 4НФ, 5 НФ, НФБК по тем же причинам что и отношение Сотрудник.
  
• 
  Отношение Расход:
  
• 
  Находится в 1 НФ, 2 НФ, 3 НФ, 4НФ, 5 НФ, НФБК по тем же причинам что и отношение Сотрудник.
  

Заключение

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

Список использованных источников

1. 
   Петрова, А.Н. Проектирование баз данных: Учебное пособие/ А. Н. Петрова, В. Е. Степаненко. – Комсомольск-на-Амуре: ФГБО ВО «КнАГУ», 2018- 104с.