Para crear un entorno de base de datos se deben tener las relaciones que hay entre los datos, el tipo de datos que se almacenara en la base de datos, como se utilizara los datos y de que manera necesitara cambiar la organización para administrar los datos en una prospectiva total de la compañía. Cada vez el diseño de base de datos también tendrá que considerar la manera de a organización pueda compartir alguno de los datos con sus socios d negocios (Jukic, Jukic y Paramenswaram, 2002). A continuación se describen principios importantes del diseño de base de datos y de los requerimientos administrativos y organizacionales de un entorno de base de datos.
Diseño de Bases de Datos
Para crear una base de datos se deben llevar a cabo dos ejercicios: un diseño conceptual y un diseño físico. El diseño conceptual, o lógico de una base de datos es un modelo abstracto de la base de datos sobre dispositivos de almacenamiento de acceso directo. El diseño lógico requiere una descripción detallada de las necesidades de la información de los usuarios finales reales de la base de datos de la empresa. Idealmente, el diseño de la base de datos será parte de un esfuerzo de planeación de datos a todo lo largo de la organización (véase el capitulo 12).
El diseño conceptual de la base de datos describe como se deben agrupar los elementos de datos en la base de datos. El proceso de diseño identifica las relaciones entre los elementos de datos y la manera mas eficientes de agrupar lo elementos de datos entre si para cumplir con los requerimientos de la información. El proceso también identifica los elementos de datos redundantes y de agrupaciones de los elementos requeridos para programas específicos de las aplicaciones. Los grupos de datos se organizan, refinan y dinamizan hasta que surja una vista general lógica de las relaciones entre todos los elementos de datos sobre la base de datos.
Los diseñadores de bases de datos de los documentos el modelo conceptual de datos con diagrama de relaciones de las entidades, que se ilustra en la fig. 7-13. Los representan las entidades y los rombos las relaciones. El 1 o la M a los lados de los rombos representan las relaciones entre las entidades ya sean de uno a uno, de uno a muchos o de muchos a muchos. La fig. 7-13 muestra la entidad PEDIDO puede tener mas de una PARTE y una parte solo puede tener PROVEEDOR. Uno mismo proveedor puede proporcionar varias partes. Los atributos de cada entidad se en listan junto a la entidad y el campo clave subrayado.
Para utilizar con eficiencia un modelo de base datos racional, se debe agilizar las agrupaciones complejas de datos para eliminar lo modelos de datos redundantes y las relaciones mucho a muchos inadecuadas. Al proceso de crear estructuras de datos pequeñas y estables a partir de grupos complejos de datos pequeños se llama normalización. La fig. 7-14 y 7-15 ilustran este proceso. El negocio especifico que se modela aquí, un pedido puede tener más de una parte, pero solamente puede ser surtido por un proveedor si construyéramos una relación llamada PEDIDO con otros campos incluidos aquí tendríamos que repetir el nombre, la descripción de cada proveedor. Esta relación tiene lo que se llama grupos repetitivos por que cada pedido puede haber muchas partes y proveedores y eso describe realmente muchas entidades: tanto partes y proveedores como pedidos. Una manera más eficiente de ordenar los datos es dividir el pedido en relaciones más pequeñas, cada una de las cuales recibe una identidad única. Si se va de etapa en etapa y se normaliza la relación pedido el resultado son las relaciones que se ilustran en la figura 7-15.
Se ha considerado cuidadosamente una base de datos, con una clara compensación de las necesidades y uso de l información de la empresa, muy probablemente el modelo de base de datos resultara en un formato normalizado. Muchas bases de datos en el mundo real no están totalmente normalizadas por que es posible que esta no se a la mejor manera de satisfacer los requerimientos de información de la empresa. Observe que la base de datos nacional y ilustrada en la fig. 7-6 no esta totalmente normalizada porque podía haber un parte mas de cada pedido. Los diseñadores prefieren no utilizar las 4 relaciones descritas en la fig. 7-15 por que la mayoría de lao pedidos manejados por esta empresa en realidad consta de una parte. Es posible que los diseñadores hayan sentido que para esta empresa en particular no era suficiente mantener cuatro tablas diferentes.
0 comentarios:
Publicar un comentario