Posteado por: mafer1988 | octubre 5, 2007

QBE

QBE

Query-by-Example (QBE, Consulta mediante ejemplos) se refiere a una familia de lenguajes que implementan las ideas del cálculo relacional de dominios, un lenguaje formal desarrollado para las bases de datos relacionales. Es el nombre tanto de un lenguaje de manipulación de datos como el de un sistema de base de datos que incluyó a este lenguaje. El sistema QBE se desarrolló en el Centro de desarrollo T.J. Watson, de IBM, a principios de los años setenta y el lenguaje de manipulación de datos QBE se usó más tarde en QMF (Query Management Facility, mecanismo de gestión de consultas) como opción de interfaz para DB2. Hay varias implementaciones de este lenguaje, entre las que se incluyen el original de IBM (Sistema QBE), QBE de Microsoft (en Access) y QBE de DB2. Aunque este lenguaje fue originalmente textual, las últimas implementaciones, como la de Access, ofrecen una interfaz gráfica para la expresión de consultas.

Las consultas en QBE se expresa utilizando esqueletos de tablas. Estos presentan el esquema de la relación. En lugar de llenar la pantalla con esqueletos de tablas, el usuario elige los esqueletos que necesita para una determinada consulta y rellena dichos esqueletos con filas ejemplo. Una fila ejemplo está formada por constantes y elementos ejemplo, las mismas que son variables de dominio. Para evitar confusiones, en QBE las variables de dominio van precedidas por un carácter de subrayado ( _ ) como en _x, y las constantes que aparecen sin ninguna indicación particular. Este es estándar con la mayoría de los lenguajes, en los que las constantes se encierran entre comillas y las variables aparecen sin ninguna indicación.

Posee dos características distintivas:

1.       A diferencia de muchos lenguajes de consulta y de programación, QBE presenta una sintaxis bidimensional. Las consultas parecen tablas. Una consulta en el lenguaje unidimensional (como SQL) se puede formular en una línea (posiblemente larga). Un lenguaje bidimensional necesita dos dimensiones para la formulación de consultas. Cabe recalcar que existe una versión unidimensional de QBE.

2.       Las consultas en QBE se expresan << mediante un ejemplo>>. En lugar de incluir un procedimiento para obtener la respuesta deseada, se usa un ejemplo de qué es lo deseado. El sistema generaliza este ejemplo para obtener la respuesta a la consulta.

Tipos de Consultas QBE

Existen varios tipos de consultas QBE:

*      Consulta de Selección: Seleccionan registros de una o varias tablas.

*      Consultas de Acción: Modifican datos de una tabla (reemplazan datos, eliminan registros o añaden registros).

*      Consultas de tabla de referencias cruzadas: Calculan totales para filas y columnas.

*      Consultas perimétricas: Aceptan valores proporcionados por el usuario para personalizar la consulta.

 

Ejemplo de consultas QBE en Microsoft Access 2003

En este ejemplo presentara un caso practico de un sistema medico y puntualizara los tipos de consultas QBE.

 

Ø  Consulta de selección:

Las consultas más sencillas, las consultas de selección, permiten extraer datos de la base de datos con el criterio que imponga el usuario. En su versión más simple, una consulta de selección mostraría todos los campos de todas las filas de una tabla. Se puede elegir tanto los campos a mostrar como las filas que cumplan una determinada condición.

 

1.       Listado de médicos por especialidad:

 

En esta consulta estamos interesados en obtener los médicos ordenados por especialidad y por apellidos, incluyendo los campos de la tabla Médicos: Especialidad, Apellidos, Nombre, Número de colegiado y Cargo.

 

 

 

 

2.       Listado de pacientes por diagnóstico

Proporciona un listado de pacientes ordenado por diagnóstico y por los apellidos del paciente. Para crear la consulta Listado de pacientes por diagnóstico hay que agregar las tablas Pacientes e Ingresos. Se añadirá a la cuadrícula QBE los siguientes campos de las siguientes tablas:

 

Campo

Tabla

 

                                              

 

 

Ø  Consulta de tablas de referencia cruzada.

 

Este tipo de consultas permite generar columnas que no existen en una determinada tabla a partir de los datos que aparecen en las filas. Son útiles cuando, por ejemplo, deseamos generar columnas con fechas o intervalos de tiempo (como un año) que contengan totales (como total de gastos). Estas consultas son difíciles de expresar en el lenguaje SQL estándar (que se verá en el siguiente tema), pero Access contiene una instrucción especial para ellas

 

1.       Gasto trimestral por planta:

Debe proporcionar el gasto total de cada una de las plantas en el año agrupado por trimestre.

 

2.       Resumen anual de gastos de la planta:

Esta consulta mostrará para cada planta el gasto realizado durante el año.

Y el resultado debe ser:

 

Ø  Consulta de parámetros.

1.       Ingreso de pacientes entre dos fechas:

Y el resultado debe ser:

2.       Ingreso de pacientes por diagnostico:

Esta consulta debe presentar el nombre, apellidos y fecha de ingreso de todos los pacientes para un diagnóstico determinado que será introducido en la consulta como parámetro.

El resultado del diagnostico por concepto de neumonía debe ser:

3.       Historial del paciente:

Esta consulta debe solicitar los apellidos del paciente y mostrar la fecha de ingreso, el diagnóstico, la edad del paciente y los apellidos del médico que atendió al paciente.

La edad puede calcularse con la expresión: Edad: Ent(([Fecha de ingreso]-[Fecha de nacimiento])/365).

 

                               El resultado para el paciente Pérez Gómez será:

 

Como habíamos señalado anteriormente los SGBDR (Sistemas de vades de datos relacionales) se han convertido en el software dominante para procesamiento y administración de datos hoy en día. Considerando lo mencionado anteriormente estudiaremos dos de los mejores SGBDR como lo son: Office Access y Oracle

Microsoft Office Access 2003

Microsoft Office Access es el SGBD relacional mas ampliamente utilizado por los entornos Microsoft Windows. Este proporciona una interfaz gráfica de usuario para la creación de tablas, consultas, formularios o informes, así como herramientas para desarrollar aplicaciones personalizadas de bases de datos utilizando el lenguaje de macros de Microsoft Office Access.

Arquitectura de Microsoft Office Access.

Puede utilizarse como un sistema autónomo en un solo equipo o como un sistema multiusuario en una red de computadoras personales, Access al igual que SQL Server, divide los datos almacenados en sus estructuras de tablas de páginas de datos de 2 kilobytes.

Para el soporte multiusuario, Access proporciona cuatro formas principales de trabajas con una base d datos compartida por varios usuarios en la red:

·         Soluciones basadas en servidor de archivos.

Se sitúa una base de datos Access en una red de modo que múltiples usuarios puedan compartirla.

 

·         Soluciones cliente – servidor.

En las primeras versiones de Office Access la única forma de conseguir este tipo de arquitectura era crear tablas enlazadas que utilizaran un controlador ODBC. Desde Access 2000, también puede crearse un archivo Access que pueda almacenar formularios, informes, macros y módulos VBA localmente y puede conectarse a una base de datos SQL Server remota utilizando OLE DB.

 

·         Soluciones de base de datos basadas en la web.

Un explorador muestra una o mas página de acceso a datos compartida, estas paginas deben ser visualizadas mediante un navegador de internet.

 

·         Soluciones de bases de replicación de bases de datos.

Permiten compartir las modificaciones de los datos en diferentes ubicaciones, sin necesidad de redistribuir copias de las base de datos completa.

Tablas.

                Access ofrece cinco formas de crear una tabla en blanco:

·         Utilizando un asistente de bases de datos.

·         Utilizando un asistente de tablas

·         Introduciendo directamente los datos a una tabla en blanco.

·         Utilizar la instrucción CREATE TABLE en la vista SQL.

Formularios.

Permiten al usuario visualizar y editar los datos almacenados en las tablas base subyacentes, presentando los datos en una forma organizada y personalizada. Los formularios se construyen como una colección de elementos de diseño individuales denominados controles u objetos de control.

Los formularios están divididos en una serie de secciones, siendo las tres principales las siguientes:

·         Cabecera del formulario. Determina lo que se visualizara en la parte de cada formulario, como por ejemplo un titulo.

·         Detalle. Esta sección muestra usualmente una serie de campos de un registro.

·         Pie del formulario. Determina lo que se mostrara en la parte inferior de cada formulario, como por ejemplo un total.

Los formularios pueden contener otros formularios, en cuyo caso estos últimos se denominan subformularios.

Informes.

Los informes son un tipo especial de formularios continuo diseñado especialmente para impresión., en lugar de para su visualización en una ventana. Entre otras cosas los usuarios de Office Access permiten al usuario ordenar registros, agrupar registros, calcular informes de resumen, controlar la disposición y apariencia global del informe.

La vista de diseño para los informes esta dividida en una serie de secciones, las principales son:

·         Cabecera del informe.

·         Cabecera de página.

·         Detalle.

·         Pie de página

·         Pie de informe.

·         Cabecera de grupo.

·         Pie de grupo.

Macros.

Office Access utiliza un paradigma de programación conducida por sucesos. Este es capaz de reconocer ciertos sucesos como por ejemplo:

·         Sucesos de ratón. Tienen lugar cada vez que se produce una acción con el ratón, como presionar o hacer clic sobre un botón del ratón.

·         Suceso de teclado. Tienen lugar cuando el usuario escribe en el teclado.

·         Sucesos de foco. Tienen lugar cuando un formulario o control de formularios gana o pierde el foco.

·         Sucesos de datos. Tienen lugar cuando se introduce, borrar o modificar datos en un formulario o control.

 

Oracle 9i

Oracle corporación es un fabricante líder de software para gestión de información y la segunda mayor empresa de software independiente en el mundo.

El usuario interactúa con Oracle y desarrolla una base de datos utilizando una serie de objetos. Los principales objetos de Oracle son las tablas.

Arquitectura de Oracle

Oracle esta basado en una arquitectura cliente-servidor, el servidor de Oracle esta compuesto de la base de datos y la instancia. Cada instancia solo puede conectarse a una base de datos. La base de datos esta compuesta de una estructura lógica como puede ser el esquema de la base de datos, y de una estructura física que contiene los archivos que forman una base de datos Oracle.

·         Estructura lógica de la base de datos Oracle.

En el nivel lógico Oracle mantiene espacios de tablas, esquema y bloques de datos y extensiones.

Un espacio de tablas se utiliza para agrupar estructuras lógicas relacionadas. Por ejemplo, normalmente se emplean espacios de tablas para agrupar todos los objetos de aplicación, con el fin de simplificar algunas operaciones administrativas.

Un usuario es un nombre definido en la base de datos que puede conectarse a los objetos de la misma y acceder a ellos.

Un esquema es una colección nominada de objetos de esquema como tablas, vistas, índices, clústeres y procedimientos, los cuales están asociados con un usuario concreto.

El bloque de datos es la unidad de almacenamiento mas pequeña que Oracle puede utilizar o asignar, el tamaño de bloque de datos puede configurarse para cada base de datos Oracle.

 

·         Estructura física de la base de datos Oracle.

Las principales estructuras físicas de la base de datos Oracle son los archivos de datos, los archivos de registro de rehacer y los archivos de control.

Cada una de las bases de datos Oracle tiene uno o más archivos de datos físicos. Los datos de las estructuras lógicas de cada base de datos se almacenan físicamente en estos archivos.

Cualquier base de datos Oracle tiene un conjunto de dos o más archivos del registro de rehacer que registran todos los cambies realizados en los datos.

También las bases de datos Oracle poseen un archivo de control que contiene una lista de todos los demás archivos que forman la base de datos.

Tablas.

Oracle 9i soporta muchas de las clausulas CREATE TABLE del estándar SQL, de modo que podemos definir:

·         Claves principales, utilizando la clausula PRIMARY KEY.

·         Claves alternativas, utilizando la palabra clave UNIQUE.

·         Valores predeterminados, utilizando la clausula DEFAULT.

·         Atributos no nulos, utilizando la palabra clave NOT NULL.

·         Claves externas, utilizando la clausula FOREIGN KEY

·         Otras relaciones relativas a los atributos o a la tabla, usando las clausulas CHECK y CONSTRAINT.

Para la creación de tablas podemos realizarlo mediante:

·         SQL*Plus. Es una interfaz SQL interactiva controlada mediante línea de comandos que permite acceder a la base de datos Oracle.

·         Utilizando el Asistente de creación de tablas. Forma parte del sector de esquemas. Utilizando una serie de formularios interactivos, este lleva al usuario a través del proceso de formación de cada una de las columnas con su tipo de datos asociado, así como la definición de cualquier restricción aplicada a la columna.

PL/SQL.

Es una extensión SQL diseñada por Oracle, esta se basa en conceptos generales a los de los lenguajes de programación modernos, como por ejemplo los conceptos de declaración de variables y constantes, estructuras de control, tratamiento de extensiones y modularidad. PL/SQL trabaja con bloques el cual se compone de hasta tres partes:

·         Una parte opcional de declaración en la que se pueden definir y posiblemente inicializar las variables, constantes, cursores y extensiones.

·         Una parte ejecutable obligatoria, en la que se manipulan las variables.

·         Una parte opcional de tratamiento de excepciones, para gestionar cualesquier excepción que se produzca durante la ejecución.

 

Subprogramas, procedimientos almacenados, funciones y paquetes.

Los subprogramas son paquetes PL/SQL nominados que pueden tomar parámetros y ser invocados a voluntad del programador.PL/SQL tiene dos tipos de subprogramas, denominados funciones y procedimientos almacenados.

Los procedimientos y funciones proporcionan modularidad y extensibilidad, promueven la reusabilidad y la mantenibilidad y ayudan en el proceso de abstracción de los datos.

Un paquete es una colección de procedimientos, funciones, variables e instrucciones SQL que se agrupan y almacenan como una única unidad de programa. Un paquete posee dos partes, La especificación que declara todas las estructuras únicas del paquete, y, el cuerpo que define todas las estructuras del paquete.

Disparadores.

Define la acción que la base de datos debe llevar a cabo cuando tenga lugar un determinado suceso en la aplicación. Pueden utilizarse para poner ciertas restricciones de integridad referencial, para poner restricciones empresariales complejas o para auditar los cambios realizados en los datos.

Para la planificación, diseño y administración de bases de datos se debe tener en cuenta algunos puntos y preliminares como lo es el ciclo de vida de los sistemas informáticos  para luego poder comprender el ciclo de vida de un sistema de bases de datos que es en si de lo que trata este capítulo.

 

1.      Ciclo de vida de un sistema de información.

Un sistema de información es el conjunto de recursos que permiten recoger, gestionar, controlar y difundir la información de toda una empresa u organización.

Un sistema de información está formado por los siguientes componentes:

·         La base de datos.

·         El SGBD.

·         Los programas de aplicación.

·         Los dispositivos físicos (ordenadores, dispositivos de almacenamiento, etc.).

·         El personal que utiliza y que desarrolla el sistema.

La base de datos es un componente fundamental de un sistema de información. El ciclo de vida de un sistema de información está ligado al ciclo de vida del sistema de base de datos sobre el que se apoya. Al ciclo de vida de los sistemas de información también se le denomina ciclo de vida de desarrollo del software. Las etapas típicas del ciclo de vida de desarrollo del software son: planificación, recolección y análisis de los requisitos, diseño (incluyendo el diseño de la base de datos), creación de prototipos, implementación, prueba, conversión y mantenimiento. Este ciclo de vida hace énfasis en la identificación de las funciones que realiza la empresa y en el desarrollo de las aplicaciones que lleven a cabo estas funciones. Se dice que el ciclo de vida de desarrollo del software sigue un enfoque orientado a funciones, ya que los sistemas se ven desde el punto de vista de las funciones que llevan a cabo.

 

2.      Ciclo de vida de un sistema de bases de datos.

Las etapas de ciclo de vida de las aplicaciones de bases de datos no son estrictamente secuenciales. De hecho hay que repetir algunas de las etapas varias veces, haciendo lo que se conocen como ciclos de realimentación. Por ejemplo, los problemas que se encuentran en la etapa del diseño de la base de datos pueden requerir una recolección de requisitos adicional y su posterior análisis.A continuación de describen todas estas etapas y se muestran las tareas más importantes que se realizan en cada una de ellas.

1.       Planificación del proyecto

Esta etapa conlleva la planificación de cómo se pueden llevar a cabo las etapas del ciclo de vida de la manera más eficiente. Hay tres componentes principales: el trabajo que se ha de realizar, los recursos para llevarlo a cabo y el dinero para pagar por todo ello. Como apoyo a esta etapa, se necesitará un modelo de datos corporativo en donde se muestren las entidades principales de la empresa y sus relaciones, y en donde se identifiquen las principales áreas funcionales. Normalmente, este modelo de datos se representa mediante un diagrama entidad-relación. En este modelo se tiene que mostrar también qué datos comparten las distintas áreas funcionales de la empresa.

La planificación de la base de datos también incluye el desarrollo de estándares que especifiquen cómo realizar la recolección de datos, cómo especificar su formato, qué documentación será necesaria y cómo se va a llevar a cabo el diseño y la implementación. El desarrollo y el mantenimiento de los estándares puede llevar bastante tiempo, pero si están bien diseñados, son una base para el personal informático en formación y para medir la calidad, además, garantizan que el trabajo se ajusta a unos patrones, independientemente de las habilidades y la experiencia del diseñador. Por ejemplo, se pueden establecer reglas sobre cómo dar nombres a los datos, lo que evitará redundancias e inconsistencias. Se deben documentar todos los aspectos legales sobre los datos y los establecidos por la empresa como, por ejemplo, qué datos deben tratarse de modo confidencial.

2.       Definición del sistema

En esta etapa se especifica el ámbito y los límites de la aplicación de bases de datos, así como con qué otros sistemas interactúan. También hay que determinar quienes son los usuarios y las áreas de aplicación.

3.       Recolección y análisis de los requisitos

En esta etapa se recogen y analizan los requerimientos de los usuarios y de las áreas de aplicación. Esta información se puede recoger de varias formas:

o    Entrevistando al personal de la empresa, concretamente, a aquellos que son considerados expertos en las áreas de interés.

o    Observando el funcionamiento de la empresa.

o    Examinando documentos, sobre todo aquellos que se utilizan para recoger o visualizar información.

o    Utilizando cuestionarios para recoger información de grandes grupos de usuarios.

o    Utilizando la experiencia adquirida en el diseño de sistemas similares.

Esta etapa tiene como resultado un conjunto de documentos con las especificaciones de requisitos de los usuarios, en donde se describen las operaciones que se realizan en la empresa desde distintos puntos de vista.

La información recogida se debe estructurar utilizando técnicas de especificación de requisitos, como por ejemplo técnicas de análisis y diseño estructurado y diagramas de flujo de datos. También las herramientas CASE ( Computer-Aided Software Engineering) pueden proporcionar una asistencia automatizada que garantice que los requisitos son completos y consistentes.

4.       Diseño de la base de datos

Esta etapa consta de tres fases: diseño conceptual, diseño lógico y diseño físico de la base de datos los cuales describiremos mes adelante.

Los objetivos del diseño de la base de datos son:

·         Representar los datos que requieren las principales áreas de aplicación y los grupos de usuarios, y representar las relaciones entre dichos datos.

·         Proporcionar un modelo de datos que soporte las transacciones que se vayan a realizar sobre los datos.

·         Especificar un esquema que alcance las prestaciones requeridas para el sistema.

Hay varias estrategias a seguir para realizar el diseño: de abajo a arriba, de arriba a abajo, de dentro a fuera y la estrategia mixta. La estrategia de abajo a arriba parte de todos los atributos y los va agrupando en entidades y relaciones. Es apropiada cuando la base de datos es simple, con pocos atributos. La estrategia de arriba a abajo es más apropiada cuando se trata de bases de datos complejas. Se comienza con un esquema con entidades de alto nivel, que se van refinando para obtener entidades de bajo nivel, atributos y relaciones. La estrategia de dentro a fuera es similar a la estrategia de abajo a arriba, pero difiere en que se parte de los conceptos principales y se va extendiendo el esquema para considerar también otros conceptos, asociados con los que se han identificado en primer lugar. La estrategia mixta utiliza ambas estrategias, de abajo a arriba y de arriba a abajo, con un esquema de divide y vencerás. Se obtiene un esquema inicial de alto nivel, se divide en partes, y de cada parte se obtiene un subesquema. Estos subesquemas se integran después para obtener el modelo final.

5.       Selección del SGBD .- Si no se dispone de un SGBD, o el que hay se encuentra obsoleto, se debe escoger un SGBD que sea adecuado para el sistema de información. Esta elección se debe hacer en cualquier momento antes del diseño lógico.

6.       Diseño de la aplicación .- En esta etapa se diseñan los programas de aplicación que usarán y procesarán la base de datos. Esta etapa y el diseño de la base de datos, son paralelas. En la mayor parte de los casos no se puede finalizar el diseño de las aplicaciones hasta que se ha terminado con el diseño de la base de datos. Por otro lado, la base de datos existe para dar soporte a las aplicaciones, por lo que habrá una realimentación desde el diseño de las aplicaciones al diseño de la base de datos.

En esta etapa hay que asegurarse de que toda la funcionalidad especificada en los requisitos de usuario se encuentra en el diseño de la aplicación. Habrá algunos programas que utilicen y procesen los datos de la base de datos.

7.       Prototipado .- Esta etapa, que es opcional, es para construir prototipos de la aplicación que permitan a los diseñadores y a los usuarios probar el sistema. Un prototipo es un modelo de trabajo de las aplicaciones del sistema. El prototipo no tiene toda la funcionalidad del sistema final, pero es suficiente para que los usuarios puedan utilizar el sistema e identificar qué aspectos están bien y cuáles no son adecuados, además de poder sugerir mejoras o la inclusión de nuevos elementos. Este proceso permite que quienes diseñan e implementan el sistema sepan si han interpretado correctamente los requisitos de los usuarios. Otra ventaja de los prototipos es que se construyen rápidamente.

Esta etapa es imprescindible cuando el sistema que se va a implementar tiene un gran coste, alto riesgo o utiliza nuevas tecnologías.

8.       Implementación

En esta etapa se crean las definiciones de la base de datos a nivel conceptual, externo e interno, así como los programas de aplicación. La implementación de la base de datos se realiza mediante las sentencias del lenguaje de definición de datos (LDD) del SGBD escogido. Estas sentencias se encargan de crear el esquema de la base de datos, los ficheros en donde se almacenarán los datos y las vistas de los usuarios.

Los programas de aplicación se implementan utilizando lenguajes de tercera o cuarta generación. Partes de estas aplicaciones son transacciones sobre la base de datos, que se implementan mediante el lenguaje de manejo de datos (LMD) del SGBD. En esta etapa, también se implementan los menús, los formularios para la introducción de datos y los informes de visualización de datos. Para ello, el SGBD puede disponer de lenguajes de cuarta generación que permiten el desarrollo rápido de aplicaciones mediante lenguajes de consultas no procedurales, generadores de informes, generadores de formularios, generadores de gráficos y generadores de aplicaciones.

También se implementan en esta etapa todos los controles de seguridad e integridad. Algunos de estos controles se pueden implementar mediante el LDD y otros puede que haya que implementarlos mediante utilidades del SGBD o mediante programas de aplicación.

9.       Conversión y carga de datos

Esta etapa es necesaria cuando se está reemplazando un sistema antiguo por uno nuevo. Los datos se cargan desde el sistema viejo al nuevo directamente o, si es necesario, se convierten al formato que requiera el nuevo SGBD y luego se cargan. Si es posible, los programas de aplicación del sistema antiguo también se convierten para que se puedan utilizar en el sistema nuevo.

10.   Prueba

En esta etapa se prueba y valida el sistema con los requisitos especificados por los usuarios. Para ello, se debe diseñar una batería de tests con datos reales, que se deben llevar a cabo de manera metódica y rigurosa. Es importante darse cuenta de que la fase de prueba no sirve para demostrar que no hay fallos, sirve para encontrarlos. Si la fase de prueba se lleva a cabo correctamente, descubrirá los errores en los programas de aplicación y en la estructura de la base de datos. Además, demostrará que los programas “parecen” trabajar tal y como se especificaba en los requisitos y que las prestaciones deseadas “parecen” obtenerse. Por último, en las pruebas se podrá hacer una medida de la fiabilidad y la calidad del software desarrollado.

11.   Mantenimiento

Una vez que el sistema está completamente implementado y probado, se pone en marcha. El sistema está ahora en la fase de mantenimiento en la que se llevan a cabo las siguientes tareas:

·         Monitorización de las prestaciones del sistema. Si las prestaciones caen por debajo de un determinado nivel, puede ser necesario reorganizar la base de datos.

·         Mantenimiento y actualización del sistema. Cuando sea necesario, los nuevos requisitos que vayan surgiendo se incorporarán al sistema, siguiendo de nuevo las etapas del ciclo de vida que se acaban de presentar.

3.      Diseño de la base de datos.

Para el diseño de la base de datos consta de tres faces que son:

1.       Diseño conceptual. En esta etapa se debe construir un esquema de la información que se usa en la empresa, independientemente de cualquier consideración física. A este esquema se le denomina esquema conceptual. Al construir el esquema, los diseñadores descubren la semántica (significado) de los datos de la empresa: encuentran entidades, atributos y relaciones. El objetivo es comprender:

·         La perspectiva que cada usuario tiene de los datos.

·         La naturaleza de los datos, independientemente de su representación física.

·         El uso de los datos a través de las áreas de aplicación.

2.       Diseño lógico.

El diseño lógico es el proceso de construir un esquema de la información que utiliza la empresa, basándose en un modelo de base de datos específico, independiente del SGBD concreto que se vaya a utilizar y de cualquier otra consideración física. En esta etapa, se transforma el esquema conceptual en un esquema lógico que utilizará las estructuras de datos del modelo de base de datos en el que se basa el SGBD que se vaya a utilizar, como puede ser el modelo relacional, el modelo de red, el modelo jerárquico o el modelo orientado a objetos. Conforme se va desarrollando el esquema lógico, éste se va probando y validando con los requisitos de usuario.

La normalización es una técnica que se utiliza para comprobar la validez de los esquemas lógicos basados en el modelo relacional, ya que asegura que las relaciones (tablas) obtenidas no tienen datos redundantes. Esta técnica se presenta en el capítulo dedicado al diseño lógico de bases de datos.

El esquema lógico es una fuente de información para el diseño físico. Además, juega un papel importante durante la etapa de mantenimiento del sistema, ya que permite que los futuros cambios que se realicen sobre los programas de aplicación o sobre los datos, se representen correctamente en la base de datos.

3.       Diseño físico..- El diseño físico es el proceso de producir la descripción de la implementación de la base de datos en memoria secundaria: estructuras de almacenamiento y métodos de acceso que garanticen un acceso eficiente a los datos.

Para llevar a cabo esta etapa, se debe haber decidido cuál es el SGBD que se va a utilizar, ya que el esquema físico se adapta a él. Entre el diseño físico y el diseño lógico hay una realimentación, ya que algunas de las decisiones que se tomen durante el diseño físico para mejorar las prestaciones, pueden afectar a la estructura del esquema lógico.

En general, el propósito del diseño físico es describir cómo se va a implementar físicamente el esquema lógico obtenido en la fase anterior. Concretamente, en el modelo relacional, esto consiste en:

·         Obtener un conjunto de relaciones (tablas) y las restricciones que se deben cumplir sobre ellas.

·         Determinar las estructuras de almacenamiento y los métodos de acceso que se van a utilizar para conseguir unas prestaciones óptimas.

·         Diseñar el modelo de seguridad del sistema.

4.      Diseño de aplicaciones:

El diseño de las aplicaciones, una fase que se debe llevar a cabo en paralelo con el diseño de la base de datos, está compuesta por dos actividades: el diseño de las transacciones y el diseño de las interfaces de usuario de informes y formularios.

5.      Herramientas CASE.

Las herramientas CASE permiten que el desarrollo de los sistemas de información se realice de modo eficiente y efectivo.

La administración de datos consiste en la gestión de los datos como recurso, mientras que la administración de la base de datos es la gestión de la base de datos física.

 

 

 

 

Técnicas de Demostración de hechos

El desarrollo de bases de datos normalmente utiliza diversas técnicas de determinación de hechos a lo largo de un mismo proyecto de bases de datos. Existen cinco técnicas de determinación de hechos comúnmente utilizadas:

1.       Examen de la documentación.

2.       Entrevistas.

3.       Observación de la operación de la empresa.

4.       Investigación.

5.       Cuestionario

Examen de la documentación.

Es muy útil cuando estamos tratando de comprender como surgió la necesidad del nuevo sistema de base de datos. Si el problema esta relacionado con el sistema actual, debe existir documentación asociada con dicho sistema. Examinando los documentos, formularios, informes y archivos asociados con el sistema actual.

Entrevistas.

Es la técnica de determinación de hecho mas comúnmente utilizada a la que resulta normalmente más útil. Existen dos tipos de entrevistas:

·         Estructurada. Es cuando el entrevistador tiene un conjunto específico de cuestiones que preguntar al entrevistado. Las cuestiones abiertas permite al entrevistado responder de la forma en la que el considere apropiado. Las cuestiones Cerradas restringen las respuestas posibles que deben ceñirse a una serie de opciones específicas o deben ser respuestas cortas y directas.

·         No estructuradas. Se llevan a cabo teniendo en mente solo un objetivo general y con solo unas pocas cuestiones específicas. El entrevistador depende del entrevistado para fijar la base y la dirección de la entrevista. Este tipo de entrevista tiende a perder el foco frecuentemente y por ello no es aconsejada para el análisis y diseño de bases de datos.

Observación de la operación de la empresa.

Es una de las técnicas de determinación de hechos mas efectiva para tratar d comprender un sistema. Con esta es posible participar en la realización de una serie de actividades para aprender acerca del sistema u observar a otra persona realizar esas actividades. Para que el proceso de observación tenga éxito se requiere de una preparación previa, por lo que es muy importante conocer lo más posible acerca de las personas y de la actividad que se va a observar.

Tenemos algunas ventajas y desventajas de esta técnica:

·         Ventajas.

o   Permite comprobar la validez de los hechos y los datos.

o   El observador puede ver directamente que es lo que se esta haciendo.

o   Es un método relativamente barato.

o   El observador puede realizar medidas acerca de las tareas.

·         Desventajas

o   Las personas pueden de forma consiente o inconsciente, comportarse de forma distinta cuando son observadas.

o   Puede perderse la observación de tareas con niveles de dificultad o volúmenes diferentes a los experimentados durante el periodo de observación.

o   Algunas tareas pueden no siempre llevarse a cabo de la manera observada.

o   Este método puede ser poco práctico o imposible de llevar a cabo.

 

Investigación.

Una técnica útil en la determinación de hechos consiste en investigar acerca de la aplicación y los problemas. Los libros, revistas y foros en internet pueden ser esenciales para la investigación ya que en estos podemos ver y analizar como otras personas han resuelto problemas y la optimidad de su solución.

Tenemos algunas ventajas y desventajas de esta técnica:

·         Ventajas.

o   Puede ahorrar tiempo si ya existe una solución.

o   El investigador puede ver como otras personas han resuelto problemas similares o han dado respuesta a similares requisitos.

o   El investigador se mantiene al día en lo que respecta a los desarrollos existentes.

·         Desventajas

o   Requiere disponer de acceso a las fuentes de información apropiadas.

o   Puede que al final no ayude a resolver el problema debido a que este no esta documentado en ningún otro sitio.

Cuestionario

Otra de las técnicas de determinación de hecho son los cuestionarios. Estos son documentos escritos ex profeso que permiten hechos de un gran número de personas al mismo tiempo que se mantiene un cierto grado de control sobre sus respuestas, cuando se quiere tratar con una audiencia demasiado amplia esta es la única técnica que se puede utilizar que sea mas optima que esta.

Tenemos algunas ventajas y desventajas de esta técnica:

·         Ventajas.

o   Las distintas personas completar y devolver los cuestionarios según les convenga.

o   Es una forma relativamente barata de recopilar datos de un gran número de personas.

o   Las respuestas pueden tabularse y analizarse rápidamente.

 

·         Desventajas

o   El número de persona que respondan puede ser bajo, posiblemente de solo entre el 5% y el 10%.

o   Puede que algunos cuestionarios se devuelvan incompletos.

o   No se puede observar y analizar el lenguaje corporal de la persona que responde al cuestionario.

 

Modelo E/R

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:

//H:\Bases%20de%20Datos%20II\eNTIDAD-RELACION\Modelo%20Entidad-Relación%20(E-R).mht!http://www.lsgames.com/tmp/imagenes/elementos-graficos.jpg

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:

//H:\Bases%20de%20Datos%20II\eNTIDAD-RELACION\Modelo%20Entidad-Relación%20(E-R).mht!http://www.lsgames.com/tmp/imagenes/ejemplos.jpg

Problemas del modelo ER

Existen algunos problemas que se pueden crear al momento de crear un modelo ER. Estos problemas se denominan trampas de conexión que aparecen debido a una mala interpretación del significado de algunas relaciones.

                Tenemos dos clases de trampas de conexión como lo son:

1.       Trampas multiplicativas:

Resulta cuando un modelo representa una relación entre tipos de entidad pero la ruta entre las mismas es ambigua.

2.       Trampas de corte:

Resulta cuando un modelo sugiere la existencia de una relación entre ciertos tipos de entidad, pero no existe ninguna ruta entre ciertas instancias de entidad.

Modelo E/R Avanzado

Especialización y Generalización

Este concepto esta asociado con tipos esenciales de entidades conocidas como superclases y subclases, y con el proceso de herencia de atributos.

·         Superclases

Un tipo de entidad que incluye uno o mas subgrupos diferentes de sus instancias, los cuales es preciso representar en un modelo de datos.

·         Subclases.

Es un subgrupo diferenciado de instancias de un tipo de entidad, que necesita ser representado en un modelo de datos.

·         Relaciones entre superclases y subclases.

Cada miembro de una subclase es también miembro de una superclase aunque desempeñan papeles distintos. Algunas superclases pueden tener subclases solapadas, como por ejemplo si uno de los empleados fuera a la vez gerente y miembro de la fuerza de ventas. Podemos utilizar las superclases y subclases para evitar tener que describir diferentes tipos de empleados que posiblemente tengan diferentes atributos, utilizando una única entidad.

·         Herencia de Atributo

Una subclase es una entidad por propio derecho, por ello esta entidad puede tener subclases, La entidad con sus subclases y estas con sus subclases,…etc., se denomina jerarquía de tipos.

Una subclase con más de una superclase se denomina subclase compartida. Es decir un miembro de la subclase compartida debe ser miembro de las superclases asociadas. Como consecuencia la subclase compartida hereda los atributos de todas las superclases, además de poder tener sus propios atributos adicionales. Este proceso se denomina herencia múltiple.

·         Especialización,

Es el proceso de maximizar las diferencias entre miembros de la entidad identificando sus características distintivas.

·         Generalización.

Es el proceso de minimizar las diferencias entre entidades identificando sus características comúnes.

·         Restricciones a la especialización/generalización.

Existen dos restricciones que se le pueden aplicar a la especialización y generalización, estas son:

o   De participación.

Determina si todo miembro de la superclase debe participar como miembro de una subclase.

o   De disyunción.

Describe la relación entre miembros de las subclases e indica si es posible que un miembro de una superclase sea miembro de una subclase o de más de una.

 

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Categorías

A %d blogueros les gusta esto: