Escribir un programa orientado a objetos (I)

Se trata de una serie de artículos prácticos para crear un primer Programa Orientado a Objetos con Visual Basic .Net se comienza con un programa sencillo y se le van añadiendo complejidad con nuevos elementos.

Con este artículo aprenderemos a:

Decidir las clases que debe tener el programa.

Crear una clase con variables, propiedades y métodos.


Los bloques principales de un programa orientado a objetos son las clases, un objeto es una ocurrencia concreta de una clase (un coche concreto es una ocurrencia concreta de la clase coche genérica). Un objeto al ser concreto toma atributos concretos definidos en sus propiedades (en un coche sería el color, modelo, etc.) y métodos que son las acciones que tienen permitido hacer (en un coche los métodos serían acelerar, frenar, girar).


Diseñaremos e implementaremos las clases usando propiedades y métodos. A continuación, declararemos e inicializaremos las variables de las clases. Por último, implementaremos una solución llamando a los métodos, propiedades y a las variables de la clase.

Hospital: Un primer Programa Orientado a Objetos

En la construcción de un sistema de información para el control hospitalario se revelaron los siguientes conceptos:

- Hospital: con los datos, Nombre, Dirección y Teléfono

- Sala: con los datos, Número y Cantidad de camas

- Médico: con los datos, Identidad, Nombre y Especialidad

- Paciente: con los datos, Identidad, Nombre, Dirección y Fecha de nacimiento.

Por otra parte, las relaciones reveladas entre dichos conceptos son:

-Cada hospital tiene varias salas. Todas y cada una de ellas pertenecen a un hospital (y sólo a uno).

-Cada médico trabaja en un único hospital, todo hospital tiene al menos 10 médicos.

-Un paciente puede estar internado; si lo está, estará en una sala y sólo en una.

-La capacidad máxima de camas que puede tener una sala es de cinco pacientes.

-Cada paciente puede ser atendido por más de un médico (pero por lo menos por uno) y a su vez un médico puede atender a varios pacientes.

Se trata de implementar un programa que permita la gestión de un grupo de hospitales.

El programa tendría varias pestañas para añadir/cambiar/eliminar los datos correspondientes, la pestaña paciente sería la más compleja y sería de este tipo:

SQL Server: restaurar una base de datos a partir de una copia de seguridad

Esto es un pequeño manual de cómo hacer con SQL Server una copia de seguridad de una Base de Datos y cómo restaurarla sobre otra machacándola (si queremos que sea nueva, la creamos vacía y machacamos sobre ella).

Antes de nada hacemos una copia de seguridad de la Base de Datos que posteriomente restauraremos.

Hacer una copia de seguridad

En primer lugar elegimos la base de datos de la que realizaremos la copia de seguridad.

Sobre ella, botón derecho del ratón…-> Back Up.

Curso de diseño de bases de datos relacionales

Con la última entrada se completa un curso básico de diseño de Bases de Datos relacionales, los primeros pasos son teóricos y los últimos son prácticos y se ejecutan en SQL Server.

El curso queda del siguiente modo:

1-     Explicación del modelo ER con un ejemplo práctico de cómo adaptar un enunciado para convertirlo en un modelo Entidad-Relacción.

2-     Cómo pasar del modelo ER a un modelo relacional para que sea más fácil adaptarlo a Bases de Datos Relacionales como SQL Server.

3-     Teoría de la normalización y formas normales explica cómo optimizar  y normalizar el diseño de la base de datos para evitar problemas de referencias entre otros, en Bases de Datos mal diseñadas.  Y se explican las diferentes formas normales. Continuando con el ejemplo sencillo del primer capítulo se expone cómo  adaptarlo a las formas normales.

4-     Finalmente se explica de forma práctica cómo crear las tablas y sus respectivas Claves y Foreing Keys a través de los menús de la aplicación SQL Management Studio de SQL Server o directamente a través de un script. 

Crear una tabla en SQL Server 2005

Esto es un pequeño manual de cómo crear en SQL Server  Tablas y asignarle las Claves y las Foreing Keys correspondientes, al final viene un script para crear una tabla mediante código.

Para generar la tabla.

 
 Y luego elegimos del nombre de la tabla

 Para poner claves.

 Elegimos el campo clave y pulsamos

 Con lo que queda

 Si queremos que la clave sean varios campos, selecionamos los campos deseados y pulsamos.

 Para crear una foreing Key simple.

 Nos abre el diálogo

 Pulsamos Add y luego el botón
 Con lo que sale

Pulsamos OK y ya tenemos nuestra Foreing Key, cerramos con close.

 Para crear una foreing Key complejo.

Aparecen dos colunnas, si intentamos dar al OK nos da un mensaje de error del tipo

Para evitar esto, hay que elegir la columna que se quiere relacionar y poner  <none> en las que no corresponda la relación

Ahora si deja crear la relación.

Generación mediante scripts

Para generar las tablas, sus claves y foreing keys se puede hacer por código del siguiente modo:

USE [model]

GO

/****** Object:  Table [dbo].[tbAtiende]    Script Date: 08/30/2011 10:55:59 ******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

SET ANSI_PADDING ON

GO

CREATE TABLE [dbo].[tbAtiende](

      [intID] [tinyint] IDENTITY(1,1) NOT NULL,

      [strID_MED] [char](5) NOT NULL,

      [strID_PAC] [char](5) NOT NULL,

 CONSTRAINT [PK_tbAtiende] PRIMARY KEY CLUSTERED

(

      [strID_MED] ASC,

      [strID_PAC] ASC

)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

Formas normales (ejemplo)

EJEMPLO SENCILLO

A Continuación un ejemplo sencillo de aplicación de las formas normales al diseño de una base de Datos relacional. Basado en el esquema de base de datos obtenido en el  punto anterior que era el siguiente:

Ahora vamos a continuar con el desarrollo del modelo adaptándolo para que cumpla las formas normales.

En Rojo la clave primaria.

En Azul las claves  ajenas

Paso a primera forma normal

Tabla: tbMedico (strId_MED, strId_HOS,  strNombre, strEspecialidad,)

Un médico puede pertenecer a varias especialidades o a varios hospitales por lo que

pasaría a descomponerse en :

tbMedico (strId_MED, strNombre)

tbMedHos(strId_MED, strId_HOS)

tbMedEsp(strId_MED, strEspecialidad)

Tabla: tbAtiende(strId_MED, strId_PAC)  está en 1FN

Tabla: tbPaciente(strId_PAC, strID_SAL, strId_HOS, strNombre, strDirección, dat_FecNacimiento)

Si consideramos que un paciente solo tiene una dirección válida y sólo puede tener asignada una sala, esta tabla estaría en 1FN.

Tabla: tbSala (strId_SAL, strId_HOS, intCamas,)  está en 1FN.

Tabla: tbHospital(strId_HOS, strNombre, strDireccion, strTelefono)

Para que el hospital pueda tener diversos números de teléfono se deja como:

tbHospital(strId_HOS, strNombre, strDireccion)

tbHospTel (strId_HOS, strTelefono)  No se contempla un listín telefónico por departamentos.

Paso a segunda forma Normal

En este ejemplo no se da ningún caso que esté en 1FN y no esté en 2FN por lo que podemos reordenar las claves dejándolo así.

tbMedico (strId_MED, strNombre)

tbMedEsp (strId_MED, strEspecialidad)

tbMedHos (strId_MED, strId_HOS)

tbAtiende (strId_MED, strId_PAC) 

 tbSala (strId_SAL, strId_HOS, intCamas,) 

tbPaciente (strId_PAC , strID_SAL, , strId_HOS, strNombre, strDirección, dat_FecNacimiento)

Que al tener sólo una clave primaria, está en 2FN.

tbHospital (strId_HOS, strNombre, strDireccion)

tbHospTel (strId_HOS, strTelefono) 

Paso a tercera forma Normal

El campo strEspecialidad de tbMedEsp depende transitivamente de strID_MED por tanto se sustituye por el código de la especialidad y se crea una nueva tabla tbEspecialidades

tbMedico (strId_MED, strNombre)

tbMedEsp (strId_MED, strId_ESP)

tbEspecialidades (strId_ESP, strEspecialidad)

Como en tbSala (strId_SAL, strId_HOS, intCamas)  strID_HOS no depende de la Sala,

sacamos la relación a una tabla auxiliar. Quedando:

tbSala (strId_SAL, intCamas) 

tbSalaHos (strId_SAL, strId_HOS) 

Repitiendo la misma operación con tbPaciente nos queda

tbPaciente (strId_PAC , strNombre, strDirección, dat_FecNacimiento)

tbPacSala (strId_PAC , strID_SAL)  Con esta información y la de tbSalaHos queda definido el hospital asignado al paciente.

Al no hacer claves complejas, llegados a este punto, también cumplen las FNCB formas normales por lo que finalmente tenemos:

SQL Server: La importancia de elegir la instrucción correcta

Diferentes instrucciones de  SQL Server que aparentemente tienen el mismo resultado en realidad muestran diferentes resultados incluso pueden generar errores. Lo veremos más claro con un ejemplo.

Enunciado  del ejemplo:
Dado un campo1 de tipo smallint, se desea que tome valor 1 para todos los valores del campo2 de tipo varchar que comiencen por 2 excepto para los que comiencen por 23 que tomará valor cero. el resto de ocurrencias es indiferente.

--estas dos select devuelven el mismo resultado

SELECT * FROM tabla WHERE substring(campo2,1,1) = 2
SELECT * FROM tabla WHERE campo2 like '2%'

Estas dos líneas de instrucciones realizan la operación solicitada. 
--Esta solución es correcta, pero si el campo varchar contiene letras dará un error de conversión de tipos.
UPDATE tabla SET campo1 = 1 WHERE substring(campo2,1,1) = 2
UPDATE tabla SET campo1 = 0 WHERE substring(campo2,1,2) = 23

Estas dos líneas de abajo realizan el mismo trabajo que las anteriores pero son más robustas frente a fallos.

--Esta solución es más correcta pues hace lo mismo que la anterior y aunque el campo varchar contenga letras, no falla.
UPDATE tabla SET campo1 = 1 WHERE campo2 like '2%'
UPDATE tabla SET campo1 = 0 WHERE campo2 like '23%'

Esto pone de manifiesto que a la hora de hacer una instrucción de SQL no sólo basta con que sea correcta, hay que tener en cuenta los posibles fallos, en este caso de conversión de tipos de un campo varchar que toma valores numéricos (pero puede que no lo haga) pues al ser varchar es legal que un campo venga como 'C2000' y en ese caso el primer UPDATE falla.