BASES DE DATOS QUIZ beta

La representación física de tablas y otros objetos relacionales en estructuras y archivos del sistema gestor influye mucho en el rendimiento final de las aplicaciones al consultar y modificar los datos. Un diseño detallado especifica no solo los esquemas lógicos sino también ubicación de tablas e índices en tablespaces según patrones de acceso, tipos de datos adecuados al rango y distribución de valores, parámetros de almacenamiento inicial y crecimiento anticipando volúmenes esperados. Asimismo un modelo eficiente define minuciosamente índices, partitioning, compression y recursos a nivel de cada objeto crítico para optimizar tiempos de respuesta, uso del buffer cache y recursos del storage. Afinar estos factores físicos puede marcar diferencias de ordenes de magnitud en el desempeño.

• Las consideraciones de rendimiento conllevan demasiada complejidad de configuración anulando cualquier posible beneficio.
  

• Los detalles físicos de implementación no afectan ya que las consultas SQL se optimizan automáticamente para cualquier estructura lógica de tablas.

• Solo importa el modelo lógico, los aspectos físicos los decide internamente el motor de base de datos.

• El rendimiento operativo depende en gran medida de cómo se implementen físicamente los objetos relacionales según perfiles de utilización y crecimiento esperados.

  
  

Uno de los conceptos centrales del modelo entidad-relación son las entidades, que representan conjuntos de objetos del mundo real relevantes para el sistema de información, sobre los cuales se desea registrar datos. Por ejemplo, las entidades cliente, producto, factura, pedido. Cada entidad tiene una existencia independiente y se diferencia de otras entidades. Para identificar de forma única cada instancia de una entidad, se define una clave primaria formada por uno o más atributos que identifican de modo único a cada tupla o fila en la tabla. Por ejemplo, el número de documento para una entidad persona, el número de serie para un producto. La correcta elección de identificadores de entidades garantiza integridad de datos.

• Las entidades y claves primarias no son necesarias porque los registros se identifican por la combinación de todos sus atributos.

• Las entidades representan conjuntos de elementos del mundo real sobre los que registrar datos, identificándose unívocamente mediante una clave primaria.

• La clave primaria no tiene relación con identificar registros únicos sino con establecer restricciones especiales.

• Lo importante son los atributos de cada tabla, las entidades y claves surgen implícitas al modelar los datos.

Los atributos constituyen las características o propiedades relevantes que se quieren registrar sobre cada elemento de las entidades. Por ejemplo, para la entidad cliente, atributos frecuentes son documento de identidad, nombres, dirección, email, teléfono. Cada atributo tiene asociado un dominio o tipo de dato que determina los valores permitidos y restricciones aplicables. Dominios típicos son numérico, alfanumérico, fecha, booleano. Los atributos modelan distintos aspectos de interés de las entidades para soportar los requerimientos de información del sistema. Una cuidadosa elección de atributos vinculados estrechamente a su entidad respaldará correctamente las necesidades de datos de los usuarios

• La elección de atributos no es relevante ya que pueden agregarse dinámicamente cuando se necesiten sin afectar el modelo.
  

• Los atributos representan propiedades de información relevante para una entidad con valores estructurados mediante la definición de dominios.

• Lo importante son las relaciones entre entidades, los atributos se agregan después para necesidades puntuales.
  

• Las entidades sólo incluyen un identificador, los atributos se modelan independientemente sin estar vinculados a entidades específicas.

Las relaciones permiten establecer interconexiones y dependencias entre distintas entidades de un modelo de datos. Por ejemplo, un alumno se matricula en varios cursos, un pedido lo realiza un cliente, una factura está vinculada a un pedido. Las relaciones establecen cardinalidades que definen cuántas instancias de una entidad se relacionan con cuántas de la otra entidad. Las relaciones cuyas dos cardinalidades son 1 se denominan uno a uno. Si una entidad tiene cardinalidad 1 y la otra N se dice que es uno a muchos. Finalmente, si ambas entidades tienen cardinalidad N se trata de una relación muchos a muchos. Identificar correctamente estos distintos tipos de interrelaciones entre entidades resulta esencial para producir un modelo preciso y completo.

• Las relaciones siempre son uno a muchos ya que no tiene sentido relacionar un registro de una entidad con varios de otra.
  

• Las interrelaciones no son importantes, basta con que los datos estén en tablas independientes.

• El modelo debe evitar las relaciones mucho a mucho porque introducen complejidad innecesaria.

• Las relaciones vinculan entidades estableciendo distintas cardinalidades posibles uno a uno, uno a varios o varios a varios.

Cuando entre dos tablas relacionadas existe una relación uno a varios, la tabla del lado “varios” debe contener una clave foránea que reference la clave primaria de la otra tabla para vincular los registros relacionados. Por ejemplo, la tabla Pedidos tendrá una clave foránea hacia la tabla Cliente ya que un cliente puede tener varios pedidos asociados. Esta clave foránea establece la integridad referencial garantizando que no puedan crearse pedidos para clientes inexistentes. Las claves foráneas correctamente definidas aseguran consistencia lógica entre instancias de entidades con dependencias entre sí al crear, modificar o borrar registros interrelacionados.

• Las claves foráneas en una tabla referencian registros de otra tabla relacionada para garantizar integridad y consistencia.
  

• Las tablas no requieren claves foráneas, la aplicación controla las relaciones entre registros mediante joins.

• Lo importante son las claves primarias, las foráneas se agregan si acaso sólo con fines de documentación.

• Las restricciones de integridad referencial por claves foráneas son irrelevantes por la complejidad que conllevan.

El estándar de notación para el modelo entidad-relación desarrollado por Chen, permite representar las entidades como rectángulos con sus atributos, determinando con doble subrayado la clave primaria. Las relaciones se modelan como rombos conteniendo los verbos enlazando las entidades relacionadas. Cardinalidades uno y varios se indican gráficamente con líneas simples y dobles respectivamente. Este estándar de notación con símbolos precisos facilita la interpretación y análisis de cualquier modelo entidad-relación por analistas y usuarios técnicos y no técnicos. Otras notaciones muy utilizadas son UML y Crow Foot, ésta última extendida en base de datos relacionales. La coherencia en la notación aplicada en un proyecto contribuye ampliamente a mejorar la comunicación entre todos los interesados.

• Existen notaciones estándar como la de Chen que facilitan la especificación y comprensión de modelos entidad-relación para todas las audiencias.
  

• Los modelos conceptuales no tienen una representación gráfica estándar definida para ello.

• La notación es solo decorativa no afecta la semántica del modelo de datos en sí mismo.

• No se requiere una notación estándar porque cada analista puede usar la más cómoda según sus preferencias.

  
  

El modelo relacional implementa en la base de datos las estructuras definidas inicialmente en el modelo entidad-relación extendiéndolo con aspectos críticos para la gestión de los datos. A cada entidad le corresponderá una tabla donde cada fila representa una tupla de la relación conteniendo toda la información de las instancias de esa entidad. Las columnas modelan sus atributos con sus respectivos tipos de datos, mientras que una clave primaria identifica unívocamente cada tupla. Las tablas se relacionan entre sí mediante claves foráneas para implementar todas las relaciones uno-a-muchos o uno-a-uno del modelo original. El modelo relacional final es la base para generar sentencias DML en SQL que consultan, modifican e interrelacionan los datos transaccionales en la base de datos.

• Las tablas no tienen vínculo con entidades ni atributos porque contienen datos transaccionales dinámicos únicamente.
  

• La notación es solo decorativa no afecta la semántica del modelo de datos en sí mismo.

• Las tablas del modelo relacional contienen en filas las instancias de entidades con sus atributos en columnas, interrelacionadas por claves foráneas.

• Las relaciones uno-a-muchos no tienen implementación en el modelo relacional que sólo contiene tablas independientes.

Uno de los principales objetivos de la normalización de bases de datos es organizar los datos en estructuras que minimicen la redundancia para evitar problemas de inconsistencia e integridad. La primera forma normal establece que cualquier tabla debe contener una clave primaria, sin grupos repetitivos ni atributos compuestos. La segunda forma normal requiere además que todos los atributos no clave dependan completamente de la clave principal. Finalmente, la tercera forma impone que no existan dependencias transitivas entre los atributos no clave. Cada paso de normalización incrementa la calidad del modelo relacional al eliminar campos y estructuras susceptibles de generar anomalías por redundancia de datos. Sin embargo, la normalización excesiva puede tener impactos negativos en performance por lo que se recomienda analizar un punto óptimo de equilibrio.

• Los modelos relacionales no requieren normalización porque SQL evita inconsistencias con cualquier estructura de tablas.

• La normalización mejora la calidad del modelo relacional eliminando redundancias mediante reglas que minimizan anomalías e inconsistencias.
  

• La primera forma normal es suficiente y las otras son sólo teóricas sin beneficios prácticos.

• Es preferible no normalizar para mejor performance y facilidad de consultas aún con el riesgo de permitir inconsistencias.

  
  

Los Sistemas de Gestión de Bases de Datos incorporan características para reforzar la calidad y consistencia de los modelos relacionales subyacentes. Las restricciones check permiten validar que cumplan condiciones los valores de ciertos campos o grupos de campos. Los triggers se disparan automáticamente ante eventos insert, delete o update sobre tablas para expandir las reglas de negocio. Las vistas y funcionesproporcionan abstracciones altamente reutilizables encapsulando sentencias SQL tediosas o complejas. Los procedimientos almacenados habilitan la construcción de lógica de aplicación del lado servidor. Finalmente, los cursores posibilitan el procesamiento interactivo de conjuntos de resultados de consultas por parte de programas clientes. Todas estas características adicionales extienden enormemente la expresividad del modelo relacional.

• El modelo relacional se amplifica con restricciones, triggers, vistas, funciones, procedimientos y cursores que potencian la gestión declarativa de datos.

• La mayoría de características no se aplican porque todas las aplicaciones prefieren SQL puro sin programación del lado servidor.

• Las abstracciones adicionales limitan la performance y consumo de recursos al extender el modelo relacional.
  

• Las únicas construcciones necesarias son tablas y claves, las demás incorporan complejidad innecesaria.

  
  

Una característica deseable durante el diseño de bases de datos es la flexibilidad para gestionar el cambio. Resulta esencial modelar pensando en la evolución futura ante nuevos requerimientos de información o cambios de reglas de negocio que obligan a reflejar otras perspectivas de los datos. Incorporar esta visión de adaptación reducirá esfuerzos en el ciclo de vida al realizar reestructuraciones. Por ejemplo, tablas con columns reservados no usados inicialmente, claves sustitutas para ocultar las reales al exterior, views desacoplando al cliente de tablas base, metadatos adicionales en comentarios. Documentar exhaustivamente decisiones de modelado también facilita reorganizaciones futuras. Planificar por adelantado la gestión de cambio permite ganar agilidad de respuesta ante movimientos inesperados en los requerimientos de información.

• No se debe diseñar para el futuro sino para las necesidades actuales únicamente.

• Incorporar flexibilidad en el modelado inicial pensando en evolución futura reducirá esfuerzos en los inevitables cambios.

• Las bases de datos no pueden evolucionar después del diseño inicial así que la adaptación al cambio es imposible.
  

• Los modelos relacionales en SQL hacen innecesarias consideraciones especiales de flexibilidad.