MODELO RELACIONAL.pdf

MODELO RELACIONAL 3.1. Introducción al modelo relacional Modelo Relacional Este modelo fue propuesto por Edgar F. Codd, quien se basó en la teoría de las relaciones para desarrollarlo. En este modelo los datos se estructuran lógicamente en forma de relaciones (tablas) y su objetivo fundamental es...

MODELO RELACIONAL 3.1. Introducción al modelo relacional Modelo Relacional Este modelo fue propuesto por Edgar F. Codd, quien se basó en la teoría de las relaciones para desarrollarlo. En este modelo los datos se estructuran lógicamente en forma de relaciones (tablas) y su objetivo fundamental es mantener la independencia de esta estructura lógica respecto al modo de almacenamiento y ante cualquier otra característica de tipo físico. El modelo relacional, como su nombre lo indica, se basa en el concepto de relación, que significa que para su representación utiliza una matriz bidimensional llamada tabla. Una tabla es similar a una hoja de Excel y está formada por columnas llamadas campos, y cada uno tiene asignado un nombre único en la tabla (cabe resaltar que este modelo permite que los nombres se puedan repetir). Además, cada campo se asocia con un conjunto de valores válidos que se corresponde con los datos que se almacenarán en ellos, éstos se identifican como dominio y todos deben ser del mismo tipo en cada campo. Las filas que conforman la tabla son un conjunto de campos de diferente tipo que, en conjunto, dan significado a los datos almacenados: es decir, componen la información. A estos conjuntos se les conoce como tuplas o registros (véase la figura 1 donde se muestran las partes que componen una tabla). Figura 1 Partes de una tabla Las tablas que integran la base de datos no deben duplicarse o, por lo menos, un campo debe ser diferente. Cabe destacar que no es importante ingresar la información en un orden determinado, ya que el sistema se encargará de organizarla automáticamente. Por otro lado, se recomienda que cada fila y cada columna sólo alberguen un valor, pues, aunque es posible que alberguen varios, esto complicaría la extracción de información al realizar una consulta. Del mismo modo en que se definieron los componentes de una tabla, es preciso definir los componentes de otros elementos como la llave primaria, clave primaria o primary key, PK por sus siglas en inglés, la cual no es más que uno o varios campos que identifican de forma única a cada tupla o registro y son la base para que se puedan relacionar con otras tablas. Este campo o conjunto de campos deben cumplir con los siguientes requisitos para que puedan ser considerados como una PK: Debe identificar unívocamente a todos los posibles registros o tuplas que serán contenidas en la tabla en todo instante. Siempre debe tener un dato almacenado pues no se permite la ausencia de éstos. A la ausencia de datos se le llama valor nulo, o null, y si se permitieran los valores nulos como identificadores de la tabla, no se podría relacionar con otras tablas y habría más de un valor de este tipo en alguna otra tupla. El dato de este campo puede ser de cualquier tipo; es decir, puede ser numérico o alfanumérico. Como se mencionó anteriormente, para que se puedan relacionar las tablas en una base de datos, además de la asignación de una PK, se debe definir la columna (o columnas) que se relacionarán con otra (u otras). A esta columna se le denomina llave foránea, clave foránea o foreign key (FK). La FK se debe definir en la tabla con la que se relaciona y el único requisito es que debe almacenar la misma información que la PK a la que hace referencia. El concepto FK es la característica más relevante de este modelo, ya que permite dividir la información en partes más simples y cuando se realiza la extracción de la información, el usuario final la visualiza como un conjunto único de datos. Reglas o principios del modelo relacional Información. Toda la información de la base de datos debe estar almacenada en las tablas base del sistema; es decir, no pueden existir datos a los que se tenga acceso por una vía diferente que no sean las tablas definidas en el modelo relacional. Acceso garantizado. Todo dato en la base de datos es accesible cuando se conoce el valor de su clave principal y el nombre de la columna o atributo que lo contiene. Esto implica que todas las tablas deben tener un identificador, lo que nos permite acceder a una fila concreta (tupla o registro en la base de datos): la columna es accesible por su nombre y no por el orden que tiene. Tratamiento sistemático de los valores nulos. El sistema gestor de bases de datos debe permitir el tratamiento adecuado de los valores nulos. Esto significa que dichos valores se consideran y se procesan como información, por lo que operar con estos valores no deberá producir error alguno. Catálogo en línea basado en el modelo relacional. El catálogo en línea es otro nombre para el diccionario de datos. Lo que significa que la forma de acceder a los metadatos es la misma que se emplea para acceder a los datos. Dicho de otra forma, los metadatos también se almacenan en tablas. Sublenguaje de datos completo. Debe de existir, por lo menos, un lenguaje que permita el manejo completo de la base de datos y mediante este lenguaje debe ser posible realizar cualquier operación sobre la base de datos, sea del tipo que sea. Actualización de vistas. El SGBD debe encargarse de que las vistas muestren información actualizada. Las vistas en ningún caso deberán mostrar información obsoleta. Inserciones, modificaciones y eliminaciones de dato nivel. Cualquier operación de modificación debe actuar sobre conjuntos de filas o registros. Por tanto, los lenguajes de manipulación de datos deben ser de cuarta generación y no pueden ser lenguajes como C o Java.  Independencia física. El esquema lógico no se debe modificar por los cambios que se realicen en la base de datos física. Es decir, aunque, por ejemplo, cambiemos el nombre de un fichero de la base de datos, esto no modificará ni los programas de los usuarios ni la lógica de la base de datos. Independencia lógica. Los cambios en las tablas de la base de datos no deben afectar a la forma en la que el usuario accede a la base de datos. Independencia de integridad. Las reglas de integridad deben almacenarse en la base de datos como parte de su diseño, no en los programas de aplicación. Esto permite que dichas reglas siempre se cumplan, independientemente de la forma en que se acceda a los datos. Independencia de la distribución. El sublenguaje de manipulación de datos (DML) debe permitir que sus instrucciones funcionen de la misma forma en una base de datos distribuida que en una que no lo es. Los programas y aplicaciones de usuarios se deben crear de la misma forma. No subversión. Si el SGBD dispone de un lenguaje de bajo nivel para trabajar en la base de datos, este lenguaje no se puede saltar ninguna regla de las anteriores. Es posible que este tipo de lenguaje facilite la realización de tareas, pero en ningún caso podrá trabajar con los datos de forma incompatible con el modelo relacional. Objetivos del modelo Codd perseguía estos objetivos con su modelo relacional: Independencia física. La forma de almacenar los datos debe ser absolutamente independiente del modelo conceptual de los mismos. Si la forma de almacenar los datos cambia, no es necesario cambiar los esquemas lógicos, pues estos deben funcionar perfectamente. Esta característica permite que los usuarios se concentren en los resultados que desean obtener de la base de datos independientemente de la manera en que están almacenados.  Independencia lógica. Se refiere a que la lógica de la base de datos debe ser independiente de la forma externa de acceso a ella. Las aplicaciones que utilizan la base de datos no deben ser modificadas porque se corre el riesgo de que se modifique el esquema lógico de la misma. Es gracias a esta independencia que el esquema externo de la base de datos es realmente independiente del modelo lógico. Cabe destacar que en la práctica esta independencia es difícil de conseguir. Flexibilidad. La base de datos ofrece, con facilidad, distintas vistas en función de las necesidades que requieran los usuarios y las aplicaciones, la visión de los datos se adapta al usuario que los requiere. Uniformidad. Las estructuras lógicas siempre tienen una forma lógica única; es decir, manejar el modelo relacional es manejar las tablas. Sencillez. Facilidad de manejo. 3.2. Conversión de modelo E-R a modelo relacional Una vez realizado el diseño conceptual, y obtenido el esquema correspondiente mediante un diagrama entidad-relación, se debe proceder con la etapa del diseño lógico. En esta etapa se debe decidir el modelo lógico de base de datos que se va a utilizar para llevar a cabo la implementación. Puesto que el modelo relacional es el modelo lógico de bases de datos más extendido, en este tema se presenta la metodología de diseño para este modelo. Esquema lógico El diseño lógico es el proceso de construir un esquema de la información que utiliza la empresa, basándose en un modelo de base de datos específico e independiente del SGBD concreto que se vaya a utilizar, así como de cualquier otra consideración física. Mientras que el objetivo fundamental del diseño conceptual es la compleción y expresividad del esquema conceptual, el objetivo del diseño lógico es obtener una representación que use, del modo más eficiente posible, los recursos que el modelo de SGBD posee para estructurar los datos y para modelar las restricciones. En esta etapa, se transforma el esquema conceptual obtenido en la etapa anterior del diseño, en un esquema lógico que utilizará las estructuras de datos del modelo de base de datos en el que se basa el SGBD que se vaya a utilizar. Los modelos de bases de datos más extendidos son el modelo relacional, el modelo de red y el modelo jerárquico. El modelo orientado a objetos es también muy popular, existiendo SGBD objeto-relacionales que implementan el modelo relacional e incorporan características de la orientación a objetos. El esquema lógico es una fuente de información para el diseño físico. Además, juega un papel importante durante la etapa de mantenimiento del sistema, ya que permite que los futuros cambios que se realicen sobre los programas de aplicación o sobre los datos, se representen correctamente en la base de datos. Tanto el diseño conceptual, como el diseño lógico, son procesos iterativos, tienen un punto de inicio y se van refinando continuamente. Ambos se deben ver como un proceso de aprendizaje en el que el diseñador va comprendiendo el funcionamiento de la empresa y el significado de los datos que maneja. El diseño conceptual y el diseño lógico son etapas clave para conseguir un sistema que funcione correctamente. Si la base de datos no es una representación fiel de la empresa, será difícil, si no imposible, definir todas las vistas de los usuarios (los esquemas externos), o mantener la integridad de la misma. También puede ser difícil definir la implementación física o mantener unas prestaciones aceptables del sistema. Además, hay que tener en cuenta que la capacidad de ajustarse a futuros cambios es un sello que identifica a los buenos diseños de bases de datos. Por todo esto, es fundamental dedicar el tiempo y las energías necesarias para producir el mejor esquema posible. La estructura de datos del modelo relacional es la relación, a la que coloquialmente denominamos tabla, término utilizado en la implementación de este modelo por parte del lenguaje SQL. El objetivo de esta etapa es obtener el esquema lógico, que estará formado por las tablas de la base de datos en tercera forma normal, a partir de la especificación realizada en la etapa del diseño conceptual. Una vez obtenidas las tablas, se considerará la posibilidad de modificar el esquema de la base de datos para conseguir una mayor eficiencia. No se debe olvidar que, si en durante la etapa del diseño lógico se detecta alguna carencia o error en la etapa anterior (diseño conceptual), se debe subsanar dicho error en el esquema conceptual, y se debe generar una nueva versión de la documentación que se ha producido en dicha etapa. Para cada tabla del esquema lógico se debe especificar: Nombre y descripción de la información que almacena. Es conveniente indicar si corresponde a una entidad, una relación o un atributo. Para cada columna, indicar: nombre, tipo de datos (puede ser un tipo de SQL), si admite nulos, el valor por defecto (si lo tiene) y el rango de valores (mediante un predicado en SQL). Indicar la clave primaria y si se ha de generar automáticamente.  Indicar las claves alternativas. Indicar las claves ajenas y sus reglas de comportamiento ante el borrado y la modificación de la clave primaria a la que referencian. Si alguna columna es un dato derivado (su valor se calcula a partir de otros datos de la base de datos) indicar cómo se obtiene su valor. Especificar las restricciones a nivel de fila de cada tabla, si las hay. Estas restricciones son aquellas que involucran a una o varias columnas dentro de una misma fila. Especificar otras restricciones no expresadas antes (serán aquellas que involucran a varias filas de una misma tabla o a filas de varias tablas a la vez). Especificar las reglas de negocio, que serán aquellas acciones que se deba llevar a cabo de forma automática como consecuencia de actualizaciones que se realicen sobre la base de datos. Introducir tablas de referencia para establecer listas de valores para las columnas que las necesiten. Una vez obtenido el esquema de la base de datos en tercera forma normal, y teniendo en cuenta los requisitos en cuanto a transacciones, volumen de datos y prestaciones deseadas, se puede realizar ciertos cambios que ayuden a conseguir una mayor eficiencia en el acceso a la base de datos: Introducir redundancias desnormalizando algunas tablas o añadiendo datos derivados. Partir tablas horizontalmente (por casos) o verticalmente (por columnas). Metodología de diseño En este apartado se presentan los pasos a seguir para obtener un conjunto de tablas a partir del esquema conceptual. A cada tabla se le dará un nombre, y el nombre de sus atributos aparecerá, a continuación, entre paréntesis. El atributo o atributos que forman la clave primaria se subrayarán. Las claves ajenas, mecanismo que se utiliza para representar las relaciones entre entidades en el modelo relacional, se especificarán aparte indicando la tabla a la que hacen referencia. Entidades fuertes En el esquema lógico se debe crear una tabla para cada entidad fuerte, incluyendo todos sus atributos simples con cardinalidad máxima 1. De los atributos compuestos con cardinalidad máxima 1 incluir sólo sus componentes. Cada atributo con cardinalidad máxima n se incluirá como una tabla dentro de la tabla correspondiente a la entidad. Si el atributo es simple, la tabla interna tendrá una sola columna; si el atributo es compuesto, la tabla interna tendrá tantas columnas como componentes tenga éste. Cada uno de los identificadores de la entidad será una clave candidata. De entre las claves candidatas hay que escoger la clave primaria; el resto serán claves alternativas. Para escoger la clave primaria entre las claves candidatas se puede seguir las siguientes indicaciones: Escoger la clave candidata que tenga menos atributos. Escoger la clave candidata cuyos valores no tengan probabilidad de cambiar en el futuro. Escoger la clave candidata cuyos valores no tengan probabilidad de perder la unicidad en el futuro. Escoger la clave candidata con el mínimo número de caracteres (si es de tipo cadena). Escoger la clave candidata más fácil de utilizar desde el punto de vista de los usuarios. Ejemplo 1 Entidad fuerte con atributos. El diagrama de la figura 2 contiene los datos de interés de los libros de una biblioteca: título (formado por un título principal y el subtítulo), ISBN, editorial, autores, idioma en que está escrito y ediciones (cada edición tiene un número y se ha publicado en un año). Figura 2 Entidad con atributos El esquema lógico correspondiente es el siguiente: Entidades débiles En el esquema lógico se debe crear una tabla para cada entidad débil, teniendo en cuenta todos sus atributos tal y como se ha hecho con las entidades fuertes. Una entidad débil participa en una relación con la entidad fuerte de la que depende y la cardinalidad con la que participa será siempre «(1,1)»: cada ocurrencia de la entidad débil se relaciona con una y sólo una ocurrencia de la entidad fuerte, de la que necesita para identificarse. Por el hecho de participar de este modo en la relación y por ser débil, a la tabla que le corresponde se le debe añadir una clave ajena a la tabla de la entidad fuerte de la que depende. Para ello, se incluye la clave primaria de la tabla que representa a la entidad fuerte (padre) en la nueva tabla creada para la entidad débil. A continuación, se debe determinar la clave primaria de la nueva tabla. Ejemplo 2 Entidad débil con atributos. Figura 3 Ejemplo de identificador de entidad débil El esquema lógico correspondiente es el siguiente: Relaciones binarias Una relación binaria es aquella en la que participan dos entidades, o bien una sola entidad cuyas ocurrencias se relacionan entre ellas (autor relación). En los diagramas entidad- relación, para cada entidad, se especifica la cardinalidad con la que participa en cada relación. Según sean las cardinalidades máximas, las relaciones binarias se clasifican como se especifica a continuación: Uno a uno: ambas entidades participan con cardinalidad máxima 1. Si una participa de forma opcional y la otra lo hace de manera obligatoria, esta última es considerada la entidad hija, mientras que la primera es la entidad madre. Uno a muchos: una entidad participa con cardinalidad máxima 1 (será la entidad hija) mientras que la otra lo hace con cardinalidad máxima n (será la entidad madre). Muchos a muchos: ambas entidades participan con cardinalidad máxima n. En función del tipo de relación, hay distintas posibilidades para representarlas en el esquema lógico. Relaciones binarias uno a uno Antes de transformar las relaciones uno a uno, es preciso revisarlas, ya que es posible que se hayan identificado dos entidades que representen el mismo concepto, pero con nombres diferentes (sinónimos). Si así fuera, ambas entidades deben integrarse en una sola, y después debe obtenerse la tabla correspondiente. Hay dos formas distintas de representar, en el esquema lógico, una relación binaria uno a uno entre entidades fuertes. Una vez obtenidas las tablas correspondientes a las entidades participantes en la relación las opciones son: (a) Incluir en una de las tablas (sólo en una de ellas) una clave ajena a la otra tabla. Esta clave ajena será, a su vez, una clave alternativa, ya que cada ocurrencia de un lado sólo puede relacionarse con una ocurrencia del otro lado y viceversa. Además, se deben incluir en la misma tabla los atributos de la relación. La clave ajena aceptará nulos o no, en función de la cardinalidad mínima con la que participe la entidad correspondiente en la relación: si es 0, la participación es opcional por lo que debe aceptar nulos; si es 1, la participación es obligatoria y no debe aceptarlos. Los atributos de la relación que se han incluido en la tabla sólo aceptarán nulos si son opcionales, o bien, cuando la clave ajena deba aceptar nulos (participación opcional). (b) Crear una nueva tabla para almacenar las ocurrencias de la relación. Esta tabla contendrá una clave ajena a cada una de las tablas correspondientes a las entidades participantes, además de incluir los atributos de la relación. Ninguna de las claves ajenas aceptará nulos, ya que la tabla almacena ocurrencias de la relación. Además, ambas claves ajenas serán claves candidatas: se escogerá una de ellas como clave primaria y la otra quedará como clave alternativa. Si la relación corresponde a una entidad débil con la entidad fuerte de la que depende, lo único que se debe hacer es añadir los atributos de la relación (si los tiene), a la tabla de la entidad débil, puesto que ésta ya contiene la clave ajena a la tabla de la entidad fuerte, que además de ayudarle a identificarse (será una clave candidata), expresa la relación. Cuando se tiene una relación binaria uno a uno entre una entidad débil y una fuerte, puede ser conveniente plantearse la posibilidad de integrar las dos entidades en una sola, como si se tratara de sinónimos. Ejemplo 3 Relación uno a uno. El diagrama de la figura 4 contiene información de los empleados (código y nombre), de los vehículos que éstos conducen (matrícula y modelo) y desde cuando lo hacen. Figura 4 Relación de uno a uno A continuación, se muestran tres posibles esquemas lógicos correspondientes a este diagrama: (a.1) Puesto que la entidad de los vehículos participa de forma obligatoria en la relación, puede considerarse entidad hija (todas sus ocurrencias están relacionadas con algún empleado), introduciéndose en ella la relación: (a.2) Aunque la entidad de los vehículos es la entidad hija, al ser una relación uno a uno, también es posible incluir la relación en la entidad de los empleados. Esto puede ser conveniente cuando se sabe que los accesos de una tabla a la otra se van a hacer siempre en la misma dirección, de EMPLEADO a VEHÍCULO: Nótese que, por el hecho de participar de manera opcional en la relación, la clave ajena y el atributo de la relación deben aceptar nulos, y que ambos deben ser nulos o no nulos a la vez. Esta restricción se puede expresar sin ambigüedad en forma de predicado SQL: (b) Otro modo de representar la relación es mediante una tabla aparte: Nótese que ninguna de las claves ajenas acepta nulos, aun habiendo una entidad que participa de manera opcional. Esto es así porque la tabla CONDUCE almacena ocurrencias de una relación, no de una entidad: si la relación no se da para algún empleado, éste no aparece en la tabla. Escoger una u otra opción para representar cada relación uno a uno dependerá, en gran medida, de cómo se va a acceder a las tablas y del número de ocurrencias de las entidades que van a participar en la relación. Se tratará siempre de favorecer los accesos más frecuentes y que requieran un tiempo de respuesta menor. Por ejemplo, en el esquema (a.1) dar de alta un vehículo conlleva ejecutar una sola sentencia INSERT en la tabla VEHÍCULO, mientras que hacerlo en los esquemas (a.2) y (b) conlleva ejecutar dos sentencias (un INSERT y un UPDATE, o dos INSERT). Sin embargo, en estos dos últimos esquemas, un recorrido completo de la tabla VEHÍCULO para obtener la matrícula y el modelo es más rápido puesto que cada fila almacena menos datos. Por otra parte, mantener la restricción de que todo vehículo debe estar relacionado con algún empleado (con la fecha de inicio), es trivial en el esquema (a.1) exigiendo que ambos atributos no acepten nulos, mientras que hacerlo en los otros dos esquemas requiere el uso de transacciones. En resumen, cada esquema será más conveniente para ciertos tipos de accesos, por lo que se tratará de favorecer aquellos que sean críticos. Relaciones binarias uno a muchos Cuando la relación entre dos entidades fuertes es de uno a muchos, sigue habiendo dos modos de representarla en el esquema lógico: mediante una clave ajena o mediante una tabla aparte; aunque el modo de hacerlo varía respecto a las relaciones de uno a uno, tal y como se muestra a continuación: (a) Incluir en la tabla hija (aquella cuya entidad participa con cardinalidad máxima 1) una clave ajena a la tabla madre, junto con los atributos de la relación. La clave ajena aceptará nulos o no, en función de la cardinalidad mínima con la que participe la entidad hija en la relación: si es 0, la participación es opcional por lo que debe aceptar nulos; si es 1, la participación es obligatoria y no debe aceptarlos. Los atributos de la relación que se han incluido en la tabla sólo aceptarán nulos si son opcionales, o bien cuando la clave ajena deba aceptar nulos (participación opcional). (b) Crear una nueva tabla para almacenar las ocurrencias de la relación. Esta tabla contendrá una clave ajena a cada una de las tablas correspondientes a las entidades participantes, además de incluir los atributos de la relación. Ninguna de las claves ajenas aceptará nulos, ya que la tabla almacena ocurrencias de la relación. La clave primaria será la clave ajena a la tabla correspondiente a la entidad hija, ya que cada ocurrencia de ésta sólo puede aparecer una vez en la tabla. Si la relación corresponde a una entidad débil con la entidad fuerte de la que depende, lo único que se debe hacer es añadir los atributos de la relación (si los tiene), a la tabla de la entidad débil, puesto que ésta ya contiene la clave ajena a la tabla de la entidad fuerte, que además de ayudarle a identificarse (formará parte de su clave primaria), expresa la relación. Ejemplo 4 Relación uno a muchos. El diagrama de la figura 5 contiene información de los profesores (código y nombre) y de los estudiantes (código y nombre). Algunos profesores tutorizan estudiantes y cada estudiante sólo puede ser tutorizado por un profesor. Figura 5 Relación de uno a muchos A continuación, se muestran los dos posibles esquemas lógicos correspondientes a este diagrama: Relaciones binarias muchos a muchos Para las relaciones binarias de muchos a muchos la única opción que existe es crear una tabla aparte para almacenar las ocurrencias de la relación. Esta tabla contendrá una clave ajena a cada una de las tablas correspondientes a las entidades participantes, además de incluir los atributos de la relación. Ninguna de las claves ajenas aceptará nulos. La clave primaria de esta tabla se determina en función de que la relación tenga o no atributos: (a) Si la relación no tiene atributos, la clave primaria está formada por las dos claves ajenas (será una clave primaria compuesta). (b) Si la relación tiene atributos, la clave primaria depende del significado de la relación. No hay que olvidar que las claves candidatas de una tabla son restricciones que sus filas deben cumplir (sus valores no se pueden repetir) y, por lo tanto, será el significado de la relación (qué relaciones se pueden dar y cuáles no) el que nos ayudará a determinar las claves candidatas y, a partir de ellas, la clave primaria. Ejemplo 5 Relación muchos a muchos. El diagrama de la figura 6 contiene información de los médicos (código y nombre) y de los pacientes (código y nombre) de un centro médico, con información de las citas que éstos tienen concertadas. Se debe tener en cuenta que un paciente puede tener concertadas varias citas con el mismo médico. Figura 6 Relación de muchos a muchos A continuación, se muestra el esquema lógico correspondiente al diagrama anterior. Para escoger la clave primaria de la tabla CITA se deben buscar antes las claves candidatas, que dependerán del significado de la relación: (codmed, fecha, hora) es una clave candidata, porque un médico no puede tener más de una cita el mismo día a la misma hora. (codpac, fecha, hora) es una clave candidata, porque un paciente no puede tener más de una cita el mismo día a la misma hora. Nótese que (codmed, codpac) no es una clave candidata, ya que un mismo paciente puede tener varias citas con un mismo médico. Jerarquías de generalización En las jerarquías se denomina entidad madre, a la entidad genérica, y entidades hijas, a las subentidades. Hay tres opciones distintas para representar las jerarquías. La elección de la más adecuada se hará en función de su tipo (total o parcial, y exclusiva o superpuesta) y del tipo y frecuencia en los accesos a los datos. Estas opciones se presentan a continuación: (a) Crear una tabla por cada entidad (madre e hijas). Las tablas de las entidades hijas heredan como clave primaria la clave primaria de la entidad madre. La clave primaria de las hijas es una clave ajena a la entidad madre. Esta representación se puede hacer para cualquier tipo de jerarquía, ya sea total o parcial, o exclusiva o superpuesta. (b) Crear una tabla por cada entidad hija, heredando cada una los atributos de la entidad madre. Esta representación sólo puede hacerse para jerarquías totales y exclusivas. (c) Integrar todas las entidades en una sola tabla, incluyendo en ella los atributos de la entidad madre, los atributos de todas las hijas y un atributo discriminativo para indicar el subconjunto al cual pertenece la entidad en consideración. Esta representación se puede utilizar para cualquier tipo de jerarquía. Si la jerarquía es superpuesta, el atributo discriminativo deberá ser multievaluado o bien se deberá incluir uno de estos atributos por cada subentidad. Ejemplo 6 Jerarquía de generalización. Figura 7 Ejemplo de jerarquía de generalización A continuación, se muestran los tres posibles esquemas lógicos correspondientes al diagrama anterior. Una vez obtenidas las tablas con sus atributos, claves primarias, claves alternativas y claves ajenas, deben normalizarse. La normalización se utiliza para mejorar el esquema lógico, de modo que satisfaga ciertas restricciones que eviten la duplicidad de datos. La normalización garantiza que el esquema resultante se encuentra más próximo al modelo de la empresa, que es consistente y que tiene la mínima redundancia y la máxima estabilidad. 3.3. Esquema de la base de datos Un esquema de base de datos representa la configuración lógica de todo o parte de una base de datos relacional. Puede existir de dos formas: como representación visual y como un conjunto de fórmulas conocidas como restricciones de integridad que controlan una base de datos. Estas fórmulas se expresan en un lenguaje de definición de datos, tal como SQL. Como parte de un diccionario de datos, un esquema de base de datos indica cómo las entidades que conforman la base de datos se relacionan entre sí, incluidas las tablas, las vistas, los procedimientos almacenados y mucho más. Restricciones de integridad La definición de las restricciones de integridad se lleva a cabo en la etapa del diseño lógico. Las restricciones son reglas que se quiere imponer para proteger la base de datos, de modo que no pueda llegar a un estado inconsistente en el que los datos no reflejen la realidad o sean contradictorios. Hay cinco tipos de restricciones de integridad. A. Datos requeridos. Algunos atributos deben contener valores en todo momento, es decir, no admiten nulos. B. Restricciones de dominios. Todos los atributos tienen un dominio asociado, que es el conjunto de valores que cada atributo puede tomar. C. Integridad de entidades. El identificador de una entidad no puede ser nulo, por lo tanto, las claves primarias de las tablas no admiten nulos. D. Integridad referencial. Una clave ajena enlaza cada fila de la tabla hija con la fila de la tabla madre que tiene el mismo valor en su clave primaria. La integridad referencial dice que si una clave ajena tiene valor (si es no nula), ese valor debe ser uno de los valores de la clave primaria a la que hace referencia. Hay varios aspectos a tener en cuenta sobre las claves ajenas para lograr que se cumpla la integridad referencial:  1. ¿Admite nulos la clave ajena? Cada clave ajena expresa una relación. Si la participación de la entidad hija en la relación es obligatoria (cardinalidad mínima 1), entonces la clave ajena no admite nulos; si es opcional (cardinalidad mínima 0), la clave ajena debe aceptar nulos. 2. ¿Qué hacer cuando se quiere borrar una ocurrencia de la entidad madre que tiene alguna hija? Esto es lo mismo que preguntarse qué hacer cuando se quiere borrar una fila que está siendo referenciada por otra fila a través de una clave ajena. Hay varias respuestas posibles: Restringir: no se pueden borrar filas que están siendo referenciadas por otras filas. Propagar: se borra la fila deseada y se propaga el borrado a todas las filas que le hacen referencia. Anular: se borra la fila deseada y todas las referencias que tenía se ponen, automáticamente, a nulo (esta opción sólo es válida si la clave ajena acepta nulos). Valor por defecto: se borra la fila deseada y todas las referencias toman, automáticamente, el valor por defecto (esta opción sólo es válida si se ha especificado un valor por defecto para la clave ajena). 3. ¿Qué hacer cuando se quiere modificar la clave primaria de una fila que está siendo referenciada por otra fila a través de una clave ajena? Las respuestas posibles son las mismas que en el caso anterior. Cuando se escoge propagar, se actualiza la clave primaria en la fila deseada y se propaga el cambio a los valores de clave ajena que le hacían referencia. E. Restricciones y reglas de negocio. Cualquier operación que se realice sobre los datos debe cumplir las restricciones y las reglas que impone el funcionamiento de la empresa. Hablamos de restricciones cuando se dan ciertas condiciones que no deben violarse y hablamos de reglas de negocio cuando se requiere la ejecución automática de ciertas acciones ante determinados eventos. Todas las restricciones de integridad establecidas en este paso se deben reflejar en la documentación del esquema lógico para que puedan ser tenidas en cuenta durante la fase del diseño físico. Referencias bibliográficas Elizabeth Pulido Romero, Óscar Escobar Domínguez y José Ángel Núñez Pérez. Base de datos. Ciudad de México: Grupo Editorial Patria, 2019. eLibro. Marqués, Mercedes. 2024. Bases de datos. Castelló de la Plana: D - Universitat Jaume I. Servei de Comunicació i Publicacions, 2009. eLibro