Sie sind auf Seite 1von 15

Diseo de datos

El diseo de datos consiste en descubrir y la definir completamente de los procesos y


caractersticas de los datos de la aplicacin. El diseo de datos es un proceso de
perfeccionamiento gradual que abarca desde la cuestin ms elemental, "Qu datos
requiere la aplicacin?", hasta los procesos y estructuras de datos precisos que
proporcionan dichos datos. Si el diseo de datos es bueno, el acceso a los datos de la
aplicacin ser rpido y fcil de mantener, y podr aceptar sin problemas las futuras
mejoras de los datos.
El proceso de diseo de datos incluye la identificacin de los mismos, la definicin de
tipos de datos y mecanismos de almacenamiento concretos, y la tarea de garantizar la
integridad de los datos mediante el uso de reglas de empresa y otros mecanismos de
exigencia en tiempo de ejecucin.
Esta seccin no constituye una metodologa formal para modelar datos, aunque utiliza
terminologa relacional. Ms bien, presenta algunos conceptos y procesos que surgen
normalmente durante el diseo de los datos de la aplicacin.
Este tema no realiza suposiciones sobre la tecnologa ocasional de almacenamiento de
datos utilizada para almacenar y recuperar los datos de la aplicacin. Despus de todo,
no siempre se puede determinar con precisin, al principio del diseo de una aplicacin,
cmo y cundo se van a almacenar los datos exactamente. Aunque la mayora de las
metodologas formales de modelado de datos prevn el uso de un motor de base de
datos relacional, una aplicacin empresarial tiene muchas opciones para almacenar los
datos, incluidos los archivos relacionales, jerrquicos de gran sistema y VSAM, los
archivos AS/400, y otras muchas estructuras de datos distribuidas de archivos.

Identificacin de datos
Los datos constituyen un recurso de informacin real importante para la aplicacin. Los
datos describen cosas, personas, productos, elementos, clientes, activos, registros y, en
ltimo trmino, estructuras de datos que son tiles para la aplicacin a la hora de
realizar tareas de clasificacin por categoras, organizacin y mantenimiento.
La identificacin de datos es un proceso iterativo. Al principio, es posible que slo
disponga de alguna informacin imprecisa y de alto nivel sobre la forma en que la
aplicacin debe de controlar su propia informacin. A medida que vaya adquiriendo
ms conocimientos sobre los procesos de empresa previstos de la aplicacin, seguir
recopilando ms detalles.
Cuando se empieza a documentar los requisitos de los datos de la aplicacin, la
descripcin de cada uno de los datos incluye normalmente los siguientes elementos:

Nombre.
Descripcin general (qu es).
Propiedad (quin es el responsable).
Caractersticas (cmo se mide y qu magnitud puede tener).

Relaciones, procesos y eventos lgicos (cmo y cundo se crea, modifica y


utiliza).

Conviene sealar que los datos tienen muchas caractersticas diferentes. Una parte del
proceso de diseo de datos consiste en especificar cmo se cuantifica cada uno de los
datos. Algunas caractersticas tpicas de los datos son las siguientes:

Atributos de ubicacin (direccin, pas, lugar de almacenamiento).


Atributos fsicos (peso, dimensiones, volumen, color, material, textura).
Atributos conceptuales (nombre, categora, nmero de serie).
Atributos relacionales (conjuntos formados por subconjuntos, escritores de
varios libros).
Atributos de valor (moneda, disposicin, consideracin).

El proceso de identificacin de datos requiere la realizacin de entrevistas, anlisis de


estructuras de datos existentes, preparacin de documentos y revisiones minuciosas. El
resultado eventual es una perspectiva conceptual y documentada de la informacin de la
aplicacin que responde a las preguntas sobre datos relativas a "qu, dnde, cundo y
por qu". Generalmente, se trata de un estudio preliminar de la forma en la que los
distintos departamentos y organizaciones, y la aplicacin, tienen que utilizar los datos.

Definicin de datos
A medida que vaya adquiriendo ms conocimientos sobre las estructuras de datos de la
aplicacin, podr agrupar definitivamente los datos seleccionados y asignar informacin
detallada que describa las caractersticas de los datos y las relaciones entre ellos.
El mtodo general de definicin de datos incluye las siguientes acciones:

Definirtablas,filasycolumnas.
Insertarclavesdendice.
Crearrelacionesentretablas.
Asignartiposdedatos.

Definir tablas, filas y columnas

Con independencia de la forma en que los datos de la aplicacin se almacenen


fsicamente, stos se organizan normalmente en varias tablas (o archivos), cada una de
ellas formada por conjunto de filas (o registros) y columnas (o campos), del mismo
modo que las filas y columnas de una hoja de clculo. Cada fila de la tabla contiene toda
la informacin relativa a una cosa, persona, producto, elemento, cliente o activo en
particular.
Por ejemplo, la tabla Authors siguiente almacena el nombre, la direccin y el nmero de
telfono de varios autores.
Fila

Nombre

Direccin

Telfono

AndrsDelValle xxxxxxxxxxxxx

(xxx)xxxxxxx

CarlosGarca

xxxxxxxxxxxxx

(xxx)xxxxxxx

IsabelDaz

xxxxxxxxxxxxx

(xxx)xxxxxxx

BernardoRamrez xxxxxxxxxxxxx

(xxx)xxxxxxx

Insertar claves de ndice

Una clave es un campo especial que proporciona un ndice para que la recuperacin de
datos sea rpida. Las claves pueden ser nicas o no nicas, en funcin de que se
permitan o no duplicados. Es posible determinar que una clave sea la clave principal,
convirtindose as en el nico identificador de cada fila de la tabla. Debera utilizar
claves cuando la aplicacin necesite tener acceso directo a filas especficas.
Por ejemplo, en la siguiente tabla, el nmero de identificacin del autor (id_au) se ha
agregado como clave principal de la tabla, de forma que identifica slo a un autor. Si en
una consulta se utiliza un valor para id_au, la recuperacin de la informacin
correspondiente a ese autor ser ms rpida.
TablaAuthors
id_au(clave)
nombre_au
direccin_au
telfono_au
Crear relaciones entre tablas

Una base de datos suele estar formada por varias tablas, y stas suelen estar
relacionadas entre s de varias formas y utilizan claves externas con frecuencia. Por
ejemplo, una tabla denominada Titles podra contener el ISBN, el ttulo y el ao en que
se public el libro. Tambin podra ser til identificar la editorial de cada ttulo. En
lugar de repetir toda la informacin sobre la editorial de cada ttulo en la tabla Titles, se
puede crear una tabla Publishers y establecer una relacin entre esta ltima y la tabla
Titles, de forma que la identificacin de la editorial (id_edit) de la tabla Titles sea una
clave externa.
En el ejemplo siguiente, la tabla Publishers est relacionada con la tabla Titles:
TablaTitles

TablaPublishers

isbn_ti(clave)

id_edit(clave)

ttulo_ti

nombre_edit

aopublic_ti

dir_edit

id_edit(claveexterna) telfono_edit

Esta relacin se denomina de uno a varios ya que slo una fila de la tabla Publishers se
puede relacionar con una o ms filas de la tabla Titles (un editor puede encargarse de
varios ttulos). Tambin se pueden crear relaciones de uno a uno y de varios a varios.
Es importante que vea que tan solo ha identificado que existe una relacin entre las
tablas Publishers y Titles, sin establecer ningn compromiso sobre cmo se va a
administrar esta relacin. Segn la implementacin final, puede usar las uniones de
tablas y las restricciones de claves externas incluidas en SQL Server, o puede escribir su
propio cdigo para leer las estructuras del archivo directamente y manipular la
integridad referencial dentro de la aplicacin.
Asignar tipos de datos

Un tipo de datos es una categora de datos con nombre que se distingue por un conjunto
de valores, una forma de indicar dichos valores y una serie de operaciones implcitas
que pueden interpretar y manipular los valores. Los tipos de datos pueden ser
intrnsecos o derivados.
Los tipos de datos intrnsecos son los que proporciona la propia base de datos. Por
ejemplo, SQL Server proporciona tipos de datos intrnsecos como integer, datetime, bit,
char y varchar.
Los tipos de datos derivados se definen utilizando el lenguaje de modelado de datos
(DML) que proporciona la base de datos. Los tipos de datos derivados se crean a partir
de tipos de datos intrnsecos o de tipos de datos derivados anteriormente definidos. Lo
normal es que se proporcione un nombre y una estructura al tipo de datos derivado. Los
tipos de datos derivados garantizan un uso coherente de tipos de datos especiales para
columnas, variables y parmetros seleccionados.
Es importante utilizar tipos de datos para asegurarse de que cualquier valor de datos
asignado es del tipo correcto y est dentro del intervalo de valores admisible. Las
diversas tecnologas de almacenamiento de datos y lenguajes de programacin admiten
distintos tipos de datos, entre los que se incluyen los siguientes:

Boolean.
Integer.
Float.
Datetime.
Tinyint.
DISPLAY.
COMP3.

Binary.
String.
Character.

Cuando se asignan tipos de datos, hay que asegurarse de que el intervalo proporcionado
por el tipo de datos se ajuste a los datos que se almacenarn y, si es posible, anticipe
cambios futuros. Por ejemplo, si se elige el tipo de datos tinyint para la identificacin de
un cliente, la aplicacin podr manejar un nmero mximo de 255 clientes. Sin
embargo, si se elige el tipo de datos integer, podr tener un nmero superior a dos mil
millones de clientes. Otro ejemplo: si utiliza un nico carcter para indicar el cdigo de
servicio de clientes, una ampliacin posterior a dos caracteres requerir cambios
complicados en la aplicacin.
Se puede ahorrar espacio en la base de datos y se pueden mejorar las operaciones de
combinacin eligiendo tipos de datos apropiados para los distintos campos. Como
norma general, se debe elegir el tipo de datos ms pequeo posible que se adecue a los
datos del campo.
A la hora de asignar tipos de datos, se deben tener en cuenta los siguientes puntos:

Valoresmximoymnimopermitidos.
Valorespredeterminados.
Valoresvacos(oNULL).
Crecimientoprevisto.
Cambiosprevistoseimprevistos(enlamedidadeloposible).

En un entorno de bases de datos relacionales, los tipos de datos ayudan a exigir las
reglas de empresa. Por ejemplo, no se pueden unir dlares y colores y obtener una
respuesta til. Aunque es prcticamente imposible que lleve a realice intencionadamente
un proceso de adicin como el anterior, una base de datos relacional identificar la
incoherencia de los tipos de datos y rechazar automticamente la consulta.
Si utiliza bases de datos de SQL Server o de Oracle, podr definir las tablas, filas,
columnas, claves y tipos de datos con Visual Database Tools.

Integridad de datos
La integridad de datos se refiere a los valores reales que se almacenan y se utilizan en
las estructuras de datos de la aplicacin. La aplicacin debe ejercer un control
deliberado sobre todos los procesos que utilicen los datos para garantizar la correccin
permanente de la informacin.
Es posible garantizar la integridad de los datos mediante la implementacin escrupulosa
de varios conceptos clave, como los que se incluyen a continuacin:

Normalizar datos.
Definir reglas de empresa.
Proporcionar integridad referencial.
Validar los datos.

En las secciones que se especifican a continuacin se describen algunos medios


importantes que permiten garantizar la integridad de los datos de la aplicacin.

Normalizacin de datos
La tarea de un diseador de bases de datos consiste en estructurar los datos de forma
que se eliminen duplicaciones innecesarias y se proporcione una ruta de bsqueda
rpida para toda la informacin necesaria. El proceso de perfeccionar tablas, claves,
columnas y relaciones para crear una base de datos eficaz se denomina normalizacin.
La normalizacin no slo es aplicable a archivos relacionales; tambin es una actividad
de diseo comn para archivos indizados.
Es un proceso complejo formado por muchas reglas especficas y distintos niveles de
intensidad. La definicin completa de normalizacin es el proceso de descartar la
repeticin de grupos, minimizar la redundancia, eliminar claves compuestas para la
dependencia parcial y separar los atributos que no sean de la clave. En trminos
generales, las reglas de normalizacin se pueden resumir en una sola frase: "Cada
atributo (columna) debe ser una realidad de la clave, toda la clave y nada ms que la
clave". Cada tabla debe describir slo un tipo de entidad (como una persona, un lugar,
un pedido de cliente o un producto).
A continuacin se enumeran algunas de las ventajas de la normalizacin:

Integridad de datos (porque no hay datos redundantes ni omitidos).


Consultas optimizadas (porque las tablas normalizadas generan combinaciones
eficaces y rpidas).
Creacin y ordenacin de ndices ms rpidas (porque las tablas tienen menos
columnas).
Ejecucin ms rpida de la instruccin UPDATE (porque hay menos ndices por
tabla).
Resolucin de concurrencias mejorada (porque los bloqueos de tabla afectarn a
menos datos).

La mayora de las bases de datos simples se puede normalizar siguiendo una simple
regla emprica: las tablas que contienen informacin repetida deben dividirse en tablas
independientes para eliminar la duplicacin.
Por ejemplo, puede crear una nueva aplicacin para un librero que realice un
seguimiento de cada libro, e incluya los datos siguientes.

Nombre del autor.


Direccin del autor.
Nmero de telfono del autor.
Ttulo.
Nmero ISBN.
Ao de publicacin.
Nombre de la editorial.
Direccin de la editorial.
Nmero de telfono de la editorial.

Es posible crear una nica tabla con un campo para cada uno de los elementos de
informacin enumerados anteriormente. No obstante, si se examinan los datos
detenidamente, es evidente que una tabla con estas caractersticas contendra numerosas
redundancias. Por ejemplo, como lo normal es que muchos autores hayan escrito ms de
un libro, la informacin correspondiente al autor y a la editorial de cada libro se
repetira muchas veces. Si todos estos campos se colocan en una nica tabla habr
muchas entradas duplicadas y confusas.
Sin embargo, de acuerdo con los principios de la normalizacin, los datos se podran
dividir en cuatro grupos: Authors, AuthorsTitles, Titles y Publishers, tal y como se
muestra en la siguiente tabla.
Tabla Authors Tabla AuthorsTitles
id_au (clave)
id_au (clave externa)
nombre_au
isbn_ti (clave externa)
direccin_au
telfono_au

Tabla Titles
isbn_ti (clave)
ttulo_ti
aopublic_ti
id_edit (clave
externa)

Tabla Publishers
id_edit (clave)
nombre_edit
dir_edit
telfono_edit

Las claves proporcionan una forma de establecer relaciones entre tablas. Por ejemplo, la
tabla AuthorsTitles crea una relacin varios a varios entre las tablas Authors y Titles (un
autor puede haber escrito muchos libros y un libro puede haber sido escrito por varios
autores). Con la tabla AuthorsTitles, se pueden realizar consultas de los nmeros de
libros escritos por un autor (utilizando id_au), as como determinar qu autor o autores
han escrito un libro determinado (utilizando isbn_ti).
Conviene sealar que, en lugar de crear la tabla AuthorsTitles, otra alternativa sera
agregar el atributo id_au en la tabla Titles, pero esta opcin slo es viable en el supuesto
de que cada libro tenga un nico autor. Observemos con ms detenimiento otra
interpretacin: la colocacin del atributo id_edit en la tabla Titles sugiere que cada ttulo
pertenece a una sola editorial. Si varias editoriales publican el mismo ttulo, la insercin
de ms filas Ttulo en la tabla Titles para cada editorial dara lugar a una duplicacin de
datos y, por lo tanto, la tabla no estara normalizada. Estas alternativas de diseo
requieren una evaluacin minuciosa de los puntos siguientes: significado de los datos de
empresa, tipos de consultas previstos en la aplicacin, posibles conflictos durante el uso
simultneo de varios usuarios y posibles problemas de rendimiento derivados de la
existencia de muchos ndices en una tabla.
Si se evala la normalizacin de otras alternativas de diseo, es conveniente conocer la
existencia de diversas tcnicas que se pueden utilizar para desnormalizar una base de
datos de forma intencionada. Cundo se puede dar este caso?. Podra desnormalizar los
datos intencionadamente en el caso de que se detectasen problemas de rendimiento o,
simplemente, desease simplificar el proceso de generacin de informes apropiados. Los
problemas de rendimiento se derivan de las consultas de produccin que requieren
combinaciones con un uso intensivo del disco y de gran lentitud. El proceso de
generacin de informes con fines especficos consiste en la realizacin de consultas no
estructuradas por parte de los usuarios finales; puede que estos usuarios no tengan la
formacin adecuada y tengan inseguridad a la hora de obtener informacin de varias
tablas relacionadas.

Las tcnicas de desnormalizacin existentes consisten en duplicar datos, proporcionar


informacin de resumen, dividir tablas en particiones horizontales o verticales y crear
vistas sin normalizar para simplificar el proceso de generacin de informes; una
alternativa inteligente que permite dejar intacta la base de datos normalizada.
Un ejemplo de desnormalizacin sera el caso de las direcciones de los clientes. Una
tabla de clientes suele incluir estos atributos: nombre, calle, ciudad, estado y cdigo
postal. Bien es cierto que la ciudad y el estado se pueden deducir a partir del cdigo
postal, por lo tanto, se podra normalizar la tabla de clientes eliminando la ciudad y el
estado de los datos de cada cliente; sin embargo, es una prctica comn dejar la
direccin sin normalizar.
Hay varias razones que justifican esta accin:

Las direcciones se utilizan en muchos lugares (consultas, informes, sobres,


pantallas de servicio al cliente), y la desnormalizacin evita que se tenga que
agregar en la aplicacin una gran cantidad de cdigo para reconstruir las
direcciones.
Las consultas basadas en la direccin utilizan una sintaxis SQL mucho ms
sencilla.
Los errores en las direcciones se limitan a clientes individuales.

Reglas de empresa para el acceso a datos


Se pueden utilizar reglas de empresa para controlar de forma coherente y correcta el
acceso a datos de la aplicacin. O mejor todava, otras aplicaciones podran utilizar las
mismas reglas de empresa y as beneficiarse de las relaciones y dependencias de
procesos integradas que se hayan creado. En general, las reglas de empresa que
controlan el acceso a datos deben disearse con detenimiento con el fin de que
proporcionen procesos independientes pero perfectamente coordinados.
Elegir la forma de exigir las reglas de empresa

Al definir las reglas de empresa para tener acceso a los datos, se eligen los mecanismos
en tiempo de ejecucin que la aplicacin utilizar para exigir las reglas aplicables a los
datos. En principio, hay que determinar el servicio o componente que debe exigir la
regla y la forma exacta en que se implementar dicha regla. A la hora de tomar esta
determinacin deben considerarse varios puntos:

QumecanismosdeexigenciaestndisponiblesElsistemadeadministracinde
basesdedatos(DBMS),elcdigodelosserviciosdelaaplicacinoloscomponentes
deinterfazdeusuariocomoformulariosWindowsFormsoWebFormspuedenexigir
lasreglas.Enelsistemadeadministracindebasesdedatos,unareglasepuedeexigir
contiposdedatos,restricciones,desencadenadoresoprocedimientosalmacenados.
Enuncomponente,comounobjetocomercial,unareglasepuedeexigirmediante
programacinatravsdelcontroldeeventos(porejemplo,sepuedeexigirunaregla
cadavezquesedesencadeneeleventoRowChanged).Enuncomponentedeinterfaz
deusuariosepuedeexigirunareglamedianteprogramacinoatravsdelos
controlesdeinterfazdeusuarioquepuedencontrolarlaedicindedatoslocales.

Esdeseableunaexigenciaredundante?Aunquelaexigenciaredundantedeuna
reglapuedaparecerunaprdidadetiempo,nosedebedescartar.Porejemplo,se
podraelegirlaopcindeexigirunareglaenunformularioyenelsistemade
administracindebasesdedatos.Mediantelaexigenciadelareglaenelformulario,
semejoraelrendimientodelaoperacindeentradadedatos(evitandoasla
comunicacindeidayvueltaconlabasededatos).Mediantelaexigenciadelaregla
enelsistemadeadministracindebasesdedatos,segarantizaquetodoslosdatos
cumplanlaregla,ynoslolosdatosintroducidosatravsdelformularioencuestin.
Enunentornodeprogramacinqueexijarapidezycontinuaactividad,puedequeotro
programadorcreeunformularioquenoexijalaregla.Tambinesposiblequeun
usuariodebasesdedatosconexperienciayunaltogradodeprivilegiosutiliceSQL
parainsertarfilasdirectamenteenlabasededatos.Enunentornodeestas
caractersticas,laformamsfiabledegarantizarlacorreccindelosdatosesutilizarel
sistemadeadministracindebasesdedatosparaexigirlaregla.
ConqurigorsedebeexigirlareglaEsdecir,silareglarequiereunaexigencia
rigurosayconstanteosiesaceptableexigirlareglasloperidicamenteoslo
durantedeterminadasfasesdeunproceso.Porejemplo,unareglaqueexijaque"el
nmerodelastarjetasdecrditotenga16dgitos"podrarequerirunaexigencia
rigurosaporquelabasededatosnodebecontenerenningnmomentounnmerode
tarjetadecrditoincorrecto.

Por otro lado, una regla que exija que "las rdenes de compra deben tener una
direccin de envo" podra no requerir una imposicin continua. Una regla de
este tipo requerira una exigencia slo durante ciertos momentos del
procesamiento de rdenes. Por ejemplo, si el agente de ventas y el cliente
necesitan varios das para completar una orden de compra, a la espera de que el
cliente elija exactamente los productos que desea comprar, la orden de compra
puede permanecer incompleta en la base de datos durante esos das. Cuando se
completa la orden de compra y se transmite al departamento de envos, debe
tener una direccin de envo. No es preciso que se exija la regla que requiere una
direccin de envo durante las etapas previas del proceso de generacin de
rdenes.

CmoafectarlaexigenciaalrendimientoEltipoelegidodeexigenciadeunaregla
puedeafectaralconceptoqueseformeelusuariosobreelrendimientodela
aplicacin.Porejemplo,siexistelaposibilidaddequeunareglasloseexijaenun
formulariooenlabasededatos,esconvenienteelegirqueseexijaenelformulario
paraquelosusuariosnotenganqueesperarunacomunicacindeidayvueltaconla
basededatosantesdedescubrirseunerrortipogrfico,porejemplo.
CmoafectarlaexigenciaalacapacidaddemantenimientoUnaregla
especialmentecomplejapuedeimplementarsedeformaquetengaunfcil
mantenimiento.Esdecir,sepuedeelegirunmecanismodeimplementacinque
muestreunagranafinidadconlapropiaregla.Porejemplo,silareglacontrolalas
secuenciasdelastareasautomatizadasdelasolucindesoftware,sepuede
implementarenunlenguajequedispongademecanismosparainstruccionesCASEo
SWITCHcomplejas,yenunlenguajequedispongademecanismosparadesencadenar
eventosyresponderaellos.

Determinar las reglas de empresa

Una aplicacin requiere reglas de empresa para el acceso a los datos en cualquiera de
las siguientes circunstancias:

Insertar,actualizar,eliminaryverlosdatos.
Validarlosdatos.
Controlarlaseguridaddelosdatos.
Controlarelaccesoadatosdevariosarchivos.
Proporcionarintegridadreferencial.

Manipulacin de datos

Es posible utilizar una regla de empresa cada vez que la aplicacin inserta, actualiza,
elimina o ve datos. Las reglas de empresa implementadas de este modo proporcionan un
control conciso sobre los datos que se pueden actualizar y la forma de actualizarlos. Por
ejemplo, si la aplicacin inserta nuevas rdenes de venta al archivo de facturas, una
regla de empresa debera comprobar automticamente el lmite de crdito del cliente
antes de aceptar e insertar los elementos de la lnea de rdenes de venta.
Validar datos

La validacin de datos es el proceso de comprobacin de los valores de los campos (por


ejemplo, si el campo numrico lo es realmente y si est dentro del intervalo) y de
validacin de los valores de archivos relacionados (por ejemplo, si la identificacin de
una editorial existe en el archivo Editoriales). Si todas las rutinas de validacin de datos
se colocan en reglas de empresa, la aplicacin puede garantizar que los datos sean
correctos y que se adapten fcilmente a los requisitos futuros. Para obtener ms
informacin, vea Validacin de datos.
Controlar la seguridad de los datos

Puede que la aplicacin requiera seguridad de acceso para controlar quin tiene acceso
para ver y modificar datos de la aplicacin. La seguridad no slo consiste en autorizar
los inicios de sesin de los usuarios; la seguridad implica tambin el control del acceso
a todos los componentes de la arquitectura de la aplicacin y el control de los procesos
de acceso a datos, incluidos los siguientes servicios:

Serviciosdeinterfazdeusuario.
Serviciosdelsistemaoperativo.
Serviciosdeprocesosdeempresa.
Serviciosdetransmisindedatos.
Serviciosdebasededatos.

Para obtener ms informacin sobre la forma de controlar la seguridad de la aplicacin


para evitar manipulaciones y modificaciones no autorizadas, vea Creacin de
aplicaciones seguras.

Controlar el acceso a datos de varios archivos

Si la aplicacin tiene que seguir paso a paso una cadena compleja de valores lgicos y
de datos con el fin de prepararse para un proceso de decisin, se debe utilizar una regla
de empresa para simplificar el acceso a varios archivos. La regla de empresa buscar
automticamente todas las estructuras de datos necesarias y volver a empaquetarlas
para facilitar su uso. Por ejemplo, supongamos que la aplicacin tiene que determinar el
importe mximo posible para un nico procedimiento de peticin de asistencia sanitaria
de varias lneas. Mientras se inspecciona el elemento de lnea actual, se debe buscar el
historial completo de peticiones del beneficiario para utilizar previamente un
procedimiento idntico. Adems, deben comprobarse los lmites de duracin del
contrato y la fecha actual para determinar el importe permitido. Este tipo de acceso a
datos de varios archivos presenta una oportunidad excelente para crear una regla de
empresa reutilizable que controle la situacin de forma coherente y correcta.
Proporcionar integridad referencial

Uno de los usos ms comunes de las reglas de empresa es el control de la integridad


referencial. La integridad referencial es importante para el caso de archivos indizados y
de archivos relacionales. Como los archivos indizados (como un archivo VSAM) son
generalmente motores de almacenamiento de datos sin procesar, la aplicacin debe
proporcionar cdigo personalizado para controlar las restricciones, la eliminacin de
claves externas y otros aspectos comunes de integridad referencial. La integridad
referencial basada en aplicaciones tambin puede ser apropiada para las bases de datos
relacionales, especialmente en situaciones donde los desencadenadores, las restricciones
y los procedimientos almacenados son inadecuados o demasiado complicados. Para
obtener ms informacin sobre el mantenimiento de relaciones correctas entre tablas,
vea Integridad referencial.
La creacin de reglas de empresa para el acceso a los datos requiere un diseo
cuidadoso, sobre todo si se considera la interaccin con reglas de empresa existentes
que pertenecen a otras aplicaciones. La ventaja radica en que se garantiza la seguridad,
la precisin y la facilidad de acceso de los datos por parte de la propia aplicacin y de
otras aplicaciones.

Integridad referencial
La integridad referencial significa que la clave externa de una tabla de referencia
siempre debe aludir a una fila vlida de la tabla a la que se haga referencia. La
integridad referencial garantiza que la relacin entre dos tablas permanezca sincronizada
durante las operaciones de actualizacin y eliminacin.
Por ejemplo, supongamos que la aplicacin tiene una tabla Titles y una tabla Publishers
como se muestra en la siguiente tabla.
TablaTitles
isbn_ti(clave)

TablaPublishers
id_edit(clave)

ttulo_ti

nombre_edit

aopublic_ti

dir_edit

id_edit(claveexterna) telfono_edit

La integridad referencial requiere que estas dos tablas estn sincronizadas. Es decir, la
identificacin de cada editorial (id_edit) de la tabla Titles tambin debe aparecer en la
tabla Publishers.
La aplicacin no puede eliminar la fila id_edit de la tabla Publishers porque la fila
id_edit de la tabla Titles se quedara sin una referencia. Sin embargo, se podra permitir
la eliminacin de la fila id_edit de la tabla Publishers y eliminar tambin todas las filas
de la tabla Titles que tengan la misma identificacin id_edit. Con esta accin se
mantendra la integridad referencial en ambas tablas.
De forma similar, la aplicacin no puede aadir una fila a la tabla Titles si no existe ya
una identificacin vlida id_edit en la tabla Publishers. Esta accin dara lugar a la
insercin de datos "defectuosos" en el campo id_edit. De manera que la aplicacin debe
asegurarse de que haya una clave id_edit vlida en la tabla Publishers antes de insertar
la identificacin id_edit en la fila de Titles relacionada.
La implementacin real de la integridad referencial depende totalmente del motor de
almacenamiento de datos que se elija y de los requisitos de diseo de la aplicacin.
Histricamente, las aplicaciones que utilizan archivos VSAM de gran sistema usaban
cdigo basado en aplicaciones para controlar la integridad referencial. Hoy en da,
aunque la aplicacin utilice SQL Server, eso no significa que se deban utilizar
desencadenadores, claves externas, restricciones y eliminaciones en cascada para
mantener la integridad referencial. Una vez ms se puede elegir la opcin de controlar
aspectos relacionales con cdigo basado en aplicaciones.

Validacin de datos
La validacin de datos garantiza la correccin y precisin de todos los valores de datos
de la aplicacin. La validacin de datos de la aplicacin puede disearse utilizando
distintos enfoques: cdigo de interfaz de usuario, cdigo de aplicacin o restricciones de
bases de datos.
Hay varios tipos de validacin de datos:

Validacin del tipo de datos.


Comprobacin del intervalo.
Comprobacin del cdigo.
Validacin compleja.

Una de las formas ms sencillas de validacin de datos consiste en comprobar el tipo de


datos. La validacin del tipo de datos responde a preguntas tan simples como "Es

alfabtica la cadena?" y "Es numrico el nmero?". Normalmente, validaciones tan


simples se pueden controlar con la interfaz de usuario de la aplicacin.
Como ampliacin del tipo sencillo de validacin, la comprobacin del intervalo
garantiza que el valor proporcionado est entre los valores mximo y mnimo
permitidos. Por ejemplo, un cdigo de servicio con tipo de datos "character" slo puede
admitir caracteres alfabticos de la A a la Z; el resto de caracteres no sera vlido. Al
igual que ocurre en el caso de la validacin del tipo de datos, la interfaz de la aplicacin
puede proporcionar normalmente la validacin de intervalo necesaria aunque, como
alternativa de diseo, se puede crear una regla de empresa para controlar validaciones
de intervalo.
La comprobacin del cdigo es un poco ms complicada y requiere normalmente una
tabla de bsqueda. Por ejemplo, supongamos que la aplicacin calcula los impuestos
sobre ventas correspondientes nicamente a determinados cdigos de estados. Ser
necesario crear una tabla de validacin que contenga cdigos de estados sujetos a
impuestos que estn autorizados. Esta tabla de validacin puede formar parte de una
regla de empresa, o se puede implementar directamente en la base de datos a efectos de
bsqueda mediante consulta.
A veces, una validacin sencilla de bsqueda y de campo no es suficiente. Por ejemplo,
consideremos el caso de una peticin de asistencia sanitaria que tiene un importe
facturado de 123,57 dlares, pero cuyo importe permitido puede depender de una
acumulacin variable anual con un lmite de 1.500 dlares (sin superar directiva de
duracin mxima de 100.000 dlares). En esta situacin, la validacin de datos va ms
all de la pantalla de entrada de datos inmediata y consiste tambin en una evaluacin
minuciosa de cmo se ha de pagar la peticin basndose en los lmites de la directiva y
en las acumulaciones anual y de vida. Este tipo de validacin de datos compleja de
varios archivos se suele controlar mejor con reglas de empresa basadas en
procedimientos.
Las estructuras de archivos antiguas tienen el inconveniente de que los datos se
corrompen con frecuencia (por ejemplo, campos numricos en blanco o con caracteres
alfabticos). Cuando se crea una aplicacin empresarial, se debe crear tambin una
utilidad de comprobacin para verificar la correccin de cada uno de los campos de
todos los registros de los archivos que utiliza la aplicacin. Si no se realiza esta accin,
los resultados producidos por la aplicacin pueden ser imprevisibles.

Precauciones que deben adoptarse al


disear datos
Aunque las directrices de diseo de datos expuestas anteriormente son tiles, no pueden
ser determinantes a la hora de adoptar las decisiones finales sobre el diseo de datos. La
infraestructura tcnica y los conocimientos del programador que influyen en el proceso
de desarrollo de la aplicacin se enfrentarn finalmente a los aspectos prcticos del
diseo pudiendo complicar algunos temas. En concreto, han de tenerse en cuenta tres
cuestiones prcticas.

En primer lugar, conviene recordar que las directrices anteriormente expuestas pueden
ser contradictorias. Por ejemplo, si la capacidad de mantenimiento se considera el
aspecto ms importante, puede que no importe sacrificar en cierta medida el
rendimiento. De forma similar, el hecho de que una regla d lugar a una exigencia
rigurosa no significa que el sistema de administracin de bases de datos tenga que
exigirla obligatoriamente. Si la regla afecta a datos que abarcan varias tablas (o
archivos) y stas se almacenan en bases de datos independientes, es posible que el
sistema de administracin de bases de datos no pueda exigirla.
En segundo lugar, conviene recordar que la capacidad de mantenimiento no es un
concepto abstracto, sino un concepto concreto que depende fundamentalmente de la
experiencia del personal con que se cuente. Disear una implementacin, fcil de
mantener, de una regla supone ante todo la eleccin de una implementacin que se
aproveche de los conocimientos de los programadores. Si la regla se puede implementar
con SQL, pero el personal tiene ms experiencia con Visual Basic que con SQL, en lo
que respecta a la capacidad de mantenimiento de la aplicacin sera ms recomendable
implementar la regla en Visual Basic.
En tercer lugar, conviene recordar que es muy difcil prever dnde van a surgir
problemas de rendimiento. Durante la fase de implementacin, no es necesario poner
demasiado empeo en lograr un rendimiento mximo. Las aplicaciones han alcanzado
tal grado de complejidad que es casi imposible prever en qu momento pueden
producirse problemas relacionados con el rendimiento. Es preferible centrarse en los
objetivos bsicos del diseo y, posteriormente, detectar y solucionar los problemas de
rendimiento durante la fase de control de calidad.

Modelar la aplicacin y los datos


Para crear una nueva aplicacin empresarial necesita una planificacin considerable de
los elementos conceptuales, lgicos y fsicos. Debe estudiar los procesos empresariales
actuales y las estructuras de datos existentes y, finalmente, proponer una solucin de
aplicacin. Cuando interviene mucha gente en ese tipo de proyectos, se hace necesaria
alguna forma de capturar, administrar y comunicar las ideas de diseo de la aplicacin
propuesta.
Qu es modelar?

El modelado de la aplicacin y de los datos es el proceso de identificar, documentar e


implementar los requisitos de datos y procesos de la aplicacin. Esto implica la revisin
de los modelos de datos y procesos existentes para analizar si es posible su reutilizacin,
y la creacin de nuevos modelos de datos y procesos para cubrir los requisitos de la
nueva aplicacin.
Los eventos principales del modelado son:

Identificarlosdatosyprocesosasociados(porejemplo,elequipodeventasdeseaver
elcatlogodeproductosenpantallayenviarlospedidosdelosnuevosclientes).
Definirlosdatos(tiposdedatos,tamaosyvalorespredeterminados).

Comprobarlaintegridaddelosdatos(utilizandoreglasdenegocioycomprobaciones
devalidacin).
Definirlosprocesosoperativos(comorevisionesycopiasdeseguridad).
Seleccionarunatecnologadealmacenamientodedatos(relacional,jerrquicao
indizada).

Es importante comprender que el modelado implica a menudo la colaboracin por parte


de la administracin de la compaa. Por ejemplo, la propiedad de los datos (y la
responsabilidad de su mantenimiento, precisin y escala de tiempo) suele generar
suspicacias sobre qu organizaciones deben mantener ciertos elementos de datos. El
diseo de datos suele obligar a la organizacin a reconocer cmo los sistemas de datos
empresariales dependen unos de otros y resalta las eficiencias, el ahorro de costes y las
oportunidades estratgicas que proporciona una planificacin de datos coordinada.
Una vez terminado el modelado, habr definido completamente los requisitos de la
aplicacin, identificado los datos y servicios reutilizables por otras aplicaciones
empresariales y proporcionado una buena base para extensiones futuras.
Trabajar con Lenguaje universal de modelado

Una de las mejores maneras de modelar cmo trabaja la aplicacin es utilizando el


Lenguaje universal de modelado (UML). UML es un sistema de notacin para
representar conceptos, procesos automatizados, interacciones humanas y asociaciones.
Con UML utiliza notacin estndar para definir distintas actividades humanas y de la
aplicacin, mediante:

Diagramassecuenciales.
Diagramasdecolaboracin.
Diagramasdecasosdeuso.
Diagramasdeestado.
Diagramasdeactividad.
Diagramasdeestructuraesttica(diagramasdeclaseydeobjeto).
Diagramasdecomponentes.
Diagramasdeimplementacin.

Una buena razn para modelar la aplicacin con UML es la comunicacin de las ideas
de diseo. Con UML puede modelar visualmente procesos empresariales, arquitecturas
de aplicaciones, estructuras de datos e interacciones del usuario tanto existentes como
propuestos. Los diagramas de UML son fciles de comprender y ayudan a entender lo
que hace la aplicacin y cmo la gente interacta con ella. Mientras se desarrollan los
diagramas de UML, puede presentar cmo trabaja la aplicacin propuesta e ir refinando
el diseo de la misma de manera incremental.
Para obtener ms informacin, vea la ayuda en pantalla de Visio para arquitectos
empresariales en el CD-ROM de Microsoft Visio para arquitectos empresariales. Visio
debe estar activo y ejecutndose para poder ver la ayuda en pantalla de la solucin UML
de Visio. Al final de la instalacin de Visual Studio .NET tiene la opcin de instalar
Visio para arquitectos empresariales.

Das könnte Ihnen auch gefallen