Normalización
de bases de datos
El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el
paso del modelo 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 sea considerada como una relación
tiene que cumplir con algunas restricciones:
§ Cada
tabla 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.
Primera Forma Normal
(1FN)
Artículo principal: Primera forma
normal.
Una tabla está en Primera Forma Normal si:
§ Todos los atributos son atómicos. Un
atributo es atómico si los elementos del dominio son indivisibles, mínimos.
§ La tabla contiene una llave primaria
única.
§ La llave primaria no contiene
atributos nulos.
§ No debe existir variación en el número
de columnas.
§ Los Campos no llave deben
identificarse por la llave (Dependencia Funcional)
§ Debe Existir una independencia del
orden tanto de las filas como de las columnas, es decir, si los datos cambian
de orden no deben cambiar sus significados
§ Una tabla no puede tener múltiples
valores en cada columna.
§ Los datos son atómicos (a cada valor
de X le pertenece un valor de Y y viceversa).
Esta forma normal elimina los valores
repetidos dentro de una BD
Segunda Forma Normal (2FN)
Artículo principal: Segunda forma normal.
Dependencia Funcional. Una relación está en
2FN si está en 1FN y si los atributos que no forman parte de ninguna clave
dependen de forma completa de la clave principal. Es decir que no existen
dependencias parciales. (Todos los atributos que no son clave principal deben
depender únicamente de la clave principal).
En otras palabras podríamos decir que la
segunda forma normal está basada en el concepto de dependencia completamente
funcional. Una dependencia funcional 
es completamente funcional si al eliminar
los atributos A de X significa que la dependencia no es mantenida, esto es que 
.
Una dependencia funcional es una dependencia parcial si hay
algunos atributos 
que pueden ser eliminados de X y la
dependencia todavía se mantiene, esto es 
.
es completamente funcional si al eliminar
los atributos A de X significa que la dependencia no es mantenida, esto es que .
Una dependencia funcional es una dependencia parcial si hay
algunos atributos que pueden ser eliminados de X y la
dependencia todavía se mantiene, esto es .
Por ejemplo {DNI, ID_PROYECTO} 
HORAS_TRABAJO (con el DNI de un
empleado y el ID de un proyecto sabemos cuántas horas de trabajo por semana
trabaja un empleado en dicho proyecto) es completamente dependiente dado que ni
DNI HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la
dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO
es parcialmente dependiente dado que DNI NOMBRE_EMPLEADO mantiene la
dependencia.
HORAS_TRABAJO (con el DNI de un
empleado y el ID de un proyecto sabemos cuántas horas de trabajo por semana
trabaja un empleado en dicho proyecto) es completamente dependiente dado que ni
DNI HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la
dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO
es parcialmente dependiente dado que DNI NOMBRE_EMPLEADO mantiene la
dependencia.
Tercera
Forma Normal (3FN)
Artículo principal: Tercera forma
normal.
La tabla se encuentra en 3FN si es 2FN y si
no existe ninguna dependencia funcional transitiva entre los atributos que no
son clave.
Un ejemplo de este concepto sería que, una
dependencia funcional X->Y en un esquema de relación R es una dependencia
transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna
clave de R, donde se mantiene X->Z y Z->Y.
Por ejemplo, la dependencia SSN->DMGRSSN
es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que
la dependencia de DMGRSSN el atributo clave SSN es transitiva vía DNUMBER
porque las dependencias SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER
no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que
la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que
DNUMBER no es una clave de EMP_DEPT.
Formalmente, un esquema de relacion 
está en 3 Forma Normal Elmasri-Navathe,2 si
para toda dependencia funcional 
,
se cumple al menos una de las siguientes condiciones:
está en 3 Forma Normal Elmasri-Navathe,2 si
para toda dependencia funcional ,
se cumple al menos una de las siguientes condiciones:
1.
es superllave o clave.
es superllave o clave.
2.
es atributo primo de ; esto es, si es miembro de alguna
clave en .
es atributo primo de ; esto es, si es miembro de alguna
clave en .
Además el esquema debe cumplir
necesariamente, con las condiciones de segunda forma normal.
Forma
normal de Boyce-Codd (FNBC)
Artículo principal: Forma normal
de Boyce-Codd.
La tabla se encuentra en FNBC si cada
determinante, atributo que determina completamente a otro, es clave candidata.
Deberá registrarse de forma anillada ante la presencia de un intervalo seguido
de una formalizacion perpetua, es decir las variantes creadas, en una tabla no
se llegaran a mostrar, si las ya planificadas, dejan de existir.
Formalmente, un esquema de relación está en FNBC, si y sólo si, para toda
dependencia funcional válida en , se cumple
que
está en FNBC, si y sólo si, para toda
dependencia funcional válida en , se cumple
que
1.
es superllave o clave.
es superllave o clave.
De esta forma, todo esquema que cumple FNBC, está además en 3FN;
sin embargo, no todo esquema que cumple con 3FN, está en FNBC.
que cumple FNBC, está además en 3FN;
sin embargo, no todo esquema que cumple con 3FN, está en FNBC.
CICLO
DE VIDA DEL SISTEMA DE APLICACION DE BASE DE DATOS
- La base
de datos es un componente fundamental de un sistema de información. El
ciclo de vida de un sistema de información está ligado al ciclo de vida
del sistema de base de datos sobre el que se apoya. Al ciclo de vida de
los sistemas de información también se le denomina ciclo de vida de
desarrollo del software. Las etapas típicas del ciclo de vida de
desarrollo del software son: planificación, recolección y análisis de los
requisitos, diseño (incluyendo el diseño de la base de datos), creación de
prototipos, implementación, prueba, conversión y mantenimiento. Este ciclo
de vida hace énfasis en la identificación de las funciones que realiza la
empresa y en el desarrollo de las aplicaciones que lleven a cabo estas
funciones. Se dice que el ciclo de vida de desarrollo del software sigue
un enfoque orientado a funciones, ya que los sistemas se ven desde el
punto de vista de las funciones que llevan a cabo. Por esta razón, el
análisis estructurado hace énfasis en los diagramas de flujo de datos,
siguiendo el movimiento de los datos a través de una secuencia de
transformaciones, y refinando éstas a través de una serie de niveles. Lo
mismo ocurre en el diseño estructurado, que ve a un sistema como una
función que se descompone sucesivamente en niveles o subfunciones.
- Que el
sistema de base de datos esta ligado al tiempo de duracion del sistema de
base de datos del que se apoya.
- http://www3.uji.es/~mmarques/f47/apun/node66.html
RECOLECCION Y ANALISIS DE INFORMACION
- La recolección de datos se refiere al uso de una gran
diversidad detécnicas y herramientas que pueden ser utilizadas por el
analista para desarrollar los sistemas
de información, los cuales pueden ser la entrevistas,
la encuesta, el cuestionario, la observación, eldiagrama de flujo y el diccionario de datos.
- Un
analista utiliza la recolecciòn de datos para un solo trabajo, por ejemplo
si quiero hablar sobre la comutaciòn,necesito hacer una recolecciòn de
informaciòn, tener varios puntos de vista.
- http://www.monografias.com/trabajos12/recoldat/recoldat.shtml
"El diseño de bases de datos es el proceso por el que
se determina la organización de una base de datos, incluidos su estructura,
contenido y las aplicaciones que se han de desarrollar. Durante mucho tiempo,
el diseño de bases de datos fue considerado una tarea para expertos: más un
arte que una ciencia. Sin embargo, se ha progresado mucho en el diseño de bases
de datos y éste se considera ahora una disciplina estable, con métodos y
técnicas propios. Debido a la creciente aceptación de las bases de datos por
parte de la industria y el gobierno en el plano comercial, y a una variedad de
aplicaciones científicas y técnicas, el diseño de bases de datos desempeña un
papel central en el empleo de los recursos de información en la mayoría de las
organizaciones. El diseño de bases de datos ha pasado a constituir parte de la
formación general de los informáticos, en el mismo nivel que la capacidad de
construir algoritmos usando un lenguaje de programación convencional."
Un gestor de base de datos o sistema de gestión de base de
datos (SGBD o DBMS) es un software que permite introducir, organizar y
recuperar la información de las bases de datos; en definitiva, administrarlas.
Existen distintos tipos de gestores de bases de datos: relacional, jerárquico,
red,... El modelo relacional es el utilizado por casi todos los gestores de
bases de datos para PC´s. El modelo relacional (SGBDR) es un software que
almacena los datos en forma de tablas
Características Generales de los Sistemas Gestores de B.D.
Aunque hay multitud de aplicaciones para la Gestión de Bases de Datos diferentes en características y precios, podemos encontrar aspectos comunes en todos ellos:
• Aceptan definiciones de esquemas y vistas (definición de diferentes bases de datos).
• Manipulan los datos siguiendo las órdenes de los usuarios.
• Cuidan que se respete la seguridad e integridad de los datos.
• Permiten definir usuarios y las restricciones de acceso para cada uno de ellos.
• Controlan la concurrencia y las operaciones asociadas a la recuperación de los fallos.
Características Generales de los Sistemas Gestores de B.D.
Aunque hay multitud de aplicaciones para la Gestión de Bases de Datos diferentes en características y precios, podemos encontrar aspectos comunes en todos ellos:
• Aceptan definiciones de esquemas y vistas (definición de diferentes bases de datos).
• Manipulan los datos siguiendo las órdenes de los usuarios.
• Cuidan que se respete la seguridad e integridad de los datos.
• Permiten definir usuarios y las restricciones de acceso para cada uno de ellos.
• Controlan la concurrencia y las operaciones asociadas a la recuperación de los fallos.
TRANSFORMACIÓN AL MODELO DE DATOS
*Es innegable que la gestión y la explotación subsiguiente de los registros que contienen datos, y, como consecuencia, información, depende de las herramientas existentes en el campo de la gestión de la información, por una parte, y del cuerpo teórico de la ciencia de la información, por otra. La explotación satisfactoria de esta información, de la misma forma, demanda experiencia en dos áreas de conocimiento: en las técnicas de recuperación de información y en el estudio de las necesidades de los usuarios.
*Para transformar al modelo de datos se debe a la forma de la información y la necesidad del usuario.
* http://tramullas.com/documatica/2-8.html
*Es innegable que la gestión y la explotación subsiguiente de los registros que contienen datos, y, como consecuencia, información, depende de las herramientas existentes en el campo de la gestión de la información, por una parte, y del cuerpo teórico de la ciencia de la información, por otra. La explotación satisfactoria de esta información, de la misma forma, demanda experiencia en dos áreas de conocimiento: en las técnicas de recuperación de información y en el estudio de las necesidades de los usuarios.
*Para transformar al modelo de datos se debe a la forma de la información y la necesidad del usuario.
* http://tramullas.com/documatica/2-8.html
El diseño de una base de datos se descompone en
tres etapas: diseño conceptual, lógico y físico. La etapa del diseño lógico es
independiente de los detalles de implementación y dependiente del tipo de SGBD
que se vaya a utilizar. La salida de esta etapa es el esquema lógico global y
la documentación que lo describe. Todo ello es la entrada para la etapa que
viene a continuación, el diseño físico.
Mientras que en el diseño lógico se especifica qué
se guarda, en el diseño físico se especifica cómo se guarda. Para ello, el
diseñador debe conocer muy bien toda la funcionalidad del SGBD concreto que se
vaya a utilizar y también el sistema informático sobre el que éste va a
trabajar. El diseño físico no es una etapa aislada, ya que algunas decisiones
que se tomen durante su desarrollo, por ejemplo para mejorar las prestaciones,
pueden provocar una reestructuración del esquema lógico.
Metodología de diseño físico para bases de datos
relacionales
El objetivo de esta etapa es producir una
descripción de la implementación de la base de datos en memoria secundaria.
Esta descripción incluye las estructuras de almacenamiento y los métodos de
acceso que se utilizarán para conseguir un acceso eficiente a los datos.
El diseño físico se divide de cuatro fases, cada
una de ellas compuesta por una serie de pasos:
Traducir el esquema lógico global para el SGBD
específico. Diseñar las relaciones base para el SGBD específico. Diseñar las
reglas de negocio para el SGBD específico. Diseñar la representación física.
Analizar las transacciones. Escoger las organizaciones de ficheros. Escoger los
índices secundarios. Considerar la introducción de redundancias controladas.
Estimar la necesidad de espacio en disco. Diseñar los mecanismos de seguridad.
Diseñar las vistas de los usuarios. Diseñar las reglas de acceso. Monitorizar y
afinar el sistema. Traducir el esquema lógico global
La primera fase del diseño lógico consiste en
traducir el esquema lógico global en un esquema que se pueda implementar en el
SGBD escogido. Para ello, es necesario conocer toda la funcionalidad que éste
ofrece. Por ejemplo, el diseñador deberá saber:
Si el sistema soporta la definición de claves
primarias, claves ajenas y claves alternativas. Si el sistema soporta la
definición de datos requeridos (es decir, si se pueden definir atributos como
no nulos). Si el sistema soporta la definición de dominios. Si el sistema
soporta la definición de reglas de negocio. Cómo se crean las relaciones base.
GENERACION
DE UN SISTEMA DE BASE DE DATOS
- Es
un sistema que almacena datos que estàn relacionados, es un repositorio en
donde guardamos informaciòn integrada que podemos almacenar y recuperar,
Se dice que los sistemas de bases de datos tienen sus raíces en el
proyecto estadounidense Apolo de mandar al hombre a la luna, en los años
sesenta. En aquella época, no había ningún sistema que permitiera
gestionar la inmensa cantidad de información que requería el proyecto.
- Actualmente
la función más importante de los sistemas de base de datos consiste en
proporcionar la materia prima necesaria a los sistemas de información.
No hay comentarios:
Publicar un comentario