¿Cuál es el diseño conceptual de la base de datos? ¿Qué es el modelo lógico y conceptual? ¿Qué es el diseño lógico y físico de una base de datos? ¿Qué es el diseño conceptual?

El diseño conceptual de una base de datos consiste en representar el sistema objeto cuyos datos serán almacenados en la base de datos.

Al momento de diseñar, el diseñador revela cómo es el sistema objeto a través de personas, documentos y procedimientos. Se deben representar aquellos aspectos del sistema objeto que sean relevantes para la toma de decisiones. Dicha relevancia viene dada por las necesidades actuales y futuras de información. Existen técnicas de diseño que brindan herramientas para hacer esta representación y capturar la mayor cantidad de datos posibles.

Aplicando la normalización y otros criterios de diseño, se llega a un modelo implementable. Este es el modelo de datos lógico, que consiste en el esquema de la base de datos.

Para garantizar que se obtiene una comprensión precisa de la naturaleza de los datos y del modo en que éstos se utilizan en la empresa, se requiere disponer de un modelo de comunicación que no sea técnico y que esté libre de ambigüedades. El modelo Entidad-Relación (E-R) es una representación que permite formalizar cuáles son los datos, y las relaciones entre éstos, que debe guardar el SI.

El modelo E-R es una técnica de diseño de base de datos de tipo arriba a abajo que comienza identificando los datos más importantes, denominados entidades, y las relaciones entre los datos que deben presentarse en el modelo. Después se añaden más detalles, como la información que se requiere almacenar acerca de las entidades y relaciones, lo que se denomina atributos y sobre cualesquiera restricciones que haya que aplicar a las entidades, relaciones y atributos.

Entidad

El modelo E-R está basado en una percepción del mundo real que consiste en un conjunto de objetos básicos, denominados entidades, y de las relaciones entre esos objetos. Una entidad es una cosa, persona o hecho del mundo real que es distinguible de otros objetos (es decir, algo que existe y que puede ser representado) sobre el cual el sistema debe guardar información. Las entidades son un grupo de objetos con las mismas propiedades, que la empresa identifica como poseedores de una existencia independiente. Puede tratarse de objetos con una existencia física (real) o de objetos con una existencia conceptual (abstracta).

Para cada entidad es necesario definir atributos, ocurrencias y clave primaria.

Ocurrencia o instancia de la entidad

Cada uno de los elementos concretos en los que se manifiesta esta entidad es una ocurrencia o instancia de la entidad. Se trata de un objeto identificable de forma unívoca dentro de un tipo de entidad. Se da cuando en una entidad los distintos atributos asumen un valor para representar una determinada instancia de la misma en la realidad.

Atributos

Las entidades se describen en las bases de datos mediante un conjunto de atributos. Un atributo es toda aquella característica o propiedad que se desee registrar de una ocurrencia de una entidad. Los atributos de una entidad son acordes con las características de la realidad que se desea representar, por ello varían en cada diseño particular. No se trata de representar todas las características de esa entidad, sino solamente las que son relevantes, es decir, las propiedades que representan a la entidad para esa organización.

Los atributos contienen valores que describen cada ocurrencia. Lo que se guarda en una base de datos son los valores posibles que pueden tener cada una de esas instancias. Cada atributo está asociado a un dominio, es decir, un conjunto de valores permitidos para uno o más atributos. El dominio es único y define los valores potenciales que un atributo puede tener.

Claves

Una superclave es un conjunto de uno o más atributos de una entidad que, cuando toman un valor, identifica unívocamente una ocurrencia de una entidad. Se trata de uno o varios atributos que, considerados conjuntamente, permiten identificar de manera unívoca una dupla (fila) de la relación. Las superclaves no son suficientes ya que pueden contener atributos innecesarios. Si C es una superclave, entonces también lo es cualquier subconjunto de C. Aquellas superclaves para las que ninguno de sus subconjuntos constituya una superclave se los denomina superclave mínima o clave candidata.

La clave candidata es el conjunto mínimo de atributos cuyos valores identifican de forma unívoca cada instancia de una entidad. Es aquella superclave a la que, si se elimina cualquier atributo del conjunto, deja de ser superclave. No puede contener valores no obligatorios (nulos). Una clave candidata es compuesta si está formada por 2 o más atributos. Ocurre en los casos donde la clave está compuesta por varios atributos cuyos valores, tomados conjuntamente, son unívocos para cada instancia de la entidad, pero no lo son si se los considera por separado.

La clave primaria (PK) es una clave candidata (por ende, es superclave) a la que se la elige como el principal criterio de identificación. Es la clave candidata que ha elegido el diseñador de la base de datos como medio principal para la identificación de las tuplas de una relación. Es obligatoria por definición y escogerse de manera que los valores de sus atributos no se modifiquen nunca, o muy rara vez (no admite duplicados). Se suele elegir teniendo en cuenta:

• Número mínimo de atributos.
• Menor frecuencia de cambios.
• Menor longitud.
• Más afín a la perspectiva del usuario.

Las claves (sean primarias, candidatas o superclaves) son propiedades de toda la relación, no de cada una de las tuplas. Ninguna pareja de tuplas de la relación puede tener simultáneamente el mismo valor de los atributos de la clave. La selección de una clave representa una restricción de la empresa del mundo real que se está modelando.

Las claves alternas son todas las claves candidatas no elegidas como clave primaria. No necesariamente son obligatorias.

Las claves subrogadas aparecen cuando, en ciertos casos, no es posible determinar una superclave, por lo que se inventa un atributo autogenerado para identificar unívocamente una ocurrencia de un evento. Es una clave inventada para ser primaria. Solamente se considera subrogada si no existía como atributo del sistema objeto al momento del diseño.

La clave foránea (FK) es una clave de una entidad que también es clave primaria de otra entidad. Es un atributo o conjunto de atributos que hacen referencia a la clave primaria de otra entidad (o a la misma, en el caso de relaciones recursivas).

Relación

Una relación es un conjunto de asociaciones significativas entre instancias de entidades. Representa las conexiones que existen entre los datos que se almacenan.

Las relaciones se definen por las claves foráneas (son la manera mecánica de dar existencia a una relación). Se clasifican según:

Restricciones

Además de entidades y relaciones, el modelo E-R representa ciertas restricciones que los contenidos de la base de datos deben cumplir. Las mismas existen para, y entre, los datos del modelo. Las restricciones pueden estar dadas por:

Transformar modelo en esquema

El modelo E-R no es la representación formal que se utilizará para diseñar el futuro esquema de la base de datos porque:

• Las entidades débiles no llevan PK, sino discriminantes.
• No se formalizan las FK.
• Existen relaciones N a M.
• Se permiten atributos multivalorados y entidades débiles.

Es por eso que para realizar el esquema de la base de datos el modelo se utiliza el diagrama Entidad-Relación (DER). Convertir el modelo en el diagrama requiere de la aplicación de una serie de reglas de transformación.

1. En las entidades fuertes se crea una relación que incluya los atributos simples.
2. En las entidades débiles se crea una relación que incluye los atributos simples y se agrega la PK de la entidad identificadora, definiéndose luego como PK de la entidad.
3. Incluir FK en las entidades, del lado del “muchos” de las relaciones.
4. Incluir la FK en las relaciones de 1 a 1 (del lado en que es subtipo, participación opcional) en donde será, además, PK.
5. Crear una tabla para representar las relaciones N a M, su PK se compone de las PK de las entidades que relaciona (por otro lado, cada una actúa como FK), y se le agregan los atributos de la relación si los tuviese.
6. Crear una tabla para representar un atributo multivalorado e incluir también un atributo de la PK de la entidad propietaria (identificadora) en la nueva tabla, la misma actuará como clave externa. También hay que definir su PK.
7. Aplicar la técnica de normalización para validar que las entidades estén bien formadas.

Trampas de conexión

Al realizar un modelo E-R pueden aparecer problemas derivados de una mala interpretación del significado de ciertas relaciones. Estos problemas se llaman trampas de conexión, las cuales deben resolverse para evitar crear un modelo que no sea una representación veraz del mundo real.

Los dos tipos más comunes de trampas de conexión son:

• Trampas multiplicativas: ocurre cuando un modelo representa una relación entre entidades, pero la ruta entre ciertas instancias de entidad es ambigua. Puede existir cuando salen de la misma entidad dos o más relaciones del tipo 1 a n. Se resuelve reestructurando el modelo E-R original con el fin de representar la asociación correcta entre las entidades.
• Trampas de corte: ocurre cuando un modelo sugiere la existencia de una relación entre ciertas entidades, pero no existe ninguna ruta entre ciertas instancias de entidad. Puede existir cuando hay una o más relaciones con una multiplicidad mínima de 0 (es decir, participación opcional) formando parte de la ruta que conecta a dos entidades relacionadas. Se resuelve identificando la relación que falta.

Normalización

La normalización es un método de diseño que permite estructurar las entidades del modelo de datos de una forma tal que sea más eficiente la actualización de los datos cuando el modelo sea implementado. El objetivo es generar un conjunto de esquemas de relaciones que permita almacenar información sin redundancias innecesarias, pero que también permita recuperar la información con facilidad.

La normalización es necesaria para evitar propiedades no deseables:

• Repetición de la información.
• Imposibilidad de representar determinada información.

Una vez que se aplica la normalización a las entidades se dice que éstas se encuentran normalizadas. Para lograrlo es conveniente ir pasando por distintos estados de las entidades, llamados formas normales. Las formas normales representan pruebas que tratan de identificar el agrupamiento óptimo de los atributos de estas entidades, con el fin de identificar un conjunto de relaciones que soporten adecuadamente los requisitos de datos de la organización. Las características de un conjunto adecuado de relaciones incluyen:

• Número mínimo de atributos necesarios para soportar los requisitos de datos de la organización.
• Los atributos con una relación lógica fuerte (dependencia funcional) se encuentran en la misma relación.
• Una redundancia mínima, estando cada atributo representado una sola vez, con la importante excepción de aquellos atributos que constituyan o formen parte de claves externas, los cuales son esenciales para la combinación de relaciones.

Anomalías de actualización

Las relaciones con datos redundantes pueden presentar problemas que se denominan anomalías de actualización, las cuales se clasifican en:

Primera forma normal (1FN)

Una entidad está en primera forma normal (1FN) si se trata de una relación en la que la intersección de toda fila y columna contiene un valor y sólo un valor. Está basada en el concepto de grupo repetitivo. Existe grupo repetitivo cuando un atributo puede asumir más de un valor en una misma ocurrencia.

Para que una entidad se encuentra en 1FN debe cumplir dos condiciones:

1. Tener definida su clave primaria.
2. No contener grupos repetitivos.

Segunda forma normal (2FN)

Una entidad está en segunda forma normal (2FN) si se trata de una relación que está en 1FN y en la que todo atributo que no sea de clave candidata depende funcionalmente de modo completo de cualquier clave candidata.

La 2FN está basada en el concepto de dependencia funcional. Se dice que un atributo B depende funcionalmente de un atributo A si el valor que asume el atributo A determina el valor que asumirá el atributo B. En otras palabras, cada valor de A está asociado con exactamente un valor de B. Esto se simboliza como A→B. En este caso se dice que A es determinante de B, lo que implica que dos instancias que tengan el mismo valor para A tendrán el mismo valor para B; sin embargo, para un determinado valor de B puede haber varios valores diferentes de A.

Se dice que hay dependencia funcional completa si la eliminación de cualquier atributo de A hace que la dependencia funcional deje de existir. En cambio, es parcial si existe algún atributo que puede eliminarse de A y la dependencia continúa verificando.

La 2FN se aplica a las relaciones con PK compuestas, es decir, PK conformadas por 2 o más atributos. Por ende, una relación con PK de un único atributo está automáticamente en 2FN.

Para que una entidad se encuentra en 2FN debe cumplir dos condiciones:

1. Encontrarse en 1FN.
2. No tener dependencias funcionales parciales respecto de la clave primaria. Es decir, todo atributo que no forme parte de la clave primaria debe depender funcionalmente del total de la clave primaria.

Tercera forma normal (3FN)

Una entidad está en tercera forma normal (3FN) si se trata de una relación que se encuentra en 1FN y 2FN y en la que ningún atributo que no sea de clave candidata depende transitivamente de ninguna clave candidata.

La 3FN se basa en el concepto de dependencia funcional transitiva:

Para que una entidad se encuentra en 3FN debe cumplir dos condiciones:

1. Encontrarse en 2FN.
2. No existen dependencias funcionales transitivas, es decir, que no existan dependencias funcionales entre atributos que no formen parte de la clave primaria.

Forma normal de Boyce-Codd (FNBC)

La forma normal de Boyce-Codd (FNBC) analiza si la dependencia funcional es trivial o no. En una dependencia funcional, un subconjunto de atributos A determina el valor de un subconjunto de atributos B. Dicha dependencia es trivial cuando B está incluido en A.

Una relación está en FNBC cuando, dada una dependencia funcional A→B, ocurre una de las siguientes posibilidades:

• A es superclave.
• A→B es trivial, estando previamente en 3FN.

La diferencia entre 3FN y FNBC es que para la dependencia funcional A→B, 3FN permite que exista esta dependencia en una relación si B es un atributo de clave principal y A no es superclave, mientras que FNBC exige, para que esta dependencia permanezca en una relación, que A sea superclave. Por tanto, FNBC es más fuerte que 3FN, de modo que toda relación en FNBC está también en 3FN.

Una entidad cuyos atributos son todos PK está automáticamente en FNBC.

Cuarta forma normal (4FN)

La cuarta forma normal (4FN) se basa en el concepto de dependencia multivaluada, las cuales ocurren cuando, dado un valor para el atributo A éste determina valores para el subconjunto de atributos B. Se simboliza A↠B.

Una entidad está en 4FN cuando, dada una dependencia multivaluada A↠B, ocurre una de las siguientes posibilidades:

• A↠B es trivial, es decir B está incluido en A (B∪A).
• A es superclave de A↠B (siendo en este caso la dependencia no trivial).

4FN es más fuerte que FNBC ya que impide que las relaciones contengan dependencias multivaluadas no triviales y, por tanto, redundancia en los datos. La normalización de FNBC a 4FN implica la eliminación de las dependencias multivaluadas de la relación, colocando los atributos en una nueva relación junto con una copia de los determinantes.

Quinta forma normal (5FN)

La quinta forma normal (5FN) se basa en el concepto de dependencia de reunión. Cuando al descomponer una entidad en dos entidades no se preservan los datos de la relación original y, al querer volver a combinarlas, se generan tuplas espurias adicionales se dice que hay descomposición con pérdida. En el caso contrario, la descomposición es sin pérdida.

Si hay descomposición sin pérdida se dice que hay dependencia de reunión o de combinación. Esta es trivial cuando, para que no haya pérdida, siempre tiene que haber una tabla con todos los atributos de la PK de la entidad original.

En función de esto, una entidad está en 5FN cuando no contiene dependencias de reunión no triviales.

Puede ocurrir que, por aplicación de las reglas de normalización, no se pueda incluir dentro de una tabla un atributo que permitiría establecer una FK necesaria para validar dicho atributo contra otra tabla. Esto se denomina dilema de la restricción. Para resolverlo, se debe elegir entre agregar el atributo y establecerlo como FK (desnaturalizando la entidad) o dejarlo así y establecer la restricción de otra manera.

Criterios de buen diseño

Representar información

El objetivo de todo modelo es representar un sistema objeto. Siempre que surjan dudas de cómo representar la información del mismo, se debe buscar aquella manera que mejor lo describa. Para ello, se debe tener en cuenta:

• Evitar valores indefinidos: son aquellos atributos donde no corresponde valor, corresponde pero falta o no se sabe si corresponde.
• Definir nivel de desagregación: se trata de tener el mayor nivel de desagregación de los datos, dentro de lo razonable. El nivel se decide según las necesidades del modelo.
• Capacidad de generar información: el modelo debe poder responder las consultas que se le realicen para que el usuario obtenga la información que requiere.

Evitar redundancia

Es un buen criterio evitar atributos derivados almacenados y la repetición en los valores. El objetivo de esto es:

• Reducir espacio de almacenamiento.
• Menor costo de actualización.
• Menor probabilidad de generar inconsistencias.
• En el costo de consultas el impacto puede ser positivo o negativo:
• La redundancia puede servir para encontrar más fácilmente un dato y hacer más sencilla la consulta.
• Tener datos redundantes, en el caso de atributos derivados, hace que en una consulta la información tarde más tiempo en obtenerse porque los registros que la base debe leer son más largos.

Asegurar consistencia

Añadir restricciones al modelo tiene un costo, el cual tiene que ver con la validación de los datos que se ingresan. Si los costos de asegurar la consistencia son mayores que los beneficios, se debe tomar la decisión profesional de no validar esa restricción y compensar esa falta de alguna otra manera.

Claridad conceptual

Tiene que ver con la semántica del modelo: debe ser comprensible y fácil de entender. Se debe establecer un criterio para nombrar los atributos y seguirlos durante todo el desarrollo del mismo. Esto ayuda a que el usuario sepa que existen ciertos atributos sin necesidad de ir a buscarlos.