Laravel proporciona muchas herramientas útiles para probar sus aplicaciones de bases de datos. Primero, puedes usar el método auxiliar de PHP. ver en la base de datos() para comprobar que los datos de la base de datos cumplen con un determinado conjunto de criterios. Por ejemplo, si desea verificar que la tabla de usuarios tenga un registro con el campo de correo electrónico igual a [correo electrónico protegido], puedes hacer lo siguiente:
PHP
{
// Haciendo una llamada de aplicación...
$this -> seeInDatabase("usuarios", [
"correo electrónico" => " [correo electrónico protegido]"
]);
}
Por supuesto, métodos como PHP ver en la base de datos() creado para mayor comodidad. Puede utilizar cualquiera de los métodos de validación integrados de PHPUnit para aumentar sus pruebas.
Restablecer la base de datos después de cada prueba.
A menudo resulta útil restablecer la base de datos después de cada prueba para que los datos de la prueba anterior no afecten las pruebas posteriores.
Usando migraciones
Una forma de restablecer el estado de la base de datos es revertir la base de datos después de cada prueba y migrarla antes de la siguiente prueba. Laravel proporciona un rasgo simple de DatabaseMigrations que automáticamente hará esto por usted. Simplemente use este rasgo en su clase de prueba y todo se hará por usted:
PHP /**
{
utilizar migraciones de bases de datos;
*
* @retorno nulo
*/
{
$esto -> visitar ("/" )
-> ver ("Laravel 5" );
}
}
Usando transacciones
Otra forma de restablecer el estado de la base de datos es envolver cada caso de prueba en una transacción de base de datos. Y para esto, Laravel también proporciona un práctico rasgo DatabaseTransactions que automáticamente hará esto por usted:
PHP Utilice Illuminate\Foundation\Testing\WithoutMiddleware; clase EjemploTest extiende TestCase /**
utilice Illuminate\Foundation\Testing\DatabaseMigrations;
utilice Illuminate\Foundation\Testing\DatabaseTransactions;
{
utilizar Transacciones de base de datos;
* Ejemplo de prueba funcional básica.
*
* @retorno nulo
*/
{
$esto -> visitar ("/" )
-> ver ("Laravel 5" );
}
}
De forma predeterminada, este rasgo solo incluirá la conexión de base de datos predeterminada en una transacción. Si su aplicación utiliza múltiples conexiones de bases de datos, debe definir la propiedad PHP $conexionesToTransact en tu clase de prueba. Esta propiedad debe ser una matriz de nombres de conexiones para realizar transacciones.
Creación de fábricas
Al realizar la prueba, es posible que necesite insertar varios registros en su base de datos antes de ejecutar la prueba. Al crear estos datos, en lugar de especificar manualmente los valores de cada columna, Laravel te permite definir un conjunto estándar de atributos para cada uno de tus modelos de Eloquent usando fábricas. Primero, mire el archivo base de datos/factories/ModelFactory.php en su aplicación. Inicialmente, este archivo contiene la definición de una fábrica:
PHP $fábrica -> definir (Aplicación \ Usuario ::clase, función (Faker \ Generador $faker) (
contraseña estática $;
Devolver [
"nombre" => $faker -> nombre,
"correo electrónico" => $faker -> único()-> correo electrónico seguro,
"contraseña" => $contraseña?: $contraseña = bcrypt ("secreto"),
"recordar_token" => str_random (10),
];
});
En un cierre que sirve como definición de fábrica, puede devolver valores de prueba estándar para todos los atributos del modelo. El cierre recibirá una instancia de la biblioteca PHP Faker, que le permite generar cómodamente varios datos aleatorios para realizar pruebas.
Por supuesto, puedes agregar tus propias fábricas adicionales en el archivo ModelFactory.php. También puede crear archivos de fábrica adicionales para cada modelo para una organización más clara. Por ejemplo, puede crear archivos UserFactory.php y CommentFactory.php en su carpeta base de datos/fábricas. Laravel descargará automáticamente todos los archivos de la carpeta de fábricas.
Estados de fábrica
Los estados le permiten definir cambios individuales que se pueden aplicar a sus fábricas modelo en cualquier combinación. Por ejemplo, su modelo de Usuario podría tener un estado moroso que cambie el valor predeterminado de uno de los atributos. Puedes definir tus transformaciones de estado usando el método PHP. estado() :
PHP $fábrica -> estado (Aplicación \ Usuario ::clase, "delincuente", función ($faker) (
devolver [
"account_status" => "moroso",
];
});
Usando fábricas
Creando modelos
Una vez definidas las fábricas, puedes usar la función global de PHP. fábrica() en sus pruebas o archivos semilla para generar instancias de modelo. Entonces, veamos algunos ejemplos de creación de modelos. En primer lugar, utilizamos el método PHP. hacer() para crear modelos, pero no los guardará en la base de datos:
PHP función pública pruebaBase de datos()
{
$usuario = fábrica (Aplicación\Usuario::clase)->make();
También puedes crear una colección de modelos o crear modelos de un tipo específico:
PHP $usuarios = fábrica (Aplicación\Usuario::clase, 3)->make();
También puedes aplicar cualquiera a los modelos. Si desea aplicar varios cambios de estado a los modelos, debe especificar el nombre de cada estado a aplicar:
PHP $usuarios = fábrica (Aplicación \ Usuario ::clase, 5 )-> estados ("delincuentes") -> make ();
$usuarios = fábrica (Aplicación \ Usuario ::clase, 5 ) -> estados ("premium", "delincuente" ) -> make ();
Anulación de atributo
Si desea anular algunos de los valores predeterminados de sus modelos, puede pasar una matriz de valores al método PHP hacer(). Solo se reemplazarán los valores especificados y el resto se configurará como se especifica en fábrica:
PHP $usuario = fábrica (Aplicación\Usuario::clase)->hacer ([
"nombre" => "Abigaíl",
]);
Modelos permanentes
Método PHP crear() no solo crea instancias de modelo, sino que también las almacena en la base de datos usando el método PHP Eloquent ahorrar() :
PHP función pública pruebaBase de datos()
{
// Crea una instancia de App\Usuario...
$usuario = fábrica (Aplicación\Usuario::clase)->create();
// Crea tres instancias de App\Usuario...
$usuarios = fábrica (Aplicación\Usuario::clase, 3)->create();
// Usando el modelo en pruebas...
}
Puede anular los atributos del modelo pasando una matriz a un método PHP crear():PHP hacer());
});
Relaciones de cierre y atributos
También puede adjuntar relaciones a modelos utilizando atributos de cierre en sus definiciones de fábrica. Por ejemplo, si desea crear una nueva instancia del modelo de Usuario al crear una Publicación, puede hacer esto:
PHP $fábrica ->
devolver [
"título" => $faker -> título,
"contenido" => $faker -> párrafo,
"id_usuario" => función() (
devolver fábrica (Aplicación\Usuario::clase)->create()->id;
}
];
});
Este cierre también recibe una matriz específica de atributos de la fábrica que lo contiene:
PHP $factory -> definir (Aplicación \ Publicación ::clase, función ($faker) (
devolver [
"título" => $faker -> título,
"contenido" => $faker -> párrafo,
"id_usuario" => función() (
devolver fábrica (Aplicación\Usuario::clase)->create()->id;
},
"tipo_usuario" => función (matriz $publicación) (
return Aplicación\Usuario::find($post["user_id"])->tipo;
}
];
});
: Cómo probar y depurar bases de datos
Las pruebas unitarias automáticas del código de la aplicación son simples y directas. ¿Cómo probar una base de datos? O una aplicación que funcione con una base de datos. Después de todo, una base de datos no es solo un código de programa, una base de datos es un objeto que guarda su estado. Y si comenzamos a cambiar los datos en la base de datos durante las pruebas (y sin esto, ¡¿qué tipo de pruebas tendremos?!), luego de cada prueba la base de datos cambiará. Esto puede interferir con pruebas posteriores y dañar permanentemente la base de datos.
La clave para resolver el problema son las transacciones. Una de las características de este mecanismo es que mientras la transacción no se complete, siempre se pueden deshacer todos los cambios y devolver la base de datos al estado en el que comenzó la transacción.
El algoritmo es así:
- abrir una transacción;
- si es necesario, llevamos a cabo pasos preparatorios para las pruebas;
- realizar una prueba unitaria (o simplemente ejecutar el script cuyo funcionamiento queremos comprobar);
- comprobar el resultado del script;
- Cancelamos la transacción, devolviendo la base de datos a su estado original.
Incluso si hay transacciones no cerradas en el código bajo prueba, el ROLLBACK externo revertirá todos los cambios correctamente.
Es bueno si necesitamos probar un script SQL o un procedimiento almacenado. ¿Qué pasa si estamos probando una aplicación que se conecta a la base de datos y abre una nueva conexión? Además, si estamos depurando, probablemente querremos mirar la base de datos a través de los ojos de la aplicación que se está depurando. ¿Qué hacer en este caso?
No se apresure a crear transacciones distribuidas, ¡existe una solución más sencilla! Con las herramientas estándar del servidor SQL, puede abrir una transacción en una conexión y continuarla en otra.
Para hacer esto, debe conectarse al servidor, abrir una transacción, obtener un token para esa transacción y luego pasar este token a la aplicación bajo prueba. Se unirá a nuestra transacción en su sesión y a partir de ese momento, en nuestra sesión de depuración veremos los datos (y también sentiremos los bloqueos) exactamente como los ve la aplicación bajo prueba.
La secuencia de acciones es la siguiente:
Habiendo iniciado una transacción en una sesión de depuración, debemos averiguar su identificador. Se trata de una cadena única mediante la cual el servidor distingue las transacciones. Este identificador debe pasarse de alguna manera a la aplicación bajo prueba.
Ahora la tarea de la aplicación es vincularse a nuestra transacción de control antes de que comience a hacer lo que se supone que debe hacer.
Entonces la aplicación comienza a funcionar, incluida la ejecución de sus procedimientos almacenados, la apertura de sus transacciones, el cambio del modo de aislamiento... Pero nuestra sesión de depuración estará todo este tiempo dentro de la misma transacción que la aplicación.
Digamos que una aplicación bloquea una tabla y comienza a cambiar su contenido. En este momento, ninguna otra conexión puede mirar dentro de la mesa bloqueada. ¡Pero no nuestra sesión de depuración! Desde allí podremos mirar la base de datos de la misma forma que lo hace la aplicación, ya que el servidor SQL cree que estamos en la misma transacción.
Mientras que para todas las demás sesiones las acciones de la aplicación están ocultas mediante candados...
¡Nuestra sesión de depuración pasa por los bloqueos (el servidor cree que son nuestros propios bloqueos)!
O imagine que la aplicación comienza a trabajar con sus propias versiones de cadenas en modo INSTANTÁNEA. ¿Cómo puedo consultar estas versiones? ¡Incluso esto es posible si están conectados por una transacción común!
No olvide revertir la transacción de control al final de este apasionante proceso. Esto se puede hacer tanto desde la sesión de depuración (si el proceso de prueba se completa con normalidad) como desde la propia aplicación (si sucede algo inesperado en ella).
Puedes aprender más sobre esto en los cursos.
Pruebas de bases de datos No es tan común como probar otras partes de la aplicación. en algunas pruebas base de datos generalmente se moja. En este artículo intentaré analizar herramientas para probar relaciones y No SQL bases de datos.
Esta situación se debe al hecho de que muchas bases de datos son comerciales y la organización que desarrolló la base de datos proporciona todo el conjunto de herramientas necesarias para trabajar con ellas. Sin embargo, la creciente popularidad de NoSQL y varias bifurcaciones de MySQL en el futuro puede cambiar esta situación.
Punto de referencia de la base de datos
Database Benchmark es una herramienta .NET diseñada para realizar pruebas de estrés en bases de datos con grandes flujos de datos. La aplicación ejecuta dos escenarios de prueba principales: insertar una gran cantidad de registros generados aleatoriamente con claves secuenciales o aleatorias y leer los registros insertados ordenados por sus claves. Tiene amplias capacidades para generar datos, informes gráficos y configurar posibles tipos de informes.
Bases de datos compatibles: MySQL, SQL Server, PostgreSQL, MongoDB y muchas otras.
Jinete de base de datos
Database Rider está diseñado para permitir pruebas había una base de datos No fue más difícil que las pruebas unitarias. Esta herramienta se basa en Arquilliano y por lo tanto el proyecto Java sólo necesita una dependencia para DBUnit. También es posible utilizar anotaciones, como enunidad conjunta, integración con CDI a través de interceptores, soporte para JSON, YAML, XML, XLS y CSV, configuración a través de las mismas anotaciones o yml archivos, integración con Pepino, soporte para múltiples bases de datos, trabajo con tipos temporales en conjuntos de datos.
DbFit
DbFit - marco de desarrollo Base de datos a través de pruebas. esta escrito encima Fitness, que es una herramienta madura y poderosa con una gran comunidad. Las pruebas se escriben en base a tablas, lo que las hace más legibles que las normales. unidad - pruebas. Puede ejecutarlos desde el IDE, usando la línea de comando o usando herramientas de CI.
Bases de datos soportadas: Oracle, SQL Server, MySQL, DB2, PostgreSQL, HSQLDB y Derby.
dbstress
dbstress es una herramienta de pruebas de estrés y rendimiento de bases de datos escrita en Scala y Akka. Usando un especial JDBC-driver, ejecuta solicitudes en paralelo una cierta cantidad de veces (posiblemente incluso a varios hosts) y guarda el resultado final en csv archivo.
Bases de datos soportadas: todas iguales que en JDBC.
Unidad Db
es una extensión JUnit (también usado con Ant), que entre pruebas puede devolver base de datos al estado deseado. Esta característica le permite evitar dependencias entre pruebas; si una prueba falla y al mismo tiempo viola la base de datos, la siguiente prueba comenzará desde cero. DbUnit tiene la capacidad de transferir datos entre una base de datos y un documento XML. También es posible trabajar con grandes conjuntos de datos en modo streaming. También puede comprobar si la base de datos resultante coincide con un determinado estándar.
Bases de datos soportadas: todas iguales que en JDBC.
Prueba de base de datos impulsada
DB Test Driven es una herramienta para examen de la unidad Base de datos. Esta utilidad es muy liviana, funciona con SQL nativo y se instala directamente en la base de datos. Se integra fácilmente con herramientas de integración continua y la versión de SQL Server tiene la capacidad de evaluar la cobertura del código mediante pruebas.
Bases de datos soportadas: SQL Server, Oracle.
martillodb
HammerDB: herramienta de pruebas de carga y referencia Base de datos. Esta es una aplicación automatizada que también es multiproceso y tiene la capacidad de utilizar scripts dinámicos. Java de código abierto y herramienta de comparación. Es automatizado, multiproceso y extensible con soporte para scripts dinámicos.
JdbcSlim
JdbcSlim ofrece una fácil integración de consultas y comandos en Slim FitNesse. El objetivo del proyecto es almacenar una variedad de configuraciones, datos de prueba y SQL. Esto garantiza que los requisitos se escriban independientemente de la implementación y sean comprensibles para los usuarios empresariales. JdbcSlim no tiene código específico de base de datos. Es agnóstico acerca de los detalles de un sistema de base de datos y no tiene un código específico para ningún sistema de base de datos. En el marco en sí, todo se describe en un alto nivel; la implementación de cualquier cosa específica ocurre cambiando solo una clase.
Bases de datos soportadas: Oracle, SQL Server, PostgreSQL, MySQL y otras.
JDBDT (Prueba delta de base de datos Java)
JDBDT es una biblioteca Java para probar aplicaciones de bases de datos (basadas en SQL). La biblioteca está diseñada para la instalación y prueba automatizadas de las pruebas de la base de datos. JDBDT no tiene dependencias de bibliotecas de terceros, lo que simplifica su integración. En comparación con las bibliotecas de prueba de bases de datos existentes, JDBDT es conceptualmente diferente en su capacidad para utilizar afirmaciones δ.
Bases de datos soportadas: PostgreSQL, MySQL, SQLite, Apache Derby, H2 y HSQLDB.
NBi
NBi es esencialmente un complemento para NUnit y está destinado más a Inteligencia de Negocio esferas. Además de trabajar con bases de datos relacionales, es posible trabajar con OLAP plataformas (Analysis Services, Mondrian, etc.), ETL Y sistemas de informes(Tecnologías de Microsoft). El objetivo principal de este marco es crear pruebas utilizando un enfoque declarativo basado en XML. No necesitará escribir pruebas en C# ni usar Visual Studio para compilar pruebas. Sólo necesita crear un archivo xml e interpretarlo usando NBi, luego podrá ejecutar las pruebas. Además de NUnit, se puede migrar a otros marcos de prueba.
Bases de datos soportadas: SQL Server, MySQL, PostgreSQL, Neo4j, MongoDB, DocumentDB y otras.
Mapa NoSQL
NoSQLMap está escrito en Python para realizar auditorías de robustez sql - inyecciones y varios exploits en la configuración de la base de datos. Y también evaluar la resistencia de una aplicación web que utilice bases de datos NoSQL ante este tipo de ataques. Los objetivos principales de la aplicación son proporcionar una herramienta para probar servidores MongoDB y disipando el mito de que las aplicaciones NoSQL son impenetrables a la inyección SQL.
Bases de datos soportadas: MongoDB.
Unidad NoSQL
NoSQLUnit es una extensión para JUnit diseñada para escribir pruebas en aplicaciones Java que utilizan bases de datos NoSQL. Objetivo Unidad NoSQL- gestionar el ciclo de vida de NoSQL. Esta herramienta le ayudará a mantener las bases de datos que está probando en un estado conocido y a estandarizar la forma en que escribe pruebas para aplicaciones que utilizan NoSQL.
Bases de datos soportadas: MongoDB, Cassandra, HBase, Redis y Neo4j.
especificación-ruby-plsql
Marco ruby-plsql-spec para pruebas unitarias de PL/SQL usando Ruby. Se basa en otras dos bibliotecas:
- ruby-plsql: API Ruby para llamar a procedimientos PL/SQL;
- RSpec es un marco para BDD.
Bases de datos compatibles: Oracle
SeLite
SeLite es una extensión de la familia Selenium. La idea principal es tener una base de datos basada en SQLite, aislado de la aplicación. Podrá detectar errores del servidor web y errores de scripts entre pruebas, trabajar con instantáneas, etc.
Bases de datos soportadas: SQLite, MySQL, PostgreSQL.
mapa sql
sqlmap es una herramienta de prueba de penetración que puede automatizar el proceso de detección y explotación de inyecciones de SQL y hacerse cargo de servidores de bases de datos. Está equipado con un potente motor de detección y muchas funciones de pentesting específicas.
Bases de datos soportadas: MySQL, Oracle, PostgreSQL, SQL Server, DB2 y otras.
Herramientas de código abierto para pruebas de bases de datos.
https://site/wp-content/uploads/2018/01/data-base-testing-150x150.png
Las pruebas de bases de datos no son tan comunes como probar otras partes de la aplicación. En algunas pruebas, se burla completamente de la base de datos. En este artículo intentaré analizar herramientas para probar bases de datos relacionales y NoSQL. Esta situación se debe a que muchas bases de datos son comerciales y todo el conjunto de herramientas necesarias para trabajar con ellas lo proporciona una organización que […]
1) Metas y objetivos…………………………………………………………... 3
2) Descripción de la base de datos………………………………………………... 4
3) Trabajar con la base de datos …………………………………………………… 6
4) Pruebas de carga de la base de datos………………………………...11
5) Conclusión……………………………………………………………………....15
6) Literatura………………………………………………………………....16
Metas y objetivos
Objetivo: Crea una base de datos de elixires para el juego The Witcher 3, que contendrá información sobre el tipo de elixires, sus propiedades, de qué están hechos, lugares donde se pueden encontrar y sobre los monstruos contra los cuales se pueden usar. Cree consultas optimizadas para esta base de datos y pruébela de carga.
Tareas:
· Crear un esquema de base de datos con al menos 5 entidades en MYSQL Workbench. Describe estas entidades y sus conexiones.
· Describir el uso de esta base de datos, describir las consultas principales, observar su tiempo de ejecución y sacar conclusiones
· Optimización de bases de datos
· Realizar pruebas de carga usando apache-jmeter. Utilice extensiones para crear gráficos.
Descripción de la base de datos
El trabajo del curso utiliza la base de datos Witcher1 creada, cuyas entidades principales son tablas:
Fig.1 Representación esquemática de la base de datos Witcher1
La tabla de Ingredientes contiene los ingredientes necesarios para crear elixires en el juego, los cuales se describen en la tabla de Elixires. Se utilizan varios ingredientes para crear un elixir, pero cada uno es único para su elixir. Es por esta razón que entre estas tablas se estableció una relación 1:n (uno a muchos), la cual se muestra en el diagrama de la base de datos (Fig. 1).
La tabla de Ingredientes también contiene información sobre los nombres de los ingredientes (Discripción) y dónde se puede encontrar este ingrediente (Dónde encontrar). La columna idElixirs es una columna de enlace para las tablas de Ingredientes y Elixires.
La tabla de Elixires contiene información sobre cómo utilizar un elixir específico y el nombre de ese elixir. Esta tabla es la tabla clave para las otras tablas.
La tabla Ubicaciones contiene información sobre en qué ubicación o ciudad se puede encontrar un ingrediente específico.
La tabla IL contiene información consolidada sobre dónde y cómo encontrar un ingrediente específico en un área determinada y qué es. Se estableció una relación n:m (muchos a muchos) entre las tablas Ingredientes y Ubicaciones, ya que se pueden encontrar múltiples ingredientes en múltiples ubicaciones, como se indica en la tabla secundaria IL.
La tabla de Monstruos contiene información sobre los tipos de monstruos en
"Witcher 3", sobre cómo reconocer tal o cual monstruo y los nombres característicos de ellos.
La tabla ML es una tabla secundaria de la unión n: m de las tablas Ubicación y Monstruos y contiene información específica sobre cómo derrotar a este monstruo en particular y qué elixires se pueden usar para esto, incluidos signos especiales de brujo, así como en qué área. y ¿Qué señales deberías utilizar para buscar este tipo particular de monstruo?
Trabajando con la base de datos
La base de datos de Witcher1 contiene información sobre qué elixires deben usarse contra qué monstruos, tácticas especiales para monstruos especialmente peligrosos, como: Pestilence Maiden, Devil, Imp, Goblin, etc. Analizar la información de cada tabla en orden llevará mucho tiempo, por lo que crearemos consultas especiales a la base de datos que serán lo más útiles posible para el usuario.
· Una solicitud de información sobre cómo encontrar un monstruo específico.
Esta consulta contendrá la palabra clave JOIN, gracias a la cual se accederá a las tablas ML y Monsters de la base de datos Witcher1.
Esta solicitud se verá así:
ml ÚNETE a los monstruos EN monsters.idMonsters=ml.idMonsters;
Después de ejecutar la consulta, recibiremos como salida una tabla bastante grande, que es el resultado de combinar dos tablas. Para que la tabla mostrada no sea tan grande, puedes especificar sobre qué monstruo mostrar información. Es decir, para Él, por ejemplo, la solicitud se verá así:
monstruos.MonstersName, monstruos.MonstersDiscription,
ml.DiscriptionHowFind, ml.idUbicaciones
ml ÚNETE a monstruos EN monsters.idMonsters=ml.idMonsters
donde monstruos.MonstersName='Hym';
A qué monstruo corresponde este o aquel ID se puede averiguar consultando las tablas Monstruos o ML. Las consultas se verán así:
SELECCIONAR SELECCIONAR
IdMonstruos, Nombre de los Monstruos idMonstruos, Nombre de los Monstruos
DE ml; DE monstruos;
Para comprobar el cumplimiento, puede consultar las tablas ML y Monsters, uniéndose primero a ellas mediante idMonsters.
ml.idMonstruos, monstruos.MonstersName
ml ÚNETE a los monstruos EN
ml.idMonsters=monstruos.idMonsters
ORDENAR POR monstruos.idMonsters;
· Una pregunta sobre qué elixir es adecuado para este monstruo.
Para implementar esta solicitud, se utilizará JOIN. La consulta se dirigirá a dos tablas Elixires y Monstruos y contendrá información sobre cuándo y qué elixir beber en la lucha contra el monstruo:
monstruos.MonstersName, elixires.ElixirName, elixires.ElixirDiscription
elixires ÚNETE a los monstruos EN
elixirs.idElixirs=monstruos.idElixirs;
· Una consulta sobre qué ingrediente se encuentra en una zona determinada.
Para implementar esta solicitud, se utilizará JOIN. La consulta se dirigirá a dos tablas Ingredientes y Ubicaciones y contendrá información sobre qué ingrediente se encuentra en qué ubicación e información sobre su tipo:
ingridientes.Descripción, ubicaciones.Descripción, ingridientes.DóndeEncontrar
ingredientes ÚNETE a ubicaciones EN
ingridients.idIngridients=ubicaciones.idIngridients
ORDENAR POR ingredientes. Descripción;
· Solicitudes de ACTUALIZAR
Implementamos esta consulta para un monstruo en la tabla Monstruos llamado Hym. Digamos que queremos cambiarle el nombre a Él:
monstruos
SET MonstersName="Él"
donde idMonstruos=1;
Pero, dado que Hym es correcto en la versión en inglés, regresemos todo:
monstruos
SET MonstersName="Himno"
donde idMonstruos=1;
Figura 2. Implementación de consultas de ACTUALIZACIÓN
· Consultas de "agregación". CONTAR y CONTAR (DISTINTO)
La función COUNT cuenta el número de filas no vacías (sin NULL dentro de ellas) en una tabla determinada. COUNT tiene una versión optimizada para mostrar el número de filas cuando se usa para 1 tabla. Por ejemplo:
Fig. 3. Cuente filas en las tablas de Elixires, Monstruos y Monstruos ÚNETE a elixires.
La función COUNT(DISTINCT) se utiliza para mostrar el número de filas no repetidas en tablas y es una versión más optimizada de la familia de funciones COUNT:
Fig.4. Contando elixires que no se repiten en la tabla de Monstruos.
· Función BORRAR.
Agreguemos otra fila a la tabla Elixires usando INSERT:
INSERTAR EN elixires VALUES (6,'ForDelete','DiscriptionDelete');
Fig.5. Agregando una fila a la tabla de Elixires.
Ahora solicitaremos eliminar esta línea, ya que no es necesario un elixir que no ayude de ninguna manera en la lucha contra los monstruos:
BORRAR DE elixires DONDE idElixirs=6;
Fig.6. Elimina la línea agregada.
Pruebas de carga de base de datos
Ahora que se han completado las consultas y se ha establecido el acceso a la base de datos, se puede probar utilizando varios parámetros:
· Tiempos de respuesta a lo largo del tiempo o Tiempos de respuesta a lo largo del tiempo: esta verificación muestra información para cada solicitud sobre su tiempo de respuesta promedio en milisegundos.
· Distribución de tiempos de respuesta o Distribución de tiempo de respuesta: esta verificación muestra el número de respuestas en un determinado intervalo de tiempo durante el cual se ejecutó la solicitud.
· Percentiles de tiempo de respuesta: esta verificación muestra percentiles para los valores de tiempo de respuesta. En el gráfico, el eje X serán los porcentajes y el eje Y será el tiempo de respuesta.
Para las pruebas más plausibles, estableceremos ciertos
opciones:
Fig.7. Parámetros de prueba
Número de subprocesos (usuarios): número de usuarios virtuales. En nuestro caso, lo configuraremos en 1000 para poder cargar nuestra base de datos tanto como sea posible.
Período de aceleración: el período durante el cual participarán todos los usuarios.
Comprobaremos todas las solicitudes JOIN para comprobar su rendimiento cuando sean activadas simultáneamente por varios usuarios.
Los últimos 3 puntos son trazadores de las comprobaciones mediante las cuales probaremos la base de datos.
· 
Comprobación de los tiempos de respuesta a lo largo del tiempo
Fig.7. El resultado de ejecutar consultas durante la prueba. Tiempos de respuesta a lo largo del tiempo
Como se puede ver en el gráfico, la solicitud más difícil de completar fue "Monsters&Locations" y requirió el mayor tiempo de respuesta. Puede verificar el motivo de la ejecución prolongada de la solicitud ejecutando la solicitud en la consola. La razón principal de este retraso es que tanto la tabla de Monstruos como la tabla ML contienen explicaciones extensas sobre los monstruos o dónde encontrarlos. Debido a esto, la solicitud tarda bastante en completarse.
· 
Examen Distribución de tiempos de respuesta
Fig.8. El resultado de ejecutar consultas durante la prueba. Distribución de tiempos de respuesta.
De este gráfico podemos concluir que el número de respuestas para cada una de nuestras solicitudes en el mismo período de tiempo es el mismo.
· 
Comprobación de percentiles de tiempo de respuesta
El eje de ordenadas muestra el tiempo de ejecución y el eje de abscisas muestra los porcentajes de la cantidad total. Según el gráfico, podemos concluir que el 90% de las solicitudes se ejecutan en el intervalo de tiempo de 0 a 340 milisegundos, y del 5% al 15% el número de solicitudes aumenta linealmente y luego exponencialmente con un coeficiente de aumento muy pequeño.
El 10% restante se ejecuta en el intervalo de tiempo de 340 milisegundos a 700 milisegundos, lo que lleva a la conclusión de que existe una carga muy grande en la base de datos.
Conclusión
En este trabajo de curso, se completaron todas las tareas. Se diseñó la base de datos, se llenó de datos, se mostraron las principales posibilidades de su uso en forma de consultas y los resultados de su ejecución.
Al final se realizaron pruebas y análisis de sus resultados, con posteriores conclusiones.
Cabe señalar que la base de datos en sí fue creada solo con fines educativos, por lo que no es tan voluminosa.
Otra característica importante es la seguridad: las contraseñas, si se crea una tabla de este tipo, deben almacenarse cifradas y protegidas del acceso no autorizado.
Literatura
1. http://phpclub.ru/mysql/doc/- Recurso de Internet "MySQL - guía de referencia"
2. Schwartz B., Zaitsev P., Tkachenko V. y otros - MySQL. Optimización del rendimiento (segunda edición)
3. Thalmann L., Kindal M., Bell C. – “Garantizar una alta disponibilidad de los sistemas basados en MySQL”
4. Andrzej Sapkowski – “The Witcher (colección grande)”, Número de páginas: 571
5. CD PROYECTO ROJO, GOG COM. "The Witcher 3: Caza salvaje".
Información relacionada.
Las pruebas de la base de datos son necesarias para garantizar la funcionalidad de la base de datos. Para ello se elaboran consultas en la base de datos de varios tipos: de muestreo, con campos calculados, paramétricas, con agrupación de datos, de actualización, de eliminación.
Consulta de ejemplo: muestra una lista de libros tomados por un estudiante específico. Establece tu nombre completo como parámetro.
Consulta de ejemplo: muestra una lista de libros de un autor específico que indica las ubicaciones de almacenamiento en la biblioteca. Establezca el nombre completo del autor como parámetro.
Solicitud de ejemplo: Determine por el número de tarjeta de la biblioteca en qué clase está el estudiante correspondiente y quién es su maestro de clase.
Arroz. 15. Consulta 3. “Buscar un estudiante por número de tarjeta de biblioteca y determinar en qué clase está estudiando”
Solicitud de ejemplo: Determinar por Estudiante_Nombre completo en qué clase está estudiando el deudor y quién es su maestro de clase.
Para la comodidad de trabajar con registros de varias tablas, se creó un programa con el que se puede abrir cualquier tabla necesaria para ver, actualizar y cambiar información. La forma del botón se muestra en la Fig. 17.
Arroz. 17. Formulario de botón de base de datos
CONCLUSIÓN
El trabajo final de calificación se realizó sobre el tema actual “Desarrollo de un sistema de información para una biblioteca escolar rural”.
Se ha logrado el objetivo del diseño del diploma de desarrollar un sistema de información para la biblioteca escolar de la región de Saratov, distrito Fedorovsky de la escuela secundaria de la institución educativa municipal en el pueblo de Solnechny.
Durante el proyecto de graduación se resolvieron las siguientes tareas:
Considerar la biblioteca como un elemento del entorno educativo;
Estudiar el concepto gubernamental de apoyar y desarrollar la lectura infantil;
Se analizan las tecnologías de trabajo de las bibliotecas de las instituciones educativas;
El área temática se describe en base a la encuesta;
-se desarrolló una especificación técnica para el desarrollo de un sistema de información para una biblioteca escolar rural;
- se construyó un modelo funcional de las actividades de la biblioteca escolar;
- descripción de los flujos de información de entrada y salida;
Se ha desarrollado un sistema de información basado en un DBMS.CACmiss;
- Se probó la base de datos relacional desarrollada.
En el trabajo final de calificación para la construcción de un sistema de información que proporcione automatización de operaciones manuales para asegurar los procesos de almacenamiento, búsqueda, contabilidad de emisión y devolución por parte de los estudiantes, se desarrolló una especificación técnica a partir del análisis de los resultados de una encuesta. del área temática. Las especificaciones técnicas (TOR) reflejaban los requisitos de los usuarios del sistema: los trabajadores de la biblioteca.
A partir de las especificaciones técnicas se ha desarrollado un modelo funcional de las actividades de una biblioteca escolar rural. El modelo funcional, a su vez, sirvió como material para identificar áreas no automatizadas en el trabajo de la biblioteca.
La elección de un DBMS como entorno de desarrollo estuvo determinada por las capacidades técnicas de la biblioteca rural. Como resultado, basado en el DBMS AccesoSe construyó el núcleo del sistema de información: la base de datos.
Para comodidad de los usuarios, se ha desarrollado una interfaz de botón.
Se han desarrollado consultas correspondientes para probar la base de datos. Completar estas consultas nos permite juzgar el desempeño normal del sistema de información de la biblioteca de una escuela rural.
LISTA BIBLIOGRAFICA
