Diseñando una base de datos en el modelo relacional
Men? de navegaci?nMen?
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

Diseñando una base de datos en el modelo relacional

El diseño de una base de datos consiste en definir la estructura de los datos que debe tener un sistema de información determinado. Para ello se suelen seguir por regla general unas fases en el proceso de diseño, definiendo para ello el modelo conceptual, el lógico y el físico.

  • En el diseño conceptual se hace una descripción de alto nivel de la estructura de la base de datos, independientemente del SGBD (Sistema Gestor de Bases de Datos) que se vaya a utilizar para manipularla. Su objetivo es describir el contenido de información de la base de datos y no las estructuras de almacenamiento que se necesitarán para manejar dicha información.
  • El diseño lógico parte del resultado del diseño conceptual y da como resultado una descripción de la estructura de la base de datos en términos de las estructuras de datos que puede procesar un tipo de SGBD. El diseño lógico depende del tipo de SGBD que se vaya a utilizar, se adapta a la tecnología que se debe emplear, pero no depende del producto concreto. En el caso de bases de datos convencionales relacionales (basadas en SQL para entendernos), el diseño lógico consiste en definir las tablas que existirán, las relaciones entre ellas, normalizarlas, etc...
  • El diseño físico parte del lógico y da como resultado una descripción de la implementación de una base de datos en memoria secundaria: las estructuras de almacenamiento y los métodos utilizados para tener un acceso eficiente a los datos. Aquí el objetivo es conseguir una mayor eficiencia, y se tienen en cuenta aspectos concretos del SGBD sobre el que se vaya a implementar. Por regla general esto es transparente para el usuario, aunque conocer cómo se implementa ayuda a optimizar el rendimiento y la escalabilidad del sistema.

BONUS: Consigue tu ebook recopilatorio GRATIS >> Héroe en SQL: manual de iniciación

El modelo relacional

En el modelo relacional las dos capas de diseño conceptual y lógico, se parecen mucho. Generalmente se implementan mediante diagramas de Entidad/Relación (modelo conceptual) y tablas y relaciones entre éstas (modelo lógico). Este es el modelo utilizado por los sistemas gestores de datos más habituales (SQL Server, Oracle, MySQL...).

Nota: Aunque mucha gente no lo sabe, a las bases de datos relaciones se les denomina así porque almacenan los datos en forma de “Relaciones” o listas de datos, es decir, en lo que llamamos habitualmente “Tablas”. Muchas personas se piensan que el nombre viene porque además las tablas se relacionan entre sí utilizando claves externas. No es así, y es un concepto que debemos tener claro. (Tabla = Relación).

El modelo relacional de bases de datos se rige por algunas normas sencillas:

  • Todos los datos se representan en forma de tablas (también llamadas “relaciones”, ver nota anterior). Incluso los resultados de consultar otras tablas. La tabla es además la unidad de almacenamiento principal.
  • Las tablas están compuestas por filas (o registros) y columnas (o campos) que almacenan cada uno de los registros (la información sobre una entidad concreta, considerados una unidad).
  • Las filas y las columnas, en principio, carecen de orden a la hora de ser almacenadas. Aunque en la implementación del diseño físico de cada SGBD esto no suele ser así. Por ejemplo, en SQL Server si añadimos una clave de tipo "Clustered" a una tabla haremos que los datos se ordenen físicamente por el campo correspondiente.
  • El orden de las columnas lo determina cada consulta (que se realizan usando SQL).
  • Cada tabla debe poseer una clave primaria, esto es, un identificador único de cada registro compuesto por una o más columnas.
  • Para establecer una relación entre dos tablas es necesario incluir, en forma de columna, en una de ellas la clave primaria de la otra. A esta columna se le llama clave externa. Ambos conceptos de clave son extremadamente importantes en el diseño de bases de datos.

Basándose en estos principios se diseñan las diferentes bases de datos relacionales, definiendo un diseño conceptual y un diseño lógico, que luego se implementa en el diseño físico usando para ello el gestor de bases de datos de nuestra elección (por ejemplo SQL Server).

Por ejemplo, consideremos la conocida base de datos Northwind de Microsoft.

Esta base de datos representa un sistema sencillo de gestión de pedidos para una empresa ficticia. Existen conceptos que hay que manejar como: proveedores, empleados, clientes, empresas de transporte, regiones geográficas, y por supuesto pedidos y productos.

El diseño conceptual de la base de datos para manejar toda esta información se puede ver en la siguiente figura, denominada diagrama Entidad/Relación o simplemente diagrama E-R:

Northwind_EF
(pulsa para aumentar)

Como vemos existen tablas para representar cada una de estas entidades del mundo real: Proveedores (Suppliers), Productos, Categorías de productos,  Empleados, Clientes, Transportistas (Shippers), y Pedidos (Orders) con sus correspondientes líneas de detalle (Order Details).

Además están relacionadas entre ellas de modo que, por ejemplo, un producto pertenece a una determinada categoría (se relacionan por el campo CategoryID) y un proveedor (SupplierID), y lo mismo con las demás tablas.

Cada tabla posee una serie de campos que representan valores que queremos almacenar para cada entidad. Por ejemplo, un producto posee los siguientes atributos que se traducen en los campos correspondientes para almacenar su información: Nombre (ProductName), Proveedor (SupplierID, que identifica al proveedor), Categoría a la que pertenece (CategoryID), Cantidad de producto por cada unidad a la venta (QuantityPerUnit), Precio unitario (UnitPrice), Unidades que quedan en stock (UnitsInStock), Unidades de ese producto que están actualmente en pedidos (UnitsOnOrder), qué cantidad debe haber para que se vuelva a solicitar más producto al proveedor (ReorderLevel) y si está descatalogado o no (Discontinued).

Los campos marcados con "PK" indican aquellos que son claves primarias, es decir, que identifican de manera única a cada entidad. Por ejemplo, ProductID es el identificador único del producto, que será por regla general un número entero que se va incrementando cada vez que introducimos un nuevo producto (1, 2, 3, etc..).

Los campos marcados como "FK" son claves foráneas o claves externas.  Indican campos que van a almacenar claves primarias de otras tablas de modo que se puedan relacionar con la tabla actual. Por ejemplo, en la tabla de productos el campo CategoryID está marcado como "FK" porque en él se guardará el identificador único de la categoría asociada al producto actual. En otras palabras: ese campo almacenará el valor de la clave primaria (PK) de la tabla de categorías que identifica a la categoría en la que está ese producto.

Los campos marcados con indicadores que empiezan por "I" (ej: "I1") se refieren a índices. Los índices generan información adicional para facilitar la localización más rápida de registros basándose en esos campos. Por ejemplo, en la tabla de empleados (Employees) existe un índice "I1" del que forman parte los campos Nombre y Apellidos (en negrita además porque serán también valores únicos) y que indica que se va a facilitar la locación de los clientes mediante esos datos. También tiene otro índice "I2" en el campo del código postal para localizar más rápidamente a todos los clientes de una determinada zona.

Los campos marcados con indicadores que empiezan con "U" (por ejemplo U1) se refieren a campo que deben ser únicos. Por ejemplo, en la tabla de categorías el nombre de ésta (CategoryName) debe ser único, es decir, no puede haber -lógicamente- dos categorías con el mismo nombre.

Como vemos, un diseño conceptual no es más que una representación formal y acotada de entidades que existen en el mundo real, así como de sus restricciones, y que están relacionadas con el dominio del problema que queremos resolver.

Modelo lógico

Una vez tenemos claro el modelo E-R debemos traducirlo a un modelo lógico directamente en el propio sistema gestor de bases de datos (Oracle, MySQL, SQL Server...). Si hemos utilizado alguna herramienta profesional para crear el diagrama E-R, seguramente podremos generar automáticamente las instrucciones necesarias para crear la base de datos.

La mayoría de los generadores de diagramas E-R (por ejemplo Microsoft Visio) ofrecen la capacidad de exportar el modelo directamente a los SGBD más populares.

Entonces, todo este modelo conceptual se traduce en un modelo lógico que trasladaremos a la base de datos concreta que estemos utilizando y que generalmente será muy parecido. Por ejemplo, este es el mismo modelo anterior, mostrado ya como tablas en un diagrama de SQL Server:

Northwind_Tablas
(pulsa para aumentar)

En este caso hemos creado cada tabla, una a una, siguiendo lo identificado en el diagrama E-R y estableciendo índices y demás elementos según las indicaciones de cada uno de los campos. Además hemos decidido el mejor tipo de datos que podemos aplicar a cada campo (texto, números, fechas... que se almacenan para cada registro).

Su representación gráfica en la base de datos es muy similar, sin embargo el modelo físico (cómo se almacena esto físicamente), puede variar mucho de un SGBD a otro y según la configuración que le demos.

En resumen

Según Thomas H. Grayson, un buen diseño de base de datos debe poseer siempre las siguientes cualidades, aunque algunas puede llegar a ser contradictorias entre sí:

  • Reflejar la estructura del problema en el mundo real.
  • Ser capaz de representar todos los datos esperados, incluso con el paso del tiempo.
  • Evitar el almacenamiento de información redundante.
  • Proporcionar un acceso eficaz a los datos.
  • Mantener la integridad de los datos a lo largo del tiempo.
  • Ser claro, coherente y de fácil comprensión.

Como hemos visto el diseño de una base de datos parte de un problema real que queremos resolver y se traduce en una serie de modelos, conceptual, lógico y físico, que debemos implementar.

El primero, el diseño conceptual, es el que más tiempo nos va a llevar pues debemos pensar muy bien cómo vamos a representar las entidades del mundo real que queremos representar, qué datos almacenaremos, cómo los relacionaremos entre sí, etc...

El diseño lógico es mucho más sencillo puesto que no es más que pasar el diseño anterior a una base de datos concreta. De hecho muchas herramientas profesionales nos ofrecen la generación automática del modelo, por lo que suele ser muy rápido.

El diseño físico por regla general recae en la propia base de datos, a partir del diseño lógico, aunque si dominamos bien esa parte elegiremos cuidadosamente índices, restricciones o particiones así como configuraciones para determinar cómo se almacenará físicamente esa información, en qué orden, cómo se repartirá físicamente en el almacenamiento, etc...

campusMVP campusMVP es la mejor forma de aprender a programar online y en español. En nuestros cursos solamente encontrarás contenidos propios de alta calidad (teoría+vídeos+prácticas) creados y tutelados por los principales expertos del sector. Nosotros vamos mucho más allá de una simple colección de vídeos colgados en Internet porque nuestro principal objetivo es que tú aprendas. Ver todos los posts de campusMVP

No te pierdas ningún post

Únete gratis a nuestro canal en Telegram y te avisaremos en el momento en el que publiquemos uno nuevo.

Archivado en: Acceso a Datos

Comentarios (13) -

Muchas gracias muy clara la información seguiré revisando sus artículos :)

Responder

Nos alegra de que te haya servido de ayuda.

Saludos cordiales,

>>>El equipo de campusMVP

Responder

hola que tal buena tarde, disculpa en que lenguaje se realiza ese modelo ??

Responder

Lo puedes desarrollar en lenjuaje SQL , esa base de datos se llama "Northwind" si gustas buscala en internet, para usarla necesitas tener Microsoft SQL Server.

Responder

JPallares
JPallares

Esa BD viene como ejemplo en Microsoft Access creo que desde la versión 2007 y permite ver la configuración de todos los objetos de la BD, el modelo Entidad - Relación y los campos de las tablas para ver como están declarados.... Deja ver todo y es muy buen ejemplo.

Responder

ALGUIEN ME PUEDE AYUDAR A RESOLVER POR FRAVOR
La información de los clientes de una empresa determinada se representa mediante la relación CLIENTES de la figura, que tiene columnas para los atributos codcli (código del cliente), nombre (nombre y apellidos del cliente), dirección (calle y número donde se ubica el cliente), codpostal (código postal correspondiente a la dirección del cliente) y codpue (código de la población del cliente). La información sobre las poblaciones se representa mediante la relación PUEBLOS de la misma figura, que tiene columnas para los atributos codpue (código de la población), nombre (nombre de la población) y codpro (código de la provincia en que se encuentra la población).
1.  Identificar las Entidades y Relaciones
2.  Diseñar el modelo Entidad Relación
3.  Definir las cardinalidades y el tipo de Relación
4.  Pasar al modelo Relacional partiendo del modelo Entidad Relación
5.  Pasar del modelo Relacional a Tablas
6.  Crear la base de datos con en el SGBD MySQL con sus respectivas Tablas (utilizar lenguaje SQL y guardarlo en un bloc de notas luego de cada ejecución)
7.  Llenar las tablas de la BD creada con información utilizando lenguaje SQL (guardar en un bloc de notas el código luego de cada ejecución)

Responder

Ponte a hacer tu tarea, no sabes lo mal que te vez haciendo eso.

Responder

Muy cierto, no se le puede ayudar hacer la tarea, esfuércese mas...

Responder

Buenas!!
Me pueden ayudar hacer las relaciones de la BD en PgAdmin.
Ya tengo la BD armada sólo me falta como hacer el Diseño Lógico. Porfa ayuda!

Responder

Muchas gracias, me ha sido de mucha ayuda. Voy a pegarle una leida al sitio se ve interesante :D

Saludos .

Responder

Alguien me puede ayudar con este trabajo de MODELO RELACIONAL
La Municipalidad de Itatí ha decidido guardar información referente a la Peregrinación a la Virgen, en una base de datos. La información que se desea almacenar es la siguiente:

La Peregrinación a Itatí se puede realizar por distintos caminos – ruta 12, ruta 14, etc., - se desea guardar información referida a: el nombre que las identifica, el número de kilómetros totales y el tiempo estimado para la realización del camino.

Cada camino se compone de distintas etapas que se identifican por un número correlativo dentro de cada camino, y para cada una de ellas se desea saber el número de kilómetros, el tiempo estimado y las distintas localidades por las que pasa. Además, se quiere conocer la localidad de salida y de llegada de la correspondiente etapa.

Se recogerán las distintas localidades por las que pasa cada camino. La información recolectada será: nombre de la misma, departamento al que pertenece y código postal. Se debe tener en cuenta que localidades comunes pueden recorrer distintos caminos.

Se desea guardar información sobre los albergues para peregrinos que existen en algunas de las localidades que están en el recorrido. Esta información consta de: nombre del albergue, capacidad y precio – si lo tuvieran -.

Por último, se quiere registrar los peregrinos que realizan dicha peregrinación. Cada uno de ellos lleva un carnet que consta de un número de identificación, el nombre completo del peregrino, su dirección y las localidades por las que pasó a lo largo del recorrido junto con el día que llegó a dicha localidad.

Responder

Gracias! muy buena la info!

Responder

Pingbacks and trackbacks (1)+

Agregar comentario