Qu son las bases de datos?

Una base de datos es un almacn que nos permite guardar grandes cantidades de informacin de forma organizada para que luego podamos encontrar y utilizar fcilmente. A continuacin te presentamos una gua que te explicar el concepto y caractersticas de las bases de datos.

Se define una base de datos como una serie de datos organizados y relacionados entre s, los cuales son recolectados y explotados por los sistemas de informacin de una empresa o negocio en particular.

ENTIDAD:
En bases de datos, una entidad es la representacin de un objeto o concepto del mundo real que se describe en una base de datos. Una entidad se describe en la estructura de la base de datos empleando un modelo de datos. Por ejemplo, nombres de entidades pueden ser: Alumno, Empleado, Artculo, etc. Cada entidad est constituida por uno o ms atributos. Por ejemplo, la entidad "Alumno" podra tener los atributos: nombre, apellido, ao de nacimiento, etc. En el modelo de entidad-relacin se emplean dos tipos de entidades: entidad fuerte y entidad dbil. Las entidades fuertes tienen atributos claves, en tanto las entidades dbiles no tienen atributos claves propios.

TABLA
Tabla en las bases de datos, se refiere al tipo de modelado de datos, donde se guardan los datos recogidos por un programa. Su estructura general se asemeja a la vista general de un programa de Hoja de clculo. Las tablas se componen de dos estructuras: Registro: es cada una de las filas en que se divide la tabla. Cada registro contiene datos de los mismos tipos que los dems registros. Ejemplo: en una tabla de nombres y direcciones, cada fila contendr un nombre y una direccin. Campo: es cada una de las columnas que forman la tabla. Contienen datos de tipo diferente a los de otros campos. En el ejemplo anterior, un campo contendr un tipo de datos nico, como una direccin, o un nmero de telfono, un nombre, etc. A los campos se les puede asignar, adems, propiedades especiales qu afectan a los e registros insertados. El campo puede ser definido como ndice o autoincrementable, lo cual permite que los datos de ese campo cambien solos o sean el principal indicar a la hora de ordenar los datos contenidos.

Cada tabla creada debe tener un nombre nico en la cada Base de Datos, hacindola accesible mediante su nombre o su seudnimo (Alias) (dependiendo del tipo de base de datos elegida). La estructura de las tablas viene dado por la forma de un archivo plano, los cuales en un inicio se componan de un modo similar. TUPLA En algunos lenguajes y especialmente en la teora de bases de datos, una tupla se define como una funcin finita que mapea (asocia unvocamente) los nombres con algunos valores. Su propsito es el mismo que se defini en las matemticas. Un pequeo ejemplo puede ilustrar esto: ( jugador : "Luis", puntuacin : 25 ) En este caso se trata de una funcin que mapea el campo "jugador" con la cadena "Luis" y el campo "puntuacin" al nmero entero 25. Es de notar que el orden de los componentes no es relevante, de esta forma la misma tupla puede ser re-escrita como: ( puntuacin : 25, jugador : "Luis" ). En un modelo relacional tal y como se define en las tuplas, se suele representar una proposicin simple, en este caso existe un jugador con el nombre "Luis" y que posee una puntuacin de 25. En los lenguajes de programacin las tuplas se suelen usar para formar estructuras de datos. Por ejemplo, lo siguiente podra ser una definicin de una estructura de datos para unalista enlazada: ( value : 16, previous-node : 1174782, next-node : 1174791 ) RELACION Una relacin o vnculo entre dos o ms entidades describe algna interaccin entre las mismas. Por ejemplo, una relacin entre una entidad "Empleado" y una entidad "Sector" podra ser "trabaja_en", porque el empleado trabaja en un sector determinado.

Las relaciones se describen en la estructura de la base de datos empleando un modelo de datos.

Las relaciones son muy empleadas en los modelos de bases de datos relacional y afines.

En SQL las relaciones son llamadas tablas.

TIPOS DE RELACIONES Se pueden distinguir tres tipos de relaciones:

Relacin Uno a Uno : Cuando un registro de una tabla slo puede estar relacionado con un nico registro de la otra tabla y viceversa . Por ejemplo: tenemos dos tablas una con los datos de diferentes poblaciones y otra con una lista de Alcaldes, una poblacin slo puede tener un alcalde, y un alcalde lo ser nicamente de una poblacin. Relacin Uno a Varios: Cuando un registro de una tabla (tabla secundaria) slo puede estar relacionado con un nico registro de la otra tabla (tabla principal) y un registro de la otra tabla(tabla principal) puede tener ms de un registro relacionado en la primera tabla (tabla secundaria). Por ejemplo: tenemos dos tablas una con los datos de diferentes poblaciones y ot a con r los habitantes, una poblacin puede tener ms de un habitante, pero un habitante pertenecer (estar empadronado) en una nica poblacin. Relacin Varios a Varios: Cuando un registro de una tabla puede estar relacionado con ms de un registro de l a otra tabla y viceversa. Por ejemplo: tenemos dos tablas una con los datos de clientes y otra con los artculos que se venden en la empresa, una cliente podr realizar un pedido con varios artculos, y un artculo podr ser vendido a ms de un cliente. Las relaciones varios a varios se suelen representar definiendo una tabla intermedia entre las dos tablas. Siguiendo el ejemplo anterior sera definir una tabla lineas de pedido relacionada con clientes y con artculos.

Arquitectura base de datos

Los usuarios no tienen porque conocer como estn organizados y almacenados los datos. Por este motivo una base de datos debe presentar los datos de forma que el usuario pueda interpretarlos y modificarlos. Evidentemente esto no lo podemos aplicar a un inform tico que necesite saber donde se encuentran fsicamente los datos para poder tratarlos. Podemos destacar tres niveles principales segn la visin y la funcin que realice el usuario sobre la base de datos:

Nivel Interno: es el nivel ms cercano al almacenamiento fsico de los datos. Permite escribirlos tal y como estn almacenados en el ordenador. En este nivel se disean los archivos que contienen la informacin, la ubicacin de los mismos y su organizacin, es decir se crean los archivos de configuracin. Nivel conceptual: En este nivel se representan los datos que se van a utilizar sin tener en cuenta aspectos como lo que representamos en el nivel interno. Nivel externo: es el ms cercano al usuario. En este nivel se describen los datos o parte de los datos que ms interesan a los usuarios.

y y

Estos tres niveles de visin de usuarios los proporcionan los sistemas gestores de base de datos (ya veremos ms adelante que significa esto). Una base de datos especifica tiene un nico nivel interno y un n ico nivel conceptual pero puede tener varios niveles externos.

ANSI El estndar ANSI/SPARC. El objetivo principal de la arquitectura ANSI/SPARC es definir un SGBD con el mximo grado de independencia, separando las aplicaciones de usuario y la base de datos fsica. Para ello se utilizan tres niveles de abstraccin conocidos como interno, conceptual y externo. 1. El nivel interno es el ms cercano a la mquina. Es una representacin a bajo nivel de la BD en la que se define la forma en la que los datos se almacenan fsicamente en la mquina. Se definen caractersticas como los dispositivos en donde se almacenan los datos, el espacio que se reserva, las estrategias de acceso, la creacin de ficheros de ndices, etc. Es dependiente de la mquina en que se vaya a instalar la BD, del sistema operativo que exista, etc. 2. El nivel conceptual tiene un esquema conceptual, que describe la estructura de los datos que van a ser almacenados en la base de datos. El esquema conceptual esconde los detalles del almacenamiento fsico y se concentra en describir entidades, tipos de datos, relaciones,operaciones de usuario y restricciones . 3. El nivel externo o nivel de vista incluye varios esquemas externos o vistas de usuario. Cada esquema externo describe la parte de la base de datos en la que est interesado un grupo de usuarios en particular y esconde el resto de la base de datos para esos usuarios. La informacin se manipula sin saber cmo est almacenada internamente (nivel interno) ni su organizacin (nivel conceptual). Existirn muchas vistas externas distintas, cada una formada por una representacin ms o menos abstracta (registros y campos lgicos) de alguna parte de la base de datos total, y existir slo una vista conceptual formada por una representacin igualmente abstracta de la base de datos en su totalidad (hay que recordar que a la mayora de los usuarios no les interesar toda la base de datos, sino slo una porcin limitada de ella). De manera similar, habr slo una vista interna, la cual representar a toda la base de datos tal como est almacenada fsicamente. El Nivel Externo

El nivel externo es el ms cercano a los usuarios, es decir, es el que se ocupa de la forma en la que los usuarios perciben los datos. El nivel externo es del usuario individual. Estos usuarios pueden ser o bien 3 programadores de aplicaciones o usuarios finales con conocimientos muy variables de informtica. El administrador de la base de datos es un caso especial (tambin debe interesarse por los dems niveles de la arquitectura). Cada usuario dispone de un lenguaje: En el caso del programador de aplicaciones, dicho lenguaje ser o bien un lenguaje de programacin convencional, o bien un lenguaje de cuarta generacin (4GL) especfico para el sistema en cuestin. Para el usuario final ser o bien un lenguaje de consulta, o algn lenguaje de aplicacin especial, quiz manejado mediante formas o mens, adaptado a los requerimientos de ese usuario y apoyado por algn programa de aplicacin en lnea (cuya funcin es servir a un usuario final que tiene acceso a la base de datos desde una terminal en lnea). El aspecto importante de todos estos lenguajes es que deben incluir un sublenguaje de datos, es decir, un subconjunto del lenguaje total que se ocupe de manera especfica de los objetos y operaciones de la base de datos. Se dice que el sublenguaje de datos (DSL data sublanguage) est embebido (o inmerso) dentro del lenguaje anfitrin correspondiente. Este ltimo se encarga de varios aspectos no relacionados con la base de datos, como por ejemplo variables locales (temporales), operaciones de clculo, lgica condicional, etc. Un sistema dado puede permitir el empleo de varios lenguajes anfitriones y varios sublenguajes de datos. Un sublenguaje de datos en particular cuyo uso es posible en casi todos los sistemas relacionales actuales es el lenguaje SQL. En principio, cualquier sublenguaje de datos es en realidad una combinacin de por lo menos dos lenguajes subordinados: un lenguaje de definicin de datos (DDL data definition language), con el cual es posible definir o declarar los objetos de la base de datos, y un lenguaje de manipulacin de datos (DML, data manipulation language) con el que es posible manipular o procesar dichos objetos. Como ya se ha dicho, al usuario individual (en general), slo le interesar una porcin de la base de datos total; por aadidura, la forma como ese usuario percibe dicha porcin casi siempre ser un tanto abstracta comparada con el almacenamiento fsico de los datos. El trmino ANSI/SPARC para la vista individual de un usuario es vista externa. As, una vista externa es el contenido de la base de datos tal como lo percibe algn usuario determinado (es decir, para ese usuario la vista externa es la base de datos). Por ejemplo, un usuario del departamento de personal podra contemplar la base de datos como un conjunto de ocurrencias de registros de departamento unido a un conjunto de ocurrencias de registros de proveedor y de parte vistas por los usuarios del departamento de compras). Toda vista externa se define mediante un esquema externo, que consiste bsicamente en definiciones de cada uno de los diversos tipos de registros externos en esa vista externa. El esquema externo se escribe con la porcin DDL del sublenguaje de datos del usuario (por ello se le denomina a ese DDL en ocasiones como DDL externo). Por ejemplo, el tipo de registro externo de empleado puede definirse como un campo de nmero de empleado de seis caracteres unido a un campo de salario de cinco dgitos, etc. Adems, debe haber una definicin de la correspondencia entre el esquema externo y el esquema conceptual subyacente. El Nivel Conceptual El nivel conceptual es un nivel de mediacin entre el nivel interno y externo. La vista conceptual es una representacin de toda la informacin contenida en la base de datos, tambin (como en el caso de una vista externa) en una forma un tanto abstracta si se compara con el almacenamiento fsico de los datos.

Adems, puede ser muy diferente de la forma como percibe los datos cualquier usuario individual. A grandes rasgos, la vista conceptual debe ser un panorama de los datos tal como son, y no como por fuerza los perciben los usuarios debido a las limitaciones del lenguaje o el equipo especficos utilizados, por ejemplo. La vista conceptual se compone de varias ocurrencias de varios tipos de registro conceptual. Por ejemplo, puede estar formada por un conjunto de ocurrencias de registros de departamento unido un conjunto de ocurrencias de registro de empleado y a un conjunto de ocurrencias de registros de proveedor y a un conjunto de ocurrencia de registros de parte... Un registro conceptual no es por necesidad idntico a un registro externo, por un lado, ni a un registro almacenado, por el otro. La vista conceptual se define mediante un esquema conceptual, el cual incluye definiciones de cada uno de los tipos de registro conceptual. El esquema conceptual se escribe utilizando otro lenguaje de definicin de datos, el DDL conceptual. Si ha de lograrse la independencia de los datos, esas definiciones en DDL conceptual no debern implicar consideraciones de estructura de almacenamiento o de tcnica de acceso. Si el esquema conceptual se hace en verdad independiente de los datos de esta manera, entonces los esquemas externos, definidos en trminos del esquema conceptual, sern por fuerza tambin independientes de los datos. As pues, la vista conceptual es una vista del contenido total de la base de datos, y el esquema conceptual es una definicin de esa vista. No obstante, sera engaoso sugerir que el esquema conceptual es slo un conjunto de definiciones similar a las sencillas definiciones de registros encontradas por ejemplo en un programa en Cobol. Es de esperar que las definiciones en el esquema conceptual incluyan muchas caractersticas ms, como son las verificaciones de seguridad y de integridad. Algunos expertos podran llegar a sugerir que el objetivo primordial del esque conceptual es describir la empresa en su totalidad (no slo los datos en s, sino tambin la forma como se utilizan: cmo fluyen de un punto a otro dentro de la empresa, qu se hace con ellos en cada punto, qu controles de auditora o de otro tipo deben aplicarse en cada punto, etc. Debe hacerse hincapi en que en ningn sistema actual es posible mantener realmente un nivel conceptual que se aproxime siquiera a ese grado de complejidad; en casi todos los sistemas existentes el esquema conceptual no es mucho ms que una simple unin de todos los esquemas externos individuales, con la posible adicin de algunas verificaciones sencillas de integridad y seguridad. Con todo, parece evidente que los sistemas del futuro llegarn a mantener niveles conceptuales mucho ms complejos.

El Nivel Interno El tercer nivel de la arquitectura es el nivel interno. La vista interna es una representacin de bajo nivel de toda la base de datos; se compone de varias ocurrencias de varios tipos de registro interno. Este ltimo trmino es el que utiliza ANSI/SPARC para referirse a la construccin que hemos estado llamando registro almacenado. La vista interna, por tanto, todava est a un paso del nivel fsico, ya que no manejo registros fsicos (llamados tambin pginas o bloques), ni otras consideraciones especficas de los dispositivos como son los tamaos de cilindros o de pistas. La vista interna se define mediante el esquema interno, el cual no slo define los diversos tipos de registros almacenados sino tambin especifica que ndices hay, cmo se representan los campos almacenados, en qu secuencia fsica se encuentran los registros almacenados, etc. El esquema interno se escribe con otro lenguaje ms de definicin de datos, el DDL interno. En algunas situaciones excepcionales podra permitirse a los programas de aplicacin operar directamente en el nivel interno en vez de hacerlo en el nivel externo. Esta prctica no es recomendable ya que representa un riesgo para la seguridad (ya que pasan por alto las verificaciones de seguridad) y para la integridad (hace lo mismo), y el programa ser en extremo dependiente de los datos; sin embargo, en ciertos casos puede ser la

nica forma de obtener la funcin o desempeo deseados, del mismo modo como el usuario de un lenguaje de programacin de alto nivel puede verse obligado en ocasiones a descender al lenguaje ensamblador para satisfacer ciertos objetivos. Correspondencias, asociaciones o ligaduras (mappings) Para describir un mismo grupo de datos, un sistema puede gestionar varios niveles de esquemas, para lo cual el DBMS debe poder garantizar la transferencia de los datos desde el formato correspondiente de un nivel al formato correspondiente a otro nivel; este proceso se denomina transformacin de datos o mapping. Hay dos niveles de correspondencia en la arquitectura ANSI/SPARC: uno entre los niveles externo y conceptual del sistema, y otro entre los niveles conceptual e interno. La correspondencia conceptual/interna es la que existe entre las vista conceptual y la base de datos almacenada; especifica cmo se representan los registros y campos conceptuales en el nivel interno. Si se modifica la estructura de la base de datos almacenada (es decir, si se altera la definicin de la estructura de almacenamiento), la correspondencia conceptual/interna deber modificarse tambin de acuerdo con ello, para que no vare el esquema conceptual (el administrador de la base de datos se debe encargar de controlar tales modificaciones). Dicho de otra manera, los efectos de las alteraciones debern aislarse por debajo del nivel conceptual, a fin de conservar la independencia de los datos. La correspondencia externa/conceptual es la que existe entre una determinada vista externa y la vista conceptual. Las diferencias que pueden existir entre estos dos niveles son similares a las que pueden existir entre la vista conceptual y la base de datos almacenada. Por ejemplo, los campos pueden tener distintos tipos de datos, los nombres de los campos y los registros pueden diferir, pueden combinarse varios campos conceptuales para formar un solo campo externo (virtual), etc. Puede existir cualquier cantidad de vistas externas; cualquier nmero de usuarios puede compartir una determinada vista externa. Algunos sistemas permiten expresar la definicin de una vista externa en trminos de otras (de hecho, a travs de una correspondencia externa/externa), en vez de requerir siempre una definicin explcita de la correspondencia respecto al nivel conceptual, cosa que resulta til si existe una relacin muy grande entre varias vistas externas. Los sistemas relacionales en particular casi siempre permiten hacer esto.

MODELOS
Un modelo de base de datos o esquema de base de datos es la estructura o el formato de una base de datos, descrita en un lenguaje formal soportada por el sistema de gestin de bases de datos. En otras palabras, un "modelo de base de datos" es la aplicacin de un modelo de datos usado en conjuncin con un sistema de gestin de bases de datos. Los esquemas generalmente son almacenados en un diccionario de datos. Aunque un esquema se defina en un lenguaje de base de datos de texto, el trmino a menudo es usado para referirse a una representacin grfica de la estructura de la base de datos.

[editar]Visin

general

Un modelo de base de datos es una teora o especificacin que describe como una base de datos es estructurada y usada. Varios modelos han sido sugeridos. Modelos comunes:

     

Modelo jerrquico Modelo de red Modelo relacional Modelo entidad-relacin Modelo objeto-relacional Modelo de objeto

Un modelo de datos no es solamente un modo de estructurar datos, sino que tambin define el conjunto de las operaciones que pueden ser realizadas sobre los datos. El modelo relacional, por ejemplo, define operaciones como seleccin, proyeccin y unin. Aunque estas operaciones pueden no ser explcitas en un lenguaje de consultas particular, proveen las bases sobre las que stos son construidos. [editar]Modelos Varias tcnicas son usadas para modelar la estructura de datos. La mayor parte de sistemas de base de datos son construidos entorno a un modelo de datos particular, aunque sea cada vez ms comn para productos ofrecer el apoyo a ms de un modelo. Ya que cualquier varia puesta en prctica lgica modela fsica puede ser posible, y la mayor parte de productos ofrecern al usuario algn nivel de control en la sintona de la puesta en prctica fsica, desde las opciones que son hechas tienen un efecto significativo sobre el funcionamiento. Un ejemplo de esto es el modelo emparentado: todas las puestas en prctica serias del modelo emparentado permiten la creacin de ndices que proporcionan rpido acceso a filas en una tabla si conocen los valores de ciertas columnas. [editar]Modelo

de tabla

El modelo de tabla consiste en una serie nica, bidimensional de elementos de datos, donde todos los miembros de una columna dada son asumidos para ser valores similares, y todos los miembros de una fila son asumidos para ser relacionados el uno con el otro. Por ejemplo, columnas para el nombre y la contrasea que podra ser usada como una parte de una base de datos de seguridad de sistema. Cada fila tendra la contrasea especfica asociada con un usuario individual. Las columnas de la tabla a menudo tienen un tipo asociado con ellos, definindolos como datos de carcter, fecha o la informacin de tiempo, nmeros enteros, o nmeros de punto flotante. [editar]Modelo

jerrquico

En un modelo jerrquico, los datos son organizados en una estructura parecida a un rbol, implicando un eslabn solo ascendente en cada registro para describir anidar, y un campo de clase para guardar los registros en un orden particular en cada lista de mismo-nivel. Las estructuras jerrquicas fueron usadas extensamente en los primeros sistemas de gestin de

datos de unidad central, como el Sistema de Direccin de Informacin (IMS) por la IBM, y ahora describen la estructura de documentos XML. Esta estructura permite un 1:N en una relacin entre dos tipos de datos. Esta estructura es muy eficiente para describir muchas relaciones en el verdadero real; recetas, ndice, ordenamiento de prrafos/versos, alguno anid y clasific la informacin. Sin embargo, la estructura jerrquica es ineficaz para ciertas operaciones de base de datos cuando un camino lleno (a diferencia del eslabn ascendente y el campo de clase) tambin no es incluido para cada registro. Una limitacin del modelo jerrquico es su inhabilidad de representar manera eficiente la redundancia en datos. Los modelos de base de datos " el valor de atributo de entidad " como Caboodle por Swink estn basados en esta estructura. En la relacin Padre-hijo: El hijo slo puede tener un padre pero un padre puede tener mltiples hijos. Los padres e hijos son atados juntos por eslabones "indicadores" llamados. Un padre tendr una lista de indicadores de cada uno de sus hijos. [editar]Modelo

de red

El modelo de red (definido por la especificacin CODASYL) organiza datos que usan dos fundamental construcciones, registros llamados y conjuntos. Los registros contienen campos (que puede ser organizado jerrquicamente, como en el lenguaje COBOL de lenguaje de programacin). Los conjuntos (para no ser confundido con conjuntos matemticos) definen de uno a varios relaciones entre registros: un propietario, muchos miembros. Un registro puede ser un propietario en cualquier nmero de conjuntos, y un miembro en cualquier nmero de conjuntos. El modelo de red es una variacin sobre el modelo jerrquico, al grado que es construido sobre el concepto de mltiples ramas(estructuras de nivel inferior) emanando de uno o varios nodos (estructuras de nivel alto), mientras el modelo se diferencia del modelo jerrquico en esto las ramas pueden estar unidas a mltiples nodos. El modelo de red es capaz de representar la redundancia en datos de una manera ms eficiente que en el modelo jerrquico. Las operaciones del modelo de red son de navegacin en el estilo: un programa man tiene una posicin corriente, y navega de un registro al otro por siguiente las relaciones en las cuales el registro participa. Los registros tambin pueden ser localizados por suministrando valores claves. Aunque esto no sea un rasgo esencial del modelo, las bases de datos de red generalmente ponen en prctica las relaciones de juego mediante indicadores que directamente dirigen la ubicacin de un registro sobre el disco. Esto da el funcionamiento de recuperacin excelente, a cargo de operaciones como la carga de base de datos y la reorganizacin. La mayor parte de bases de datos de objeto usan el concepto de navegacin para proporcionar la navegacin rpida a travs de las redes de objetos, generalmente usando identificadores de

objeto como indicadores "inteligentes" de objetos relacionados. Objectivity/DB, por ejemplo, los instrumentos llamados 1:1, 1:muchos, muchos:1 y muchos:muchos, llamados relaciones que pueden cruzar bases de datos. Muchas bases de datos de objeto tambin apoyan SQL, combinando las fuerzas de ambos modelos. El modelo de red (definido por la especificacin CODASYL) organiza datos que usan dos fundamental construcciones, registros llamados y conjuntos. Los registros contienen campos (que puede ser organizado jerrquicamente, como en el lenguaje COBOL de lenguaje de programacin). Los conjuntos (para no ser confundido con conjuntos matemticos) definen de uno a varios relaciones entre registros: un propietario, muchos miembros. Un registro puede ser un propietario en cualquier nmero de conjuntos, y un miembro en cualquier nmero de conjuntos. El modelo de red es una variacin sobre el modelo jerrquico, al grado que es construido sobre el concepto de mltiples ramas(estructuras de nivel inferior) emanando de uno o varios nodos (estructuras de nivel alto), mientras el modelo se diferencia del modelo jerrquico en esto las ramas pueden estar unidas a mltiples nodos. El modelo de red es capaz de representar la redundancia en datos de una manera ms eficiente que en el modelo jerrquico. Las operaciones del modelo de red son de navegacin en el estilo: un programa mantiene una posicin corriente, y navega de un registro al otro por siguiente las relaciones en las cuales el registro participa. Los registros tambin pueden ser localizados por suministrando valores claves. Aunque esto no sea un rasgo esencial del modelo, las bases de datos de red generalmente ponen en prctica las relaciones de juego mediante indicadores que directamente. dirigen la ubicacin de un registro sobre el disco. Esto da el funcionamiento de recuperacin excelente, a cargo de operaciones como la carga de base de datos y la reorganizacin. La mayor parte de bases de datos de objeto usan el concepto de navegacin para proporcionar la navegacin rpida a travs de las redes de objetos, generalmente usando identificadores de objeto como indicadores "inteligentes" de objetos relacionados. Objectivity/DB, por ejemplo, los instrumentos llamados 1:1, 1:muchos, muchos:1 y muchos:muchos, llamados relaciones que pueden cruzar bases de datos. Muchas bases de datos de objeto tambin apoyan SQL, combinando las fuerzas de ambos modelos. [editar]Modelo

Dimensional

El modelo dimensional es una adaptacin especializada del modelo relacional, sola representar datos en depsitos de datos, en un camino que los datos fcilmente pueden ser resumidos usando consultas OLAP. En el modelo dimensional, una base de datos consis en te una mesa sola grande de los hechos que son descritos usando dimensiones y medidas. Una dimensin proporciona el contexto de un hecho (como quien particip, cuando y donde pas, y su tipo) y es usado en preguntas al grupo hechos relacionados juntos. Las dimensiones tienden a ser discretas y son a menudo jerrquicas; por ejemplo, la posicin(ubicacin) podra incluir el edificio, el estado, y el pas.

Un indicador es una cantidad que describe el hecho, como el ingreso. Es importante que los indicadores significativamente puedan ser agregados - por ejemplo, el ingreso de ubicaciones diferentes pueden ser aadidas juntas. En una consulta OLAP, las dimensiones son escogidas y los hechos son agrupados y aadidos juntos para crear un reporte. El modelo dimensional a menudo es puesto en prctica sobre la cima del modelo emparentado que usa un esquema de estrella, consistiendo en una mesa que contiene los hechos y mesas circundantes que contienen las dimensiones. Dimensiones en particular complicadas podran ser representadas usando mltiples mesas, causando un esquema de copo de nieve. Un almacen de datos (data warehouse) puede contener mltiples esquemas de estrella que comparten tablas de dimensin, permitindoles para ser usadas juntas. La llegada levanta un conjunto de dimensiones estndar y es una parte importante del modelado dimensional. [editar]Modelo

de objeto

En aos recientes, el paradigma mediante objetos ha sido aplicado a la tecnologa de base de datos, creando un nuevo modelo de programa sabido(conocido) como bases de datos de objeto. Estas bases de datos intentan traer el mundo de base de datos y el uso que programa el mundo ms cerca juntos, en particular por asegurando que la base de datos usa el mismo sistema de tipo que el programa de uso. Esto apunta para evitar el elevado (a veces mencionaba el desajuste de impedancia) de convertir la informacin entre su representacin en la base de datos (por ejemplo como filas en mesas) y su representacin en el programa de uso (tpicamente como objetos). Al mismo tiempo, las bases de datos de objeto intentan introducir las ideas claves de programa de objeto, como encapsulation y polimorfismo, en el mundo de bases de datos. Una variedad de estas formas ha sido aspirada almacenando objetos en una base de datos. Algunos productos se han acercado al problema del uso que programa el final, por haciendo los objetos manipulados segn el programa persistente. Esto tambin tpicamente requiere la adicin de una especie de lengua de pregunta, ya que lenguajes de programacin convencionales no tienen la capacidad de encontrar objetos basados en su contenido de la informacin. Los otros han atacado el problema a partir del final de base de datos, por definiendo un modelo de datos mediante objetos para la base de datos, y definiendo un lenguaje de programacin de base de datos que permite a capacidades de programa llenas as como instalaciones de pregunta tradicionales. Las bases de datos de objeto han sufrido debido a la carencia de estandarizacin: aunque las normas fueran definidas por ODMG, nunca fueron puestas en prctica lo bastante bien para asegurar la interoperabilidad entre productos. Sin embargo, las bases de datos de objeto han sido usadas satisfactoriamente en muchos usos:Usualmente aplicaciones especialisadas como

bases de datos de ingenieria, base de datos biologica molecualar, ms bien que proceso de datos establecido comercial. Sin embargo, las ideas de base de datos de objeto fueron recogidas por los vendedores emparentados y extensiones influidas hechas a estos productos y de verdad a la lengua SQL.

Normalizacin y Dependencia Funcional

Normalizacin
La normalizacin es un proceso que consiste en comprobar que las tablas (tambin denominadas relaciones en terminologa propia del modelo relacional de datos) definidas cumplen unas determinadas condiciones. Se pretente garantizar la no existencia de redundancia y una cierta coherencia en la representacin mediante un esquema relacional de las entidades y relaciones del modelo conceptual (diagrama E -R). Mediante la normalizacin se pueden solucionar diversos errores en el diseo de la base de datos as como mejorarlo. Tambin se facilita el trabajo posterior del administrador de la base de datos y de los desarrolladores de aplicaciones.

Dependencia Funcional
Una dependencia funcional, denotada por X -> Y, entre dos conjuntos de atributos X y Y que son subconjuntos de R (R ={A1, A2,...,A3}) especifica una restriccin sobre las posibles tuplas que podran formar un ejemplar de relacin r de R. La restriccin dice que, para cualesquier dos tuplas t1 y t2 de r tales que t1[X] = t2[X], debemos tener tambin t1[Y] = t2[Y]. Esto significa que los valores componentes de Y de una tupla de r dependen de los valores del componente X, o estn determinados por ellos; o bien, que los valores del componente X de una tupla determinan de manera nica (o funcionalmente) los valores del componente Y. Tambin decimos que hay una dependen cia funcional de X a Y o que Y depende funcionalmente de X.

Sean a y b atributos de una misma tabla o relacin T. Se dice que b es funcionalmente dependiente de a y se denota T.a -> T.b o bien simplemente a -> b si todo posible valor de a tiene asociado un nico valor de b, o lo que es lo mismo, en todas las tuplas de T en las que el atributo a toma el mismo valor v1, el atributo b toma tambin un mismo valor v2. Claramente a -> b no implica b -> a. Pueden repetirse los valores del atributo b para distintos valores de a. Un mismo atributo puede determinar funcionalmente a varios atributos lo cual se denota a -> (b1, b2, ...). Puede darse una dependencia funcional mutua: a -> b y b -> a o lo que es lo mismo a <-> b. Nse que el concepto de dependencia funcional no depende de la extensin concreta (contenido) que en un momento determinado tenga la tabla sino de cualquier posible extensin que pudiera tener. Los atributos a y b pueden ser simples o compuestos (formados por la agregacin de varios atributos). Los atributos funcionalmente dependientes pueden o no formar parte de la clave primaria de la tabla, de una clave altenativa o de una clave ajena de otra tabla. El atributo b es funcionalmente dependiente de forma completa de a si a -> b y b no depende funcionalmente de ningn subconjunto de atributos de a. Si a es un atributo simple y a -> b entonces la dependencia funcional es con seguridad completa. Las dependencias funcionales verifican una serie de propiedades denominadas axiomas de Armstrong: Reflexividad. A partir de cualquier atributo o conjunto de atributos siempre puede deducirse l mismo. Dependencia trivial: x -> x. Aumentatividad. Si x -> y entonces x+z -> y. As se puede aumentar trivialmente el antecedente de una dependencia. Ejemplo: si con el dni se determina el nombre de una persona, entonces con el dni ms la direccin tambin se determina el nombre. Proyectividad. Si x -> y+z entonces x -> y. Ejemplo: si a partir del dni es posible deducir el nombre y la direccin de una persona, entonces con el dni es posible determinar el nombre. Aditividad. Si x -> y y z -> w entonces x+z -> y+w. Ejemplo: si con el dni se determina el nombre y con la direccin el telfono de una persona, entonces con el dni y la direccin podr determinarse el nombre y el telfono.

Transitividad o enlace de dependencias funcionales. Si x -> y e y -> z entonces x -> z. Ejemplo: si con el dni puede determinarse el cdigo de la provincia de residencia de una persona y con ste cdigo puede determinarse el nombre de la provincia, entonces con el dni puede determinarse el nombre de la provincia. ste es el mecanismo bsico de funcionamiento del enlace entre tablas a partir de claves ajenas.

Reglas de normalizacin
El punto de partida del proceso de normalizacin es un conjunto de tablas con sus atributos, el denominado esquema relacional. Se pretende mejorar dicho esquema de datos. Se dice que una tabla estn en una determinada forma normal si satisface un cierto nmero de restricciones impuestas por la correspondiente regla de normalizacin. La aplicacin de una de estas reglas a un esquema relacional produce un nuevo esquema relacional en el que no se ha introducido ningn nuevo atributo. Un esquema relacional se compone de una serie de ternas T(A,D) donde T es el nombre de una tabla, A el conjunto de los atributos de esa tabla y D el conjunto de dependencias funcionales que existen entre esos atributos. Si una tabla no satisface una determinada regla de normalizacin, se procede a descomponerla en otras dos nuevas que s las satisfagan. Esto usualmente requiere decidir qu atributos de la tabla original van a residir en una u otra de las nuevas tablas. La descomposicin tiene que conservar dos propiedades fundamentales: 1.No prdida de informacin. Sea T(A,D) que se divide en T1(A1,D1) y T2(A2,D2). A partir de los atributos comunes en ambos esquemas es posible determinar los atributos de T1 no presentes en T2 (es decir, el conjunto A1 - A2) o bien los atributos de T2 no presentes en T1 (el conjunto diferencia A2 - A1). Desde cualquier esquema se consigue recuperar los datos del otro mediante un mecanismo de clave ajena que permite reconstituir el esquema original de partida. Expresado mediante dependencias funcionales, la interseccin de los conjuntos de atributos A1 y A2 debe

determinar funcionalmente la diferencia de los conjuntos de atributos A1 A2 o bien A2 - A1. 2.No prdida de dependencias funcionales. La normalizacin consiste pues en descomponer los esquemas relacionales (tablas) en otros equivalentes (puede obtenerse el original a partir de los otros) de manera que se verifiquen unas determinadas reglas de normalizacin. Eviden temente las reglas de normalizacin imponen una serie de restricciones en lo relativo a la existencia de determinados esquemas relacionales. Segn se avance en el cumplimiento de reglas y restricciones se alcanzar una mayor forma normal. Existen cinco formas normales hacia las cuales puede conducir el proceso de normalizacin de forma incremental ms una forma normal independiente de las otras. Un esquema relacional que satisface todas las restricciones impuestas por la tercera forma normal se considera de buena calidad aunque es mejor que satisfaga una interesante propiedad. La verificacin de una forma normal implica el cumplimiento de todas las formas normales anteriores. La primera forma normal es de cumplimiento obligatorio para que exista siquiera un esquema relacional propiamente formado FN1. Se pretende garantizar la no existencia de grupos repetitivos. Un grupo repetitivo es un conjunto de atributos de igual semntica en el problema y dominio, que toman valores distintos para la misma clave. Cualquier esquema que tenga claves correctas est seguro en FN1. FN2.Si FN1 y cada atributo de la tabla que no forma parte de la clave depende funcionalmente de forma completa de la clave primaria. Es decir, depende de toda la clave y no de ningn subconjunto de ella. Se pretende garantizar una correcta eleccin de claves y eliminar redundancias. Si la clave estn formada por un nico atributo entonces ese esquema estar seguro en segunda forma normal. FN3. Si FN2 y cada atributo no primo de la tabla no depende funcionalmente de forma transitiva de la clave primaria. FNBC (Forma Normal de Boyce-Codd). Se basa en el concepto de determinante funcional: uno o varios atributos de una tabla de los cuales dependen funcionalmente de forma completa algn

otro atributo de la misma tabla. Una relacin est en FNBC si FN1 y cada determinante funcional es una clave candidata de la tabla. As se garantiza que se han elegido bien las claves al no existir dependencias funcionales entre atributos que no son clave. Cada vez que se verifica una dependencia funcional a -> b entonces a es clave primaria o alterna con seguridad. Todas las dependencias funcionales cumplen que en su parte izquierda solo aparecen atributos que son parte de una clave candidata. Esta forma normal es ms restrictiva que la tercera y tiene la interesante propiedad de que su cumplimiento implica la satisfaccin de FN3 o sea que FNBC -> FN3. Ejemplo: Dependencias funcionales Ejemplo: a.Empleado_departameto nombre nss fecha_n direccin b.Empleado_proyecto nss numero_proy horas

numero_dep

nombre_dep lugar_proy

nombre_emp

nombre_proy

Emp_proy - nss -> nombre (el nss del empleado determina de forma nica el nombre de ese empleado) - numero_proy -> {nombre_proy,lugar_proy} - {nss, numero_proy} -> horas

Control de Concurrencia

La mayora de las bases de datos se utilizan en entornos multi-usuario, en los que muchos clientes utilizando la misma aplicacin, o muchas aplicaciones cada una con uno o muchos clientes acceden a la misma base de datos. Cada una de esas aplicaciones enviar consultas al gestor, y normalmente cada hilo de ejecucin ser una transaccin diferente. En la mayora de los sistemas operativos actuales, las diferentes tareas o hilos se ejecutan de forma intercalada (incluso en el caso de mquinas con varios procesadores). Es decir, el sistema operativo decide por su cuenta cuando suspender una de las tareas y darle un poco de tiempo de ejecucin a otra. Si hay tareas simultneas o concurrentes sobre la misma base de datos, esta intercalacin puede resultar en que las lecturas y escrituras de las diferentes tareas o aplicaciones en el medio fsico se realicen en cualquier orden y secuencia. El acceso simultneo descrito puede dar como resultados informacin inconsistente o simplemente incorrecta, dependiendo de la mala o buena suerte que tengamos en la intercalacin de las lecturas y escrituras simultneas. Esta problemtica ha llevado a disear e implementar diferentes estrategias de control de concurrencia, que se encargan de evitar todos esos problemas, de modo que los desarrolladores de las aplicaciones pueden olvidarse de ellos al escribir su cdigo.

Para detectar la concurrencia es necesario proveer de mecanismos al sistema para que pueda ser capaz de detectarla. Una consideracin muy importante es llevar un control de acceso de todos los procesos que intervienen en un sistema, el cual puede ser llevado a cabo mediante la creacin de una matriz de transacciones vs. recursos, que informar de todas las posibles concurrencias. b) Solucin de problemas de concurrencia

b.1 Bloqueo
El bloqueo es una tcnica de control de concurrencia. Sirve para regular el acceso concurrente a registros en un ambiente de base de datos compartido. Una transaccin puede causar un bloqueo sobre un registro a consecuencia del requerimiento de un componente del sistema llamado "Manejador de Bloqueos". El bloqueo tiene un control que incluye, entre otras cosas, la identificacin (ID) del registro con el cual es asociado y la ID de la transaccin que mantiene el bloqueo. Este mecanismo debe ser capaz de permitir que slo una trabaje con ellos y, cuando sta termine, acceder el ingreso de la nueva transaccin. Existen dos tipos de bloqueo:
 Un proceso mediante el cual se lee un elemento realizando un bloqueo de tipo compartido sobre l y que permite a los procesos concurrentes leer dicho elemento, pero les impide su actualizacin.  Un proceso que graba un elemento, realiza un bloqueo de tipo exclusivo sobre l e impide a otros procesos grabarlo y leerlo.

Reglas para asegurar la coherencia de la base de datos 1. Todo proceso debe tener un bloqueo compartido del elemento antes de leerlo. 2. Todo proceso debe tener un bloqueo exclusivo del elemento antes de grabarlo. 3. No debe existir bloqueos compartidos sobre elementos con bloqueo exclusivo. 4. No debe existir bloqueos sobre elementos con bloqueo de cualquier tipo. 5. Todo proceso debe mantener el bloqueo compartido sobre un elemento, hasta finalizar por completo su lectura.

6. Todo proceso debe mantener el bloqueo exclusivo hasta completar sus operaciones y haber grabado todas las modificaciones en la base de datos. b.2 Sincronizacin La sincronizacin se usa en sistemas de gestin de base de datos distribuido, como una generalizacin del control de concurrencia en un sistema centralizado. En este caso el problema es ms serio, debido a que las actualizaciones provienen de varios nodos o copias en diferente orden, lo cual puede provocar inconsistencias aunque tengan un control de concurrencia local.

Mtodos para proveer sincronizacin 1. Control Centralizado. Todos los pedidos de actualizacin pasan por un nico punto de control, en el cual se validan los pedidos. Los algoritmos de sincronizacin son los siguientes:

Se escoge un nodo (encargado de la sincronizacin) que contiene el proceso de "Controlador de Bloqueo Centralizado", mientras los otros nodos, con una parte de la base de datos, tienen un proceso de controlador de bloqueo local.
 Protocolo

de Controlador de Bloqueo Centralizado.

El controlador de bloqueo centralizado examina los pedidos de bloqueo o desbloqueo de todos los nodos y decide si se debe dar o no.
 Protocolo de Token de Control. En este mtodo se asigna un nmero consecutivo a cada nodo en el sistema, creando un anillo virtual. Uno de los nodos mantiene un token de control nico, el cual est autorizado a procesar las transacciones que se originan en l e invocar actividades a otros nodos, requeridas para completar dichas transacciones, al trmino del cual, el token de control se transmite al nodo siguiente en el anillo virtual.

Este procedimiento provee consistencia, ya que en todo momento existe un nico foco de control y una sola tabla de bloqueos.
 Protocolo

de Copia Primaria. Este mtodo provee de una rpida recuperacin de fallas a las bases de datos de rplicas. Un pedido de actualizacin en un nodo implica su envo al nodo primario. Este actualiza su copia de la data y pide la cooperacin del primer nodo en la secuencia que recibe el pedido del nodo primario y lo ejecuta. Entonces el primer nodo enva mensajes a: j Al siguiente nodo para avisar que la actualizacin fue enviada.

j Al nodo que la origin para avisar que la actualizacin fue aceptada. j En forma similar al anterior al nodo primario.

La actualizacin se enva a los otros nodos a travs de una comunicacin lineal o difundida.

Es muy flexible y sirve para base de datos relacionales. En este caso, la copia primaria trabaja con fragmentos de la base de datos, teniendo cada uno un sitio primario hacia el cual se dirigen primero todas las actualizaciones.
 Protocolo

de Sitio Primario .

2. Control Distribuido. La responsabilidad de validar los pedidos de actualizacin y aplicarlos a las rplicas de la base de datos, es distribuida entre los nodos. Los algoritmos de sincronizacin son:
 Protocolo de Consenso Mayoritario. Mantiene la consistencia entre las copias de una base de datos distribuida, sin requerir de la deteccin de fallas del sistema o cambiar a un modo especial de recuperacin en el caso de fallas.

de Timestamp. Se utiliza en base de datos de rplicas, en el cual los nodos no estn necesariamente disponibles todo el tiempo. La sincronizacin es ms simple que la de otros protocolos y la decisin de cul usar se hace en el diseo, cuyo resultado se incorpora en tablas que pueden consultarse al momento de la ejecucin, sin necesidad de comunicarse entre nodos.
 Protocolo

 Protocolo de Difusin. Es un algoritmo distribuido y completo. Cuando un nodo recibe un pedido de actualizacin de un usuario local, chequea su tabla local de bloqueos y verifica si existe un conflicto. Si no es as, el nodo difunde un pedido a los dems para obtener bloqueos en la transaccin. Si los nodos locales o cualquier nodo remoto detecta un conflicto, se suspende la transaccin. En caso contrario, la actualizacin se ejecuta localmente y luego se difunde la data a los dems y todos responden despus que se complete la actualizacin.
 Protocolo

En este mtodo realiza las transacciones utilizando tickets (etiquetas). Este protocolo requiere que cada transaccin tenga un nmero de secuencia que lo da el nodo principal, al momento que se origina dicha transaccin.

de Ticket.

SEGURIDAD E INTEGRIDAD La informacin de la base de datos debe estar protegida contra accesos no autorizados, destruccin o alteracin con fines indebidos y la introduccin accidental de inconsistencia. VIOLACIONES DE LA SEGURIDAD E INTEGRIDAD La prdida accidental de la consistencia puede deberse a: v v v v Cadas durante el procesamiento de las transacciones Anomalas por acceso concurrente a la base de datos Anomalas que resultan de la distribucin de los datos entre varios computadores Un error lgico que viola la suposicin de que las transacciones respetan las protecciones de

consistencia de la base de datos. Alguna de la formas de acceso indebido son: Lectura de datos sin autorizacin Modificacin de datos sin autorizacin Destruccin no autorizada de los datos Para proteger a la base de datos es necesario adoptar medidas de seguridad en varios niveles: Fsico Humano Sistema operativo Sistemas de base de datos

La seguridad en estos niveles debe mantenerse para asegurar la seguridad de la base de datos. AUTORIZACIONES Y VISTAS Las vistas son una forma de proporcionar al usuario un modelo personalizado de la base de datos. Las bases de datos relacionales cuentan con dos niveles de seguridad: Relacin Vistas Un usuario puede tener varias formas de autorizacin sobre partes de la base de datos. Entre ellas se encuentran las siguientes: Autorizacin Autorizacin Autorizacin Autorizacin de de de de lectura insercin actualizacin borrado

Un usuario puede tener asignado todo, ninguno o una combinacin de los tipos de autorizacin anteriores. Es posible autorizar al usuario para que modifique el esquema de la base de datos. Autorizacin Autorizacin Autorizacin Autorizacin de de de de ndice recursos alteracin eliminacin

La forma fundamental de autoridad es la que se le da al administrador de la base de datos. Al usuario al que se le ha concedido alguna forma de autoridad se le puede permitir pasar sta autoridad a otros usuarios. Estos usuarios a su ves pueden transferir la autorizacin a otros, la transferencia de autorizacin de un usuario a otro se representa por medio de un grafo de autorizacin. ESPECIFICACION DE LA SEGURIDAD EN SQL El lenguaje de definicin de datos en SQL incluye mandatos para conceder y revocar privilegios, SQL incluye una lista modificada de privilegios: Alter (modificar) Delete (borrar) Index (ndice) Insert (inserter) Select (elegir) Update (actualizar) References (referencia)

Por defecto un usuario al que se le concede un privilegio en SQL no est autorizado a conceder ste privilegio a otro usuario. Para conceder un privilegio y permitir al beneficiario pasar el privilegio a otros usuarios, la sentencia with grant option (con opcin de concesin) se aade al mandato grant apropiado. La sentencia revoke(revocar) se utiliza para anular la autorizacin. Toma en forma id-entica a la de grant: Revoke On from