Tabla de clientes, proveedores, registro fiscal

Alfredo:

Mi intención fue sugerir que revisara la teoría ya que parecía que estaba
modelando una base de datos relacional y todos los requerimientos no los
conocemos y hacer el análisis correspondiente es complejo e imposible en
el
foro. Hoy por hoy también me encuentro permanentemente con modelos que
representan objetos, lo cual tanbien hace difícil definir cual es la mejor
forma y ahí no podríamos hablar de dependencias funcionales y de
normalización deberíamos pensar en el modelo adecuado de persistencia.

Es verdad que puede haber varios modelos lógicos de base de datos que
respondan a los requerimientos funcionales de la aplicación, como usted
dice, así como puede ser que un único modelo lógico pueda responder a
varios
modelos funcionales.

Otra cosa importante a tener en cuenta, y que suele suceder
frecuentemente,
es que por ahorro de interpretación (y por el uso de herramientas CASE),
muchas veces existe casi una correspondencia 1 a 1 entre el modelo lógico
y
el físico. Por lo tanto hablar de separar y crear una tabla nueva para
evitar redundancias creo que puede y es generalmente entendido como un
mecanismo de normalización, aun sin el correspondiente análisis de las
dependencias funcionales tal como lo define la teoría.

En cuanto al caso en particular, habría que determinar claramente la
ventaja
de hacerlo. Es verdad que normalizar parece ser lo adecuado y por eso le
respondí que si coincidiendo con usted, sin embargo no puedo ser tan
categórico como usted, porque no puedo saber cuales de los atributos
relacionados a la clave primaria de la entidad "registro fiscal" son
dependiente funcionales porque eso lo definen los requerimientos
funcionales
particulares y las simplificaciones que se pueden aplicar. A priori, el
modelo podría ser adecuado pero también podría ser erróneo. Por ejemplo en
mi país existen varios números fiscales otorgados por organismos
gubernamentales diferentes para cada persona/empresa/grupo económico. En
ese
caso el numero de teléfono que propone almacenar no parece adecuado como
atributo de la entidad. "registro fiscal" y si parece mas adecuado en una
entidad "Empresa/Persona" o ("Party") como suelen expresar los modelos
americanos y tener una entidad de registros fiscales con solo los
atributos
que si dependen funcionalmente de la clave de registro fiscal.


Me pareció que ser tan estricto en cuanto a los términos no aportaba valor
por eso fui algo mas laxo y seguiré siéndolo en pos de que la mayoría sea
beneficiada. .Espero usted sepa disculpar mis expresiones "inexactas".




Saludos

Ing. Jose Mariano Alvarez
SQLTotal Consulting


(Cambia los ceros por O y saca lo que sobra)


IMPORTANTE
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.


Por favor tratar de indicar la versión de SQL y Service Pack.
La inclusión de (CREATE, INSERTS, etc.) para poder reproducir el problema
también ayuda.









"Alfredo Novoa" wrote in message
news:tj823sxz4z0n$.1866ylie38ouw$

Hola Jose Mariano,

El Sat, 10 Jan 2009 16:45:40 -0200, Jose Mariano Alvarez escribió:

Si, podrias, solo que deberias analizar por un lado los requerimientos
funcionales de tu aplicacion y luego de aplicar la normalizacion de tu
base
de datos definir si esa normalizacion te aporta valor o en tu modelo
funcional podrian ser atributos del cliente y evitar la entidad registro
fiscal.

Menudo lío te estás montando. La normalización no tiene nada que ver con
lo
que pregunta Carlos, y en todo caso habría que decidir si es conveniente
antes de aplicarla y no después :-)

Además estás confundiendo el modelo funcional con el modelo lógico. La
normalización se aplica al modelo lógico. Se pueden usar modelos lógicos
diferentes para los mismos requerimientos funcionales.

Si agregas una tabla mas es probable que requieras mas joins para
resolver tus consultas lo cual seria mas lento en las consultas,

Hay cosas mucho más importantes que un incremento marginal en los tiempos
de algunas consultas.

Sugiero que revises la teoria
de normalizacion de bases de datos hasta la quinta forma normal y luego
decidas.

Podías haberlo hecho tú también.


Saludos

Ya que tienes un campo de código fiscal que es clave te podrías ahorrar el
otro código.

lo que pasa es que el código fiscal es muy largo pero lo analizaré a ver que
tal.