Administración de Bases de Datos

 

BASES DE DATOS RELACIONALES

 

            Una base de datos relacional consiste en una colección de tablas, a cada una de las cuales se asigna un nombre único. Cada tabla tiene una estructura similar donde se presenta la E-R. Una fila de la tabla presenta una relación entre un conjunto de valores. Puesto que una tabla es una colección de dichas relaciones, hay una estrecha correspondencia entre el concepto de tabla y el concepto matemático relación, del cual toma su nombre el modelo relacional.

 

 

Estructura Básica del Modelo Relacional

 

Nombre-Cliente

Número-Cuenta

Nombre-Cliente

Saldo

Downtown

Mianus

Perryridge

Round Hill

Rerryridge

Redwood

Brighton

Downtown

101

215

102

205

201

222

217

105

Juan

Sergio

Héctor

Teresa

María

Leticia

Gregoria

Gregoria

500

700

400

350

900

700

750

850

 

 

La tabla depósito tiene cuatro atributos. Para cada atributo hay un conjunto de valores permitidos, llamado domino de ese atributo. Para el atributo nombre-sucursal, por el ejemplo, el dominio es el conjunto de todos los nombres de las sucursales. Sea D1 ese conjunto y D2 el conjunto de todos los números de cuenta y así con cada atributo. Donde cada fila va a constar de 4 tuplas (V1, V2, V3, V4) donde V1 es un nombre de sucursal, es decir, V1 está en el dominio D1, V2 es un número de cuenta, es decir está en dominio D2 y así con cada uno. En general, depósito  contendrá únicamente un subconjunto del conjunto de todas las filas posibles. Por tanto, depósito es un subconjunto de

 

D1 x D2 x D3 x D4

 

Los matemáticos definen una relación como un subconjunto de un producto cartesiano de una lista de dominios. Esto corresponde casi exactamente con nuestra definición de tabla; la diferencia es que nosotros asignamos nombres a atributos, mientras que los matemáticos se basan en nombres numéricos, usando el entero 1 para el primer atributo, 2 para el segundo atributo y así sucesivamente. Puesto que las tablas son esencialmente relaciones, usaremos los términos matemáticos relación y tupla en lugar de los términos tabla y fila.

 

En la relación depósito hay ocho tuplas. Sea la variable tupla t la primera tupla de la relación. Usamos la notación t[nombre-sucursal] para indicar el valor de t en el atributo nombre-sucursal. Así t[nombre-sucursal]=”Downtown”. De la misma forma, t[número-sucursal]=101 y así para cada uno. Alternativamente podemos escribir t[1] para indicar  el valor de la tupla t en el atributo (nombre-sucursal), t[2] para indicar número-cuenta, y así sucesivamente. Puesto que una relación es un conjunto de tuplas, usamos la notación matemática tÎ r para indicar que la tupla t está en la relación r. Necesitamos que, para todas la relaciones r, los dominios de los atributos de r san atómicos.

 

 

Esquema de la Base de Datos

 

El concepto esquema de una relación corresponde a la noción de definición de tipo en los lenguajes de programación. Una variable de un tipo dado tiene un valor determinado en un instante de tiempo dado.

 

Así una variable en los lenguajes de programación corresponde al concepto de una instancia de una relación.

 

Adoptamos el convenio de usar nombres en minúsculas para las relaciones, y nombres empezando con una letra mayúscula para los esquemas de relaciones. Siguiendo esta notación usamos esquema-depósito para indicar el esquema de relación para la relación depósito.

 

Ejemplo:

 

            Esquema-depósito=(nombre-sucursal, número-cuenta, nombre-cliente, saldo)

 

Indicamos el hecho de que depósito es una relación sobre el esquema depósito por

 

                                    Depósito(esquema-depósito)

 

En general el esquema de una relación es una lista de atributos y sus correspondientes dominios.  Para definir los dominios será como sigue:

 

(nombre-sucursal:cadena, número-cuenta:entero, nombre-cliente:cadena, saldo:entero)

 

Esto es para definer el esquema de relación para la relación depósito.

 

Si quisiéramos definir otra relación cliente el esquema quedaría como sigue:

 

Esquema-cliente=(nombre-cliente, calle, ciudad-cliente)

 

Obsérvese que el atributo nombre-cliente aparece en los dos esquemas de relaciones. Es el uso de atributos comunes en esquema de relaciones es una forma de relacionar tuplas de distintas relaciones. Por ejemplo si queremos encontrar las ciudades donde viven los clientes de las sucursal Perryridge, primero miramos la relación depósito para encontrar todos los clientes de dicha sucursal, después miramos la relación cliente para encontrar la ciudad donde vive. Usando la terminología E-R decimos que el atributo nombre-cliente representa el mismo conjunto entidad en las dos relaciones.

 

 

 

 

 

 

Lenguajes de Consulta

 

            Un lenguaje de consulta es un lenguaje en el que un usuario solicita información de la base de datos. Estos lenguajes son normalmente de más alto nivel que los lenguajes estándar de programación. Los lenguajes de consulta pueden clasificarse en:

 

  • Lenguajes procedimentales
  • Lenguajes no procedimentales.

 

            Un Lenguaje procedimental, el usuario da instrucciones al sistema para que realice una secuencia de operaciones en la base de datos para calcular el resultado deseado.

 

            Un Lenguaje no procedimental, el usuario describe la información deseada sin dar un procedimiento específico para obtener esa información.

 

 

ALGEBRA RELACIONAL

 

            El algebra relacional es un lenguaje de consulta procedimental. Consta de un conjunto de operaciones que toman una o dos relaciones como entrada y producen una nueva relación como resultado. Las operaciones fundamentales del Algebra Relacional son Seleccionar, Proyectar, Producto cartesiano, Renombrar, Unión y Diferencia de conjuntos.

 

Operaciones Fundamentales:

 

Las operaciones seleccionar, proyectar y renombrar se llaman operaciones unitarias,  ya que operan sobre una relación. Las otras operan sobre pares de relaciones y, por tanto, se llaman binarias.

 

Seleccionar

 

            Esta operación selecciona tuplas que satisfacen un predicado dado. Usamos la letra griega minúscula sigma (s) para indicar la selección. El predicado aparece como subíndice de s. Ejemplo:

 

            Para seleccionar aquellas tuplas de la relación préstamo en la que la sucursal es “Nogales”, escribimos

 

snombre de sucursal=”Nogales”(préstamo)

 

 

            Podemos encontrar todas las tuplas en las que la cantidad prestada es más de 1200 pesos, escribimos

 

                                               scantidad>1200(préstamo)

 

Para las comparaciones usamos los símbolos =, ¹, >,<,³,£, en el predicado de la selección. También pueden combinarse varios predicados en un predicado más complejo usando los conectores Y (Ù) y O (Ú). Así para encontrar las tuplas escribimos:

 

snombre-sucursal=”Nogales” Ùcantidad>1200(préstamo)

 

 

Proyectar

 

            La operación proyectar es una operación unitaria que devuelve su relación argumento con ciertas columnas omitidas. Pues se eliminan todas las filas duplicadas. La proyección se indica por la letra griega pi (Õ). Listamos los atributos que queremos que aparezcan en el resultado como subíndices de Õ.

 

Ejemplos:

 

Supongamos que queremos una relación que muestre los clientes y las sucursales en las tienen préstamos, pero no nos interesa ni la cantidad del préstamo, ni el número de préstamo.

 

Õnombre-sucursal,nombre-cliente(préstamo)

 

 

Ahora supongamos que queremos encontrar a los clientes que tienen el mismo nombre que su banquero personal.

 

Õnombre-cliente(snombre-cliente=nombre-banquero(préstamo))

 

            Aquí observamos que en lugar de dar una relación como argumento para la operación proyección, damos una expresión que evalúa a una relación.

 

 

Producto Cartesiano

 

            Las operaciones que hemos tratado nos permiten extraer información únicamente de una sola relación.  La operación producto cartesiano representada por una (x) es una operación binaria.

 

            Supóngase que queremos encontrar a todos los clientes del banquero Jonson, así como las ciudades en las que viven estos clientes. Necesitamos la información en la relación servicio y en la relación cliente para resolver dicha incógnita.

El esquema de relaciones para es:

 

(servicio.nombre-cliente,servicio.nombre-banquero, cliente.nombre-cliente,cliente.calle,cliente.ciudad-cliente)

 

 

Es decir, simplemente listamos todos los atributos de las dos relaciones, y adjuntamos el nombre de la relación de la que el atributo procede originalmente. Necesitamos adjuntar el nombre de la relación para distinguir de servicio.nombre-cliente de cliente.nombre-cliente. Para aquellos atributos que aparecen en uno de los dos esquemas, omitiremos el prefijo nombre-relación. Esta situación no conduce a ninguna ambigüedad. Ahora podemos escribir la planificación de relación para r como:

 

(servicio.nombre-cliente,nombre-banquero, cliente.nombre-cliente,calle,cliente.ciudad-cliente)

 

Ya que conocemos el esquema de relaciones para r = servicio x cliente, ¿qué tuplas aparecen en r? Construimos una tupla de r por cada par posible de tuplas: de una relación grande. (como en el ejemplo)

 

Supongamos que tenemos n1 tuplas en servicio y n2 en cliente. Existen entonces n1n2 formas de elegir un par de tuplas: una tupla de cada relación; de forma que hay n1n2 tuplas para r. Observemos que puede darse el caso para algunas tuplas t en r que t[servicio.nombre-cliente] ¹ t[cliente.nombre-cliente].

 

En general si tenemos r1 x r2 es una relación cuyo esquema es la concatenación de R1 y R2. La relación R contiene todas las tuplas t ara las cuales existe una tupla t1 en r1 y t2 en r2. Volviendo a la pregunta “encontrar a todos los clientes del banquero Jonson y la ciudad en la que viven”, consideremos la relación r = servicio x cliente. Si escribimos

 

snombre-banquero = “Johnson” (servicio x cliente)

 

Entonces el resultado es la relación que se muestre en la figura B. Tenemos una relación que corresponde únicamente al banquero Jonson. Sin embargo, el dominio cliente.nombre-cliente puede contener clientes de banqueros que no sean Jonson. Porque recuerde que el producto cartesiano toma los pares de tupla de servicio con la tupla de cliente. Observe que el dominio servicio.nombre-cliente contiene solo clientes de Jonson.

 

Puesto que la operación producto cartesiano asocia todas la tuplas de cliente con todas las tuplas de servicio, sabemos que alguna tupla de servicio x cliente tiene la dirección del cliente del banquero. Esto ocurre en aquellos casos en los que sucede que servicio.nombre-cliente = cliente.nombre-cliente. Así, escribimos

 

sservicio.nombre-cliente = cliente.nombre-cliente(snombe-banquero = “Jonson” (servicio x cliente))

 

Con esto obtenemos las tuplas de servicio x cliente que

 

  • Se relacionan con Jonson
  • Tienen la dirección y la ciudad del cliente de Jonson

 

Finalmente, puesto que solo queremos nombre-cliente y ciudad-cliente, hacemos una proyección:

 

Õservicio.nombre-cliente,ciudad-cliente(sservicio.nombre-cliente=cliente.nombre-cliente(snombre-banquero=”Jonson”(servicio x cliente)))

 

El resultado de esta expresión es la respuesta correcta a nuestra pregunta.

 

 

Renombrar

 

En el ejemplo anterior, introdujimos el convenio de nombrar atributos mediante nombre-relación.nombre-atributo para eliminar posibles ambigüedades. Otra forma de ambigüedad surge cuando la misma relación aparece más de una vez en una pregunta. Como ejemplo, consideremos la pregunta “Encontrar los nombres de todos los clientes que viven en la misma calle y en la misma ciudad que Smith”. Quedaría como sigue:

 

Õcalle,ciudad-cliente(snombre-cliente=”Smith”(cliente))

 

Sin embargo, para encontrar otros clientes con esa calle y esa ciudad, debemos hacer referencia una segunda vez  a la relación cliente:

 

sp(cliente) x Õcalle, ciudad-cliente(snombre-cliente = “Smith” (cliente)))

 

Donde P es un predicado de selección que requiere que los valores de calle y los valores de ciudad-cliente sean iguales. Para especificar a qué valor de calle nos referimos, no podemos usar cliente.calle, ya que ambos valores de calle se toman de la misma relación cliente. Una dificultad parecida existe para cliente.ciudad. Este problema se resuelve usando el operador renombrar, representado por p. La expresión quedaría:

 

px(r)

 

devuelve la relación r con el nombre de x. Usaremos ésta para renombrar una referencia a la relación cliente y así hacer referencia a la relación dos veces sin ambigüedad. En la consulta de abajo usamos el nombre cliente2 al calcular la calle y la ciudad de Smith.

 

Õcliente.nombre-cliente((scliente2.calle=cliente.calleÙcliente2.cliente-ciudad=cliente.cliente-ciudad(cliente x (Õcalle,ciudad-cliente(snombre-cliente=”Smith”(pcliente2(cliente))))))

 

 

Unión

 

            Esta operación esta considerada como una consulta que podría plantearse con el siguiente ejemplo: El departamento de publicidad de un banco quiere “encontrar a todos los clientes de la sucursal Perryridge”. Para contestar esta consulta, necesitamos la información de la relación préstamo y de la relación depósito. Sabemos como encontrar a todos los clientes con un préstamo en la sucursal Perryridge:

 

Õnombre-cliente(snombre-sucursal=”Perryridge”(préstamo)

 

De la misma forma cómo encontrar a todos los clientes con una cuenta en la sucursal Perryridge

 

Õnombre-cliente(snombre-sucursal=”Perryridge”(depósito)

 

Para contestar la consulta, necesitamos la unión de estos dos conjuntos, es decir, todos los clientes que aparecen en cualquiera de las dos relaciones o en ambas. Esto se logra mediante la operación binaria unión, representada, como en la teoría de conjuntos, por È. Así la expresión que el departamento de publicidad necesita en nuestro ejemplo es:

 

Õnombre-cliente(snombre-sucursal=”Perryridge”(préstamo)

ÈÕnombre-cliente(snombre-sucursal=”Perryridge”(depósito)

 

Si hubiera valores duplicados se eliminan, puesto que las relaciones son conjuntos. Obsérvese que tomamos la unión de dos conjunto, ambos formados por los valores de nombre-cliente, es decir, debemos que las dos relaciones sean compatibles. Las relaciones deben tener el mismo número de atributos y de dominios.

 

 

Diferencia de conjuntos

 

            La operación diferencia de conjuntos representada por ¾, nos permite encontrar las tuplas que estén en una relación pero no en la otra.

 

Podemos encontrar a todos los clientes de la sucursal Perryridge que tienen un cuenta allí, pero no un préstamo, escribiendo

 

Õnombre-cliente(snombre-sucursal=”Perryridge”(préstamo)

¾Õnombre-cliente(snombre-sucursal=”Perryridge”(depósito)

 

Si en la consulta pidieramos “encontrar todos los saldos excepto el mayor” el esquema quedaría:

 

Õsaldo.depósito(ssaldo.depósito<d.saldo (depósito x pd(depósito)))

 

Esta expresión de aquellos valores de la relación depósito para los que aparece un saldo mayor en algún lugar de la relación depósito (renombrado por d). El resultado contiene todos los saldos excepto el mayor.

 

 

El CÁLCULO RELACIONAL DE TUPLAS

 

            Cuando escribimos una expresión en álgebra relacional, damos una secuencia de procedimientos que genera la respuesta a nuestra consulta. El cálculo relacional de tuplas, en cambio, es un lenguaje d consultas no procedimental. Describe la información deseada sin dar un procedimiento específico para obtener esta información.

 

            Una consulta en el calculo relacional de tuplas se expresa como sigue

 

{t|P(t)}

 

Es decir, el conjunto de todas las tuplas de t, tl que el predicado P, es verdadero para t. Siguiendo la notación anterior, usamos t[A] para representar el valor de la tupla t en el atributo A, y usamos t Î r para indicar que la tupla t esta en la relación r.

 

Ejemplos de consultas:

 

Encontrar el nombre-sucursal, número-préstamo, nombre-cliente, y cantidad para préstamos mayores de 1200 dólares:

{t|tÎpréstamoÙt[cantidad]>1200}

 

Supóngase que queremos únicamente el atributo nombre-cliente y todos los atributos de la relación préstamo. Para escribir esta consulta en el cálculo relacional de tuplas necesitamos escribir una expresión para una relación sobre el esquema (nombre-cliente). Necesitamos aquellas tuplas en (nombre-cliente) tales que exista una tupla en préstamo correspondiente a ese nombre-cliente con el atributo cantidad >1200 dólares. Para expresar esto necesitamos la construcción <exite> de la lógica matemática. La notación

 

$tÎr(Q(t))

 

Significa <exite una tupla t en la relación r tal que el predicado Q(t) es verdadero>

 

Usando esa notación podemos escribir la consulta <encontrar a todos los clientes que tienen un préstamo por una cantidad mayor d 1200 dólares>, como:

 

{t|$sÎpréstamo (t[nombre-cliente]=s[nombre-cliente]Ùs[cantidad]>1200)}

 

En español, la expresión anterior se lee: <el conjunto de todas las tuplas t tal que existe una tula s en la relación préstamo para la cual los valores de t y s para el atributo nombre-cliente son iguales y el valor de s para el atributo cantidad se mayor de 1200 dólares>.

 

La variable de tupla t se define sólo en el atributo nombre-cliente puesto que ése es el único atributo para el que se especifica una condición para t. Así, el resultado es una relación sobre (nombre-cliente).

 

Considérese la consulta <Encontrar a todos los clientes que tienen un préstamo de la sucursal Perryridge y las ciudades en las que viven>. Esta consulta es un poco más compleja que las anteriores, puesto que implica dos relaciones, a saber, cliente y préstamo. Pero, como veremos todo lo que se requiere es que tengamos dos cláusulas <existe> en nuestra expresión del cálculo relacional de tuplas conectadas por y (Ù). Escritos:

 

{t|$sÎpréstamo(t[nombre-cliente]=s[nombre-cliente]

Ùs[nombre-sucursal]=”Perryridge”

Ù $uÎcliente(u[nombre-cliente]=s[nombre-cliente]

Ùt[ciudad-cliente]=u[ciudad-cliente]))}

 

En español, éste es <el conjunto de todas las  tuplas (nombre-cliente, nombre-cliente) para las cuales nombre-cliente es un receptor de préstamo en la sucursal Perryridge y ciudad-cliente es la ciudad de nombre-cliente>. La variable de tupla s asegura que el cliente tiene  un préstamo en la sucursal Perryridge. La variable de tupla u tiene la restricción de que debe pertenecer al mismo cliente que s, y u asegura que ciudad-cliente es la ciudad del cliente. El resultado de esta consulta se muestra a continuación:

 

Nombre-cliente

Ciudad-cliente

Hayes

Glenn

Harrison

Woodside

Para encontrar a todos los clientes que tienen un préstamo, una cuenta o las dos, en la sucursal Perryridge se usó la operación unión en el álgebra relacional. En el cálculo relacional de tuplas necesitamos dos cláusulas <existe> conectadas por o (Ú).

 

{t|$sÎpréstamo(t[nombre-cliente]=s[nombre-cliente]

Ùs[nombre-sucursal]=Perryridge”)

Ù$uÎdepósito(t[nombre-cliente]=u[nombre-cliente]

Ùu[nombre-sucursal]=”Perryridge”)}

 

La expresión anterior nos da el conjunto de todas las tuplas nombre-cliente que cumple a menos una de las siguientes condiciones:

 

  • El nombre-cliente aparece en alguna tupla de la relación préstamo como receptor de préstamo de la sucursal Perryridge.
  • El nombre-cliente aparece en alguna tupla de la relación depósito como depositante de la sucursal Perryridge.

 

Si algún cliente tiene un cuenta y un préstamo en la sucursal Perryridge, ese cliente aparece sólo una ve en el resultado porque la definición matemática de un conjunto no permite duplicar miembros.  El resultado sería el siguiente:

 

Nombre-cliente

Hayes

Glenn

Williams

 

Si ahora queremos únicamente aquellos clientes que tienen una cuenta y un préstamo en la sucursal Perryridge, todo lo que necesitamos hacer es cambiar la o (Ú) y la y (Ù) en la expresión anterior

 

{t|$sÎpréstamo(t[nombre-cliente]=s[nombre-cliente]

Ùs[nombre-sucursal]=Perryridge”)

Ù$uÎdepósito(t[nombre-cliente]=u[nombre-cliente]

Ùu[nombre-sucursal]=”Perryridge”)}

 

El resultado sería el siguiente:

 

Nombre-cliente

Hayes

 

Ahora considérese la consulta <Encontrar a todos los clientes que tienen una cuenta en la sucursal Perryridge pero no tienen un préstamo de la sucursal Perryridge>. La expresión del cálculo relacional de tuplas para esta es similar a los que acabamos de ver, excepto el uso del símbolo no (Ø).

 

{t|$uÎdepósito(t[nombre-cliente]=u[nombre-cliente]

Ùs[nombre-sucursal]=Perryridge”)

ÙØ$sÎpréstamo(t[nombre-cliente]=s[nombre-cliente]

Ùs[nombre-sucursal]=”Perryridge”)}

La expresión anterior del cálculo relacional de tuplas usa la cláusula de $ u Î depósito (…) para exigir que el cliente tenga una cuenta en la sucursal Perryridge, y usa la cláusula Ø $ s Î préstamo (…) para eliminar aquellos clientes que aparezcan en alguna tupla de la relación préstamo por tener un préstamo de la sucursal Perryridge. El resultado de esta consulta aparece en el siguiente recuadro

 

Nombre-cliente

Williams

 

La consulta que vamos a considerar a continuación usa la implicación, representada Þ. La fórmula PÞQ significa <<P implica Q>>; es decir <<si P es verdadera, entonces Q debe ser verdadera>>. Obsérvese que PÞQ es equivalente lógicamente a Ø PÚQ. El uso de la implicación en lugar del no y o a menudo sugiere n interpretación más intuitiva de una en una consulta en español.

 

 

 

 

 

Normalización de una base de datos

El proceso de normalización de una base de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo E-R (entidad-relación) al modelo relacional.

Las bases de datos relacionales se normalizan para:

  • Evitar la redundancia de los datos.
  • Evitar problemas de actualización de los datos en las tablas.
  • Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla bidimensional sea considerada como una relación tiene que cumplir con algunas restricciones:

  • Cada columna debe tener su nombre único.
  • No puede haber dos filas iguales. No se permiten los duplicados.
  • Todos los datos en una columna deben ser del mismo tipo.
  •  

Terminología equivalente

  • entidad = tabla o archivo
  • tupla = registro, fila o renglón
  • atributo = campo o columna
  • base de datos = banco de datos
  • dependencia multivaluada = dependencia multivalor
  • clave = llave
  • clave primaria = superclave
  • clave ajena = clave externa o clave foránea
  • RDBMS = del inglés Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales

Dependencia funcional

Una dependencia funcional son conexiones entre uno o más atributos. Por ejemplo si conocemos el valor de FechaDeNacimiento podemos conocer el valor de Edad.

Las dependencias funcionales se escriben utilizando una flecha, de la siguiente manera:

FechaDeNacimiento->Edad

Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener éstas dependencias funcionales para lograr mayor eficiencia en las tablas.

Dependencia funcional transitiva

Supongamos que en la relación de la figura 3.0 los estudiantes solo pueden estar matriculados en un solo curso y supongamos que los profesores solo pueden dar un curso.

ID_Estudiante -> Curso_Tomando

Curso_Tomando -> Profesor_Asignado

ID_Estudiante -> Curso_Tomando -> Profesor_Asignado

Entonces tenemos que ID_Estudiante determina a Curso_Tomando y el Curso_Tomando determina a Profesor_Asignado, indirectamente podemos saber a través del ID_estudiante el Profesor_Asignado. Entonces en la figura 3.0 tenemos una dependencia transitiva.

Claves

Clave ajena

Cuando se tienen dos tablas o más, una clave ajena es aquella columna de una tabla que hace referencia a una clave primaria de otra tabla. Supongamos que tenemos una base de datos con las dos tablas. Como podemos ver en la tabla de la figura 4.0 la columna NumeroCliente hace de clave primaria, pero en la tabla de la figura 5.0 la columna de NumeroCliente hace de clave externa. La clave primaria NumeroCliente de la figura 4.0 hace referencia a toda la fila, evitando así errores tipográficos y ahorrando espacio físico.

También existe el caso de Relaciones Autoreferenciales. Sucede cuando en la misma relación se tiene una clave ajena que hace referencia a la clave primeria de la misma relación. Un ejemplo es EMP (NumEmp, Nombre,... ,NumEmp-Ger). En este caso NumEmp-Ger es una clave ajena que hace referencia a la clave primaria NumEmp. Por otro lado las claves ajenas pueden tomar valores nulos, como por ejemplo para un Gerente, el valor NumEmp-Ger sería nulo, ya que no posee ninguna persona a nivel superior.


Regla de Integridad Referencial

La base de datos no debe contener valores de clave ajena sin concordancia. Así como los valores de clave primaria representan identificadores de entidades, las claves ajenas representan referencia a entidades.

La regla dice: Si B hace referencia a A entonces A debe existir.

Surgen los siguientes dos puntos: - La integridad referencial exige concordancia en las claves ajenas, con las claves primarias, no con la claves alternativas. - Los conceptos de clave ajena e integridad referencial se definen uno en termino del otro.

Clave candidata

En la figura 1.0 podemos ver que tenemos al atributo ID_empleado como clave primaria, aunque podemos ver que tenemos a otro atributo llamado Seguro Social que también lo podemos utilizar de clave primaria, puesto que se supone que éste sea unívoco para cada persona, entonces decimos que tanto ID_empleado como Seguro Social son claves candidatas. Por lo general la forma más eficiente y segura para escoger o hacer la clave primaria es poniendo un número y aumentando éste a medida que se van añadiendo filas, pero si de casualidad se diera el caso de que existan varias claves candidatas de las cuales se deba escoger la clave primaria, esta elección se hace utilizando el sentido común.

Clave alternativa

Son aquellas claves candidatas que no han sido elegidas. En el ejemplo anterior Seguro Social pasaría a ser una clave alternativa en caso de no ser elegida como clave primaria.

Clave simple

Es una clave que esta compuesta solo de un atributo.

Clave compuesta

Es una clave que esta compuesta por más de un atributo.

 

 

Pasos para la normalización

·         Descomponer todos los grupos de datos en registros bidimensionales.

·         Eliminar todas las relaciones en la que los datos no dependan completamente de la llave primaria del registro.

·         Eliminar todas las relaciones que contengan dependencias transitivas.

            La teoría de la normalización tiene como fundamento el concepto de formas normales; se dice que una relación esta en una determinada forma normal si satisface un conjunto de restricciones.

Formas Normales

Las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd, éste introdujo la normalización en un artículo llamado A Relational Model of Data for Large Shared Data Banks Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387[1].

Primera Forma Normal (FNF o 1FN)

Sea α un conjunto de atributo perteneciente (Є) a la relación R, en donde R está en la Primera Forma Normal si todos los atributos α[n] son atómicos, es decir no pueden seguir dividiéndose.

Esta forma debe cumplir lo siguiente:

1.      Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos repetidos, como valores, es decir, contienen un solo valor por cada celda.

2.      Todos los ingresos en cualquier columna (atributo) deben ser del mismo tipo.

3.      Cada columna debe tener un nombre único, el nombre de las columnas en la tabla no es importante.

4.      Dos filas o renglones de una misma tabla no deben ser idénticas, aunque el orden de las filas no es importante.

Por ejemplo:

La Relación:

  • cursos: nombre, código, vacantes, horario, bibliografía

Queda después de aplicar la Forma Normal 1 de la siguiente manera:

  • cursos1: nombre, código, vacantes
  • horario1: código, día, módulo
  • bibliografia1: código, nombre, autor

Una columna no puede tener multiples valores. Los datos estan atomicos (Si a cada valor de X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X).

Segunda Forma Normal (SNF o 2FN)

Para definir formalmente la segunda forma normal requerimos saber que es una dependencia funcional: Consiste en edificar que atributos dependen de otros atributos.

                                                           Atributo dependiente (Semestre que cursa)

Atributo (Número-control)   

                                                           Atributo dependiente (Especialidad)

Dependencia completa. Esta en 2FN si esta en 1FN y si sus atributos no principales dependen de forma completa de la clave principal. Toda columna que no sea clave debe depender por completo de la clave primaria. Los atributos dependen de la clave. Varia la clave y varian los atributos. Dependencia completa. Sus atributos no principales dependen de forma completa de la clave principal.

 

Tercera Forma Normal (TNF o 3FN)

Para definir formalmente la 3FN necesitamos definir dependencia transitiva: en una tabla bidimensional que tiene por lo menos 3 atributos (A,B,C) en donde A determina a B, B determina a C pero C no determina a A.

Una relación esta en 3FN si y solo si esta en 2FN y todos son atributos primos dependen no transitivamente de la llave primaria.

Consiste en eliminar la dependencia transitiva que queda en una 2FN, en pocas palabras una relación esta en 3FN si esta en 2FN y no existe dependencias transitivas entre los atributos, nos referimos a dependencias transitivas cuando existe más de una forma de llegar a referenciar a un atributo en una relación.

Cuarta Forma Normal (FNF)

Está en forma normal de Boyce-Codd y se eliminan las dependencias multivaluadas y se generan todas las relaciones externas con otras tablas u otras bases de datos.

Quinta Forma Normal (5FN)

Está en cuarta forma normal y toda dependencia-join viene implicada por claves candidatas.

 

 

Reglas de Codd

Codd se dio de cuenta que existían bases de datos en el mercado las cuales decían ser relacionales, pero lo único que hacían era guardar la información en las tablas, sin estas tablas estar literalmente normalizadas; entonces éste publicó 12 reglas que un verdadero sistema relacional debería de tener, en la práctica algunas de ellas son difíciles de realizar.Un sistema podrá considerarse "más relacional" cuanto más siga estas reglas.

Regla No. 1 - La Regla de la información

"Toda la información en un RDBMS está explícitamente representada de una sola manera por valores en una tabla".

Cualquier cosa que no exista en una tabla no existe del todo. Toda la información, incluyendo nombres de tablas, nombres de vistas, nombres de columnas, y los datos de las columnas deben estar almacenados en tablas dentro de las bases de datos. Las tablas que contienen tal información constituyen el Diccionario de Datos.

Regla No. 2 - La regla del acceso garantizado

"Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que combine el nombre de la tabla, su clave primaria, y el nombre de la columna".

Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el nombre de la columna requerida, deberá encontrarse uno y solamente un valor. Por esta razón la definición de claves primarias para todas las tablas es prácticamente obligatoria.

Regla No. 3 - Tratamiento sistemático de los valores nulos

"La información inaplicable o faltante puede ser representada a través de valores nulos".

Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar el uso de valores nulos en el lugar de columnas cuyos valores sean desconocidos o inaplicables.

Regla No. 4 - La regla de la descripción de la base de datos

"La descripción de la base de datos es almacenada de la misma manera que los datos ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios autorizados".

La información de tablas, vistas, permisos de acceso de usuarios autorizados, etc, debe ser almacenada exactamente de la misma manera: En tablas. Estas tablas deben ser accesibles igual que todas las tablas, a través de sentencias de SQL.

Regla No. 5 - La regla del sub-lenguaje Integral

"Debe haber al menos un lenguaje que sea integral para soportar la definición de datos, manipulación de datos, definición de vistas, restricciones de integridad, y control de autorizaciones y transacciones".

Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que pueda ser usado para administrar completamente la base de datos.

Regla No. 6 - La regla de la actualización de vistas

"Todas las vistas que son teóricamente actualizables, deben ser actualizables por el sistema mismo".

La mayoría de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar vistas complejas.

Regla No. 7 - La regla de insertar y actualizar

"La capacidad de manejar una base de datos con operandos simples aplica no solo para la recuperación o consulta de datos, sino también para la inserción, actualización y borrado de datos".

Esto significa que las cláusulas SELECT, UPDATE, DELETE e INSERT deben estar disponibles y operables sobre los registros, independientemente del tipo de relaciones y restricciones que haya entre las tablas.

Regla No. 8 - La regla de independencia física

"El acceso de usuarios a la base de datos a través de terminales o programas de aplicación, debe permanecer consistente lógicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los métodos de acceso a los datos".

El comportamiento de los programas de aplicación y de la actividad de usuarios vía terminales debería ser predecible basados en la definición lógica de la base de datos, y éste comportamiento debería permanecer inalterado, independientemente de los cambios en la definición física de ésta.

Regla No. 9 - La regla de independencia lógica

"Los programas de aplicación y las actividades de acceso por terminal deben permanecer lógicamente inalteradas cuando quiera que se hagan cambios (según los permisos asignados) en las tablas de la base de datos".

La independencia lógica de los datos especifica que los programas de aplicación y las actividades de terminal deben ser independientes de la estructura lógica, por lo tanto los cambios en la estructura lógica no deben alterar o modificar estos programas de aplicación.

Regla No. 10 - La regla de la independencia de la integridad

"Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo, no en el programa de aplicación".

Las reglas de integridad son:

1. Ningún componente de una clave primaria puede tener valores en blanco o nulos. (esta es la norma básica de integridad).

2. Para cada valor de clave foránea deberá existir un valor de clave primaria concordante. La combinación de estas reglas aseguran que haya Integridad referencial.

Regla No. 11 - La regla de la distribución

"El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos esté distribuida físicamente en distintos lugares sin que esto afecte o altere a los programas de aplicación".

El soporte para bases de datos distribuidas significa que una colección arbitraria de relaciones, bases de datos corriendo en una mezcla de distintas máquinas y distintos sistemas operativos y que este conectada por una variedad de redes, pueda funcionar como si estuviera disponible como jeje una única base de datos en una sola máquina.

Regla No. 12 - Regla de la no-subversión

"Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para violar la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como SQL)".

Algunos productos solamente construyen una interfaz relacional para sus bases de datos No relacionales, lo que hace posible la subversión (violación) de las restricciones de integridad. Esto no debe ser permitido.

 

Visual FoxPro

 

Historia

Visual FoxPro proviene de FoxPro, que a su vez deriva de FoxBASE, creado por Fox Technologies en 1984; inicialmente un compilador de dBase, acabó superándolo y con Clipper, convirtiéndose en una de las estrellas de los lenguajes xBase. Fox Technologies fue adquirido por Microsoft en 1992.

Visual FoxPro 3.0, fue la primera versión “Visual”, redujo su compatibilidad a solo Mac y Windows (La última versión de FoxPro (2.6) corría en MS-DOS, MS Windows, Mac OS y UNIX), versiones posteriores fueron solo para Windows. La versión actual se basa en archivos COM y Microsoft ha declarado que no piensan crear una versión .NET.

En la versión 5.0 se integra en Microsoft Visual Studio añadiéndosele el soporte de Microsoft Source Safe. Hasta entoces es visto típicamente por el publico como meramente un Sistema de gestión de base de datos (SGBD), ignorando el hecho de que no solo incluye el entorno SGBD, sino un completo lenguaje de programación.

Visual FoxPro 6.0, publicado en 1999, no supone un cambio radical respecto de la anterior versión sino únicamente una mejora en sus diversas funcionalidades y una adaptación al mundo internet y al mundo de los objetos. Esta versión hace más atractivo a los desarrolladores el tratamiento de los datos en los entornos COM. Es un paso más en la evolución de este producto desde un entorno de aplicaciones monousuario o de redes pequeñas centradas en los datos hacia una herramienta orientada a objeto diseñada para la construcción de la lógica del negocio en los entornos multi-tier con una fuerte orientación hacia los tratamientos intensivos de datos en Internet. Pese a su relativa antigüedad, es hoy todavía ampliamente utilizado en grandes empresas (por ej., la compañía de seguros Mapfre) por su estabilidad.

Visual FoxPro 7.0, publicado en 2001, supuso su salida de Visual Studio, pues aunque en un principio se pensaba incluir a Fox en .NET, no era posible sin romper con la herencia de anteriores versiones. Esta versión incorporó por primera vez el IntelliSense, y se mejoró el manejo de arrays, acercándolo al de cursores.

A finales del 2002, algunos miembros de comunidades demostraron que Visual FoxPro puede correr en Linux usando el emulador de Windows Wine. En el 2003, esto llevo a quejas de Microsoft: se dijo que el desarrollo de código de FoxPro para rutinas en máquinas no-Windows viola el Acuerdo de Licencia de Usuario Final.

Los rumores de que Microsoft planea terminar el soporte para FoxPro han sido comunes desde su adquisición del producto, a pesar del hecho de que éste ha tenido el tiempo de vida de soporte más largo para un producto de Microsoft (hasta el 2014). VFP 9 fue lanzado el 17 de diciembre del 2004 y el equipo de Fox está trabajando actualmente en un proyecto cuyo nombre clave es Sedna que será construido sobre el código base de VFP 9 y consistirá principalmente en componentes Xbase que soportarán un número de escenarios interoperables con varias tecnologías de Microsoft incluyendo SQL Server 2005, .NET, WinFX, Windows Vista y Office 12.

 

Visual FoxPro es un lenguaje de programación orientado a objetos y procedural, un Sistema Gestor de Bases de datos o Database Management System (DBMS), y desde la versión 7.0, un Sistema administrador de bases de datos relacionales, producido por Microsoft.

Características

Visual FoxPro ofrece a los desarrolladores un conjunto de herramientas para crear aplicaciones de bases de datos para el escritorio, entornos cliente/servidor, table PC o para la Web.

Entre sus características se pueden enumerar:

  • Capacidades poderosas y muy veloces para el manejo de datos nativos y remotos.
  • Flexibilidad para crear todo tipo de soluciones de bases de datos.
  • Lenguaje de programación Orientado a objetos.
  • Utilización de sentencias SQL en forma nativa.
  • Poderoso manejo de vistas y cursores y control completo de estructuras relacionales.
  • Su propio gestor de base de datos incorporado. Sin embargo, también puede conectarse con servidores de base de datos, tales como Oracle, Microsoft SQL Server o MySQL.
  • Cuenta con un motor de generación de informes renovado y muy flexible para soluciones más robustas.
  • Desde la versión 9.0, amplio soporte de XML, tanto como fuente de datos (por ej., servicios Web basados en XML) como por generar reports en formato XLM.
  • Desde la versión 7.0, soporte de la tecnología IntelliSense de Microsoft

 

Visual Fox Pro es un gestor de base de datos, orientado a la programación de objetos.

Visual Fox Pro pertenece a la familia xbase lo que hace que su programación sea sencilla, estructurada y más fácil de entender tanto para programadores principiantes como programadores expertos.

Nos enfocaremos en cinco áreas principales:

·         Base de datos: Trata sobre el diseño, creación y manipulación de tablas libres o tablas con integridad referencial (base de datos)

·         Programación: En esta parte seremos capaces de identificar y aplicar las estructuras básicas de programación y conocer aspectos sobre la programación orientada a objetos.

·         Formularios: Aplicaremos conocimientos para la integración de una interfaz con el usuario y base de datos.

·         Informes: Aprenderemos a diseñar las salidas de los sistemas de información, haciendo uso de las herramientas que el programa ofrece.

·         SQL: haremos uso del lenguaje SQL para manipular datos, creando así diferentes consultas o vistas.

FoxPro es un lenguaje de mucha rapidez, esto lo convierte en un lenguaje de los más rápidos en el mercado, FoxPro es también uno de los lenguajes de programación que contiene mucha potencia en el manejo de las bases de datos.

Algunas herramientas más utilizadas de FoxPro son:

·         Ventana Examinar: una vista, tipo hoja de cálculo, de una tabla.

·         Ventana Código: para desplegar código asociado a varios eventos en los formularios y controles. Cuando un evento se dispara el código se ejecuta.

·         Ventana Depuración: permite examinar variables de memoria o valores campos y establecer puntos de interrupción. La ejecución del programa se detiene cuando una variable de memoria o una expresión con un punto de interrupción cambian de valor.

·         Comando Opciones (Menú de Herramientas): permite controlar la configuración de docenas de características en el entorno FoxPro, incluidos todos los comandos SET, así como planillas y bibliotecas de clases.

·         Ventana Propiedades: permite establecer propiedades en una buena cantidad de generadores, incluidos los generadores de formularios, informes etiquetas y de las bases de datos, también proporciona acceso a propiedades, métodos y código de eventos.

·         Administrador de Proyectos: un diseño completamente novedoso de FoxPro para Windows, este administrador de proyectos administra todos los componentes de un proyecto en cinco grupos: Bases de datos (con extensión .DBC), tablas libres (con extensión .DBF), vistas locales y remotas, conexiones, etc.

·         Generador de consultas: una recodificación completa del RQBE (Consulta Relacional Ejemplificada), esta herramienta maneja todos los aspectos de construir una consulta.

·         Barras de herramientas FoxPro: proporciona a los generadores aplicaciones más de una docena de barras de herramientas para colocar toda la herramienta para varias tareas justo al alcance de sus dedos. Además, puedes diseñar tus propias barras de herramientas en conjunción con formularios, para proporcionar a los usuarios el mismo tipo de acceso instantáneo a las herramientas.

Generadores

Los generadores son entornos de trabajo en los que se construyen componentes de una aplicación de FoxPro.

En la siguiente lista te mostrare algunos generadores:

·         Generador de clases Para construir objetos reutilizables.

·         Generador de Bases de Datos Para organizar los datos en tablas y documentar las relaciones entre tablas.

·         Generador de formularios Para diseñar las pantallas de la aplicación.

·         Generador de consulta Para construir conjuntos de datos utilizados en reportes y en pantallas de sólo lectura.

·         Generador de informes Para construir informes para la pantalla o la impresora.

·         Generador de menús Construye el sistema de menús que ejecuta una aplicación.

·         Generador de tablas Administra el formato de las tablas utilizadas en la aplicación.

·         Generador de cuadrículas Permite aprender cómo las configuraciones de la propiedad de cuadrícula del objeto controlan la operación de la cuadrícula.

Asistentes

Son conjunto de cuadro de diálogos que te ayudan paso a paso a crear una determinada aplicación, por ejemplo un formulario, etc.

·         Asistente para formularios: Construye "Pantallas instantáneas" con la estructura de las tablas basándose en clases prediseñadas, incluidos efectos especiales en las pantallas y botones de navegación ínter construidos.

·         Asistente para documentación: Documenta la aplicación.

·         Asistente para informes: Diseña informes, sencillos o complejos, utilizando un poco más que la estructura de las tablas.

·         Asistente para tablas: Útil para hacer tablas sencillas

Barras de Herramientas

El propósito de que hayan estas barras es para hacerte un poco más fácil el trabajo, es decir que el uso que le dará a la ventana de comandos será un poquito reducido.

·         Paleta de colores creo que te imaginas que es la barra de los colores en función RGB. Bueno RGB significa (Rojo, Verde y Azul)

·         Generador de bases de datos en esta barra se manejan el entorno de datos, iconos para: crear, agregar, y quitar una tabla así, como también modificar, vista remota o local, examinar una tabla o editar procedimientos almacenados en el contenedor de la base de datos.

·         Generador de formularios esta barra te permite el paso rápido de uno a otro entre varios elementos usados en el diseño de pantallas: el entorno de los datos, la ventana propiedades, la ventana código la barra Controles de formularios, la paleta de colores, la barra de herramientas. Distribución, entre otros.

·         Presentación Preliminar para que una vez diseñado un informe puedas apreciarlo como te quedará y si no te gusta pues lo podrás modificar.

·         Estándar Este lo verás cuando inicies FoxPro, proporciona acceso al generador de formularios y al Generador de informes, a bases de datos de impresión consultan tablas, conexiones, vistas, etiquetas, programas, clases, archivos de texto y menús.

La barra de herramientas en FoxPro hay muchos botones, estos botones pertenecen a la barra de herramientas de VFP. También existen otras barras de herramientas. Se hace clic en el menú Ver, aparece una sola opción de barras de herramientas. Sólo haz clic en la barra que quieres activar y aparecerá al igual que la estándar. Algunas de estas barras ya las vimos anteriormente.

 

Administrador de Proyectos

Estos proyectos están integrados por el Administrador de proyectos, quien mantiene la pista de los componentes de la aplicación. Conforme se agregan componentes a un proyecto, (Estas son las carpetas o nombre de los menús del Administrador) FoxPro los colecta bajo alguno de los siguientes encabezados:

·         Datos: las bases de datos (y todos los elementos que pueden describir), incluidas las tablas, vistas locales y remotas, conexiones y procedimientos almacenados, así como tablas libres y consultas.

·         Documentos: formularios, etiquetas e informes.

·         Bibliotecas de clases: repositorios de objetos usados en la aplicación.

·         Código: los archivos con extensión .PRG que contienen código que no está asociado con un formulario, así como bibliotecas API y archivos llamados por la aplicación.

·         Otros: menús, archivos de texto y otros, incluyendo mapas de bits.

Estructura de un .BDF

Los datos en FoxPro se almacenan en forma de tablas, estas tablas son las bases de datos pues la extensión de estas bases de datos es .DBF aunque también hay otras que se verá más adelante. Los DBF comienzan con una breve descripción de los datos que están en la tabla.

 

 

 

 

 

Página de Inicio

 

 

Webmaster: L.I. Ma. de Lourdes Guarneros Morales                                                                                               Sitio Patrocinado por REYDEC