El primer paso para la construcción del modelo entidad-relación es la obtención y el análisis de los requerimientos de los usuarios. Esta tarea es parte de los diseñadores de la base de datos relacional.
Luego, a partir de los requisitos, se crea un esquema conceptual de la base de datos. El esquema conceptual contiene las descripciones detalladas de las entidades, relaciones y restricciones. Todas estas descripciones se expresan empleando conceptos gráficos y textuales del modelo de datos relacional.
El siguiente paso es implementar la base de datos empleando algún SGBD (software de gestión de bases de datos) adaptado al modelo entidad-relación.
Un diagrama o modelo entidad-relación (a veces denominado por sus siglas en inglés, E-R "Entity relationship", o del español DER "Diagrama de Entidad Relación") es una herramienta para el modelado de datos que permite representar las entidades relevantes de un sistema de información así como sus interrelaciones y propiedades.
- Se elabora el diagrama (o diagramas) entidad-relación.
- Se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama.
El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas para lograr un modelo directamente implementa ble en una base de datos. Breve mente:
permite mostrar resultados entre otras entidades pertenecientes a las existentes de manera que se encuentre la normalidad de archivos que se almacenarán
- Transformación de relaciones múltiples en binarias.
- Normalización de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa).
- Conversión en tablas (en caso de utilizar una base de datos relacional).
3 FORMAS DE NORMALIZAR UNA BASE DE DATOS
La Primera Forma Normal Esta primera Forma Normal, nos lleva a no repetir datos en nuestras tablas. Los famosos maestro – detalle, deben aplicarse a la estructura de la tabla.Si nuestra tabla de ventas repite una y otra vez (por cada venta) , el nombre, el domicilio y otros datos del Cliente, es que no hemos aplicado esta NormalizanSi tenemos una tabla clientes, en la tabla ventas, solo debería figurar el código del cliente, para que el resto de los datos se puedan referencia automáticamente sin problemas y sin duplicar información.Lo mismo ocurriría en una tabla de detalle de ventas, si por cada ítem vendido colocamos el detalle del producto, con su descripción , medidas, et…Tendríamos un desaprovechamiento de espacio y recursos muy grande. Para ello, tendremos nuestra tabla maestra de Productos y con solo grabar el código de dicho producto en nuestra tabla de ventas, será suficiente.
La Segunda Forma Normal (Si o si debe estar previamente aplicada la Primera Forma Normal) La Segunda Forma Normal nos habla de que cada columna de la tabla debe depender de la clave.Esto significa que todo un registro debe depender únicamente de la clave principal, si tuvieramos alguna columna que se repite a lo largo de todos los registros, dichos datos deberian atomizarse en una nueva tabla.Veamos un ejemplo
| VentaID | ItemID | FechaVenta | ClienteVenta | ProductoId | Cantidad |
| 1 | 1 | 01/12/2007 | 2 | 2334 | 10 |
| 1 | 2 | 01/12/2007 | 2 | 3333 | 2 |
| 1 | 3 | 01/12/2007 | 2 | 66643 | 34 |
| 1 | 4 | 01/12/2007 | 2 | 21 | 3 |
| 2 | 1 | 02/12/2007 | 5 | 3566 | 6 |
Ahi tenemos un claro problema !!!Acaso no se busca NO REPETIR DATOS ?Si toda una venta tendrá el mismo numero de Cliente y la misma Fecha…Por que no crear una Tabla de MAESTRO DE VENTAS y que contenga esos 2 datos ?Es evidente que la columna ClienteVenta y FechaVenta se repetirán por cada venta realizada.Es por ello que proponemos el siguiente esquema
| VentaID | ItemID | ProductoId | Cantidad |
| 1 | 1 | 2334 | 10 |
| 1 | 2 | 3333 | 2 |
| 1 | 3 | 66643 | 34 |
| 1 | 4 | 21 | 3 |
| 2 | 1 | 3566 | 6 |
Y ahora nuestra nueva tabla maestra
| VentaId | FechaVenta | ClienteVenta |
| 1 | 01/12/2007 | 2 |
| 2 | 02/12/2007 | 5 |
Entonces, nuestra 2da Forma Normal nos habla de que cada columna de una tabla debe depender de toda la clave y no constituir un dato unico para cada grupo de registros.
La Tercera Forma Normal En realidad si nos guiamos en el ejemplo de esta nota, ya no quedaría nacionalización por aplicar y podríamos decir que nuestro ejemplo cumple con las 3 formas normales, ya que la 3ra Forma Normal nos habla de que :
- Ninguna Columna puede depender de una columna que no tenga una clave
- No puede haber datos derivados
En el 2do ejemplo hemos descubierto campos que dependían de la clave principal (VentaID) y que podrían incluirse en una tabla maestra.Pero supongamos un ejemplo donde ciertas columnas no dependen de la clave principal y si dependen de una columna de nuestra tabla.
| VentaID | ItemID | ProductoID | Cantidad | Descripcion | Medida | Proveedor |
| 1 | 1 | 3455 | 12 | Impresora HP LJ8000 | 122cm | 1 |
| 1 | 2 | 2455 | 34 | Scanner HP A3555 | 33cm | 1 |
| 2 | 1 | 5444 | 21 | Mouse HP Wireless | – | 1 |
Esto es muy normal encontrar en bases mal normalizadas.Vemos que los campos DESCRIPCION , MEDIDA y PROVEEDOR no dependen de VENTAID y es por ello que no deberian estar dentro de la tabla de detalle de ventas, ya que dependen de PRODUCTOID.Aqui no se trata ya de eliminar grupos repedidos de datos (1ra Forma Normal) sino que ante la inclusion de una clave perteneciente a otra tabla, cualquier campo que sea subordinado de dicha clave debe estar en otra tabla y no en nuestra tabla detalle.
MI OPINIÓN QUE ES LA NORMALIZACION DE UNA BASE DE DATOS
Supongo que es un proceso que consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional. Las bases de datos relacionales se normalizan para: Evitar la redundancia de
los datos.
¿esquematiza los símbolos utilizado en el modelo identidad relación?
Antes de que mire símbolos específicos, es importante entender los varios niveles de los DER ("ERD" en inglés). Hay varias formas de modelar diagramas de entidad relación. El tipo de más alto nivel es un modelo de datos conceptual; el siguiente mayor es el modelo de datos lógicos; y el tipo de nivel más bajo (y por lo tanto el más detallado) es el modelo de datos físicos. Consulte el gráfico inferior para ver qué elementos están cubiertos en cada modelo de datos.
Símbolos físicos DER
Los símbolos de la parte inferior se utilizan en el nivel más granular de DER: modelos de datos físicos, aunque algunos elementos también se utilizan para modelos de datos lógicos.
- Las tablas son otra forma de representar entidades
- Los campos representan atributos de la entidad
- Las claves son una forma de categorizar atributos. Una clave primaria es un atributo o combinación de atributos que identifican únicamente una y solo una instancia de una entidad. La clave primaria se convierte en una clave foránea en cualquier tipo de entidad con la que está relacionada a través de una relación de uno a uno o de uno a muchos
- Los tipos pueden referirse a los tipos de datos asociados con el campo correspondiente en una tabla. Los tipos también puede referirse a los tipos de entidades, los cuales describen la estructura de una entidad; por ejemplo, los tipos de entidad de un libro son autor, título y fecha de publicación.
En este apartado mostraremos la implementación que bajo el modelo relacional de datos hemos llevado a cabo para nuestro lexicón multilingüe, mostrando los diagramas conceptuales y explicando las circunstancias que nos han llevado a adoptar determinadas decisiones. Pasaremos por alto la descripción detallada de la base de datos (tipos de datos, restricciones, código SQL de consultas, etc.). Lo realmente interesante de una base de datos y lo que determina en gran medida su funcionalidad es su esquema conceptual.
El modelado que vamos a mostrar aquí es el resultado de la experimentación con otros posibles esquemas que, por una razón un otra, fueron descartados en su momento. De todos los diseños probados, el que ahora presentamos es sin duda el más compacto y el que mejor se adapta al tipo de aplicación que le queremos dar, manteniendo al mismo tiempo una gran independencia de los datos y de la teoría gramatical. Respecto a esta característica, hemos de reconocer que la influencia del modelo para el que la base de datos se diseñó en principio, en 1992, bajo la dirección del profesor Martín Mingorance, es aún patente. Lo que hemos pretendido es aprovechar los grandes beneficios que de esta circunstancia se derivan al mismo tiempo que hemos construido sobre ello.
ESQUEMA LÓGICO
El esquema lógico de una base de datos, es el resultado del diseño logico de bases de datos. El diseño lógico, es parte del proceso de diseño de bases de datos, junto con el diseño conceptual de bases de datos y el diseño físico de bases de datos.Un esquema lógico de una base de datos, es una descripción de la estructura de la base de datos que puede procesar un SGBD. El esquema lógico de base de datos depende de un tipo de SGBD (relacional, de redes, jerárquico...), pero no de un SGBD específico.
ESQUEMA FÍSICO
Resultado del proceso de diseño físico de una base de datos. El esquema físico de una base de datos, depende del tipo de SGBD y de un SGBD específico. El esquema físico de una base de datos es una descripción de la implementación de una base de datos en memoria secundaria, describiendo las estructuras de almacenamiento y los métodos de acceso a esos datos.
MODELO DE ENTIDAD Y RELACIÓN EJEMPLO
No hay comentarios:
Publicar un comentario