Отчет по практикеБазы данныхГод: 2025МТИ: Московский технологический институт
👁 18💼 0

Готовый отчет по практике: Соадминистрирование БД

Загружена: 15.02.2026 16:31

Проектирование и реализация реляционной базы для интернет‑магазина «СМ‑Сервис». Описаны инфологическая, логическая и физическая модели, реализованы 10 таблиц, триггеры Oracle и пример SQL‑скриптов. Полезно для отработки навыков администрирования и автоматизации серверной части.

Содержание

Образовательная автономная некоммерческая организация
высшего образования

«МОСКОВСКИЙ ТЕХНОЛОГИЧЕСКИЙ ИНСТИТУТ»

	


ОТЧЕТ 
о прохождении производственной практики
по профессиональному модулю ПМ.05 Соадминистрирование и автоматизация баз данных и серверов ОЗПИПо-22051
						     шифр и номер группы
Васильев Дмитрий Сергеевич 
 (Ф.И.О.)
 
Содержание:
1.	Организационный этап (инструктаж по проведению практики)
2.	Подготовительный этап (изучение организационной структуры объекта практики и особенностей деятельности выбранного магазина)
3.	Исследовательский этап (сбор информации об объекте практики и анализ содержания источников информации по практике)
4.	Проектный этап (экспериментально-практическая работа)
5.	Аналитический этап (обработка и анализ полученной информации об объекте практики, предложения и рекомендации)
6.	Отчетный этап (заполненные формы отчетности, документы, схемы, графики и прочее)

Введение

1. Характеристика базы практики, роль и место подразделения, в котором работал практикант в общей структуре организации, объем выполняемых подразделением работ и услуг в общем объеме операций и т.д.

Заключение

Выводы и предложения. Необходимо разработать конкретные предложения по усовершенствованию организации работы базы практики в рамках соответствующего профессионального модуля, что, по сути, становится итогом пройденной практики. При этом сравниваются результаты теоретического обучения с наблюдениями и выводами по работе в конкретной организации.
4. Приложения
Документальное подтверждение отдельных разделов, положений отчета (заполненные формы отчетности, документы, схемы, графики и прочее).
5. Литература
Законодательная база, №№ инструкций, приказов, распоряжений, учебные пособия, учебники и другая литература.
Дата: _____________	           					 Васильев Д.С.
(Подпись, инициалы студента)
Анализ предметной области
Компания, в которой проходила практика - ООО «СМ-Сервис»
Полное наименование: Общество с ограниченной ответственностью "СМ-Сервис"
ИНН: 7814501376
КПП: 781401001
ОГРН: 1117847197280
Место нахождения: 197371, г. Санкт-Петербург, пр-кт Комендантский, д. 21 корп. 2, 476
ООО "СМ-Сервис" — это компания, основанная в 2011 году, которая специализируется на ремонте компьютеров и периферийного оборудования. Компания также занимается оптовой и розничной торговлей компьютерной техникой и электроникой. Основной целью ООО "СМ-Сервис" является предоставление качественных услуг и товаров по конкурентоспособным ценам с удобным сервисом для клиентов.
Для достижения этой цели компания использует автоматизированную систему управления, которая обеспечивает эффективное управление заказами, товарами, клиентами и персоналом. Система включает в себя следующие функциональные возможности:
Функциональные требования:
Для клиентов:
Регистрация и авторизация: клиенты могут создавать учетные записи и входить в систему для доступа к личным данным и истории заказов.
Поиск товаров: клиенты могут искать товары по различным параметрам, таким как название, категория, производитель и цена.
Просмотр информации о товаре: клиенты могут просматривать подробную информацию о товаре, включая описание, характеристики, фотографии и отзывы.
Добавление товаров в корзину: клиенты могут добавлять выбранные товары в корзину для последующего оформления заказа.
Оформление заказа: клиенты могут оформлять заказы с выбором способа доставки и оплаты.
Отслеживание статуса заказа: клиенты могут отслеживать статус своих заказов в реальном времени.
Просмотр истории заказов: клиенты могут просматривать историю своих заказов и управлять ими.
Обратная связь с магазином: клиенты могут оставлять отзывы и обращаться в службу поддержки.
Управление личным профилем: клиенты могут изменять свои личные данные и адреса доставки.
Для сотрудников:
Управление каталогом товаров: сотрудники могут добавлять, редактировать и удалять товары в каталоге.
Обработка заказов: сотрудники могут подтверждать заказы, комплектовать их и отправлять.
Управление доставкой: сотрудники могут отслеживать доставку и взаимодействовать с курьерскими службами.
Управление клиентами: сотрудники могут просматривать информацию о клиентах и их истории заказов.
Формирование отчетов: сотрудники могут создавать отчеты по продажам, популярным товарам и другим показателям.
Управление акциями и скидками: сотрудники могут настраивать и управлять акциями и скидками.
Управление контентом сайта: сотрудники могут обновлять новости и баннеры на сайте.
Эти функциональные возможности позволяют ООО "СМ-Сервис" эффективно управлять своими бизнес-процессами и предоставлять клиентам высокий уровень сервиса.
Описание сущностей:
Пользователь (общая сущность для клиентов и сотрудников):
ID
ФИО
Дата рождения (опционально для клиентов)
Телефон
Email
Пароль (хешированный)
Роль (клиент, менеджер, администратор, курьер, бухгалтер и т.д.)
Клиент (наследует от Пользователя):
Адрес доставки (может быть несколько)
Почтовый индекс
Сотрудник (наследует от Пользователя):
Дата приема на работу
Должность
Данные о зарплате (доступ ограничен)
Товар:
ID
Наименование
Категория
Производитель
Цена
Срок гарантии
Описание
Характеристики (в виде JSON или отдельной таблицы)
Фотографии
Количество на складе
Заказ:
ID
Клиент (ссылка на сущность Клиент)
Дата заказа
Статус (новый, подтвержден, отправлен, доставлен, отменен)
Способ доставки
Способ оплаты
Адрес доставки
Стоимость доставки
Общая стоимость
Список товаров (связь многие-ко-многим с Товаром через промежуточную таблицу "Позиция заказа")
Позиция заказа:
ID
Заказ (ссылка на сущность Заказ)
Товар (ссылка на сущность Товар)
Количество
Цена на момент заказа
Чек:
ID
Заказ (ссылка на сущность Заказ)
Дата покупки
Сумма
Дополнительные аспекты:
Интеграция со сторонними сервисами: платежные системы, курьерские службы.
Безопасность: защита данных пользователей, предотвращение несанкционированного доступа.
Производительность: быстрая загрузка страниц, обработка заказов.
Масштабируемость: возможность расширения функциональности и увеличения объема данных.
Организационная структура:
Организационная структура "СМ-Сервис" включает в себя руководство (директор, менеджеры), отдел продаж, отдел логистики (курьеры, менеджеры по доставке), отдел закупок, бухгалтерию, IT-отдел (администраторы системы, разработчики). Система должна учитывать роли и права доступа каждого сотрудника.
Рисунок 1 - Организационная структура магазина “СМ-Сервис”
Требования к разрабатываемой БД «СМ-Сервис»
В соответствии с современными практиками разработки информационных систем и с учетом специфики "СМ-Сервис", сформулированы следующие требования:
2.1. Роли пользователей и права доступа:
Система должна поддерживать различные роли пользователей с разграничением прав доступа. Основные роли включают:
Администратор: Обладает полным доступом ко всем функциям системы, включая:
Управление пользователями (создание, редактирование, удаление, назначение ролей).
Управление каталогом товаров (добавление, редактирование, удаление, управление категориями и производителями).
Управление заказами (просмотр, редактирование, отмена, изменение статуса).
Управление контентом сайта (новости, баннеры, акции).
Просмотр отчетов и статистики.
Управление настройками системы.
Менеджер: Отвечает за обработку заказов и взаимодействие с клиентами:
Просмотр и редактирование информации о заказах (подтверждение, комплектация, изменение статуса).
Взаимодействие с курьерскими службами.
Генерация чеков и документов.
Обработка возвратов и обменов.
Коммуникация с клиентами (ответы на вопросы, решение проблем).
Клиент: Имеет доступ к функциям, связанным с покупкой товаров:
Регистрация и управление профилем.
Поиск и просмотр товаров.
Формирование и оформление заказов.
Отслеживание статуса заказов.
Просмотр истории заказов.
Оставление отзывов о товарах.
2.2. Ограничения и правила валидации данных:
Для обеспечения целостности и корректности данных в системе должны быть реализованы следующие ограничения и правила валидации:
Возраст сотрудников: При регистрации сотрудника должна проводиться проверка возраста (не менее 18 лет). Это может быть реализовано через запрос даты рождения или через интеграцию с государственными сервисами верификации.
Обязательные данные сотрудников: При регистрации сотрудника все поля, относящиеся к его должностным обязанностям (например, данные для начисления зарплаты, контактная информация), должны быть обязательными для заполнения.
Обязательные данные клиента при заказе: При оформлении заказа ФИО и номер телефона клиента должны быть обязательными для заполнения. Также необходимо предусмотреть валидацию формата вводимых данных (например, номера телефона).
Бесплатная доставка: При оформлении заказа на сумму от 10 000 рублей стоимость доставки должна автоматически обнуляться.
Валидация данных товаров: Цены на товары должны быть положительными числами. Наименования товаров не должны содержать специальных символов или скриптов.
Ограничение количества товара в заказе: Количество товара в заказе не должно превышать доступное количество на складе.
2.3. Требования к производительности и безопасности:
Производительность: Система должна обеспечивать быструю загрузку страниц и обработку запросов, особенно в периоды высокой нагрузки (например, во время акций или распродаж).
Безопасность: Система должна обеспечивать защиту данных пользователей от несанкционированного доступа. Необходимо использовать надежные методы аутентификации и авторизации, а также шифрование конфиденциальной информации. Регулярно проводить аудит безопасности и обновлять программное обеспечение.
Инфологическое проектирование базы данных
Инфологическая модель базы данных представляет собой абстрактное описание предметной области, ориентированное на восприятие человеком и не зависящее от конкретной системы управления базами данных (СУБД). Цель инфологического проектирования — создать понятную и непротиворечивую модель данных, отражающую сущности, их атрибуты и взаимосвязи.
Требования к инфологической модели:
Понятность и естественность: Модель должна использовать терминологию предметной области и быть легко понимаемой всеми заинтересованными сторонами (аналитиками, разработчиками, пользователями).
Корректность и полнота: Модель должна адекватно отражать все важные аспекты предметной области и обеспечивать целостность данных.
Простота и удобство использования: Модель должна быть достаточно простой для последующего преобразования в физическую модель данных.
Независимость от СУБД: Модель не должна зависеть от конкретной СУБД и ее особенностей.
Сущности и атрибуты:
На основе анализа предметной области выделены следующие сущности:
Пользователь: (обобщенная сущность для Клиента и Сотрудника)
ID (первичный ключ)
ФИО
Email
Телефон
Пароль
Клиент: (наследует атрибуты Пользователя)
Адрес доставки
Почтовый индекс
Сотрудник: (наследует атрибуты Пользователя)
Должность
Дата приема на работу
Товар:
ID (первичный ключ)
Наименование
Описание
Цена
Количество на складе
Срок гарантии
Категория:
ID (первичный ключ)
Наименование
Производитель:
ID (первичный ключ)
Наименование
Заказ:
ID (первичный ключ)
Дата создания
Статус
Способ доставки
Способ оплаты
Общая стоимость
Позиция заказа:
ID (первичный ключ)
Количество
Цена за единицу
Доставка:
ID (первичный ключ)
Адрес доставки
Дата доставки
Стоимость доставки
Статус доставки
Курьер (ссылка на Сотрудника с ролью "курьер")
Взаимосвязи между сущностями:
Пользователь - Клиент: 1:1 (один к одному)
Пользователь - Сотрудник: 1:1 (один к одному)
Товар - Категория: Многие-к-одному (Many-to-One)
Товар - Производитель: Многие-к-одному (Many-to-One)
Заказ - Клиент: Многие-к-одному (Many-to-One)
Заказ - Доставка: Один-к-одному (One-to-One)
Заказ - Позиция заказа: Один-ко-многим (One-to-Many)
Позиция заказа - Товар: Многие-к-одному (Many-to-One)
Логическое и даталогическое проектирование базы данных
Для логического проектирования выбрана реляционная модель данных, как наиболее распространенная и эффективная для организации данных интернет-магазина. Реляционная модель обеспечивает:
Отсутствие избыточности данных: Данные хранятся в нормализованных таблицах, что минимизирует дублирование информации и упрощает обновление данных.
Поддержание целостности данных: Механизмы ссылочной целостности гарантируют корректность связей между таблицами и предотвращают появление несогласованных данных.
Гибкость и масштабируемость: Реляционная модель позволяет легко добавлять новые таблицы и атрибуты, а также адаптироваться к изменяющимся требованиям бизнеса.
Даталогическое (физическое) проектирование:
Цель физического проектирования — создать схему базы данных, оптимизированную для конкретной СУБД, с учетом требований к производительности, безопасности и доступности.
Ниже представлена схема таблиц базы данных, разработанная на основе инфологической модели и учитывающая связи между сущностями.
Пользователи (Users):
user_id (INT, PRIMARY KEY)
ФИО (VARCHAR)
email (VARCHAR, UNIQUE)
телефон (VARCHAR)
пароль (VARCHAR) — хранить хешированный пароль
роль (ENUM: 'клиент', 'менеджер', 'администратор', 'курьер')
Клиенты (Clients):
user_id (INT, PRIMARY KEY, FOREIGN KEY referencing Users)
адрес_доставки (VARCHAR)
почтовый_индекс (VARCHAR)
Сотрудники (Employees):
user_id (INT, PRIMARY KEY, FOREIGN KEY referencing Users)
должность (VARCHAR)
дата_приема (DATE)
Товары (Products):
product_id (INT, PRIMARY KEY)
наименование (VARCHAR)
описание (TEXT)
цена (DECIMAL)
количество_на_складе (INT)
срок_гарантии (INT)
категория_id (INT, FOREIGN KEY referencing Categories)
производитель_id (INT, FOREIGN KEY referencing Manufacturers)
Категории (Categories):
category_id (INT, PRIMARY KEY)
наименование (VARCHAR)
Производители (Manufacturers):
manufacturer_id (INT, PRIMARY KEY)
наименование (VARCHAR)
Заказы (Orders):
order_id (INT, PRIMARY KEY)
user_id (INT, FOREIGN KEY referencing Users)
дата_создания (TIMESTAMP)
статус (ENUM: 'новый', 'подтвержден', 'отправлен', 'доставлен', 'отменен')
способ_доставки (VARCHAR)
способ_оплаты (VARCHAR)
общая_стоимость (DECIMAL)
Позиции_заказа (OrderItems):
order_item_id (INT, PRIMARY KEY)
order_id (INT, FOREIGN KEY referencing Orders)
product_id (INT, FOREIGN KEY referencing Products)
количество (INT)
цена_за_единицу (DECIMAL)
Доставки (Deliveries):
delivery_id (INT, PRIMARY KEY)
order_id (INT, FOREIGN KEY referencing Orders)
адрес_доставки (VARCHAR)
дата_доставки (DATE)
стоимость_доставки (DECIMAL)
статус_доставки (VARCHAR)
курьер_id (INT, FOREIGN KEY referencing Employees)
Физическое проектирование БД
На основе реляционной модели произведена программная реализация.
База данных содержит 10 таблиц:
Продавец
Клиент
Заказ
Доставка
Менеджер
Продажа товара
Товар
Категории
Производитель
Содержание чека
Таблица 1 - Продавцы (SELLER)
Таблица 2 - Менеджеры(MANAGER)
Таблица 3 - Клиенты(CLIENT)
Таблица 4 - Категории(CATEGORY)
Таблица 5 - Производитель(MAKER)
Таблица 6 - Товар(PRODUCT)
Таблица 7 - Продажа товара(CHEK_INFO)
Таблица 8 - Содержание чека(CHEK)
Таблица 9 - Доставка(DELIVERY)
Таблица 10 - Заказ(ORDERS)
Реализация ограничений. Безопасность и контроль.
База данных обслуживает три категории пользователей: администраторов, менеджеров и клиентов.
Администраторы обладают полными правами, контролируя все аспекты базы данных, включая изменение ее структуры и содержимого. Менеджеры имеют доступ к определенным данным и могут вносить необходимую информацию. Клиенты могут только просматривать информацию, релевантную их потребностям.
Для автоматизации правила "бесплатная доставка при заказе от 10000 рублей" используется следующий триггер:
CREATE OR REPLACE TRIGGER Orders_Trig
AFTER INSERT OR UPDATE ON ORDERS FOR EACH ROW
BEGIN
IF :new.SUMMA > 10000 THEN
UPDATE DELIVERY SET Price_Delivery = 0 WHERE ID_Order = :new.ID_Order;
END IF;
END;
Тестирование показало, что после изменения суммы заказа в таблице ORDERS цена доставки в таблице DELIVERY автоматически обнуляется.
Следующий триггер предназначен для расчета суммы чека в таблице "Продажа товара" путем умножения количества товара из таблицы "Содержание чека" на цену товара из таблицы "Товар":
CREATE OR REPLACE TRIGGER Chek_T
AFTER INSERT OR UPDATE ON CHEK_INFO
FOR EACH ROW
DECLARE pCost INT;
BEGIN
SELECT PRICE INTO pCost FROM PRODUCT WHERE ID_Product = :new.ID_Product;
UPDATE CHEK SET Summa = pCost * :new.Kolichestvo WHERE ID_Chek = :new.ID_Chek;
END;
Любые изменения в таблице CHEK_INFO автоматически пересчитывают сумму в таблице CHEK.
Третий триггер устанавливает цену товара в 5000 рублей, если производитель находится в Америке:
CREATE OR REPLACE TRIGGER Trig2
AFTER UPDATE ON MAKER FOR EACH ROW
BEGIN
IF :new.Country = 'America' THEN
UPDATE PRODUCT SET Price = 5000 WHERE ID_Maker = :new.ID_Maker;
END IF;
END;
Oracle предоставляет различные механизмы аутентификации. Базовая аутентификация требует от пользователя ввода имени и пароля при каждом подключении, независимо от используемого интерфейса. Доступ предоставляется только после успешной проверки учетных данных по таблице SYS.USERS, где пароли хранятся в зашифрованном виде.
Различные категории пользователей имеют разные права доступа. Простейший сценарий предполагает две роли: для ввода данных и для выполнения запросов. Однако, часто требуется более гранулированное управление доступом, что достигается динамическим формированием интерфейса в зависимости от роли пользователя.
Помимо аутентификации, необходимо ограничить доступ уполномоченных пользователей к конкретным данным.
При создании учетной записи пользователя администратор назначает ему профиль, определяющий лимиты на использование системных ресурсов, таких как процессорное время.
Oracle поддерживает системные и объектные привилегии. Системные привилегии предоставляют права на выполнение общих операций, например, SELECT ANY TABLE или UPDATE ANY TABLE. Объектные привилегии регулируют доступ к конкретным объектам базы данных, таким как таблицы, представления и последовательности. Оператор GRANT используется для предоставления привилегий.
Выводы
Разработанная база данных:
Полностью соответствует требованиям предметной области.
Содержит 10 взаимосвязанных таблиц, обеспечивающих хранение данных о товарах, клиентах, заказах, сотрудниках и пр.
Обеспечивает возможность добавления, изменения и удаления данных.
Включает триггеры для автоматизации расчета суммы чека, стоимости доставки и изменения цены для товаров производства Америка.
Реализованы ограничения целостности данных, а также разграничение прав доступа пользователей.
Полученные знания и навыки:
Углублено понимание принципов проектирования и реализации баз данных.
Освоены методы анализа предметной области, построения инфологических и логических моделей.
Приобретены практические навыки работы с СУБД Oracle (создание таблиц, запросы, триггеры).
Получен опыт работы в команде и взаимодействия с различными категориями пользователей.
Оценка результатов:
Разработанная база данных полностью выполняет поставленные задачи.
Процесс разработки позволил закрепить теоретические знания и применить их на практике. В процессе работы выявлены проблемы, связанные с недостаточной точностью первичных требований, и устранены в процессе работы.
Предложения и рекомендации по усовершенствованию:
Разработка веб-интерфейса: Разработать веб-приложение для взаимодействия клиентов с базой данных, чтобы они могли делать заказы, отслеживать их статус и просматривать историю покупок онлайн.
Интеграция с CRM-системой: Интегрировать базу данных с CRM (система управления взаимоотношениями с клиентами) для автоматизации процессов маркетинга и продаж, улучшения взаимодействия с клиентами.
Мобильное приложение для сотрудников: Разработать мобильное приложение для продавцов и курьеров для оперативного доступа к данным о товарах и заказах.
Аналитическая отчетность: Разработать систему аналитической отчетности для получения данных о продажах, популярности товаров, а также для прогнозирования спроса.
Оптимизация запросов и таблиц: Проводить регулярную оптимизацию базы данных и запросов для повышения производительности системы.
Регулярное резервное копирование: Организовать систему регулярного резервного копирования базы данных для обеспечения сохранности данных.
Список используемых источников
Основная литература:
Романенко М.Г. Системы электронного документооборота : учебное пособие (лабораторный практикум) / составители М. Г. Романенко. — Ставрополь : Северо-Кавказский федеральный университет, 2019. — 109 c.
Сизова, О. В. Управление электронным предприятием : учебное пособие / О. В. Сизова, О. П. Смирнова. — Саратов : Ай Пи Ар Медиа, 2019. — 143 c.
Степанова, Е. Н. Система электронного документооборота (облачное решение) : учебное пособие / Е. Н. Степанова. — Москва : Ай Пи Ар Медиа, 2021. — 182 c.
Кузнецов, С.Д. Базы данных. Модели и языки. — М.: Интернет-Университет Информационных Технологий, 2005. — 704 с.
Дейт, К.Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: Вильямс, 2006. — 1328 с.
Гарсиа-Молина, Г., Ульман, Дж., Уидом, Дж. Системы баз данных. Полный курс = Database System Implementation. — 2-е изд. — М.: Вильямс, 2003. — 1088 с.
Карпова, Т.С. Базы данных: модели, разработка, реализация / Т.С. Карпова. – СПб.: Питер, 2001. – 304 с.
Хомоненко, А. Д., Цыганков, В. М., Мальцев, М. Г. Базы данных : учебник для вузов / под ред. А. Д. Хомоненко. – 4-е изд. – СПб. : КОРОНА-Век, 2014. – 736 с.
Конноли, Т., Бегг, К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. — 3-е изд. — М.: Вильямс, 2003. — 1088 с.
Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендров. – М.: Финансы и статистика, 2004. – 208 с.
Дополнительная литература:
Гладкий, А. А. Компьютер для индивидуального предпринимателя. Как вести учет быстро, легко и безошибочно : практическое пособие : [16+] / А. А. Гладкий. – Москва ; Берлин : Директ-Медиа, 2020. – 217 с.
Яковенко В.С. Учет в торговле : учебное пособие / В. С. Яковенко, Е. И. Костюкова, М. Н. Татаринова, О. В. Ельчанинова ; под редакцией В. С. Яковенко. — Ставрополь : Секвойя, 2019. — 81 c.
Маклаков, С.В. BPwin и ERwin. CASE-средства разработки информационных систем / С.В. Маклаков. - М.: ДИАЛОГ-МИФИ, 2000. – 160 с.
Ортега, Э., Риос, А. Oracle Database 12c. Руководство разработчика : [пер. с англ.]. - М. : ДМК Пресс, 2017. – 622 c.
Зенкин, А. Oracle SQL. Полное руководство / А. Зенкин. — СПб.: БХВ-Петербург, 2017. — 704 с.
Бурбаки, Н. Теория множеств / Н. Бурбаки; [Пер. с фр. Е. М. Фейс]. — Москва: УРСС, 2004. — 496 с.
ПРИЛОЖЕНИЕ
Программный код базы данных
CREATE DATABASE smservice;
USE smservice;
CREATE TABLE CLIENT (
ID_Client int PRIMARY KEY,
FIO varchar(25) NOT NULL,
Birth_Date date NOT NULL,
Phone varchar(20) NOT NULL,
Address varchar(50) NOT NULL,
ZIP int NOT NULL);
CREATE SEQUENCE ID_Cl INCREMENT BY 1 START WITH 1;
INSERT INTO CLIENT (ID_Client, FIO, Birth_Date, Phone, Address, ZIP)
VALUES (ID_Cl.NEXTVAL, 'Shirokov V.N.', TO_DATE('1980/01/01', 'YYYY/MM/DD'), '9183212115', 'Moscow, Volgogradskaya, 31-15', '111352');
INSERT INTO CLIENT (ID_Client, FIO, Birth_Date, Phone, Address, ZIP)
VALUES (ID_Cl.NEXTVAL, 'Malaxova O.U.', TO_DATE('1990/11/22', 'YYYY/MM/DD'), '9031823574', 'Moscow, Komsomolskaya, 64-12', '196182');
INSERT INTO CLIENT (ID_Client, FIO, Birth_Date, Phone, Address, ZIP)
VALUES (ID_Cl.NEXTVAL, 'Nikolaev A.N.', TO_DATE('1989/04/13', 'YYYY/MM/DD'), '9032183131', 'Moscow, Zelenaya, 25-18', '315112');
CREATE TABLE SELLER (
ID_Seller int PRIMARY KEY,
FIO varchar(25) NOT NULL,
Birth_Date date NOT NULL,
Pasport int NOT NULL,
Phone varchar(20) NOT NULL,
Address varchar(50) NOT NULL,
Date_Priema date NOT NULL);
CREATE SEQUENCE ID_Sel INCREMENT BY 1 START WITH 1;
INSERT INTO SELLER (ID_Seller, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)
VALUES (ID_Sel.NEXTVAL, 'Ivanov I.I.', TO_DATE('1991/05/13', 'YYYY/MM/DD'), '6115348243', '9051237816', 'Moscow, Aviamotornaya, 34-8', TO_DATE('2015/02/05', 'YYYY/MM/DD'));
INSERT INTO SELLER (ID_Seller, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)
VALUES (ID_Sel.NEXTVAL, 'Alekseeva N.D.', TO_DATE('1987/04/21', 'YYYY/MM/DD'), '6211354218', '9203211515', 'Moscow, Volgogradskaya, 7-64', TO_DATE('2016/03/21', 'YYYY/MM/DD'));
INSERT INTO SELLER (ID_Seller, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)
VALUES (ID_Sel.NEXTVAL, 'Smirnov N.I.', TO_DATE('1990/09/21', 'YYYY/MM/DD'), '3208114586', '9207421881', 'Moscow, Avtozavodskaya, 16-5', TO_DATE('2015/01/17', 'YYYY/MM/DD'));
INSERT INTO SELLER (ID_Seller, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)
VALUES (ID_Sel.NEXTVAL, 'Xoxlova I.V.', TO_DATE('1987/02/01', 'YYYY/MM/DD'), '6512132476', '9031283516', 'Tula, Biruzova, 13-17', TO_DATE('2014/05/30', 'YYYY/MM/DD'));
INSERT INTO SELLER (ID_Seller, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)
VALUES (ID_Sel.NEXTVAL, 'Krasnova E.A.', TO_DATE('1992/08/29', 'YYYY/MM/DD'), '3842132115', '9037422835', 'Moscow, Uznaya, 24-64', TO_DATE('2016/09/24', 'YYYY/MM/DD'));
CREATE TABLE MANAGER (
ID_Manager int PRIMARY KEY,
FIO varchar(25) NOT NULL,
Birth_Date date NOT NULL,
Pasport int NOT NULL,
Phone varchar(20) NOT NULL,
Address varchar(50) NOT NULL,
Date_Priema date NOT NULL);
CREATE SEQUENCE ID_Man INCREMENT BY 1 START WITH 1;
INSERT INTO MANAGER (ID_Manager, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)
VALUES (ID_Man.NEXTVAL, 'Rublev A.I.', TO_DATE('1984/01/13', 'YYYY/MM/DD'), '1235748212', '9035721801', 'Moscow, Svobodnaya, 30-2', TO_DATE('2014/12/13', 'YYYY/MM/DD'));
INSERT INTO MANAGER (ID_Manager, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)
VALUES (ID_Man.NEXTVAL, 'Ivanova A.M.', TO_DATE('1987/04/20', 'YYYY/MM/DD'), '6117841211', '9213151694', 'Moscow, Bolshaya, 18-24', TO_DATE('2015/01/17', 'YYYY/MM/DD'));
INSERT INTO MANAGER (ID_Manager, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)
VALUES (ID_Man.NEXTVAL, 'Soboleva I.N.', TO_DATE('1991/12/03', 'YYYY/MM/DD'), '3151821322', '9037541118', 'Moscow, Svobodi, 21-24', TO_DATE('2015/08/02', 'YYYY/MM/DD'));
INSERT INTO MANAGER (ID_Manager, FIO, Birth_Date, Pasport, Phone, Address, Date_Priema)
VALUES (ID_Man.NEXTVAL, 'Vitko A.G.', TO_DATE('1990/10/10', 'YYYY/MM/DD'), '6215312418', '9203182111', 'Moscow, Pushkina, 31-21', TO_DATE('2016/09/15', 'YYYY/MM/DD'));
CREATE TABLE CATEGORY (
ID_Category int PRIMARY KEY,
Name varchar(25) NOT NULL);
CREATE SEQUENCE ID_Cat INCREMENT BY 1 START WITH 1;
INSERT INTO CATEGORY (ID_Category, Name)
VALUES (ID_Cat.NEXTVAL, 'Telephone');
INSERT INTO CATEGORY (ID_Category, Name)
VALUES (ID_Cat.NEXTVAL, 'Notebook');
INSERT INTO CATEGORY (ID_Category, Name)
VALUES (ID_Cat.NEXTVAL, 'Planshet');
INSERT INTO CATEGORY (ID_Category, Name)
VALUES (ID_Cat.NEXTVAL, 'Aksessuari');
INSERT INTO CATEGORY (ID_Category, Name)
VALUES (ID_Cat.NEXTVAL, 'PhotoCamera');
INSERT INTO CATEGORY (ID_Category, Name)
VALUES (ID_Cat.NEXTVAL, 'VideoCamera');
CREATE TABLE MAKER (
ID_Maker int PRIMARY KEY,
Name varchar(25) NOT NULL,
Country varchar(25) NOT NULL,
Site varchar(50) NOT NULL,
Phone int NOT NULL);
CREATE SEQUENCE ID_Maker INCREMENT BY 1 START WITH 1;
INSERT INTO MAKER (ID_Maker, Name, Country, Site, Phone)
VALUES (ID_Maker.NEXTVAL, 'ASUS', 'China', 'asus.ru', '88001002787');
INSERT INTO MAKER (ID_Maker, Name, Country, Site, Phone)
VALUES (ID_Maker.NEXTVAL, 'Huawei', 'China', 'shop.huawei.ru', '84953201221');
INSERT INTO MAKER (ID_Maker, Name, Country, Site, Phone)
VALUES (ID_Maker.NEXTVAL, 'Lenovo', 'China', 'lenovo.com', '861058868888');
INSERT INTO MAKER (ID_Maker, Name, Country, Site, Phone)
VALUES (ID_Maker.NEXTVAL, 'Nikon', 'Japan', 'nikon.ru', '84952216912');
INSERT INTO MAKER (ID_Maker, Name, Country, Site, Phone)
VALUES (ID_Maker.NEXTVAL, 'Canon', 'Japan', 'canon.ru', '84952585601');
INSERT INTO MAKER (ID_Maker, Name, Country, Site, Phone)
VALUES (ID_Maker.NEXTVAL, 'Xiaomi', 'China', 'ru-xiaomi.com', '84991109938');
INSERT INTO MAKER (ID_Maker, Name, Country, Site, Phone)
VALUES (ID_Maker.NEXTVAL, 'PocketBook', 'Ukraine', 'pocketbook-int.com', '88007009327');
INSERT INTO MAKER (ID_Maker, Name, Country, Site, Phone)
VALUES (ID_Maker.NEXTVAL, 'Sony', 'Japan', 'sony-russia.com', '84951252446');
CREATE TABLE CHEK_INFO (
ID_Chek int PRIMARY KEY,
ID_Seller int NOT NULL,
Kolichestvo int NOT NULL);
CREATE SEQUENCE ID_Chek INCREMENT BY 1 START WITH 1;
ALTER TABLE CHEK_INFO
ADD CONSTRAINT SellerFK FOREIGN KEY (ID_Seller) REFERENCES SELLER;
INSERT INTO CHEK_INFO (ID_Chek, ID_Seller, Kolichestvo)
VALUES (ID_Chek.NEXTVAL, '2', '5000');
INSERT INTO CHEK_INFO (ID_Chek, ID_Seller, Kolichestvo)
VALUES (ID_Chek.NEXTVAL, '3', '7200');
CREATE TABLE PRODUCT (
ID_Product int PRIMARY KEY,
Name varchar(30) NOT NULL,
ID_Category int NOT NULL,
ID_Maker int NOT NULL,
Garanty varchar(15) NOT NULL,
Price int NOT NULL);
CREATE SEQUENCE ID_Pr INCREMENT BY 1 START WITH 1;
ALTER TABLE PRODUCT
ADD CONSTRAINT CategoryFK FOREIGN KEY (ID_Category) REFERENCES CATEGORY;
ALTER TABLE PRODUCT
ADD CONSTRAINT MakerFK FOREIGN KEY (ID_Maker) REFERENCES MAKER;
INSERT INTO PRODUCT (ID_Product, Name, ID_Category, ID_Maker, Garanty, Price)
VALUES (ID_Pr.NEXTVAL, 'ASUS GL552VX', '2', '1', '2 year', '57000');
INSERT INTO PRODUCT (ID_Product, Name, ID_Category, ID_Maker, Garanty, Price)
VALUES (ID_Pr.NEXTVAL, 'Xiaomi Redmi 4', '1', '6', '2 year', '7900');
INSERT INTO PRODUCT (ID_Product, Name, ID_Category, ID_Maker, Garanty, Price)
VALUES (ID_Pr.NEXTVAL, 'Lenovo Vibe', '1', '3', '1 year', '5000');
INSERT INTO PRODUCT (ID_Product, Name, ID_Category, ID_Maker, Garanty, Price)
VALUES (ID_Pr.NEXTVAL, 'Huawei Nedia Pad', '3', '2', '1 year', '7200');
CREATE TABLE CHEK (
ID_Chek int NOT NULL,
ID_Product int NOT NULL,
Summa int NOT NULL);
ALTER TABLE CHEK ADD CONSTRAINT PK_CEK PRIMARY KEY (ID_Chek, ID_Product);
ALTER TABLE CHEK
ADD CONSTRAINT ChekFK FOREIGN KEY (ID_Chek) REFERENCES CHEK_INFO;
ALTER TABLE CHEK
ADD CONSTRAINT MProduct_FK FOREIGN KEY (ID_PRODUCT) REFERENCES PRODUCT;
INSERT INTO CHEK (ID_Chek, ID_Product, Summa)
VALUES ('1', '3', '1');
INSERT INTO CHEK (ID_Chek, ID_Product, Summa)
VALUES ('2', '4', '1');
CREATE TABLE DELIVERY (
ID_Delivery int PRIMARY KEY,
Price_Delivery int NOT NULL,
Address varchar(50) NOT NULL,
Phone int NOT NULL,
Date_Delivery date NOT NULL,
ID_Manager int NOT NULL,
ID_Order int NOT NULL);
CREATE SEQUENCE ID_Del INCREMENT BY 1 START WITH 1;
ALTER TABLE DELIVERY
ADD CONSTRAINT ManagerFK FOREIGN KEY (ID_Manager) REFERENCES MANAGER;
INSERT INTO DELIVERY (ID_Delivery, Price_Delivery, Address, Phone, Date_Delivery, ID_Manager, ID_Order)
VALUES (ID_Del.NEXTVAL, '57000', 'Moscow, Zelenya, 25-18', '9032183131', TO_DATE('2016/03/20', 'YYYY/MM/DD'), '3');
INSERT INTO DELIVERY (ID_Delivery, Price_Delivery, Address, Phone, Date_Delivery, ID_Manager, ID_Order)
VALUES (ID_Del.NEXTVAL, '7900', 'Moscow, Komsomolskaya, 64-12', '9031823574', TO_DATE('2017/04/20', 'YYYY/MM/DD'), '3');
INSERT INTO DELIVERY (ID_Delivery, Price_Delivery, Address, Phone, Date_Delivery, ID_Manager, ID_Order)
VALUES (ID_Del.NEXTVAL, '7900', 'Moscow, Volgogradskaya, 31-5', '9183212115', TO_DATE('2017/04/13', 'YYYY/MM/DD'), '1');
CREATE TABLE ORDERS (
ID_Order int PRIMARY KEY,
ID_Product int NOT NULL,
ID_Client int NOT NULL,
Kolichestvo int NOT NULL,
Date_Order date NOT NULL,
Summa int NOT NULL);
CREATE SEQUENCE ID_Or INCREMENT BY 1 START WITH 1;
ALTER TABLE ORDERS
ADD CONSTRAINT ProductFK FOREIGN KEY (ID_Product) REFERENCES PRODUCT;
ALTER TABLE ORDERS
ADD CONSTRAINT ClientFK FOREIGN KEY (ID_Client) REFERENCES CLIENT;
ALTER TABLE ORDERS
ADD CONSTRAINT DeliveryFK FOREIGN KEY (ID_Delivery) REFERENCES DELIVERY;
INSERT INTO ORDERS (ID_Order, ID_Product, ID_Client, Kolichestvo, Date_Order, Summa, ID_Delivery)
VALUES (ID_Or.NEXTVAL, '2', '3', '1', TO_DATE('2016/03/20', 'YYYY/MM/DD'), '57000', '1');
INSERT INTO ORDERS (ID_Order, ID_Product, ID_Client, Kolichestvo, Date_Order, Summa, ID_Delivery)
VALUES (ID_Or.NEXTVAL, '3', '2', '1', TO_DATE('2017/03/31', 'YYYY/MM/DD'), '7900', '2');
INSERT INTO ORDERS (ID_Order, ID_Product, ID_Client, Kolichestvo, Date_Order, Summa, ID_Delivery)
VALUES (ID_Or.NEXTVAL, '3', '1', '1', TO_DATE('2017/04/11', 'YYYY/MM/DD'), '7900', '3');

Подробное описание

📘 О чем эта работа

Отчет посвящен прохождению производственной практики по модулю ПМ.05: соадминистрирование и автоматизация баз данных и серверов. Объект — ООО «СМ‑Сервис», интернет‑магазин компьютерной техники; предмет — проектирование, реализация и тестирование реляционной базы данных для магазина, включая политику доступа и встроенные механизмы автоматизации.

📚 Что внутри

В работе приведены конкретные проектные артефакты и примеры реализации:

  • Инфологическая модель: перечислены сущности Пользователь/Клиент/Сотрудник, Товар, Категория, Производитель, Заказ, Позиция заказа, Чек, Доставка и их связи.
  • Логическая и физическая модели: реляционная схема с описанием типов полей, первичных и внешних ключей и перечислением 10 реализованных таблиц (SELLER, MANAGER, CLIENT, CATEGORY, MAKER, PRODUCT, CHEK_INFO, CHEK, DELIVERY, ORDERS).
  • Программная реализация в SQL: создание базовой БД 'smservice', последовательностей, INSERT‑примеров, ALTER TABLE с внешними ключами и реальными значениями для тестирования.
  • Триггеры Oracle с именами и назначением: Orders_Trig (обнуление стоимости доставки при сумме заказа >10000), Chek_T (пересчет суммы чека при изменении позиций), Trig2 (установка цены для производителей из America).
  • Ограничения и правила валидации: проверка возраста сотрудников, обязательность контактных данных клиентов, запрет на превышение количества в заказе, валидация цен и форматов.
  • Меры безопасности и разграничение прав: роли 'администратор', 'менеджер', 'клиент', политика профилей Oracle, системные и объектные привилегии (GRANT).
  • Тестирование и результаты: проверена корректность триггеров и автоматического пересчета сумм, проаннотированы проблемные места и исправления при уточнении требований.

📊 Для кого подходит

Отчет полезен для студентов и начинающих администраторов БД, курсовых и практических работ по направлению «Информационные системы и программирование», специалистов по сопровождению интернет‑магазинов и разработчиков backend‑части.

✨ Особенности

Практическая ценность работы: готовая SQL‑реализация с последовательностями и примерами INSERT, реализация бизнес‑правил через триггеры, типовые ограничения целостности и рекомендации по интеграции с веб‑интерфейсом и CRM. Включены практические рекомендации — резервное копирование, оптимизация запросов и аналитическая отчетность.

❓ Частые вопросы

Подойдет ли для моего ВУЗа?
Структура отчета соответствует требованиям по производственной практике: вводная часть, анализ предметной области, проектная реализация, выводы и приложения с кодом.

Можно адаптировать?
Да. SQL‑скрипты и схемы легко модифицируются под другую СУБД или под дополнительные требования к безопасности и масштабированию.