Introduccion Al Diseño De Bases De Datos.docx

2 Introducción al diseño de bases de datos ¿Cuáles son los pasos para diseñar una base de datos? ¿Por qué se utiliza el modelo ER para crear un diseño inicial? ¿Cuáles son los principales conceptos en el modelo ER? ¿Cuáles son las pautas para usar el modelo ER de manera efectiva? ¿Cómo encaja el diseño de la base de datos dentro del marco general de diseño para software complejo dentro de grandes empresas? ¿Qué es UML y cómo se relaciona con el modelo ER?

Conceptos clave: diseño de bases de datos, diseño conceptual, lógico y físico; modelo entidad-relación (ER), conjunto de entidades, conjunto de relaciones, atributo, instancia, clave; restricciones de integridad, relaciones de uno a muchos y de muchos a muchos, restricciones de participación; Entidades débiles, jerarquías de clases, agregación; UML, diagramas de clase, clataba, se diagramas, diagramas de componentes.

Los grandes hombres exitosos del mundo han usado su imaginación. Piensan de antemano y crean su imagen mental. y luego vaya a trabajar materializando esa imagen en todos sus detalles, completando aquí, agregando un poco allí, alterando este bit y ese bit, pero construyendo constantemente, construyendo constantemente. Robert Collier

El modelo de datos (entidad-relación (ER) nos permite describir los datos involucrados en una empresa del mundo real en términos de objetos y sus relaciones y se utiliza ampliamente para desarrollar un diseño de base de datos inicial. Proporciona conceptos útiles que nos permiten Pase de una descripción informal de lo que los usuarios desean de su base de datos a una descripción más detallada y precisa que se pueda implementar en un DBMS. En este capítulo, presentamos el modelo ER y discutimos cómo sus características nos permiten modelar una amplia gama de datos fielmente. Comenzamos con una descripción general del diseño de la base de datos en la Sección 2.1 para motivar nuestra discusión del modelo ER. En el contexto más amplio del proceso de diseño general, el modelo ER se utiliza en una fase llamada diseño conceptual de base de datos. Luego introducimos el modelo ER en las Secciones 2.2, 2.3 y 2.4. En la Sección 2.5, discutimos problemas de diseño de bases de datos que involucran el modelo ER. Discutimos brevemente el diseño conceptual de la base de datos para grandes empresas en la Sección 2.6. En la Sección 2.7, presentamos una descripción general de UML, un enfoque de diseño y modelado que es más general en su alcance que el modelo ER.

En la Sección 2.8, presentamos un estudio de caso que se utiliza como un ejemplo de ejecución en todo el libro. El estudio de caso es un diseño de base de datos de extremo a extremo para una tienda de Internet. Ilustramos los dos primeros pasos en el diseño de la base de datos (análisis de requisitos y diseño conceptual) en la Sección 2.8. En capítulos posteriores, extendemos este estudio de caso para cubrir los pasos restantes en el proceso de diseño.

Notamos que muchas variaciones de los diagramas ER están en uso y no prevalecen estándares ampliamente aceptados. La presentación en este capítulo es representativa de la familia de modelos ER e incluye una selección de las características más populares.

2.1 DISEÑO DE BASE DE DATOS Y DIAGRAMAS DE ER. Comenzamos nuestra discusión sobre el diseño de bases de datos observando que esto es típicamente solo una parte, aunque es una parte central en aplicaciones de uso intensivo de datos, de un diseño de sistema de software más grande. Sin embargo, nuestro enfoque principal es el diseño de la base de datos, y no discutiremos otros aspectos del diseño del software en detalle. Revisamos este punto en la Sección 2.7.

El proceso de diseño de la base de datos se puede dividir en seis pasos. El modelo ER es más relevante para los primeros tres pasos. 1. Análisis de requisitos: el primer paso para diseñar una aplicación de base de datos es comprender qué datos se almacenarán en la base de datos, qué aplicaciones deben construirse sobre ella y qué operaciones son más frecuentes y están sujetas a requisitos de rendimiento. En otras palabras, debemos averiguar qué quieren los usuarios de la base de datos. Este suele ser un proceso informal que involucra discusiones con grupos de usuarios, un estudio del entorno operativo actual y cómo se espera que cambie, análisis de cualquier documentación disponible sobre aplicaciones existentes que se espera que sean reemplazadas o complementadas por la base de datos, y así en. Se han propuesto varias metodologías para organizar y presentar la información recopilada en este paso, y se han desarrollado algunas herramientas automatizadas para respaldar este proceso. 2. Diseño conceptual de la base de datos: la información recopilada en el paso de análisis de requisitos se utiliza para desarrollar una descripción de alto nivel de los datos que se almacenarán en la base de datos, junto con las restricciones que se sabe que existen sobre estos datos. Este paso a menudo se lleva a cabo utilizando el modelo ER y se analiza en el resto de este capítulo. El modelo ER es uno de varios modelos de datos de alto nivel o semánticos utilizados en el diseño de bases de datos. El objetivo es crear una descripción simple de los datos que coincida estrechamente con la forma en que los usuarios y los desarrolladores piensan en los datos (y las personas y los procesos que se representarán en los datos). Esto facilita la discusión entre todas las personas involucradas en el proceso de diseño, incluso aquellas que no tienen experiencia técnica. Al mismo tiempo, el diseño inicial

debe ser lo suficientemente preciso para permitir una traducción directa a un modelo de datos respaldado por un sistema de base de datos comercial (que, en la práctica, significa el modelo relacional). 3. Diseño de base de datos lógica: debemos elegir un DBMS (Sistemas de Gestión de Bases de Datos (SGBD)) para implementar nuestro diseño de base de datos y convertir el diseño conceptual de la base de datos en un esquema de base de datos en el modelo de datos del DBMS elegido. Consideraremos solo los DBMS relacionales y, por lo tanto, la tarea en el paso de diseño lógico es convertir un esquema ER en un esquema de base de datos relacional. Discutimos este paso en detalle en el Capítulo 3; el resultado es un esquema conceptual, a veces denominado esquema lógico, en el modelo de datos relacionales.

2.1.1 Más allá del diseño de ER. El diagrama ER es solo una descripción aproximada de los datos, construida a través de una evaluación subjetiva de la información recopilada durante el análisis de requisitos. Un análisis más cuidadoso a menudo puede refinar el esquema lógico obtenido al final del Paso 3. Una vez que tenemos un buen esquema lógico, debemos considerar los criterios de rendimiento y diseñar el esquema físico. Finalmente, debemos abordar los problemas de seguridad y garantizar que los usuarios puedan acceder a los datos que necesitan, pero no a los datos que deseamos ocultarles. Los tres pasos restantes del diseño de base de datos se describen brevemente a continuación: 4. Refinamiento del esquema: el cuarto paso en el diseño de la base de datos es analizar la recopilación de relaciones en nuestro esquema de base de datos relacional para identificar problemas potenciales y refinarlo. En contraste con el análisis de requisitos y los pasos de diseño conceptual, que son esencialmente subjetivos, el refinamiento del esquema puede guiarse por alguna teoría elegante y poderosa. Discutimos la teoría de normalizar las relaciones (reestructurándolas para garantizar algunas propiedades deseables) en el Capítulo 19. 5. Diseño físico de la base de datos: en este paso, consideramos las cargas de trabajo típicas esperadas que nuestra base de datos debe admitir y refinar aún más el diseño de la base de datos para garantizar que cumpla con los criterios de rendimiento deseados. Este paso puede implicar simplemente la creación de índices en algunas tablas y agrupar algunas tablas, o puede implicar un rediseño sustancial de partes del esquema de base de datos obtenido de los pasos de diseño anteriores. Discutimos el diseño físico y el ajuste de la base de datos en el Capítulo 20. 6. Diseño de aplicaciones y seguridad: cualquier proyecto de software que involucre un DBMS debe considerar aspectos de la aplicación que van más allá de la base de datos en sí. Las metodologías de diseño como UML (Sección 2.7) tratan de abordar el ciclo completo de diseño y desarrollo del software. Brevemente, debemos identificar las entidades (por ejemplo, usuarios, grupos de usuarios, departamentos) y los procesos involucrados en la aplicación. Debemos describir el rol de cada entidad en cada proceso que se refleja en alguna tarea de la aplicación, como parte de un flujo de trabajo completo para esa tarea. Para cada función, debemos identificar las partes de la base de datos que deben ser accesibles y las partes de la base de datos que no deben ser accesibles, y debemos tomar medidas para

garantizar que estas reglas de acceso se cumplan. Un DBMS proporciona varios mecanismos para ayudar en este paso, y lo analizamos en el Capítulo 21. En la fase de implementación, debemos codificar cada tarea en un lenguaje de aplicación (por ejemplo, Java), usando el DBlVIS para acceder a los datos. Discutimos el desarrollo de aplicaciones en los capítulos 6 y 7. En general, nuestra división del proceso de diseño en pasos debe verse como una clasificación de los tipos de pasos involucrados en el diseño. De manera realista, aunque podríamos comenzar con el proceso de seis pasos descrito aquí, un diseño completo de la base de datos probablemente requerirá una fase de ajuste posterior en la que los seis tipos de pasos de diseño se intercalan y repiten hasta que el diseño sea satisfactorio.

2.2 ENTIDADES, ATRIBUTOS, Y CONJUNTOS DE ENTIDADES Una entidad es un objeto en el mundo real que se distingue de otros objetos. Los ejemplos incluyen los siguientes: el juguete Green Dragonzord, el departamento de juguetes, el gerente del departamento de juguetes, la dirección de la casa del gerente del departamento de juguetes. A menudo es útil identificar una colección de entidades similares. Tal colección se llama un conjunto de entidades. Tenga en cuenta que los conjuntos de entidades no necesitan ser desarticulados; la colección de empleados del departamento de juguetes y la colección de empleados del departamento de electrodomésticos pueden contener al empleado John Doe (que trabaja en ambos departamentos). También podríamos definir un conjunto de entidades llamado Empleados que contenga los conjuntos de empleados del departamento de juguetes y de dispositivos. Una entidad se describe utilizando un conjunto de atributos. Todas las entidades en un conjunto de entidades dado tienen los mismos atributos; esto es lo que entendemos por similar. (Esta declaración es una simplificación excesiva, como veremos cuando analicemos las jerarquías de herencia en la Sección 2.4.4, pero es suficiente por ahora y resalta la idea principal). Nuestra elección de atributos refleja el nivel de detalle en el que deseamos representar la información. sobre las entidades. Por ejemplo, el conjunto de entidades Empleados podría usar el nombre, el número de seguro social (ssn) y el estacionamiento (lote) como atributos. En este caso, almacenaremos el nombre, el número de seguro social y el número de lote de cada empleado. Sin embargo, no almacenaremos, digamos, la dirección de un empleado (o el sexo o la edad). Para cada atributo asociado con un conjunto de entidades, debemos identificar un dominio de valores posibles. Por ejemplo, el dominio asociado con el nombre de atributo de Empleados podría ser el conjunto de cadenas de 20 caracteres. Como otro ejemplo, si la compañía califica a los empleados en una escala de 1 a 10 y almacena las calificaciones en un campo llamado mting, el dominio asociado consiste en números enteros del 1 al 10. Además, para cada conjunto de entidades, elegimos una clave. Una clave es un conjunto mínimo de atributos cuyos valores identifican de forma única una entidad en el conjunto. Podría haber más de una clave candidata; Si es así, designamos a uno de ellos como la clave principal. Por ahora, asumimos que cada conjunto de entidades contiene al menos un conjunto de atributos que identifica de forma única a

una entidad en el conjunto de entidades; es decir, el conjunto de atributos contiene una clave. Revisamos este punto en la Sección 2.4.3. El conjunto de entidades Empleados con atributos ssn, nombre y lote se muestra en la Figura 2.1. Un conjunto de entidades está representado por un rectángulo, y un atributo está representado por un óvalo. Cada atributo en la clave primaria está subrayado. La información del dominio podría aparecer junto con el nombre del atributo, pero omitimos esto para mantener las cifras compactas. La clave es ssn.

2.3 RELACIONES Y CONJUNTOS DE RELACIONES Una relación es una asociación entre dos o más entidades. Por ejemplo, podemos tener la relación que Attishoo trabaja en el departamento de farmacia.

Al igual que con las entidades, se puede desear recopilar un conjunto de relaciones similares en un conjunto de relaciones. Un conjunto de relaciones puede considerarse como un conjunto de n-tuplas:

{(e1, ..., en) | e1 ϵ E1, ..., en ϵ En } Cada n-tupla denota una relación que involucra n entidades e1 a través de en, donde la entidad ei está en el conjunto de entidades Ei. En la Figura 2.2 mostramos el conjunto de relaciones Trabaja_en, en el que cada relación indica un departamento en el que trabaja un empleado. Tenga en cuenta que varios conjuntos de relaciones pueden

implicar los mismos conjuntos de entidades. Por ejemplo, también se podría tener un conjunto de relaciones manejadas con empleados y departamentos.

Una relación también puede tener atributos descriptivos. Los atributos descriptivos se utilizan para registrar información sobre la relación, en lugar de sobre cualquiera de las entidades participantes; por ejemplo, podemos desear registrar que Attishoo trabaja en el departamento de farmacia a partir de enero de 1991. Esta información se captura en la Figura 2.2 agregando un atributo, ya que, a Trabaja_en. Una relación debe ser identificada de manera única por las entidades participantes, sin hacer referencia a los atributos descriptivos. En el conjunto de relaciones Trabaja_en, por ejemplo, cada relación Trabaja_en debe identificarse de forma única mediante la combinación de SSN de empleado y el id de departamento. Por lo tanto, para un determinado par empleadodepartamento, no podemos tener más de uno asociado desde el valor. Una instancia de un conjunto de relaciones es un conjunto de relaciones. Intuitivamente, una instancia puede considerarse como una 'instantánea' de la relación establecida en algún momento en el tiempo. En la Figura 2.3 se muestra una instancia del conjunto de relaciones Trabaja_en. Cada entidad de los empleados se denota por su número de serie, y cada entidad de los departamentos se denota por su carácter de simplicidad. El valor desde se muestra al lado de cada relación. (Los comentarios de "muchos a muchos" y "participación total" en la figura se discuten más adelante, cuando analizamos las restricciones de integridad).

Como otro ejemplo de un diagrama de ER, suponga que cada departamento tiene oficinas en varias ubicaciones y queremos registrar las ubicaciones en las que trabaja cada empleado. Esta relación es ternaria porque debemos registrar una asociación

entre un empleado, un departamento y una ubicación. El diagrama ER para esta variante de Trabaja_en, que llamamos Trabaja_en2, se muestra en la Figura 2.4.

Los conjuntos de entidades que participan en un conjunto de relaciones no necesitan ser distintos; a veces una relación puede involucrar dos entidades en el mismo conjunto de entidades. Por ejemplo, considere el conjunto de relaciones Reports_To que se muestra en la Figura 2.5. Dado que los empleados informan a otros empleados, todas las relaciones en Reports_To son de la forma (emp1, emp2), donde tanto empl como empz son entidades en Employees. Sin embargo, desempeñan diferentes roles: los informes de los empleados al empleado de administración emp2, que se refleja en los indicadores de rol supervisor y subordinado en la Figura 2.5. Si un conjunto de entidades juega más de un rol, el indicador de rol concatenado con un nombre de atributo del conjunto de entidades nos da un nombre único para cada atributo en el conjunto de relaciones. Por ejemplo, el conjunto de relaciones Reports_To tiene atributos correspondientes a la ssn del supervisor y a la ssn del subordinado, y los nombres de estos atributos son supervisor_ssn y subordinate-ssn.

2.4 CARACTERÍSTICAS ADICIONALES DEL MODELO ER Ahora observamos algunas de las construcciones en el modelo ER que nos permiten describir algunas propiedades sutiles de los datos. La expresividad del modelo ER es una gran razón para su difusión generalizada.

2.4.1 Restricciones clave Considere la relación Works-.In que se muestra en la Figura 2.2. Un empleado puede trabajar en varios departamentos, y un departamento puede tener varios empleados, &., Ilustrados en la instancia de Works_In que se muestra en la Figura 2.3. El empleado 231-31-5368 ha trabajado en el Departamento 51 desde el 3/3/93 y en el Departamento 56 desde el 2/2/92. El departamento 51 tiene dos empleados. Ahora considere otro conjunto de relaciones llamado Administraciones entre los conjuntos de entidades Empleados y Departamentos de tal manera que cada departamento tenga a lo sumo un gerente, aunque un solo empleado puede administrar más de un departamento. La restricción que cada departamento tiene a lo más un administrador es un ejemplo de una restricción clave, e implica que cada entidad de

Departamentos aparece como máximo en una relación de Administradores en cualquier instancia permitida de Administraciones. Esta restricción se indica en el diagrama de ER de la Figura 2.6 utilizando una flecha de Departamentos a Administradores. Intuitivamente, la flecha indica que, dada una entidad de Departamentos, podemos determinar de forma única la relación de Administradores en la que aparece. En la Figura 2.7 se muestra una instancia del conjunto de relaciones Administrativas. Si bien esta también es una instancia potencial para el conjunto de relaciones Works_In, la instancia de Works_In que se muestra en la Figura 2.3 viola la restricción clave en Administraciones.

A veces se dice que una relación establecida como Administradores es de uno a muchos, para indicar que un empleado puede asociarse con muchos departamentos (en calidad de gerente), mientras que cada departamento puede asociarse con un empleado como máximo como administrador. En contraste, el conjunto de relaciones Trabaja_en, en el que un empleado puede trabajar en varios departamentos y un departamento puede tener varios empleados, se dice que es de muchos a muchos. Si se agrega la restricción que cada empleado puede administrar, como máximo, un departamento al conjunto de relaciones de Administraciones, que se indicaría al agregar una flecha de Empleados a Administraciones en la Figura 2.6, tenemos un conjunto de relaciones de uno a uno. Limitaciones clave para las relaciones ternarias.

Podemos extender esta convención, y el concepto de restricción de clave subyacente, a los conjuntos de relaciones que incluyen tres o más conjuntos de entidades: si un conjunto de entidades E tiene una restricción clave en un conjunto de relaciones R, cada entidad en una instancia de E aparece como máximo una relación en (una instancia correspondiente de) R. Para indicar una restricción clave en el conjunto de entidades E en el conjunto de relaciones R, dibujamos una flecha de E a R. En la Figura 2.8, mostramos una relación ternaria con restricciones clave. Cada empleado trabaja como máximo en un departamento y en una sola ubicación. En la Figura 2.9 se muestra una instancia del conjunto de relaciones Trabaja_en3. Tenga en cuenta que cada departamento puede asociarse con varios empleados y ubicaciones, y cada ubicación puede asociarse con varios departamentos y empleados; sin embargo, cada empleado está asociado con un solo departamento y ubicación.

2.4.2 Restricciones de participación La restricción clave en Administraciones nos dice que un departamento tiene a lo más un administrador. Una pregunta natural es si cada departamento tiene un gerente. Digamos que cada departamento debe tener un gerente. Este requisito es un ejemplo de una restricción de participación; la participación del conjunto de entidades Departamentos en el conjunto de relaciones Gestiones se dice que es total. Una participación que no es total se dice que es parcial. Como ejemplo, la participación del conjunto de entidades Empleados en administraciones es parcial, ya que no todos los empleados pueden administrar un departamento. Revisando el conjunto de relaciones Works_ln, es natural esperar que cada empleado trabaje en al menos un departamento y que cada departamento tenga al menos un empleado. Esto significa que la participación tanto de los empleados como de los departamentos en Works_ln es total. El diagrama de ER en la Figura 2.10 muestra los conjuntos de relaciones de Manages y Works_ln y todas las restricciones dadas. Si la participación de un conjunto de entidades en un conjunto de relaciones es total, los dos están conectados por una línea gruesa; independientemente, la presencia de una flecha indica una restricción clave. Las instancias de Works_In y Manages que se muestran en las Figuras 2.3 y 2.7 satisfacen todas las restricciones en la Figura 2.10.

2.4.3 Entidades débiles Hasta ahora, hemos asumido que los atributos asociados con un conjunto de entidades incluyen una clave. Este supuesto no siempre es válido. Por ejemplo, suponga que los empleados pueden comprar pólizas de seguro para cubrir a sus dependientes. Deseamos registrar información sobre las políticas, incluso quién está cubierto por cada política, pero esta información es realmente nuestro único interés en los dependientes de un empleado. Si un empleado renuncia, se cancela cualquier póliza que pertenezca al empleado y queremos eliminar toda la política relevante e información dependiente de la base de datos.

Podríamos elegir identificar a un dependiente solo por su nombre en esta situación, ya que es razonable esperar que los dependientes de un empleado dado tengan nombres diferentes. Por lo tanto, los atributos del conjunto de entidades Dependientes podrían ser pname y age. El atributo pname no identifica a un dependiente únicamente. Recordemos que la clave para los empleados es ssn; así podríamos tener dos empleados llamados Smethurst y cada uno podría tener un hijo llamado Joe. Dependientes es un ejemplo de un conjunto de entidades débiles. Una entidad débil solo puede identificarse considerando algunos de sus atributos junto con la clave principal de otra entidad, que se denomina propietario identificador. Las siguientes restricciones deben cumplir: 



El conjunto de entidades propietarias y el conjunto de entidades débiles deben participar en un conjunto de relaciones de uno a varios (una entidad propietaria está asociada con una o más entidades débiles, pero cada entidad débil tiene un único propietario). Este conjunto de relaciones se denomina conjunto de relaciones de identificación del conjunto de entidades débiles. El conjunto de entidades débiles debe tener participación total en el conjunto de relaciones de identificación.

Por ejemplo, una entidad Dependientes puede identificarse únicamente si tomamos la clave de la entidad Empleada propietaria y el nombre de la entidad Dependientes. El conjunto de atributos de un conjunto de entidades débiles que identifican de manera única a una entidad débil para una entidad propietaria dada se denomina clave parcial del conjunto de entidades débiles. En nuestro ejemplo, pname es una clave parcial para Dependientes. El conjunto de entidades débiles de los Dependientes y su relación con los Empleados se muestra en la Figura 2.1.1. La participación total de los Dependientes en la Política se indica al vincularlos con una línea oscura. La flecha de los Dependientes a la Política indica que cada entidad Dependientes aparece a lo sumo en una relación de Política (de hecho, exactamente una, debido a la restricción de participación). Para subrayar el hecho de que los Dependientes es una entidad débil y la Política es su relación de identificación, dibujamos ambos con líneas oscuras. Para indicar que pname es una clave parcial para los

Dependientes, lo subrayamos con una línea discontinua. Esto significa que puede haber dos dependientes con el mismo valor pname.

2.4.4 Jerarquías de clase. A veces es natural clasificar las entidades en un conjunto de entidades en subclases. Por ejemplo, podríamos querer hablar sobre un conjunto de entidades de Emperios por hora y un conjunto de entidades ContracLEmps para distinguir la base sobre la cual se les paga. Podríamos tener los atributos hours_worked y hourly_wage definidos para Hourly_Emps y un atributo contractid definido para ContracLEmps. Queremos la semántica de que cada entidad en uno de estos conjuntos también es una entidad de Empleados y, como tal, debe tener definidos todos los atributos de los Empleados. Por lo tanto, los atributos definidos para una entidad Hourly_Emps son los atributos de Employees plus Hourly ~ mps. Decimos que los atributos para el conjunto de entidades Los empleados son heredados por el conjunto de entidades Hourly_Emps y que ISA de Hourly-Emps (lectura es a) Empleados. Además, y en contraste con las jerarquías de clases en lenguajes de programación como C ++, hay una restricción en las consultas sobre las instancias de estos conjuntos de entidades: una consulta que solicita todas las entidades de Empleados también debe considerar todas las entidades Hourly_Emps y ContracLEmps. La figura 2.12 ilustra, la jerarquía de clases. El conjunto de entidades Los empleados también pueden clasificarse utilizando un criterio diferente. Por ejemplo, podríamos identificar un subconjunto de empleados como SenioLEmps. Podemos modificar la Figura 2.12 para reflejar este cambio agregando un segundo nodo ISA como hijo de Empleados y haciendo de SenioLEmps un hijo de este nodo. Cada uno de estos conjuntos de entidades podría ser clasificado más adelante, creando una jerarquía ISA multinivel.

Una jerarquía de clases se puede ver de una de dos maneras: Los empleados están especializados en subclases. La especialización es el proceso de identificar subconjuntos de un conjunto de entidades (la superclase) que comparten alguna característica distintiva. Normalmente, la superclase se define primero, las subclases se definen a continuación, y luego se agregan los atributos específicos de subclase y los conjuntos de relaciones. Hourly_Emps y ContracLEmps son generalizados por los empleados. Como otro ejemplo, dos conjuntos de entidades Motorboats y Cars pueden generalizarse en un conjunto de entidades MotoLVehicles. La generalización consiste en identificar algunas características comunes de una colección de conjuntos de entidades y crear un nuevo conjunto de entidades que contenga entidades que posean estas características comunes. Normalmente, las subclases se definen primero, la superclase se define a continuación, y luego se definen los conjuntos de relaciones que involucran a la superclase.

Podemos especificar dos tipos de restricciones con respecto a las jerarquías de ISA, a saber, las restricciones de superposición y cobertura. Las restricciones de superposición determinan si dos subclases pueden contener la misma entidad. Por ejemplo, ¿puede Attishoo ser tanto una entidad Hourly_Emps como una entidad ContracLEmps? Intuitivamente, no. ¿Puede ser tanto una entidad ContracLEmps como una entidad SeniorEmps? Intuitivamente, sí. Lo denotamos escribiendo 'ContracLEmps OVERLAPS SeniorEmps'. En ausencia de tal declaración, asumimos de manera predeterminada que los conjuntos de entidades están restringidos para que no se superpongan. Las restricciones de cobertura determinan si las entidades en las subclases incluyen colectivamente todas las entidades en la superclase. Por ejemplo, ¿cada entidad de los empleados debe pertenecer a una de sus subclases? Intuitivamente, no. ¿Cada entidad Motor_Vehicles tiene que ser una entidad Motorboats o una entidad Cars? Intuitivamente, sí; una propiedad característica de las jerarquías de generalización es que cada instancia de una superclase es una instancia de una subclase. Lo denotamos escribiendo 'Motorboats And Cars COVER Motor-Vehicles'. En ausencia de tal declaración, asumimos por defecto que no hay restricción de cobertura; Podemos tener vehículos motorizados que no sean lanchas o automóviles. Hay dos razones básicas para identificar subclases (por especialización o generalización): 



Es posible que queramos agregar atributos descriptivos que tengan sentido solo para las entidades en una subclase. Por ejemplo, hourly_wages no tiene sentido para una entidad ContracLEmps, cuyo pago está determinado por un contrato individual. Podríamos querer identificar el conjunto de entidades que participan en alguna relación. Por ejemplo, podríamos desear definir la relación de Administradores de modo que los conjuntos de entidades participantes sean Senior-Emps y Departments, para garantizar que solo los empleados senior puedan ser gerentes. Como otro ejemplo, las lanchas y los automóviles pueden tener diferentes atributos descriptivos (por ejemplo, tonelaje y número de puertas), pero como entidades Motor_Vehicles, deben tener una licencia. La información de la licencia se puede capturar mediante una relación Licensed_To entre Motor_Vehicles y un conjunto de entidades llamado Propietarios.

2.4.5 Agregación. Como se definió hasta ahora, un conjunto de relaciones es una asociación entre conjuntos de entidades. A veces, tenemos que modelar una relación entre una colección de entidades y relaciones. Supongamos que tenemos un conjunto de entidades denominado Proyectos y que cada entidad de Proyectos está patrocinada por uno o más departamentos. El conjunto de relaciones Patrocinadores captura esta información. Un departamento que patrocina un proyecto puede asignar empleados para monitorear el patrocinio. Intuitivamente, los monitores deben ser un conjunto de relaciones que asocien una relación de patrocinadores (en lugar de una entidad de proyectos o departamentos) con una entidad de empleados. Sin embargo, hemos definido relaciones para asociar dos o más entidades.

Para definir un conjunto de relaciones como Monitores, introducimos una nueva característica del modelo ER, llamada agregación. La agregación nos permite indicar que un conjunto de relaciones (identificado a través de un cuadro discontinuo) participa en otro conjunto de relaciones. Esto se ilustra en la Figura 2.13, con un cuadro discontinuo alrededor de los Patrocinadores (y sus conjuntos de entidades participantes) que se utiliza para denotar la agregación. Esto nos permite de manera efectiva tratar a los patrocinadores como un conjunto de entidades con el fin de definir el conjunto de relaciones de monitores. ¿Cuándo debemos usar la agregación? Intuitivamente, lo usamos cuando necesitamos expresar una relación entre relaciones. ¿Pero no podemos expresar relaciones que involucren otras relaciones sin usar la agregación? En nuestro ejemplo, ¿por qué no hacer de los Patrocinadores una relación ternaria? La respuesta es que en realidad hay dos relaciones distintas, Patrocinadores y Monitores, cada uno posiblemente con atributos propios. Por ejemplo, la relación Monitores tiene un atributo hasta que registra la fecha hasta que el empleado es nombrado monitor de patrocinio. Compare este atributo con el atributo de los patrocinadores, que es la fecha en que el patrocinio entró en vigencia. El uso de la agregación frente a una relación ternaria también puede guiarse por ciertas restricciones de integridad, como se explica en la Sección 2.5.4

2.5 DISEÑO CONCEPTUAL CON EL MODELO ER. El desarrollo de un diagrama de ER presenta varias opciones, incluidas las siguientes: ¿Debe un concepto ser modelado como una entidad o un atributo? ¿Debe un concepto ser modelado como una entidad o una relación? ¿Qué arco establecen los conjuntos de relaciones y sus entidades participantes? ¿Debemos utilizar relaciones binarias o ternarias? ¿Debemos utilizar la agregación? Ahora discutimos los temas involucrados en la toma de estas decisiones.

2.5.1 Entidad versus atributo. Al identificar los atributos de un conjunto de entidades, a veces no está claro si una propiedad debe modelarse como un atributo o como un conjunto de entidades (y en relación con el primer conjunto de entidades que utiliza un conjunto de relaciones). Por ejemplo, considere agregar información de dirección al conjunto de entidades Empleados. Una opción es usar una dirección de atributo. Esta opción es apropiada si necesitamos registrar solo una dirección por empleado, y es suficiente pensar en una dirección como una cadena. Una alternativa es crear un conjunto de entidades denominado Direcciones y registrar las asociaciones entre empleados y direcciones mediante una relación (por ejemplo, Dirección_Has). Esta alternativa más compleja es necesaria en dos situaciones: o o

Tenemos que registrar más de una dirección para un empleado. Queremos capturar la estructura de una dirección en nuestro diagrama de ER. Por ejemplo, podemos desglosar una dirección en ciudad, estado, país y código postal, además de una cadena para información de la calle. Al representar una dirección como una entidad con estos atributos, podemos admitir consultas como "Buscar a todos los empleados con una dirección en Madison, WI".

Para otro ejemplo de cuándo modelar un concepto como un conjunto de entidades en lugar de un atributo, considere el conjunto de relaciones (llamado Works_In4) que se muestra en la Figura 2.14.

Se diferencia del conjunto de relaciones Works_In de la Figura 2.2 solo en que tiene atributos desde y hacia, en lugar de desde entonces. Intuitivamente, registra el intervalo durante el cual un empleado trabaja para un departamento. Ahora suponga que es posible que un empleado trabaje en un departamento determinado durante más de un período. Esta posibilidad queda descartada por la semántica del diagrama ER, porque las entidades participantes identifican de manera única la relación (recuérdese de la Sección 2.3). El problema es que queremos registrar varios valores para los atributos descriptivos de cada instancia de la relación Works_ln2. (Esta situación es análoga a querer registrar varias direcciones para cada empleado). Podemos resolver este problema introduciendo un

conjunto de entidades llamado, por ejemplo, Duración, con atributos desde y hasta, como se muestra en la Figura 2.15.

En algunas versiones del modelo ER, los atributos pueden tomar conjuntos como valores. Dada esta característica, podríamos hacer que la Duración sea un atributo de Works_In, en lugar de un conjunto de entidades; asociados a cada relación Works_In, tendríamos un conjunto de intervalos. Este enfoque es quizás más intuitivo que modelar la duración como un conjunto de entidades. No obstante, cuando dichos atributos de valor de conjunto se convierten en el modelo relacional, que no admite atributos de valor de conjunto, el esquema relacional resultante es muy similar al que obtuvimos con respecto a la Duración como un conjunto de entidades.

2.5.2 Entidad versus relación. Considere el conjunto de relaciones llamado Administraciones en la Figura 2.6. Supongamos que a cada gerente de departamento se le asigna un presupuesto discrecional (dpresupuesto), como se muestra en la Figura 2.16, en el que también hemos cambiado el nombre de la relación establecida a Administraciones2.

Dado un departamento, conocemos al gerente, así como la fecha de inicio y el presupuesto del gerente para ese departamento. Este enfoque es natural si asumimos que un gerente recibe un presupuesto discrecional por separado para cada departamento que administra. ¿Pero qué sucede si el presupuesto discrecional es una suma que cubre todos los departamentos administrados por ese empleado? En este caso, cada relación de Administraciones2 que involucra a un empleado dado tendrá el mismo valor en el campo dpresupuesto, lo que lleva a un almacenamiento redundante de la misma información. Otro problema con este diseño es que es engañoso; sugiere que el presupuesto está asociado con la relación, cuando en realidad está asociado con el gerente. Podemos abordar estos problemas mediante la introducción de un nuevo conjunto de entidades denominado Administradores (que puede ubicarse debajo de Empleados en una jerarquía ISA, para demostrar que cada administrador también es un empleado). Los atributos desde y dpresupuesto ahora describen una entidad gestora, según lo previsto. Como variación, mientras que cada gerente tiene un presupuesto, cada gerente puede tener una fecha de inicio diferente (como gerente) para cada departamento. En este caso, dpresupuesto es un atributo de los gerentes, pero ya que es un atributo de la relación establecida entre los gerentes y los departamentos. La naturaleza imprecisa del modelado ER puede dificultar el reconocimiento de las entidades subyacentes, y podríamos asociar atributos con relaciones en lugar de entidades apropiadas. En general, tales errores conducen a un almacenamiento redundante de la misma información y pueden causar muchos problemas. Discutimos la redundancia y sus problemas concomitantes en el Capítulo 19, y presentamos una técnica llamada normalización para eliminar las redundancias de las tablas.

2.5.3 Relaciones binarias versus relaciones ternarias. Considere el diagrama ER que se muestra en la Figura 2.17. Modela una situación en la que un empleado puede poseer varias pólizas, cada póliza puede ser propiedad de varios empleados y cada dependiente puede estar cubierto por varias pólizas.

Supongamos que tenemos los siguientes requisitos adicionales:   

Una póliza no puede ser propiedad conjunta de dos o más empleados. Cada póliza debe ser propiedad de algún empleado. Los dependientes son un conjunto de entidades débiles, y cada entidad dependiente se identifica de forma única al tomar pnombre junto con el ID de política de una entidad de política (que, de manera intuitiva, cubre al dependiente dado).

El primer requisito sugiere que impongamos una restricción clave en las Políticas con respecto a las Cubiertas, pero esta restricción tiene el efecto secundario no deseado de que una política solo puede cubrir a un dependiente. El segundo requisito sugiere que impongamos una restricción de participación total en las políticas. Esta solución es aceptable si cada póliza cubre al menos un dependiente. El tercer requisito nos obliga a introducir una relación de identificación que sea binaria (en nuestra versión de diagramas ER, aunque hay versiones en las que este no es el caso).

Incluso ignorando el tercer requisito, la mejor manera de modelar esta situación es usar dos relaciones binarias, como se muestra en la Figura 2.18.

Este ejemplo realmente tiene dos relaciones con Políticas, y nuestro intento de usar una sola relación ternaria (Figura 2.17) es inapropiado. Sin embargo, hay situaciones en las que una relación asocia inherentemente a más de dos entidades. Hemos visto un ejemplo de este tipo en las Figuras 2,4 y 2.15. Como ejemplo típico de una relación ternaria, considere los conjuntos de entidades, Proveedores y Departamentos, y un conjunto de relaciones de Contratos (con atributo descriptivo cantidad) que involucra a todos ellos. Un contrato especifica que un proveedor suministrará (una cierta cantidad de) una parte a un departamento. Esta relación no puede ser capturada adecuadamente por una colección de relaciones binarias (sin el uso de agregación). Con las relaciones binarias, podemos denotar que un proveedor "puede suministrar" ciertas partes, que un departamento "necesita" algunas partes, o que un departamento "trata con" un determinado proveedor. Ninguna combinación de estas relaciones expresa el significado de un contrato adecuadamente, por al menos dos razones:





¡Los datos que el proveedor S puede suministrar de la parte P, que el departamento D necesita la parte P y que D comprará a S no implican necesariamente que el departamento D compre la parte P al proveedor S! No podemos representar limpiamente el atributo de cantidad de un contrato.

2.5.4 Agregación versus relaciones ternarias Como señalamos en la Sección 2.4.5, la elección entre el uso de agregación o una relación ternaria está determinada principalmente por la existencia de una relación que relaciona un conjunto de relaciones con un conjunto de entidades (o un segundo conjunto de relaciones). La elección también puede estar guiada por ciertas restricciones de integridad que queremos expresar. Por ejemplo, considere el diagrama ER que se muestra en la Figura 2.13. De acuerdo con este diagrama, un proyecto puede ser patrocinado por cualquier número de departamentos, un departamento puede patrocinar uno o más proyectos y cada patrocinio es supervisado por uno o más empleados. Si no necesitamos registrar el atributo de hasta de los monitores, entonces podríamos usar una relación ternaria, por ejemplo, Sponsors2, como se muestra en la Figura 2.19. Considere la restricción de que cada patrocinio (de un proyecto por un departamento) sea monitoreado por un empleado como máximo. No podemos expresar esta restricción en términos del conjunto de relaciones de Sponsors2. Por otro lado, podemos expresar fácilmente la restricción dibujando una flecha de los Patrocinadores de la relación agregada a los Monitores de relaciones en la Figura 2.13. Por lo tanto, la presencia de tal restricción sirve a otra razón para utilizar la agregación en lugar de un conjunto de relaciones ternarias.

Figura 2.19 Uso de una relación ternaria 1

2.6 DISEÑO CONCEPTUAL PARA GRANDES EMPRESAS Hasta ahora nos hemos concentrado en las construcciones disponibles en el modelo ER para describir varios conceptos y relaciones de aplicación. El proceso de diseño conceptual consiste en algo más que describir pequeños fragmentos de la aplicación en términos de

diagramas ER. Para una empresa grande, el diseño puede requerir los esfuerzos de más de un diseñador y abarcar los datos y el código de aplicación utilizados por varios grupos de usuarios. El uso de un modelo de datos semánticos de alto nivel, como los diagramas ER, para el diseño conceptual en un entorno de este tipo ofrece la ventaja adicional de que el diseño de alto nivel puede representarse esquemáticamente y ser comprendido fácilmente por las muchas personas que deben aportar información al proceso de diseño. Un aspecto importante del proceso de diseño es la metodología utilizada para estructurar el desarrollo del diseño general y garantizar que el diseño tenga en cuenta todos los requisitos del usuario y sea coherente. El enfoque habitual es que se consideren los requisitos de varios grupos de usuarios, que se resuelvan de alguna manera los requisitos conflictivos y se genere un conjunto único de requisitos globales al final de la fase de análisis de requisitos. Generar un conjunto único de requisitos globales es una tarea difícil, pero permite que la fase de diseño conceptual continúe con el desarrollo de un esquema lógico que abarque todos los datos y aplicaciones en toda la empresa.

Un enfoque alternativo es desarrollar un esquema conceptual separado para diferentes grupos de usuarios y luego integrar estos esquemas conceptuales. Para integrar múltiples esquemas conceptuales, debemos establecer correspondencias entre entidades, relaciones y atributos, y debemos resolver numerosos tipos de conflictos (por ejemplo, conflictos de nombres, discrepancias de dominio, diferencias en las unidades de medida). Esta tarea es difícil por nosotros mismos. En algunas situaciones, la integración de esquemas no se puede evitar; por ejemplo, cuando una organización se fusiona con otra, es posible que las bases de datos existentes deban integrarse. La integración de esquemas también está aumentando en importancia a medida que los usuarios exigen acceso a fuentes de datos heterogéneas, a menudo mantenidas por diferentes organizaciones.

2.7 EL LENGUAJE DE MODELADO UNIFICADO Existen muchos enfoques para el diseño de sistemas de software de extremo a extremo, que abarcan todos los pasos, desde la identificación de los requisitos comerciales hasta las especificaciones finales para una aplicación completa, incluidos el flujo de trabajo, las interfaces de usuario y muchos aspectos de los sistemas de software que van más allá. Bases de datos y los datos almacenados en ellas. En esta sección, tratamos brevemente un enfoque que se está volviendo popular, llamado el enfoque del lenguaje de modelado unificado (UML). El diagrama UML, al igual que el modelo ER, tiene la característica atractiva de que sus construcciones se pueden dibujar como diagramas. Abarca un espectro más amplio del proceso de diseño de software que el modelo ER:



Modelo de negocio: en esta fase, el objetivo es describir los procesos de negocio involucrados en la aplicación de software que se está desarrollando.



Modelado de sistemas: la comprensión de los procesos de negocios se utiliza para identificar los requisitos para la aplicación de software. Una parte de los requisitos son los requisitos de la base de datos.



Modelado conceptual de bases de datos: este paso corresponde a la creación del diseño de ER para la base de datos. Para este propósito, UML proporciona muchas construcciones paralelas a las construcciones ER.



Modelado de bases de datos físicas: El diargrama UML también proporciona representaciones pictóricas para las opciones de diseño de bases de datos físicas, tales como la creación de índices de espacios de tablas. ("Discutir el diseño físico de la base de datos en los capítulos posteriores, pero no en las construcciones UML correspondientes.)



Modelado de sistemas de hardware: se pueden usar diagramas UML para describir la configuración de hardware utilizada para la aplicación.

Hay muchos tipos de diagramas en UML. Los diagramas de casos de uso describen las acciones realizadas por el sistema en respuesta a las solicitudes de los usuarios y las personas involucradas en estas acciones. Estos diagramas especifican la funcionalidad externa que se espera que el sistema admita. Los diagramas de actividad muestran el flujo de acciones en un proceso de negocio.. Los diagramas de cuadros de estado describen las interacciones dinámicas entre los objetos del sistema. Estos diagramas, utilizados en negocios y modelado de sistemas, describen cómo se implementará la funcionalidad externa, de acuerdo con las reglas de negocios y los procesos de la empresa. Los diagramas de clase son similares a los diagramas ER, aunque son más generales porque están diseñados para modelar entidades de aplicación (intuitivamente, componentes importantes del programa) y sus relaciones lógicas, además de entidades de datos y sus relaciones. Tanto los conjuntos de entidades como los conjuntos de relaciones se pueden representar como clases en UML, junto con restricciones clave, entidades débiles y jerarquías de clases. El término relación se usa de forma ligeramente diferente en UML, y las relaciones de UML son binarias. Esto a veces lleva a la confusión sobre si los conjuntos de relaciones en un diagrama de ER que involucran tres o más conjuntos de entidades se pueden representar directamente en UML. La confusión desaparece una vez que entendemos que todos los conjuntos de relaciones (en el sentido de ER) se representan como clases en UML; Las 'relaciones' binarias de UML son esencialmente los enlaces que se muestran en los diagramas ER entre los conjuntos de entidades y los conjuntos de relaciones. Los conjuntos de relaciones con claves de restricciones generalmente se omiten de los diagramas UML, y la relación se indica mediante el enlace directo de los conjuntos de entidades involucrados. Por ejemplo, considere la figura 2.6. Una representación en UML de este diagrama ER tendría una clase para Empleados, una clase para Departamentos, y

los gestores de relaciones se muestran al vincular estas dos clases. El enlace se puede etiquetar con un nombre e información de cardinalidad para mostrar que un departamento solo puede tener un administrador. Como veremos en el Capítulo 3, los diagramas ER se traducen en el modelo relacional al mapear cada conjunto de entidades en una tabla y cada conjunto de relaciones en una tabla. Además, como veremos en la Sección 3.5.3, la tabla correspondiente a un conjunto de relaciones uno a muchos se omite típicamente al incluir alguna información adicional sobre la relación en la tabla para uno de los conjuntos de entidades involucrados. Por lo tanto, los diagramas de clase UML se corresponden estrechamente con las tablas creadas al asignar un diagrama ER. De hecho, cada clase en un diagrama de clase UML se asigna a una tabla en el diagrama de base de datos UML correspondiente. Los diagramas de la base de datos de UML muestran cómo se representan las clases en la base de datos y contienen detalles adicionales sobre la estructura de la base de datos, como las restricciones de integridad y los índices. Los enlaces ("relaciones" de UML) entre clases de UML llevan a varias restricciones de integridad entre las tablas correspondientes. Se pueden modelar muchos detalles específicos del modelo relacional (por ejemplo, vistas, claves foraneas, campos permitidos nulos) y que reflejan las opciones de diseño físico (por ejemplo, campos indexados) en los diagramas de la base de datos de la ONU. Los diagramas de componentes de UML describen aspectos de almacenamiento de la base de datos, como los espacios de tablas y las condiciones de la base de datos, así como las interfaces para las aplicaciones que acceden a la base de datos. Finalmente, los diagramas de despliegue muestran los aspectos de hardware del sistema. Nuestro objetivo en este libro es concentrarnos en los datos almacenados en una base de datos y los problemas de diseño relacionados. Para este fin, deliberadamente tomamos una vista simplificada de los otros pasos involucrados en el diseño y desarrollo de software. Más allá de la discusión específica de UML, el material en esta sección está destinado a colocar los problemas de diseño que cubrimos dentro del contexto del proceso de diseño de software más amplio. Esperamos que esto ayude a los lectores interesados en una discusión más completa del diseño de software para complementar nuestra discusión al referirnos a otro material sobre su enfoque preferido para el diseño general del sistema.

2.8 ESTUDIO DE CASO: LA TIENDA DE INTERNET Ahora presentamos un estudio de caso de diseño ilustrativo, "desde el inicio hasta el final", que utilizamos como ejemplo en este libro. DBDudes Inc., una reconocida firma de consultoría de bases de datos, ha sido llamada para ayudar a Barns and Nobble (B&N) con su diseño e implementación de bases de datos. B&N es una gran librería especializada en libros sobre carreras de caballos, y ha decidido conectarse a Internet. DBDudes primero verifica que B&N está dispuesta y es capaz de pagar sus tarifas elevadas y luego programa una reunión para almorzar y negociar para B&N, naturalmente para hacer un análisis de requisitos.

2.8.1 Análisis de requerimientos El propietario de B&N, a diferencia de muchas personas que necesitan una base de datos, ha pensado mucho sobre lo que quiere y ofrece un resumen conciso: "Me gustaría que mis clientes puedan navegar por mi catálogo de libros y hacer pedidos a través de Internet. Actualmente, recibo pedidos por teléfono. Tengo clientes en su mayoría corporativos que me llaman y me dan el número de ISBN de un libro y un cantidad; a menudo pagan con tarjeta de crédito. Luego preparo un envío que contiene los libros que ordenaron. Si no tengo suficientes copias en stock, ordeno copias adicionales y demoro el envío hasta que lleguen las nuevas copias; quiero enviar el pedido completo de un cliente junto. Mi catálogo incluye todos los libros que vendo. Para cada libro, el catálogo contiene su número de ISBN, título, autor, precio purcha.se, precio de venta y el año en que se publicó el libro. La mayoría de mis clientes son constantes, y tengo registros con sus nombres y direcciones. Los clientes nuevos deben llamarme primero y establecer una cuenta antes de poder usar mi sitio web.

Figura 2.20 Diagrama ER del diseño inici 1

En mi nuevo sitio web, los clientes primero deben identificarse por su número de identificación de cliente único. Entonces deberían poder navegar por mi catálogo y realizar pedidos en línea ". Los consultores de DBDudes están un poco sorprendidos por la rapidez con la que se completa la fase de requisitos; por lo general, se necesitan semanas de discusiones (y muchos almuerzos y cenas) para que esto termine en sus oficinas y analice esta información.

2.8.2 Diseño conceptual En el paso de diseño conceptual, DBDudes desarrolla una descripción de alto nivel de los datos en términos del modelo ER. El diseño inicial se muestra en la Figura 2.20. Los libros y los clientes se modelan como entidades y se relacionan a través de los pedidos que los clientes hacen. Pedidos es un conjunto de relaciones que conecta los conjuntos de entidades Libros y Clientes. Para cada pedido, se almacenan los siguientes atributos: cantidad, fecha de pedido y fecha de envío. Tan pronto como se envía un pedido, se

establece la fecha de envío; hasta entonces, la fecha de envío se establece en nula, lo que indica que este pedido aún no se ha enviado. DBDudes tiene una revisión interna de diseño en este punto, y se plantean varias preguntas. Para proteger sus identidades, nos referiremos al líder del equipo de diseño como persona 1 y al revisor de diseño como persona 2.

Persona 2: ¿Qué pasa si uno hace dos pedidos para el mismo libro en un día? Persona 1: el primer pedido se maneja creando una nueva relación de Órdenes y el segundo se maneja al actualizar el valor del atributo de cantidad en esta relación. Persona 2: ¿Qué sucede si un cliente hace dos pedidos de libros diferentes en un día? Persona 1: No hay problema. Cada instancia del conjunto de relaciones Pedidos relaciona al cliente con un libro diferente. Persona 2: Ah, pero ¿y si un cliente hace dos pedidos para el mismo libro en días diferentes? Persona 1: ¿Qué puede usar el atributo fecha de orden de la relación de órdenes para distinguir las dos órdenes? Persona 2: Oh no, no puedes. Los atributos de Clientes y Libros deben contener conjuntamente una clave para Pedidos. Por lo tanto, este diseño no permite que un cliente realice pedidos para el mismo libro en días diferentes. Persona 1: Ay, tienes razón. Oh bueno, a B&N probablemente no le importará; ya veremos.

DBDudes decide continuar con la siguiente fase, el diseño lógico de la base de datos; Nos reunimos con ellos en la Sección 3.8.

2.9 PREGUNTAS DE REVISIÓN Las respuestas a las preguntas de revisión se pueden encontrar en las secciones enumeradas.     



Nombra los pasos principales en el diseño de la base de datos. ¿Cuál es el objetivo de cada paso? ¿En qué paso se utiliza principalmente el modelo ER? (Sección 2.1) Defina estos términos: entidad, conjunto de entidades, atributo, clave. (Sección 2.2) Defina estos términos: relación, conjunto de relaciones, atributos descriptivos. (Sección 2.3) Defina los siguientes tipos de restricciones y dé un ejemplo de cada una: restricción clave, restricción de participación. ¿Qué es una entidad débil? ¿Qué son las jerarquías de clase? ¿Qué es la agregación? Dé un ejemplo de escenario motivando el uso de cada una de estas construcciones de diseño de modelo ER. (Sección 2.4) ¿Qué pautas utilizaría para cada una de estas opciones al realizar el diseño de la ER: si usar un atributo o un conjunto de entidades, una entidad o un conjunto de relaciones, una relación binaria o ternaria o una agregación? (Sección 2.5)

 

¿Por qué es especialmente difícil diseñar una base de datos para una gran empresa? (Sección 2.6) ¿Qué es UML? ¿Cómo encaja el diseño de base de datos en el diseño general de un sistema de software de uso intensivo de datos? ¿Cómo se relaciona UML con los diagramas de ER? (Sección 2.7).

EJERCICIOS Ejercicio 2.1 Explique brevemente los siguientes términos: atributo, dominio, entidad, relación ,. conjunto de entidades, conjunto de relaciones, relación de uno a muchos, relación de muchos a muchos. pan · tcipation constmint. restricción de superposición, restricción de cobertura, conjunto de entidades débiles. agregación, e indicador de rol. Ejercicio 2.2 Una base de datos de la universidad contiene información sobre profesores (identificados por el número de seguridad social o SSN) y cursos (identificados por courseid). Los profesores imparten cursos; Cada una de las siguientes situaciones se refiere al conjunto de relaciones de Enseñanza. Para cada situación, dibuje un diagrama ER que lo describa (suponiendo que no se cumplan otras restricciones). 1. Los profesores pueden enseñar el mismo curso en varios semestres, y cada ofrenda debe ser registrada. 2. Los profesores pueden impartir el mismo curso en varios semestres y solo es necesario registrar la oferta más reciente. (Suponga que esta condición se aplica en todas las preguntas posteriores). 3. Cada profesor debe impartir algún curso. 4. Cada profesor enseña exactamente un curso (ni más, ni menos). 5. Cada profesor enseña exactamente un curso (ni más, ni menos), y cada curso debe ser impartido por algún profesor. 6. Ahora supongamos que ciertos cursos pueden ser impartidos por un equipo de profesores conjuntamente, pero es posible que ningún profesor en un equipo pueda impartir el curso. Modele esta situación, introduciendo conjuntos de entidades adicionales y conjuntos de relaciones si es necesario.

Ejercicio 2.3 Considere la siguiente información sobre una base de datos de la universidad:      

Los profesores tienen un SSN, un nombre, una edad, un rango y una especialidad de investigación. Los proyectos tienen un número de proyecto, un nombre de patrocinador (por ejemplo, NSF), una fecha de inicio, una fecha de finalización y un presupuesto. Los estudiantes graduados tienen un SSN, un nombre, una edad y un programa de grado (por ejemplo, M.S. o Ph.D.). Cada proyecto es administrado por un profesor (conocido como el investigador principal del proyecto). Cada proyecto es trabajado por uno o más profesores (conocidos como los coinvestigadores del proyecto). Los profesores pueden gestionar y / o trabajar en múltiples proyectos.

 

    

Cada proyecto es trabajado por uno o más estudiantes graduados (conocidos como asistentes de investigación del proyecto). Cuando los estudiantes de posgrado se dedican a un proyecto, un profesor debe supervisar su trabajo en el proyecto. Los estudiantes graduados pueden trabajar en múltiples proyectos, en cuyo caso tendrán un supervisor (potencialmente diferente) para cada uno. Los departamentos tienen un número de departamento, un nombre de departamento y una oficina principal. Los departamentos tienen un profesor (conocido como el presidente) que dirige el departamento. Los profesores trabajan en uno o más departamentos, y para cada departamento en el que trabajan, un porcentaje de tiempo está asociado con su trabajo. Los estudiantes graduados tienen un departamento importante en el que están trabajando en su grado. Cada estudiante graduado tiene otro estudiante graduado más senior (conocido como consejero estudiantil) que le aconseja qué cursos tomar.

Diseñe y dibuje un diagrama de ER que capture la información sobre la universidad. Use solo el modelo ER básico aquí; Es decir, entidades, relaciones y atributos. Asegúrese de indicar cualquier restricción clave y de participación. Ejercicio 2.4 Una base de datos de la empresa necesita almacenar información sobre empleados (identificados por ssn, con salario y teléfono como atributos), departamentos (identificados por dna, con dname y presupuesto como atributos) e hijos de empleados (con nombre y edad como atributos) . Los empleados trabajan en departamentos; cada departamento es administrado por un empleado; un niño debe identificarse únicamente por su nombre cuando se conoce al padre (que es un empleado; se supone que solo uno de los padres trabaja para la empresa). No nos interesa la información sobre un niño una vez que el padre abandona la empresa. Dibuja un diagrama de ER que capture esta información. El ejercicio 2.5 Notown Records ha decidido almacenar información sobre músicos que actúan en sus álbumes (así como en otros datos de la compañía) en una base de datos. La compañía ha elegido sabiamente contratarle como diseñador de base de datos (con su tarifa de consultoría habitual de $ 2500 por dia). 



 

Cada músico que graba en Notown tiene un SSN, un nombre, una dirección y un número de teléfono. Los músicos mal pagados a menudo comparten la misma dirección, y ninguna dirección tiene más de un teléfono. Cada instrumento utilizado en las canciones grabadas en Notown tiene un nombre (por ejemplo, guitarra, sintetizador, flauta) y una tecla musical (por ejemplo, C, Bflat, E-flat). Cada álbum grabado en la etiqueta Notown tiene un título, una fecha de copyright, un formato (por ejemplo, CD o MC) y un identificador de álbum. Cada canción grabada en Notown tiene un título y un autor.

   

Cada músico puede tocar varios instrumentos, y un instrumento dado puede ser tocado por varios musicos. Cada álbum tiene una cantidad de canciones, pero ninguna canción puede aparecer en más de un álbum. Cada canción es interpretada por uno o más músicos, y un músico puede interpretar varias canciones. Cada álbum tiene exactamente un músico que actúa como su productor. Un músico puede producir varios álbumes, por supuesto.

Diseñe un esquema conceptual para Notown y dibuje un diagrama ER para su esquema. La información anterior describe la situación que la base de datos Notown debe modelar. Asegúrese de indicar todas las restricciones de clave y cardinalidad y cualquier suposición que haga. Identifique cualquier restricción que no pueda capturar en el diagrama de ER y explique brevemente por qué no pudo expresarlas. Ejercicio 2.6 Los viajeros frecuentes del Departamento de Ciencias de la Computación se han quejado a los funcionarios del Aeropuerto del Condado de Dane sobre la mala organización en el aeropuerto. Como resultado, los funcionarios decidieron que toda la información relacionada con el aeropuerto debería organizarse utilizando un DBMS, y usted ha sido contratado para diseñar la base de datos. Su primera tarea es organizar la información sobre todos los aviones estacionados y mantenerlos en el aeropuerto. La información relevante es la siguiente:  

 

 





Cada avión tiene un número de registro, y cada avión es de un modelo específico. El aeropuerto tiene capacidad para varios modelos de aviones, y cada modelo se identifica por un número de modelo (por ejemplo, DC-10) y tiene una capacidad y un peso. Varios técnicos trabajan en el aeropuerto. Necesitas guardar el nombre, SSN, dirección, Número de teléfono y sueldo de cada técnico. Cada técnico es un experto en uno o más modelos de avión, y su experiencia puede coincidir con la de otros técnicos. Esta información sobre los técnicos también debe ser registrada. Los controladores de tráfico deben tener un examen médico anual. Para cada controlador de tráfico, debe almacenar la fecha del examen más reciente. Todos los empleados del aeropuerto (incluidos los técnicos) pertenecen a un sindicato. Debe guardar el número de membresía sindical de cada empleado. Puede asumir que cada empleado está identificado de manera única por un número de seguro social. El aeropuerto tiene una serie de pruebas que se utilizan periódicamente para garantizar que los aviones aún estén en condiciones de volar. Cada prueba tiene un número de prueba de la Administración Federal de Aviación (FAA), un nombre y un puntaje máximo posible. La FAA requiere que el aeropuerto realice un seguimiento de cada vez que un técnico determinado pruebe un avión determinado mediante un examen determinado. Para cada evento de prueba, la información necesaria es la fecha, la cantidad de horas que el técnico dedicó a la prueba y la calificación que recibió el avión en la prueba.

1. Dibuja un diagrama de ER para la base de datos del aeropuerto. Asegúrese de indicar los diversos atributos de cada entidad y conjunto de relaciones; También especifique la clave y las restricciones de participación para cada conjunto de relaciones. Especifique cualquier superposición necesaria y las restricciones de cobertura ahora bien (en inglés). 2. La FAA aprueba un reglamento que establece que las pruebas en un avión deben ser realizadas por un técnico experto en ese modelo. ¿Cómo expresarías esta restricción en el diagrama de ER? Si no puedes expresarlo, explícalo brevemente.

Ejercicio 2.7 La cadena de farmacias Prescriptions-R-X ha ofrecido darle un suministro gratuito de medicamentos de por vida si usted diseña su base de datos. Dado el aumento del costo de la atención médica, usted está de acuerdo. Aquí está la información que reúnes:    

  







Los pacientes se identifican por un SSN, y sus nombres, direcciones y edades deben ser registrados. Los médicos son identificados por un SSN. Para cada médico, el nombre, la especialidad y los años de la experiencia debe ser registrada. Cada compañía farmacéutica está identificada por su nombre y tiene un número de teléfono. Para cada medicamento, el nombre comercial y la fórmula deben ser registrados. Cada medicamento es vendido por una compañía farmacéutica determinada, y el nombre comercial identifica un medicamento de forma exclusiva entre los pJs; productos de esa compañía. Si se elimina una empresa farmacéutica, ya no es necesario seguir la pista de sus productos. Cada farmacia tiene un nombre, dirección y número de teléfono. Cada paciente tiene un médico de cabecera. Cada médico tiene al menos un paciente. Cada farmacia vende varios medicamentos y tiene un precio para cada uno. Un medicamento puede venderse en varias farmacias y el precio puede variar de una farmacia a otra. Los médicos recetan medicamentos para los pacientes. Un médico puede recetar uno o más medicamentos para varios pacientes, y un paciente puede obtener recetas de varios médicos. Cada receta tiene una fecha y una cantidad asociada. Puede suponer que, si un médico prescribe el mismo medicamento para el mismo paciente más de una vez, solo debe guardarse la última receta. Las compañías farmacéuticas tienen contratos a largo plazo con farmacias. Una compañía farmacéutica puede contratar varias farmacias, y una farmacia puede contratar varias compañías farmacéuticas. Para cada contrato, debe almacenar una fecha de inicio, una fecha de finalización y el texto del contrato. Las farmacias nombran un supervisor para cada contrato. Siempre debe haber un supervisor para cada contrato, pero el supervisor del contrato puede cambiar durante la vigencia del contrato.

1. Dibuja un diagrama ER que capture la información anterior. Identifique cualquier restricción no capturada por el diagrama ER. 2. ¿Cómo cambiaría su diseño si todas las farmacias vendieran un medicamento a un precio fijo? 3. ¿Cómo cambiaría su diseño si los requisitos de diseño cambian de la siguiente manera? Si un médico receta el mismo medicamento para el mismo paciente más de una vez, es posible que deban almacenarse varias de estas recetas.

Ejercicio 2.8 Aunque siempre quiso ser un artista, terminó siendo un experto en bases de datos porque le encanta cocinar datos y de alguna manera confundió la base de datos con datos básicos. Sin embargo, tu antiguo amor todavía está allí, así que creas una compañía de base de datos, ArtBase, que construye un producto para galerías de arte. El núcleo de este producto es una base de datos con un esquema que captura toda la información que las galerías deben mantener. Las galerías guardan información sobre los artistas, sus nombres (que son únicos), lugares de nacimiento, edad y estilo de arte. Para cada obra de arte, el artista, el año en que se realizó, su título único, su tipo de arte (por ejemplo, pintura, litografía, escultura, fotografía) y su precio deben almacenarse. Las obras de arte también se clasifican en grupos de varios tipos, por ejemplo, retratos, naturalezas muertas, obras de Picasso u obras del siglo XIX; Una pieza dada puede pertenecer a más de un grupo. Cada grupo se identifica con un nombre (como los que se acaban de dar) que describe al grupo. Finalmente, las galerías mantienen información sobre los clientes. Para cada cliente, las galerías conservan el nombre único, la dirección, la cantidad total de dólares gastados en la galería (¡muy importante!) Y los artistas y grupos de arte que el cliente tiende a agradar. Dibuja el diagrama de ER para la base de datos.

Ejercicio 2.9 Responde las siguientes preguntas. 



Explique brevemente los siguientes términos: UML, diagramas de casos de uso, diagramas de gráficos de estados, diagramas de clases, diagramas de bases de datos, diagramas de componentes y diagramas de implementación. Explicar la relación entre los diagramas ER y UML.