Содержание
Введение…………………………………………………………………………..5
1 Концептуальная модель .................................................................................. 6
1.1
Описание объекта их атрибутов и связи между объектами. ................. 6
1.2
Описание функциональной зависимости предметной области ............ 8
1.3 Описание способов обработки и представление сведений хранимой в
базе данных информации ................................................................................... 9
1.4
Дополнительные требования к базе данных......................................... 10
1.5
Модель предметной области в виде схемы “Объекты связи” ............ 12
1.6
Выводы ..................................................................................................... 14
Логическая модель предметной области ..................................................... 15
2
2.1
Схема базовых отношений ..................................................................... 15
2.2
Домены атрибутов всех отношений ...................................................... 15
2.3
Построение множества функциональных зависимостей .................... 19
2.4
Построение неприводимых множеств функциональных зависимостей
…………………………………………………………………………...21
2.5
Построение множеств супер-ключей .................................................... 22
2.6
Построение множества потенциальных ключей .................................. 23
2.7
Выбор первичного ключа ....................................................................... 23
2.8
Нормализация отношений ...................................................................... 24
2.9
Разработка предиката для проверки целостности базы данных ......... 25
2.10 Виртуальная отношения базы данных .................................................. 26
2.11 Разработка реляционного выражения для реализации запросов........ 27
2.12 Выводы ..................................................................................................... 28
Жизненный цикл базы данных ..................................................................... 30
3
Изм.
3.1
Ввод исходной информации................................................................... 32
3.2
Обработка информации .......................................................................... 32
3.3
Получение выходной информации ........................................................ 33
3.4
Выводы ..................................................................................................... 33
Лист
№ докум.
Разраб.
Мартыненко Ю.О.
Провер.
Долгопятов А.Ю.
Реценз.
Н. Контр.
Утверд.
Подпись Дата
ПЗ.370000.000
Лит.
Пояснительная записка
Лист
Листов
3
43
ТИ (филиал) ДГТУ в г. Азове
Кафедра «ВТиП»
Физическая модель предметной области .................................................... 35
4
4.1
Физическая независимость данных ....................................................... 35
4.2
Логическая независимость данных ....................................................... 35
4.3
Дистрибутивная независимость данных ............................................... 36
4.4
Архитектура базы данных ...................................................................... 37
4.5
SQL запросы базы данных ...................................................................... 39
4.6
Выводы ..................................................................................................... 40
Заключение ........................................................................................................... 42
Перечень используемых информационных ресурсов ...................................... 43
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
4
Введение
Разработка серверного модуля CRM (Customer Relationship Management)
- системы представляет собой важную стадию в создании и оптимизации
системы управления взаимоотношениями с клиентами. Серверный модуль
играет ключевую роль в обеспечении надежности и эффективности работы
системы, позволяя обрабатывать данные, управлять бизнес-процессами и
обеспечивать безопасное хранение информации.
При разработке серверной логики CRM-системы необходимо учесть
требования бизнес-процессов и функциональные возможности самой CRMсистемы. Производится анализ и определяются, какие данные и операции
должны быть доступны, чтобы удовлетворить потребности пользователей и
бизнеса.
Затем проводится проектирование и создание серверного комплекса,
используя современные технологии программирования. Цель заключается в
создании надежной и масштабируемой системы, способной обеспечивать
эффективную работу CRM-системы. Разработка серверной части также
включает
в
себя
обеспечение
безопасности
данных
и
защиту
конфиденциальности при обработке информации.
Неотъемлемой частью процесса является интеграция серверного модуля
с фронтенд-интерфейсом и другими системами, обеспечивая синхронизацию
данных и обмен информацией. Также уделяется внимание мониторингу и
оптимизации производительности серверной системы.
Разработка серверного модуля CRM-системы – сложный и ответственный
процесс, требующий глубокого анализа и учета бизнес-потребностей.
Качественная серверная часть способствует надежной работе CRM-системы,
обеспечивает безопасность данных и обмен информацией, и в конечном итоге
способствует повышению эффективности управления взаимоотношениями с
клиентами.
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
5
1
Концептуальная модель
1.1
Описание объекта их атрибутов и связи между объектами.
В ходе разработки курсовой работы формируется концептуальная база
данных для эффективного управления библиотечным комплексом. Следует
отметить, что данная модель представляет лишь один из возможных подходов,
который подлежит настройке с учетом требований конкретных бизнес целей и
задач.
Представленная
концептуальная
модель
включает
стандартные
элементы, поля и взаимосвязи, характерные для систем администрирования
библиотек.
Объект в данной модели представляет собой конкретные данные или
функциональные компоненты, а атрибут – параметры, описывающие
характеристики объекта. Связи определяют взаимодействие и отношения
между различными объектами, что является ключевым элементом в структуре
программного интерфейса приложения, определяя логику передачи данных и
выполнения функциональных операций.
Модели базы данных:
1. “Reader” - содержит информацию о посетителях библиотеки,
включая такие параметры, как имя, фамилия, дата рождения, адрес, адрес
электронной почты, номер телефона, а также даты создания и обновления
записи.
2.
“Loan” - описывает информацию о займах книг читателями,
Добавлено примечание ([A1]): Сделать как в п.1
включая дату займа, дату срока возврата, фактическую дату возврата, а также
устанавливает связи с записями о книгах и читателями.
3.
“BookReview” - предоставляет возможность читателям оставлять
свои отзывы о книгах, включая текст отзыва, дату написания, рейтинг и связи с
конкретной книгой и читателем.
4.
Изм. Лист
“Book” - содержит информацию о книгах, включая название,
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
6
международный стандартный книжный номер (ISBN), возрастной рейтинг,
количество экземпляров, а также устанавливает связи с жанром, языком,
местоположением, автором и другой информацией.
“Genre” - описывает различные жанры книг, предоставляя
5.
параметры, такие как название, и устанавливает связи с соответствующими
книгами.
“Publisher” - представляет информацию об издателях, включая
6.
имя, адрес, адрес электронной почты, дату основания и связи с информацией о
книгах.
“Language” - описывает языки, на которых написаны книги,
7.
включая название языка и код языка, а также устанавливает связи с
соответствующими книгами.
“Location” - представляет информацию о расположении книг в
8.
библиотеке, включая комнату, стеллаж и полку, а также устанавливает связи с
книгами.
“Author” - описывает информацию об авторах книг, включая имя,
9.
фамилию, дату рождения, а также устанавливает связи с соответствующими
книгами и информацией.
10.
“Info” - предоставляет дополнительные сведения о книгах,
издателях и авторах, включая текст информации, веб-сайт, дату создания и
обновления записи, а также устанавливает связи с книгами, издателями и
авторами.
Эти
примеры
моделей
и
их
взаимосвязи
представляют
собой
концептуальное основание базы данных, предназначенной для управления
функциональностью библиотечного комплекса. Тем не менее, возможно
создание альтернативных моделей с разнообразными параметрами и связями,
адаптированных под конкретные требования и потребности организации.
Представленные
модели
и
их
взаимосвязи
демонстрируют
концептуальное строение базы данных, применимое для эффективного
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
7
управления библиотечными ресурсами. Однако есть возможность разработать
альтернативные варианты моделей, включая различные параметры и
взаимосвязи, соответственно требованиям и запросам.
1.2
Описание функциональной зависимости предметной области
Функциональная зависимость представляет собой взаимосвязь между
различными элементами или характеристиками, где значение одного элемента
определяет
значение
другого.
Это
понятие
позволяет
выявлять
и
систематизировать взаимосвязи в рамках системы или процесса.
1. Анализ функциональной зависимости в контексте CRM-системы и
разработки API (Application Programming Interface) - функций интерфейсного
модуля включает рассмотрение следующих ключевых аспектов: CRM-система
представляет собой основной инструмент для эффективного управления
взаимодействием с клиентами. Разработка API-функций интерфейсного модуля
является важной составной частью этой системы.
2.
Добавлено примечание ([A2]): Отступ везде так сделать
Взаимодействие с внешним приложением: API представляет
собой набор правил и протоколов, обеспечивающих внешним приложениям
взаимодействие с CRM-системой. API-функции интерфейсного модуля
облегчают сценарии обмена данными, улучшая пользовательский опыт и
позволяя внешним приложениям выполнять различные операции.
3.
Автоматическая синхронизация данных: Интеграция CRM-
системы с приложением через API-интерфейс автоматизирует синхронизацию
данных, обеспечивая актуальность и достоверность информации в системе.
4.
Создание гибких решений: API-функции интерфейсного модуля
предоставляют возможность создания гибких решений для оптимизации
процессов и улучшения взаимодействия с клиентами.
5.
Получение и передача данных: API-функции позволяют внешним
приложениям получать и передавать данные, что важно для обновления
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
8
информации о клиентах, создания новых записей, а также получения
статистики и аналитических данных для управленческих решений.
Авторизация и обработка запросов: Разработка API-функций
6.
включает в себя настройку механизмов авторизации и обработки запросов,
обеспечивая безопасное и эффективное взаимодействие с системой.
Учет особенностей и требований: Разработка API-функций
7.
интерфейсного модуля учитывает особенности конкретной CRM-системы,
обеспечивая оптимальное взаимодействие между ее компонентами.
В итоге, API-функции интерфейсного модуля играют ключевую роль в
раскрытии
потенциала
CRM-системы,
обеспечивая
максимальную
эффективность через непрерывный обмен данными, автоматизацию процессов
и улучшение пользовательского опыта.
1.3
Описание способов обработки и представление сведений
хранимой в базе данных информации
В процессе разработки API-функций интерфейсного модуля для CRMсистемы,
особое
внимание
уделяется
обеспечению
эффективного
взаимодействия между внешним приложением и самой CRM-системой. Ниже
представлено детальное описание данного аспекта:
1.
Извлечение данных через API: одним из ключевых методов
Добавлено примечание ([A3]): Везде исправить
обработки данных является возможность получения информации из базы
данных CRM-системы при помощи API-запросов. API предоставляет удобный
и структурированный доступ к данным, что позволяет внешнему приложению
запрашивать информацию о сущностях.
2.
Сортировка данных: внешнее приложение может использовать
API для сортировки данных в соответствии с собственными потребностями, что
дает пользователям приложений возможность выбирать способ отображения
информации.
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
9
Поддержка форматов данных: API обеспечивает представление
3.
данных в различных форматах, таких как JSON (JavaScript Object Notation) или
XML
(eXtensible
Markup
Это
Language).
дает
приложению-клиенту
возможность обрабатывать данные в наиболее удобном формате.
Обновление и создание данных: внешнее приложение может не
4.
только извлекать информацию, но и создавать новые записи или обновлять
существующие данные.
Аутентификация и авторизация: для обеспечения безопасности
5.
данных, API-функции интерфейсного модуля поддерживают механизмы
аутентификации и авторизации, гарантируя, что доступ к данным имеют только
авторизованные пользователи.
Документация API: для упрощения интеграции и использования
6.
API предоставляется документация, описывающая доступные методы,
параметры запросов и примеры использования. Документация является
важным ресурсом для разработчиков, интегрирующих внешнее приложение.
Вышеописанные методы обработки и представления данных из базы
CRM-системы через API-функции интерфейсного модуля обеспечивают
эффективное взаимодействие, гибкость и безопасность при работе с
информацией, что является ключевым элементом успешной разработки и
интеграции API-интерфейса CRM-системы.
1.4
Дополнительные требования к базе данных
Минимальные
и
максимальные
требования
для
использования
программы, работающей с базой данных, зависят от различных факторов, таких
как характер приложения, объем данных, количество пользователей и
требования к производительности.
Минимальные требования:
1.
Изм. Лист
Характеристики сервера базы данных:
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
10
2.
3.
•
Процессор: Двухъядерный, 2.0 ГГц.
•
Оперативная память: 4 ГБ.
•
Хранилище: 100 ГБ HDD/SSD.
Характеристики клиентского приложения:
•
Процессор: Одноядерный, 1.5 ГГц.
•
Оперативная память: 2 ГБ.
•
Дисплей: Разрешение 1280x720.
Тип подключения:
•
4.
Скорость Интернет-соединения: минимум 10 Мбит/с.
Системные требования ПО:
•
Операционная система: Windows 10, macOS 10.14+, Ubuntu
•
Браузер: последние версии Chrome, Firefox, Safari, Opera.
18.04+.
Максимальные требования:
1.
2.
3.
Характеристики сервера базы данных:
•
Процессор: Четырехъядерный или более, 3.0 ГГц.
•
Оперативная память: 16 ГБ или более.
•
Хранилище: 1 ТБ SSD.
Характеристики клиентского приложения:
•
Процессор: Двухъядерный, 2.5 ГГц.
•
Оперативная память: 8 ГБ.
•
Дисплей: Разрешение 1920x1080.
Тип подключения:
•
4.
Скорость Интернет-соединения: минимум 50 Мбит/с.
Системные требования ПО:
•
Операционная система: Windows 10 Pro, macOS 11+, Ubuntu
•
Браузер: последние версии Chrome, Firefox, Safari.
20.04+.
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
11
Дополнительные требования:
Безопасность:
1.
•
Применение механизмов шифрования данных.
•
Управление доступом с использованием ролевой модели.
•
Регулярное проведение аудита безопасности.
•
Масштабируемость:
•
Горизонтальное масштабирование сервера базы данных при
увеличении пользовательской базы.
•
Резервное копирование и восстановление:
•
Регулярное автоматизированное резервное копирование
•
Механизмы восстановления данных в случае сбоев.
•
Мониторинг и аналитика:
•
Системы мониторинга производительности базы данных.
•
Инструменты аналитики для отслеживания использования
данных.
ресурсов.
Оптимизация запросов:
2.
•
Регулярное тестирование и оптимизация запросов к базе
данных.
Добавлено примечание ([A4]): Отступы сделать
1.5
Модель предметной области в виде схемы “Объекты связи”
Схема "Объекты связи" или ER-диаграмма (Entity-Relationship Diagram),
представляет собой визуальный метод моделирования структуры данных в
определенной области. Этот метод применяется для наглядного отображения
взаимосвязей между сущностями и объектами в системе или приложении и
широко используется при проектировании баз данных и информационных
систем.
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
12
Примером предметной области, на которой можно проиллюстрировать
применение ER-диаграммы, является "Библиотека". В данном контексте
сущности могут включать в себя книги, авторов, читателей и библиотеки, а
связи между ними позволяют описать взаимодействие этих объектов в рамках
библиотечной системы. Рисунок 1 предоставляет схему «Объекты связи»,
демонстрирующую эту концепцию.
Рисунок 1 - схема "Объект связи"
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
13
1.6
Выводы
В первом разделе была представлена концептуальная модель предметной
области, включающая объекты, их атрибуты и взаимосвязи между ними.
Основные связи между объектами были детально описаны, а также были
учтены дополнительные требования к базе данных, такие как необходимость
поддержки
связей,
обеспечение
использование
безопасности
и
индексов,
осуществление
нормализация
регулярного
данных,
резервного
копирования. Кроме того, модель предметной области была представлена в
форме схемы "Объекты связи". Эти данные предоставляют основу для
разработки функциональности и API-функций серверного модуля CRMсистемы.
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
14
2
Логическая модель предметной области
2.1
Схема базовых отношений
Структура базы данных описывается с помощью схемы базовых
отношений, которая представляет собой обзор основных таблиц (отношений) в
базе данных. Эта схема включает в себя информацию о структуре каждой
таблицы, их атрибутах и взаимосвязях.
Таблицы представляют основные компоненты базы данных и определяют
структуру данных, которые будут храниться и взаимодействовать в системе.
Ниже приведены использованные таблицы и их поля:
1.
Reader (Читатель): id (PK), first name, last name, birth, address, email,
phone_number, createdAt, updatedAt
2.
Loan (Займ): id (PK), loan, due, fact_due, book (FK), reader (FK)
3.
BookReview (Отзыв о книге): id (PK), text, date, rating, book (FK),
loan (FK), reader (FK), createdAt, updatedAt
4.
Book (Книга): id (PK), title, ISBN, age_rating, count, genre (FK),
publisher (FK), language (FK), location (FK), author (FK), info (FK), createdAt,
updatedAt
5.
Genre (Жанр): id (PK), name, child (K)
6.
Publisher (Издатель): id (PK), name, address, email, founding, info
(FK), createdAt, updatedAt Language (Язык): id (PK), language, code
7.
Location (Местоположение): id (PK), room, rack, shelf
8.
Author (Автор): id (PK), first name, last name, birth, info (FK),
createdAt, updatedAt
Изм. Лист
9.
Info (Информация): id (PK), info, website, date, createdAt, updatedAt
2.2
Домены атрибутов всех отношений
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
15
1.
2.
3.
4.
Изм. Лист
Reader (Читатель):
•
id (PK): Идентификаторы читателя.
•
first name: Строки, представляющие имена читателей.
•
last name: Строки, представляющие фамилии читателей.
•
birth: Даты рождения.
•
address: Строки, представляющие адреса читателей.
•
email: Строки, представляющие адреса электронной почты.
•
phone_number: Строки, представляющие номера телефонов.
•
createdAt: Даты создания записей.
•
updatedAt: Даты обновления записей.
Loan (Займ):
•
id (PK): Идентификаторы займа.
•
loan: Даты займа.
•
due: Даты срока возврата.
•
fact_due: Фактические даты возврата.
•
book (FK): Внешние ключи, связанные с записями книги.
•
reader (FK): Внешние ключи, связанные с записями читателя.
BookReview (Отзыв о книге):
•
id (PK): Идентификаторы отзыва о книге.
•
text: Строки, представляющие тексты отзывов.
•
date: Даты отзывов.
•
rating: Числовые значения рейтинга.
•
book (FK): Внешние ключи, связанные с записями книги.
•
loan (FK): Внешние ключи, связанные с записями займа.
•
reader (FK): Внешние ключи, связанные с записями читателя.
•
createdAt: Даты создания записей.
•
updatedAt: Даты обновления записей.
Book (Книга):
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
16
•
id (PK): Идентификаторы книги.
•
title: Строки, представляющие названия книг.
•
ISBN: Строки, представляющие международные стандартные
книжные номера.
•
age_rating: Строки, представляющие возрастные рейтинги.
•
count: числовых значений количества.
•
genre (FK): Внешние ключи, связанные с записями жанра.
•
publisher (FK): Внешние ключи, связанные с записями
•
language (FK): Внешние ключи, связанные с записями языка.
•
location (FK): Внешние ключи, связанные с записями
Издателя.
местоположения.
•
author (FK): Внешние ключи, связанные с записями автора.
•
info
(FK):
Внешние
ключи,
связанные
с
записями
информации.
5.
•
createdAt: Даты создания записей.
•
updatedAt: Даты обновления записей.
Genre (Жанр):
•
id (PK): Идентификаторы жанра.
•
name: Строки, представляющие названия жанров.
•
child (K): Ключи, указывающие на связанные жанры внутри
данного жанра.
6.
Изм. Лист
Publisher (Издатель):
•
id (PK): Идентификаторы издателя.
•
name: Строки, представляющие имена Издателей.
•
address: Строки, представляющие адреса Издателей.
•
email: Строки, представляющие адреса электронной почты.
•
founding: Даты основания Издателя.
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
17
•
info
(FK):
Внешние
ключи,
связанные
с
записями
информации.
7.
•
createdAt: Даты создания записей.
•
updatedAt: Даты обновления записей.
Language (Язык):
8.
•
id (PK): Идентификаторы языка.
•
language: Строки, представляющие названия языков.
•
code: Строки, представляющие коды языков.
Location (Местоположение):
9.
•
id (PK): Идентификаторы местоположения.
•
room: Строки, представляющие комнаты.
•
rack: Строки, представляющие стеллажи.
•
shelf: Строки, представляющие полки.
Author (Автор):
•
id (PK): Идентификаторы автора.
•
first name: Строки, представляющие имена авторов.
•
last name: Строки, представляющие фамилии авторов.
•
birth: Даты рождения.
•
info
(FK):
Внешние
ключи,
связанные
с
записями
информации.
10.
Изм. Лист
•
createdAt: Даты создания записей.
•
updatedAt: Даты обновления записей.
Info (Информация):
•
id (PK): Идентификаторы информации.
•
info: Строки, представляющие дополнительные информации.
•
website: Строки, представляющие веб-сайты.
•
date: Даты.
•
createdAt: Даты создания записей.
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
18
•
2.3
updatedAt: Даты обновления записей.
Построение множества функциональных зависимостей
Для создания набора функциональных зависимостей (МФЗ) в базе
данных необходимо провести анализ взаимосвязей между атрибутами таблиц.
Функциональные зависимости определяют, как значения одного набора
атрибутов влияют на значения другого набора.
Ниже приведен список МФЗ таблиц:
1.
Reader (Читатель):
•
{id}
->
{first_name,
last_name,
birth,
address,
email,
phone_number, createdAt, updatedAt}
•
{email}
->
{id,
first_name,
last_name,
birth,
address,
phone_number, createdAt, updatedAt}
2.
3.
4.
Loan (Займ):
•
{id} -> {loan, due, fact_due, book, reader}
•
{book} -> {id, loan, due, fact_due, reader}
BookReview (Отзыв о книге):
•
{id} -> {text, date, rating, book, loan, reader}
•
{book} -> {id, text, date, rating, loan, reader}
•
{reader} -> {id, text, date, rating, book, loan}
Book (Книга):
•
{id} -> {title, ISBN, age_rating, count, genre, publisher, language,
location, author, info, createdAt, updatedAt}
•
{ISBN} -> {id, title, age_rating, count, genre, publisher, language,
location, author, info, createdAt, updatedAt}
•
{title} -> {id, ISBN, age_rating, count, genre, publisher, language,
location, author, info, createdAt, updatedAt}
•
Изм. Лист
№ докум.
{genre} -> {id, title, ISBN, age_rating, count, publisher, language,
Подп.
Дата
ПЗ.370000.000
Лист.
19
location, author, info, createdAt, updatedAt}
•
{publisher} -> {id, title, ISBN, age_rating, count, genre, language,
location, author, info, createdAt, updatedAt}
•
{language} -> {id, title, ISBN, age_rating, count, genre, publisher,
location, author, info, createdAt, updatedAt}
•
{location} -> {id, title, ISBN, age_rating, count, genre, publisher,
language, author, info, createdAt, updatedAt}
•
{author} -> {id, title, ISBN, age_rating, count, genre, publisher,
language, location, info, createdAt, updatedAt}
•
{info} -> {id, title, ISBN, age_rating, count, genre, publisher,
language, location, author, createdAt, updatedAt}
Genre (Жанр):
5.
•
{id} -> {name, child}
•
{name} -> {id, child}
Publisher (Издатель):
6.
•
{id} -> {name, address, email, founding, info, createdAt,
•
{name} -> {id, address, email, founding, info, createdAt,
updatedAt}
updatedAt}
7.
8.
9.
Изм. Лист
Language (Язык):
•
{id} -> {language, code}
•
{language} -> {id, code}
•
{code} -> {id, language}
Location (Местоположение):
•
{id} -> {room, rack, shelf}
•
{room} -> {id, rack, shelf}
•
{rack} -> {id, room, shelf}
•
{shelf} -> {id, room, rack}
Author (Автор):
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
20
10.
•
{id} -> {first_name, last_name, birth, info, createdAt, updatedAt}
•
{first_name, last_name} -> {id, birth, info, createdAt, updatedAt}
Info (Информация):
•
2.4
{id} -> {info, website, date, createdAt, updatedAt}
Построение
неприводимых
множеств
функциональных
зависимостей
Неприводимые множества функциональных зависимостей (НМФЗ)
формируются из исходного множества функциональных зависимостей (МФЗ)
путем удаления избыточных зависимостей.
Ниже приведен список НМФЗ таблиц:
1.
Reader (Читатель)
•
{id} -> {first name, last name, birth, address, email,
phone_number, createdAt, updatedAt}
2.
Loan (Займ)
•
{id} -> {loan, due, fact_due, book}
•
{book} -> {title, ISBN, age_rating, count, genre, publisher,
language, location, author, info, createdAt, updatedAt}
•
{reader} -> {first name, last name, birth, address, email,
phone_number}
3.
BookReview (Отзыв о книге)
•
{id} -> {text, date, rating, book, loan, reader}
•
{book} -> {title, ISBN, age_rating, count, genre, publisher,
language, location, author, info, createdAt, updatedAt}
•
{reader} -> {first name, last name, birth, address, email,
phone_number}
•
4.
Изм. Лист
{loan} -> {loan, due, fact_due, book}
Book (Книга)
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
21
•
{id} -> {title, ISBN, age_rating, count, genre, publisher, language,
location, author, info, createdAt, updatedAt}
•
{genre} -> {name}
•
{publisher} -> {name, address, email, founding, info, createdAt,
•
{language} -> {language, code}
•
{location} -> {room, rack, shelf}
•
{author} -> {first name, last name, birth, info, createdAt,
•
{info} -> {info, website, date, createdAt, updatedAt}
updatedAt}
updatedAt}
2.5
Построение множеств супер-ключей
Супер-ключи представляют собой уникальные комбинации атрибутов,
которые служат для идентификации каждой записи в таблице. Все супер-ключи
уникальны в контексте данной таблицы и могут включать как один, так и
несколько атрибутов. Супер-ключи представляют более общее понятие и могут
включать в себя потенциальные ключи.
Ниже приведен список ключей таблиц:
Изм. Лист
1.
Reader (Читатель): {id}, {email}
2.
Loan (Займ): {id}, {id, book}, {book, reader}
3.
BookReview (Отзыв о книге): {id}, {id, book, reader}, {book, reader}
4.
Book (Книга): {id}, {ISBN}, {title, author}
5.
Genre (Жанр): {id}, {name}
6.
Publisher (Издатель): {id}, {name}
7.
Language (Язык): {id}, {language}, {code}
8.
Location (Местоположение): {id}, {room, rack, shelf}
9.
Author (Автор): {id}, {first_name, last_name}
10.
Info (Информация): {id}
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
22
2.6
Построение множества потенциальных ключей
Потенциальный ключ представляет собой уникальную комбинацию
атрибутов, рассматриваемую как кандидат на роль основного ключа. Основной
ключ используется для гарантированной уникальной идентификации записей.
Потенциальные ключи могут служить основой для выбора основного ключа и
обычно определяются в соответствии с требованиями к функциональной
зависимости и уникальности. Из множества потенциальных ключей может быть
выбран один в качестве основного ключа, который фактически будет
использоваться для идентификации записей в данном отношении.
Ниже приведен список потенциальных ключей таблиц:
1.
Reader (Читатель): {id}, {email}
2.
Loan (Займ): {id}, {book, reader}
3.
BookReview (Отзыв о книге): {id}, {book, reader}
4.
Book (Книга): {id}, {ISBN}, {title, author}
5.
Genre (Жанр): {id}, {name}
6.
Publisher (Издатель): {id}, {name}
7.
Language (Язык): {id}, {language, code}
8.
Location (Местоположение): {id}, {room, rack, shelf}
9.
Author (Автор): {id}, {first_name, last_name}
10.
Info (Информация): {id}
2.7
Выбор первичного ключа
Первичный ключ представляет собой уникальный идентификатор для
каждой записи в базе данных. Этот ключ гарантирует, что каждая запись в
таблице обладает уникальным значением, обеспечивая таким образом
уникальную идентификацию в пределах таблицы. Помимо этого, первичный
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
23
ключ может быть использован для установления связей между различными
таблицами в базе данных. Типы первичных ключей могут включать
целочисленные значения, GUID или другие уникальные идентификаторы.
Использование первичного ключа включает следующие аспекты:
Уникальность: Первичный ключ гарантирует, что каждое значение
1.
в этом ключе уникально для каждой записи, обеспечивая корректную
идентификацию каждой строки в таблице.
Связи: Первичный ключ может быть использован для установления
2.
связей между разными таблицами. Например, в таблицах "Авторы" и "Книги"
первичный ключ в таблице "Авторы" может быть использован в качестве
внешнего ключа в таблице "Книги" для установления связи между ними.
Индексирование:
3.
Обычно
первичный
ключ
автоматически
индексируется, что улучшает эффективность операций поиска и сортировки
данных в таблице.
2.8
Нормализация отношений
Нормализация в базе данных представляет собой метод организации
данных в таблицах с целью уменьшения избыточности и зависимостей, что в
итоге способствует повышению структурированности базы данных и ее
эффективности.
Процесс
нормализации
направлен
на
устранение
повторяющихся данных и предотвращение аномалий при выполнении
операций вставки, обновления и удаления записей. Существует несколько
нормальных форм, определяющих различные уровни нормализации. От первой
нормальной формы (1NF) до пятой нормальной формы (5NF) они
предоставляют стандарты для оценки структуры данных.
Вот краткое описание некоторых из них:
1.
Первая нормальная форма (1NF):
▪
Изм. Лист
№ докум.
Все
Подп.
значения
Дата
в
таблице
должны
быть
ПЗ.370000.000
атомарными
Лист.
24
(неделимыми).
▪
Все столбцы должны содержать только простые значения, а
не списки, множества или другие таблицы.
Вторая нормальная форма (2NF):
2.
▪
Таблица должна быть в 1NF.
▪
Все не ключевые атрибуты должны полностью зависеть от
первичного ключа.
Третья нормальная форма (3NF):
3.
▪
Таблица должна быть в 2NF.
▪
Нет транзитивных зависимостей: не ключевые атрибуты не
должны зависеть от других не ключевых атрибутов.
Четвертая нормальная форма (4NF):
4.
▪
Таблица должна быть в 3NF.
▪
Зависимость должна быть только от ключа, а не от других не
ключевых атрибутов.
Пятая нормальная форма (5NF):
5.
▪
Таблица должна быть в 4NF.
•
Представляет собой дополнительный уровень разделения для
устранения зависимостей между не ключевыми атрибутами.
Применение этих нормальных форм зависит от конкретных требований
базы данных и приложения. В ходе процесса нормализации часто приходится
создавать дополнительные таблицы, реорганизовывать данные и устанавливать
связи между ними для достижения желаемого уровня нормализации.
2.9
Разработка предиката для проверки целостности базы данных
Добавлено примечание ([A5]): Это?
Для обеспечения надежности и согласованности данных в базе данных
разрабатываются предикаты, которые представляют собой условия проверки
целостности. Каждый предикат представляет собой логическое выражение,
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
25
устанавливающее требования, которым должны соответствовать данные в базе.
В рамках данной курсовой работы были созданы предикаты для проверки
следующих аспектов целостности:
Целостность сущности (Entity Integrity):
1.
•
Разработан
предикат,
который
гарантирует,
что
все
обязательные атрибуты в записи отношения "Reader" содержат значения, и что
отсутствуют записи с пропущенными обязательными атрибутами.
Ссылочная целостность (Referential Integrity):
2.
•
Разработаны предикаты для проверки того, что значения во
внешних ключах, таких как "book" и "reader" в отношении "Loan", всегда
ссылаются на существующие записи в соответствующих таблицах "Book" и
"Reader".
3.
Правила уникальности (Unique Constraints):
•
Разработаны предикаты для проверки уникальности значений
в ключевых атрибутах, таких как "id", "ISBN", "name" и других, чтобы избежать
нарушений уникальности и предотвратить появление дубликатов.
Реализация
этих
предикатов
обеспечивает
надежность
данных,
предотвращает ошибки и снижает вероятность появления несогласованности в
базе данных. Предикаты могут быть интегрированы в структуру базы данных
или использованы в триггерах и ограничениях для автоматической проверки
данных при их вставке, обновлении или удалении.
2.10 Виртуальная отношения базы данных
Виртуальные отношения в базе данных представляют собой средство для
оптимизации доступа и анализа данных. Существует несколько методов
реализации виртуальных отношений, обеспечивающих удобство запросов и
агрегирования данных.
1.
Изм. Лист
Представления (Views): В базах данных представление – это
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
26
виртуальная таблица, формируемая результатом выполнения запроса SELECT.
Эти данные не хранятся физически, а предоставляют удобный способ доступа
к информации в базе данных. Например, можно создать представление для
отображения только активных сотрудников, что упростит выполнение
запросов.
2.
Виртуальные таблицы с использованием JOIN: Иногда для
получения нужной информации применяется соединение (JOIN) между
таблицами, создавая временное виртуальное отношение на основе данных из
нескольких таблиц. Например, можно соединить таблицы с информацией о
клиентах и заказах для получения данных о заказах каждого клиента.
3.
Вычисляемые столбцы: Вычисляемые столбцы – это виртуальные
столбцы в таблице, значения которых автоматически вычисляются на основе
других столбцов. Например, в таблице с данными о кругах можно добавить
вычисляемый столбец для площади круга на основе радиуса.
4.
Виртуальные отношения в объектно-реляционных СУБД: В
определенных базах данных, таких как PostgreSQL с использованием типов
данных JSONB или HSTORE, можно создавать виртуальные отношения внутри
записей. Например, в таблице сотрудников можно использовать поле JSONB
для хранения дополнительной информации, создавая тем самым вложенные
виртуальные структуры данных.
Виртуальные отношения в базах данных предоставляют гибкость в
доступе к данным. Однако следует учитывать, что такие отношения не хранятся
постоянно и могут повлиять на производительность при выполнении сложных
запросов. Поэтому оценка баланса между удобством использования и
производительностью является важным аспектом при разработке баз данных.
2.11 Разработка реляционного выражения для реализации запросов
Реляционная алгебра представляет собой математическую систему,
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
27
применяемую для создания запросов в реляционных базах данных. Она
включает в себя набор операторов, которые позволяют выполнять различные
операции с данными в таблицах.
Некоторые из основных реляционных операторов включают в себя:
1.
Выбор (Selection):
•
Оператор выбора возвращает строки из таблицы, которые
соответствуют определенному условию.
2.
Проекция (Projection):
•
Оператор
проекции
возвращает
только
определенные
столбцы из таблицы.
3.
Переименование (Renaming):
•
4.
Оператор переименования изменяет имя атрибута в таблице.
Соединение (Join):
•
Оператор соединения объединяет строки из двух таблиц на
основе совпадения значений в определенных столбцах.
5.
Объединение (Union):
•
Оператор объединения возвращает все уникальные строки из
двух таблиц.
Эти операторы используются для формулировки запросов, обеспечивая
гибкость при извлечении и обработке данных в реляционных базах данных.
Реляционная алгебра является теоретической основой, на которой базируются
многие языки запросов, включая SQL.
2.12 Выводы
В данном разделе проводится формализация структуры данных и их
взаимосвязей в рамках конкретной предметной области. Основная цель этого
раздела заключается в создании абстрактного представления данных, которое
послужит основой для разработки физической базы данных.
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
28
Логическая модель предметной области включает в себя описание
сущностей (таблиц), их атрибутов (столбцов) и связей между ними. Важным
элементом является также определение первичных и внешних ключей,
обеспечивающих целостность данных.
При создании логической модели необходимо учитывать бизнес-правила,
требования к производительности и предоставляемую функциональность. Эта
модель служит основой для построения физической базы данных и формирует
основу для разработки запросов и манипуляций с данными.
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
29
3
Жизненный цикл базы данных
Добавлено примечание ([A6]): Применительно к вашей
работе дать обоснование
Уровни базы данных обычно связаны с организацией данных и их
взаимодействием.
Ниже приведены уровни проектирования:
1.
Изм. Лист
Физический уровень (Physical Level): Описывает, как данные
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
30
фактически хранятся в базе данных, включая детали хранения таблиц, индексы,
кластеризацию и т.д.
Логический уровень (Logical Level): Определяет структуру
2.
данных без конкретной реализации. Модели данных, такие как Book, Author,
Reader и др., представлены в виде таблиц с ключами.
Концептуальный уровень (Conceptual Level) Предоставляет
3.
абстракцию данных, отражая бизнес-структуру. Сущности, такие как Книга
(Book), Автор (Author), Читатель (Reader), Займ (Loan), определяются с их
отношениями и атрибутами.
Видовой уровень (View Level):
4.
Определяет, как пользователи видят данные, например, представления
данных в виде отчетов или списков.
В базе данных CRM-системы библиотеки представлены следующие
сущности и их атрибуты:
1.
Book (Книга): ID, Название, ISBN, Год выпуска, Издатель, Язык,
Жанр и др.
2.
Author (Автор): ID, Имя, Фамилия, Дата рождения, Биография и др.
3.
Reader (Читатель): ID, Имя, Фамилия, Дата рождения, Адрес, Email
4.
Loan
и др.
(Займ):
ID,
ID_Книги,
ID_Читателя,
Дата_Взятия,
Дата_Возврата и др.
5.
Genre (Жанр): ID, Название и др.
6.
Location (Местоположение): ID, Название, Адрес и др.
7.
Language (Язык): ID, Название и др.
8.
Publisher (Издатель): ID, Название, Адрес и др.
9.
BookReview (Рецензия на книгу): ID, ID_Книги, Оценка,
Комментарий и др.
10. Biography (Биография): ID, ID_Автора, Текст и др.
Эти сущности взаимосвязаны через ключи, обеспечивая эффективную
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
31
организацию и обработку информации в базе данных CRM-системы
библиотеки.
3.1
Ввод исходной информации
Идентификация требований пользователей и бизнеса для библиотечной
системы
включает
в
себя
понимание
потребностей
библиотекарей,
администраторов и читателей. Например, эти требования могут охватывать
учет книг, контроль процессов выдачи и возврата, а также генерацию отчетов о
доступности литературы.
Процесс сбора данных начинается с анализа текущих библиотечных
процессов и выявления информации о книгах, читателях и операциях займа или
возврата. Собранные данные могут включать в себя названия книг, авторов,
сведения о читателях, сроки займа и другие соответствующие параметры.
На
основе
выявленных
потребностей
и
полученных
данных
разрабатывается структура базы данных.
Пример приведен ниже:
Таблица "Books" с полями: id (PK), title, author, ISBN, genre,
1.
available_copies.
Таблица "Readers" с полями: id (PK), first_name, last_name,
2.
birth_date, contact_info.
Таблица "Loans" с полями: id (PK), book_id (FK), reader_id (FK),
3.
loan_date, due_date, return_date.
3.2
Обработка информации
Этап обработки включает в себя наполнение базы данных начальной
информацией в соответствии с ее структурой. В контексте библиотечной
системы это включает добавление сведений о книгах, читателях и операциях
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
32
займа/возврата. Примерами могут быть внесение в базу данных новых книг с
указанием их названия, автора, ISBN и доступных экземпляров.
Регулярное обновление и
внесение
изменений
в базу
данных
представляют собой важный аспект обработки информации. Это может
включать в себя изменение статуса книги, такое как обновление количества
доступных копий, а также обновление данных о читателях и отметки о возврате
книг.
Обеспечение целостности данных и соблюдение ограничений и правил
базы данных имеет особое значение для библиотечной системы. Например,
система должна предотвращать попытки взять в аренду книгу, которая уже
находится в аренде, а также запрещать изменение данных читателя без
соответствующих прав.
3.3
Получение выходной информации
На этапе получения выходной информации разрабатываются запросы для
извлечения информации из базы данных библиотеки. Например, система может
создавать отчеты о доступных экземплярах каждой книги, о задолженностях
или о наиболее популярных жанрах.
Инструменты анализа данных могут применяться для извлечения ценной
информации. Например, анализ популярности определенных авторов или
жанров книг может помочь библиотеке принимать более обоснованные
решения по пополнению своей коллекции.
Полученные
результаты
предоставляются
пользователям
и
заинтересованным сторонам. Это может включать формирование отчетов о
текущем
состоянии
библиотеки,
динамике
аренды
книг,
а
также
предоставление информации для управленческих решений.
3.4
Изм. Лист
Выводы
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
33
При рассмотрении жизненного цикла базы данных в контексте
библиотечной системы выделяются три основных этапа: ввод исходной
информации, обработка данных и получение выходной информации.
На этапе ввода исходной информации определяются потребности
пользователей
и
бизнеса,
собирается
первоначальная
информация
и
разрабатывается структура базы данных. Эти шаги служат основой для
создания эффективной системы управления библиотекой.
Этап обработки информации включает в себя внесение данных, их
регулярное обновление и поддержание целостности. Эти меры не только
поддерживают актуальность данных, но и гарантируют их правильность в
системе.
На этапе получения выходной информации формируются запросы,
проводится анализ данных, и предоставляются результаты. Эти процессы
позволяют системе принимать информированные решения и совершенствовать
свою функциональность.
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
34
4
Физическая модель предметной области
4.1
Физическая независимость данных
Принцип физической независимости данных в области баз данных
заключается в том, что логическая структура данных, такая как таблицы и
отношения, отделена от физической организации данных на уровне их
хранения. Это означает, что изменения в физической структуре базы данных не
должны сказываться на приложениях или запросах пользователей.
Основные концепции физической независимости данных включают:
Абстракция уровня данных: Пользователи и приложения
1.
взаимодействуют с логической моделью данных, не беспокоясь о том, где и как
физически хранятся эти данные. Это упрощает процессы разработки и делает
систему более гибкой.
Изменение структуры без воздействия: Администраторы баз
2.
данных могут изменять физическую структуру, например, добавлять индексы
или изменять методы хранения, без необходимости изменения запросов и
приложений, использующих эти данные.
Оптимизация для производительности: Администраторы могут
3.
оптимизировать физическую структуру
базы
данных для улучшения
производительности, не внося изменений в логическую модель данных.
Принцип физической независимости данных является ключевым для
реляционных баз данных, таких как Oracle, MySQL или PostgreSQL. Этот
принцип способствует гибкости и эффективности при управлении данными в
различных условиях и требованиях системы.
4.2
Логическая независимость данных
Логическая независимость данных в базах данных — это принцип,
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
35
который утверждает, что внесение изменений в логическую структуру базы
данных не должно требовать соответствующих изменений в приложениях,
использующих эти данные.
Основные аспекты этого принципа включают следующее:
Изменение структуры данных: Администраторы баз данных
1.
могут вносить изменения в логическую структуру данных, такие как
добавление новых таблиц или модификация существующих полей и связей, не
затрагивая функциональность приложений, работающих с этими данными.
Сохранение совместимости с приложениями: Приложения,
2.
предназначенные для работы с базой данных, продолжают корректно
функционировать после внесения изменений в её структуру. Это обеспечивает
стабильность работы системы при развитии базы данных.
Абстракция от физической реализации: Пользователи и
3.
приложения взаимодействуют с абстрактной логической моделью данных, не
беспокоясь о том, как эти данные хранятся на физическом уровне. Это
обеспечивает гибкость и удобство использования базы данных.
Принцип логической независимости данных представляет собой важный
аспект реляционных баз данных, где данные организованы в виде таблиц и
отношений между ними. Этот принцип способствует устойчивости системы к
изменениям и упрощает процессы управления базами данных.
4.3
Дистрибутивная независимость данных
Принцип дистрибутивной независимости данных в области баз данных
подразумевает, что организация логической структуры данных не зависит от
физического размещения данных на различных узлах или серверах в
распределённой базе данных. Этот принцип направлен на обеспечение
эффективного управления данными в сценариях, где данные обрабатываются и
хранятся на нескольких компьютерах или серверах.
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
36
Основные аспекты дистрибутивной независимости данных включают
следующее:
Распределение данных: Возможность физического распределения
1.
базы данных по различным узлам или серверам без воздействия на логическую
структуру данных. Это способствует более эффективному использованию
ресурсов и повышает отказоустойчивость.
Прозрачность для пользователя: Пользователи и приложения
2.
могут взаимодействовать с данными так, будто они централизованы, не
обращая внимания на то, где физически хранятся эти данные. Дистрибутивная
независимость обеспечивает абстракцию от распределения данных.
Управление распределением: Возможность администраторам баз
3.
данных изменять физическое распределение данных без воздействия на
логическую структуру. Это важно при необходимости масштабирования
системы или оптимизации производительности.
Дистрибутивная
независимость
данных
особенно
важна
в
распределённых базах данных, где данные размещаются на различных серверах
в разных частях мира. Такие системы обеспечивают балансировку нагрузки,
повышают
отказоустойчивость
и
обеспечивают
более
эффективное
использование ресурсов. Примеры распределённых баз данных включают
Apache Cassandra, Amazon DynamoDB и Google Spanner.
4.4
Архитектура базы данных
1.
Внешний уровень:
На внешнем уровне базы данных предоставляется удобный интерфейс
для конечных пользователей и внешних приложений. Этот уровень включает в
себя:
•
Пользовательские интерфейсы: Веб-приложение для читателей:
Позволяет пользователям искать книги, просматривать свои займы, читать
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
37
отзывы и оставлять свои.
•
API для взаимодействия: RESTful API: Обеспечивает сторонние
приложения возможностью взаимодействия с базой данных.
•
Отчеты и аналитика: Модуль отчетов: Генерирует отчеты по
различным аспектам работы библиотеки, таким как популярность книг,
активность читателей и т.д.
2.
Концептуальный уровень:
На концептуальном уровне определены основные сущности и связи
между ними, а также бизнес-правила. Этот уровень включает:
•
Сущности и связи: Читатель, Займ, Отзыв, Книга, Жанр, Издатель,
Язык, Местоположение, Автор, Информация.
•
Связи между сущностями: Например, связи между Читателем и
Займом, Книгой и Жанром, Книгой и Автором.
•
Бизнес-правила: Ограничения на займы: Например, максимальный
срок займа, количество одновременных займов для одного читателя.
•
Целостность данных: Гарантирует соблюдение стандартов и правил
для данных, например, правила формирования ISBN.
3.
Внутренний уровень:
На внутреннем уровне определены структуры данных, процедуры
обработки данных и механизмы обеспечения целостности данных. Этот
уровень включает:
•
Логическая структура: Таблицы: для хранения данных о Читателях,
Займах, Отзывах, Книгах и других основных сущностях.
•
Индексы: для оптимизации поиска данных и ускорения выполнения
запросов. Процедуры и триггеры:
•
Хранимые
процедуры:
реализуют
бизнес-логику,
например,
процесс оформления нового займа или расчет статистики.
•
Триггеры: обеспечивают автоматическую обработку событий,
например, обновление статуса книги после ее возврата.
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
38
•
Безопасность и управление доступом:
•
Роли и права доступа: гарантируют, что только авторизованные
пользователи имеют доступ к чувствительным данным.
Эта трехуровневая архитектура обеспечивает эффективное управление
базой данных, удобство использования для конечных пользователей и
безопасность операций внутри системы.
4.5
SQL запросы базы данных
Ниже приведен пример некоторых SQL-запросов примененные в данной
курсовой работе:
•
Выборка информации о читателях:
SELECT id, first_name,
phone_number
FROM Reader;
•
last_name,
birth,
address,
email,
Добавлено примечание ([A7]): Везде так сделать
Поиск книг по определенному жанру:
SELECT
b.title,
b.ISBN,
b.age_rating,
g.name
AS
genre,
a.first_name AS author_first_name, a.last_name AS author_last_name
FROM Book b
JOIN Genre g ON b.genre = g.id
JOIN Author a ON b.author = a.id
WHERE g.name = 'Фантастика';
•
Добавление нового читателя:
INSERT INTO Reader (first_name, last_name, birth, address,
email, phone_number, createdAt, updatedAt)
VALUES ('Дмитрий', 'Пучков', '1990-01-01', 'Улица Есенина,
д.10', 'puchok@example.com', '+7-999-111-11-11', NOW(), NOW());
•
Обновление информации о книге:
UPDATE Book
SET count = count - 1
WHERE id = 1001;
•
Удаление отзыва о книге:
DELETE FROM BookReview
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
39
WHERE id = 5001;
•
Подсчет количества книг определенного автора:
SELECT a.first_name, a.last_name, COUNT(b.id) AS book_count
FROM Author a
JOIN Book b ON a.id = b.author
GROUP BY a.id;
•
Получение информации о книгах, взятых в займ:
SELECT l.id AS loan_id, b.title, r.first_name, r.last_name,
l.loan, l.due, l.fact_due
FROM Loan l
JOIN Book b ON l.book = b.id
JOIN Reader r ON l.reader = r.id;
•
Поиск книг по ключевому слову в названии:
SELECT title, ISBN, genre.name AS genre, author.first_name,
author.last_name
FROM Book
JOIN Genre ON Book.genre = Genre.id
JOIN Author ON Book.author = Author.id
WHERE title LIKE '%приключения%';
4.6
Выводы
Создание базы данных для управления библиотечными ресурсами
представляет собой сложный и тщательно продуманный процесс. Структура
базы данных включает в себя ключевые сущности и связи между ними,
обеспечивая эффективное хранение данных и оперативный доступ к
информации. Многоуровневая архитектура, включающая концептуальный,
логический и физический уровни, обеспечивает гибкость и масштабируемость
системы.
Принципы нормализации данных и использование внешних ключей
гарантируют целостность и эффективность работы с данными. Внедрение
современных технологических тенденций, обеспечивает ее отзывчивость и
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
40
устойчивость к изменениям.
Эта база данных представляет собой надежный инструмент для
эффективного управления ресурсами библиотеки, учитывая потребности как
читателей, так и библиотечного персонала. Структура и функциональность
базы данных обеспечивают эффективную обработку запросов, поддержание
актуальности данных и обеспечивают высокий уровень обслуживания
пользователей библиотеки.
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
41
Заключение
В заключение, процесс создания интерфейсного модуля для CRMсистемы представляет собой сложный процесс, направленный на разработку
удобного и эффективного инструмента взаимодействия пользователей с
системой управления взаимоотношениями с клиентами. В ходе данного
процесса не только анализируются потребности пользователей и особенности
бизнес-процессов, но предоставляется персонализированный и интуитивно
понятный опыт для различных групп пользователей.
Основное внимание уделяется созданию простого, но функционального
модуля для CRM-системы, соответствующего современным стандартам и
тенденциям в области взаимодействия с данными. Целью является повышение
эффективности работы с CRM-системой, улучшение пользовательского опыта
и повышение уровня обслуживания клиентов.
Важным этапом также является интеграция модуля с основной CRMсистемой, обеспечивая надежную синхронизацию данных и обмен
информацией. При этом уделяется особое внимание вопросам безопасности
данных и конфиденциальности
Таким образом, высококачественный CRM-модуль способствует
повышению эффективности работы с системой. В совокупности все эти
аспекты делают разработку CRM-модуля значимым этапом в создании и
оптимизации CRM-системы.
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
42
Перечень используемых информационных ресурсов
Дунаев, В. В. "Базы данных. Язык SQL для студента." М.: БХВ-
1.
Петербург, 2021. - 288 с.
2.
Кантелон, М. "Node.js в действии." М.: Питер, 2020. - 810 с.
3.
Майкл, Дж. "Node.js. Путеводитель по технологии." Кирилл
Сухов. - М.: ДМК Пресс, 2020. - 416 с.
Майкл Дж. Хернандес, Вьескас, Джон Л. "SQL - запросы для
4.
простых смертных. Практическое руководство по манипулированию данными
в SQL." М.: ЛОРИ, 2013. - 458 с.
Моргунов Е. П. "PostgreSQL. Основы языка SQL: учебное
5.
пособие." СПб. : БХВ-Петербург, 2023.
Ригс Саймон. "Администрирование PostgreSQL 9. Книга
6.
рецептов." М.: ДМК Пресс, 2018.
Саймон, Ригс "PostgreSQL. Для профессионалов (+ CD)." М.: СПб:
7.
Питер, 2022.
Стоунз, Мэттью Ричард; Нейл. "PostgreSQL. Основы." М.: СПб:
8.
Символ-Плюс, 2022.
Уорсли, Дж. "PostgreSQL. Для профессионалов (+ CD)." Дж.
9.
Уорсли, Дж. Дрейк. - М.: СПб: Питер, 2022.
10.
Янг А. "Node.js в действии." А. Янг, Б. Мек, М. Кантелон. – 2-е
издание. – Санкт-Петербург: Питер, 2020.
Изм. Лист
№ докум.
Подп.
Дата
ПЗ.370000.000
Лист.
43
