Modelado y Diseo de Base de Datos

Modelado y Diseo de Base de datos
Csar Luza Montero
UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS FACULTAD DE INGENIERA DE SISTEMAS E INFORMATICA
MODELADO Y DISEO DE BASE DE DATOS
CSAR LUZA MONTERO
LIMA-PER, 2010
Csar Luza Montero
Contenido
UNIDAD 1................................................................................................................................4 INTRODUCCIN A LOS SISTEMAS DE BASE DE DATOS Y AL DISEO DE BASE DE DATOS .....................................................................................................................................4 Leccin 1.................................................................................................................................. 5 Introduccin a los Sistemas de Base de Datos ........................................................................ 5
1.1 1.2 1.3 1.4 1.5 1.6 Sistema de Archivos .................................................................................................................... 5 Sistema de Base de Datos ........................................................................................................... 6 Base de Datos .............................................................................................................................. 7 Sistema de gestin de base de datos .......................................................................................... 8 Arquitectura de tres niveles ........................................................................................................ 9 Independencia de datos............................................................................................................ 10
Leccin 2................................................................................................................................ 11 Introduccin al Diseo de Base de Datos .............................................................................. 11

2.1 2.2 2.3 2.4 2.5 Qu es el diseo de base de datos? ........................................................................................ 11 Fases del diseo de base de datos ............................................................................................ 11 Un ejemplo sencillo de diseo de base de datos ...................................................................... 12 Modelos de Datos ..................................................................................................................... 13 Abstracciones de datos ............................................................................................................. 15
Resumen ................................................................................................................................ 17 Lectura................................................................................................................................... 18 Actividades ............................................................................................................................ 19 Autoevaluacin...................................................................................................................... 19 Exploracin On-Line.............................................................................................................. 20 Referencias Bibliogrficas ..................................................................................................... 20 UNIDAD 2..............................................................................................................................21 EL MODELO ENTIDAD-RELACIN (MER) ..........................................................................21 Leccin 3................................................................................................................................ 22 Conceptos asociados al MER ................................................................................................. 22
3.1 3.2 3.3 3.4 Qu es el MER? ....................................................................................................................... 22 Entidad y Atributo ..................................................................................................................... 22 Tipo de Entidad, Atributo Identificador y Conjunto de valores ................................................ 23 Relacin y Tipo de Relacin....................................................................................................... 25
Leccin 4................................................................................................................................ 29 Extendiendo el MER .............................................................................................................. 29

4.1 4.2 4.3 Razn de Participacin .............................................................................................................. 29 Entidades dbiles ...................................................................................................................... 30 Generalizacin o Especializacin............................................................................................... 30
Leccin 5................................................................................................................................ 35 Proceso de Construccin de un MER .................................................................................... 35

5.1 5.2 5.3 5.4 5.5 5.6 5.7 Identificar Tipos de Entidades................................................................................................... 35 Identificar Atributos .................................................................................................................. 35 Identificar Tipos de relaciones .................................................................................................. 36 Determinar Identificadores y Entidades dbiles ....................................................................... 36 Determinar Jerarquas de Generalizacin ................................................................................ 36 Revisar el Esquema Conceptual ............................................................................................. 36 Casos de ejemplo ..................................................................................................................... 37
Resumen ................................................................................................................................ 40 Lectura................................................................................................................................... 41 Actividades ............................................................................................................................ 43 Autoevaluacin...................................................................................................................... 45 Exploracin On-Line.............................................................................................................. 46 2
Csar Luza Montero
Referencias Bibliogrficas ..................................................................................................... 46 UNIDAD 3..............................................................................................................................48 EL MODELO RELACIONAL (MR) .........................................................................................48 Leccin 6................................................................................................................................ 49 Definicin y elementos del MR.............................................................................................. 49
4.1 4.2 4.3 Definicin .................................................................................................................................. 49 Elementos ................................................................................................................................. 49 Reglas ........................................................................................................................................ 51
Leccin 7................................................................................................................................ 53 Transformacin de un MER a MR ......................................................................................... 53

7.1 7.2 7.3 7.4 7.5 Transformacin de tipo de entidad........................................................................................... 53 Transformacin de tipo de relacin .......................................................................................... 53 Transformacin de entidades dbiles ....................................................................................... 55 Transformacin de generalizaciones ........................................................................................ 55 Caso Ejemplo............................................................................................................................. 56
Leccin 8................................................................................................................................ 58 Normalizacin ....................................................................................................................... 58

8.1 8.2 8.3 8.4 8.5 Definicin .................................................................................................................................. 58 Dependencias funcionales ........................................................................................................ 58 Formas normales....................................................................................................................... 59 Proceso de Normalizacin......................................................................................................... 61 Normalizacin Avanzada ........................................................................................................... 65
Resumen ................................................................................................................................ 66 Actividades ............................................................................................................................ 67 Referencias Bibliogrficas ..................................................................................................... 69 GLOSARIO .............................................................................................................................70 BIBLIOGRAFA GENERAL ....................................................................................................71
Csar Luza Montero
UNIDAD 1 INTRODUCCIN A LOS SISTEMAS DE BASE DE DATOS Y AL DISEO DE BASE DE DATOS

Qu es un Sistema de Base de datos? Qu es una Base de Datos? Qu es un Sistema de gestin de base de datos? Quines son los usuarios? En qu consiste la arquitectura de tres niveles? En qu consiste la independencia de datos? Cules son las fases del proceso de diseo de base de datos? Qu son los modelos de datos? Cmo se clasifican? Qu es abstraccin de datos? Qu tipos de abstraccin existen?
Csar Luza Montero
Leccin 1 Introduccin a los Sistemas de Base de Datos

Las organizaciones requieren de informacin para apoyar sus actividades de toma de decisiones y controlar sus operaciones rutinarias. Esta informacin se transmite en todos los niveles de la organizacin a travs de los sistemas de informacin. Uno de los componentes fundamentales de los sistemas de informacin modernos es el Sistema de Base de Datos. Su propsito es almacenar, recuperar y mantener las grandes cantidades de datos requeridos por la organizacin.
1.1
Sistema de Archivos
Tradicionalmente, para almacenar los datos, se utilizaban los llamados sistemas de archivos. En este enfoque, los archivos se diseaban para cada programa de aplicacin destinado a apoyar las actividades de un departamento especfico. Cada departamento era responsable de crear y mantener los datos en sus propios archivos a travs de sus programas de aplicacin. Por ejemplo, en la figura 1.1 se aprecia que el Dpto. de Ventas es responsable de los datos de Empleados y Clientes; el Dpto. de Personal, de los datos de Empleados y Nominas, y el Dpto. de Contabilidad, de los datos de Empleados, Clientes y Nminas.
Figura 1.1 Organizacin de los datos mediante archivos
Fuente : Elaboracin propia
Como se aprecia, esta forma de organizacin implicaba que los archivos por departamento podran contener informacin duplicada (redundancia de informacin), que ocasionaba uso inadecuado de espacio en disco y posibles inconsistencias porque un mismo dato podra reflejar diferentes valores. Asimismo, se generaba dependencia de los datos respecto del soporte fsico y los programas, que conlleva a falta de flexibilidad frente a cambios. Adicionalmente, los sistemas de archivos no eran apropiados para sistemas de ayuda a la toma de decisiones.
En lo sucesivo, en este libro, si las figuras, imgenes o tablas no consignan fuente, es porque son de propia elaboracin.
Csar Luza Montero
1.2
Sistema de Base de Datos
La idea de los sistemas de base de datos es mantener los datos en un repositorio centralizado (base de datos) evitando los inconvenientes generados por los sistemas de archivos. Cada departamento crea, mantiene y recupera la informacin de este repositorio centralizado, no de sus propios archivos (figura 1.2). Para lograr este objetivo, los sistemas de base de datos tienen un componente software, llamado sistema de gestin de base de datos (SGBD), que permite administrar este repositorio. Cada programa de aplicacin interacta con el sistema de gestin de base de datos para crear, mantener o recuperar datos de la base de datos. El SGBD se constituye en la interfaz entre los programas de aplicacin y la base de datos.
Figura 1.2 Organizacin de los datos mediante base de datos
1.2.1 Definicin
Un sistema de base de datos es una coleccin de datos interrelacionados, almacenados en conjunto, sin redundancias perjudiciales o innecesarias. Su finalidad es servir a una aplicacin o ms de la mejor manera posible. Los datos se almacenan de modo que resulten independientes de los programas que los usan. Se emplean mtodos bien definidos para incluir nuevos datos y para modificar o extraer los datos almacenados (Martin, 1975, p.19). De acuerdo con Elmasri (1997, p.3), podemos decir que un sistema de base de datos est formado por la base de datos y el sistema de gestin de la base de datos (SGBD). En la figura 1.3, podemos ver un entorno simplificado de un sistema de base de datos. Los usuarios acceden a la base de datos almacenada a travs de programas de aplicacin o consultas interactivas. El Software SGBD atiende y gestiona las solicitudes de acceso a la base de datos (repositorio). Estas solicitudes pueden incluir aadir, borrar, cambiar o consultar los datos del repositorio.
Figura 1.3 Entorno simplificado de un Sistema de Base de Datos
PROGRAMAS
SGBD Usuarios
CONSULTAS
Base de Datos
6 SISTEMA DE BASE DE DATOS
Csar Luza Montero
1.3
Base de Datos
La base de datos se constituye en el repositorio de los datos de la empresa, o de un dominio particular, que debe permanecer en el tiempo con el propsito de brindar informacin requerida para apoyar las actividades de la organizacin.
1.3.1 Definicin
Una base de datos consiste en alguna coleccin de datos persistentes e independientes, usados por una organizacin determinada (Date, 1995, p.10). En la base de datos, los datos deben estar organizados de tal manera que refleje la realidad del dominio o de la empresa en el contexto de informacin requerida. Esto implica que adems de los datos, se deben guardar las relaciones que existen entre los datos. Por ejemplo, en el dominio de la gestin de matrcula en una institucin educativa, los datos de los alumnos, asignaturas y docentes son necesarios; pero, adems es necesario guardar la relacin entre alumno con asignatura para saber las asignaturas que un alumno est llevando. Asimismo, la relacin entre docente y asignatura. Una base de datos es una coleccin de datos relacionados, y una descripcin de estos datos, diseados para cumplir con las necesidades de informacin de una organizacin (Connolly, 2008, p.17). La base de datos tambin incluye la descripcin de los datos almacenados. Dicho de otra forma, se almacena tambin la estructura de los datos. Por ejemplo, para alumno, se almacena el tipo y tamao de sus atributos: cdigo, nombre, etc. Entonces, tenemos dos mbitos dentro de la base de datos: las descripciones de los datos y los propios datos almacenados. Para ilustrar ambos aspectos, en la figura 1.4, se muestra un ejemplo de descripcin de datos de alumno, y en la figura 1.5, los datos almacenados de cuatro alumnos. Tanto la descripcin como los datos se almacenan en la base de datos.
Figura 1.4 Descripcin datos Alumno
Table ALUMNO ( Cdigo numeric (09) not null, Apellidos varchar(30), Nombres (varchar(30), Edad numeric (02), Gnero char(01) default (M, N), Primary key (cdigo) );
Figura 1.5 Datos almacenados de alumnos

ALUMNO Cdigo 2111199 2122233 2199882 2157660 Apellidos GONZALES ROJAS MARTNEZ QUISPE MUOZ RA ARIAS JUREZ Nombres JUAN PEDRO CARMEN HUGO edad 21 20 20 18 Gnero M M F M
Csar Luza Montero
1.3.2 Aplicaciones
Toda base de datos se disea, construye y puebla con datos para un propsito especifico. Est dirigida a un grupo de usuarios y tienen ciertas aplicaciones preconcebidas que interesan a dicho usuarios (Elmasri, 1997, p.2). Algunas aplicaciones son las siguientes: En la banca, para almacenar informacin de los clientes, cuentas y prstamos y transacciones bancarias. En Lneas areas, para reservas e informacin de planificacin. Las lneas areas fueron las primeras en usar las bases de datos de forma distribuida geogrficamente (los terminales situados en todo el planeta accedan al sistema de bases de datos centralizado a travs de las lneas telefnicas y otras redes de datos). En Universidades, para informacin de los estudiantes, matrculas de las asignaturas y cursos. En Transacciones de tarjetas de crdito, para compras con tarjeta de crdito y generacin mensual de extractos. En Telecomunicaciones, para guardar un registro de las llamadas realizadas, generacin mensual de facturas manteniendo el saldo de las tarjetas telefnicas de prepago y para almacenar informacin sobre las redes de comunicaciones. En Finanzas, para almacenar informacin sobre grandes empresas, ventas y compras de documentos formales financieros, como bolsa y bonos. En Ventas, para informacin de clientes, productos y compras. En Produccin, para la gestin de la cadena de produccin y para el seguimiento de la produccin de elementos en las factoras, inventarios de elementos en almacenes y pedidos de elementos. En Recursos humanos, para informacin sobre los empleados, salarios, impuestos y beneficios, y para la generacin de las nminas.
1.4
Sistema de gestin de base de datos
1.4.1 Definicin
Un Sistema de Gestin de Base de Datos (SGBD) o Data Base Management System (DBMS) es el conjunto de programas que permite a los usuarios crear y mantener una base de datos. Es decir, el SGBD facilita el proceso de definir, construir y manipular base de datos para diversas aplicaciones (Elmasri, 1997, p.2). Definir una base de datos significa especificar los tipos de datos, las estructuras y las restricciones de los datos que se almacenarn en ella. Construir una base de datos se refiere al proceso de poblar (crear y guardar) los datos en un medio de almacenamiento controlado por el SGBD. Manipular la base de datos es realizar funciones como: consultar la base de datos para obtener datos especficos, actualizar (aadir, modificar o eliminar) la base de datos para reflejar los cambios del mbito o espacio del problema (mundo real) y generar informes a partir de estos datos.
Csar Luza Montero
1.4.2 Usuarios
El sistema de gestin de base de datos se constituye en la interfaz entre los usuarios y la base de datos. Los usuarios pueden ser: usuarios finales o usuarios informticos. Los usuarios finales son aquellos que utilizan servicios de programas previamente preparados para realizar consultas o actualizaciones a la base de datos. Los usuarios informticos pueden ser: administrador de la base de datos, diseador y analista/programador. El administrador de la base de datos (Data Base Administrator, DBA) es responsable de la confidencialidad, disponibilidad, seguridad e integridad de los datos almacenados en la base de datos; vigila el buen funcionamiento del sistema de base de datos. El diseador identifica los datos que han de estar contenidos en la base de datos y determina las estructuras ms apropiadas. El analista/programador desarrolla los programas para los usuarios finales.
1.4.3 Funciones
Las funciones de un SGBD se pueden agrupar en funcin de definicin de datos, funcin de manipulacin de datos y funcin de control. La funcin de definicin de datos permite describir los elementos de datos, su estructura, sus interrelaciones y sus validaciones o restricciones a tres niveles (interno, conceptual y externo) a travs del lenguaje de definicin de datos (DDL). La funcin de manipulacin permite: consultar (Sobre la totalidad o selectiva), aadir, suprimir, modificar; lo cual supone definir normas de seguridad (administrador), definir un criterio de seleccin (usuario), definir la estructura externa a recuperar (usuario) y acceder a la estructura fsica (sistema) a travs del lenguaje de manipulacin de datos (DDL). La funcin de control rene las interfaces de los usuarios y suministra procedimientos para el administrador. Algunas funciones son: cambiar la capacidad de los ficheros, obtener estadsticas de utilizacin, obtener copias de seguridad, etc.
1.5
Arquitectura de tres niveles
Se ha establecido una arquitectura de tres niveles, llamada tambin arquitectura de tres esquemas (Elmasri, 1997, p.25). En la figura 1.6, se muestra esta arquitectura, cuyo objetivo es lograr independencia de los datos respecto de los programas de aplicacin y del almacenamiento fsico. En el nivel interno, se establece la organizacin fsica de almacenamiento de los datos, es decir la estructura de datos en disco y las rutas de acceso a los mismos considerando la velocidad en responder los requerimientos del usuario y el uso eficiente del espacio en disco. Formalmente, el artefacto en el que se define la organizacin interna de los datos se conoce como esquema interno. En el nivel conceptual, se define la estructura lgica de almacenamiento de los datos de toda la base de datos considerando que esta estructura debe reflejar los aspectos conceptuales (se omiten detalles de almacenamiento fsico), de los requerimientos de informacin del mbito o espacio de problema global (mundo real). Formalmente, el artefacto en el que se define la estructura lgica de la base de datos completa se conoce como esquema conceptual. En el nivel externo, se define la estructura lgica de la porcin de la base de datos (vista) requerida por un grupo particular de usuarios. Formalmente, a esta descripcin lgica parcial de la base datos se conoce como esquema externo.
Modelado y Diseo de Base de datos Figura 1.6 Arquitectura de tres niveles
Csar Luza Montero
USUARIOS FINALES
NIVEL EXTERNO
ESQUEMA EXTERNO 1
ESQUEMA EXTERNO n
NIVEL CONCEPTUAL
ESQUEMA CONCEPTUAL
ESQUEMA INTERNO NIVEL INTERNO
Fuente: (Elmasri, 1997)
1.6
Independencia de datos
Los sistemas de base de datos deben mantener la coherencia entre los esquemas interno, conceptual y externo, y lograr la independencia de los datos. Los datos en la base de datos se organizan independientemente de los programas que lo van a usar (independencia lgica) y del dispositivo de almacenamiento fsico (independencia fsica).
1.6.1 Independencia lgica de datos

Con la Independencia Lgica, los cambios en el esquema conceptual no afectan fuertemente el esquema externo ni el programa de aplicacin. Si hay cambios en el esquema conceptual (por ejemplo, agregar ms elementos de informacin, no afecta a las vistas o esquemas externos); si se modifica algn elemento de informacin, solo afecta a las vistas que la incluyen.
1.6.2 Independencia fsica de datos

Con la Independencia Fsica, los cambios en el esquema interno no afectan el esquema conceptual ni los esquemas externos. Si hay cambios en la organizacin interna de los datos, no se afecta al esquema conceptual global ni a las vistas. Por ejemplo, si hay cambio de versin del SGBD o migrar a otro, no hay problemas con el esquema conceptual ni con las aplicaciones.
10
Csar Luza Montero
Leccin 2 Introduccin al Diseo de Base de Datos

La forma en que los datos se organizan y se almacenan en la base de datos es vital para cubrir exitosamente las necesidades de informacin de los usuarios de una empresa y hacer uso adecuado de los recursos de almacenamiento fsico. Para lograr este objetivo, se sigue un mtodo sistemtico conocido como diseo de base de datos. En esta leccin, se realiza una breve introduccin al diseo de base de datos.
2.1
Qu es el diseo de base de datos?
El diseo de base de datos es el proceso mediante el cual se define la estructura lgica y fsica de una base de datos que cubra los requerimientos de informacin de los usuarios en una organizacin (Elmasri, 1997). La estructura lgica es la descripcin de los datos que se almacenarn en la base de datos sin considerar aspectos de implementacin. La estructura fsica es la descripcin de los datos considerando el SGBD especfico y detalles de almacenamiento fsico. En la estructura lgica, se define que se almacenar, en la estructura fsica se define como se almacenar.
2.2
Fases del diseo de base de datos
El diseo de base de datos es un proceso complejo que considera decisiones en diversos niveles. La literatura sobre base de datos descompone el proceso de diseo de base de datos en tres fases (figura 2.1): Diseo Conceptual, Diseo Lgico y Diseo Fsico.
Figura 2.1 Fases del Diseo de Base de datos REQUERIMIENTOS DE DATOS DISEO CONCEPTUAL ESQUEMA CONCEPTUAL DISEO LGICO ESQUEMA LGICO DISEO FSICO ESQUEMA FSICO
11
Csar Luza Montero
2.2.1 Diseo Conceptual

En el diseo conceptual, se utiliza como punto de partida los requerimientos de informacin planteados por los usuarios y se los expresa en un esquema conceptual. Un esquema conceptual es una descripcin concisa de la estructura de la base de datos, expresada en un lenguaje independiente del SGBD a utilizar para manipularla. El lenguaje que se utiliza para describir esquemas conceptuales se conoce como modelo conceptual. En resumen, el objetivo del diseo conceptual es describir el contenido de informacin de la base de datos y no las estructuras de almacenamiento fsico que se necesitarn para manejar esta informacin.
2.2.2 Diseo Lgico

En el diseo lgico, se utiliza el esquema conceptual elaborado en la fase de diseo conceptual y se elabora el esquema lgico. Un esquema lgico es una descripcin de la estructura de la base de datos en trminos de las estructuras de datos que puede procesar un tipo de SGBD, por ejemplo SGBD de tipo Relacional. El lenguaje que se utiliza para especificar esquemas lgicos se conoce como modelo lgico. En resumen, el diseo lgico transforma el esquema conceptual en esquema lgico; depende del tipo de SGBD que se vaya a utilizar, no depende del producto concreto.
2.2.3 Diseo Fsico

En el diseo fsico, se utiliza el esquema lgico elaborado en la fase de diseo lgico, y se elabora el esquema fsico correspondiente. Un esquema fsico es una descripcin detallada de la implementacin de una base de datos en trminos de estructura de almacenamiento internos y los mtodos utilizados para tener acceso eficiente a los datos. En resumen, el diseo fsico depende del SGBD concreto y el esquema fsico se expresa mediante su lenguaje de definicin de datos.
2.3
Un ejemplo sencillo de diseo de base de datos
Consideremos una porcin pequea de requerimientos de informacin del dominio de gestin acadmica de una Universidad. Se necesita mantener informacin de las Facultades y de los alumnos que pertenecen a ellas. En la fase de diseo conceptual, se elabora el esquema conceptual. En este ejemplo, se usa la notacin del modelo entidad relacin de Chen (1976). En la figura 2.2, se aprecia el modelo entidad relacin para reflejar los requerimientos sealados. Figura 2.2 Ejemplo de MER
APELLIDOS CODIGO NOMBRE
(1,1) (1,n)
CODIGO
NOMBRES
FACULTAD
TIENE
ALUMNO
12
Csar Luza Montero
En la fase de diseo lgico, se transforma el esquema conceptual a esquema lgico. En este ejemplo, usaremos el esquema relacional. A continuacin se aprecia el esquema lgico relacional:
FACULTAD ALUMNO
(CDIGO, NOMBRE); CLAVE PRIMARIA= CDIGO (CDIGO, APELLIDOS, NOMBRES, CDIGO, FACULTAD); CLAVE PRIMARIA=CDIGO CLAVE FORNEA = CDIGO, FACULTAD
En la fase de diseo fsico se define las tablas usando la sintaxis de SQL, como se aprecia a continuacin:
CREATE TABLE FACULTAD ( CODIGO CHAR (02) NOT NULL, NOMBRE VARCHAR (40), PRIMARY KEY (CODIGO) ); CREATE TABLE ALUMNO ( CODIGO NUMERIC (09) NOT NULL, NOMBRES VARCHAR (40), APELLIDOS VARCHAR (60), CODIGO_FACULTAD CHAR (02), PRIMARY KEY (CODIGO), FOREING KEY (CODIGO_FACULTAD) REFERENCES FACULTAD (CDIGO) );
2.4
Modelos de Datos
Durante el proceso de diseo de base de datos, se utilizan modelos de datos, en diversos niveles, para representar los requerimientos de los usuarios.
2.4.1 Definicin
De acuerdo con De Miguel (1999), un modelo de datos describe, en base a conceptos y reglas, los datos de una porcin del mundo real. En otras palabras, un modelo de datos es un conjunto de conceptos y reglas que permiten describir, a distintos niveles de abstraccin, la estructura de una base de datos, a la cual denominamos esquema.
2.4.2 Tipos
De acuerdo con las fases del proceso de diseo, los modelos de datos se pueden clasificar en: conceptuales, lgicos y fsicos. Los modelos de datos conceptuales se enfocan en describir el mundo real con independencia del tipo de SGBD y de detalles de implementacin en la mquina. 13
Csar Luza Montero
Los modelos de datos lgicos se orientan a representar los datos segn la implementacin del tipo SGBD especfico, pero sin detalles de implementacin de la mquina. Los modelos de datos fsicos se orientan a representar los datos considerando detalles de implementacin en la mquina. Otra forma de clasificar a los modelos de datos es segn los niveles de abstraccin de la arquitectura de tres niveles: Externo, Global e Interno. El modelo de datos externo representa el punto de vista de cada usuario en particular. El modelo de datos global representa el punto de vista del conjunto de usuarios de la empresa. El modelo de datos interno representa el punto de vista de la maquina.
2.4.3 Notaciones
Existen diversas notaciones para el modelo de datos. La eleccin de una depende de las condiciones en que se realizar el proceso de diseo de la base de datos y el ambiente de la organizacin. Se puede mencionar: Notacin CHEN (1976), para modelos de datos conceptuales que da especial nfasis a las relaciones entre entidades representndolas con un rombo (figura 2.3). Figura 2.3 Modelo conceptual Notacin CHEN
APELLIDOS CODIGO NOMBRE
(1,1) (1,n)
CODIGO
NOMBRES
FACULTAD
TIENE
ALUMNO
Notacin IE (Information Engineering) desarrollada inicialmente por Clive Finkelstein (1992) quien, luego, la refin con el apoyo de James Martin. Aunque es clara e intuitiva, sirve solo para modelos de alto nivel de abstraccin (modelos conceptuales y lgicos), pues no permite modelar los atributos de las entidades (Figura 2.4). Figura 2.4 Modelo conceptual Notacin IE
FACULTAD CODIGO NOMBRE ALUMNO CODIGO NOMBRES APELLIDOS
TIENE
Notacin UML (Unified Modeling Language): si bien es un lenguaje de modelado objetual, se puede extender a travs de perfiles para soportar otro tipo de modelos, como el modelo de datos (Booch, 1999) (figura 2.5).
14
Modelado y Diseo de Base de datos Figura 2.5 Modelo conceptual Notacin UML
Csar Luza Montero
2.5
Abstracciones de datos
El modelado de datos se realiza en base a abstracciones. La abstraccin consiste en seleccionar caractersticas relevantes de un conjunto de objetos o elementos del dominio del problema y excluir otras no pertinentes. A travs de ellas se establecen vnculos entre los elementos del modelo. Se puede establecer los siguientes tipos de abstracciones: Clasificacin, Asociacin, Generalizacin y Agregacin.
2.5.1
Abstraccin de Clasificacin
Mediante la clasificacin se abstrae las caractersticas comunes a un conjunto de elementos u objetos del mundo real para crear una categora (clase o tipo) a la cual pertenecen dichos elementos. Se corresponde con el concepto de pertenencia a un conjunto. Se utiliza para definir un concepto como una clase de objetos de la realidad caracterizados por propiedades comunes. Por ejemplo, considere los siguientes elementos u objetos del dominio de Gestin Acadmica de una Universidad: Anlisis de Sistemas, Base de datos I, Matemtica I, Fsica I y Fundamentos de informtica; todas ellas pertenecen a una clase o tipo que podemos llamar: ASIGNATURA (Figura 2.6).
Figura 2.6 Proceso de clasificacin
Anlisis de Sistemas
Fsica I
CLASIFICACIN ASIGNATURA
Fundamentos de informatica Matemtica I Base de datos I
Los mismos objetos admiten clasificaciones distintas. Por ejemplo, podemos clasificar las asignaturas de varias maneras: obligatorias / electivas, de primer ciclo, segundo ciclo, etc., tericas / prcticas, etc.
2.5.2 Abstraccin de Agregacin

Mediante la agregacin se construye una nueva clase o tipo o categora de objetos a partir de un conjunto de otras clases denominadas componentes o partes. Define una nueva clase de 15
Csar Luza Montero
objetos a partir de un conjunto de clases (otras, no necesariamente distintas) que representan sus partes componentes. Por ejemplo: CPU, Teclado, Mouse, Monitor son partes de Computadora (figura 2.7). En otras palabras, una Computadora est compuesta por Mouse, CPU, Teclado y Monitor. Figura 2.7 Proceso de agregacin
CPU MONITOR
MOUSE
AGREGACIN COMPUTADORA
TECLADO
Una Clase ES PARTE DE otra clase
2.5.3 Abstraccin de Generalizacin

Mediantes la generalizacin se aabstrae las caractersticas comunes a varias clases (subclases) para construir una clase ms general (superclase). Define una relacin de subconjunto entre elementos de dos o ms clases. Por ejemplo, Secretaria, Tcnico, Ingeniero son tipos de Empleados (figura 2.8). Figura 2.8 Proceso de Generalizacin GENERALIZACIN
SECRETARIA INGENIERO TECNICO
EMPLEADO
Una Clase ES UN TIPO DE otra clase
2.5.4 Abstraccin de Asociacin

Mediante la abstraccin de asociacin se vincula dos o ms clases crendose un elemento de tipo distinto (Vnculo). Puede parecerse a la agregacin, pero posee rasgos distintivos. Por ejemplo PROFESOR imparte ASIGNATURA figura 2.9). Figura 2.9 Asociacin ASOCIACIN: IMPARTE PROFESOR ASIGNATURA
16
Csar Luza Montero
Resumen
Introduccin a los sistemas de base de datos
Un Sistema de base de datos est formado por: la base de datos y el sistema de gestin de base de datos. Una base de datos consiste en alguna coleccin de datos persistentes e independientes, usados por una organizacin determinada. Un sistema de gestin de base de datos (SGBD) o Data Base Management System (DBMS) es el conjunto de programas que permite a los usuarios crear y mantener una base de datos. Los usuarios pueden ser usuarios finales y usuarios informticos. Los usuarios finales usan los programas preparados previamente para consultas o actualizar la base de datos. Los usuarios informticos pueden ser administrador de la base de datos, diseador de base de datos y anlisis programador de aplicaciones. Las funciones de un SGBD son: definicin de datos, manipulacin de datos y control. La funcin de definicin permite describir los elementos de datos. La funcin de manipulacin permite consultar y actualizar la base de datos. La funcin de control est dirigida a la administracin de la base de datos. La arquitectura de tres niveles considera: nivel interno, nivel conceptual y nivel externo. En el nivel interno se establece la organizacin fsica de almacenamiento de los datos, conocido como esquema interno. En el nivel conceptual se define la estructura lgica de almacenamiento de los datos de toda la base de datos, conocido como esquema conceptual. En el nivel externo se define la estructura lgica de la porcin de la base de datos (vista) requerida por un gripo particular de usuarios, conocido como esquema externo. La Independencia Lgica, permite que los cambios en el esquema conceptual no afectan fuertemente en el esquema externo ni el programa de aplicacin. La Independencia Fsica, permite que los cambios en el esquema interno no afectan el esquema conceptual ni a los esquemas externos.
Introduccin al diseo de base de datos

El diseo de base de datos es el proceso mediante el cual se define la estructura lgica y fsica de una base de datos que cubra los requerimientos de informacin de los usuarios. La estructura lgica es la descripcin de los datos sin considerar aspectos de implementacin. La estructura fsica es la descripcin de los datos considerando el SGBD especfico y detalles de almacenamiento fsico. El proceso de de diseo tiene tres fases: Diseo conceptual, Diseo Lgico y Diseo Fsico. En el diseo conceptual, los requerimientos se expresan en un esquema conceptual, descripcin concisa de la estructura de la base de datos, independiente del SGBD (modelo conceptual). En el diseo lgico, el esquema conceptual se transforma en esquema lgico, descripcin de la estructura de la base de datos en trminos de las estructuras de datos que puede procesar un tipo de SGBD (modelo lgico). En el diseo fsico, el esquema lgico se transforma en esquema fsico, descripcin detallada de la implementacin de una base de datos en trminos de estructura d almacenamiento internos y los mtodos utilizados para tener acceso a los datos. Un modelo de datos es un conjunto de conceptos y reglas para describir la estructura de una base de datos, en distintos niveles de abstraccin. Se clasifican en: Conceptuales, Lgicos y Fsicos. El Conceptual se enfoca en describir el mundo real con independencia del tipo de SGBD y de detalles de implementacin en la mquina. El lgico se orienta a representar los datos segn la implementacin del tipo SGBD especfico, pero sin detalles de implementacin de la mquina. El fsico se orientan a representar los datos considerando detalles de implementacin en la mquina. La abstraccin de datos consiste en seleccionar caractersticas relevantes en un dominio y excluir otras no pertinentes. Existen cuatro tipos de abstraccin: Clasificacin, Agregacin, Generalizacin, y Asociacin. Mediante la clasificacin un conjunto de objetos con las mismas caractersticas se abstraen en una clase de objetos. La agregacin define una nueva clase de objetos a partir de otras que representan sus partes o componentes. La generalizacin define una nueva clase de objetos a partir las caractersticas comunas de otras que representan sus subclases. Mediante la asociacin se establece un vnculo entre dos clases de objetos.
17
Csar Luza Montero
Lectura
Oficina Estatal de Licencias y Registro de Vehculo (*) Ahora consideremos una aplicacin aun mayor de las tecnologas de base de datos: una oficina estatal de licencias y registro de vehculo. Tiene 52 centros de pruebas de manejo, expedicin de licencias para conductores, renovacin de licencias de manejo, y tambin 37 oficinas que expiden registros de vehculos. El personal tiene acceso a una base de datos para realizar su trabajo. Antes que a las personas se les otorgue o renueve su licencia de conducir, hay que verificar su registro en la base de datos para buscar posibles infracciones de trnsito, accidentes o arrestos. Estos ltimos datos se utiliza para determinar si la licencia debe o no ser renovada, o si se debe otorgar con ciertas limitaciones. De igual manera, el personal del departamento de registro de automviles tiene acceso a la base de datos para determinar si un auto ha sido registrado antes y, si es as, quien lo registro, o si existe algn asunto importante que impide expedir el registro. Esta base de datos tiene ciento de usuarios, incluyendo no solo al personal de las licencias y registros, sino al del departamento tal de contribuciones y del departamento jurdico. No es de extraar que la base de datos sea grande y compleja, con ms de 40 diferentes tablas de datos, muchas de las cuales contienen cientos de miles de filas. La base de datos de las grandes organizaciones, como la oficina de licencias y registros, fueron las primeras aplicaciones de este tipo de tecnologa. Estos sistemas han existido durante 20 o 30 aos y se han modificado para satisfacer los cambios que ocurrieron durante ese periodo. Otros ejemplos de bases de datos organizacionales se relacionan con el procesamiento de cuentas en bancos e instituciones financieras, sistemas de produccin y de suministro de material en fbricas grandes, procesamiento de registros mdicos en hospitales, y en compaas de seguros y agencias gubernamentales. Actualmente muchas organizaciones estn adaptando sus aplicaciones de bases de datos para permitir a los clientes tener acceso, e incluso cambiar sus datos, por medio de internet. Si usted llegar a trabajar en una gran organizacin importante, probablemente le podran asignar ese proyecto.
(*) Fuente: (Kroenke, 2003, p.8)
18
Csar Luza Montero
Actividades
1. Realice una bsqueda en internet, ubique un sistema de gestin de base de datos LIBRE y descrguelo. 2. Descargue de internet un software libre para modelar base de datos.
Autoevaluacin
1. Con respecto al concepto de Sistema de Base de Datos, entre los parntesis de la siguiente lista, marque V=Verdadero o F=Falso, segn corresponda: a. ( ) Est compuesto por base de datos y SGBD. b. ( ) Est formado por base de datos y DBA c. ( ) Solo es un repositorio donde se almacenan los datos d. ( ) Es el conjunto de usuarios y programas para hacer consultas e. ( ) Es el software que atiende a las solicitudes de acceso a la base de datos. Con respecto al concepto de Base de Datos, entre los parntesis de la siguiente lista, marque V=Verdadero o F=Falso, segn corresponda: a. ( ) Esta compuesto por programas y datos b. ( ) Es una coleccin de datos temporales usados por una organizacin c. ( ) Es un conjunto de datos persistentes requeridos por una organizacin d. ( ) Es un almacn que guarda datos y las relaciones entre los datos. e. ( ) Guarda datos, relaciones y la descripcin de los datos y relaciones. Respecto al concepto de SGBD, marque V=Verdadero o F=Falso segn corresponda: a. ( ) Conjunto de usuarios b. ( ) Conjunto de programas c. ( ) Permite crear la base de datos d. ( ) Permite compilar los programas para los usuarios finales e. ( ) Es el conjunto de datos almacenados sin redundancias perjudicial Con respecto a la arquitectura de tres niveles, entre los parntesis de la siguiente lista coloque I=Nivel Interno, C=Nivel conceptual o E=Nivel Externo, segn corresponda: a. ( ) Estructura lgica de almacenamiento de toda la base de datos b. ( ) Su descripcin se llama esquema externo c. ( ) Estructura lgica de una porcin de la base de datos d. ( ) Considera detalle de implementacin e. ( ) Considera el uso eficiente de espacio en disco Establezca la relacin de concepto y su descripcin, colocando la letra de la descripcin en la celda a la derecha del Concepto: Concepto Descripcin del concepto. 1. Independencia a) Su resultado es el esquema conceptual obtenido a partir de los Lgica requerimientos de informacin de los usuarios 2. Independencia b) Descripcin de la estructura de la base de datos considerando el Fsica tipo de SGBD 3. Diseo c) Si hay cambio de versin en el SGBD no afecta a esquema Conceptual conceptual ni a las aplicaciones 4. Diseo Lgico d) Depende del SGBD para elabora el esquema fsico 5. Diseo Fsico 6. Esquema Conceptual e) Descripcin de los datos considerando detalles de implementacin f) Los cambios en el esquema conceptual no afecta a los programas de aplicacin
2.
3.
4.
5.
19

7. Esquema Lgico 8. Esquema Fsico 6.
Csar Luza Montero
g)
Se transforma el esquema conceptual en esquema lgico
h) Descripcin concisa de la estructura de la base de datos independiente del SGBD
Con respecto a los tipos de abstraccin, entre los parntesis de la siguiente lista coloque C=Abstraccin de Clasificacin, A=Abstraccin de Agregacin, G=Abstraccin de Generalizacin o V=Abstraccin de Asociacin, segn corresponda: a. b. c. d. e. 1. 2. 3. 4. 5. 6. ( ( ( ( ( ) Csar Luza, Pedro Carpio y Pedro Alvarado son Personas ) Docente, Alumno y Empleado son Personas ) Pas est formado por Departamentos ) Profesor asignado a Facultad ) Proveedor y Cliente son tipos de Agente Comercial
Respuestas de Control
a = V, b = F, c = F, d = F, e = F a = F, b = F, c = V, d = V, e = V a = F, b = V, c = V, d = F, e = V a = C, b = E, c = E, d = I, e = I 1 = f, 2 = c, 3 = a, 4 = g, 5 = d, 6 = h, 7 = b, 8 = e a = C, b = G, c = A, d = V, e = G
Exploracin On-Line
Microsoft SQL Server 2008 http://www.microsoft.com/latam/sqlserver/ Oracle : http://www.oracle.com/index.html MySQL http://www.mysql.com/
Referencias Bibliogrficas
1. 2. 3. 4. 5. 6. 7. 8. 9. Booch, G., Rumbaugh, J. y Jacobson, I. (1999) El lenguaje unificado de modelado. Madrid. Addison Wesley Iberoamericana. Chen, Peter (1976), The entety-relationship model:Towards a unified view of data. ACM Trans. Database systems 1 (1) 9-36 Connolly, Thomas y Begg, Carolyn. (2008) Database Solutions. 5ta. Ed. Massachusetts. Addison Wesley. Date, C. (1995) An introduction to data base systems. 5ta. Ed. Massachusetts. Addison Wesley. De Miguel A. y Piattini M., (1999) Fundamentos y Modelos de Base de datos. 2da. Ed. Madrid. Alfa y Omega. Elmasri, Ramez y Shamkant Navathe (1997) Sistemas de Bases de Datos. Conceptos fundamentales. Segunda Edicin, Madrid, Addison-Wesley Iberoamericana. Finkelstein, C. (1992) Strategic systems development. Sydney: Addison-Wesley. Kroenke, David M. (2003) Procesamiento de base de datos. Fundamentos, diseo e implementacin. Mxico. Pearson Educacin. Martin, James. (1975) Computer Data Base Organization. New Jersey. Prentice Hall.
20
Csar Luza Montero
UNIDAD 2 EL MODELO ENTIDAD-RELACIN (MER)

Qu es el MER? Cules son sus elementos? Cmo se representan? Cul es la diferencia entre entidad y tipo de entidad? Qu es un atributo Qu significa atributo Identificado? Cul es la diferencia entre Relacin y Tipo de Relacin? Qu es Razn de Cardinalidad o Tipo de correspondencia? Qu tipos hay? Qu es Razn de participacin o Cardinalidad mnima y mxima? Qu son los atributos de una relacin? Cmo se representan? Qu son las entidades dbiles? Cmo se representan? Qu es una generalizacin? Qu es una especializacin? Cmo se representan?
21
Csar Luza Montero
Leccin 3 Conceptos asociados al MER

3.1 Qu es el MER?
El MER (Modelo Entidad Relacin) es un modelo de datos conceptual propuesto por Peter Chen (1976). Se han realizado extensiones y aportaciones por otros autores. El MER describe, de manera concisa, los requisitos de informacin de los usuarios como un conjunto de entidades y sus atributos, las relaciones entre las entidades y las restricciones que ellas deben cumplir. No se consideran detalles de implementacin, permitiendo una comunicacin ms adecuada entre desarrolladores y usuarios no tcnicos. Los elementos bsicos del MER incluyen Tipo de Entidad, Tipo de Relacin y Atributos. Las extensiones consideran representaciones para entidad dbil, generalizacin, entre otros.
3.2
Entidad y Atributo
3.2.1 Entidad
El elemento bsico en el MER es la entidad. Una Entidad es una persona, lugar, cosa, concepto o suceso, real o abstracto, de inters para la empresa (ANSI2, 1977). Una entidad es una cosa u objeto en el mundo real que es distinguible de otros objetos (Korth, 2002, p.5). Por ejemplo, una persona, un alumno, el libro Anlisis de sistemas, un empleado, una asignatura, la asignatura Base de datos 1, un viaje, etc. En la figura 3.1, se representa una entidad persona.
Figura 3.1 Una Persona
3.2.2 Atributo
Cada entidad tiene propiedades especficas llamadas atributos que la describen. Un atributo es una propiedad o caractersticas de una entidad. Una entidad particular es descrita por los valores de sus atributos dentro del tipo de entidad. Por ejemplo, una entidad PERSONA puede describirse por su DNI, Nombre, Apellidos, Gnero, Estatura, Peso, Fecha de nacimiento. Una persona particular tendr un valor para cada uno de sus atributos. As dos entidades Persona con sus valores para cada atributo son: 06111988, CSAR, LUZA MONTERO, M, 1,70 m., 76 kg, 06-02-1959. 05879997, PEDRO, CARPIO FARFN, M, 1,76 m., 76 kg, 03-03-1959. Otro ejemplo: Considere el Tipo de entidad ALUMNO con los siguientes atributos: Cdigo. Nombre, Edad, Ciclo; a continuacin se muestra una porcin del conjunto de alumnos:
2
ANSI = American National Standards Institute, <http://www.ansi.org/> Instituto de estndares Americano
22
Modelado y Diseo de Base de datos (21-223333-23, Sofa, 18 aos, 2) (21-333333-44, Josefa, 19 aos, 5) (21.555555-55, Gabriela, 20 aos, 2)
Csar Luza Montero
Cada una de las entidades pertenecientes a este conjunto se diferencia de las dems por el valor de sus atributos. Ntese que dos o ms entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos.
3.3
Tipo de Entidad, Atributo Identificador y Conjunto de valores
Un Tipo de entidad define un conjunto de entidades que poseen los mismos atributos (Elmasri, 1997). Por ejemplo, el conjunto de entidades personas forman el tipo de entidad PERSONA (Figura 3.2).
Figura 3.2 Conjunto de personas, tipo de entidad PERSONA
Otros ejemplos de tipo de entidad son: LIBRO, EMPLEADO, ASIGNATURA, VIAJE. Desde el punto de vista de la abstraccin de clasificacin, el tipo de entidad describe un conjunto de entidades como resultado de la clasificacin, cada entidad es un elemento del tipo de entidad. En la figura 3.3, se observa cinco entidades que se clasifican en el tipo de entidad Asignatura.
Figura 3.3 Entidades y Tipo de entidad por abstraccin de clasificacin
Anlisis de Sistemas
Fsica I
CLASIFICACIN ASIGNATURA
Fundamentos de informtica Matemtica I Base de datos I
Un tipo de entidad est formado por un conjunto de entidades, a los elementos de este conjunto tambin se le conoce como instancias de tipo de entidad. Por ejemplo, anlisis de sistemas es una instancia del tipo de entidad ASIGNATURA.
3.3.1 Notacin de Tipo de Entidad

La notacin Chen (1976) para un tipo de entidad es un rectngulo con el nombre del tipo de entidad en el interior (figura 3.4):
Figura 3.4 Notacin de Tipo de entidad (Chen, 1976) PERSONA
23
Csar Luza Montero
En la figura 3.5, se aprecia la notacin IE (Finkelstein, 1992) para un tipo de entidad.

Figura 3.5 Notacin de Tipo de entidad segn IE
PERSONA
En la figura 3.6, se observa algunos ejemplos de tipos de entidad para un sistema acadmico:
Figura 3.6 Ejemplos de Tipo de entidad
ALUMNO PROFESOR ASIGNATURA
MATRICULA
AULA
HORARIO
3.3.2 Atributo Identificador de un tipo de entidad

Los tipos de entidades casi siempre tienen un atributo cuyo valor es distinto para cada entidad individual, denominado atributo identificador. Un atributo identificador es aquel atributo que permite distinguir a una entidad de otra distinta. Por ejemplo, el atributo identificador que distingue a un alumno de otro es su cdigo, el DNI es el atributo identificador del tipo de entidad Persona.
3.3.3 Notacin de atributo de un tipo de entidad

La notacin Chen (1976) para atributos es un crculo con el nombre especfico. El atributo identificador se denota con el circulo sombreado (Figura 3.7).
Figura 3.7 Notacin de atributos segn Chen
En la figura 3.8, se aprecia la notacin IE (Finkelstein, 1992) para atributos.

Figura 3.8 Notacin de atributo segn IE
ALUMNO Codigo Nombre Edad Ciclo
24
Csar Luza Montero
3.4
Relacin y Tipo de Relacin
3.4.1 Relacin
Una Relacin, tambin llamada interrelacin, es una asociacin, vnculo o correspondencia entre entidades relacionadas de alguna manera en un contexto determinado. Ejemplos: El profesor Jos Cruz ensea la asignatura Fundamentos de informtica El profesor Cesar Luza ensea la asignatura de Base de datos I El cliente Juan Prez realiza el pedido 34677 El cliente Jos Quiroz realiza el pedido 17450 El producto Tornillo se almacena en el almacn Central
3.4.2 Tipo de Relacin

Un Tipo de Relacin es la abstraccin del conjunto de relaciones existentes entre dos o ms tipos de entidad. Ejemplos: PROFESOR ensea ASIGNATURA. CLIENTE realiza PEDIDO PRODUCTO se almacena en ALMACN
La notacin Chen (1976) para un tipo de relacin es un rombo que une a los tipos de entidades asociadas (figura 3.9).
Figura 3.9 Notacin de tipo de relacin segn Chen (1976)
La figura 3.10 muestra la notacin IE para un tipo de relacin.

Figura 3.10 Notacin de tipo de relacin segn IE
PROFESOR ASIGNATURA
ENSE A
En la figura 3.11, se observa algunos ejemplos de tipo de relacin para un sistema acadmico.
Figura 3.11 ejemplos de tipo de relacin
Entre dos tipos de entidades puede establecer ms de un tipo de relacin. En la figura 3.12, se observa dos relaciones entre persona y edificio. El tipo de relacin Persona USA Edificio significa que una persona es usuaria del edificio. El tipo de relacin Persona POSEE Edificio 25
Csar Luza Montero
significa que la persona es propietaria del edificio. Ambas relaciones se modelan porque es de inters la informacin de quien es el propietario y quines son los usuarios.
Figura 3.12 Dos tipos de relacin entre dos tipos de entidad
3.4.3 Grado de un Tipo de Relacin

El grado de un tipo de relacin es el nmero de tipos de entidad que participan en el tipo de relacin. En la figura 3.13, se aprecia un ejemplo de tipo de relacin binaria o de grado 2, es el ms frecuente, se interpreta como: actor acta en pelcula. En la figura 3.14, se muestra un ejemplo de tipo relacin de grado 3 o ternaria, se interpreta como: El cliente alquila pelcula un local del videoclub. En la figura 3.15, se presenta un ejemplo de tipo de relacin de grado 1 o unaria, se interpreta como: la pelcula es continuacin de otra pelcula.
Figura 3.13 Tipo de relacin binaria (Grado 2)
Figura 3.14 Tipo de relacin ternaria (Grado 3)
Figura 3.15 Tipo de relacin unaria (Grado 1)
3.4.4 Nombre de Rol

Todo tipo de entidad que participa en un tipo de relacin juega un papel especfico en la relacin. Los nombres de rol ayudan a explicar el significado de la relacin, por eso su uso es casi obligatorio en los tipos de relacin unarias, para evitar la ambigedad. En figura 3.16, el tipo de relacin Continuacin de establece el vinculo entre dos pelculas, una de ellas juega el rol de original, y la otra juega el rol de continuacin.
Figura 3.16 nombre de rol
Original Continuacin
26
Csar Luza Montero
3.4.5 Restricciones Estructurales 3

Las restricciones estructurales son reglas que limitan las posibles combinaciones de entidades que pueden participar en las relaciones. Son extradas de la situacin real que se modela. Por ejemplo, Una asignatura puede ser dictada por uno o ms profesores y Un profesor puede dictar ms de una asignatura, son reglas que deben cumplir los datos que se almacenaran en la base de datos de un sistema acadmico. Las restricciones bsicas en el MER se conocen como Razn de cardinalidad o Tipo de Correspondencia. La Razn de cardinalidad o Tipo de correspondencia es el nmero mximo de instancias o entidades de un tipo de entidad que puede estar relacionado con una instancia de otro tipo de entidad. Puede ser de tres tipos de correspondencia: 1 a 1, Uno a Uno. 1 a N, Uno a Mucho y M a N, Muchos a Muchos El Tipo de correspondencia 1 a 1 (Uno a Uno) significa que una instancia de un tipo de entidad est vinculada a lo ms con una instancia del otro tipo de entidad asociada y viceversa. Por ejemplo el tipo de relacin DECANO dirige FACULTAD es de Uno a Uno, porque un Decano dirige una sola Facultad, adems una Facultad es dirigida por solo un Decano (Figura 3.17).
Figura 3.17 Ejemplo Tipo de Relacin Uno a Uno
Notacin Chen
Notacin IE
DECANO
DIRIGE
FACULTAD
El Tipo de correspondencia 1 a N (Uno a Muchos) significa que una instancia de un tipo de entidad est vinculada a lo ms con varias instancias del otro tipo de entidad asociada. Por ejemplo el tipo de relacin FACULTAD tiene ALUMNO es de Uno a Muchos, porque una Facultad tiene muchos Alumnos, adems un Alumno pertenece solo a una Facultad (Figura 3.18).
Figura 3.18 Ejemplo Tipo de Relacin Uno a Muchos
FACULTAD
T IENE
ALUMNO
En adelante, se usa notacin Chen y su equivalente en notacin IE.
27
Csar Luza Montero
El Tipo de correspondencia M a N (Muchos a Muchos) significa que una instancia de un tipo de entidad est vinculada a lo ms con varias instancias del otro tipo de entidad asociada, y viceversa. Por ejemplo el tipo de relacin ALUMNO lleva ASIGNATURA es de Muchos a Muchos, porque un Alumno lleva varias Asignaturas, adems una Asignatura es llevada por varios Alumnos (Figura 3.19).
Figura 3.19 Ejemplo Tipo de Relacin Muchos a Muchos
ALUMNO
LLEVA
ASIGNATURA
3.4.6 Atributos de una relacin

Un tipo de relacin puede tener atributos, conceptualmente pertenecen al tipo de relacin. Un atributo de un tipo relacin M:N es propio del tipo de relacin. En cambio, un atributo de un tipo relacin 1:1 o 1:N se puede llevar a uno de los tipos de entidad participantes. En la figura 3.22 se muestra notacin Chen para atributos de una relacin.
Figura 3.22 Atributos de una relacin
ACTOR
ACTUA Papel Salario
PELICULA
28
Csar Luza Montero
Leccin 4 Extendiendo el MER

4.1 Razn de Participacin
En el modelo MER bsico de Chen, otros autores han agregado ms detalles para representar restricciones estructurales que se conocen como Razn de Participacin o Cardinalidad Mnima y Mxima. La Razn de Participacin o cardinalidad mnima y mxima de una relacin, son los nmeros mnimo y mximo de instancias de tipo de relacin en las que puede intervenir una instancia del tipo de entidad participante. Se denota mediante (min., mx.) en la lnea que une el tipo de entidad con el tipo de relacin. Por ejemplo, consideremos la relacin Facultad tiene Alumno, una Facultad como mnimo tiene un alumno y como mximo muchos alumnos; adems, un alumno como mnimo pertenece a una Facultad y como mximo a una sola (figura 3.20).
Figura 3.20 Ejemplo Razn de participacin
FACULTAD
T IENE
ALUMNO
Ahora, consideremos la relacin Alumno lleva Asignatura, un alumno como mnimo lleva cero asignaturas (puede no matricularse en un semestre), como mximo puede llevar muchas asignaturas; adems, una asignatura como mnimo tiene cero alumnos (cuando la asignatura se cancela o no se programa) y como mximo muchos alumnos (figura 3.21).
Figura 3.21 Otros ejemplo Razn de participacin
ALUMNO
LLEVA
ASIGNATURA
29
Csar Luza Montero
4.2
Entidades dbiles
En ocasiones, una entidad no tiene por s misma datos suficientes como para poder identificarla. Por ejemplo, las aulas de una Facultad se pueden identificar por nmero de aula, pero los nmeros podran repetirse en otra Facultad. En este caso diremos que el tipo de entidad AULA es dbil respecto de FACULTAD (entidad fuerte).
4.2.1 Definicin
Una entidad dbil es aquella que no tiene atributo identificador propio. Su existencia depende de otra entidad (fuerte) que la posee y la identifica inequvocamente. Ejemplo: Provincia es entidad dbil de departamento, para identificar una provincia se necesitar el nombre de la provincia y del departamento. En el contexto de la planilla de una empresa, FAMILIAR depende de EMPLEADO, Familiar es entidad dbil porque depende de Empleado.
4.2.2 Notacin
Una entidad dbil se representa con un rectngulo de doble lnea, con el nombre al interior. En la figura 4.1 se muestra la entidad dbil familiar que depende de Empleado.
Figura 4.1 Notacin de entidad dbil
EMPLEADO
(1,1)
E Tiene dependientes
(0,n)
FAMILIAR
EMPLEADO
T IENE_DEPEDIENT ES
FAMILIAR
4.3
Generalizacin o Especializacin
4.3.1 Definicin
La generalizacin es caso especial de relacin entre un tipo de entidad y varios otros tipos de entidad. La jerarqua o relacin que se establece entre uno y otros corresponde a la nocin de es_un o de es_un_tipo_de. Estas jerarquas pueden formarse por especializacin o bien por generalizacin. Por ejemplo: Un ANIMAL es un FELINO, es una jerarqua obtenida por Especializacin, de arriba hacia abajo. Un REPTIL es un tipo de ANIMAL; Un INSECTO es un tipo de ANIMAL son jerarquas obtenidas por Generalizacin. El proceso de generalizacin se caracteriza por el nfasis en las similitudes de los subtipos y cada instancia del supertipo es tambin una instancia de algunos de los subtipos.
30
Csar Luza Montero
El proceso de especializacin se caracteriza por las diferencias de los subtipos y alguna instancia del supertipo puede no ser instancia de ningn subtipo.
4.3.2 Notacin 4
La generalizacin o especializacin se representa con un triangulo, en la figura 4.2, representa que Secretario es un tipo de Empleado, de igual forma Gerente y Comercial son tipos de Empleados.
Figura 4.2 Notacin de generalizacin
EMPLEADO
SECRETARIO
GERENTE
COMERCIAL
4.3.3 Subtipo y Supertipo

En una relacin de generalizacin, el subtipo es un tipo de entidad que agrupa a las instancias dentro de otro tipo de entidad, llamado supertipo, que debe representarse explcitamente debido a su importancia para el diseo o aplicacin Ejemplos: Los Subtipos de VEHCULO son: CAMIN, TURISMO, AUTOBS y CICLOMOTOR. Los Subtipos del tipo de entidad EMPLEADO son: SECRETARIO, GERENTE COMERCIAL El supertipo es el tipo de entidad que se especializa en otros o se generaliza de otros. En los ejemplos anteriores VEHCULO y EMPLEADO son supertipo. La extensin o conjunto de entidades de un subtipo es un subconjunto de la extensin del supertipo. Es decir, una instancia o entidad de un subtipo tambin es instancia del supertipo y es la misma instancia, pero con un papel especfico distinto. Una instancia no puede existir slo por ser miembro de un subtipo: tambin debe ser miembro del supertipo. Una instancia del supertipo puede no ser miembro de ningn subtipo. En la figura 4.3 se muestra tres subtipos de vehculo, pero pueden existir otros tipos que no estn representados, por ejemplo AUTO.
La notacin Chen que utilizamos, en esta leccin, se basa en De Miguel (1999).
31
Csar Luza Montero
Figura 4.3 Supertipo Vehculo y subtipos Camin, Turismo y Ciclomotor
4.3.4 Herencia de tipo

En la generalizacin, un subtipo puede tener atributos propios (especficos) y participar en relaciones por separado. Un subtipo hereda todos los atributos del supertipo, y toda relacin en la que participa el supertipo. Un subtipo, con sus atributos y relaciones especficos, ms los atributos y relaciones que hereda del supertipo, es un tipo de entidad por derecho propio. En la figura 4.4, se muestra un ejemplo de subtipos con atributos propios y relaciones independientes.
Figura 4.4 Subtipos con atributos propios y relaciones independientes
Nmero (1,1) Fabricado FABRICANTE
Precio
VEHICULO (0,1) ISA 1 (0,1) (0,1) TURISM O
(1,n)
(0,1) BICICLETA (1,1) ID lle v a
(0,1) SIDECAR
CAM ION
NumEjes
NumPuertas
4.3.5 Restricciones de definicin

En el modelado de generalizacin o especializacin algunas veces es importante definir que instancias del supertipo pertenecen a cada subtipo, esto se conoce como Restriccin de definicin. Por ejemplo, en la figura 4.5, se utiliza un atributo del supertipo: claseTrabajo, para discriminar la que subtipo pertenecen las instancias del supertipo. Una instancia del supertipo Empleado_Hospital, segn el valor que tome el atributo claseTrabajo, ser pertenecer a Medico, Celador, Enfermero o Limpiador. El atributo claseTrabajo se conoce como Atributo Discriminante.
Figura 4.5 Ejemplo de atributo discriminante
32
Csar Luza Montero
4.3.6 Restricciones de Disyuncin y Solapamiento

Permite determinar a cuntos subtipos puede pertenecer (a la vez) una instancia del supertipo dentro de una relacin de generalizacin. Los subtipos son disjuntos si una instancia del supertipo puede ser miembro de cmo mximo uno de los subtipos. En la figura 4.6 se representa a los subtipos disjuntos mediante un arco, significa que una instancia de VEHCULO puede ser pertenecer al subtipo Turismo o Camin, pero no a ambas.
Figura 4.6 Ejemplo de Disyuncin
Los Subtipos son solapados si una instancia del supertipo puede ser, a la vez, miembro de ms de un subtipo. Es la opcin por defecto. En la figura 4.7, una instancia de Persona puede pertenecer a Empleado y a estudiante a la vez.
Figura 4.7 Ejemplo de Solapamiento
4.3.7 Restricciones de Completitud y Parcialidad

Permite determinar si toda instancia del supertipo debe pertenecer a algn subtipo en la relacin de generalizacin. La Especializacin total (completa) indica que toda instancia del supertipo tambin debe ser instancia de algn subtipo. En la figura 4.8, todas las instancias del supertipo Animal, pertenecen a algn subtipo; es decir, un animal es macho o es hembra o es hermafrodita. La totalidad se representa con el pequeo crculo cerca del supertipo.
Figura 4.8 Ejemplo de Completitud
33
Csar Luza Montero
La Especializacin parcial indica que es posible que alguna instancia del supertipo no pertenezca a ninguno de los subtipos. Es la opcin por defecto. La unin de las extensiones de los subtipos no es la extensin del supertipo en su totalidad. En la figura 4.9, existen algunas instancias del supertipo Alimento que no pertenecen a ninguno de los subtipos representados.
Figura 4.9 Ejemplo de Parcialidad
34
Csar Luza Montero
Leccin 5 Proceso de Construccin de un MER

El proceso de construccin de un MER corresponde a la fase de Diseo Conceptual de una base de datos. El artefacto de entrada para el diseo conceptual es la especificacin de requerimientos de informacin obtenidos del mundo real (dominio de la aplicacin o del negocio). El artefacto de salida del diseo conceptual se conoce como esquema conceptual (un ejemplo es el modelo entidad-relacin). Se pueden considerar las siguientes actividades para el proceso de construccin de un MER (Diseo Conceptual): Identificar tipo de entidades, Identificar atributos para cada tipo de entidad, identificar tipos de relaciones, determinar identificadores y entidades dbiles, determinar jerarquas de generalizacin, y finalmente, revisar el modelo.
5.1
Identificar Tipos de Entidades
Para identificar los tipos de entidad, es muy importante considerar el contexto o dominio del problema descrito en la especificacin de requerimientos de informacin. En general, se puede seleccionar como tipo de entidad los nombres o sustantivos que aparecen en la especificacin de requerimiento, por ejemplo Cliente, Aula, Alumno. Se sugiere, tambin, seleccionar objetos importantes como personas, lugares o conceptos de inters, excluyendo aquellos nombres que slo son propiedades de otros objetos, por ejemplo, se pueden agrupar el nmero de empleado y el nombre de empleado en un tipo de entidad denominada Empleado, y agrupar nmero de inmueble, direccin del inmueble y nmero de habitaciones en otro tipo de entidad denominada Inmueble. Una de las decisiones cruciales del diseo conceptual es determinar si un objeto o concepto se modela como un tipo de entidad o no. Por ejemplo, el color es habitualmente un atributo de una entidad (color de un auto), pero en una fbrica de pinturas probablemente sera apropiado modelar el color como una entidad con sus propios atributos. No siempre es obvio saber si un objeto es una entidad, una relacin o un atributo. Por ejemplo cmo se podra clasificar matrimonio? Pues de cualquiera de las tres formas. El anlisis es subjetivo, por lo que distintos diseadores pueden hacer distintas interpretaciones, aunque todas igualmente vlidas. Todo depende de la opinin y la experiencia de cada uno. Los diseadores de bases de datos deben tener una visin selectiva y clasificar las cosas que observan dentro del contexto de la empresa u organizacin. A partir de unas especificaciones de usuario es posible que no se pueda deducir un conjunto nico de entidades, pero despus de varias iteraciones del proceso de anlisis, se llegar a obtener un conjunto de entidades que sean adecuadas para el sistema que se ha de construir.
5.2
Identificar Atributos
Para identificar atributos, al igual que con las entidades, se buscan nombres en las especificaciones de requisitos. Son atributos los nombres que identifican propiedades, cualidades, identificadores o caractersticas de entidades o relaciones.
35
Csar Luza Montero
Otra forma sencilla para identificar atributos es preguntarse qu informacin se quiere saber de cada entidad? La respuesta a esta pregunta se debe encontrar en las especificaciones de requisitos. Cuando se estn identificando los atributos, se puede descubrir alguna entidad que no se ha identificado previamente, por lo que hay que volver al principio introduciendo esta entidad y viendo si se relaciona con otras entidades.
5.3
Identificar Tipos de relaciones
Para identificar los tipos de relaciones se suelen buscar las expresiones verbales (por ejemplo: oficina tiene empleados, empleado gestiona inmueble, cliente visita inmueble). Si las especificaciones de requisitos reflejan estas relaciones es porque son importantes para la empresa y, por lo tanto, se deben reflejar en el esquema conceptual. Slo interesan las relaciones que son necesarias. En el ejemplo anterior, se han identificado las relaciones empleado gestiona inmueble y cliente visita inmueble. Se podra pensar en incluir una relacin entre empleado y cliente: empleado atiende a cliente, pero observando las especificaciones de requisitos no parece que haya inters en modelar tal relacin. La mayora de las relaciones son binarias (entre dos entidades), pero no hay que olvidar que tambin puede haber relaciones en las que participen ms de dos entidades, as como relaciones recursivas. Una vez identificadas todas las relaciones, hay que determinar la cardinalidad mnima y mxima con la que participa cada entidad en cada una de ellas. Si la relacin es de muchos a muchos es importante asegurarse si tiene o no atributos. De este modo, el esquema representa de un modo ms explcito la semntica de las relaciones.
5.4
Determinar Identificadores y Entidades dbiles
Cada entidad tiene al menos un identificador. En este paso, se trata de encontrar todos los identificadores de cada una de las entidades. Los identificadores pueden ser simples o compuestos. De cada entidad se escoger uno de los identificadores como clave primaria en la fase del diseo lgico. Cuando se determinan los identificadores es fcil darse cuenta de si una entidad es fuerte o dbil. Si una entidad tiene al menos un identificador, es fuerte (otras denominaciones son padre, propietaria o dominante). Si una entidad no tiene atributos que le sirvan de identificador, es dbil (otras denominaciones son hijo, dependiente o subordinada)..
5.5
Determinar Jerarquas de Generalizacin
En este paso hay que observar los tipos de entidades que se han identificado hasta el momento. Si es necesario reflejar las diferencias entre distintas ocurrencias de un tipo sw entidad, con lo que surgirn nuevos subtipos de esta entidad genrica; o bien, si hay entidades que tienen caractersticas en comn y que realmente son subtipos de una nueva entidad genrica.
5.6
Revisar el Esquema Conceptual
Antes de finalizar el diseo conceptual, se debe revisar el esquema conceptual con el usuario. Este esquema est formado por el diagrama entidad-relacin y toda la documentacin que describe el esquema. Si se encuentra alguna anomala, hay que corregirla haciendo los cambios oportunos, por lo que posiblemente haya que repetir alguno de los pasos anteriores.
36
Csar Luza Montero
Este proceso debe repetirse hasta que se est seguro de que el esquema conceptual es una fiel representacin de la parte de la empresa que se est tratando de modelar.
5.7
Casos de ejemplo
5.7.1 Empresa de alquiler de autos

Un determinado cliente, cuyos datos importantes son Cdigo y Nombre, puede tener en un momento dado varias reservas. Una reserva la realiza un nico cliente y solo puede involucrar a un auto. Un auto puede tener varias reservas en un determinado periodo de tiempo. Es importante registrar el nmero de orden de la reserva, la fecha de comienzo de reserva y la de terminacin. Todo automvil, que se identifica por su nmero de placa, tiene siempre asignado un determinado garaje, que no puede cambiar. El Garaje se describe por su direccin y capacidad. Cada reserva se realiza en una determinada agencia. De la agencia se necesita su cdigo y direccin. En la base de datos pueden existir clientes que no hayan hecho ninguna reserva. Es importante saber si un automvil est reservado o no en un momento determinado. Se pide elaborar el MER correspondiente Solucin: Identificando Entidades
Figura 5.1 Tipos de Entidades
CLIENTE RESERVA AUTO
AGENCIA
GARAJE
Identificando Atributos:
Figura 5.2 Atributos de Entidades
DNI
NOMBRE
NUMERO
FECHA_INICIO
FECHA_FIN
NRO_PLACA
CLIENTE CODIGO DIRECCION
RESERVA
AUTO
DIRECCION
CAPACIDAD
AGENCIA
GARAJE
37
Modelado y Diseo de Base de datos Identificando Tipos de Relaciones y agregando cardinalidades:
Csar Luza Montero
Figura 5.3 Modelo ER completo

NUMERO DNI NOMBRE (1,1) FECHA_INICIO FECHA_FIN (0,n) (0,n)
CLIENTE
REALIZA
RESERVA (0,n)
INVOLUCRA REALIZADA (1,1) CODIGO AUTO (1,1) AGENCIA (0,n) NRO_PLACA
ASIGNADO DIRECCION (1,1) CAPACIDAD DIRECCION GARAJE
En la siguiente figura 5.3, se muestra el mismo MER con notacin IE

Figura 5.3 Modelo ER completo con Notacin IE
CLIENTE DNI NOMBRE RESERVA
REALIZA
NUMERO FECHA_INICIO FECHA_FIN
REALIZADA
INVOLUCRA
AGENCIA CODIGO DIRECCION
AUTO PLACA
ASIGNADO
GARAJE DIRECCION_GARAJ CAPACIDAD
38
Csar Luza Montero
5.7.2 Gestin de Trnsito Vehicular

La Polica de Trnsito de un determinado pas, dividido en Demarcaciones, desea un mejor control de la gestin vehicular, en especial en lo que se refiere a las multas y accidentes. Las Demarcaciones se identifican por su cdigo y tienen un nombre; adems, se requiere los datos actuales referentes a su nmero de habitantes, nmero de vehculos y nmero de conductores con carnet. Un vehculo viene identificado por su matrcula (que consta del cdigo de la demarcacin correspondiente, y de un nmero correlativo dentro de la demarcacin). Supondremos que la matrcula no cambia por ningn concepto. En un momento determinado, un vehculo tiene un nico propietario, que puede ir cambiando en sucesivas ventas. Interesa, en los diferentes momentos de cada compra, su kilometraje (0, si es nuevo), y su estado de conservacin (valorado de A hasta E, en sentido decreciente). Tanto las multas como los accidentes se producen en una demarcacin determinada, y una consulta que se estima ser frecuente es la de conocer las multas o los accidentes que se han producido en una fecha determinada, o bien en un intervalo determinado. Las multas y accidentes son identificados por un nmero dentro de cada demarcacin. De un accidente interesa saber la hora y el lugar donde se ha producido, as como el/los vehculos, que se hayan visto involucrados, y tambin el/los ciudadanos afectados. De estos ltimos, queremos saber si eran o no conductores en el accidente, y tambin el dao fsico recibido, que se calificar de 1 a 5, segn la gravedad, significando 1 que ha resultado muerto. De los vehculos anotaremos el estado en que han quedado, valorado de 1 a 5, significando aqu 1 que no ha habido daos. Las multas se ponen a un vehculo y a su propietario correspondiente, y especifican el lugar, el tipo de infraccin (como por ejemplo, exceso de velocidad), el importe, etc. Como que muchas veces el polica no podr pedir documentaciones (caso de multas de aparcamiento, radar, etc.), ser la base de datos la que conseguir los datos del propietario, haciendo un clculo apropiado.
SOLUCIN
DEMARCACION CODIGO NOMBRE NUM_HABITANTES NUM_VEHICULOS NUM_CONDUCTORES
SE_PRODUCE
INCIDENTETRANSITO NUMERO FECHA HORA LUGAR
MULTA TIPO_INFRACCION IMPORTE
ACCIDENTE ESTADO_VEHICULO
AFECT A
CIUDADANO IDENTIFICACION DAO_FISICO IND_CONDUCTOR_SN
APLICADA
INVOLUCRA
VEHICULO
REGIST RA
MATRICULA
VENDIDO DUEO_ACT UAL
PROPIETARIO NUM_TARJETA_PROP
COMPRADO
VENTA KILOMETRAJE ESTADO_CONSERVACION
39
Csar Luza Montero
Resumen
Un MER es un modelo conceptual, basado en Tipos de entidad, Tipos de relacin y atributos. Sus extensiones consideran entidades dbiles, generalizacin, etc. Una entidad es una persona, lugar, cosa, concepto o suceso, real o abstracto, de inters para la empresa. Un atributo es una propiedad de la entidad. Un tipo de entidad define un conjunto de entidades con los mismos atributos. Un atributo identificado permite distinguir una entidad de otra. Una relacin es una asociacin entre dos entidades. Un tipo de relacin es un conjunto de relaciones existentes entre entidades. El grado de una relacin es el numero de entidades que participa en la relacin Los roles ayudan a explicar el significado de una relacin, se usa relaciones unarias La razn de cardinalidad o tipo de correspondencia es una restriccin definida por el nmero mximo de instancias de un tipo de entidad que puede estar relacionada con una instancia del otro tipo de entidad asociada. Puede ser: uno a uno, uno a muchos y muchos a muchos. Un atributo de una relacin es propio de la relacin. La Razn de Participacin o cardinalidad mnima y mxima de una relacin, son los nmeros mnimo y mximo de instancias de tipo de relacin en las que puede intervenir una instancia del tipo de entidad participante. Una entidad dbil es aquella que no tiene atributo identificador propio. Su existencia depende de otra entidad (fuerte) que la posee y la identifica inequvocamente. La generalizacin es una relacin entre un tipo de entidad (padre) y varios otros tipos de entidad (hijos), donde la jerarqua o relacin que se establece entre uno y otros corresponde a la nocin de es_un o de es_un_tipo_de.
40
Csar Luza Montero
Lectura
El Lenguaje de Modelado Unificado UML (*)
Los diagramas entidad-relacin ayudan a modelar el componente de representacin de datos de un sistema software. La representacin de datos, sin embargo, slo forma parte de un diseo completo de un sistema. Otros componentes son modelos de interaccin del usuario con el sistema, especificacin de mdulos funcionales del sistema y su interaccin, etc. El lenguaje de modelado unificado (UML, Unified Modeling Language) es un estndar propuesto para la creacin de especificaciones de varios componentes de un sistema software. Algunas de las partes de UML son: Diagrama de clase. Un diagrama de clase es similar a un diagrama E-R. Ms adelante en este apartado se mostrarn algunas caractersticas de los diagramas de clase y cmo se corresponden con los diagramas E-R. Diagrama de caso de uso. Los diagramas de caso de uso muestran la interaccin entre los usuarios y el sistema, en particular los pasos de las tareas que realiza el usuario (tales como prestar dinero o matricularse de una asignatura). Diagrama de actividad. Los diagramas de actividad describen el ujo de tareas entre varios componentes de un sistema. Diagrama de implementacin. Los diagramas de implementacin muestran los componentes del sistema y sus interconexiones tanto en el nivel del componente software como el hardware. Aqu no se intentar proporcionar un tratamiento detallado de las diferentes partes de UML. Vanse las notas bibliogrficas para encontrar referencias de UML. En su lugar se ilustrarn algunas caractersticas de UML mediante ejemplos. La Figura 2.28 muestra varios constructores de diagramas E-R y sus constructores equivalentes de los diagramas de clase UML. Ms abajo se describen estos constructores. UML muestra los conjuntos de entidades como cuadros y, a diferencia de E-R, muestra los atributos dentro del cuadro en lugar de como elipses separadas. UML modela realmente objetos, mientras que E-R modela entidades. Los objetos son como entidades y tienen atributos, pero adems proporcionan un conjunto de funciones (denominadas mtodos) que se pueden invocar para calcular valores en trminos de los atributos de los objetos, o para modificar el propio objeto. Los diagramas de clase pueden describir mtodos adems de atributos. Los conjuntos de relaciones binarias se representan en UML dibujando simplemente una lnea que conecte los conjuntos de entidades. Se escribe el nombre del conjunto de relaciones adyacente a la lnea. Tambin se puede especificar el papel que juega un conjunto de entidades en un conjunto de relaciones escribiendo el nombre del papel en un cuadro, junto con los atributos del conjunto de relaciones, y conectar el cuadro con una lnea discontinua a la lnea que describe el conjunto de relaciones. Este cuadro se puede tratar entonces como un conjunto de entidades, de la misma forma que una agregacin en los diagramas E-R puede participar en relaciones con otros conjuntos de entidades. La relaciones no binarias no se pueden representar directamente en UML .se deben convertir en relaciones binarias. Las restricciones de cardinalidad se especifican en UML de la misma forma que en los diagramas E-R, de la forma i..h, donde i denota el mnimo y h el mximo nmero de relaciones en que puede participar una entidad. Sin embargo, se debera ser consciente que la ubicacin de las restricciones es exactamente el inverso de la ubicacin de las restricciones en los diagramas E-R, como muestra la Figura 2.28. La restriccin 0..* en el lado E2 y 0..1 en el lado E1 41
Csar Luza Montero
significa que cada entidad E2 puede participar a lo sumo en una relacin, mientras que cada entidad E1 puede participar en varias relaciones; en otras palabras, la relacin es varios a uno de E2 a E1. Los valores como 1 o * se pueden escribir en los arcos; el valor 1 sobre un arco se trata equivalentemente como 1..1, mientras que * es equivalente a 0..*. La generalizacin y especializacin se representan en el diagrama E-R conectando conjuntos de entidades por una lnea con un tringulo al final correspondiente al conjunto de entidades ms general. Por ejemplo, el conjunto de entidades persona es una generalizacin de cliente y empleado. Los diagramas UML tambin pueden representar explcitamente las restricciones de generalizaciones disjuntas y solapadas. La Figura 2.28 muestra generalizaciones disjuntas y solapadas de cliente y empleado a persona. Recurdese que la generalizacin de cliente / empleado a persona es disjunta, y significa que ninguna entidad puede ser a la vez un cliente y un empleado. Una generalizacin solapada permite que una persona sea tanto cliente como empleado.
(*)Korth (2002, pp.46-47)
42
Csar Luza Montero
Actividades
Elaborar el MER para los siguientes casos 1. Empresa de venta de productos
Una empresa vende productos a varios clientes. Se necesita conocer los datos personales de los clientes: DNI, nombre, apellidos, direccin y fecha de nacimiento. Cada producto tiene un cdigo y un nombre as como un precio unitario. Un cliente puede comprar varios productos a la empresa, y un mismo producto puede ser comprado por varios clientes. Se debe tener en cuenta que un producto solo puede ser suministrado por un proveedor, y que un proveedor puede suministrar diferentes productos. De cada proveedor se desea conocer el RUC, nombre y direccin.
2. Institucin Educativa
Se desea elabora una base de datos para el administrador de una institucin educativa, que brinda cursos de informtica, quien manifiesta lo siguiente: Enseamos muchos cursos, cada uno de los cuales tiene un cdigo, un nombre y un precio. Dos de nuestros cursos ms populares son: Introduccin a Internet y Programacin Java. Los cursos se dictan entre uno a cuatro das. Un instructor puede ensear varios cursos. Registramos el nombre y nmero de telfono de los profesores. Cada curso es enseado por slo un instructor. Creamos un curso y luego le asignamos un profesor. Los estudiantes pueden tomar varios cursos a la vez, y muchos de ellos lo hacen. Tambin registramos el nombre y telfono de cada estudiante. Algunos de nuestros estudiantes e instructores no nos dan sus nmeros telefnicos."
3. Empresa de venta de automviles

Se desea disear una base de datos para almacenar y gestionar la informacin empleada por una empresa dedicada a la venta de automviles, teniendo en cuenta los siguientes aspectos: La empresa dispone de una serie de coches para su venta. Se necesita conocer la matrcula, marca y modelo, el color y el precio de venta de cada coche. Los datos que interesa conocer de cada cliente son el DNI, nombre, direccin, ciudad y nmero de telfono: adems, los clientes se diferencian por un cdigo interno de la empresa que se incrementa automticamente cuando un cliente se da de alta en ella. Un cliente puede comprar tantos coches como desee a la empresa. Un coche determinado solo puede ser comprado por un nico cliente. El concesionario tambin se encarga de llevar a cabo las revisiones que se realizan a cada coche. Cada revisin tiene asociado un cdigo que se incrementa automticamente por cada revisin que se haga. De cada revisin se desea saber si se ha hecho cambio de filtro, si se ha hecho cambio de aceite, si se ha hecho cambio de frenos u otros. Los coches pueden pasar varias revisiones en el concesionario.
4. Compaa de Videos
Soy el propietario de una pequea tienda de videos. Tenemos alrededor de 3.000 cintas de las cuales necesitamos mantener su estado. Cada uno de nuestras cintas tiene un nmero de identificacin. Para cada pelcula, necesitamos conocer su ttulo y categora (comedia, suspenso, drama, accin, guerra, etc.)Tenemos mltiples copias de muchas de nuestras pelculas. A cada pelcula le asignamos un identificador y le asociamos la cinta que la contiene. Una cinta puede ser formato Beta o VHS. Siempre tenemos al menos una cinta para cada pelcula que nosotros rastreamos, y cada cinta es siempre una copia de una nica pelcula. Nuestras cintas son de larga duracin y no tenemos pelculas que requieran mltiples cintas. Frecuentemente nos preguntan por pelculas con actores populares especficos. As que deseamos registrar las pelculas donde estn los actores de moda. No todas nuestras pelculas tienen actores famosos o de moda. Clientes desean conocer de cada actor su nombre real y fecha de cumpleaos. Slo registramos los actores que aparecen en pelculas de nuestro inventario.
43
Csar Luza Montero
Tenemos cientos de clientes. Slo arrendamos videos a gente asociada a nuestro video-club. Para cada socio, registramos su nombre, apellido, telfono, direccin. Y, por supuesto cada socio tiene su nmero de socio. Luego, necesitamos conocer que cinta ha retirado cada cliente. Un cliente puede retirar varias cintas al mismo tiempo. Slo registramos los arriendos actuales, no los histricos.
5. Empresa Bancaria
Un banco brinda cuentas corrientes y cuentas de ahorro. Un cliente tiene al menos una cuenta, aunque puede tener varias cuentas de cualquiera de los dos tipos. Cada cuenta pertenece a un nico cliente. Los clientes tienen un nombre, una direccin y se identifican por su cdigo. Los clientes son personas reales u organizaciones. Las personas tienen fecha de nacimiento y sexo; en cambio las organizaciones tienen un tipo de organizacin (empresa, institucin pblica, etc.), un representante y un total de empleados. Cada cuenta se identifica por un cdigo, formado por el nmero de la sucursal y el n de la cuenta (dentro de dicha sucursal). Todas las cuentas tienen un saldo actual y un saldo medio, pero el tipo de amortizacin slo lo tienen las cuentas de ahorro (que slo suponen el 5% del total de cuentas existentes). Cada sucursal se identifica por su nmero. Adems tiene una direccin, un cdigo postal y una ciudad. Los empleados del banco se identifican por su DNI. Tambin interesa conocer su nombre, fecha de nacimiento, sexo y la sucursal en la que trabajan (aunque hay empleados que no trabajan en ninguna sucursal).
6. Organizacin Interna de Empresa

Una empresa necesita organizar la siguiente informacin referente a su organizacin interna. La empresa est organizada en una serie de departamentos. Cada departamento tiene un cdigo, nombre y presupuesto anual. Cada departamento est ubicado en un centro de trabajo. La informacin que se desea guardar del centro de trabajo es el cdigo de centro, nombre, poblacin y direccin del centro. La empresa tiene una serie de empleados. Cada empleado tiene un telfono, fecha de alta en la empresa, DNI y nombre. De cada empleado tambin interesa saber el nmero de hijos que tiene y su salario. A esta empresa tambin le interesa tener guardada informacin sobre los hijos de los empleados. Cada hijo de un empleado tendr un cdigo, nombre y fecha de nacimiento. Se desea mantener tambin informacin sobre las habilidades de los empleados (por ejemplo, mercadotecnia, trato con el cliente, fresador, operador de telefona, etc). Cada habilidad tendr una descripcin y un cdigo. Considerar tambin los siguientes aspectos: Un empleado est asignado a un nico departamento. Un departamento estar compuesto por uno o ms empleados. Cada departamento se ubica en un nico centro de trabajo. Estos se componen de uno o ms departamentos. Un empleado puede tener varios hijos. Un empleado puede tener varias habilidades, y una misma habilidad puede ser poseda por empleados diferentes. Un centro de trabajo es dirigido por un empleado. Un mismo empleado puede dirigir centros de trabajo distintos.
44
Csar Luza Montero
Autoevaluacin
1. Con respecto al concepto de MER, entre los parntesis de la siguiente lista, marque V=Verdadero o F=Falso, segn corresponda: a. ( ) Es un modelo de datos lgico b. ( ) Es un modelo de datos conceptual c. ( ) Incluye detalles de implementacin d. ( ) Incluye tipos de entidades y tipos de relacin e. ( ) Es un software para representar datos Establezca la relacin de concepto y su descripcin, colocando la letra de la descripcin en la celda a la derecha del Concepto: Concepto 1. Entidad 2. Tipo de entidad 3. Atributo 4. Atributo Identificador 5. Relacin 6. Tipo de Relacin 7. Grado de Tipo Relacin 8. Rol 3. a) Descripcin del concepto. Cdigo, nombre, edad de alumno; DNI, nombre de persona
2.
b) Cesar alquila un video; Juan lleva base de datos 1 c) d) Juan Prez, Pedro Miranda, Ayudan a explicar el significado de una relacin y se usa en relaciones unarias
e) DNI de una persona, Cdigo de una Asignatura f) g) Numero de tipos de entidad que participan en un tipo de relacin Alumno, Persona
h) Cliente alquila Video
A continuacin se listan una serie de supuestos semnticos y una serie de diagramas entidad relacin, establezca la correspondencia correcta colocando la letra del diagrama en la casilla DERal costado del supuesto semntico: Supuesto semnticos 1. 2. 3. 4. Un promotor vende uno o ms productos y un producto es vendido por solo un promotor. Un promotor puede vender muchos productos (al menos uno) y un producto puede ser vendido por muchos promotores. Un promotor vende uno y solo un producto, un producto puede ser vendido por solo un promotor. Hay promotores que no venden ningn producto. Un promotor vende uno y solo un producto, pero un producto puede ser vendido por muchos promotores Diagramas Entidad Relacin a)
PROMOTOR
VEN DE
DER
PRODUCTO
b)
PROMOTOR
VEN DE
PRODUCTO
45

c)
PROMOTOR
VEN DE
Csar Luza Montero
PRODUCTO
d)
PROMOTOR
VEN DE
PRODUCTO
4.
Considerando el siguiente Diagrama Entidad Relacin

CLIENTE
SOLICITA
PRESTAMO
PERSONA
EMPRESA
Entre los parntesis de la siguiente lista, marque V=Verdadero o F=Falso, segn corresponda: a. b. c. d. e. ( ( ( ( ( ) Una persona puede solicitar prstamo ) Un prstamo puede ser solicitado solo por un cliente persona, no por empresas ) Un cliente es un tipo de empresas ) Una empresa es un tipo de cliente ) Una persona es un tipo de cliente
Respuestas de Control
1. 2. 3. 4. a = F, 1 = c, 1 = c, a = V, b = V, 2 = g, 2 = d, b = F, c = F, 3 = a, 3 = a, c = F, d = V, e = F 4 = e, 5 = b, 6 = h, 7 = f, 8 = d 4= b d = V, e = V
Exploracin On-Line
Herramienta de modelado dbdesigner http://fabforce.net/dbdesigner4/ Herramienta de modelado DIA for Windows http://dia-installer.de/index_en.html
1. ANSI (1977): The ANSI/X3/SPARC DBMS Framework. Report on the Study Group on Database Management Systems. D. Tsichiritzis y A. Klug (eds). Montvalle, N.J.: AFIP Press. 46
Csar Luza Montero
2. Chen, Peter (1976), The entety-relationship model:Towards a unified view of data. ACM Trans.Sistemas de bases de datos 1 (1) 9-36. 3. De Miguel A. y Piattini M., (1999) Fundamentos y Modelos de Base de datos. 2da. Ed. Madrid. Alfa y Omega. 4. Elmasri, Ramez y Shamkant Navathe (1997) Sistemas de Bases de Datos. Conceptos fundamentales. Segunda Edicin. Madrid. Addison-Wesley Iberoamericana. 5. Finkelstein, C. (1992) Strategic systems development. Sydney: Addison-Wesley. 6. Korth, H., Silberschatz, A., Sudarschan, S. (2002) Fundamentos de base de datos. 4ta. Ed. Madrid. McGrawHill/Interamericana.
47
Csar Luza Montero
UNIDAD 3 EL MODELO RELACIONAL (MR)

Qu es el Modelo relacional? Cules son sus elementos? Qu es una relacin? Qu es un domino de atributo? Qu es el esquema y estado de la base de datos? Qu es una clave candidata?, Qu es Clave Primaria y Clave fornea? Cules son las restricciones del modelo relacional? Qu es la normalizacin? Cules son sus reglas o formas normales?
48
Csar Luza Montero
Leccin 6
Modelo Entidad-Relacin
Definicin y elementos del MR

ITEM_FACTURA PRODUCTO
4.1
Definicin
El Modelo Relacional, es un modelo de datos lgico, fue introducido por Codd (1970). Es el FACTURA modelo ms utilizado en la actualidad para modelar y administrar datos. En el modelo relacional los datos se representan como una coleccin de Relaciones o Tablas (Figura 6.1). Una Relacin es un conjunto de datos.
Figura 6.1 OrganizacinBase Datos Relacional tablas de datos como relaciones o
FACTURA cod fecha id_t
Datos Jerarquica
FACTURA
ITEM 1
ITEM 1 ITEM cod cant prod PRODUCTO 2 PRODUCTO cod desc stock
RODUCTO 1
Base Datos Red
Este modelo de datos persegua una serie de objetivos que se resumen en: Independencia fsica, Independencia lgica, Flexibilidad, Uniformidad. Sencillez. FACTURA PROD1 Con la Independencia fsica PROD2 el modo en que se almacenan los datos no influye en su manipulacin lgica y por tanto, los usuarios que acceden a esos datos no tienen que modificar sus programas por cambios en el almacenamiento fsico.
ITEM1 ITEM2 Con la Independencia lgica el aadir, eliminar o modificar objetos de la base de datos no repercute en los programas y usuarios que estn accediendo a subconjuntos parciales de los mismos (vistas).
Con la Flexibilidad se pretende presentar a cada usuario los datos de la forma en que ste prefiera. Con la Uniformidad las estructuras lgicas de los datos presentan un aspecto uniforme, lo que facilita la concepcin y manipulacin de la base de datos por parte de los usuarios. Con la Sencillez las caractersticas anteriores, as como unos lenguajes de usuario muy sencillos, producen como resultado que el modelo de datos relacional sea fcil de comprender y de utilizar por parte del usuario final.
4.2
Elementos
4.2.1 Relacin
De manera simple, una relacin representa una tabla, que no es ms que un conjunto de filas y columnas. Cada fila es un conjunto de atributos, el conjunto de atributos se conoce como cabecera o esquema de la relacin y cada atributo representa un valor que interpretado describe el mundo real (Figura 6.2).
49
Csar Luza Montero
Cada fila tambin se puede denominar tupla o registro y a cada columna tambin se le puede llamar campo o atributo.
Figura 6.2 Elementos de una relacin
4.2.2 Dominio de un atributo

El Dominio de un atributo es el conjunto de valores que un atributo puede tomar. Un dominio es usualmente representado por un tipo. Ejemplos: . El Domino del atributo Cdigo es un Char(09) --- Cadena de caracteres de longitud 9. El Dominio de Nombre es un Varchar(30) --- Cadena de caracteres de longitud variable hasta 30 caracteres. El Dominio de Edad, es un rango de nmeros: 15 a 90. El Dominio del atributo Nota es un rango de nmero de 0 a 20. El Dominio del atributo Gnero es el conjunto de valores Masculino y Femenino.
4.2.3 Esquema y Estado de una Relacin

El Esquema (schema) de una relacin o cabecera de la relacin es el conjunto de los atributos de la relacin (korth, 2002). Por ejemplo, el esquema de la relacin ALUMNO, de la figura 6.2, es (Cdigo, Nombre, Edad, Nota) y se representa: ALUMNO (Cdigo, Nombre, Edad, Nota) El Estado (o contenido) de la relacin es el actual conjunto de tuplas o filas de la relacin. Un esquema determinado puede tener diferentes estados en diferentes tiempos. El esquema de una relacin raramente cambia. Algunos posibles cambios son: Renombrar un atributo, Borrar un atributo, Aadir un atributo, Borrar el esquema. El estado de una relacin puede cambiar frecuentemente. Algunos posibles cambios son: Modificar algunos valores de atributos, Borrar una tupla existente, Insertar una nueva tupla.
4.2.4 Esquema y Estado de una Base de Datos

El esquema de base de datos relacional consiste de un conjunto de esquemas de relaciones. Por ejemplo, el esquema de una base de datos acadmica sencilla podra ser: 50
Modelado y Diseo de Base de datos FACULTADES (Cdigo, Nombre) ALUMNOS (Cdigo, Nombre, Edad, Facultad), ASIGNATURAS (Cdigo, Descripcin), DOCENTES (DNI, Nombre)
Csar Luza Montero
El estado de la base de datos es la data actualmente en la base de datos. En la figura 6.3 se muestra un ejemplo de estado de base de datos en un momento determinado.
FACULTADES Cdigo Nombre 21 17 11 SISTEMAS INDUSTRIAL ADMINISTRACIN Figura 6.3 Estado de una base de dato ALUMNOS Cdigo Nombre Edad Facultad 21 19 18 17 21 21 21-990101 JUAN 21-872342 MARA 21-765349 ALBERTO DOCENTES Cdigo 6222888 3490023 8674444 Nombre CARPIO CRUZ LUZA
ASIGNATURAS Cdigo Nombre BD01 BASE DE DATOS 1 ANLISIS DE AS99 SISTEMAS LP03 CC00 LENGUAJE CIRCUITOS DIGITALES
OM00 ORGANIZACIN
4.2.5 Claves Candidata, Clave Primaria y Clave Fornea

Las Claves Candidatas es un conjunto no vacio de atributos que identifican univoca y mnimamente cada tupla que cumple un esquema de relacin, puede haber varias en el mismo esquema. Una Clave Primaria (Primary Key) es una clave candidata elegida, mediante algn criterio, para este fin. Una Clave Fornea (Foreign Key) es una combinacin de atributos cuyos valores estn basados en los valores de la clave primaria de otra tabla o de la misma tabla. Por ejemplo, sean los siguientes esquemas de relaciones: EMPLEADO ( NEmpleado, NSeguridadSocial, DNI, Nombre, Edad, NDepartamento, NEmpleadoSupervisor ) DEPARTAMENTO ( NDepartamento, Denominacin, NEmpleadoJefe ) Las Claves candidatas de EMPLEADO son: NEmpleado, NSeguridadSocial y DNI. La clave Primaria elegida puede ser NEmpleado. La Clave Primaria de DEPARTAMENTO es NDepartamento. Las Claves Forneas de EMPLEADO son NDepartamento y NEmpleadoSupervisor y la Clave Fornea de DEAPARTAMENTO es NEmpleadoJefe.
4.3
Reglas
El modelo relacional considera una serie de reglas o restricciones para estar completamente definida. 51
Csar Luza Montero
4.3.1 Regla de primera forma normal

No se permiten atributo multivaluado en una tabla. Es decir, para cualquier tupla t y atributo A en una tabla, t [A] debe ser un valor simple o atmico.
4.3.2 Regla de fila nica

No se permite dos filas en la misma tabla que sean idnticas en cualquier momento dado. Es decir cada tupla en la tabla es nica. Cuando una nueva tupla es insertada a la relacin, el sistema tiene que estar seguro que la nueva tupla es diferente a todas las tuplas existentes en la relacin.
4.3.3 Regla de Integridad de Entidad

No se permiten valores nulos en la llave primaria y todas las entradas sern nicas. Con las reglas de integridad de entidad se garantiza que cada entidad (tupla) tiene un identificador nico.
4.3.4 Regla de Integridad Referencial

El valor de la clave fornea puede ser nulo o tiene que parear (coincidir) con el valor de la clave primaria de la tabla con la cual se establece la interrelacin. Se garantiza que no es posible establecer relaciones que no pareen. Con las reglas de integridad se minimizan los errores de entrada de datos, esto es, que haya consistencia.
52
Csar Luza Montero
Leccin 7 Transformacin de un MER a MR

El proceso de transformacin de un MER a MR corresponde a la fase de Diseo Lgico de una base de datos. El artefacto de entrada para el diseo lgico es el esquema conceptual (MER) elaborado en la fase de diseo conceptual. El artefacto de salida del diseo lgico es el esquema lgico. Se pueden considera las siguientes reglas para el proceso de transformacin de un MER a MR:
7.1
Transformacin de tipo de entidad
Para transformar un tipo de entidad a relacin (esquema relacional) se se crea una relacin por cada entidad; los atributos de la entidad se transforman en atributos de la relacin; el identificador del tipo de entidad se transforma en la clave primaria de la relacin. Por ejemplo, el siguiente tipo de entidad
CODIGO
DESCRIPCION
CATEGORIA
Se transforma en el siguiente esquema relacional: CATEGORA (CDIGO, DESCRIPCIN) PK = Cdigo

Donde PK = Primary Key, Clave Primaria.
7.2
Transformacin de tipo de relacin
Las reglas bsicas de transformacin de tipo de relacin a esquema relacional se puede resumir segn el tipo de correspondencia en:
7.2.1 Uno a Muchos

Para los tipos de relacin unarias o binarias de tipo 1:N se adicionan los atributos identificadores de la entidad del lado 1 a la del lado N, convirtindose en claves forneas (Foreign Key) . i. Por ejemplo, el siguiente tipo de relacin unaria de Uno a Muchos:
CODIGO APELLIDO NOM BRE
(0,1) ALUM NO
(0,n)
Es_tutor_de
Se transforma en el siguiente esquema relacional: 53
Csar Luza Montero
ALUMNO (CDIGO, APELLIDO, NOMBRE, CODIGO_TUTOR) PK = CDIGO FK = CODIGO_TUTOR de ALUMNO

FK = Foreign Key, Clave Foranea.
ii.
El siguiente tipo de relacin binaria Uno a Muchos:

CODIGO CODIGO DESCRIPCION APELLIDO NOMBRE
FACULTAD
(1,1)
TIENE
(0,n)
ALUMNO
Se transforma en los siguientes esquemas relacionales: FACULTAD (CDIGO, DESCRIPCIN) PK = CDIGO ALUMNO (CDIGO, APELLIDO, NOMBRE, CODIGO_FACULTAD) PK = CDIGO FK = CODIGO_FACULTAD de AFACULTAD
7.2.2 Muchos a Muchos

Para los tipos de relacin unarias o binarias de cardinalidad M:N y ternarias, se crea una nueva relacin cuya clave primaria estar formada por la combinacin de las claves primarias de las entidades participantes. El siguiente tipo de relacin binaria de M:N:
NOM BRE CODIGO APELLIDO CODIGO NOM BRE
ALUM NO
(0,n)
LLEVA
(0,n)
ASIGNATURA
Se transforma en los siguientes esquemas relacionales: ALUMNO (CODIGO, APELLIDO, NOMBRE) PK= CODIGO ASIGNATURA (CODIGO, NOMBRE) PK = CODIGO LLEVA (CODIGO_ALUMNO, CODIGO_ASIGNATURA) PK = (CODIGO_ALUMNO, CODIGO_ASIGNATURA) FK = CODIGO_ALUMNO de ALUMNO FK = CODIGO_ASIGNATURA de ASIGNATURA Se ha creado una nueva relacin llamada LLEVA, cuyo PK est formado por la combinacin de los atributos: CodigoAlumno y CodigoAsignatura, cada uno de estos atributos es clave fornea independientemente. 54
Csar Luza Montero
7.2.3 Uno a Uno

Para los tipos de relacin unaria o binaria de cardinalidad 1:1, se intercambia los atributos identificadores entre los tipos de entidad participantes. Por ejemplo el siguiente tipo de relacin binaria Uno a Uno:
NOM BRES DNI APELLIDOS CODIGO NOM BRE
DECANO
(0,1)
(1,1) DIRIGE FACULTAD
Se transforma en los siguientes esquemas relacionales, se ha intercambiado los atributos identificadores de ambas entidades:. DECANO (DNI, APELLIDOS, NOMBRES, CODIGO_FACULTAD)) PK = DNI FK = CODIGO_FACULTAD de FACULTAD FACULTAD (CODIGO, NOMBRE, DNI_DECANO) PK = CODIGO FK = DNI_DECANO de DECANO
7.3
Transformacin de entidades dbiles
Para transformar una entidad dbil, se crea una relacin para cada entidad dbil incluyendo todos sus atributos. Se aade una clave ajena a la entidad de la que depende. Para ello, se incluye la clave primaria de la relacin que representa a la entidad fuerte en la nueva relacin creada para la entidad dbil. A continuacin, determinar la clave primaria de la nueva relacin. Por ejemplo, el siguiente MER que incluye entidad dbil:
Cod_Articulo Fecha Nro_Fac (1,1)
E TIENE
Condicin
Nro_Det
Cantidad
FACTURA
(1,n)
DETALLE
Se transforma en: FACTURA (NroFac, Fecha, Condicin) PK = NroFac DETALLE (NroFac, NroDet, CodArticulo, Cantidad) PK = (NroFac, NroDet) FK = NroFac de FACTURA
7.4
Transformacin de generalizaciones
Para transformar una generalizacin se crear una relacin por cada entidad. Las relaciones de las entidades hijo heredan como clave primaria la de la entidad padre. Por lo tanto, la clave 55
Csar Luza Montero
primaria de las entidades hijo es tambin una clave ajena al padre. Esta opcin sirve para cualquier tipo de jerarqua, total o parcial y exclusiva o superpuesta. Por ejemplo, la siguiente jerarqua:
Codigo Ape llidos Nombre s
ESTUDIANTE Fe chaGraduacion (0,1) ISA 1 (0,1) GRADUADO (0,1) NO GRADUADO Fe chaInscripcin
Se transforma en: ESTUDIANTE (Cdigo, Apellidos, Nombres) PK = Cdigo GRADUADO (Cdigo, FechaGraduacin)) PK = Cdigo FK = Cdigo de ESTUDIANTE NO_GRADUADO (Cdigo, FechaInspcripcin)) PK = Cdigo FK = Cdigo de ESTUDIANTE
7.5
Caso Ejemplo
Codigo Descripcin
Transformar el siguiente MER a MR
CATEGORIA (1,1) INCLUYE Cantidad (0,n) Codigo PRODUCTO (1,n) (1,1) Nombre E TIENE (0,n) REA LIZADO (1,1) FechaCompra RUC (0,n) PEDIDO NUMERO FECHA
VENDIDO
(1,n)
PRESENTACION Numero LimiteSup LimiteInf Cantidad Precio
CLIENTE (1,1) ISA 1 (0,1) (0,1)
RaznSocial Contacto EMPRESA
Apellidos
Nombres
Descripcin
PERSONA
56
Csar Luza Montero
SOLUCIN CATEGORA (Cdigo, Descripcin); PK = Cdigo PRODUCTO (Cdigo, Nombre, CodigoCategoria); PK = Cdigo, FK = CodigoCategoria de CATEGORIA PRESENTACIN (CodigoProducto, Nmero, Descripcin, Cantidad, LimiteInf, LimiteSup); PK = (CodigoProducto, Nmero); FK = CodigoProducto de PRODUCTO CLIENTE (RUC, FechaCompra); PK = RUC EMPRESA (RUC, RaznSocial, Contacto); PK = RUC FK = RUC de CLIENTE PERSONA (RUC, Apellidos, nombres); PK = RUC FK = RUC de CLIENTE PEDIDO (Nmero, Fecha, RUC); PK = Nmero FK = RUC de CLIENTE VENDIDO (CodigoProducto, NmeroPedido, Cantidad); PK = (CodigoProducto, NumeroPedido) FK = CodigoProducto de PRODUCTO FK = NumeroPedido de PEDIDO
57
Csar Luza Montero
Leccin 8 Normalizacin
8.1 Definicin
La normalizacin de base de datos relacional es considerada un proceso formal para asegurar un buen diseo de base de datos relacional. A travs de este proceso, se descompone las relaciones (tablas) en otras de menor cantidad de columnas con el objetivo de evitar anomalas que pueden ocurrir en las operaciones de actualizacin de las mismas. La teora asociada al concepto de normalizacin fue introducida por E.D. Codd (1970). Se basa en el concepto matemtico de dependencias funcionales, y se expresa como reglas conocidas como formas normales.
8.2
Dependencias funcionales
Informalmente, el concepto de dependencia funcional se puede explicar de la siguiente manera: Un dato depende funcionalmente de otro, si este ltimo siempre lo identifica, es decir que conociendo su valor podemos identificar al primero. Por ejemplo, conociendo el valor de fecha de nacimiento podemos conocer el valor de Edad, entonces, se dice que Edad depende funcionalmente de fecha de nacimiento, y se representa: Fecha de Nacimiento Edad Formalmente, la dependencia funcional se puede definir de la siguiente manera: Sean A y B atributos de una relacin R. Se dice que B es funcionalmente dependiente de A (A B) si todo posible valor de A tiene asociado un nico valor de B. A y B pueden ser atributos simples o compuestos. Veamos otro ejemplo, consideremos la siguiente tabla: MATRICULA
Alumno Jos Prez Luis Adonis Jos Prez Lucas Len Asignatura Base de datos I Base de datos I Anlisis de Sistemas Organizacin y Mtodos Direccin Bolvar 180. Pueblo Libre Junn 300. Jess Mara Bolvar 180. Pueblo Libre Quiones 780. San Miguel Nota 18 16 19 17
Se observa que en las filas correspondientes a un mismo Alumno, existe el mismo valor para la Direccin. En otras palabras, en todas las filas con el mismo valor del atributo Alumno, el atributo Direccin tendr tambin el mismo valor. Entonces, se dice que el esquema cumple una dependencia funcional, y que el atributo Direccin depende funcionalmente de Alumno o que Alumno determina funcionalmente a Direccin y se denota: Alumno Direccin Tambin se observa que: Nota depende funcionalmente de Alumno y Asignatura juntos. (Alumno, Asignatura) Nota
58
Csar Luza Montero
8.2.1 Dependencia Funcional Completa

Sea X (conjunto de atributos). Se dice que un atributo Y tiene dependencia funcional y completa de un conjunto de atributos X, si depende funcionalmente de TODO el conjunto, pero no de algn subconjunto de X. Por ejemplo, consideremos la siguiente relacin: MATRICULA
Alumno Jos Prez Luis Adonis Jos Prez Lucas Len Asignatura Base de datos I Base de datos I Anlisis de Sistemas Organizacin y Mtodos Direccin Bolvar 180. Pueblo Libre Junn 300. Jess Mara Bolvar 180. Pueblo Libre Quiones 780. San Miguel Nota 18 16 19 17 Crditos 3 3 4 2
Se observa que (Alumno, Asignatura) ==> Nota es una dependencia funcional completa. En cambio: (Alumno, Asignatura) Crditos no es una dependencia funcional completa, porque Asignatura Crditos.
8.2.2 Dependencia Funcional Transitiva

Sean X e Y, atributos de una relacin R. Si XY (Y depende funcionalmente de X), Y-/X (X No depende funcionalmente de Y), YZ (Z depende funcionalmente de Y), entonces, Z depende transitivamente de X ( X--Z ). Por ejemplo, consideremos la siguiente relacin: MATRICULA
Alumno Jos Prez Luis Adonis Jos Prez Lucas Len Asignatura Base de datos I Base de datos I Anlisis de Sistemas Organizacin y Mtodos Distrito Pueblo Libre Jess Mara Pueblo Libre San Miguel Nota 18 16 19 17 Distancia 200 100 200 300
Se observa que: Alumno Distrito, Distrito --/ Alumno (no determina funcionalmente), y Distrito Distancia, Entonces, Alumno --- distancia (Alumno determina transitivamente a distancia).
8.3
Formas normales
Las Formas Normales son reglas que permiten estructurar las relaciones (tablas) de tal manera que los datos de la base de datos permanezcan organizados y sea fcil realizar cambios sin efectos secundarios. Las formas normales bsicas son conocidas como: Primera Forma normal, Segunda Forma Normal y Tercera Forma Normal. Cada una se basa en el conjunto precedente de reglas, por lo que los datos que se encuentran en la Tercera Forma Normal, estn automticamente en las Primera y Segunda formas Normales, tambin.
8.3.1 Primera Forma Normal (1FN)

Un esquema o relacin (tabla) est en 1 FN, si el dominio asociado a cada atributo contiene nicamente valores atmicos; es decir, no tiene atributos multivalorados (repetidos). 59
Modelado y Diseo de Base de datos Por ejemplo, consideremos la siguiente relacin: MATRICULA
Alumno Jos Prez Luis Adonis Lucas Len Asignatura Base de datos I Base de datos I Organizacin y Mtodos Distrito Pueblo Libre Jess Mara San Miguel
Csar Luza Montero
Telfonos 4519089, 93009877 5490878 9876523, 8762552
Se observa que la relacin no esta en 1FN, porque el atributo telfono es multivalorado (permite varios valores). Las siguientes relaciones si estn en 1FN: MATRICULA
Alumno Jos Prez Luis Adonis Lucas Len Asignatura Base de datos I Base de datos I Organizacin y Mtodos Distrito Pueblo Libre Jess Mara San Miguel Telfono1 4519089 5490878 9876523 Telfono2 93009877 8762552
MATRICULA
Alumno Jos Prez Jos Prez Luis Adonis Lucas Len Lucas Len Asignatura Base de datos I Base de datos I Base de datos I Organizacin y Mtodos Organizacin y Mtodos Distrito Pueblo Libre Pueblo Libre Jess Mara San Miguel San Miguel Telfono 4519089, 93009877 5490878 9876523 8762552
8.3.2 Segunda Forma Normal (2FN)

Un esquema o relacin (tabla) est en 2 FN, si y slo si est en 1 FN y sus atributos no primarios dependen completamente de la clave primaria. Por ejemplo, consideremos la siguiente relacin: MATRICULA
Alumno Jos Prez Luis Adonis Jos Prez Lucas Len Asignatura Base de datos I Base de datos I Anlisis de Sistemas Organizacin y Mtodos Direccin Bolvar 180. Pueblo Libre Junn 300. Jess Mara Bolvar 180. Pueblo Libre Quiones 780. San Miguel Nota 18 16 19 17
Se observa que Alumno y Asignatura forman la clave primaria compuesta, mientras que Direccin y Nota son atributos no primarios (no forma parte de la clave primaria). Adems, (Alumno, Asignatura) ==> Nota es una dependencia funcional completa. Pero, (Alumno, Asignatura) Direccin no es una dependencia funcional completa, porque Alumno Direccin (Direccin solo depende de Alumno). Por lo tanto: La relacin MATRICULA, no esta en 2FN, porque, hay atributos no primarios que no depende completamente de la clave primaria.
60
Modelado y Diseo de Base de datos Las siguientes relaciones si estn en 2FN: MATRICULA
Alumno Jos Prez Luis Adonis Jos Prez Lucas Len Asignatura Base de datos I Base de datos I Anlisis de Sistemas Organizacin y Mtodos Nota 18 16 19 17
Csar Luza Montero
ALUMNO
Alumno Jos Prez Luis Adonis Jos Prez Lucas Len Direccin Bolvar 180. Pueblo Libre Junn 300. Jess Mara Bolvar 180. Pueblo Libre Quiones 780. San Miguel
8.3.3 Tercera Forma Normal (3FN)

Un esquema o relacin (tabla) est en 3 FN, si y slo si est en 2 FN y ninguno de sus atributos no primarios depende transitivamente de la clave primaria. Es decir no hay dependencias funcionales transitivas. Por ejemplo, consideremos la siguiente relacin cuya clave primaria es Alumno: ALUMNO
Alumno Jos Prez Luis Adonis Jos Prez Lucas Len Edad 15 20 15 18 Distrito Pueblo Libre Jess Mara Pueblo Libre San Miguel Distancia 200 100 200 300
Se observa que: Alumno Distrito, Distrito --/ Alumno (no determina funcionalmente), y Distrito Distancia, eEntonces, Alumno --- distancia (Alumno determina transitivamente a distancia). Por lo tanto: la relacin ALUMNO, no est en 3FN. Las siguientes relaciones si estn en 3FN: ALUMNO
Alumno Jos Prez Luis Adonis Jos Prez Lucas Len Edad 15 20 15 18 Distrito Pueblo Libre Jess Mara Pueblo Libre San Miguel
DISTRITO
Alumno Pueblo Libre Jess Mara Pueblo Libre San Miguel Distancia 200 100 200 300
8.4
Proceso de Normalizacin
La normalizacin involucra varias fases que se realizan en orden. La realizacin de la 2da fase supone que se ha concluido la 1ra y as sucesivamente. Tras completar cada fase se dice que la relacin esta en: Primera Formal Normal (1FN), Segunda Forma Normal (2FN) o Tercera Forma Normal (3FN), en ese orden. Para ejemplificar el proceso de normalizacin, consideremos la siguiente relacin, que muestra los datos asociados a los pedidos de productos realizados por los clientes de una determinada compaa: 61
Csar Luza Montero
PEDIDO_DE_PRODUCTOS ID_PEDIDO FECHA

123 23/11/2008
ID_CLIENTE NOMCLI
010 E.METALICAS
ID_PROD NOMB_PROD CANT

P2 P9 COMPAC PLANILLA MTO ANUAL P2 COMPAC MTO ANUAL MTO ANUALP LOTUS 20 5 1 10 1 1 5
246
13/10/2008
020
M.SOLDADURA P9 P8
280
5/12/2008
010
E.METALICAS P12
El anlisis de la organizacin de datos en esta tabla de pedido de productos nos permite observar las siguientes anomalas que se presentan cuando se realizan operaciones de actualizacin: Si se desea registrar a un nuevo cliente, se tendra que registrar, como consecuencia, un pedido ficticio. Es decir, no se puede registrar a un cliente sin un pedido. Si se desea actualizar algn dato de un cliente, se tendra que actualizar, como consecuencia, en mas de una fila. Si se desea anular un pedido de un cliente, se tendra, como consecuencia la eliminacin del cliente. Estas anomalas corresponden a un mal diseo, procedamos a normalizar para evitar estas anomalas.
8.4.1 Pasando a 1FN

La relacin PEDIDO_DE_PRODUCTOS no est en 1FN. Para pasar a 1FN, despus de verificar que existan repeticiones de valores en algn atributo, debe descomponerse la relacin en dos relaciones: Una que contenga los atributos sin repeticiones y Otra que contenga repeticiones; si en esta ultima relacin existe la necesidad de un atributo adicional para tener una llave nica, entonces, incorporar la llave de la otra relacin. Por ejemplo, la relacin PEDIDO_DE_PRODUCTOS, se descompone en dos relaciones: PEDIDO (con los atributos sin repeticiones) y DETALLE_PEDIDO (con las repeticiones), como se muestra a continuacin: PEDIDO
ID_PEDIDO 123 246 280 FECHA 23/11/200 8 13/10/200 8 5/12/2008 ID_CLIENT E 010 020 010 NOMBRE_CLI E. METALICAS M .SOLDADURA E. METALICAS
62
Modelado y Diseo de Base de datos DETALLE_PEDIDO

ID_PEDIDO 123 123 123 246 246 280 280 ID_PRODUCTO P2 P4 P9 P2 P9 P8 P12 NOMBRE_PROD LIC. CONTA LIC. PLAN MTO. ANUAL LIC. CONTA MTO ANUAL MTO ANUAL X LOTUS CANT 20 5 1 10 1 1 5
Csar Luza Montero
8.4.2 Pasando a 2FN

Una vez asegurados que la relacin esta en 1FN, se debe preguntar si la LLAVE de la relacin NO ES CONCATENADA, entonces, estar en 2FN. Si la llave es concatenada, preguntarse por cada atributo NO PRIMO si depende totalmente de la llave. Para aquellos atributos que dependen de un subconjunto de la llave (o parcialmente de la llave) deber formarse una nueva relacin que precisamente tenga como llave este subconjunto. Por ejemplo, la relacin PEDIDO tiene llave no concatenada, entonces, esta en 2FN. En cambio, la relacin DETALLE_PEDIDO si tiene llave concatenada: DETALLE_PEDIDO
ID_PEDIDO 123 123 123 246 246 280 280 ID_PRODUCTO P2 P4 P9 P2 P9 P8 P12 NOMBRE_PROD LIC. CONTA LIC. PLAN MTO. ANUAL LIC. CONTA MTO ANUAL MTO ANUAL X LOTUS CANT 20 5 1 10 1 1 5
Observamos que NOMBRE_PROD depende de ID_PRODUCTO, (Hay dependencia parcial), entonces, no esta 2FN. Procedemos a formar otra relacin que tendr como llaves este subconjunto, a esta nueva relacin le llamamos PRODUCTO, como se muestra a continuacin: PRODUCTO
ID_PRODUCTO P2 P4 P9 P2 P9 P8 P12 NOMBRE_PROD LIC. CONTA LIC. PLAN MTO. ANUAL LIC. CONTA MTO ANUAL MTO ANUAL X LOTUS
63
Modelado y Diseo de Base de datos Y la relacin DETALLE_PEDIDO quedar como sigue: DETALLE_PEDIDO
ID_PEDIDO 123 123 123 246 246 280 280 ID_PRODUCTO P2 P4 P9 P2 P9 P8 P12 CANT 20 5 1 10 1 1 5
Csar Luza Montero
8.4.3 Pasando a 3FN

Una vez asegurados que la relacin esta en 2FN, se debe preguntar si cada uno de los atributos que no son parte de la llave, dependen directamente de ella. Para aquellos atributos que no dependan directamente de la llave, se debern formar una relacin con estos datos adjuntando como llave primaria, precisamente, al atributo a travs del cual dependen indirectamente de la llave primaria de la relacin. Por ejemplo, en la relacin PEDIDO, que se muestra abajo, el atributo no primo NOMBRE_CLI depende de la llave ID_PEDIDO, pero indirectamente a travs del dato ID_CLIENTE, por tanto, no esta 3FN. PEDIDO
ID_PEDIDO 123 246 280 FECHA 23/11/2008 13/10/2008 5/12/2008 ID_CLIENTE 010 020 010 NOMBRE_CLI E. METALICAS M .SOLDADURA E. METALICAS
Para pasar a 3FN, deber formarse una NUEVA relacin con este dato. Esta relacin deber tener como llave a ID_CLIENTE. A esta nueva tabla le llamamos CLIENTE: CLIENTE
ID_CLIENT E 010 020 010 NOMBRE_CLI E. METALICAS M .SOLDADURA E. METALICAS
Y la relacin PEDIDO quedara como sigue: PEDIDO

ID_PEDIDO 123 246 280 FECHA 23/11/200 8 13/10/200 8 5/12/2008 ID_CLIENT E 010 020 010
64
Modelado y Diseo de Base de datos Finalmente, el esquema normalizado es: CLIENTE (ID_CLIENTE, NOMBRE_CLI) PEDIDO (ID_PEDIDO, FECHA, ID_CLIENTE) PRODUCTO (ID_PRODUCTO, NOMBRE_PROD)
Csar Luza Montero
DETALLE_PEDIDO ( ID_PEDIDO, ID_PRODUCTO, CANTIDAD) .
8.5
Normalizacin Avanzada
Con las tres formas normales bsicas se pueden realizar diseo adecuados de base de datos relacionales. Sin embargo, hay casos especiales que requieren otras reglas de normalizacin, estas son: la Forma Normal de Boyce-Codd (FNBC), la Cuarta (4FN) y la Quinta Forma (5FN).
8.5.1 Forma Normal de Boyce-Code (FBNC)

Para definir la FNBC es preciso, previamente, definir el concepto de Determinante- Un Determinante es cualquier atributo o conjuntos de atributos del cual depende funcional y completamente cualquier otro atributo. Una relacin est en la forma normal de Boyce-Codd si y solo si, todo determinante es una clave candidata. Esta forma normal en realidad aade la restriccin para que cada columna que no forma parte de la clave principal deba depender de toda la clave principal La violacin de la (FNBC) es poco frecuente ya que se da bajo ciertas condiciones que raramente se presentan. Se debe comprobar si una relacin viola la (FNBC) si tiene dos o ms claves candidatas compuestas que tienen al menos un atributo en comn. Una relacin que este en (FNBC) est tambin en 1FN, 2FN y 3FN
8.5.2 Cuarta Forma Normal (4FN)

La 4FN aborda los problemas que se surgen cuando existen dependencias de conjuntos de entidades. La regla de normalizacin (4FN) est basada en la eliminacin de las relaciones de un tipo especial de dependencias multivaloradas, las cuales fueron consideradas por primera vez por Fagin (1977).
8.5.3 Quinta Forma Normal (5FN)

La quinta forma normal resuelve un problema en el que una tabla no se puede descomponer en dos tablas sin perder informacin, pero si puede descomponer en ms de dos tablas. En una relacin r puede estar presente un caso especial de dependencias llamadas dependencias de reunin, las cuales son la base de aplicacin de (5FN). Las dependencias de reunin son difciles de detectar, por lo tanto la aplicacin de esta regla de normalizacin no es muy usual. Adems hay que ver si se mejora o no la aplicacin, pues se adiciona una cierta complejidad al esquema por el nmero de relaciones nuevas que se introduce.
65
Csar Luza Montero
Resumen
El modelo relacional es un modelo de datos lgico. Los datos son representados como tablas. Una relacin o tabla es un conjunto de filas y columnas. Cada fila es un conjunto de atributos (esquema o cabecera de la relacin). El estado o contenido de la relacin es el conjunto de filas. El dominio de un atributos es el conjunto de valores que el atributo puede tomar. La Clave Candidata es un conjunto no vacio de atributos que identifican univoca y mnimamente cada tupla que cumple un esquema de relacin. Una Clave Primaria (Primary Key) es una clave candidata elegida, mediante algn criterio, para este fin. Una Clave Fornea (Foreign Key) es una combinacin de atributos cuyos valores estn basados en los valores de la clave primaria de otra tabla o de la misma tabla. La normalizacin es un proceso que permite asegurar un buen diseo de base de datos relacionalesr. Los pasos del proceso de normalizacin son los siguientes: o Representar en una nica relacin todos los atributos o Determinar las llaves candidatas y seleccionar la llave primaria o Aplicar la 2FN o Aplicar la 3FN o Analizar las relaciones obtenidas para optimizarlas Al aplicar la 2FN a una relacin, puede ser necesario crear varias tablas, ya que puede haber diferentes conjuntos de atributos no llaves que dependan, cada uno, de diferentes subconjuntos de la llave primaria y, por lo tanto, habr que hacer una tabla por cada subconjunto diferente de la llave primaria que determine a los distintos conjuntos de atributos no llaves. Los subconjuntos de la llave primaria pueden ser simples o compuestos. Al aplicar la 3FN pueden derivarse tambin varias tablas, si hay distintos conjuntos de atributos no llaves que dependen transitivamente de la llave primaria a travs de diferentes atributos ( o conjunto de atributos) no llaves primarias Al aplicar la normalizacin a un determinado fenmeno, puede ocurrir que no haya que aplicar una determinada forma normal, es decir puede ocurrir que, al encontrar bien la llave y por lo tanto tener la relacin en 1FN, ya este tambin en 2 FN o que, al llevar una relacin a 2 FN, ya este tambin en 3 FN. Puede haber varias llaves candidatas para una relacin. De estas, se escoge como llave primaria, en general, la que resulte ms cmoda para trabajar Al aplicar la normalizacin a una relacin que tiene ms de una llave candidata, independientemente de la llave primaria que se haya escogido, se obtienen modelos de datos equivalentes. Puede ocurrir que, aplicar la 3FN a una relacin, alguna de las que se deriven de ella no est aun en 3FN y, entonces es necesario aplicar nuevamente la 3FN a esta relacin resultante. En la mayora de casos, bastara con normalizar los datos hasta FNBC, tambin deber tener en cuenta algunas de nuestras advertencias o recomendaciones vertidas en esta unidad.
66
Csar Luza Montero
Actividades
1. Transformar los siguientes MER a MR
a)
nombre Nacionalidad (1,1) Titulo (1,n) Productora Ao (1,n) Nombre Nacionalidad (1,n)
DIRECTOR
DIRIGE
PELICULA (1,1)
PARTICIPA
ACTOR
Sexo AVAL
TIENE (1,n) EJEM PLAR (0,n) (1,1) SOCIO (0,n) (0,n) SOLICITA FecDevolucion DNI Nombre Direccin FecSolicitud Numero Estado
Sexo
b)
Nombre Codigo EM PLEADO (0,1)
S
Direccin
CodDe pto (1,1)
NomDe pto
(1,n)
PERTENECE
DEPARTAM ENTO
FecAsignacin
(0,1) (0,1)
FecCe se
ADM INISTRATIVO
TECNICO
(1,n)
TRABAJA
(0,n)
PROYECTO
Numero Nivel FecCe se Nombre FecInicio
67
Modelado y Diseo de Base de datos c)

Codigo Nombre
Csar Luza Montero
SUPERVISA Codigo (0,1)
DEPARTAM ENTO (1,1) (1,n)
ASIGNADO
(1,n)
EM PLEADO (1,1)
(0,n)
Estudios Nombre CONSUM E Cantidad E TIENE Pare nte sco (0,n) RECURSO Nombre CodRe curso BENEFICIARIO Dire ccin
(1,n)
De scripcin
Fe cNacimie nto
Se xo
68
Csar Luza Montero
1. Codd, E.F. (1970) "A Relational Model of Data for Large Shared Data Banks") Communications of the ACM, Vol 13 Num. 6. 2. Fagin R. (1977) Multi-Valued Dependencies and a New Normal Form for relationa data bases. ACM TODS 2 . No 3 (Septiembre) 3. Korth, H., Silberschatz, A., Sudarschan, S. (2002) Fundamentos de base de datos. 4ta. Ed. Madrid. McGrawHill/Interamericana.
69
Csar Luza Montero
GLOSARIO
1. DBA: Data Base Administrator, persona responsable de la confidencialidad, disponibilidad, seguridad e integridad de los datos almacenados en la base de datos; vigila el buen funcionamiento del sistema de base de datos. 2. DBMS: Data Base Management System, Sistema de Gestin de de Base de Datos 3. Arquitectura ANSI/x3/SPARC: Arquitectura de tres niveles (externo, conceptual e interno) que permite la independencia de datos. 4. SQL: Structured Query Language, Lenguaje de Consultas estructurado, formado por DDL, DML y DCL. 5. DDL: Data Definition Language, Lenguaje de definicin de datos 6. DML: Data Manipulation Language, Lenguaje de manipulacin de datos 7. DCL: Data Control Language, Lenguaje de Control de los datos
70
Csar Luza Montero
BIBLIOGRAFA GENERAL
1. ANSI (1977): The ANSI/X3/SPARC DBMS Framework. Report on the Study Group on Database Management Systems. D. Tsichiritzis y A. Klug (eds). Montvalle, N.J.: AFIP Press. 2. Booch, G., Rumbaugh, J. y Jacobson, I. (1999) El lenguaje unificado de modelado.
Madrid: Addison Wesley,

3. Chen, Peter (1976), The entety-relationship model:Towards a unified view of data. ACM Trans.Sistemas de bases de datos 1 (1) 9-36 4. Codd, E.F. (1970) "A Relational Model of Data for Large Shared Data Banks") Communications of the ACM, Vol 13 Num. 6. 5. Connolly, Thomas y Begg, Carolyn. (2008) Database Solutions. 5ta. Ed. Madrid. Addison Wesley. 6. Date, C. (1995) An introduction to data base systems. 5ta. Ed. Massachusetts Addison Wesley. 7. De Miguel A. y Piattini M., (1999) Fundamentos y Modelos de Base de datos. 2da. Ed. Madrid. Alfa y Omega. 8. Elmasri, Ramez y Shamkant Navathe (1997) Sistemas de Bases de Datos. Conceptos fundamentales. Segunda Edicin. Madrid. Addison-Wesley Iberoamericana. 9. Fagin R. (1977) Multi-Valued Dependencies and a New Normal Form for relationa data bases. ACM TODS 2 . No 3 (Septiembre) 10. Finkelstein, C. (1992) Strategic systems development. Sydney: Addison-Wesley. 11. Korth, H. y otros (2002) Fundamentos de base de datos. 5ta. Ed. Madrid. MacGrawHill. 12. Kroenke, D. (2003) Procesamiento de base de datos. Fundamentos, diseo e implementacin. 8va. Edicin, Mexico. Pearson Educacion. 13. Martin, James. (1975) Computer Data Base Organization. New Jersey. Prentice Hall.
71

Modelado y Diseo de Base de Datos

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelado y Diseo de Base de Datos

Uploaded by

Copyright:

Available Formats

Modelado y Diseo de Base de datos

Csar Luza Montero

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS FACULTAD DE INGENIERA DE SISTEMAS E INFORMATICA