En esta nueva entrega de Code Time continuamos en el campo de las bases de datos ahondado en el uso de Modelos para reflejar la realidad. Con este podcast damos cierre al tema de los modelos Entidad-Relación y Relacional.
Listen to “Code Time (52): Bases de datos: Los modelos, un reflejo de la realidad PT 2” on Spreaker.
Nota: Antes de continuar con esta nota te recomendamos hayas leído la entrada anterior y escuchado su respectivo podcast. Con eso podrás entender mejor el tema y así aprender más. Si estás interesado en hacerlo aquí te dejamos un enlace directo.
Claves en entidades
Anteriormente se hizo referencia a las superclaves como conjuntos de atributos que sirven para distinguir a una entidad de otra. Así mismo se habló de las claves candidatas para poder definir a una clave primaria. Ahora bien esto no significa que toda entidad va a tener obligatoriamente una clave primaria asignada. Esto se debe a que muchas veces los atributos no permiten hacer una distinción única.
Debido a esto existen dos categorías de entidades: fuertes y débiles. Las entidades fuertes son aquellas que tienen al menos una clave candidata. Al grupo de las restantes que carecen de esta característica se las denomina entidades débiles.
Para reflejar esto utilizaremos el ejemplo del banco. Consideremos que tenemos las entidades Cuenta, Cliente, Transacción. A esto se le agregan las relaciones realiza_transacción que asocia una Cuenta con Transacción y la relación cuentaCli la cual asocia Cuenta con Cliente. En nuestra representación Cuenta tiene como clave primaria el atributo número-cuenta. Por su parte Transacción tiene los atributos número-transacción, fecha y cantidad. Las transacciones en cuentas diferentes pueden tener el mismo número de transacción por lo que esta entidad no tiene clave candidata.
Para identificar este tipo de entidades utilizamos el concepto de discriminador. Este es un conjunto de atributos que junto a la clave primaria de la entidad fuerte asociada permiten distinguir a una entidad débil de otra. En el caso de transacción la clave primaria estaría formada por número-cuenta y número-transacción (discriminador).
Diagramas Entidad-Relación (E-R)
El modelo entidad relación tiene como utilidad convertir una descripción en un modelo útil. Pero a priori tiene el inconveniente de no parecer muy expresivo. Para eso surgieron los diagramas Entidad-Relación. Estos utilizan figuras simples acompañadas de etiquetas (texto) para representar el modelo de una manera más sencilla.
Figuras en los diagramas Entidad-Relación:
Los diagramas E-R tienen los siguientes componentes base:
- Rectángulos: Conjunto de entidades
- Ellipses: Atributos
- Rombos: Relaciones entre conjunto de entidades
- Líneas: Conectan atributos a conjunto de entidades y conjunto de entidades a relaciones.
Cada componente se etiqueta con la entidad o relación que representa, es decir, se le da un nombre para poder interpretarlo.
En las relaciones se agrega una etiqueta indicando la cardinalidad de cada asociación.
Si una asociación es con sigo misma cada línea lleva una etiqueta que identifique el rol de cada línea.
Las entidades débiles se representan con un rectángulo con doble línea
Como último detalle las claves primarias se destacan con un subrayado.
Mapas Canónicos
Una vez que se ha convertido la información al modelo E-R y creado el diagrama E-R se procede a crear un mapa canónico. Estos son básicamente una conversión del modelo actual a un modelo donde toda información es representable mediante tablas: Modelo Relacional.
En este modelo existen convenciones de conversión:
Entidad fuerte
Tabla donde cada columna representa un atributo y cada fila a una entidad en particular.
Si tenemos la entidad Cliente {nombre-cliente, seguridad-social, calle, ciudad-cliente} generamos una tabla con las columnas (nombre-cliente, seguridad-social, calle, ciudad-cliente).
Entidad debil
Se hace lo mismo que en el caso anterior pero agregando los atributos que forman la clave primaria de la entidad fuerte asociada. Consideremos:
- Entidad fuerte: Cuenta {número-cuenta, saldo}
- Entidad débil: Transacción {número-transacción, fecha, cantidad}
Related Posts
Los grandes mitos de la programación PT 2
Obtendremos la tabla con las columnas (número-cuenta, número-transacción, fecha, cantidad)
Relaciones entre entidades fuertes
La tabla tendrá como columnas los atributos de la misma más las claves primarias de las entidades que la relación involucra.
Consideremos la relación CtaCli que asocia clientes con cuentas la cual cuenta con un atributo fecha. La tabla obtenida tendrá las columnas (seguridad-social, número-cuenta, fecha)
Relaciones entre entidad fuerte y débil
Este es un caso particular, ya que si la relación no cuenta con atributos hacer la conversión resulta en una redundancia innecesaria.
Si hiciéramos la tabla de la relación bitácora la tabla resultante sería (número-cuenta, número-transacción). Pero cuando convertimos Transacción generamos una tabla con más información aún. Así pues hacer la conversión es redundante así que se la omite.
Modelo Relacional
Existen modelos basados en objetos que sirven para describir a nivel conceptual y modelos basados en registros útiles para describir datos a nivel físico. El modelo E-R es una técnica de diseño de bases de datos. Por su parte el modelo Relacional es una formalización teórica de las bases de datos relacionales.
Estructura de las bases de datos relacionales
Una base de datos relacional es una colección de tablas donde cada una tiene un nombre único.
Relación
En el modelo Relacional, a diferencia del modelo E-R, una relación es una tabla (de ahi el nombre de relacional). Cada fila representa una relación entre un conjunto de valores. A esto hay que agregar el concepto de dominio en los atributos. Estos describen el conjunto de los posibles valores que puede tener un atributo. De esta manera podemos definir matemáticamente a un conjunto como un subconjunto del producto cartesiano de una lista de dominios. Resumiendo una tabla es una relación y una fila es una tupla.
Propiedades de las relaciones
No existen tuplas repetidas
Los conjuntos por definición no incluye elementos repetidos. Como las tablas son un conjunto de tuplas estas no pueden repetirse. He aquí la importancia de las claves primarias.
Las tuplas no están ordenadas
Los conjuntos no son ordenados, por lo cual no se puede suponer ningún orden.
Los atributos no están ordenados
La cabecera de una relación se define como un conjunto de atributos. Las columnas de una tabla tienen un orden evidente, de izquierda a derecha, pero los atributos de una relación carecen de un orden.
Todos los valores de los atributos son atómicos
En cada posición de fila y columna dentro de una tabla, siempre existe un solo valor, nunca una lista de valores.
Si una relación satisface estas condiciones se dice que está normalizada.
Esperamos que les haya gustado esta nota. Recuerden que estamos abiertos a criticas constructivas y sugerencias. No se olviden de dejar comentarios, compartir y leer más de BandaGeek para mantenerte informado sobre el mundo de la tecnología.
Puedes escucharnos en Code Time los lunes a las 23:00 Hs Argentina, en Desde la Barra de Abel los martes y jueves a las 23:30 Hs Argentina y en Movimiento Geek los lunes, miércoles y viernes a las 24:00 Hs Argentina.
Recuerda que si quieres aprender Swift 3 desde Cero Gratis puedes hacerlo
Mis medios de contacto
Gmail
Contenido
