10 pasos para el éxito sql

El propósito de SQL es permitir a los desarrolladores para crear bases de datos útiles y robustos y aplicaciones de bases de datos. Con el fin de tener éxito en esto, su esfuerzo de desarrollo debe pasar por una serie de etapas, cada uno de los edificios en el anterior, hasta que pueda celebrar con razón un proyecto exitoso. He aquí diez etapas esenciales que se traducirá en un esfuerzo de desarrollo de base de datos exitosa.

Definir la tarea

Al inicio de un proyecto, la persona que le está asignando la tarea de construir un sistema (el cliente) tiene una idea de lo que se necesita. Esa idea puede ser muy específico, agudo y conciso, o puede ser vago, nebuloso y mal definida. Su primera tarea es generar y poner por escrito una descripción detallada de exactamente lo que el resultado final del proyecto, llamado los entregables debería ser. Esta es la tarea principal de la fase de definición.

En la etapa de definición, se define el problema a resolver por su base de datos y la aplicación asociada con la mayor precisión posible. Para ello, escuchando con atención a su cliente como ella describe lo que prevé el sistema sea. Haga preguntas para aclarar puntos vagos. A menudo, el cliente no tendrá cosas de pensamiento a través del todo. Ella va a tener una idea general de lo que quiere, pero sin una idea clara de los detalles. Usted debe llegar a un acuerdo con ella sobre los detalles antes de poder continuar.

Determinar el alcance del proyecto

El siguiente paso en la fase de definición es determinar el alcance del proyecto. ¿Qué tan grande un trabajo será? ¿Qué se requiere de sistemas de tiempo analista programador, tiempo, equipo y otras partidas de costes? ¿Hay una fecha límite?

Determinar lo que se necesita para hacer el trabajo:

Una vez que haya determinado el alcance del proyecto, la siguiente pregunta que debe hacerse es: "¿Es posible hacer este trabajo dentro de las limitaciones de tiempo y de costos que se le plantean por el cliente? Para responder a esta pregunta, debe hacer un análisis de factibilidad. Después de completar el análisis, puede decidir que el proyecto no es viable como se define actualmente. Usted debe ya sea rechazarla o convencer al cliente a reducir el alcance a algo más manejable.

Una vez que haya determinado que el proyecto es factible, ya sabes qué tipo de personal que necesita para hacer el trabajo. En este punto, usted necesita decidir quién va a trabajar en el proyecto. Usted puede ser capaz de hacer un pequeño trabajo por sí mismo, pero la mayoría de los esfuerzos de desarrollo requiere un equipo de varias personas. Encontrar a las personas que tienen las habilidades necesarias (y que también están disponibles para trabajar en el proyecto cuando los necesite) puede ser tan difícil como cualquier parte del esfuerzo total de desarrollo.

Generar una Declaración de Requisitos

Una vez que ha llegado a un acuerdo con su cliente sobre qué es exactamente el proyecto incluirá, puede escribir una declaración formal de Requisitos. La Declaración de los requisitos es una declaración explícita de los mecanismos de la exhibición, de actualización y de control de la aplicación de base de datos.

La Declaración de los requisitos debe ser lo más detallada posible. Básicamente se trata de un contrato entre usted y su cliente. Usted está de acuerdo en exactamente lo que será entregado y cuándo va a ser entregado. Para sellar el acuerdo, usted y su cliente debe firmar la Declaración de los requisitos, lo que significa un acuerdo sobre lo que será responsable de la entrega. Este paso puede parecer más bien formal, pero protege a ambas partes. Nunca puede haber ninguna pregunta más tarde como a lo acordado.

Crear un modelo de base de datos oficial

Hasta ahora, el proyecto ha sido sobre todo el análisis. En este punto, se puede entrar en la fase de diseño y hacer la transición de análisis para diseñar. Lo más probable es saber todo lo que necesitas saber sobre el problema, por lo que ahora se puede empezar a diseñar la solución.

Diseño de base de datos tiene que ver con los modelos. En este punto, usted tiene 'modelo de datos, que captura los usuarios de los usuarios concepto de la estructura de la base de datos. Incluye todos los tipos principales de objetos, las características de los objetos, y cómo los objetos se relacionan entre sí. Sin embargo, no está suficientemente estructurado para ser la base para un diseño de base de datos. Para eso, es necesario convertir el modelo de datos de los usuarios en un modelo que se ajusta a uno de los sistemas formales de modelado de bases de datos que se han desarrollado en los últimos decenios.

El más popular de los sistemas de modelado formal es el modelo de entidad-relación, comúnmente conocida como el modelo ER. Con este modelo, puede capturar lo que los usuarios le han dicho en una forma bien definida que luego se puede traducir fácilmente en una base de datos relacional.

Una vez que tenga el sistema en la forma de un modelo ER, es fácil de convertir en un modelo relacional. El modelo relacional es algo que su DBMS entiende, y usted puede crear la base de datos directamente de ella.

Diseñe la aplicación de base de datos

Una vez que haya diseñado la base de datos, la tarea de diseño se hace sólo medio. Usted tiene una estructura que ahora puede llenar con los datos, pero aún no tienen una herramienta para operar sobre esos datos. La herramienta debe diseñar ahora es la aplicación de base de datos.

La aplicación de base de datos es la parte del sistema total que interactúa con el usuario. Se crea todo lo que el usuario ve en la pantalla. Detecta y responde a cada pulsación de la tecla que el usuario hace y cada acción del ratón que el usuario realiza. Imprime todos los informes que es leído por los compañeros de trabajo del usuario. Desde el punto de vista del usuario, la aplicación de base de datos es el sistema.

En el diseño de la aplicación de base de datos, debe asegurarse de que permite a los usuarios hacer todo lo que la Norma de Requisitos promete que van a ser capaces de hacer. También debe presentar una interfaz de usuario que sea comprensible y fácil de usar. Las funciones del sistema deben aparecer en posiciones lógicas en la pantalla. El usuario debe entender fácilmente cómo realizar todas las funciones que la aplicación proporciona.

Constrúyelo

Ahora que tiene un diseño de base de datos, puede crear las tablas, las relaciones entre ellos, y las restricciones a que los datos que se pueden introducir en ellos.

Documentarlo

Todo lo que has hecho y las razones de todas las decisiones que has tomado deben ser meticulosamente documentado. Con suerte, usted ha estado haciendo esto todo el tiempo. En esta etapa, todo lo que tiene que hacer es poner la documentación en su forma final. Un desarrollador competente que no esté familiarizado con el proyecto debe ser capaz de recogerlo después de haber pasado a cosas más grandes y mejores.

Prueba de todo

Una vez que se ha construido y documentado un sistema de base de datos, puede parecer como si estuviera terminada y se puede disfrutar de unas vacaciones bien merecidas, pero no está del todo todavía terminado - el sistema debe ser probado rigurosamente. Eso prueba que hay que hacer por alguien que no piensa de la misma manera que haces. Una vez que el sistema entre en funcionamiento, los usuarios van a hacer las cosas a lo que nunca imaginaste. Van a hacer combinaciones de selecciones que no previó, introduzca valores en los campos que no tienen sentido, y hacer las cosas al revés y al revés. No se sabe lo que van a hacer. Cualquiera que sea inesperado lo hace el usuario, desea que el sistema para responder de una manera que protege la base de datos y que guía al usuario en la toma de acciones de entrada apropiados.

Mantener el producto terminado

Después de haber entregado el sistema a tiempo y dentro del presupuesto, que se celebra, y se recoge el pago final para el trabajo, sus responsabilidades no se han terminado. Incluso si el probador independiente ha hecho un trabajo fantástico de tratar de hacer que el sistema falle, después de la entrega todavía puede albergar errores latentes que aparecen semanas, meses o incluso años después. Usted puede ser obligado a corregir esos errores sin cargo, dependiendo de su acuerdo contractual con el cliente.

Incluso si no se encuentran errores, es posible que tenga alguna responsabilidad en curso. Después de todo, nadie entiende el sistema, así como usted. Conforme pasa el tiempo, las necesidades de su cliente va a cambiar. Tal vez ella necesitará funciones adicionales, o quiere migrar a más nuevo, el hardware más potente. Estas posibilidades pueden requerir modificaciones a la aplicación de base de datos, y que está en la mejor posición para hacer esas modificaciones, en función de su conocimiento previo. Este trabajo adicional podría significar algún buen ingreso adicional para usted.