Fundamentos de Bases

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 8

Nombre: Ariam Estefania Diaz Sanchez.

ID: 00710659

Ingeniería Software y Sistemas computacionales.

Modulo: Fundamentos de Bases de Datos.

PREROYECTO

ENERO - ABRIL 2023.

4to Cuatrimestre.
En el momento en que surgen problemas de ejecución de la base de datos, no es
muy probable que las razones precisas sean evidentes con prontitud. Un DBA
(Administrador de bases de datos) debe descifrar problemas ambiguos de los
clientes finales en problemas explícitos que puedan mostrar por qué se están
produciendo los problemas. Este proceso puede poco engorroso y hacer que los
problemas pasen desapercibidos, especialmente sin una solución de prueba de
carga, como LoadView, para ayudar al DBA.

La capacidad de medir el rendimiento de la base de datos y


reconocer problemas explícitos de la base de datos, es quizás
la razón más convincente para las pruebas de rendimiento y la
supervisión. Cuando se enfrenta a una prueba de
rendimiento, el DBA puede descubrir rápidamente los
problemas actuales. En lugar de buscar el controlador
principal del problema manualmente, las pruebas de
carga pueden mostrar qué componentes de base de
datos están bajo rendimiento para corregir problemas.
Además, junto con una solución de supervisión continua, los
administradores de bases de datos pueden establecer límites de
ejecución que, una vez descubiertos, envían inmediatamente una alerta
si no se cumplen. Además, los administradores de bases de datos pueden
configurar monitores para que se ejecuten a intervalos específicos con un objetivo
final para distinguir entre los problemas que se deben atender inmediatamente o los
que necesitan tiempo adicional para investigar.

Piense en una situación típica: un DBA se notifica a través del equipo de desarrollo
web, explicando que una aplicación no responde lo suficientemente rápido. El DBA,
equipado con la solución correcta, puede revisar a través de los diversos
dispositivos de monitoreo y buscar cuándo se produjeron los errores. El DBA es
capaz de utilizar un panel para distinguir fácilmente los cuellos de botella que
causan conflictos y, a continuación, podría corregir el problema rápidamente. Sin un
historial de datos de rendimiento, un DBA que no tiene ninguna solución para buscar
en el tiempo de actividad y la funcionalidad realmente no tiene idea de por dónde
empezar, lo que hace que este error siga afectando a los usuarios finales.
Las pruebas de carga de definición generalmente se refieren a las pruebas como
un subconjunto del proceso de pruebas de rendimiento del software, que
normalmente también incluye varios otros tipos de pruebas, como pruebas de
esfuerzo, pruebas de remojo, pruebas de picos, pruebas de resistencia, pruebas de
volumen y pruebas de escalabilidad, entre otros tipos de pruebas.

De hecho, Google sugiere que el 53% de las personas abandonan un sitio móvil si
tarda más de tres segundos en cargar, y que los sitios móviles que cargan un
segundo más rápido pueden obtener hasta un 27% más de conversiones, y un 36%
menos de rebote.

Pero no sólo se trata de mejorar la UX: la velocidad de carga es, desde hace ya
varios años, un factor de posicionamiento SEO. Esto significa que los sitios que
sean más lentos para cargar tienen menos probabilidades de aparecer primero en
la página de resultados del buscador, tanto en móviles como en escritorio.

La calidad del servicio de hosting impacta directamente en la velocidad de carga.


Un servidor barato puede tener velocidades de transferencia muy bajas, o cuellos
de botella en su rendimiento si se trata de hosting compartido. Esto puede aumentar
los tiempos de respuesta del equipo, y hacer que la velocidad de carga de un sitio
suba.
Google compila una serie de recomendaciones técnicas adicionales en sus recursos
de PageSpeed Insights. En este enlace puede encontrarse información adicional
sobre distintas maneras de mejorar la velocidad de carga, como:

• Evitar redirecciones a páginas de destino.


• Habilitar la compresión.
• Aprovechar el almacenamiento en caché de los navegadores.
• Minificar recursos.
• Optimizar la entrega de CSS.
• Priorizar el contenido visible.
• Quitar el JavaScript que bloquea el renderizado del contenido.

Una transacción es una secuencia de operaciones realizadas como una sola unidad
lógica de trabajo. Una unidad lógica de trabajo debe exhibir cuatro propiedades,
conocidas como propiedades de atomicidad, coherencia, aislamiento y durabilidad
(ACID), para ser calificada como transacción.

Atomicidad
Una transacción debe ser una unidad atómica de trabajo, tanto si se realizan todas
sus modificaciones en los datos, como si no se realiza ninguna de ellas.

Coherencia
Cuando finaliza, una transacción debe dejar todos los datos en un estado coherente.
En una base de datos relacional, se deben aplicar todas las reglas a las
modificaciones de la transacción para mantener la integridad de todos los datos.
Todas las estructuras internas de datos, como índices de árbol b o listas doblemente
vinculadas, deben estar correctas al final de la transacción.
Diseño de base de datos: fases principales
Como cada proceso, el diseño de base de datos está compuestos por distintas
etapas secuenciales.

Recopilación y análisis de requisitos


Esta primera fase consiste en un paso previo obligatorio, para asegurarnos de que
nuestra base de datos cumplirá con nuestros objetivos. Para ello, deberemos
analizar distintos factores, entre los cuales:
Los datos que necesitamos almacenar y de dónde provienen.
La información que los datos describen.
Los usuarios de la base de datos y sus necesidades a la hora de acceder a los
datos.

Diseño conceptual
En esta fase se representan una descripción a alto nivel del contenido de la base
de datos, independientemente del sistema de gestión de base de datos que se
utilizará a continuación. Se definen en un dibujo las entidades, sus atributos y las
relaciones entre ellas.
Elección de un sistema de gestión de base de datos
Es en esta fase donde elegiremos el sistema de gestión de bases de datos (SGBD)
concreto que mejor se adapta a nuestro proyecto, como, por ejemplo, Oracle,
MySQL, Microsoft SQL Server y PostgreSQL.

Diseño lógico
En esta fase, se traduce el modelo conceptual obtenido anteriormente a un
esquema lógico, que describe la estructura de la base de datos. Se trata de la fase
en la cual se diseñan las tablas propiamente dichas, con sus filas, columnas y
relaciones. El modelo lógico depende del SGBD que se utilizará.

Diseño físico
En esta fase se definen las estructuras de almacenamiento de la base de datos de
forma física. Es cuando se escribe el código (por ejemplo, SQL) para concretar el
diseño en el motor de base de datos que hemos escogido.
Implementación
Finalmente, se crea y se compila el esquema de la base de datos, se generan los
ficheros y las aplicaciones que implementan las transacciones.

Principios de diseño de base de datos


Para que nuestra base de datos sea eficiente y responda a los requerimientos, es
necesario seguir una serie de principios que deben guiar el proceso de diseño de
base de datos.
Organización eficiente de las tablas, las unidades fundamentales de la base de
datos. Cada tabla se compone de filas, también llamadas registros, y columnas,
conocidas como campos. En los campos debería almacenarse un solo tipo de
información (parte lógica). También no deberían almacenarse datos que pueden ser
obtenidos mediante cálculos sobre otros datos.
Diseño de las claves primarias y las claves externas. Las claves primarias (o PK),
son columnas que identifican de forma única cada fila y permiten construir
relaciones entre tablas. Las claves primarias nunca pueden tener un valor nulo o
duplicado. Por otro lado, las claves externas deben corresponder con las claves
primarias de las tablas con la cual se relacionan.
Diseño de las relaciones entre tablas, que pueden ser de uno a uno, de uno a
muchos o de muchos a muchos. Las relaciones permiten organizar la información
entre distintas tablas, optimizando el espacio disponible.
Normalización de la base de datos, que permite cumplir con los estándares de la
industria. La normalización es necesaria si vamos a trabajar con una base de datos
de tipo OLTP y las formas más comunes son:
• Primera forma normal: un solo valor para cada celda de una tabla.
• Segunda forma normal: los atributos deben depender de la clave primaria de
la tabla.
• Tercera forma normal: cada columna que no contenga una clave tiene que
ser independiente de las otras columnas.

Los beneficios de las pruebas de carga

El propósito de las pruebas de carga es simular el tráfico esperado que su sitio web,
aplicación o sistema debe administrar adecuadamente de forma regular, sin
experimentar una degradación importante. Puede haber casos en los que los
sistemas pueden experimentar la desaceleración ocasional de un aumento
inesperado de usuarios, pero el sistema debe recuperarse y reanudar las
operaciones normales dentro de un período de tiempo esperado.

Disminuir los tiempos de carga de la página: Obviamente, la velocidad es clave


cuando se trata de la experiencia del usuario y un sitio o aplicación lenta hará que
los clientes impacientes, o que abandonen completamente su sitio. Si hay páginas
críticas para impulsar los ingresos, las pruebas de carga pueden ayudar a
determinar el problema específico y ayudar a los equipos de WebOps a priorizar las
páginas afectadas y solucionar los problemas, minimizando el impacto negativo
potencial.
Descubrir cuellos de botella: las pruebas de carga de una aplicación o sitio en la
fase de desarrollo pueden descubrir cuellos de botella comunes, como la cpu, la
memoria y la utilización de la red, lo que permite a los desarrolladores solucionar
estos problemas antes de insertar código o aplicaciones en producción.
Ubicaciones geográficas: si sabe de dónde provienen la mayoría de sus clientes, la
configuración de una prueba desde esas ubicaciones puede identificar problemas
específicos que afectan a esos visitantes. Esto garantiza que todos puedan acceder
a su sitio, sin importar desde qué áreas geográficas visiten, y que su experiencia
sea consistente en todo el mundo.
Establecer acuerdos de nivel de servicio (SLA): la planificación de capacidad ayuda
a determinar qué recursos de hardware y software se necesitan para ejecutar una
aplicación, dentro de un conjunto de requisitos predefinidos. Las pruebas de carga
pueden ayudar a predecir cómo se desempeñará una aplicación bajo un gran estrés
y si es necesario invertir en infraestructura adicional en el futuro.
Referencias:
https://www.loadview-testing.com/es/pruebas-de-carga/

https://www.dotcom-monitor.com/wiki/es/knowledge-base/solucion-de-prueba-de-
carga/

También podría gustarte