Cómo diseñar una base de datos y no morir en el intento

Hola a todos. Mi nombre es José León Cabel. Profesional  en Ing. De Sistemas y más de 18 años en el rubro del desarrollo e instrucción en lo concerniente a Tecnologías de Información, y ahora compartiendo con uds. algo que me apasiona: el diseño de base de datos. Este es el primer artículo de una serie de 4 que  tendrá como objetivo fundamental el aportar a los usuarios finales, que no necesariamente están ligados a temas de Tecnologías de Información (TI), pautas y conocimientos metodológicos acerca de cómo diseñar una base de datos , independientemente de la magnitud o alcances del  escenario real donde dichos usuarios se desarrollan.

¿Es la Información un recurso vital en la empresa moderna?

Como punto de partida me gustaría compartir con ustedes  un concepto de información que, mas allá de tecnicismos y esferas donde nos desenvolvemos, me parece uno de los más claros y de aceptación general: “Información es todo aquello que reduce nuestro nivel de incertidumbre acerca de algo que tenemos  necesidad de conocer”. Podemos poner varios ejemplos

a) Es sábado por la noche y quiero ver una buena película”. Pues lo primero que tenemos que hacer es informarnos en que sala de cine pasan la película, en que horarios, el costo de las entradas y comentarios acerca de la película (actores,  guion, director, etc.)

b) “Necesito hacer un viaje para relajarme y recargar energías”. Igual que el punto anterior, el interesado deberá buscar información sobre promociones turísticas, costos, que incluyen cada plan de viaje, hospedajes, entre otros  puntos de importancia.

c) “Me he dado cuenta que necesito seguir un diplomado en Marketing para desempeñarme mejor en mi  empleo”. Si esa es la necesidad, pues deberemos saber que instituciones ofrecen ese tipo de diplomados, su duración, horarios, si se dicta “on line” o presencial, los temarios o contenidos por curso, los expositores y la certificación que se obtendrá al finalizar el dicho diplomado. En pocas palabras, información.

Con estos 3 ejemplos de la vida diaria demostramos que tan importante es la información, la cual tiene como consecuencia final, que si la tenemos en un alto nivel de calidad y veracidad, nos asegura un altísimo porcentaje de éxito en la decisión que tomemos  y podríamos asegurar una excelente noche de cine, un reparador e inolvidable viaje de vacaciones o el de alcanzar una mejor proyección en nuestro desarrollo laboral.

Ahora si esto se da en esta pequeña escala la pregunta es ¿Qué será en las corporaciones grandes?

Imagine que es Ud. el responsable de definir el plan de expansión de una cadena de supermercados. ¿En base a que definiría en qué puntos de Lima o provincias aperturar un nuevo local? Lo más probable sería hacer un estudio de mercado con información acerca de mercados potenciales, competencia, ubicación y facilidad de acceso a los posibles nuevos locales, etc., además de conocer nuestras posibilidades de inversión en el plan de expansión que ambicionamos. Como nos damos cuenta, la información aquí ya es más detallada, especifica y requiere de un mayor cuidado en obtenerla. 

Dependiendo el nivel  administrativo donde se tomen las decisiones, la calidad y exactitud de la información varía. La siguiente gráfica así lo demuestra:

En los niveles operativos y tácticos las decisiones son de tipo estructurada, es decir, los factores que permiten tomar la decisión son conocidos y se tiene una alta posibilidad de  éxito. Por ejemplo a que proveedor  solicitarle un producto o el monto a cobrarle a un cliente, según su cronograma de pagos. El cometer un error en este nivel, se puede manejar de manera correcta sin fuertes impactos en la empresa (claro está, si no son cotidianos).

Nos habíamos quedado conversando acerca de la mitología llamada Entidad-Relación, que nos permitirá diseñar lógicamente la base de datos y plasmarlo en un diagrama conocido como Diagrama Entidad-Relación. La metodología se llama así, porque identifica las Entidades pertenecientes al escenario a analizar así como sus relaciones.

El concepto de Entidad ya lo habíamos dado (todo aquello relevante para el sistema y de lo cual se que requiere registrar información). Sin embargo, antes de pasar al tema de Relaciones, es importante definir otro concepto esencial: Los atributos.

Los Atributos, características de las Entidades

Cada entidad tiene características que permiten identificarla, calificarla, clasificarla  o cuantificarla. Esas características se llaman Atributos. Por ejemplo en el caso de una base de datos para una clínica, el paciente sería una entidad importante y por tanto habría que identificar que atributos son relevantes conocer del paciente. Sin duda, sería necesario registrar su nombre, apellidos, sexo, fecha de nacimiento, DNI, dirección, teléfono, tipo de sangre, talla, peso, estado civil entre otros de importancia para un centro médico. Información como su experiencia laboral o formación académica no serian relevantes para un sistema de este tipo.

Si por otro lado el sistema fuera de Recursos Humanos, definitivamente que el trabajador seria una entidad relevante, y atributos como nombre, apellidos, sexo, fecha de nacimiento, dirección, teléfono, correo electrónico, DNI, experiencia laboral y formación académica serian importantes conocer, más no su tipo de sangre, peso o talla (aunque si hay empresas que registran dicha información de sus colaboradores).

Esto nos lleva a una conclusión. La identificación de los atributos depende del escenario donde nos ubiquemos, de tal forma que estemos seguros de que la información a registrar será la que realmente necesitamos para luego procesarla y obtener resultados valiosos.

El atributo Clave Principal

 Dentro de la lista de atributos identificados en una entidad, hay uno que debe ser el que permita ubicar a cada ocurrencia de la entidad. Llamamos ocurrencia a cada instancia de la misma  (por ejemplo, de la entidad Alumno, cada alumno es una ocurrencia de dicha entidad, como también en la entidad Producto, cada uno  de los productos es una ocurrencia o instancia de la misma). El atributo que nos permita acceder de manera única a una determinada instancia de la entidad es el llamado Clave Principal.  Hay 2 requisitos para que un atributo sea definido como Clave Principal:

- Que tenga valores únicos en cada ocurrencia de la entidad

- Que exista un valor para todas las ocurrencias de la entidad

Veamos algunos casos. En la entidad  Trabajador  podemos ubicar los siguientes atributos (asumiendo que son  empresas o personas jurídicas):

- Código del trabajador

 - Nombres

- Apellido Paterno

- Apellido Materno

- DNI

- Fecha de Nacimiento

- Sexo

- Estado Civil

- Dirección

- Distrito

- Teléfono Fijo

- Teléfono Celular

- Cargo

- Fecha de  Ingreso

- E_mail

- Estado (Activo o Inactivo)

De esta lista de atributos hay 2 que pueden ser Clave Principal: El código del trabajador o su DNI. Los demás atributos no cumplen los requisitos indicados. Si estuvo pensando que el correo pudo ser clave principal, pues se encuentran casos de trabajadores que no cuentan con un correo electrónico (o no tiene la necesidad de tener uno) o si pensaron que el teléfono fijo o celular podría ser clave también, pues puede ser que algunos trabajadores sean miembros de la misma familia y compartan el mismo número de teléfono fijo. Y si pensó  por un instante en el número de celular, pues simplemente pueden existir trabajadores que no tengan celular.

Por consiguiente de los  2 candidatos a ser clave principal se debe elegir solo uno, donde lo más probable es que sea el código del trabajador, quedando el DNI como una clave alterna, para ubicar a un trabajador, en caso de que  no se tenga su código. Esto lo vemos a diario en muchas empresas donde tenemos una afiliación, por ser clientes, alumnos, etc. Si no se tiene a la mano nuestro código, pues nuestra DNI servirá para identificarnos.

Refinando Normalizando

El término “Normalización” es muy conocido en el ámbito de las base de datos. Si bien es cierto que el concepto se aplica  ya al modelo implementado para determinar su validez, podemos ir anticipándonos a ciertas cosas durante la construcción del modelo olgico.

Por ejemplo, en el caso de la entidad tTabajador expuesto  líneas arriba hay 2 atributos que pueden derivarse o convertirse en entidad: Distrito y Cargo . Bajo que premisa podemos afirmar esto?? . Por las siguientes razones:

a) Tanto el distrito como el cargo existen independientemente del trabajador. El hecho que el trabajador José León Cabel deje de pertenecer a la empresa, no quiere decir que el distrito de Surquillo deje de existir o que el cargo de Jefe de proyectos que el ostentaba  ya no exista más.

b) La cantidad de ocurrencias de distritos y de cargos amerita a que se deriven a una entidad para su mejor control y gestión. Solo en Lima existen más de 45 distritos y en una empresa pueden tranquilamente existir más de 10 cargos.

Por  tanto la lista de atributos  seria asi:

- Código del trabajador

- Nombres

- Apellido Paterno

- Apellido Materno

- DNI

- Fecha de Nacimiento 

- Sexo 

- Estado Civil

- Dirección

- Código de distrito

- Teléfono Fijo

- Teléfono Celular

- Código de Cargo

- Fecha de  Ingreso

- E_mail

- Estado (Activo o Inactivo)

Tercera Parte:

Hola de nuevo. Mi nombre es José León Cabel.  En mi primera entrega conversamos sobre la importancia de la información en las actividades cotidianas, ya sea en nuestras vidas  personales como también en las organizaciones donde nos desempeñamos.

En la segunda, planteamos la necesidad de identificar atributos o características para las entidades,  siendo importante  tomar en cuenta a los que son necesarios dentro del ámbito del sistema. Además, establecimos la necesidad de incluir en cada entidad un atributo de tipo Clave Principal, factor de vital importancia en la búsqueda de información en una base de datos. Por último , establecimos también un refinamiento (Normalización) en cuanto a algunos atributos que podían convertirse en entidades, como en el caso del distrito y el cargo, quedando así el ejemplo final de la entrega anterior:

ENTIDAD TRABAJADOR

- Código del trabajador (Clave Principal)

- Nombres

- Apellido Paterno

- Apellido Materno

- DNI

- Fecha de Nacimiento 

- Sexo

- Estado Civil

- Dirección

- Código de distrito

- Teléfono Fijo

- Teléfono Celular

- Código de Cargo

- Fecha de  Ingreso

- E_mail

- Estado (Activo o Inactivo)

ENTIDAD  DISTRITO

- Código Distrital (Clave Principal)

- Nombre del distrito 

ENTIDAD CARGO:

- Código del cargo (Clave Principal)

- Descripción del cargo

En esta última entrega conversaremos acerca de las Relaciones entre las entidades y daremos la “estocada final” para el entendimiento de cómo se inicia el diseño de una base de datos. Allá vamos!!! 

Las Relaciones y como están  vinculadas las entidades 

En el modelo lógico (que es el ámbito donde nos ubicamos)  el termino RELACION  se orienta a la forma como 2  o más entidades están asociadas o vinculadas. Cuando la relación involucra a 2 entidades se llama relación binaria; cuando son 3 relaciones se llama relación ternaria y  así  por el estilo. Por ahora nos encargaremos solo de las relaciones binarias que son las más frecuentes. 

En este punto quisiera hacer una aclaración y desmitificar un concepto que vengo observado cómo se va mal interpretando por muchas personas. Veamos: 

El modelo lógico (que estamos diseñando) se basa en los requerimientos de los usuarios  de la base de datos, de acuerdo a lo que ellos necesitan almacenar en ella. Para elaborar el modelo lógico existe la metodología llamada “Modelo Entidad Relación” (MER), cuyo entregable es el gráfico llamado Diagrama Entidad Relación (DER). Bajo este punto de vista las relaciones son VÍNCULOS o ASOCIACIONES entre las entidades del modelo. 

Culminado el modelo lógico, este debe revertirse en el modelo físico, es decir, la base de datos propiamente dicha. Para ello, en lo que al  modelo físico se refiere, en la actualidad se emplea el modelo llamado “Modelo Relacional” que se basa en el principio MATEMÁTICO de relación el cual define a ésta como “conjunto de elementos”.  Ejemplo: cuando uno escucha por la radio “Daremos la RELACIÓN de ganadores del premio por el día de la madre” la palabra relación no implica vínculo, sino conjunto o grupo.  En el modelo físico entonces, la palabra RELACIÓN no implicavínculo o asociación, sino más bien conjunto y que para evitar confusiones con el modelo lógico se le conoce mejor como TABLA: Entonces podemos afirmar que el modelo  lógico permite implementar bases de datos que si son físicamente vistas en el modelo físico relacional, pueden ser construidas en cualquier manejador de base de datos  “relacional” como lo son casi todos los software de base de datos en la actualidad (Access, SQL Server, Oracle, etc.).  En el modelo físico , cada entidad y atributo  del modelo lógico se convertirán en tablas y columnas respectivamente.

En conclusión,  y justo hacia ahí apunta mi aclaración,  una base de datos  desde el punto de vista “físico” es relacional no porque sean “un conjunto de tablas relacionadas” como lo vengo leyendo y escuchando en muchos sitios, sino que es “relacional” porque se basa en el concepto MATEMÁTICO de relación el cual equivale a conjunto. Espero haber sido claro.

Nos enfocaremos en las relaciones ahora.

Para determinar el grado de una relación se emplea el término multiplicidad. Existen 3 tipos de multiplicidad. Sean las entidades A y B veamos lo siguiente:

- De uno a uno: Cuando para una ocurrencia de la  entidad A le corresponde una y solo una ocurrencia de la unidad  B y viceversa.

- De uno a muchos : Cuando para una ocurrencia de la entidad A existen una o más ocurrencias en la entidad  B y para cada ocurrencia de la entidad  B existe una y solo una ocurrencia en la entidad A

- De muchos a  muchos: Cuando para una ocurrencia de la entidad A existen una o más ocurrencias en la entidad B y para cada ocurrencia de la entidad B existen una o más  una ocurrencias en la entidad A.

Nótese la simbología, la entidad se diagrama con un rectángulo, la relación con una línea recta y la multiplicidad con la rayita “perpendicular” indicando grado uno y  la “patita de gallo” indicando grado muchos. 

Consejos para identificar la multiplicidad 

Si tiene dificultades en establecer el grado de una relación  siga estos pasos:

- Nombre cada entidad con un sustantivo en SINGULAR: Ejemplo: Alumno, Producto, Cliente, Factura. No use plural !!!

- Identifique un verbo para la relación. Por ejemplo entre las entidades Cliente y Factura puede ser emplear  verbo “Generar”

- Identificado el verbo, lea la relación en ambos sentidos y empezando de “UN(A)”. Por ejemplo  entre las entidades Cliente y Factura seria así :

Leyendo  de Cliente a Factura: “UN Cliente genera una o más Facturas”. Ahora leyendo de Factura a Cliente:”UNA Factura es generada por un solo Cliente”

En conclusión la relación entre Cliente con Factura seria de “Uno a Muchos” siendo el lado “Uno” Cliente y el lado “Muchos” Factura. 

Maneje con cuidado el factor “tiempo” en las relaciones: 

Por ejemplo, si tenemos las entidades Trabajador y  Cargo podemos decir que “Un trabajador ocupa un cargo y un cargo es ocupado por muchos trabajadores”. Esto sería si el análisis lo hacemos en el tiempo presente. Pero si lo hacemos “históricamente” hablando, la relación seria “Un trabajador HA OCUPADO uno o más cargos y un cargo es ocupado por muchos trabajadores!”. Nótese como el factor tiempo convierte una relación de UNO a MUCHOS en una relación de MUCHOS a MUCHOS. Siempre es bueno cuestionar las relaciones uno a muchos y si el factor tiempo es necesario en su sistema pues tome la segunda opción del ejemplo como grado para la relación entre Trabajador y Cargo. 

Migrando al modelo físico

Como ya adelantamos líneas arriba, el modelo lógico es la “receta” del pastel. Ud. el pastel lo puede hacer con la marca de horno que desee, pero si sigue al pie de la letra la receta y emplea ingredientes de calidad, es casi seguro que el pastel salga riquísimo. Aquí el pastel es la base de datos ya implementada en los “hornos con marca” Access, SQL Server u Oracle.

Recuerde que cada Entidad se convertirá en una Tabla de la base de datos física. Cada atributo de las entidades se convertirá en campos de la tabla (con sus respectivos tipos de datos según el manejador de base de datos que se elija). Y el atributo clave principal  será la Llave Primaria de la tabla. A continuación damos a conocer 2 reglas para refinar el modelo lógico antes de pasarlo al físico: 

Refinando las relaciones de Uno a Muchos:

“En una relación de uno a muchos el atributo clave principal del lado uno pasa como atributo de clave foránea a la entidad del lado muchos.”

Por ejemplo, en la relación Cliente-Factura, el atributo código del cliente que es clave principal de la entidad Cliente, pasaría a formar parte también de los atributos de la entidad Factura como una clave foránea. Esto permitirá saber cada factura que cliente la generó. 

Nota: Si la relación es de Uno a Uno, la clave principal de una entidad puede a pasar a formar de los atributos de la otra según sea más conveniente. Por ejemplo en la relación Asiento-Pasajero, el código de pasajero (clave principal de la entidad Pasajero) puede pasar a ser parte de los atributos de la entidad Asiento, y así se sabrá que pasajero ocupa cada asiento, o si se desea, el Nro. De asiento (clave principal de la entidad Asiento) puede pasar a formar parte de la entidad Pasajero para saber que asiento le corresponde a cada pasajero. 

Refinando las relaciones de mucho a muchos

“Una relación de muchos a muchos no se puede implementar en el modelo físico relacional. Por tanto, se debe construir una entidad  asociativa, que tendrá como clave principal una clave compuesta por las claves primarias de  cada entidad asociada. Podrá agregar más atributos a dicha entidad, de acuerdo a la necesidad planteada”

Por ejemplo, en la relación Alumno- Curso que se muchos a muchos se deberá reemplazar esta por una entidad asociativa (que se puede llamar Alumno_Curso) que tendrá como clave principal una clave compuesta por los atributos código del curso (clave principal de la entidad Curso) y el código del alumno (clave principal de la entidad Alumno). Puede agregar aquí los atributos de Examen Parcial, Examen Final, Nota de Proyecto de tal forma que esta entidad permita saber que cursos lleva cada alumno y que notas tiene en cada uno de ellos.

Donde los términos PK se refieren a Primary Key (Llave Primaria) , FK a Foreign Key (Llave Foránea) y PFK Primary Foreign Key (Llave Primaria Foranea).

Bien, hasta aquí llegamos. Espero que estos 3 avances les hayan permitido entender e iniciarse en el mundo del modelamiento de datos.  Recuerden que existen herramientas como el TOAD o ERWIN que permiten no solo diseñar los DER sino que también en base a ellos generar de manera automática la base de datos, pero esto vas mas allá del alcance de estas entregas.

Por último, sino cuenta con estas herramientas puede crear su modelo a mano, eso sí…lápiz, papel , borrador y muy buen humor para empezar todo de nuevo cuando sea necesario. 

Cualquier  consulta o asesoría en proyectos informáticos me pueden escribir a mi correo: [email protected]. 

Saludos. Dios los bendiga. Hasta la próxima.