Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

ПКС / ПКС. Лабораторная 2

.docx
Скачиваний:
1
Добавлен:
19.09.2023
Размер:
81.07 Кб
Скачать

МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ,

СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ТЕЛЕКОММУНИКАЦИЙ ИМ. ПРОФ. М.А. БОНЧ-БРУЕВИЧА» (СПбГУТ)

Кафедра информационных управляющих систем

Лабораторная работа № 2

по Б1.О.12 «ПРОГРАММИРОВАНИЕ КРИТИЧЕСКИХ СЕРВИСОВ»

Студент гр. ИСТ-111_____________________________ П.П. Иванов

(подпись)

Проверил ___________________________ А. В. Параничев

(оценка и подпись)

Санкт-Петербург

2023 год

Создание таблиц с соотношением «один-ко-многим» с помощью скрипта MySQL для построения IDEF1X-диаграммы

Описание соотношения «многие-ко-многим» помощью таблиц MySQL

[Выполнить в электронном виде, ответ отправить, переименовав файл по шаблону; выделенное зеленым прочитать и перед отправкой удалить; выделенное желтым - подставить свои значения:

1) Составить 2 соотношения "многие-ко-многим" ДОПОЛНИВ скрипт из 1й лабораторной; если необходимо, то добавить соотношения "один-ко-многим"

2) Скрипт составить также в ( https://dbfiddle.uk/ или https://paiza.io/

3) Отобразить взаимосвязи с помощью ER-диаграммы в PlantUML для всей схемы].

Выполним связывание составных параметров видеорегистраторов, продемонстрировав соотношение многие-ко-многим, добавив таблицу вариантов взаимосвязей диагонали экранов и разрешений экранов (VR_Resolution_to_Screen):

  • разрешениям экрана соответствуют следующие диагонали экранов:

  • разрешению «1920х1080» (индекс 0) соответствуют экраны 2”, 2.7”, 3”, 4”, без экрана;

  • разрешению «2560x1600» (индекс 1) соответствуют экраны 5”;

  • разрешению «2304x1296» (индекс 2) соответствуют экраны 3”;

  • разрешению «2880x2160» (индекс 3) соответствуют экраны 2.4”;

  • разрешению «2560x1080» (индекс 4) соответствуют экраны 5”;

  • диагоналям экранов, точно так же, соответствуют следующие разрешения экранов:

    • экрану 2” (индекс 0) разрешение «1920х1080»;

    • экрану 2.4” (индекс 1) разрешение «2880х2160»;

    • экрану 2.7” (индекс 2) разрешение «1920х1080»;

    • экрану 3” (индекс 3) разрешение «1920х1080» и «2304x1296»;

    • экрану 4” (индекс 4) разрешение «1920х1080»;

    • экрану 5” (индекс 5) разрешение «2560х1080» и «2560x1600»;

    • варианту «без экрана» (индекс 6) разрешение «1920x1080».

Для добавления и заполнения таблицы VR_Resolution_to_Screen добавим код:

SET FOREIGN_KEY_CHECKS = 0;

DROP TABLE IF EXISTS VR_Resolution_to_Screen;

SET FOREIGN_KEY_CHECKS = 1;

CREATE TABLE VR_Resolution_to_Screen (

id int(11) UNIQUE AUTO_INCREMENT,

id_resolution int(11),

id_screen int(11),

PRIMARY KEY (id),

FOREIGN KEY (id_resolution) REFERENCES VR_Base_Resolution(VR_Base_Resolution_id),

FOREIGN KEY (id_screen) REFERENCES VR_Base_Screen(VR_Base_Screen_id)

);

ALTER TABLE VR_Resolution_to_Screen AUTO_INCREMENT=1;

ALTER TABLE VR_Resolution_to_Screen CONVERT TO CHARACTER SET utf8;

DESCRIBE VR_Resolution_to_Screen;

INSERT INTO VR_Resolution_to_Screen (id_resolution, id_screen) VALUES

(0, 0),

(0, 2),

(0, 3),

(0, 4),

(0, 6),

(1, 2),

(2, 1),

(3, 1),

(4, 2),

(5, 1);

SELECT id AS 'Индекс',

screen.VR_Base_Screen_name AS 'Экран',

resolution.VR_Base_Resolution_name AS 'Разрешение съемки'

FROM VR_Resolution_to_Screen AS r2s

INNER JOIN VR_Base_Screen AS screen ON screen.VR_Base_Screen_id = r2s.id_screen

INNER JOIN VR_Base_Resolution AS resolution ON resolution.VR_Base_Resolution_id = r2s.id_resolution;

В результате получим значения по параметрам видеорегистратора, связанным соотношением «многие-ко-многим», представленные на рис. 1.

Рис. 1. Результат выполнения скрипта MySQL с помощью онлайн-ресурса … Compile MySQL Online

Результат выполнения скрипта MySQL (рис. 1) представлен в виде короткой ссылки ….

Рис. 2. IDEF1X-диаграмма (ER-диаграмма) базы данных о видеорегистраторах (здесь «PK» (Primary Key) – первичный ключ; «FK» (Foreigh Key) – внешний ключ)

Диаграмме на рис. 2 соответствует следующий скрипт: [planttext.com или plantuml.com/plantuml]

@startuml

left to right direction

entity VR_Base_Dashcam{

VR_Base_D_name : varchar(100)

VR_Base_D_brand : int(5) <<FK>>

VR_Base_D_corner : int(5) <<FK>>

VR_Base_D_screen : int(5) <<FK>>

VR_Base_D_resolution : int(5) <<FK>>

VR_Base_D_sensormic : int(5) <<FK>>

VR_Base_D_sensorg : int(5) <<FK>>

VR_Base_D_sensorfoto : int(5) <<FK>>

VR_Base_D_sensorgps : int(5) <<FK>>

VR_Base_D_battery : int(5) <<FK>>

VR_Base_D_price : decimal(10,2)

}

entity VR_Base_Brand{

VR_Base_Brand_id : int(5) <<PK>>

VR_Base_Brand_name : varchar(20)

}

entity VR_Base_Screen{

VR_Base_Screen_id : int(5) <<PK>>

VR_Base_Screen_name : varchar(15)

}

entity VR_Base_Resolution{

VR_Base_Resolution_id : int(5) <<PK>>

VR_Base_Resolution_name : varchar(15)

}

entity VR_Resolution_to_Screen{

id : int(5) <<PK>>

id_resolution : int(5) <<FK>>

id_screen : int(5) <<FK>>

}

entity VR_Base_YesNo{

VR_Base_YesNo_id : int(5) <<PK>>

VR_Base_YesNo_name : varchar(15)

}

entity VR_Base_Corner{

VR_Base_Corner_id : int(5) <<PK>>

VR_Base_Corner_name : varchar(5)

}

entity Users_Dashcam{

user_id : int(11) <<PK>>

role_id : int(1) <<FK>>

first_name : varchar(50)

middle_name : varchar(50)

last_name : varchar(50)

email : varchar(50)

username : varchar(50)

password : varchar(50)

created_at : datetime

last_view : datetime

}

entity Users_Roles{

role_id : int(1) <<PK>>

role_name : varchar(20)

}

VR_Base_Dashcam }|..|| VR_Base_Brand

VR_Base_Dashcam }|..|| VR_Base_Screen

VR_Base_Dashcam }|..|| VR_Base_Resolution

VR_Base_Dashcam }|..|| VR_Base_YesNo

VR_Base_Dashcam }|..|| VR_Base_Corner

VR_Base_Resolution }|..|| VR_Resolution_to_Screen

VR_Base_Screen }|..|| VR_Resolution_to_Screen

Users_Dashcam }|..|| Users_Roles

@enduml

Вывод: о созданных таблицах в дополнение к представленным в 1й лабораторной работе: в одном скрипте, и о ER-диаграмме: 5-7 строк.