Bases de datos - Modelado de datos

BASES DE DATOS ITema 3: Modelado de datosProfr. Valentin Baez Trejo

Universidad Autónoma de Ciudad Juárez IIT Campus CU

INTRODUCCIÓNEl modelado conceptual es una fase muy importante para diseñar correctamente una aplicación de DB.

Por lo general, el término aplicación de base de datos se refiere a una DB concreta y a los programas asociados encargados de implementar las consultas y las actualizaciones de la misma.

Tradicionalmente, el diseño y la comprobación de los programas de aplicación se han considerado más como parte del dominio de la ingeniería de software que del dominio de las DB.

Seguiremos la metodología tradicional de concentrarse en las estructuras y las restricciones de la DB durante el diseño de esta última. Presentaremos los conceptos de modelado del modelo Entidad-Relación (ER), que es un modelo de datos conceptual de alto nivel.

USO DE MODELO DE DATOS PARA EL DISEÑO DE DB

USO DE MODELO DE DATOS PARA EL DISEÑO DE DB

Una descripción simplificada del proceso de diseño de una DB seria:

1. Recopilación de datos y análisis. Documentación de requisitos (diseño y funcionalidad), para operaciones y transacciones.

2. Diseño conceptual. Descripción de los requisitos de datos de usuarios (tipos de entidades, relaciones y restricciones).

3. Diseño Lógico. Implementación real de la DB mediante una DBMS.

4. Diseño Físico. Especificación de las estructuras de almacenamiento interno (índices, rutas de acceso)

EJEMPLO DE APLICACIÓN DE DB

En primer lugar se enumeran los requisitos de datos para la DB, y después se crea su esquema conceptual paso a paso tras introducir los conceptos de modelado del modelo ER.

Una DB EMPRESA sirve como seguimiento de los empleados, los departamentos y los proyectos de una empresa. Suponga que después de la fase de recopilación de requisitos y análisis, los diseñadores de la DB proporcionan la siguiente descripción del mini-mundo.

La empresa está organizada en departamentos. Cada uno tiene un nombre único, un número único y un empleado concreto que lo administra. Se realizará un seguimiento de la fecha en que ese empleado empezó a administrar el departamento. Un departamento puede tener varias ubicaciones.


Un departamento controla una cierta cantidad de proyectos, cada uno de los cuales tiene un nombre único, un número único y una sola ubicación.

Almacenaremos el nombre, el DNI (SSN o CURP), la dirección, el sueldo, el sexo y la fecha de nacimiento de cada empleado. Un empleado está asignado a un departamento, pero puede trabajar en varios proyectos, que no están controlados necesariamente por el mismo departamento. Se hará un seguimiento del número de horas por semana que un empleado trabaja en cada proyecto. También se realizará el seguimiento del supervisor directo de cada empleado.

También se desea realizar un seguimiento de las personas a cargo de cada empleado por el tema de los seguros. Por cada persona a cargo o subordinado, se registrará su nombre de pila, sexo, fecha de nacimiento y relación con el empleado.


EJERCICIOS DE APLICACIÓN DE DB

A partir de los siguientes enunciados, diseñe el modelo entidad-relación necesario para cada caso:

CASO 1:

Una empresa vende productos a varios clientes. Se necesita conocer los datos personales de los clientes (nombre, apellidos, DNI, dirección y fecha de nacimiento). Cada producto tiene un nombre y un código, así como un precio unitario. Un cliente puede comprar varios productos a la empresa, y un mismo producto puede ser comprado por varios clientes.

Los productos son suministrados por diferentes proveedores. Se debe tener en cuenta que un producto sólo puede ser suministrado por un proveedor, y que un proveedor puede suministrar diferentes productos. De cada proveedor se desea conocer el NIF, nombre y dirección”.


CASO 2

Se desea diseñar la base de datos de un Instituto. En la base de datos se desea guardar los datos de los profesores del Instituto (DNI, nombre, dirección y teléfono).

Los profesores imparten módulos, y cada módulo tiene un código y un nombre. Cada alumno está matriculado en uno o varios módulos. De cada alumno se desea guardar el nº de expediente, nombre, apellidos y fecha de nacimiento. Los profesores pueden impartir varios módulos, pero un módulo sólo puede ser impartido por un profesor. Cada curso tiene un grupo de alumnos, uno de los cuales es el delegado del grupo.


CASO 3

Se desea actualizar la gestión de una escuela para llevar el control de los alumnos matriculados y los profesores que imparten clases en ese centro.

De cada profesor y cada alumno se desea recoger el nombre, apellidos, dirección, población, DNI, fecha de nacimiento, código postal y teléfono. Los alumnos se matriculan en una o más asignaturas, y de ellas se desea almacenar el código de asignatura, nombre y número de horas que se imparten a la semana.

Un profesor del centro puede impartir varias asignaturas, pero una asignatura sólo es impartida por un único profesor. De cada una de las asignaturas se desea almacenar también la nota que saca el alumno y las incidencias que puedan darse con él. Además, se desea llevar un control de los cursos que se imparten en la escuela.


De cada curso se guardará el código y el nombre. En un curso se imparten varias asignaturas, y una asignatura sólo puede ser impartida en un único curso. Las asignaturas se imparten en diferentes aulas del centro. De cada aula se quiere almacenar el código, piso en el que se encuentra y número de espacios de que dispone.

Una asignatura se puede dar en diferentes aulas, y en un aula se pueden impartir varias asignaturas. Se desea llevar un registro de las asignaturas que se imparten en cada aula. Para ello se anotará el mes, día y hora en el que se imparten cada una de las asignaturas en las distintas aulas.

La dirección también designa a varios profesores como tutores en cada uno de los cursos. Un profesor es tutor tan sólo de un curso. Un curso tiene un único tutor. Se habrá de tener en cuenta que puede que haya profesores que no sean tutores de ningún curso.

TIPOS DE ENTIDAD, CONJUNTOS, ATRIBUTOS Y

CLAVESEntidades y atributos.

El objeto básico representado por el modelo de ER es una entidad. Una entidad puede ser un objeto con existencia física o conceptual. Cada entidad tiene atributos.

Una entidad en particular tendrá un valor para cada uno de sus atributos. Los valores de los atributos que describen cada entidad se convierten en la parte principal de los datos almacenados en la base de datos.


CLAVESEn el modelo ER se dan varios tipos de atributos: simple frente a compuesto, mono valor frente a multi-valor, y almacenado frente a derivado.

Atributos compuestos frente a atributos simples

Los atributos compuestos se pueden dividir en sub-partes más pequeñas, que representan atributos más básicos con significados independientes.

Los atributos que no son divisibles se denominan atributos simples o atómicos.


CLAVESAtributos mono-valor y multi-valor.

La mayoría de los atributos tienen un solo valor para una entidad en particular; dichos atributos reciben el nombre de mono-valor o de un solo valor.

Atributos almacenados y derivados

En algunos casos, dos (o más) valores de atributo están relacionados. Para una entidad de persona en particular, suponga que el valor de Edad puede determinarse a partir de la fecha actual y el valor de FechaNac de esa persona.

El atributo Edad se denomina entonces atributo derivado y se dice que se ha derivado del atributo FechaNac, que es el denominado atributo almacenado.


CLAVESValores NULL (nulos).

En algunos casos, es posible que una entidad en particular no tenga un valor aplicable para un atributo. Por ejemplo, un atributo Licenciaturas sólo se aplica a las personas con carrera universitaria en especifico.

Atributos complejos.

Los atributos compuestos y multi-valor se pueden anidar arbitrariamente. Podemos representar el anidamiento arbitrario agrupando componentes de un atributo compuesto entre paréntesis ( ) y separando los componentes con comas, y mostrando los atributos multi-valor entre llaves { }. Dichos atributos se denominan atributos complejos.

TIPOS DE ENTIDADES, CONJUNTOS,CLAVES Y CONJUNTOS

Tipos de entidades y conjuntos de entidades.

Una base de datos normalmente contiene grupos de entidades que son parecidas. Estas entidades comparten los mismos atributos, pero cada entidad tiene su(s) propio (s) valor(es) para cada atributo.

Un tipo de entidad define una colección (o conjunto) de entidades que tienen los mismos atributos.


Atributos clave de un tipo de entidad.

Una restricción importante de las entidades de un tipo de entidad es la clave o restricción de unicidad de los atributos.

Un tipo de entidad normalmente tiene un atributo cuyos valores son distintos para cada entidad individual del conjunto de entidades. Dicho atributo se denomina atributo clave, y sus valores se pueden utilizar para identificar cada entidad sin lugar a dudas.

En ocasiones, una clave está formada por varios atributos juntos, lo que da a entender que la combinación de los valores de atributo debe ser distinta para cada entidad. En la notación diagramática ER, cada atributo clave tiene su nombre subrayado dentro del óvalo.


Conjuntos de valores (dominios) de atributos.

Cada atributo simple de un tipo de entidad está asociado con un conjunto de valor (o dominio de valores), que especifica el conjunto de los valores que se pueden asignar a ese atributo por cada entidad individual

DISEÑO CONCEPTUAL INICIAL DE LA BASE DE DATOS EMPRESA

Ahora podemos definir los tipos de entidad para la base de datos EMPRESA, en base a los requisitos descritos. Después de definir aquí varios tipos de entidad y sus atributos, refinaremos nuestro diseño, después de introducir el concepto de una relación.

Tipo de entidad DEPARTAMENTO con los atributos NombreDpto, NúmeroDpto, Ubicaciones, Director y FechalngresoDirector. Ubicaciones es el único atributo multivalor. Podemos especificar que Nombre y NúmeroDpto son atributos clave (separados) porque cada uno se especificó como único.


Tipo de entidad PROYECTO con los atributos Nombre, Número, Ubicación y DepartamentoControl. Tanto Nombre como Número son atributos clave (separados).


Tipo de entidad EMPLEADO con los atributos Nombre, Dni, Sexo, Dirección, Sueldo, FechaNac, Departamento y Supervisor. Nombre y Dirección pueden ser atributos compuestos; no obstante, esto no se especificó en los requisitos.

Debemos volver a los usuarios para ver si alguno de ellos se referirá a los componentes individuales de Nombre (NombrePila, PrimerApellido, SegundoApellido) o de Dirección.


Tipo de entidad SUBORDINADO con los atributos Empleado, NombreSubordinado, Sexo, FechaNac y Relación (con el empleado).

TIPOS DE RELACIONES, CONJUNTOS, ROLES Y

RESTRICCIONES ESTRUCTURALESTipos, conjuntos e instancias de relaciones.

Un tipo de relación R entre n tipos de entidades define un conjunto de asociaciones (o un conjunto de relaciones) entre las entidades de esos tipos de entidades. Como en el caso de los tipos de entidades y los conjuntos de entidades, normalmente se hace referencia a un tipo de relación y su correspondiente conjunto de relaciones con el mismo nombre, R.

Por ejemplo, considere un tipo de relación TRABAJA_EN asociado con una entidad EMPLEADO y una entidad DEPARTAMENTO, donde cada instancia de relación se muestra conectada a las entidades EMPLEADO y DEPARTAMENTO.

En los diagramas ER, los tipos de relaciones se muestran mediante rombos, conectados a su vez mediante líneas a los rectángulos que representan los tipos de entidad participantes. El nombre de la relación se muestra en el rombo


RESTRICCIONES ESTRUCTURALES


RESTRICCIONES ESTRUCTURALESRelaciones y atributos.

A veces es conveniente imaginar un tipo de relación en términos de atributos, considere el tipo de relación TRABAJA_EN de la figura anterior.

Uno puede pensar en un atributo denominado Departamento del tipo de entidad EMPLEADO donde el valor de Departamento por cada entidad EMPLEADO es una referencia a la entidad DEPARTAMENTO para la que ese empleado trabaja. Por tanto, el conjunto de valores para este atributo departamento es el conjunto de todas las entidades DEPARTAMENTO.


RESTRICCIONES ESTRUCTURALESNombres de rol y relaciones recursivas.

Cada tipo de entidad que participa en un tipo de relación juega un papel o rol particular en la relación. El nombre de rol hace referencia al papel que una entidad participante del tipo de entidad juega en cada instancia de relación, y ayuda a explicar el significado de la relación.

Los nombres de rol no son técnicamente necesarios en los tipos de relación donde todos los tipos de entidad participantes son distintos, puesto que cada nombre de tipo de entidad participante se puede utilizar como nombre de rol.

No obstante, en algunos casos el mismo tipo de entidad participa más de una vez en un tipo de relación con diferentes roles. En esos casos, el nombre de rol es esencial para distinguir el significado de cada

Dichos tipos de relaciones se denominan relaciones recursivas.




RESTRICCIONES ESTRUCTURALESRestricciones en los tipos de relaciones.

Los tipos de relaciones normalmente tienen ciertas restricciones que limitan las posibles combinaciones entre las entidades que pueden participar en el conjunto de relaciones correspondiente. Estas restricciones están determinadas por la situación del mini-mundo representado por las relaciones.

Podemos distinguir dos tipos principales de restricciones de relación: razón de cardinalidad y participación.


RESTRICCIONES ESTRUCTURALESRazones de cardinalidad para las relaciones binarias.

La razón de cardinalidad de una relación binaria especifica el número máximo de instancias de relación en las que una entidad puede participar.

Por ejemplo, en el tipo de relación binaria TRABAJA_EN, DEPARTAMENTO:EMPLEADO tiene una razón de cardinalidad de 1:N, que significa que cada departamento puede estar relacionado con (es decir, emplea a) cualquier cantidad de empleados, pero un empleado puede estar relacionado con (trabajar para) un solo departamento. Las posibles razones de cardinalidad para los tipos de relación binaria son 1: 1, 1 :N, N: 1 y M:N.




RESTRICCIONES ESTRUCTURALESRestricciones de participación y dependencias de existencia.

La restricción de participación especifica si la existencia de una entidad depende de si está relacionada con otra entidad a través de un tipo de relación.

Esta restricción especifica el número mínimo de instancias de relación en las que puede participar cada entidad, y en ocasiones recibe el nombre de restricción de cardinalidad mínima.

Hay dos tipos de restricciones de participación, total y parcial, que ilustramos con ejemplos.


RESTRICCIONES ESTRUCTURALES Si una política de la empresa dice que cada

empleado debe trabajar para un departamento, entonces una entidad de empleado sólo puede existir si participa en al menos una instancia de relación.

De este modo, la participación de EMPLEADO en TRABAJA_EN se denomina participación total, es decir, cada entidad del conjunto total de entidades empleado debe estar relacionada con una entidad departamento a través de TRABAJA_PARA. La participación total también se conoce como dependencia de existencia.


RESTRICCIONES ESTRUCTURALES En la Figura no esperamos que cada empleado dirija un departamento, de

modo que la participación de EMPLEADO en el tipo de relación ADMINISTRA es parcial; esto significa que algo o parte del conjunto de entidades empleado está relacionado con alguna entidad departamento a través de ADMINISTRA, pero no necesariamente con todas. Nos referiremos a la razón de cardinalidad y a las restricciones de participación, en conjunto, como restricciones estructurales de un tipo de relación.


RESTRICCIONES ESTRUCTURALES En los diagramas ER, la participación total (o dependencia existente) se

muestra como una línea doble que conecta el tipo de entidad participante con la relación, mientras que las participaciones parciales se representan mediante una línea sencilla.

ATRIBUTOS DE LOS TIPOS DE RELACIÓN

Los tipos de relación también pueden tener atributos, parecidos a los de los tipos de entidad.

Por ejemplo, para registrar el número de horas por semana que un empleado trabaja en un proyecto en particular, podemos incluir un atributo Horas para el tipo de relación TRABAJA_EN.


Los atributos de los tipos de relación 1: 1 o l:N se pueden trasladar a uno de los tipos de entidad participantes.


En el caso de un tipo de relación 1 :N, un atributo de relación sólo se puede migrar al tipo de entidad que se encuentra en el lado N de la relación


La decisión sobre dónde debe colocarse un atributo de relación (como un atributo de tipo de relación o como un atributo de un tipo de entidad participante) la determina subjetivamente el diseñador del esquema.

Para los tipos de relación M:N, algunos atributos pueden determinarse mediante la combinación de entidades participantes en una instancia de relación, no mediante una sola relación. Dichos atributos deben especificarse como atributos de relación.

Un ejemplo de esto es el atributo Horas de la relación M:N TRABAJA_EN; el número de horas que un empleado trabaja en un proyecto viene determinado por una combinación empleado-proyecto, y no separadamente por cualquiera de estas entidades.

TIPOS DE ENTIDADES DÉBILES

Los tipos de entidad que no tienen atributos clave propios se denominan tipos de entidad débiles. En contraposición, los tipos de entidad regulares que tienen un atributo clave se denominan tipos de entidad fuertes.

Las entidades que pertenecen a un tipo de entidad débil se identifican como relacionadas con entidades específicas de otro tipo de entidad en combinación con uno de sus valores de atributo. Podemos llamar a este otro tipo de entidad tipo de entidad identificado o propietario, y al tipo de relación que relaciona un tipo de entidad débil con su propietario lo podemos llamar relación identificativa del tipo de entidad débil.

Un tipo de entidad débil siempre tiene una restricción de participación total respecto a su relación identificativa, porque una entidad débil no puede identificarse sin una entidad propietaria.


Un tipo de entidad débil normalmente tiene una clave parcial (discriminador), que es el conjunto de atributos que pueden identificar sin lugar a dudas las entidades débiles que están relacionadas con la misma entidad propietaria.

En los diagramas ER, tanto el tipo de la entidad débil como la relación identificativa, se distinguen rodeando sus cuadros y rombos mediante unas líneas dobles. El atributo de clave parcial aparece subrayado con una línea discontinua o punteada.


Los tipos de entidades débiles se puede representar a veces como atributos complejos. El diseñador de la base de datos toma la decisión del tipo de representación que hay que usar. Uno de los criterios que puede utilizar es elegir la representación del tipo de entidad débil si hay muchos atributos.

Si la entidad débil participa independientemente en los tipos de relación de otra forma que su tipo de relación identificativa, entonces no debe modelarse como un atributo complejo.

PERFECCIONAMIENTO DEL DISEÑO ER

PARA LA BASE DE DATOS EMPRESA Ahora para refinar el diseño de la base de datos EMPRESA convirtiendo los

atributos que representan relaciones en tipos de relaciones. La razón de cardinalidad y la restricción de participación de cada tipo de relación vienen determinadas por los requisitos enumerados previamente. Si no es posible determinar alguna razón de cardinalidad o dependencia a partir de los requisitos, habrá que consultar con los usuarios para determinar esas restricciones estructurales.


PARA LA BASE DE DATOS EMPRESA


PARA LA BASE DE DATOS EMPRESA ADMINISTRA, un tipo de relación 1: 1 entre EMPLEADO y DEPARTAMENTO.

La participación de EMPLEADO es parcial, pero la de DEPARTAMENTO no queda clara a partir de los requisitos. Consultamos con los usuarios, que nos dicen que un departamento siempre debe tener un gerente, lo que implica una participación total. El atributo Fechalnício se asigna a este tipo de relación.

TRABAJA_PARA, un tipo de relación l:N entre DEPARTAMENTO y EMPLEADO. Ambas participaciones son totales.

CONTROLA, un tipo de relación l:N entre DEPARTAMENTO y PROYECTO. La participación de PROYECTO es total, mientras que la de DEPARTAMENTO se ha determinado como parcial, después de haber consultado con los usuarios, que indicaron que es posible que algunos departamentos no controlen proyecto alguno.


PARA LA BASE DE DATOS EMPRESA CONTROL, un tipo de relación I:N entre EMPLEADO (en el papel de

supervisor) y EMPLEADO (en el papel de supervisado). Como los usuarios han indicado que no todo empleado es un supervisor y no todo empleado tiene un supervisor, se determina que las dos participaciones son parciales.

TRABAJA_EN que, después de que los usuarios hayan indicado que en un proyecto pueden trabajar varios empleados, se determina que es un tipo de relación M:N con el atributo Horas. Se determina que ambas participaciones son totales

SUBORDINADOS_DE, un tipo de relación I:N entre EMPLEADO y SUBORDINADO, que también es la relación identificativa del tipo de entidad débil SUBORDINADO. La participación de EMPLEADO es parcial, en tanto que la de SUBORDINADO es total.


PARA LA BASE DE DATOS EMPRESA Después de especificar los seis tipos de relación anteriores, eliminamos de

los tipos de entidad todos los atributos que se han convertido en relaciones, entre los que se encuentran Director y FechalngresoDirector de DEPARTAMENTO.

DepartamentoControl de PROYECTO; Departamento, Supervisor y Trabaja_en de EMPLEADO; y Empleado de SUBORDINADO.

Es importante tener el mínimo de redundancia posible cuando diseñemos el esquema conceptual de una base de datos. Si es deseable algo de redundancia a nivel de almacenamiento o a nivel de la vista de usuario, se puede introducir más tarde






PARA LA BASE DE DATOS EMPRESA Tarea: prepare todos los ejercicios hasta este momento empleados con la

notación qua hasta este momento se ha discutido en clase, además agregue los siguientes.

Artículos y encargos.

Una base de datos para una pequeña empresa debe contener información acerca de clientes, artículos y pedidos. Hasta el momento se registran los siguientes datos en documentos varios:

Para cada cliente: Número de cliente (único), Direcciones de envío (varias por cliente), Saldo, Límite de crédito (depende del cliente, pero en ningún caso debe superar los $3.000.000), Descuento.

Para cada artículo: Número de artículo (único), Fábricas que lo distribuyen, Existencias de ese artículo en cada fábrica, Descripción del artículo.


PARA LA BASE DE DATOS EMPRESA Para cada pedido: Cada pedido tiene una cabecera y el cuerpo del pedido.

La cabecera está formada por el número de cliente, dirección de envío y fecha del pedido. El cuerpo del pedido son varias líneas, en cada línea se especifican el número del artículo pedido y la cantidad.

Además, se ha determinado que se debe almacenar la información de las fábricas. Sin embargo, dado el uso de distribuidores, se usará: Número de la fábrica (único) y Teléfono de contacto. Y se desean ver cuántos artículos (en total) provee la fábrica.

También, por información estratégica, se podría incluir información de fábricas alternativas respecto de las que ya fabrican artículos para esta empresa. Nota: Una dirección se entenderá como Nº, Calle, Comuna y Ciudad. Una fecha incluye hora. Se pide hacer el diagrama ER para la base de datos que represente esta información.


PARA LA BASE DE DATOS EMPRESASistema de ventas.

Le contratan para hacer una BD que permita apoyar la gestión de un sistema de ventas. La empresa necesita llevar un control de proveedores, clientes, productos y ventas.

Un proveedor tiene un RUT, nombre, dirección, teléfono y página web. Un cliente también tiene RUT, nombre, dirección, pero puede tener varios teléfonos de contacto. La dirección se entiende por calle, número, comuna y ciudad.

Un producto tiene un id único, nombre, precio actual, stock y nombre del proveedor. Además se organizan en categorías, y cada producto va sólo en una categoría. Una categoría tiene id, nombre y descripción.

Por razones de contabilidad, se debe registrar la información de cada venta con un id, fecha, cliente, descuento y monto final. Además se debe guardar el precio al momento de la venta, la cantidad vendida y el monto total por el producto.

DIAGRAMAS DE CLASE UML

La metodología UML se está utilizando extensamente en el diseño de software y tiene muchos tipos de diagramas para los distintos fines del diseño de software.

En algunos casos, los diagramas de clase se pueden considerar como una notación alternativa a los diagramas ER.

En los diagramas de clase UML, una clase (equivalente a un tipo de entidad en ER) se muestra como un cuadro que incluye tres secciones:

La sección superior ofrece el nombre de la clase.

La sección intermedia incluye los atributos de los objetos individuales de la clase.

La última sección incluye las operaciones que se pueden aplicar a esos objetos.


En los diagramas ER no se especifican las operaciones.

El diseñador puede especificar opcionalmente el dominio de un atributo, si lo desea, colocando el símbolo de dos puntos (:) seguido por el nombre de dominio o descripción.

Un atributo compuesto se modela como un dominio estructurado.

Un atributo multivalor generalmente se modelará como una clase separada.




Documents

Bases de datos - Modelado de datos