Daniel Correa Botero José López Vélez Universidad de Antioquia 2013-II

Presentación del tema: "Daniel Correa Botero José López Vélez Universidad de Antioquia 2013-II"— Transcripción de la presentación:

1 Daniel Correa Botero José López Vélez Universidad de Antioquia 2013-II
Modelo Relacional Daniel Correa Botero José López Vélez Universidad de Antioquia 2013-II

2 Modelo Relacional Este modelo organiza y representa los datos en forma de tablas o relaciones. Elementos básicos: Tabla – Relación Fila – Registro – Tupla Columna – Campo - Atributo

3 Elementos Básicos – Tabla Persona
Tabla - Relación Persona Columna - Campo Atributo Fila – Registro - Tupla

4 Clave primaria Una relación siempre tiene una clave primaria.
Una clave primaria es un conjunto de atributos que permiten identificar unívocamente a las tuplas de una relación. Una clave primaria puede estar compuesta por 1 o múltiples atributos. Los atributos de una clave primaria no pueden ser nulos. Persona nn = not null

5 Clave foranea Son claves que son primarias en una relación y aparecen como atributos en otra relación. Se les llama claves foráneas solo para las relaciones en las cuales aparecen como atributos. Las claves foraneas se pueden declarar como requeridas o nulas. Persona Grupo de Investigacion

6 Notas Una clave foranea puede estar representada por 1 o múltiples atributos. Cliente Cotizacion

7 Notas Una clave foranea puede representar una clave primaria de la misma tabla donde se encuentra. Persona

8 Notas Una clave foranea puede hacer parte de una clave primaria. Curso
Persona Matricula

9 Conversión Modelo ER a Modelo relacional
1 a 1: la clave foranea puede ir en cualquiera de las 2 tablas. 1 a muchos: la clave foranea debe ir en la tabla muchos. Muchos a muchos: se crea una nueva tabla intermedia y las claves foraneas se introducen en esta tabla intermedia. Por lo general la clave primaria de la tabla intermedia es la combinación de las claves foraneas.

10 Relaciones de herencia
¿Que hacer con la herencia? Opción 1: crear tantas tablas como entidades. Opción 2: crear una sola tabla y un atributo adicional tipo. Opción 3: crear una sola tabla y otra tabla adicional “rol” que permita manejar múltiples roles.

11 Representar Modelo relacional

12 CASO 1: Nuestra empresa se basa en vender productos a distribuidores autorizados, y son los distribuidores quienes se encargan de vender los productos al cliente final. El sistema debe contar con administradores a los cuales solo se le almacenará el nombre de usuario y contraseña. Un administrador puede o no registrar muchos distribuidores autorizados y un distribuidor autorizado debe ser registrado por un solo administrador. Necesitamos guardar el nombre, dirección, teléfono y de cada uno de los distribuidores autorizados. Los distribuidores autorizados también se deberán conectar en el sistema. Allí cada distribuidor puede o no registrar los clientes que tiene a cargo. De esta manera podremos saber quiénes son los distribuidores con más clientes y al mismo tiempo tener almacenada toda la información importante de los clientes como: NIT, nombre, teléfono y celular. Finalmente requerimos un sistema de cotizaciones. Un distribuidor ingresa al sistema, luego entra al menú cotizaciones, allí selecciona un cliente, a continuación ingresa un titulo y un campo grande de texto donde ingresa la descripción de la cotización. Cuando finalice y de clic en Registrar cotización, el sistema deberá transformar la cotización a pdf y enviarla a otro sistema.

13 Caso 2: Administración de fincas
La empresa Farmers LTDA lo contrata para desarrollar un software para administrar la información de todos los socios y las propiedades a cargo de los socios. Luego de la entrevista con los interesados se presenta a continuación el texto resultante: Necesitamos almacenar la información de los socios, se considera a un socio aquella persona que por lo menos cuenta con una finca registrada en nuestra empresa. Para los socios nos gustaría contar con información tal como: nombres, apellidos, dirección, teléfono y celular. Otro ítem importante es que normalmente los socios nuevos llegan por UN referido (un socio antiguo), también nos gustaría poder saber quien fue el socio que los refirió. De igual manera la información de las fincas es muy valiosa. Queremos almacenar datos como: nombre de la finca, ubicación, teléfono, cantidad de animales y una imagen. Como dijimos anteriormente un socio debe ser dueño de por lo menos una finca. Pero vale la pena resaltar que cuando un socio no está disponible deja a otro socio como encargado o “segundo” dueño de la finca, es importante que el sistema nos entregue esa información (que toda finca tenga su dueño y su “segundo” dueño). Finalmente queremos que todos los socios puedan almacenar sus fechas de “no disponibilidad”, ingresando datos como: nombre del evento, fecha inicio y fecha fin.

14 Bibliografia C.J. Date: “Introducción a los sistemas de bases de datos”. Prentice Hall, 2001 [7a edicion]. ISBN Ramez A. Elmasri & Shamkant B. Navathe: “Fundamentos de Sistemas de Bases de Datos”. Addison-Wesley, [5a edicion]. ISBN Thomas M. Connolly & Carolyn E. Begg: “Sistemas de Bases de Datos” Addison-Wesley, 2005 [4a edicion]. ISBN Henry F. Korth, Abraham Silberschatz & S. Sudarshan: “Fundamentos de Bases de Datos”. McGraw-Hill, 2006 [5a edicion]. ISBN