Apunte capítulo I

Asignatura Bases de Datos (10131) Escuela de Informática Carrera de Ing. Informática

CAPITULO I
FUNDAMENTOS DE BASES DE DATOS

1.4. Aplicación de los Sistemas de Base de Datos.

Las bases de datos se usan ampliamente. Algunas de sus aplicaciones representativas son:

• Banca: Para información de los clientes, cuentas, préstamos, y transacciones
bancarias.
• Líneas Aéreas: Para reservas e información de horarios. Las líneas aéreas fueron de
las primeras en usar las bases de datos de forma distribuida geográficamente.
• Universidades: Para información de los estudiantes, matrículas en las asignaturas y
cursos.
• Transacciones de Tarjetas de Crédito: Para compras con tarjeta de crédito y la
generación de los extractos mensuales.
• Telecomunicaciones: Para guardar un registro de las llamadas realizadas, generar las
facturas mensuales, mantener el saldo de las tarjetas telefónicas de prepago y para
almacenar la información sobre las redes de comunicaciones.
• Finanzas: Para almacenar información sobre compañías tenedoras, ventas y compras
de productos financieros, como acciones y bonos; también para almacenar datos del
mercado en tiempo real para permitir a los clientes la compraventa en línea y a la
compañía la compraventa automática.
• Ventas: Para información de clientes, productos y compras.
• Comercio en Línea: Para los datos de venta ya mencionados y para el seguimiento de
los pedidos we, generación de listas de recomendaciones y mantenimiento de
evaluaciones de productos en línea.
• Producción: Para la gestión de la cadena de proveedores y para el seguimiento de la
producción de artículos en las factorías, inventarios en los almacenes y pedidos.
• Recursos Humanos: Para información sobre los empleados, salarios, impuestos sobre
los sueldos y prestaciones, y para la generación de las nóminas.

1.2- Concepto de Base de Datos.

Una base o banco de datos, es un conjunto de datos que pertenecen al mismo contexto
almacenados sistemáticamente para su posterior uso.

En la actualidad, y gracias al desarrollo tecnológico de campos como la informática y la
electrónica, la mayoría de las bases de datos tienen formato electrónico, que ofrece un amplio
rango de soluciones al problema de almacenar datos.

Existen numerosas definiciones de bases de datos. Algunas de ellas:

o Colección de datos interrelacionados. Elmarsi, R, Navathe, S.B. 1989.
o Colección no redundante de datos que son compartidos por diferentes programas de
aplicación. Howe, 1983.
o Conjunto de datos de la empresa memorizado en un ordenador, que es utilizado por
numerosas personas y cuya organización está regida por un modelo de datos. Flory,
1982.

Capítulo I. Elaborado por: Prof. Virginia Juárez M. FIEC – 2011
Página: 1/45


o “Una base de datos es un conjunto de información almacenada en memoria auxiliar que
permite acceso directo, y un conjunto de programas que manipulan esos datos.”
o “Una base de datos es un conjunto exhaustivo, no redundante de datos estructurados,
organizados independientemente de su utilización y su implementación en máquina,
accesibles en tiempo real y compartibles por usuario s concurrentes que tienen
necesidad de información diferente y no predecible en el tiempo.”
o “Colección o depósito de datos integrados, con redundancia controlada y con una
estructura que refleje las interrelaciones y restricciones existentes en el mundo real; los
datos, que han de ser compartidos por diferentes usuarios y aplicaciones, deben
mantenerse independientes a éstas, y su definición y descripción, únicas para cada tipo
de dato, han de estar almacenadas junto con los mismos. Los procedimientos de
actualización y recuperación, comunes y bien determinados, habrán de ser capaces de
conservar la integridad, seguridad y confidencialidad del conjunto de los datos.

1.4. Propósito de los Sistemas de Bases de Datos.

Resolver las dificultades que presentaban los sistemas de procesamiento de archivos. Los
sistemas operativos tradicionales soportan un sistema de procesamiento de archivos típico. El
sistema almacena los registros en varios archivos y necesita diferentes programas de
aplicación para extraer y añadir a los archivos correspondientes. Los inconvenientes que
presenta un sistema de procesamiento de archivos son los siguientes:

o Redundancia e inconsistencia de los datos.

o Dificultad en el acceso a los datos.
o Aislamiento de datos
o Problemas de integridad
o Problemas de atomicidad
o Anomalías en el acceso concurrente
o Problemas de Seguridad

1.4.1. Ventajas del Uso de Base de Datos.

o Reducción de la Redundancia: En los sistemas tradicionales de ficheros cada aplicación
tiene sus datos privados, lo que provoca un alta redundancia y desaprovechamiento del
espacio en disco.

Aunque se mantenga cierto grado de redundancia, por motivos de rendimiento u otros,
proporciona mecanismos para garantizar la consistencia.

Consistencia: Eliminando o controlando las redundancias de datos se reduce en gran
medida el riesgo de que haya inconsistencias. Si un dato está almacenado una sola vez,
cualquier actualización se debe realizar sólo una vez, y está disponible para todos los
usuarios inmediatamente. Si un dato está duplicado y el sistema conoce esta
redundancia, el propio sistema puede encargarse de garantizar que todas las copias se
mantienen consistentes.

Puede evitarse la inconsistencia: Se controla la redundancia garantizando que los datos
redundantes se actualicen de forma automática.

Página: 2/45


o Los datos pueden compartirse: Las necesidades de datos de nuevas aplicaciones
pueden atenderse con los ya existentes sin tener que almacenar nuevos datos.

o Pueden hacerse cumplir las normas establecidas: Al tener un control centralizado de la
base de datos, el administrador puede garantizar que se observen las normas de la
empresa aplicables a la representación de los datos.

o Restricciones de Seguridad: El administrador puede asegurar que el único modo de
acceso sea a través de los canales establecidos, y en consecuencia definir controles de
autorización que pueden afectar a cada modo de acceso. Sin estos controles de
seguridad, es mucho más sensible una base de datos que los archivos.

1.4.2. Inconvenientes

o Instalación costosa

• Coste del SGBD: El costo de un SGBD varía dependiendo del entorno y de la
funcionalidad que ofrece. Por ejemplo, un SGBD para un ordenador personal
puede costar 500 euros, mientras que un SGBD para un sistema multiusuario
que dé servicio a cientos de usuarios puede costar entre 10.000 y 100.000
euros. Además, hay que pagar una cuota anual de mantenimiento que suele ser
un porcentaje del precio del SGBD.

• Coste de Equipo Adicional: Tanto el SGBD, como la propia base de datos,
pueden hacer que sea necesario adquirir más espacio de almacenamiento.
Además, para alcanzar las prestaciones deseadas, es posible que sea necesario
adquirir una máquina más grande o una máquina que se dedique solamente al
SGBD..

• Coste de la Conversión: Este coste incluye el coste de enseñar a la plantilla a
utilizar estos sistemas y, probablemente, el coste del personal especializado
para ayudar a realizar la conversión y poner en marcha el sistema. Este coste
es una de las razones principales por las que algunas empresas y
organizaciones se resisten a cambiar su sistema actual de ficheros por un
sistema de bases de datos.

o Necesita de personal especializado
o Implantación larga y difícil
o Falta de rentabilidad a corto plazo.
o Escasa estandarización
o Desfase entre teoría y práctica

1.4. Sistemas de Gestión de Bases de Datos.

En un sistema de bases de datos, debe existir una capa intermedia entre los datos
almacenados en la base de datos, las aplicaciones y los usuarios del mismo. Se trata
del Sistema de Gestión de Bases de Datos (SGBD). Actúa de intermediario entre los
usuarios y aplicaciones y los datos proporcionados, medios para describir, almacenar y
manipular los datos, y proporciona herramientas al administrador para gestionar el
sistema, entre ellas las herramientas de desarrollo de aplicaciones, generadores de

Página: 3/45


informes, lenguajes específicos de acceso de acceso a los datos, como SQL
(Structured Query Language) o QBE (Query by Example).

1.4.1. Objetivo de los SGBD.

Un sistema gestor de bases de datos o SGBD (aunque se suele utilizar más a menudo las
siglas DBMS procedentes del inglés, Data Base Management System) es el software que
permite a los usuarios procesar, describir, administrar y recuperar los datos almacenados en
una base de datos.

En estos Sistemas se proporciona un conjunto coordinado de programas, procedimientos y
lenguajes que permiten a los distintos usuarios realizar sus tareas habituales con los datos,
garantizando además la seguridad de los mismos.

Ilustración 1, Esquema del funcionamiento y utilidad de un sistema
gestor

El éxito del SGBD reside en mantener la seguridad e integridad de los datos. Lógicamente tiene
que proporcionar herramientas a los distintos usuarios. Entre las herramientas que proporciona
están:

• Herramientas para la creación y especificación de los datos. Así como la estructura
de la base de datos.
• Herramientas para administrar y crear la estructura física requerida en las unidades
de almacenamiento.
• Herramientas para la manipulación de los datos de las bases de datos, para añadir,
modificar, suprimir o consultar datos.
• Herramientas de recuperación en caso de desastre
• Herramientas para la creación de copias de seguridad
• Herramientas para la gestión de la comunicación de la base de dato
• Herramientas para la creación de aplicaciones que utilicen esquemas externos de los
datos
• Herramientas de instalación de la base de datos.
• Herramientas para la exportación e importación de datos

1.4.2. Niveles de Abstracción de una Base de Datos.

Página: 4/45


En cualquier sistema de información se considera que se pueden observar los datos desde dos
puntos vista:

• Vista Externa. Esta es la visión de los datos que poseen los usuarios del Sistema de
Información.

• Vista Física. Esta es la forma en la que realmente están almacenados los datos.

En un Sistema de ficheros, los usuarios ven los datos desde las aplicaciones creadas por los
programadores. Esa vista pueden ser formularios, informes visuales o en papel,... Pero la
realidad física de esos datos, tal cual se almacenan en los discos, no la ven. Esa visión está
reservada a los administrados.

En el caso de los Sistemas de Base de datos, se añade una tercera vista, que es la vista
conceptual. Esa vista se sitúa entre la física y la externa. Se habla pues en Bases de Datos de
la utilización de tres esquemas para representar los datos.

Esquema Físico.

Representa la forma en la que están almacenados los datos. Esta visión sólo la requiere el
administrador. El administrador la necesita para poder gestionar más eficientemente la base
de datos

En este esquema es donde aparecen las unidades de disco, archivos y carpetas del sistema.

Esquema Conceptual.

Se trata de un esquema teórico de los datos en la que figuran organizados en estructuras
reconocibles del mundo real y en el que también aparece la forma de relacionarse los datos.

Esta estructura es utilizada por el desarrollador, que necesita conocerla para al crear
aplicaciones saber como acceder. Todas las aplicaciones que se crean sobre la base de datos
utilizan este esquema.

Realmente cuando se habla del diseño de la base de datos, se suele referir a este esquema. El
esquema conceptual lo realiza el diseñador de la base de datos.

Esquema Externo.

Se trata de la visión de los datos que poseen los usuarios finales. Esa visión es la que
obtienen a través de las aplicaciones. Las aplicaciones creadas por los desarrolladores
abstraen la realidad conceptual de modo que el usuario no conoce las relaciones entre los
datos, como tampoco conoce todos los datos que realmente se almacenan.

Realmente cada aplicación produce un esquema externo diferente (aunque algunos pueden
coincidir) o vistas de usuario. El conjunto de todas las vistas de usuario es lo que se
denomina esquema externo global.

Página: 5/45


1.4.3. Independencia de los Esquemas.

Lo interesante de estos esquemas es que trabajan independientemente. Cada usuario utiliza el
esquema que necesita sin saber nada del resto. Esa independencia se traduce en:

• Independencia física de los datos. Aunque el esquema físico cambie, el esquema
conceptual no debe verse afectado. En la práctica esto significa que aunque la base de
datos se almacene en otro disco duro, la parte conceptual de la base de datos no debe
verse afectada. No habrá que modificar dicho esquema.

• Independencia lógica de los datos. Significa que aunque se modifique los datos del
esquema conceptual, las vistas que poseen las aplicaciones (los esquemas externos)
no se verán afectados.

1.4.4. Funciones.

Los SGBD tienen que realizar tres tipos de funciones para ser considerados válidos.

Función de Descripción o Definición.

Permite al diseñador de la base de datos crear las estructuras apropiadas para integrar
adecuadamente los datos. Esta función es la que permite definir las tres estructuras de la base
de datos (relacionadas con sus tres esquemas).

• Estructura interna
• Estructura conceptual
• Estructura Externa

Esta función se realiza mediante el lenguaje de descripción de datos o DDL. Mediante ese
lenguaje:

• Se definen las estructuras de datos.
• Se definen las relaciones entre los datos.
• Se definen las reglas que han de cumplir los datos.

Función de Manipulación.

Permite modificar y utilizar los datos de la base de datos. Se realiza mediante el lenguaje de
modificación de datos o DML. Mediante ese lenguaje se puede:

• Añadir datos.
• Eliminar datos.
• Modificar datos.
• Buscar datos.

Actualmente se suele distinguir la función de buscar datos respecto del resto. Para lo cual se
proporciona un lenguaje de consulta de datos o DQL.

Página: 6/45


Función de Control.

Mediante esta función los administradores poseen mecanismos para determinar las visiones de
los datos permitidas a cada usuario, además de proporcionar elementos de creación y
modificación de esos usuarios.

Se suelen incluir aquí las tareas de copia de seguridad, carga de ficheros, auditoria, protección
ante ataques externos, configuración del sistema,... El lenguaje que implementa esta función
es el lenguaje de control de datos o DCL.

1.4.5. Estandarización.

Es uno de los aspectos que todavía sigue pendiente. Desde la aparición de los primeros
gestores de base de datos se intentó llegar a un acuerdo para que hubiera una estructura
común para todos ellos, a fin de que el aprendizaje y manejo de este software fuera más
provechoso y eficiente

El acuerdo nunca se ha conseguido del todo, no hay estándares aceptados del todo. Aunque sí
hay unas cuentas propuestas de estándares que sí funcionan como tales.

Organismos de Estandarización.

Los intentos por conseguir una estandarización han estado promovidos por organismos de todo
tipo. Algunos son estatales, otros privados y otros promovidos por los propios usuarios. Los dos
que han tenido gran relevancia en el campo de las bases de datos son ANSI/SPARC/X3,
CODASYL y ODMG. Los organismos grandes (que recogen grandes responsabilidades)
dividen sus tareas en comités, y éstos en grupos de trabajo que se encargan de temas
concretos.

SC21

ISO (International Organization for Standardization). Es un organismo internacional de
definición de estándares de gran prestigio.

IEC (International Electrotechnical Commission). Organismo de definición de normas en
ambientes electrónicos.

JTC1 (Joint Technical Committee). Comité formado por los dos organismos anteriores
encargado de diversos proyectos. En el campo de las bases de datos, el subcomité SC21 (en
el que participan otros organismos nacionales, como el español AENOR) posee un grupo de
trabajo llamado WG 3 que se dedica a las bases de datos. Este grupo de trabajo es el que
define la estandarización del lenguaje SQL entre otras cuestiones.

DBTG Codasyl

Codasyl (Conference on Data System Languages) es el nombre de una conferencia de
finales de los años 60 en la que participaron organismos privados y públicos del gobierno de
Estados Unidos con la finalidad de definir estándares (Codasyl definió el lenguaje COBOL) para
la informática de gestión.

Página: 7/45


De ahí salió DBTG (Data Base Task Group, grupo de tareas para bases de datos) grupo que
definió el modelo en red de bases de datos que desde entonces se llama Codasyl o DBTG y
que fue aceptado por la ANSI.

ANSI/X3/SPARC

ANSI (American National Science Institute) es un organismo científico de Estados Unidos
que ha definido diversos estándares en el campo de las bases de datos. X3 es la parte de ANSI
encargada de los estándares en el mundo de la electrónica. Finalmente.

SPARC System Planning and Repairments Committee, comité de planificación de sistemas
y reparaciones es una subsección de X3 encargada de los estándares en Sistemas
Informáticos en especial del campo de las bases de datos. Su logro fundamental ha sido definir
un modelo de referencia para las bases de datos (que se estudiará posteriormente).

En la actualidad ANSI para Estados Unidos e ISO para todo el mundo son nombres
equivalentes en cuanto a estandarización de bases de datos, puesto que se habla ya de un
único modelo de sistema de bases de datos.

Modelo ANSI/X3/SPARC

El grupo ANSI ha marcado la referencia para la construcción de SGBD. Se basa en los
estudios anteriores en los que se indicaban tres niveles de abstracción de la base de datos.
ANSI profundiza más en esta idea y define cómo debe ser el proceso de creación y utilización
de estos niveles.

Página: 8/45


Ilustración 3, Niveles en el modelo ANSI

En el modelo ANSI se indica que hay tres modelos (externo, conceptual e interno) entendiendo
por modelo las normas que permiten crear esquemas (diseños de la base de datos). Los
esquemas externos reflejan la información preparada para el usuario final, el esquema
conceptual refleja los datos y relaciones de la base de datos y el esquema interno la
preparación de los datos para ser almacenados.

Página: 9/45


Ilustración 4, Arquitectura ANSI

El paso de un esquema a otro se realiza utilizando un interfaz o función de traducción. En su
modelo, la ANSI no indica cómo se debe realizar esta función, sólo que debe existir.

La arquitectura completa (Ilustración 4) esta dividida en dos secciones, la zona de definición de
datos y la de manipulación. Esa arquitectura muestra las funciones realizadas por humanos y
las realizadas por programas.

En la fase de definición, una serie de interfaces permiten la creación de los metadatos que se
convierten en el eje de esta arquitectura. La creación de la base de datos comienza con la
elaboración del esquema conceptual realizándola el administrador de la empresa (actualmente
es el diseñador, pero ANSI no lo llamó así). Ese esquema se procesa utilizando un procesador
del esquema conceptual (normalmente una herramienta CASE, interfaz 1 del dibujo anterior)

Página: 10/45


que lo convierte en los metadatos (interfaz 2).

La interfaz 3 permite mostrar los datos del esquema conceptual a los otros dos
administradores: el administrador de la base de datos y el de aplicaciones (el desarrollador).
Mediante esta información construyen los esquemas internos y externos mediante las
interfaces 4 y 5 respectivamente, los procesadores de estos esquemas almacenan la
información correspondiente a estos esquemas en los metadatos (interfaces 6 y 7).

En la fase de manipulación el usuario puede realizar operaciones sobre la base de datos
usando la interfaz 8 (normalmente una aplicación) esta petición es transformada por el
transformador externo/conceptual que obtiene el esquema correspondiente ayudándose
también de los metadatos (interfaz 9). El resultado lo convierte otro transformador en el
esquema interno (interfaz 10) usando también la información de los metadatos (interfaz 11).
Finalmente del esquema interno se pasa a los datos usando el último transformador (interfaz
12) que también accede a los metadatos (interfaz 13) y de ahí se accede a los datos (interfaz
14). Para que los datos se devuelvan al usuario en formato adecuado para él se tiene que
hacer el proceso contrario (observar dibujo).

Estructuras Operacionales.

Actualmente casi todos los sistemas gestores de base de datos poseen también la misma idea
operacional en la que se entiende que la base de datos se almacena en un servidor y hay una
serie de clientes que pueden acceder a los datos del mismo. Las posibilidades son:

• Estructura Cliente-Servidor. Estructura clásica, la base de datos y su SGBD están en
un servidor al cual acceden los clientes. El cliente posee software que permite al usuario
enviar instrucciones al SGBD en el servidor y recibir los resultados de estas
instrucciones. Para ello el software cliente y el servidor deben utilizar software de
comunicaciones en red.

• Cliente multi-servidor. Ocurre cuando los clientes acceden a datos situados en más de
un servidor. También se conoce esta estructura como base de datos distribuida. El
cliente no sabe si los datos están en uno o más servidores, ya que el resultado es el
mismo independientemente de dónde se almacenan los datos. En esta estructura hay
un servidor de aplicaciones que es el que recibe las peticiones y el encargado de
traducirlas a los distintos servidores de datos para obtener los resultados. Una
posibilidad muy extendida hoy en día es la posibilidad Cliente/Servidor Web/Servidor
de datos, el cliente se conecta a un servidor mediante un navegador web y desde las
páginas de este ejecuta las consultas. El servidor web traduce esta consulta al servidor
(o servidores) de datos.

1.4.6. Recursos Humanos de las Bases de Datos.

Intervienen muchas personas en el desarrollo y manipulación de una base de datos.

Informáticos.

Lógicamente son los profesionales que definen y preparan la base de datos. Pueden ser:

Página: 11/45


• Directivos/as. Son los organizadores y coordinadores del proyecto a desarrollar. Esto
significa que son los encargados de decidir los recursos que se pueden utilizar,
planificar el tiempo y las tareas, la atención al usuario y de dirigir las entrevistas y
reuniones pertinentes.
• Directivos/as. Son los organizadores y coordinadores del proyecto a desarrollar. Esto
significa que son los encargados de decidir los recursos que se pueden utilizar,
planificar el tiempo y las tareas, la atención al usuario y de dirigir las entrevistas y
reuniones pertinentes.

• Administradores/as de las bases de datos. Definen la seguridad de la base de datos
y gestionan las copias de seguridad y la gestión física de la base de datos. Los analistas
suelen tener esta funcionalidad cuando la base de datos está creada.
• Desarrolladores/as o programadores/as. Encargados de la realización de las
aplicaciones de usuario de la base de datos.
• Equipo de mantenimiento. Encargados de dar soporte a los usuarios en el trabajo
diario (suelen incorporar además tareas administrativas).

Usuarios.

• Expertos/as. Utilizan el lenguaje de manipulación de datos (DML) para acceder a la
base de datos. Son usuarios que utilizan la base de datos para gestión avanzada de
decisiones.
• Habituales. Utilizan las aplicaciones creadas por los desarrolladores para consultar y
actualizar los datos. Son los que trabajan en la empresa a diario con estas herramientas
y el objetivo fundamental de todo el desarrollo de la base de datos.
• Ocasionales. Son usuarios que utilizan un acceso mínimo a la base de datos a través
de una aplicación que permite consultar ciertos datos. Serían por ejemplo los usuarios
que consultan el horario de trenes a través de Internet.

1.4.7. Componentes del SGBD.

Estructura Multicapa.

Un SGBD está en realidad formado por varias capas que actúan como interfaces entre el
usuario y los datos. El propio ANSI/X3/SPARC introdujo una mejora de su modelo en 1988 a
través de un grupo de trabajo llamado UFTG (User Facilities Task Group, grupo de trabajo
para las facilidades de usuario). Este modelo toma como objeto principal, al usuario habitual de
la base de datos y orienta el funcionamiento de la base de datos de modo que este usuario
ignora el funcionamiento externo.

Desde esta óptica para llegar a los datos hay que pasar una serie de capas que poco a poco
van entrando más en la realidad física de la base de datos. Esa estructura se muestra en la
siguiente figura:

Página: 12/45


Ilustración 5, Modelo de referencia de las facilidades de usuario

Núcleo.

El núcleo de la base de datos es el encargado de traducir las operaciones que le llegan a
instrucciones ejecutables por el sistema operativo en el lenguaje que éste último requiera.

Diccionario de Datos.

Se trata del elemento que posee todos los metadatos. Gracias a esta capa las solicitudes de
los clientes se traducen en instrucciones que hacen referencia al esquema interno de la base
de datos.

Acceso a Datos.

La capa de acceso a datos es la que permite comunicar a las aplicaciones de usuario con el
diccionario de datos a través de las herramientas de gestión de datos que incorpore el SGBD.

Página: 13/45


Facilidades de Usuario.

Son las herramientas que proporciona el SGBD a los usuarios para permitir un acceso más
sencillo a los datos. Actúan de interfaz entre el usuario y la base de datos, y son el único
elemento que maneja el usuario.

1.4.8. Funcionamiento del SGBD.

El esquema siguiente presenta el funcionamiento típico de un SGBD:

Ilustración 6, Esquema del funcionamiento de un SGBD

El esquema anterior reproduce la comunicación entre un proceso de usuario que desea
acceder a los datos y el SGBD:

[1] El proceso lanzado por el usuario llama al SGBD indicando la porción de la base de
datos que se desea tratar

[2] El SGBD traduce la llamada a términos del esquema lógico de la base de datos. Accede
al esquema lógico comprobando derechos de acceso y la traducción física.

[3] El SGBD obtiene el esquema físico

[4] El SGBD traduce la llamada a los métodos de acceso del Sistema Operativo que
permiten acceder a los datos requeridos

Página: 14/45


[5] El Sistema Operativo accede a los datos tras traducir las órdenes dadas por el SGBD

[6] Los datos pasan del disco a una memoria intermedia o buffer. En ese buffer se
almacenarán los datos según se vayan recibiendo

[7] Los datos pasan del buffer al área de trabajo del usuario (ATU) del proceso del usuario.

[8] El SGBD devuelve indicadores en los que manifiesta si ha habido errores o advertencias
a tener en cuenta. Esto se indica al área de comunicaciones del proceso de usuario. Si
las indicaciones son satisfactorias, los datos de la ATU serán utilizables por el proceso
de usuario.

1.5. Tipos de Sistemas Gestores de Bases de Datos (SGBD).

1.5.1. Introducción.

Cada SGBD puede utilizar un modelo diferente para los datos. Por lo que hay modelos
conceptuales diferentes según que SGBD utilicemos.

No obstante existen modelos lógicos comunes, ya que hay SGBD de diferentes tipos. En la
realidad el modelo ANSI se modifica para que existan dos modelos internos: el modelo lógico
(referido a cualquier SGBD de ese tipo) y el modelo propiamente interno (aplicable sólo a un
SGBD en particular). De hecho en la práctica al definir las bases de datos desde el mundo real
hastata llegar a los datos físicos se pasa por los siguientes esquemas:

Por lo tanto la diferencia entre los distintos SGBD está en que proporcionan diferentes modelos
lógicos.

Diferencias entre el modelo lógico y el conceptual

• El modelo conceptual es independiente del DBMS que se vaya a utilizar. El lógico
depende de un tipo de SGBD en particular.
• El modelo lógico es más cercano al ordenador.

Página: 15/45


• El modelo conceptual es más cercano al usuario, el lógico es el encargado de
establecer el paso entre el modelo informático y el modelo físico del sistema.

Algunos ejemplos de modelos conceptuales son:

• Modelo E/R
• Modelo RM/T
• Modelos semánticos

Ejemplos de modelos lógicos son:

• Modelo relacional
• Modelo Codasyl
• Modelo Jerárquico
•
A continuación se comentarán los modelos lógicos más importantes.

1.5.2. Modelo Jerárquico.

Era utilizado por los primeros SGBD, desde que IBM lo definió para su IMS (Information
Management System, Sistema Administrador de Información) en 1970. Se le llama también
modelo en árbol debido a que utiliza una estructura en árbol para organizar los datos.

La información se organiza con un jerarquía en la que la relación entre las entidades de este
modelo siempre es del tipo padre / hijo. De esta forma hay una serie de nodos que contendrán
atributos y que se relacionarán con nodos hijos de forma que puede haber más de un hijo para
el mismo padre (pero un hijo sólo tiene un padre).

Los datos de este modelo se almacenan en estructuras lógicas llamadas segmentos. Los
segmentos se relacionan entre sí utilizando arcos. La forma visual de este modelo es de árbol
invertido, en la parte superior están los padres y en la inferior los hijos.

Ilustración 8, Ejemplo de esquema jerárquico

Página: 16/45


Este esquema está en absoluto desuso ya que no es válido para modelar la mayoría de
problemas de bases de datos.

1.5.3. Modelo en Red (Codasyl).

Es un modelo que ha tenido una gran aceptación (aunque apenas se utiliza actualmente). En
especial se hizo popular la forma definida por Codasyl a principios de los 70 que se ha
convertido en el modelo en red más utilizado.
El modelo en red organiza la información en registros (también llamados nodos) y enlaces.
En los registros se almacenan los datos, mientras que los enlaces permiten relacionar estos
datos. Las bases de datos en red son parecidas a las jerárquicas sólo que en ellas puede haber

más de un padre.

En este modelo se pueden representar perfectamente cualquier tipo de relación entre los datos
(aunque el Codasyl restringía un poco las relaciones posibles), pero hace muy complicado su
manejo.

1.5.4. Modelo Relacional.

En este modelo los datos se organizan en tablas cuyos datos se relacionan. Es el modelo más
popular y se describe con más detalle en los temas siguientes.

1.5.5. Modelo de Bases de Datos Orientadas a Objetos.

Desde la aparición de la programación orientada a objetos (POO u OOP) se empezó a pensar
en bases de datos adaptadas a estos lenguajes. La programación orientada a objetos permite
cohesionar datos y procedimientos, haciendo que se diseñen estructuras que poseen datos
(atributos) en las que se definen los procedimientos (operaciones) que pueden realizar con
los datos. En las bases orientadas a objetos se utiliza esta misma idea.

A través de este concepto se intenta que estas bases de datos consigan arreglar las
limitaciones de las relacionales. Por ejemplo el problema de la herencia (el hecho de que no se
puedan realizar relaciones de herencia entre las tablas), tipos definidos por el usuario,
disparadores (triggers) almacenables en la base de datos, soporte multimedia...

A través de este concepto se intenta que estas bases de datos consigan arreglar las
limitaciones de las relacionales. Por ejemplo el problema de la herencia (el hecho de que no se
puedan realizar relaciones de herencia entre las tablas), tipos definidos por el usuario,
disparadores (triggers) almacenables en la base de datos, soporte multimedia...

Su modelo conceptual se suele diseñar en UML y el lógico actualmente en ODMG (Object
Data Management Group, grupo de administración de objetos de datos, organismo que
intenta crear estándares para este modelo).

Página: 17/45


1.5.6. Bases de Datos Objetos Relacionales.

Tratan de ser un híbrido entre el modelo relacional y el orientado a objetos. El problema de las
bases de datos orientadas a objetos es que requieren reinvertir capital y esfuerzos de nuevo
para convertir las bases de datos relacionales en bases de datos orientadas a objetos. En las
bases de datos objeto relacionales se intenta conseguir una compatibilidad relacional dando la
posibilidad de integrar mejoras de la orientación a objetos.
Estas bases de datos se basan en el estándar SQL 99. En ese estándar se añade a las bases
relacionales la posibilidad de almacenar procedimientos de usuario, triggers, tipos definidos por
el usuario, consultas recursivas, bases de datos OLAP, tipos LOB,...

Las últimas versiones de la mayoría de las clásicas grandes bases de datos relacionales
(Oracle, SQL Server, Informix, ...) son objeto relacionales.

1.6. Tipos de Bases de Datos.

1.6.1. Según la Variabilidad de los Datos Almacenados.

Bases de Datos Estáticas: Éstas son bases de datos de sólo lectura,
utilizadas primordialmente para almacenar datos históricos que posteriormente se
pueden utilizar para estudiar el comportamiento de un conjunto de datos a través del
tiempo, realizar proyecciones y tomar decisiones.
Bases de Datos Dinámicas: Éstas son bases de datos donde la
información almacenada se modifica con el tiempo, permitiendo operaciones como
actualización y adición de datos, además de las operaciones fundamentales de
consulta. Un ejemplo de esto puede ser la base de datos utilizada en un sistema de
información de una tienda de abarrotes, una farmacia, un videoclub, etc.

1.6.2. Según su Contenido.

o Bases de Datos Bibliográficas: Solo contienen un representante de la fuente
primaria, que permite localizarla.
Un registro típico de una base de datos bibliográfica contiene información sobre el
autor, fecha de publicación, editorial, título, edición, de una determinada publicación,
etc.

Puede contener un resumen o extracto de la publicación original, pero nunca el texto
completo, porque sino estaríamos en presencia de una base de datos a texto
completo (o de fuentes primarias).

Como su nombre lo indica, el contenido son cifras o números. Por ejemplo, una
colección de resultados de análisis de laboratorio, entre otras.

o Bases de Datos de Texto Completo: Almacenan las fuentes primarias, como por
ejemplo, todo el contenido de todas las ediciones de una colección de revistas
científicas.

o Directorios: Un ejemplo son las guías telefónicas en formato electrónico.

Página: 18/45


o Banco de imágenes, videos, audios, multimedias, etc

o Bases de Datos o “bibliotecas” de información Biológicas:

Son bases de datos que almacenan diferentes tipos de información proveniente de
las ciencias de la vida o médicas.

Se pueden considerar en varios subtipos:

• Aquellas que almacenan secuencias de nucleótidos o proteínas.
• Las bases de datos de rutas metabólicas.
• Bases de datos de estructura, comprende los registros de datos
• experimentales sobre estructuras 3D de biomoléculas.
• Bases de datos clínicas.
• Bases de datos bibliográficas (biológicas)

1.7. Modelos de Bases de Datos.

1.7.1. Concepto y Técnica de Modelados.

La realidad del mundo que nos rodea es demasiado rica y compleja para la limitada capacidad
de percepción y entendimiento del hombre. Esto conlleva a que el hombre vaya acercándose a
la verdad objetiva (la realidad) por vía de simplificarla, eliminando todo lo que en un momento
dado pueda considerarse superfluo y capturando lo esencial para sus propósitos.

Abstracción: Ese esfuerzo en capturar lo relevante y eliminar los detalles no significativos para
nuestros objetivos.

Modelo: El conjunto de abstracciones que conforman una visión parcial, pero útil, de una parte
del mundo.

Una cercanía a la realidad del mundo circundante puede lograrse a base de construir modelos
que representan aspectos parciales de la misma. Esto también es aplicable para los productos
que el hombre fabrica. Así, antes de la fabricación de un sistema de información el ingeniero
de software construye una multitud de modelos del mismo. Para construir este modelo, utiliza
un lenguaje (vocabulario) determinado y unas reglas de construcción de las que no puede
salirse. Los elementos que pueden verse en un modelo, junto con las reglas de construcción,
constituyen primitivas de modelización (u ontología).

Modelos de Análisis.

El ingeniero puede llegar a construir tres modelos alineados en tres niveles. Estos
modelos, evidentemente, no son independientes ya que representan enfoques distintos
de una misma realidad. Cada nivel se ocupa de un tipo de conocimiento entre los que
se necesitan para responder a las grandes preguntas del análisis:

Página: 19/45


• ¿Qué hay en el mundo (dominio)?,
• ¿Qué ocurre en el mundo (funcional)?,
• ¿Cuándo cambia el mundo (control)?.

La siguiente figura muestra la estructura de niveles y modelos.

MODELO
NIVEL DE DINAMICO
CONTROL

NIVEL MODELO
FUNCIONAL FUNCIONAL

MODELO DE
NIVEL DATOS
DEL
DOMINIO

Niveles y Modelo de Análisis

o Modelo a Nivel de Dominio:

El nivel del dominio busca modelar el conocimiento de tipo estático identificando, en
el mundo del que va a entender el sistema, verdades de tipo universal (axiomas)
referentes a los objetos presentes en el dominio, sus características relevantes y las
relaciones y dependencias entre ellas.

Ejemplo: "(en el dominio de la empresa) hay empleados, funciones y
departamentos. Todo empleado tiene asignada alguna función y pertenece a un
departamento. Toda función ha de ser desempeñada por alguien. A veces, incluso,
por más de un empleado. Hay distintas categorías de empleado y todo empleado
tiene derecho a percibir una remuneración acorde con su categoría.

Página: 20/45


o Modelo Funcional:

Describe aquellos aspectos del sistema relativos a las transformaciones que puede
sufrir la información contenida en el dominio. Se trata de capturar los que el sistema
ha de hacer, sin considerar cuándo o cómo lo hará.

o Modelo Dinámico:

Describe los aspectos del sistema relativos al tiempo, capturando el control del
sistema: cuándo ocurren los cambios en el sistema, sin especificar en qué consisten
esos cambios (aspecto funcional) ni cómo son implementados.

o Relaciones entre Modelos:

De todos los niveles del análisis, el nivel del dominio es el que recoge el
conocimiento más profundo sobre un tema. Si nos propusiéramos realizar un
análisis de todo el saber humano, una gran parte del conocimiento científico se
recogería a este nivel. El resto de los niveles buscan sacar parido del modelo del
dominio, de manera que nos sea útil.

Lo que aquí nos interesa es la forma de representar los datos en el modelo del
dominio y concretamente qué modelos de datos disponemos para representar esos
datos en un sistema de base de datos.

El Nivel de Dominio: Modelos de Datos.

Modelo: (Diccionario de la Lengua Española): Esquema teórico, generalmente en forma
matemática, de un sistema o de una realidad compleja (por ejemplo la evolución
económica de un país); que se elabora para facilitar su comprensión y el estudio de su
comportamiento.

Modelar: Consiste en definir un mundo abstracto y teórico tal que las conclusiones que
se puedan sacar de él coinciden con las manifestaciones aparentes del mundo real.

Modelo: Conjunto de conceptos que permiten construir una representación
organizacional de la empresa.

Modelo de Datos: Es un dispositivo de abstracción que nos permite ver el bosque (la
información contenida en los datos) en oposición a los árboles (valores individuales de
los datos).

Modelo: Instrumento que se aplica a una parcela del mundo real (Universo del
Discurso) para obtener una estructura de datos a la que denominamos esquema.

MODELO Instrumento
ESQUEMA Resultado de aplicar el Instrumento

El primer paso en el diseño de una Base de Datos es definir el Universo del Discurso
fijando una serie de objetivos sobre el mundo real.

Página: 21/45


O
J UNIVERSO
E DEL
T MODELO ESQUEMA
DISCURSO
I
V
O

MUNDO
REAL

Definición de Modelo de Datos: Conjunto de conceptos, reglas y convenciones que
nos permiten describir los datos del universo del discurso, constituyendo una
herramienta que facilita su interpretación en forma de datos en nuestro sistema de
información.

Los Modelos de Datos son la base para los lenguajes de datos. El nivel de abstracción de
los lenguajes de datos es menor, ya que son el modelo más una sintaxis:

LD = M.D. + Sintaxis

El lenguaje puede venir tanto del modelo como de la sintaxis:

SQL = Modelo Relacional + Sintaxis
DL/I = Modelo Jerárquico + Sintaxis

Objetivos del Modelo de Datos.

o Formalización: Permite definir formalmente las estructuras permitidas y sus
restricciones a fin de representar los datos, y también porque establece las
bases para un lenguaje de datos.

o Diseño: El modelo de datos es uno de los elementos básicos en el diseño de
una Base de Datos.

Definición Formal del Modelo de Datos.

Propiedades del Universo del Discurso:

o Invariantes en el tiempo (Estáticas) Estructuras.
o Varían en el tiempo (Dinámicas): Datos o valores que se almacenan en
esas estructuras.

MD = < S, O >

Página: 22/45


S = Conjunto de reglas de generación que permiten representar la
componente estática, es decir las estructuras del Universo del Discurso.
Se corresponden con el Lenguaje de Definición de Datos.

O = Conjunto de operaciones autorizadas sobre la estructura que permite
representar la componente dinámica. Se corresponde con el Lenguaje de
Manipulación de Datos.

Componente Estática.

Está compuesta por:

o Objetos Permitidos: Varían mucho de unos modelos a otros. En general
son: entidades, atributos, dominios sobre los que se definen los atributos,
interrelaciones (asociaciones entre los objetos).

o Restricciones: No todas las estructuras están permitidas. Existen
restricciones que invalidan ciertos objetos o asociaciones entre ellos:

Inherentes: Impuestas por la misma naturaleza del modelo que no
admiten ciertos objetos o asociaciones. Introduce rigideces a la hora
de modelar.
De Usuario: Permiten captar la semántica del Universo del Discurso
que se quiere modelar. Facilitan la labor del diseñador.

La aplicación de la parte estática de un modelo a un Universo del Discurso da como
resultado un esquema o estructura e datos que representa dicho U.D. en el
correspondiente modelo.

Componente Dinámica.

Los valores que toman los distintos objetos de un esquema en un momento
determinado ti se llaman ocurrencia del esquema o Base de datos en ti (BDi).

En otro momento tj la ocurrencia será, en general, distinta. Se pueden haber modificado
la base de datos.

La componente dinámica del modelo consta de un conjunto de operaciones que de
definen sobre la estructura del correspondiente modelo de datos.

La aplicación de una operación a una ocurrencia de un esquema transforma a ésta en
una ocurrencia distinta:

O(BDi) = BDj

Tipos de Operaciones: SELECCIÓN, ACCION.

SELECCIÓN: Localizar una ocurrencia indicando un camino (Sistema navegacional) o
un conjunto de ocurrencias especificando una condición (especificación).

Página: 23/45


ACCION: Sobre la ocurrencias previamente localizadas. Puede consistir en
Recuperación o Actualización.

Se puede expresar:

SELECCIÓN < CONDICION>

ACCION <OBJETIVO>

La distinción SELECCIÓN – ACCION es de tipo formal, aunque algunos lenguajes,
como DL/I, tienen verbos distintos para cada operación. SQL reúne ambas operaciones
en una única sentencia.

Modelos

Conceptual (Lógico) ME/R
Convencional (Físico) Red Jerárquico Relacional

1.7.2. Modelos de Bases de Datos.

Además de la clasificación por la función de las bases de datos, éstas también se pueden
clasificar de acuerdo a su modelo de administración de datos.

Un modelo de datos es básicamente una "descripción" de algo conocido como contenedor de
datos (algo en donde se guarda la información), así como de los métodos para almacenar y
recuperar información de esos contenedores. Los modelos de datos no son cosas físicas: son
abstracciones que permiten la implementación de un sistema eficiente de base de datos; por lo
general se refieren a algoritmos, y conceptos matemáticos. Algunos modelos con frecuencia
utilizados en las bases de datos:

o Bases de Datos Jerárquicas: Éstas son bases de datos que, como su nombre indica,
almacenan su información en una estructura jerárquica. En este modelo los datos se
organizan en una forma similar a un árbol (visto al revés), en donde un nodo padre de
información puede tener varios hijos. El nodo que no tiene padres es llamado raíz, y a
los nodos que no tienen hijos se los conoce como hojas.

Las bases de datos jerárquicas son especialmente útiles en el caso de aplicaciones que
manejan un gran volumen de información y datos muy compartidos permitiendo crear
estructuras estables y de gran rendimiento.

Una de las principales limitaciones de este modelo es su incapacidad de representar
eficientemente la redundancia de datos.

o Bases de Datos de Red: Éste es un modelo ligeramente distinto del jerárquico; su
diferencia fundamental es la modificación del concepto de nodo: se permite que un
mismo nodo tenga varios padres (posibilidad no permitida en el modelo jerárquico).

Fue una gran mejora con respecto al modelo jerárquico, ya que ofrecía una solución
eficiente al problema de redundancia de datos; pero, aun así, la dificultad que significa

Página: 24/45


administrar la información en una base de datos de red ha significado que sea un
modelo utilizado en su mayoría por programadores más que por usuarios finales.

o Bases de Datos Relacional: Éste es el modelo más utilizado en la actualidad para
modelar problemas reales y administrar datos dinámicamente. Tras ser postulados sus
fundamentos en 1970 por Edgar Frank Codd, de los laboratorios IBM en San José
(California), no tardó en consolidarse como un nuevo paradigma en los modelos de
base de datos. Su idea fundamental es el uso de "relaciones".

Estas relaciones podrían considerarse en forma lógica como conjuntos de datos
llamados "tuplas". Pese a que ésta es la teoría de las bases de datos relacionales
creadas por Edgar Frank Codd, la mayoría de las veces se conceptualiza de una
manera más fácil de imaginar. Esto es pensando en cada relación como si fuese una
tabla que está compuesta por registros (las filas de una tabla), que representarían las
tuplas, y campos (las columnas de una tabla).

En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia
(a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable
ventaja de que es más fácil de entender y de utilizar para un usuario esporádico de la
base de datos. La información puede ser recuperada o almacenada mediante
"consultas" que ofrecen una amplia flexibilidad y poder para administrar la información.

El lenguaje más habitual para construir las consultas a bases de datos relacionales es
SQL, Structured Query Language o Lenguaje Estructurado de Consultas, un estándar
implementado por los principales motores o sistemas de gestión de bases de datos
relacionales.

Durante su diseño, una base de datos relacional pasa por un proceso al que se le
conoce como normalización de una base de datos.

Durante los años '80 (1980-1989) la aparición de dBASE produjo una revolución en los
lenguajes de programación y sistemas de administración de datos.

Aunque nunca debe olvidarse que dBase no utilizaba SQL como lenguaje base para su
gestión.

o Bases de Datos Orientada a Objetos: Este modelo, bastante reciente, y propio de los
modelos informáticos orientados a objetos, trata de almacenar en la base de datos los
objetos completos (estado y comportamiento).

Una base de datos orientada a objetos es una base de datos que incorpora todos los
conceptos importantes del paradigma de objetos:

Encapsulación - Propiedad que permite ocultar la información al resto de los objetos,
impidiendo así accesos incorrectos o conflictos.

Herencia - Propiedad a través de la cual los objetos heredan comportamiento dentro de
una jerarquía de clases.

Página: 25/45


Polimorfismo - Propiedad de una operación mediante la cual puede ser aplicada a
distintos tipos de objetos.
En bases de datos orientadas a objetos, los usuarios pueden definir operaciones sobre
los datos como parte de la definición de la base de datos.

Una operación (llamada función) se especifica en dos partes. La interfaz (o signatura)
de una operación incluye el nombre de la operación y los tipos de datos de sus
argumentos (o parámetros). La implementación (o método) de la operación se
especifica separadamente y puede modificarse sin afectar la interfaz.

Se está trabajando en SQL3, que es el estándar de SQL92 ampliado, que soportará los
nuevos conceptos orientados a objetos y mantendría compatibilidad con SQL92.

o Bases de Datos Documentales: Permiten la indexación a texto completo, y en líneas
generales realizar búsquedas más potentes. Tesaurus es un sistema de índices
optimizado para este tipo de bases de datos.

o Bases de Datos Deductivas: Un sistema de base de datos deductivas, es un sistema
de base de datos pero con la diferencia de que permite hacer deducciones a través de
inferencias. Se basa principalmente en reglas y hechos que son almacenados en la
base de datos.

También las bases de datos deductivas son llamadas base de datos lógica, a raíz de
que se basan en lógica matemática.

o Gestión de Bases de Datos Distribuida: La base de datos está almacenada en varias
computadoras conectadas en red. Surgen debido a la existencia física de organismos
descentralizados. Esto les da la capacidad de unir las bases de datos de cada localidad
y acceder así a distintas universidades, sucursales de tiendas, etc.

1.8. Lenguajes de Bases de Datos.

Los sistemas de bases de datos proporcionan un lenguaje de definición de datos para
especificar el esquema de la base de datos y un lenguaje de manipulación para expresar las
consultas y las modificaciones de la base de datos. En la práctica, los lenguajes de definición y
manipulación de datos no son dos lenguajes diferentes; simplemente forma parte de un único
lenguaje de bases de datos, como puede ser el muy usado SQL (Structured Query Language).

• Creado por IBM alrededor de los años 70s
• Combinación de álgebra relacional y cálculo relacional
• En 1986 ANSI e ISO lo estandarizan en SQL-86
• Otras versiones: SQL-92, SQL-99

1.8.1. Lenguaje de Manipulación de los Datos (DML).

Permite a los usuarios tener acceso a los datos organizados mediante un modelo de datos
correspondiente a manipularlos. Los tipos de acceso son:

o La recuperación de la información almacenada en la base de datos. (SELECT,
UNION, JOIN)

Página: 26/45


o La inserción de información nueva en la base de datos. (INSERT)
o El borrado de la información de la base de datos. (DELETE)
o La modificación de la información almacenada en la base de datos. (UPDATE).

Una consulta se expresa mediante tres cláusulas:

SELECT seguida de una lista de atributos que interese obtener como respuesta (SELECT A1
,..., An).
FROM seguida de la lista de las relaciones que usamos en la consulta (FROM r1,...,rm).
WHERE (cláusula opcional) va seguida del predicado de selección (WHERE p).

Nota: El nombre de la cláusula SELECT es engañoso, ya que lo que hace no es una selección,
sino una proyección.

Equivalencia entre una consulta en SQL, y en álgebra relacional:

SELECT A1,...,An
FROM r1,...,rm ≈ •A1 ,..., An (• P
(r1 x r2 x .... x rm))
WHERE P

Operaciones posibles en SQL, por medio de ejemplos:

"Seleccionar todos los atributos de préstamo para los préstamos de más de mil €".
(Selección)

SELECT nombre_sucursal, num_prestamo, nombre_cliente, importe
FROM prestamo
WHERE importe > 1000

Existen fundamentalmente dos tipos:

Los DMLs procedimentales necesitan que el usuario especifique qué datos se necesitan y
cómo obtener esos datos.

Los DMLs declarativos (también conocidos como DML no procedimentales) necesitan que el
usuario especifique qué datos se necesitan sin que haga falta que especifique cómo obtener
esos datos. Suelen se más fáciles de aprender y usar que los procedimentales.

Una consulta es una instrucción que solicita que se recupere información. La parte de los DMLs
implicada en la recuperación de información se denomina lenguaje de consultas. Aunque
técnicamente sea incorrecto, resulta habitual usar las expresiones lenguaje de consultas y
lenguajes de manipulación como sinónimas.

Página: 27/45


1.8.2. Lenguaje de Definición de los Datos (DDL).

Los esquemas de las bases de datos se especifican mediante un conjunto de definiciones
expresadas mediante un lenguaje especial denominado lenguaje de definición de datos.
También se usa para especificar más propiedades de los datos.

La estructura de almacenamiento y los métodos de acceso usados por el sistema de base de
datos se especifican mediante un conjunto de instrucciones en un tipo especial de LDD
denominado lenguaje de almacenamiento y definición de datos. Estas instrucciones definen los
detalles de implementación de los esquemas de las bases de datos, que suelen ocultarse a los
usuarios.

Los valores de los datos almacenados en la base de datos deben satisfacer ciertas
restricciones de consistencia. Ejm: saldo < 100.00 no debe ser. El LDD proporciona
facilidades para responder a tales restricciones. Los sistemas de base de datos se concentran
en las restricciones de integridad que pueden comprobarse con una sobrecarga mínima.

o Restricciones de Dominio: Se debe asociar un dominio de valores posibles a cada
atributo. La declaración de un atributo como parte de un dominio concreto actúa como
restricción de los valores que puede adoptar. Las restricciones de dominio son la forma
más elemental de restricción de integridad. El sistema las comprueba fácilmente siempre
que se introduce un nuevo elemento de datos en la base de datos.

o Integridad Referencial: Se desea asegurar que un valor que aparece en una relación para
un conjunto de atributos dado aparece también para un determinado conjunto de atributos
en otra relación.

o Asertos: Es cualquier condición que la base de datos debe satisfacer siempre. Las
restricciones de dominio y de integridad referencial son formas especiales de asertos.
Cuando se crea un aserto, el sistema comprueba su validez. Si el aserto es válido,
cualquier modificación futura de la base de datos se permite únicamente si no hace que se
viole ese aserto.

o Autorización: Puede que se desee diferenciar entre los usuarios en cuanto al tipo de
acceso que se les permite a diferentes valores de los datos de la base de datos. Estas
diferenciaciones se expresan en términos de autorización, cuyas modalidades más
frecuentes son: autorización de lectura, inserción, actualización, eliminación.

CREATE

create table table_name (
column_name column_type column_modifiers,
...,
column_name column_type column_modifiers);

create table musicians(
musician_id INT,
last_name CHAR(40),
first_name CHAR(40),
nickname CHAR(40));

Página: 28/45


FOREING CONSTRAINTS: Definición de restricciones de integridad
DROP: Eliminar estructuras
ALTER: modificar estructuras
DATABASE: crear bases de datos
GRANTS: Definir roles, permisos, sinónimos.
VIEWS: Definir objetos virtuales.

1.8.3. Resumen de Comandos.

Comandos DLL
Comando Descripción
CREATE Utilizado para crear nuevas tablas, campos e índices
DROP Empleado para eliminar tablas e índices
Utilizado para modificar las tablas agregando campos o cambiando la definición de
ALTER
los campos.
Comandos DML
Comando Descripción
Utilizado para consultar registros de la base de datos que satisfagan un criterio
SELECT
determinado
INSERT Utilizado para cargar lotes de datos en la base de datos en una única operación.
UPDATE Utilizado para modificar los valores de los campos y registros especificados
DELETE Utilizado para eliminar registros de una tabla de una base de datos

Cláusulas.

Las cláusulas son condiciones de modificación utilizadas para definir los datos que desea
seleccionar o manipular.

Cláusula Descripción
FROM Utilizada para especificar la tabla de la cual se van a seleccionar los registros
Utilizada para especificar las condiciones que deben reunir los registros que
WHERE
se van a seleccionar
GROUP BY Utilizada para separar los registros seleccionados en grupos específicos
HAVING Utilizada para expresar la condición que debe satisfacer cada grupo
Utilizada para ordenar los registros seleccionados de acuerdo con un orden
ORDER BY
específico

Página: 29/45


Operadores Lógicos.

Operador Uso
Es el "y" lógico. Evalúa dos condiciones y devuelve un valor de verdad sólo si
AND
ambas son ciertas.
Es el "o" lógico. Evalúa dos condiciones y devuelve un valor de verdad si
OR
alguna de las dos es cierta.
NOT Negación lógica. Devuelve el valor contrario de la expresión.

Operadores de Comparación

Operador Uso
< Menor que
> Mayor que
<> Distinto de
<= Menor o igual que
>= Mayor o igual que
= Igual que
BETWEEN Utilizado para especificar un intervalo de valores.
LIKE Utilizado en la comparación de un modelo
In Utilizado para especificar registros de una base de datos

Funciones de Agregado.

Las funciones de agregado se usan dentro de una cláusula SELECT en grupos de registros
para devolver un único valor que se aplica a un grupo de registros.

Función Descripción
AVG Utilizada para calcular el promedio de los valores de un campo determinado
COUNT Utilizada para devolver el número de registros de la selección
SUM Utilizada para devolver la suma de todos los valores de un campo determinado
MAX Utilizada para devolver el valor más alto de un campo especificado
MIN Utilizada para devolver el valor más bajo de un campo especificado

Página: 30/45


1.9. Bases de Datos Relacionales.

Es una base de datos que cumple con el modelo relacional, modelo más utilizado en la
actualidad para modelar problemas reales y administrar datos dinámicamente. Permiten
establecer interconexiones (relaciones) entre los datos (que están guardados en tablas), y
trabajar con ellos conjuntamente. Tras ser postuladas sus bases en 1970 por Edgar Frank
Codd, de los laboratorios IBM en San José (California), no tardó en consolidarse como un
nuevo paradigma en los modelos de base de datos.[1]

Usan un conjunto de tablas para representar tanto los datos como las relaciones entre ellos.
También incluyen un DML y DLL descritos en la sección anterior. La mayor parte de los
sistemas de bases de datos relacionales comerciales emplean el lenguaje SQL.

En las bases de Codd se definían los objetivos de este modelo:

• Independencia física. La forma de almacenar los datos, no debe influir en su
manipulación lógica.

• Independencia lógica. Las aplicaciones que utilizan la base de datos no deben ser
modificadas por que se modifiquen elementos de la base de datos.

• Flexibilidad. La base de datos ofrece fácilmente distintas vistas en función de los
usuarios y aplicaciones.

• Uniformidad. Las estructuras lógicas siempre tienen una única forma conceptual (las
tablas)

• Sencillez.

1.9.1. Elementos.

Relaciones Base y Derivadas.

En una base de datos relacional, todos los datos se almacenan y se acceden a ellos por medio
de relaciones.

Relaciones Base: Son las relaciones que almacenan datos y su implementación es llamada
"tabla".

Relaciones Derivadas: Las relaciones que no almacenan datos, pero son calculadas al aplicar
operaciones relacionales; su implementación es llamada "vista" o "consulta".

Las relaciones derivadas son convenientes ya que expresan información de varias relaciones
actuando como si fuera una sola.

Restricciones.

Una restricción es una condición que obliga el cumplimiento de ciertas condiciones en la base
de datos. Algunas no son determinadas por los usuarios, sino que son inherentemente

Página: 31/45


definidas por el simple hecho de que la base de datos sea relacional. Algunas otras
restricciones las puede definir el usuario, por ejemplo, usar un campo con valores enteros entre
1 y 10.

Las restricciones proveen un método de implementar reglas en la base de datos. Las
restricciones restringen los datos que pueden ser almacenados en las tablas. Usualmente se
definen usando expresiones que dan como resultado un valor booleano, indicando si los datos
satisfacen la restricción o no.

Las restricciones no son parte formal del modelo relacional, pero son incluidas porque juegan el
rol de organizar mejor los datos. Las restricciones son muy discutidas junto con los conceptos
relacionales.

Dominios.

Un dominio describe un conjunto de posibles valores para cierto atributo. Como un dominio
restringe los valores del atributo, puede ser considerado como una restricción.
Matemáticamente, atribuir un dominio a un atributo significa "todos los valores de este atributo
deben de ser elementos del conjunto especificado".
Distintos tipos de dominios son: enteros, cadenas de texto, fecha, etc.

Clave Única.

Cada tabla puede tener uno o más campos cuyos valores identifican de forma única cada
registro de dicha tabla, es decir, no pueden existir dos o más registros diferentes cuyos valores
en dichos campos sean idénticos. Este conjunto de campos se llama clave única.

Pueden existir varias claves únicas en una determinada tabla, y a cada una de éstas suele
llamársele candidata a clave primaria.

Clave Primaria

Una clave primaria es una clave única elegida entre todas las candidatas que define
unívocamente a todos los demás atributos de la tabla, para especificar los datos que serán
relacionados con las demás tablas. La forma de hacer esto es por medio de claves foráneas.

Sólo puede existir una clave primaria por tabla y ningún campo de dicha clave puede contener
valores NULL.

Clave Foránea.

Una clave foránea es una referencia a una clave en otra tabla. Las claves foráneas no
necesitan ser claves únicas en la tabla donde están y sí a donde están referenciadas.
Por ejemplo, el código de departamento puede ser una clave foránea en la tabla de empleados,
obviamente se permite que haya varios empleados en un mismo departamento, pero existirá
sólo un departamento.

Página: 32/45


Clave Índice.

Las claves índices surgen con la necesidad de tener un acceso más rápido a los datos. Los
índices pueden ser creados con cualquier combinación de campos de una tabla. Las consultas
que filtran registros por medio de estos campos, pueden encontrar los registros de forma no
secuencial usando la clave índice.

Las bases de datos relacionales incluyen múltiples técnicas de ordenamiento, cada una de
ellas es óptima para cierta distribución de datos y tamaño de la relación.
Los índices generalmente no se consideran parte de la base de datos, pues son un detalle
agregado. Sin embargo, las claves índices son desarrolladas por el mismo grupo de
programadores que las otras partes de la base de datos.

Procedimientos Almacenados.

Un procedimiento almacenado es código ejecutable que se asocia y se almacena con la base
de datos. Los procedimientos almacenados usualmente recogen y personalizan operaciones
comunes, como insertar un registro dentro de una tabla, recopilar información estadística, o
encapsular cálculos complejos. Son frecuentemente usados por un API por seguridad o
simplicidad.
Los procedimientos almacenados no son parte del modelo relacional, pero todas las
implementaciones comerciales los incluyen.

Estructura.

La base de datos se organiza en dos marcadas secciones; el esquema y los datos (o
instancia).
El esquema es la definición de la estructura de la base de datos y principalmente almacena los
siguientes datos:

• El nombre de cada tabla
• El nombre de cada columna
• El tipo de dato de cada columna
• La tabla a la que pertenece cada columna

Las bases de datos relacionales pasan por un proceso al que se le conoce como
normalización, el resultado de dicho proceso es un esquema que permite que la base de datos
sea usada de manera óptima.

Los datos o instancia es el contenido de la base de datos en un momento dado. Es en si, el
contenido de todos los registros.

1.9.2. Tablas.

Las bases de datos relacionales se basan en el uso de tablas (también se les llama
(relaciones). Las tablas se representan gráficamente como una estructura rectangular formada
por filas y columnas. Cada columna almacena información sobre una propiedad determinada
de la tabla (se le llama también atributo), nombre, dni, apellidos, edad,....

Página: 33/45


Cada fila posee una ocurrencia o ejemplar de la instancia o relación representada por la tabla
(a las filas se las llama también tuplas).

NOMBRE
Atributo 1 Atributo2 Atributo3 … Atributo n
valor 1,1 valor 1,2 valor m,3 … valor m,n
valor 2,1 valor 2,2 valor 2,3 … valor 2,n
….. ….. ….. ….. …..
valor m,1 valor m,2 2 valor 2,3 … valor 2,n

Representación de una tabla en el modelo relacional

Tablas: Cada tabla tiene varias columnas, y cada columna tiene un nombre único.

Tabla Clientes
Id_cliente Nombre_cliente Calle_cliente Ciudad_cliente
19.283.746 González Arenal, 12 La Granja
67.789.901 López Mayor, 3 Peguerinos
18.273.609 Abril Preciados, 123 Valsaín
32.112.312 Santos Mayor, 100 Peguerinos
33.666.999 Rupérez Rambas, 175 León
01.928.374 Gómez Carretas, 72 Cerceda

El modelo relacional es un modelo basado en registros denominado así por que la base de
datos se estructura en registros de formato fijo de varios tipos. Cada tabla contiene registros de
un tipo dado. Cada tipo de registros define un número fijo de campos, o atributos. Las
columnas de la tabla se corresponden con los atributos del tipo de registro.

Terminología.

• Tupla. Cada fila de la tabla (cada ejemplar que la tabla representa)
• Atributo. Cada columna de la tabla
• Grado. Número de atributos de la tabla
• Cardinalidad. Número de tuplas de una tabla
• Dominio. Conjunto válido de valores representables por un atributo.

Ejemplo de Dominio.

Los dominios suponen una gran mejora en este modelo ya que permiten especificar los
posibles valores válidos para un atributo. Cada dominio incorpora su nombre y una definición
del mismo. Ejemplos de dominio:

Dirección: 50 caracteres
Nacionalidad: Español, Francés, Italiano,...

Página: 34/45


Los dominios pueden ser también compuestos a partir de otros (año, mes y día = fecha)
Es posible especificar directamente el tipo de dato para cada atributo. Pero también se pueden
declarar dominios, y usar el nombre de éstos. Esto facilita hacer cambios en los tipos de datos
(cambiando sólo el dominio y no cada dato declarado). Por ejemplo, podemos crear el dominio
TIPO_RUT con la siguiente instrucción:

CREATE DOMAIN TIPO_RUT AS VARCHAR(10);

A partir de ahora, podemos usar TIPO_RUT en lugar de VARCHAR(10), por ejemplo en los
atributos RUT, RUTSUPERV, RUTGERENTE y ERUT de algún caso de estudio.

CREATE TABLE EMPLEADO
( NPILA VARCHAR(15) NOT NULL,
APPAT VARCHAR(15) NOT NULL,
APMAT VARCHAR(15) NOT NULL,
RUT VARCHAR(10) NOT NULL,
FNAC DATE,
DIRECCION VARCHAR(30),
SEXO CHAR,
SUELDO DECIMAL(5,2),
RUTSUPERV VARCHAR(10),
NDEPTO INT NOT NULL,
PRIMARY KEY (RUT),
FOREIGN KEY (RUTSUPERV) REFERENCES EMPLEADO(RUT),
FOREIGN KEY (NDEPTO) REFERENCES DEPARTAMENTO(DNUMERO));

CREATE TABLE DEPARTAMENTO
( DNOMBRE VARCHAR(15) NOT NULL,
DNUMERO INT NOT NULL,
RUTGERENTE VARCHAR(10) NOT NULL,
GERFECHAINIC DATE,
PRIMARY KEY (DNUMERO),
UNIQUE (DNOMBRE),
FOREIGN KEY (RUTGERENTE) REFERENCES EMPLEADO(RUT));

CREATE TABLE UBICACIONES_DEPTO
( DNUMERO INT NOT NULL,
DUBICACION VARCHAR(15) NOT NULL,
PRIMARY KEY (DNUMERO, DUBICACION),
FOREIGN KEY (DNUMERO) REFERENCES DEPARTAMENTO(DNUMERO));

CREATE TABLE PROYECTO
( PNOMBRE VARCHAR(15) NOT NULL,
PNUMERO INT NOT NULL,
PUBICACION VARCHAR(15),

Página: 35/45


DNUM INT NOT NULL,
PRIMARY KEY (PNUMERO),
UNIQUE (PNOMBRE),
FOREIGN KEY (DNUM) REFERENCES DEPARTAMENTO(DNUMERO));

CREATE TABLE TRABAJA_EN
( ERUT VARCHAR(10) NOT NULL,
PNO INT NOT NULL,
HORAS DECIMAL(3,1) NOT NULL,
PRIMARY KEY (ERUT, PNO),
FOREIGN KEY (ERUT) REFERENCES EMPLEADO(RUT),
FOREIGN KEY (PNO) REFERENCES PROYECTO(PNUMERO));

CREATE TABLE CARGA
( ERUT VARCHAR(10) NOT NULL,
NOMBRE_CARGA VARCHAR(15) NOT NULL,
SEXO CHAR,
FNAC DATE,
PARENTESCO VARCHAR(8),
PRIMARY KEY (ERUT, NOMBRE_CARGA),
FOREIGN KEY (ERUT) REFERENCES EMPLEADO(RUT));

1.9.3. Programas de Aplicación.

SQL no es tan potente como la máquina universal de Turing; es decir, hay algunos cálculos que
no pueden obtenerse mediante ninguna consulta SQL. Estos cálculos deben escribirse en un
lenguaje anfitrión, como C, C++, java. Los programas de aplicación se usan para interactuar de
esta manera con la base de datos. Para tener acceso a la base de datos, las instrucciones DML
deben ejecutarse desde el lenguaje anfitrión.

1.10. Diseño de Base de Datos

Implica principalmente el diseño del esquema de las bases de datos. El diseño de un entorno
completo de aplicaciones para la base de datos que satisfaga las necesidades de la empresa
que se está modelando; exige prestar atención a un conjunto de aspectos más amplio.

1.10.1. Ciclo de Vida de las Aplicaciones de Bases de Datos

Las etapas del ciclo de vida de una aplicación de bases de datos son las siguientes:

• Planificación del proyecto.
• Definición del sistema.
• Recolección y análisis de los requisitos.
• Diseño de la base de datos.
• Selección del SGBD.
• Diseño de la aplicación.
• Prototipado.

Página: 36/45


• Implementación.
• Conversión y carga de datos.
• Prueba.
• Mantenimiento.

Estas etapas no son estrictamente secuenciales. De hecho hay que repetir algunas de las
etapas varias veces, haciendo lo que se conocen como ciclos de realimentación. Por ejemplo,
los problemas que se encuentran en la etapa del diseño de la base de datos pueden requerir
una recolección de requisitos adicional y su posterior análisis.

Abordaje de diseño escalonado de base de datos.

La base de datos se puede diseñar en tal forma que pueda evolucionar y cambia para
satisfacer futuras necesidades de información de la organización. Esta evolución es posible
cuando el diseñador crea un verdadero modelo conceptual de la organización con las
siguientes características:

El modelo refleja fehacientemente las operaciones de la organización.
Es lo bastante flexible para permitir cambios conforme surjan necesidades de
información.
Apoya muchas visiones de usuarios diferentes.
Es independiente de la implementación física.
No depende del modelo de datos usado por un sistema de gestión de base de datos
particular.

“Un modelo de base de datos conceptual bien diseñado protege la fuente de datos al permitirle
evolucionar de modo que sirva a las necesidades de información actuales y del mañana.”

1.10.2. Proceso de Diseño.

Los modelos de datos de alto nivel resultan útiles a los diseñadores de bases de datos al
ofrecerles un marco conceptual en el que especificar, de manera sistemática, los requisitos de
datos de los usuarios de las bases de datos y la manera en que se estructurará la base de
datos para satisfacer esos requisitos.

Los objetivos del diseño de la base de datos son:

• Representar los datos que requieren las principales áreas de aplicación y los grupos de
usuarios, y representar las relaciones entre dichos datos.
• Proporcionar un modelo de datos que soporte las transacciones que se vayan a realizar
sobre los datos.
• Especificar un esquema que alcance las prestaciones requeridas para el sistema.

La fase inicial del diseño es caracterizar completamente los requisitos de los datos de los
hipotéticos usuarios de la base de datos. Los diseñadores de bases de datos deben interactuar
ampliamente con los expertos y usuarios del dominio para llevar a cabo esta tarea.

A continuación, el diseñador escoge un modelo de datos y mediante, la aplicación de los
conceptos del modelo de datos elegido traduce esos requisitos en un esquema conceptual de

Página: 37/45


la base de datos. Este esquema del diseño conceptual, ofrece la visión general detallada de la
empresa.

En términos del modelo relacional, el proceso de diseño conceptual implica decisiones sobre
qué atributos se desea capturar en la base de datos y cómo agruparlos para formar las
diferentes tablas.

o Qué: decisión conceptual (modelo entidad-relación)
o Cómo: un problema informático (conjunto de algoritmos, normalización)

Para lograrlo, se siguen las siguientes etapas; de éstas las principales son tres fases: diseño
conceptual, diseño lógico y diseño físico de la base de datos.

Análisis del entorno del usuario.
Desarrollo de un modelo de datos conceptual.
Elección de un DBMS.
Desarrollo del modelo lógico.
Desarrollo del modelo físico.
Realización de una afinación si lo indica la evaluación.
Implementación del modelo físico.
Análisis de Entorno del Usuario.

Desarrollo del Modelo
Conceptual

Elección del DBMS

Desarrollo del Modelo Lógico

Desarrollo del Modelo Físico

Evaluación del Modelo Físico

Afinación del Sistema

Implementación del Sistema

Página: 38/45


Diseño Conceptual.

En esta etapa se debe construir un esquema de la información que se usa en la empresa,
independientemente de cualquier consideración física. A este esquema se le denomina
esquema conceptual. Al construir el esquema, los diseñadores descubren la semántica
(significado) de los datos de la empresa: encuentran entidades, atributos y relaciones. El
objetivo es comprender:

• La perspectiva que cada usuario tiene de los datos.
• La naturaleza de los datos, independientemente de su representación física.
• El uso de los datos a través de las áreas de aplicación.
•
El esquema conceptual se puede utilizar para que el diseñador transmita a la empresa lo que
ha entendido sobre la información que ésta maneja. Para ello, ambas partes deben estar
familiarizadas con la notación utilizada en el esquema. La más popular es la notación del
modelo entidad-relación, que se describirá en el capítulo dedicado al diseño conceptual.

El esquema conceptual se construye utilizando la información que se encuentra en la
especificación de los requisitos de usuario. El diseño conceptual es completamente
independiente de los aspectos de implementación, como puede ser el SGBD que se vaya a
usar, los programas de aplicación, los lenguajes de programación, el hardware disponible o
cualquier otra consideración física. Durante todo el proceso de desarrollo del esquema
conceptual éste se prueba y se valida con los requisitos de los usuarios. El esquema
conceptual es una fuente de información para el diseño lógico de la base de datos.

Diseño Lógico.

El diseño lógico es el proceso de construir un esquema de la información que utiliza la
empresa, basándose en un modelo de base de datos específico, independiente del SGBD
concreto que se vaya a utilizar y de cualquier otra consideración física.

En esta etapa, se transforma el esquema conceptual en un esquema lógico que utilizará las
estructuras de datos del modelo de base de datos en el que se basa el SGBD que se vaya a
utilizar, como puede ser el modelo relacional, el modelo de red, el modelo jerárquico o el
modelo orientado a objetos. Conforme se va desarrollando el esquema lógico, éste se va
probando y validando con los requisitos de usuario.

La normalización es una técnica que se utiliza para comprobar la validez de los esquemas
lógicos basados en el modelo relacional, ya que asegura que las relaciones (tablas) obtenidas
no tienen datos redundantes. Esta técnica se presenta en el capítulo dedicado al diseño lógico
de bases de datos.

El esquema lógico es una fuente de información para el diseño físico. Además, juega un papel
importante durante la etapa de mantenimiento del sistema, ya que permite que los futuros
cambios que se realicen sobre los programas de aplicación o sobre los datos, se representen
correctamente en la base de datos.

Página: 39/45


Tanto el diseño conceptual, como el diseño lógico, son procesos iterativos, tienen un punto de
inicio y se van refinando continuamente. Ambos se deben ver como un proceso de aprendizaje
en el que el diseñador va comprendiendo el funcionamiento de la empresa y el significado de
los datos que maneja. El diseño conceptual y el diseño lógico son etapas clave para conseguir
un sistema que funcione correctamente. Si el esquema no es una representación fiel de la
empresa, será difícil, sino imposible, definir todas las vistas de usuario (esquemas externos), o
mantener la integridad de la base de datos. También puede ser difícil definir la implementación
física o el mantener unas prestaciones aceptables del sistema. Además, hay que tener en
cuenta que la capacidad de ajustarse a futuros cambios es un sello que identifica a los buenos
diseños de bases de datos. Por todo esto, es fundamental dedicar el tiempo y las energías
necesarias para producir el mejor esquema que sea posible

Diseño Físico.

El diseño físico es el proceso de producir la descripción de la implementación de la base de
datos en memoria secundaria: estructuras de almacenamiento y métodos de acceso que
garanticen un acceso eficiente a los datos.

Para llevar a cabo esta etapa, se debe haber decidido cuál es el SGBD que se va a utilizar, ya
que el esquema físico se adapta a él. Entre el diseño físico y el diseño lógico hay una
realimentación, ya que algunas de las decisiones que se tomen durante el diseño físico para
mejorar las prestaciones, pueden afectar a la estructura del esquema lógico.

En general, el propósito del diseño físico es describir cómo se va a implementar físicamente el
esquema lógico obtenido en la fase anterior. Concretamente, en el modelo relacional, esto
consiste en:

• Obtener un conjunto de relaciones (tablas) y las restricciones que se deben cumplir
sobre ellas.
• Determinar las estructuras de almacenamiento y los métodos de acceso que se van a
utilizar para conseguir unas prestaciones óptimas.
• Diseñar el modelo de seguridad del sistema.

1.10.3. El Modelo Entidad Relación.

Está basado en la percepción del mundo real que consiste en un conjunto de objetos básicos,
denominados entidades, y de las relaciones entre esos objetos. Una entidad es un cosa u
objeto del mundo real que es distinguible entre objetos. Las entidades se describen en las
bases de datos mediante un conjunto de atributos. Ejm: numero_cuenta, saldo constituye
atributos de la entidad cuenta.

Se usa un atributo extra para identificar unívocamente a los clientes

Una relación es una asociación entre varias entidades. El conjunto de todas las entidades del
mismo tipo y el conjunto de todas las relaciones del mismo tipo se denominan,
respectivamente, conjunto de entidades y conjunto de relaciones.

La estructura lógica general de la base de datos se puede expresar gráficamente mediante un
diagrama entidad relación que está constituido por los siguientes componentes.

Página: 40/45


o Rectángulos: conjunto de entidades
o Elipses: atributos
o Rombos: conjunto de relaciones entre los miembros de varios conjuntos de entidades.
o Líneas: unen los atributos con los conjuntos de entidades entre sí, y también los
conjuntos de entidades con las relaciones.

Calle_cliente

Número_cuenta saldo
Nombre_cliente Ciudad_cliente

Id_cliente

impositor
Cliente cuenta

Componentes de un Diagrama Entidad Relación

1.10.4. Normalización.

Descomposición sin pérdida de información ni de semántica de la relación universal (o de una
colección de relaciones equivalentes a la misma) en una colección de relaciones en la que las
anomalías de actualización (inserción, borrado y modificación) no existan o sean mínimas.

Normalización es un conjunto de reglas que sirven para ayudar a los diseñadores a desarrollar
un esquema que minimice los problemas de lógica. Cada regla está basada en la que le
antecede. La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo
lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a errores de
lógica cuando se trataba de manipular los 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:

Página: 41/45


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

Cuando realizamos un diseño en el modelo relacional, tenemos diferentes alternativas,
pudiendo obtener diferentes esquemas relacionales, y no todos ellos serán equivalentes, unos
representarán la información mejor que otros.

En la estructura del Modelo Relacional la información de nuestra base de datos puede
representarse mediante un conjunto de objetos, dominios y relaciones y de un conjunto de
reglas de integridad.

Las relaciones obtenidas pueden presentar problemas

• Incapacidad para representar ciertos hechos.
• Redundância en la información, lo que dará lugar a incoherencias
• Ambiguedades.
• Aparición en la base de datos que no son válidos em el mundo real:anomalias de
modificación, insercción y borrado.

Ejemplo:

ESCRIBE
AUTOR NACIONALIDAD COD_LIBRO TITULO EDITORIAL AÑO
DATE C. Norteamericana
CODD E. Norteamericana
GARDARIN Francesa
GARDARIN Francesa
VALDURIEZ Ffrancesa
KIM, W. Norteamericana
LOCHOVSKY Canadiense

En el ejemplo la relación escribe almacena datos sobre autores de libros (autor y nacionalidad
) y sobre los libros (código, título, editorial, año).

La relación escribe presenta varios de los problemas citados anteriormente.

• Gran cantidad de Redundancia: La nacionalidad del autor se repite por cada
ocurrencia del mismo. Del mismo modo, cuando un libro tiene más de un autor, la
editorial y el año de publicación se repiten también.
• Anomalías de Modificación: Puede ocurrir que modifiquemos el nombre de la editorial
en una fila sin modificarlo en el resto de las que corresponden al mismo libro lo que da
lugar a incoherencias.

Página: 42/45

Apunte capítulo I

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Viewers also liked

Viewers also liked (10)

Similar to Apunte capítulo I

Similar to Apunte capítulo I (20)

Recently uploaded

Recently uploaded (16)

Apunte capítulo I