martes, 27 de abril de 2010

ELECCION DE UN SISTEMA GESTOR DE UNA BASE DE DATOS

  • Se consideran diferentes factores técnicos, económicos y de beneficio, de servicio técnico y formación de usuarios, organizativos de rendimiento, etc. Existen muchas "maneras" de manejar informáticamente esas bases de datos: con Access, Oracle, SQL, PostgreSQL o MySql .. entre otros. Cada sistema tiene unas características, unas ventajas y unos inconvenientes, la elección de uno u otro sistema para gestionar nuestra base de datos vendrá definida por nuestras necesidades.MySql es un gestor de bases de datos, es una manera de gestionar nuestros datos, es un bibliotecario computarizado que administra, gestiona, y opera con nuestros ficheros de datos . Si le hablamos en un idioma que entienda nos los devolverá ordenados, clasificados y/o seleccionados. Constituye el núcleo de la base de datos, contiene todas las rutinas necesarias para la gestión de los datos. Muchos sistemas utilizan como lenguaje del sistema el lenguaje SQL (Structured Query Language) Siendo una base de datos como un sistema de captación y mantenimiento de registros de forma computarizada, en este sistema se van a poder realizar las operaciones de inserción, borrado y modificación de un dato y modificaciones, borrados e inserciones de información de la estructura de la base de datos.
  • Por lo que entendi es que existen muchas maneras de manejar informaticamente las bases de datos ya sea con Acces, sql, oracle, entre otros cada uno de estos tiene sus ventajas y sus caracteristicas; nosotros podemos gestionar nuestros datos en un biblotecario computarizado
  • http://www.slideshare.net/tramullas/bases-de-datos-1176222

DISEÑO CONCEPRUAL DE LA BASE DE DATOS

  • El diseño conceptual parte de las especificaciones de requisitos de usuario y su resultado es el esquema conceptual de la base de datos. Un esquema conceptual es una descripción de alto nivel de la estructura de la base de datos, independientemente del SGBD que se vaya a utilizar para manipularla. Un modelo conceptual es un lenguaje que se utiliza para describir esquemas conceptuales. El objetivo del diseño conceptual es describir el contenido de información de la base de datos y no las estructuras de almacenamiento que se necesitarán para manejar esta información.
    El diseño lógico parte del esquema conceptual y da como resultado un esquema lógico. Un esquema lógico es una descripción de la estructura de la base de datos en términos de las estructuras de datos que puede procesar un tipo de SGBD. Un modelo lógico es un lenguaje usado para especificar esquemas lógicos (modelo relacional, modelo de red, etc.). El diseño lógico depende del tipo de SGBD que se vaya a utilizar, no depende del producto concreto.
    El diseño físico parte del esquema lógico y da como resultado un esquema físico. Un esquema físico es una descripción de la implementación de una base de datos en memoria secundaria: las estructuras de almacenamiento y los métodos utilizados para tener un acceso eficiente a los datos. Por ello, el diseño físico depende del SGBD concreto y el esquema físico se expresa mediante su lenguaje de definición de datos.

El diseño de una base de datos es un proceso complejo que abarca decisiones a muy distintos niveles. La complejidad se controla mejor si se descompone el problema en subproblemas y se resuelve cada uno de estos subproblemas independientemente, utilizando técnicas específicas. Así, el diseño de una base de datos se descompone en diseño conceptual, diseño lógico y diseño físico.

  • Este diseño de una base de datos abarca distintos niveles en los que se lleva una estructura de almacenamiento; para realizar un diseño complejo primero se tiene que dividir en grupos asi para hacerlo menos complejo despues; el diseño complejo describe el lenguaje usado para especificar esquemas logicos y el diseño fisico parte del logico el cual es una descripcion de una base de datos en una memoria secundaria
  • http://www3.uji.es/~mmarques/f47/apun/node81.htm

RECOLECCION Y ANALISIS DE BASES DE DATOS

  • La recolección de datos se refiere al uso de una gran diversidad de técnicas y herramientas que pueden ser utilizadas para desarrollar los sistemas de información, los cuales pueden ser la entrevistas, la observación, el diagrama de flujo y el diccionario de datos.
    Todas estos instrumentos se aplicarán en un momento en particular, con la finalidad de buscar información que será útil y utilizada.
    Se tratan con detalle los pasos que se debe seguir en el proceso de recolección de datos, con las técnicas ya antes nombradas.

    TÉCNICAS PARA HALLAR DATOS:
    Se utilizan una variedad de métodos a fin de recopilar los datos sobre una situación existente, como entrevistas, cuestionarios, inspección de registros (revisión en el sitio) y observación. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa.
    LA ENTREVISTA:
    Las entrevistas se utilizan para recabar información en forma verbal. Quienes responden pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema existente, usuarios potenciales del sistema propuesto o aquellos que proporcionarán datos o serán afectados por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos algunos analistas prefieren este método a las otras técnicas que se estudiarán más adelante. Sin embargo, las entrevistas no siempre son la mejor fuente de datos de aplicación.
    Dentro de una organización, la entrevistas es la técnica más significativa y productiva de que dispone el analista para recabar datos. En otras palabras, la entrevistas es un intercambio de información que se efectúa cara a cara. Es un canal de comunicación entre el analista y la organización; sirve para obtener información acerca de las necesidades y la manera de satisfacerlas, así como concejo y comprensión por parte del usuario para toda idea o método nuevos. Por otra parte, la entrevista ofrece al analista una excelente oportunidad para establecer una corriente de simpatía con el personal usuario, lo cual es fundamental en transcurso del estudio.

  • Esta recoleccion de datos debe hacer uso de tecnicas para que se pueda llevar acabo los sistemas de informacion como entrevistas, la observacion, etc; esto nos sirve para que mediante varios metodos logremos establecer los datos mas relevantes y asi para tener la finalidad de buscar informacion que nos sera util

  • http://www.monografias.com/trabajos12/recoldat/recoldat.shtml

CIGLO DE VIDA DEL SISTEMA DE APLICACION DE BASES DE DATOS

  • Las etapas del ciclo de vida de una aplicación de bases de datos son las siguientes:

    *Planificación del proyecto.
    *Definición del sistema.
    *Recolección y análisis de los requisitos.
    *Diseño de la base de datos.
    *Selección del SGBD.
    *Diseño de la aplicación.
    *Prototipado.
    *Implementación.
    *Conversión y carga de datos.
    *Prueba.
    *Mantenimiento.

    Estas etapas 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.

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.

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úa. También hay que determinar quienes son los usuarios y las áreas de aplicación.

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:
Entrevistando al personal de la empresa, concretamente, a aquellos que son considerados expertos en las áreas de interés.
Observando el funcionamiento de la empresa.
Examinando documentos, sobre todo aquellos que se utilizan para recoger o visualizar información.
Utilizando cuestionarios para recoger información de grandes grupos de usuarios.
Utilizando la experiencia adquirida en el diseño de sistemas similares. La información recogida debe incluir las principales áreas de aplicación y los grupos de usuarios, la documentación utilizada o generada por estas áreas de aplicación o grupos de usuarios, las transacciones requeridas por cada área de aplicación o grupo de usuarios y una lista priorizada de los requerimientos de cada área de aplicación o grupo de usuarios.

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. La primera fase consiste en la producción de un esquema conceptual, que es independiente de todas las consideraciones físicas. Este modelo se refina después en un esquema lógico eliminando las construcciones que no se pueden representar en el modelo de base de datos escogido (relacional, orientado a objetos, etc.). En la tercera fase, el esquema lógico se traduce en un esquema físico para el SGBD escogido. La fase de diseño físico considera las estructuras de almacenamiento y los métodos de acceso necesarios para proporcionar un acceso eficiente a la base de datos en memoria secundaria.
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.

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.
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.

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.

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.

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.
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.

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.

  • En una aplicaion de bases de datos se lleva acabo un ciclo de vida el cual contiene etapas, como la planeacion en la cual el modolo de datos se represnta un diagrama de entidad-relacion

Todos estos distintos ciclos de vida necesitan una retroalimentación continua y tiene varios pasos a seguir para determinar cual será éste ciclo de vida.

TERCERA FORMA NORMAL

  • La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.
    Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.
    Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva vía DNUMBER porque las dependencias SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.

  • Por lo que entendi es que esta tercera debe estar entrelazada con la segunda y no debe tener ninguna dependencia funcional, esta dependencia no es es dependiente si no parcial

  • http://es.wikipedia.org/

wiki/Normalización_de_bases_de_datos#Primera_Forma_Normal_.281FN.29

SEGUNDA FORMA NORMAL

  • Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales.

    En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que A Є X, (X – {A}) -x-> Y. Una dependencia funcional es una dependencia parcial si hay algunos atributos que pueden ser eliminados de X y la dependencia todavía se mantiene, esto es A Є X, (X – {A}) -> Y.
    Por ejemplo {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un empleado y el ID de un proyecto sabemos cuántas horas de trabajo por semana trabaja un empleado en dicho proyecto) es completamente dependiente dado que ni DNI HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI NOMBRE_EMPLEADO mantiene la dependencia.

  • Esta segunda forma debe estar en la primera; pero esta segunda debe de valerse por si misma osea que sus datos debed de estar ligados de alguna manera ya que esta segunda sera dependiende de la primera informacion ya que la segunda no valdria por si misma

  • http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos#Primera_Forma_Normal_.281FN.29

PRIMERA FORMA NORMAL

  • Una tabla está en Primera Forma Normal si:

*Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.
*La tabla contiene una clave primaria.
*La llave primaria no contiene atributos nulos.
*No posee ciclos repetitivos.
*No debe de existir variación en el número de columnas.
*Una columna no puede tener múltiples valores. Los datos son atómicos. (Si a cada valor de X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X)
*Esta forma normal elimina los valores repetidos dentro de una BD.

  • La primer forma normal no debe tener variociones en sus columnas ya que esta forma normal las eliminara a los valores repetidos dentro de una tabla es por esto que es la primer forma normal ya los atributos son atomicos