+ docker inspect <name of the mysql container>
+
+Furthermore, the TAG_PRE variable should be defined because the default value is 'mysql' (note that the 'dev-mysql' is used for development purposes - look at pom.xml file).
+
+If the database must be re-deployed (it is assumed that the corresponding mysql container has been stopped and deleted) while the persistent storage already exists (currently, the 'akraino-validation-mysql' docker volume is used), a different approach should be used after the image building process.
+
+To this end, another script has been developed, namely validation/docker/mysql/deploy_with_existing_storage.sh which easily deploys the container. This script accepts the following as input parameters:
+
+CONTAINER_NAME, the name of the container, default value is akraino-validation-mysql
+REGISTRY, the registry of the mysql image, default value is akraino
+NAME, the name of the mysql image, default value is validation
+TAG_PRE, the first part of the image version, default value is mysql
+TAG_VER, the last part of the image version, default value is latest
+
+In order to deploy the image using only the required parameters and the existing persistent storage, the below instructions should be followed (the user should override the default variables based on the requirements):
+
+.. code-block:: console
+
+ cd validation/docker/mysql
+ ./deploy_with_existing_persistent_storage.sh --TAG_PRE dev-mysql
+
+Finally, if the database must be re-deployed (it is assumed that the corresponding mysql container has been stopped and deleted) and the old persistent storage must be deleted, the used docker volume should be first deleted (note that all database's data will be lost).
+
+To this end, after the image build process, the following commands should be executed (the user should override the default variables based on the requirements):
+
+.. code-block:: console
+
+ docker volume rm akraino-validation-mysql
+ cd validation/docker/mysql
+ ./deploy.sh --TAG_PRE dev-mysql --MYSQL_ROOT_PASSWORD <root user password> --MYSQL_PASSWORD <mysql akraino user password>
+ mysql -p<MYSQL_AKRAINO_PASSWORD> -uakraino -h <IP of the mysql container> < ../../ui/db-scripts/examples/initialize_db_example.sql
+
+In the context of the UI application, the following tables exist in the database:
+
+- lab (here, every lab owner should store the name of the lab and the silo used for storing results in Nexus)
+- timeslot (here, every lab owner should register the available timeslots that can be used for blueprint validation test execution)
+- blueprint_layer (here, all the blueprint layers should be registered. These layers will be referenced by the blueprint instances)
+- blueprint (here, every blueprint owner should register the name of the blueprint)
+- blueprint_instance_for_validation (here, every blueprint owner should register the blueprint instances for validation, i.e. version and layer)
+- blueprint_instance_blueprint_layer (here, the many-to-many relationship between blueprint instances and layers is formulated)
+- blueprint_instance_timeslot (here, the many-to-many relationship between blueprint instances and timeslots is formulated)
+
+As it has been already mentioned, a user can perform CRUD operations on these tables using the UI. Also, all these tables except from lab and timeslot are initialized and updated automatically
+by the UI by fetching data from Nexus. It is the lab owners responsibility to update them if a modifications is needed (especially the data related to lab and timeslot tables).
+
+An example of data initialization is stored in the following file:
+
+ db-scripts/examples/initialize_db_example.sql
+
+That is the reason why the command 'mysql -p<MYSQL_AKRAINO_PASSWORD> -uakraino -h <IP of the mysql container> < ../../ui/db-scripts/examples/initialize_db_example.sql' has been used previously.
+
+Some of this data is illustrated below:
+
+.. code-block:: console
+
+ Labs:
+ id:1, lab:'att', silo:'att-blu-val'
+