miércoles, 26 de septiembre de 2012

UNIDAD II

2.1 PROCESO DE DISEÑO DE UNA BD
Si usa un proceso de diseño de base de datos establecido, puede crear de forma rápida y efectiva una base de datos bien diseñada que le proporciona acceso conveniente a la información que desea. Con un diseño sólido tardará menos tiempo en construir la base de datos y obtendrá resultados más rápidos y precisos.
La clave para obtener un diseño de base de datos eficaz radica en comprender exactamente qué información se desea almacenar y la forma en que un sistema de administración de bases de datos relacionales, como Visual FoxPro, almacena los datos. Para ofrecer información de forma eficiente y precisa, Visual FoxPro debe tener almacenados los datos sobre distintos temas en tablas separadas. Por ejemplo, puede haber una tabla donde sólo se almacenen datos sobre empleados y otra tabla que sólo contenga datos de ventas.
Al organizar los datos de forma apropiada, proporciona flexibilidad a la base de datos y tiene la posibilidad de combinar y presentar información de muchas formas diferentes.
Al diseñar una base de datos, en primer lugar debe dividir la información que desea almacenar como temas distintos y después indicar a Visual FoxPro cómo se relacionan estos temas para que pueda recuperar la información correcta cuando sea necesario. Si mantiene la información en tablas separadas facilitará la organización y el mantenimiento de los datos y conseguirá aplicaciones de alto rendimiento.
A continuación se indican los pasos que hay que seguir en el proceso de diseño de una base de datos. Cada paso se trata con mayor detalle en los temas restantes de esta sección.
  1. Determinar el propósito de la base de datos   Este paso le ayudará a decidir los datos que desea que Visual FoxPro almacene.
  2. Determinar las tablas necesarias   Cuando ya conozca claramente el propósito de la base de datos, puede dividir la información en temas distintos, como "Employees" u "Orders". Cada tema será una tabla de la base de datos.
  3. Determinar los campos necesarios   Tiene que decidir la información que desea incluir en cada tabla. Cada categoría de información de una tabla se denomina campo y se muestra en forma de columna al examinar la tabla. Por ejemplo, un campo de la tabla Employee podría ser Last_name y otro podría ser Hire_date.
  4. Determinar las relaciones   Observe cada tabla y decida cómo se relacionan sus datos con los de las tablas restantes. Agregue campos a las tablas o cree tablas nuevas para clarificar las relaciones, si es necesario.
  5. Perfeccionar el diseño   Busque errores en el diseño. Cree las tablas y agregue algunos registros de datos de ejemplo. Vea si puede obtener los resultados que desea de sus tablas. Haga los ajustes necesarios al diseño.


2.2 MODELO ENTIDAD RELACION
Cuando se utiliza una base de datos para gestionar información, se está plasmando una parte del mundo real en una serie de tablas, registros y campos ubicados en un ordenador; creándose un modelo parcial de la realidad. Antes de crear físicamente estas tablas en el ordenador se debe realizar un modelo de datos.
       Se suele cometer el error de ir creando nuevas tablas a medida que se van necesitando, haciendo así el modelo de datos y la construcción física de las tablas simultáneamente. El resultado de esto acaba siendo un sistema de información parcheado, con datos dispersos que terminan por no cumplir adecuadamente los requisitos necesarios.
Entidades y Relaciones
       El modelo de datos más extendido es el denominado ENTIDAD/RELACIÓN (E/R) En el modelo E/R se parte de una situación real a partir de la cual se definen entidades y relaciones entre dichas entidades:
  • Entidad.- Objeto del mundo real sobre el que queremos almacenar información (Ej: una persona). Las entidades están compuestas de atributos que son los datos que definen el objeto (para la entidad persona serían DNI, nombre, apellidos, dirección,...). De entre los atributos habrá uno o un conjunto de ellos que no se repite; a este atributo o conjunto de atributos se le llama clave de la entidad, (para la entidad persona una clave seria DNI). En toda entidad siempre hay al menos una clave que en el peor de los casos estará formada por todos los atributos de la tabla. Ya que pueden haber varias claves y necesitamos elegir una, lo haremos atendiendo a estas normas:
    • Que sea única.
    • Que se tenga pleno conocimiento de ella.- ¿Por qué en las empresas se asigna a cada cliente un número de cliente?.
    • Que sea mínima, ya que será muy utilizada por el gestor de base de datos.
  • Relación.- Asociación entre entidades, sin existencia propia en el mundo real que estamos modelando, pero necesaria para reflejar las interacciones existentes entre entidades. Las relaciones pueden ser de tres tipos:
    • Relaciones 1-1.- Las entidades que intervienen en la relación se asocian una a una (Ej: la entidad HOMBRE, la entidad MUJER y entre ellos la relación MATRIMONIO).
    • Relaciones 1-n.- Una ocurrencia de una entidad está asociada con muchas (n) de otra (Ej: la entidad EMPERSA, la entidad TRABAJADOR y entre ellos la relación TRABAJAR-EN).
    • Relaciones n-n.-Cada ocurrencia, en cualquiera de las dos entidades de la relación, puede estar asociada con muchas (n) de la otra y viceversa (Ej: la entidad ALUMNO, la entidad EMPRESA y entre ellos la relación MATRÍCULA).
Representación gráfica de Entidades y Relaciones
       Para asimilar fácilmente un diseño de datos cuando se emplea el modelo E/R se utilizan los siguientes elementos gráficos:
       La utilización de estos elementos dará como resultado lo que se denomina el esquema entidad-relación de la base de datos. Los ejemplos que se incluyen en el apartado anterior, gráficamente quedarían como sigue:


2.3 RESTRICCIONES
Es una notación alternativa a las restricciones de llave (cardinalidad) que incluye un par de números enteros (mín, máx) a cada participación.
La existencia de una entidad depende de que esté relacionado con otra entidad a través de un tipo de vínculo.

2.6 CONJUNTO DE ENTIDADES DEBILES
Un conjunto de entidades débiles es aquel que no tiene suficientes atributos para formar una clave primaria. Un conjunto que sí tiene una clave primaria se denomina conjunto de entidades fuertes.
Cada conjunto de entidades débiles debe estar asociada con un conjunto de entidades llamado conjunto de entidades identificadoras o propietarias. Así, el conjunto de entidades débiles depende existencialmente del conjunto de entidades identificadoras. La relación que asocia el conjunto de entidades débiles con el conjunto de entidades identificadoras se denomina relación identificadora. La relación identificadora es varios a uno del conjunto de entidades débiles al conjunto de entidades identificadoras y la participación del conjunto de entidades débiles en la relación es total.
Aunque un conjunto de entidades débiles no tiene clave primaria, deben hacerse distinguir todas aquellas entidades del conjunto de entidades que dependen de una entidad fuerte particular. El discriminante de un conjunto de entidades débiles es un conjunto de atributos que permiten esta distinción.
La clave primaria de un conjunto de entidades débiles se forma con la clave primaria del conjunto de entidades identificadoras, más el discriminante del conjunto de entidades débiles.


No hay comentarios:

Publicar un comentario