BaseDatos-UNTR-Sistemas-DefinicionCaracteristicas

Universidad Nacional de Trujillo
Facultad de Ingeniera Ingeniera de Sistemas
Tecnologa de la Programacin II
Bases de Datos Relacionales V Ciclo
SISTEMA DE BASE DE DATOS 1. DEFINICIN: Una base de datos es un almacn que nos permite guardar grandes cantidades de informacin de forma organizada para que luego podamos encontrar y utilizar fcilmente. Una base de datos se puede definir como un conjunto de informacin relacionada que se encuentra agrupada o estructurada. Desde el punto de vista informtico, la base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulen ese conjunto de datos. Se define una base de datos como una serie de datos organizados y relacionados entre s, los cuales son recolectados y explotados por los sistemas de informacin de una empresa o negocio en particular.

Ejemplo: una biblioteca
2. CARACTERSTICAS Entre las principales caractersticas de los sistemas de base de datos podemos mencionar:

Independencia de los Datos. Es decir, que los datos no dependen del programa y por tanto cualquier aplicacin puede hacer uso de los datos. Reduccin de la Redundancia. Llamamos redundancia a la existencia de duplicacin de los datos, al reducir sta al mximo conseguimos un mayor aprovechamiento del espacio y adems evitamos que existan inconsistencias entre los datos. Seguridad. Un SBD debe permitir que tengamos un control sobre la seguridad de los datos. Podemos permitir aadir comentarios a las entradas de la base de datos. Distribucin espacial de los datos: la independencia lgica y fsica facilita la posibilidad de sistemas de bases de datos distribuidas. Los datos pueden encontrarse en otra habitacin, otro edificio e incluso otro pas. El usuario no tiene por qu preocuparse de la localizacin espacial de los datos a los que accede. Respaldo y recuperacin: se refiere a la capacidad de un sistema de base de datos de recuperar su estado en un momento previo a la prdida de datos. Se visualiza normalmente como una tabla de una hoja de clculo, en la que los registros son las filas y las columnas son los campos, o como un formulario. Permite realizar un listado de la base de datos. Manejo de mltiples vistas de los datos. Cada usuario visualiza lo que le interesa en la base de datos, pudiendo acceder a subconjuntos de datos. En el ejemplo de base de datos visto anteriormente, al departamento de Compras posiblemente le interese visualizar la tabla Productos y en

ocasiones las de Facturas (para chequear bajas en el stock), pero no la que contiene los datos de los Clientes. Acceso a travs de lenguajes de programacin estndar: se refiere a la posibilidad ya mencionada de acceder a los datos de una base de datos mediante lenguajes de programacin ajenos al sistema de base de datos propiamente dicho.
3. POR QU UTILIZAR UNA BASE DE DATOS? Una base de datos proporciona a los usuarios el acceso a datos, que pueden visualizar, ingresar o actualizar, en concordancia con los derechos de acceso que se les hayan otorgado. Se convierte ms til a medida que la cantidad de datos almacenados crece. Una base de datos puede ser local, es decir que puede utilizarla slo un usuario en un equipo, o puede ser distribuida, es decir que la informacin se almacena en equipos remotos y se puede acceder a ella a travs de una red. La principal ventaja de utilizar bases de datos es que mltiples usuarios pueden acceder a ellas al mismo tiempo. 4. COMPONENTES DE UNA BASE DE DATOS:

Hardware: constituido por dispositivo de almacenamiento como discos, tambores, cintas, etc. Software: que es el DBMS o Sistema Administrador de Base de Datos. Datos: los cuales estn almacenados de acuerdo a la estructura externa y van a ser procesados para convertirse en informacin.

5. ELEMENTOS DE UNA BASE DE DATOS En prcticamente cualquier base de datos actual existen cuatro elementos esenciales: tablas, consultas, informes y formularios. Todos son indispensables y necesarios: Tablas: Es el elemento principal de la base de datos, ya que all se registra la informacin que se quiere gestionar. Est compuesta, como si se tratase de una planilla de clculo, por filas y columnas. Cada archivo de una base de datos puede contener tantas tablas como se requiera.
A las filas de una tabla de una base de datos se les llama registros y a las columnas, campos.

Consultas: Con las consultas podremos acceder a los datos almacenados, ordenarlos y filtrarlos por diferentes criterios. La consulta, de esta manera, permite establecer criterios de bsqueda para que Access seleccione, dentro de las tablas, aquellos datos que se quieren conocer.
Informes Se utilizan para que la informacin aparezca ordenada y bien presentada en el momento de la impresin del documento.

Formularios: La informacin dentro de la base de datos puede introducirse directamente en las tablas, pero tambin a travs de un formulario lo que resulta ms cmodo y prctico . Los formularios hacen que sea ms fcil arrastrar los datos.

6. QUE ES UN DBMS O SGBD? Las siglas Data Base Management System o Sistema Gerenciador de Bases de Datos Es una coleccin de programas que permiten a los usuarios crear y mantener la BD Sirven de interfaz entre las bases de datos y las aplicaciones que la utilizan. Se compone de un lenguaje de definicin de datos, de un lenguaje de manipulacin de datos y de un lenguaje de consulta. 7. CICLO DE VIDA DE LAS OPERACIONES DE BASE DE DATOS Etapas: Planificacin del Proyecto Definicin del Sistema Recoleccin y Anlisis de los Requisitos Diseo de la Base de Datos Seleccin del SGDB / DBMS Diseo de la Aplicacin Prototipo Implementacin Conversin y Carga de datos Prueba Mantenimiento
Planificacin del Proyecto: Esta etapa con lleva la planificacin de cmo se puede llevar acabo las etapas de ciclo de vida de la manera ms eficiente, hay tres componentes principales: El trabajo que se va a realizar. Los recursos para llevarlo a cabo. El dinero para pagar todo ello.
Definicin del Sistema En esta etapa se especifica el mbito y los ndices de la aplicacin de la Base de Datos as como con que otros sistemas interactan. Tambin hay que determinar quines son los usuarios y las reas de la aplicacin.
8

Recoleccin y Anlisis de los Requisitos: En esta etapa se recoge y analiza los requerimientos de los usuarios y de las reas de aplicacin. Esta informacin se la puede recoger de varias formas: Entrevistando el personal de la empresa concretamente aquellos que son considerando expertos en la rea que se d. Observando el funcionamiento de la empresa. Examinando documentos sobre todo aquellos que se utilizan para recoger o visualizar la informacin. Utilizando cuestionario para recoger informacin de grandes grupos de usuarios. Utilizan la experiencia adquirida en el Diseo de Sistemas similares.
Esta etapa tiene como resultado en conjunto de documentos con las especificaciones de requisitos de los usuarios en donde se describen las operaciones que se realizan en la empresa desde distintos puntos de vista. Diseo de Base de datos: En esta etapa se crea un esquema conceptual de la base de datos. Se desarrollan las especificaciones hasta el punto en que puede comenzar la implementacin. Durante esta etapa se crean modelos detallados de las vistas de usuario y sobre todo las relaciones entre cada elemento del sistema, documentando los derechos de uso y manipulacin de los diferentes grupos de usuarios. El diseo consta, como se vio anteriormente, de tres fases: el diseo global o conceptual, el diseo lgico y el modelo fsico. La primera fase consiste en la produccin de un esquema conceptual que es independiente de todas las consideraciones fsicas. Este modelo se refina despus en un esquema lgico eliminando las construcciones que no se puede representar en el modelo de Base de Datos escogido (relacional, orientado a objeto, etc.). En la tercera fase el esquema lgico que traduce un esquema fsico para el sistema gestor de Base de Datos escogido. La fase de diseo fsico considera las estructuras de almacenamiento y los mtodos de acceso necesarios para proporcionar un acceso eficiente a la Base de Datos en memoria secundaria.
9

Seleccin del SGBD / DBMS: Si no se dispone de un Sistema Gestor de Base de Datos o que se encuentre obsoleto se debe escoger un SGBD que sea adecuado para el sistema de informacin. Esta eleccin se debe hacer en cualquier momento antes del diseo lgico. Diseo de aplicacin: En esta etapa de disea los programas de aplicacin que usarn y aplicar la Base de Datos, esta etapa el diseo de la Base de Datos son paralelos en la mayor parte de los casos no se puede finalizar el diseo de las aplicaciones hasta que se ha terminado el diseo de Base de Datos. Por otra lado la Base de Datos exige para dar soporte a las aplicaciones por lo que ahora una retroalimentacin desde el diseo de las aplicaciones al diseo de la Base de Datos. En esta etapa hay que asegurarse de que toda la funcionalidad especificada en los requisitos de usuarios se encuentra en el diseo de la aplicacin. Prototipo: Esta etapa es opcional es para construir prototipo de la aplicacin que permiten a los diseadores y al usuario probar el sistema, un prototipo es un modelo de trabajo de las aplicaciones del sistema. El prototipo no tiene toda la funcionalidad del sistema final pero es suficiente para que los usuarios puedan usar el sistema e identificar qu aspectos estn bien, cuales no son adecuados adems de poder sugerir mejora la inclusin de nuevos elementos. Implementacin: En esta etapa se crean las definiciones de la Base de Datos a nivel conceptual externo interno, as como los programas de aplicacin la implementacin de la Base de Datos se realiza mediante las sentencias SQL, estas sentencias se encargan de crear el sistema d la base, los ficheros donde se almacenarn los datos y las vistas de los usuarios. Los programas de aplicacin se implementan utilizando lenguaje de tercera y cuarta generacin, partes de estas aplicaciones son transacciones de la Base de Datos que se implementan tambin mediante lenguaje SQL.
10

Conversin y Carga de datos: Esta etapa es necesaria cuando se est reemplazando un sistema antiguo por uno nuevo. Los datos se cargan desde el sistema viejo al nuevo directamente si es necesario se convierte al formato que requiera el nuevo SGBD y luego se carga esta etapa se la suele llamar "Migracin". Prueba: En esta etapa se prueba y vlida el sistema con los requisitos especificados por los usuarios. Para ello se debe disear una materia de test con datos reales que se deben llevar acabo de manera metdica y rigurosa. Si la fase de prueba se lleva correctamente descubrir los errores en los programas de aplicacin y en la estructura de la Base de Datos. Mantenimiento: Una vez que el sistema est completamente probado o implementado se pone en marcha. El sistema est ahora en la fase de mantenimiento en la que se lleva acabo los siguientes tareas: monitoreo de las prestaciones del sistema y mantenimiento, y actualizacin del sistema. En esta ltima etapa todos los usuarios del sistema acceden a la base de datos y deben asegurarse el correcto funcionamiento de la misma, que sus derechos son los adecuados, teniendo a su disposicin cuanta informacin necesiten. Tambin debern asegurarse que el acceso a los datos es cmodo, prctico, seguro y que se han eliminado, en la medida de lo posible, las posibilidades de error. BASE DE DATOS RELACIONALES En la actualidad, los sistemas de bases de datos ms populares son las bases de datos relacionales. Un lenguaje llamado SQL es el lenguaje estndar internacional que se utiliza casi universalmente con las bases de datos relacionales para realizar consultas (es decir, para solicitar informacin que satisfaga ciertos criterios) y para manipular datos. Una base de datos relacional almacena los datos en tablas. se almacenan los valores. A las filas tambin se le conoce con el nombre de registros o tuplas. A las columnas tambin se les llama campos filas, y las filas, de columnas en las que
11

Es posible acceder a la informacin contenida en dos o ms tablas simultneamente.
1) CARACTERSTICAS

Una base de datos relacional se compone de varias tablas o relaciones. No pueden existir dos tablas con el mismo nombre ni registro. Cada tabla es a su vez un conjunto de registros (filas y columnas). La relacin entre una tabla padre y un hijo se lleva a cabo por medio de las claves primarias y ajenas (o forneas). Las claves primarias son la clave principal de un registro dentro de una tabla y stas deben cumplir con la integridad de datos. Las claves ajenas se colocan en la tabla hija, contienen el mismo valor que la clave primaria del registro padre; por medio de stas se hacen las relaciones
2) TERMINOLOGA RELACIONAL

Tupla. Cada fila de la tabla (cada ejemplar que la tabla representa) Atributo. Cada columna de la tabla Grado. Nmero de atributos de la tabla Cardinalidad. Nmero de tuplas de una tabla Dominio Conjunto vlido de valores representables por un atributo.
3) ELEMENTOS DE UNA BASE DE DATOS RELACIONAL TABLAS: Son estructuras encargadas de alojar la informacin de la base de datos. CAMPOS: Son cada una de las columnas de una tabla, cada campo almacena un dato en concreto. REGISTROS: Cada una de las filas de la tabla que agrupa toda la informacin de un mismo elemento. RELACIONES: Son los vnculos establecidos entre las diferentes tablas que permiten trabajar con los datos de todas ellas, como si estuvieran en una sola.
12

o Relaciones base y derivadas: A travs de las relaciones se puede acceder a la informacin de una base de datos relacional. Las Relaciones pueden ser: Relaciones Base, son relaciones que almacenan datos cuya implementacin es Una Tabla. Relaciones Derivadas, son relaciones que no almacenan datos, pero se calculan al aplicar operaciones relacionales, muestran la informacin de varias relaciones. Su implementacin es llamada Vista o Consulta. CONSULTA: Mediante el uso de consulta se puede extraer informacin concreta aunque la misma provenga de varias tablas. CLAVES: Es un campo cuyo contenido no puede estar duplicado en la misma tabla y permite identificar a cada registro de manera univoca. o Clave nica Cada tabla puede tener uno o ms campos cuya informacin es nica en cada tabla, es decir, no pueden existir dos o ms registros diferentes cuyos valores en dichos campos sean idnticos. Este conjunto de campos se llama clave nica. Pueden existir varias claves nicas en una determinada tabla, y a cada una de stas suele llamrsele candidata a clave primaria. o Clave primaria Una clave primaria es una clave nica elegida entre todas las candidatas que define unvocamente a todos los dems atributos de la tabla, para especificar los datos que sern relacionados con las dems tablas. La forma de hacer esto es por medio de claves forneas. o Clave fornea Una clave fornea es una referencia a una clave en otra tabla, determina la relacin existente en dos tablas. Las claves forneas no necesitan ser claves nicas en la tabla donde estn y s a donde estn referenciadas.
13
Por ejemplo, el cdigo de departamento puede ser una clave fornea en la tabla de empleados. Se permite que haya varios empleados en

un mismo departamento, pero habr uno y slo un departamento por cada clave distinta de departamento en la tabla de empleados. o Clave ndice Las claves ndices surgen con la necesidad de tener un acceso ms rpido a los datos. Los ndices pueden ser creados con cualquier combinacin de campos de una tabla. Las consultas que filtran registros por medio de estos campos, pueden encontrar los registros de forma no secuencial usando la clave ndice. FORMULARIOS: Son ventanas que permiten trabajar de manera cmoda sobre el contenido de varias tareas simultneamente. INFORMES: De la base de datos se adquiere la informacin y se imprime, o a travs de un pantallazo. RESTRICCIONES: Las restricciones proveen un mtodo de implementar reglas en la base de datos. Son restricciones en general limitan la estructura de la informacin almacenada en la base de datos, suministrando por tanto informacin sobre las caractersticas que respetan los datos guardados. Las restricciones pueden ser determinadas por los usuarios o pueden estar definidas dentro de la misma base de datos. Algunas otras restricciones las puede definir el usuario, por ejemplo, usar un campo con valores enteros entre 1 y 10. DOMINIOS: Es un conjunto de posibles valores para cierto atributo. Como un dominio restringe los valores del atributo, puede ser considerado como una restriccin. Matemticamente, atribuir un dominio a un atributo significa "todos los valores de este atributo deben ser elementos del conjunto especificado". Algunos ejemplos de dominios son: enteros y cadenas de texto, fecha, etc.
MODEDO ENTIDAD RELACION:
14

Es una herramienta para el modelado de datos de un sistema de informacin. Estos modelos expresan entidades relevantes para un sistema de informacin as como sus interrelaciones y propiedades. INTEGRIDAD REFERENCIAL: La integridad referencial es una propiedad deseable en las bases de datos. Gracias a la integridad referencial se garantiza que una entidad (fila o registro) siempre se relaciona con otras entidades vlidas, es decir, que existen en la base de datos. Implica que en todo momento dichos datos sean correctos, sin repeticiones innecesarias, datos perdidos y relaciones mal resueltas.
PROCEDIMIENTOS ALMACENADOS: Un procedimiento almacenado es cdigo ejecutable que se asocia y se almacena con la base de datos. Los procedimientos almacenados usualmente recogen y personalizan operaciones comunes, como insertar un registro dentro de una tabla, recopilar informacin estadstica, o encapsular clculos complejos. Son frecuentemente usados por un API por seguridad o simplicidad. Los procedimientos almacenados no son parte del modelo relacional, pero todas las implementaciones comerciales los incluyen.
15

El nombre de la tabla es Empleado, y su principal propsito es almacenar los atributos de un empleado. Esta tabla consiste de seis filas. La columna Nmero de cada fila en esta tabla es la clave principal para la tabla. Una clave principal es una columna (o grupo de columnas) en una tabla que tiene un valor nico, el cual no puede duplicarse en las dems filas. Esto garantiza que cada fila puede Identificarse por su clave principal. Algunos ejemplos de columnas con clave primaria son el nmero de DNI, el nmero del Seguro Social, un cdigo de alumno, un nmero de pieza en un sistema de inventario, etc.
16

Aqu vemos las relaciones que hay entre las tablas y podemos identificar las filas y columnas por cada tabla adems de su clave primaria. Por ejemplo, para la tabla Pacientes se tiene que pensar que campo no se repite. Podra ser el campo nombre, pero el nombre no es algo nico. Los campos nombre y apellidos juntos tambin se podran repetir en algn caso. De modo que lo ms indicado es crear un cdigo nico para cada paciente Este tipo de restricciones podemos dividirlas en: Restricciones de atributo. Restricciones de tupla. Restricciones de tabla. Restricciones de base de datos. Restricciones por usuario
Restricciones de atributo Hemos hablado del concepto de dominio, que se corresponde con los valores que puede tornar un atributo de una tabla. Normalmente, los dominios de que se dispone en cualquier S.G.B.D. son dominios muy generales, y que abarcan un conjunto de valores muy amplio que en la mayora de los casos puede satisfacer las necesidades del administrador. No obstante, hay situaciones en las que se desea restringir an ms el conjunto de estos valores. P.ej., si en una tabla de Albaranes deseamos guardar un atributo Descuento que contendr el porcentaje de descuento a aplicar, est claro que Descuento no puede poseer un valor superior al 100%. Si el S.G.B.D. slo permite decir si un atributo posee un valor entero o decimal, cmo indicar esta restriccin sobre el campo Descuento?. La solucin viene dada a travs de las restricciones de atributo. Una restriccin de atributo es un predicado en el que slo pueden intervenir constantes y, por supuesto, dicho atributo. El De esta forma, la restriccin del ejemplo anterior, quedara: Descuento < 100 Por supuesto, podemos emplear predicadores ms complejos. Si tenemos una tabla de Clientes, y deseamos saber su sexo para poder mandarles cartas personalizadas, emplearemos un atributo Sexo cuyo tipo ser Texto de 1 carcter. Est claro que los nicos valores que vamos a permitir sern V (Varn) y M (Mujer). Esto puede conseguirse con el siguiente predicado: Sexo = "V" OR Sexo = "M"
17

Hay algunos S.G.B.D. en este tipo de restricciones puede indicarse de una forma ms intuitiva Dado que el nico atributo que puede intervenir es aqul al que se refiere la propia restriccin, podemos quitarlo de la expresin, dndolo por implcito: = "V" OR = "M" Restricciones de Tupla En el caso anterior, los valores que poda tomar un determinado atributo, dependen exclusivamente de su propia condicin, o sea, con independencia del resto de los atributos de la tupla a que pertenece. No siempre ocurre as, sino que a veces, los valores de ciertos atributos de una tupla deben poseer valores consistentes entre s, y no de forma independiente. P.ej., si tenemos una tabla de Clientes y queremos almacenar datos de cada uno de ellos para hacerles la nmina, podemos incluir entre otros, los atributos de Nmero de Hijos y de Retencin IRPF. Est claro que existe una relacin entre ambos valores, de manera que si alguien no tiene hijos, su retencin de IRPF no puede ser menor que un porcentaje mnimo establecido por ley, pongamos el 10%. No podemos considerar esta restriccin como una restriccin de atributo, ya que existe una dualidad a la hora de considerar a que atributo pertenece la restriccin. Podemos verlo como una restriccin de Retencin IRPF que no puede ser menor de 10 si Nmero de hijos es igual a 0. Pero, por qu no verlo como una restriccin de Nmero de Hijos? Nmero de Hijos no puede ser 0 si Retencin IRPF es menor de 10. Esta dualidad, producida por una restriccin mutua entre dos o ms atributos de una misma tupla es lo que da lugar a una restriccin de tupla. El predicado que soluciona este problema sera: Nmero de hijos = 0 IMPLIES Retencin IRPF > 10 Restricciones de Tabla En otras situaciones, no es el valor de un atributo el que depende de los de los dems de la tupla a que pertenece, sino que es la tabla en si la que debe preservar unas propiedades globales para que la informacin que posee sea consistente.
18

Por ejemplo, supongamos que estamos gestionando las prcticas que los alumnos de Hostelera deben realizar en distintos hoteles y restaurantes de la costa. Estas prcticas vienen determinadas mediante una serie de tumos que cada alumno tiene asignado en distintas empresas. Para conseguir una enseanza de calidad deseamos que cada alumno efectu practicas por al menos 50 horas, y por supuesto, no debe darse la circunstancia de que ningn alumno tenga turnos coincidentes, esto es, en lo que coincidan fecha y hora de la practica en distintos lugres. La figura siguiente representa una situacin que no queremos que ocurra. En esta tabla hemos representado tan slo los datos referentes a dos de nuestros alumnos. Uno de ellos, Juan Yez Pi tiene asignadas 86 horas de prcticas, mientras que Ana Bernal Gracia tan slo tiene 44 horas asignadas, incumpliendo la restriccin que queremos imponer. Pero an hay ms, las tupla marcadas con una flecha entran en contradiccin, pues nos indican que de 12:00 a 18:00 Juan Yez Pi debe realizar prcticas en dos sitios distintos: el restaurante La Plata, y el restaurante Baco, lo cual es igualmente inadmisible. Con objeto de evitar este tipo de situaciones, aparecen las restricciones de tabla. Una restriccin de tabla es un predicado que engloba todas o parte de las tuplas de una misma tabla. Su valor de VERDAD o FALSEDAD no puede ser encontrado si no es con el examen de dichas tuplas. La forma de expresar este tipo de restricciones implica la utilizacin de expresiones y consultas que, por ahora, quedan fuera de nuestra visin. Baste decir que ser necesario utilizar toda una batera de mtodos de consulta que veremos ms adelante en el apartado de SQL.
19

Restricciones de base de datos. Las restricciones de base de datos son a las restricciones de tablas, lo que las de tupla son a las de atributo. Si en una restriccin de atributo slo poda intervenir un atributo, y en las de tupla podan intervenir varios (siempre de la misma tupla), las restricciones de base de datos son iguales que las de tabla con la salvedad de que pueden intervenir ms de una tabla (de la misma base de datos, evidentemente).
Supongamos p .ej. que trabajamos en una agencia de viajes en la que ofertamos paquetes de viajes; de cada paquete de viajes el nmero de plazas es limitado. As, podemos almacenar informacin de los paquetes disponibles en una tabla como la de la figura. A medida que vamos vendiendo los paquetes, iremos guardando en otra tabla el cliente que ha comprado el paquete, y el nombre del paquete comprado. De manera que tras algn tiempo, podemos tener la siguiente tabla de ventas. A poco que observemos esta tabla, vemos que hemos vendido cuatro paquetes de Alpinismo, cuando el nmero de plazas disponibles es tan solo de tres. Estamos infringiendo una restriccin de la base de datos, y lo que es para darnos cuenta de ello hemos tenido que inspeccionar los datos de ms de una tabla. Para poder detectar automticamente a travs del S.G.B.D. este tipo de situaciones hemos de indicar una restriccin de base de datos.
20

Al igual que ocurra en el caso anterior, el predicado correspondiente a esta restriccin es complejo de especificar, y su estudio est supeditado al conocimiento de SQL, que veremos ms adelante. Restricciones de usuario Estas restricciones son muy diferentes a las anteriores, y suelen estar referidas a la insercin de datos por parte de un usuario concreto. Como veremos ms adelante, cuando se crea una gran base de datos, su manejo y gestin no suele realizarlo una sola persona, sino que sobre ella trabajan muchas personas a la vez, cada una de las cuales suele efectuar unas operaciones concretas: el recepcionista suele dar entrada a los clientes (check in), les hace la factura cuando se marchan (check out), etc, mientras que el contable se centra exclusivamente en los asientos contables y no necesita saber nada de los clientes. De esta forma, podemos hacer incluso que el S.G.B.D. sepa QUIN est manejando la base de datos en cada momento, mediante un sistema en el que antes de acceder a la base de datos, el S.GB.D solicita una identificacin al usuario. En funcin del perfil que tenga asignado cada usuario (privilegios), podernos hacer que los datos que introduzca en la base de datos estn restringidos en todos los sentidos. Por ejemplo, podernos permitir que cualquier persona haga un apunte en la factura de un cliente de un hotel. Sin embargo, si este apunte supera las 100000 ptas, slo puede hacerse con el consentimiento de algn usuario especial como pueda ser p .ej. el gerente. De esta forma, el valor de un apunte en una factura est condicionado a quien es el usuario que inserta dicho apunte. Este tipo de reglas suele ser muy complejo de manejar a travs del S.G.B.D., y suelen sustituirse mediante los llamados permisos de usuario.
21

4) ESTRUCTURA La base de datos se organiza en dos marcadas secciones; el esquema y los datos (o instancia). El esquema es la definicin de la estructura de la base de datos y principalmente almacena los siguientes datos: El nombre de cada tabla El nombre de cada columna El tipo de dato de cada columna La tabla a la que pertenece cada columna
Las bases de datos relacionales pasan por un proceso al que se le conoce como normalizacin, el resultado de dicho proceso es un esquema que permite que la base de datos sea usada de manera ptima. Los datos o instancia es el contenido de la base de datos en un momento dado. Es en s, el contenido de todos los registros. 5) MANIPULACIN DE LA INFORMACIN El lenguaje ms comn para construir las consultas a bases de datos relacionales es SQL (Structured Query Language), un estndar implementado por los principales motores o sistemas de gestin de bases de datos relacionales integrados. El lenguaje SQL es el ms universal en los sistemas de base de datos. Este lenguaje nos permite realizar consultas a nuestras bases de datos para mostrar, insertar, actualizar y borrar datos. 6) MANEJADORES DE BASE DE DATOS RELACIONALES Existe software exclusivamente dedicado a tratar con bases de datos relacionales. Este software se conoce como SGBD (Sistema de Gestin de Base de Datos relacional) o RDBMS (del ingls Relational Database Management System). Entre los gestores o manejadores actuales ms populares encontramos: MySQL, PostgreSQL, Oracle, DB2, INFORMIX, Interbase, FireBird, Sybase y Microsoft SQL Server.
22

7) VENTAJAS Y DESVENTAJAS DE LAS BASES DE DATOS RELACIONALES Ventajas -Independencia de los datos y los programas y procesos. Esto permite modificar los datos sin modificar el cdigo de las aplicaciones. -Menor redundancia. No hace falta tanta repeticin de datos. Aunque, slo los buenos diseos de datos tienen poca redundancia. -Integridad de los datos. Mayor dificultad de perder los datos o de realizar incoherencias con ellos. -Mayor seguridad en los datos. Al limitar el acceso a ciertos usuarios. -Datos ms documentados. Gracias a los metadatos que permiten describir la informacin de la base de datos. -Acceso a los datos ms eficiente. La organizacin de los datos produce un resultado ms ptimo en rendimiento. -Menor espacio de almacenamiento. Gracias a una mejor estructuracin de los datos. -Provee herramientas que garantizan la duplicidad de registros. -Garantiza la integridad referencial, as, al eliminar un registro elimina todos los registros relacionados dependientes. Desventajas: - Una de las desventajas de las bases de datos relacionales es la costosa creacin y mantenimiento del sistema. Con el fin de establecer una base de datos relacional, por lo general, se necesita comprar un software especial. Sin embargo, lleva tiempo ingresar toda la informacin y configurar el programa. Si la empresa es grande y se necesita una base de datos ms robusta, tendrs que contratar a un programador para crear una base de datos relacional utilizando el lenguaje de consulta estructurado (SQL, por sus siglas en ingls) y a un administrador de base de datos para el mantenimiento una vez instalada. Independientemente de los datos que utilices, tendrs que, o bien importarlos de otros archivos de datos, como texto u hojas de clculo de Excel, o introducirlos manualmente.
23

-Requiere personal cualificado. Debido a la dificultad de manejo de este tipo de sistemas. - Abundancia de informacin. Los avances en la complejidad de la informacin causan otro inconveniente en las bases de datos relacionales. Las bases de datos relacionales se realizan para organizar los datos por caractersticas comunes. Las imgenes complejas, nmeros, diseos y productos multimedia desafan una fcil categorizacin liderando el camino para un nuevo tipo de base de datos relacional de objetos llamada sistemas de gestin de bases de datos. Estos sistemas estn diseados para manejar aplicaciones ms complejas y tienen la capacidad de ser escalables. -Ausencia de estndares reales. Lo cual significa una excesiva dependencia hacia los sistemas comerciales del mercado. Aunque hay una buena parte de esta tecnologa aceptada como estndar de hecho. - Algunas bases de datos relacionales tienen lmites en cuanto a la longitud de los campos. Al disear la base de datos, debes especificar la cantidad de datos que pueden caber en un campo. Algunos de los nombres o las consultas de bsqueda son ms cortos que el actual, y esto puede conducir a la prdida de datos. -Los sistemas complejos de bases de datos relacionales pueden conducir a que estas bases de datos se conviertan en "islas de informacin", donde la informacin no puede ser compartida fcilmente de un sistema a otro. A menudo, las grandes empresas o instituciones, se encuentran con que las bases de datos relacionales en divisiones separadas crecieron de manera diferente. Por ejemplo, tal vez el departamento de facturacin del hospital utiliza una base de datos, mientras que el departamento de personal del hospital utiliza una base de datos diferente. Lograr que las bases de datos se "comuniquen" entre s puede ser largo, costoso y abrumador. 8) DISEO DE BASE DE DATOS RELACIONAL El diseo de una base de datos relacional consiste bsicamente en generar un conjunto de esquemas de relaciones que permitan almacenar la informacin con un mnimo de redundancia, pero que a la vez facilite la recuperacin de la informacin almacenada en ella. CARACTERISTICAS DEL DISEO RELACIONAL.
24
El modelo relacional para la gestin de una base de datos es un modelo de datos basado en la lgica de predicados y en la teora de conjuntos. Es el

modelo ms utilizado en la actualidad para modelar problemas reales y administrar datos dinmicamente. En este modelo todos los datos son almacenados en relaciones, y como cada relacin es un conjunto de datos, el orden en el que stos se almacenen no tiene relevancia (a diferencia de otros modelos como el jerrquico y el de red). Esto tiene la considerable ventaja de que es ms fcil de entender y de utilizar por un usuario no experto. La informacin puede ser recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la informacin. Para manipular la informacin utilizamos un lenguaje relacional, actualmente se cuenta con dos lenguajes formales el lgebra relacional y el Clculo relacional. El lgebra relacional permite describir la forma de realizar una consulta, en cambio, el Clculo relacional slo indica lo que se desea devolver. Esquema: Un esquema es la definicin de una estructura (generalmente relaciones o tablas de una base de datos), es decir, determina la identidad de la relacin y que tipo de informacin podr ser almacenada dentro de ella. Instancias: Una instancia de manera formal es la aplicacin de un esquema a un conjunto finito de datos. En palabras no tan tcnicas, se puede definir como el contenido de una tabla en un momento dado, pero tambin es vlido referirnos a una instancia cuando trabajamos o mostramos nicamente un subconjunto de la informacin contenida en una relacin o tabla. DOMINIOS ATOMICOS Y LA FORMA NORMAL. Dominio Atmico. El dominio se refiere a todos los valores que se desprenden de un atributo o que son legales o permitidos en la base de datos, y atmico significa indivisible, es decir, cada atributo debe contener un nico valor del dominio. Adems, cada valor debe tener un nombre nico, ya que la creacin de tablas implica la definicin de columnas de un tipo concreto y con un nombre nico. Tampoco pueden existir tuplas idnticas. Por ejemplo si un registro es modificado ms de una vez el mismo da, no deber crearse un registro nuevo cada vez. Formas Normales Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos est en la forma normal N es decir que todas sus tablas estn en la forma normal N. En general, las primeras tres formas normales son suficientes para cubrir las necesidades de las bases de datos. El creador de estas tres primeras formas normales o reglas de creacin de una base de datos
25

fue Edgar F. Codd. Dichas formas normales se representan en un orden similar al que se muestra en la siguiente figura.
Primera Forma Normal (1FN) Aplicar la primera forma normal es muy simple, bastara con dividir cada columna no atmica en tantas columnas atmicas como sea necesario. Por ejemplo, si tenemos una relacin que contiene la informacin de una agenda de amigos con este esquema: Agenda (Nombre, Email) El nombre normalmente, estar compuesto por el tratamiento (seor, seora, don, doa, seorita, etc), el nombre en si de la persona y los apellidos. Podramos en este caso, considerar el nombre como un dato atmico, pero puede interesarnos separar algunas de las partes que lo componen, por lo que podra quedar de la siguiente forma: Agenda (Nombre_Tratamiento, Nombre_Pila, Nombre_Apellidos, Email). Por tanto, tenemos que: Una tabla est en primera forma normal si: o o o o o Todos los atributos son atmicos. La tabla contiene una clave primaria. La clave primaria no contiene atributos nulos. No existe variacin en el nmero de columnas. Los campos no clave deben de identificarse por la clave principal (Dependencia Funcional). o Una tupla no puede tener mltiples valores de cada columna. o Esta forma normal elimina los valores repetidos dentro de una BD. Por lo general la mayora de las relaciones cumplen con estas caractersticas, as que podemos decir que la mayora de las relaciones se encuentran en la primera forma normal. Para ejemplificar como se representan grficamente las relaciones en primera forma normal
26

consideremos la relacin alumno cursa materia cuyo diagrama E-R es el siguiente:
Como esta relacin maneja valores atmicos, es decir un solo valor por cada uno de los campos que conforman a los atributos de las entidades, ya se encuentra en primera forma normal, grficamente as representamos a las relaciones en 1FN. DEPENDENCIAS FUNCIONALES. Una dependencia funcional es una relacin entre atributos de una misma relacin (tupla). Es decir, si X e Y son atributos de la relacin R, se dice que Y es funcionalmente dependiente de X (se denota por XY) si cada valor de X tiene asociado un solo valor de Y (X e Y pueden constar de uno o varios atributos). Cada dependencia funcional es una clase especial de regla de integridad y representa una relacin de uno a muchos.
Dependencia funcional mutua: ab y ba o lo que es lo mismo ab. Ntese que el concepto de dependencia funcional no depende de la extensin concreta (contenido) que en un momento determinado tenga la tabla sino cualquier posible extensin que pudiera tener. Los atributos a y b pueden ser simples o compuestos (formados por la agregacin de varios atributos). Reflexividad. A partir de cualquier atributo o conjunto de atributos siempre puede deducirse el mismo. Dependencia Trivial: xx.
27

Aumentatividad. Si XY entonces X+ZY. As se puede aumentar trivialmente el antecedente de una dependencia. Ejemplo: si con el DNI se determina el nombre de una persona, entonces con el DNI ms la direccin tambin se determina el nombre. Proyectividad. Si XY+Z entonces XY. ejemplo: si a partir del DNI es posible deducir el nombre y la direccin de una persona, entonces con el DNI es posible determinar el nombre. Aditividad. Si XY y ZW entonces X+ZY+W. Ejemplo: si con el DNI se determina el nombre y con la direccin se determina el telfono de una persona, entonces con el DNI y la direccin se puede determinar el nombre y el telfono. Transitividad o Enlace de Dependencias Funcionales. Si XY e YZ entonces XZ. Ejemplo: si con el DNI puede determinarse el cdigo postal de residencia de la persona, y con este cdigo puede determinarse el nombre de la provincia, entonces con el DNI puede determinarse el nombre de la provincia. Este es el mecanismo bsico de funcionamiento del enlace entre tablas a partir de claves ajenas.
SEGUNDA FORMA NORMAL (2FN). Para definir formalmente la segunda forma normal requerimos saber que es una dependencia funcional: Consiste en edificar que atributos dependen de otro(s) atributo(s).
Definicin formal: Una relacin R est en 2FN si y solo si est en 1FN y los atributos no primos dependen funcionalmente de la llave primaria. Una relacin se encuentra en segunda forma normal, cuando cumple con las reglas de la primera forma normal y todos sus atributos que no son claves (llaves) dependen por completo de la clave. De acuerdo con esta definicin, cada tabla que tiene un atributo nico como clave, est en segunda forma normal. La segunda forma normal se representa por dependencias funcionales como:
28

Ntese que las llaves primarias estn representadas con doble cuadro, las flechas nos indican que de estos atributos se puede referenciar a los otros atributos que dependen funcionalmente de la llave primaria. TERCERA FORMA NORMAL (3FN). Para definir formalmente la 3FN necesitamos definir dependencia transitiva: En una afinidad (tabla bidimensional) que tiene por lo menos 3 atributos (A, B, C) en donde A determina a B, B determina a C pero no determina a A. Definicin formal: Una relacin R est en 3FN si y solo si est en 2FN y todos sus atributos no primos dependen no transitivamente de la llave primaria. Consiste en eliminar la dependencia transitiva que queda en una segunda forma normal, en pocas palabras una relacin est en tercera forma normal si est en segunda forma normal y no existen dependencias transitivas entre los atributos, nos referimos a dependencias transitivas cuando existe ms de una forma de llegar a referencias a un atributo de una relacin. Por ejemplo, consideremos el siguiente caso:
29
Tenemos la relacin alumno-cursa-materia manejada anteriormente, pero ahora consideramos al elemento maestro, grficamente lo podemos representar de la siguiente manera:

Podemos darnos cuenta que se encuentra graficado en segunda forma normal, es decir que todos los atributos llave estn indicados en doble cuadro indicando los atributos que dependen de dichas llaves, sin embargo en la llave Necono tiene como dependientes a 3 atributos en el cual el nombre puede ser referenciado por dos atributos: Necono y RFC (Existe dependencia transitiva), podemos solucionar esto aplicando la tercera forma normal que consiste en eliminar estas dependencias separando los atributos, entonces tenemos:
FORMA NORMAL BOYCE-COD. Determinante: Uno o ms atributos que, de manera funcional, determinan otro atributo o atributos. En la dependencia funcional (A,B) C, (A,B) son los determinantes.
30

Definicin formal: Una relacin R est en FNBC si y solo si cada determinante es una llave candidato. Denominada por sus siglas en ingls como BCNF; Una tabla se considera en esta forma si y slo s cada determinante o atributo es una llave candidato. Continuando con el ejemplo anterior, si consideramos que en la entidad alumno sus atributos control y nombre nos puede hacer referencia al atributo esp., entonces decimos que dichos atributos pueden ser llaves candidato. Grficamente podemos representar la forma normal de Boyce Codd de la siguiente forma:
Obsrvese que a diferencia de la tercera forma normal, agrupamos todas las llaves candidato para formar una global (representadas en el recuadro) las cuales hacen referencia a los atributos que no son llaves candidato. INTEGRIDAD DE LA BASE DE DATOS. Integridad de datos en bases de datos: Integridad de datos se refiere al estado de correccin y completitud de los datos ingresados en una base de datos. Los SGBD relacionales deben ser capaces de mantener la integridad de los datos almacenados en una base de datos con respecto a las reglas predefinidas o restricciones que el administrador y creador de la base de datos determine. Un claro ejemplo de error de integridad es el ingreso de un tipo de dato incorrecto dentro de un campo. Por ejemplo, ingresar un texto cuando se espera un nmero entero. Tambin un error en la integridad de una base de datos puede ser la existencia de un valor numrico (ID_Cliente) en la compra de un producto por parte de un cliente que no existe en su correspondiente tabla con ese nmero. (Integridad referencial). La exigencia de integridad de los datos garantiza la calidad de los datos de la base de datos. Por ejemplo, si se especifica para un empleado el valor de identificador de 123, la base de datos no debe permitir que ningn otro empleado tenga el mismo valor de identificador. Si tiene una columna employee_rating para la que se prevean valores entre 1 y 5, la base de datos no debe aceptar valores fuera de ese intervalo.
31

Dos pasos importantes en el diseo de las tablas son la identificacin de valores vlidos para una columna y la determinacin de cmo forzar la integridad de los datos en la columna. 9) EJEMPLOS DE BASES DE DATOS RELACIONALES Para cada ejercicio se presenta la solucin final que se obtiene tras el diseo lgico, es decir, el conjunto de relaciones que forman el esquema lgico de la base de datos, las claves ajenas y sus reglas. EJEMPLO 1 CLIENTE(dnicli,nombre,direccin) Esta tabla almacena los datos personales de los clientes. PROCURADOR(dniproc,nombre,direccin) Esta tabla almacena los datos personales de los procuradores. ASUNTO(numexp,dnicli,fechaini,fechafin,estado) ASUNTO.dnicli es clave ajena a CLIENTE (cliente al que pertenece el asunto) Esta tabla almacena los datos de los asuntos y el cliente al que pertenecen. ASUNTO_PROC(numexp,dniproc) ASUNTO_PROC.numexp es clave ajena a ASUNTO (asunto que es llevado por algn procurador) ASUNTO_PROC.dniproc es clave ajena a PROCURADOR (procurador que lleva el asunto) En esta tabla se especifica qu procuradores llevan cada asunto y los asuntos que lleva cada procurador. Nulos ASUNTO.dnicli No (1) ASUNTO_PROC.numexp No ASUNTO_PROC.dniproc No Borrado Restringir (2) Propagar (3) Restringir (4) Modificacin Propagar Propagar Propagar
Veamos la interpretacin de algunas de las reglas que acabamos de especificar para las claves ajenas, una vez consultadas con los propietarios de la informacin: (1) Todo asunto debe pertenecer a un cliente conocido. (2) No se puede eliminar un cliente si ste tiene algn asunto. (3) Si se elimina un asunto, ya no se mantiene la informacin respecto a los procuradores que lo llevaban. (4) No se puede eliminar un procurador si ste lleva o ha llevado algn asunto.
32

EJEMPLO 2 ZOO(nombre,ciudad,pas,tamao,presupuesto) Esta tabla almacena los datos de los zoos. ESPECIE(nomcientfico,nomvulgar,familia,peligro) Esta tabla almacena los datos que caracterizan las especies animales. ANIMAL(numid,nomzoo,nomespecie,sexo,aonacim,pas,continente) ANIMAL.nomzoo es clave ajena a ZOO (zoo en el que se encuentra el animal) ANIMAL.nomespecie es clave ajena a ESPECIE (especie a la que pertenece el animal) Esta tabla almacena los datos de los animales, la especie a la que pertenece cada uno y el zoo en el que se encuentran. Nulos No (1) No (1) Borrado Restringir (2) Restringir (3) Modificacin Propagar Propagar
ANIMAL.nomzoo ANIMAL.nomespecie
Veamos la interpretacin de algunas de las reglas que acabamos de especificar para las claves ajenas, despus de haberlas consultado con los propietarios de la informacin: (1) Todo animal se encuentra en un zoo conocido y pertenece a una especie conocida. (2) No se puede eliminar un zoo que tiene animales. Se podra dar la opcin de cambiar todos sus animales a otros zoos, y una vez repartidos todos, ya se puede eliminar el zoo que ha quedado vaco. (3) No se puede eliminar una especie si hay animales en los zoos que pertenecen a la misma. EJEMPLO 3 SOCIO(codsocio,nombre,direccin,telfono) En esta tabla se almacenan los datos personales de los socios. DIRECTOR(nomdirector) En esta tabla se guardan nombres de directores de pelculas. Cualquier dato adicional que se desee saber de los directores, se colocar en esta tabla aadiendo nuevas columnas. El esquema de la base de datos es as flexible ya que acepta la introduccin de nueva informacin en el esquema sin introducir por ello redundancias de datos. ACTOR(nomactor) En esta tabla se guardan nombres de actores de pelculas. Cualquier dato adicional sobre los actores se podr aadir a esta tabla mediante nuevas columnas. El esquema sigue siendo flexible.
33

GENERO(nomgnero) En esta tabla se guardan nombres de gneros de pelculas. PELICULA(ttulo,nomdirector,nomgnero) PELICULA.nomdirector es clave ajena a DIRECTOR (director de la pelcula) PELICULA.nomgnero es clave ajena a GENERO (gnero al que pertenece la pelcula) En esta tabla se almacena el ttulo de las pelculas que hay en el vdeo club, el director y el gnero de la pelcula. CINTA(numcinta,ttulo,nomdirector) (CINTA.ttulo,CINTA.nomdirector) es clave ajena a PELICULA (pelcula que hay grabada en la cinta) En esta tabla se guarda informacin sobre las cintas que posee el vdeo club. Cada cinta tiene grabada una sola pelcula. PRESTAMO(numcinta,fecha,codsocio) PRESTAMO.numcinta es clave ajena a CINTA (cinta que est actualmente prestada) PRESTAMO.codsocio es clave ajena a SOCIO (socio que tiene prestada la cinta) Cuando se presta una cinta a un socio, se registra en esta tabla. DEVUELTA(numcinta,fecha,codsocio) Se supone que la fecha contiene informacin tambin sobre la hora en que se realiza el prstamo. DEVUELTA.numcinta es clave ajena a CINTA (cinta que fue prestada y ya ha sido devuelta) DEVUELTA.codsocio es clave ajena a SOCIO (socio que tom prestada la cinta y ya la ha devuelto) Cuando un socio devuelve una cinta que tena prestada, la tupla correspondiente a dicho prstamo se copia en esta tabla y se borra de PRESTAMO. LISTA_ESPERA(codsocio,ttulo,nomdirector,fecha,hora) LISTA_ESPERA.codsocio es clave ajena a SOCIO (socio que est esperando ver una pelcula) (LISTA_ESPERA.ttulo,LISTA_ESPERA.nomdirector) es clave ajena a PELICULA (pelcula que tiene socios en lista de espera) Los atributos fecha, hora se han aadido para mantener el orden en la lista de espera. En esta tabla se especifica la lista de espera de socios para cada pelcula. Un mismo socio puede estar en la lista de espera de varias pelculas a la vez. Cuando el socio consigue la pelcula, se elimina de la lista. REPARTO(ttulo,nomdirector,nomactor) (REPARTO.ttulo,REPARTO.nomdirector) es clave ajena a PELICULA (pelcula que de la que conocemos el reparto de actores) REPARTO.actor es clave ajena a ACTOR (actor que aparece en el reparto de la pelcula) En esta tabla se almacena informacin sobre las pelculas en las que ha intervenido cada actor. Un mismo actor puede haber participado en varias pelculas.
34

GUSTA_DIRECTOR(codsocio,nomdirector) GUSTA_DIRECTOR.codsocio es clave ajena a SOCIO (socio al que le gustan directores) GUSTA_DIRECTOR.nomdirector es clave ajena a DIRECTOR (director que le gusta al socio) En esta tabla se almacenan los gustos, en cuanto a directores, de cada socio (a cada socio le pueden gustar varios directores). GUSTA_ACTOR(codsocio,nomactor) GUSTA_ACTOR.codsocio es clave ajena a SOCIO (socio al que le gustan actores) GUSTA_ACTOR.nomactor es clave ajena a ACTOR (actor que le gusta al En esta tabla se almacenan los gustos, en cuanto a actores, de cada socio (a cada socio le pueden gustar varios actores). GUSTA_GENERO(codsocio,nomgnero) GUSTA_GENERO.codsocio es clave ajena a SOCIO (socio al que le gustan gneros de pelculas) GUSTA_GENERO.nomgnero es clave ajena a GENERO (gnero que le gusta al socio) En esta tabla se almacenan los gustos, en cuanto a gneros, de cada socio (a cada socio le pueden gustar varios gneros). Tras consultar con los propietarios de la informacin, se han establecido las siguientes reglas para las claves ajenas: Nulos Borrado PRESTAMO.codsocio No Restringir (1) DEVUELTA.codsocio No Restringir (1) LISTA_ESPERA.codsocio No Propagar (1) GUSTA_DIRECTOR.codsocio No Propagar (1) GUSTA_ACTOR.codsocio No Propagar (1) GUSTA_GENERO.codsocio No Propagar (1) (CINTA.ttulo,CINTA.nomdirector) No Propagar (2) (LISTA_ESPERA.ttulo, LISTA_ESPERA.nomdirector) No Restringir (2) (REPARTO.ttulo,REPARTO.nomdirector) No Propagar (2) PRESTAMO.numcinta No Restringir (3) DEVUELTA.numcinta No Restringir (3) PELICULA.nomdirector No Restringir (4) GUSTA_DIRECTOR.nomdirector No Restringir (4) REPARTO.nomactor No Restringir (5) GUSTA_ACTOR.nomactor No Restringir (5) PELICULA.nomgnero No Restringir (6) GUSTA_GENERO.nomgnero No Restringir (6) Modific. Propagar Propagar Propagar Propagar Propagar Propagar Propagar Propagar Propagar Propagar Propagar Propagar Propagar Propagar Propagar Propagar Propagar
35

(1) Si se elimina un socio, ya no se quiere conocer sus gustos en cuanto a directores, actores y gneros. Adems, se elimina de las listas de espera en las que se encontraba. No se puede eliminar un socio que ha tomado prestada alguna pelcula en alguna ocasin. (2) Si se elimina una pelcula, se eliminan todas sus copias y la informacin sobre su reparto de actores. No se puede eliminar una pelcula que tiene socios en lista de espera. (3) No se puede eliminar una cinta que ha sido prestada alguna vez. (4) No se pueden eliminar directores que han dirigido alguna pelcula o que le gustan a algn socio. (5)No se pueden eliminar actores que aparecen en el reparto de alguna pelcula o que le gustan a algn socio. (6) No se puede eliminar un gnero si hay pelculas del mismo o si es un gnero que le gusta a algn socio. Por motivos de eficiencia puede ser necesario cambiar el diseo, uniendo las tablas PRESTAMO y DEVUELTA, quedando de este modo: PRESTAMO(numcinta,fecha,codsocio,pres_dev) El nuevo atributo pres_dev tomar el valor 'prestada' si la cinta est prestada actualmente, y tomar el valor 'devuelta' si la cinta ya ha sido devuelta y el prstamo ha finalizado. Antes, la tabla PRESTAMO tena como clave primaria numcinta, con lo que no era posible que una misma cinta apareciese como prestada a dos socios a la vez. Ahora, al unir los prstamos actuales y los finalizados, la clave primaria es (numcinta,fecha) y se debe aadir una regla de integridad que se encargue de respetar que cada cinta puede estar prestada (actualmente) a un nico socio.
36

10) DESCRIPCION DEL SOFTWARE WORKBENCH MySQL Workbench: MySQL Workbench es una herramienta visual de base de datos unificada para arquitectos, desarrolladores y administradores de bases. MySQL Workbench ofrece modelado de datos, desarrollo de SQL y herramientas completas de administracin de servidor de administracin de configuracin, el usuario y mucho ms. MySQL Workbench est disponible en Windows, Linux y Mac OS. Ventana Principal
Diseo MySQL Workbench permite a un DBA, desarrollador o arquitecto de datos para disear visualmente, modelo, generar y gestionar bases de datos. Incluye todo lo que un modelador de datos necesita para crear modelos ER complejas, hacia adelante y la ingeniera inversa, y tambin ofrece caractersticas clave para realizar la gestin del cambio difcil y tareas de documentacin que normalmente requieren mucho tiempo y esfuerzo.
37

Desarrollo MySQL Workbench proporciona herramientas visuales para crear, ejecutar, y optimizar consultas SQL. El Editor SQL proporciona el color de resaltado de sintaxis, la reutilizacin de fragmentos de SQL, y el historial de ejecucin de SQL. El panel de conexiones de base de datos permite a los desarrolladores para gestionar fcilmente las conexiones de base de datos. El Examinador de objetos permite el acceso instantneo a esquemas de bases de datos y objetos. Administrar MySQL Workbench proporciona una consola visual para administrar fcilmente entornos MySQL y obtener una mejor visibilidad en bases de datos. Los desarrolladores y DBAs pueden utilizar las herramientas visuales para la configuracin de los servidores, la administracin de usuarios y la visualizacin de la salud de base de datos. Migracin de base de datos MySQL Workbench proporciona ahora una solucin fcil de usar completa, para la migracin de Microsoft SQL Server, Sybase ASE, PostgreSQL, y otras tablas RDBMS, los objetos y los datos a MySQL. Los desarrolladores y DBAs pueden convertir rpidamente y fcilmente las aplicaciones existentes se ejecuten en MySQL tanto en Windows y otras plataformas. La migracin tambin es compatible con la migracin desde versiones anteriores de MySQL a las ltimas versiones. CREACIN DE UN MODELO En esta seccin, aprenders cmo crear un nuevo modelo de base de datos, crear una tabla, cree un diagrama EER de su modelo, y luego como ingeniero enve su modelo en el servidor de base de datos en vivo. 1. Iniciar MySQL Workbench. En la ventana principal, seleccione Crear nuevo Modelo EER. Un modelo puede contener mltiples esquemas. Tenga en cuenta que cuando se crea un nuevo modelo, que contiene el mydbesquema por defecto. Puede cambiar el nombre de este esquema para servir a sus propios fines, o eliminarlo.
38

2. En la barra de herramientas Schemata fsica, haga clic en el botn + para aadir un nuevo esquema. Esto crear un nuevo esquema y mostrar una Hoja Pestaa para el esquema. En la Hoja Pestaa, cambie el nombre del esquema al "dvd_collection", escribiendo en el campo llamado Nombre. Asegrese de que este cambio se refleja en la ficha Esquemas fsica. Ahora ya est listo para agregar una tabla a su esquema.
39

3. En la seccin Esquemas fsica, haga doble clic en Agregar tabla. 4. Esto cargar automticamente el editor de tablas, con el nombre de tabla por defecto es tabla1. En el editor de tablas, cambiar el nombre de la tabla de "tabla 1" a "pelculas". 5. A continuacin, aadir varias columnas. Haga doble clic en una celda de la columna Nombre de la columna, y el primer campo de forma predeterminada "moviesid" porque MySQL Workbench agrega "id" para el nombre de tabla como valor predeterminado para el campo inicial. Cambiar el nombre a "movie_id" y mantener eltipo de datos como INT . A continuacin, asegrese de PK (PRIMARY KEY), NN (NOT NULL) y AI(AUTO_INCREMENT) sean controladas. 6. Aadir dos columnas adicionales utilizando el mismo mtodo que se ha descrito anteriormente:
Nombre de columna
MOVIE_TITLE RELEASE_DATE
Tipo de datos
Propiedades de las columnas
40
VARCHAR (45) NN Fecha (AAAA-MM-DD) Ninguno

7. Ahora se puede obtener una representacin visual de este esquema hasta ahora. En el men principal, seleccione Modelo, Crear Diagrama del catlogo Objects. El diagrama EER se crea y se muestra.
41

8. En el editor de tablas, cambiar el nombre de la columna "MOVIE_TITLE" a "ttulo". Tenga en cuenta que el diagrama EER se actualiza automticamente para reflejar este cambio. 9. En este punto, usted puede guardar su modelo. Haga clic en el botn de barra de herramientas Guardar modelo en archivo actual. Usted an no ha guardado el archivo para que se le pedir que introduzca un nombre de archivo de modelo. Para este tutorial, introduzca "Home_Media". El modelo Home_Media puede contener adems esquemas, adems de dvd_collection , tales como cd_collection . Haga clic en Guardarpara guardar el modelo. 10. Puede sincronizar el modelo con el servidor de base de datos activa. En primer lugar, usted debe decirle a MySQL Workbench cmo conectar con el servidor en vivo. En el men principal, seleccione Base de datos, en Administrar conexiones.... 11. En el cuadro de dilogo Gestionar conexiones DB, haga clic en Nuevo. 12. Escriba "Big servidor de Hierro" para el nombre de la conexin. Esto le permite identificar el servidor a la que corresponde esta conexin, a pesar de que es posible crear mltiples conexiones con el mismo servidor. 13. Introduzca el nombre de usuario de la cuenta que utilizar para conectarse al servidor. 14. Haga clic en la tienda en Bveda... botn e introduzca la contrasea para el nombre de usuario que introdujo en el paso anterior. Puede pasar por alto este paso opcional, y se le solicitar esta contrasea cada vez que MySQL Workbench se conecta al servidor. 15. Haga clic en Probar conexin para comprobar los parmetros de conexin. Si todo est bien en este momento, puede hacer clic en Cerrar.
42

16. Ahora est listo para disear adelante su modelo en el servidor en vivo. En el men principal, seleccioneBase de datos, Ingeniero Forward.... Aparecer el Ingeniero Forward Base de datos del asistente. 17. La pgina Opciones del asistente muestra varias opciones avanzadas. Para este tutorial, puede ignorar esto y haga clic en Siguiente. 18. En la pgina siguiente, usted puede seleccionar el objeto que desea exportar al servidor en vivo. En este caso, es suficiente con una mesa, por lo que ningn otro objeto necesita ser seleccionado. Haga clic en Siguiente. 19. En la pgina siguiente, Revista SQL Script, muestra la secuencia de comandos que se ejecuta en el servidor activo para crear el esquema. Revise la secuencia de comandos para asegurarse de que comprende las operaciones que se llevarn a cabo. Haga clic en Siguiente.
43

20. Seleccione la conexin que cre anteriormente, "Big Iron Server". Haga clic en Ejecutar. Compruebe los mensajes de errores, haga clic en Cerrar para salir del asistente 21. Asegrese de que el guin corri sin error en el servidor, a continuacin, haga clic en Cerrar. Como prueba de que el guin trabaj en marcha la lnea de comandos de cliente MySQL (mysql). Introduzca SHOW DATABASES; e identificar el esquema. Introduzca USE dvd_collection; para seleccionar el esquema. A continuacin, introduzca SHOW TABLES; . Escriba SELECT * FROM movies; , esto devolver el conjunto vaco que an no ha entrado en los datos en su base de datos. Tenga en cuenta que es posible utilizar MySQL Workbench para llevar a cabo dichos controles, y ver cmo hacer esto ms tarde, pero la lnea de comandos de cliente MySQL se ha utilizado aqu como es probable que haya usado antes. 22. Asegrese de que su modelo se guarda. Haga clic en Guardar modelo en archivo actual en la barra de herramientas principal.
44

45
El estilo de la notacin de objeto utilizado en la Figura 7.50, "El sakila Database Diagram EER " es Workbench (PKs only) . Esta notacin slo muestra las claves

primarias y hay otras columnas, lo cual es especialmente til cuando el espacio es un bien escaso. La notacin relacin es la predeterminada, pata de gallo. Como las lneas de conexin muestran, cada tabla est relacionada con al menos otra tabla en la base de datos (con la excepcin de la film_text tabla). Algunas mesas tienen dos claves externas que se refieren a la misma mesa. Por ejemplo, la film tabla tiene dos claves externas que se relacionan con el language mesa, es decir,fk_film_language_original y fk_film_language . Cuando exista ms de una relacin entre dos tablas, las lneas de conexin se ejecutan simultneamente. Identificar y relaciones nonidentifying se indica por las lneas continuas y discontinuas, respectivamente. Por ejemplo, la clave externa category_id es parte de la clave principal de la film_category mesa para que su relacin con la category la tabla se dibuja con una lnea continua. Por otro lado, en la city tabla, la clave externa, country_id , no es parte de la clave primaria por lo que la conexin utiliza una lnea de trazos. 11) EJEMPLO DE BASE DE DATOS RELACIONAL EN WORKBENCH DESCRIPCION DEL CASO El laboratorio de Anlisis Clnicos Primavera surge con la finalidad de entregar apoyo al accionar medico a travs de la realizacin de exmenes de Laboratorio a pacientes para contribuir en el diagnstico de enfermedades y control de tratamiento de pacientes. PRINCIPALES PROBLEMAS DE LA ORGANIZACIN -Lentitud en el manejo de la informacin en los procesos de bsqueda, reportes y dems requerimientos de informacin que se solicita. -Prdida de tiempo en el acceso a los datos y a la gestin de los pacientes, pues en el registro, reporte y bsqueda de pacientes y sus resultados, se utiliza una hoja de clculo en Excel. -Procedimiento de registro de pacientes nuevos, en forma manual, esto causa demora en el proceso de la informacin del paciente. -Los reportes de historial clnico que se brinda a los pacientes no estn bien estructurados, esto causa que el paciente no reciba un reporte detallado de sus anlisis realizados en forma oportuna. REQUERIMIENTOS FUNCIONALES -El sistema permitir realizar el mantenimiento de tipo de anlisis, las citas e Historias Clnicas. -El sistema permitir listar pacientes, Historias Clnicas, por diversos filtros. -Permitir registrar citas por internet por parte de los pacientes reales.
46

-Permitir consultar el monto de venta y utilidad por lnea de los pacientes, por documento y por los servicios que brinda la empresa. -Registrar niveles de ingreso al sistema por tipo de usuario. -Registrar pagos de pacientes.
47

LINKOGRAFA
http://www.mysql.com/products/workbench/ http://downloads.mysql.com/docs/workbench-en.pdf http://es.wikipedia.org/wiki/MySQL_Workbench http://www.ehowenespanol.com/desventajas-base-datos-relacional-lista_183865/ http://www.monografias.com/trabajos34/base-de-datos/base-de-datos.shtml http://www.maestrosdelweb.com/editorial/%C2%BFque-son-las-bases-de-datos/ http://es.kioskea.net/contents/66-introduccion-bases-de-datos http://www.jorgesanchez.net/bd/bdrelacional.pdf http://www.uazuay.edu.ec/analisis/El%20modelo%20relacional.pdf http://www.buenastareas.com/ensayos/Principales-Base-De-Datos-Relacionales/4683239.html http://yulipane.blogspot.com/2010/09/elementos-de-una-base-de-datos.html http://www.buenastareas.com/ensayos/Elementos-De-Una-Base-De-Datos/1835983.html http://elies.rediris.es/elies9/4-1-2.htm http://docs.moodle.org/all/es/Caracter%C3%ADsticas_de_la_base_de_datos_%28m%C3%B3dulo %29 http://www.ite.educacion.es/formacion/materiales/93/cd/m1_1/componentes_esenciales_de_un a_base_de_datos.html http://es.scribd.com/doc/2970454/6/Ejemplo-de-base-de-datos-relacional
48

BaseDatos-UNTR-Sistemas-DefinicionCaracteristicas

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

BaseDatos-UNTR-Sistemas-DefinicionCaracteristicas

Diunggah oleh

Hak Cipta:

Format Tersedia

Universidad Nacional de Trujillo

Facultad de Ingeniera Ingeniera de Sistemas

Universidad Nacional de Trujillo

Ejemplo: una biblioteca

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Es posible acceder a la informacin contenida en dos o ms tablas simultneamente.

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

MODEDO ENTIDAD RELACION:

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

consideremos la relacin alumno cursa materia cuyo diagrama E-R es el siguiente:

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Propiedades de las columnas

VARCHAR (45) NN Fecha (AAAA-MM-DD) Ninguno

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Universidad Nacional de Trujillo

Anda mungkin juga menyukai