Home » .NET » Diseño de aplicaciones .NET

Diseño de aplicaciones .NET

Qué trataremos en este artículo?

Después de una breve definición del entorno de programación que utilizaremos, se presenta una visión general de las tareas implicadas en el diseño de una aplicación; se describe brevemente el ciclo de vida de una aplicación y se esquematizan algunas metodologías de diseño que ayudan a construir los cimientos de una aplicación. 
 
En este artículo se explican los pasos fundamentales para crear un buen diseño de una base de datos normalizada y los mecanismos de desnormalización que permiten ajustar el diseño más purista para obtener mejores rendimientos.
 
Lo explicado en este artículo se aplicará en cada aplicación que desarrollaremos en este cursillo por lo que los conceptos teóricos aquí explicados luego quedarán firmemente incorporados a nuestra rutina de trabajo en base a repetidas prácticas. 
Si bien estos artículos de aplicaciones .NET están redactados en el año 2007, el tema de diseño en capas sigue siendo totalmente vigente. 
 

ASP.NET

ASP.NET es la plataforma de Microsoft para desarrollar aplicaciones Web y se debe ejecutar en un servidor Web para generar formularios web dinámicos; para poder desarrollar formularios Web necesitamos Visual Studio o Visual Web Developer Express, herramientas que nos proporcionan un entorno de desarrollo potente para generar aplicaciones Web que, una vez publicadas en un servidor de producción, podrán ser utilizadas desde cualquier rincón del mundo, siempre y cuando se tenga acceso a Internet.
 
ASP.NET ha logrado simplificar el desarrollo Web  que, con el IDE adecuado, resulta ser casi tan simple como cualquier aplicación cliente/servidor haciendo transparentes las complicaciones propias de la separación del código que se ejecuta en la parte del cliente y en la parte del servidor.   
  
¿Para qué un IDE adecuado?
Es cierto, se puede desarrollar con ASP. NET simplemente con .NET Framework 2.0 y el Bloc de notas. Es posible pero para que nuestro trabajo resulte productivo es conveniente contar con un buen IDE de desarrollo de aplicaciones Web:  por ejemplo, Visual Studio o Visual Web Developer Express. Con más razón aún ahora que éste último es gratuito.

Visual Web Developer Express

Microsoft ha desarrollado un producto independiente especializado para el desarrollo de páginas Web dinámicas con ASP 2.0 y de distribución gratuita: Visual Web Developer 2005 Express Edition, que se puede descargar del sitio Web de Microsoft. Es la herramienta que utilizaremos en las distintas aplicaciones que desarrollaremos en este libro, siempre que no indiquemos lo contrario, junto también con SQL Server 2005 Express.
Visual Web Developer es un subconjunto de Visual Studio 2005: todo lo que se explique sobre Visual Web Developer es válido para aplicarlo en Visual Studio 2005.  

Visual Web Developer es una herramienta para el desarrollador Web que permite utilizar el paradigma visual para crear páginas Web y que incorpora un potente editor de código con ayudas auxiliares para que podamos codificar en Visual Basic, C# y HTML sin tener que abandonar el editor para buscar referencias externas. Visual Web Developer está totalmente integrado con SQL Server Express.

Visual Web Developer también incluye un navegador integrado, lo que nos libera de la necesidad de utilizar IIS en el entorno de desarrollo y prueba para el tipo de sitio Web denominado "Sistema de archivos".  
Visual Web Developer  permite tres tipos de sitios:  Sistema de archivos , Directorio virtual IIS o un Directorio FTP. En la versión anterior sólo se tenía la opción IIS, lo que obligaba tener iniciado un IIS.

Modos de aprender ASP.NET

Este cursillo es eminentemente práctico; podríamos decir que es sobre aplicaciones reales. ASP.NET es una tecnología muy simple de explicar pero cargada de infinitos detalles; hay libros que se enfrentan al desafío de enseñar la tecnología diseccionando cada tema y analizando las posibilidades de cada parámetro de cada método disponible. No es el enfoque de este libro, para eso tenemos muchos libros sobre ASP .NET o incluso la documentación en línea que nos ofrece Microsoft.  
 
 El enfoque de este cursillo es la enseñanza de ASP .NET a partir del desarrollo práctico de una serie de aplicaciones Web elegidas entre las que nos encontraremos más comúnmente en la vida real como programadores de aplicaciones: comercio electrónico, gestión de un catálogo de productos, foro temático, etc. 
 
Todas las aplicaciones son totalmente funcionales y se pueden utilizar como base para las adaptaciones que se necesiten en cada implantación. Lo importante es que las aplicaciones resuelven los problemas más comunes que nos encontraremos en nuestro trabajo profesional. Seguramente podremos encontrarnos que a las tablas de las bases de datos de los ejemplos quizá les  falten algunas columnas más, que el diseño de la página no sea de nuestro agrado, que sería interesante tal o cual funcionalidad adicional, etc.  Eso no es fundamental porque habremos aprendido a implementar esas modificaciones en las aplicaciones básicas.  
Las aplicaciones desarrolladas en el cursillo se pueden considerar como un punto de partida para cualquier aplicación real.
En cada artículo se analiza un problema determinado y se diseña e implementa la solución. La suma de lo aprendido en cada uno de los artículo equivaldrá a varios meses de experiencia práctica en el mundo profesional.  

Etapas en el diseño de aplicaciones

Existen infinitas metodologías para aplicar en el diseño de aplicaciones, quizá tantas como jefes de proyectos haya. A pesar de la amplia gama de alternativas, todas pasan de una manera u otra por una serie de pasos o fases inevitables que, según la metodología, tendrán nombres diferentes pero que en definitiva forman parte de la esencia del desarrollo de las aplicaciones informáticas. A continuación se presenta la secuencia de uno de los esquemas más habituales de lo que se denomina ciclo de vida de un proyecto de desarrollo: requerimiento, estudio de factibilidad, análisis, diseño, implementación, aceptación, implantación y mantenimiento.
 
Veamos brevemente qué sucede y que se espera de cada una de estas fases.

El requerimiento del usuario

El usuario (normalmente una empresa) detecta la necesidad de resolver un problema. El requerimiento puede estar dentro de lo considera lógico o escapar hacia la utopía. Por ejemplo, estos son tres ejemplos de requerimientos:
 
  • Una librería dedicada a la venta de libros a través de puntos de venta de "cemento y ladrillo" quiere ampliar su alcance comercial mediante su entrada al comercio electrónico. 
  • Una empresa de transporte internacional quiere controlar el flujo de sus mercaderías mediante un sistema GPS y dar a sus clientes la posibilidad de consultar la situación de sus envíos mediante una página Web en donde puede saber su posición con un margen de error de menos de 10 metros. 
  • Una empresa que vende sus productos por Internet quiere implementar un sistema de distribución de los productos comprados por sus clientes que permita asegurar que la compra se entrega a domicilio en cualquier lugar de la península dentro de las 24 horas y sin necesidad de utilizar un servicio de mensajería sino el correo nacional.
En este contexto se utilizamos la palabra "usuario" con dos sentidos diferentes y esto puede confundir al lector. Usamos "usuario" para definir al representante de una sección de una empresa que actúa como interlocutor con el analista de sistemas o desarrollador (por ejemplo, en el diseño de la aplicación de comercio electrónico de amazon.com quizá el gerente de ventas actuó como usuario de la aplicación). Por otra parte, no tenemos que confundir este término con el de "usuario final" de la aplicación que es cualquier persona que la utiliza y que no ha participado en el diseño (por ejemplo, cualquier comprador de amazon.com es un usuario final).    
 
Cuando se llega a esta fase sólo se cuenta con el requerimiento. Es la fase en la que se debe valorar la necesidad y la posibilidad de resolver el problema con los recursos técnicos y presupuestarios. Se debe saber cuánto es el tiempo disponible para resolver el problema y si la solución del problema puede rendir beneficios respecto a la situación vigente. 
 
Esta fase es la que descarta el tercer requerimiento de la sección anterior ya que obviamente no se puede depender del correo nacional para una entrega de productos en cualquier parte de la península dentro de un plazo de 24 horas. Las cosas de palacio van despacio. 
 
El resultado de esta fase, cuando el proyecto se considera factible, es un esquema del nuevo proyecto (no necesariamente con componente informático)  en la que:
 
  • Se definen a grandes rasgos el ámbito y el alcance del proyecto.
  • Se definen someramente los requerimientos del usuario.
  • Se establece la disponibilidad y las limitaciones del presupuesto para el desarrrollo de la solución.
  • Se establece un margen de tiempo para la implantación de la solución.

Análisis

En esta fase del proceso corresponde decidir exactamente qué es lo que hará el nuevo sistema. Normalmente esta fase comienza con un estudio muy completo del sistema vigente (cuando lo haya) y con la detección de sus fallos y carencias. A este estudio se le incorporan los nuevos requerimientos y todo esto da como resultado un documento que se denomina normalmente especificación del sistema. 
 

 

La especificación del sistema explica exacta y precisamente qué es lo que hará el sistema pero no necesariamente cómo lo hará.
 
La especificación del sistema es un documento fundamental en la relación usuario-desarrollador. Cuanto mejor documentada quede la especificación mayor protección, para ambas partes, habrá ante futuros malos entendidos.
 

Diseño

Todas las fases de un desarrollo informático son fundamentales. Al inicio del diseño del nuevo sistema el desarrollador ya tiene estos datos:
  • Qué es lo que se quiere obtener.
  • En qué plazo se quiere implantar.
  • Cuáles son las restricciones de presupuesto que limitan la elección en la compra de hardware y software.
No siempre es posible encontrar un diseño que cumpla con estos tres puntos. El más fácil de violar es el plazo de implantación que rara vez se cumple. Obviamente, si estamos desarrollando un sistema de acreditaciones para un evento deportivo que se realizará en noviembre de 2007 de nada sirve terminarlo en diciembre. A veces una demora de un día hace que una aplicación no sirva para nada y seguramente habrá graves penalizaciones por el incumplimiento y arduas discusiones en búsqueda de culpables (he aquí la importancia del documento de especificaciones). Sin embargo no siempre las cosas son tan dramáticas: otras veces una demora de un mes es perfectamente asumible por ambas partes.  
 
En esta fase el diseñador crea un plan de implementación para la especificación del sistema y se centra en cómo funcionará el sistema. También se define el entorno de desarrollo y de producción que se utilizará. 
 
En general, un diseño de una aplicación, es decir, el resultado de cumplir con esta fase, contiene lo siguiente:
  • Definición precisa de los objetivos y el alcance del sistema: este documento describe las funcionalidades y las distintas clases de usuarios del sistema.
  • Modelo de datos: es el diseño de la estructura de datos que da soporte a la aplicación compuesto por diagramas de entidad-relación, con un diseño definitivo de las tablas y un diseño primario del contenido de los campos. No se espera que en esta fase se sepa exactamente todos los campos de cada tabla, aunque sí las claves primarias y las relaciones. En la fase de implementación se detectarán necesidades de existencia de nuevos campos auxiliares. Incluso en la fase de prueba surgirán necesidades de creación o de eliminación de índices por razones de rendimiento.
  • Diagrama de flujo de datos: en las aplicaciones de cierta envergadura es preciso definir un diagrama de flujo de datos asociado a las distintas ramas de procesamiento del sistema.
  • Diagrama de navegación de páginas: los sistemas basados en interfaz de usuario, tal como son las aplicaciones Web, requieren la definición de un diagrama de navegación para clarificar la idea propuesta por el usuario y para buscar la mejor solución. Esto nos evitará la obtención de diseños engorrosos o de situaciones difíciles de entender para el usuario final (que muchas veces, obviamente, no participa en el diseño de la aplicación pero que debe estar representado por alguien que asuma su papel).
  • El diseño requiere mayores precisiones por parte de los usuarios pero siempre ateniéndose a los límites de la especificación inicial. Cualquier desvío respecto a la especificación debe provocar un replanteo de los tres elementos definidos en el análisis: objetivo, plazo y presupuesto.
 

Implementación

Esta fase es la más técnica de todas: es la fase de la creación de los programas,  adquisición del hardware, adquisición de licencias, instalación de los sistemas operativos, instalación de las bases de datos, contratación de líneas de comunicación, etc.  Tradicionalmente es una fase en la que el desarrollador se limita a concretar lo diseñado y el usuario interviene mucho menos que en la fase de diseño. No siempre es así y muchas veces en esta fase se detectan fallos o indefiniciones del diseño que nos obligan a replantearnos si la nueva información no modifica algo de la sagrada trilogía: objetivo, plazo y presupuesto. 
 
El resultado de esta fase es un sistema en funcionamiento dentro del entorno de desarrollo, listo para pasar las pruebas de aceptación por parte del usuario. 

Aceptación

Al llegar a esta fase, el sistema se encuentra terminado y cumple, en teoría,  con las especificaciones iniciales, incorporando si corresponde cualquier corrección posterior. Es la fase en la que se comprueba el funcionamiento adecuado de todas las funcionalidades y los requisitos de rendimiento y tiempos de respuesta en un entorno similar al de producción. 

Implantación

La implantación o puesta en marcha o en producción, todos términos similares, es la fase en la que la aplicación pasa a estar operativo para el uso. En el caso de aplicaciones de uso privado, internas de una empresa,  los usuarios finales suelen requerir un entrenamiento previo y un manual de operaciones. En contrapartida, las aplicaciones públicas como las que solemos utilizar en Internet deben ser totalmente autoexplicativas e intuitivas por lo que los usuarios deben saber utilizarlas con sólo mirar las opciones disponibles en la pantalla.
Si para poder utilizar una aplicación Web de uso público se necesita que el usuario realice un curso de aprendizaje  es porque hemos diseñado mal la aplicación.
 

Mantenimiento

Es una fase inevitable de todas las aplicaciones. Por más que hayamos previsto cada detalle en las fases previas lo más probable es que a lo largo del tiempo surjan modificaciones en el código, por fallos o por cambios de criterio. Otra fuente importante de modificaciones son las mejoras que piden los usuarios después de comenzar a utilizar el sistema. 
 
Una medida de la calidad de la aplicación la da su capacidad para aceptar fácil y seguramente modificaciones. 
 
En esta fase, que dura toda la vida que le resta a la aplicación, es bueno contar con una buena documentación en el propio código. 
 
La documentación del código es algo que se valora positivamente cuando se debe mantener un código creado por otro pero que, absurdamente,  muchas veces se considera innecesaria cuando se crea código nuevo, al pensar ingenua o erróneamente que ese código ya nadie más tendrá que modificarlo. 

Diseño RAD

El desarrollo RAD (Rapid Application Development) es la metodología más ampliamente utilizada y se basa en un proceso iterativo en el que se parte de un prototipo de aplicación. El prototipo no es más que un esqueleto de aplicación que se debe ir completando mediante la interacción usuario-desarrollador. Aquí las fases de diseño e implementación se realizan como si fuese un bucle operativo. En cada iteración el usuario opina, critica, sugiere y va guiando al desarrollador en lo que necesita para que la aplicación le resulte funcional. 
 
La ventaja de este desarrollo progresivo, en el que la aplicación se va creando como si fuese un modelo de arcilla, es que resulta muy fácil y económico rever y replantarse una solución. El modelo que se va creando como si fuese una cebolla, pero de adentro hacia afuera, es muy fácil de destruir y volver a la iteración anterior. Pensemos en lo que sucedería si se aplicase una metodología cerrada en donde cada fase quedase blindada a cualquier modificación. 
Hay quienes ven en el diseño RAD la gran solución para la definición precisa de los objetivos de una aplicación. Es cierto que a los desarrolladores les impone un esfuerzo adicional especialmente con usuarios que no tienen muy claro qué es lo que quieren de su aplicación. Pero son justamente los usuarios a quienes les resulta más cómodo este desarrollo iterativo ya que no los obliga a definir todo desde un principio y a medida que ven los resultados se les va ampliando la imaginación (lo que no siempre es una buena noticia para el desarrollador, todo se ha de decir).
 
La creación a partir de modelos y prototipos  no es una metodología nueva ni exclusiva del diseño informático ya que  se viene utilizando desde hace siglos en obras de ingeniería y para la evolución de las grandes invenciones del hombre. Podríamos pensar que el automóvil no es otra cosa que un resultado de un diseño evolutivo de duración milenaria que comenzó con el invento de la rueda. 

 Sobre el diseño en capas

El diseño en capas nos permite modularizar las aplicaciones en base a responsabilidades muy definidas. Es una manera de simplificar el diseño y facilitar la expansión de las aplicaciones.  
 
El diseño en capas tampoco es una invención del diseño informático. Hagamos un paralelismo con los automóviles que tanto conocemos. Si observamos la descripción técnica de un automóvil veremos que se suele realizar en diferentes planos: la estructura o chasis, el circuito de frenos, el sistema de propulsión, el sistema de amortiguación, el sistema eléctrico, etc. Cada uno de estos sistemas actúa como un sistema especializado en una función. Los sistemas informáticos también se subdividen en subsistemas con funcionalidades bien específicas que se pueden diseñar y desarrollar casi de modo independiente del resto.
Para lograr un diseño correcto, las capas que conforman una aplicación informática deben cumplir ciertas condiciones:
  • Cada capa debe tener una funcionalidad lo más específica posible y no compartida con las otras capas.
  • Cada capa debe interactuar, si corresponde, con las otras capas mediante una interfaz específica.
Pero hemos estado hablando de capas y quizá el lector no relaciona este concepto con el diseño de una aplicación. Para que quede claro, una aplicación normalmente se diseña con dos, tres o cuatro capas. La cantidad de capas depende de la complejidad de la aplicación y de elementos tan variables como el rendimiento, la seguridad, las comunicaciones, etc. Un diseño de tres capas, el más habitual, divide una aplicación en estos tres componentes:
  • Capa de presentación: es el conjunto de interfaces de usuario, todo lo que se muestra en pantalla. Es un código superespecializado en presentación de datos en pantalla, define la estética de la aplicación pero no interviene en la lógica de la aplicación.
  • Capa de reglas de negocio: es la capa de lógica, en donde se gestionan las reglas de negocio de la aplicación (cálculos, permisos de acceso, tablas de decisión, etc.). Es la capa que suele sufrir mayores modificaciones a lo largo del ciclo de vida de la aplicación.
  • Capa de acceso a los datos: es la capa que gestiona el acceso a las tablas de la base de datos de la aplicación y la ejecución de sentencias y procedimientos almacenados. Es un código superespecializado en el acceso a los datos pero con escasa lógica de aplicación (a veces mínima, dentro de los procedimientos almacenados).
La comunicación entre las capas se debe hacer mediante una interfaz precisa que indica que no se debe permitir el acceso directo a ninguna capa sin pasar por la capa de las reglas de negocio. De esta manera tendremos controlados (o más bien dicho, prohibidos) los accesos directos a la base de datos desde la capa de presentación sin pasar por las reglas de negocio. De la misma manera, todo lo que se muestre en pantalla en la capa de presentación debe provenir de la capa de reglas de negocio. La capa de reglas de negocio contiene la lógica de la aplicación y por lo tanto es la que decide qué es lo que se muestra en pantalla, cómo se accede a los datos y quién puede hacerlo.

Capa de presentación

Es la capa visible de la aplicación y no hace falta decir que el éxito de una aplicación Web se debe en gran parte al diseño de la interfaz de usuario. Obviamente que una aplicación bien presentada pero con tiempos de espera inadmisibles está destinada al fracaso. En el diseño de aplicaciones todas las capas tienen gran importancia y todas deben realizar su función de modo efectivo. Dicho esto, se debe también en cuenta que el efecto de la presentación puede hacer que un navegante se quede en un sitio Web o que salga disparado hacia otro sitio sin ni siquiera valorar el espléndido tiempo de respuesta que tiene una aplicación que espanta por su mala presentación. 
 

 

Se suele decir que no hay una segunda oportunidad para dar una buena primera impresión. Aquí también vale.

En una aplicación ASP.NET la interfaz de usuario está compuesta por un conjunto de páginas (extensión .aspx) que se muestra en un entorno de un navegador utilizando HTML estándar. El diseño de las páginas y la navegación entre una y otra son los dos aspectos fundamentales de esta capa. 

El estándar HTML cuenta con un reducido grupo de controles:
  • Botones
  • Botones de opciones 
  • Cuadro de verificación
  • Cuadros de texto
  • Listas desplegables
No obstante, ASP.NET nos permite una gran variedad de controles.
 
¿Cómo hace ASP.NET para ofrecer esta variedad y a la vez ser compatible con HTML clásico? 
 
La respuesta es simple: ASP.NET realiza un trabajo que nos resulta transparente y cuando debe presentar uno de sus controles especializados (por ejemplo, un control GridView) realiza una conversión interna para mostrarlo en el navegador a partir de una combinación de controles básicos HTML o de elementos de formato de HTML como lo son las tablas.
Un control ASP.NET se presenta en el navegador como una combinación de controles HTML y de elementos de formateo HTML.
El diseño de una interfaz no es un tema trivial ni mucho menos. No existen reglas fijas para un diseño pero se debe intentar no hacer que otro tenga que hacer lo que no nos gusta que nos hagan hacer. La experiencia de navegación por sitios Web nos va enriqueciendo con las distintas soluciones que nos encontramos. Seguro que ninguna cumple exactamente con los requisitos de nuestra aplicación, pero es muy probable que ese aprendizaje nos servirá para lograr un diseño y una navegación adecuados. 
En ASP.NET la capa de presentación está definida físicamente en los archivos aspx.

Diseño de navegación antes que diseño de página

Antes de abordar el detalle del diseño de una página de una aplicación tenemos que tener muy clara la navegación del sitio. ¿Cómo se llega a esa página? ¿Adónde se va desde esa página? ¿Qué datos tenemos acumulados de la navegación previa? 
 
Por estos motivos el primer paso del diseño de la capa de presentación es el diagrama de navegación del sitio. El diagrama es una estructura jerárquica que indica el punto de entrada al sitio (la página de inicio) y las conexiones posibles entre las distintas páginas. Esto no quiere decir que este mapa luego no pueda modificarse. Raro sería que no. Pero la definición del mapa de navegación es un paso fundamental para la creación de una aplicación Web ya que nos clarifica cómo presentaremos las distintas funcionalidades de la aplicación.

No hay recomendaciones de diseño 

Se suele decir que no hay reglas fijas o simples para el diseño de las interfaces de usuario pero eso no es cierto; hay algunos errores que no podemos cometerlos:
  • No todos los usuarios tienen un ordenador de última generación ni una línea ADSL de 20 MB ni tienen un monitor de 20 pulgadas: por lo tanto, se recomienda no cargar excesiva e injustificadamente  las páginas con imágenes ya que el rendimiento quedará penalizado.
  • No todos los usuarios son hábiles expertos en el uso de los ordenadores: diseñar para el usuario promedio de nuestro abanico de usuarios potenciales.
  • Probar y revisar la interfaz de usuario con personas que tengan un perfil similar al del usuario final real.
  • Las acciones que pueden realizar los usuarios son totalmente imprevisibles. No se debe dar por segura ninguna secuencia de páginas. Lo único cierto es la página que nos llega a la aplicación ya que la navegación se puede interrumpir por mil motivos.
  • El uso de las páginas se debe explicar por sí sólo con opciones claras y precisas. 

Capa de lógica o reglas de negocio

En esta capa se encierra toda la lógica de la aplicación. En esta capa se decide, entre otras cosas, quién puede usar la aplicación y qué puede hacer cada usuario o cada tipo de usuario. En esta capa, por ejemplo, se resuelve mediante código la respuesta a este tipo de interrogantes:
  • ¿Qué hago si el cliente ya no tiene crédito?
  • ¿Qué descuento se le aplica al comprador?
  • ¿Qué tiempo de entrega se informa al comprador?
  • ¿Qué medios de pago se permiten para esta operación?
  • ¿Qué texto se utiliza para informar que la operación ha finalizado correctamente?
  • ¿Qué opciones de menú se muestran en una situación determinada?
 Y así una larga lista de decisiones. 
 
 El criterio fundamental para crear las reglas de negocio sin complicar el programa tiene dos pautas:
  • Identificar cuando algo es una regla de negocio
  • Aislar la codificación de la regla de negocio en un módulo independiente del resto (una clase, un método de una clase, un módulo) para que sea fácilmente modificable sin que afecte al resto del código.

¿Por qué conviene resolver de un modo independiente una regla de negocio?

Porque lo más probable es que esa regla de negocio se utilice en varias partes de una aplicación o en varias aplicaciones. Si la tratamos con una clase específica o con un módulo o una función con sólo modificar en un único sitio habremos resuelto el problema en todas las aplicaciones que la utilizan (después de recompilar)  y sólo habrá una única interpretación de la regla de negocio.

Capa de datos

La tarea de desarrollo de la capa de datos comienza muy temprano en el diseño de la aplicación con la creación de la base de datos. Obviamente, antes de crear la base de datos tenemos que haber decidido qué sistema de gestión de bases de datos se utilizará (SQL Server, Access, Oracle, MySQL, etc.).
Generalmente la decisión del servidor de bases de datos viene impuesta por el entorno del servidor de Internet o por el tipo de servidor que ha elegido nuestra empresa. El desarrollador normalmente se adapta al tipo de base de datos elegida por la empresa. En términos generales las bases de datos de tipo empresarial tienen las mismas funcionalidades aunque haya diferencias en la codificación.
 
El segundo paso después de la creación de la base de datos es la creación de las tablas que la componen y la definición de las columnas que integran cada tabla.  
 
Más adelante, en la fase de implementación, tendremos que definir cómo accederemos a la base de datos; es decir, que clase de instrucciones utilizaremos para los accesos a la base de datos. Podemos hacerlo con distintas alternativas de código que tienen sus propias características (nos encontraremos seguramente que una alternativa tiene mejor rendimiento pero es menos portable a otro tipo de base de datos, otra alternativa que es exactamente lo contrario, una es fácil de codificar pero no tiene buen rendimiento, otra es más compleja pero tiene mejor rendimiento, etc.). Aunque al inicio se puede tener una idea preconcebida del mecanismo elegido para acceder a los datos, estas decisiones se terminan tomando o ajustando en una fase más avanzada del proyecto.
Si la base de datos está bien diseñada la aplicación parecerá que es mucho más simple, clara y lógica.  El tiempo invertido en un buen diseño se recupera con creces en la implementación de la aplicación. 
 
La tarea de diseño de una base de datos puede describirse con una secuencia bastante definida de pasos pero cuando se hayan realizado varios diseños y se haya ganado experiencia se verá que el proceso nos saldrá casi naturalmente.
  1. PASO 1: Descubrimiento de las entidades de nuestra aplicación: dicho en otros términos, qué tablas necesito en mi base de datos.
  2. PASO 2: Definición de las propiedades de las entidades: es decir, qué columnas debe tener cada tabla.
  3. PASO 3: Análisis y definición de las relaciones entre las tablas.
  4. PASO 4: Normalización de la base de datos.
  5. PASO 5: Desnormalización de la base de datos.
Antes de pasar a describir una metodología para realizar estas tareas debemos tener en cuenta que existen herramientas que nos pueden asistir en este proceso.

Diseño de base de datos relacionales

Las bases de datos bien diseñadas nos ayudarán a que el código de nuestros programas sea claro y simple. Pero es fundamental que diseñemos correctamente la base de datos porque en caso contrario después la implantación resultará mucho más compleja y poco eficiente, y no siempre resulta sencillo corregir posteriormente los errores estructurales. 
Existen muchas herramientas que nos ayudarán en la tarea de diseño de bases de datos. No obstante, aunque estas herramientas son excelentes, es preciso que el diseñador domine las estructuras de las bases de datos relacionales para aprovechar plenamente las funcionalidades que brindan estas herramientas. Aquí se presentan algunas de las herramientas disponibles:
  • Visible Analyst® DB Engineer.
  • ICT WizERD.
  • Erwin.
Una premisa que se debe recordar siempre: si comparamos el desarrollo de aplicaciones con la construcción de un edificio podríamos decir que la etapa de diseño de la base de datos es equiparable a la construcción de los cimientos del edificio; un mal diseño de la base de datos nos hará generar un código confuso, ineficiente y propenso a los errores e impedirá el crecimiento de la aplicación.
izq sup der

Deja un comentario