Comprender los bloques de construcción de bases de datos en SQL Server

Me gusta este Blog 3

Añadido por Peter Avila Noviembre 21, 2012

Cada casa tiene una cocina, al menos un baño y un dormitorio, una puerta de entrada, un sistema de plomería y otras cosas. Estas cosas se pueden organizar de diferentes maneras y en diferentes números para producir diferentes casas. Lo mismo ocurre con las bases de datos. Hay ciertas cosas que todas las bases de datos tienen en común. En este post, presentaré los bloques de construcción que componen todas las bases de datos y mostraré cómo se ensamblan. También discutiré tres reglas que deben seguirse al usar los bloques de construcción.

El material presentado en este post debe ser de valor para cualquier persona que tenga cualquier tipo de interacción con bases de datos, pero se encuentra en un nivel muy elemental. Para una discusión más completa sobre el diseño de bases de datos, consulte mi artículo, Un enfoque Intuitivo para el Diseño de bases de datos.

Mini-Mundos.

Antes de llegar a los bloques de construcción, tomemos un momento para entender el término mini-mundo porque nos ayudará a entender los bloques de construcción.

Una base de datos es un modelo de un mini-mundo. Un mini-mundo puede ser un consultorio médico, un negocio minorista, una biblioteca o muchas otras cosas. Cuando queremos información sobre el mini-mundo, recurrimos a la base de datos que lo modela.

Digamos que vas al médico para una cita. Cuando le diga a la recepcionista que tiene una cita, la recepcionista intentará encontrar su cita en el modelo (la base de datos). Si el modelo se ha mantenido actualizado con su mini-mundo, debería poder confirmar que tiene una cita. Del mismo modo, si una empresa quiere saber cuál de sus clientes de gran volumen no ha realizado pedidos en los últimos 6 meses, puede recurrir al modelo de su mini-mundo si se ha mantenido actualizado con ese mini-mundo.

Un mini-mundo puede ser un negocio completo, o puede ser parte de un negocio, como una sucursal bancaria o el departamento de ventas.

Lo primero que hace un diseñador de bases de datos es entender el mini-mundo, porque el trabajo del diseñador es diseñar un modelo de ese mini-mundo. Y para entender el mini-mundo, el diseñador comienza identificando los bloques de construcción que entrarán en el ensamblaje de una base de datos.

Los Bloques de construcción

1. Entidades

Una entidad es algo que existe en el mini-mundo y que tiene características que nos interesan. Por ejemplo, en un mini-mundo de inscripción escolar, hay entidades de estudiantes, entidades de cursos, entidades de instructores y otras. Los estudiantes tienen nombres, direcciones, GPA y otras características que nos interesan. Los cursos tienen títulos, créditos, cuotas y otros. Y los instructores tienen nombres, direcciones, calificaciones y otros. Las entidades son únicas. Cada estudiante es una entidad única; están Juan y María, y así sucesivamente. Cada curso es una entidad única y cada instructor es una entidad única.

Las entidades no tienen que ser cosas físicas. Aunque no se puede tocar, ver u oler una inscripción, sin embargo, existe en el mini mundo de inscripción escolar y tiene características que nos interesan, como la fecha de la inscripción, el estudiante que se inscribió, el curso en el que el estudiante se inscribió y la calificación final recibida. Las ventas son otros ejemplos de entidades que no tienen un componente físico pero que tienen características de interés para nosotros (fecha de venta, cliente, vendedor, total del pedido, método de envío, condiciones de pago, etc.).).

2. Tipos de entidad

Las entidades del mismo tipo pertenecen a un tipo de entidad. Un tipo de entidad es un conjunto de entidades de ese tipo. El tipo de entidad Estudiantil es el conjunto de todos los estudiantes. El tipo de entidad de curso es el conjunto de todos los cursos, y el tipo de entidad de instructor es el conjunto de todos los instructores.

Los tipos de entidad son el concepto más importante en este post. Se convierten en tablas en una base de datos.

3. Atributos

Los atributos de una entidad son las características de esa entidad que nos interesan. Como ya se mencionó, los atributos de los estudiantes incluyen nombre, dirección, GPA y otros. Los cursos tienen nombres, créditos, departamentos a los que pertenecen y otros. Y así sucesivamente con otros tipos de entidades.

Ensamblando los Bloques de construcción

¿Cómo se representan estos bloques de construcción en la base de datos? Cada tipo de entidad está representado por una tabla en la base de datos. En esa tabla, las filas individuales son las entidades únicas y las columnas son los atributos. Aquí hay un ejemplo de una tabla que representa el tipo de entidad de tarjeta de crédito:

Reglas de bloques de construcción

Al trabajar con bloques de construcción, es importante seguir ciertas reglas que no solo facilitan el trabajo con objetos de base de datos, sino que también evitan anomalías de datos (las anomalías de datos están más allá del alcance de esta publicación, pero se discuten en detalle en mi artículo, Un enfoque intuitivo para el diseño de bases de datos).

Regla 1: Cada tabla debe representar un solo tipo de entidad.

La base de datos del mini-mundo de inscripción escolar, arriba, necesita las siguientes tablas: Estudiante, Curso, Instructor, Inscripción y otros, uno para cada tipo de entidad identificado en ese mini-mundo. La base de datos del mini-mundo del consultorio médico necesita una mesa para el médico, una mesa para el paciente, una mesa para citas, una mesa para Medicamentos y otras cosas. Una tabla para cada tipo de entidad.

Hay una excepción a esta regla. Prepárate, aquí viene el torbellino cerebral: Si dos tipos de entidad comparten los mismos atributos y una entidad en uno de los tipos de entidad es también una entidad en el otro tipo de entidad (una entidad es miembro de ambos tipos de entidad), entonces los dos tipos de entidad se pueden representar en una tabla. Aquí está, de nuevo: Un tipo de entidad Profesor y un tipo de entidad Asesor se pueden representar en una tabla, porque los asesores también son profesores y tienen los mismos atributos (nombre de profesor/asesor, calificaciones de profesor/asesor y otros). Y de nuevo: Un tipo de entidad de carpeta y un tipo de entidad de subcarpeta se pueden representar en una tabla, porque todas las entidades de subcarpeta también son entidades de carpeta y comparten los mismos atributos (título de carpeta, tamaño de carpeta, número de elementos en carpeta, carpeta principal y otros). Solo una más: Los tipos de entidad Empleado y Gerente se pueden representar en la misma tabla, porque las entidades empleados y gerentes tienen los mismos atributos y las entidades gerentes también son entidades de empleados. Esta excepción a la regla se examina más de cerca en otro blog: SQL Server – La consulta de unión automática.

Por cierto, observe que esta regla es la razón por la que la forma correcta de nombrar una tabla es en singular. Las tablas representan un único tipo de entidad.

Regla 2: Todas las columnas deben ser atómicas.

¿Alguna vez se ha preguntado por qué las tablas de la base de datos pueden tener columnas para la Ciudad y el Estado, pero solo una columna para la dirección? Tal vez se haya preguntado por qué no hay una columna para el Número de Dirección, otra para el Tipo de Calle de Dirección (Blvd., Avenida, etc.), otro para el número de apartamento, y así sucesivamente. ¿Por qué estas columnas generalmente se agrupan en una sola columna de dirección? La respuesta a todas estas preguntas radica en la comprensión de la atomicidad.

Cuando decimos que una columna es atómica, queremos decir que no se puede subdividir más y aún conservar el significado. Hagamos una columna y llamémosla MegaDirecta que incluya una dirección junto con la ciudad y el estado.

Pero debido a que hacemos búsquedas, ordenaciones y otras operaciones en partes de esa columna (búsqueda por ciudad, ordenar por estado, imprimir solo la parte de la dirección de la calle, y así sucesivamente), podemos decir que las subdivisiones de esa columna tienen su propio significado (dirección de la calle, Ciudad y Estado). Por lo tanto, MegaAddress no es atómico. Una mejor mesa sería:

Ahora, ¿qué pasa con la columna streetAddress? ¿Deberíamos subdividirlo en StreetNumber, StreetName y StreetType? Mientras no hagamos nada significativo con subdivisiones de la misma, si no clasificamos los números de las calles, buscamos todos los caminos o avenidas, etc., entonces la columna es atómica tal como está. Pero si hacemos esas cosas, entonces la columna no es atómica y entonces, sí, deberíamos subdividirla como se describe.

Regla 3: las Columnas no puede tener varios valores.

Algunos tipos de entidad contienen atributos multivalores, o un atributo que puede tener más de un valor. En una tabla de cursos, puede haber un atributo llamado Prerrequisitos. Dado que una entidad de curso puede tener más de un requisito previo, el atributo Prerrequisito es un atributo multivalor. Cuando creamos una tabla para el tipo de entidad de curso, no podremos representar el atributo Prerrequisito como una columna en la tabla. Para representar correctamente un atributo multivalor, necesitaremos crear otra tabla para él y relacionarla con la tabla original utilizando una relación de uno a muchos (las relaciones se discuten en detalle en los cursos que imparto en Interface Tachnical Training SQL100: Introducción a Transact-SQL y SQL250: Transact-SQL para Desarrolladores y en mi artículo, Un Enfoque Intuitivo para el Diseño de bases de datos). Otros ejemplos de atributos multivalor incluyen los dependientes de un empleado, las calificaciones de un médico, etc.

La regla 3 dice que, para una entidad dada (fila en una tabla), solo puede haber un valor en cada columna.

Resumen

Este post introdujo el concepto de mini-mundo como los aspectos de un negocio u otro entorno que modela una base de datos. La publicación también describe una tabla de base de datos que representa un solo tipo de entidad en la que las filas contienen las entidades individuales del mismo tipo y las columnas representan los atributos de esas entidades. Se introdujeron tres reglas relativas a las tablas. La regla 1 establece que un cuadro debe representar un único tipo de entidad. La excepción a la regla es cuando dos tipos de entidad comparten los mismos atributos y las entidades de un tipo de entidad son miembros del otro tipo de entidad. En ese caso, ambos tipos de entidad se pueden representar en la misma tabla. La regla 2 establece que todas las columnas de una tabla deben ser atómicas, lo que significa que una columna no se puede subdividir y aún así conservar el significado en el mini-mundo. Por último, la regla 3 establece que las columnas de una tabla no pueden tener varios valores, lo que significa que, para una entidad determinada (fila de una tabla), solo puede haber un valor por columna.

¡Disfruta!

Peter Avila

Instructor de SQL Server – Capacitación Técnica de Interfaz

Phoenix, AZ