Reglas Practicas Diseño Base Datos PDF

Facultad de Ciencias Económicas y Jurídicas UNLPam
Reglas Prácticas de Normalización de Datos aplicables al Diseño de Bases de Datos
Cr. Carlos Miguel FARIAS Año 2002 Página 1

Indice:
Objetivo Principal..............................................................................................................................................3
Introducción y Antecedentes............................................................................................................................4
¿Por que Normalizar?.....................................................................................................................................6

¿Qué es normalización?..................................................................................................................................9
Antes de Normalizar......................................................................................................................................11
¿Cómo Normalizar?......................................................................................................................................23
Conclusiones de normalizar con formas normales:......................................................................................31
Modelos Semánticos: ...................................................................................................................................32
Reglas Practicas: .............................................................................................................................................43

Relevamiento de los requisitos del Sistema de Información:......................................................................43
Las reglas propuestas son las siguientes:.....................................................................................................46
Tabulación de Entidades, sus Atributos y Relaciones.................................................................................46
Diagramación de Entidades........................................................................................................................55
Diagramación de Relaciones......................................................................................................................56
Distribución de Atributos............................................................................................................................56
Definir Claves de cada Entidad..................................................................................................................58
Establecer Relaciones Básicas....................................................................................................................58
Establecer Relaciones Básicas Múltiples....................................................................................................61
Establecer Relaciones Complejas...............................................................................................................62
Establecer Relaciones Especiales...............................................................................................................62
Unificación de Poblaciones Equivalentes...................................................................................................63
Aplicación Práctica de las Reglas Definidas..............................................................................................65
Un Sistema de Contabilidad:......................................................................................................................65
Sistema de Administración de Cursos: .......................................................................................................80
Participación Terceros en el trabajo de Investigación:..............................................................................99
Sistema de Gestión de Imprentas.................................................................................................................99
Bibliografía:...................................................................................................................................................119

Objetivo Principal
El presente trabajo se propone establecer Reglas Prácticas
para la Normalización de Datos al momento del Diseño de las Bases de
Datos. Estas reglas no pretenden reemplazar las reglas teórico-matemáticas
que se utilizan en diseño avanzado de bases de datos, si no que como objetivo
busca establecer una serie de ventajas a saber:
a) Simplificar la modelización de bases de datos aplicando principalmente

la metodología de Entidad-Relación (en contraposición del uso de las
Formas Normales).
b) Posibilitar al profesional de Ciencias Económicas el diseño Bases de

Datos de complejidad pequeña a mediana y/o controle el diseño
instrumentado por los profesionales de Sistemas de Información.
c) Establecer mecanismos simples para que el Contador pueda evaluar la

calidad y verificar la facilidad del uso del sistema diseñado para
obtener de obtener información gerencial o a los efectos del control
interno y/o auditoria del mismo.

Introducción y Antecedentes
Es común que los Contadores Públicos se encuentren ante
la necesidad de diseñar pequeñas bases de datos para administrar sistemas de
información de su propio estudio o de clientes que no cuentan con sistemas de
información propios.
Tales profesionales pueden utilizar sistemas de gestión de

bases de datos para computadoras personales (SGBDPC) para instrumentar
dichas sistemas de información. Aunque dichos SGBDPC son relativamente
fáciles de manejar, el profesional no está capacitado para el uso de los
mismos ya que le resultan “extrañas a la profesión”, presuponiendo que tienen
que programar, por lo que actúan de la siguiente manera:
 Utilizan planillas de cálculo (Excel, Lotus, etc.) creando planillas con

gran cantidad de columnas, las que a medida que se van cargando los datos
se vuelven “monstruosas” (difíciles de manipular, administrar, y utilizar).
 Por la forma de diseño de las planillas, la incorporación de datos se

pone engorrosa, ya que implica repetir fila a fila todos los datos comunes a
filas previas, aunque es fácil el “copiar y pegar” provisto por entornos
gráficos (p.e. Windows), las posibilidades de errores y la redundancia de
datos aumentan.
 A veces, para solucionar la carga, el contador crea “macros” dentro de

la planilla o en casos extremos formularios, lo cual puede ser tan o más
difícil que una instrumentación equivalente utilizando asistentes de los
SGBDPC.
 En el caso de haber logrado cargar los datos, la elaboración posterior

los informes se hace complejo y poco práctico por ser las planillas de gran
tamaño y porque no siempre hay que mostrar y/o listar todos los datos que
se hayan incorporado.
 Los paquetes actuales de planillas de calculo, proveen facilidades de
creación de equivalentes a tablas de bases de datos relacionales, pero su
uso adecuado implica utilizar las mismas técnicas de diseño de bases de
datos que se efectúen utilizando algún SGBDPC.
En consecuencia, resulta evidente que el contador, tanto
en sus roles de administrador, asesor o auditor interno, debe participar en el
análisis (aportando requisitos) y en la implementación (controlando lo
instrumentado) de los sistemas de información de la empresa.
Un buen diseño de las bases de datos, permite al

profesional contador utilizar asistentes para la generación de formularios
específicos de carga de datos y luego elaborar consultas y reportes a partir de
los datos almacenados, utilizando asistentes específicos o herramientas como
el SQL.
De esta manera puede cargar datos fácilmente en los

casos de crear bases de datos para manejo de sus clientes en su propio estudio
o en las empresas de estos. Logrando luego obtener información de tipo
gerencial y/o para efectuar las tareas del Control Interno.
También, un Auditor Externo, podrá aprovechar un buen
diseño de la Base de Datos para las tareas de auditoria, ya que un buen diseño
aumenta la probabilidad de que los datos de la empresa, no sean redundantes,
sean consistentes y tengan alta posibilidad de integridad.
Por lo tanto, estas reglas podrán ayudar al Contador a

determinar si los datos de la empresa están almacenados en forma tal que le
faciliten el trabajo de elaborar los informes gerenciales o bien hacer sus
propias indagaciones de control, sin tener que recurrir a los programadores
del área de sistemas de la organización, a los que puede que se este
controlando, o a profesionales contratados, si la aplicación fue comprada.
Como las metodologías de diseño de bases de datos por

medio de la normalización implican conocimientos de matemáticas
específicas, las cuales no le son impartidas al Contador en el plan de estudios,
el contador se encuentra en falta al momento de encarar el diseño de pequeñas
a medianas bases de datos.
De ahí, la necesidad de establecer Reglas Prácticas que
permitan que el contador pueda diseñar bases de datos de pequeña o mediana
envergadura o pueda controlar el diseño hecho por los analistas de sistemas
(de la empresa o externos), para que dichas bases de datos respondan a los
requerimientos de información gerencial y/o control.

¿Por que Normalizar?

Siempre que un analista de sistemas de base de datos
arma una base de datos, queda a su cargo descomponer dicha base en grupos
y segmentos de registros. Este proceso es la descomposición; el mismo es
necesario independientemente de la arquitectura de la base de datos
(relacional, red, jerárquica u orientado a objetos).
Sin embargo, para la Base de Datos Relacional (en

adelante BDR), la acción correspondiente puede dividirse y expresarse en
términos formales y se denomina normalización a la misma. Se hace
hincapié en el modelo relacional (de todos los posibles) por ser el mas usado
en la actualidad y el de más aplicación actual y en un futuro inmediato a
sistemas de gestión en los que podrá encontrarse inmerso el contador.
Aunque algunos podrán alegar que el modelo

Orientado a Objetos (en adelante OO) es mejor, pero este involucra mas
conocimientos sobre sistemas y procesos, y eso nos aparta del objetivo
propuesto, independientemente de ello, las reglas a desarrollar, permitirán al
contador contar con los primeros conceptos sobre objetos, o sea que este no es
un camino distinto de OO, solo es el principio.
Todo el proceso de normalización busca distribuir

los datos de manera racional. Téngase en cuenta que por muy poderoso que
sea nuestro Sistema de Gestión de Bases de Datos (en adelante SGBD), si los
datos de la Empresa no están normalizados se tendrá las siguientes
desventajas:
a) Redundancia de datos.
b) Inconsistencia de Datos.
c) Perdida de Información.
d) Mayor esfuerzo de mantenimiento (Altas, Bajas y Cambios).
Para el caso de la redundancia, se supone que se guardan

los datos de las facturas a los clientes, de ellas se necesitan el Número y
Fecha de la Factura, Nombre, CUIT, Dirección del Cliente, Total Venta, y de
cada Articulo vendido en dicha Factura, se necesitará, Código, Descripción,
Cantidad, Costo Unitario y Precio de Venta.
Si todo esto se pone en una tabla (por ejemplo de nuestra

planilla de cálculos preferida), se obtendrá la siguiente estructura:
Relación FACTURACIÓN (sinónimos: Tupla o Tabla)

#Fac Fecha Tvta Nombre CUIT Dir. Cod. Des. Can CUnit PVta
1 10/08/2001 199,91 Mengan 2012... XX A12 Alfombra 5 25,12 29,99
1 10/08/2001 199,91 Mengan 2012... XX S915 Sillon 1 15,20 19,99
1 10/08/2001 199,91 Mengan 2012... XX S91 Silla 3 8,90 9,99
2 11/08/2001 22,43 Zutano 2017... YY P914 Pinturex 4 2,23 2,99
2 11/08/2001 22,43 Zutano 2017... YY L91 Lija 8 0,35 0,50
2 11/08/2001 22,43 Zutano 2017... YY P912 Pincel 2 1,65 1,99
2 11/08/2001 22,43 Zutano 2017... YY R15 Rodillo 1 2,10 2,49
3 15/08/2001 79,96 Perenga 2008... ZZ S915 Sillon 4 15,20 19,99
4 15/08/2001 92,47 Perenga 2008... ZZ L91 Lija 5 0,35 0,50
4 15/08/2001 92,47 Perenga 2008... ZZ A12 Alfombra 3 25,12 29,99
5 16/08/2001 47,94 Untano 2048... XY L91 Lija 6 0,35 0,50
5 16/08/2001 47,94 Untano 2048... XY R15 Rodillo 2 2,10 2,49
5 16/08/2001 47,94 Untano 2048... XY S91 Silla 4 8,90 9,99
6 17/08/2001 43,91 Mengan 2012... XX P914 Pinturex 8 2,23 2,99
6 17/08/2001 43,91 Mengan 2012... XX S915 Sillón 1 15,20 19,99
7 18/08/2001 151,45 Perenga 2008... ZZ A12 Alfombra 5 25,12 29,99
7 18/08/2001 151,45 Perenga 2008... ZZ L91 Lija 3 0,35 0,50
8 18/08/2001 10,45 Untano 2048... XY R15 Rodillo 1 2,10 2,49
8 18/08/2001 10,45 Untano 2048... XY P912 Pincel 4 1,65 1,99
Tabla 1
De este simple ejemplo se puede ver que hay gran

cantidad de datos que se repiten, y otros se tornan más difícil determinar, caso
del total de cada factura, que en el caso de una usar una planilla de cálculo, la
formula para obtener el total es un poquito más complicada (la referencia a las
filas debe ser fija, por lo que no se puede obtener con un simple copiar y
pegar).
En realidad, en el ejemplo anterior no solo se repiten las

cantidades vendidas, también se repetirían las columnas de costos, precios,
descripciones, etc.. Si se estuviéra en una época inflacionaria, las columnas de
costo y precio de venta, no estarían repetidas, pero en si hay estabilidad de
precios, si lo estarán.
Los dos párrafos precedentes muestran como es la

redundancia, la primera gran desventaja de datos no normalizados. La primera
dificultad visible es que los datos repetidos requieren más espacio para
ubicarlos, evidentemente, la carga de los mismos lleva más tiempo, hay
mayor cantidad de digitaciones por lo que la probabilidad de error de
trascripción de las transacciones es mayor.
Otro problema altamente asociado con el anterior, es que

detectado un error en una entrada (por ejemplo la dirección del cliente), salta
a la vista que corregir el error puede ser engorroso, buscar todos los renglones
de las facturas que corresponden a ese cliente, controlar y si corresponde,
corregir.

Esto evidencia también que los datos no serían

consistentes, ya que ante una consulta a la base de datos, la respuesta tiene
probabilidad de no ser única. O según como se efectúe la consulta, puede
tener respuestas alternativas.
El ejemplo planteado, favorece la falta de integridad de

datos, ya que un error, puede perderse en el volumen, por ejemplo: un mismo
cliente con distintos CUIT o direcciones, un mismo producto, con diferentes
descripciones, o costos, precios de venta, la misma factura con distintas
fechas, etc..
Cualquier sistema de Información con características

como el brindado en el ejemplo, que responde a diseños utilizados en
aplicaciones con diseño tradicional de 20 años atrás, en donde, por
limitaciones en el equipamiento y software de base disponible, no quedaban
otras posibilidades, limitaciones emergentes de restricciones por ejemplo en
la cantidad de archivos abiertos, ya sea por limitación del Sistema Operativo
como por el lenguaje de programación utilizado.
Como puede verse, estas circunstancias puede causar

muchos problemas, no solo para el proceso operativo normal del SdI, si no
que al momento del Control Interno, la tarea será ardua, y en el caso de una
Auditoria Externa, si es sería, esta falta de normalización puede resultar en
una calificación baja al SdI.

¿Qué es normalización?
Normalización es un proceso que clasifica relaciones,
objetos, formas de relación y demás elementos en grupos, sobre la base de las
características que cada uno posee. Si se identifican ciertas reglas, se aplica
una categoría; si se definen otras reglas, se aplicará otra categoría.
La forma de efectuar esto es a través de los tipos de

dependencias que se pueden determinar dentro de la relación. Cuando las
reglas de clasificación sean más y más restrictivas, se dirá que la relación está
en una forma normal (en adelante FN) más elevada.
La relación que está en la FN más elevada posible es la

que mejor se adapta a las necesidades del Sistema de Información (en
adelante SdI) debido a que optimiza las condiciones que son de importancia
para quienes usan dicho sistema.
La normalización convierte una relación (conjuntos de

datos del SdI) en varias sub-relaciones, cada una de las cuales obedece a
reglas. Estas reglas se describen en términos de dependencia. Una vez que se
hayan examinado las distintas formas de dependencia, se tendrán
procedimientos a aplicar a las relaciones de modo tal que las mismas puedan
descomponerse de acuerdo a la dependencia que prevalece. Esto llevará
indefectiblemente a formar varias sub-relaciones a partir de la única relación
preexistente.
En el ejemplo de la Tabla 1, se observa una relación con

todos los datos de un “sistemita” de facturación, se ve que la tabla tiene
muchas columnas (una por cada dato o atributo requerido), y la cantidad de
filas es igual a la suma de la cantidad de renglones de todas las facturas de
registradas.
Al normalizar, la idea es crear varias tablas (sub-

relaciones) con menor cantidad de columnas (menor grado de relación) y de
filas (menor cardinalidad), por lo que cada una de estas sub-relaciones será
más simple de visualizar, por la menor cardinalidad (tendrá atributos más
específicos) y más fácil de manipular, por la menor cardinalidad.
Por supuesto que este proceso de normalización debe ser

apropiado, para que al distribuir los datos (se están separando en distintos
archivos), la información luego será recuperable tal cual.

Por lo que si el sistema es optimizado (normalizado) se

obtendrán las siguientes ventajas claves:
 El Volumen de Datos es el menor posible que implica:

 Menor requerimiento de espacio en medios de almacenamiento.
 Menor tiempo para responder a las consultas por parte del sistema
informático.
 Menores requerimientos de equipo (hardware) tanto en capacidad de
proceso como en transmisión.
 La facilidad para actualizar la relación es la mayor posible que implica:
 Programas más simples para efectuar dicha tarea.
 Menor probabilidad de errores en el proceso de datos.
 Simplicidad de procesos, facilitan el control interno y la auditoria.
 La explicación de la base de datos es la más sencilla posible que implica:
 Simplificación de las consultas (query’s), por lo que la especificación
de las mismas está más fácilmente al alcance del contador, con
sentencias simples en SQL, etc. y fundamentalmente, resolubles
mediante asistentes de consultas.
 Simplificación de los controles a instrumentar a los efectos del control
interno.
 El reducir el volumen de datos, puede considerarse como el primero de
seis criterios de selección de estructuras de datos para soportar la Base de
Datos y por lo tanto el SdI que aunque no serían de incumbencia del
Contador, le permitirá participar en la toma de decisiones en cuanto al
costo de dicho SdI.
Los otros criterios para seleccionar estructuras de datos
para optimizar el SdI son:
 Frecuencia y Modo de Uso: La estructura debe ser tal que soporte la
frecuencia de uso (por ejemplo, cantidad de transacciones, accesos de
consulta) y el Modo de Uso o de acceso a los datos, o sea si responderá
a procesamiento secuencial o aleatorio, etc.
 Estatismo o Dinamismo: Luego debe considerarse si la estructura
soportará adecuadamente datos que son estáticos, o sea que se
modifican poco, o dinámicos, o sea que cambian mucho.
 Espacio Requerido por la Estructura: Espacio de Almacenamiento
para manejar la estructura.
 Tiempo de Acceso: Si las respuestas se dan en tiempo y forma.
 Facilidad de Programación: Si el personal de Sistemas, conoce las
estructuras y sabe utilizarlas apropiadamente.

Antes de Normalizar
Como se indicó previamente, la normalización
comprende una serie de pasos donde el conjunto de datos requeridos por el
SdI, alcanzan ciertas condiciones, que de acuerdo al conjunto de reglas que
cumplen están en una FN determinada.
Antes de empezar con el proceso de normalización, se

deben tener en claro un conjunto de conceptos (o definiciones) previos, que
serán necesarios para dicha actividad.
Conceptos Básicos: Antes de entrar en tópicos específicos como la

dependencia, se aclarará lo que se entiende respecto a algunos conceptos
acerca de los individuos (también conocidas como entidades) y acerca de las
tablas (o tuplas) que corresponden a BDR, el porque se indico bajo el titulo
¿Por qué Normalizar? :
1) Atributos (Datos): Los individuos tienen muchos atributos que pueden

ser de interés a diferentes personas en diferentes momentos. En un SdI,
un atributo constituye un dato, asociado (dependiente) de una entidad,
que es necesario para el SdI. Considerándose además que:
a) A es el símbolo del nombre de un atributo (en la tabla 1, el
nombre de cada columna es el nombre de un atributo).
b) a es el símbolo de un valor del atributo (en la tabla 1, el valor
dentro de cada celda, debajo de la fila del titulo de la tabla,
constituye un valor de a.
Dentro de una relación se tendrá una columna para cada
atributo, como se ve a continuación:
R COLOR MARCA
´verde` ´ford`
ázul` ´fiat`
Tabla 2
2) Dominio (del atributo): Es el Universo (U) de valores posibles a que

puede tomar un atributo A. En la tabla 1, el dominio de #Fac, son todos
los posibles valores de factura que pueden tomar las facturas.

 Ejemplo:
 D1 = {´rojo`, ´verde`, ńegro`, ázul`}
 D2 = {`ford´, ćhevrolet`, ´fiat`, ´toyota`, ´renault`}
3) Aplicación: Se denomina comúnmente “aplicación” a la

instrumentación informática de todo o parte del SdI de la empresa, ésta
requerirá para cumplir su cometido un subconjunto de todos los datos
(atributos) disponibles sobre uno o mas tipos de individuos o entidades,
por ejemplo, todos los datos de la tabla 1.
4) Tupla: La variedad de atributos o datos, se encontrarán distribuidos en

subconjuntos del total requerido, cada uno de estos se denominará Tupla
(simbolizada como R, R en letra normal, no confundir con Relación que
es R, letra en negrita), que será un vector que describe a un individuo
en particular. Téngase en cuenta que:
a) En un sistema de archivos tradicional, el concepto de tupla puede
asociarse con el de registro, o sea que al definir el contenido de
datos de una tupla, es equivalente a obtener el “diseño del
registro”.
b) En un modelo de BDR, la tupla constituirá la distribución de
columnas, en cada fila de una tabla.
c) El proceso de normalización busca obtener la distribución de
atributos en tuplas óptima.
d) La cantidad de atributos (columnas o datos) que contenga una
tupla determinarán su grado.
5) Relación: También se simbolizará como R (letra en negrita) a cada

relación, que es una matriz o un conjunto de vectores (tuplas) que
pertenecen la población de interés. Téngase en cuenta que:
a) En un sistema de archivos tradicional, el concepto de relación
puede asociarse con el de archivo. Como se indico que tupla
equivalente a registro, conjunto de tupla igual a conjunto de
registro.
b) En un modelo de BDR, la relación constituirá una tabla, o sea
todas las filas con datos que corresponden a una población de
entidades.
c) Una tupla en general se simboliza con:
R = (a, b, c, ...., n)
d) La cantidad de tuplas en la relación, determinará su cardinalidad,
y determina una de las dimensiones de la matriz.
e) También a la relación es de aplicación el concepto de grado, que
define la otra dimensión de la matriz.

 Ejemplo:
 R1 = {(´rojo`,`ford´), (´verde`,`ford´), (ńegro`,ćhevrolet`),
(ázul`, ´toyota`)}
 R2 = {(´fiat`, ´verde`)}
 R3 = { }
En forma de tabla, las poblaciones del ejemplo quedarían

plasmadas como en la tabla 3:
R D1 D2
´verde` ´ford`
ázul` ´fiat`
Tabla 3
6) Esquema de una relación o de tabla: es el nombre de la relación

seguido de la lista de sus atributos con sus dominios. Un esquema de
relación se puede representar por intención o por extensión.
Ejemplo:
Auto(Patente, marca, modelo, color)
tabla ↓ Columna ↓
Auto Patente Marca Modelo Color
fila o tupla CQH543 Chevrolet Corsa Rojo Naval
→ SKF110 Ford Mondeo Verde Oliva
XSG230 Fiat Siena Azul Cobalto
Tabla 4
7) Base de datos relacional: es una base de datos cuyo esquema es un

conjunto de esquemas de relación de diferente nombre cada una, y donde
sus ocurrencias son las tuplas de esas relaciones. Estas bases de datos
deben cumplir con una serie de reglas de formación:
a) Cada relación o tabla contiene un solo tipo de fila o tupla.
b) Cada tupla tiene un número fijo de atributos o columnas.
c) No se permiten atributos compuestos o grupos repetitivos.
d) Cada tupla es única y se identifica con su clave primaria.
e) Un atributo o grupo de ellos que identifiquen unívoca e
inequívocamente cada tupla de la relación es una clave candidata.

f) La clave primaria de una relación se selecciona entre las claves

candidatas.
g) Si un atributo A ∈ R1 es también la clave primaria de R2,
entonces A es un atributo foráneo de R1.
h) El orden de las tuplas en la relación es irrelevante.
i) Los valores de los atributos deben pertenecer al dominio de cada
atributo definido en ella.
j) Un mismo dominio puede ser usado por diferentes atributos.
k) A partir de una o más tablas se pueden producir nuevas tablas
diferentes mediante el uso de las operaciones del álgebra
relacional.
8) Reglas de integridad
a) De la relación: ningún componente de un valor de los atributos
que conforman la clave primaria puede ser nulo.
b) De referencia: sea A la clave primaria de R1 y también un
atributo foráneo de R2, entonces para toda tupla de R2 donde A ≠
nulo debe existir la tupla correspondiente en R1.
c) De los valores de un atributo: son los predicados definidos por
el administrador de bases de datos sobre los valores de los
atributos usando el lenguaje de definición de datos.
 Ejemplo:
 Iniciando ≤ Terminando de integridad de..
 Inscripto ≤ Iniciando los valores de los atributos.
Semestre Código Iniciando Terminando Inscripto

tupla → 101 02/03/2000 17/07/2000 22/2/2000
132 14/09/2000 30/01/2001 07/09/2000
133 15/03/2001 23/07/2001 08/03/2001
Tabla 5
9) Universo Relacional: U es el universo consistente en todas las posibles

descripciones individuales, obtenido mediante una combinación
exhaustiva de los valores de atributos. Si por ejemplo existe 10 modelos
de vehículos, 20 colores posibles de pintura y 7 motores disponibles. U =
1400 posibles vehículos.
De d), e) y h), se tiene que R ∈ R ⊂ U1
1
∈ significa es miembro de. ⊂ significa esta incluido en.

10) Clave de la Relación: Es el conjunto de atributos de una tupla

(generalmente es un conjunto de un solo elemento), cuyos valores de
atributos son indefectiblemente diferentes de una tupla a otra dentro de
la relación. Por lo que se dice que cada valor de la clave, identifica en
forma univoca a una tupla de dicha relación (o sea, a una y solo una).
Además las claves se pueden clasificar en:
a) Claves primarias: Es el conjunto de atributos2 que son clave de

la tupla que cumple con las características indicadas en la
definición (identificación unívoca) y se usa prioritariamente para
tal función. No deben confundirse con las superclaves ya que
estas pueden contener atributos ajenos.
b) Claves candidatas (o alternativas): Son otros conjuntos de
atributos distintos de los indicados en el apartado anterior, que
tienen iguales características (identificación unívoca) pero que no
se usan normalmente para identificar a las tuplas de la relación.
Esto es por necesidades del SdI, ya sea por restricciones del
software de tratamiento o por que se busca optimizar la
estructura de datos utilizada para el acceso.
c) Claves externas (o foráneas): Son aquellos atributos, cuyos
valores dentro de la Relación pueden repetirse de una tupla a
otra, pero resultan ser el conjunto de atributos que constituyen la
clave primaria en otra Relación. Estos atributos cumplen con la
función de Relacionar (vincular, asociar, etc.) una relación con
otra.
Y deben cumplirse además las siguientes condiciones por

parte de las claves primarias de una base de datos:
a. Todas las relaciones tienen que tener una.

b. Debe figurar como clave foránea en al menos otra relación
o...
c. Ser parte de la clave compuesta (más de un atributo como
clave) de otra relación, donde dicha clave compuesta es la
clave primaria de tal relación o...
d. La relación de la que es clave debe tener al menos una clave
foránea.
2
Cuando se dice Conjunto de Atributos, significa que se habla de al menos un atributo de la tupla (nunca un conjunto
vacío), este conjunto tiene normalmente un miembro, pero puede llegar a tener más de uno, cuando una clave tiene
más de un atributo, se dice que es una clave compuesta.

Esto es muy importante ya que para establecer las

relaciones en una BDR, se utilizan sus claves primarias ya sean tomadas
como un todo, o en el caso de claves compuestas, por una de sus partes.
Ejemplo de tipos de claves:

Supónganse dos relaciones, Clientes y Ciudades,
usadas para manejar los atributos básicos de la empresa como se indica a
continuación:
Ciudades = {Código Postal, Nombre Ciudad}

Clientes = {Número, CUIT, Nombre, Dirección, Código Postal}
En la primera relación (Ciudades),

indiscutiblemente, el atributo Código Postal es la clave primaria, hay varias
ciudades con igual nombre (Sin considerar el caso especial de Capital
Federal, en la guía de códigos postales búsquese ciudades como Arroyito,
Avellaneda, Bajo Grande, etc.), esto descarta dicho atributo como clave.
Tomando la segunda relación (Clientes) puede decirse

que:
Dos clientes pueden tener el mismo nombre, por lo que
no puede ser el atributo clave, mas raro pero factible, dos clientes pueden
tener la misma Dirección (aquí se asume que la dirección comprende la calle
y el número), lo que también descarta a Dirección como posible atributo
clave.
Además, dos o más clientes pueden vivir en la misma

Ciudad, por lo que tendrían el mismo Código Postal, y este no podrá ser clave
ni primaria ni candidata, pero como es Clave Primaria de otra relación (ya se
dijo que utilidad tiene), se puede decir que Código Postal es una clave
externa o foránea.
Quedan para analizar Número (de cliente) y CUIT (Clave

Única de Identificación Tributaria), como posibles atributos clave, si la
empresa tiene 1.000 clientes (o aún hasta 1.000.000), será más fácil digitar el
número del cliente (6 dígitos) que el CUIT (11 dígitos), por lo que es más
óptimo para el SdI, utilizar el Número (de cliente) como atributo clave
primario, relegando el CUIT como clave candidata.

Ejemplo de análisis para determinar atributos claves:
Facturación ={#Fac, Fecha, Tvta, Nombre, CUIT, Dir.,

Cod., Des., Can, Cunit, Pvta}
En el ejemplo, tomando los atributos de la Tabla 1, los

dos atributos subrayados son los campos claves, Fecha, bajo ciertas
circunstancias (como se explica más adelante) puede ser clave, ¿Por qué
dichos campos pueden considerarse clave?. Se deducirá por la inversa, porque
los otros no pueden ser clave. Obsérvese:
1. Tvta (total venta): es el total de ventas de la factura, dos facturas

distintas pueden tener el mismo valor, que es lo mismo que pasa con
fecha.
2. Nombre (del Cliente): Dos clientes pueden tener el mismo nombre, por
lo que dado un nombre de cliente, no puedo identificarse unívocamente
a quien se refiere.
3. Dir. (Dirección del Cliente): Es raro, pero no imposible, que dos
clientes tengan la misma dirección, por lo que dado una dirección, al
igual que con el nombre, no puede diferenciarse un cliente de otro.
4. Cunit (costo unitario) y Pvta (precio de venta): Varios productos
pueden tener igual costo unitario, igual precio de ventas o ambos
iguales, por lo que es imposible identificar o determinar con estos
atributos una tupla (que producto).
5. Can (Cantidad): Este atributo puede repetirse en distintas facturas o
dentro de la misma factura, por lo que no permite identificar nada.
6. Fecha: es la fecha de facturación, en un día pueden haber más de una
factura, por lo que dado una fecha, no puedo identificar los valores que
corresponden a una Factura. La circunstancia por la cual bajo la cual
podría considerarse clave es que si el SdI debe responder a un entorno
con proceso inflacionario implicando que los precios (costo y venta) no
sean estables y por lo tanto dependientes, no solo del artículo, sino
también de la fecha.
11) Dependencia: Son importantes las relaciones dependientes entre

atributos de los individuos en una o varias poblaciones. La dependencia
es una relación funcional tal que los valores de una (o más de una) de las
variables determina y fija el valor de las otras variables en la relación
dependiente. Considérese a los atributos D, E, y F, el caso en el que E y
F dependen de D. Esto se describe más brevemente en forma simbólica:
e = e (d) f = f(d)

Existen varios tipos de dependencia diferentes, en el

presente trabajo se consideran:
a) Dependencia Funcional: Es una generalización del concepto de
clave. Las dependencias funcionales son una restricción al
conjunto de relaciones legales.
Sea R(A1, A2, ..., An) y X e Y dos subconjuntos del

conjunto formado por {A1, A2, ..., An} . Se dice que X → Y (X
determina a Y o que Y depende funcionalmente de X) si para
toda extensión r de R y para toda tupla t1 y t2 de r se tiene que:
Π X ( t1 ) = Π X ( t2 ) implica que Π Y ( t1 ) = Π Y ( t2 ) 3
Ejemplo de dependencia funcional:

Patente → marca
Patente → modelo
Patente → color
Patente → (marca, modelo)
Modelo → marca
Las dependencias funcionales (en adelante DF), se

identifican mirando atentamente el significado de los atributos,
no sus valores actuales, sino todos los valores posibles de ellos.
Las DF deben aparecer en el esquema conceptual de una BD.
(1) Propiedades de las DF:

(a) Reflexibidad: Si Y ⊆ X ⇒ X → Y.4
Ejemplo: modelo ⊆ marca ⇒ marca → modelo
(b) Aumento: Si X → Y ⇒ X Z → Y Z
Ejemplo: modelo → marca ⇒ (modelo, color) → (marca, color)
(c) Transitividad: Si X → Y e Y → Z entonces X → Z

Ejemplo: patente → modelo y modelo → marca
⇒ patente → marca
3
Simbolo Π (Pí), significa proyección
4
⊆ Incluido estrictamente ⇒ implica → determina

(d) Aditividad: Si X → Y e Y → Z entonces X → Y Z
Ejemplo: patente → modelo y modelo → marca

⇒ patente → (modelo, marca)
(e) Pseudo-transitividad: Si X → Y e W Y → Z
entonces W Y → Z
Ejemplo: patente → modelo y (marca, modelo) → potencia
⇒ (patente, marca) → potencia
(f) Descomposición: Si X → Y e Z ⊆ Y entonces X → Z

Ejemplo: Patente → (modelo, marca) y...
modelo ⊆ (modelo, marca) ⇒ Patente → modelo
b) Dependencias funcionales elementales: Una dependencia

funcional elemental, en adelante DFE, es una DF de la forma X
→ A, donde A es un atributo único no incluido en X y donde no
existe un X' ⊂ X tal que X' → A
Ejemplo: Patente → DFE modelo, pero

Patente → no es DFE (modelo, marca)
La regla de inferencia que se aplica a las DFE es la

transitividad. Las DFE se expresan en un grafo de DFE donde
los nodos son los atributos y las aristas son las DFE. En caso de
tener más de un atributo en la parte izquierda de la DFE, ésta se
expresa colocando una línea que acoja las aristas de todos los
atributos de la parte izquierda y de ella sale una arista al atributo
de la parte derecha, convirtiendo así el grafo de DFE en una red
de DFE. Un ejemplo de grafo y de red de DFE se muestra en el
Gráfico 1.
A partir de las DFE se pueden componer otras DFE

utilizando la propiedad de transitividad. El conjunto completo de
todas las DFE se denomina cierre transitivo, formalmente se
define como el conjunto de las DFE consideradas, enriquecidas
con todas las DFE deducidas por transitividad.
Notación: C+. (cierre de C)

Marca
Patente Modelo
Color
a) Grafo de DFE
Ciudad
Calle Codigo Postal
Extension (*) Observaciones

(*) Extension son Numero,
Piso, Dpto, etc.
b) Red de DFE
Dependencia Funcionales Elementales (Gráfico 1)
Ejemplo: Para la relación Auto se tiene:
C+ = {Patente → marca, Patente → modelo, ...

Patente → color, modelo → marca }
A partir de C+ se define la equivalencia de dos conjuntos

de DFE. Dos conjuntos de DFE son equivalentes si tienen la
misma C+.
Cobertura mínima: es el conjunto C de DFE asociado a

un conjunto de atributos que verifican las propiedades siguientes:
a) ninguna DF es redundante en C, es decir para toda DF

denotada f de C, C - f no es equivalente a C.
b) toda DFE de los atributos está dentro de C+.

Ejemplo: C = {Patente → modelo, Patente → color,

modelo → marca }
C es esencial para la descomposición sin pérdida.
c) Total (uno-uno-sinónimo): Si se consideran los atributos X e Y.

Cada valor (x) de X tiene uno y solo un valor (y) de Y asociados
a él; e inversamente, dado un valor (y) de Y existe solamente un
valor de x asociado a éste. Se trata de una función unitaria de una
variable tanto en sentido directo como inverso y por o tanto se
denomina dependencia total. Otra forma de expresar lo mismo es
decir que x e y son sinónimos; ambas expresiones son
equivalentes, en el ejemplo de tipos de claves, hay dependencia
total entre Número (de Cliente) y CUIT.
d) Completa – subtupla: El concepto de dependencia completa se

aplica solamente cuando:
• Se tienen más de dos atributos, y
• Un atributo dependiente depende de dos o más atributos
independientes.
Considérese una relación que abarca los atributos P, Q y

R. Supóngase que P es el atributo dependiente. Si el valor de P
está determinado por una función de Q y R combinados, se trata
de una dependencia completa. Esto es, el valor de P no depende
únicamente ni de Q ni de R.
Simbólicamente es: p = p (q, r)
En el ejemplo de análisis para determinar atributos

claves hay dependencia completa del atributo Can (cantidad
vendida) con respecto a los atributos claves #Fac (Número de
Factura) y Cod. (Código de artículo), esto es debido a que con
solo el número de la factura, no se puede determinar la cantidad
vendida, ya que en una misma factura se pueden vender iguales
cantidades de distintos artículos, con el código de artículo
tampoco se puede determinar la cantidad, ya que ésta (para un
artículo dado) puede ser diferente en distintas facturas.

e) Transitiva – múltiple: La dependencia transitiva se aplica o tres

o más atributos. Considérese el caso de solo tres atributos
denominados S, T y V. S es el atributo independiente si sus
valores determinan tanto a los valores de T como a V, y se
simbolizará así:
S → T; S → V
Sin embargo, sería deseable encontrar una relación más

restrictiva o definida. Se tendrá dependencia transitiva cuando S
determina a T y V, pero los valores de V pueden considerarse
siempre como dependiendo de los valores de T. Esto puede
escribirse como:
S → T; T → V ó v = v(t); t = t(s) v = v(t(s))
Ejemplo de transitividad:
Retomando el ejemplo anteriormente mostrado de dos
relaciones, Clientes y Ciudades:
Ciudades = {Código Postal, Nombre Ciudad}
Clientes = {Número, CUIT, Nombre, Dirección, Código

Postal}
Puede observarse que en la primera relación,

Nombre Ciudad depende de Código Postal, pero Código Postal a
su vez en la otra relación (Clientes) depende Número (de cliente).
De se puede decir que se da una transitividad entre Número y
Nombre Ciudad.
Número → Código Postal; Código Postal → Nombre

Ciudad
Como podrá apreciarse posteriormente, puede indicarse

que las claves foráneas en una tabla, son el término intermedio en
una transitividad.

¿Cómo Normalizar?
El objetivo de las tres primeras formas normales es
permitir la descomposición de relaciones sin pérdida de información, a partir
de las DFE y obtener así el esquema conceptual relacional normalizado.
Una Base de Datos para poder ser considerada racional

(no confundir con relacional), deberá estar normalizada hasta al menos la
tercera forma normal.
Primera forma normal (1FN): Una relación está en 1FN si todo atributo
contiene un valor atómico.
Ejemplos:
a) Auto ={Patente, marca, modelo, color}
Acá cada atributo es indiscutiblemente es atómico, sus

valores son perfectamente asignables a un Dominio determinado.
b) Facturación ={#Fac, Fecha, Tvta, Nombre, CUIT, Dir., Cod. , Des.,

Can, Cunit, Pvta}
Aquí en un análisis fino, podrá discutirse que los

atributos #Fac, Fecha, Nombre, CUIT y Dir. no serían atributos
atómicos (no divisibles) ya que por ejemplo #FAC, está formado
por la letra de la factura (A, B, C, etc.), cuatro dígitos que
corresponde a la sucursal (o equivalente) y 8 dígitos
correspondientes al número propiamente dicho, el Nombre puede
decirse que se descompone en Apellido y Nombre, el CUIT se lo
separa normalmente en 3 partes y Dir. (dirección) puede tener
varias partes (código postal, calle, numero, ciudad, etc.).
Justamente analizar estas relaciones con la mirada crítica

de encuadrarla en la 1FN permite detectar situaciones de análisis
no del todo completas. Pero los atributos arriba nombrados solo
podrán considerarse no atómicos (y por lo tanto fuera de lo que
es 1FN) solo si los requerimientos del SdI indiquen un manejo
de dichos atributos desmenuzados tal como se indico en el
párrafo anterior.
c) Estudiante ={legajo, apellido, nombre, materias, notas}

Acá es evidente que los primeros tres atributos son

atómicos, pero también es claro que los dos últimos no lo son, por lo
tanto la relación no está en 1FN. Para convertirla a 1FN se proyecta en
dos relaciones, obteniendo:
i) Estudiante ={legajo, apellido, nombre}

ii) Cursa ={legajo, materia, nota}
Segunda forma normal (2FN): Una relación está en 2FN si y solo si:
1) la relación está en 1FN y...
2) todo atributo que no pertenece a una clave no puede depender de una
parte de esa clave.
Ejemplo:
Facturación ={#Fac, Fecha, Tvta, Nombre, CUIT, Dir., Cod., Des., Can,
Cunit, Pvta}
Con las consideraciones sobre el ejemplo, que se hicieron

cuando se incluyo en 1FN, puede decirse que está en 1FN, pero es cierto
que se observan las siguientes DFE (Dependencias Funcionales
Elementales):
a) En un entorno no inflacionario:
i) #Fac → (Fecha, Tvta)
ii) #Fac → CUIT → (Nombre, , Dir)
iii) Cod. → (Des., Cunit, Pvta)
iv) (#Fac, Cod.) → Can
b) En un entorno inflacionario:
i) #Fac → (Fecha, Tvta)
ii) #Fac → CUIT → (Nombre, Dir)
iii) Cod. → Des.
iv) (#Fac, Cod.) → (Can, Cunit, Pvta)
Como la clave está formada por los atributos #Fac, CUIT

y Cod, puede verse que todos los atributos no dependen de toda
la clave (y aunque hubiese alguno) el solo hecho que alguno no
dependa de toda la clave es suficiente para que la relación
Facturación no este en 2FN, por lo que para que cumpla con
dicha forma normal, se deberán proyectar las siguientes
relaciones (se parte del ejemplo “no inflacionario”):

c) Facturas ={#Fac, Fecha, Tvta, CUIT, Nombre, Dir.}

d) Artículos ={Cod., Des., Cunit, Pvta}
e) Detalle ={#Fac, Cod., Can }
La segunda forma normal permite eliminar las

redundancias para que ningún atributo esté determinado por una
parte de una clave.
Tercera forma normal (3FN): Una relación está en 3FN si y solo si:
1) la relación está en 2FN y...
2) todo atributo que no pertenece a la clave no depende de un atributo que
no es clave.
Ejemplo:
Siguiendo con el ejemplo iniciado previamente puede
observarse que tanto la relación Artículos como Detalles, cumplen con
la definición de 3FN, pero no es el caso de Facturas:
Facturas ={#Fac, Fecha, Tvta, CUIT, Nombre, Dir.}
Donde se puede observar que se cumplen las DFE siguientes:
a) #Fac → (Fecha, Tvta)

b) #Fac → CUIT → (Nombre, Dir)
Para normalizar Facturas en 3FN se debe efectuar una nueva

descomposición en las siguientes relaciones:
c) Facturas ={#Fac, Fecha, Tvta, CUIT}

d) Clientes ={CUIT, Nombre, Dir.}
La tercera forma normal permite asegurar la eliminación de

redundancias debidas a las dependencias transitivas, y para ello se
tendrá en cuenta que:
3) Descomposición que preserva las dependencias funcionales: la

descomposición {R1, R2, ..., Rn} de una relación R preserva las DF de R,
si C+ de R es la misma que la de la unión de las DF de {R1, R2, ..., Rn}.
Toda relación R tiene al menos una descomposición en 3FN tal que:

a) la descomposición preserve las DF y...
b) la descomposición sea sin pérdida.

4) Algoritmo de descomposición en 3FN: Este algoritmo propuesto por

Bernstein en 1976 se basa en el principio siguiente: Se construye la
cobertura mínima C y a partir de la misma se editan los atributos
aislados, considerándolos como claves, luego se busca el conjunto más
grande X de atributos que determine a otros A1, A2, ..., An con n ≥ 1 y
como salida se genera la relación (X, A1, A2, ..., An). Las DFE utilizadas
en la formación de esa relación se eliminan de C y todos los atributos
aislados que no estén en las DFE que quedaron en C.
Procedimiento
Normalizar
3FN (DFE)
Repetir
C=cobertura At=Obtener Procedimiento Mientras Formar una R
minima de Atributos Reducir (1) c/atributos
las DFE Aislados (C, At) restantes en At
pertenece C
Formar Eliminar de C eliminar de C

Buscar Relacion las DFE las DFE
Conjunto mas R(X, A1 ,..., Ak utilizadas en R utilizadas en R
grande
X tal que
(1) 1 DFE en C NO -> todos los atributos o C este vacio
X -> A 1,...
X -> Ak
Procedimiento Normalización 3FN (DFE) (Gráfico 2)5
Forma normal de Boyce-Codd (FNBC): Una relación está en FNBC si y

solo si las solas DFE son aquellas dentro de las cuales una clave determina un
atributo.
5
Diagrama Metodología LCP, derivada en Warnier-Orr y Jackson.

Ejemplo:
a) Examen ={Legajo, Materia, Profesor, Nota} está en 3FN
b) (Legajo, Materia) → Profesor no está en
FNBC si
c) Profesor → Materia cada profesor dicta
d) (Legajo, Materia) → Nota una única materia
para resolver el problema se proyecta para que cumpla con la FNBC:
i) Examen ={Legajo, Materia, Nota}

ii) Dicta ={Materia, Profesor}
Pero No se preserva la DFE (Legajo, Materia) → Profesor
En general, la descomposición en FNBC es sin pérdida

pero NO preserva las DFE, después ellas pueden obtenerse por reunión
o producto.
Cuarta forma normal (4FN): Para definir 4FN deben dejarse en claro los
siguientes conceptos:
1) Dependencias multivaluadas (DM): Sea R(A1, A2, ..., A n) y X e Y dos

subconjuntos de atributos de {A1, A2, ..., An}. Se dice que X −» Y, si
dados los valores de X hay un conjunto de valores Y asociados y este
conjunto es independiente de otros atributos Z = R – X – Y de R,
entonces:
a) Las DM caracterizan la independencia entre
Y y Z correlacionadas por X y...
b) Las DF son un caso particular de las DM,
por lo cual X → Y ⇒ X −» Y
2) Dependencias multivaluadas elementales (DME): Una DME es una

DM X −» Y de una relación R tal que:
a) Y no es vacío y es disjunto de X y...

b) R no contiene otra DM del tipo X’ −»Y’ tal que X’ ⊂ X e Y’ ⊂ Y
Ejemplo: EstMatDeporte (Legajo, Materia, Deporte)

EstMatDeporte Legajo Materia Deporte

3101 ‘Contabilidad ‘tenis’
’
2101 ‘Contabilidad ‘natación’
’
4105 ‘Álgebra’ ‘tenis’
3132 ‘Informática’ ‘fútbol`
Tabla 6
Legajo −» Materia, Legajo −» Deporte, pues un

estudiante puede cursar varias materias y puede practicar varios
deportes, pero Materia es independiente de Deporte y en este caso solo
están correlacionados a través de Legajo.
Definición 4FN: Una R está en 4FN si y solo si las solas DME

son aquellas donde una clave determina un atributo. Una R en 4FN está
en 3FN y en FNBC.
Ejemplo: EstMatDeporte ={Legajo, Materia, Deporte} no está en

4FN, por lo que se proyecta según sus DME como:
i) Cursa ={Legajo, Materia}

ii) Practica ={(Legajo, Deporte}
6) Teorema de Fagin (1979): R(A, B, C) se puede descomponer sin

pérdida en R1(A,B) y R2(A, C) si y solo si se cumplen en R las DM A −»
B | C. Demuestra que toda R tiene una descomposición, no siempre
única, en 4FN sin pérdida de información.
Ejemplo: Curso ={IdCurso, Profesor, Texto)
Curso IdCurso Profesor Texto

‘Sistemas’ ‘Zutano’ ‘Fundamentos Base de Datos’
‘Sistemas’ ‘Zutano’ ‘Ingeniería de Software’
‘Sistemas’ ‘Mengano’ ‘Fundamentos Base de Datos’
‘Sistemas’ ‘Mengano’ ‘Ingeniería de Software’
Tabla 7
IdCurso −» Profesor, IdCurso −» Texto

Se proyecta como:
iii) TextoMateria ={IdCurso, Texto}

iv) DictadaPor ={IdCurso, Profesor}
Dependencias de productos (DP o 5FN): Existen relaciones que no es

posible descomponerlas en 2 relaciones, pero si en 3, 4 o más relaciones. Sea
R(A1, A2, ..., An) y X1, X2, ..., Xm subconjuntos de {A1, A2, ..., An}. Se dice
que existe una DP simbolizada por *{X1, X2, ..., Xm} si R es el producto de
sus proyecciones sobre X1, X2, ..., Xm, es decir si R = Π X1( R ) Π X2( R ) ...
Π Xm( R )
Ejemplo: Si los Proveedores suministran Piezas y en los
Proyectos se utilizan Piezas y los Proveedores además suministran piezas a
los Proyectos, entonces los Proveedores suministran Piezas a los Proyectos.
Suministros ={ Proveedor, Pieza, Proyecto} está en 4FN
Suministro Proveedor Pieza Proyecto

INTEL Pentium II NoteBook
INTEL Pentium III Super PC
IBM Pentium II Super PC
INTEL Pentium II Super PC
Tabla 8
No está en 5FN pues Proveedor −» Pieza, Pieza −»

Proyecto, Proyecto −» Proveedor, no es posible descomponerla en 2
relaciones, pero si es posible en 3 relaciones, así:
Distribuyen Proveedor Pieza

INTEL Pentium II
INTEL Pentium III
IBM Pentium II
Tabla 9
Usan Pieza Proyecto

Pentium II Super PC
Pentium III NoteBook
Pentium II Super PC
Tabla 10

Proveen Proveedor Proyecto

INTEL Super PC
INTEL NoteBook
IBM Super PC
Tabla 11
Suministro ≠ Distribuyen ∪ Usan,

Suministro ≠ Distribuyen ∪ Proveen,
Suministro ≠ Usan ∪ Proveen,
Suministro = Distribuyen ∪ Usan ∪ Proveen
Entonces una relación R está en 5FN (Quinta forma

normal) si y solo si toda DP está implicada por las claves candidatas de R.
En la realidad no es común tener DP y es muy difícil darse cuenta de su
existencia, Fagin presentó en 1979 un algoritmo para probar si una DP está
implicada por un conjunto de claves en R.
Hay otras formas normales mencionadas en la

bibliografía, que aquí no se desarrollarán por que van más allá del alcance de
este trabajo, estas formas normales son (entre otras):
 Normalización por medio de Dependencias de

Intersección.
 Forma Normal de Dominio-Clave

Conclusiones de normalizar con formas normales:

El uso de los métodos de normalización, implica conocer,
identificar y aplicar los conceptos de DF (dependencias funcionales) y DFE
(dependencias funcionales elementales), más una serie de conocimientos
sobre álgebra relacional.
Hay autores que consideran por ejemplo que la 2FN solo

tiene interés histórico, y otros investigadores indican que algunos de los
fundamentos matemáticos de algunas de las formas normales más avanzadas
tienen algunos “fallos”, los cuales están en proceso de determinación.
La aplicación de las formas normales para normalizar

base de datos, pueden considerarse que no son aplicables por el profesional
contador, ya que implica una preparación muy específica, que van más allá de
la intervención del contador en el desarrollo o evaluación del diseño de las
bases de datos.
Por los conocimientos propios de mi especialización en el

diseño de bases de datos, pude inferir que debían analizarse otras
metodologías que sirvieran al contador en su intervención en el diseño y
evaluación de los SdI.
De allí que procedo a elaborar la presente investigación

analizando otras metodologías como son el caso de los modelos semánticos.

Modelos Semánticos:
Introducción:
Los modelos semánticos capturan un mayor significado
de los datos e intentan representar la estructura real de los datos
independientemente de las características de almacenamiento, es decir ellos
están orientados a las aplicaciones. Existen, hoy en día, numerosos y muy
variados modelos semánticos, entre ellos se encuentran: el modelo Entidad-
Relación de P. Chen, el modelo Entidad-Relación-Extendido (ERE) de
Teorey y el modelo IFO propuesto por Abiteboul. De los modelos anteriores
solo será tratado el segundo de ellos en detalle más adelante.
Los modelos básicos constituyen el grupo de modelos

que han sido diseñados orientándose al computador, sobre ellos se han
desarrollado la mayoría de los SGBD. Ellos son: el modelo jerárquico, el
modelo de redes, el modelo relacional, el modelo orientado por objetos y el
objeto-relacional.
Muchos modelos semánticos han sido propuestos, pero

pocos de ellos han atraído el interés de los desarrolladores de sistemas de base
de datos, esto tal vez es debido a la complejidad de tales modelos y a su
dificultad para ser plasmados con los modelos básicos actuales. La mayoría
de los conceptos del modelado semántico de datos han sido muy bien
representados en el modelo ERE, el cual goza de gran prestigio y popularidad
en el ambiente comercial, jugando un rol muy importante en la mayoría de las
herramientas CASE (Computer Aided Software Engineering, Ingeniería de
Programación Asistido por Computadoras).
Modelo Entidad-Relación-Extendido (ERE)
El modelo Entidad-Relación (E-R) propuesto por P. Chen

fue la primera versión del modelo ERE. Dicha primera versión se fue
modificando con el paso del tiempo debido a la necesidad de tener
constructores más adecuados para la gran diversidad de aplicaciones que
existen hoy en día en el área de las bases de datos.
Así, la proposición de P. Chen ha sido modificada y

enriquecida semánticamente por otros autores. Debido al gran poder
expresivo que tiene hoy en día, este modelo es el primero en popularidad y en
utilización en la etapa de diseño conceptual de base de datos. En este modelo
se emplea el enfoque de diseño de arriba-hacia-abajo y los conceptos de
abstracción de datos.

El modelo ERE representa la información por medio de

tres conceptos básicos:
 entidades,
 relaciones y
 atributos.
Su principal objetivo es producir vistas conceptuales de

los datos de la aplicación. Cada vista se expresa en términos de los conceptos
básicos ilustrados en los diagramas ERE. El modelo está basado en la teoría
de conjuntos y en la teoría de las relaciones.
Entidad, según el diccionario Larousse, es "lo que

constituye la esencia del ser ó colectividad considerada como una unidad".
Para los efectos de las aplicaciones en base de datos:
Una entidad puede ser un objeto como: una casa,

una planilla, un Auto, etc.; un sujeto como una
persona; o un evento o actividad como: un
partido de fútbol, un viaje, etc.
Las entidades se agrupan en conjuntos denominados

conjunto entidad y se representan en los diagramas ERE como un rectángulo
con el nombre del conjunto entidad dentro. En el Gráfico 2 muestra un
ejemplo de dicha representación.
Personas Viviendas
Conjuntos entidad en los diagramas ERE (Gráfico 3)
Una misma entidad puede pertenecer a varios conjuntos

entidad. Por ejemplo, una persona puede pertenecer a los conjuntos entidad
Clientes y Empleados.
Una relación es una asociación entre dos o más entidades

de un mismo tipo o de tipos diferentes. Las relaciones o asociaciones también
se agrupan en conjuntos, recibiendo el nombre de conjunto relación. Los
conjuntos relación se representan gráficamente por medio de un rombo que
encierra el nombre asociado al conjunto relación especificado. Ejemplos de

estos son: propietario que asocia una vivienda a una persona, dicta que asocia
un profesor con una materia, etc., ver ejemplos en el gráfico 4:
1:1 1:N
Personas Propietario Viviendas
1:1 1:N
Profesor A cargo Materias
Relaciones entre poblaciones (Gráfico 4)
En estos gráficos también se refleja los tipos de

correspondencia entre los conjuntos entidad asociados por el conjunto
relación Propietario o A cargo y la cardinalidad de dicha relación.
Los tipos de correspondencia se refieren al número de

entidades involucradas en la relación, en un sentido y en el sentido contrario.
Así:
 1:1 Una entidad del conjunto entidad 1 (C-E1) está asociada a una única
entidad del C-E2.
 1:N o N:1 Cada entidad del C-E1 está asociada a cero, una o más
entidades del C-E2 o viceversa.
 N:M Cada entidad del C-E1 está asociada a cero, una o más entidades
del C-E2 y viceversa.
Representación gráfica de la cardinalidad.
1:1 1:N
1:1 1:N
Relación entre poblaciones con Cardinalidad (Gráfico 5)

La cardinalidad de la relación o asociación entre dos

entidades expresa el número mínimo y máximo de entidades relacionadas a
través del conjunto relación, en el gráfico superior del par anterior, se usa una
flecha de punta simple para indicar el lado de los unos, y flecha de punta
doble para indicar el lado de los muchos. En el segundo gráfico se utiliza una
pequeña línea perpendicular, para indicar el lado de los unos y tres líneas
(“pata de gallo”) para indicar el lado de los muchos. En este segundo caso, se
usa un pequeño circulo, para indicar que la relación podría no existir para
algunas personas (las que no son propietarios de viviendas).
Una entidad se describe por medio de sus atributos y una

relación puede también ser descrita por medio de atributos. Un atributo es
una característica o propiedad específica de una entidad o de una relación.
Cada atributo se identifica con un nombre y se le asocia un dominio de
valores posible que puede tener en un momento particular. Los atributos se
expresan en el modelo E-R con nombres que etiquetan las aristas entre el
conjunto entidad o relación a que pertenecen y el dominio asociado al mismo.
Los dominios se expresan con óvalos identificados con un nombre, que es el
nombre del dominio. En el gráfico 6 completa el diagrama mostrado en el
gráfico 5:
Nomenclatura
Nombres
NomCatas
Nombre
Documentos
Importes Superficies
DocPer
Valuación Metros2
PERSONAS PROPIEDAD VIVIENDAS
DirPer FecCompra DirVivienda
TelPer CatViv
Fechas
FecNacio
Telefonos
Categoria
Direcciones
Diagrama E-R con incorporación de atributos (Gráfico 6)

Una clave6 de un conjunto entidad o relación es un grupo

de uno o más atributos que identifican unívocamente cada entidad o relación
del conjunto. La clave de un conjunto relación es siempre la concatenación de
las claves de los conjuntos entidad que ella asocia. En el gráfico 6 se observan
las claves de cada conjunto entidad y de la relación propietario. En forma más
extensa, los conceptos de clave se vertieron en este trabajo en la sección
“Antes de Normalizar. Conceptos Básicos. Clave de la Relación” (punto
10) en página 15).
Un conjunto entidad es débil si su existencia depende de

otro conjunto entidad. De igual manera, un conjunto relación es débil si él
depende de otro. El gráfico 7 presenta un ejemplo de diagrama donde se
observan ambos casos. Un objeto del conjunto “Detalle Factura” existe en la
Base de Datos si existe la entidad Factura del conjunto Facturas. Asimismo, la
relación clave-obj existe si la relación vista-obj existe.
TotFac
Precio Importes
C.U.I.T.s
NFact Numeros NroFacDet
CodArtVen
Facturas
Costo
CUITCli
(1,0 o 1) (1,N) DETALLE (N,1) Vendido

FACTURAS Se Vende
FACTURA en
FecFac RenglonD
CantVend (1,0 o 1)
Numeros Stock Codigo

Fechas
Renglones
Cantidades ARTICULOS C o d A r t Articulo
RenglonP CantPed (1,0 o 1)
FecPed
(1,0 o 1) Pedido (1,N) DETALLE (N,1) Obtenido

PEDIDOS
CUITPro en PEDIDO desde
NumPed CodArtPed
Numeros
Pedidos NumPedDet
Entidades y relaciones débiles en un diagrama ERE. (Gráfico 7)
6
en Ingles Key, algunos autores traducen también como llave, que es otra acepción de dicha palabra, pero entiendo
que en un entorno de datos, clave es el valor para acceder o identificar un registro en un archivo, la llave sería mas
aplicable a un entorno de seguridad, “la llave de acceso”,y en el diccionario de Simon and Schuster se dan 9 posibles
traducciones del término KEY al castellano.

Modelo Objeto-relacional
Este modelo es básicamente el mismo modelo relacional
extendido con algunas facilidades del modelo orientado por objetos, a saber:
 Pueden crearse nuevos tipos de datos (inclusive del tipo compuesto)

siempre y cuando se dispongan de métodos de transformación del
nuevo tipo a ASCII7 y viceversa, los nuevos tipos complejos pueden
ser alguno de los siguientes:
o Registros: P.ej.: Equivalente a filas o conjunto de campos.
o Conjuntos. P.ej.: Para manejar la existencia o no distintos
atributos, que pueden existir conjuntamente o no.
o Referencias. P.ej.: Apuntadores a otros elementos.
o Listas. P.ej.: Conjunto de elementos, ordenados o no.
o Pilas. P.ej.: Para administrar procesos lógicos en orden LIFO.
o Colas. P.ej.: Para administrar procesos lógicos en orden FIFO
o Arreglos. P.ej.: El uso de arreglos es muy amplio.
 Se pueden crear funciones que tengan un código en algún lenguaje

de programación, por ejemplo: SQL, Java, C, etc.
 Se pueden crear operadores asignándole un nombre y asociándoselo
a una función ya definida o creada con anterioridad.
 Se soporta el encadenamiento dinámico y herencia en los tipos tupla
o registro.
 Posibilidad de incluir el chequeo de las reglas de integridad
referencial a través de los triggers (desencadenantes y/o disparadores).
 Soporte adicional para seguridad y activación de la versión cliente-
servidor.
Transformación de modelos de alto a bajo nivel

Las reglas de transformación del modelo ERE al modelo
relacional son las siguientes:
 Cada conjunto entidad se convierte en un esquema de relación constituido

por todos los atributos del conjunto entidad.
 Cada tupla en la relación es una entidad del conjunto entidad.
 La clave primaria de la relación es la misma del conjunto entidad.
 Ejemplo: Usuario ={IdUsusario, NombreUsuario, ApellidoUsuario,

DepartamentoUsuario}
7
ASCII: Código de Intercambio Estándar Americano. Se usa para codificar los símbolos (letras, números, símbolos de
puntuación y otros símbolos utilizados en computadores, es el más difundido en entornos de Computadoras Personales,
en entornos de MainFrame IBM, es de uso común el EBCEDIC, y en la actualidad se empieza a usar el UNICODE, que
soporta los símbolos utilizados por casi todos los lenguajes humanos.

NombreUsuario
ApellidoUsuario
Departamento_Usuario
IdUsuario
Usuarios
Entidad y sus Atributos (Gráfico 8)
 Cada conjunto relación entre los conjuntos entidades que asocia se

convierte en un esquema de relación cuya clave primaria es la
concatenación de las claves primarias de los conjunto entidad que ella
asocia y sus atributos no clave son los mismos del conjunto relación
tratado.
 Ejemplo:
Préstamos ={ISBN, IdUsuario, Fecha_Prestamo, Fecha_Devolución}
Titulo
ISBN IdUsuario
Fecha_Prestamo
NombreUsuario
Año
Libros Prestamos Usuarios
ApellidoUsuario
Fecha_Compra Fecha_Devolucion
Editorial Departamento_Usuario
Esquema de la Relación del Ejemplo anterior (Gráfico 9)
 Los conjuntos de valores del diagrama ERE se convierten en los dominios

del modelo relacional.
 Los conjuntos entidades débiles se convierten en esquemas de relación con

clave primaria igual a la concatenación de la clave primaria del conjunto
entidad fuerte del cual depende con algún atributo propio del conjunto

entidad débil que sirva para identificar unívocamente cada tupla de la

relación.
 Cada especialización es una tabla con los atributos de la especialización y

con clave la del conjunto entidad general.
 Ejemplo:
 TrabajadorUniversitario ={ Legajo, Nombre, Apellido,

Fecha_Ingreso},
 Profesor ={ Legajo, Categoría, Dedicación, Fecha_Categoria,

Fecha_Dedicación),
 Empleado ={Legajo, Grado, Fecha_Grado, Especialización)
NombreUsuario ApellidoUsuario Fecha_Ingreso

Legajo
Categoria Dedicacion Trabajador Grado

Universitario
Profesores d Empleados
Fecha_Dedicacion Fecha_Categoria Fecha_Grado Especializacion
Esquema de Especialización (Gráfico 10)
 Una categoría es una subclase de la unión de dos o más superclases, por lo

que se crea una clave para la categoría, y se coloca en las tablas de las
superclases, si ellas tienen diferentes esquemas. Si las superclases tienen
la misma clave, no es necesario utilizar la clave nueva o clave sustituta.
 Ejemplo:
 Personas ={Documento, Nombre, Apellido, Nacimiento,

Dirección, Teléfono, IdDueño),

 Bancos ={IdBanco, Nombre, Dirección, Teléfono, IdDueño},
 Empresas ={IdEmpresa, Nombre, Dirección, Teléfono, IdDueño}
con la categoría Dueños ={IdDueño}
Personas Ba ncos Empresas
Propietarios
Esquema de Categoría (SubClase) Gráfico 11
<- Agregacion
AVION
Herencia Simple TREN DE

ALAS
ATERRIZAJE
AVION AVION AVION DE

MOTOR FUSELAJE
DE CARGA MILITAR PASAJEROS
CAZA BOMBARDERO TRANSPORTE

Ejemplo de Clases,
Herencia Multiple Herencia Simple y Multiple,
y de Agregaciones
CAZA-
BOMBARDERO
Clases, Tipos de Herencias y Agregaciones (Gráfico 12)

Un conjunto entidad puede especializarse en otros

conjuntos entidad mostrando los diferentes tipos de ese conjunto entidad.
Asimismo, varios conjuntos entidad pueden generalizarse en un conjunto
entidad genérico, en cuyo caso el proceso de abstracción realizado se
denomina generalización y en el primer caso se denomina especialización.
En estos casos y desde un punto de vista de Orientación a

Objetos, se tiene Herencia. Si al generalizar se encuentran más de dos clases
superiores, se tiene Herencia Múltiple y cuando se descompone una entidad
en partes (entidades componentes), se cuenta con una Agregación.
Sin importar el proceso de abstracción realizado, el hecho

es que existe en el diagrama un conjunto entidad que es una superclase (en el
ejemplo del gráfico 12 es el caso de AVIÓN) otros conjuntos entidad
denominados subclases (AVIÓN DE CARGA, MILITAR y TRANSPORTE),
los cuales heredan de la superclase todos sus atributos. La herencia puede ser
simple (los casos citados) o múltiple (CAZA-BOMBARDERO), bien sea que
herede de un solo conjunto entidad o de varios, respectivamente.
Se especifica una agregación, cuando una Entidad (o

clase), está compuesta por otras entidades, que tienen sus propios atributos y
en el entorno de Orientación a Objetos, su propios métodos, e incluso su
propia estructura jerárquica de Herencias, un ejemplo no graficado sería que
MOTOR, hereda atributos (es una subclase) de una superclase llamada,
MAQUINAS, también puede decirse que AVIÓN es una subclase de
MAQUINAS, y esta ultima, una subclase de invenciones del hombre, etc.
Todo depende hasta donde se quiere llevar el proceso de análisis.
En el gráfico 13 puede observarse un modelo más

complejo de objetos con herencias múltiples. Las cuentas del Activo, Pasivo,
Patrimonio Neto y Resultado, heredan tanto características de las Cuentas
Contables por un lado o de las Cuentas Resumen o Cuentas con Asientos por
el otro.
Además puede decirse que las Cuentas Contables resulta

de la agregación de Cuentas Resumen y de Cuentas con Asientos. Recuérdese
que en la simbología utilizada, el rombo significa agregación, el triangulo
herencia y la flecha que llega al rombo está indicando que hay una herencia
múltiple.
Otro ejemplo de Agregación se dispone en el gráfico 14,

que es otra forma de ver la parte correspondiente a factura en el gráfico 7.

Ejemplo de:
Cuentas
Herencia Multiple
Contables
y Agregacion
Cuentas
Cuentas c/
Resumen
Asientos
Patrimonio
Activo Pasivo Resultado
Neto
Ejemplo “Contable” de Herencia Múltiple y Agregación (Gráfico 13)
Facturas
FechaVenta
ImporteIVA
NombreCliente
TotalFactura
NumeroFactura
Cabecera Detalle Pie

Factura Factura Factura
CUITCliente
CondicionesVenta
Direccion
NumeroRenglon Cantidad
PrecioUnitario Descripcion CodigoProducto
Ejemplo de Agregación (Gráfico 14)

Reglas Practicas:
Relevamiento de los requisitos del Sistema de Información:
Cuando se encara el diseño de una base de datos para un

sistema de información, se debe proceder primero a efectuar el relevamiento
de los datos requeridos por el sistema.
Del análisis efectuado, se conocerá la interacción entre

las entidades intervinientes, los flujos de datos necesarios para dicha
interacción y por supuesto, como todo Sistema, tendrá una interacción con el
entorno, por lo que deberá tenerse en cuenta los flujos de datos entran y salen
desde y hacia dicho entorno.
Según Roger S. Pressman, luego de evaluar distintas

metodologías para el análisis y el diseño de sistemas, propone las siguientes
etapas o actividades respectivamente:
1) Para el análisis:
a) Obtener los requisitos del cliente para el SdI.
i) Identificar escenarios o casos de uso.
ii) Construir un modelo de requisitos.
b) Seleccionar clases y objetos usando los requisitos básicos como
guías.
c) Identificar atributos y operaciones para cada objeto del sistema.
d) Definir estructuras y jerarquías que organicen las clases.
e) Construir un modelo objeto-relación.
f) Construir un modelo objeto-comportamiento.
g) Revisar el modelo de análisis.
2) Para el diseño:
a) Describir cada uno de los subsistemas de manera que sean
implementables:
i) Asignar subsistemas a procesadores y tareas.

ii) Elegir una estrategia de diseño para la implementación de

la gestión de datos, soporte a interfaz y la gestión de tareas.
iii) Diseñar un mecanismo apropiado de control para el
sistema.
iv) Revisar y considerar intercambios.
b) Diseño de Objetos:
i) Diseñar cada operación a nivel procedimental.
ii) Definir toda clase interna.
iii) Diseñar estructuras de datos internas para los atributos de
clase.
c) Diseño de mensajes:
i) Diseñar el modelo de mensajes a partir del uso de
colaboraciones entres objetos y objeto-relación.
d) Revisión del modelo de diseño e iterar siempre que sea necesario.
Por supuesto que todos estos pasos corresponden a las

actividades de un ingeniero del software, por lo que solo se tratará de
establecer reglas prácticas orientadas a aportar soluciones a los pasos del
análisis en el paso 1)e) y 2)b)iii) y como se planteó como objetivo inicial,
acotado a pequeñas bases de datos, con análisis y diseño a efectuar por
Contador Profesional, para solucionar SdI que pueden presentarse en un
estudio contable o en el manejo de una PyME.
Estas reglas, en principio deberán poder ser aplicables a

implementar SdI sobre algún S.G.B.D. como Access de Microsoft o BASE de
Sun (incorporado al paquete StarOffice) o aún en planillas de cálculo, si el
usuario tiene un adecuado manejo de macros o del lenguaje de programación
subyacente.
Definir los objetivos del SdI, es un prerrequisito antes de empezar

aplicar las reglas propuestas. Esta es una actividad previa, cuyos pasos u
objetivos se indican mas adelante, esta actividad no se considera dentro de las
reglas porque está fuera del alcance de lo objetivo de este trabajo. Esta
definición o relevamiento inicial del SdI puede elaborarse a partir de8:
8
No se pretende en este trabajo establecer o determinar cuales son las mejores metodologías que deben aplicarse para
llevar a cabo el análisis del sistema, en todo caso el objetivo de esta regla, es lograr adquirir el suficiente “conocimiento”
del sistema para poder confeccionar las planillas y gráficos que se indican en la regla número tres.

a) Entrevista a los usuarios actuales o futuros del sistema.

b) Conocimientos sobre los requerimientos del SdI por parte del
contador (descripción de entradas, procesos y salidas).
c) Documentación utilizada como entrada, intermedia (interna o para
feedback), o generada por el sistema actual (sea un sistema manual
o uno computarizado al que se quiere hacer mantenimiento
adaptativo o correctivo).
d) Cualquier otra técnica conocida por el profesional contador para
determinar estado actual del SdI, y cuales son los requerimientos
para informatizarlo. Entre dichas técnicas pueden ser de aplicación
el Diagrama de Flujo de Datos (DFDs9), de Entidad y sus
Relaciones (DERs, DEREs10) u orientado a objetos (diagramas de
clases) para conocer la estructura del sistema, sus elementos
componentes (entidades) y la interrelación entre las partes
(relaciones).11
Presentadas las Formas Normales (basadas en lógica

Matemática), los modelos semánticos (basados en interpretación de texto
descriptivo del sistema) y los pasos para obtener el knowledge (conocimiento)
del SdI, se desarrollan a continuación las reglas de normalización prácticas,
objetivo de este trabajo de investigación, haciéndose referencia a los
conceptos vertidos a lo largo del trabajo, de manera tal de que cada regla
tenga los fundamentos correspondientes.
Para cada regla se indicará si corresponde un ejemplo

pequeño, que aclare la interpretación de la regla correspondiente (o el
objetivo de la misma), posteriormente se desarrollaran algunos casos
prácticos, de manera que se pueda apreciar la aplicación de dichas reglas.
9
Diagramas de Flujo de Datos.
10
Diagramas Entidad-Relación y Entidad-Relación Extendidos entre otros.
11
Tampoco aquí se quiere hacer un compendio de técnicas aplicables para el diseño del SdI, pero entiéndase que los
diagramas indicados pueden ser herramientas útiles para lograr una compresión de dicho SdI ayudando a determinar
las entidades, sus atributos y las reglas de negocio correspondientes, que permitan llevar a cabo los pasos indicados a
partir de la regla 3 en adelante. Después de todo, el diseño de la base de datos es parte del “diseño” del SdI.

Las reglas propuestas son las siguientes:

Tabulación de Entidades, sus Atributos y Relaciones
1) Tabulación de Entidades, sus Atributos y Relaciones: A
partir del conocimiento obtenido en el relevamiento del sistema, deberán
confeccionarse planillas donde se vuelquen los distintos datos obtenidos
de entidades, relaciones y atributos. En la aplicación de las reglas, deberá
adoptarse un proceso cíclico, el cual se repetirá tantas veces como sea
necesario hasta lograr que los controles de diseño que se establecen en
estas reglas se cumplan. Dichas planillas se contendrán los datos que se
indican a continuación:
a) Planilla Entidades: que incluirá aquellas que se hayan detectado en
los citados pasos previos. Las entidades son los conjuntos de ítems
que se entienda o deduzca que existe por si mismos o dependiendo
de otros. Por cada conjunto homogéneo de entidades se deberán
indicar los siguientes datos12:
i) Identificador Conjunto Entidad (ICE): se utilizará para ello
el sistema de nombrado de identificación de columnas de los
programas de planillas de cálculo, o sea letras mayúsculas a
partir de la A. Puede también utilizar como ICE la inicial del
nombre de la entidad, en el caso de que se repitan, se reservará
la inicial para la entidad más significativa13, este ICE se usará
para referencias en las tablas siguientes y en documentación a
confeccionar posteriormente.
ii) Nombre Conjunto Entidad: Un nombre apropiado, no muy
largo (no más de 15 caracteres), que el conjunto entidad
represente. Pueden establecerse las siguientes pautas para la
formación del nombre de una entidad:
(1) Concreto, conciso y representativo del tipo de entidades
que el conjunto representará. Básicamente la idea es que el
conjunto sea el plural del nombre singular de las entidades
que comprende. En el caso de que el conjunto tenga un
nombre especifico, será preferible usar este, con tal de lograr
la mayor claridad. Por ejemplo, para representar las cuentas
del plan de cuentas de la contabilidad, PlanCuentas será
mejor nombre que usar Cuentas.
12
El concepto y definición de entidades puede revisarse a partir de los conceptos vertidos en el presente trabajo en el
punto Modelos Semánticos, Modelo Entidad Relación Extendido en página 33 y s.s.
13
Téngase en cuenta que si fuesen más de 26 conjuntos entidades, se estaría posiblemente ante un modelo de base
de datos que no sería normalizado por un contador, esto no invalida las reglas para aplicarlo a bases de datos de mayor
tamaño.

(2) Si el nombre se hace muy largo, en el caso de nombres

compuestos, podrán utilizarse abreviaturas de uso
generalizado para reemplazar parte o todo el nombre.
(3) Excluir del nombre todos los artículos, preposiciones y
espacios en blanco14, para reducir su largo. Al eliminar los
elementos indicados en la frase anterior, conviene por
razones de claridad que las palabras incluidas en el nombre
de la entidad (si hay más de una), mantengan su primera
letra en mayúsculas y el resto en minúsculas.
iii) Descripción Entidad: Una descripción no muy extensa que
especifique que elementos integran la entidad que se representa
con el conjunto, y alguna otra característica que pueda
considerarse de ayuda para evaluar la entidad como fuerte ó
débil15 (dicho carácter se especifica en la columna siguiente):
iv) Carácter de la Entidad: Si es Fuerte (F), Débil (D), o
Dominios de Valores (V), donde, para cada caso debe
considerarse:
(1) Entidades del tipo “fuerte” son aquellas donde cada ítem
que las constituyen existe independientemente de la
existencia de otro ítem en otra entidad o población, p.e.
Clientes, Artículos, etc.. Representan elementos de los que
se necesitan almacenar datos, administrarlos, controlarlos,
etc. de acuerdo a los requisitos del SdI.
(2) Son entidades del tipo “débil” cuando la existencia de
cada ítem componente depende de la existencia de otro
elemento (ítem, instancia, etc.) en una única entidad fuerte,
ya sea directamente o por carácter transitivo, en estos casos
deberá indicarse además cual es la entidad previa en la
jerarquía de dependencia16. Si dependiese de más de una
Entidad fuerte, sería una relación entre entidades.
(3) Se consideran “dominios de valores” aquellas entidades
que contienen listas de valores posibles para un atributo, y
que por sus características no pueden ser representados por
14
Aunque muchos de los S.G.B.D. actuales admiten blancos dentro del nombre de las tablas, cuando estos se usan,
dificultan las referencias a dichas tablas al utilizarlas en consultas o con lenguajes de acceso a datos (SQL), implicando
utilizar elementos separadores adicionales, como corchetes, llaves o comillas, dificultando su escritura y haciendo
perder la claridad que se pretendía obtener en la visualización del nombre con la inclusión de dichos blancos.
15
Las relaciones van tabuladas en la planilla que se describe a continuación de la actual.
16
Esto puede observarse en diagramas de “Agregación” de Diseño Orientado a Objeto, que permitirá detectar mejor
aquellas entidades que tengan una estructura con varias partes. Ver conceptos en página 36 y en gráficos 7 y 14. p.ej.
TeléfonosClientes, necesita a Clientes, DetallesFacturas a Facturas, etc., para el caso de transitividades, Apartados
necesita Capítulos y estos Libros, en este caso Libros es la entidad fuerte, y Capítulos y Apartados las entidades
débiles).

una expresión matemática, y que también tienen asociados

alguna descripción complementaria aclaratoria. Como
ejemplos se tendrían aquí Tipos de Documentos, Códigos
Postales, etc. Estas entidades no son principales para el SdI,
pero son necesarias para hacer más ‘descriptivo’ al mismo.
v) Documentación Fuente: Deberá anotarse aquí referencias a las
especificaciones obtenidas al hacer el relevamiento del sistema
(documentos, narraciones, diagramas etc.) que se utilizan para
inferir la entidad presente.
b) Planilla Relaciones: que contendrá datos de Relaciones17 entre las
entidades de la planilla anterior. Las relaciones en general, no
tendrán atributos propios, la excepción son del tipo muchos a
muchos entre entidades que si pueden tener atributos descriptivos
propios, y aún no teniéndolos, al instrumentarse en una base de
datos con Arquitectura Relacional, tendrá que indefectiblemente
crearse una tabla ad hoc.
Es fácil confundir una entidad débil con una relación muchos a

muchos, pero estás ultimas necesitan de un ítem en al menos otras
dos poblaciones, o de dos ítems distintos en una mismo conjunto de
entidades. Excepcionalmente una entidad débil puede tener una clave
propia completa, no tan difícil que tenga una clave parcial y lo
normal es que no tenga clave propia. Dicha planilla tendrá los
siguientes datos:
i) Identificador Relación: El identificador de la relación se
establecerá por medio de una numeración correlativa en sistema
numérico romano en minúsculas (i, ii, iii, iv...), para referenciar
el mismo en documentación a confeccionar posteriormente (y
no confundirlo con denominaciones de entidades, que se indico
que se usen letras mayúsculas).
ii) Nombre de la Relación: En general se pondrán los
nombres de las entidades que relacione separadas por un verbo
que indique o explique la relación (Ubicado en, Posee, Tiene,
Contiene, etc.), pero este no es importante, salvo que sea una
relación muchos a muchos, en dichos casos pueden seguirse las
siguientes pautas para la formación del nombre de una relación:
(1) Si a la relación se le conoce algún nombre en concreto, es
preferible utilizar el mismo (por ejemplo una de las
relaciones muchos a muchos entre Alumnos y Materias,
17
Ver conceptos en página 33 y s.s., además gráficos 4 a 9.

puede denominarse Exámenes, otra puede ser Asistencias),

en caso contrario, deberá utilizarse preferentemente una
denominación que mencione las tablas relacionadas.
iii) Una vez determinado el nombre de la relación, pueden
aplicarse el resto de los lineamientos indicados para el nombre
de Entidades.
c) Tipo de Relación: En este caso se propone utilizar la siguiente
metodología de codificación (al menos en este trabajo) de la forma
R(lCEde w x : y z ICEa) donde:
(1) ICEde: es el identificador del conjunto entidad origen de
la relación, asignado en el tabulado de entidades [1. a) i)]. Si
se tiene una relación donde intervienen tres o más entidades,
se definirá una relación entre un par cualquiera de las
entidades intervinientes, y luego se relacionará las terceras y
subsiguientes entidades con la inicialmente definida.
(2) w: Es la cardinalidad o cantidad de veces que puede
aparecer en una relación la población de origen, donde w
será:
(a) < Cardinalidad uno.
(b) << Cardinalidad muchos.
(c) – (guión) si no puede deducirse o se desconoce.
(3) x: Es la “obligatoriedad” de existencia de ítems de la
población de origen en la relación, donde x podrá ser:
(a) | (Símbolo “pipe”) si es obligatoria.
(b) 0 (cero) si puede no darse.
(4) y: Es la “obligatoriedad” de existencia de ítems de la
población de destino de la relación, donde x podrá ser:
(a) | (Símbolo “pipe”) si es obligatoria.
(b) 0 (cero) si puede no darse.
(5) z: Es la cardinalidad o cantidad de veces que puede
aparecer en una relación la población de destino de la
relación, donde z será:
(a) > Cardinalidad uno.
(b) >> Cardinalidad muchos.

(6) ICEa18: es el identificador del conjunto entidad destino de

la relación, asignado en el tabulado de entidades [1. a) i)].
En el caso de relaciones tripartitas o superiores, aquí se
incluirá el identificador de la relación base (ver definición de
ICEde en 1) b) iii) (1)).
Ejemplos:
R(A<|:0>>B) : Estaría indicando una relación uno a muchos
entre los conjuntos de entidades identificadas como A y B
donde la existencia de entidades en A es obligatoria mientras
que la existencia de entidades en B no lo es.
R(A--:--B) : Estaría indicando que hay una relación entre las
entidades A y B, pero se desconocen o no pueden deducirse
ningún otro elemento que describa dicha relación19.
R(A<<|:|>>B) : Estaría indicado que hay una relación muchos
a muchos entre las entidades A y B, que la existencia de
elementos de ambos lados de la relación es obligatoria.
Si la relación es entre tres o más entidades, se

codificará como se indica precedentemente la relación entre un
par cualesquiera de los conjuntos de entidades involucrados,
luego en la misma columna pero renglón aparte, se agregará un
renglón adicional por cada conjunto de entidades adicional,
vinculando la relación con la población en cuestión, por
ejemplo:
Dada la relación muchos a muchos k20 entre A, B y
C, se especificará:
A<<|:|>>B y k<<|:|>>C
ii) Descripción de la relación: relato que explique como se
deduce la relación, debe ser breve y conciso.
iii) Documentación Fuente: Deberá anotarse aquí referencias a las
especificaciones del sistema (documentos, narraciones,
diagramas etc.) obtenidas en el relevamiento previo se utilizaron
para inferir la relación presente.
18
ICEde e ICEa pueden ser iguales, es cuando se da la relación entre entidades del mismo tipo, por ejemplo en el caso
de la relación de jerarquía entre un jefe y sus subalternos y viceversa, donde tanto jefes como subalternos son
entidades empleados, y para el SdI, se manejan dentro del mismo conjunto entidad.
19
Esta situación es el punto inicial de donde se parte cuando se detecta una relación entre entidades, si después de
haber efectuado todo el estudio del material obtenido en el relevamiento de los requisitos del SdI, se obtiene una
relación en esas condiciones, evidentemente, deberá revisarse la documentación estudiado o volver a efectuarse las
tareas asociadas con las reglas mencionadas, hasta poder dilucidar correctamente si la relación realmente existe o no, y
de existir, cual es su cardinalidad y el carácter participativo de las entidades nombradas.
20
k representa aquí a un número en notación romana, el cual se utiliza como identificador de la relación kaésima.

d) Tabulación de Atributos Requeridos por el SdI: Una vez

tabuladas las entidades y sus relaciones en las dos planillas previas,
se procederá a definir los atributos (“que datos son requeridos de...”)
de las entidades y relaciones que se han tabulado. A partir de dichos
atributos se obtendrá tras su procesamiento con la Información que
se pretende provea el SdI, para ello se confeccionará otra planilla
con :
i) Identificador Atributo: Un número de atributo, correlativo,
en sistema numérico decimal (1, 2, 3...), para referenciarlo en
documentación a confeccionar posteriormente.
ii) Nombre Atributo: Un nombre asignado al atributo, que
será después utilizado para darle nombre a la columna de la
tabla que forme parte de la base de datos que se está
normalizando. Conviene que ningún atributo tenga nombre
repetido, ya que aunque si esta en distintas tablas, cualquier
S.G.B.D. relacional lo soportaría, puede causar confusión o
mayor trabajo cuando se indague la base de datos por medio de
sentencias SQL, ya que obligará indefectiblemente a calificar
los atributos con el nombre o alias asignado a cada tabla en la
sentencia SELECT correspondiente. Pueden establecerse las
siguientes pautas para la formación del nombre de un atributo:
(1) Concreto, conciso y representativo del atributo. Los
atributos pueden ser (entre otras) un identificador de la
entidad, describirla en forma textual o mensurable, o algún
valor relativo a algún suceso relevante para dicha entidad, la
Contabilidad básicamente registra sucesos mensurables
como fechas, cantidades, valores, etc.. Además debe evitarse
en el nombre elementos obvios.
(2) Utilizar abreviaturas de uso generalizado para dar nombre
a los atributos, por ejemplo CUIT en lugar de Código Único
de Identificación Tributaria.
(3) Eliminar todos los artículos, preposiciones y espacios en
blanco de dentro del nombre21, para reducir su largo. Al
eliminar los espacios en blanco y otros elementos, conviene
por razones de claridad de que las palabras que forman el
nombre del atributo (si hay más de una), mantengan su
primera letra en mayúsculas y el resto en minúsculas.
21
Aunque muchos de los S.G.B.D. actuales soportan blancos dentro del nombre de las columnas, cuando se incluyen,
luego en su manipulación en consultas o con lenguajes de acceso a datos (SQL), implican utilizar elementos
separadores adicionales, como corchetes, llaves o comillas, que dificultan su escritura, haciendo perder la claridad que
se pretendía obtener en la visualización del nombre con la inclusión de dichos blancos.

(4) Si el atributo puede ser una clave, será conveniente que

incluya en su nombre la denominación en singular de la
entidad a la que pertenece (o una abreviatura de la misma),
ya que como se verá más adelante, las claves pueden ser
principales o foráneas en otras poblaciones, y causar por ello
confusión y/o conflictos al utilizarse en la creación de
informes.
(5) Si el atributo no es clave, puede omitirse en el nombre la
denominación de la entidad al que corresponde, para lograr
que sea mas corto, salvo que el atributo sea relevante para la
entidad, fundamentalmente si esta representa un suceso en el
SdI, tales serían los casos de la Fecha en una Factura o en un
Asiento contable22.
(6) Opcionalmente, incluir como primera letra del nombre del
atributo, una letra acorde al tipo de dato almacenado, para
evitar errores en su utilización posterior23.
(7) Para el nombre de los atributos no conviene utilizar
plurales, ya que estaría induciendo a considerar que el dato
tiene repeticiones incluidas (como si fuera un arreglo), y por
definición, en una base de datos relacional solo pueden
manejarse datos atómicos, p. e. una factura no debe contener
un atributo FechasVencimiento que sugiera más de un
vencimiento, en una B.D.R. esto implica una tabla adicional,
donde se especifican las distintas fechas de vencimiento para
una factura dada24.
Ejemplos:
A partir de una Entidad que representa a una factura se
muestra la aplicación de las pautas:
Factura = { Tipo de Factura, Número de la Factura, Código

Único de Identificación Tributaria Cliente, Fecha de la Factura,
Tipo de la Venta, Condiciones del Impuesto al Valor Agregado,
Número de la Cuenta Corriente }
22
Esto no crea problemas de uso, ya que un atributo puede calificarse con el nombre de la población o tabla donde se
almacena, por ejemplo: Empleados.Nacimiento, Facturas.Fecha, DetalleFactura.Cantidad, etc.
23
Existe diferentes criterios, aquí se sugiere uno posible: c: Carácter (longitud definida y menos de 250 caracteres), f:
Fechas, g: Imágenes, u otros objetos con formato especial (BLOBs, binary large objects u objetos binarios grandes), i:
Entero l: Lógico, t: Fecha y Hora, m: Texto largo de gran longitud (más de 250 caracteres y/o con renglones internos), n:
Numérico, r: Números Reales e y: Moneda (currency).
24
En los S.G.B.D.R. se incluyen soporte para tipo de datos texto de gran longitud (ver nota anterior), que incluye el
soporte de renglones, los cuales pueden accederse por separado fácilmente, como si fuera un arreglo, en las
características de SQL-3, se indica soporte para arreglos y objetos, que se aparta de las reglas de Codd propuestas
para el modelo relacional pero que responde a la necesidades de los sistemas de información modernos.

Por la pauta uno se determina:

Tipo de Factura Número de la Factura
Código Único de Identificación Tributaria Cliente
Fecha de la Factura Tipo de la Venta
Condiciones del Impuesto al Valor Agregado
Número de la Cuenta Corriente
De la pauta dos se obtiene:
Tipo de Factura Número de la Factura
CUIT Cliente Fecha de la Factura
Tipo de la Venta Condiciones del IVA
Número de la Cta Cte
Por tres se deriva:
TipoFactura NúmeroFactura
CUITCliente FechaFactura
TipoVenta CondicionesIVA
NúmeroCtaCte
Cuatro en este ejemplo no se aplica y de cinco queda:
TipoFactura NúmeroFactura
CUITCliente FechaFactura
TipoVenta CondicionesIVA
NúmeroCtaCte
Con seis se complementa el tipo de dato:
cTipoFactura nFactura
nCUITCliente fFecha
cTipoVenta nCondicionesIVA.
nCtaCte
Y con siete se eliminan los “plurales”:
cTipoFactura nFactura
nCUITCliente fFecha
cTipoVenta nCondicionIVA25
25
Al agregar el tipo de dato, se considero adicionalmente eliminar la palabra número en algunos atributos, ya que si el
tipo de dato (en este caso números) ya formaba parte del nombre, habría una redundancia al decir nNumeroFactura o
que sea que atributo Numero de Factura contiene un número.
La palabra Factura, que es el nombre de la entidad a la que se está referenciando, no se excluye de los
atributos cTipoFactura y nFactura, porque evidentemente, el tipo de una factura (A, B, C,...) y su número constituyen
atributos que pasarán a ser la clave de la población (de manera de identifícalas en forma univoca) y posiblemente sean
referenciados en otras entidades como claves foráneas o parte de sus respectivas claves principales. Además si en
lugar de nFactura, que quede n solamente es una simplificación extrema, que aporta confusión y no simplificación.
cTipoVenta se deja así, porque si se elimina Venta, queda muy ambiguo el significado de ctipo solo, lo mismo
si se procede en forma inversa (dejando cVenta solamente).
Cuando un atributo hace referencia a un suceso relativo a una entidad, como en el caso de fFecha en el
ejemplo, puede asignarse nombres como fFacturado o fFacturada, o en el caso de datos de persona, en lugar de
fFechaNacimiento o fNacimiento, poner fNacido.

iii) Descripción Atributo: Aquí se deberá detallar

textualmente que significado tiene el atributo para el sistema.
iv) Entidad a la cual corresponde: Debe indicarse a que
entidad (fuerte, débil o dominio de valores) o relación muchos a
muchos a muchos pertenece un atributo. Un atributo no puede
pertenecer a más de una entidad o relación, caso contrario se ha
hecho un análisis incompleto, o los nombres asignados son
demasiados genéricos.
v) Admite Nulos: Puede indicarse si el atributo admite
valores nulos o no (un valor nulo, significa que no se conoce el
dato, o puede no conocerse, un valor cero es eso, un valor
numérico posible, un hilera de caracteres vacía “”, significa un
dato alfanumérico que no está, por ejemplo, si se tiene un
atributo AliasPersona, si tiene un valor nulo significa que no se
conoce, si es una cadena vacía, es que no tiene.
vi) Valor por omisión: Si se agrega una fila (para una tabla o
una planilla de cálculo, equivale a un registro en un archivo
tradicional), y no se especifica un valor para el atributo, que
valor se asigna por omisión.
vii) Regla de validación: Como se valida el atributo, o sea que
dominio de valores pueden admitirse cuando se agrega un dato o
se modifica. Esto puede ser una expresión lógica de cualquier
tipo (Dentro de estas se incluyen la lista de valores posibles, si
la lista es relativamente corta, pueden enumerarse los valores
directamente, en el caso de que la lista sea extensa o pueda
evolucionar en el tiempo, es mejor que la misma se indique
mediante una relación a otra tabla que contenga el dominio de
valores posibles, vinculándola mediante una clave foránea).26
viii) Documentación Fuente: Aquí se anotaran referencias a las
especificaciones del SdI de donde se infiere el atributo actual.
26
Alguien podría decir que estos tres últimos datos son más de incumbencia del analista-programador que del Contador,
pero debe tenerse en cuenta que la calidad de la información (y por ende de los datos en que se base) la certifica el
Contador, por lo tanto es lógico suponer que la forma de validar los mismos, es responsabilidad de él, estos datos
relevados aquí pueden después facilitar las tareas de control durante la implementación de la aplicación, o luego
durante el control interno o la auditoria.
No tener en cuenta estas tres últimas especificaciones, puede provocar informes erróneos al momento del uso
de la base de datos para generar información gerencial y facilitar por otra parte que se cometan fraudes. Cual es el
resultado del promedio de edad de nuestros clientes, cuando para aquellos casos en los que se desconoce la fecha de
nacimiento se cargo una fecha “vacia”, en lugar de una fecha nula, muchos S.B.D.R, consideran las fechas vacias como
la fecha inicial del rango de fechas que pueden manipular, en cambio un valor nulo, no es considerado en los cálculos,
por lo que el informe será exacto con relación a los datos conocidos. Un valor por omisión en una fecha de transacción,
permite evitar que accidentalmente (o maliciosamente) se ingresen transacciones y no se conozca cuando se produjo
dicha transacción. También, al especificar un dominio que esté almacenado en una tabla externa (clave foránea) puede
permitir detectar alguna relación que en el relevamiento respectivo paso desapercibida.

Diagramación de Entidades
2) Diagramación de Entidades: En esta cuarta regla se comenzará a
diagramar las entidades que intervienen en la base de datos que se está
normalizando. Para dicha diagramación se propone utilizar la siguiente
simbología en el trazado de dichos diagramas27:
CLIENTES A
R epresentacion
Grafica
ENTIDAD
(Fuerte)
DETALLE D
R epresentacion
FACTURAS Grafica
ENTIDAD
(Debil)
DETALLE R epresentacion D
FACTURAS Grafica
ENTIDAD
(Debil y/ o
R elaciones con
Atributos)
Representación de Entidades y Relaciones (Gráfico 15)
a) Para diagramar una entidad “fuerte” se utilizará un rectángulo, en el

cual, en la parte superior del mismo se especificará el ICE (1.a.i) o
su nombre (1.a.ii), lo que se considere más claro (ver gráfico 15).
b) Para diagramar una entidad “débil”, se utilizará un rectángulo de
bordes dobles (opcionalmente, podrá usarse un rombo dentro de un
rectángulo), y se identificará con la misma metodología que para
entidades (ver gráfico 15).
27
No se propone en este trabajo instrumentar un nuevo conjunto de símbolos para representar entidades, objetos,
relaciones, etc. Cada profesional podrá utilizar lo sugerido en este documento pero se aconseja que el profesional utilice
preferentemente aquella metodología que le sea conocida, o la utilizada en el equipo de trabajo en el cual trabaje, o la
requerida por el cliente, en el caso de tener que presentar un trabajo para terceros.

Diagramación de Relaciones
3) Diagramación de Relaciones: Para graficar las relaciones entre
entidades (o poblaciones), se considerarán dos grandes casos por
separado:
a) Para el caso de las relaciones uno a uno (<-:->, según nomenclatura
sugerida previamente) uno a muchos (<-:->>) o muchos a uno (<<-:-
>), que no tienen atributos propios, se instrumentan en Bases de
Datos Relacionales (B.D.R.), utilizando “claves foráneas”28. Para su
graficación se utilizará una línea para unir las entidades
involucradas en cuyos extremos se incluirá un terminador acorde a
las características correspondientes a dicha relación (ver gráfico 16),
y adyacente a dicha línea se pondrá, el nombre o identificador de la
relación asignado a la misma en la planilla correspondiente29.
b) Si la relación es muchos a muchos, (tenga o no atributos propios, no

confundir con entidades débiles), para su instrumentación en B.D.R.
deberá crearse una tabla intermedia, la cual será representada
mediante un rectángulo con un rombo dentro, o simplemente un
rombo, dentro del cual, se indicará el identificador abreviado o
extendido que se haya asignado, según se considere más apropiado
(ver gráfico 15).
Distribución de Atributos
4) Distribución de Atributos: Los atributos se incluirán dentro de
cada entidad (fuerte, débil o dominio de valores) o de las figuras que
representan a las relaciones muchos a muchos según corresponda, de
acuerdo a lo que se desprenda de la planilla de 1) c). De cada atributo,
solo hace falta indicar su identificador numérico (para lograr un gráfico
más compacto), pero pueden agregarse los nombres asignados a los
mismos.
En esta primera etapa, ningún atributo debe aparecer en

más de una entidad (fuerte, débil o dominio de valores) o relación
muchos a muchos, en caso de aparecer un atributo en más de una entidad
o relación, deberá revisarse las definiciones de atributos, porque se debe
a un error o ambigüedad en la definición30.
28
Ver dentro de Conceptos básicos, Clave Relación, Claves Externas (o foráneas), en páginas previas.
29
Con diagramas E-R, cualquier tipo de relación, se representa por medio de un rombo, pero como se busca manejar
diagramas compactos, salvo para relaciones muchos a muchos, no haría falta el rombo para graficar las relaciones.
30
Un error común en estos casos, es que se incluya como atributo en una entidad débil, el atributo clave de la entidad
fuerte de la cual depende la entidad débil para su existencia, p. e. Incluir el NumeroFactura (atributo de la entidad
Facturas) en la entidad débil DetalleFactura.

Si después de la distribución de atributos, quedase alguna

entidad sin atributos, y no se fuese esta circunstancia causada por un
error de relevamiento, dicha entidad deberá ser eliminada del diagrama
de entidades porque es una “sobreinterpretación” de las especificaciones.
Formas de Graficar Relaciones entre Entidades
a) R elacion (no se especifico tipo)

ENTIDAD --:
1, 2, 3, 4, 5
...
b) R elacion Uno
ENTIDAD <-:
1, 2, 3, 4, 5
... (puede ser no obligatoria,
pero no se especifica con certeza)
c) R elacion Uno
ENTIDAD <|:
1, 2, 3, 4, 5
... (este lado de la relacion es
obligatoria)
d) R elacion uno no obligatoria

ENTIDAD <0:
1, 2, 3, 4, 5
... (puede existir o no)
e) R elacion M uchos
ENTIDAD <<-
1, 2, 3, 4, 5
... (no se indica si es obligatoria,
puede serlo o no)
f) R elacion M uchos obligatoria

ENTIDAD <<|:
1, 2, 3, 4, 5
... (este lado de la relacion
es obligatorio)
g) R elacion M uchos no obligatoria.

ENTIDAD <<0:
1, 2, 3, 4, 5
... (puede existir o no)
N OTA AL GRAFICO:
Se muestra como se dibuja uno de los lados de la relacion, el otro lado se
dibujara segun corresponda con el mismo tipo de terminacion de la linea.
Los casos de las relaciones muchos a muchos se incluyen en otro grafico.
ATEN C ION: La herramienta utilizada para la elaboracion de los graficos no admite incluir asentos,
los cuales se pierden en el momento de hacer el copiado y pegado en el documento principal.
Graficación entre Entidades (Cardinalidad) (Gráfico 16)

Definir Claves de cada Entidad

5) Definir Claves de cada Entidad: Una vez distribuidos los
atributos según la regla anterior, se procederá a determinar la clave de
cada una de las entidades. Para ello se utilizarán los conceptos vertidos
en este trabajo en Conceptos Básicos, sub-temas 7) Base de Datos
Relacional y 10) Clave de la Relación. Para identificar cada una de los
atributos claves dentro del gráfico, se procederá de la siguiente manera:
a) Las claves primarias, se subrayarán, y si es posible se resaltará el
número del atributo (o atributos, en caso de claves compuestas) con
trazos más gruesos (“negrita”).
b) Los números de los atributos que correspondan a las claves
alternativas (o candidatas) se encerrarán entre paréntesis.
c) Los atributos que admitan valores nulos se encerrarán entre
corchetes (“[]”).
d) Una entidad débil puede resultar que en esta etapa de la
normalización no cuente con una clave que garantice unicidad, esto
se logrará al aplicar la regla 6 (regla de los unos a los muchos).31
e) Cualquier clave que sea del tipo compuesto (o sea conformada por
dos o más atributos), se encerrará entre llaves (“{}” ).
f) Si un atributo forma parte de más de una clave (de cualquier tipo
que sea), la segunda y sucesivas veces que aparezca, se pondrá su
atributo en formato de letra itálica.
g) Los demás atributos se dejarán como están.
Establecer Relaciones Básicas
6) Establecer Relaciones Básicas (regla de los unos a los muchos):
Los atributos que son claves principales de las poblaciones (o entidades)
del lado de uno de la relación copiarán en la población que esté del lado
muchos de la relación, teniéndose en cuenta las siguientes
particularidades:
a) Si la entidad receptora es una entidad fuerte, el atributo recibido
quedará como clave foránea dentro de dicha población, y para
diferenciarlo, se le agregará un apostrofe.
31
En el caso de no poder determinarse que algún atributo, o combinación de estos pueda ser declarado como clave,
deberá revisarse el análisis efectuado y en todo caso se utilizar como clave parcial el atributo que sea más identificativo
en dicha entidad débil.

b) Si la entidad receptora es la misma que la de origen, es el caso de la

relación de una población consigo mismo (el jefe de un empleado es
un empleado también), por lo que deberá “clonarse” dicha clave
principal, con otro nombre apropiado, ya que la clave del lado uno,
deberá copiarse en la misma población (que también oficia de
muchos) de esa manera se evita la duplicación del atributo que es
clave en dicha población.
c) Si la entidad del “lado de los unos” cae en la categoría de
“dominios de valores”, su atributo clave se pasará o copiará como
clave foránea en la población del lado de los muchos.
d) Si la entidad receptora es una entidad débil, deberán considerarse las
siguientes circunstancias al momento de establecer los atributos de
enlace entre la entidad uno y la entidad muchos:
i) Cuando la clave que se copia “del lado de los unos”,
corresponde a la entidad fuerte de la cual depende
jerárquicamente la existencia de la entidad débil, dicha clave se
pasará o copiara pasando a formar parte de la clave primaria de
la entidad débil salvo el caso previsto en 6) d) iii).
ii) En el caso de que la jerarquía tenga varios niveles, la
transferencia de dichas claves deberá comenzar en una entidad
fuerte. Esto implica que la clave de tal entidad fuerte, formará
parte de la clave primaria de todas las entidades débiles que
dependan de la existencia de dicha entidad fuerte (directamente
o por carácter transitivo).
Ejemplo:
R1=( a, b, c, d)
donde R1 es una entidad fuerte y a es su clave.
R2=( {e, a}, f, g, h)
donde R2 es una entidad débil dependiente de R1 y e
es la clave original de R2, por lo que R2, pasa a tener una
clave compuesta, por último...
R3=( {i, e, a, }, j, k, l)
donde R3 es una entidad débil dependiente de R2 y i
clave compuesta por tres atributos (i, e y a).
iii) Si la entidad débil cuenta con una clave que provee

identificación unívoca, la clave que proviene del “lado de los
unos” quedará incorporada como clave foránea en la entidad
receptora. En el caso del inciso anterior, esta clave propia de la

entidad débil será la que pasará a las siguientes entidades
débiles dependientes.
Ejemplo:
R1=( a, b, c, d)
donde R1 es una entidad fuerte y a es su clave.
R2=( e, ‘a, f, g, h)
donde R2 es una entidad débil dependiente de R1
pero en este caso e es una clave que provee unicidad para la
entidad débil R2, actuando como su clave principal, por
último...
R3=( {i, e,}, j, k, l)
donde R3 es una entidad débil dependiente de R2 y i
clave compuesta por dos atributos (i y e).
i) Si la entidad débil no cuenta alcanza a conformar una

clave propia (aún con el aditamento de la clave proveniente de
la entidad fuerte de la cual proviene, deberá crearse un campo
ad hoc para poder manejar tal circunstancia32.
ii) Para las otras claves provenientes del “lado unos de la
relación” se las trata como las otras claves, quedando como
claves foráneas.
Establecer Relaciones Básicas Múltiples
7) Establecer Relaciones Básicas Múltiples (regla de los unos a
los muchos, muchas veces): En algunas circunstancias, puede darse que
entre dos poblaciones existan varias relaciones diferentes, en esos casos,
si por cada relación se lleva la clave de la población del lado de los unos
al conjunto entidad del lado muchos, dicho atributo quedará duplicado
en la población receptora. Para solucionar esta situación, al pasar la
clave, deberá renombrarse la misma para solucionar tal circunstancia,
ejemplo:
Se han definido una entidad Empleados y otra

SolicitudesReparación, entre ambas entidades existe una primera
relación porque toda Solicitud de Reparación es solicitada por un
Empleado (por ejemplo el chofer de un vehículo), otra relación entre
ambas entidades surge de que toda Solicitud de Reparación, tiene que ser
32
Generalmente se soluciona con un campo que cuente cada fila en la tabla de la entidad débil que depende de la
entidad fuerte.

autorizada por un “Responsable” (el jefe del chofer), otro empleado

confirma la recepción de la orden (el jefe de talleres), otro indica que la
orden se completo (el mecánico) y otro que recibió el vehículo (en este
caso) reparado (el chofer o el jefe del chofer).
Empleados=(nLegajo, cApellido, cNombre, cCargo, nJefe, ...)

SolicitudRepación=(nSolicitud, fSolicitud, cBienUso, ‘nSolicitante,
‘nAutorizo, ‘nRecibio, ‘nEntrego, ‘nRecibio, ...)
Los atributos de SolicitudRepación de ‘nSolicitante a, ‘nRecibio son las
claves foráneas generadas por la aplicación de la presente regla.
Establecer Relaciones Complejas
8) Establecer Relaciones Complejas (regla de los muchos a
muchos): Si la relación entre las poblaciones es muchos a muchos, en un
modelo relacional deberá indefectiblemente crearse una tabla intermedia
33
. Una relación muchos a muchos normalmente se da entre dos
entidades, pero no es imposible que en la misma intervengan tres o más
entidades. Bajo cualquier circunstancia, quedan definidas relaciones uno
a muchos entre las poblaciones iniciales y la tabla creada, debiendo
aplicarse lo siguiente:
a) Dicha tabla intermedia tendrá como atributos las claves primarias de
las poblaciones originales en la relación. Dichos atributos
constituirán en forma conjunta la clave primaria de dicha tabla
intermedia34.
b) Si la relación muchos a muchos entre las poblaciones tiene atributos
propios, ninguno de ellos podrá ser considerado como clave.
c) Si la relación muchos a muchos tiene atributos cuyos valores están
incluidos en dominios de valores, las claves de dichos dominios de
valores, se incorporan como clave foránea dentro de la relación.
Establecer Relaciones Especiales
9) Establecer Relaciones Especiales (regla de los unos a los unos):
Si la relación entre las poblaciones es uno a uno, pueden darse dos
circunstancias normalmente:
a) Si los lados son obligatorios en la relación, se han creado dos
poblaciones que deberán unificarse, porque si una parte no puede
33
Ver regla 3) b). Al diagramar relaciones, las que son muchos a muchos necesitan una tabla intermedia.
34
Debe considerársela clave primaria a todos los atributos que pasaron como claves, porque de esa manera se asegura
la unicidad de la relación (o se que se evita que se cargue dos veces la misma relación entre dos entidades). Desde el
punto de vista programación, puede llegar a ser conveniente tener dichas claves como claves foráneas, para facilitar las
consultas, pero desde el punto de vista de integridad, todas las claves que pasan o se copian dentro de la relación
deben conformar un clave compuesta.

existir sin la otra, no tiene sentido que estén separadas en dos

poblaciones diferentes. En este caso, se tomará como clave primaria
de la entidad unificada, aquel atributo que requiera menor esfuerzo
computacional para ser manipulado como clave (menor volumen de
almacenamiento, etc.)35
b) Si uno de los lados de la relación puede no darse, la clave de la
población obligatoria pasará a la otra población como clave foránea,
por ejemplo en las poblaciones de empleados y cónyuges, se da una
relación uno a uno, pero para un sistema de liquidación de sueldos,
el cónyuge puede no existir (pero el empleado es imprescindible).
c) Si los dos lados de la relación pueden no darse, el atributo clave que
se pasa es el de aquella población que se estime tendrá menor
cantidad de ítems, o aquella que aparezca mas veces como primaria
en las consultas.
Unificación de Poblaciones Equivalentes
10) Unificación de Poblaciones Equivalentes: Puede resultar que
al diagramar las distintas entidades y luego de establecer las relaciones
indicadas precedentemente, se controlara y aplicarán los siguientes
pasos:
a) Formar conjuntos de entidades que tengan la misma cantidad de
atributos, que estos sean equivalentes uno a uno entre las distintas
entidades en cuanto al significado de los datos que almacenan (igual
dominio de valores, tipo de datos, si admiten nulos, regla de
validación, valor por omisión, etc.).
b) Por cada conjunto que cumplan con 10) a), se creará una única
población, que reemplazará a las del conjunto. Cuyo nombre
generalice los nombres de las entidades que engloba.
c) Los nombres de cada uno de los atributos se adaptaran de acuerdo a
las reglas ya indicadas precedentemente.
d) Se corregirán los nombres de los atributos clave que hayan sido
“copiados” en las entidades relacionadas con estas tablas unificadas,
a los efectos de mantener las relaciones apropiadamente.
35
Si una de las claves es simple y la otra es compuesta (dos o más atributos) se preferirá la clave simple. En general los
atributos numéricos son mejores en almacenamiento que los alfanuméricos, dependiendo del S.G.B.D., en caso de ser
necesario concatenar claves, va ha ser mas simple concatenar claves alfanuméricas. Si la clave es usada habitualmente
para acceder a elementos individuales al azar, la clave preferida como principal, será aquella que para el usuario sea de
uso más común. Estos son algunos criterios, que deberán en todo caso ser discutidos con el programador de la
aplicación, ya que él estará más al tanto de las posibilidades que ofrece la herramienta con la cual trabaja.

e) Se depurará el tabulado de entidades, relaciones y atributos, para

que reflejen esta nueva situación.
f) La nueva distribución de poblaciones, no debe causar la perdida de
información.

Aplicación Práctica de las Reglas Definidas

Un Sistema de Contabilidad:
Objetivos:
El objetivo es diseñar una base de datos para almacenar
los datos correspondientes a un simple sistema de contabilidad. No se
pretende establecer pautas completas de lo que debe hacer un sistema de
contabilidad, y si se omiten algunos requisitos, es pura y exclusivamente por
que se pretende hacer un ejemplo simple.
El sistema deberá tener la capacidad de almacenar los

datos de los asientos contables, el plan de cuentas y los datos de los
comprobantes utilizados en las operaciones registradas.
También se pretende que el sistema pueda dar

información tales como resúmenes de cuentas corrientes de clientes, y otros
informes con un grado de detalle apreciable, para uso interno y hacia terceros,
por lo que sería apropiado poder contar con datos sobre los emisores de los
comprobantes que se registran.
DFD 1er. Nivel (Nivel 0)
SERVICIOS COMPRAS ALMACENES TERCEROS
Sistema de AUDITOR
PERSONAL
Contabilidad EXTERNO
CONTROL
ADMINISTRACION VENTAS GERENCIA
INTERNO
Diagrama de Entorno del Sistema de Contabilidad (Gráfico 17)

En este diagrama, el sistema en cuestión es la elipse
central, los cuadrados de bordes con sombra, son las entidades externas desde
las cuales se reciben datos y hacia las cuales se les envía información.

Si se generaliza este diagrama, se puede obtener un

modelo más simplificado del sistema y su entorno (gráfico 18) y también se
pueden derivar los siguientes niveles de análisis del sistema (gráficos 19 y
20), para eso se incluirán algunos DFDs de nivel (detalle descriptivo) mayor.
DFD 1er. Nivel (Nivel 0)

(Simplificado)
OPERACIONES
TERCEROS
CONTABILIZABLES
Balances, etc. AUDITOR

EXTERNO
Comprobantes, Documentos... Sistema de
Controles, Informes,... Contabilidad Balances, Informes, Controles...
Informes, Reportes,...
CONTROL INTERNO
GERENCIA
Diagrama de Entorno Simplificado (Gráfico 18)
DFD 2do. Nivel (Nivel 1)

(Registracion de Operaciones)
Asientos
OPERACIONES
Contables
CONTABILIZABLES
(Diario)
Registro y
Control de
Asientos
Comprobantes, Documentos... Registro
Registro y Control Asientos
Archivo de Plan de
Documentos Validacion Cuentas Cuentas
D.F.D. del Registro de los Asientos (Gráfico 19)

DFD 2do. Nivel (Nivel 1)

(Generación de Balances)
TERCEROS
Asientos
Contables
Balances
Impresos
Asientos Contables Emision de AUDITOR

Denominacion Cuentas Balances EXTERNO
Plan de
GERENCIA
Cuentas
D.F.D. correspondiente a la Emisión de Balances (Gráfico 20) 36
Plan de
Comprobante Diario
Cuentas
Libro
Emisor Concepto SubDiario
Mayor
Puesto Detalle
Operador
Trabajo Asientos
Ω Un comprobante tiene un emisor y uno o mas conceptos. Puede generar uno o mas asientos.
Ω El Diario tiene un Registrador (Operador) y un lugar donde se registra (puesto trabajo), esta
compuesto por asientos y puede subvidivirse en SubDiarios.
Ω El Plan de cuentas se relaciona con el Diario a traves de los asientos. Una cuenta puede
aparecer en mas de un asiento, y cada entrada en el asiento (renglon) se relaciona con una
cuenta.
Objetos del Sistema de Contabilidad y sus relaciones (Gráfico 21)
36
Los rectángulos con sombra representan entidades externas al sistema, los círculos representan los procesos y los
rectángulos abiertos (falta el lado derecho) representan almacenes de datos, en un sistema de archivo tradicional serían
archivos de datos, en un entorno de Base de Datos Relacional, serán tablas o vistas de la Base de Datos.

En todo sistema de contabilidad, básicamente se registran

las operaciones del ente a partir de comprobantes que respaldan dichas
operaciones. Además de los Diagramas de Flujo de Datos presentados, puede
hacerse un diagrama de objetos (clases) y sus relaciones (gráfico 21), que
puede facilitar la interpretación del sistema.
A continuación, se irán desglosando las características del

sistema de contabilidad propuesto:
1. En la contabilidad, se registran las operaciones económicas del ente que

son de interés para el Sistema de Información Contable, de las mismas
es necesario saber que37:
a. Las operaciones económicas se reflejan en comprobantes que las

documentan ante la Contabilidad. Un comprobante (documento)
puede generar uno o más asientos contables y varios documentos
ser contabilizados en único asiento, un comprobante interesa solo
si genera algún asiento,...
b. Todo comprobante o documento tiene una fecha correspondiente
al momento de la operación que documentan, téngase en cuenta
que con la misma fecha puede haber más de un comprobante,...
c. Por razones de estandarización, los tipos de comprobantes
(documentos) estarán codificados y descriptos apropiadamente,
cada tipo debe indicar si es emitido por un tercero (emisor
externo, empleados, etc.) o por el ente a quien pertenece la
Contabilidad (emisor interno),
d. Se necesita el número del comprobante,...
e. Se necesitará tener guardado el nombre del emisor, estos
nombres pueden repetirse, por lo que será necesario contar con
alguna codificación ya sea propia o disponible de alguna otra
manera (v.g. CUIT, CUIL, número de Legajo personal, etc.),...
f. Para identificar cada comprobante se guardará un identificador
propio, para permitir corregir su emisor o su tipo sin afectar los
conceptos asociados o los asientos relacionados38,...
g. Un comprobante tendrá al menos un importe, asociado con un
único concepto, dichos conceptos convendrán que este
codificados y descriptos en forma estándar, para que la
información provista por el sistema este bien descripta,...
37
Estos requerimientos surgen de un hipotético relevamiento efectuado para un Sistema de Contabilidad.
38
Evidentemente, el tipo de comprobante, el emisor y el número de comprobante constituyen una clave alternativa. Dos
emisores, v.g. dos proveedores distintos, pueden emitir su factura tipo A, número 12345 y para poder diferenciar un
documento de otro será necesario tener individualizados los emisores. Un emisor no puede tener dos documentos del
mismo tipo con igual número.

2. Los atributos de las cuentas contables son los necesarios para manejar
nuestro SdI, y emergen del Plan de Cuentas, elaborado por el Contador
para el ente. Como este sistema es simple, para cada Cuenta solo será
requerido:
a. Un Código de Cuenta que es exclusivo de cada cuenta,...

b. Código de cuenta maestra, o sea, de que cuenta depende la actual
en la jerarquía de cuentas, (Activo, Pasivo, etc., dependen de si
mismas), el código de esta cuenta maestra estará contenido a la
izquierda del Código de la Cuenta (especificación 2. a.),...
c. Un Nombre de Cuenta, no puede repetirse, no puede omitirse,...
d. Nombre Mnemotécnico o abreviatura (v.g. para seleccionar
desde un control desplegable), puede faltar pero no repetirse,...
e. Código de Identificación Corto, es opcional (para facilitar la
registración de cuentas con muchos movimientos), no puede
repetirse de especificarse,...
f. Descripción de la cuenta (para documentación interna), puede
omitirse, pero no estar en blanco,...
g. Saldo Cuenta ejercicio anterior, para restaurar el saldo si es
necesario, análisis comparativo, todas las cuentas inicialmente
tienen un saldo en cero, etc., ...
h. Saldo Cuenta ejercicio actual, inicialmente en cero, actualizado a
la fecha que se indica a continuación, y por supuesto...
i. Fecha en que se calculó el saldo actual, salvo que la aplicación a
desarrollar a posteriori prevea actualizar el mismo en línea,...
j. Código que determina si la cuenta tiene subcuentas, para
establecer si la cuenta puede o no recibir asientos directamente o
solamente es una cuenta resumen o sintética,...
k. Código que determine si la cuenta requiere Libro Mayor y...
39
l. Código que determine si la cuenta requiere o utiliza SubDiario.
3. En general, todos los asientos se generan a partir de algún documento

asociado, pero ciertos procesos internos, no los hay, como son los casos
de apertura y cierre de ejercicio. Para cada asiento, se debe guardar:
a. Número de Asiento, no hay dos asientos con el mismo número,

estos deben ser consecutivos y mantenerse en orden respecto a
las fechas40,...
39
Podrían preverse más atributos, pero para un sistema simple, es más que suficiente. Debe tenerse en cuenta que el
Sistema de Información que es la Contabilidad, es un sistema que tiene un fuerte nivel de abstracción de la información,
donde toda la capacidad del mismo para generar informes (balances, cuadros, reportes, proyecciones, etc.) deriva en
una gran parte de la “inteligencia” con la que se elabora el Plan de Cuentas (que cuentas incluye entre otras cosas).
40
El asiento k-esimo debe tener fecha de asiento menor o igual que al asiento k+1-ésimo.

b. Por cada asiento, un comentario, que será completado por el

Contador, descriptivo del significado del asiento, de la operación
económica de origen y/o su implicancia, puede faltar pero no
estar en blanco...
c. Fecha en que se efectúa el asiento, puede haber más de un
asiento por día, la fecha del asiento debe estar comprendida entre
la fecha del comprobante de origen y la fecha del día que se
carga el asiento, ...
d. Por razones de seguridad, se desea conocer fecha y hora
(Cuando), el usuario u operador (Quien) y el nombre de la
computadora (Donde) en que se efectúa el asiento41.
e. Cada asiento en el diario esta formado por dos o más entradas
(renglones), cada una de las cuales estará indefectiblemente
asociada con una cuenta del Plan de Cuentas, una cuenta puede
aparecer una sola vez por asiento,...
f. Las cuentas en cada entrada pueden aparecer como deudoras o
acreedoras, para ello se guardará una letra indicando tal carácter
(D: Debe, H: Haber), complementado con el punto siguiente, ...
g. También debe incluirse el importe que se debita o se acredita
respectivamente. El cual será positivo para los débitos y negativo
para los créditos42,...
h. Se deben numerar a partir de uno dentro de cada asiento los
renglones, por lo que será necesario un número renglón, los
números de renglón que corresponden a los débitos, deben ser
menores que los que corresponden a los créditos...
i. Una señal lógica que indica si el asiento esta cerrado o pendiente.
En un proceso iterativo, se van leyendo las

especificaciones del sistema, complementando todas aquellas especificaciones
que no sean suficientemente claras, y a luego se van completando los
tabulados especificados por la regla 1), a continuación las el tabulado de
entidades para el sistema de contabilidad:
41
Entre paréntesis, se indican Cuando, Quien y Donde, que junto al Que, constituyen las pistas mínimas de control
transaccional de cualquier sistema informatizado, en este caso, el Que es el asiento en si.
42
Aquí se podría pensar en guardar en atributos separados los débitos por un lado y los créditos por otro, pero eso se
hace en un diario manual (columnas separadas) para facilitar la operatoria de obtener la sumas separadas de débitos
y créditos y efectuar la comprobación de la partida doble.
En un sistema informático, es más simple usar una sola columna para el importe, poniendo como positivo por
ejemplo el débito y negativo el crédito; dejando para el aplicativo la tarea de distribuir los datos visualmente.
Esto facilitará mas adelante la indagación de la base de datos utilizando algún lenguaje de cuarta generación
(por ejemplo SQL) o un para asistente de consultas. El control de la partida doble es tan simple como controlar que
dado un asiento, la suma algebraica de débitos y créditos de 0 (cero).

Tabulado de Entidades: Regla 1 a)

I Documen-
Carácter
D Nombre Entidad Descripción Entidad tación
Entidad
E Fuente
Documentación que respaldan los
A Comprobantes Fuerte 1) a)
asientos contables.
Lugar donde se registran las operaciones
B Diario Fuerte 1) b)
económicas, a través de asientos.
Todos los comprobantes son de algún Dominio
C TiposComprobante 1) c)
tipo especificado. Valores
Identificación y Nombres de Emisores de Dominio
D Emisores 1) e)
Documentos. Valores
E Conceptos Conceptos incluidos en un comprobante. Débil (A) 1) g)
Dominio
F TiposConceptos Los conceptos son de algún tipo. 1) g)
Valores
Las cuentas que se utilizan en los asientos
G PlanCuentas Fuerte 2)
pertenecen al plan de cuentas.
Observando el tabulado anterior, y luego al analizar el

tabulado de relaciones, puede parecer extraño que Conceptos aparezcan como
una entidad (débil) en lugar de una relación entre Comprobantes y
TiposConceptos. Esto se plantea así porque TiposConceptos surge para
sistematizar la descripción de los conceptos. Inicialmente, no es una entidad
que exista por si misma, si no, como su calificación lo indica, es un dominio
de valores, con el significado que estos tienen dentro de este trabajo.
Si se hubiese optado por interpretar que Conceptos es una

relación entre Comprobantes y TiposConceptos, el resultado final no sería
muy distinto del obtenido con la interpretación tomada, igual se logra mayor
consistencia de datos, reducir el volumen de datos requerido, es muy difícil
lograr unificar criterios al interpretar las especificaciones de sistemas, tema
que además se aparta del tema central de este trabajo.

Continuando con 1) b) se despliega el tabulado de

relaciones para el sistema de contabilidad:
Tabulado de Relaciones: Regla 1 b)

I
Tipo
D Nombre Relación Descripción Relación 3)
Relación
R
Un comprobante da origen a uno o más
asientos (si un comprobante no genera
1) a) y
I Documentación A<<0:|>>B asiento, no se tiene en cuenta para el sistema
3)
de contabilidad, un asiento puede involucrar
a mas de un comprobante).
Todos los comprobantes son de algún tipo
Comprobante- codificado, puede haber algunos codificados
ii A<<0:|>C 1) c)
TiposComprobantes (en dominio de valores) que no se hayan
cargado
Un comprobante es emitido por un emisor,
1) e) y
iii Comprobante-Emisor A<<0:|>D estos pueden emitir cero o más
1) f)
comprobantes.
Un comprobante puede tener varios
Comprobante-
iv A<|:|>>E conceptos (al menos uno), cada concepto 1) g)
Concepto
estará asociado a un comprobante
Concepto-
v E<<|:|>F Todo concepto es de algún tipo codificado 1) g)
TipoConcepto
Relación de una cuenta del plan de cuenta
PlanCuentas-
vi G<<0:0>G con la cuenta de la que depende, hay cuentas 2) b)
PlanCuentas
que no tienen subalternas
Cada asiento en el diario tiene dos o mas
renglones para representar al menos un
vii DetalleAsientos B<<|:0>>G 3) e)
débito y al menos un crédito, cada cuenta
puede aparecer en más de una asiento.
Como último paso de la regla 1) se procederá a

confeccionar el tabulado de atributos. Los atributos indicados en dicho
tabulado surgen de las especificaciones enumeradas precedentemente, salvo
los dos últimos de la lista que corresponden a la aplicación de reglas
propuestas.
Estos dos últimos atributos corresponden a la solución

que brindan las reglas propuestas a dos casos que se presentan en el ejemplo
presentado. El primer caso es cuando una población (entidad) se relaciona
consigo misma (atributo 33), y en este caso se aplica la regla 6ta inciso b), ya
que de otra manera el identificador de la cuenta quedaría duplicado en la
misma población.

El segundo caso es para resolver la situación de una

entidad débil, que no cuenta con clave propia completa, por la que se crea un
atributo especifico (el 34) para resolver tal circunstancia (regla 6) d) iv).
Tabulado de Atributos: Regla 1 c)

Valor X
1) Nombre Atributo Descripción Atributo 2) 3) Regla Validación 4)
Omisión
No puede ser posterior a la
Fecha
1 FComprobante Fecha del Comprobante A No fecha de la carga (puede 1) b)
Carga
repetirse
Indica el tipo de emisor
2 CTipoEmisor A No I (Interno) I (interno) ó E (externo) 1) c)
(Interno o Externo)
Mnemotécnico. Debe existir
3 cTipoComprobante Tipo de comprobante C No 1) c)
en el Dominio de Valores
Descripción del Tipo de No puede repetirse ni estar en

4 cDesComprobante C No 1) c)
Comprobante blanco
Lo genera el sistema, número
Identificador Univoco de Auto
5 NIdComprobante A No usado aunque se borra, no se 1) f)
cada comprobante Incremento
reutiliza
Combinado con
1) d) y
6 NComprobante Número del Comprobante A No cTipoComprobante y
1) f)
cIdEmisor no puede repetirse
Nombre del Emisor de Puede repetirse pero no estar

7 cNombreEmisor D No 1) e)
Documentos en blanco
Identificador del Emisor de No puede repetirse ni estar

8 cIdEmisor D No 1) e)
Documentos en blanco
Cada concepto en un
9 yMontoConcepto comprobante tiene un E No Importe positivo 1) g)
importe o monto
Los conceptos son
Mnemotécnico. Debe existir
10 cTipoConcepto codificados para mayor F No 1) g)
en el Dominio de Valores
claridad.
Descripción del concepto No puede repetirse ni estar
11 cDesConcepto F No 1) g)
incluido en un comprobante en blanco
Código Cuenta asignada Este código responde a la

12 cCodigoCuenta por el Contador en el plan G No estructura jerárquica de las 2) a)
de cuentas cuentas en el plan de cuentas
Nombre de la Cuenta No puede repetirse ni estar

13 cNombreCuenta G No 2) c)
asignada. en blanco
Mnemotécnico. Si no es
14 cCodigoAbreviado Código Cuenta Mnemónico G Si nulo, no puede estar en 2) d)
blanco ni repetirse
Código Corto para facilitar Si no es nulo, no puede estar
15 cCodigoCorto G Si 2) e)
la registración en blanco ni repetirse
Si no es nulo, no puede estar

16 mDescripcion Descripción de la Cuenta. G Si 2) f)
en blanco.
17 ySaldoAnterior Saldo Cuenta Ejercicio G No 0 2) g)


Valor X
Omisión
Anterior
Saldo Cuenta Ejercicio
18 ySaldoActual G No 0 2) h)
Actual
No puede ser mayor a la
Fecha a la que esta Día de la
19 fSaldo G No fecha del día en que se carga 2) i)
calculado el Saldo Fecha
o modifica
Señal lógica que indica que
20 lTieneSubCuentas G No FALSO Verdadero o Falso 2) j)
la cuenta tiene subcuentas
VERDADE
21 lRequiereMayor la cuenta requiere libro G No Verdadero o Falso 2) k)
RO
mayor.
22 lTieneSubDiario la cuenta requiere G No FALSO Verdadero o Falso 2) l)
subdiario.
El asiento #k debe tener una
Auto
23 nAsiento Número de Asiento B No fecha menor o igual que el 3) a)
Incremento
asiento #k+1
Comentarios acerca del Si no es nulo, no puede estar
24 mComentario B Si 3) b)
asiento en blanco.
Comprendida entre la fecha
del comprobante asociado y
Fecha del asiento (a que Día de la
25 fAsiento B No la fecha en que se carga, 3) c)
fecha corresponde) Fecha
respe debe respetarse la regla
de nAsiento
Generado por sistema, el
Fecha en que se cargo el Día de la
26 fAsentado B No operador no puede 3) d)
asiento al sistema Fecha
modificarlo
Identificación del operador Provisto Generado por sistema, el
27 cOperador del programa que cargó el B No por operador no puede 3) d)
asiento Aplicación modificarlo
Identificación computadora
Provisto Generado por sistema, el
donde corre el programa
28 cComputadora B No por operador no puede 3) d)
Contable al hacerse el
S.Operativo modificarlo
asiento
Indicador del Carácter de la
"D" (Deudora) o "H"
29 cCaracterCuenta Cuenta dentro del asiento vii No "D" 3) f)
(Acreedora)
(Deudora o Acreedora)
Positivo si
Monto del Débito o del cCaracterCuenta="D" y
30 yImporte vii No 0 3) g)
Crédito en el renglón Negativo si
cCaracterCuenta="H"
Provisto Generado por sistema, el
Número Renglón en el
31 NRenglon vii No por operador no puede 3) h)
asiento
Aplicación modificarlo
Verdadero o Falso (solo
Señal lógica si el asiento
puede ser verdadero si
32 LCerrado esta cerrado (y sumarizable B No FALSO 3) i)
asiento cumple con partida
o no)
doble


Valor X
Omisión
Este atributo debe crearse Es nulo cuando la cuenta no

de acuerdo a la regla 6) b) depende de ninguna otra
33 CCuentaMaestra relación uno a muchos de G Si (Activo, Pasivo, etc.) caso 2) b)
una población consigo contrario, debe existir en el
misma. plan de cuentas.
Este atributo debe crearse

de acuerdo a la regla 6) d) Provisto Generado por sistema, el Regla
34 NConcepto iv) para completar la clave E No por operador no puede 6) d)
de la entidad débil Aplicación modificarlo iv)
concepto.
Referencias a títulos del tabulado de atributos:

1. Número asignado al atributo. 2. Entidad donde a la que pertenece el atributo.
3. Atributo admite valores nulos o no. 4. Parte de la documentación donde se basa el atributo.
Una vez concluida la etapa de tabulación de los datos se

procederá a aplicar las 2da y 3ra reglas de normalización propuesta, esto
implica que se procederá a diagramar las entidades y relaciones, lo que queda
reflejado en el siguiente grafico, en un primer caso (gráfico 22), se utiliza la
propuesta de identificar las entidades y relaciones muchos a muchos por
medio de su identificador, en el gráfico 23, se usan los nombres asignados:
D iii i i B
vii
i
C A vii
ii iv
vii
vi
F v E G
Entidades y sus relaciones luego de aplicar reglas 2da y 3ra (Gráfico 22)

EMISORES iii DOCUMENTACION i DIARIO
vii
i
TIPOS COMPROBANTES DETALLAASIENTOS
COMPROBANTES
ii iv
vii
vi
TIPOS v CONCEPTOS PLANCUENTAS
CONCEPTOS
Otra forma de nombrar Entidades y Relaciones (Gráfico 23)
DIARIO
EMISORES DOCUMENTACION i
iii 23. nAsiento
7. cNombreEmisor
24. mComentario
8. cIdEmisor
25. fAsiento
26. fAsentado
27. cOperador
28. cComputadora
i
32. lCerrado
COMPROBANTES
TIPOS
1. fComprobante vii
COMPROBANTES
2. cTipoEmisor
3. cTipoComprobante
5. nIdComprobante
4.DesComprobante
6. nComprobante
DETALLAASIENTOS
ii
iv 29. cCaracterCuenta
30. yImporte
31. nRenglon
TIPOS CONCEPTOS
CONCEPTOS v 9. yMontoConcepto vii
10. cTipoConcepto
PLANCUENTAS
11. cDesConcepto
12. cCodigoCuenta
vi 13. cNombreCuenta
14. cCodigoAbreviado
15. cCodigoCorto
16. mDescripcion
17. ySaldoAnterior
Elementos agregados en
este diagrama con referencia 18. ySaldoActual
al anterior estan en trasos 19. fSaldo
mas gruesos (negrita) 20. lTieneSubCuentas
21. lRequiereMayor
22. lTieneSubDiario
Entidades, Relaciones y Atributos luego de aplicar regla 4ta (Gráfico 24)

Una vez que se aplicaron las reglas 2da (diagramación de

entidades) y la 3ra (diagramación de relaciones) se debe aplicar la 4ta regla
que corresponde a la distribución de atributos (plasmado en el grafico 24).
Debe notarse que después de distribuir los atributos según

ta
la 4 regla, ninguno de estos debe aparecer en más de una entidad o relación
muchos a muchos. Aquí se adopto volcar el número identificador de cada
atributo más el nombre asignado en el tabulado 1) c) para mayor claridad.
DIARIO
EMISORES DOCUMENTACION i
iii 23. nAsiento
7. cNombreEmisor
[24. mComentario]
8. cIdEmisor
25. fAsiento
26. fAsentado
27. cOperador
28. cComputadora
i
32. Cerrado
COMPROBANTES
TIPOS
1. fComprobante vii
COMPROBANTES
2. cTipoEmisor
3. cTipoComprobante
5. nIdComprobante
4.DesComprobante
6. nComprobante
DETALLAASIENTOS
ii
iv 29. cCaracterCuenta
30. yImporte
31. nRenglon
TIPOS CONCEPTOS
CONCEPTOS v 9. yM ontoConcepto vii
10. cTipoConcepto PLANCUENTAS
11. cDesConcepto
12. cCodigoCuenta
vi 13. cNombreCuenta
[14. cCodigoAbreviado]
[15. cCodigoCorto]
[16. mDescripcion]
17. ySaldoAnterior
Elementos agregados en
este diagrama con referencia 18. ySaldoActual
al anterior estan en trasos 19. fSaldo
mas gruesos (negrita) 20. lTieneSubCuentas
21. lR equiereM ayor
22. TieneSubDiario
Entidades y Relaciones c/sus claves marcadas luego de aplicar regla 5ta

(Gráfico 25)

Luego se aplica la regla 5ta a los efectos de definir las

claves de cada una de las entidades y relaciones detectadas. Hay casos en que
algunas entidades o relaciones queden con definiciones de sus claves
incompletas, eso se soluciona aplicando las reglas siguientes. Las claves
definidas en primera instancia se plasman en el gráfico 25.
Aplicando la regla 3ra se trazan (grafican) las relaciones

entre las entidades faltando indicar como dichas relaciones quedarán
instrumentadas en la base de datos relacional, esta situación empieza a
plasmarse a partir de la aplicación de la regla 6ta.
La regla 6ta con el latiguillo “Pasar las claves de los

unos a los muchos” empieza a establecer las relaciones entre las distintas
tablas que constituirán la base de datos relacional que se está normalizando.
Dada la simplicidad del modelo Contable propuesto como primera aplicación
práctica de las reglas propuestas, no serán aplicables las reglas 7may, 9na y
10ma, al aplicar la 8va regla, se definirán los atributos claves de la única
relación muchos a muchos que pudo inferirse (Documentación).
Este primer ejemplo propuesto versó sobre un sistema

conocido para el profesional Contador, de manera de que pueda ir asimilando
los conceptos vertidos en este trabajo y la aplicación de las reglas
desarrolladas. El diagrama final que concretado en el gráfico 26.
Con la finalidad de mostrar la aplicación de las otras

reglas y proveer ejemplos prácticos adicionales de normalización de bases de
datos a partir de especificaciones relativamente simples, primero se
enumerarán los objetivos de un sistema de administración de cursos de
capacitación dictados por un Organismo Gubernamental, procediendo luego a
su normalización, luego, se procederá a indicar las especificaciones de una
imprenta y su posterior normalización.

DIARIO
EMISORES DOCUMENTACION i 23. nAsiento
iii
7. cNombreEmisor 5. nIdComprobante [24. mComentario]
8. cIdEmisor 23. nAsiento 25. fAsiento
26. fAsentado
27. cOperador
i 28. cComputadora
COMPROBANTES 32. Cerrado
1. fComprobante
TIPOS vii
2. cTipoEmisor
COMPROBANTES
5. nIdComprobante
3. cTipoComprobante
6. nComprobante
4.DesComprobante DETALLAASIENTOS
'3. 'cTipoComprobante
'8. 'cIdEmisor 29. cCaracterCuenta
ii
30. yImporte
iv 31. nR englon
23. nAsiento
12. cCodigoCuenta
vii
CONCEPTOS PLANCUENTAS
TIPOS
9. yM ontoConcepto 12. cCodigoCuenta
CONCEPTOS v
5. nIdComprobante vi 13. cNombreCuenta
10. cTipoConcepto
34. nConcepto [14. cCodigoAbreviado]
11. cDesConcepto
'10. 'cTipoConcepto [15. cCodigoCorto]
[16. mDescripcion]
17. ySaldoAnterior
18. ySaldoActual
Elementos agregados en 19. fSaldo
este diagrama con referencia 20. lTieneSubCuentas
al anterior estan en trasos
21. lR equiereM ayor
mas gruesos (negrita)
22. TieneSubDiario
'34. 'nCuentaMaestra
Diagrama después de aplicar las 6ta y 8va reglas (Gráfico 26)

Sistema de Administración de Cursos:
Objetivos de la Aplicación:
El sistema deberá:
1. Llevar el control de asistencia de los alumnos a los cursos dictados por el
Organismo, ...
2. Seguimiento del equipamiento que utilizan.
3. Registrar la asistencia de los alumnos, con una interfase a utilizar por los
mismos.
4. Que los alumnos puedan registrar preguntas, a contestar por el profesor.
5. Que las preguntas y sus respuestas estén disponibles para ser accedidas por
cualquiera de los alumnos.
1. En este sistema, se necesitan datos de personas, que participan en el

mismo, como empleados (de diverso tipo), alumnos y/o personas
vinculadas (familiares, empleadores, etc.), por ello de todas ellas se deberá
disponer de los siguientes datos43:
a) Identificador Número de Control Interno, exclusivo de la persona,...
b) Documento de Identidad (tipo codificado y su número),...
c) Apellido, Primer Nombres, y otros Nombres e Iniciales (por
separado),...
d) Fecha de Nacimiento,...
e) Sexo,...
f) Ciudad, Calle, Número, Piso, Dpto., Barrio, lo mas codificado posible,
para evitar redundancia de datos y simplificar la carga, por cada tipo de
dirección (postal, legal, laboral, etc.) disponible,...
g) Teléfonos que disponga, con su tipo...
h) Direcciones de Correo Electrónico,...
44
i) Carácter de la persona (Codificado) ,...
j) Estudios Previos de mayor nivel alcanzado por la persona,
codificados,...
k) Grado de avance del alumno en los estudios indicados (año, ciclo según
corresponda),...
l) Observaciones sobre la persona que se considere oportuno registrar (con
fecha y hora).
m) Según la persona registrar...
i) Si es funcionario, empleado de planta o de plan de empleo:
45
(1) Número de Legajo personal ,...
43
Salvo la identificación de instancia y el nombre de la persona, ningún otro dato personal es obligatorio, si los mismos
no están disponibles, deberán cargarse como nulos.
44
El carácter de la persona es si es empleado, funcionario, persona relacionada, etc.
45
Si el legajo esta disponible, lo carga el operador, caso contrario, lo genera el sistema con números negativos de valor
absoluto creciente.

(2) Año de Ingreso al Municipio,...

(3) Oficina donde se desempeña con los siguientes datos:
(a) Código,...
(b) Descripción,...
(c) Teléfonos,...
46
(d) Funcionario o responsable a cargo ,...
47
(e) Empleados contacto, puede haber más de uno ,...
(4) Cargo que desempeña (codificados),...
48
(5) Condiciones de empleo (codificados) .
ii) Si no es empleado, los siguientes datos:
(1) Oficina que lo envía, con los mismos datos requeridos para las
oficinas de los empleados.
(2) Si trabaja, lugar donde trabaja con los siguientes datos:
(a) Un identificador interno,...
(b) Denominación de la empresa,...
(c) Dirección postal de la empresa, con los datos como se indico
para personas en 1)f)
(d) Teléfonos,...
49
(e) Persona que es contacto .
n) Personas relacionadas y tipo de relación, codificadas,...
2) Para cada tipo de curso que se dicte:
a) Un código identificador,...
b) Descripción del curso,...
c) Cantidad de clases del curso,...
d) Duración de cada clase,...
3) Para cada vez que se dicta un curso, diferenciando inclusive si el mismo
curso se dicta los mismos días, en distinto horario (turno), se deberá contar
con:
a) Un identificador interno de dictado
b) El curso que se dicta,...
c) La persona que lo dicta (puede variar de un dictado al otro),...
d) Fecha de inicio del curso,...
e) Días de la semana que se dicta,...
f) Horario de comienzo de la clase.
4) Para el control de asistencia se deberá contar con los siguientes datos:
a) Identificación de la Persona,...
b) Fecha de la clase,...
c) Hora de inicio de la clase,...
d) Tiempo de clase,...
46
Del funcionario o responsable son necesarios los mismos datos que si fuera un empleado.
47
De los empleados que son contactos, los mismos datos que los que hacen cursos.
48
Si es empleado de planta, contratado o permanente, si es plan de empleo, descripción del plan.
49
Del contacto son necesarios los mismos datos que cualquier otra persona.

e) Máquina asignada (codificadas),...

50
f) Estado de la asistencia (codificada) ,...
g) Identificador de dictado (ver punto previo).
5) Para el manejo de preguntas de los alumnos, deberá contarse con:
a) Identificador de pregunta,...
b) Texto de la pregunta,...
c) Fecha y Hora de la pregunta,...
d) Persona que hizo la pregunta,...
e) Texto de la respuesta,...
51
f) Profesor que respondió ,...
g) Fecha y hora de la respuesta,...
h) Tema y subtema para el encuadre de la pregunta (codificados).
6) El sistema deberá además proveer control de acceso (identificación de los
alumnos y contraseña de los alumnos).
Cuando en las especificaciones precedentes se indica que

se necesitan atributos codificados, implica que estos en lugar de cargarse en
forma descriptiva en las respectivas entidades, se busca que los mismos se
detallen en dominios de atributos, de manera tal que el sistema provea datos
en forma consistente, facilitando su carga y reduciendo el volumen de
almacenamiento necesario.
Para el manejo de direcciones de las personas en el

sistema, y complementando las especificaciones precedentes, se busca definir
cada dirección como un objeto, de manera tal que las mismas pueden ser
referenciadas por diversas entidades con distinto carácter.
En algunos casos, aparecen entidades como débiles, ya

que se indican como dependientes de alguna de las poblaciones con las cuales
se vinculan. Estas surge de la interpretación particular que se le dan a las
especificaciones indicadas previamente.
En otros casos se indican relaciones muchos a muchos

“tripartitas” y en otros se especifican dominios de valores relacionados con
dichas relaciones muchos a muchos, como se indicó previamente, emergente
de la interpretación que se hizo en el presente trabajo.
A continuación se vuelca el primer tabulado requerido

por las reglas propuestas, que corresponde a las entidades detectadas al leer
las especificaciones:
50
El estado de la asistencia puede ser presente, ausente o algún código que indique la justificación de la falta.
51
Para el profesor prever los datos como que es un empleado más.


ID Carácter Documentación
Nombre Entidad Descripción Entidad
E Entidad Fuente
A Personas Personas en el Sistema Fuerte 1 a)

B TiposDocumento Tipos Documentos de las Personas Dominio Valores 1 b)
C Ciudades Ciudades donde viven personas Dominio Valores 1 f)
D Calles Calles donde hay direcciones de Personas Dominio Valores 1 f)
Barrios que complementan los datos de dirección de las
E Barrios Dominio Valores 1 f)
personas
F TiposDireccion Tipos de Direcciones de las Personas Fuerte 1 f)
Direcciones disponibles, se manejan por separado para
G Lugares Fuerte 1 f)
evitar redundancia
H Teléfonos Teléfonos que tiene una persona Débil (A) 1 g)
I TiposTelefonos Tipos de Teléfonos de una Persona Dominio Valores 1 g)
J DireccionesCorreo Direcciones Correo Electrónico Débil (A) 1 h)
K TiposPersonas Tipo o Carácter de la Persona Dominio Valores 1 i)
L TiposEstudios Tipos de Estudios alcanzados por la Personas Dominio Valores 1 j)
M Observaciones Observaciones sobre la persona Débil (A) 1 l)
N Empleados Empleados, funcionarios, planes de empleo, etc. Débil (A) 1 m) i)
O Oficinas Oficinas donde trabajan los empleados Dominio Valores 1 m) i) (3)
P TelefonosOficinas Teléfonos que tiene una Oficina Débil (O) 1 m) i) (3) (c)
Q Contactos Empleados que son contactos en una oficina Débil (N) 1 m) i) (3) (d)
R Cargos Cargos que puede desempeñar un empleado Dominio Valores 1) m) i) (4)
S Condiciones Condiciones de empleo de un empleado Dominio Valores 1) m) i) (5)
T Invitados Personas que participan en los cursos sin ser empleados Débil (A) 1) m) ii)
U Empresas Empresas, etc. que proveen empleo a las personas Fuerte 1) m) ii) (2)
V TelefonosEmpresas Una empresa puede tener varios teléfonos Débil (U) 1) m) ii) (2) (d)
W TiposRelaciones Tipos de Relaciones entre Personas Dominio Valores 1) n)
X Cursos Cursos que se dictan Fuerte 2)
Y Dictados Dictados de cada curso Débil (X) 3)
Z Máquinas Máquinas utilizadas para los cursos Dominio Valores 4) e)
Estados posibles de las Asistencia (ausencia,
AA EstadosAsistencias Dominio Valores 4) f)
justificación, etc.)
AB Preguntas Preguntas efectuadas por los alumnos Débil (A) 5)
AC Temas Tema en el que se encuadra una pregunta Dominio Valores 5 h)
AD SubTemas Sub Tema en el que se encuadra una pregunta Débil (AC) 5 h)
AE Usuarios Usuarios del Sistema Débil (A) 6)
AF Bitácora Registro de Entrada y Salida de Usuarios Fuerte 6)
En cualquier interpretación semántica puede haber

diferencias, ya que en las mismas, juegan notoriamente la experiencia previa
del analista y/o el diseñador, que puede, dentro de la libertad propia de su
profesionalidad, incluir “experiencias” de su propia cosecha.
A continuación se vuelca el segundo tabulado:


Tipo Documentación
IDR Nombre Relación Descripción Relación
Relación Fuente
Personas- Una persona tiene un documento de un tipo pero puede no
i A<<0:0>B 1 a) y 1 b)
TiposDocumentos conocerse su documento.
Direcciones
Una persona puede tener distintos tipos de direcciones.
ii (Personas con A<<0:0>>F 1 f)
Estos pueden estar disponibles para cualquier persona.
TiposDireccion)
Cada relación entre Personas-TipoDirección y
Direcciones, una dirección puede aparecer en distintas de
iii Direcciones-Lugares ii<<0:|>G 1 f)
dichas relaciones pero estas solo tienen una dirección.
(esto debido al requerimiento de que no se repitan datos)
Ciudad donde esta la Dirección, una dirección tiene que
iv Ciudades-Lugares C<|:0>>G tener una ciudad pero una ciudad puede no estar en 1 f)
ninguna de las direcciones cargadas.
Calle donde esta la Dirección, una dirección tiene que
v Calles-Lugares D<|:0>>G tener una calle pero una calle puede no estar referenciada 1 f)
ninguna de las direcciones cargadas.
Barrio donde esta la Dirección, una dirección puede tener
vi Barrios-Lugares E<|:0>>G un barrio y algunos barrios pueden no estar referenciados 1 f)
a ninguna de las direcciones cargadas.
Una persona puede tener o no teléfonos, puede tener mas
vii Personas-Teléfonos A<|:0>>H 1 g)
de uno
Teléfonos- Un teléfono puede tener asignado un tipo de teléfono, el
viii H<<0:0>I 1 g)
TiposTelefonos mismo tipo puede asignarse a mas de un tipo
Personas- Una persona puede tener ninguna o más direcciones de
ix A<|:0>>J 1 h)
DireccionesCorreo correo electrónico
Personas- Una persona tiene un carácter o tipo, no necesariamente
x A<<0:|>K 1 i)
TiposPersonas en forma exclusiva
Personas- Una persona tiene algún tipo de estudio, no
xi A<<0:|>L 1 j)
TiposEstudios necesariamente en forma exclusiva
Personas- Observaciones sobre una persona efectuada, con fecha y
xii A<|:0>>M 1 l)
Observaciones hora
Una persona puede o no ser empleado, funcionario, etc.
xiii Personas-Empleados A<|:0>N 1 m) i)
Estos últimos no pueden ser varias personas a la vez
Empleados-Oficinas Un empleado trabaja en una oficina, en esta puede haber
xiv N<<0:|>O 1 m) i) (3)
(trabajan en...) varios empleados
Oficinas-
xv O<|:0>>P Una oficina puede tener 0 ó más teléfonos 1 m) i) (3) (c)
TelefonosOficinas
Un empleado puede ser el responsable de una oficina (no
Empleados-Oficinas
xvi N<|:0>O todos los empleados son funcionarios) Una oficina tiene un 1 m) i) (3) (d)
(son jefes de...)
solo empleado como jefe.
Empleados-
xvii N<|:0>Q Un empleado puede ser contacto de una oficina 1 m) i) (3) (e)
Contactos
Varios Contactos pueden ser de una oficina, pero cada uno
xviii Contactos-Oficinas Q<<0:>O 1 m) i) (3) (e)
de una sola
Varios Empleados pueden tener el mismo cargo pero solo
xix Empleados-Cargos N<<0:0>R 1) m) i) (4)
un cargo por empleado
Empleados- Varios Empleados pueden tener la misma condición de
xx N<<0:0>S 1) m) i) (5)
Condiciones empleo pero solo una por empleado


Tipo Documentación
IDR Nombre Relación Descripción Relación
Relación Fuente
Una persona puede o no ser un invitado a realizar los
xxi Personas-Invitados A<|:0>T 1) m) ii)
cursos (participante externo)
Un invitado debe ser enviado por alguna oficina, una
xxii Invitados-Oficinas T<<0:|>O 1) m) ii) (1)
oficina puede 0 o más invitados
Un invitado puede tener un empleador, un empleador mas
xxiii Invitados-Empresas T<<0:0>U 1) m) ii) (2)
de un invitado
Una empresa puede tener definida una dirección postal,
xxiv Empresas-Lugares U<<0:0>G 1) m) ii) (2) (c)
varios la misma.
Empresas-
xxv U<|:0>>V Una empresa puede tener 0 o más teléfonos 1) m) ii) (2) (d)
TelefonosEmpresas
Relaciones Una persona puede tener relaciones con muchas otras
xxvi A<<0:0>>A 1) n)
(Personas-Personas) personas
Relaciones- Una relación es de algún tipo, varias relaciones pueden ser
xxvii xxvi<<0:|>W 1) n)
TiposRelaciones del mismo tipo
Un curso puede dictarse mas de una vez, pero cada
xxviii Cursos-Dictados X<|:0>>Y 3) y 3 b)
dictado es de un curso
Un dictado de un curso lo hace una persona y una persona
xxix Dictados-Empleados Y<<0:|>N 3) c)
puede dictar varios cursos
Asistencias Una persona puede asistir a dictados de distintos cursos, a
xxx Y<<0:0>>A 4), 4) a) y 4) g)
(Personas-Dictados) un dictado pueden concurrir más de una persona
Asistencias- En una asistencia puede utilizarse una máquina, esta
xxxi xxx<<0:0>Z 4) c)
Máquinas puede usarse en diversas asistencias
Asistencias- Una asistencia puede tener distintos estados (presente,
xxxii xxx<<0:0>AA 4) e)
EstadoAsistencias ausente, justificado, etc.)
Una persona como alumno puede hacer una o más
xxxiii Personas-Preguntas A<|:0>>AB 5)
preguntas
Personas-Preguntas Una pregunta es respondida por una persona, la cual
xxxiv A<0:0>>AB 5 f)
(respuesta) puede contestar a varias
Preguntas- Una pregunta puede ser encuadrada en un sub tema, más
xxxv AB<<0:0>AD 5 h)
SubTemas de una pregunta puede tener el mismo subtema
Un subtema esta comprendido en un tema, un tema tiene
xxxvi SubTemas -Temas AD<<|:|>AC 5 h)
varios subtemas
Una persona puede ser un usuario, un usuario es sí o sí
xxxvii Personas-Usuarios A<|:0>AE 6)
una persona
Un usuario puede tener registrado 0 o más entradas en la
xxxviii Usuarios-Bitácora AE<0:0>>AF bitácora, en la bitácora además se registran los accesos 6)
fallidos
Una empresa puede tener una persona que oficie de
xxxix Empresas-Personas U<0:0>A 1) m) ii) (2) (e)
contacto.
Y por último se vuelca el tabulado de atributos, con lo

que quedan pasadas en limpio las especificaciones del sistema de Gestión de
Cursos:


Valor X Regla
1) Nombre Atributo Descripción Atributo 2) 3) 4)
Omisión Validación
Identificador de la persona. Único, no Auto-
1 nPersona A No No Duplicados 1 a)
se repite. Generado
No Nulo ni igual a
Número de Documento Persona. Si se
0 si
2 nDocumento especifica, debe haber A Si 1 b)
cTipoDocumento
cTipoDocumento
es No Nulo
Tipo de Documento. Combinado con Mnemo No Duplicados. No
3 cTipoDocumento B No 1 b)
nDocumento no debe repetirse. Usuario en Blanco
Descripción Tipo Documento (esto no No Duplicados. No
4 cDesDocumento B No 1 b)
debe estar abreviado) en Blanco
5 cApellido Apellido de la Persona A No No en Blanco 1 c)
6 cPrimerNombre Primer Nombre de la Persona A No No en Blanco 1 c)
No en Blanco si no
7 cOtrosNombres Otros Nombres de la Persona A Si 1 c)
nulo
1er. Letra No Duplicados. No
8 cIniciales Iniciales de la Persona A No 1 c)
de 6) y 7) en Blanco
Al menos 8 años
9 fNacimiento Fecha Nacimiento Persona A Si 1 d)
de edad
10 cSexo Sexo de la Persona A No "M" ó "F" 1 e)
Codigos No Duplicados.
11 nCodigoPostal Código Postal de la Ciudad C No Postales Entre 1000 y 9999 1 f)
Correo inclusive
12 cCiudad Nombre de la Ciudad C No No en Blanco 1 f)
Mnemo No Duplicados. No
13 cCodigoCalle Código asignado a la Ciudad D No 1 f)
Usuario en Blanco
No Duplicados. No
14 cCalle Nombre de la Calle D No 1 f)
en Blanco
15 cCodigoBarrio Código asignado a cada barrio E No
Usuario en Blanco
No Duplicados. No
16 cBarrio Nombre del Barrio E No 1 f)
en Blanco
17 nPuerta Número de la Puerta en la dirección G No Mayor que 0 1 f)
Puede estar en
18 cPiso Piso que corresponde a la Dirección G No 1 f)
blanco
Departamento que corresponde a la Puede estar en
19 cDepartamento G No 1 f)
Dirección blanco
20 cTipoDireccion Código del Tipo de Dirección F No 1 f)
Usuario en Blanco
21 cDesDirección Descripción del Tipo de Dirección F No No en Blanco 1 f)
Auto-
22 nLugar Identificador Interno de cada lugar G No No Duplicados. 1 f)
Generado
23 nTelefono Número de teléfono de la persona H No Al menos 5 dígitos 1 g)
24 cTipoTelefono Código Tipo teléfono I No 1 g)
Usuario en Blanco
No en Blanco. No
25 cDesTipoTelefono Descripción del Tipo de teléfono I No 1 g)
Duplicados
26 cDirecciónCorreo Dirección de Corre Electrónico J No No en Blanco 1 h)
Descripción Carácter de la persona en No Duplicados. No
27 cDesCaracter K No 1 i)
el sistema en Blanco


Valor X Regla
Código Carácter de la persona en el Mnemo No Duplicados. No
28 cCaracter K No 1 i)
sistema Usuario en Blanco
Mnemo
29 cTipoEstudio Código Tipo Estudio alcanzado L No No Duplicados. 1 j)
Usuario
Descripción del Tipo de Estudio No Duplicados. No
30 cDesEstudio L No 1 j)
alcanzado en Blanco
Grado Avance en Estudio, Año,
31 cGradoAvance A Si No en Blanco 1 k)
materias, etc.
Texto Observación efectuada sobre
32 cObservacion M No No en Blanco 1 l)
una persona
Fecha y hora del
Fecha y Hora en que se efectuó la DATE
33 tObservacion M No Sistema o la que 1 l)
observación TIME()
entre el usuario
Auto- No duplicados, 1 m) i) (1)
34 nLegajo Número de Legajo del Empleado N No
Generado distinto de cero. (ver Nota 3)
35 nAñoIngreso Año de Ingreso al Municipio N Si Mayor que 1950 1 m) i) (2)
Mnemo No Duplicados. No 1 m) i) (3)
36 cOficina Código de la Oficina O No
Usuario en Blanco (a)
Descripción o Denominación de la No Duplicados. No 1 m) i) (3)
37 cDesOficina O No
Oficina en Blanco (b)
Teléfono de la Oficina, generalmente
1 m) i) (3)
38 cTelefonoOficina incluye extensión o elementos P No No en Blanco.
(c)
similares
Identificación persona que se
39 nPersonaRelacionada relaciona (persona que se relaciona xxvi No 1) n)
con esta)
40 cCodigoCargo Código Cargo del Empleado R No 1) m) i) (4)
Usuario en Blanco
No Duplicados. No
41 cDesCargo Descripción del Cargo R No 1) m) i) (4)
en Blanco
42 cCodigoCondicion Código Descripción de la condición S No 1) m) i) (5)
Usuario en Blanco
Descripción de la Condición de No Duplicados. No
43 cDesCondición S No 1) m) i) (5)
Empleo en Blanco
Auto- No duplicados, 1) m) ii) (2)
44 nEmpresa Código Identificador Empresa U No
Generado mayor que 0 (a)
1) m) ii) (2)
45 cDenominación Denominación de la Empresa U No No en Blanco
(b)
1) m) ii) (2)
46 cTelefonoEmpresa teléfono de la Empresa V No No en Blanco.
(d)
Código Tipo Relación entre una Mnemo No Duplicados. No
47 cTipoRelacion W No 1) n)
persona y otra Usuario en Blanco
No Duplicados. No
48 cDesRelacion Descripción del Tipo de Relación W No 1) n)
en Blanco
49 cCurso Código del Curso X No 2) a)
Usuario en Blanco
No Duplicados. No
50 cNombreCurso Denominación del Curso X No 2) b)
en Blanco
51 nClases Cantidad de Clases del Curso X No Mayor que 0 2) c)


Valor X Regla
52 nDuracion Tiempo de Cada Clase del Curso X No Mayor que 0 2) d)
Código Interno cada vez que dicta un Mnemo No Duplicados. No
53 cDictado Y No 3) a)
curso Usuario en Blanco
54 fInicio Fecha Inicio dictado del curso Y No 3) d)
Concatenación de
Dígitos donde
Días de la Semana que se hace el 0=Domingo,
55 cDiasSemana Y No 3) e)
Dictado 1=Lunes,
2=Martes,
3=Miercoles, etc.
56 nHorario Horario en comienza el curso Y No 0 a 2359 3) f)
57 fClase Fecha de la Clase xxx No Fecha Válida 4) b)
Hora inicio de la clase para una
58 nHoraInicio xxx No 0 a 2359 4) c)
asistencia dado
0 a 1440 (tiempo
59 nTiempo Tiempo real de clase xxx No 4) d)
en minutos)
60 cMaquina Código de Maquina usada Z No 4) e)
Usuario en Blanco
No Duplicados. No
61 cDesMáquina Descripción de la Máquina Z No 4) e)
en Blanco
62 cCodEstado Código Estado Asistencia AA No 4) f)
Usuario en Blanco
Descripción del Estado de la No Duplicados. No
63 cDesEstado AA No 4) f)
Asistencia en Blanco
Auto- No duplicados,
64 nIdPregunta Número Identificador Pregunta AB No 5 a)
Generado mayor que 0
Texto de la Pregunta Efectuada por el
65 mPregunta AB No No en blanco 5 b)
Alumno
Fecha y Hora en que se efectuó la DATE Generada por el
66 tFechaHoraPregunta AB No 5 c)
pregunta TIME() Sistema
No en blanco. Es
Texto de la Respuesta efectuada por nulo si no esta la
67 mRespuesta AB Si 5 e)
el profesor pregunta
respondida
Fecha y Hora en que se dio respuesta DATE Generada por el
68 tFechaHoraRespuesta AB Si 5 f)
a la pregunta TIME() Sistema
69 cCodigoSubTema Código Identificador del SubTema AD No 5 h)
Usuario en Blanco
70 cSubTema Descripción del SubTema AD No No en blanco 5 h)
71 cCodigoTema Código Identificador del Tema AC No 5 h)
Usuario en Blanco
72 cTema Descripción del Tema AC No No en blanco 5 h)
Identificación de la persona como Mnemo No Duplicados. No
73 cIdentificacion AE No 6)
usuario Usuario en Blanco
Función Valor Hash sobre 6)
74 nContraseña Valor Hash de la Contraseña AE No
Hash() la contraseña
Fecha y hora del 6)
Fecha y Hora que el usuario se DATE Sistema en la que
75 tFechaHoraEntrada AF No
registra TIME() el usuario se
identifique


Valor X Regla
Fecha y hora del 6)
Sistema en la que
Fecha y Hora que el usuario termina DATE
76 tFechaHoraSalida AF No el usuario termina
su sesión de trabajo TIME()
su sesión de
trabajo
Texto registrado 6)
Texto sobre notas observaciones de por el profesor
77 mObservación lo ocurrido en la sesión de trabajo del AF Si referente a la
usuario actividad del
alumno
Debe ser una Regla 7
Identificación de la persona que
pregunta que
78 nPersonaResponde responde a la pregunta efectuada por AF Si
exista, nulo si no
un alumno.
se respondió

Una vez terminado la confección de los tabulados

indicados por la Regla 1 (todos sus incisos), se procederá a confeccionar el
diagrama indicado por la regla 2 (diagramación de las entidades).
En un primer intento, al diagramar las entidades,

simplemente se transcribirán las enumeradas en el primer tabulado, tal cual
aparecen, se incluye por razones de claridad, tanto el nombre asignado a cada
una como la letra correspondiente. No se plantea una distribución especial ya
que para ello se debería ir analizando el tabulado de relaciones.
Dependiendo de la herramienta que se utilice para trazar

el diagrama, en el caso de trabajar con herramientas manuales, puede ser
práctico ir visualizando tanto el primer tabulado como el segundo, a los
efectos de poder ir distribuyendo las entidades, de manera tal de que vayan
quedando cerca aquellas que tienen que ver entre si.
En el caso de utilizar algún utilitario para diagramación,
la cosa cambia ya que es mucho más fácil y modificando posteriormente
dicho diagrama.

PERSONAS TIPOS CIUDADES CALLES

(A) DOCUMENTOS (B) (C) (D)
BARRIOS TIPOS LUGARES TELEFONOS

(E) DIRECCION (F) (G) (H)
TIPOS DIRECCIONES TIPOS TIPOS

TELEFONOS (I) CORREO (J) PERSONAS (K) ESTUDIOS (L)
OBSERVACIONES EMPLEADOS OFICINAS TELEFONOS

(M) (N) (O) OFICINAS (P)
CONTACTOS CONDICIONES CARGOS INVITADOS

(Q) S (R) (T)
EMPRESAS TELEFONOS TIPOS CURSOS

(U) EMPRESAS (V) RELACIONES (W) (X)
DICTADOS MAQUINAS ESTADOS PREGUNTAS

(Y) (Z) ASISTENCIAS (AA) (AB)
TEMAS SUBTEMAS USUARIOS BITACORA

(AC) (AD) (AE) (AF)
Entidades Sistema Gestión Cursos después de la 2da regla (gráfico 27)
Para diagramar la siguiente regla, se utilizó un programa

“ad hoc”, se reubicaron las entidades de manera tal de que las relaciones a
trazar entre las mismas no se superpusieran con los bloques de cada entidad
(o los bloques correspondientes a relaciones muchos a muchos) y se trato
(casualmente con éxito) que las líneas respectivas no se cortaran mutuamente.

xii
xviii TIPOS vi
CONTACTOS OFICINAS BARRIOS CIUDADES
DIRECCION
xiv iv
ii
TELEFONOS iii
CARGOS DIRECCIONES LUGARES
xv OFICINAS
xix ii
xvi
TIPOS
EMPLEADOS CALLES
xvii PERSONAS v
xxix x
xx xxvii
xxvi TIPOS
CONDICIONES RELACIONES
DICTADOS RELACIONES
xxvi
xxx
xiii
i TIPOS
TIPOS xi
PERSONAS DOCUMENTOS
ESTUDIOS
xxx
ix
DIRECCIONES TELEFONOS
MAQUINAS vii
CORREO
xxxi
xxxiii xxxiv viii
TIPOS
ASISTENCIAS PREGUNTAS
TELEFONOS
xxviii xxxii xxxv
ESTADOS xxxvi
CURSOS OBSERVACIONES SUBTEMAS TEMAS
ASISTENCIAS xii
xxxviii TELEFONOS
INVITADOS BITACORA USUARIOS
xxxvii EMPRESAS
xxi
xxv
xxxix EMPRESAS
xxiv
xxiii
Entidades con sus relaciones después de la 3ra regla (gráfico 28)
Hasta aquí, se han trazado solo las relaciones entre

entidades, las cuales quedarán completas al aplicar las reglas 6ta a 9na por que
las mismas necesitan atributos equivalentes en las tablas vinculadas dentro de
la arquitectura de bases de datos relacionales.
A continuación se inserta el grafico 29 donde se procede

a incluir los atributos correspondientes de acuerdo a la 4ta regla propuesta:

xii
CONTACTOS OFICINAS TIPOS BARRIOS vi CIUDADES

36. cOficina DIRECCION 15. cCodigoBarrio 11. nCodigoPostal
xviii
37. cDesOficina 20. cTipoDireccion 16. cBarrio 12. cCiudad
xiv 21. cDesDireccion iv
ii LUGARES
CARGOS
TELEFONOS DIRECCIONES iii 17. nPuerta
40. cCodigoCargo
OFICINAS 18. cPiso
41. cDesCargo xv
38. cTelefonoOficina 19. cDepartamento
xix ii 22. nLugar
xvi
EMPLEADOS TIPOS CALLES

34. nLegajo PERSONAS 13. cCodigoCalle
xvii v
35. nAñoIngreso 27. cDesCaracter 14. cCalle
xxix 28. cCaracter

x
xx xxvii
CONDICIONES xxvi RELACIONES TIPOS

42. cCodigoCondicion RELACIONES
43. cDesCondicion 47. cTipoRelacion
xxvi
48. cDesRelacion
PERSONAS
TIPOS
xiii 1. nPersona
2. Documento i DOCUMENTOS
DICTADOS TIPOS 5. cApellido 3. cTipoDocumento
53. cDictado ESTUDIOS xi 6. cPrimerNombre 4. cDesDocumento
54. fInicio 29. cTipoEstudio 7. cOtrosNombres
55. cDiasSemana 30. cDesEstudio 8. cIniciales
9. fNacimiento xxxiv
56. nHorario
10. cSexo
xxx
31. cGradoAvance
ix vii
MAQUINAS DIRECCIONES TELEFONOS

60. cM aquina CORREO 23. nTelefono
61. cDesM aquina 26. cDireccionCorreo
xxxi xxxiii
PREGUNTAS viii
64. nIdPregunta
ASISTENCIAS TIPOS
65. mPregunta
57. fClase
66. tFechaHoraPregunta TELEFONOS
58. nHoraInicio xxx 24. cTipoTelefono
67. mRespuesta
59. nTiempo 25. cDesTipoTelefono
68. FechaHoraRespuesta
xxviii
xxxii xxxv
CURSOS
ESTADOS OBSERVACIONES SUBTEMAS
49. cCurso
50. cNombreCurso ASISTENCIAS 32. cObservacion 69. cCodigoSubTema
xii
62. cCodEstado 33. tObservacion 70. cSubTema
51. nClases
52. nDuracion 63. cDesEstado
xxxvi
BITACORA
75. tFechaHoraEntrada xxxviii USUARIOS TELEFONOS TEMAS
INVITADOS 73. cIdentificacion 71. cCodigoTema
76. tFechaHoraSalida xxxvii EMPRESAS
74. nContraseña 72. cTema
77. mObservacion 46. cTelefonoEmpresa
xxi
xxv
EMPRESAS
xxxix 44. nEmpresa
xxiv
45. cDenominacion
xxiii
Entidades, sus relaciones y atributos después de la 4ta regla (gráfico 29)

Con la 5ta regla se definen los atributos claves de cada

entidad, algunas pueden en este paso figurar sin clave (y aún sin atributos):
xii
CONTACTOS OFICINAS TIPOS BARRIOS vi CIUDADES

36. cOficina DIRECCION 15. cCodigoBarrio 11. nCodigoPostal
xviii
ii LUGARES
CARGOS
TELEFONOS DIRECCIONES iii 17. nPuerta
40. cCodigoCargo
OFICINAS 18. cPiso
41. cDesCargo xv
38. cTelefonoOficina 19. cDepartamento
xix ii 22. nLugar
xvi
EMPLEADOS TIPOS CALLES

34. nLegajo PERSONAS 13. cCodigoCalle
xvii v
[35. nAñoIngreso] 27. cDesCaracter 14. cCalle
xxix 28. cCaracter

x
xx xxvii
CONDICIONES xxvi RELACIONES TIPOS

42. cCodigoCondicion RELACIONES
43. cDesCondicion 47. cTipoRelacion
xxvi
48. cDesRelacion
PERSONAS TIPOS
xiii 1. nPersona DOCUMENTOS
[2. nDocumento]
DICTADOS TIPOS i 3. cTipoDocumento
5. cApellido
53. cDictado 4. cDesDocumento
ESTUDIOS [6. cPrimerNombre]
54. fInicio
29. cTipoEstudio xi [7. cOtrosNombres]
55. cDiasSemana
30. cDesEstudio 8. cIniciales
56. nHorario xxxiv
[9. fNacimiento]
xxx 10. cSexo
[31. cGradoAvance]
ix vii
MAQUINAS DIRECCIONES TELEFONOS

60. cMaquina CORREO 23. nTelefono
61. cDesM aquina 26. cDireccionCorreo
xxxi xxxiii
PREGUNTAS
viii
64. nIdPregunta
ASISTENCIAS
65. mPregunta TIPOS
57. fClase
66. tFechaHoraPregunta TELEFONOS
58. nHoraInicio xxx [67. mRespuesta] 24. cTipoTelefono
59. nTiempo
[68. FechaHoraR espuesta] 25. cDesTipoTelefono
xxviii
xxxii xxxv
CURSOS
ESTADOS OBSERVACIONES SUBTEMAS
49. cCurso
50. cNombreCurso
ASISTENCIAS 32. cObservacion 69. cCodigoSubTema
xii
62. cCodEstado 33. tObservacion 70. cSubTema
51. nClases
xxxvi
BITACORA
xxxviii USUARIOS TELEFONOS TEMAS
INVITADOS 75. tFechaHoraEntrada
73. cIdentificacion 71. cCodigoTema
76. tFechaHoraSalida xxxvii EMPRESAS
74. nContraseña 72. cTema
[77. mObservacion] 46. cTelefonoEmpresa
xxi
xxv
EMPRESAS
xxxix 44. nEmpresa
xxiv
45. cDenominacion
xxiii
Determinación de los atributos claves al aplicar la 5ta regla (gráfico 30)

xii
CONTACTOS xviii OFICINAS TIPOS BARRIOS vi CIUDADES

'36. 'cOficina 36. cOficina DIRECCION 15. cCodigoBarrio 11. nCodigoPostal
LUGARES
CARGOS TELEFONOS ii
'11. 'nCodigoPostal
40. cCodigoCargo OFICINAS DIRECCIONES iii '13. 'cCodigoCalle
41. cDesCargo xv 36. cOficina
'15. 'cCodigoBarrio
xix 38. cTelefonoOficina 17. nPuerta
ii 18. cPiso
19. cDepartamento
xvi
22. nLugar
EMPLEADOS TIPOS
34. nLegajo CALLES
PERSONAS
[35.
[35.nAñoIngreso]
nAñoIngreso] 13. cCodigoCalle
27. cDesCaracter
'36. 'cOficina 14. cCalle
v
xvii 28. cCaracter
'40. 'cCodigoCargo
'42. 'cCodigoCondicion x
xxix xxvii
xx xxvi RELACIONES TIPOS

47. cTipoRelacion
42. cCodigoCondicion xxvi
48. cDesR elacion
43. cDesCondicion
PERSONAS
TIPOS
xiii 1. nPersona i DOCUMENTOS
[2. nDocumento]
DICTADOS '3. 'cTipoDocumento 3. cTipoDocumento
'34. 'nLegajo TIPOS 5. cApellido 4. cDesDocumento
'49. 'cCurso ESTUDIOS xi [6. cPrimerNombre]
53. cDictado 29. cTipoEstudio [7. cOtrosNombres]
54. fInicio 30. cDesEstudio 8. cIniciales
55. cDiasSemana [9. fNacimiento] xxxiv
56. nHorario 10. cSexo
'29. 'cTipoEstudio vii
xxx MAQUINAS [31. cGradoAvance]
60. cMaquina ix TELEFONOS
61. cDesM aquina DIRECCIONES 1. nPersona
23. nTelefono
xxxi CORREO xxxiii
'24. 'cTipoTelefono
1. nPersona
26. cDireccionCorreo
PREGUNTAS
64. nIdPregunta
ASISTENCIAS 65. mPregunta
viii
57. fClase 66. tFechaHoraPregunta
58. nHoraInicio [67. mRespuesta] TIPOS
59. nTiempo xxx [68. FechaHoraRespuesta] TELEFONOS
'60. 'cM aquina '69. 'cCodigoSubTema
24. cTipoTelefono
'62. 'cCodAsistencia '71. 'cSubTema
25. cDesTipoTelefono
xxviii xxxv
xxxii
CURSOS SUBTEMAS
ESTADOS OBSERVACIONES
49. cCurso 69. cCodigoSubTema
50. cNombreCurso ASISTENCIAS 1. nPersona
71. cCodigoTema
62. cCodEstado 32. cObservacion xii
51. nClases 70. cSubTema
63. cDesEstado 33. tObservacion
52. nDuracion
xxxvi
BITACORA TELEFONOS
INVITADOS 73. cIdentificacion xxxviii USUARIOS EMPRESAS TEMAS
'36. 'cOficina 75. tFechaHoraEntrada 73. cIdentificacion 44. nEmpresa 71. cCodigoTema
76. tFechaHoraSalida xxxvii
'44. 'nEmpresa 74.
74.nContraseña
nContraseña 46. cTelefonoEmpresa 72. cTema
[77. mObservacion]
xxi
xxv
EMPRESAS
'22. 'nLugar
xxxix
44. nEmpresa xxiv
xxiii 45. cDenominacion
Pase de claves primarias de las entidades “unos” a las “muchos”

Por aplicación de la 6ta regla (gráfico 31)

xii

LUGARES
CARGOS TELEFONOS ii
'11. 'nCodigoPostal
40. cCodigoCargo OFICINAS DIRECCIONES iii '13. 'cCodigoCalle
41. cDesCargo xv 36. cOficina
'15. 'cCodigoBarrio
xix 38. cTelefonoOficina 17. nPuerta
ii 18. cPiso
19. cDepartamento
xvi
22. nLugar
EMPLEADOS TIPOS
34. nLegajo CALLES
35. PERSONAS
[35.nAñoIngreso]
27. cDesCaracter
v
xvii 28. cCaracter
'40. 'cCodigoCargo
xxix xxvii
xx xxvi RELACIONES TIPOS

47. cTipoRelacion
42. cCodigoCondicion xxvi
48. cDesR elacion
43. cDesCondicion
PERSONAS
TIPOS
[2. nDocumento]
60. cMaquina ix
xxxiii TELEFONOS
61. cDesM aquina DIRECCIONES 1. nPersona
PREGUNTAS 23. nTelefono
xxxi CORREO 64. nIdPregunta '24. 'cTipoTelefono
1. nPersona
65. mPregunta
26. cDireccionCorreo 66. tFechaHoraPregunta
[67. mR espuesta]
ASISTENCIAS
[68. FechaHoraR espuesta] viii
57. fClase
'69. 'cCodigoSubTema
58. nHoraInicio TIPOS
'71. 'cSubTema
59. nTiempo xxx TELEFONOS
'78. 'nPersonaR esponde
'60. 'cM aquina 24. cTipoTelefono
'62. 'cCodAsistencia 25. cDesTipoTelefono
xxviii xxxv
xxxii
CURSOS SUBTEMAS
ESTADOS OBSERVACIONES
49. cCurso 69. cCodigoSubTema
50. cNombreCurso
ASISTENCIAS 1. nPersona
71. cCodigoTema
62. cCodEstado 32. cObservacion xii
51. nClases 70. cSubTema
63. cDesEstado 33. tObservacion
52. nDuracion
xxxvi
BITACORA TELEFONOS
xxxvii
'44. 'nEmpresa 76. tFechaHoraSalida 74. nContraseña 46. cTelefonoEmpresa 72. cTema
74. nContraseña
[77. mObservacion]
xxi
xxv
EMPRESAS
'22. 'nLugar
xxxix
44. nEmpresa xxiv
Resolución de relaciones “unos a los muchos, muchas veces”

Por aplicación de la 7ma regla (gráfico 32)

xii

ii
LUGARES
CARGOS TELEFONOS DIRECCIONES
'11. 'nCodigoPostal
40. cCodigoCargo OFICINAS 1. nPersona
'13. 'cCodigoCalle
41. cDesCargo xv 36. cOficina 20. cTipoDireccion
iii '15. 'cCodigoBarrio
38. cTelefonoOficina 22. nLugar
xix 17. nPuerta
ii 18. cPiso
19. cDepartamento
xvi
22. nLugar
EMPLEADOS TIPOS
34. nLegajo CALLES
PERSONAS
[35.
35.nAñoIngreso]
27. cDesCaracter
v
xvii 28. cCaracter
'40. 'cCodigoCargo
xxix xxvii
xx RELACIONES TIPOS
xxvi 1. nPersona RELACIONES
CONDICIONES
39. nPersonaRelacionada 47. cTipoRelacion
42. cCodigoCondicion
47. cTipoRelacion 48. cDesR elacion
43. cDesCondicion
xxvi
PERSONAS
TIPOS
[2. nDocumento]
61. cDesM aquina xxxiii 1. nPersona
DIRECCIONES
PREGUNTAS 23. nTelefono
xxxi CORREO
64. nIdPregunta '24. 'cTipoTelefono
1. nPersona
26. cDireccionCorreo 65. mPregunta
ASISTENCIAS 66. tFechaHoraPregunta
1. nPersona [67. mRespuesta]
viii
53. cDictado [68. FechaHoraRespuesta]
57. fClase '69. 'cCodigoSubTema TIPOS
58. nHoraInicio xxx '71. 'cSubTema TELEFONOS
59. nTiempo '78. 'nPersonaResponde 24. cTipoTelefono
'60. 'cM aquina 25. cDesTipoTelefono
'62. 'cCodAsistencia
xxviii xxxv
xxxii
CURSOS SUBTEMAS
OBSERVACIONES
49. cCurso ESTADOS 69. cCodigoSubTema
1. nPersona
50. cNombreCurso ASISTENCIAS 71. cCodigoTema
32. cObservacion xii
51. nClases 62. cCodEstado 70. cSubTema
33. tObservacion
xxxvi
BITACORA TELEFONOS
76. tFechaHoraSalida xxxvii
'44. 'nEmpresa 74.
74.nContraseña
nContraseña 46. cTelefonoEmpresa 72. cTema
[77. mObservacion]
xxi
xxv
EMPRESAS
'22. 'nLugar
xxxix
44. nEmpresa xxiv
Resolución de relaciones “muchos a los muchos”

Por aplicación de la 8va regla (gráfico 33)

xii
OFICINAS TIPOS BARRIOS CIUDADES

CONTACTOS xviii '34. 'nLegajo
vi
34. nLegajo
DIRECCION 15. cCodigoBarrio 11. nCodigoPostal
36. cOficina 20. cTipoDireccion 16. cBarrio 12. cCiudad
'36. 'cOficina
37. cDesOficina 21. cDesDireccion iv
xiv
ii
LUGARES
'11. 'nCodigoPostal
'13. 'cCodigoCalle
xix 17. nPuerta
ii 18. cPiso
xvi 19. cDepartamento
22. nLugar
EMPLEADOS
xii TIPOS
'1. 'nPersona
OFICINAS PERSONAS
TIPOS CALLES
BARRIOS CIUDADES
CONTACTOS 34. nLegajo vi
xviii 35. nAñoIngreso]
'34. 'nLegajo DIRECCION
27. cDesCaracter 13. cCodigoBarrio
15. cCodigoCalle 11. nCodigoPostal
34. nLegajo [35. nAñoIngreso] v
xvii 36. 14. cBarrio
cCalle
'36. 'cOficina '36. cOficina
'cOficina 28.cTipoDireccion
20. cCaracter 16. 12. cCiudad
37. cDesOficina
'40. 'cCodigoCargo 21. cDesDireccion
x iv
'42. 'cCodigoCondicion
xiv
ii
xxix xxvii
LUGARES
CARGOS TELEFONOS DIRECCIONES RELACIONES TIPOS
xx '11. 'nCodigoPostal
40. cCodigoCargo OFICINAS 1. nPersona xxvi
1. nPersona RELACIONES
'13. 'cCodigoCalle
41. cDesCargo CONDICIONES
xv 36. cOficina 20. cTipoDireccion
39. nPersonaRelacionada iii '15.
47.'cCodigoBarrio
cTipoRelacion
42.cTelefonoOficina
38. cCodigoCondicion 22. nLugar
xix 47. cTipoRelacion 17.48.
nPuerta
cDesR elacion
43. cDesCondicion
ii 18. cPiso
xxvi
22. nLugar
EMPLEADOS PERSONAS
TIPOS TIPOS
'1. 'nPersona xiii 1. nPersona i DOCUMENTOS
PERSONAS [2. nDocumento] CALLES
34. nLegajo
DICTADOS 27. cDesCaracter '3. 'cTipoDocumento 13. cCodigoCalle 3. cTipoDocumento
[35. nAñoIngreso]
TIPOS v 4. cDesDocumento
'34. 'nLegajo xvii '36. 'cOficina 28. cCaracter 5. cApellido 14. cCalle
'40. 'cCodigoCargo x
55. cDiasSemana xxix [9. fNacimiento] xxxiv xxvii
xx RELACIONES TIPOS
'29. 'cTipoEstudio
xxvi 1. nPersona
xxx MAQUINAS CONDICIONES RELACIONES
vii
[31. cGradoAvance]39. nPersonaRelacionada
60. cMaquina ix 47. cTipoRelacion
TELEFONOS
47. cTipoRelacion 48.nPersona
cDesR elacion
61. cDesM aquina 43. cDesCondicion
DIRECCIONES xxxiii 1.
xxvi 23. nTelefono
xxxi CORREO PREGUNTAS
'24. 'cTipoTelefono
1. nPersona 64. nIdPregunta
PERSONAS
26. cDireccionCorreo 65. mPregunta TIPOS
ASISTENCIAS xiii 1. nPersona 66. tFechaHoraPregunta i DOCUMENTOS
[2. nDocumento]
1. nPersona [67. mR espuesta]
viii
53.
TIPOScDictado [68. FechaHoraR espuesta] 4. cD esDocumento
'34. 'nLegajo 5. cApellido
58. nHoraInicio
29. cTipoEstudio
xxx '71. 'cSubTema TELEFONOS
53. cDictado [7. cOtrosNombres]
59. nTiempo '78. 'nPersonaR esponde 24. cTipoTelefono
xxviii '29. 'cTipoEstudio xxxv vii
xxxii
CURSOS 60. cMaquina ix SUBTEMAS TELEFONOS
OBSERVACIONES
49. cCurso ESTADOS
61. cDesM aquina DIRECCIONES 69. cCodigoSubTema
xxxiii 1. nPersona
1. nPersona
50. cNombreCurso ASISTENCIAS 71. cCodigoTema 23. nTelefono
xxxi CORREO
32. cObservacion xii PREGUNTAS
51. nClases 62. cCodEstado 70. cSubTema '24. 'cTipoTelefono
1.33. tObservacion
nPersona 64. nIdPregunta
xxxvi
BITACORA
1. nPersona TELEFONOS
[67. mR espuesta] viii
INVITADOS 53. cIdentificacion
cDictado
xxxviii USUARIOS TEMAS
73. [68. FechaHoraR espuesta]
EMPRESAS
57. tFechaHoraEntrada
fClase '69. TIPOS
1. nPersona 75. 73. cIdentificacion 44.'cCodigoSubTema
nEmpresa 71. cCodigoTema
'36. 'cOficina 58.tFechaHoraSalida
76. nHoraInicio xxx 74. nContraseña
xxxvii '71.
46.'cSubTema
cTelefonoEmpresa TELEFONOS
72. cTema
74. nContraseña
'44. 'nEmpresa 59. nTiempo
[77. mObservacion] '78. 'nPersonaR esponde 24. cTipoTelefono
xxi
'62. 'cCodAsistencia xxv
xxviii EMPRESAS
xxxv
xxxii '1. 'nPersona
CURSOS xxxixSUBTEMAS
'22. 'nLugar
OBSERVACIONES
49. cCurso ESTADOS 69.
44.cCodigoSubTema
nEmpresa
xxiv
1. nPersona
32. cObservacion xii xxiii 45. cDenominacion
33. tObservacion
Instrumentación relaciones “unos a unos” por aplicación de la 9na regla xxxvi
BITACORA TELEFONOS
INVITADOS (gráfico 34)
USUARIOS EMPRESAS
73. cIdentificacion TEMAS xxxviii
1. nPersona 75. tFechaHoraEntrada 73. cIdentificacion 44. nEmpresa 71. cCodigoTema
xxxvii
'36. 'cOficina 76. tFechaHoraSalida 74. nContraseña 46. cTelefonoEmpresa 72. cTema
'44. 'nEmpresa [77. mObservacion]
xxi xxv
Cr. Carlos Miguel FARIAS Año 2002 EMPRESAS
Página 96
'1. 'nPersona
xxxix '22. 'nLugar
xxiv
44. nEmpresa
xii
OFICINAS TIPOS BARRIOS CIUDADES

CONTACTOS xviii '34. 'nLegajo
vi
34. nLegajo
DIRECCION 15. cCodigoBarrio 11. nCodigoPostal
36. cOficina 20. cTipoDireccion 16. cBarrio 12. cCiudad
'36. 'cOficina
37. cDesOficina 21. cDesDireccion iv
xiv
ii
LUGARES
'11. 'nCodigoPostal
'13. 'cCodigoCalle
xix 17. nPuerta
ii 18. cPiso
22. nLugar
EMPLEADOS
TIPOS
'1. 'nPersona
PERSONAS CALLES
34. nLegajo
35. 27. cDesCaracter 13. cCodigoCalle
[35.nAñoIngreso]
nAñoIngreso] v
xvii 28. cCaracter 14. cCalle
'36. 'cOficina
'40. 'cCodigoCargo x
xxix xxvii
xx RELACIONES TIPOS
xxvi 1. nPersona RELACIONES
CONDICIONES
39. nPersonaRelacionada 47. cTipoRelacion
47. cTipoRelacion 48. cDesR elacion
43. cDesCondicion
xxvi
PERSONAS
TIPOS
[2. nDocumento]
'34. 'nLegajo TIPOS 5. cApellido 4. cD esDocumento
61. cDesM aquina DIRECCIONES xxxiii 1. nPersona
23. nTelefono
xxxi CORREO PREGUNTAS
'24. 'cTipoTelefono
1. nPersona 64. nIdPregunta
1. nPersona [67. mR espuesta] viii
53. cDictado [68. FechaHoraR espuesta]
58. nHoraInicio xxx '71. 'cSubTema TELEFONOS
59. nTiempo '78. 'nPersonaR esponde 24. cTipoTelefono
xxviii xxxv
xxxii
CURSOS SUBTEMAS
OBSERVACIONES
49. cCurso ESTADOS 69. cCodigoSubTema
1. nPersona
32. cObservacion xii
33. tObservacion
xxxvi
BITACORA TELEFONOS
1. nPersona 75. tFechaHoraEntrada 73. cIdentificacion 44. nEmpresa 71. cCodigoTema
xxxvii
'36. 'cOficina 76. tFechaHoraSalida 74. nContraseña 46. cTelefonoEmpresa 72. cTema
74. nContraseña
'44. 'nEmpresa [77. mObservacion]
xxi xxv
EMPRESAS
'1. 'nPersona
xxxix '22. 'nLugar
xxiv
44. nEmpresa
Diagrama final de la Base de Datos de Gestión de Cursos (gráfico 35)

Participación Terceros en el trabajo de Investigación:
Como participación en el trabajo de investigación se

contó con la valiosa colaboración del alumno German Branvilla, libreta
universitaria 3184, el cual en su doble carácter de alumno de la carrera de
Contador Público de la Facultad de Ciencias Económicas y Jurídicas de la
Universidad Nacional de La Pampa y alumno de la carrera Analista de
Sistemas del Instituto Superior de Enseñanza de Informática, junto con la
alumna Hilda Nemesio de dicho instituto.
Ambos hicieron una revisión del trabajo, sobre todo

desde el punto de vista de entendimiento por parte de estudiantes y probaron
la aplicabilidad de las reglas, efectuando un trabajo de relevamiento de un
Sistema de Información para una Imprenta, el cual es trascripto en la parte
pertinente como parte del presente trabajo de investigación.
Sistema de Gestión de Imprentas

El relevamiento del sistema de Gestión de Imprenta se
efectuó sobre una imprenta real situada en la Ciudad de Santa Rosa La
Pampa, para ello se aplicaron técnicas de análisis que no se explican en este
trabajo por no corresponder a la esencia del mismo.
Diagrama de Entorno
Clientes Gerencia
Pedidos, R emitos,
Facturas, R ecibos
Notas de Debito Informes y
Notas de Credito R eportes
Gerenciales
SISTEMA
GESTION
IMPRENTA R eportes para el
Sistema de
Informacion de
Imprentas
R eportes de
Auditor Control Interno AFIP
Externo y Auditoria
Diagrama de Contexto para el Sistema de Imprenta (gráfico 36)

Objetivo General:
El sistema deberá capacidad para administrar una imprenta que

comercializa papelería en general, del tipo estándar o con impresiones de
acuerdo a lo solicitado por los clientes. En los casos de comprobantes como
facturas, administrar además la información que se debe mantener relativos
a las reglamentaciones vigentes de la AFIP (ex DGI).
Requerimientos Particulares:
1) Con relación a los clientes es necesario contar con sus datos personales, los
relativos a la personalización de los productos que se les vende, además el
sistema requiere controlar los pedidos, las correspondientes ordenes de
trabajo para imprenta, las facturas por los trabajos efectuados, los remitos
y los pagos efectuados por dichos clientes.
a) Los datos personales de los clientes a tener en cuenta son:
i) Nombre y el apellido (por separado)...
ii) Dirección postal completa, esto incluye la codificación de las
ciudades y de las respectivas provincias...
iii) Sexo del cliente, Fecha de Nacimiento y su Estado Civil...
iv) Si el cliente es una empresa, en lugar de sexo se indicará que es una
persona jurídica y el Apellido y Nombre conformarán la Razón
Social...
v) Número de teléfono, Dirección de Correo Electrónico...
vi) Número y tipo de documento...
vii) Todo cliente es una persona pero no todas las personas son clientes,
algunas personas son proveedores y otras empleados.
b) Los datos inherentes a su condición de clientes requeridos son:

i) Número de CUIT, condición ante el IVA., codificada, y el de
inscripción en Ingresos Brutos...
ii) Fecha de inicio de actividad y Descripción Actividad que lleva a
cabo...
iii) Nombre de la Empresa y/o Nombre de Fantasía...
iv) Fecha de alta como cliente, Saldo en Cuenta Corriente y Límite de
Crédito...
v) Un cliente puede contarse con uno o más logos, que se usan en sus
ordenes de trabajo, además, asociado a cada logo se guarda un
comentario apropiado al mismo...
c) Para hace el seguimiento de los pedidos hechos por los clientes se

requieren los siguientes datos:

i) Todos los pedidos están numerados, los números no pueden

repetirse...
ii) Fecha y Hora en que se efectúa el pedido y Fecha y Hora en que el
pedido es completado y entregado al cliente
iii) Se necesita saber que empleado recibe el pedido
iv) Un pedido puede tener varios estados posibles desde el momento
que se carga hasta que se completa, estos estados son comunes a
distintos documentos y desea tenerlos codificados...
v) El pedido tiene por cada articulo solicitado un renglón numerado...
vi) En cada renglón se especifica la cantidad de artículos y el articulo
solicitado, el articulo puede estar en stock o no, y puede ser a su vez
utilizado como insumo de una orden de producción...
vii) Si un articulo no está en stock, corresponde hacer una orden de
trabajo de imprenta, cada renglón de pedido corresponde a una
única orden, pero varios renglones pueden incluirse en la misma
orden...
viii) La facturación de un pedido puede distribuirse en varias facturas y
en una factura estar relacionados con varios pedidos...
d) Para llevar el control de la facturación de la imprenta, se requiere

almacenar los siguientes atributos:
i) Tipo y Número de la Factura, más la fecha de la misma...
ii) Se requiere la condición del Cliente al IVA al momento de la
confección de la factura...
iii) Se necesita saber la fecha de vencimiento de la factura y la fecha en
que fue cobrada...
iv) Para facilitar las consultas y el control, se requiere contar con el
subtotal de la factura que representa la suma de los importes de los
artículos facturados
v) Se necesita almacenar el importe del IVA correspondiente al carácter
de inscripto...
vi) También se debe disponer del monto del IVA correspondiente al
carácter de no inscripto...
vii) Para facilitar consultas, control e informes se incluirá el importe
total de cada factura...
viii) Cada factura se relaciona a un cliente, el cual puede tener varias
facturas...
ix) Debe saberse que empleado confeccionó cada factura...
x) Una factura se paga con un único recibo, pero en el mismo recibo
pueden incluirse varias facturas...
xi) De cada factura se quiere tener codificado su estado, el cual es
común a otros documentos que se manejan en el sistema...

xii) De cada factura se quiere tener un detalle numerado de los artículos

que se incluyen en la misma...
xiii) para cada renglón se quiere contar con la cantidad vendida, el
articulo vendido y el precio unitario de venta del articulo en dicha
factura...
e) Una factura puede tener asociado un remito, por cada remito que se
maneja en el sistema es necesario contar con los siguientes atributos:
i) Número de Remito que son correlativos, y no pueden duplicarse...
ii) Fecha en que se remitió el remito...
iii) Nombre del Transporte que llevo la mercadería...
iv) El peso total de los artículos incluidos en el remito y la cantidad de
bultos...
v) Como de cualquier otro documento manejado por el sistema, se
desea conocer el estado del mismo, los estados posibles están
codificados y son comunes a los estados de otros documentos en el
sistema.
vi) En un remito, puede incluirse más de un articulo, cada uno de estos
se discrimina en renglones numerados del remito, estos números
empiezan desde uno en cada remito...
vii) Para cada articulo en un remito, se necesita saber la cantidad
remitida...
f) Para el control de los pagos de los clientes, se necesita contar con:

i) Los números de recibo que son correlativos y no pueden repetirse
ii) La fecha en que se confecciono el recibo y importe total cobrado...
iii) La persona que efectuó el pago y tener identificado el empleado que
lo hizo...
iv) Al igual que otros documentos en el sistema, el recibo tendrá un
estado codificado común...
v) Un recibo puede contar con al menos un renglón numerado
correlativo por moneda o forma de cobro que incluya...
vi) Por cada renglón se necesita el importe correspondiente y la forma
en que se cobra dicha parte (efectivo, cheque, etc.) y en que tipo de
moneda se hizo el pago...
vii) las monedas en que se cobra están codificadas para estandarización
de los informes...
viii) cada renglón del recibo puede cobrarse con uno o mas cheques, de
cada uno de estos cheques es necesario contar con:
(1) Número del cheque y fecha ñeque fue emitido...
(2) Fecha de pago y fecha de deposito del cheque...
(3) Fecha en que fue acreditado el cheque

(4) Nombre del librador y su número de cuenta corriente...

(5) Un cheque solo puede cubrir un único renglón del recibo...
(6) Es necesario contar con la identificación del banco al cual
corresponde el cheque, dichos bancos están codificados
internamente...
(7) de cada banco se necesita su nombre, su dirección y la sucursal...
(8) además es necesario contar la dirección y la ciudad
correspondiente, las ciudades utilizan la misma codificación que
la usada para personas en el sistema...
2) Se necesita controlar al personal que interviene en la recepción de los

pedidos de los clientes, las ordenes de imprenta, quien lleva a cabo las
facturas a los clientes y cobra y confecciona los respectivos recibos, de
estos recibos se debe saber si se cobra con cheque, en efectivo en pesos u
otro tipo de moneda de circulación legal.
a) Del personal que interviene en las diversas actividades de la imprenta,
se desea contar con sus datos personales, equivalente a lo manejado
respecto a los clientes y adicionalmente:
i) Un número de legajo para uso interno y para identificarlo en las
operaciones de la imprenta que en las que interviene
ii) la fecha de ingreso a la empresa...
iii) Si el empleado es activo o no...
iv) Un empleado, interviene en la recepción de pedidos, en las ordenes
de trabajo como receptor y como controlador de calidad...
v) También interviene en la confección de Facturas, Remitos y Recibos
vi) En todos los documentos del sistema en los que interviene el
empleado y que se indican en los puntos precedentes debe quedar
constancia de tal circunstancia...
3) Para gestionar el funcionamiento de la imprenta, se desea llevar control de

stock de artículos de comercialización directa y de los insumos necesarios
para elaborar artículos que respondan a las solicitudes de trabajo de los
clientes, además se desea disponer información relativa a los proveedores
de cada articulo o insumo.
a) Para controlar las Ordenes de Trabajo de Imprenta debe tenerse en
cuenta:
i) Las ordenes de trabajo están numeradas en forma correlativa y no
pueden repetirse su número, además cuenta con una descripción del
trabajo...
ii) Se debe contar con la fecha y hora en que se confecciona la Orden
de Trabajo y la Fecha y hora en que se termino...

iii) Debe saberse que empleado recibió dicha orden y quien hizo el
control de calidad del trabajo...
iv) El sistema debe informar el grado de avance de cada orden de
trabajo...
v) Una orden de trabajo puede utilizar más de un insumo (articulo),
estos pueden ser utilizado en diversas ordenes de trabajo, en distinta
cantidades, dicha cantidad debe ser conocida por el sistema...
b) Para controlar el stock el sistema debe facilitar los siguientes datos:

i) Cada artículo tiene una identificación interna irrepetible, también
tienen una descripción irrepetible, que no puede faltar...
ii) De cada articulo se necesita saber la existencia actual, el punto de
pedido (stock mínimo), el precio unitario, el histórico y la fecha de
este último...
iii) Cada articulo puede ser provisto por mas de un proveedor, además
cada uno de estos puede proveer distintos productos...
iv) Algunos artículos, tienen una descripción adicional encuadrada
como “Papelería”, cada descripción de estas corresponde a un único
articulo...
v) Para los artículos que deben cumplir formalidades impuestas por la
AFIP, y que caen en la categoría de “comprobantes” debe contarse
con un Nombre, de Comprobante (no estandarizado)...
vi) Los comprobantes que corresponde a un lote que tienen un número
de punto de venta, un número inicial y número final, además de
estar impresos en número determinado de copias...
vii) Cada comprobante tiene una fecha de impresión...
viii) uno o mas comprobantes tienen asociada una autorización
emanada de la AFIP, la cual estará enumerada en forma
correlativa...
ix) cada autorización tiene una descripción y una fecha...
x) Cada autorización tiene una fecha de vencimiento...
xi) Para cada una de las autorizaciones debe guardarse el Código de
Autorización de Impresión y el Código de la Próxima autorización...
xii) De cada autorización se requiere contar con su porcentaje de
aprobación y su documentación de autorización Html, otorgado por
la AFIP...
c) De los proveedores se desea contar con datos personales equivalentes a

los que se disponen para clientes y empleados, más un comentario
acerca del proveedor.

Aplicando las reglas de normalización determinadas en el

presente trabajo, se procedió primero a confeccionar los tabulados indicados
en la regla 1, los cuales se transcriben a continuación.
Primero se incluye el tabulado de entidades:

I Documen
Carácter
Entidad
E Fuente
A Personas Personas (Físicas o Jurídicas) que se vinculan con la imprenta Fuerte I.A. y s.s.
Aquellas personas que se vinculan comercialmente con la imprenta,
B Clientes Débil (A) I y I.B.
adquiriendo productos.
C Ciudades Ciudades donde viven las personas D.Valores I.A.ii.
D Provincias Provincias donde están las ciudades donde viven personas D.Valores I.A.ii.
E CondicionesIVA Condiciones de los Clientes ante el IVA D.Valores I.B.i
Actividades de los clientes nomencladas según codificación de
F Actividades D.Valores I.B.ii.
ingresos brutos.
G Logos Logos de los Clientes Débil (B) I.B.v
H Pedidos Pedidos efectuados por los clientes Débil (B) I.C y I.C.i
Empleados que intervienen en diversas documentos manejados por I.C.iv, II y
I Empleados Débil (A)
el sistema s.s.
Todos los documentos tienen algún estado desde que se crean hasta
J EstadosDocumentos D.Valores I.C.v.
que se eliminan
Por cada Artículo incluido en un pedido se llena (completa) un
K DetallePedidos Débil (I) I.C.vi.
renglón numerado del detalle de pedido.
Artículos que se comercializan o se utilizan como insumos por la
L Artículos Fuerte I.C.vi.
empresa
I.C.vii.,
Cuando un Artículo no esta en stock, y es elaborado por la imprenta,
M OrdenesTrabajo Fuerte I.C.viii.,
debe hacerse una orden de trabajo de imprenta
III.A. y s.s.
N Facturas Las ventas de la imprenta se refleja en Facturas Fuerte I.D. y s.s.
Recibos con el se registra el cobro de facturas que no son de
O Recibos Fuerte I.D.x.
contado
Por cada Artículo incluido en una Factura se llena (completa) un
P DetalleFacturas Débil (N) I.D.xii.
renglón numerado del detalle de la factura.
Q Remitos Remitos que puede ir asociados a una factura Débil (N) I.E. y s.s.
Por cada Artículo incluido en un remito se llena (completa) un renglón
R DetalleRemitos Débil (Q) I.E.vi.
numerado del detalle del remito
Por cada tipo moneda o forma de cobro incluido en un recibo se llena
S DetalleRecibos Débil (O) I.F.v.
(completa) un renglón numerado del detalle del recibo
I.F.vi y
T TiposMoneda Los tipos de moneda en que se cobra están codificados D.Valores
I.F.vii
I.F.vi y
U Cheques Cada cheque recibido como parte del pago de un recibo se registra Débil (S)
I.F.viii
Bancos de los cuales se reciben cheques como parte de pago de los
V Bancos D.Valores I.F.viii.f)
recibos
WProveedores Personas que proveen artículos Débil (A) III.C.
Los artículos que deben cumplir con especificaciones de la AFIP,
X Comprobantes caen en la categoría de comprobantes y de los mismos se debe Débil (L) III.B.v.
guardar información AD HOC


I Documen
Carácter
Entidad
E Fuente
Y Autorizaciones Autorizaciones emanadas de la AFIP Fuerte III.B.viii.
Luego se incluye el tabulado de relaciones:

Documen
Tipo
IDR Nombre Relación Descripción Relación tación
Relación
Fuente
Una persona puede ser un cliente, un cliente debe ser una
i Personas-Clientes A<|:0>B I.A., I.B.vii
persona
Una persona vive en una ciudad, en una ciudad pueden vivir mas
ii Personas-Ciudades A<<0:|>C I.A.ii.
de una persona
iii Ciudades-Provincias C<<0:|>D Una ciudad está en una ciudad, varias ciudades en una provincia I.A.ii.
Clientes- Un cliente puede tener una condición ante el IVA, dicha condición
iv B<<0:|>E I.B.i
CondicionesIVA puede ser común a mas de un cliente
Un cliente puede tener una actividad, la cual puede ser común a
v Clientes-Actividad B<<0:|>F I.B.ii
más de un cliente
Un cliente puede tener más de un logo, cada logo es exclusivo de
vi Clientes-Logos B<|:0>>G I.B.v
cada cliente
vii Clientes-Pedidos B<|:0>>H Un pedido corresponde a un cliente el cual puede tener varios I.C.i
I.C.iv y
viii Pedidos-Empleados H<<0:|>I Cada pedido es recibido por un empleado
II.A.iv
Pedidos- Un pedido tiene un estado de documento mientras exista dentro
ix H<<|:|>J I.C.v.
EstadosDocumentos del sistema
Pedidos- Un pedido tiene uno o mas renglones de detalle, se llena un
x H<|:0>>K I.C.vi.
DetallePedidos renglón uno por cada Artículo pedido
Un Artículo que figura en un pedido, del cual no hay stock, I.C.vi,
DetallePedidos-
xi K<<0:0>M genera una orden de trabajo de imprenta, en una de estas I.C.vii y
OrdenesTrabajo
pueden cubrirse varios renglones de pedidos I.C.viii
Condición ante el IVA del Cliente cuando se hace la factura, se
Facturas-
xii E<<0:|>N aprovecha el mismo dominio de valores, creado para manejar I.D.ii.
CondicionesIVA
dichas condiciones.
Un cliente puede tener varias facturas, pero estas corresponden
xiii Facturas-Clientes N<<0:|>B I.D.viii.
a uno solo
Un empleado puede confeccionar cero o más facturas, pero uno
xiv Empleados-Facturas I<|:0>>N I.D.ix.
solo es el responsable de su contenido.
Para una factura que no sea de contado, se requiere un recibo
I.D.x., I.F. y
xv Facturas-Recibos N<<|:0>O para registrar su cobro, un recibo puede incluir más de una
s.s.
factura.
Facturas- Una factura tiene un estado de documento mientras exista dentro
xvi N<<|:|>J I.D.xi.
EstadosDocumentos del sistema
Facturas- Una Factura tiene uno o mas renglones de detalle, se llena un
xvii N<|:0>>P I.D.xii.
DetalleFacturas renglón por cada Artículo facturado
DetalleFacturas- En un renglón del detalle de la factura figura el Artículo facturado,
xviii P<<0:|>L I.D.xiii.
Artículos el mismo Artículo puede ser vendido en diversas facturas.


Documen
Tipo
IDR Nombre Relación Descripción Relación tación
Relación
Fuente
xix Pedidos-Facturas H<<0:0>>N La facturación de un pedido puede distribuirse en varias facturas I.D.xiv.
y una factura estar relacionados con varios pedidos
xx Facturas-Remitos N<|:0>Q Algunas Facturas tienen un remito (cada una) I.E. y s.s.
Remitos- Un remito tiene un estado de documento mientras exista dentro
xxi Q<<0:|>J I.E.v.
EstadoDocumentos del sistema
Remitos- Un remito tiene uno o más renglones de detalle, se llena un
xxii Q<|:|>>R I.E.vi.
DetalleRemitos renglón por cada Artículo incluido
DetalleRemitos- En un renglón del detalle del remito figura el Artículo remitido, el
xxiii R<<0:|>L I.E.vi.
Artículos mismo Artículo puede ser figurar en diversos remitos
xxiv Clientes-Recibos B<|:0>>O Un cliente puede efectuar uno o más pagos I.F.iii
Un empleado puede confeccionar cero o más recibos, pero uno
xxv Empleados-Recibos I<|:0>>O I.F.iii
solo es el responsable de su contenido.
Recibos- Un recibo tiene un estado de documento mientras exista dentro
xxvi O<<0:|>J I.F.iv.
EstadoDocumentos del sistema
Recibos- Un recibo tienen un renglón por tipo de moneda o forma de cobro
xxvii O<|:|>>S I.F.v.
DetalleRecibos que incluya
DetalleRecibos- Cada renglón del detalle del recibo esta asociado a un tipo de I.F.vi y
xxviii S<<0:|>T
TiposMoneda moneda, que fueron codificados para unificación de tratamiento. I.F.vii
I.F.vi y
DetalleRecibos- Cada renglón del detalle del recibo puede estar asociado a un o
xxix S<|:0>>U I.F.viii y
Cheques más cheques.
I.F.viii.e)
xxx Cheques-Bancos U<<0:|>V Cada cheque está asociado a un banco I.F.viii.f)
I.F.viii.g) y
xxxi Bancos-Ciudades U<<0:|>C Una sucursal bancaria está en una ciudad
1.F.viii.h)
Una persona puede ser un empleado, un empleado es una
xxxii Personas-Empleados P<|:0>I II.A.
persona
Empleados-
xxxiii I<|:0>>M Un empleado recibe las ordenes de trabajo de imprenta II.A.iv
OrdenesTrabajo
xxxiv Empleados-Remitos I<|:0>>Q Un empleado confecciona los remitos (via sistema) II.A.v
Una orden de trabajo puede usar varios insumos (conocidos
OrdenesTrabajo-
xxxv M<<0:0>>L como artículos) y a su vez cada insumo usarse en diversas III.A.v.
Artículos
ordenes de trabajo
Un proveedor puede proveer varios artículos y cada uno de estos
xxxvi Artículos-Proveedores L<<0:0>>W III.B.iii
ser provistos por diversos proveedores.
Artículos- De un artículo que cumplen con disposiciones de la AFIP debe
xxxvii L<|:0>X III.B.v.
Comprobantes contarse con información encuadrada como comprobante.
Comprobantes- Cada comprobante tiene asociada una autorización de la AFIP, la
xxxviii X<<|:>Y III.B.viii.
Autorizaciones cual puede tener asociada más de un comprobante
Personas- Una persona puede ser un proveedor, pero un proveedor debe
xxxix A<|:0>W III.C.
Proveedores ser una persona
Artículos- Un artículo en un pedido figura en cada uno de los renglones de
xl K<|:0>L I.C.vi.
DetallePedidos detalle del mismo.
Como último tabulado se incluyen el de atributos a
manejar por el sistema.


Valor
Nombre X
1) Descripción Atributo 2) 3) Regla Validación 4)
Atributo Omisi
ón
Pueden repetirse entre
Apellido de la Persona, en caso de ser
1 cApellido A No personas pero no estar en I.A.i. y I.A.iv.
una persona jurídica, será la razón social
blancos
Pueden repetirse entre
2 cNombre Nombre de la Persona A No personas pero no estar en I.A.i. y I.A.iv.
blancos
Dirección de la Persona (Calle, Número, Pueden repetirse entre
3 cDirección Dpto. piso, etc., no incluye la ciudad ni la A No personas pero no estar en I.A.ii.
provincia) blancos
No puede omitirse, puede
Código Postal Ciudad donde vive la repetirse de una persona
4 cCódigoPostal C No 6300 I.A.ii.
persona a otra pero no entre
ciudades
Los nombres de las
ciudades pueden
5 cCiudad Nombre de la Ciudad C No I.A.ii.
repetirse, pero con distinto
código postal
Si se instrumenta un
código de un carácter, el
6 cCodProvincia Código de cada Provincia D No “L” por omisión I.A.ii.
correspondería a “La
Pampa”
No puede estar en blanco
7 cProvincia Nombre de la Provincia D No I.A.ii.
ni repetirse
Sexo de la Persona, o su condición de “M”≡ “Masculino”, “F”≡
8 cSexo A No “M” I.A.iii. y I.A.iv.
“persona jurídica” “Femenino”, “J”≡ “Jurídica”
Puede faltar, si la fecha
indica que el cliente es un
9 fNacimiento Fecha de Nacimiento de la Persona A Si I.A.iii.
menor de edad, pedir
segunda confirmación
Este atributo, podría
llegarse a codificar en un
Estado civil de la persona, en el caso de
10 cEstadoCivil A Si dominio de valores (o I.A.iii. y I.A.iv.
entidades jurídicas, el tipo societario
estar descripto por
programa).
Debería instrumentarse
cNúmeroTelefon una máscara de entrada
11 Número de teléfono de la persona A Si I.A.v.
o apropiada para números
de teléfono
Debería instrumentarse
cCorreoElectroni una máscara de entrada
12 Correo Electrónico de la Persona A Si I.A.v.
co apropiada para correos
electrónicos.


Valor
Nombre X
Atributo Omisi
ón
Dos personas pueden
tener el mismo, no puede
cTipoDocument duplicarse combinado con
13 Tipo Documento de Identidad A Si I.A.vi.
o el número de documento
de identidad en dos
personas distintas.
No puede repetirse en dos
cNúmeroDocum personas diferentes si
14 Número de Documento de la Persona A Si I.A.vi.
ento además coinciden los
tipos de documento.
Número CUIT (Código Único de No puede repetirse en dos
15 nCUIT B Si I.B.i.
Identificación Tributario) clientes diferentes.
No se repite, no puede
16 cCondicionIVA Código Condición ante el IVA E No “CF” I.B.i.
estar en blanco.
“Consu
17 cDescripcionIVA Descripción de la Condición ante el IVA E No midor I.B.i.
estar en blanco.
Final”
Si no es nulo, no puede
18 nInscripcionIB Número de Inscripción en Ingresos Brutos B Si repetirse en dos clientes I.B.i.
diferentes.
Menor que el día de la
19 fInicioActividad Fecha de Inicio de Actividades del Cliente B No I.B.ii.
fecha
No se repiten. Obtenidos
Código Actividad acorde nomenclador de
20 cCodActividad F No del del nomenclador para I.B.ii.
Ingresos brutos
Ingresos Brutos Provincial
No puede estar en blanco.
Obtenidos del
21 cDesActividad Descripción Actividad del Cliente F No I.B.ii.
nomenclador de Ingresos
Brutos Provincial
cNombreEmpres Nombre de la Empresa (nombre de
22 B Si estar en blanco ni I.B.iii
a fantasia)
repetirse
23 fAlta Fecha de Alta del cliente para la Imprenta B No I.B.iv
fecha
Campo calculado por el
24 ySaldoCuenta Saldo en Cuenta Corriente del Cliente B No 0 sistema o cargado en I.B.iv
carga inicial del sistema
25 yLimiteCredito Limite de Crédito otorgado a un cliente B No 0 I.B.iv

Gener
Calculado por el sistema,
Número correlativo por cada cliente de a
26 nLogo G No número ultimo logo del I.B.v
logos que cuenta para con la empresa Sistem
cliente mas 1
a
27 gLogo Imagen del Logo G No I.B.v
28 mLogo Comentario textual acerca del Logo G Si I.B.v
estar en blanco.
Auto
Número Identificador del Pedido, no se
29 nPedido H No Numéri Calculado por el sistema. I.C.ii
repiten
co


Valor
Nombre X
Atributo Omisi
ón
Fecha
tFechaHoraPedi No mayor que fecha y
30 Fecha y Hora en que se efectuó el pedido H No y Hora I.C.iii
do hora actuales
Actual
Código asignado a cada estado posible
31 cCódigoEstado J No “ “ No puede repetirse. I.C.v.
de un documento
cDescripcionEst No puede repetirse ni
32 Descripción del Estado de un documento J No I.C.v.
ado estar en blanco
Auto
33 nRenglónPedido Número de renglón dentro de un pedido K No Numéri Calculado por el sistema. I.C.vi.
co
nCantidadPedid Cantidad de Artículo pedidos en cada
34 K No 0 Mayor que 0 I.C.vii.
a renglón de la orden de pedido.
Código con el cual se identifica cada Mnem No puede estar en blanco
35 cCódigoArtículo L No I.C.vii.
Artículo ónico ni repetirse
Auto Calculado por el sistema. I.C.vi, I.C.vii,

Número que identifica cada Orden de
36 nOrdenTrabajo M No Numéri Puede ser nulo en el I.C.viii y
trabajo de imprenta
co detalle del pedido. III.A.i.
Auto
Número de Factura, no se repite dentro El sistema de generar los
37 nFactura N No Numéri I.D.i.
de un mismo tipo números correlativos
co
Debe corresponder al tipo
38 cFactura Tipo de Factura, “A” ó “B” N No “B” I.D.i.
de IVA del Cliente
Fecha en que hecha la Factura Fecha La fecha debe ser menor
39 fFacturada N No I.D.i.
(facturado) Actual a la del día de la fecha
Fecha
Actual El dato es requerido si no
40 fVencimiento Fecha de vencimiento de la Facturas N Si I.D.iii.
+ 30 es una venta al contado
días
Mayor o igual fecha
41 fCobrada Fecha en que fue cobrada la factura N Si I.D.iii.
facturada
Gener
Al crear o modificar la
a
42 ySubTotal Importe sub total de la factura N No factura, el sistema debe I.D.i.
Sistem
sumar el detalle
a
Gener
Corresponde al importe
a
43 yIVAInscripto Importe IVA inscripto incluido en la factura N No IVA relativo a la alícuota I.D.v
Sistem
base de dicho impuesto.
a
Gener Corresponde al importe
Importe IVA no inscripto incluido en la a IVA relativo a la alícuota
44 yIVANoInscripto N No I.D.vi
factura Sistem adicional de dicho
a impuesto.
Gener Al crear o modificar la
a factura, el sistema debe
45 yTotal Importe total de la factura N No I.D.vii.
Sistem sumar el detalle,
a incluyendo el IVA
Auto
nRenglónFactur
46 Número de renglón dentro de una Factura P No Numéri Calculado por el sistema. I.D.xii.
a
co


Valor
Nombre X
Atributo Omisi
ón
nCantidadVendi Cantidad de Artículo vendidos en cada
47 P No 0 Mayor a cero I.D.xiii.
da renglón de la factura.
Provee
Precio venta unitario por cada Artículo el Inicialmente extraído de la
48 yPrecioVenta P No
incluido en un renglón de la factura Sistem tabla de artículos
a
Auto
El sistema de generar los
49 nRemito Número de Remito Q No Numéri I.E.i.
números correlativos
co
Fecha La fecha debe ser menor
50 fRemito Fecha de Emisión del Remito Q No I.E.ii.
Actual a la del día de la fecha
Nombre del Transporte que llevo Si no es nulo, no puede
51 cTransporte Q Si I.E.iii.
mercadería estar en blanco
52 nPeso Peso de los artículos en el remito Q Si I.E.iv.
ser 0 (cero)
53 nBultos Cantidad de Bultos en el remito Q Si I.E.iv.
ser 0 (cero)
Auto
54 nRenglónRemito Número de renglón dentro de un Remito R No Numéri Calculado por el sistema. I.E.vi.
co
nCantidadRemiti Cantidad de Artículos remitidos en cada
55 R No 0 Mayor a cero I.E.vii.
da renglón del remito
Auto
56 nRecibo Número de los recibos O No Numéri Calculado por el sistema. I.F.i.
co
Fecha La fecha debe ser menor
57 fRecibo Fecha en que se confecciono el recibo O No I.F.ii.
Actual a la del día de la fecha
Auto
Número de cada renglón del detalle del
58 nRenglónRecibo S No Numéri Calculado por el sistema. I.F.v.
recibo
co
59 yImporte Importe en cada renglón del recibo S No 0 Mayor a cero I.F.vi.
Los valores posibles son

Modo en que se cobra (efectivo, cheque,
60 cModoCobro S No “E” “E”=Efectivo, “C”=Cheque, I.F.vi.
etc.)
“O”=Otra modalidad
61 cTipoMoneda Código Interno para determinar moneda T No “$” I.F.vi y I.F.vii
estar en blanco.
cNombreMoned Nombre de la Moneda con la cual se “PESO No se repite, no puede
62 T No I.F.vi y I.F.vii
a cobra S” estar en blanco.
63 nCheque Número del Cheque U No No puede repetirse I.F.viii.a)
No puede ser mayor que
64 fEmisión Fecha en que fue emitido el cheque U No I.F.viii.a)
la fecha del recibo
Si no es nulo debe mayor
65 fPago Fecha en que fue pagado el cheque U Si o igual a la de fecha de I.F.viii.b)
emisión
Si no es nulo debe estar
entre la fecha de emisión
66 fDeposito Fecha en que fue depositado el cheque U Si I.F.viii.b)
y la de cobro (ambas
inclusive)


Valor
Nombre X
Atributo Omisi
ón
Si no es nulo debe estar
entre la fecha de deposito
67 fAcreditado Fecha en que fue acreditado el cheque U Si I.F.viii.c)
y la de cobro (ambas
inclusive)
cNombreLibrado
68 Nombre del titular de la cuenta del cheque U No No puede estar en blanco I.F.viii.d)
r
69 cNúmeroCuenta Número de cuenta del librador del cheque U No No puede estar en blanco I.F.viii.d)
Combinado con cSucursal
70 cCódigoBanco Código Interno asignado a cada banco V No I.F.viii.f)
no puede repetirse
Repetido en c/u. de las
I.F.viii.f) y
71 cNombreBanco Nombre del Banco V No sucursales de un mismo
I.F.viii g)
banco, no puede omitirse
No puede repetirse dentro I.F.viii.g) y

72 cDirecciónBanco Dirección del banco (cada sucursal) V No
de una misma ciudad I.F.viii.h.
Combinado
Código Asignado a cada sucursal de un I.F.viii.g) y
73 cSucursal V No c/cCódigoBanco no puede
banco. I.F.viii.h.
repetirse
Auto
Número de Legajo del Empleado, usado
74 nLegajo I No Numéri Calculado por el sistema. II.A.i.
en procesos internos de la empresa
co
75 fIngreso Fecha Ingreso empleado a la empresa I No II.A.ii.
fecha
VERD
Señal lógica que indica si el empleado
76 lActivo I No ADER VERDADERO o FALSO II.A.iii.
existe o no
O
77 mDescripcion Descripción de la Orden de trabajo M No No puede estar en blanco III.A.i.
Fecha y Hora en que se confecciona la Fecha La fecha debe ser menor
78 fOrdenTrabajo M No III.A.ii.
orden de trabajo Actual a la del día de la fecha
La fecha debe mayor o
igual a fOrdenTrabajo, es
Fecha y Hora en que se termina la orden Fecha
79 fTerminacion M Si nula hasta que no se III.A.ii.
de trabajo Actual
termino la Orden de
Trabajo
Porcentaje de avance en el trabajo, que
se combinan con el estado de la orden de
80 nAvance M Si 0 Entre 0 y 100 III.A.iv.
trabajo para documentar la situación de la
misma
Cantidad de un artículo utilizado como xxx

81 nInsumo No 0 Debe ser mayo a cero III.A.v.
insumo en una orden de trabajo v

82 cArtículo Descripción Artículo L No III.B.i.
y no debe repetirse
83 nExistencia Existencia actual de Artículo determinado L No 0 Mayor o igual a cero III.B.ii.
Existencia mínima aceptable antes de
84 nStockMinimo L No 0 Mayor o igual a cero III.B.ii.
“disparar” un pedido a proveedores


Valor
Nombre X
Atributo Omisi
ón
85 yPrecio Precio unitario del Artículo L No 0 Mayor o igual a cero III.B.ii.
86 yPrecioHistorico Precio histórico del Artículo L No 0 Mayor o igual a cero III.B.ii.
87 fPrecioHistorico Fecha del Precio Histórico L No 0 III.B.ii.
fecha
Puede ser nulo, pero si
Descripción “extensión” de un Artículo
88 mPapelería L Si .NULL. existe no puede estar en III.B.iv.
cuando cae la categoría de “papelería”
blanco
Denominación del Comprobante que se
89 cComprobante X No y puede repetirse (no esta III.B.v.
ajusta a requisitos de la AFIP
estandarizado)
Número Punto de Venta al que
90 nPuntoVenta X No 0 III.B.vi.
corresponde un lote de artículos
91 nInicial Número Inicial del lote de comprobantes X No 1 Debe ser mayo a cero III.B.vi.
nInicial Debe ser mayor que
92 nFinal Número Final del lote de comprobantes X No III.B.vi.
+50 nInicial
Cantidad de copias que se hace de un
93 nCopias X No 2 Debe ser mayo a cero III.B.vi.
lote de comprobantes
Debería ser igual que la
Fecha en que se imprimió el lote de Fecha
94 fImpresion X No fecha de terminación del III.B.vii.
comprobantes Actual
trabajo correspondiente
Auto
Número de autorización de la AFIP, los
95 nAutorización Y No Numéri Genera Sistema III.B.viii.
cuales son correlativos
co
cDesAutorizacio
96 Descripción de la autorización de la AFIP Y No No puede estar en blanco III.B.ix..
n
Fecha autorización de comprobantes por
97 fAutorizacion Y No III.B.ix..
parte de la AFIP
fVenceAutorizaci Fecha en que vence la autorización de la
98 Y No III.B.x.
on AFIP
cCodAutorizacio
99 Código Autorización de Impresión Y No III.B.xi.
n
Código Próxima Autorización de
100 cCódigoProxima Y No III.B.xi.
Impresión
101 nPorcentaje Porcentaje de aprobación Y No 0 Entre 0 y 100 III.B.xii.
mAutorizacionH Documento Autorización formato HTML
102 Y No III.B.xii.
TML otorgado por la AFIP
103 mComentario Comentario acerca del proveedor W Si III.C.

Los datos de estos cuadros fueron completados con

algunos elementos de análisis de uso común, no detallados en las

especificaciones originales, que complementan el trabajo, sin afectar el

proceso de normalización en si.
Siguiendo con la regla número dos que es el trazado de
los graficos correspondientes, en primer lugar va el de entidades:
PERSONAS (A) CLIENTES (B) CIUDADES (C) PROVINCIAS (D) CONDICIONES

IVA (E)
ACTIVIDADES (F) LOGOS (G) PEDIDOS (H) EMPLEADOS (I) ESTADOS

DOCUMENTOS (J)
DETALLE ARTICULOS (L) ORDENES FACTURAS (N) RECIBOS (O)

PEDIDOS (K) TRABAJO (M)
DETALLES REMITOS (Q) DETALLE DETALLE TIPOS

FACTURAS (P) REMITOS (R) RECIBOS (S) MONEDA (T)
CHEQUES (U) BANCOS (V) PROVEEDORES COMPROBANTES AUTORIZACIONES

(W) (X) (Y)
Sistema de Imprenta, Diagramando Entidades..., Regla 2 (gráfico 37)
A partir del gráfico anterior, se aplica la regla 3 que es el

trazado de las relaciones, para lograr que las respectivas líneas se entrecrucen
lo menos posible, se reubican las distintas poblaciones, obteniéndose el
grafico 38. Además, para una mejor visualización, se trazan las líneas
correspondientes a las poblaciones más relacionadas con distinto grosor o
diferente estilo (continuo, guiones y/o puntos).

PERSONAS (A)
xxx BANCOS (V) PROVINCIAS (D) iii CIUDADES (C) ii
xxxi i xxxii
xxv
LOGOS (G) vi CLIENTES (B) EMPLEADOS (I) xxxiv

xiv xxxiii
xxiviv vii viii xxxix
PROVEEDORES
xxxvi
ACTIVIDADES (F) (W)
PEDIDOS (H)
CONDICIONES
xiii
IVA (E)
FACTURAS (N) xix FACTURACION
xii
x
(xix)
RECIBOS (O) xvii

xv
xxvi
xxvii
DETALLE DETALLES xl DETALLE

xviii ARTICULOS (L) PEDIDOS (K)
xxxv
RECIBOS (S) FACTURAS (P)
xxiii
xxix
xxxvii
CHEQUES (U) ESTADOS COMPROBANTES ARTICULOS_

xvi
xxi DOCUMENTOS (J) (X) ORDEN (xxxv)
ix
xxxv
AUTORIZACIONES ORDENES
TIPOS
(Y) xxxviii TRABAJO (M) xi
MONEDA (T) xxviii
DETALLE
REMITOS (R) xxii
Referencias s/Relaciones:
> Lineas Gruesas: con Estados REMITOS (Q)
> Lineas Medianas: con Empleados
> Lineas Guiones: con Clientes
> Lineas Puntos: con Articulos
> Resto Lineas: Resto Relaciones xx
Sistema de Imprenta, Diagramando Relaciones..., Regla 3 (gráfico 38)
Hay que tener en cuenta que al hacer el relevamiento y

posteriores tabulados de entidades y relaciones, se aplican una serie de
criterios de análisis e interpretación, que pueden variar de un analista a otro,
inclusive, en la interpretación que puede hacer el mismo contador, puede
haber diferencias de interpretación.
Así por ejemplo, en este trabajo sobre un gestión de

imprenta se utilizan muchos las “entidades débiles”, en muchos lugares donde
otros criterios de interpretación hubiesen definido la existencia de relaciones
muchos a muchos.

Los alumnos colaboradores utilizaron como criterio

principal el de la estructura física del documento principal, por ello, los
detalles de los distintos tipos de documentos que el sistema debe manejar
(facturas, recibos, ordenes de trabajo, etc.) son considerados “entidades
débiles” de la respectiva entidad que representa la “cabecera del documento”.
PERSONAS (A)
BANCOS (V)
PROVINCIAS (D) iii CIUDADES (C) ii 1. cApellido
xxx 70. nCodigoBanco 6. cCodProvincia 4. cCodigoPostal 2. cNombre
71. cNombreBanco
7. cProvincia 5. cCiudad 3. cDireccion
72. cDireccionBanco
8. cSexo
73. cSucursal xxxi
9. fNacimiento
i 10. cEstadoCivil
11. cNumeroTelefono
12. cCorreoElectronico
xxv xxxii 13. cTipoDocumento
EMPLEADOS (I) 14. cNumeroDocumento
LOGOS (G) CLIENTES (B)
26. nLogo vi 15. nCUIT 74. nLegajo xxxiv
27. gLogo 18. nInscripcionIB 75. fIngreso
xiv xxxiii
28. mLogo 19. fInicioActividad 76. lActivo
22. NombreEmpresa
viii xxxix
23. fAlta
ACTIVIDADES (F) 24. ySaldoCuenta PROVEEDORES
xxxvi
20. cCodActividad 25. yLimiteCredito (W)
v 103. mComentario
21. cDesActividad
xxiviv vii
CONDICIONES
IVA (E) xiii
PEDIDOS (H)
16. cCondicionIVA xii FACTURAS (N) 29. nPedido
17. cDescripcionIVA 37. nFactura xix FACTURACION 30. tFechaHoraPedido
38. cFactura (xix)
39. fFacturada x
40. fVencimiento
RECIBOS (O) 41. fCobrada
56. nRecibo xv
xxvi 42. ySubTotal
57. fR ecibo 43. yIvaInscripto
44. yIvaNoInscripto
xxvii ARTICULOS (L)
45. yTotal
35. cCodigoArticulo
xvii DETALLE
82. cArticulo xl
83. nExistencia PEDIDOS (K)
DETALLE 84. nStockM inimo 33. nRenglonPedido
DETALLES xxxv 34. nCantidadPedido
RECIBOS (S) 85. yPrecio
FACTURAS (P) xviii 86. yPrecioHistorico
58. nRenglonRecibo
46. nRenglonFactura
59. yImporte 87. fPrecioHistorico xxiii
47. nCantidadVendida
60. cM odoCobro 88. mPapeleria
48. yPrecioVenta
xxix
ARTICULOS_
xxxvii ORDEN (xxxv)
CHEQUES (U) ESTADOS COMPROBANTES 81. nInsumo
63. nCheque xvi DOCUMENTOS (J) (X)

64. fEmision 31. cCodigoEstado 89. mComprobante
xxi 90. nPuntoVenta
65. fPago 32. cDescripcionEstado ix xxxv
66. fDepositado 91. nInicial
67. fAcreditado 92. nFinal ORDENES
68. cNombreLibrador 93. nCopias TRABAJO (M)
69. cNumeroCuenta 94. fImpresion 36. nOrdenTrabajo
AUTORIZACIONES 77. mDescripcion
xi
(Y) 78. fOrdenTrabajo
95. nAutorizacion 79. fTerminacion
TIPOS 96. cDesAutorizacion 80. nAvance
xxxviii
MONEDA (T) 97.fAutorizacion
61. cTipoMoneda xxviii 98. fVenceAutorizacion
62. cNombreM oneda 99. cCodAutorizacion
DETALLE
100. cCodigoProxima
101. nPorcentaje REMITOS (R) REMITOS (Q)
102. mAutorizacionHTM L 54. nRenglonRemito
49. nRemito
Referencias s/Relaciones: 55. nCantidadR emitida xxii
> Lineas Gruesas: con Estados 50. fRemito
> Lineas Medianas: con Empleados 51. cTransporte
> Lineas Guiones: con Clientes
52. nPeso
> Lineas Puntos: con Articulos xx
> Resto Lineas: Resto Relaciones 53. nBultos
Sistema de Imprenta, Agregando Atributos y Claves..., Regla 4 y 5

(gráfico 39)

En el gráfico 39 se distribuyen los atributos y se marcan

las claves específicas de cada entidad, se observará que algunas entidades
débiles tienen un clave incompleta (no son claves unívocas) o le falta, esto se
completa con las reglas siguientes.
BANCOS (V) PERSONAS (A)
70. nCodigoBanco CIUDADES (C) 1. cApellido
PROVINCIAS (D) iii ii
xxx 71. cNombreBanco 4. cCodigoPostal 2. cNombre
6. cCodProvincia
72. cDireccionBanco 5. cCiudad 3. cDireccion
7. cProvincia
73. cSucursal '6. 'cCodProvincia 8. cSexo
'4. 'cCodigoPostal xxxi 9. fNacimiento
i 10. cEstadoCivil
11. cNumeroTelefono
12. cCorreoElectronico
xxv
13. cTipoDocumento
LOGOS (G) CLIENTES (B) xxxii
15. nCUIT EMPLEADOS (I) 14. cNumeroDocumento
26. nLogo vi 74. nLegajo '4. 'cCodigoPostal
27. gLogo 18. nInscripcionIB
75. fIngreso xxxiv
28. mLogo 19. fInicioActividad
76. lActivo xxxiii
15. nCUIT 22. NombreEmpresa xiv
23. fAlta '13. 'cTipoDocumento
viii xxxix
24. ySaldoCuenta '14. 'cNumeroDocumento
25. yLimiteCredito PROVEEDORES
ACTIVIDADES (F) v '13. 'cTipoDocumento (W)
20. cCodActividad
'14. 'cNumeroDocumento xxxvi 103. mComentario
21. cDesActividad
'16. 'cCondicionIVA 13. cTipoDocumento
'20. 'cCodActividad 14. cNumeroDocumento
xxiviv vii '35. 'cCodigoArticulo
CONDICIONES
IVA (E) xiii
16. cCondicionIVA xii
FACTURAS (N) PEDIDOS (H)
17. cDescripcionIVA FACTURACION
37. nFactura 29. nPedido
38. cFactura (xix) 30. tFechaHoraPedido
39. fFacturada 29. nPedido '15. 'nCUIT
RECIBOS (O) xix 37. nFactura '31. 'cCodigoEstado
40. fVencimiento
56. nRecibo 38. cFactura
41. fCobrada '74. 'nLegajo
57. fRecibo xv 42. ySubTotal
'15. 'nCUIT x
xxvi 43. yIvaInscripto
'31. 'cCodigoEstado
44. yIvaNoInscripto
'74. 'nLegajo
45. yTotal
xxvii '15. 'nCUIT
ARTICULOS (L) DETALLE
'16. 'cCondicionIVA
35. cCodigoArticulo PEDIDOS (K)
'31. 'cCodigoEstado
DETALLE 82. cArticulo xl 33. nRenglonPedido
'56. 'nRecibo
RECIBOS (S) '74. 'nLegajo 83. nExistencia 34. nCantidadPedido
58. nRenglonR ecibo 84. nStockM inimo 29. nPedido
59. yImporte xvii 85. yPrecio xxxv '35. 'cCodigoArticulo
60. cM odoCobro 86. yPrecioHistorico '36. 'nOrdenTrabajo
56. nRecibo 87. fPrecioHistorico xxiii
'61. 'cTipoM oneda DETALLES 88. mPapeleria
FACTURAS (P) xviii ARTICULOS_

xxix
46. nRenglonFactura
ORDEN (xxxv)
47. nCantidadVendida
xxxvii 81. nInsumo
48. yPrecioVenta
CHEQUES (U) 35. cCodigoArticulo
37. nFactura COMPROBANTES
63. nCheque 36. nOrdenTrabajo
38. cFactura (X)
64. fEmision
'35. 'cCodigoArticulo 89. mComprobante
65. fPago
66. fDepositado 90. nPuntoVenta xxxv
67. fAcreditado 91. nInicial
ESTADOS ORDENES
68. cNombreLibrador 92. nFinal
xvi DOCUMENTOS (J) 93. nCopias
TRABAJO (M)
69. cNumeroCuenta
31. cCodigoEstado 94. fImpresion 36. nOrdenTrabajo
'56. 'nRecibo
xxi 32. cDescripcionEstado 35. cCodigoArticulo 77. mDescripcion
'58. 'nRenglonR ecibo ix
'95. 'nAutorizacion 78. fOrdenTrabajo xi
'70. 'nCodigoBanco
79. fTerminacion
80. nAvance
AUTORIZACIONES
'74. 'nLegajo
(Y) xxxviii
TIPOS 95. nAutorizacion
MONEDA (T) 96. cDesAutorizacion
DETALLE
61. cTipoM oneda xxviii 97.fAutorizacion REMITOS (R) REMITOS (Q)
62. cNombreM oneda 98. fVenceAutorizacion 54. nRenglonR emito xxii 49. nRemito
99. cCodAutorizacion 55. nCantidadRemitida 50. fRemito
100. cCodigoProxima '35. 'cCodigoArticulo 51. cTransporte
Referencias s/Relaciones:
101. nPorcentaje 49. nRemito 52. nPeso
> Lineas Gruesas: con Estados
> Lineas Medianas: con Empleados 102. mAutorizacionHTM L 53. nBultos
> Lineas Guiones: con Clientes '31. 'cCodigoEstado
> Lineas Puntos: con Articulos
'37. 'nFactura
> Resto Lineas: Resto Relaciones
'38. 'cFactura
xx '74. 'nLegajo
Sistema de Imprenta, Aplicando el resto de las reglas (gráfico 40)

Conclusiones:
La utilidad de estas reglas se deberán probar con su uso,

por las pruebas llevadas a cabo, tanto por los alumnos colaboradores como
por alumnos del instituto privado mencionado, de nivel terciario, se pueden
resolver problemas de normalización mas rápidamente que utilizando formas
normales.
Además, con formas normales, se requiere un tipo de

conocimientos matemáticos que en la Carrera de Contador Público no son
inculcados a los alumnos, por lo que dado un conjunto de especificaciones,
volcarlos a un modo formal matemático para luego proceder a su
normalización, crearía una brecha imposible de cubrir.
En la experiencia del autor, con mas de 15 años

diseñando (y enseñando sobre el tema) bases de datos, en muchos casos se
presentan esquemas de bases de datos, que para los cuales, lograr especificar
en modo formal su estructura es muy difícil o imposible de expresar,
principalmente cuando el esquema esta orientado a objetos.
Téngase en cuenta además que estas reglas no están

orientadas a desplazar otras metodologías de normalización (como las
mencionadas en la primera parte de este trabajo), pero si a cubrir el vacío que
puede presentársele a un Contador Público, que tenga que normalizar un
pequeño sistema de datos, y no cuenta con las herramientas básicas para ello.

Bibliografía:
Bases de Datos (Una concepción de Sistemas de Información)
Guillermo SERRANO de ENTRAMBASAGUAS
Servicio de Publicaciones del Ministerio de Educación y Ciencia de
España (1976)
Bases de Datos
John K. LYON
Editorial El Ateneo (1983)
Arquitectura de Bases de Datos
Ivan FLORES
Diseño e Implementación de Bases de Datos
I.B.M.
I.B.M. Argentina S.A. (1986)
Sistemas de Administración de Bases de Datos
Dimitris N. CHORAFAS
Aplique SQL
James R. GROFF, Paul N. WEINBERG
Editorial Mc Graw Hill (1991)
Fundamentos de Bases de Datos (2da. Edición)
Henry F. KORTH, Abraham SILVERCHATZ
Análisis y Diseño Orientado a Objetos
James MARTÍN, James J. ODELL
Editorial Prentice Hall (1994)
Ingeniería del Software: Un enfoque práctico (4ta. Edición)
Roger S. PRESSMAN
Diseño e Implementación Base de Datos c/SQL SERVER.
Microsoft
Microsoft Corporation (1997).
Guía de SQL (LAN TIMES)
James R. GROFF, Paul N. WEINBERG
Evolución de las Bases de Datos: Modelos Orientado a Objetos y Relacional
Extendido
Alejandro Deg’Innocenti
Cuadernos de Reportes Técnicos ITBA (1999)
Diversos Artículos en INTERNET. Para ello se utilizo el buscador Yahoo y Google,

efectuando una búsqueda con las palabras claves Entidad, Relación, Extendida,
Objeto, Base de Datos, Normalización.
Por la cantidad de enlaces obtenidos, es imposible transcribirlos, es más se
presento la situación que enlaces accedidos en una primera instancia, no estaban
disponibles en lo sucesivo, y otros tenían información repetida o no aplicables para
este trabajo.

Reglas Practicas Diseño Base Datos PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Reglas Practicas Diseño Base Datos PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Facultad de Ciencias Económicas y Jurídicas UNLPam

Reglas Prácticas de Normalización de Datos aplicables al Diseño de Bases de Datos

Cr. Carlos Miguel FARIAS Año 2002 Página 1

¿Por que Normalizar?.....................................................................................................................................6

Reglas Practicas: .............................................................................................................................................43

Cr. Carlos Miguel FARIAS Año 2002 Página 2

a) Simplificar la modelización de bases de datos aplicando principalmente

b) Posibilitar al profesional de Ciencias Económicas el diseño Bases de

c) Establecer mecanismos simples para que el Contador pueda evaluar la

Cr. Carlos Miguel FARIAS Año 2002 Página 3

Tales profesionales pueden utilizar sistemas de gestión de

 Utilizan planillas de cálculo (Excel, Lotus, etc.) creando planillas con

 Por la forma de diseño de las planillas, la incorporación de datos se

 A veces, para solucionar la carga, el contador crea “macros” dentro de

 En el caso de haber logrado cargar los datos, la elaboración posterior

Un buen diseño de las bases de datos, permite al

De esta manera puede cargar datos fácilmente en los

Por lo tanto, estas reglas podrán ayudar al Contador a

Como las metodologías de diseño de bases de datos por

Cr. Carlos Miguel FARIAS Año 2002 Página 5

¿Por que Normalizar?

Sin embargo, para la Base de Datos Relacional (en

Aunque algunos podrán alegar que el modelo

Todo el proceso de normalización busca distribuir

Para el caso de la redundancia, se supone que se guardan

Si todo esto se pone en una tabla (por ejemplo de nuestra

Cr. Carlos Miguel FARIAS Año 2002 Página 6

De este simple ejemplo se puede ver que hay gran

En realidad, en el ejemplo anterior no solo se repiten las

Los dos párrafos precedentes muestran como es la

Otro problema altamente asociado con el anterior, es que

Cr. Carlos Miguel FARIAS Año 2002 Página 7

Esto evidencia también que los datos no serían

El ejemplo planteado, favorece la falta de integridad de

Cualquier sistema de Información con características

Como puede verse, estas circunstancias puede causar

Cr. Carlos Miguel FARIAS Año 2002 Página 8

La forma de efectuar esto es a través de los tipos de

La relación que está en la FN más elevada posible es la

La normalización convierte una relación (conjuntos de

En el ejemplo de la Tabla 1, se observa una relación con

Al normalizar, la idea es crear varias tablas (sub-

Por supuesto que este proceso de normalización debe ser

Cr. Carlos Miguel FARIAS Año 2002 Página 9

Por lo que si el sistema es optimizado (normalizado) se

 El Volumen de Datos es el menor posible que implica:

Cr. Carlos Miguel FARIAS Año 2002 Página 10

Antes de empezar con el proceso de normalización, se

Conceptos Básicos: Antes de entrar en tópicos específicos como la

1) Atributos (Datos): Los individuos tienen muchos atributos que pueden

2) Dominio (del atributo): Es el Universo (U) de valores posibles a que

Cr. Carlos Miguel FARIAS Año 2002 Página 11

3) Aplicación: Se denomina comúnmente “aplicación” a la

4) Tupla: La variedad de atributos o datos, se encontrarán distribuidos en

5) Relación: También se simbolizará como R (letra en negrita) a cada

Cr. Carlos Miguel FARIAS Año 2002 Página 12

En forma de tabla, las poblaciones del ejemplo quedarían

6) Esquema de una relación o de tabla: es el nombre de la relación

7) Base de datos relacional: es una base de datos cuyo esquema es un

Cr. Carlos Miguel FARIAS Año 2002 Página 13

f) La clave primaria de una relación se selecciona entre las claves

Semestre Código Iniciando Terminando Inscripto

9) Universo Relacional: U es el universo consistente en todas las posibles