Tema 4: Transformación del esquema conceptual al relacional

4.1 Normalización

La normalización puede considerarse como un proceso durante el cual los esquemas de relación modelados se descomponen entre esquemas de relación más pequeños que cumplen con ciertas condiciones establecidas sin pérdida de información y sirven para ayudar a los diseñadores a desarrollar un esquema que minimice los problemas de lógica.

Grados de normalización

Existen básicamente tres niveles de normalización: Primera Forma Normal (1NF), Segunda Forma Normal (2NF) y Tercera Forma Normal (3NF) a  la que se conoce como forma normal de Boyce‑Codd (FNBC). Todas estas formas normales se basan en las dependencias funcionales entre los atributos de una relación. Más adelante se propusieron una cuarta forma normal (4FN) y una quinta (5FN), con fundamento en los conceptos de dependencias multivaluadas y dependencias de reunión, respectivamente. Cada una de estas formas tiene sus propias reglas.

Cuando una base de datos se conforma a un nivel, se considera normalizada a esa forma de normalización. Por ejemplo, supongamos que una base de datos cumple con todas las reglas del segundo nivel de normalización. Se considera que está en la Segunda Forma Normal. Sin embargo, no siempre es conveniente tener una base de datos conformada en el nivel más alto de normalización. Puede llevar a un nivel de complejidad que pudiera ser evitado si estuviera en un nivel más bajo de normalización.

Primera Forma Normal

Es la más elemental de todas.

La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y colocarse en tablas separadas. Estas nuevas tablas heredan la clave primaria de la relación

Observemos el esquema de la tabla MClientes de la base de datos.

MClientes

ID Cliente

Nombre

Apellidos

Dirección

Nombre_Producto1

Costo_Producto1

Nombre_Producto2

Costo_Producto2

Fecha_Pedido

Cantidad_Pedido

ID_Cia_Envios

Nombre_Cia_Envios

La tabla tiene varias columnas repetidas. Éstas se refieren principalmente a los productos y pedidos de estos. De acuerdo con la regla, deben eliminar las columnas repetidas y crearles su propia tabla.

Eliminación de columnas repetidas en una base de datos

<><> <><> <><> <><> <><>

MClientes ID_Clientes Nombre Apellidos Dirección Número_Pedido Fecha_Pedido Cantidad_Pedido ID_Producto Cantidad_producto ID_Cia_Envios Nombre_Cia_Envios

MProducto ID_Producto Nombre_Producto Costo_Producto

Así, se han relaciones donde el cliente tendrá muchos productos que podrá comprar, sin importar cuántos otros clientes quieran comprarlos también. Además, el cliente necesitará haber pedido un producto para ser un cliente y ya no estamos obligados a añadir un cliente cada vez que se añade un nuevo producto al inventario.

Poner la base de datos en la Primera Forma Normal resuelve el problema de los encabezados de columna múltiples (Producto1, Producto2...). Muy a menudo, se comete el error de crear columnas que representen los mismos datos, algo similar a una tabla no normalizada.

La normalización ayuda a hacer mas clara la base de datos, así como a organizarla en partes más pequeñas y más fáciles de entender. En lugar de tener que entender una tabla enorme que tiene muchos diferentes aspectos, solo tenemos que entender elementos pequeños y más manejables, así como las relaciones que guardan con otros elementos también pequeños, lo que nos lleva a que un mejor entendimiento del funcionamiento de la base de datos conducirá a un mejor aprovechamiento de su información.

Segunda Forma Normal

La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un término que describe a aquellos datos que no dependen de la clave de la tabla para identificarlos. En la base de datos de muestra, la información de pedidos está en cada uno de los registros. Sería mucho más simple utilizar únicamente el número del pedido. El resto de la información podría residir en su propia tabla. Una vez que se haya organizado la información de pedidos.

Eliminación de las dependencias parciales -Segunda Forma Normal

<><> <><> <><> <><> <><> <><>

MClientes ID_Clientes Nombre Apellidos Dirección

MProducto ID_Producto Nombre_Producto Costo_Producto

EPedido ID_Pedido Fecha_Pedido Cantidad_Pedido  ID_Producto Cantidad_producto ID_Cia_Envios Nombre_Cia_Envios

Una forma sencilla de ver la segunda forma normal es que, para que una relación se encuentre en ésta debe estar en primera forma normal y además todos los atributos que no sean claves sean dependientes de modo irreducible de la clave primaria.

Al haber alcanzado la Segunda Forma Normal, podemos disfrutar de algunas de las ventajas de las bases de datos relacionales. Por ejemplo, pueden añadirse nuevas columnas a la tabla Clientes sin afectar a las tablas Productos y Pedidos. Lo mismo aplica para las otras tablas. Alcanzar este nivel de normalización permite que los datos se acomoden de una manera natural dentro de los límites esperados.

Una vez que ha alcanzado el nivel de la Segunda Forma Normal, se han controlado la mayoría de los problemas de lógica. Pueden insertarse registros sin un exceso de datos en la mayoría de las tablas. Observando un poco más de cerca la tabla Clientes, vemos la columna Nombre_Cia_Envios. Ésta no es dependiente del cliente. El siguiente nivel de normalización explicará cómo solucionar esto.

Tercera Forma Normal

La regla de la Tercera Forma Normal señala que hay que eliminar y separar cualquier dato que no sea clave. El valor de esta columna debe depender de la clave. Todos los valores deben identificarse únicamente por la clave. En la base de datos de muestra, la tabla Clientes contiene la columna Nombre_Cia_Envios, la cual no se identifica únicamente por la clave. Podría separar estos datos de la tabla y ponerlos en una tabla aparte.

Eliminación de los datos que no son claves para la Tercera Forma Normal

<><> <><> <><> <><> <><> <><>

MClientes ID_Clientes Nombre Apellidos Dirección

MProducto ID_Producto Nombre_Producto Costo_Producto

EPedido ID_Pedido Fecha_Pedido Cantidad_Pedido

DPedido ID_Pedido ID_Producto Cantidad_producto

MCias_Envios ID_Cia_Envios Nombre_Cia_Envios

El Diagrama ER simplificado sería:

Ahora todas las tablas están en la Tercera Forma Normal. Esto da más flexibilidad y previene errores de lógica cuando se insertan o borran registros. Cada columna en la tabla está identificada de manera única por la clave, y no hay datos repetidos. Esto provee un esquema limpio y elegante, que es fácil de trabajar y expandir.

4.2 Diccionario de Datos

Cuando diseñamos una base de datos, para hacer su tratamiento lo mas fácil posible, le asignamos descriptores o “alias” a cada campo mediante el cual nos referimos a él para su manipulación, por lo tanto es necesario dar una descripción de dicho campo que estamos definiendo bajo determinado nombre, es por ello que se requiere contar con un diccionario de datos, el cual contiene información explicativa sobre los campos para facilitar a los desarrolladores el implementar aplicaciones para manejar la base de datos y al mismo tiempo permite al mismo diseñador mantener la noción de los mismos datos.

Siguiendo el mismo ejemplo, tendríamos que el diccionario de datos para la entidad Clientes sería:

ID_Cliente: Identificador del cliente

Nombre: Nombre del cliente

Apellidos: Apellidos del cliente

Dirección: Dirección del cliente

Veamos ahora el caso de la entidad EPedido:

ID_Pedido: Identificador del pedido

ID_Cliente: Identificador del cliente que realiza el pedido

Fecha_Pedido: Fecha en que se levanta el pedido

Numero_Pedido: Número de control del pedido

ID_Cia_Envios: Identificador de la compañía de envíos a utilizar

Podemos observar en este último caso que la fecha del pedido se especifica si debe ser la fecha en que se levanta el pedido. Si bien los atributos son intuitivos, puede haber malentendidos en caso de no contar con el diccionario de datos, como el pensar que la fecha mencionada pueda ser la fecha en la que se envía el pedido.

4.3 Reducción a tablas

Cuando hemos terminado de normalizar, resulta bastante sencillo reducir nuestro modelo normalizado a tablas para nuestra base de datos.

El proceso de reducción a tablas tiene algunas reglas:

Entidades

Ø  Cada entidad genera una tabla en la que cada atributo (simple) ocupa una columna y el identificador será la llamada llave primaria de la tabla.

Ø  Una entidad débil genera una tabla en la que cada atributo (simple) ocupa una columna y la llave primaria será el identificador o clave de la entidad de la que dependen más los atributos.

Relaciones

Ø  Las relaciones 1:1 no generan tablas.

Ø  Las relaciones N:M generan tabla que incluye las claves de las entidades que se relacionan además de su propio identificador que será su llave primaria.

Observa el siguiente gráfico qure ilustra el proceso:

Notación para las llaves

Llave primaria (*) Es un atributo simple o compuesto que sirve para identificar un objeto de manera univoca, es decir, debe ser única

Llave foránea (**) Es aquel atributo que es llave primaria en una entidad y que se relaciona con una segunda entidad. En la segunda entidad se llama llave foránea

Llave secundaria (*) Es cualquier atributo que va a servir para realizar búsquedas dentro de una misma entidad

Llave compuesta (***) Atributos que sirven para identificación único esta llave es utilizada solamente en caso de que no exista un atributo que pueda identificar por si solo a un objeto de otro

Dando seguimiento al ejemplo, la definición de nuestra tabla de Clientes será la siguiente:

<><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><>

ID_Cliente	Nombre	Apellidos	Dirección
*	***	***	***

El campo ID_Cliente será la llave primaria, que será única e irrepetible para diferenciar los registros entre sí.

Para la entidad DPedido,  la tabla es:

<><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><>

ID_DPedido	ID_Pedido	ID_Producto	Cantidad_Pedidos	Costo_Pedido
*	**	**	***	***

La llave primaria será el campo ID_DPedido, y se incluyen además los campos ID_Pedido junto con ID_Producto, pues sin un pedido encabezado no puede haber detalles del pedido, al mismo tiempo que sin productos, no puede haber pedido detallado.

La tabla de la entidad EPedido sería:

<><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><> <><>

ID_Pedido	ID_Cliente	Fecha_Pedido	ID_Cia_Envios
*	**	***	**

Si bien no puede haber un pedido encabezado sin pedido detallado (que tiene la información de los productos), ya hemos relacionado ambas tablas mediante el campo ID_Pedido en la tabla DPedido, lo que cobra más sentido al imaginar cómo se llenan las tablas. Cuando un cliente haga un pedido, primero se registrará en el sistema la información de EPedido, y posteriormente se registrarán los valores en la tabla DPedido con la información de los productos seleccionados y el pedido maestro al que pertenecen, pudiendo llenar varios registros en DPedido con el mismo valor de ID_Pedido, es decir, el mismo pedido encabezado.

Tema 3: Modelado de Datos

 

 El modelado será entonces una abstracción de la realidad que la represente lo más lógica y fielmente posible, y esta realidad será representada por medio de datos, se trata de una descripción de algo conocido como contenedor de datos (algo en donde se guarda la información), así como de los métodos para almacenar y recuperar información de esos contenedores. Los modelos de datos son abstracciones que permiten la implementación de un sistema eficiente de base de datos; por lo general se refieren a algoritmos y conceptos matemáticos, además mediante dichos modelos reflejaremos la estructura de negocio de la organización por medio de datos y relaciones.

Modelo Entidad Relación

Constituye una de las formas de modelado de datos más utilizada en la actualidad y que representa una forma fácil y estandarizada de representar la realidad de la manera más fiel posible.

Este modelo está formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones gráficas y lingüísticas. Se encuentra en un nivel de abstracción superior al modelo relacional pero está basado en él.

Enidad: Cualquier tipo de objeto o concepto del mundo real (cosa, persona, concepto abstracto o suceso) distinguible de otros objetos sobre el que se recopila información, por ejemplo: autos, casas, empleados, clientes, empresas, oficios, diseños de productos, etc. Debemos elegir nombres que comuniquen, hasta donde sea posible, el significado de cada entidad. Normalmente se utilizan nombres en singular y no en plural.

Las entidades se representan gráficamente mediante rectángulos y su nombre aparece en el interior. Un nombre de entidad sólo puede aparecer una vez en el esquema conceptual.

Tipos de Entidades

a) Entidad fuerte.- Es una entidad que existe por sí misma y no depende de otras entidades y se representa mediante un rectángulo sencillo.

b) Entidad débil.- Es una entidad cuya existencia depende de la existencia de otra entidad, (Por ejemplo, FAMILIAR depende de EMPLEADO. La desaparición de un empleado de la base de datos hace que desaparezcan también todos los familiares del mismo). Se representa mediante un rectángulo doble.

Atributos

Representan las propiedades básicas que describen a cada entidad o relación. Gráficamente, se representan mediante elipses ligadas a las entidades o relaciones a las que pertenecen.

Los atributos clave (clave o llave primaria) deben aparecer destacados; por ejemplo, subrayando su nombre. 

Identificador

Un identificador de una entidad es un atributo o conjunto de atributos que determina de modo único cada ocurrencia de esa entidad. Un identificador de una entidad debe cumplir dos condiciones:

Ø  No pueden existir dos ocurrencias de la entidad con el mismo valor del identificador.

Ø  Si se omite cualquier atributo del identificador, la condición anterior deja de cumplirse.

Un identificador no es más que la clave o llave primaria del modelo relacional.

Toda entidad tiene al menos un identificador y puede tener varios identificadores alternativos. Las relaciones no tienen identificadores. Retomando el ejemplo de una persona, su atributo ID sería entonces el identificador.

Relación

Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene un nombre que describe su función. Las relaciones se representan gráficamente mediante rombos y su nombre aparece en el interior.

Una característica importante es que dicho nombre debe ser un verbo que describa tal relación, por ejemplo: vende, pertenece, etc.

Propuesta y convenciones alternativas de diseño de Bases de Datos

Por su simplicidad y fácil interpretación de requerimientos Se sugiere la siguiente notación para diseñar bases de datos.

Entidades

Las entidades se clasifican en:

Entidad	Descripción
Catálogo	En este tipo de entidad se agrupan los datos registrándolos y clasificándolos de acuerdo a la similitud de sus características para ser utilizados por otras entidades, por estas características poseen un menor factor de crecimiento de registros, además en el modelado siempre serán entidades fuertes. La identificaremos colocando una C al inicio de su nombre. Ejemplos de este tipo de entidad son: CPoblación, CPaís, CSexo, etc.
Maestra	En este tipo de entidad se registran los datos de acuerdo a la similitud de sus características, tiene una mayor probabilidad de crecimiento en los registros, y en el modelado se puede utilizar como entidad fuerte y/o débil dependiendo de las necesidades del negocio, la identificaremos colocando una letra M al inicio de su nombre. Por ejemplo: MPersona, MProfesor, MEmpleado, MProducto, etc.
Detalle	En esta entidad se descargan los datos de varias entidades, para relacionar la información de éstas y evitar la redundancia de datos en dichas entidades permitiendo la repetición de estos. Este tipo de entidad en el modelado siempre será débil.  La identificaremos colocando una D al inicio de su nombre. Ejemplos de este tipo de entidad son: DFactura, DNota, DReceta.
Encabezado	Esta entidad permite agrupar los datos de una entidad detalle bajo un mismo identificador. Se trata de una entidad fuerte cuando se relaciona con una entidad de detalle, y es una entidad débil cuando requiere datos de otra(s) entidades. La identificaremos colocando una E al inicio de su nombre. Ejemplos de este tipo de entidad son: EFactura, ENota, EReceta, etc.

Atributos

Se representan mediante óvalos ligados a la entidad o relación de la que forman parte.

Su formato mediante la norma ISO 10015 será:

3 caracteres para propiedad _ 3 caracteres para tabla _ dígito de ser necesario

XXX_XXX_99

Por ejemplo para nombrar las propiedades RFC y Nombre pertenecientes a la entidad MCliente, su formato sería: rfc_cli y nom_cli respectivamente.

Relaciones

Se representan mediante un rombo.y asocian al dominio y al codominio, escogiendo el atributo más particular e irrepetible que contiene la entidad. Por ejemplo si quisiéramos saber el país al que pertenece un cliente, debido a que la entidad MCliente almacena las características propias del cliente y la entidad CPais almacena los nombres de los países, es necesario hacer una relación entre dichas entidades a través de un atributo propio del dominio que identifique unívocamente a cada registro, el cual también será un atributo del codominio que tomará el papel de clave foránea.

Ahora, la elección del atributo identificador viene dada primeramente por la necesidad que requiere el codominio de su respectivo dominio por lo que el identificador debe ser tomado de ese último, en este caso de CPais. Ahora bien, en la definición de relación se hizo énfasis en que se escoge el atributo más particular que contiene la entidad dominio, entonces, para evitar inconsistencia y duplicidad de la información, dicho atributo puede ser el atributo clave de la entidad dominio, se saca este de dicha entidad y se indica en la relación.

 

Componentes de una base de datos

Cuando se desarrolla una Base de Datos en el nivel lógico o conceptual, esta se organiza de forma que los datos puedan ser manipulados fácilmente, por lo que se identifican los siguientes componentes.

Componente	Descripción
Datos	Pueden ser un número, una letra, un signo ortográfico o cualquier símbolo que represente una cantidad, una medida, una palabra o una descripción.
Campos	Se conoce también como Atributo o Campo Almacenado. Se refiere a un tipo o atributo de información. Es la unidad más pequeña que se encuentra almacenada en una BD. Este posee: nombre, tipo de campo y características propias.
Registros	Toda la información sobre un individuo, cosa u objeto. Es la unidad de almacenamiento de las tablas y estas pueden contener un gran número de registros, cada uno de los cuales consta de Campos.
Tablas o Archivos	Son las unidades básicas de almacenamiento que permiten a la computadora distinguir entre los diversos conjuntos de información, y que está identificado con un nombre Este almacena datos en Registros (Filas) y Campos (Columnas).