En la unidad pasada se habló de los Sistemas Informáticos centrados en bases de datos.

Ahora aislaremos el componente técnico y hablaremos

del proceso para implementar ese componente.

Necesidad - No se puede comenzar el diseño de una base de datos si no se especificó su propósito (requerimientos funcionales – OLTP o DSS) – el
diseño de un ambiente transaccional de bases de datos es completamente diferente del diseño de un ambiente de bases de datos para
consultas. Ese diseño guiará las pautas para la eficiencia y facilidad de mantenimiento del ambiente.

Toda base de datos construida pasa por los tres niveles presentados:

• Nivel Conceptual – en esta etapa se definen formalmente los requerimientos de información. Esa información es la que debe ser procesada y
almacenada de manera persistente. El diagrama técnico que unifica la presentación de esos requerimientos es el Modelo Entidad-Relación
(E-R). Hay algunas condiciones y características de la información que no se pueden representar en el E-R por eso se complementa este nivel
con la especificación de las reglas y condiciones adicionales. El nivel conceptual es parte de la etapa de Análisis del SBD.
• Nivel lógico – aquí se aplica el modelo de implementación o arquitectura de bases de datos elegido – Relacional, OR, OO,…se traduce el E-R
a las especificaciones de diseño pertinentes. Para este momento es obligatorio tener el MBD elegido ya que el diseño dependerá de las
características de ese Manejador. Por ejemplo si se quiere definir claves foráneas y el Manejador es NoSQL nunca se podrá implementar esa
característica…El nivel lógico ocurre en la etapa de Diseño del SBD.
• Nivel físico – aquí se implementa la base de datos – se crean los objetos, se inserta la información base y se implementan las medidas de
acceso y seguridad para que los usuarios a través de las distintas aplicaciones informáticas pertinentes puedan conectarse a esa base de
datos y trabajar la información según su rol (algunos sólo consultando, otros generando la misma). Para construir una base de datos se
requiere el MBD – esta herramienta tendrá los mecanismos y lenguajes necesarios para la implementación. El nivel físico es parte de la etapa
de Implementación del SBD. Cuando se llega al nivel físico se debe tener instalado y configurado el MBD. Si son SQL habrá un lenguaje de
implementación estandar que permitirá mantener y migrar fácilmente la b/d.

Antes de comenzar a implentar las interfaces de usuario se debe tener construida por completo la base de datos, de lo contrario se perderá
mucho tiempo corrigiendo errores y reprogramando las interfaces debido a los cambios que se vayan haciendo mientras se prueba su
funcionamiento.

Prof.Lúcia  Cardoso   3  
 El Modelo Entidad Relación es una técnica propia de la Ingeniería Informática y carreras afines, cuyo objetivo es representar los requerimientos
de información de una organización o de un proceso de negocio. En el E-R sólo se representará la información que posteriormente será
almacenada en la base de datos a construir. No se utiliza el E-R para validar con los usuarios sus necesidades. El E-R es de uso exclusivo del
ingeniero. Un E-R NO ES UN DIAGRAMA DE CLASES, no representa objetos ni aplica nada del paradigma OO.

Aunque este modelo se puede utilizar para el entendimiento conceptual, el ingeniero informático lo usa para garantizar un diseño íntegro e
eficiente de su b/d, por ende, el uso correcto de la técnica está vinculado a la construcción de una base de datos. El profesional o aprendiz se
debe mover con facilidad entre el negocio y su naturaleza (representación abstracta de la realidad) y las implicaciones técnicas de un
ambiente de computación.

El E-R va a ser el instrumento más valioso que tendrá el analista y el desarrollador para construir una b/d efectiva. Si se piensa en este modelo
como un conjunto de “cajitas” que se pintan por obligación pero que no significan nada para el técnico, se estará perdiendo el tiempo…

Del lado del negocio pensamos en la información (tanto de entrada como de salida) que requieren sus actividades o procesos. Del lado técnico
pensamos en archivos en medios de almacenamiento secundario (discos), memoria, procesador y solicitudes de lectura y/o escritura. Archivos
no ordenados se modifican más rápido pero implican búsquedas más lentas – siempre secuenciales; archivos ordenados implican búsquedas
rápidas pero actualizaciones extremadamente lentas.

Tomando en cuenta todo lo anterior comenzaremos a trabajar concretamente para lograr un SBD efectivo.

No puede prevalecer un solo mundo – debe estar claro el concepto del negocio y se debe pensar en el uso eficiente de los recursos técnicos.

Físicamente una base de datos es un conjunto de archivos no ordenados persistentes. Estos archivos se mantienen a través del MBD. El tiempo de
respuesta será en función de lo que tarde el computador en recuperar los bloques de información almacenados y montarlos en memoria –
cuando alguna aplicación o programa modifica esos bloques éstos se copian nuevamente a disco. Menos escritura implica un tiempo de
respuesta menor. La construcción de esos archivos se hará en función del diseño de bases de datos aplicado. Si se diseña mal, el ambiente no
será eficiente ni íntegro.

Prof.Lúcia  Cardoso   4  
 Existen muchas notaciones para realizar un E-R. Si se puede elegir, excelente si el ambiente de trabajo exige utilizar alguna en particular, pues
habrá que adaptarse. El punto es que al aprender a utilizar una se puede entender todas las demás. Los componentes siempre serán los mismos
y con una leyenda que explique el significado de cada elemente se podrá leer cualquiier diagrama con cualquier notación.

Las dos notaciones principales son las de Peter Chen y la de James Martin – ambos autores y especialistas en la Teoría de Bases de Datos.

James Martin es considerado el padre de la Ingeniería de Información. Las herramientas de modelado automatizan alguna derivación de la
notación de James Martin. Una de las más populares es la notación “Patas de Gallo” (autor Richard Barker) por su representación de los vínculos
o relaciones múltiples.

La notación de Chen es de uso académico y de poca utilización en la práctica debido a su alto nivel de abstracción que obliga a mayor
esfuerzo de traducción del diseño. Mientras más traducciones haya que hacer entre el concepto y el diseño mayor probabilidad de cometer
errores.

Para la materia utilizaremos la notación “Patas de Gallo”. Herramientas de modelado nativas de los manejadores de bases de datos Oracle
utilizan tal notación. Otros utilizan aproximaciones y, algunos ambientes hacen uso de UML (lenguaje unificado de modelado) para realizar E-Rs.

Si la base de datos a implementar es relacional se tendrá una traducción casi transparente del E-R (notación “Patas de Gallo”) al Modelo Lógico,
disminuyendo los errores y reduciendo el tiempo de trabajo y esfuerzo del ingeniero.

Los elementos del E-R son:

Entidades – cajas con bordes redondeados y el nombre de la entidad en letra mayúscula. Entre paréntesis se pueden colocar nombres
alternativos o sinónimos.
Atributos – se ubican dentro de cada entidad y se escriben en letra minúscula. Al lado de cada atributo se debe indicar su opcionalidad
(obligatorio - *; opcional – o).
Relaciones (o vínculos) – cada una tiene un nombre, opcionalidad ( obligatoria; opcional) y cardinalidad ( simple; múltiplle)
Uids (Identificadores únicos) – atributos con # y/o relaciones con |

Prof.Lúcia  Cardoso   5  
 Al indicar que una entidad es un conjunto se indica que debe tener múltiples elementos y cada elemento responde a las mismas características.
Si se mezclan elementos de diferentes conjuntos en una misma entidad se pone en peligro la integridad ya que el comportamiento, reglas y
condiciones no aplican de igual manera a diferentes conjuntos. El conjunto debe tener significado para el negocio. Así Empleado significa un
conjunto de personas que trabaja formalmente en una organización. Al identificar conjuntos verdaderos se garantiza la independencia entre
cada uno.

Desde el punto de vista físico, se debe imaginar cada entidad como un archivo independiente de otros. Eso es muy importante para garantizar
la integridad de la información modelada en la b/d. Si hay dependencias entonces es necesario duplicar información – la información
duplicada en un ambiente transacional es crítica porque si los cambios no se aplican uniformemente a todos los registros duplicados entonces se
tendrán muchas versiones de la misma información y nunca se sabrá cuál es la verdadera. Por otro lado si los archivos fueran dependientes se
deben almacenar vinculados (a través de apuntadores) y cada vez que se quiera recuperar algun bloque se tendría que montar en memoria la
totalidad de los archivos vinculados. A medida que crece el ambiente los archivos se pueden fragmentar porque no hay espacio secuencial
para almacenarlos – un sistema de computación se vuelve lento cuando depende de discos con información fragmentada. Ambos ejemplos
muestran como el diseño de la b/d afectará la integridad de la información y la eficiencia del SBD.

Cada conjunto puede tener muchas características, pero sólo se representarán aquellas relevantes para el negocio. Esas caracterísitcas o
cualificadores del conjunto son los atributos.

No se almacenarán conjuntos con pocos elementos por ende una entidad válida debe tener múltiples ocurrencias o registros – cada
organización tiene muchos empleados y a lo largo del tiempo esa cantidad puede crecer o se puede reducir (nuevos contratos, despidos o
renuncias).

Cada ocurrencia debe tener una identificación que la haga única (no se repite dentro del conjunto). El UID es un requisito técnico. Los UIDs serán
utilizados por el MBD para construir archivos ordenados que agilizarán la recuperación de la información. Si el conjunto no tiene un atributo que
naturalmente sea único entonces se debe crear uno – esos atributos reciben el nombre de atributos artificiales.

Prof.Lúcia  Cardoso   6  
 Cada entidad de un E-R tendrá significado debido a sus atributos. Se observa en las ocurrencias que se puede conocer varias cosas de cada
empleado – su nombre completo, su género, cuando nacieron y por ende calcular su edad, cuando ingresaron a la compañía y por ende saber
su antigüedad…Si la información del conjunto fuera toda numérica no se sabría nada de cada persona empleada.

La información como nombre, dirección aporta signifiacado pero debe ser tratada con mucho cuidado en un ambiente de b/d. Los caracteres
se comparan individualmente y hay muchas variantes – letras mayúsculas, minúsculas, acentos, caracteres especiales, etc… Por ejemplo,
conceptualmente hablando es correcto poner como atributo nombre del empleado – sin embargo ese diseño no sería eficiente porque se
almacenaría una cadena que tiene al menos 4 partes y, no habría forma de poder automatizar los filtros o condiciones de búsqueda – Ana
Perez; Perez Ana; Perez Gomez, Ana; anaperez…. Cualquiera de las anteriores serían cadenas válidas para guardar en un campo Nombre…
Cómo pudiera devolver empleados cuyo primer apellido es Perez?...por eso no se modelan atributos compuestos – nombre se descompone en
primer nombre, segundo nombre, primer apellido, segundo apellido como mínimo. En la Entidad se debe indicar la combinación mínima
completa del atributo compuesto, teniendo como criterio lo que es obligatorio – todas las personas con partida de nacimiento tiene al menos un
nombre y dos apellidos, el segundo nombre es opcional pero es importante contemplarlo porque puede dar un criterio adicional de búsqueda.
Si lo que se almacena no se puede recuperar no tiene sentido construir la b/d.

Más adelante trataremos al atributo direccion. Por ahora se considera una cadena completa.

Los nombres de cada atributo deben tener significado – no hago nada con colocar fecha1 y fecha2, nombre1, nombre2, nombre3. No habría
referencia con el negocio y el analista perdería su tiempo haciendo el levantamiento de información y plasmándolo en un E-R.

Los atributos derivados o calculados también se deben tratar con mucho cuidado. La regla es no modelarlos a menos que se haya evaluado las
implicaciones de realizar una desnormalización (se explicará en la unidad temática 3). Para el ejemplo, realmente la información de interés para
el negocio es la edad, sin embargo se guarda la fecha de nacimiento. Por qué? La fecha de nacimiento no cambia, no hay que actualizar
nada, cada vez que se quiera saber la edad de una persona se calculan los años restando la fecha de nacimiento a la fecha actual. La edad es
un valor que cambia constantemente si se almacenara perdería vigencia antes de llegar a disco y habría que estar modificando ese valor a
tiempo real en cada ocurrencia (qué tal una empresa con 100000 empleados…).

Prof.Lúcia  Cardoso   7  
 Si fuera necesario almacenar la nacionalidad de cada empleado se tendría que resolver dos problemas:
1.Cada campo de un archivo físico solo puede almacenar un valor por ocurrencia. Para el ejemplo el empleado Pedro Gonzalez
es venezolano y español pero sólo se podría guardar una de las dos – eso no es aceptable porque afecta la integridad de la
información. O peor, se ingresan dos registros iguales repitiendo todos los datos del empleado menos cada nacionalidad.(sería
una solución peor que la primera por afectaría la integridad y la eficiencia). Entonces si un atributo es multivaluado se debe
convertir en una entidad.

2.Supongamos que cada persona tiene una sola nacionalidad, pero muchos empleados tendrán la misma (es un atributo cuyos
valores se repiten en varias ocurrencias)– hay varios venezolanos, varios colombianos, etc. Dejar el atributo pone en peligro la
integridad de información porque una cadena que se repite y no se protege no sirve – se puede escribir VENEZOLANA;
VENEZOLANO; VENEZUELA; venezolano, Venezolana; venezuela;…6 cadenas diferentes pero que conceptualmente son la misma.
Se pudiera validar el atributo con una lista de valores permitidos – así se garantiza integridad pero se afecta la eficiencia – hay
más de 195 nacionalidades, cada vez que se inserte un valor en el campo nacionalidad el MBD hace la comparación con las
195 cadenas y el tiempo de la transacción no sería adecuado.

La mejor alternativa tanto para integridad como eficiencia es crear otra entidad y vincular ambos conjuntos.

El género no es multivaluado pero sí es repetitivo y pasa lo mismo que con la nacionalidad – se puede escribir Hombre,
Masculino, m, h, MAS, …y cuando se necesite saber cuántos hombres y cuántas mujeres hay en la empresa nunca se
sabrá….pero a diferencia de la nacionalidad, este atributo sólo tiene 2 valores posibles – masculino, femenino así que se puede
completar el atributo con una validación – lista de valores permitidos (F, M) – se puede usar solo las iniciales y almacenar una
cadena menor, y al momento de realizar las consultas y mostrar los reportes se completa el texto.

Prof.Lúcia  Cardoso   8  
 Las relaciones muestran como los conjuntos de información se vinculan. En general las actividades o procesos de negocio necesitan muchos
conjuntos de información y esos conjuntos se vinculan para dar el significado final que se requiere.

En el ejemplo vemos que la entidad Emplleado está relacionada con la entidad Departamento. Con esas relaciones se modela el concepto
“trabajo actual”.

Aunque visualmente se verá una sola relación, siempre existen 2 – relación que va del conjunto A al conjunto B; relación que va del conjunto B al
conjunto A. La relación muestra la cardinalidad (una ocurrencia de un conjunto con cuántas ocurrencias del otro conjunto se vincula); la
opcionalidad (cada elemento de un conjunto puede o debe relacionarse con el otro conjunto) y el nombre del vínculo.

Según opcionalidad se tiene:

Relación obligatoria.

Relación opcional

Cardinalidad uno y sólo uno

Cardinalidad uno o muchos

En el conjunto empleados se ve que cada empleado está asignado a un solo departamento. Un departamente puede estar vacío o tener varios
empleados – el 20 y el 40 están vacíos pero el 30 tiene los empleados 1,4,5. Así se construyen las relaciones.

De Empleado a Departamente es una relación obligatoria y de cardinalidad 1 y sólo uno. De Departamento a Empleado es una relación
opcional y de cardinalidad 1 o muchos.
Cómo se lee de Empleado a Departamento: Un empleado debe trabajar en uno y sólo un Departamento. Cómo se lee de Departamento a
Empleado: Un Departamento puede emplear uno o más empleados

Prof.Lúcia  Cardoso   9  
 La opcionalidad de la relación se pinta del lado de la entidad afectada, la cardinalidad se pinta del lado opuesto. Los nombres
se colocan uno abajo y otro arriba, cada uno cerca de la entidad que representa.

Físicamente las relaciones no implican almacenamiento dependiente, sino la creación de un campo de referencia que permitirá
enlazar lógicamente (en memoria) los registros de ambos conjuntos. En el conjunto Empleados se crea un campo que guarda el
UID del departamento al que ese empleado está asignado – así cuando se quiera saber la información completa sólo hay que
igualar esos valores. Más adelante veremos que esa característica se llama Integridad Referencial siendo una de las ventajas
técnicas de un ambiente de bases de datos. Hay integridad porque no se puede guardar un id en idDept que no exista en
Departamento, pero también hay eficiencia porque la asociación de los registros ocurrirá en memoria.

Entre dos conjuntos las combinaciones posibles de cardinalidades son:

1:1 (uno a uno) ambos conjuntos tienen cardinalidades uno y sólo uno
1:N ó 1:M (es lo mismo). M:1 ó N:1 (Depende de qué lado se esté leyendo. (uno a muchos o muchos a uno). Una entidad tiene
cardinalidad uno y sólo uno y la otra uno o muchos
M:N (muchos a muchos). Ambas entidades tienen cardinalidades múltiples.

Las relaciones 1:M son las más comunes y representan la típica relación maestro/detalle (un maestro muchos detalles). Las
relaciones M:N aunque conceptualmente correctas no se pueden implementar en la base de datos por eso deben ser
transformadas.

Prof.Lúcia  Cardoso   10  
 Las relaciones M:N no se pueden implementar por el mismo motivo que no se puede implementar un atributo
multivaluado - en un campo o columna sólo se puede guardar un valor por ocurrencia. Las M:N deben ser rotas
creando relaciones 1:M, permitiendo su almacenamiento. Se crearán entidades artificiales que se llaman entidades
de intersección. Estas entidades al igual que los atributos artificiales son requerimientos técnicos.

Dejar el E-R con vínculos M:N es correr el riesgo de no implementar correctamente la base de datos.

Prof.Lúcia  Cardoso   11  
 La forma general de resolver una relación M:N es como se ve en la lámina:
1.Se crea una entidad de intersección. El nombre no es significativo y generalmente se usa la combinación de las iniciales de las
entidades involucradas.
2.Las relaciones originales de cada entidad se mantienen con la misma opcionalidad y cardinalidad
3.Del lado de la entidad de intersección cada relación debe ser obligatoria y de cardinalidad uno y sólo uno
4.No hay atributos porque esa entidad sólo se crea para romper las cardinalidades múltiples
5.El UID es la combinación de las relaciones de las entidades involucradas. Para el ejemplo sólo se puede guardar una vez el
empleado 2 con la nacionalidad 100, si se tratara de repetir y volver a guardar el 2 con la 100, el MBD da error. Si se hubiese
colocado la barra en una sola relación no se tendría unicidad ya que tanto los empleados como las nacionalidades se repiten.

En el próximo material veremos más ejemplos de relaciones M:N que no se resuelven con este estándar.

Para garantizar un diseño eficiente, un E-R nunca debe tener relaciones M:N sin resolver.

Cerrando el punto de los UIDs - Los UIDs pueden ser simples (un atributo o una relación) o compuestos (varios atributos, varias
relaciones o una combinación de ambos). Desde el punto de vista técnico sirven para lograr la unicidad de la ocurrencia en el
conjunto; agilizar las búsquedas y actualizaciones; implementar la integridad referencial. Por entidad sólo existe un UID.

El criterio es definir UIDs simples antes que compuestos. Exclusivamente numéricos y muy excepcionalmente fechas combinadas
con números. Nunca se debe tener un UID que corresponda a cadenas de caracteres.

En la mayoría de los casos se crean atributos artificiales – que luego se implementan generando números secuenciales.

Prof.Lúcia  Cardoso   12