Estructuras y Bases de Datos

Sistemas administradores de bases de datos

�Qu� es un DBMS? Data Base Management System

Es un software cuyo objetivo principal es proveer mayor control sobre la informaci�n. Subsana las deficiencias, limitantes y carencias del uso de archivos tradicionales. En un ambiente tradicional los programas interact�an directamente sobre los archivos de datos a trav�s del sistema operativo. En un ambiente con DBMS los programas interact�an con �l y este a su vez con los archivos de datos a trav�s del sistema operativo.

Niveles de un DBMS

Interno

Representaci�n de bajo nivel de toda la informaci�n de la base de datos. Registros internos, m�todos de almacenamiento y de acceso a la informaci�n.

Conceptual

Esquema l�gico de la base de datos (definici�n). Se aplican restricciones de seguridad e integridad.

Usuario

Vistas l�gicas que el usuario percibe como informaci�n. El usuario puede ser un usuario final o un programador (el DBA (database administrator) es aparte).

Objetivos de un DBMS

Integridad

Estar seguros de que la informaci�n dentro de la base de datos esta correcta de acuerdo a ciertos par�metros de validaci�n.

L�gica
Bit�cora de control, unicidad de la transacci�n, mantiene la consistencia. Ejemplo:

BEGIN transaction
	Movimiento de retiro
	Actualiza retiro en C23
	Moviemiento de dep�sito
	Actualiza dep�sito en C24
END transaction
Si alg�n movimiento dentro de la transacci�n falla, los otros son cancelados.

Referencial
Que el campo de una tabla (llave externa) nunca haga referencia a un rengl�n de otra tabla (llave interna) que no exista.

Entidad
Nunca tener dos registros dentro de la misma tabla que sean id�nticos, esto produce confusi�n en el proceso de selecci�n.

Usuario
Conjunto de reglas que regulan el medio ambiente donde se desenvolver� el sistema (business rules). Pueden incluir procedimientos y pol�ticas de seguridad.

Dominio
Poder controlar (restringir) los valores posibles (a un dominio) para un campo determinado de una relaci�n (tabla).

Seguridad

Facilidades que provee la base de datos para controlar el acceso y la utilizaci�n de la informaci�n.

Del sistema operativo
Sistemas de seguridad que son parte de la arquitectura del sistema operativo sobre el cual funciona el DBMS: OS/2, VMS, DOS, UNIX, VM, MVS, etc. Dan protecci�n de archivos y directorios as� como controlan cuentas y usuarios.

Acceso a la informaci�n
Estructuras de datos que sirven para facilitarle al usuario s�lo la informaci�n que requiere. Pueden ser vistas l�gicas, tablas derivadas, subesquemas, esquemas del DBMS, columnas, tablas e incluso bases de datos completas.

Ejecuci�n de comandos
Esquema que nos sirve para controlar los comandos que puede ejecutar el usuario sobre la informaci�n. Se regulan los comandos de SQL como Select, Insert, Update, Delete y Execute con directivas GRANT y REVOKE.

Independencia

Es la facilidad de modificar ciertas estructuras o criterios definidos en la base de datos sin repercusiones para los programas. Existen la independencia l�gica, la f�sica, la de integridad y la de distribuci�n.

M�dulos o sistemas donde opera el DBMS

Estructuras CDD

Diccionario de datos comunes, almacena informaci�n centralizada, ah� reside la definici�n de la base de datos.

Funciones de lenguaje

Definici�n DDL
Lenguaje de definici�n de datos, maneja las estructuras de la base de datos.

Manipulaci�n DML
Lenguaje de manipulaci�n de datos, realiza la explotaci�n, actualizaci�n, borrado e inserci�n de datos en la base de datos.

Control DCL
Maneja las transacciones, los usuarios y los privilegios.

Programaci�n
Interfaz para interactuar con lenguajes de programaci�n externos al DBMS.

Operaci�n y administraci�n

Administraci�n
Definici�n de cuestiones asociadas con las estructuras a nivel conceptual e interno de la base de datos.

Operaci�n
Mantenimiento del medio ambiente �ptimo para el funcionamiento del manejador de base de datos.

Archivo Log

Es un archivo donde se guardan las instrucciones que conforman una transacci�n l�gica mientras se completa. Esto con el objetivo de preservar la integridad.

Precompilador

Parte integral del DBMS que se encarga de traducir los comandos del lenguaje espec�fico del DBMS a instrucciones del lenguaje de programaci�n donde se intercalan dichos comandos.

Esquema general de un DBMS

El usuario (final, programador u operador, recordar que el DBA es un caso particular), interact�a con los m�dulos DML (manipulaci�n de datos) y DDL (definici�n de datos). Los m�dulos DML y DDL interact�an con el precompilador. El precompilador interact�a con el CDD (diccionario de datos) y con programas externos. Los programas externos interact�an con el DBMS y el sistema operativo. Por �ltimo el DBMS interact�a con el CDD, con el archivo log y con la base de datos.

Los componentes de un DBMS pueden variar dependiendo del modelo (jer�rquico, redes o relacional) y del producto.

Modelos de bases de datos

Modelo jer�rquico, red y relacional

Caracter�sticas, usos y mantenimiento

El modelo relacional de bases de datos

Se basa en el concepto l�gico que nos indica que la informaci�n de un manejador de base de datos debe presentarsele al usuario en forma de tablas.

Cronolog�a

1970 Codd define el modelo R
1974 IBM inicia el system R
1974 Primer art�culo de SEQUEL
1977 SEQUEL2 (SQL)
1978 Primeras pruebas de R
1979 Liberaci�n de Oracle
1981 Liberaci�n de Ingres
1981 IBM anuncia SQL/DS
1982 ANSI forma X3HZ
1983 IBM anuncia DB2
1986 Se ratifica el SQL de ANSI
1986 Sybase introduce OLTP
1987 IBM define SAA/SQL
1987 X/Open (ISO) ratifica el SQL86
1987 IBM saca SAA, DB2, SQL/400 SQL/DS y EE DBM para OS/2
1988 SQL est�ndar de FIPS
1988 Microsoft anuncia su SQL
1990 ANSI/SQL2

�reas principales

Un DBMS relacional debe dar un nivel de soporte de ciertos conceptos relacionales criticos que son: Estructura tabular, operadores tradicionales, operadores especiales, reglas de integridad y l�gica de dominios. Se dividen en:

Estructuras de datos
Dominios relacionales: Relaci�n o tabla, atributo o columna, tupla o entidad o rengl�n, llave primaria y llave externa. Las llaves pueden ser simples (un solo atributo) o compuestas (2 o m�s atributos). Existen adem�s las tablas bases (parte de la estructura de la base de datos) y las tablas derivadas (vistas) que se crean a partir de tablas base.

Integridad
De la entidad
No se deben manejar valores nulos ni repetidos en la llave primaria.

Referencial
No se debe referenciar algo que no existe dentro de la base de datos (llaves externas).

Manipulaci�n de datos
�lgebra relacional
Conjunto de operaciones para manipular informaci�n en un sistema relacional. Estos operadores deber�n ser parte del sublenguaje de datos (SQL) del producto. El �lgebra relacional se aplica sobre relaciones (tablas) y da como resultado relaciones (tablas).

Operadores Uni�n Es un operador tradicional, construye una relaci�n a partir de dos relaciones concatenando todas las tuplas posibles de estas (elimina duplicados), C:=A Uni�n B.

Intersecci�n Es un operador tradicional, construye una relaci�n a partir de todas las tuplas que aparecen en las dos relaciones de entrada, C:=A Intersecci�n B.

Diferencia Es un operador tradicional, construye una relaci�n a partir de las tuplas que aparecen en A y no en B, C:=A Diferencia B.

Producto Es un operador tradicional, la relaci�n resultante se compone de todas las combinaciones posibles de las columnas de ambas relaciones de entrada, C:=AB.

Select Selecciona tuplas de A de acuerdo a un criterio espec�fico (l�gico) y forma con ellas una nueva relaci�n.

Project Selecciona columnas (atributos) de la relaci�n A y forma con ellos una nueva relaci�n.

Join La relaci�n resultante C contiene todas las tuplas concatenadas de las dos relaciones de entrada (A y B) que satisfacen una cierta condici�n com�n.

		a1 b1	Join	b1 c1	=	a1 b1 c1
		a2 b2

Divide Toma dos relaciones, una binaria y otra unitaria, construye la relaci�n de salida a partir de: Todos los valores de un atributo de la relaci�n binaria cuyo otro atributo comprende todos los valores que se encuentran en la relaci�n unitaria.

		a x	Divide	x	=	a
		a y		z		b
		a z
		b x
		b y
		b z
No se deben confundir el Select como concepto algebr�ico de la instrucci�n de SQL Select.

Asignaci�n relacional
C�mo y d�nde se guardan los resultados del �lgebra relacional.

Contexto, Reglas de Codd
Sistema tabular, relacional m�nimo, relacional completo o relacional total

0.- Todo sistema relacional debe manejar sus bases de datos a trav�s de sus capacidades relacionales exclusivamente.

1.- Toda la informaci�n en una base de datos relacional se debe representar expl�citamente en el nivel l�gico en forma de tablas relacionales.

2.- Acceso garantizado: Todos y cada uno de los datos en una base de datos relacional deben poder accesarse a trav�s de la combinaci�n: Nombre de relaci�n (Tabla), llave primaria (Rengl�n) y nombre atributo (Columna).

3.- Valores nulos: Todo manejador relacional debe poder representar y manipular valores nulos, utilizando para su representaci�n un c�digo espec�fico.


	  V F N		  V F N
	V V F N		V V V V
	F F F F		F V F N
	N N F N AND	N V N N OR
4.- Cat�logo relacional: La informaci�n sobre la base de datos debe estar representada en tablas para que podamos utilizar el mismo lenguaje para su administraci�n.

5.- Sublenguaje de datos (SQL): Un manejador relacional debe soportar al menos un lenguaje, con una sint�xis formalmente definida, a trav�s del cual podemos: Definir datos, definir vistas l�gicas, manipular datos, controlar la integridad, controlar seguridad y realizar transacciones l�gicas.

6.- Actualizaci�n de vistas: Un DBMS relacional debe tener un algoritmo al menos tan poderoso como el VU-1 para determinar si la vista l�gica en cuesti�n es sujeta a inserciones o borrados de tuplas y si se pueden modificar columnas.

7.- Operaciones masivas: La capacidad del manejador de manipular una relaci�n a trav�s de un solo operando debe aplicar no solo al Select si no tambi�n al Insert, Delete y al Update.

8.- Independencia f�sica: Los programas de aplicaci�n deben permanecer sin cambios cuando se modifiquen, ya sea las representaciones de almacenamiento, o los m�todos de acceso a la informaci�n (modelo f�sico).

9.- Independencia l�gica: Los programas de aplicaci�n deben permanecer sin cambios cuando se lleven a cabo modificaciones para preservar la informaci�n (modelo l�gico).

10.- Independencia de integridad: Las reglas de integridad deben poder definirse en el lenguaje de datos y almacenarse en el cat�logo del sistema relacional.

11.- Independencia de distribuci�n: Los programas de aplicaci�n no deben sufrir modificaciones cuando la informaci�n se distribuye en lugares f�sicamente diferentes. Esto debe ser transparente para el usuario.

12.- No subversi�n: Ninguna aplicaci�n podr� accesar directamente la informaci�n en la base de datos por cuestiones de integridad. Toda aplicaci�n deber� pasar a trav�s de los controles de seguridad e integridad del DBMS.

Lo importante de un DBMS no es que sea relacional, si no que cumpla con las caracter�sticas de integridad, independencia y seguridad. Hay que evaluar no solo que el producto cumpla con las reglas de Codd, si no tambi�n que tan eficientemente las lleva a cabo.

Sublenguaje de datos (SQL, Structured Query Language)

Los paquetes, herramientas o programas que accesan al DBMS lo hacen mediantes instrucciones de SQL. En el SQL el usuario no indica d�nde est�n los datos, ni los manipula uno por uno, el SQL es un lenguaje no-procedural.

�Qu� es SQL?
Es una herramienta para organizar y explotar informaci�n almacenada en una base de datos del tipo relacional. Sus funciones son: Consultas interactivas (ISQL), programaci�n, administraci�n de la base de datos, lenguaje cliente/servidor, soporte a bases de datos distribuidas y servir como gateway a otras bases de datos. Cumple el papel de sublenguaje de datos en el modelo relacional.

El SQL es la forma de comunicaci�n con el motor de base de datos. El SQL es usado para manejar formas, generar reportes, programar aplicaciones, comunicar con otros equipos, bases de datos y otros manejadores.

Valores nulos
Debe existir una forma expl�cita de representar la ausencia de informaci�n en cualquier campo de la base de datos: NI (Nulo Inaplicable) y NA (Nulo Aplicable).

Tipos de SQL
Est�tico, que va al pre-compilador del DBMS y se define al crear la aplicaci�n. Lo usan los paquetes de aplicaci�n y los programas.

Din�mico, que va al optimizador del DBMS y se define al ejecutar la aplicaci�n. Lo usan las herramientas de usuario.

El optimizador es parte integral del DBMS, su labor es analizar los comandos SQL y decide la mejor opci�n para accesar la informaci�n en funci�n del cat�logo de sistema (diccionario de la base de datos), el pre-compilador tambi�n lo usa.

Cursores
Estructura a trav�s de la cual podemos accesar las tablas de una base de datos registro por registro, con SQL intercalado en un lenguaje de 3� generaci�n.

Subqueries
Es la posibilidad de anidar varios queries en un mismo bloque de ejecuci�n, es indispensable para tener un lenguaje estructurado.

Cliente/Servidor con SQL/DBMS
Front End: Interfaz de usuario (PC)

Front - Back : NetBios, IPX/SPX, Named Pipes
Back End: SQL/DBMS en el servidor

Front - MainFrame: TCP/IP, APPC, ISO/OSI
MainFrame: SQL/DBMS en el MainFrama

Comandos de SQL
Definici�n
A trav�s de estos comandos creamos la base de datos, modificamos alguna de sus caracter�sticas o la borramos:

Create

CREATE TABLA productos
	pro_clave CHAR(6),
	pro_descri CHAR(20),
	pro_precio MONEY,
	pro_invent INTEGER
Drop
DROP TABLE productos
Alter
ALTER TABLE productos ADD pro_ventas MONEY
Manipulaci�n
A trav�s de estos comandos consultamos, modificamos o borramos la informaci�n dentro de la base de datos:

Select

SELECT pro_descri
FROM productos
WHERE pro_clave = "100345"

SELECT *
FROM productos
Insert
INSERT INTO productos (pro_clave , pro_descri, pro_precio, pro_invent)
VALUES ("100345","Un producto m�s",100.00,123)
Update
UPDATE productos
SET pro_estado = "A"
WHERE pro_clave = "100345"
Delete
DELETE FROM productos
WHERE pro_clave = "100345"
Control (DCL)
Manejamos la seguridad y los privilegios relacionados con la base de datos.

Grant

GRANT UPDATE, SELECT ON productos TO usuaio01
Revoke
REVOKE ALL ON productos TO usuario02
Commit Rollback

An�lisis b�sico para bases de datos relacionales

Entidades

Personas, lugares, objetos, conceptos, actividades o eventos de inter�s para la empresa: EMPLOYEE, DEPARTAMENT, PROJECT.

Un tipo de entidad son un conjunto de cosas escritos en may�sculas (EMPLOYEE), un ejemplo de entidad es una cosa particular escrita en min�scula (John Smith).

Las entidades se convierten en tablas en el dise�o relacional.

E1 Buscar entidades en las entrevistas

Las entidades son sustantivos, pero no todos los sustantivos son entidades. Se deben ignorar sustantivos que denoten datos espec�ficos o que no sean importantes para la empresa.

No se debe confundir una forma con la informaci�n que documenta.

E2 �Qu� tipo de entidad?

Se ver� en el an�lisis avanzado.

E3 Determinar llave primaria

La llave primaria identifica y distingue a los miembros de las entidades: EMPLOYEE_NUMBER, DEPARTAMENT_CODE.

Caracter�sticas generales: �nica, conocida todo el tiempo.

Caracter�sticas deseables: Estable, controlada por el DBA, disponible para los usuarios, no describe informaci�n, corta, simple, evitar nombres.

E4 Decidir un nombre formal

Usar el singular del sustantivo (EMPLOYEE, DEPARTAMENT). Listar los nombres alternativos como sin�nimos en el diccionario de datos. Eliminar hom�nimos.

E5 Escribir una descripci�n

Significados y usos en oraciones completas, inclu�r ejemplos y contra ejemplos.

Relaciones

Una oraci�n acerca de dos entidades: EMPLOYEE MANAGE DEPARTAMENT, EMPLOYEE ASSIGN_TO PROJECT.

Un tipos de relaci�n se escribe en may�sculas: EMPLOYEE MANAGE DEPARTAMENT, un ejemplo de relaci�n es una oraci�n acerca de entidades en min�sculas: John Smith manage Administration.

Las relaciones se transforman en llaves for�neas en el dise�o relacional.

R1 Buscar relaciones en entrevistas

Las relaciones son verbos, pero no todos los verbos son relaciones. Se deben ignorar verbos que describen procesos en lugar de verbos o que no son seguidos por la empresa.

Buscar relaciones impl�citamente documentadas.

R2 �Qu� tipo de relaciones?

Se ver� en el an�lisis avanzado.

R3 Determinar la cardinalidad

M�xima

La cardinalidad de EMPLOYEE WORK_IN DEPARTAMENT es muchos-uno, �cu�ntos empleados pueden trabajar en un departamento? Muchos, �en cu�ntos departamentos puede un empleado trabajar? Al menos uno.

La cardinalidad de EMPLOYEE MANAGE DEPARTAMENT es uno-uno, �cu�ntos empleados pueden manejar un departamento? Al menos uno, �cu�ntos departamentos puede un empleado manejar? Al menos uno.

M�nima

La cardinalidad m�nima de EMPLOYEE MANAGE DEPARTAMENT es uno-cero, �cu�ntos empleados deben manejar un departamento? Al menos uno, �cu�ntos departamentos debe manejar un empleado? Cero.

La cardinalidad es una regla especial de integridad y refleja la pol�tica de la empresa.

R4 Decidir un nombre formal

Usar la voz activa cuando sea posible, listar los sin�nimos en el diccionario de datos y eliminar los hom�nimos. Los nombres de las relaciones incluyen nombres de entidades (o no cuando sean obvias).

EMPLOYEE ASSIGN_TO PROJECT, AGENT ASSIGN_TO CUSTOMER.

R5 Escribir una descripci�n

Usar oraciones completas, ejemplos y contra ejemplos.

Atributos

Una propiedad descriptiva de la entidad o de la relaci�n.

EMPLOYEE		EMPLOYEE-------------->PROJECT
EMPLOYEE_NUMBER			ASSIGN_TO
SALARY_MOUNT			START_DATE
EXTENSION_NUMBER		ROLE_NAME
Padre: Entidad o relaci�n que posee un atributo.

Tipo de atributo: Conjunto de valores (may�sculas).

Ejemplo de atributo: Valor individual (min�sculas).

Los atributos se transforman en columnas en el dise�o relacional.

A1 Buscar atributos en la entrevista

Los atributos son sustantivos que denotan datos espec�ficos. NAME, DATE, QUANTITY, MONETARY VALUE.

A2 �Qu� tipo de dato?

Los tipos de datos incluyen:

nombre: MONEY, LENGTH, QUANTITY
tipo f�sico: character, integer, float, binary
n�mero de caracteres o d�gitos
valores legales (COLOR IN [RED, GREEN, BLUE])
reglas de validaci�n (AGE>=21)
valor por omisi�n (default)

A3 Determinar la cardinalidad

Los atributos tienen cardinalidad m�nima y m�xima

La cardinalidad de EXTENSION_NUMBER es muchos=m�ximo a cero=m�nimo, �cu�ntas extensiones puede un empleado tener? Muchas, �cu�ntas extensiones debe un empleado tener? Cero.

Terminolog�a: Singular M�ximo uno, Optional M�nimo cero, Plural M�ximo muchos, Required M�nimo uno.

A4 Buscar un nombre formal

El nombre formal del atributo deber� tener el formato: PARENTAL_QUALIFIER_DATATYPE, ejemplos: EMPLOYEE_FIRTS_NAME, ASSIGN_START_DATE o CUSTOMER_BALANCE_AMOUNT.

El nombre de padre puede evitarse para claridad en el contexto. Pueden usarse cero, uno o varios calificadores. El DATATYPE se toma de la lista est�ndar. Se deben eliminar hom�nimos y documentar en el diccionario de datos los sin�nimos.

A5 Escribir una descripci�n

Usar frases completas, dar ejemplos y contra ejemplos. Especificar unidades (monetarias, distancia, tiempo, peso).

Diagrama entidad - relaci�n

		M(0)		    M(0)
EMPLOYEE	------------------------PROJECT
EMPLOYEE_NUMBER		ASSIGN_TO	PROJECT_NUMBER
SS_NUMBER		ROLE_NAME	DESCRIPTION
FULL_NAME				BUDGET_AMOUNT
SEX						|1(0)
EXTENSION_NUMBER				|
|1		|M(0)				|BELONG_TO
| MANAGE	| WORK_IN			|
|1(0)		|1				|M
DEPARTAMENT				TASK
DEPT_NUMBER				PROJECT_NUMBER
DEPT_NAME				TASK_NAME
BUILDING_NUMBER				START_DATE
					STATUS

An�lisis avanzado para bases de datos relacionales

Entidades

Las entidades dependientes no pueden existir sin su entidad padre. Las dependencias siempre tienen una relaci�n BELONG_TO con su entidad padre, usualmente muchos a uno.

PROJECT		-------------------------  TASK
PROJECT_NUMBER	1	BELONG_TO	M  PROJECT_NUMBER
					   TASK_NAME
La llave primaria de las dependencias incluyen la llave padre y una columna descriptiva.

Subentidades

La subentidad es un subconjunto de otra entidad, llamada superentidad. Crear subentidades para subconjuntos importantes de una entidad, que tienen atributos especiales.

Entidad: EMPLOYEE, ejemplos AGENT, CLERK, SALARIED_EMPLOYEE, HOURLY_EMPLOYEE
Subentidad: PROGRAMMER, ejemplos APPLICATION_PROGRAMMER, SYSTEMS_PROGRAMMER

Herencia

La llave primaria, los atributos y las relaciones de la superentidad se aplican a todas sus subentidades y no viceversa.

EMPLOYEE			AGENT			SALARIED_EMPLOYEE
EMPLOYEE_NUMBER			COMMISION_AMOUNT
SS_NUMBER			TERRITORY_NAME		HOURLY_EMPLOYEE
FULL_NAME						OVERTIME_RATE
SEX				CLERK
EXTENSION_NUMBER		TYPING_SPEED		PROGRAMMER	APPL_PROGRAMMER
							LANGUAGE
							LEVEL_CODE	SYS_PROGRAMMER
									MACHINE_NAME

La relaci�n ISA (is a, es un)

Existe siempre una relaci�n ISA entre una subentidad y una superentidad. La cardinalidad es siempre m�ximo: 1-1 y m�nimo: 1-0 (super-sub).

		EMPLOYEE----------------PROGRAMMER
			1    ISA    1(0)
No se documentar� la relaci�n ISA en el diccionario de datos o en el diagrama, siempre es asumida.

E2 �Qu� clase de entidad?

Si no puede existir sin su padre, es dependiente y se debe documentar como BELONG_TO. Los subconjuntos importantes de una entidad con atributos especiales son subentidades, documentar la superentidad pero no la relaci�n ISA.

E3 Determinar la llave primaria

La llave primaria de la dependencia incluye la llave de la entidad padre y una columna descriptiva. La llave primaria de la subentidad es heredada de la superentidad.

E7 Crear superentidades alrededor de entidades similares

Las entidades similares tienen muchos atributos en com�n. Asigna los atributos comunes a la superentidad, y los especiales a las subentidades.

Considera el uso de llaves primarias artificiales para nuevas superentidades.

EMPLOYEE	CUSTOMER		PERSON			EMPLOYEE
FULL_NAME	FULL_NAME		PERSON_ID		SALARY_AMOUNT
ADDRESS		ADDRESS			FULL_NAME		JOBCODE
BIRTH_DATE	BIRTH_DATE		ADDRESS
SALARY_AMOUNT	ACCOUNT_NUMBER		BIRTH_DATE		STOCKHOLDER
JOBCODE				--->
								CUSTOMER
STOCKHOLDER							ACCOUNT_NUMBER
FULL_NAME
ADDRESS

E8 Determina clases y clasifica atributos

EMPLOYEE		JOBCODE		WAGE_STATUS
EMPLOYEE_NUMBER
SS_NUMBER		AGENT		SALARIED_EMPLOYEE
FULL_NAME
			CLERK		HOURLY_EMPLOYEE

			PROGRAMMER SKILL_TYPE

			APPLICATIONS_PROGRAMMER
			SYSTEM_PROGRAMMER
Clase: Grupo de subentidades mutuamente excluyentes, alineadas verticalmente. Cada clase corresponde a la clasificaci�n del atributo de la superentidad. Una superentidad puede tener muchas clases sin relacionarse.

Relaciones

Las relaciones N-way (n caminos) inmiscuyen m�s de dos entidades
		ROLE--IN--EMPLOYEE--ASSIGN_TO--PROJECT
Buscar oraciones con frases prepositivas que contienen una entidad.

Una three-way no es lo mismo que tres two-way:

			EMPLOYEE	ROLE		PROJECT
			smith		flunky		training
			smith		manager		sales
			jones		flunky		sales

EMPLOYEE	ROLE		EMPLOYEE	PROJECT		ROLE		PROJECT
smith		flunky		smith		training	flunky		traininig
smith		manager		smith		sales		manager		sales
jones		flunky		jones		sales		flunky		sales

			EMPLOYEE	ROLE		PROJECT
			smith		flunky		training
			smith		manager		sales
			jones		flunky		sales
			smith		flunky		sales

Relaciones recursivas

La relaci�n recursiva es una frase acerca de una entidad: EMPLOYEE SUPERVISE EMPLOYEE.

Documentar los roles de la primera y la segunda entidad en la descripci�n, ejemplo: SUPERVISOR, SUBORDINATE.

R2 �Qu� tipo de relaci�n?

Las frases con una oraci�n proposicional conteniendo una entidad son relaciones tres-caminos. No confundir las tres-caminos con dos de dos-caminos. Se deben documentar los roles en la relaci�n recursiva.

R7 Eliminar las relaciones indirectas

Una relaci�n indirecta es redundante a otras dos relaciones. Usualmente se excluyen las relaciones indirectas del diccionario.

		EMPLOYEE---------DEPARTAMENT---------DIVISION
		    |	 WORK_IN	    BELONG_TO   |
		    |					|
		    --------------ASSIGN_TO--------------

�Relaciones o atributos?

Cuando un atributo iguala la llave primaria de una entidad, es en realidad una relaci�n.

				EMPLOYEE
				DEPARTAMENT_CODE
				      |
			EMPLOYEE----WORK_IN------DEPARTAMENT
				      |
				DEPARTAMENT
				EMPLOYEE_NUMBER

�Relaciones o entidades?

Los verbos pueden substituirse por sustantivos y viceversa. Si la llave primaria coincide con la llave primaria de otras entidades, es una relaci�n.

	EMPLOYEE--------PROJECT		EMPLOYEE	PROJECT
	  |	ASSIGN_TO		    |---ASSIGMENT---|
	  |IN			----->		    |
	ROLE					   ROLE

R8 No confundir relaciones con entidades o atributos

Los atributos que designan entidades son relaciones. Si la llave primaria de una entidad coincide con otras llaves primarias, podr�a ser una relaci�n.

Atributos

Usualmente la relaci�n padre es intuitivamente obvia, si no se est� seguro se deber� buscar:

- Posesivo: El salario del empleaado.
- Verbo poseer: Los empleados tienen< c�digos de trabajo.

- Preposici�n: El salario de el eempleado.

A1 Buscar atributos en la entrevista

Verificar la entidad padre o la relaci�n. Buscar una preposici�n, un verbo de posesi�n o una voz posesiva.

A7 Reasignar los atributos indirectos

Un atributo indirecto no es en realidad una propiedad de su padre:

EMPLOYEE		--->	EMPLOYEE----------------DEPARTAMENT
BUILDING_NUMBER				     WORK_IN	BUILDING_NUMBER
Un atributo indirecto es un caso especial de relaci�n indirecta.

A8 Documentar la f�rmula derivada (si la hay)

Un atributo derivable es calculado en base a otros atributos.
	COMPENSATION_AMOUNT = HOURLY_WAGE_AMOUNT * 2000 + BONUS_AMOUNT
Un atributo primitivo debe ser entrado directamente.
Documentar la f�rmula si el atributo es importante o la derivaci�n es obscura.
Considerar la eliminaci�n de atributos derivables.

A9 Convertir los atributos opcionales en subentidades

Los atributos opcionales tienen una cardinalidad m�nima de cero.

	EMPLOYEE		EMPLOYEE
	FULL_NAME		FULLNAME
	ADDRESS			ADDRESS
	SALARY_AMOUNT	---->	SALARY_AMOUNT
	COMMISSION (o)
	TERRITORY (o)		AGENT
				COMMISSION
				TERRITORY
Los atributos son opcionales cuando su valor es a veces desconocido o inaplicable.

E6 R6 A6 Documentar estados pasados o futuros

Muchas entidades, relaciones y atributos se refieren a la situaci�n actual, si estados pasados o futuros se necesitan entonces agregar:

Para entidades o relaciones a�adir DATE o DATETIME como atributo para estados puntuales o continuos y START_DATE y END_DATE para estados segmentados.

Los atributos se deben hacer compuestos (SALARY_AMOUNT, EFFECTIVE_DATE).

Se deben documentar los estados pasados y futuros en la descripci�n.

Dise�o relacional b�sico

					  M(0) M(0)
EMPLOYEE			JOBCODE   --------- PROJECT
EMPLOYEE_NUMBER				  ASSIGN_TO PROJECT_NAME
SS_NUMBER			AGENT	  ROLE_NAME DESCRIPTION
FULL_NAME			TERRITORY	    BUDGET_AMOUNT
SEX				COMMISSION		| 1(0)
EXTENSION_NUMBER (m)					| BELONG_TO
				CLERK			| M
						    TASK
				PROGRAMMER	    PROJECT_NAME
				LANGUAGE	    TASK_NAME
				LEVEL		    START_DATE
				   1(0)		    STATUS
  |1		|M(0)	    1(0) | ---|
  |MANAGE	|WORK_IN	 |    |MARRY
  |1(0)		|1		 ------
DEPARTAMENT
DEPT_NUMBER
DEPT_NAME
BUILDING_NUMBER

Dise�o l�gico

En el dise�o b�sico relacional, cada entidad se transforma en una tabla. Las tablas son mezcladas o combinadas para mejorar el desempe�o en el dise�o relacional avanzado.

T1 Las entidades independientes se transforman en tablas independientes
	PROJECT
	PROJECT_NAME	DESCRIPTION	BUDGET_AMOUNT
	    P1		xyz Database	19000
	    P2		gizmo test	48000
	    P3		widget sales	4000
La llave primaria no contiene llaves for�neas.

T2 las entidades dependientes se transforman en tablas dependientes
	TASK
	PROJECT_NAME	TASK_NAME	START_DATE	STATUS
	    P1		Requirements	10/29/85	complete
	    P1		Logical design	03/24/87	active
	    P1		Physical design	03/29/87	proposed
	    P3		Sales report	null		proposed
La llave for�nea hace referencia a la tabla padre, es una relaci�n BELONG_TO. La llave primaria contiene esta llave for�nea y otras columnas adicionales. En la llave for�nea no se permiten nulos ni defaults. El borrado de datos usualmente se hace en cascada, o se restringe del todo.

T3 Las subentidades se transforman en subtablas
	PROGRAMMER
	EMPLOYEE_NUMBER	LANGUAGE	LEVEL
	e1		PL/1		beginner
	e5		Fortran		intermediate
	e6		Cobol		advanced
La llave for�nea hace referencia a la tabla padre, es una relaci�n ISA. La llave primaria es exactamente igual a la llave for�nea. En la llave for�nea no se permiten nulos ni defaults. El borrado de datos usualmente se hace en cascada, o se restringe del todo.

La clasificaci�n de las columnas en la supertabla es recomendada si se desean eliminar las b�squedas en la subtabla y evitar la redundancia de los datos en la subtabla:

	EMPLOYEE
	EMPLOYEE_NUMBER	...	JOBCODE	DEPT# LANGUAGE	LEVEL	TERRITORY
		e1		program	d3	Pl/1	begin	null
		e2		agent	d2	null	null	Texas
		e3		agent	d2	null	null	Bulgaria
		e4		clerk	d1	null	null	null
		e5		program	d2	Fortran	interm	null
		e6		program	d3	Cobol	advanc	null
Las relaciones se transforman en llaves for�neas
El nombre de la llave for�nea ser� el mismo del de la llave primaria, solo se agregar� un calificador si se necesita. Se deben usar nombres con significado (MANAGER, SPOUSE):

	EMPLOYEE       ---|MARRY		PROJECT
	EMPLOYEE_NUMBER---|			PROJECT_NUMBER
	|	|					|
	|MANAGE |WORK_IN				| BELONG_TO
	|	|					|
	DEPARTAMENT				TASK
	DEPARTAMENT_NUMBER			PROJECT_NUMBER
						TASK_NAME
Relaciones muchos-uno
		EMPLOYEE-----------DEPARTAMENT
			M WORK_IN 1

Dise�o err�neo:

	DEPARTAMENT
	DEPT_NUMBER	DEPT_NAME	BUILDING	MANAGER	STAFF
		d1	Finance		139		e4	e4
		d2	Marketing	200		e3	e2, e3, e5
		d3	research	360		e6	e1, e5
		d4	legal		145		null	null
R1 Muchos-uno, poner la llave for�nea en la tabla "muchos"
La llave primaria debe ser singular porque las tablas son normalizadas.

	EMPLOYEE
	EMPL_NUMBER	NAME		SEX	SPOUSE JOBCODE	DEPT_NUMBER
	e1		Ronald Reagan	male	e2	program	d3
	e2		Nancy Reagan	female	e1	agent	d2
	e3		Dick Butkus	male	null	agent	d2
	e4		Humphrey Bugart	male	e5	clerk	d1
	e5		Lauren Bacall	female	e4	program	d2
	e6		Maggie Thatcher	female	null	program	d3
R2 Uno-uno, poner la llave for�nea en la tabla con menos renglones
Esto reduce o elimina los valores nulos.

		[DEPARTAMENT]	MANAGE	[EMPLOYEE]
		   pocos		  muchos
		Aqu� va la llave
R3 Muchos-muchos, transformarlas en tablas asociativas
	EMPLOYEE	1	M	     M		1 PROJECT
	EMPLOYEE_NUMBER --------- ASSIGNT_TO ------------ PROJECT_NUMBER
				  EMPLOYEE_NUMBER
				  PROJECT_NUMBER
				  ROLE_NAME

	ASSIGN_TO
	EMPLOYEE_NUMBER	PROJECT_NUMBER	ROLE_NAME
	e1		p1		Supervisor
	e1		p3		Scientist
	e3		p2		null
	e5		p3		Flunky
Dos llaves for�neas sobre la misma tabla se refieren a dos tablas relacionadas. La llave primaria est� compuesta de las llaves for�neas, podr�a contener columnas adicionales. No se permiten nulos ni defaults en la llave for�nea, el borrado es en cascada o no se restringe del todo.

R4 la relaci�n tres-caminos se transforma en tabla asociativa
Como en la relaci�n muchos-muchos la llave primaria contiene tres o m�s llaves for�neas.

		[EMPLOYEE] ASSIGN_TO [PROJECT]
			     IN
			   [ROLE]

	ROLE
	ROLE_NUMBER	ROLE_NAME	RATE
	r1		supervisor	60.00
	r2		scientist	25.50
	r3		flunky		9.95

	ASSIGN_TO
	EMPL_NUMBER	PROJ_NUMBER	ROLE_NUMBER
	e1		p1		r1
	e1		p3		r2
	e3		p2		r1
	e5		p3		r3
Los atributos se transforman en columnas
Los atributos singulares se transforman en una columna.

Los tipos de datos compuestos se transforman en diversas columnas, esto depende del soporte del DBMS.

EMPLOYEE
EMPLOYEE_NUMBER
SS_NUMBER
NAME
SEX		    1
JOBCODE		    ----
EXTENSION_NUMBER (m)   |MARRY
	|M	  |-----
	|WORK_IN   1
	|1
DEPARTMENT

Dise�o simple pero imposible porque las tablas se normalizan:

EMPLOYEE_NUMBER		NAME		DEPT_#	EXTENSION
	e1		Ronald Reagan	d3	1000,1111,1112

Ni siquiera se piense:

EMPLOYEE_NUMBER         NAME            DEPT_#  EXTENSION
        e1              Ronald Reagan   d3      1000
        e1              Ronald Reagan   d3      1111
        e1              Ronald Reagan   d3      1112

Esto es lo que usualmente se hace, error com�n:

EMPLOYEE_NUMBER         NAME            DEPT_#  EXT_1	EXT_2	EXT_3
        e1              Ronald Reagan   d3      1000	1111	1112
C1 los atributos plurales se transforman en tablas dependientes
La llave for�nea se refiere a la tabla padre. La llave primaria contiene la llave for�nea y el atributo plural. La llave for�nea no debe contener nulos ni defaults, el borrado se hace en cascada o se restringe.

EMPLOYEE	------- TELEPHONE
EMPLOYEE_NUMBER 	EMPLOYEE_NUMBER
SS_NUMBER		EXTENSION_NUMBER
NAME
SEX
JOBCODE

	TELEPHONE
	EMPLOYE_NUMBER	EXTENSION_NUMBER
	e1		1000
	e1		1111
	e1		1112
C2 Especificar no-nulo para los atributos y las relaciones requeridas
Un atributo es requerido si en el an�lisis se encuentra con una cardinalidad m�nima de 1, en el dise�o esto se especifica como un atributo no-nulo.

Se debe especificar no-nulo cuando sea un atributo requerido, cuando se trate de la llave for�nea que representa una relaci�n requerida y en todos los atributos de la llave primaria.

No se deben permitir defaults con significado desconocido o inaplicable.

C3 forzar los atributos �nicos con �ndices
Los �ndices podr�an hacer m�s lentas las inserciones, se debe evaluar si el beneficio justifica el costo. Siempre se deben crear indices �nicos en las columnas de la llave primaria.

CREATE UNIQUE INDEX SS# ON EMPLOYEE (SS#)

C4 los atributos de las relaciones van con la llave for�nea
Para las relaciones uno-uno y muchos-uno se debe poner el atributo en la tabla que contiene la llave for�nea. En las relaciones muchos-muchos y tres-caminos los atributos van en su propia tabla asociativa.

	[EMPLOYEE]-------------[DEPARTAMENT]
		  M MANAGE 1(0)
		    START_DATE

DEPARTAMENT
DEPT_#		DEPT_NAME	BUILDING_#	MANAGER	START_DATE
d1		Finance		139		e4	10/29/89

Normalizaci�n

Redundancia
La redundancia de un valor es la repetici�n de un hecho dentro de la base de datos relacional. La redundancia es de hechos o de valores. Trae como consecuencias: Inconsistencia de datos, anomal�as en la actualizaci�n e incertidumbre en el procedimiento de mantenimiento de la base de datos.

Forma normal
La forma normal (FN) es una estructura de tablas que reduce la redundancia. La forma normal logra, por descomposici�n y sin p�rdidas, dividir una tabla en tablas m�s peque�as.

Primera forma normal
Cada celda de una tabla contiene solamente un valor.

Segunda forma normal
Se debe eliminar la dependencia parcial descomponiendo sin p�rdida la tabla. Cada columna no-llave (todo el rengl�n) debe depender enteramente de la llave primaria.

Tercera forma normal
Se debe eliminar la dependencia indirecta por descomposici�n sin p�rdida. Cada columna no-llave (solo la columna) depende directamente de la llave primaria.

Dise�o relacional avanzado

Llaves artificiales

Llaves primarias no significativas introducidas por el administrador de la base de datos. Algunas veces son nulos las llaves naturales, por eso se crean las artificiales.

Las llaves naturales son f�cilmente accesadas por el usuario final. Las artificiales solo tienen prop�sitos administrativos.

Se debe considerar hacer una llave artificial cuando existen muchas llaves for�neas, cuando la llave natural pueda ser nula o no �nica o inestable o compleja.

Problema de la forma L (L-shaped data)

Ventajas de tener una supertabla:

Se tienen pocos Joins (uniones) entre tablas
Se tienen pocas llaves for�neas
Se tienen pocas tablas

Ventajas de tener subtablas:

Se tienen pocos nulos aplicables
Se ocupa menor espacio f�sico
Se tiene mayor estabilidad y flexibilidad

Lo mejor es hacer lo posible por tener subtablas simpre y cuando el costo de los joins sea aceptable, o para evitar tener nulos inaplicables, se deber�an unir las tablas con cardinalidad uno-uno.

Vectores

Un vector es un atributo plural donde el n�mero de valores es "siempre" el mismo.

Rengl�n
	a�o	fresh	soph	junior	senior	grad
	1981	143	102	205	257	50

Columna
	a�o	class	num_alumnos
	1981	fresh	143
	1981	soph	102
El dise�o en rengl�n tiene como ventajas la menor cantidad de datos almacenados y el hecho de tener pocas tablas.

El dise�o en columnas es f�cil de mantener y es mas flexible.

Columna:			Rengl�n:

Select AVG(num_alumnos)		Select (fresh + soph + ...)/5
From Tabla_columna		From Tabla_renglon
Where a�o=1981			Where a�o=1981
Debemos implantar vectores de columna a menos que el tama�o f�sico, el acceso a los usuarios, o el n�mero de tablas nos oblige a usar el dise�o de rengl�n.

Atributos codificados

Son "c�digos" obscuros que deben ser bien documentados y conocidos por los usuarios y los programadores:

N�mero de empleado non = Empleado asalariado
N�mero de empleado par = Empleado por honorarios
No se deben usar demasiado.

Valores sobrepuestos

Son columnas en las cuales los atributos plurales fueron implementados como singulares.

Resumen

Se deben implementar los atributos plurales en tablas dependientes y considerar el uso del dise�o de rengl�n.

Se deben evitar el uso de columnas sobrepuestas y los atributos codificados.

Sobrenormalizaci�n

Razones para la sobrenormalizaci�n:

1.- Remover datos sin importancia de tablas cr�ticas
2.- Remover grandes columnas descriptivas
3.- Cuando un solo rengl�n excede el tama�o de una p�gina

En el tercer punto, en Sybase 1 p�gina equivale a 2 kb. Esto es, solo se protegen 2 kb de tabla cuando alguien modifique un rengl�n.

La sobrenormalizaci�n mejora el desempe�o, pero primero se deben agotar las soluciones f�sicas.

Estructuras de datos

Pilas (stacks)

Colas

Listas

�rboles (Trees)

Grafos (Graphs)

Hosted by www.Geocities.ws

1 1