generacioOn de un sistema de base de datoOs

• En esta fase se crea un esquema conceptual y los esquemas externos necesarios en el modelo de datos del SGBD seleccionado, mediante la transformación de los esquemas de modelo de datos a alto nivel obtenidos en la Fase 2a, al modelo de datos ofrecido por el SGBD.
• como su nombre lo dice se hace como un resumen de toda la informacion y se pueden ver todos los esquemas mas importantes.
• http://tramullas.com/documatica/2-8.html

transfoOrmacioOn al moOdeloO de datoOs

• Fase 4: Transformación del modelo de datos (o fase de diseño lógico).En esta fase se crea un esquema conceptual y los esquemas externos necesarios en el modelo de datos del SGBD seleccionado, mediante la transformación de los esquemas de modelo de datos a alto nivel obtenidos en la Fase 2a, al modelo de datos ofrecido por el SGBD.
• es una fase en la cual se hace un tipo de esquema se basa en los esquemas externos y se relaciona con los datos que se obtienen en una fase anterior
• http://tramullas.com/documatica/2-8.html

diseñoO fisicoO de la base de datoOs

• El diseño de una base de datos se descompone en tres etapas: diseño conceptual, lógico y físico. La etapa del diseño lógico es independiente de los detalles de implementación y dependiente del tipo de SGBD que se vaya a utilizar. La salida de esta etapa es el esquema lógico global y la documentación que lo describe. Todo ello es la entrada para la etapa que viene a continuación, el diseño físico.
  Mientras que en el diseño lógico se especifica qué se guarda, en el diseño físico se especifica cómo se guarda. Para ello, el diseñador debe conocer muy bien toda la funcionalidad del SGBD concreto que se vaya a utilizar y también el sistema informático sobre el que éste va a trabajar. El diseño físico no es una etapa aislada, ya que algunas decisiones que se tomen durante su desarrollo, por ejemplo para mejorar las prestaciones, pueden provocar una reestructuración del esquema lógico.
• consta de tres etapas cada una tiene una funcion diferente una se encarga del sgbd otra de la documentacion y la otra se encarga de como se guarda
• http://www.mailxmail.com/curso-diseno-base-datos-relacionales/diseno-fisico-bases-datos

eleccioOn de un sistema gestoOr de base de datoOs

• Software con capacidad para definir, mantener y utilizar una base de datos.Un sistema de gestión de bases de datos debe permitir definir estructuras dealmacenamiento, acceder a los datos de forma eficiente y segura, etc.Factores técnicos1. Organización de los datos independientemente de las aplicaciones que los vayan a usar(independencia lógica) y de los ficheros en los que vayan a almacenarse(independencia física).2. Datos y aplicaciones accesibles a los usuarios y a otras aplicaciones de la manera másamigable posible (lenguajes de consulta: SQL, Query-by-example…)3. Datos gestionados de forma centralizada e independiente de las aplicaciones.4. No redundancia (los datos no deben estar duplicados), consistencia e integridad.5. Fiabilidad (protección frente a fallos).6. Seguridad (no todos los datos deben ser accesibles a todos los usuarios).7. Capacidad de replicación y distribución8. Disponibilidad de herramientas de desarrollo de software9. PortabilidadFactores no técnicos1. Coste de la adquisición del software, del hardware y coste de mantenimiento.2. Coste de creación y conversión de la base de datos3. Coste de personal (formación y operación).4. Disponibilidad de servicios del proveedor.
• el proposito de esto es manejar adecuadamente los datos para que en un determinado momento se pueda utilizar esta informacion
• http://elvex.ugr.es/idbis/db/docs/design/1-process.pdf

diseñoO coOnceptual de la base de datoOs

• Definición de Diseño conceptual de bases de datos Conjunto de actividades que resultan en un esquema conceptual de alto nivel de una base de datos, independiente del software gestor (SGBD), partiendo de especificaciones de requerimientos.El diseño conceptual de una base de datos suele hacerse empleando un DER.Las personas encargadas de esta tarea suelen llamarse diseñadores de bases de datos.El diseño conceptual de una base de datos forma parte del proceso de diseño de la base de datos completa, que incluye el diseño conceptual, diseño lógico y diseño físico de la misma.Desarrollo del diseño conceptual de una base de datosEl diseño conceptual parte de los requerimientos, resultando en un esquema conceptual de base de datos.El esquema conceptual sirve luego para el diseño lógico de base de datos.
• un diseñador de base de datos se encarga de admnistrarla primero se hace un esquema y despues se hace el diseño fisico
• http://www.alegsa.com.ar/Dic/dise%C3%B1o%20conceptual%20de%20bases%20de%20datos.php

recoOleccioOn y analisis de infoOrmacioOn

• La recolección de datos se refiere al uso de una gran diversidad de técnicas y herramientas que pueden ser utilizadas por el analista para desarrollar los sistemas de información, los cuales pueden ser la entrevistas, la encuesta, el cuestionario, la observación, el diagrama de flujo y el diccionario de datos.
  Todas estos instrumentos se aplicará en un momento en particular, con la finalidad de buscar información que será útil a una investigación en común. En la presente investigación trata con detalle los pasos que se debe seguir en el proceso de recolección de datos, con las técnicas ya antes nombradas.
• la recoleccion de datos nos sirve para conseguir informacion de diferentes temas necesitamos cierto tipo de pasos para conseguir datos concretos
• http://www.monografias.com/trabajos12/recoldat/recoldat.shtml

cicloO de vida del sSisStema de aplicacioOn de basSe de datoOsS

• Ciclo de vida de las aplicaciones 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. 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, se muestran las tareas más importantes que se realizan en cada etapa.
  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úa. 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:
  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.
  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. 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.
  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.
  Además, habrá que diseñar las interfaces de usuario, aspecto muy importante que se suele ignorar. El sistema debe ser fácil de aprender, fácil de usar, ser directo y estar ``dispuesto a perdonar''. Si la interface no tiene estas características, el sistema dará problemas, sin lugar a dudas.
  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. Las sentencias de este lenguaje se pueden embeber en un lenguaje de programación anfitrión como Visual Basic, Delphi, C, C++, Java, COBOL, Fortran, Ada o Pascal. 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.
• son una serie de pasos que cada uno tiene caracteristicas especiales y no llevan una secuencia en especifico
• http://www3.uji.es/~mmarques/f47/apun/node67.html

tercera foOrma noOrmal

• Tercera Forma Normal (3FN) Artículo principal: Tercera forma normal
  La tabla se encuentra en 3FN si es 2FN y cada atributo que no forma parte de ninguna clave, depende directamente y no transitivamente, de la clave primaria.
  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 via 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.
• la tercera forma normal depende de que antes debio haber pasado por la primera y la segunda forma
• http://es.wikipedia.org/wiki/Clave_for%C3%A1nea

segunda foOrma noOrmal

• Segunda Forma Normal (2FN)
  Artículo principal: 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 removidos de X y la dependencia todavía se mantiene, esto es A Є X, (X – {A}) -> Y .
  Por ejemplo {SSN, PNUMBER} HOURS es completamente dependiente dado que ni SSN HOURS ni PNUMBER HOURS mantienen la dependencia. Sin embargo {SSN, PNUMBER} ENAME es parcialmente dependiente dado que SSN ENAME mantiene la dependencia
• sabemos que una segunda forma normal debio antes de pasar por la primera forma normal, un atributo depende de otro y cuenta con una clave
• http://es.wikipedia.org/wiki/Clave_for%C3%A1nea

primera foOrma noOrmal

• Primera Forma Normal (1FN) [editar]
  Artículo principal: Primera forma normal
  Una tabla está en Primera Forma Normal sólo 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 tabla no contiene atributos nulos.
  Si no posee ciclos repetitivos.
  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
• sabemos que las tablas que se encuentran en primera forma normal no deben tener datos repetidos y tienen una clave
• http://es.wikipedia.org/wiki/Clave_for%C3%A1nea#Segunda_Forma_Normal_.282FN.29

noOrmalizacioOn

• El proceso de normalización de bases de datos consiste en 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.
  Evitar problemas de actualización de los datos en las tablas.
  Proteger la integridad de los datos.
  En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:
  Cada columna debe tener su nombre único.
  No puede haber dos filas iguales. No se permiten los duplicados.
  Todos los datos en una columna deben ser del mismo tipo.
• la normalizacion son reglas que nos ayudan a que no tengamos imprevistos al actualizar nuestras tablas, a cuidar los datos y no tener informacion repetida
• http://es.wikipedia.org/wiki/Clave_for%C3%A1nea