Sistema de gestión de base de datos
De Wikipedia, la enciclopedia libre
Saltar a navegación, búsqueda
Los sistemas de gestión de base de datos (SGBD); (en inglés: DataBase Management System, abreviado DBMS) son un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan.
Contenido[ocultar]
1 Propósito
2 Objetivos
3 Ventajas
Propósito [editar]
El propósito general de los sistemas de gestión de base de datos es el de manejar de manera clara, sencilla y ordenada un conjunto de datos que posteriormente se convertirán en información relevante para una organización.
Objetivos [editar]
Existen distintos objetivos que deben cumplir los SGBD:
Abstracción de la información. Los SGBD ahorran a los usuarios detalles acerca del almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se hace transparente al usuario. Así, se definen varios niveles de abstracción.
Independencia. La independencia de los datos consiste en la capacidad de modificar el esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella.
Consistencia. En aquellos casos en los que no se ha logrado eliminar la redundancia, será necesario vigilar que aquella información que aparece repetida se actualice de forma coherente, es decir, que todos los datos repetidos se actualicen de forma simultánea. Por otra parte, la base de datos representa una realidad determinada que tiene determinadas condiciones, por ejemplo que los menores de edad no pueden tener licencia de conducir. El sistema no debería aceptar datos de un conductor menor de edad. En los SGBD existen herramientas que facilitan la programación de este tipo de condiciones.
Seguridad. La información almacenada en una base de datos puede llegar a tener un gran valor. Los SGBD deben garantizar que esta información se encuentra segura de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categorías de permisos.
Manejo de Transacciones. Una Transacción es un programa que se ejecuta como una sola operación. Esto quiere decir que luego de una ejecución en la que se produce una falla es el mismo que se obtendría si el programa no se hubiera ejecutado. Los SGBD proveen mecanismos para programar las modificaciones de los datos de una forma mucho más simple que si no se dispusiera de ellos.
Tiempo de respuesta. Lógicamente, es deseable minimizar el tiempo que el SGBD tarda en darnos la información solicitada y en almacenar los cambios realizados.
Ventajas [editar]
Proveen facilidades para la manipulación de grandes volúmenes de datos. (Ver Objetivos) Entre éstas:
Simplifican la programación de equipos de consistencia.
Manejando las políticas de respaldo adecuadas, garantizan que los cambios de la base serán siempre consistentes sin importar si hay errores correctamente, etc.
Organizan los datos con un impácto mínimo en el código de los programas.
Bajan drásticamente los tiempos de desarrollo y aumentan la calidad del sistema desarrollado si son bien explotados por los desarrolladores.
Usualmente, proveen interfaces y lenguajes de consulta que simplifican la recuperación de los datos.
Inconvenientes [editar]
Típicamente,es necesario disponer de una o más personas que administren de la base de datos, en la misma forma en que suele ser necesario en instalaciones de cierto porte disponer de una o más personas que administren de los sistemas operativos. Esto puede llegar a incrementar los costos de operación en una empresa. Sin embargo hay que balancear este aspecto con la calidad y confiabilidad del sistema que se obtiene.
Si se tienen muy pocos datos que son usados por un único usuario por vez y no hay que realizar consultas complejas sobre los datos, entonces es posible que sea mejor usar una planilla de cálculo.
Complejidad: los software muy complejos y las personas que vayan a usarlo deben tener conocimiento de las funcionalidades del mismo para poder aprovecharlo al máximo.
Tamaño: la complejidad y la gran cantidad de funciones que tienen hacen que sea un software de gran tamaño, que requiere de gran cantidad de memoria para poder correr.
Coste del hardware adicional: los requisitos de hardware para correr un SGBD por lo general son relativamente altos, por lo que estos equipos pueden llegar a costar gran cantidad de dinero
martes, 22 de septiembre de 2009
tendencias futuras
La explotación efectiva de la información dará ventaja competitiva a las organizaciones.
Las bases de datos orientadas a objetos empleadas para diseño y manufactura asistida por computadora CAD/CAM serán utilizados a un mismo nivel que las Bases se Datos relacionales de la actualidad.
Los lenguajes de consulta (SQL) permitirán el uso del lenguaje natural para solicitar información de la Base de Datos, haciendo más rápido y fácil su manejo.
Las bases de datos orientadas a objetos empleadas para diseño y manufactura asistida por computadora CAD/CAM serán utilizados a un mismo nivel que las Bases se Datos relacionales de la actualidad.
Los lenguajes de consulta (SQL) permitirán el uso del lenguaje natural para solicitar información de la Base de Datos, haciendo más rápido y fácil su manejo.
relacion entre los datos
Sistema de administración de bases de datos, que almacena información en tablas y realiza búsquedas utilizando los datos de columnas especificadas de una tabla para encontrar datos adicionales en otra tabla
En una base de datos relacional, las filas representan registros (conjunto de datos acerca de elementos separados) y las columnas representan campos (atributos particulares de un registro). Al realizar las búsquedas, una base de datos relacional hace coincidir la información de un campo de una tabla con información en el campo correspondiente de otra tabla y con ello produce una tercera tabla que combina los datos solicitados de ambas tablas.
Relación Muchos A Uno
PROY- GERENTE (los proyectos designan a los gerentes)
DEPTO-EMP (los empleados designan a los departamento)
EMP-DEPEN (los dependientes designan a los empleados)
De estas tres, la última implica un tipo de entidad débil (DEPENDIENTE) y las otras dos implican sólo tipos de entidades regulares. El ejemplo DEPTO-EMP no provoca la introducción de relaciones nuevas. En vez de ello, basta introducir una clave ajena en la relación correspondiente al lado de "muchos" de la interrelación (EMP), que haga referencia a la relación correspondiente al lado "uno" (DEPTO).
La interrelación entre un tipo de entidad débil y el tipo de entidad del cual depende es por su puesto una interrelación de muchos a uno.
Relación uno a uno
No son muy frecuentes en cualquier caso en prácticas. Estas se manejan exactamente en el mismo modo que las interrelaciones mucho a uno.
Relaciones muchos a muchos
Las interrelaciones de muchos a muchos (o de muchos a muchos a muchos, etc) mostradas en el ejemplo siguiente:
PROY-TRABAJO (asocia empleados y proyectos)
PROV-PARTE (asocia proveedores y partes)
PROV_PARTE_PROY (asocia proveedores, partes y proyectos)
En una base de datos relacional, las filas representan registros (conjunto de datos acerca de elementos separados) y las columnas representan campos (atributos particulares de un registro). Al realizar las búsquedas, una base de datos relacional hace coincidir la información de un campo de una tabla con información en el campo correspondiente de otra tabla y con ello produce una tercera tabla que combina los datos solicitados de ambas tablas.
Relación Muchos A Uno
PROY- GERENTE (los proyectos designan a los gerentes)
DEPTO-EMP (los empleados designan a los departamento)
EMP-DEPEN (los dependientes designan a los empleados)
De estas tres, la última implica un tipo de entidad débil (DEPENDIENTE) y las otras dos implican sólo tipos de entidades regulares. El ejemplo DEPTO-EMP no provoca la introducción de relaciones nuevas. En vez de ello, basta introducir una clave ajena en la relación correspondiente al lado de "muchos" de la interrelación (EMP), que haga referencia a la relación correspondiente al lado "uno" (DEPTO).
La interrelación entre un tipo de entidad débil y el tipo de entidad del cual depende es por su puesto una interrelación de muchos a uno.
Relación uno a uno
No son muy frecuentes en cualquier caso en prácticas. Estas se manejan exactamente en el mismo modo que las interrelaciones mucho a uno.
Relaciones muchos a muchos
Las interrelaciones de muchos a muchos (o de muchos a muchos a muchos, etc) mostradas en el ejemplo siguiente:
PROY-TRABAJO (asocia empleados y proyectos)
PROV-PARTE (asocia proveedores y partes)
PROV_PARTE_PROY (asocia proveedores, partes y proyectos)
bases de datos distribuidas
ENFOQUE RELACIONAL:
ENFOQUE RELACIONAL:
Casi todos los productos de base de datos desarrollados años recientes se basan en lo que se conoce como enfoque relacional. La cuestión es que ningún sistema actual maneja el modelo relacional en todos sus aspectos (varios se acercan, pero la mayor parte fallan en algún detalle u otro; en los dominios, o si no en alguna otra cosa).
Cumplen las siguientes leyes básicas:
A. Generalmente, contendrá muchas tablas.
B. Una tabla sólo contiene un número fijo de campos.
C. El nombre de los campos de una tabla es distinto.
D. Cada registro y de la es único.
E. El orden de los registros y de los campos no está determinado
F. Para cada campo existe un conjunto de valores posible.
Requisitos que han de tener las tablas
El primer paso para crear una base de datos, es planificar el tipo de información que se quiere almacenar en la misma, teniendo en cuenta dos aspectos: la información disponible y la información que necesitamos. La planificación de la estructura de la base de datos, en particular de las tablas, es vital para la gestión efectiva de la misma. El diseño de la estructura de una tabla consiste en una descripción de cada uno de los campos que componen el registro y los valores o datos que contendrá cada uno de esos campos. Los campos son los distintos tipos de datos que componen la tabla, por ejemplo: nombre, apellido, domicilio. La definición de un campo requiere: el nombre del campo, el tipo de campo, el ancho del campo, etc.
Casi todos los productos de base de datos desarrollados años recientes se basan en lo que se conoce como enfoque relacional. La cuestión es que ningún sistema actual maneja el modelo relacional en todos sus aspectos (varios se acercan, pero la mayor parte fallan en algún detalle u otro; en los dominios, o si no en alguna otra cosa).
Cumplen las siguientes leyes básicas:
A. Generalmente, contendrá muchas tablas.
B. Una tabla sólo contiene un número fijo de campos.
C. El nombre de los campos de una tabla es distinto.
D. Cada registro y de la es único.
E. El orden de los registros y de los campos no está determinado
F. Para cada campo existe un conjunto de valores posible.
Requisitos que han de tener las tablas
El primer paso para crear una base de datos, es planificar el tipo de información que se quiere almacenar en la misma, teniendo en cuenta dos aspectos: la información disponible y la información que necesitamos. La planificación de la estructura de la base de datos, en particular de las tablas, es vital para la gestión efectiva de la misma. El diseño de la estructura de una tabla consiste en una descripción de cada uno de los campos que componen el registro y los valores o datos que contendrá cada uno de esos campos. Los campos son los distintos tipos de datos que componen la tabla, por ejemplo: nombre, apellido, domicilio. La definición de un campo requiere: el nombre del campo, el tipo de campo, el ancho del campo, etc.
ENFOQUE JERARQUIZADO:
El enfoque jerarquizado (superior que tiene una elevada categoría en una organización) es una base de datos que se compone de un conjunto de arboles ordenados, también se dice que es un conjunto formado por múltiples ocurrencias de un solo tipo de árbol.
Es usado para la representación lógica de los datos. Los archivos son organizados en jerarquías, y normalmente cada uno de ellos se corresponde con una de las entidades de la base de datos. Los árboles jerárquicos se representan de forma invertida, con la raíz hacia arriba y las hojas hacia abajo como se muestra en la representación.
caracteristicas de la relacion entre los datos
Relación Muchos A UnoEjemplosPROY- GERENTE (los proyectos designan a los gerentes)DEPTO-EMP (los empleados designan a los departamento)EMP-DEPEN (los dependientes designan a los empleados)De estas tres, la última implica un tipo de entidad débil (DEPENDIENTE) y las otras dos implican sólo tipos de entidades regulares. El ejemplo DEPTO-EMP no provoca la introducción de relaciones nuevas. En vez de ello, basta introducir una clave ajena en la relación correspondiente al lado de "muchos" de la interrelación (EMP), que haga referencia a la relación correspondiente al lado "uno" (DEPTO).La interrelación entre un tipo de entidad débil y el tipo de entidad del cual depende es por su puesto una interrelación de muchos a uno.
Relación uno a unoNo son muy frecuentes en cualquier caso en prácticas. Estas se manejan exactamente en el mismo modo que las interrelaciones mucho a uno.
Relaciones mucho a muchoLas interrelaciones de muchos a muchos (o de muchos a muchos a muchos, etc) mostradas en el ejemplo siguiente:PROY-TRABAJO (asocia empleados y proyectos)PROV-PARTE (asocia proveedores y partes)PROV_PARTE_PROY (asocia proveedores, partes y proyectos)ESTRUCTURA DE PARTES (asocia a partes a partes)Cada una de estas interrelaciones también corresponde a una relación base. Por tanto, introducimos otras cuatro relaciones base correspondientes a estas cuatro interrelaciones. Como en el caso de las interrelaciones de muchos a muchos, resulta que podemos escoger. Una posibilidad es tomar la combinación de la clave ajena y la "clave" de la entidad del diagrama E/R. O bien, podríamos introducir un atributo nuevo no compuesto que sirva como clave primaria.
Relación uno a unoNo son muy frecuentes en cualquier caso en prácticas. Estas se manejan exactamente en el mismo modo que las interrelaciones mucho a uno.
Relaciones mucho a muchoLas interrelaciones de muchos a muchos (o de muchos a muchos a muchos, etc) mostradas en el ejemplo siguiente:PROY-TRABAJO (asocia empleados y proyectos)PROV-PARTE (asocia proveedores y partes)PROV_PARTE_PROY (asocia proveedores, partes y proyectos)ESTRUCTURA DE PARTES (asocia a partes a partes)Cada una de estas interrelaciones también corresponde a una relación base. Por tanto, introducimos otras cuatro relaciones base correspondientes a estas cuatro interrelaciones. Como en el caso de las interrelaciones de muchos a muchos, resulta que podemos escoger. Una posibilidad es tomar la combinación de la clave ajena y la "clave" de la entidad del diagrama E/R. O bien, podríamos introducir un atributo nuevo no compuesto que sirva como clave primaria.
Suscribirse a:
Entradas (Atom)
